0% found this document useful (0 votes)
81 views67 pages

Internet Protocol: Objectives

The document discusses Internet Protocol (IP) and IP datagrams. It covers the format and fields of an IP datagram header including version, header length, total length, identification, flags, fragmentation offset, protocol, and time to live. It describes how IP provides connectionless, unreliable packet switching using variable length datagrams. It also covers fragmentation of datagrams into multiple fragments to fit into smaller MTUs of different physical networks, and the fields used for fragmentation and reassembly.

Uploaded by

abccc
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
81 views67 pages

Internet Protocol: Objectives

The document discusses Internet Protocol (IP) and IP datagrams. It covers the format and fields of an IP datagram header including version, header length, total length, identification, flags, fragmentation offset, protocol, and time to live. It describes how IP provides connectionless, unreliable packet switching using variable length datagrams. It also covers fragmentation of datagrams into multiple fragments to fit into smaller MTUs of different physical networks, and the fields used for fragmentation and reassembly.

Uploaded by

abccc
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 67

Chapter 8

Internet Protocol

Objectives
Upon completion you will be able to:

• Understand the format and fields of a datagram


• Understand the need for fragmentation and the fields involved
• Understand the options available in an IP datagram
• Be able to perform a checksum calculation
• Understand the components and interactions of an IP package

TCP/IP Protocol Suite 1


Figure 8.1 Position of IP in TCP/IP protocol suite

IP: connectionless, unreliable, packet switching w/ datagrams


TCP/IP Protocol Suite 2
8.1 DATAGRAM
A packet in the IP layer is called a datagram, a variable-length packet
consisting of two parts: header and data. The header is 20 to 60 bytes in
length and contains information essential to routing and delivery.

Some of the fields:

VER - version numbers, 4 and 6


HLEN - header length in 4-byte words. Value of 5 means 20 byte header

TCP/IP Protocol Suite 3


Figure 8.2 IP datagram

TCP/IP Protocol Suite 4


Figure 8.3 Service type or Differentiated Services - DS field

This field was previously called Service type. Now called


Differentiated Services.
Precedence bits - never used. Similar to PRI bits in IPv6.
TOS (Type of Service) bits - see next slide.

TCP/IP Protocol Suite 5


Table 8.1 Types of service

If you want to send a packet with a special type of service,


use one of the above 5-bit sets.

TCP/IP Protocol Suite 6


Table 8.2 Default types of service

Some apps
have default
service types.

TCP/IP Protocol Suite 7


If we call these 8 bits Differentiated Services (and not the
older Service Type), then the first six bits are called code-
points.

Table 8.3 Values for codepoints

When the 3 right-most bits are 0, the 3 left-most bits are the same
as the precedence bits from the previous slides.
When the 3 right-most bits are not all 0s, the 6 bits define 64
Services based on the priority assignment by the Internet or
local authorities. Assignments have not yet been finalized.

TCP/IP Protocol Suite 8


Figure 8.4 Encapsulation of a small datagram in an Ethernet frame

The total length field defines the total length of the datagram
including the header.

Total length field is 16 bits, or 65,535 bytes. Of which 20 to


60 bytes are the header.

If an IP datagram is short, and is packaged into an Ethernet


frame, remember that the minimum payload size of an
Ethernet frame is 46 bytes (to avoid being mistaken for a runt).

TCP/IP Protocol Suite 9


Identification, Flags, and Fragmentation offset are all used
to perform fragmentation, which we will cover shortly.

Time to Live - 8-bit field, so Time to Live can be set to 255.


As it passes thru a router, the router decrements the
counter. When counter hits 0, the datagram is deleted
(and ICMP sends an error message back to the source).

Why might a host set the Time to Live field to 1?

TCP/IP Protocol Suite 10


Figure 8.5 Multiplexing

The Protocol field (8 bits) identifies the upper layer protocol


that is using IP for transmission of its data.

TCP/IP Protocol Suite 11


