Understanding Layer 4 Protocols

To appreciate the part that a content switch plays in the lifecycle of a user session, it is important to understand the component parts that make up such a session. Many protocols can be considered as Layer 4. Routing protocols such as OSPF, proprietary ones such as EIGRP, redundancy protocols such as the Virtual Router Redundancy Protocol (VRRP), and a host of others such as ICMP, IGMP, and IP itself can all be identified by a unique protocol number in the IP header (see Figure 2-5).

Figure 2-5. Different IP protocol numbers identify which Layer 4 protocol is being used.

graphics/02fig05.gif

The list of IP protocol numbers is administered and controlled by the Internet Assigned Numbers Authority (IANA), and a comprehensive list can be found at www.iana.org/. Table 2-1 lists some of the more common IP protocol numbers.

Table 2-1. Some Examples of Common IP Protocol Numbers

IP P ROTOCOL N UMBER	L AYER 4 P ROTOCOL
1	ICMP ” Internet Control Message Protocol
6	TCP ” Transmission Control Protocol
17	UDP ” User Datagram Protocol
112	VRRP ” Virtual Router Redundancy Protocol

Some Layer 4 protocols effectively operate at this layer alone. VRRP, for example, uses Layer 4 headers to transport all information between a series of participating routers in an IP subnet and consequently has no need for upper layer protocol information. Its payload is simply the information contained at Layer 4. Other routing protocols, such as the Border Gateway Protocol (BGP), will use the reliable Layer 4 Transport layer protocol with the BGP routing information and updates carried in the upper layer payloads.

In terms of content switching, the two most commonly understood Layer 4 protocols are TCP and UDP. The majority of the standard Application layer protocols are carried either within TCP or UDP depending on whether there is a requirement for a reliable end-to-end connection. Taking a Web user example, the browser application needs to ensure that all packets are successfully delivered when presenting the user with the desired Web page. The HTTP protocol will therefore rely on TCP as its Transport layer protocol, to guarantee delivery, which in turn will use IP as its delivery mechanism.

Transport Control Protocol (TCP)

As the Layer 3 IP protocol is principally a connectionless and best-efforts delivery mechanism, there is a requirement for many applications to ensure the correctly sequenced delivery of all packets within a conversation. Consequently, many applications will use Transport Control Protocol (TCP) at Layer 4 to guarantee successful delivery. TCP has several characteristics built in to ensure this delivery:

Checksum: The TCP header contains a 16-bit data checksum that is computed from all other data elements in the TCP header. The receiving end station uses this checksum to ensure that the packet arrived without corruption.
Sequence and acknowledgment numbers : Each octet of data sent and received by end stations has an associated sequence number associated with it. These sequence numbers are cumulative, whereby a certain sequence number inside the TCP header will be used to indicate that all data up to and including X should have been received. Sequence and acknowledgment numbering is used to bring the concept of order to packet delivery over IP.
Windowing: The TCP windowing technique allows two communicating end stations to build on the sequencing and acknowledgments above by removing the need for each sequence of data to be individually acknowledged . In LANs where packet loss is usually minimal, it is far more efficient to allow the sender to transmit several frames of data before an acknowledgment is sent.

Along with these mechanisms, TCP must also be able to uniquely identify each conversation within an internetwork. We've already seen the idea of a TCP port number that is used, among other things, to identify the application process to the high OSI layers during the conversation. Within a TCP conversation, there are in fact two port numbers used: one to identify the sender's listening port and the other to identify the receiver's listening port. Depending on the direction of each individual frame in the conversation, these ports become either the source port or the destination port within the Layer 4 headers.

This combination of source and destination ports, along with the Layer 3 IP addressing, gives TCP the ability to uniquely identify each conversation or session within an internetwork, even in the case of the Internet itself.

The Lifecycle of a TCP Session

Let's put these concepts of addresses, ports, and sequencing numbers together and look at how a conversation between two end stations is initiated, sustained, and terminated . Throughout the following example, we will assume that the client is a PC (10.10.10.10) initiating a connection to a Web server (20.20.20.20).

1. Initiating a Session

Before initiating the session, there are two pieces of information upon which the client must decide. First, in order to identify the session uniquely between itself and the server, it selects a TCP port number to represent the session. This port will be the source port for packets from the client to the server and the destination port for packets from the server to the client. The client will select the source port sequentially on a connection-by-connection basis starting from a value greater than 1024. Port numbers below 1024 are typically referred to as well-known ports and are used to identify well-known applications. Table 2-2 shows some well-known reserved ports as defined by IANA.

Table 2-2. Some Well-Known TCP Port Number Assignments

TCP P ORT N UMBER	A PPLICATION
20 and 21	File Transfer Protocol (FTP)
25	Simple Mail Transfer Protocol (SMTP)
23	Telnet
80	HyperText Transfer Protocol (HTTP)

The second element that needs to be decided by the client is the starting sequence number. This will be selected based on an internal 32-bit clock that ensures both randomness and that sequence numbers will not overlap should a lost packet reappear some time after its original transmission. Just as with the TCP ports used by both the client and server, each side also uses its own sequence numbering to identify where within the session each frame fits.

