Home > Articles

  • Print
  • + Share This
This chapter is from the book

Format of an IP Datagram

The format of data that can be recognized by IP is called an IP datagram. It consists of two components, namely, the header and data, which need to be transmitted. The fields in the datagram, except the data, have specific roles to perform in the transmission of data. Every field in the IP datagram has a fixed size except for the IP Options field, which can be 20–60 bytes in length. The sending computer sends a message to the protocol in the same layer on the destination computer by using the header. The format of an IP datagram is displayed in Figure 3.3.

Figure 3.3 The fields in the IP datagram are used for transmitting data.

In the sections that follow, the fields in an IP datagram are discussed in detail.

Version

This field specifies the version of IP used for transferring data. The size of the Version field is 4 bits. Both the sender and the receiver must use the same version of IP to ensure proper interpretation of the fields in the datagram.

Header Length

The size of the Header Length or the IHL field is 4 bits. The Header Length field is used to specify the length of header, which can range from 20 to 60 bytes. You must multiply the value in this field by four to get the length of the IP header. For example, if the value in this field is 3, the length of the header is 3*4, which is 12 bytes.

Total Length

The Total Length field specifies the total length of the datagram. The size of the field is 16 bits. The Total Length field can be calculated as follows:

Total length of the datagram = Length of the header + Length of the data

If a datagram can be accommodated in a frame, data transmission becomes very simple. However, if the size of the datagram is more than the value that can be accommodated in the frame, the datagram must be divided into logical groups called fragments. In few cases, the size of a datagram will be much less than the size of the data that can be passed over the physical medium at one point in time. In that case, padding is done to fill in extra spaces. To find the exact length of the data that is sent over the frame, the Total Length field is used.

Service Type

The Service Type field is used to set priorities or precedence for data transmission. The size of the field is 8 bits. This field is also used to determine the type of service that is required for a particular application. The priority is set using the first three bits and the service type is set using the next three bits. The last two bits are reserved for future use. The Service Type field has two components, Precedence and Types of Service. In the sections that follow, the components of the Service Type field are explained in detail.

Precedence

The component of the Service Type field that is used to set priorities is called Precedence. This component is 3 bits long. Therefore, eight priority values ranging from 0 (000) to 7 (111) can be set. IP specifies the rules for deciding when a packet must be discarded. For example, if congestion occurs on the network, IP identifies the packets that need to be sent immediately and the packets that can be delayed depending on the priority assigned to the packet. If IP is not able to find an alternative, it can discard the packets. If data packets are discarded, ICMP generates an error message and sends it to the Transport layer. The Precedence field was created for programs that were created for the Department of Defense.

Types of Service

The Types of Service (ToS) component is used to determine the type of service that must be provided by the Internet layer depending on the type of application for which the data transfer needs to be done. The types of services that can be provided by IP are maximizing reliability and throughput and minimizing cost and delay. The size of the ToS component is 4 bits. The Transport layer provides the value of this field to the Internet layer. However, the values in these bits are just guidelines and not rules. The devices that operate from the Internet layer use these values to transfer data. The values that can be assigned to this component and a description of each value is provided in Table 3.1. For example, if the application is an Online Transaction Processing (OLTP) system, it will require the delay to be minimized and therefore the value would be 10002. However, in a situation where a bulk transfer of data is to be done, maximizing throughput will be appreciated and thus the value will be 01002.

NOTE

Throughput refers to the capacity of a network to transmit data and is measured by recording the total size of data that is transmitted over a network within a fixed time limit. This is also referred to as bandwidth.

Table 3.1 Values the Types of Service Component Can Take

Binary Value

Description

0000

Normal

0001

Minimizing cost

0010

Maximize reliability

0100

Maximize throughput

1000

Minimize delay


NOTE

0000 is the default value of the Type of Service component.

NOTE

