Transport and Network Layer Protocols (Data Communications and Networking)

There are many different transport/network layer protocols, but one family of protocols, TCP/IP, dominates. Each transport and network layer protocol performs essentially the same functions, but each is incompatible with the others unless there is a special device to translate between them. Many vendors provide software with multiprotocol stacks, which means that the software supports several different transport/network protocols. The software recognizes which protocol an incoming message uses and automatically uses that protocol to process the message. In this topic, we focus only on TCP/IP. A good overview of protocols, at all layers, is available at: www.protocols.com.

The Transmission Control Protocol/Internet Protocol (TCP/IP) was developed for the U.S. Department of Defense’s Advanced Research Project Agency network (ARPANET) by Vinton Cerf and Bob Kahn in 1974. TCP/IP is the transport/network layer protocol used on the Internet. It is the world’s most popular protocol set, used by almost all BNs, MANs, and WANs. TCP/IP allows reasonably efficient and error-free transmission. Because it performs error checking, it can send large files across sometimes unreliable networks with great assurance that the data will arrive uncorrupted. TCP/IP is compatible with a variety of data link protocols, which is one reason for its popularity.

As the name implies, TCP/IP has two parts. TCP is the transport layer protocol that links the application layer to the network layer. It performs segmenting: breaking the data into smaller PDUs called segments, numbering them, ensuring each segment is reliably delivered, and putting them in the proper order at the destination.


Transmission Control Protocol (TCP) segment, ACK = acknowledgment; CRC = cyclical redundancy check

Figure 5.2 Transmission Control Protocol (TCP) segment, ACK = acknowledgment; CRC = cyclical redundancy check

IP is the network layer protocol and performs addressing and routing. IP software is used at each of the intervening computers through which the message passes; it is IP that routes the message to the final destination. The TCP software needs to be active only at the sender and the receiver, because TCP is involved only when data comes from or goes to the application layer.

Transmission Control Protocol (TCP)

A typical TCP segment has 192-bit header (24 bytes) of control information (Figure 5.2). Among other fields, it contains the source and destination port identifier. The destination port tells the TCP software at the destination to which application layer program the application layer packet should be sent whereas the source port tells the receiver which application layer program the packet is from. The TCP segment also provides a sequence number so that the TCP software at the destination can assemble the segments into the correct order and make sure that no segments have been lost.

The options field is optional, so in many cases it is omitted. In this case, TCP has a length of 20 bytes (160 bits). The header length field is used to tell the receiver how long the TCP packet is, that is, whether the options field is included or not.

TCP/IP has a second type of transport layer protocol called User Datagram Protocol (UDP). UDP PDUs are called datagrams. UDP is typically used when the sender needs to send a single small packet to the receiver (e.g., for a DNS request, which we discuss later in this topic). When there is only one small packet to be sent, the transport layer doesn’t need to worry about segmenting the outgoing messages or reassembling them upon receipt, so transmission can be faster. A UDP datagram has only four fields (eight bytes of overhead) plus the application layer packet: source port, destination port, length, and a CRC-16. Unlike TCP, UDP does not check for lost messages, so occasionally a UDP datagram is lost, and the message must be resent.

Internet Protocol (IP)

IP is the network layer protocol. Network layer PDUs are called packets. Two forms of IP are currently in use. The older form is IP version 4 (IPv4), which also has a 192-bit header (24 bytes) (Figure 5.3). This header contains source and destination addresses, packet length, and packet number.

IPv4 is being replaced by IPv6, which has a 320-bit header (40 bytes) (Figure 5.4). The primary reason for the increase in the packet size is an increase in the address size from 32 bits to 128 bits. IPv6′s simpler packet structure makes it easier to perform routing and supports a variety of new approaches to addressing and routing.

Internet Protocol (IP) packet (version 4). CRC = cyclical redundancy check

Figure 5.3 Internet Protocol (IP) packet (version 4). CRC = cyclical redundancy check

IPv6 was developed because we were running out of IP addresses on the Internet. IPv4 has a four-byte address field, which means there is a theoretical maximum of about 4.2 billion addresses. However, about 500 million of these addresses are reserved and cannot be used, and the way addresses were assigned in the early days of the Internet means that a small number of companies received several million addresses, even when they didn’t need all of them. With the increased growth in Internet users, and the explosion in mobile Internet devices, current estimates project that we will run out of IPv4 addresses somewhere between 2012 and 2017.

IPv6 uses a 16-byte long address which provides a theoretical maximum of 3.4 x 1038 addresses—more than enough for the foreseeable future. IPv4 uses decimal to express addresses (e.g., 128.192.55.72), but IPv6 uses hexadecimal (base 16) like Ethernet to express addresses, which makes it slightly more confusing to use. Addresses are eight sets of two byte numbers (e.g., 2001:0890:0600:00d1:0000:0000:abcd:f010), but because this can be long to write, there is a IPv6 "compressed notation" which eliminates the leading zeros within each block and blocks that are all zeros. So the IPv6 address above could also be written as 2001:890:600:d1: :abcd:f010.

Adoption of IPv6 has been slow. Most organizations have not felt the need to change because IPv6 provides few benefits other than the larger address space and requires their staff to learn a whole new protocol. In most cases, the shortage of addresses on the Internet doesn’t affect organizations that already have Internet addresses, so there is little incentive to convert to IPv6. Most organizations that implement IPv6 also run IPv4, and IPv6 is not backward-compatible with IPv4, which means that all network devices must be changed to understand both IPV4 and IPv6. The cost of this conversion, along with the few benefits it provides to organizations which do convert, has led a number of commentators to refer to this as the IPv6 "mess." In order to encourage the move to IPv6, the U.S. government required all of its agencies to convert to IPv6 on their WANs and backbone networks by June 2008, but the change was not completed on time.

The size of the message field depends on the data link layer protocol used. TCP/IP is commonly combined with Ethernet. Ethernet has a maximum packet size of 1,492 bytes, so the maximum size of a TCP message field if IPv4 is used is 1,492—24 (the size of the TCP header)—24 (the size of the IPv4 header) = 1, 444.

Internet Protocol (IP) packet (version 6)

Figure 5.4 Internet Protocol (IP) packet (version 6)

Moving to TCP/IP

MANAGEMENT FOCUS

Merita Bank in Finland is the Finnish part of the Nordea, the largest financial services group in the Nordic and Baltic region. Merita runs over 3 million transactions on its IBM mainframe computer during a normal banking day, with approximately 190 transactions per second during the peak hour.

Prior to the conversion, Merita’s IBM mainframe computer used the Systems Network Architecture (SNA) protocol while its network supporting its many branches used TCP/IP. The inbound data from the branches would arrive at the mainframe network and have to be converted from TCP/IP to SNA before being sent to the mainframe. Likewise, outbound traffic from the mainframe would have to be converted from SNA to TCP/IP before being sent to the branches.

Although the network worked, it was not efficient and during periods of high traffic could experience considerable delays.

To eliminate the slow and complex conversion between the TCP/IP-based branch office network and the SNA-based mainframe network, Merita replaced the mainframe’s SNA protocol with TCP/IP. Now the network runs significantly faster, and there is one end-to-end protocol. All this, with just changing the network hardware and software on the mainframe and throwing away some old equipment; there were no changes to the branch network or to the application software.

Next post:

Previous post: