The IP Protocol Suite

---

The lingua franca of the Internet is the Internet Protocol, otherwise known as IP. IP is the foundation upon which Transport and Application layer protocols are built (see Figure 1.3). The IP packet is recognized throughout the Internet and permits packets to be routed from their source to their destination host. All protocols are encapsulated within IP datagrams, which means that interior nodes of the Internet see only this IP wrapper. Inner protocols are viewed only at the endpoints (except for a few nonstandard scenarios).

Figure 1.3: Layered protocols for IP.

In this section, we look at the standard protocols that operate on IP.

Network Layer

The Network layer provides the ability to transport packets from a source to a destination endpoint. This layer is occupied by the Internet Protocol (IP), Internet Control Message Protocol (ICMP), and the Internet Group Management Protocol (IGMP).

Note 

IP and ICMP are standard protocols and found within all IP networking devices. IP is defined by a collection of RFCs, including 791, 950, 919, and 922. ICMP is defined by RFC 792 (with updates in RFC 950). Both IP and ICMP are known as STD number 5. IGMP is defined by RFC 1112, but is also covered by STD number 5.

Internet Protocol (IP)

The Internet Protocol (or IP) is the foundation protocol by which all other Internet protocols are transported. IP provides the end-to-end transport capability, but it is unreliable and provides only best-effort connectionless delivery. This means that IP datagrams may be lost, duplicated, or even arrive at their destination in a different order than which they were transmitted. This isn't a problem, because Transport layer protocols will provide any reliability that may be necessary for the given application. IP provides the very specific end-to-end delivery service.

The IP packet header is shown in Figure 1.4. The important elements to note here are the source address and destination address. These addresses, known as IP addresses, are 32-bit quantities that uniquely identify the source and destination hosts on the Internet. Also of interest is the length field, which permits an IP packet length to range from zero bytes to 65535 octets.

Figure 1.4: Internet Protocol packet header.

Internet Control Message Protocol (ICMP)

ICMP is the Internet Control Message Protocol; as its name implies, it provides control messages to report errors to the IP layer and to provide specialized functionality for Application layer programs. It's important to realize that although ICMP is commonly mentioned separately from IP (as we're doing here), ICMP is an integral part of IP and utilizes IP as its underlying protocol. ICMP can be thought of as a support protocol for IP, whose most common use is echo request, or ping. ICMP also handles error reporting to notify hosts of errors from routers along the path to the destination, or from the destination host itself.

The ICMP header is shown in Figure 1.5 and, being an IP-based protocol, is preceded by an IP packet header on the wire. Recall from Figure 1.4 that a protocol field is present. This field identifies the protocol header that exists inside the IP header. Within the IP network stack, the IP protocol field is used to route the inner protocol frame to the specific upper-layer transport protocol.

Figure 1.5: Internet Control Message Protocol packet header.

ICMP utilizes a very simple header whose type-specific contents depend upon the actual purpose of the packet. Other than ping, ICMP messages can represent router advertisements and solicitations, time stamp transfer, or an indication that the destination listed in a prior IP packet is unreachable.

Internet Group Management Protocol (IGMP)

IGMP, or the Internet Group Management Protocol, is a similar protocol to ICMP. The purpose of IGMP is to advertise to multicast routers on the local network that the interface from which the advertisement was sent is interested in receiving multicast messages. In reality, a host responds to requests sent by routers on the LAN. If the router has no requests for multicast traffic for a given LAN segment, the router will not relay multicast traffic from other segments. Note that for multi-homed interfaces (hosts with more than one interface), an IGMP request must be originated on each interface that desires to converse using multicast. The IGMP packet header is shown in Figure 1.6.

Figure 1.6: Internet Group Management Protocol packet header.

IGMP packets, as with ICMP, are encapsulated within an IP datagram. Only two types of messages are possible with IGMP, requests sent by multicast routers and replies sent by hosts.

Transport Layer

The Transport layer provides end-to-end communication services to applications running in the Application layer. Two types of protocols are provided in the Transport layer: datagram-based protocols and stream-based protocols. Stream-based protocols are reliable and guarantee end-to-end, in-order delivery of packets sent. This doesn't mean that the protocol guarantees all packets sent will arrive at the destination. The protocol ensures that no packets are delivered out-of-order. Datagram-based protocols make no guarantees for delivery. Packets may arrive out of order or not at all, with no indication of packet drops. We describe the most common examples of three types of transport protocols, UDP, TCP, and SCTP.

Note 

TCP is described in RFC 793 and is known as STD number 7. Additional RFCs such as 1323 describe additions to TCP (in the case of RFC 1323, extensions for high performance). UDP is defined in RFC 791 and is known as STD number 6. SCTP is described in RFC 2960, but is not yet an Internet STD document.

User Datagram Protocol (UDP)

The User Datagram Protocol, or UDP, provides an efficient datagram transport service. UDP offers no guarantees for delivery, nor will it identify packets lost in the network. Despite these limitations, UDP provides a very fast alternative to TCP because no connection is necessary with UDP and no acknowledgment protocol exists. The UDP packet header is shown in Figure 1.7.

Figure 1.7: User Datagram Protocol packet header.