Only one of the ToS bits can be set at any point of time. A value, such as 11002 is invalid. Another important point to be noted is that the TOS bits will be meaningful only if the network devices through which a datagram is routed are programmed to support and provide a quality of service.

Time to Live

The Time to Live (TTL) field is used to specify the time for which a datagram must be retained on the network. This field is 8 bits long. TTL is measured in seconds. The TTL field can be used to improve the performance of a network because it is used to prevent the data packets from remaining indefinitely on the network. TTL values must be set according to the type of service that is required by the network and the speed of the network.

Consider a situation in which a datagram needs to be transmitted over a slow speed network. Considering the fact that the speed of the network is slow, the TTL value must be set to a higher value compared to the one that is set for transmitting the datagram over a high-speed network. If the TTL value is low, the datagram might not reach the intended recipient on time and might eventually be discarded. Another factor that influences the value of the TTL is the type of service that is required by the Application layer.

The TTL value is decremented by every router through which the data packet passes. The TTL value is measured in seconds. The routers decrement the value of the TTL field by 1 second. If the TTL value is 0 before the datagram reaches the destination, the datagram is discarded. After the datagram is discarded, ICMP sends an error message to the Transport layer protocols. The Transport layer then decides whether the data needs to be retransmitted.

Protocol

The Protocol field is used to specify the protocol used to create the data present in the Data field. The size of this field is 8 bits. The values that are assigned to the Protocol field are provided in Table 3.2. IP receives data from all the higher layer protocols. Each layer in the TCP/IP reference model adds information to the data that will be interpreted by the peer protocols to implement certain tasks. Thus, the data part of an IP datagram contains the original data that has to be sent in addition to the headers added by the higher layer protocols. When the datagram is received at the destination, the data needs to be redirected to the appropriate protocol that is operating in the higher layer. For example, IP can interact with TCP or UDP in the higher layers. The protocol plays an important role because messages can be interpreted only by the protocol that created them.

Table 3.2 Values the Protocol Component Can Take

Value (Decimal)

Protocol

1

Internet Control Message Protocol (ICMP)

2

Internet Group Management Protocol (IGMP)

3

Gateway-to-Gateway Protocol (GGP)

4

Internet Protocol (IP)

6

Transmission Control Protocol (TCP)

8

Exterior Gateway Protocol (EGP)

9

Interior Gateway Protocol (IGP)

17

User Datagram Protocol (UDP)

41

Internet Protocol Version 6 (IPv6)

86

Dissimilar Gateway Protocol (DGP)

88

Interior Gateway Routing Protocol (IGRP)

89

Open Shortest Path First (OSPF)


Source Address

The Source Address or the Source IP Address field is 32 bits long and is used to identify the sender of the data. This field is used to redirect error messages to the source in case the datagram is discarded before reaching the destination. The error messages are generated by an ICMP, which also operates from the Internet layer. The address that is specified in this field represents the originator of the message.

Destination Address

The Destination Address or the Destination IP Address field is 32 bits long. This field specifies the final destination of a data packet. However, this field does not provide information about the intermediate devices through which a data packet passes.

NOTE

The details of the intermediate paths that a datagram can take are stored in the local routing table.

To know more about routing tables, see "Routing Concepts," p. 260

Data

The Data field holds the data that needs to be transmitted over the network. The data part of the IP datagram also includes the header information that is sent by the higher layer protocols, such as TCP, HTTP, and so on.

Header Checksum

The Header Checksum field contains the checksum, which is used by the destination to check for the integrity of the transmitted data by applying an algorithm on the IP header. The size of this field is 16 bits. The Header Checksum value is calculated by the sender and is sent along with the IP header. The sender uses a specific algorithm for arriving at the checksum value. When the datagram reaches the destination, the checksum is calculated by the destination by using the same algorithm. If the value that is calculated is not equal to the specified Header Checksum value in the header of the datagram, the packet is discarded. The Header Checksum value is calculated only with the header values and not by using the data. Every intermediate device that receives the data must calculate the Header Checksum value before forwarding it.

