Internet Protocol:
Connectionless Datagram
Delivery (IPv4)
Chapter 6
1
Have looked at HW & SW that make
internet communication possible
Now begin looking at IP



Internet Protocol
Provides connectionless delivery
IP datagrams form basis for all internet
communication
2
Internet Philosophy
Focus: interface internet provides to users

Not on the interconnection technology
User sees single virtual network

Underlying architecture is hidden and irrelevant
Conceptually, TCP/IP provides three sets
of services:
Application
Services
Reliable Transport Service
Connectionless Packet Delivery Service
3
Protocol SW can be associated with each


Instead, consider them conceptual internet parts
Embody philosophical underpinnings of design
Internet SW designed around the conceptual services
Surprisingly robust and adaptable architecture
Adv of conceptual separation
 Can replace one service without disturbing others
R&D can proceed concurrently on all three
4
Connectionless Delivery System
Most fundamental internet service:

Packet delivery system
Technically, the service is:

Unreliable
Packet can be lost, duplicated, delayed, out-of-order
No notification of such problems

Best-effort
Makes earnest attempt to deliver

Connectionless
Packets treated independently
5
Purpose of the IP
IP: protocol that defines delivery service

Specifies basic unit of transfer
Exact format of data

Performs the routing function
Chooses the paths for packets

Includes rules for unreliable packet delivery
How hosts and routers process packets
How and when error messages are generated
When packets can be discarded
6
Internet Datagram
Physical network:

Unit of transfer is frame
Contains header and data
Internet

Unit of transfer is Internet datagram
IP datagram or datagram
Contains header and data
Header difference:

IP addresses versus physical addresses
7
IP Datagram
Datagram Header
Datagram Data Area
Datagram format
0
4
VERS
8
HLEN
16
Service Type
24
31
Total Length
Identification
Time to Live
19
Flags
Protocol
Fragment Offset
Header Checksum
Source IP Address
Destination IP Address
IP Options (if any)
Padding
Data
...
8
Service Type field:

Originally
0
1
2
PRECEDENCE

3
4
5
D
T
R
6
7
UNUSED
Precedence 0-7
Routers use 6 or 7 (info goes thru during congestion)



D: low delay
T: high throughput
R: high reliability
9

Later
0
1
2
3
CODEPOINT


4
5
6
7
UNUSED
Differential Services interpretation
Have 8 ordered classes when of form:
xxx000
Just like previous precedence
6 or 7 goes to high priority class of service

Codepoint values divided into 3 groups:
xxxxx0 : assigned by Standards organization
xxxx11 : local or experimental
xxxx01 : local or experimental for now
10
Regardless of the interpretation:


Service type specification is a hint to the
routing algorithm
Chose among various paths based on:
Local policies
Knowledge of technologies available on the paths

No guarantee to provide a type of service
11
Datagram Encapsulation
How long can a datagram be?


Handled by SW (not HW)
Any length protocol designers want
IPv4 has 16 bits for total length field

Limit is 65,535 octets
But, want efficient transportation

Map abstract physical packet to real packet
12
Encapsulation:



Idea to carry 1 datagram in 1 network frame
Underlying HW not concerned with datagram
One machine to another: datagram is in the
data portion of a frame
Datagram
Header

Frame
Header
Datagram Data Area

Frame Data Area
13
Ideal: entire IP datagram in one frame



Would need maximum datagram size
What would that be?
Look at network hardware:
MTU: maximum transfer unit





Ethernet: 1500 octet MTU
FDDI: 4470 octet MTU
Some hardware: 128 octets or less
Limit to smallest: inefficient
If bigger than MTU: need multiple frames
14
Design goal: convenience for user

Not worry about physical network constraints
Solution:


Pick convenient initial datagram size
Have way to divide up for small MTU
Pieces of divided datagram: fragments
Process of dividing: fragmentation
15
Fragmentation usually occurs along the path
Host A
Host B
Net 1
Net 3
MTU=1500
MTU=1500
R1
Net 2
R2
MTU=62
0
16
Fragments sized for one per frame
Size is a multiple of eight

Last piece may be shorter than rest
Fragments must be reassembled

Datagram must be rebuilt before processing
IP does not limit datagrams to small size




Source can choose any size
Fragmentation and reassembly are automatic
Routers must accept datagrams up to max size of
MTU’s of attached networks
Routers must handle datagrams up to 576 octets
Each piece formatted like original datagram
17
Datagram
Header
(600 octets)
Fragment1
Header
Data1
Fragment 1 (offset 0)
Fragment2
Header
Data2
Fragment 2 (offset 600)
Fragment3
Header
Data1
Data3
Data2
(600 octets)
Data3
(200 octets)
Fragment 3 (offset 1200)
Fragment header mostly the same as
datagram header

