Tải bản đầy đủ
16 The problem of long lines—the need to observe the maximum line length

16 The problem of long lines—the need to observe the maximum line length

Tải bản đầy đủ

The problem of long lines — the need to observe the maximum line length


Figure 2.26 Parallel and serial transmission.

have also how protocols are necessary to set out an etiquette of communication. But before
we go on to discuss how the protocols themselves work, it is worth considering the ‘physical’
constraints which protocol developers are up against: what they must consider and incorporate
in their protocol designs. In particular, it is important to recognise the influence of the line
length. The best way of conducting the communication, and thus the best type of protocol to
use, depends greatly upon the line length.
For many data networks and protocols a maximum line length, bit rate and other parameters
are specified (or is not specified, but is nonetheless implicit in the design of the protocol!). It
is important to be aware of these limitations when using the particular type of interface, line
or protocol. Here’s why.

Attenuation and distortion
One of the problems of long lines is the degradation caused by attenuation and distortion,
and this largely determines the maximum allowed line and link lengths possible in a given
network and using a given protocol. But in addition to attenuation and distortion, there are
some far less obvious problems which also limit line length. These are caused by the ‘storage
medium’ and ‘transient’ effects of a long line, as we shall see next.

The effect of propagation delays on how protocols function
The electrical pulses which represent the individual bits in a data signal typically travel across
a network at a speed of around 10 million metres per second (108 m/s). This is around one
third of the speed of light. The delay (as compared to the speed of light) is caused by the
various buffers and electronic components along the way. If we assume quite a modest bit


Fundamentals of data communication and packet switching

rate of 2 Mbit/s (2 × 106 bit/s) is used to convey a signal along a given transmission line, we
can actually work out the length of each pulse!
Bit length = [speed in m/s]/[bit rate] = 108 /(2 × 106 ) = 50 m
The first time I contemplated the length of a bit in metres, I was surprised by the result. After
all, one tends to assume when considering electrical circuits that the transmission is instant:
‘the light goes on as I flick the switch!’ But this is far from true when we are dealing with
high speed communication lines! If our 2 Mbit/s line above is 1000 km long (quite possible
within a nationwide network, never mind an international connection!), then there are actually
20 000 bits (or 2500 bytes) in transit on the line at any one time [1000 000 m/50 m]. Say
‘stop’ and you’ll still receive at least all the 20 000 bits already on their way! Actually many
more: because the ‘stop’ message will take some time to get to the receiver (this message
is itself in a queue of at least 20 000 bits heading in the other direction). 20 000 bits will be
received before the ‘stop’ message is acted upon by the transmitter, by which time a further
20 000 bits are already on their way. So after saying ‘stop’ be prepared to receive a further
40 000 bits (5000 bytes).
For the 5000 bytes you need a buffer unless of course this data is simply thrown away! But
throw the data away at your peril! For if you throw it all away, you’ll have to ask for it to be
sent again, once you’re ready to receive it. That will mean another 5000 bytes (of ‘idle line
information’) for the dustbin — wasted while the message requesting the retransmission gets
through to the other end. Plus, of course, the 5000 bytes will have to be sent again. That’s
10 000 bytes of information we didn’t need to send over the line! We’ll have to be careful
about all this waste, if the maximum capacity of the line is to be used efficiently!
A similar flow control problem to that discussed above is illustrated as a signal flow diagram
in Figure 2.27. Protocol interchanges are frequently illustrated in this manner, so it is worth
becoming familiar with how to read the chart. The left-hand vertical line represents the ‘A-end’
of a point-to-point connection, the right hand vertical line the ‘B-end’. The top of each line
represents the beginning of the illustrated time period, and the ‘time axis’ progresses towards
the bottom of the page. The diagonal lines represent individual bits sent from one end of the
line to the other. (The bits progress along the line from one side of the diagram to the other,
while time elapses down the page — hence the diagonal line.)
At the beginning of the time period shown, a ‘request’ signal is generated at the A-end of
the line, to request data to be returned by the B-end. Since the request message is more than
one bit long, a certain amount of time expires (shown as TR on the diagram) to transmit all of
the message onto the line. Once on the line, the message propagates along the line towards the
B-end (represented by the diagonal lines for the ‘first’ and ‘last’ bits of the request message).
After a period TP (called the propagation time), the first bit of the request reaches the B-end.
The final bit of the request arrives a short time, TR , later. Now the message can be interpreted
by the B-end computer. We assume in Figure 2.27 that it reacts instantaneously and starts to
send the first packet of the requested data. (Normally a further processing delay would be
encountered here.)
Further diagonal lines represent the first and last bits of the returned data packet as they
make their way back to the A-end. After a total elapsed time TC the first packet of data has
completely arrived at A.
The protocol shown in Figure 2.27 requires that the A-end acknowledges receipt of the first
packet of data before the B-end is allowed to send the second packet. The acknowledgement
of the first packet and the transmission of the second packet is shown in the diagram.
Now let us consider the relative efficiency of our usage of the line. The total duration of a
‘cycle’ of sending a request (or acknowledgement) and receiving a packet of data is TC , where:
TC = (TP + TR ) + (TP + TD ) = 2 TP + TR + TD

