Tải bản đầy đủ
6 Layers 5 ¨C 7 ¡ª higher layer protocols

6 Layers 5 ¨C 7 ¡ª higher layer protocols

Tải bản đầy đủ

Layers 5–7 — higher layer protocols

115

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:
accept
bind
close
connect
listen

Msg.Call
Msg.Listen
Msg.Receive
Msg.Send
Msg.Session.Status

Read
recv
select
semdmsg
send

Sendto
setsocket
shutdown
socket


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
1980s);
• 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
‘releases’.
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.
19
20

See Chapter 10.
See Chapter 11.

116

Basic data networks and protocols

Session (layer 5) and transport layer (layer 4) addresses
Before we leave the subject of the session layer, we should briefly explain the two terms:
session target and socket number. The session target (a term being increasingly used) is the
(layer 5) destination ‘address’ of a session in its initiation phase (it is a logical username
or equivalent). The socket address, meanwhile, is a layer 4 (transport layer) address, usually
quoted as a combination of the IP network address (layer 3) and the TCP port number
(layer 4).

Presentation layer
The presentation layer (layer 6) is concerned with the format 21 and syntax of data communicated between applications. Since most computers uses ASCII format for the coding of basic
characters, presentation conversion does not have to be carried out at this level. On the other
hand, software commands and datafile formats can vary widely, and need to be standardised or
converted for the purpose of open communication. Control codes, special graphics, graphical
user interfaces, browsers and character sets work in this layer. The different applications and
associated datafile (presentation) formats which serve them are the domain of object-oriented
programming.
Typical examples of presentation layer related services and formats are:
• Graphical user interface (GUI) — a presentation format conversion which typically converts communicated characters into ‘graphics’ — typically screen ‘windows’ or browsers;
• XDR (eXternal data representation — RFCs 1014 and 1832) is a language used to describe
different data formats. It was developed by Sun Microsystems to facilitate the interchange
of files between different types of computer;
• ASN.1 (abstract syntax notation 1) — is an ITU-T and ISO-defined language somewhat
similar to XDR — and also used to describe different data formats. ASN.1 and the SMI
(structure of management information) subsets of it, have become one of the standard
means of defining application layer protocols, as we shall discover in Chapters 9 and 10;
• html (hypertext markup language — RFC 1866) — provides a character set (ISO 8859)
and a method of punctuating text with html tags. The tags indicate how the text is to
be presented to the human user receiving the file (e.g., bold, italics, background colour,
blinking, position, size, etc.). html also provides for the possibility of hyperlinking text.22
• MIME (multipurpose Internet mail extensions) — a standard format for including non-text
information in Internet email which enables the attachment of multimedia data files;
• Network virtual terminal (NVT) — this is a process and format makes remote terminals
with different characteristics (e.g., a PC, an appleMac, a ‘dumb terminal’, etc.) all appear
the same to a server or host computer;
• PostScript — a widely used ‘print’ file format used to send data to computer printers;
• Server message block (SMB) and the similar CIFS (common Internet file system) — provides
a standard control block structure for server communications in Microsoft Networks,
including, among other things, file and printer management and queuing. SMB was the
original version, CIFS is the name of the latest version;
21
22

See Chapter 2.
See Chapter 11.

Protocol stacks and nested protocol control information (PCI)

117

• Connection-oriented presentation service (COPS) and protocol (ISO 8823 and ITU-recommendations X.216 and X.226).

Application layer
Application layer (layer 7) protocols perform input and output routines (or sub-programs) on
behalf of more complicated end-user application programmes. Invoking an application layer
protocol is typically done using modern object-oriented computer commands and file structures
that C, C++ and JAVA programmers are familiar with. Typical examples of application layer
services and protocols are:
• Berkeley remote commands (UNIX);
• FTAM (file transfer, access and management) — the OSI protocol suite for transferring
files between computers;
• FTP (file transfer protocol);
• HTTP (hypertext transfer protocol);
• NFS (network file system) — developed by Sun Microsystems for networked sharing of
files between UNIX computers and servers;
• POP3 (post office protocol) and SMTP (simple mail transfer protocol) — widely used by
modern email systems;
• Telnet (remote log-in protocol);
• X.400 or message handling service (MHS) — the OSI version of email service.

