Better to know some
... than all
The transport protocol is essentially connection oriented, regardless of whether the underlying network layer uses virtual circuits or datagrams. After establishing a connection (always full-duplex), the two user processes may exchange data in the normal or expedited fashion. The sequence of exchanged messages is always maintained, except for expedited data, which do not obey the normal flow control. For messages larger than can be handled by the network layer, the transport layer performs the necessary segmentation and re-assembly.
Transport layer messages are exchanged by the network layer using Transport Protocol Data Units (TPDUs). In a manner similar to the network sublayers 2 and 3, a user PDU may be represented by a single TPDU, or segmented into multiple TPDUs when it is too large.
A TPDU consists of a variable length header and user Data. The contents of the header is dependent on the TPDU Type.
Classes of Protocol
To facilitate the mapping of the user-requested QOS to an appropriate network QOS, five classes (0-4) of transport protocols are defined. The protocol class is selected during the establishment of a transport connection according to the requested QOS. The choice is made transparently by the transport layer without the user's knowledge or involvement.
Class 0 is the most basic transport service and is suitable for type A networks. Although Class 0 is capable of detecting data errors (e.g., corrupted, lost, duplicated data) and signaled errors (e.g., failure in switching nodes), it cannot recover from them. These errors therefore result in the connection being terminated. This is the simplest form of transport service and must be supported by all transport layer implementations. (Supporting other classes is optional.)
Class 1 protocol supports recovery from signaled errors. It also supports segmentation, expedited data transfer, and acknowledgment using sequence numbers.
Class 2 is like class 0, except that it also supports multiplexing and flow control.
Class 3 is like class 2, except that it also supports recovery from signaled errors.
Class 4 provides the widest set of features, making its suitable for C type networks. It is the only class that supports the resequencing of TPDUs, and the splitting of the transport connection into multiple network connections to improve throughput.
The Transport Service Data Units (TSDUs) which the transport service users work with may be larger than can be handled by the network layer packets. For this reason, all protocol classes support the segmenting of TSDUs into multiple TPDUs and reassembling them at the receiver end. This facility is very similar to the segmentation facility supported by the internetworking sublayers.
Given the limited number of ports available on a host and the potentially large number of transport connections usually required by the users, multiple transport connections are often multiplexed onto a single network connection. The price to be paid for this is additional complexity: transport connections need to carry identifiers for distinguishing between connections over the same circuit, and each connection needs to be separately flow controlled. Multiplexing is supported by Class 2, 3, and 4 protocols.
Splitting and Recombining
In situations where a transport connection is needed to have a bandwidth of size that cannot be provided by a single network connection, the connection may be split over multiple network connections. This is the opposite of multiplexing and introduces an additional complexity: with multiple network connections, the TPDUs may arrive out of order and need to be resequenced. Thus splitting can only be supported when the transport protocol can support resequencing of TPDUs. Class 4 is the only protocol that can provide this function.
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.
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.
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.