The problem of long lines — the need to observe the maximum line length


Figure 2.27 A protocol signal flow diagram.

The proportion of the time for which the two communication paths (A-to-B and B-to-A) are
in use reflects the efficiency of usage of each:
Usage efficiency (A-to-B) = TR /TC = TR /(2 TP + TR + TD )
Usage efficiency (B-to-A) = TD /TC = TD /(2 TP + TR + TD )
Let us assume that we keep our request message very short; we assume it can be transmitted
onto the line instantly (e.g., because of a very high line bit rate). Then we set TR = 0. This
is usually a reasonable assumption. Now, when the line is very short we can also ignore the
time required for an individual bit to propagate along the line, by setting TP = 0. In this case,
we discover that:
For very short lines:
Usage efficiency (A-to-B: request direction) = 0%
Usage efficiency (B-to-A: data direction) = 100%
No surprises here perhaps. Data is being downloaded nearly all the time (100% line usage
B-to-A), and our acknowledgements are a help in making sure that the A-end is always ready
to receive the next packet. All hunky dory! But look at what happens when the propagation
time TP becomes significant. In particular, let us return to our previous example of a 1000 km
line of 2 Mbit/s bit rate, and assume packet lengths of 256 bytes (2048 bits). In this case TP =
106 m/[108 m/s] = 0.01 s and TD = 2048 bits/2 000 000 bits/s = 0.001 s. And what are the
line usage efficiencies?
Example long line of 1000 km and 256 byte packet size:
Usage efficiency (A-to-B: request direction) = 0%
Usage efficiency (B-to-A: data direction) = 4.8%


Fundamentals of data communication and packet switching

What? 4.8% line usage efficiency! A shock perhaps? Let it be a warning to all communications
programmers and protocol designers! Acknowledgements used with short packet sizes can lead
to very low line utilisation on long, high bit rate lines!

The effect of delays on ‘collision’ protocols
In some shared medium networks (e.g., radio networks and ethernet LAN networks), users
are allowed to transmit signals onto the medium provided they first check that the medium is
free (i.e., idle). In such networks, the protocol has to be able to deal with collisions of packets
sent by different sources.
Because of the propagation delay incurred by the signal sent by a first transmitter, a second
remote device may start transmitting on the already ‘busy’ line, unaware that the transmission
of the first device has not yet reached it. The danger is in the length of the line! The longer the
line, or the greater the size of the shared medium network (e.g., LAN — local area network),
so the greater the chance of a collision. The more collisions that occur, the less efficient is the
use of the medium.
If the network is too big, the bit rate is too high (making the pulses too short) or the line
is too long for the protocol in use, then the efficiency of the network may drop dramatically!
MORAL: Know the limitations of the network and protocols in use.

Basic Data Networks
and Protocols
Modern data communications networks are built up in a ‘modular’ fashion — using
standardised network components, interfaces and protocols based on digital line
transmission, packet switching and layered communications protocols. In this chapter we present the basic components of a data network, and explain in detail the
‘networking’ or lower-layer protocols (protocol layers 1–3) which make them work.
We shall explain physical and electrical interfaces and connectors, as well as physical, datalink, network, transport and higher-layer protocols: everything that goes to
ensure efficient propagation across a network. Complex though it may seem, these
are only the network basics!

3.1 The basic components of a data network
The basic components of a data network are illustrated in Figure 3.1. A personal computer
(PC) and a mainframe computer — both examples of DTE (data terminal equipment) — are
connected to the network (shown as a ‘cloud’) by means of DCE (data circuit-terminating
equipment). The DCE is a device which provides the ‘starting point of the long-distance
network’ and is a device installed either near to the DTE, or sometimes is incorporated into it.
The network of Figure 3.1 (providing the connection between the DCEs) comprises a meshed
network of 4 nodes.1
The devices (DTEs, DCEs and nodes) in Figure 3.1 are interconnected by means of standardised communications interfaces, and every possible physical, electrical and protocol aspect
of the interconnection is precisely defined.
There are different classes of general interfaces describing different types of connections,
as we learned in Chapter 1. User-network interfaces (UNIs) are used to connect end devices
(DTEs) to the network and are generally ‘asymmetric’ — the balance of control of the interface
being with the network. Network-node interfaces (NNIs), meanwhile, are more ‘symmetric’
arrangements intended to be used to interconnect nodes of equal importance in the main
backbone part of the network.
Both UNI and NNI specifications define in precise detail the physical and electrical aspects
of the interconnection, as well as the lower-layer or networking protocols (layers 1–3 of
A node is any kind of switch-type device, upon which numerous communications links and other connections
converge. A node might technically be a switch, a router, a LAN hub, a multiplexor or some other kind of
exchange. In this example, as often, the exact technical nature of the node does not concern us.

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

Martin P. Clark


Basic data networks and protocols

Figure 3.1

Figure 3.2

The components and interfaces making up a simple data network.

The protocol layers of the OSI (Open Systems Interconnection) model.

Figure 3.2) which must be used at the interfaces. It is the detailed functions of these layers
(layer 1 — physical layer; layer 2 — datalink layer and layer 3 — network layer) which will
be the main subject of discussion in this chapter. We start with an overview of the various
layer roles, before we go on later to review the details.

Physical layer (layer 1)
The physical layer (layer 1) interface and protocol specification define how the physical
medium (e.g. the copper cable, optical fibre or radio channel) is to be used to transport
the bitstream which comprises a digital signal: the precise shape and electrical or optical
characteristics of the signal, the bit rate and clocking, as well as the physical connectors to
be used.
Different physical layer specifications correspond to different physical media and modulation or line coding schemes. Thus one physical layer specification might cover the use of a
twisted-pair copper cable to carry a signal of a given bit rate, while another physical layer
specification may define the use of light pulses of a given laser light wavelength — to be sent
over an optical fibre medium.

The basic components of a data network


While one physical layer (i.e., the medium and its related modulation, control and line
coding — the protocol ) may be used as an alternative for another, media and protocols within
the physical layer are not interchangeable. Thus, for example, it may be possible to use either
a twisted-pair line or a fibre-optic-based communications system to carry a given signal, but
it is ludicrous to consider using an optical transmitter and detector (intended for use with a
fibre cable) in conjunction with a copper cable!
The physical layer interface usually provides for a simple point-to-point connection or
link between two end-points. Alternatively, the physical layer of a shared medium (e.g.,
radio) provides for the ‘broadcast’ of a signal from any of a number of devices sharing the
communications medium to all of the others. In the case of a shared medium, all but the
intended recipient(s) will ignore the transmission. The most common shared medium systems
used for data communications are LANs (local area networks) and wireless data networks.
Physical layer interfaces specifically designed for long-distance lines or NNIs (networknode interfaces) are usually designed for long-distance, permanently established point-to-point
links. Such line interfaces use a minimum number of cable leads for the connection.
Each link of an end-to-end connection across a network may use a different physical
medium and thus a different physical layer. Thus, for example, the path across the network
from DTE-to-DTE in Figure 3.1 (a minimum of five links) might traverse different fibre,
copper and radio communications media along the way. Each node will perform the necessary
physical layer adaptations and signal conversions to achieve this.
In the case of physical layer interfaces intended for use as UNIs (user-network interfaces),
the role of a special ‘network terminating’ or ‘adaption’ device is defined: the DCE — datacircuit terminating equipment. As we shall learn, the DCE undertakes a physical layer conversion of the short-range communications port capabilities of the DTE into a line interface
format suitable for long-distance communication. The role of the DCE is to do the following:
• convert the physical interface emanating from the DTE (data terminal equipment) into a line
interface format suitable for long-distance transmission, and provide for digital/analogue
signal conversion if necessary;
• provide for network termination, being a source of power for the line and network
as necessary;
• forward data received from the DTE to the network;
• deliver data received from the network to the DTE;
• clock and bit-synchronise 2 the data transmission of the DTE during the data transfer phase;
• set up the physical connection forming the medium and clear it as required and/or requested
by the DTE (This may be necessary where the physical link is actually a dial-up connection
across a telephone network, or a temporary radio path).

Datalink layer (layer 2)
The datalink layer and datalink protocol are concerned with the formatting of the ‘raw’ stream
of bits carried across a link by the physical layer into a byte-synchronised and structured form
recognisable as blocks or frames of data. Apart from this, the datalink layer is also concerned
with data flow control. The sending and receiving devices at either end of the physical link
need to be coordinated to make sure that they ‘listen’ when ‘spoken to’ and only ‘speak’ when
it is ‘their turn’. A frame check sequence (FCS) may be applied by the datalink protocol in

See Chapter 2.


Basic data networks and protocols

