Which layer is responsible for source to destination delivery of packet?

Layer 4: The Transport Layer

The transport layer provides a total end-to-end solution for reliable communications. TCP/IP relies on the transport layer to effectively control communications between two hosts. When an IP communication session must begin or end, the transport layer is used to build this connection. The elements of the transport layer and how it functions within TCP/IP are discussed in more detail later in the chapter. The transport layer is the layer at which TCP/IP ports listen. For instance, the standard port which HTTP listens on is TCP Port 80, although HTTP could really run on any TCP port; this is the standard. Again, there is no difference between TCP port 80, 1000, or 50000; any protocol can run on it. Standardized port numbers are used to help ease the need to negotiate the port number for well-known applications.

4.2 TRANSPORT LAYER

A transport layer is required for transporting data beyond the boundaries of an address space. From the point of view of the transport layer, the data being transported consist of unstructured byte sequences. The transport layer is implemented by a concrete transport mechanism. The task of the transport layer is to abstract from platform-specific transport mechanisms and to offer a homogeneous interface to the presentation layer. The transport layer is typically merely a wrapper of the network functions offered by an operating system. Similar to the introduction of the bank scenario, an analysis of requirements presents the characteristics of the transport layer that form the basis for a design:

The transport layer guarantees a reliable end-to-end connection between precisely two address spaces.

Data can be sent bidirectionally in the form of unstructured byte sequences of any length.

Different transport mechanisms should be supported.

Transport layer links address spaces

The transport layer offers reliable end-to-end connections; that is, details of the underlying transport mechanism are hidden above the transport layer. Many transport mechanisms, such as TCP, already offer reliable connections. However, implementation of the transport layer using an unreliable transport mechanism makes it more difficult to guarantee suitable semantics above the transport layer.

The requirement that the transport layer should link exactly two address spaces together is aimed at reducing the complexity of the middleware. If this restriction did not exist, the administration of the transport channels between various address spaces would be complex. As a consequence, μORB only permits the objects belonging to an application to be distributed among exactly two address spaces.

The transport layer views data that are exchanged between a client and a server over the transport layer as unstructured, variable-length byte sequences. However, the transport layer is not expected to transmit continuous media, a capability required by multimedia applications. On the other hand, the assumption is that it will support different transport mechanisms.

The following use case suggests the type of modeling required at the class level:

The server establishes a communication end point and waits for a connection setup request.

The client creates a communication end point and connects it to the server.

The client sends data and waits for a response.

The server receives the data of the client and then sends a response.

After the client receives the response from the server, both close their communication end points.

Applications scenario of the transport layer

Note that in this use case the words “client” and “server” do not refer to objects. They refer instead to roles taken in interaction with the transport layer, thus indicating an asymmetry in the use of the transport layer. Clients and servers define a communications channel on the basis of the corresponding communication end points. The communication end points are specified by an address that represents a mutual consent between client and server. An address of the transport layer typically contains a network address that refers to the actual transport mechanism. Different transport mechanisms can have different address formats and details. Thus a generally valid format does not exist.

Classes Buffer, Address, and Transportmodel transport layer

Three classes are introduced for modeling the transport layer: Buffer, Address, and Transport. The class Buffer represents the storage area associated with a chunk of memory. Instances of this class are used as containers for the unstructured byte sequences that are transmitted between address spaces via a transport mechanism. The interface of the class Buffer offers methods for setting up and managing a memory chunk.

The class Address represents the address of a particular transport mechanism, and the class Transport represents the transport mechanism itself. The address here is used as a factory for the transport mechanism. The two classes themselves are abstract because they only form the interface for the actual transport mechanism. Therefore, two concrete classes have to be defined for each transport mechanism: one for the address and one for the transport mechanism itself. These classes are derived from the abstract base classes Address and Transport. Figure 4.2 shows a TCP-based transport mechanism in UML notation.

Address serves as a factory for Transport instances

The preceding use case clarifies the use of the transport layer and can be translated into the following C++ code fragment:

