Layer 4 — transport layer protocol

The transport layer (layer 4) protocol is responsible for providing network-independent com-munication services between computer applications running in end-user terminals. In theory, data communication (i.e., transport of data) may have to traverse different networks along

the way. The transport layer in this case has to ensure the coordination and control of all the various networks and arrange communication end-to-end. The transport layer provides what is correctly called thetransport service.

The most commonly used transport protocols nowadays are TCP (transmission control protocol)and UDP (user datagram protocol). Both of these protocols are normally used in conjunction with IP (Internet protocol)¹⁸ based networks. TCP is said to provide areliable transport service, and works as aconnection-oriented transport service (COTS). The reliable and connection-oriented nature of TCP/IP gives it similar properties to an X.25 network. Note how X.25 did not need a transport layer to achieve this — users of X.25 typically use anull layer at the transport layer. UDP, meanwhile, is unreliable and is based on a connectionless transport service. Unlike TCP, UDP is unable to guarantee delivery of the message, but UDP is efficient in the use of the network for lower priority and short messages, since it requires much lessprotocol control information (PCI). In other words, it uses a shorter packetheader.

One often speaks of UDP being a ‘best effort’ protocol.

Peer-to-peer communication at the transport layer usually takes place between peer partner softwareapplications running in the two end-user computing devices. At the originating end, the transport layer organises a ‘connection’ on behalf of the computer application, thereby isolating the application completely from the constraints of the network or networks over which the data will be carried. The transport layer need only be informed by the application of the destination network address and software application (i.e., the peer partner— for example, the IP address of the destination device to which data is to be transported).

As necessary, the transport layer maysplit up a long stream of data into separate packets or individual messages and organise for these to be transported over one or more different networks and paths to the destination (Figure 3.27). This is important when using IP networks, since each packet is carried at the IP level as if it were a completely separate message.

At the destination, the separate packets are once again reassembled into the correct data sequence. For this, the transport layer protocol usesdata sequence numbersjust like layer 2 and layer 3 protocols. (Yet more sequence numbers, I here you say!) These are necessary for the reassembly process — helping ensure that packets which travelled via different networks are reassembled in order. In addition, the transport layer (as also at layers 2 and 3) provides for flow control and error correction on an application-to-application basis.

You may be wondering why each protocol layer appears to have yet another provision for sequence numbers, flow control and error correction. The simple answer is that each progressively higher layer may have to coordinate multiple networks or datalinks of the layer beneath it, and has a responsibility to ‘bring this all together’ as a single, coordinatedservice.

Figure 3.27 Transport layer functions of multiplexing and splitting.

18TCP is also well suited to use with frame relay.

Layer 4 — transport layer protocol 113 The sequence numbers of the transport layer, for example, control the flow of data directly between the end applications. These numbers aresynchronisedon an end-to-end basis, making the coordination much simpler.

Why not simply throw away the flow control and error correction at the lower protocol levels? To some extent, more modern protocols (e.g.,frame relay) have much weaker or no flow control and error correction procedures at the lower protocol layers, in order to reduce the total overhead of the protocol control information. When necessary, packet corruptions or losses can be recovered by having them retransmitted from their source. But in the past, when bit errors during transmission were more common, it made no sense to ‘start all over again’ from the start of the connection when half the journey (i.e., some of the data links) had been traversed without errors. Recovering the error at a midway point and ‘carrying on’ is sometimes far more efficient than taking the risk that on the next attempt from the beginning you do not even get as far, but meanwhile increase the load on the network.

Consider a simple connection comprising two data links, the first of which runs at a faster bit rate than the second. Then at the datalink level, the first link can deliver data into the intermediate node faster than the intermediate node is able to forward it. This is the reason why the intermediate node needs its datalink (i.e., layer 2) flow control. It ensures, in the short term, that the buffer does not overflow. Meanwhile the data flow controls of the higher layers (3 and 4) regulate the flow end-to-end across the intermediate networks and complete connection. If, for example, the receiving end-user device can only accept data at a relatively slow rate, then it is worth trying to match the original sending rate to the same speed. If more data is sent into the network than can get past a given ‘bottleneck’, or more data is sent than the receiver can accept, then the data only serves to clog up all the data buffers along the way, like a queue of cars at every traffic lights because everyone left for the same holiday destination at the same time. The solution? To spread the departures over a longer period of time.

Another important capability of the transport layer protocol is its ability tomultiplex differ-entsessionsacross the same transport ‘connection’. The different possible sessions correspond to different functions which the end-user computers may be coordinating between one another.

Different sessions are identified with different port numbers corresponding to the different activities. Different port numbers are allocated within TCP and UDP, for example, for the following differentsession, presentation andapplication services:

• FTP (file transfer protocol)— an application layer protocol which transfers data files between computers;

• Telnet— an network application allowing a PC to log-on to a remote mainframe computer via the Internet;

• SMTP (simple mail transfer protocol)— used for email service;

• HTTP (hypertext transfer protocol)— used for the Worldwide Web;

• DNS (domain name system)— used as a ‘directory’ for Worldwide Web addresses in the form www.company.com

• SNMP (simple network management protocol)— used for network management commu-nication and control of the devices;

• POP3 (post office protocol)andIMAP (interactive mail access protocol)– used for email service.

In addition to TCP and UDP, there are a number of other widely used transport protocols, but we will not discuss these in detail (More about transport protocols and applicationport numbers in Chapter 7!):

• TLI (transport layer interface), as defined in 1986 as part of the open systems intercon-nection (OSI) work and defined in ISO 8072 and ITU-T recommendation X.214;

• Transport protocol (associated with TLI above and defined by ISO 8073). This defines different service levels, specifically TP1, TP2, TP3, TP4 and TP5, of which TP4 (class 4) is the most widely used. TP4 stands for OSI transport protocol class 4 (error detection and recovery class). TP4 is the OSI ‘equivalent’ to TCP. It was developed by the US National Bureau of Standards and forms part of the US government OSI Profile (GOSIP) architecture;

• Windows95 transport protocol/NDIS (network driver interface specification)— this allows multiple higher layer protocol stacks to be multiplexed across a network;

• NetBEUI (NetBIOS extended user interface)— this provides a standard transport layer frame format for conveyance of NetBIOS (network basic input output system), as used to control sessions in LANs.