August 8, 2010

Internet Protocol Suite: Transport Layer Protocols

An illustration based on :Image:Voip HowItWork...
In computer networking, the Transport Layer is a group of methods and protocols within a layered architecture of network components within which it is responsible for encapsulating application data blocks into data units (datagrams, segments) suitable for transfer to the network infrastructure for transmission to the destination host, or managing the reverse transaction by abstracting network datagrams and delivering their payload to an application. Thus the protocols of the Transport Layer establish a direct, virtual host-to-host communications transport medium for applications and therefore also referred to as transport protocols.

Transport layers are contained in both the TCP/IP model (RFC 1122), which is the foundation of the Internet, and the Open Systems Interconnection (OSI) model of general networking. The definitions of the Transport Layer are slightly different in these two models. This article primarily refers to the TCP/IP model. See also the OSI model definition of the Transport Layer.

The most well-known transport protocol is the Transmission Control Protocol (TCP). It lent its name to the title of the entire Internet Protocol Suite, TCP/IP. It is used for connection-oriented transmissions, whereas the connectionless User Datagram Protocol (UDP) is used for simpler messaging transmissions. TCP is the more complex protocol, due to its stateful design incorporating reliable transmission. Other prominent protocols in this group are the Datagram Congestion Control Protocol (DCCP) and the Stream Control Transmission Protocol (SCTP).

Transmission Control Protocol (TCP)
The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite (the other being Internet Protocol, or IP), so the entire suite is commonly referred to as TCP/IP. Whereas IP handles lower-level transmissions from computer to computer as a message makes its way across the Internet, TCP operates at a higher level, concerned only with the two end systems, for example a Web browser and a Web server. In particular, TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. Besides the Web, other common applications of TCP include e-mail and file transfer. Among its other management tasks, TCP controls segment size, the rate at which data is exchanged, and network traffic congestion.

User Datagram Protocol
The User Datagram Protocol (UDP) is one of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special transmission channels or data paths. UDP is sometimes called the Universal Datagram Protocol. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768.

UDP uses a simple transmission model without implicit hand-shaking dialogues for guaranteeing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to using delayed packets. If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.

UDP's stateless nature is also useful for servers that answer small queries from huge numbers of clients. Unlike TCP, UDP is compatible with packet broadcast (sending to all on local network) and multicasting (send to all subscribers).

Common network applications that use UDP include: the Domain Name System (DNS), streaming media applications such as IPTV, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP) and many online games.

Datagram Congestion Control Protocol
The Datagram Congestion Control Protocol (DCCP) is a message-oriented Transport Layer protocol. DCCP implements reliable connection setup, teardown, ECN, congestion control, and feature negotiation. DCCP was published as RFC 4340, a proposed standard, by the IETF in March, 2006. RFC 4336 provides an introduction. Linux had an implementation of DCCP first released in Linux kernel version 2.6.14 (released October 28, 2005).

DCCP provides a way to gain access to congestion control mechanisms without having to implement them at the Application Layer. It allows for flow-based semantics like in TCP, but does not provide reliable in-order delivery. Sequenced delivery within multiple streams as in SCTP is not available in DCCP.

DCCP is useful for applications with timing constraints on the delivery of data that may become useless to the receiver if reliable in-order delivery combined with congestion avoidance is used. Such applications include streaming media, multiparty online games and Internet telephony. Primary feature of these applications is that old messages quickly become stale so that getting new messages is preferred to resending lost messages. Currently such applications have often either settled for TCP or used UDP and implemented their own congestion control mechanisms (or have no congestion control at all).

While being useful for these applications, DCCP can also be positioned as a general congestion control mechanism for UDP-based applications, by adding, as needed, a mechanism for reliable and/or in-order delivery on the top of UDP/DCCP. In this context, DCCP allows the use of different (but generally TCP-friendly) congestion control mechanisms.

A DCCP connection contains acknowledgment traffic as well as data traffic. Acknowledgments inform a sender whether its packets arrived, and whether they were ECN marked. Acks are transmitted as reliably as the congestion control mechanism in use requires, possibly completely reliably.

DCCP has the option to have very long (48-bit) sequence numbers corresponding to a packet ID (rather than a byte ID as in TCP). The long length of the sequence numbers is intended to guard against "some blind attacks, such as the injection of DCCP-Resets into the connection."

Stream Control Transmission Protocol
In computer networking, the Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role as the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Indeed, it provides some of the same service features of both, ensuring reliable, in-sequence transport of messages with congestion control.

The protocol was defined by the IETF Signaling Transport (SIGTRAN) working group in 2000, and is maintained by the IETF Transport Area (TSVWG) working group. RFC 4960 defines the protocol. RFC 3286 provides an introduction.

In the absence of native SCTP support in operating systems it is possible to tunnel SCTP over UDP, as well as mapping TCP API calls to SCTP ones.

Resource reservation protocol
The Resource ReSerVation Protocol (RSVP), described in RFC 2205, is a Transport layer protocol designed to reserve resources across a network for an integrated services Internet. "RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols" - RFC 2205. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows with scaling and robustness.

RSVP can be used by either hosts or routers to request or deliver specific levels of quality of service (QoS) for application data streams or flows. RSVP defines how applications place reservations and how they can relinquish the reserved resources once the need for them has ended. RSVP operation will generally result in resources being reserved in each node along a path.

RSVP is not itself a routing protocol and was designed to interoperate with current and future routing protocols.

Explicit Congestion Notification
Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. It is an optional feature, and is only used when both endpoints signal that they want to use it.

Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header instead of dropping a packet in order to signal the beginning of congestion. The receiver of the packet echoes the congestion indication to the sender, which must react as though a packet drop were detected.

ECN uses two bits in the Differentiated Services field in the IP header, in the IPv4 TOS Byte or the IPv6 Traffic Class Octet. These two bits can be used to encode one of the values ECN-Capable Transport (ECT), Not-ECN-Capable Transport (Not-ECT) or Congestion Experienced (CE).

Some outdated or buggy network equipment drops packets with the ECN bit set, rather than ignoring the bit.

About the Author


Author & Editor

Has laoreet percipitur ad. Vide interesset in mei, no his legimus verterem. Et nostrum imperdiet appellantur usu, mnesarchum referrentur id vim.

Post a Comment

Iwebslog Blog © 2015 - Designed by