The transport mechanism used here is based on TCP/IP, which explains why instances of the class TCPAddress are used. A tuple (computer name, port number) establishes the communication end point for client and server (lines 2 and 12). The server generates the communication end point from the address in line 3, and using the method accept() waits for a connection setup request from the client. This method blocks the server until the client sets up a connection. The server then creates a data area using the class Buffer (line 6) and waits until a maximum of 10 bytes are received (line 7). The maximum number of bytes to be received is indicated as a parameter of the method recv(). The result that this method returns is the exact number of bytes received. The method close() is then used on the server side to terminate the connection to the client (line 8).

Transport mechanism on server side

The client proceeds in a similar way. However, instead of waiting for an incoming connection setup request, it initiates the connection to the server using the method open() (line 14). The method send() then transports a previously created data area to the server in line 15. The entire data area is sent without any transformation of the data. In line 16 the client terminates the connection to the server.

Transport mechanism on client side

3.1.6 Layer 4: Transport Layer

The transport layer delivers messages between transport service access points (TSAPs or ports) in different computers. Several processes running on a computer may be exchanging messages with processes running on other computers. The TSAPs appended to the messages differentiate those information streams. The transport layer may multiplex several low-rate transmissions with different TSAPs onto one virtual circuit or divide a high-rate connection into parallel virtual circuits.

Some frequently used applications such as e-mail and file transfers are allocated fixed TSAPs (also called well-known ports). To connect to a process with unknown TSAP, a remote process first connects to a process server attached to a fixed TSAP. The server then indicates the TSAP of the desired process.

The transport layer delivery of messages is either connection-oriented or connectionless. A connection-oriented transport layer delivers error-free messages in the correct order. Such a transport layer provides the following services: CONNECT, DATA, EXP_DATA, and DISCONNECT. CONNECT sets up a connection between TSAPs. DATA delivers a sequence of messages in the correct order and without errors. EXP_DATA delivers urgent messages by making them jump ahead of the nonurgent messages in the two end nodes. DISCONNECT releases the connection. A connectionless transport layer delivers messages one by one, possibly with errors, and with no guarantee on the order of the messages. The service of a connectionless transport layer is UNIT_DATA, the connectionless delivery of a single message.

The transport layer decomposes messages into packets and combines packets into messages, possibly after resequencing them. Such packetization may be necessary because the size of the message may be larger than the size of the packets accepted by the network layer. Resequencing may be necessary because packets may not be received in the order in which they are transmitted. To perform this packetization function, the transport layer numbers the packets belonging to the same message. The layer also controls the flow of packets to prevent the source from sending packets faster than the destination can handle them. Moreover, the transport layer requests retransmissions of corrupted packets (see Figure 3.8).

To be able to combine packets into messages, the transport layer numbers packets. When the source computer fails, it may lose track of the sequence number it had reached. Resuming the numbering arbitrarily might lead to delayed packets in the network having the same sequence numbers as the packets being transmitted; this would confuse the destination. One solution to this problem is to attach a “time to live,” L, to each packet and to decrement that time to live every time the packet goes through a network node. Packets with a zero time to live are discarded. Thus, L is the maximum number of hops for each packet, and it corresponds to a maximum lifetime of T seconds inside the network, because a packet will remain in each node for some bounded time. When a source computer recovers from a crash, it can wait for T seconds to make sure that all the delayed packets to the destination were discarded, thus avoiding any numbering ambiguity. The transport layer protocols in the two nodes agree on an initial sequence number by using a three-way handshake.

Figure 3.8 summarizes the functions of layers 4 to 7.

4. The Transport layer

The Transport layer describes the quality and nature of the data delivery. This layer ensures that messages are delivered error-free, in sequence, and with no losses or duplications. This layer defines if and how retransmissions will be used to ensure data delivery. The basic function of the Transport layer is to accept data from the session layer, split it up into smaller units if need be, pass these to the Network layer, and ensure that all the pieces arrive correctly at the other end. Furthermore, all this must be done efficiently and in a way that isolates the Session layer from the inevitable changes in the hardware technology.

Under normal conditions, the Transport layer creates a distinct network connection for each transport connection required by the Session layer. If the transport connection requires a high throughput, however, the Transport layer might create multiple network connections, dividing the data among the network connections to improve throughput. On the other hand, if creating or maintaining a network connection is expensive, the Transport layer might multiplex several transport connections onto the same network connection to reduce the cost. In all cases, the Transport layer is required to make the multiplexing transparent to the Session layer.

