Tải bản đầy đủ
5 Layer 4 ¡ª transport layer protocol
Basic data networks and protocols
the way. The transport layer in this case has to ensure the coordination and control of all the
various networks and arrange communication end-to-end. The transport layer provides what
is correctly called the transport service.
The most commonly used transport protocols nowadays are TCP (transmission control
protocol) and UDP (user datagram protocol). Both of these protocols are normally used in
conjunction with IP (Internet protocol)18 based networks. TCP is said to provide a reliable
transport service, and works as a connection-oriented transport service (COTS). The reliable
and connection-oriented nature of TCP/IP gives it similar properties to an X.25 network. Note
how X.25 did not need a transport layer to achieve this — users of X.25 typically use a null
layer at the transport layer. UDP, meanwhile, is unreliable and is based on a connectionless
transport service. Unlike TCP, UDP is unable to guarantee delivery of the message, but UDP
is efficient in the use of the network for lower priority and short messages, since it requires
much less protocol control information (PCI). In other words, it uses a shorter packet header.
One often speaks of UDP being a ‘best effort’ protocol.
Peer-to-peer communication at the transport layer usually takes place between peer partner
software applications running in the two end-user computing devices. At the originating end,
the transport layer organises a ‘connection’ on behalf of the computer application, thereby
isolating the application completely from the constraints of the network or networks over which
the data will be carried. The transport layer need only be informed by the application of the
destination network address and software application (i.e., the peer partner — for example,
the IP address of the destination device to which data is to be transported).
As necessary, the transport layer may split up a long stream of data into separate packets
or individual messages and organise for these to be transported over one or more different
networks and paths to the destination (Figure 3.27). This is important when using IP networks,
since each packet is carried at the IP level as if it were a completely separate message.
At the destination, the separate packets are once again reassembled into the correct data
sequence. For this, the transport layer protocol uses data sequence numbers just like layer 2
and layer 3 protocols. (Yet more sequence numbers, I here you say!) These are necessary for
the reassembly process — helping ensure that packets which travelled via different networks
are reassembled in order. In addition, the transport layer (as also at layers 2 and 3) provides
for flow control and error correction on an application-to-application basis.
You may be wondering why each protocol layer appears to have yet another provision
for sequence numbers, flow control and error correction. The simple answer is that each
progressively higher layer may have to coordinate multiple networks or datalinks of the layer
beneath it, and has a responsibility to ‘bring this all together’ as a single, coordinated service.
Figure 3.27 Transport layer functions of multiplexing and splitting.
TCP is also well suited to use with frame relay.
Layer 4 — transport layer protocol
The sequence numbers of the transport layer, for example, control the flow of data directly
between the end applications. These numbers are synchronised on an end-to-end basis, making
the coordination much simpler.
Why not simply throw away the flow control and error correction at the lower protocol
levels? To some extent, more modern protocols (e.g., frame relay) have much weaker or no
flow control and error correction procedures at the lower protocol layers, in order to reduce
the total overhead of the protocol control information. When necessary, packet corruptions
or losses can be recovered by having them retransmitted from their source. But in the past,
when bit errors during transmission were more common, it made no sense to ‘start all over
again’ from the start of the connection when half the journey (i.e., some of the data links) had
been traversed without errors. Recovering the error at a midway point and ‘carrying on’ is
sometimes far more efficient than taking the risk that on the next attempt from the beginning
you do not even get as far, but meanwhile increase the load on the network.
Consider a simple connection comprising two data links, the first of which runs at a faster
bit rate than the second. Then at the datalink level, the first link can deliver data into the
intermediate node faster than the intermediate node is able to forward it. This is the reason
why the intermediate node needs its datalink (i.e., layer 2) flow control. It ensures, in the
short term, that the buffer does not overflow. Meanwhile the data flow controls of the higher
layers (3 and 4) regulate the flow end-to-end across the intermediate networks and complete
connection. If, for example, the receiving end-user device can only accept data at a relatively
slow rate, then it is worth trying to match the original sending rate to the same speed. If more
data is sent into the network than can get past a given ‘bottleneck’, or more data is sent than
the receiver can accept, then the data only serves to clog up all the data buffers along the
way, like a queue of cars at every traffic lights because everyone left for the same holiday
destination at the same time. The solution? To spread the departures over a longer period
Another important capability of the transport layer protocol is its ability to multiplex different sessions across the same transport ‘connection’. The different possible sessions correspond
to different functions which the end-user computers may be coordinating between one another.
Different sessions are identified with different port numbers corresponding to the different
activities. Different port numbers are allocated within TCP and UDP, for example, for the
following different session, presentation and application services:
• FTP (file transfer protocol) — an application layer protocol which transfers data files
• Telnet — an network application allowing a PC to log-on to a remote mainframe computer
via the Internet;
• SMTP (simple mail transfer protocol) — used for email service;
• HTTP (hypertext transfer protocol) — used for the Worldwide Web;
• DNS (domain name system) — used as a ‘directory’ for Worldwide Web addresses in the
• SNMP (simple network management protocol) — used for network management communication and control of the devices;
• POP3 (post office protocol) and IMAP (interactive mail access protocol)–used for email
In addition to TCP and UDP, there are a number of other widely used transport protocols,
but we will not discuss these in detail (More about transport protocols and application port
numbers in Chapter 7!):
Basic data networks and protocols
• TLI (transport layer interface), as defined in 1986 as part of the open systems interconnection (OSI) work and defined in ISO 8072 and ITU-T recommendation X.214;
• Transport protocol (associated with TLI above and defined by ISO 8073). This defines
different service levels, specifically TP1, TP2, TP3, TP4 and TP5, of which TP4 (class 4)
is the most widely used. TP4 stands for OSI transport protocol class 4 (error detection
and recovery class). TP4 is the OSI ‘equivalent’ to TCP. It was developed by the US
National Bureau of Standards and forms part of the US government OSI Profile (GOSIP)
• Windows95 transport protocol/NDIS (network driver interface specification) — this allows
multiple higher layer protocol stacks to be multiplexed across a network;
• NetBEUI (NetBIOS extended user interface) — this provides a standard transport layer
frame format for conveyance of NetBIOS (network basic input output system), as used to
control sessions in LANs.
3.6 Layers 5–7 — higher layer protocols
The higher layer protocols of layer 5 (session layer), layer 6 (presentation layer) and layer
7 (application layer), like the transport layer (layer 4) are resident in the computer enddevices which communicate end-to-end across the network. The peer partners are computer
software programs at the operating system and application program level. Because such
programs are often delivered as a complete ‘suite’ of software by a given software or operating
system manufacturer (e.g., Microsoft, Sun Microsystems, etc.), the standardisation of software
interfaces at these higher layers has come to follow the ‘proprietary’ and ‘de facto’ standards
established by the computing industry rather than the original strict layers envisaged by OSI.
The number of ‘layers’ of protocols and software and the boundaries between layers can
thus become somewhat blurred. Thus, for example, a single software may spread across all
the layers 5–7 (or even 4–7). Put simply, only a few still comply rigidly to the OSI model
and standards. Nonetheless, it is instructive to consider examples of commonly used software
which provides the functionality of these layers.
The session layer is an end-user computer program responsible for binding (setting up and
managing communications) and unbinding logical links between two application programs
(e.g., computer-to-computer, computer-to-printer, etc.). Put simply, the session layer manages
the different computer hardware resources which are interconnected by means of a network.
It is thus strongly linked to the computer operating system (OS) software. The session layer
provides ‘network gateway capabilities’ which link the ‘computer world’ to the ‘telecommunications world’.
Above the session layer, computers are largely concerned only with datafiles (in different
formats) and ‘real’ application software. These are the concerns respectively of the presentation and application layers. In this world of programming and computing hardware, software
designers, network administrators and users prefer to refer to devices with names or acronyms
such as ‘LPT1’, ‘local printer’, ‘group-printer’, ‘peter-pc’, etc. Referring to the devices like this
means you don’t have to change the software each time the network gets reconfigured, somebody moves or the network addresses change. But it does mean that a central network resource
management is needed, linking computer names to network addresses, binding and unbinding
Layers 5–7 — higher layer protocols
these devices to their addresses and setting-up sessions when they wish to communicate with
one another. This is the job of the session layer.
The session layer has to be able to cope with recovering such problems as the remote
computer being switched off. Having initiated a session, the session layer has to be able to
check that it remains ‘alive’. The software commands issued to the session layer and used to
invoke and control session activities are ‘input’ and ‘output’ commands which will be familiar
to computer programmers:
Typical and well-known examples of software providing session services and protocols19 are:
• Berkeley socket service or socket interface (this was the first consistent application programming interface, used in UNIX and TCP/IP networking environments since the early
• NetBIOS (network basic input output system) — provides for session and transport services
between PCs and servers in LANs. It was originally developed for IBM’s LAN manager software, but subsequently became the basis of Windows NT and Windows 2000
networking, which is nowadays the most commonly used LAN management software.
• RPC (remote procedure call) — used for the initial UNIX client server networking;
• Secure sockets layer (SSL) — a layer introduced between session and transport layers to
provide for extra authentication and encryption of communications between a web user
(client) and a web server;
• Winsock (Windows socket interface);
• SIP (session initiation protocol) for VOIP (voice over IP).
A session binds two logical units (LUs) by arranging for the interconnection of the two relevant network ports (identified by their network addresses and transport layer ports). Session
multiplexing allows a single device (e.g., a server) to ‘speak’ with multiple remote devices
(e.g., clients) at once.
The term bind originates from Berkeley Internet Name Daemon. This was originally a
software and a related file which provided a link between the logical names known by computer
programs and Internet addresses. In a UNIX system, the IP address information related to
computer and device usernames is held in a file called ‘etc/hosts’. The Windows equivalent
is called WINS (Windows Internet name server). It deals with name registration, queries and
As the Internet rapidly became more complex, it became impractical to store all possible
remote device names, web addresses (e.g., www.company.com) and related network addresses
in a local file called /etc/hosts and to keep this file up-to-date. Instead, root directories and
the domain name system (DNS)20 were developed.
See Chapter 10.
See Chapter 11.