NOTE

The Header Checksum value is not calculated based on the data because every intermediate device through which the datagram passes will require more time to calculate the Header Checksum for all the bits in the data part. Calculating the checksum based on data will also reduce the efficiency of the network because the datagrams will be held by the intermediate device for a long time.

NOTE

In addition, the data part of an IP datagram consists of headers created by the higher layer protocols. Performing the check on the data will mean that the intermediate devices must understand the data formats of other protocols and calculate the Header Checksum, which will bring down the performance.

To know more about the C/C++ programming structures implementing an IP datagram, see "Programming Structures For Data Formats," p. 447

Algorithm to Calculate the Header Checksum

The sender uses the following steps to calculate the Header Checksum:

  1. The header part of the IP datagram is divided into sections of 16 bits each.

  2. The values in the sections are added using the one's complement arithmetic. The sum is then complemented and the result forms the Header Checksum.

NOTE

When the Header Checksum is calculated at the sender's end, the value of the Header Checksum is taken as 0.

The following are the steps used by the receiver to check whether the Header Checksum is correct:

  1. The header part of the IP datagram that is received from the sender is divided into sections of 16 bits each.

NOTE

Normally, the size of each section that is created must be 16 bits.

  1. The data in all the sections are added using one's complement arithmetic. The sum obtained is complemented.

NOTE

At the receiving end, all the sections in the IP header are included, whereas at the sender's end the Header Checksum value is taken as 0.

  1. If the result is zero, it means that the data is intact and the packet is retained. Otherwise, it means that the data has undergone a change during the transmission and the packet is discarded.

For example, if the header is 48 bytes long, it will first be divided into different sections of 16 bits each. The values in all the sections are added together by using one's complement arithmetic.

NOTE

One's complement of a binary number can be found by inverting the bits in a binary number. Inversion refers to converting 0s to 1s and vice versa. On the other hand, One's complement arithmetic is a method that specifies the rules for adding two binary numbers. The rules specify that if two 1s are added, the result would be 0 and a carry of 1 would be generated. On the other hand, if three 1s are added, the result would be a 1 and a carry of 1 would be generated. If the addition of the numbers in the last column results in a carry, the sum must be added with 1 to obtain the result.

Calculation of the Header Checksum at the sender's might appear as:

 1111 1110 1001 0110 --------------------------(Section 1)
 1101 1111 1001 0001 -------------------------- (Section 2)
 0000 0000 0000 0000 -------------------------- (Checksum)

Note that the value of the checksum section is taken as zero when the Header Checksum value is calculated at the sender's end. The sum of Section 1, Section 2, and Checksum is

11101 1110 0010 0111 

As the sum that is derived has a carryover of 1, the sum is added to 1 once again.

11101 1110 0010 0111 ---------------------------- (Sum)
     1

The Header Checksum calculated by the sender is

0010 0001 1101 0111 

The Header Checksum at the receiver's end is calculated as:

 1111 1110 1001 0110 --------------------------(Section 1)
 1101 1111 1001 0001 ---------------------------(Section 2)
 0010 0001 1101 0111 ---------------------------(Checksum)

The receiver takes the value of the checksum field from the IP header unlike the sender, which assumes the same to be 0. The sum of Section 1, Section 2, and Checksum is

11111 1111 1111 1110 

The sum obtained has a carryover of 1; therefore, the sum is added to 1 once again.

11111 1111 1111 1110 -------------------------(Sum)
     1

The result of the above operation is

1111 1111 1111 1111

As one's complement of the result, 1111 1111 1111 1111, is performed. If the value that is arrived at is 0, the data packet is retained. Otherwise, the data packet is rejected and an error message is reported to the source.

NOTE

The complement of a number is obtained by converting all 1s to 0s and vice versa.

An IP datagram has a few more fields that are used for fragmentation. These fields are discussed in the following section.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020