UDP is represented by a very simple packet header. A checksum field is used to validate the UDP header (and associated payload) and ensure that it wasn't modified en route. The length field defines the length of the payload data provided in the UDP packet. Finally, the source and destination ports are used to differentiate traffic and uniquely represent the source application and the destination application on the recipient host.

Transmission Control Protocol (TCP)

The Transmission Control Protocol, or TCP, is a reliable connection-based protocol that includes flow control and error recovery. TCP operates using the port model (as with UDP). The port defines the particular application for which the packet should be delivered.

From an application perspective, TCP is a stream-based protocol. This means that all data that flows between a sender and receiver is simply a stream of bytes without any indication of boundaries. This differs from UDP, in which data sent by the application is received in the same manner. For example, if an application sends 20 bytes through a UDP datagram, the receiving application receives 20 bytes, even if additional data was sent after the original 20 bytes. With TCP, the 20 bytes sent may be accumulated with other data sent (for the given connection) and, therefore, the application must take care of deconstructing the stream in the event it represents individual packets of data.

TCP requires that a connection between two endpoints be set up prior to data moving between the applications. This allows initialization of the connection at both endpoints for error recovery and flow control. The TCP packet header is shown in Figure 1.8.

Figure 1.8: Transmission Control Protocol packet header.

TCP provides source and destination ports (to help uniquely identify the source and destination application) and many other fields that are used for other purposes. As TCP is reliable, the sequence number allows the sender to identify a numeric identifier of the first byte of data in the packet (given that each byte sent is uniquely identified by an incrementing number). The receiver replies at various times with an acknowledgment number using the sequence number of the last byte in the packet to tell the sender that this data has been received (or in TCP terms, acknowledged). The sequence and acknowledgment numbers are symmetric; the sequence number represents the data that we send, whereas the acknowledgment number represents our acknowledgment of the data we receive. The peer operates with its own (swapped) versions of this data. A checksum protects not only the TCP header, but also any data contained in the packet.

The flags field (to the right of Reserved in Figure 1.8) allows the packet to alter the behavior of the peer as well as convey additional information. For example, the 'S' field represents 'Synchronization,' and is used to initiate a connection. The 'F' field is the 'Final' bit and instructs the peer to close its side of the connection.

A final interesting point to note regarding the TCP packet header is the window field. When two endpoints negotiate a connection, they define the size of window. The window is the amount of outstanding data that can be sent by a peer at one time (the amount of data on the wire at any given time). The window can also be thought of as the amount of memory set aside by the host for the connection. When a full window of data is received, but the application awaiting the data has not yet accepted it from the stack, then no room exists for additional data. In this case, the window has closed and the sender must stop sending and await notification from the receiver that space is available. Although this is a simplified version of what happens within TCP, it provides a very powerful mechanism for flow control and adapts to both the speed of the receiving host to process the data and congestion in the network. From an application point of view, large windows improve throughput on long haul, many-hop networks by getting as much data into the pipe as possible.

Stream Control Transmission Protocol (SCTP)

The Stream Control Transmission Protocol, or SCTP, is another reliable Transport layer protocol that is similar to both TCP and UDP, but provides additional powerful features.

Although SCTP is most similar to TCP, it provides message framing similar to UDP. For example, if an application sends 20 bytes, the receiving application will receive those 20 bytes without any additional data that may have been accumulated by the sender. In other words, SCTP operates in a message-oriented fashion (such as UDP), not in a byte-stream fashion (as with TCP).

SCTP also provides for out-of-order delivery of data, provided by neither TCP nor UDP. This feature is designed to solve the head-of-line blocking problem, in which multiple flows may be defined within an SCTP connection, and no subflow may halt the receiving of data of any other. This feature is also called multistreaming.

Other important and innovative features of SCTP permit the use of multiple network interfaces on a single host to be aggregated so that the load can be shared across each of the links for a single SCTP connection. TCP and UDP support multiple interfaces, but SCTP provides native support for seamless redundancy and failover.

Note 

A network host that provides two or more network interfaces, or assigns more than one IP address to its single interface is known as a multi-homed host.

The SCTP packet header is shown in Figure 1.9. What is shown is the SCTP common header, as the SCTP packet header can be very different based upon the type of packet.

Figure 1.9: Stream Control Transmission Protocol packet header.

The source and destination ports help define the SCTP association, whereas the verification tag helps uniquely identify the packet as part of the current association rather than a previous embodiment of the association between the same pair of endpoints. The checksum provides a data integrity check on the SCTP packet. This differs from TCP and UDP's 16-bit checksum.

The final elements of the SCTP packet include what is known as chunks. A chunk is a self-descriptive packet within the SCTP packet. The chunk is used for data, initiating SCTP connections, acknowledging data, shutting down a connection, and so on. This differs from the flags method provided in TCP, allowing SCTP to be much more extensible.

Application Layer

The Application layer provides for the application-specific protocols. These protocols utilize the Transport layer protocols to achieve their results. Examples of Application layer protocols include HTTP (HyperText Transport Protocol) and SMTP (Simple Mail Transport Protocol).

The interface between the Application layer and the Transport layer is the subject of this book. The most common interface for the development of Application layer protocols is the BSD (Berkeley Software Distribution) Sockets API (Application Programming Interface). The Sockets API permits the creation of sockets between endpoints on the Internet.

---