Bit in the FLAGS field; Value in TOTAL LENGTH
field; checksum
18
Reassembly of Fragments
Reassembly after each hop or at end?
TCP/IP: once fragmented, stays that way

Reassemble at ultimate destination (host)
Two disadvantages:


Inefficient if other networks have higher MTU
Probability of datagram loss increases with more
fragments
Advantages:


Fragments can be routed independently
Intermediate routers do not have to store or
reassemble
19
Fragmentation Control
Three datagram header fields control
fragmentation and reassembly:

Identification
Unique integer to ID the datagram

Fragment Offset
Offset in original datagram of data being carried

Flags
Use two low-order bits of 3-bit field
1st bit: if set, means do not fragment
Low bit: more fragments bit
20
Time to Live (TTL)
TTL specifies how long, in seconds, datagram
is allowed to remain in the internet system



Router & hosts that process must decrement TTL
Remove when time expires
Each router decrements TTL by 1
If long delay, decrement by number seconds there

When TTL = 0, discard and send error message
Guarantees datagram not be around forever
Mostly, TTL acts as hop limit

Rather than estimate of delay
21
Other Datagram Header Fields
PROTOCOL


Tells which high-level protocol used in creation
Specifies format of data area
HEADER CHECKSUM




Ensures integrity of header values
Only applies to header, not data
Adv:
Header smaller; routers only worry about headers
Higher level protocols choose own data checksum
scheme
Disadv:
Higher level protocols must add their own data
checksum
22
SOURCE IP ADDRESS
DESTINATION IP ADDRESS


Contain 32-bit IP addresses of sender & recipient
Never change when going through routers
IP OPTIONS


Variable length
PADDING field depends upon options selected
23
Datagram Options
IP OPTIONS field not required


Used mostly for network testing and debugging
Option processing is integral part of IP protocol
Field length varies based on options selected


Options appear contiguously; no separators
Each option:
Consists of single octet option code
Followed by single octet length & set of data octets
24
Option code octet divided into three fields
0
Copy

1
2
Option
Class
3
4
5
6
7
Option Number
COPY flag controls how routers treat options
during fragmentation
Set to 1: copy options to all fragments
Set to 0: only copy into first fragment

CLASS & NUMBER fields specify general option
class and a specific option in the class
Class 0: datagram or network control
Class 1: Reserved for future use
Class 2: Debugging and measurement
Class 3: Reserved for future use
25
Record Route Option
Source creates empty list of IP addresses

Each router adds its IP address to the list
Format:
0
8
Code (7)
16
Length
24
31
Pointer
First IP Address
Second IP Address
...
27
Original source must allocate enough
space for the addresses
When a machine handles the datagram:

Compare pointer and length fields
Pointer > length: list full (not add address)
Otherwise: put 4-octet IP address at pointer
position and increment pointer
Source and destination must agree to use


Source enable option
Destination agree to process resulting list
28
Source Route Option
Sender can dictate path through the internet
Format:
0
Code (137)
8
16
Length
24
31
Pointer
IP Address of first hop
IP Address of second hop
...


Test throughput over particular network
Average user would not know topology
29
Strict source routing:


Addresses specify exact path
Path between addresses must be a single
network
Loose source routing


Datagram must follow sequence of IP addresses
May be multiple hops between addresses
Processing similar to record route option

When router follows an IP address, it replaces
the IP address with its own address
30
Timestamp Option
Initially empty list
Each router adds:


32-bit IP address
32-bit integer timestamp
0
8
Code (68)
16
Length
24
Pointer
Oflow
31
Flags
First IP Address
First IP Timestamp
...
31
Oflow (4-bits)

Integer count of routers that could not timestamp
Flags (4-bits)

Controls format of the option
0: Record timestamp only; omit IP addresses
1: Precede each timestamp by an IP address
3: IP addresses are specified by sender; a
router only records a timestamp if the next IP
address in the list matches the router’s IP
address
32
Timestamps tell when router handled the datagram


Expressed as milliseconds since midnight
Based on Universal Time (Greenwich Mean Time)
All computer clocks not necessarily synchronized


Local clocks may differ
Should be treated as estimates
Why not just use record route option?


Eliminates ambiguity
Receiver knows exactly which path the datagram
followed
33
Processing Options During Fragmentation
COPY bit in CODE field



Replicates some options in all fragments
Places some in only one fragment
Ex: Recording the datagram route
Not all fragments will follow the same route
Reassembly would produce conflicting lists
Only put in one fragment

Ex: Source route option
Must be replicated for all fragments to follow same
route
34
Summary
Fundamental TCP/IP service is




Connectionless
Unreliable
Best-effort
Packet delivery
IP formally specifies internet packet format

Called datagram
35
Like physical frame, datagram has header
and data

Header contains:
Source and destination IP addresses
Fragmentation control
Precedence
Checksum
Options field
 Variable in length
 Intended to help monitor and control an internet
36