#header-inner {background-position: right !important; width: 100% !important;}

1/30/14

IPv4 Datagram.

Network-layer packet is referred to as a datagram.

Fields.

The key fields in the IPv4 datagram are the following:

* Version number (4 bits) : these bits determine how to interpret rest of the datagram. This article deals with IPv4 datagrams.
* Header Length (4 bits) : because option field is variable length, this field determines where in the IP datagram the data field actually begins. Most IP datagrams do not contain options, so typical IP datagram has a 20 byte header.
* Type of Service (8 bits) : the type of service (TOS) bits were included in the IPv4 header to allow different types of IP dtagrams (for example: datagrams particularly requiring low delay, high throughput, or reliability) to be distinguished from each other.
* Datagram length (16 bits) : This is total length of the IP datagram (header plus data), measured in bytes. Since this field is 16 bits long, the theoretical maximum size of the IP datagram is 65,535 bytes. However, datagrams are rarely larger than 1500 bytes.
* Identifier (16 bits), Flags (3 bits), Fragmentation offset (13 bits) : used to handle IP Datagram Fragmentation.
* Time-to-live (8 bits) : The time-to-live (TTL) field is included to ensure that datagrams do not circulate forever (due to, for example, a long-lived routing loop) in the network. This field is decremented by one each time the datagram is processed by a router. If the TTL field reaches 0, the datagram must be dropped.
* Upper layer protocol (8 bits) : The value of this field indicates the specific transport layer prtocol to which the data portion of this IP datagram should be passed (for example: 6 means TCP and 17 indicates that the data is passed to UDP).
* Header checksum (16 bits) : The header checksum aids a router in detecting bit errors in a received IP datagram.
* Source IP address (32 bits).
* Destination IP address (32 bits).
* Options (variable, if any) : The options fields allow an IP header to be extended.
* Data (variable) : transport-layer segment (TCP or UDP) to be delivered to the destination. Or other data, such as ICMP messages.


IPv4 datagram format

------------ 32 bits -----------
12345678901234567890123456789012
--------------------------------
Ver.Hdr.TOS.....Datagram-length.
Identifier......Flg.Fragm-offset
TTL.....ProtocolChecksum........
Source IP address...............
Destination IP address..........
Options (if any)................
Data............................
................................
--------------------------------
12345678901234567890123456789012
--------------------------------


Header Checksum.

The header checksum aids a router in detecting bit errors in a received IP datagram. The header checksum is computed by treating each 2 bytes in the header as number (with the checksum bytes set to 0), and summing these numbers using 1's complement arithmetic, with adding carry bits. It is also stored in the header checksum field. A router computes the header checksum for each received IP datagram and detects an error condition if the checksum carried in the datagram header does not equal the computed checksum. Routers typically discard datagram for which an error has been detected. Note that checksum must be recalculated and stored again at each router, as the TTL field, and possibly the options field as well, may change.


IP datagram fragmentation.

Different link-layer protocols use different packet sizes. Network-layer packets, also called datagrams, are encapsulated in these link layer packets. Because network-layer communication involves more than one hop, datagrams sometimes need to be 'repackaged' into two or more datagrams to be sent into outgoing links. Each of these smaller datagrams is called 'fragment'.

Fragments need to be reassembled before they reach the transport layer at the destination. Indeed, both TCP and UDP are expecting to receive complete, unfragmented segments from the network layer.

for example:

Fragments with black and white. photo fragments_bb_wt_zps2f5ae510.png



Source: [3].

No comments:

Post a Comment