Once the client has determined these two variables , it is ready to send the first packet of the session and initiate the connection to the server. Using TCP flags, the client will indicate to the server that it wants to initiate a connection by setting the SYN or synchronize flag showing that this is the first pack in the session. In TCP terms, this element is the first packet in what is commonly referred to as the "three-way handshake." This is simply because three packets are exchanged between the client and server to bring the TCP state into that which can transport data. Consequently, no Application layer data is transmitted until at least the fourth packet in the session, a concept which we will see has an important consequence when applied to content switching. Figure 2-6 shows a simplified representation of the three-way handshake to illustrate which side sends which of the packets when a new connection is initiated.

Figure 2-6. The TCP three-way handshake.

graphics/02fig06.gif

Taking this sequence packet by packet, we can see the importance of the port and sequence numbers in ensuring the reliable transport between the client and server. The first frame from the client to the server initiates the connection by setting the client side port and sequence numbers as shown in Figure 2-7. As we can see, the client chooses a random source port that will be used by the client to identify this session uniquely in cases where it has concurrent sessions to the same server.

Figure 2-7 The SYN packet sent by the client.

Internet Protocol Headers
    Version: 4
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xb926 (correct)
    Source: 10.10.10.10
    Destination: 20.20.20.20
Transmission Control Protocol Headers

Source port: 3086 (3086)


Destination port: http (80)


Sequence number: 713245119

Header length: 28 bytes
    Flags: 0x0002 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set

...0 .... = Acknowledgment: Not set

.... 0... = Push: Not set
        .... .0.. = Reset: Not set

.... ..1. = Syn: Set

.... ...0 = Fin: Not set

When the server replies, both the SYN and ACK flags are set in the TCP headers to indicate that the server acknowledges the client's connection request. To ensure that each packet can be accounted for, the server will set an acknowledgment number that is equal to the last byte received from the client, relative to the starting sequence number, plus one. In our example, the client started with a sequence number of 713245119 and transmitted no user data, meaning that the server will use an acknowledgment of 713245120.

It is also important to notice the change in source and destination ports depending on which way a particular packet is directed. In our example, the client sends on port 80 and listens on port 3086, whereas the server sends on port 3086 and listens on port 80. Figure 2-8 shows the return packet from the server to the client.

The final packet exchanged during this handshake period is an acknowledgment from the client to the server. This allows the client to correctly acknowledge the sequence numbering used by the server in the previous packet and remove the SYN flag being used to show the start of the session. Once this final packet of the handshake has been received, both sides of the connection can move into the established state, indicating that the transfer of user or application data can now commence. Figure 2-9 shows this final packet of the handshake. Note that in our example, the client has changed the acknowledgment numbering to match that initiated by the server and has also removed the SYN flag in the TCP header.

Figure 2-8 The SYN-ACK packet sent by the server.

Internet Protocol Headers
    Version: 4
    Time to live: 114
    Protocol: TCP (0x06)
    Header checksum: 0x9889 (correct)
    Source: 20.20.20.20
    Destination: 10.10.10.10
Transmission Control Protocol Headers

Source port: http (80)


Destination port: 3086 (3086)


Sequence number: 20072


Acknowledgement number: 713245120

Header length: 28 bytes
    Flags: 0x0012 (SYN, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set

...1 .... = Acknowledgment: Set

.... 0... = Push: Not set
        .... .0.. = Reset: Not set

.... ..1. = Syn: Set

.... ...0 = Fin: Not set

2. Data Transfer

Once the connection has moved into the established state, data transmission can begin between the two end points. During this state, the ACK flag is always set and the two end stations use the sequence and acknowledgment numbering to track the successful delivery of each segment of data. TCP also employs a number of windowing and buffering techniques to ensure the optimal delivery, retransmission, and buffering of data during this state. The discussions of such techniques are outside of the scope of this book.

Figure 2-9 The final ACK packet of the handshake.

Internet Protocol Headers
    Version: 4
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xb92c (correct)
    Source: 192.168.254.201 (192.168.254.201)
    Destination: 212.58.226.40 (212.58.226.40)
Transmission Control Protocol Headers

Source port: 3086 (3086)


Destination port: http (80)


Sequence number: 713245120


Acknowledgement number: 20073

Header length: 20 bytes
    Flags: 0x0010 (ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set

...1 .... = Acknowledgment: Set

.... 0... = Push: Not set
        .... .0.. = Reset: Not set

.... ..0. = Syn: Set

.... ...0 = Fin: Not set

3. Terminating a Session

Unlike the session initiation, the termination of a TCP connection can be initiated from either side. Once one side of the connection decides that it has no more data to transmit, it will set the FIN flag in the TCP header to indicate to the other side that it is ready to terminate the connection. In simple terms, the receiving station will then acknowledge the FIN, by setting the ACK flag, and set its own FIN flag to show that it too is ready to terminate the connection. This series of exchanges results in both sides moving through the TIME WAIT state to the CLOSED state and the connection is closed.

In some instances, when the client receives the FIN it might still have data to send, in which case it will issue only an ACK back to the closing station. This allows the client to continue sending data until it is complete and then issue a FIN to show that the termination of the session can commence. During this period, the initiator and recipient of the initial FIN are referred to as being in the FIN WAIT 2 and CLOSE WAIT states, respectively. Some applications, such as Web browsers, will often use this type of exchange to leave the connection in a type of half-closed state, thereby allowing the connection to be brought back into use when needed without having to reinitiate the entire connection (see Figure 2-10).