Table 8.4 Protocols

These are some common values that are used in the Protocol field.

TCP/IP Protocol Suite 12


Example 1

An IP packet has arrived with the first 8 bits as shown:

01000010

The receiver discards the packet. Why?

TCP/IP Protocol Suite 13


Example 1

An IP packet has arrived with the first 8 bits as shown:

01000010

The receiver discards the packet. Why?

Solution
There is an error in this packet. The 4 left-most bits (0100)
show the version, which is correct. The next 4 bits (0010) show
the header length; which means (2 × 4 = 8), which is wrong.
The minimum number of bytes in the header must be 20. The
packet has been corrupted in transmission.
TCP/IP Protocol Suite 14
Example 2

In an IP packet, the value of HLEN is 1000 in binary. How


many bytes of options are being carried by this packet?

TCP/IP Protocol Suite 15


Example 2

In an IP packet, the value of HLEN is 1000 in binary. How


many bytes of options are being carried by this packet?

Solution
The HLEN value is 8, which means the total number of bytes
in the header is 8 × 4 or 32 bytes. The first 20 bytes are the base
header, the next 12 bytes are the options.

TCP/IP Protocol Suite 16


Example 3

In an IP packet, the value of HLEN is 516


and the value of the total length field is 002816 . How
many bytes of data are being carried by this packet?

TCP/IP Protocol Suite 17


Example 3

In an IP packet, the value of HLEN is 516


and the value of the total length field is 002816 . How
many bytes of data are being carried by this packet?

Solution
The HLEN value is 5, which means the total number of bytes
in the header is 5 × 4 or 20 bytes (no options). The total length
is 40 bytes, which means the packet is carrying 20 bytes of data
(40 − 20).

TCP/IP Protocol Suite 18


Example 4

An IP packet has arrived with the first few hexadecimal digits


as shown below:

45000028000100000102 . . .

How many hops can this packet travel before being dropped?
The data belong to what upper layer protocol?

TCP/IP Protocol Suite 19


Example 4

An IP packet has arrived with the first few hexadecimal digits


as shown below:

45000028000100000102 . . .

How many hops can this packet travel before being dropped?
The data belong to what upper layer protocol?

Solution
To find the time-to-live field, we skip 8 bytes (16 hexadecimal
digits). The time-to-live field is the ninth byte, which is 01. This
means the packet can travel only one hop. The protocol field is
the next byte (02), which means that the upper layer protocol is
IGMP (see Table 8.4).
TCP/IP Protocol Suite 20
8.2 FRAGMENTATION
The format and size of a frame depend on the protocol used by the
physical network. A datagram may have to be fragmented to fit the
protocol regulations.

The topics discussed in this section include:


Maximum Transfer Unit (MTU)
Fields Related to Fragmentation

TCP/IP Protocol Suite 21


Figure 8.6 MTU

MTU - Maximum Transfer Unit

TCP/IP Protocol Suite 22


Table 8.5 MTUs for some networks

Max datagram size for IP is 65535 bytes. So if we have a max


sized datagram to send over Ethernet, what do we do?

TCP/IP Protocol Suite 23


Figure 8.7 Flags field

A datagram can be fragmented by the source host or any


router in the path. Reassembly is done only by the destination
host.

Most fields are copied from one fragment to the next. The 3
fields that are not copied are the flags, fragmentation offset,
and the total length.
(And the checksum of course is recalculated.)

The Identification field is copied from one fragment to the next.

The Do Not Fragment bit is set to 1 if the network is not supposed


to fragment this datagram. (If it has to be fragmented, it is
tossed.) The More Fragments bit is set to 1 if there are more fragments
following this one.

TCP/IP Protocol Suite 24


Figure 8.8 Fragmentation example

The Fragmentation Offset tells what position this fragment


is in the whole stream. The offset counts by 8. So if a
fragment is supposed to start at byte 400, the offset equals
50.