the case where the physical medium is likely to be prone to a high level of bit errors. We
discussed all this in Chapter 2.
Together, a datalink layer protocol, a physical medium and a physical layer protocol are all
that is needed for point-to-point transport of blocks or frames of data. A network layer (layer
3) protocol only becomes necessary when a network (i.e., a meshed topology of numerous
links) needs to be traversed.
While various different physical layer media and protocols may be used with any given
datalink layer, not all datalink protocols are suitable for all physical media and physical
protocols. MORAL: you can mix and match to some degree — but not all combinations of
physical layer (layer 1) and datalink layer (layer 2) protocols are viable!

Network layer (layer 3)
The network layer (layer 3) protocol is used to combine a number of separate individual
datalinks into a ‘chain’ — thereby forming a complete path across a network comprising
multiple nodes (as, for example, in Figure 3.1).
The network protocol is concerned with packets and packet switching. As we learned in
chapters 1 and 2, packets of data are analogous to the parcels and letters of a postal service.
The frames of data carried by the datalink layer (layer 2), meanwhile, are analogous to the
postal delivery vans which run from one postal depot or sorting office to the next. In just
the same way in which postal delivery vans are loaded before a ‘run’ from one depot to the
next, and then completely emptied and ‘re-sorted’ before packing into another van for the next
‘leg’ of the journey, so the frames of the datalink layer are filled and emptied of their packet
contents before and after each datalink of the path through the network. The frames of the
datalink protocol only carry the data for a single leg of its journey. The packets of the network
protocol, on the other hand, are transferred from one end of the complete path to the other.
Network layer protocols have a number of responsibilities to fulfil:
• identification of destination network address;
• routing or switching of packets through the individual network nodes and links to the
• statistical multiplexing of the data supplied by different users for carriage across the network;
• end-to-end data flow control: the flow control conducted by layer 2 protocols only ensure
that the receiving data buffers on each individual link can receive more data. The layer 3
protocol has the more onerous task of trying to ensure a smooth flow of data across all
the datalinks or subnetworks taken together. Uneven ‘hold-ups’ along the route need to
be avoided;
• correct re-sequencing of packets (should they get out of order having travelled different
routes on their way to the destination);
• error correction or transmission re-request on a network end-to-end basis.
Now, let’s get down to details.

3.2 Layer 1 — physical layer interface: DTE/DCE, line interfaces
and protocols
The physical layer interface defines the manner in which the particular medium (e.g., twisted
pair cable, coaxial cable, fibre line or radio link) should be coded to carry the basic digital

Layer 1 — physical layer interface: DTE/DCE, line interfaces and protocols


information. At a minimum, the physical interface specification needs to define the precise
nature of the medium (e.g., wire grade, impedance etc); the exact electrical (or equivalent)
signals which are to be used on the line and the details of the line code which shall be used for
bit synchronisation as discussed in Chapter 2. Many modern physical interface specifications
also stipulate the precise mechanical connectors (i.e., plugs and sockets) which should be
used for the interface, but this is not always defined. As well as the basic electrical (radio
or optical) interface, the physical layer specification defines control procedures (the physical
layer protocol ) which allows one or both of the devices at either end of the line (i.e., the
physical medium) to control the line itself.
There are three main types of physical interface to be distinguished from one another:
• DTE-to-DCE interfaces. These are the asymmetric point-to-point user-network interfaces
(UNIs) used typically to connect end devices (e.g., computers) to modems, line terminating
units (LTU), channel service units (CSU), data service units (DSUs), network terminating
units (NT or NTU). All the latter are examples of data circuit terminating equipment (DCE);
• Line interfaces or trunk interfaces (symmetrical point-to-point line interfaces) — most
NNIs and some UNIs are of this type;
• Shared medium interfaces (point-to-multipoint interfaces) — usually used as UNIs. [The
most commonly used shared media are local area networks (LANs). LANS are widely
used to connect end-users PCs to internal office data networks].
In general terms, the UNI (user-network interface) always employs a DTE-to-DCE type
interface, while trunk interfaces tend to use symmetrical, higher bit rate NNI (networknode interface).
Figure 3.3 shows a network in which three routers and two DTEs are interconnected. Both
DTEs are connected to the network by means of DTE/DCE interfaces. Routers C and B are
also connected to the line which interconnects them by means of DTE/DCE (e.g., V.24 or
RS-232) interfaces. Routers A & B and A & C, meanwhile, are interconnected by means of
direct trunk interfaces (DCE/DCE3 ). In these cases, the DCE function is included within the
router itself.

Figure 3.3 DTE/DCE Interface and Trunk or line interface.

The ‘DCE/DCE interface’: tempting as it may be, it is not correct to call the long-distance connection between
DCEs a ‘DCE/DCE interface’. Instead, one should refer to the line interface or network interface. The term
‘DCE/DCE interface’ is reserved for the case in which the UNI interface (normally used to connect a DTE to
a DCE) is used to connect a second DCE instead. A cross-cable is used for this purpose, as we discover in
Figure 3.8b.