The transport layer also determines what type of service to provide to the Session layer, and ultimately, the users of the network. The most popular type of transport connection is an error-free point-to-point channel that delivers messages in the order in which they were sent. However, other possible kinds of transport, service and transport isolated messages exist, with no guarantee about the order of delivery to multiple destinations. The type of service is determined when the connection is established.

The Transport layer is a true source-to-destination or end-to-end layer. In other words, a program on the source machine carries on a conversation with a similar program on the destination machine, using the message headers and control messages.

Many hosts are multi-programmed, which implies that multiple connections will be entering and leaving each host. There needs to be some way to tell which message belongs to which connection. The transport header is one place where this information could be added.

In addition to multiplexing several message streams onto one channel, the Transport layer must establish and delete connections across the network. This requires some kind of naming mechanism, so that the process on one machine has a way of describing with whom it wishes to converse. There must also be a mechanism to regulate the flow of information, so that a fast host cannot overrun a slow one. Flow control between hosts is distinct from flow control between switches, although similar principles apply to both.

The Transport Layer

The transport layer is implemented by TCP and similar protocols. Not all transport protocols provide the same level of service as TCP, but a description of TCP will suffice to help us understand the issues addressed by the transport layer. The transport layer provides a multitude of functions.

First, the transport layer creates and manages instances of two-way channels between communication endpoints. These channels are called connections. Each connection represents a virtual endpoint between a pair of communication endpoints. A connection is named by a pair of IP addresses and port numbers. Two devices can support simultaneous connections using different port numbers for each connection. It is common to differentiate applications on the same host through the use of port numbers.

A second function of the transport layer is to support delivery of messages of arbitrary length. The 64 K byte limit of the underlying IP module is too small to carry really large messages, and the transport layer module at the message source chops messages into pieces called segments that are more easily digestible by lower-layer communications modules. The segment size is negotiated between the two transport endpoints during connection setup. The segment size is chosen by discovering the smallest maximum frame size supported by any MAC+PHY link on the path through the Internet used by the connection setup messages. Once this is known, the transmitter typically partitions a large message into segments no larger than this size, plus room for an IP header. The transport layer module passes each segment to the network layer module, where it becomes the payload for a single IP datagram. The destination network layer module extracts the payload from the IP datagram and passes it to the transport layer module, which interprets the information as a message segment. The destination transport reassembles this into the original message once all the necessary segments arrive.

Of course, as noted, MAC frames and IP datagrams can be lost in transit, so some segments can be lost. It is the responsibility of the transport layer module to detect this loss and retransmit the missing segments. This is accomplished by a sophisticated acknowledgment algorithm defined by the transport layer. The destination sends a special acknowledgment message, often piggybacked with a data segment being sent in the opposite direction, for each segment that arrives. Acknowledgments can be lost as well, and if the message source does not receive the acknowledgment within a time window, the source retransmits the unacknowledged segment. This process is repeated a number of times, and if the failure continues, the network layer tears down the connection because it cannot fulfill its reliability commitment.

One reason for message loss is congestion at routers, something blind retransmission of unacknowledged segments will only exacerbate. The network layer is also responsible for implementing congestion control algorithms as part of its transmit function. TCP, for instance, lowers its transmit rate whenever it fails to receive an acknowledgment message in time, and it slowly increases its rate of transmission until another acknowledgment is lost. This allows TCP to adapt to congestion in the network, helping to minimize frame loss.

It can happen that segments arrive at the destination out of order, since some IP datagrams for the same connection could traverse the Internet through different paths due to dynamic changes in the underlying network topology. The transport layer is responsible for delivering the segments in the order sent, so the receiver caches any segments that arrive out of order prior to delivery. The TCP reordering algorithm is closed tied to the acknowledgment and congestion control scheme so that the receiver never has to buffer too many out-of-order received segments and the sender not too many sent but unacknowledged segments.

Segment data arriving at the receiver can be corrupted due to undetected bit errors on the data link and copy errors within routers and the sending and receiving computing systems. Accordingly, all transport layers use a checksum algorithm called a cyclic redundancy check (CRC) to detect such errors. The receiving transport layer module typically discards segments with errors detected by the CRC algorithm, and recovery occurs through retransmission by the sender when it fails to receive an acknowledgment from the receiver for a particular segment.

11.5.4 Transport layer

The transport layer provides an interface for upper layer protocols (ULPs) (and applications) to communicate within and across subnets over network layer using a QP for send and receive operations. It is responsible for delivering a data payload from the source end node to the destination end node using the delivery characteristics desired by the application (e.g., reliable versus unreliable and connection versus datagram). The transport layer delivers packets to the right QP based on the information in the transport header.

The transport layer is also responsible for providing segmentation and reassembly services to ULPs. It segments consumer data in the transmit path into the right-sized payload based on the maximum transfer unit supported by the underlying network layer. Each segment is encapsulated with headers and CRC during transmission. Upon reception, a QP reassembles all the segments in a specified ULP buffer in memory.

Actual transport of data and its delivery is dependent on the type of service a given QP is configured with. Details about these mechanisms are discussed in Section 11.5.1.

Transport

The Transport layer starts to get into what is called the “upper layers” or “host layers” of the OSI model. This layer defines protocols that help even further ensure the integrity of network communications. At this layer, definitions are created that provide even more granular error correction for any messages that are sent between two devices on the network. In some cases, this involves taking large messages that are sent from the Session layer and splitting them up into more digestible chunks that increase the likelihood of the message getting to its destination successfully. Obviously, the larger a message is, the higher the probability that some small part of the message could get mangled causing the entire message to be unreadable. Protocols at the Transport layer help in preventing this. The Transport layer also handles creating the logical “end-to-end connection” between devices and adding the appropriate messages to maintain that active connection. We’ll discuss this in a little more detail when we get into specific protocols and the difference between connection-based and connectionless protocols.

20.5.4 Transport Layer

The transport layer helps to maintain the flow of data if the sensor network application requires it. The transport layer is needed when a system is planned to be accessed through the Internet or other external networks. Transmission control protocol (TCP) with its current transmission window mechanisms matches the extreme characteristics of the sensor network environment. An approach such as TCP splitting may be needed to make sensor networks interact with other networks such as the Internet. In this approach, TCP connections are ended at sink nodes, and a special transport layer protocol can handle the communication between the user and sink nodes. Communication between the user and sink node is by user datagram protocol (UDP) or TCP via the Internet or satellite. On the other hand, communication between the sink and sensor nodes may be purely by UDP-type protocols, because each sensor node has limited memory.

Event-to-sink reliable transport (ESRT) has been proposed to achieve reliable event detection (at the sink node) with a protocol that is energy aware and has congestion control mechanisms.

The end-to-end communication schemes in sensor networks are not based on global addressing. These schemes use attribute-based naming to indicate the destinations of the data packets. Factors such as power consumption and scalability, and characteristics such as data-centric routing mean sensor networks need different handling in the transport layer. Thus, these requirements stress the need for new types of transport layer protocols.

4.13.1 OSI Upper Layers

The role of the OSI upper layers (Transport, Session, Presentation, and Application) are summarized as follows [3, 14]:

The transport layer segments the messages into packets of acceptable sizes and performs the reassembly at the destination. It may multiplex many low-rate transmissions onto one virtual circuit or divide a high-rate transmission into parallel virtual circuits. The transport layer controls transmission errors and requests retransmissions of packets corrupted by transmission errors. In addition, the flow may be controlled by some mechanism to prevent one host from sending data faster than the destination host can handle.

The session layer sets up the call and takes care of the authentication of the user and of billing. The session layer supervises the synchronization (packet numbering) and the recovery in case of failures. The session layer closes the session at the end of transmission.

The presentation layer asks the session layer to set up a call. It specifies the destination's name and type of transmission (e.g., datagram, high priority). The presentation layer translates between the local syntax used by the application process and transfer syntax. The presentation layer also performs the required encryption and data compression.

The application layer provides information transfer services for user application programs. The user interacts with the application layer through a user interface. The application layer is composed of Specific Application Service Elements (SASEs) that use the services of Common Application Service Elements (CASEs). A CASE establishes are association between SASEs and may include an Association Control Service Element (ACSE), a Remote Operation Service Element (ROSE), and the Commitment Concurrency and Recovery (CCR) element.