3.7 Protocol stacks and nested protocol control information (PCI)
Modern telecommunications protocols, as we have seen, are designed as layered peer-to-peer
protocols. Each layer performs a separate distinct function which is coordinated by the peer
partners (the two protocol handlers which deal with the particular function or layer at the two
ends of the connection). Each layer adds its own protocol control information (PCI) to the
original user data. PCI identifies the address, socket or target of the peer partner and allows
for such functions as sequence numbering, data flow control, error correction, port or logical
channel identification, information regarding the data format, and so on.
In reality, the communication starts at the application layer of the sender. The user data
(i.e., the user message or data) is packed into the user data field of the application layer frame.
In the jargon, the user data field is called the application SDU (service data unit). The SDU is
passed to the application layer to make use of the application service. The point of handover
is called the service access point (SAP) of the application layer. Protocols identify the SAP
with some kind of address. The address is called the SAPI (service access point identifier).
In order to invoke the application service at the application SAP (Figure 3.29) a number
of commands have to be issued, to tell the application layer protocol exactly what it has to do.
These commands are part of the protocol and are called primitives. Once the application SDU
has been received, the application layer adds the application layer protocol control information
(PCI) — as if it were ‘talking’ directly to the application layer protocol handler in the receiver
(i.e., in peer-to-peer communication). The combination of the user data (the application layer
SDU) and the application layer PCI (added as headers and trailers) is an application layer
frame, but also called the application layer protocol data unit (PDU).

118

Basic data networks and protocols

Though the sending application layer has the impression it is talking directly peer-to-peer
with the application layer at the receiver, in reality, the application layer PDU has to be
processed by all the other protocol layers. Under a new name (presentation layer SDU ), the
(unchanged) application layer PDU is passed to the presentation layer at the presentation-SAP,
using presentation layer primitives as appropriate — to ‘order’ the correct presentation service.
The entire application layer frame becomes the ‘user data’ as far as the presentation layer
is concerned, and to it are added the headers and trailers of the presentation layer protocol
control information (PCI) to form the presentation layer PDU.
In turn, the presentation layer PDU becomes the session layer SDU; passed over at the
session layer SAP, using the session layer primitives. And so on. Incidentally, the transport
layer SAPI is the port number or socket number we talked of earlier, while the network layer
SAPI is the network address and the datalink layer SAPI is the MAC-address.
The actual frame transmitted over the physical medium (the end result of all the individual
layer protocol activities) thus has a structure which appears like a set of ‘nested’ frames,
the layer 7 frame is the user information of layer 6. The layer 6 frame is the user information
of layer 5, and so on, with the frame itself finally delimited by the layer 2 (datalink) frame
and flags (Figure 3.28).
The headers and trailers comprising the protocol control information (PCI) of each protocol
layer are stripped from the received message by the corresponding protocol handler (the peer
partner) in the distant end device, and the user data field information (i.e., the remainder of
the message) is passed to the next higher protocol layer, and finally to the ‘end-user’. In other
words, the actual communication is first down the protocol stack of the sender and then up
the protocol stack at the receiver (Figure 3.29), though each individual protocol layer believes
itself to be in direct peer-to-peer communication with its remote peer partner.
If you consider the actual data frame sent over the medium, it comprises a flag, followed by
a large number of PCI fields (for all the various layers), the user data and then all the various
further PCI fields in the trailer. This is when you really begin to question whether all the
different fields are necessary (must I really send multiple sequence numbers?). The more PCI

Note: An FCS (frame check sequence) is not always used at each of the protocol layers. Whether one
is used depends upon the design of the protocol—and in particular upon the reliability of the network
for which the protocol is intended. In addition, the terminology FCS (frame check sequence) is not used
by all protocols. The IP-suite of protocols, as we will discover later has a checksum file instead (see
Chapter5). The checksum algorithm used is much simpler than the FCS of HDLC (higher level data link
control), which we presented earlier in this chapter.

Figure 3.28 ‘Nested’ frame formats of layer protocols.

Protocol encapsulation

119

Figure 3.29 Processing and transfer of user data by layered protocols.

fields I can do without, the lower is the total overhead — and the more efficient is my usage of
the network capacity. Unsurprisingly, the relative efficiency of different alternative protocol
suites is a hotly and continuously debated subject. And protocol designers are continually
developing protocols as the needs of the users change and the reliability of networks improve.
In my experience, different protocols designed for similar purposes are rarely significantly
more or less efficient than their competitors, as their designers would like to have us believe.
Quite simply, they have to add similar amounts of overhead to carry out the required functions,
even if the functions are performed slightly differently. As the Germans would say: ‘We can
all only cook with water’, i.e., you can’t break the laws of physics!

3.8 Real networks and protocol stack representations
It is often helpful, in attempting to understand protocols and their relationships with one
another to illustrate the protocol stacks of the various devices. Books about data communications and protocols are littered with protocol stacks (as indeed this one is). A diagram
of the protocol stack helps to clarify the roles played by different pieces of networking and
computer hardware and software. Figure 3.30, for example, illustrates a typical office LAN
(local area network), comprised of end-user devices, structured cabling, a LAN hub and a
bridge or router. Note how the end-user PC of Figure 3.30 takes part in all the protocol layers
(including layers 4–7 which are not illustrated). The LAN devices (the hub, LAN switch and
bridge), meanwhile, only have functionality corresponding to layers 1 and 2 at most (the LAN
medium and datalink layer protocol, LLC — logical link control.

3.9 Protocol encapsulation
When new protocols are devised, it is often useful to be able to use older (so-called legacy)
networks to transport them, or conversely, to be able to carry the old protocols across the new
network. A ‘quick-and-dirty’ method of achieving this is by means of protocol encapsulation.
In purist terms, protocol encapsulation relies on ‘cheating’ — taking the PDU (protocol data
unit — i.e., the complete frame including real user data as well as headers and trailers) of a

120

Basic data networks and protocols

Figure 3.30 A typical office data network and its protocol stack representation.

low level protocol and transmitting it across another network by pretending it is ‘user data’
of a higher level protocol of the second protocol suite.
By using protocol encapsulation you could mimic a simple layer 2 datalink between two
devices, even if the actual communication takes place across an IP-based router network.
How? By delivering the layer 2 frame of the datalink to the transport layer of the TCP/IP
network as if it were ‘user data’.
Protocol encapsulation (also called tunnelling 23 ) often proves a useful way of interconnecting and integrating networks of different vintages and originally meant for different purposes.
It is useful to remember that, however many protocol layers are placed ‘underneath’ the
encapsulated protocol, the resulting protocol service will remain the same. For example,
PPPoE — PPP over ethernet — provides for a datalink layer service — PPP (point-to-point
protocol) service, but carried over an ethernet LAN. Similarly, encapsulating a datalink protocol (layer 2) into a layer 4 protocol (such as TCP/IP) will leave the end-to-end service
unchanged — as a layer 2 service.
Be careful when using protocol encapsulation! Protocols which have been encapsulated
do not always behave quite the way they would when left to themselves. The extra delays
caused by the encapsulation and the transport can lead to serious problems, if not with the
encapsulated protocol itself, then with the application which is being run across it.

3.10 Control and management protocols
When I think back to my first encounters with layered protocols and my attempts to understand
multiprotocol networks, I can recall a series of long mental struggles: trying to relate the
different protocols onto the 7-layer OSI model and trying to figure out the roles of individual
23

See Chapter 13.

Control and management protocols

121

protocols in coordinating the overall activities of the network. One of my biggest breakthroughs
was to realise that many of the protocols used in networks are not intended to carry messages
between the A-party and B-party of a connection, but instead for control and management of
the network itself.
Figure 3.31 illustrates a protocol reference model (PRM) developed by ITU-T to illustrate
how different protocol stacks on the user plane (u-plane), the control plane (c-plane) and
the management plane (m-plane) combine with one another. So far in this chapter, we have
concerned ourselves mainly with the protocols used on the user plane. These are the protocols
used directly in the transfer of user data from end-user DTE to another.
The control plane is used to describe protocols which communicate information from an
end-user DTE to the (control part) of a node, or between nodes within the network — for the
purpose of conveying information needed for establishing, controlling and clearing connections
(Figure 3.31a).
Management plane protocols, meanwhile, are used only within the network itself. They
might carry status information regarding network or end-user equipment performance to a
human operator at a network management centre. Alternatively, they may be used to deliver
controls and commands as required to reconfigure the network. Management plane protocols
are used, among other things, to allow nodes in a network to mutually update one another’s
routing tables. Routing protocols (as we will discuss in Chapter 6) come in this category.
It is important to recognise that entirely different protocol stacks may be used for the
different user plane, control plane and management plane functions (Figure 3.31), though
usually the same lower layers (layers 1–3) are used (e.g., IP and ethernet or HDLC).
For a user plane application, the two end-points of the communication are the A-end
and B-end of the connection. For a control plane application, the communication end-points
are the control part of a DTE and at the control part of a network node. Sometimes the

Figure 3.31

Protocol reference model: user, control and management planes [Figure 3.31b reproduced
courtesy of ITU].

122

Basic data networks and protocols

control protocol procedure is referred to as signalling. Between the DTE and node control
points (or signalling points), a second connection may exist (over and above that used for
the A-to-B user plane connection). The control plane connections are often dedicated virtual
channels with pre-determined logical channel numbers (sometimes called signalling virtual
channels). Similarly, pre-configured virtual channels may be used for different pre-determined
management plane activities.
Unfortunately many books, and especially marketing brochures do not refer to the protocol
stacks of different network functions accurately and compare protocols of different layers and
functions, and even on different planes with one another. This confused me for a long time,
and I have therefore tried hard in this chapter to navigate you around the main pitfalls. I hope
I have succeeded, for a thorough understanding of the basics of layered protocols will make
the rest of the book (and networking life as a whole) much easier to follow and understand.

3.11 Propagation effects affecting protocol choice and network design
and operation
It might seem an obvious statement to make, but not all protocols are the same and not all
protocols are equally well suited for a particular purpose or application. Obvious, but often
forgotten, ignored or simply unknown! If a computer program or application is to run well,
then the programmer should consider precisely how the protocols he or she selects operate.
Similarly, network equipment designers need to consider the specific needs of each protocol
and how they are to interact with one another. Unfortunately, too many programmers spend
too little effort here, with the result that many applications run much slower than they need
to. It’s not always the case that the network is overloaded: far too often the application itself
is poorly designed or is expecting too much from the network. The best solution to a slow
application is not always simply to upgrade the network bandwidth or bit rate!
We discussed the effect on protocol delays of the indiscriminate use of data acknowledgement on a datalink we discussed in Figure 2.27 of Chapter 2. Here, we shall consider similar
propagation delay problems and constraints as arise from packet buffering, error correction
and relaying between multiple links and nodes of a network path.
Figure 3.32 illustrates how the number of ‘hops’ in a connection (the hop count) has a
significant impact on the end-to-end propagation delay across the communications path [even

Figure 3.32 Propagation delays in a multiple hop link.

Propagation effects affecting protocol choice and network design and operation

123

before considering the additional ‘processing time’ required by the nodes themselves]. Each
packet (or frame) must be fully buffered at each intermediate station before it can be forwarded;
and the packet length governs the period of time required to ‘read’ the entire packet into the
buffer (this is the time which expires between the receipt of the first and last bits of the
packet). Including the ‘reaction and handling time’ of each of the intermediate and end-nodes,
the overall delay between the ‘first bit sent’ and the ‘last bit received’ (assuming that all the
links have the same bit rate) is something like:

End-to-end propagation delay = Tp + (h + 1)tN + h(Lp /B) + Q
Where: B = line bit rate in bit/s
h = hop count
Lp = packet length in bits (including protocol control information)
Q = sum of intermediate node queueing delays
tN = node reaction and packet handling delay
Tp = minimum theoretical propagation delay = connection length/speed of propagation

The end-to-end propagation delay is thus very sensitive to the packet length and to the hop
count, as well as to the bit rate of the line! Merely upgrading the bit rate on one of the links
along the route will not have much effect, unless that link is overloaded — in other words,
is adding significantly to the overall queueing delay, (the queueing is that caused by packets
having to wait in a queue at intermediate nodes for use of the outgoing line).
Perhaps we could save some of the delay at the intermediate nodes by forwarding each
bit immediately as it arrives (i.e., the first bit is sent on before the last bit arrives)? Some
hardware designs and specific protocols do offer scope for tricks like this, but in many cases
two constraints prevent simultaneous onward relaying:
• the need to set and check the error correction code (frame check sequence);
• the different bit rates of lines entering and leaving intermediate nodes (if the outgoing line
is faster than the incoming line there is a problem, because the outgoing line expects to
send bits faster than it is receiving them).

This page intentionally left blank

4
Local Area Networks (LANs)
LANs emerged in the late 1980s as the most important means of conveying data
between different computers and computer peripheral devices (printer, file server,
electronic mail server, fax gateway, host gateway, computer printer, scanner, etc.)
within a single office, office building, or small campus. They were originally designed
as shared media (layer 2 or datalink communications media) and are ideally suited
for relatively short distance, high speed data transport and have thus become the
foundation for modern ‘electronic offices’ — interconnecting workstations, word processors, shared printers, file servers, email systems, web servers and so on. We shall
explain the various types of LAN and explain how they work but we shall primarily
be concerned with the ethernet LAN in its various forms — 10baseT, 100baseT (fast
ethernet) and Gigabit ethernet, for this has become the predominant standard for PC
and server-based networking.

4.1 The different LAN topologies and standards
The different types of LAN may be characterised by their distinctive topologies, but all comprise a single shared medium transmission path interconnecting all the data terminal devices,
together with appropriate protocols (called the logical link control and the medium access
control (MAC)) to enable data transfer. The three most common LAN topologies are the star,
ring and bus topologies. These are illustrated in Figure 4.1.
The original IEEE 802.3 (ISO 8802.3) standard defines a physical layer protocol called
CSMA/CD (carrier sense multiple access with collision detection) which is usually used with
a bus topology and referred to as ethernet. IEEE 802.4 (ISO 8802.4) defines an alternative
physical layer (layer-1) protocol for a token bus, but is also suitable for a star topology.
IEEE 802.5 defines a layer 1 protocol suitable for use on a token ring topology. Meanwhile,
IEEE 802.2 (ISO 8802.2) defines the logical link control (LLC) protocol (equivalent to the
layer 2 or datalink layer) which is used with any of the above physical layer protocols. LLC
provides for the transfer of information in the form of data frames between any two devices
connected to the LAN. The information to be transported (i.e., information frame or packet)
is submitted to the logical link control (LLC) layer together with the address of the device to
which it is to be transmitted. Much like HDLC1 (from which it was developed), LLC assures
successful transfer, error detection, retransmit etc. Figure 4.2 shows the various protocols and
their relationship to the layers of the OSI model. The main difference between the different
1

See Chapter 3.

Data Networks, IP and the Internet: Protocols, Design and Operation
 2003 John Wiley & Sons, Ltd ISBN: 0-470-84856-1

Martin P. Clark