TCP/IP Protocol Suite 25


Figure 8.9 Detailed fragmentation example

TCP/IP Protocol Suite 26


Example 5

A packet has arrived with an M bit value of 0. Is this the first


fragment, the last fragment, or a middle fragment? Do we
know if the packet was fragmented?

TCP/IP Protocol Suite 27


Example 5

A packet has arrived with an M bit value of 0. Is this the first


fragment, the last fragment, or a middle fragment? Do we
know if the packet was fragmented?

Solution
If the M bit is 0, it means that there are no more fragments; the
fragment is the last one. However, we cannot say if the original
packet was fragmented or not. A non-fragmented packet is
considered the last fragment.

TCP/IP Protocol Suite 28


Example 7

A packet has arrived with an M bit value of 1 and a


fragmentation offset value of zero. Is this the first fragment,
the last fragment, or a middle fragment?.

TCP/IP Protocol Suite 29


Example 7

A packet has arrived with an M bit value of 1 and a


fragmentation offset value of zero. Is this the first fragment,
the last fragment, or a middle fragment?.

Solution
Because the M bit is 1, it is either the first fragment or a middle
one. Because the offset value is 0, it is the first fragment.

TCP/IP Protocol Suite 30


Example 8

A packet has arrived in which the offset value is 100. What is


the number of the first byte? Do we know the number of the
last byte?

TCP/IP Protocol Suite 31


Example 8

A packet has arrived in which the offset value is 100. What is


the number of the first byte? Do we know the number of the
last byte?

Solution
To find the number of the first byte, we multiply the offset value
by 8. This means that the first byte number is 800. We cannot
determine the number of the last byte unless we know the
length of the data.

TCP/IP Protocol Suite 32


Example 9

A packet has arrived in which the offset value is 100, the value
of HLEN is 5 and the value of the total length field is 100.
What is the number of the first byte and the last byte?

TCP/IP Protocol Suite 33


Example 9

A packet has arrived in which the offset value is 100, the value
of HLEN is 5 and the value of the total length field is 100.
What is the number of the first byte and the last byte?

Solution
The first byte number is 100 × 8 = 800. The total length is 100
bytes and the header length is 20 bytes (5 × 4), which means
that there are 80 bytes in this datagram. If the first byte
number is 800, the last byte number must be 879.

TCP/IP Protocol Suite 34


8.3 OPTIONS
The header of the IP datagram is made of two parts: a fixed part and a
variable part. The variable part comprises the options that can be a
maximum of 40 bytes.

The topics discussed in this section include:


Format
Option Types

TCP/IP Protocol Suite 35


Figure 8.10 Option format

Not all routers/hosts use these options, but they must be


ready to do so if they are present in the datagram.

Copy - tells whether to copy this option into a fragment


Class - defines the general purpose of the option
TCP/IP Protocol Suite 36
Figure 8.11 Categories of options

As we just saw, only 6 options in use currently. The single-byte


options are only 1 byte in length and do not require length or
data fields.

TCP/IP Protocol Suite 37


Figure 8.12 No operation option

Used as a filler between options. For example, can be used


to align the next option on a 16- or 32-bit boundary.

TCP/IP Protocol Suite 38


Figure 8.13 End of option option

Denotes the end of the options and that the data is next.

TCP/IP Protocol Suite 39


Figure 8.14 Record route option

Records the route a datagram takes thru routers. Can only record
9 routers, since max size of the header is 60 bytes, 20 bytes for
base header, leaving only 40 bytes for options.

TCP/IP Protocol Suite 40


Figure 8.15 Record route concept

The Pointer field (4, then 8, then 12, then 16) is the byte
number of the first available space.

TCP/IP Protocol Suite 41


Figure 8.16 Strict source route option

For when a datagram has to follow a given, fixed route.

TCP/IP Protocol Suite 42


Figure 8.17 Strict source route concept

First hop address is here

Second hop address is here

Note that as hops are made, next hop is replaced with


