Jafar Shaikh

Chap -4 Internet Protocol Chapter 4 Internet Protocol Virtual network Internet architecture and philosophy Purpose of internet protocol, IPv4 Internet datagram options Direct and indirect delivery UDP

COCSIT

A Virtual Network
The focus should be on the interface that an internet provides to users, not on the interconnection technology.
A user thinks of an internet as a single virtual network that interconnects all hosts, and through which communication is possible; its underlying architecture is both hidden and irrelevant. In a sense, an internet is an abstraction of physical networks because, at the lowest level, it provides the same functionality: accepting packets and delivering them. Higher levels of internet software add most of the rich functionality users perceive.

Internet Architecture and Philosophy

Conceptually, a TCPIIP internet provides three sets of services as shown in Figure 7.1; their arrangement in the figure suggests dependencies among them. At the lowest level, a connectionless delivery service provides a foundation on which everything rests. At the next level, a reliable transport service provides a higher level platform on which applications depend. We will soon explore each of these services, understand what they provide, and see the protocols associated with them.

M.No. 9970702247

BCA SY 2013-14

Page 1

Jafar Shaikh

Chap -4 Internet Protocol

COCSIT

The Conceptual Service Organization

Although we can associate protocol software with each of the services in Figure 7.1, the reason for identifying them as conceptual parts of the internet is that they clearly point out the philosophical underpinnings of the design. The point is: Internet software is designed around three conceptual networking services arranged in a hierarchy; much of its success has resulted because this architecture is surprisingly robust and adaptable. One of the most significant advantages of this conceptual separation is that it becomes possible to replace one service without disturbing others. Thus, research and development can proceed concurrently on all three.

Connectionless Delivery System

The most fundamental internet service consists of a packet delivery system. Technically, the service is defined as an unreliable, best-effort, connectionless packet delivery system, analogous to the service provided by network hardware that operates on a best-effort delivery paradigm. The service is called unreliable because delivery is not guaranteed. The packet may be lost, duplicated, delayed, or delivered out of order, but the service will not detect such conditions, nor will it inform the sender or receiver. The service is called connectionless because each packet is treated independently from all others. A sequence of packets sent from one computer to another may travel over different paths, or some may be lost while others are delivered. Finally, the service is said to use best-effort delivery because the internet software makes an earnest attempt to deliver packets. That is, the internet does not discard packets capriciously; unreliability arises only when resources are exhausted or underlying networks fail.

Purpose of the internet Protocol

The protocol that defines the unreliable, connectionless delivery mechanism is called the Internet Protocol and is usually referred to by its initials, IP. IP provides three important definitions. First, the IP protocol defines the basic unit of data transfer used throughout a TCP IP internet. Thus, it specifies the exact format of all data as it passes across the internet. Second, IP software performs the routing function, choosing a path over which data will be sent. Third, in addition to the precise, formal specification of data formats and routing, IP includes a set of rules that embody the idea of unreliable packet delivery. The rules characterize how hosts and routers should process packets, how and when error messages should be generated, and the conditions under which packets can be discarded. IP is such a fundamental part of the design that a TCP/IP internet is sometimes called an IP-based technology. We begin our consideration of IP in this chapter by looking at the packet format it specifies. We leave until later chapters the topics of routing and error handling.

The internet Datagram

The analogy between a physical network and a TCP/IP internet is strong. On a physical network, the unit of transfer is a frame that contains a header and data, where the header gives information such as the (physical) source and destination addresses. The internet calls its basic transfer unit an Internet datagram, sometimes referred to as an IP datagram or merely a datagram. Like a typical physical network frame, a datagram is divided into header and data areas. Also like a frame, the datagram header contains the source and destination addresses and a type field that identifies the contents of the datagram. The difference, of course, is that the datagram header contains IP addresses Where as the frame header contains physical addresses. Figure 7.2 shows the general form of a datagram:

Datagram Format

M.No. 9970702247

BCA SY 2013-14

Page 2

Jafar Shaikh

Chap -4 Internet Protocol

COCSIT

Now that we have described the general layout of an IP datagram, we can look at the contents in more detail. Figure 7.3 shows the arrangement of fields in a datagram:

Because datagram processing occurs in software, the contents and format are not constrained by any hardware. For example, the first C bit field in a datagram (VERS) contains the version of the IP protocol that was used to create the datagram. It is used to verify that the sender, receiver, and any routers in between them agree on the format of the datagram. All IP software is required to check the version field before processing a datagram to ensure it matches the format the software expects. If standards change, machines will reject datagrams with protocol versions that differ from theirs, preventing them from misinterpreting datagram contents according to an outdated format. The current IP protocol version is 4. Consequently, the term IPv4 is often used to denote the current protocol. The header length field (HLEN), also 4 bits, gives the datagram header length measured in 32-bit words. As we will see, all fields in the header have fixed length except for the IP OPTIONS and corresponding PADDING fields. The most common header, which contains no options and no padding, measures 20 octets and has a header length field equal to 5. The TOTAL LENGTH field gives the length of the IP datagram measured in octets, including octets in the header and data. The size of the data area can be computed by subtracting the length of the header (HLEN) from the TOTAL LENGTH. Because the TOTAL LENGTH field is 16 bits long, the maximum possible size of an IP datagram is 216 or 65,535 octets. In most applications this is not a severe limitation. It may become more important in the future if higher speed networks can carry data packets larger than 65,535 octets.

Internet Datagram Options

The IP OPTIONS field following the destination address is not required in every datagram; options are included primarily for network testing or debugging. Options processing is an integral part of the IP protocol, however, so all standard implementations must include it. The length of the IP OPTIONS field varies depending on which options are selected. Some options are one octet long; they consist of a single octet option code. Other options are variable length. When options are present in a datagram, they appear contiguously, with no special separators between them. Each option consists of a single octet option code, which may be followed by a single octet length and a set of data octets for that option. The option code octet is divided into three fields as Figure 7.10 shows.

The fields of the OPTION CODE consist of a 1-bit COPY flag, a 2-bit OPTION CLASS, and the 5-bit OPTION NUMBER. The COPY flag controls how routers treat options during fragmentation. When the COPY bit is set to I, it specifies that the option should be copied into all fragments. When set to 0, the COPY bit means that the option should only be copied into the first fragment and not into all fragments. The OPTION

M.No. 9970702247

BCA SY 2013-14

Page 3

Jafar Shaikh Chap -4 Internet Protocol COCSIT CLASS and OPTION NUMBER bits specify the general class of the option and a specific option in that class. The table in Figure 7.1 1 shows how option classes are assigned

The table in Figure 7.12 lists examples of options that can accompany an IP datagram and gives their OPTION CLASS and OPTION NUMBER values. As the list shows, most options are used for control purposes.

1.

Record Route Option

The routing and timestamp options are the most interesting because they provide a way to monitor or control how internet routers route datagram. The record route option allows the source to create an empty list of IP addresses and arrange for each router that handles the datagram to add its IP address to the list. Figure 7.13 shows the format of the record route option. As described above, the CODE field contains the option class and option number (0 and 7 for record route). The LENGTH field specifies the total length of the option as it appears in the IP datagram, including the first three octets. The fields starting with the one labeled FIRST IP ADDRESS comprise the area reserved for recording internet addresses. The POINTER field specifies the offset within the option of the next available slot.

M.No. 9970702247

BCA SY 2013-14

Page 4

Jafar Shaikh

Chap -4 Internet Protocol

COCSIT

Whenever a machine handles a datagram that has the record route option set, the machine adds its address to the record route list (enough space must be allocated in the option by the original source to hold all entries that will be needed). To add itself to the list, a machine first compares the pointer and length fields. If the pointer is greater than the length, the list is full, so the machine forwards the datagram without inserting its entry. If the list is not full, the machine inserts its Coctet IP address at the position specified by the POINTER, and increments the POINTER by four. When the datagram arrives, the destination machine can extract and process the list of IP addresses. Usually, a computer that receives a datagram ignores the recorded route. Using the record route option requires two machines that agree to cooperate; a computer will not automatically receive recorded routes in incoming datagrams after it turns on the record route option in outgoing datagrams. The source must agree to enable the record route option and the destination must agree to process the resultant list.

2.

Source Route Options

Another idea that network builders find interesting is the source route option. The idea behind source routing is that it provides a way for the sender to dictate a path through the internet. For example, to test the throughput over a particular physical network, N, system administrators can use source routing to force IP datagrams to traverse network N even if routers would normally choose a path that did not include it. The ability to make such tests is especially important in a production environment, because it gives the network manager freedom to route users' datagrams over networks that are known to operate correctly while simultaneously testing other networks. Of course, source routing is only useful to people who understand the network topology; the average user has no need to know or use it. IP supports two forms of source routing. One form, called strict source routing, specifies a routing path by

including a sequence of IP addresses in the option as Figure 7.14 shows.

M.No. 9970702247

BCA SY 2013-14

Page 5

Jafar Shaikh

Chap -4 Internet Protocol

COCSIT

Strict source routing means that the addresses specify the exact path the datagram must follow to reach its destination. The path between two successive addresses in the list must consist of a single physical network; an error results if a router cannot follow a strict source route. The other form, called loose source routing, also includes a sequence of IP addresses. It specifies that the datagram must follow the sequence of IP addresses, but allows multiple network hops between successive addresses on the list. Both source route options require routers along the path to overwrite items in the address list with their local network addresses. Thus, when the datagram arrives at its destination, it contains a list of all addresses visited, exactly like the list produced by the record route option. The format of a source route option resembles that of the record route option shown above. Each router examines the POINTER and LENGTH fields to see if the list has been exhausted. If it has, the pointer is greater than the length, and the router routes the datagram to its destination as usual. If the list is not exhausted, the router follows the pointer, picks up the IP address, replaces it with the router's address?, and routes the datagram using the address obtained from the list. Timestamp Option The timestamp option works like the record route option in that the timestamp option contains an initially empty list, and each router along the path from source to destination fills in one item in the list. Each entry in the list contains two 32-bit items: the IP address of the router that supplied the entry and a 32-bit integer timestamp. Figure 7.15 shows the format of the timestamp option
3.

