Addressing

A transport layer source or destination address uniquely identifies a TSAP within a network-wide name space. The TSAP denotes a port on a host to which transport connections are made. Transport addresses are not directly used by TPDUs;

references are used instead. These are much shorter identifiers that are mapped to the transport addresses (in the variable part of the TPDU header) during connection establishment, allowing the two parties to agree on a common mapping. The source and destination references are used for the remainder of the connection.

Also, for user convenience, a higher level mapping is often provided by a name server, which maps meaningful service names for frequently-used transport addresses to the addresses themselves. When wishing to connect to one of these services, the user specifies the service name and the network software looks up the name using the name server to come up with the corresponding transport address, which is then used for initiating a transport connection.

5.2.7. Flow Control

As mentioned earlier, supporting multiplexing in Class 2, 3, and 4 protocols requires transport connections to be separately flow controlled. The flow control protocol used for this purpose is called credit. It is similar to the sliding window protocol of the data link and network layers in that a window is used. However, unlike the sliding window protocol where the receiver window size remains fixed, here the window size may vary. The sender is informed of the new window size through a data acknowledgment TPDU which includes a new credit value (the Credit field in the TPDU) which denotes the number of TPDUs that can be received.

A suitable credit value is negotiated during connection establishment. This value can be dynamically adjusted subsequently by the receiver. When the receiver is unable to receive further TPDUs, it can suspend flow of further TPDUs by adjusting the credit value to 0.

5.2.8. Error Checking

The transport layer may do additional error checking on top of the ones carried out by lower layers. This may serve one of two reasons: the lower layers might not be performing any error checking, or the network service may be very unreliable and deliver packets that have undetected errors.

To address these needs (especially for the Class 4 protocol) a checksum option is available in the TPDUs. This is a 16-bit checksum that covers the entire TPDU and is designed to be much simpler than CRC so that it can be efficiently computed in software.

5.3.

Transport Layer Standards

Transport services (discussed in Section 5.1) are defined by the ISO 8072 and CCITT X.214 standards. ISO 8073 and CCITT X.224 define the transport protocol, and were the basis of the descriptions in Section 5.2. Below we will look at TCP— a de facto transport layer standard that has gained considerable acceptance in the industry.

5.3.1. TCP

The Transmission Control Protocol (TCP) originated in ARPANET, and was designed to cope with Type C networks. Consequently, the CCITT Class 4 protocol has borrowed many of its concepts. TCP sits directly on top of IP (see Chapter 4) and is well suited to internetworking. The combination is commonly referred to as TCP/IP.

TCP accepts arbitrary size messages from a service user and, if necessary, segments them into smaller blocks. Figure 5.62 depicts the general structure of a TCP block. The block is constructed in two stages. First, a TCP header is added to user data; this header is essentially a transport-layer-style header. Next, a datagram header is added to the result to prepare it for a datagram network service.

Given the unreliable network service expectations of TCP (Type C), blocks may be corrupted, lost, duplicated, or out of sequence. TCP uses sequence numbers and resequences blocks when necessary. Unlike other protocols, sequencing is performed on an octet rather than block basis. The sequence numbers for the octets in a block are determined by the Sequence Number and the Total Length fields. Flow control is also octet-oriented. It is based on a credit-style sliding window, where the window size determines how many octets may be transmitted.

Figure 5.62 General structure of a TCP block.

Field Description

Version Datagram protocol version. Header Length Datagram header length.

Service Type Type of service expected of the network layer. Total Length Total length of the block.

Datagram Segment Owner The sequence number of the owner datagram. Segment Flags Segmentation-related flags.

Header Segment Offset Offset to where segment begins in owner datagram. Lifetime Block lifetime in seconds.

Checksum Simple checksum for the datagram header. Addresses Source and destination network+host addresses.

Options Various options for errors, routing, security, etc. Ports Source and destination ports.

Sequence Number Sequences every octet of data.

Acknowledgment Used for piggyback acknowledgment of data. TCP Header Length Length of the TCP header.

Flags Flags for SYN, ACK, segmentation, reset, etc.

Header Window Window size in octets.

Checksum Simple checksum for the TCP header. Expedited Offset to where expedited data is located.

Options Various TCP-related options, e.g., buffer sizes. User Data Actual transport service user data.

Corrupted and lost blocks are retransmitted (the T1 timer is used for detecting lost blocks). Delayed duplicate control blocks for establishing connections are dealt with

using the three-way handshake method. In this method, to establish a connection between A and B, when A requests a connection and receives a confirmation from B, it must acknowledge (and therefore finalize) the connection as intended. Should B receive a delayed duplicate connection request and confirm it, A will know that this is due to a duplicate message and reject the connection on that basis.

5.4.

Further Reading

Schwartz (1987), Black (1989), and Stallings (1994) provide general descriptions of the transport layer protocols and standards. Black (1992), Feit (1992), Comer (1993), and Piscitello and Chapin (1993) describe TCP/IP in detail.