These Notes are divided into hyperlinked sections
Introduction
Internet
Transport Protocols TCP and UDP
TCP
TCP Service Model
TCP Protocol
TCP Segment Header
Performing the Checksum
TCP Connection Management
Timing out
User Datagram Protocol
UDP
ATM
Subdivisions of AAL
AAL Structure
AAL 1
AAL 2
AAL 3/ 4
AAL
5 (Simple Efficient Adaptation Layer) SEAL
Conclusion
Further Reading
The Transport Layer resides above the network layer and exists in all hosts. Its function is to add a layer of reliability to the inherently unreliable network (and lower) layers.
Network nodes do not need to have a transport layer as they are not concerned with the application that deals with the data, just its delivery.
We will see the options for sending data offered by the Transport Layer, namely TCP and UDP. We will examine the options offered by TCP and see how this relates to UDP.
Finally we will see how ATM deals with issues such as
connections and reliability and examine the ATM Adaptation layers in current
use.
Internet Transport Protocols TCP and UDP
There are two main protocols in the transport layer of the Internet, one being connection oriented, the other connectionless. These are Transmission Control Protocol TCP and User Datagram Protocol UDP respectively.
This was originally designed to provide a reliable end-to-end byte stream over an unreliable internetwork. Because the design of intervening networks can vary widely in terms of topologies, bandwidths, delays, packet sizes etc. TCP was designed to dynamically adapt to these conditions and be robust in the face of many failures.
The definition of TCP may be found in RFC 793 and subsequent additions may be found in RFC 1122 and RFC 1323.
All machines supporting TCP must have a transport entity to manage TCP streams and interfaces to the IP layer.
The TCP entity accepts user data streams from local processes and sends each piece as a separate IP datagram. IP guarantees nothing so TCP has to oversee the operation and time-out and re-transmit as necessary. At the receiving end, TCP has to re-order datagrams as necessary.
The TCP service operates by having both end systems create and define sockets (IP number plus port number). The port number is a 16-bit number local to the host only and is also known as a TSAP. A socket may be used as the termination of one or more connections. No other identifiers or VC numbers are used. Well known destination ports are 21 for the FTP daemon and 23 for TELNET. A list of well known ports may be found in RFC 1700.
All TCP connections are full duplex and point to point therefore traffic an flow in both directions but only between two end systems. The traffic is a byte-stream rather than a message stream so message boundaries are not preserved end to end. The TCP software has no idea what the bytes mean and no need to find out.
When an application passes data to TCP it may be sent at once or alternatively it may be queued ( buffered) to collect a larger amount to send in one go. To override this, the PUSH flag may be used to force TCP to send the data immediately. If an interactive user presses DEL or CTRL+C to break off a remote computation, the TCP entity sends the data with an URGENT flag and this data is sent. Upon arrival, the TCP entity passes this up to the receiving application where the data stream is read to discover the urgent data. The end of the urgent data is marked, but not the beginning so it is up to the receiving application to work this out.
Every byte on a TCP connection has its own 32-bit sequence number. Sending and receiving entities exchange data in the form of segments consisting of a fixed 20-byte header plus an optional part) followed by zero or more data bytes. The TCP software decides how big the segments should be.
Each segment, including TCP header must fit into the 65 535 IP byte payload. Also each network will have a Maximum Transmission Unit MTU and each segment must fit into the MTU (usually a few thousand bytes). If a message passes across a network without being fragmented and then meets the boundary of another network with a smaller MTU, the segment is fragmented i.e. broken into smaller pieces by the router at the networks' boundary.
Each new segment thus formed by fragmentation gets its own IP header and so increases overhead (IP header = 20 bytes).
TCP entities use the sliding window protocol and when a segment is transmitted, the sender starts a timer. When the segment arrives at its destination, the receiving entity sends back a segment (including data if it is a 2-way data exchange) with an acknowledgement number equal to the next byte sequence number that it expects to receive. If the timer ends before the acknowledgement is received, the sender re-transmits the segment to which the timer alluded.
TCP must cope with
Figure 8.1 shows a TCP segment header. The first 20 bytes are fixed and always appear. This is the from Source port to Urgent pointer. After the options (if any) 65 495 bytes may follow. This is made from 65 535 (IP maximum size) less 20 bytes for IP header less 20 bytes for the TCP header. Segments without data may be sent for ACKs and control messages.
Source and destination ports identify the local end ports for the applications that are conversing
Sequence number identifies the first byte number that is being sent and ACK identifies the next byte sequence number expected.
TCP header length says how many 32-bit words are contained
in the TCP header. Needed because the options field is of variable length.
It points to the start of the data.
Fig 8.1 TCP Segment Header
Next come 6 unused bits. After that is the URG Urgent pointer to indicate if the Urgent field is in use and indicates the byte offset of urgent data described by the urgent pointer field.
ACK is 1 if the ACK field is valid, 0 otherwise.
PSH indicates pushed data and indicates to the receiver that the data ought to be passed to the application immediately.
RST resets a connection that has become confused due to a host crash or other reason.
SYN is used to establish connection. A connection request is SYN = 1 and ACK = 0 indicating that the piggyback acknowledgement is not in use. The connection reply does bear an ACK and so it is SYN = 1, ACK = 1. The SYN bit denotes Connection Request and Connection Accepted with the ACK bit differentiating between them.
The FIN bit releases the connection and specifies that the sender has no more data to send (but is prepared to receive more). SYN and FIN numbers have sequence numbers and are guaranteed to be processed in the correct order.
TCP handles flow control using a variable sliding window. Window size field specifies how many bytes may be sent starting at the byte acknowledged. If a Window size of 0 is received, it means that bytes up to and including Acknowledgement number - 1 have been received correctly but the receiver needs a break to clear its buffers. To restart the transmission, another segment is sent by the (previously) busy entity but containing the same Acknowledgement number and a non-zero Window size field.
Checksum provides for more reliability. The checksum operates across the header and the data.
Receiver does same and result should be 0 (including
checksum).
In client/ server relationship, primitives are used to control the connection.
Server passively waits for requests for service by issuing LISTEN and ACCEPT primitives.
Client issues a CONNECT primitive specifying IP address and port number, maximum TCP segment size it can accept and maybe some data e.g. password. Connect primitive sends a TCP segment to with SYN = 1 and ACK = 0 and waits for a response.
When the segment arrives, the TCP entity checks whether a process exists that has done a LISTEN on the port specified in the segment. If there is none, the RST bit is set to indicate a rejection of the connection.
If a process is listening on the port specified, that process is handed the TCP segment. The process itself may accept or reject the connection. If accepted, an ACK segment is sent back.
When a connection is released the initiator of the release will wait two maximum packet lifetimes and regardless of whether the FIN is acknowledged, the originator closes the connection. The other end will realise that nobody is listening after a while and also release its connection.
This is described in RFC 768. It is a way that applications can use to send encapsulated raw IP datagrams and send them without establishing a connection. Client server applications that have one request and one response often use UDP. It is also used within the application ICQ to send characters.
UDP segment consists of a 8-byte header followed by the data (IP datagram).
Fig 8.2 UDP Header
The source and destination port have the same meaning as the TCP ports, the UDP length specifies the length of the UDP header and data. The UDP checksum is calculated in a similar manner as the TCP checksum. This may be turned off for applications such as digitised speech.
It is not totally clear whether ATM has a transport layer. The ATM layer has the functionality of a network layer and an upper layer known as AAL is similar to a transport layer. AAL5 is functionally similar to UDP, a transport layer protocol.
None of the AAL protocols provide a reliable end-to-end connection as done by TCP. In most cases a transport layer is used on top of AAL.
AAL was designed to provide excellent transmission of voice and video streams. Here rapid delivery is more important than accurate delivery. ATM merely produces 48 byte data chunks with a 5 byte header and has no error control (apart from header check), no flow control and no other control. This leads to a conflict in the requirements of most applications used.
To help solve this Recommendation I.363 was defined by ITU to sit atop of the ATM layer. It is called AAL, ATM Adaptation Layer and is full of mistakes, revisions and unfinished business.
Real-time vs. nonreal-time service
Constant bit rate versus variable bit rate service
Connection oriented service versus connectionless service
With three subdivisions offering two types of service, eight distinct services can be defined. ITU decided that only four of the eight were useful and defined classes A, B, C and D. The others were not supported.
ITU defined services AAL1 through to AAL4. It was realised that the technical requirements for AAL3 and AAL4 were so similar that they were combined into AAL3/4. The computer industry decided that none of the above were any use and defined AAL5.
The upper part of AAL is inhabited by the convergence sublayer. This has a job to provide an interface to the application. The lower part is common to all ATM applications (for that protocol) and the upper part is application specific.
The convergence sublayer is responsible for accepting bit streams from applications and then breaking them into 44 or 48 byte units for transmission. The size is protocol dependent.
At the reception, the sublayer reassembles the cells into the original messages and passes them to the appropriate process.
The lower part of AAL is called Segmentation and Reassembly SAR sublayer and can add headers and trailers to data units passed to it by the convergence layer and forms cell payloads. At the destination, SAR reassembles cells into messages and passes them up to the convergence sublayer.
SAR passes the cells down to the ATM layer for transmission as independent cells.
Used for transmitting class A traffic - real time, constant bit rate, connection oriented traffic e.g. uncompressed audio and video.
For connection oriented real time data streams with no error correction except for missing and misinserted cells.
Suitable for connection and connectionless data that is sensitive to loss or errors but not time dependent
One useful feature is that AAL3/4 allows multiplexing therefore multiple sessions may travel along the same connection (VC) and be separated at the far end.
AAL5 Simple Efficient Adaptation Layer) SEAL
Designed by the computer industry. It offers several choices:
For a further treatment of ATM see my
notes
The Transport Layer provides a reliable front to the unreliable network (and lower) layers below. TCP and UDP exist as connection and connectionless connections respectively.
Sockets are defined as the application port number plus the IP number. TCP header contains source and destination port, a segment number to allow lost bytes to be recovered, error checking information and fields to set up and manage connections.
UDP header is much smaller and only identifies the source and destination ports, includes error checking and UDP length.
ATM operates in a totally different manner to TCP/ IP or OSI. A transport layer should be run above ATM to ensure accuracy of delivery.
ATM has Adaptation layers, the most useful one of which
is AAL 5, designed by the computer community.
Internet Transport Protocols TCP and UDP 521
TCP Service Model
TCP Protocol 524
TCP connection management
TCP transmission policy
TCP congestion control
TCP timer management
UDP 542
ATM AAL protocols 545
(c) MMClements 2001
Back to Top
of Page