In the figure, the LENGTH and POINTER fields are used to specify the length of the space reserved for the option and the location of the next unused slot (exactly as in the record route option). The 4-bit OFLOW field contains an integer count of routers that could not supply a timestamp because the option was too small. The value in the 4-bit FLAGS field controls the exact format of the option and tells how routers should supply timestamps. The values are:

Timestamps give the time and date at which a router handles the datagram, expressed as milliseconds since midnight, Universal Time?. If the standard representation for time is unavailable, the router can use any

M.No. 9970702247

BCA SY 2013-14

Page 6

Jafar Shaikh

Chap -4 Internet Protocol

COCSIT

representation of local time provided it turns on the high-order bit in the timestamp field. Of course, timestamps issued by independent computers are not always consistent even if represented in universal time; each machine reports time according to its local clock, and clocks may differ. Thus, timestamp entries should always be treated as estimates, independent of the representation. It may seem odd that the timestamp option includes a mechanism to have routers record their IP addresses along with timestamps because the record route option already provides that capability. However, recording IP addresses with timestamps eliminates ambiguity. Having an address recorded along with each timestamp is also useful because it allows the receiver to know exactly which path the datagram followed.

User Datagram Protocol

In the TCPIP protocol suite, the User Datagram Protocol or UDP provides the primary mechanism that application programs use to send datagrams to other application programs. UDP provides protocol ports used to distinguish among multiple programs executing on a single machine. That is, in addition to the data sent, each UDP message contains both a destination port number and a source port number, making it possible for the UDP software at the destination to deliver the message to the correct recipient and for the recipient to send a reply. UDP uses the underlying Internet Protocol to transport a message from one machine to another, and provides the same unreliable, connectionless datagram delivery semantics as IF'. It does not use acknowledgements to make sure messages arrive, it does not order incoming messages, and it does not provide feedback to control the rate at which information flows between the machines. Thus, UDP messages can be lost, duplicated, or arrive out of order. Furthermore, packets can arrive faster than the recipient can process them. We can summarize: The User Datagram Protocol (UDP) provides an unreliable connectionless delivery service using IP to transport
messages between machines. It uses IP to carry messages, but adds the ability to distinguish among multiple destinations within a given host computer.

An application program that uses UDP accepts full responsibility for handling the problem of reliability, including
message loss, duplication, delay, out-of-order delivery, and loss of connectivity. Unfortunately, application programmers often ignore these problems when designing software. Furthermore, because programmers often test network software using highly reliable, low-delay local area networks, testing may not expose potential failures. Thus, many application programs that rely on UDP work well in a local environment but fail in dramatic ways when used in a larger TCP/IP internet.

Format Of UDP Messages

Each UDP message is called a user datagram. Conceptually, a user datagram consists of two parts: a UDP header and a UDP data area. As Figure 12.1 shows, the header is divided into four 16-bit fields that specify the port from which the message was sent, the port to which the message is destined, the message length, and a UDP checksum.

The SOURCE PORT and DESTINATION PORT fields contain the 16-bit UDP protocol port numbers used to demultiplex datagram among the processes waiting to receive them. The SOURCE PORT is optional. When used, it specifies the port to which replies should be sent; if not used, it should be zero. The LENGTH field contains a count of octets in the UDP datagram, including the UDP header and the user data. Thus, the minimum value for ENGTH is eight, the length of the header alone. The UDP checksum is optional and need not be used at all; a value of zero in

M.No. 9970702247

BCA SY 2013-14

Page 7

Jafar Shaikh

Chap -4 Internet Protocol

COCSIT

the CHECKSUM field means that the checksum has not been computed. The designers chose to make the checksum optional to allow implementations to operate with little computational overhead when using UDP across a highly reliable local area network. Recall, however, that IP does not compute a checksum on the data portion of an IP datagram. Thus, the UDP checksum provides the only way to guarantee that data has arrived intact and should be used. Begi~erso ften wonder what happens to UDP messages for which the computed checksum is zero. A computed value of zero is possible because UDP uses the same checksum algorithm as IP: it divides the data into 16-bit quantities and computes the one's complement of their one's complement sum. Surprisingly, zero is not a problem because one's complement arithmetic has two representations for zero: all bits set to zero or all bits set to one. When the computed checksum is zero, UDP uses the representation with all bits set to one.

M.No. 9970702247

BCA SY 2013-14

Page 8