address of router you just went thru
TCP/IP Protocol Suite 43
Figure 8.18 Loose source route option

Similar to fixed route - each router in the list must be visited,


but other routers can be visited too.

TCP/IP Protocol Suite 44


Figure 8.19 Timestamp option
Can be used if you want to record the time the datagram
visits each router. Time in milleseconds, Universal Time.

O-Flow bits (overflow bits) record the number of routers that could not
add their timestamp because no more fields were available.
TCP/IP Protocol Suite 45
Figure 8.20 Use of flag in timestamp

The Flag bits tell the router whether to do one of the


following operations:

TCP/IP Protocol Suite 46


Figure 8.21 Timestamp concept

TCP/IP Protocol Suite 47


Example 10

Which of the six options must be copied to each fragment?

TCP/IP Protocol Suite 48


Example 10

Which of the six options must be copied to each fragment?

Solution
We look at the first (left-most) bit of the code for each option.

a. No operation: Code is 00000001; not copied.


b. End of option: Code is 00000000; not copied.
c. Record route: Code is 00000111; not copied.
d. Strict source route: Code is 10001001; copied.
e. Loose source route: Code is 10000011; copied.
f. Timestamp: Code is 01000100; not copied.

TCP/IP Protocol Suite 49


Example 11

Which of the six options are used for datagram control and
which are used for debugging and management?

TCP/IP Protocol Suite 50


Example 11

Which of the six options are used for datagram control and
which are used for debugging and management?

Solution
We look at the second and third (left-most) bits of the code.

a. No operation: Code is 00000001; datagram control.


b. End of option: Code is 00000000; datagram control.
c. Record route: Code is 00000111; datagram control.
d. Strict source route: Code is 10001001; datagram control.
e. Loose source route: Code is 10000011; datagram control.
f. Time stamp: Code is 01000100; debugging and management
control.

TCP/IP Protocol Suite 51


Example 12

One of the utilities available in UNIX (and Microsoft) to check


the traveling of the IP packets is ping. In the next chapter, we
talk about the ping program in more detail. In this example, we
want to show how to use the program to see if a host is
available. We ping a server at De Anza College named
fhda.edu. The result shows that the IP address of the host is
153.18.8.1.
$ ping fhda.edu
PING fhda.edu (153.18.8.1) 56(84) bytes of data.
64 bytes from tiptoe.fhda.edu (153.18.8.1): ....

The result shows the IP address of the host and the number of
bytes used.
TCP/IP Protocol Suite 52
Example 13

We can also use the ping utility with the -R option to implement
the record route option. (in Microsoft: ping –r count URL)
$ ping -R fhda.edu
PING fhda.edu (153.18.8.1) 56(124) bytes of data.
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=0 ttl=62 time=2.70 ms
RR: voyager.deanza.fhda.edu (153.18.17.11)
Dcore_G0_3-69.fhda.edu (153.18.251.3)
Dbackup_V13.fhda.edu (153.18.191.249) tiptoe.fhda.edu (153.18.8.1)
Dbackup_V62.fhda.edu (153.18.251.34)
Dcore_G0_1-6.fhda.edu (153.18.31.254)
voyager.deanza.fhda.edu (153.18.17.11)

The result shows the interfaces and IP addresses.


(In MS-DOS window, enter ping/?)
TCP/IP Protocol Suite 53
Example 14

The traceroute utility (tracert in Microsoft) can also be used to


keep track of the route of a packet.

$ traceroute fhda.edu
traceroute to fhda.edu (153.18.8.1), 30 hops max, 38 byte packets
1 Dcore_G0_1-6.fhda.edu (153.18.31.254) 0.972 ms 0.902 ms 0.881 ms
2 Dbackup_V69.fhda.edu (153.18.251.4) 2.113 ms 1.996 ms 2.059 ms
3 tiptoe.fhda.edu (153.18.8.1) 1.791 ms 1.741 ms 1.751 ms

The result shows the three routers visited.

TCP/IP Protocol Suite 54


Example 15

The traceroute program can be used to implement loose source


routing. The -g option allows us to define the routers to be
visited, from the source to destination. The following shows
how we can send a packet to the fhda.edu server with the
requirement that the packet visit the router 153.18.251.4.

$ traceroute -g 153.18.251.4 fhda.edu.


traceroute to fhda.edu (153.18.8.1), 30 hops max, 46 byte packets
1 Dcore_G0_1-6.fhda.edu (153.18.31.254) 0.976 ms 0.906 ms 0.889 ms
2 Dbackup_V69.fhda.edu (153.18.251.4) 2.168 ms 2.148 ms 2.037 ms

In Microsoft: tracert -j

TCP/IP Protocol Suite 55


Example 16

The traceroute program can also be used to implement strict


source routing. The -G option forces the packet to visit the
routers defined in the command line. The following shows how
we can send a packet to the fhda.edu server and force the
packet to visit only the router 153.18.251.4, not any other one.

$ traceroute -G 153.18.251.4 fhda.edu.


traceroute to fhda.edu (153.18.8.1), 30 hops max, 46 byte packets
1 Dbackup_V69.fhda.edu (153.18.251.4) 2.168 ms 2.148 ms 2.037 ms

Option not available in Microsoft.

TCP/IP Protocol Suite 56


8.4 CHECKSUM
The error detection method used by most TCP/IP protocols is called the
checksum. The checksum protects against the corruption that may occur
during the transmission of a packet. It is redundant information added to
the packet.

The topics discussed in this section include:


Checksum Calculation at the Sender
Checksum Calculation at the Receiver
Checksum in the IP Packet

TCP/IP Protocol Suite 57


Note:

To create the checksum the sender does the following:


❏ The packet is divided into k sections, each of n bits.

❏ All sections are added together using 1’s complement


arithmetic.

❏ The final result is complemented to make the


checksum.

TCP/IP Protocol Suite 58


Figure 8.22 Checksum concept

TCP/IP Protocol Suite 59


Figure 8.23 Checksum in one’s complement arithmetic

TCP/IP Protocol Suite 60


Example 17

Figure 8.24 shows an example of a checksum calculation for


an IP header without options. The header is divided into 16-bit
sections. All the sections are added and the sum is
complemented. The result is inserted in the checksum field.

See Next Slide

TCP/IP Protocol Suite 61


Figure 8.24 Example of checksum calculation in binary

TCP/IP Protocol Suite 62


Example 18

Let us do the same example in hexadecimal. Each row has four


hexadecimal digits. We calculate the sum first. Note that if an
addition results in more than one hexadecimal digit, the right-
most digit becomes the current-column digit and the rest are
carried to other columns. From the sum, we make the
checksum by complementing the sum. However, note that we
subtract each digit from 15 in hexadecimal arithmetic (just as
we subtract from 1 in binary arithmetic). This means the
complement of E (14) is 1 and the complement of 4 is B (11).
Figure 8.25 shows the calculation. Note that the result (8BB1)
is exactly the same as in Example 17.

See Next Slide


TCP/IP Protocol Suite 63
Figure 8.25 Example of checksum calculation in hexadecimal

TCP/IP Protocol Suite 64


Note:

Check Appendix C for a detailed


description of checksum calculation
and the handling of carries.

TCP/IP Protocol Suite 65


8.5 IP PACKAGE
We give an example of a simplified IP software package to show its
components and the relationships between the components. This IP
package involves eight modules.

The topics discussed in this section include:

Header-Adding Module
Processing Module
Queues
Routing Table
Forwarding Module
MTU Table
Fragmentation Module
Reassembly Table
Reassembly Module

TCP/IP Protocol Suite 66


Figure 8.26 IP components

See pages 204


and on for
module
flowcharts.

TCP/IP Protocol Suite 67

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy