Tài liệu Mạng và viễn thông P18 ppt

PART
3
MODERN DATA
NETWORKS
Networks and Telecommunications: Design and Operation, Second Edition.
Martin P. Clark
Copyright © 1991, 1997 John Wiley & Sons Ltd
ISBNs: 0-471-97346-7 (Hardback); 0-470-84158-3 (Electronic)
Packet Switching
Packet switching emerged in the
1970s
as an efficient means of data conveyance. It overcame the
inability of circuit-switched (telephone) networks
to
provide efficiently for variable bandwidth
connections for bursty-type usage as required between computers, terminals and storage devices.
In
this chapter we discuss the basics of packet switching and
ITU-T’s
X.25
recommendation,
nowadays the worldwide technical standard interface to packet-switched networks.
We
then also
go on to discuss the
IBM
company’s SNA (systems network architecture), a proprietary form
of
packet switching, important because of its dominant role in
IBM
computer networks.

18.1
PACKET SWITCHING BASICS
Packet switching
is so-called because the user’s overall message is broken up into a
number of smaller packets, each of which is sent separately. We illustrated the concept
in Figure
1.10
of Chapter
1.
Each packet of data is labelled
to
identify its intended
destination, and
protocol control information (PCZ)
is added, as we saw in Chapter
9,
before it is sent. The receiving end re-assembles the packets in their proper order, with
the aid of
sequence numbers
and the other PC1 fields. Each packet is carried across
the network in a
store-and-forward
fashion, taking the most efficient route available at
the time.
Packet switching is a form of
statistical
multiplexing, as we discovered in Chapter
9.
Figure
18.1

illustrates how a link within a packet switching network is used to carry the
jumbled-up packets of various different messages and the use of the information carried
in the packet
header
to sort arriving packets at the destination end into the separate
logical channels, virtual circuits
(
VCs)
or
virtual calls
(VCs).
Transmission capacity between pairs of nodes in a packet-switched network is
generally not split up into rigidly separate physical channels, each of a fixed bandwidth.
Instead, the entire available bandwidth between two nodal points (switches) in the
network is bundled together as a single high bitrate pipe, and all packets to be sent
between the two endpoints of the link share the same pipe (Figure
18.1).
In this way, the
entire bandwidth (i.e. full bitspeed) can be used momentarily by any of the
logical
channels
sharing the connection. This means that individual packets are transported
more quickly and bursts of transmission can be accommodated.
341
Networks and Telecommunications: Design and Operation, Second Edition.
Martin P. Clark
Copyright © 1991, 1997 John Wiley & Sons Ltd
ISBNs: 0-471-97346-7 (Hardback); 0-470-84158-3 (Electronic)
342
PACKET

SWITCHING
n
packet
may
mm
switch
U
Figure
18.1
The statistical multiplexing principle of packet switching
A
problem arises when more than one or all
logical channels
try to send packets at
once. This is accommodated by
buffers
at sending and receiving ends of the connection
as shown in Figure 18.2. These delay some of the simultaneous packets for an instant
until the line becomes free.
By use
of
buffers as shown in Figure 18.2, it is possible to run the transmission link at
very close to 100% utilization. This is achieved by sharing the capacity between a
number of end devices (each with a
logical channel).
The statistical average of the total
bitrate of all the
logical channels
must be slightly lower than the line bitrate
so

that all
packets may be carried, but at any individual point in time the buffers may be
accumulating packets or emptying their contents to the line.
Packet switching is able to carry
logical channels
of almost any average bitrate. Thus
a 128 kbit/s trunk between two packet switches might carry
6
logical channels
of
mixed
and varying bitrates
5.6
kbit/s, 11.4 kbit/s, 12.3 kbit/s, 22.1 kbit/s, 28.7 kbit/s, 43.0 kbit/s
and still have capacity to spare. This compares with the two channels which a telephone
network would be able to carry using the same trunk capacity. (The excess capacity
of the telephone channels simply has to be wasted, and the other four channels cannot
be carried.)
packet
switch
buff
er
Figure
18.2 The use
of
a
buffer to accommodate simultaneous sending
of
packets by different
logical channels

TRANSMISSION DELAY
IN
PACKET-SWITCHED NETWORKS
343
18.2
TRANSMISSION DELAY IN PACKET-SWITCHED NETWORKS
When using the trunks in a packet-switched network at very close to full utilization, very
large buffers are required for each of the
logical channels,
to smooth out the bursts from
individual channels into
a
smooth output for carriage by the line. (This is rather like
having a very large water reservoir, collecting water during showers of rain, and varying
in water depth, but always capable of outputting a constant volume of water for munic-
ipal use (Figure
18.3).
The water reservoir is analagous to the data buffers, the showers
of rain to the bursts of data information, and the constant output to the information
carried by the line.)
We can make sure that the packets accumulated in the buffer are despatched
on a
jirst-in-jirst
out (FIFO)
basis to fairly share out the
queueing delays
which result, but it is
critical to ensure that the queueing delay does not become unacceptably long. The
chance of
a

very long delay is much greater when close to
100%
utilization of the line is
expected. (Imagine waiting in line for a bus, all of the seats of which had to be full
before it pulled away; either the bus doesn’t come very often, or there is a very long
queue to ensure that all the seats can be filled).
A
certain amount of queueing delay caused by buffering is not noticeable to
computer users (a
$
second is a very long queueing delay in packet switching network
terms). Even
if
a typed character did not appear on the computer screen until a
f
second
after hitting the keyboard, the user is unlikely to notice.
A
variation
in the delay
(sometimes a
$
second, and sometimes
no
delay) is also unimportant. (The fact that
some characters appear on the screen more quickly than the
f
second maximum delay
will not be noticed.) On the other hand, once the average delay becomes much longer,
then computer work may become frustrating,

so
that much longer queueing delays are
unacceptable.
There is an entire statistical science used to estimate queueing delays. The most
important formula is the
Erlang call-waiting formula,
which we will discuss in Chapter 30.
In simple terms, however, the unacceptability of long queueing delays means that the
344
PACKET
SWITCHING
trunks in packet-switching networks may not be utilized at 100%. Typical acceptable
maximum utilization is around
50%. Despite this fact, they are still more efficient than
circuit-switched networks to carry
data tra@c
(i.e. information between computers).
18.3 ROUTING IN PACKET-SWITCHED NETWORKS
Packets are routed across the individual paths within the network according to the
prevailing traffic conditions, the link error reliability, and the shortest path to the desti-
nation, according to one
of two main techniques, so-called
path-oriented routing
and
dutagram routing.
The routes chosen are controlled by the (layer
3)
software of the
packet switch, together with routing information pre-set by the network operator.
Path-oriented routing

is nowadays the most common technique. In
path-oriented
routing,
a
fixed path is chosen for a given
logical channel
(i.e.
virtual circuit,
VC)
at the
time
of
call set up. The path itself is chosen based on the current loading of the network
and the available topology. In the case
of
the
virtual call
(i.e.
switched virtual con-
nection)
service, the required destination of the path is indicated using an X.121 address
carried by a layer
3
packet, called the
call set-up packet.
This packet has the equivalent
function to the dialled digits of a telephone number in setting up a telephone call.
Should any link in the path become unavailable during the course
of
the call (say

because of
a
transmission failure), then an altenative path is sought, without breaking
the connection. The packets are stored for
a
short while, while the new path is found
and then sent over this path. (Figure 18.4).
The advantage of
path-oriented routing
is that the packets pertaining to a given
logical connection
all take the same path, all suffer about the same amount
of
queue-
ing delay in the buffers and arrive pretty much in the same order as they were sent
(allowing for any lost on the way). This makes the job of
re-sequencing
the packets at
the receiving end much easier, as well as the job of directing the packets through the
network. It also leads to more predictable delay performance for the end user or
computer application.
The packet switching network components can therefore be
relatively simple and cheap.
The disadvantage of
path-oriented routing
is the inability of the network on a more
immediate basis to employ alternative routing to better utilize the network as a whole
(A31ppq-W
back-up C-path c1
p1

(c31
4q
m
p1
packet
4
packet
*
switch
fcl
normal A-connection-path
,"
normal C-path (currently failed)
A'
Figure
18.4
Circumventing a transmission link failure using path-oriented routing
ROUTING
IN
PACKET-SWITCHED NETWORKS
345
m
L
U
U)
2
346
PACKET
SWITCHING
during periods of sudden surge in demand resulting from simultaneous packet bursts by

many logical channels sharing the same path. The second type of routing,
datagram
routing,
allows for more dynamic routing of individual packets (Figure
18.5),
and thus
has the potential for better overall network efficiency. The technique, however, requires
more sophisticated equipment, and powerful switch processors capable of determining
routes for individual packets.
Packet switching gives good end-to-end reliability, with well-designed switches and
networks it is possible to bypass network failures (even during the progress of a
call).
Packet switching is also efficient in its use of network links and resources, sharing them
between a number
of calls, thereby increasing their utilization.
18.4
ITU-T RECOMMENDATION
X.25
Most packet-switched networks use the protocol standards set by ITU-T’s recommen-
dation X.25. This sets out the manner in which a
data terminal equipment
(DTE)
should
interact with a
data circuit terminating equipment
(DCE),
forming the interface to a
packet-switched network. The relationship is shown in Figure 18.6.
The X.25 recommendation defines the protocols between DTE (e.g. personal
computer or computer

terminal controller
(e.g.
IBM
3174)) and DCE (i.e. the
connection point to a
wide area network,
WAN)
corresponding to
OS1
layers
1,
2
and
3
(Figure 18.7) which we learned about in Chapter
9).
The physical connection may either be X.21 (digital leaseline) or X.21 bis (V.24/V.28
modem in conjunction with an analogue leaseline: Chapter
9).
Alternatively, the X.31
recommendation (Chapter 10) specifies how the physical connection (DTE/DCE) may
be achieved via an ISDN (integrated digital services network). Finally, recommenda-
tion X.32 specifies the use of a dial-up connection for a
packet mode connection
via the
telephone or
ISDN
network to an
X.25
packet exchange.

The
X.25
recommendation itself defines the
OS1
Iayer 2 and layer
3
protocols. These
are called the
link access procedures
(LAPB
and
LAP)
and the
packet level interface.
The
link access procedure
assures the correct carriage of data across the link connecting DTE
DTE
DTE
DCE
DCE
I
I
I
I
l
*X25
U
IcX25-W
Packet switched network

Figure
18.6
The
X.25
interface
to
packet switched networks
ITU-T RECOMMENDATION
X.25
347
layer
3
protocol
(packet layer)
layer 2 protocol
(link layer)
layer 1 protocol
(physical layer)
(NETWORK)
E
DTE
X.25 packet level interface
*
-
X.25
LAPB
(link access procedure)
X.21, X.Slbis, X.31
or
X.32

DCE
Figure
18.7
OS1
layered model representation
of
ITU-T
recommendation
X.25
to DCE and for multiplexing of
logical channels;
the
packet level interface
meanwhile
guarantees the end-to-end carriage of information across the network as a whole.
The
LAPB
(link access procedure balanced)
protocol provides for the IS0
balanced
class
of
procedure
and also allows for use of multiple physical circuits making up a
single logical link.
LAP
is an older and simpler procedure only suitable for single
physical circuits without balanced operation. The link access procedures use the
principles and terminology of
high-level data link control

(HDLC)
as defined by
ISO.
This procedure ensures the correct and error-free transmission of data information
across the link from DTE to DCE. It does not, however, enable the DCE (in the form
of a
data switching exchange,
DSE)
to determine where the information should be
forwarded to within the network or ensure its correct and error-free arrival at the
distant side of the packet network. This is the job of the OS1 layer
3
protocol, the X.25
packet level interface.
During the set-up of a
switched virtual circuit
(SVC, also called a
virtual call
(VC)) it
is a level
3
call set up packet
which delivers the DSE the data network address of the
remote DTE. Level
3
packets
confirm the set-up of the connection to the initiating DTE
and then pass end to end through the network, allowing user data to be carried between
the DTEs.
A

packet of data carried by the X.25 protocol may be anything between three and
about 4100octets (bytes:
8
bits). Up to 4096 alphanumeric characters of
user
information
may be carried in a single packet.
In slang usage, many people refer to ‘X.25 networks’. In general they mean packet
switching networks to which X.25 compliant DTEs may be connected, for recommenda-
tion X.25 describes only the
UNI (user-network interface,
see Chapter
7).
The X.25
protocol allows DTEs made by any manufacturer to communicate across the network.
You
should not be tempted into believing that the protocol used between the various
packet
data switching exchanges
(DSEs)
within the network is also X.25. Generally,
packet-switched data networks are built from a number of individual exchanges, but all
of them provided by the same manufacturer. The protocol used for the carriage of
the data between the exchanges is normally an X.25-like, but enhanced ‘proprietary’
protocol. Examples include those used by
Northern Telecom (Nortel), Telenet,
BBS,
Tymnet
and France’s
Transpac.

Proprietary trunk protocols typically allow the carriage of sophisticated network
management and charging information back to the network control centre. In addition,
348
PACKET
SWITCHING
they may allow for dynamic adjustment of the traffic paths taken through the network,
so giving better overall network performance during heavy traffic loading.
Where separate packet-switched sub-networks (provided by different manufac-
turers) need to be interconnected, the
X.75
(NNI) protocol is used. We discuss this
later
in
the chapter.
18.5 THE TECHNICAL DETAILS
OF
X.25
X.25
was one of the first data protocols to be well defined and standardized.
As
such it
has formed the basis on which later data transport protocols have been developed.
Understanding the principles in detail will give the reader a very good understanding
of
all other data switching protocols, all of which use similar principles. There thus follows
a
very detailed description.
18.6 X.25 LINK ACCESS PROCEDURE (LAP AND LAPB)
The
link access procedure

can be performed either in the basic mode
(B
=
0,
called
LAP)
or in the more advanced
balanced mode
(B
=
1,
called
LAPB).
Nowadays the
LAPB
mode is more common.
There are two forms of
LAPB;
the basic form is called
LAPB
modulo
8,
the extended
form is called
LAPB
modulo
128. Only the modulo
8
form is universally available. The
difference between the two forms is only the maximum value of the sequence number

given to consecutive packets before resetting
to
value
‘0’.
LAPB
allows for data
frames
to be carried across
a
physical layer connection between a DTE and a DCE. The frame
is structured in the manner shown in Figure
18.8.
The
jag
is a
delimiter
between frames. The
address
(perhaps confusingly named, as
we discovered in Chapter
9)
is a means of indicating whether the frame is a
command
or
a
response frame,
and whether control is with the DTE or DCE. It is coded as shown in
Table
18.1.
Flag

Flag
Frame
Check
Information
Control
Address
01111110
(of
next
frame)
Sequence
(N
bits)
(8
bits)
(8
bits)
(16
bits)
Figure
18.8
X.25
LAPB
modulo
8
frame
Table
18.1
X.25
LAPB

address field coding
Single link procedure Multiple link procedure
command from DCE
to
DTE address
A
-
1 l000000 address
C
-
1 11 10000
response
of
DTE
to
DCE address
A
-
1
l000000 address
C
-
11 110000
command from DTE
to
DCE
address
B
-
10000000 address

D
-
11
l00000
response of DCE
to
DTE
address
B
-
10000000
address D
-
11
l00000
X.25
LINK ACCESS PROCEDURE (LAP AND LAPB)
349
Table
18.2
X.25
LAPB modulo
8
control field command and response coding
Format Command Response bit
1
bit
2
bit
3

bit
4
bit
5
bit
6
bit
7
bit 8
~ ~ ~ ~ ~ ~~~~~~~~~~~~
Information
I
(information)
transfer
Supervisory RR (receive
ready)
RNR
(receive
not
ready)
REJ (reject)
Unnumbered SABM
(set
asynchronous
balanced mode)
DISC
(disconnect)
DM
(disconnect
mode)

UA (unnumbered
acknowledgement)
FRMR
(frame
reject)
0
P
1100P010
llllFllO
llOOFllO
lllOFOOl
The controlfieldcontains either a
command
or a
response,
and sequence numbers where
applicable as a reference when acknowledging receipt of a previous frame. There are three
types of control field format, corresponding to the numbered information trans-
fer of
I-frames
(I format), numbered supervisory functions
(S
format) and unnumbered
control functions
(U
format).
The control field is coded as detailed in Table 18.2.
The
frame check sequence
(FCS)

field is a string of bits which help to determine at the
receiving end whether the data in the frame has in any way been corrupted. It is a 16 bit
field, created using the properties of a cyclic code, hence the term
cyclic redundancy
check.
The exact 16 bit sequence sent is the ones complement of the sum (in binary) of
the following two parts.
(1) The remainder
of
xk(xI5
+
xI4
+
xI3
+
XI*
+
xl1
+
x10
+
x9
+
x8
+
x7
+
x6
+X5
+

X4
+
x3
+
X2
+
XI
+
X
+
1)
divided (in binary) by
x16
+
xL2
+
x5
+
1
where
k
is the number of bits in the frame excluding flag and
FCS.
(2) The remainder of the product of the frame content (excluding flag and
FCS)
and
xI6,
when divided by
X'6
+

X12
+
X5
+
1
There are six configurable parameters when setting up
LAPB
connections. These, their
meaning and typical value settings are given in Table 18.3.
350
PACKET
SWITCHING
Table
18.3 Optional parameter settings for
X.25 LAPB
Parameter Meaning Typical value
Frame window size
N1
parameter
N2
parameter
Timer T1
Parameter
T2
Timer
T3
This is the maximum permitted number of
outstanding frames which may be sent without
receiving an acknowledgement
This is the maximum number of bits in an I-frame

This is the maximum number of attempts which
may be used to complete
a
transmission
The timer T1 is the timeout period after which
a
retransmission may be initiated
This is the maximum time allowed before an
acknowledging frame must be initiated
Should the channel remain idle longer than this time,
then the link shall be assumed to be non-active
7
2096
10
attempts
3
seconds
0.2
seconds
0 (not used)
18.7
X.25
PACKET LEVEL INTERFACE (LAYER
3
PROTOCOL)
The
information carried
within
a
LAPB

I-frame
will
be
a
packet
of
user
data
informa-
tion
structured in the format
as
defined
by
the
X.25
packet
level
interface.
The
general format of a
packet
is
as
shown in
Figure
18.9.
Octet
8
7

6
54
3
2
1
1
Logical channel group
number
General format identifier
I
2
Logical channel number
31
clearing cause, resetting cause
or
interrupt data
4
Packet type identifier
5
diagnostic code
41
Address digit
1
I
Address digit
2
I
I
I
I

I I
X
Facility length
(1
octet)
Figure
18.9
X.25
packet format (layer
3)
X.25
PACKET
LEVEL
INTERFACE
(LAYER
3
PROTOCOL)
351
Table
18.4
X.25 packet-coding of the general format identifier
General format identifier bit
8
bit
7
bit
6
bit
5
Call set-up packets sequence number modulo

8
X
X
0
1
sequence number modulo I28
X X
1
0
Clearing packets sequence number modulo
8
X
0 0
1
sequence number modulo 128
X
0
1
0
Flow
control, interrupt, sequence number modulo
8
0
0
0
1
reset, restart, registration sequence number modulo 128
0
0
1

0
and diagnostic packets
Data packets sequence number modulo
8
X X
0
1
sequence number modulo 128
X
X
1
0
general format identifier extension
0 0
1 1
reserved for other applications
*
*
0
0
The minimum number of octets in a packet is three, the general format identifier, the
logical channel identifier and the packet type identifier. The other packet types are
added as required.
As
is normal, the least significant bits of each octet (i.e. bit 1) is
transmitted first.
The
general format identijier
field provides information about the nature of the rest of
the packet header (the first three octets of the packet).

It
is coded according to the
values set out in Table 18.4.
The
logical channel number
is a reference number allowing the DTE and DCE to
distinguish to which logical connection (or statistically multiplexed
virtual channel)
the
packet belongs. Thus, in theory, up to 4096 logical channels may be supported by a
single DTE /DCE connection simultaneously.
The
packet type identijier
is coded according to Table 18.5.
As
can be seen from
the table, certain packet types are needed for
virtual calls (VCs,
also called
switched
virtual channels,
or
SVCs),
and
a
lesser number of packet types are required to sup-
port
permanent virtual channels
(or
PVCs).

The difference between an SVC and a
PVC is essentially the difference between an ordinary telephone line and a point-
to-point leaseline. With an ordinary telephone line and an SVC each connection is set
up on demand by dialling the number of the desired destination. With a telephone
leaseline or a PVC the connection is permanently connected between the same two
endpoints.
In clear request and clear indication packets, the clearing cause is included at octet
4.
In
reset request packets the reset cause appears in octet 4, while in interrupt data
packets.
Interrupt data,
when sent, also appears in octet 4. This is data which is not
subject to normal flow control, in effect allowing the DTE to override previous
commands to the distant DTE (like
a
‘break’ or ‘escape’ key).
Call request, call
accepted
and
call connected
packets contain from octet
4
onwards the
address block
field, and optional
facility length
and
facility $eld
and the

called user data.
The
352
PACKET
SWITCHING
Table
18.5 X.25 packet identifier coding
Packet type
From DCE to DTE From DTE to DCE VC PVC bit bit bit bit bit bit bit bit
81654321
~
Call set-up and clearing
incoming call call request
call connected call accepted
clear indication clear request
DCE clear confirmation DTE clear confirmation
J
00001011
J
00001111
J
00010011
J
00010111
Data and interrupt
DCE data DTE data
DCE interrupt DTE interrupt
DCE interrupt confirmation DTE interrupt confirmation
Flow control and reset
DCE RR (modulo

8)
DTE RR (modulo
8)
DCE RR (modulo 128) DTE RR (modulo 128)
DCE RNR (modulo
8)
DTE RNR (modulo
8)
DCE RNR (modulo 128) DTE RNR (modulo 128)
DTE REJ (modulo
8)
DTE REJ (modulo 128)
reset indication reset request
DCE reset confirmation DTE reset confirmation
Restart
restart indication restart request
DCE restart confirmation DTE restart confirmation
Diagnostic
Registration
registration confirmation
registration request
J
Jxxxxxxxo
J
J00100011
JJOO100111
J
Jxxx00001
J
J00000001

J
Jxxx00101
J
J00000101
J
Jxxx01001
J
J00001001
JJOOO11011
JJOOO11111
JJ11111011
JJ11111111
JJ11110001
JJl1110011
JJ11110111
diagnostic code is included in diagnostic type packets and also optionally in clear
request and reset request packets.
The address
block
field is coded as shown in Figure 18.10. The calling
DTE
and called
DTE
address length fields are coded in binary. The address digits themselves, however,
are coded in four digit blocks, binary coded decimal, according to ITU-T
recommendation X.121. If necessary, bits 1-4 of the last octet are filled with
Os
to
maintain octet alignment.
Thefacility length field merely indicates as

a
binary number the length
of
the facility
field which follows. The facilities field allows the calling DTE to request
a number of
optional services. These (where made available) are as listed in Table 18.6.
X.25
PACKET LEVEL INTERFACE (LAYER
3
PROTOCOL)
353
8
7
6
54
3
2
1
called
DTE
address length
called
DTE
address
calling
DTE
address length
l
I

I
I
I
I
calling
DTE
address
I
I
I
I
0
0
0
0
I
I
Figure
18.10
Format of the X.25 packet address block
Table
18.6
X.25 network facilities
X.25
Optional facilities Description
on-line facility registration
extended packet sequence numbering
D bit modification
packet retransmission
incoming calls barred

outgoing calls barred
one-way logical channel outgoing
one-way logical channel incoming
non-standard default packet sizes
non-standard default window sizes
default throughput classes assignment
flow control parameter negotiation
throughput class negotiation
closed user group
bilateral closed user group
fast select
fast select acceptance
if subscribed to, allows user to request facility
registration
packets numbered modulo 128 rather than normal
modulo 8
support of D-bit procedure
allows DTE to request DCE to restransmit packets
prevents incoming calls being presented to DTE
prevents DCE from accepting outgoing calls
restricts logical channel
use
to originating outgoing
virtual calls only
restricts logical channel
use
to incoming virtual calls
only
provides for the selection of non-default packet sizes
provides for the selection

of non-default window sizes
provides for the selection of default throughput
classes
allows the DTE to alter window and packet sizes for
each virtual call
allows throughput class (i.e. bitspeed) negotiation for
each call
restricts incoming calls to the DTE to be from other
specific DTEs which are members
of
a closed user
group
a closed user group of only two DTEs
allows the call request packet to contain up to 128
octets of user information, thereby speeding the
sending of short user messages
authorizes DCE to forward fast select packets to the
DTE
354 PACKET SWITCHING
Table
18.6
(continued)
X.25
Optional facilities Description
reverse charging
reverse charging acceptance
local charging prevention
network user identification (NUI)
charging information
RPOA related facilities

hunt group
call redirection and call deflection
called line address modified notification
transit delay selection and indication
TOA/NPi address subscription
allows calls to be requested for charging to recipients
rather than callers
DTE authorization to the DCE that it is willing to
accept reverse charge calls
prevents the DCE from allowing virtual calls to be set
up for which the local DTE will be charged
an authorisation procedure allowing for the dial-in to
an
X.25
network port across a public telephone
network
DTE may request charging information
allows the calling DTE to specify transit networks
through which the call should be routed
allows several separate DTE/DCE network
connections to share the same network address.
Incoming calls are routed to any free logical channel
within at any of the DTEs
allows deflection on busy or redirection on no answer
notifies the calling DTE that the called address has
been modified (diverting to a new destination)
allows the calling DTE to specify a desired transit
delay
DTE/DCE to use TOA/NPi address format
18.8

TYPICAL PARAMETER DEFAULT SETTINGS USED
IN
X.25
NETWORKS
A typical public
X.25
network might be set up with the following default settings
for
the
packet
level
interface
window size
2
packet size
128
window negotiation allowed
packet negotiation allowed
throughput negotiation allowed
lowest logical channel
number
1
highest logical channel number
16
customer
DTE
to
select logical channel number, from highest number descending
PACKET ASSEMBLER/DISASSEMBLERS (PADS)
355

18.9
PACKET ASSEMBLER/DISASSEMBLERS (PADS)
The X.25 protocol is suitable for the connection of synchronous communication devices
(i.e. computers) to a packet switching network. It is widely used, and many devices are
available worldwide (both DTEs and packet DSEs (data switching exchanges) which
support it. However, directly X.25 protocol is unsuitable for connecting slow and
relatively unintelligent asynchronous computer terminals to an X.25 packet network.
Instead a procedure is defined by ITU-T recommendation X.28.
Necessary interworking is achieved by means of a piece
of
equipment provided in
place of the DCE at the packet-switched exchange. This equipment is called a packet
assembler/disassembler or
PAD
for short. As its name suggests, it assembles packets
from the asynchronous terminal data for onward transmission, and it disassembles
packets received from the far end DTE, conveying them on to the asynchronous
terminal as individual characters.
Three ITU-T recommendations define the operation of PADS.
0
X.3 defines the functions of the PAD (i.e. the conversion of asynchronous characters
into synchronous packets).
0
X.28 defines the control interface between PAD and asynchronous terminal. The X.28
parameters (Figure 18.18) define how the PAD is to react to the characters sent to it,
how often to despatch groups
of
characters as apacket, and which characters typed by
the end terminal are to be interpreted directly by the PAD itself as control characters.
0

X.29 defines the interface between PAD and remote X25 DTE (usually some form
of host computer).
Figure
18.1
1 illustrates the inter-relationship of the three recommendations and Table
18.7 lists the PAD control parameters of recommendation X.28. In the final column of
packet-switched
network
functions defined
by
X.3
L
PAD
DCE
V.24
I
interface
I
!
I
(packet-
I
4
8
I-
X.28
H+
X.29
-:
protocol

Figure
18.11
The packet assembler/disassembler
(PAD)
356
PACKET SWITCHING
Table 18.7 PAD control parameters defined by ITU-T recommendation X.28
Parameter Purpose Permitted values Simple standard
reference profile (value)
parameter
1
PAD recall using character
0
=
no
escape
1
=
escape
32-126
=
ASCII code of ‘escape’ character
parameter 2 Echo (i.e. character is
0
=
no echo
returned to be displayed
on
1
=echo

screen)
parameter
3
Selection of data fowarding
0
=forwarded only on ‘poll’ from network
characters (e.g. ‘carriage
2
=
forward
on
‘carriage return’
return’ key)
8
=forward on (CR), (ESC), (DEL), (ENQ),
WK)
18=forward
on
(CR),
(EDT), (ETX)
126
=
forward on all control characters
parameter
4
Selection
of
idle timer delay 0
=
no

delay
1-255 (delay, multiple of 10ms)
parameter
5
Ancillary device control
0
=
X-ON and X-OFF not in use
1
=X-ON
and X-OFF in use
2
=
X-ON and X-OFF in use during data
transfer
parameter 6 Control of PAD service
0
=no
signals sent to DTE
and command signals
1
=signals sent
to
DTE
other values define which signals may be used
parameter
7
Selection
of
reaction

of
0 =no
reaction to ‘break’
PAD to the ‘break’ key
1
=
assembled characters and ‘interrupt’ sent
to host
2
=
reset on ‘break’
other values define other actions
parameter
8
Discard output
0
=
deliver data
l
=
discard data
parameter 9 Padding after carriage 0-255 (number of characters to be inserted
return after ‘carriage return’)
parameter
10
Line folding 0-255 (defines length of a line in characters)
parameter 11 Binary speed
12
=
2

400
bit/s
13
=
4
800
bit/s
14
=
9 600 bit/s
16= 19200bit/s
19= 14400bit/s
20
=
28
800
bit/s
21
=
38
400
bit/s
other values give other speeds
1
1
126
1
2
0
0

0
-
PACKET ASSEMBLER/DISASSEMBLERS (PADS)
357
Table
18.7
(continued)
Parameter Purpose Permitted values Simple standard
reference profile (value)
parameter 12 Flow control of the PAD
0
=no
use
of X-ON and X-OFF for flow
by the DTE control
1
=
use
of X-ON and X-OFF for flow control
parameter 13 ‘Linefeed’ insertion after 0 =no linefeed insertion
‘carriage return’
1
=
linefeed after ‘carriage return’
other values define other actions
parameter 16 Character delete
parameter 17 Line delete
parameter
18
Line display

parameter 14 Linefeed padding 0-255 (number of characters inserted after
linefeed)
parameter 15 Editing
0
=
editing only in command mode
1
=
editing in command and data transfer
modes
2 =extended editing
0-127 (ASCII code of character used as
character delete)
0-127 (ASCII code of character used as line
delete)
0-127 (ASCII code of character used to
request line display)
parameter
19
Editing PAD service
signals
parameter 20 Echo mask
parameter 21 Parity treatment
parameter 22 Page wait
parameter 23 Size of input field
parameter 24 End of frame signal
0
=
no editing
1

=editing for print terminals
2 =editing for display terminals
8,
32-126 this character replaces deleted
characters
0
=
no echo mask
1
=
no echo of ‘carriage return’
2
=
no echo of ‘linefeed’
other values define other control characters
not echoed
0
=parity not generated or checked
1
=parity checked of input from DTE
2 =parity generated for output to DTE
3 =parity generated and checked
(combination of
1
and 2)
0-255 (number of line feeds which may
be
generated before an ‘abort’)
0-255 (number of characters)
0

=
not used
1-127 ASCII code of character to signify end
of frame
1
0
127
24
18
1
0
0
0
0
0
358
PACKET
SWITCHING
Table 18.7
(continued)
Parameter Purpose Permitted values Simple standard
reference profile (value)
parameter 25
parameter 26
parameter 27
parameter 28
parameter 29
Additional data forwarding
0
=no

extra data forwarding
0
character 1-127
=
ASCII code
of
extra forwarding
character
Display ‘interrupt’ character
0
=
no abort character
0
1-127
=
ASCII code
of
‘interrupt’ character
Display interrupt
0
=
no
confirmation
confirmation (‘prompt’
1-127
=
ASCII code
of
‘interrupt’
character)

confirmation character
Diacritic character coding
0
=not used
scheme
0
0
Extended
echo
mask
0
=
not
used
0
Table 18.7, the parameter settings are given for the
simple standard profile.
This is a
standard X.28 parameter setting set for emulating a low speed ‘transparent’ leaseline
between an asynchronous computer terminal and its terminal controller.
In case you are left wondering, having studied Table 18.7, what exactly ‘X-ON’
and ‘X-OFF’ are, these are the alternative states of a given control lead within a
standard DTE-to-DCE interface (such as V.24 as defined in Chapter
9).
When the
lead is set ‘X-ON’ then the DTE may send transmit data. When instead the lead is
set ‘X-OFF’ then no data may be transmitted. This ensures that the DCE is ready
to receive data before the
DTE
may send. Before call set up the lead is set X-OFF,

then
X-ON after call set-up. During the call, the lead may be reset to X-OFF to
slow up the receipt of data (i.e. for
flow control)
if the DCE or network becomes
overloaded.
A call can be set up from an
asynchronous
DTE
(so-called
startlstop terminal)
simply
by typing in the X.121 data network address (Chapter 29). This procedure for call set-
up from a start-stop terminal is also defined by X.28.
18.10
ITU-T RECOMMENDATION
X.75
To connect different packet switched networks together, a
network-network interface
(NNZ)
or
gateway protocol
is defined by
ITU-T
in its recommendation X.75. X.75 can
be thought of as
a
super set of the X.25 protocol (Figure 18.12). It was originally
developed for international interconnection of packet networks).
Like X.25, recommendation X.75 defines all the protocols for layers

1-3.
At layer 1, a
64 kbitls bearer conforming to Recommendation G.703 is stipulated. At layer 2, the
ITU-T RECOMMENDATION
X.75
359
r
-I
m
W
c
D
W
0
U
N
Y
ln
U
2
-
z
U
360
PACKET
SWITCHING
single link procedure (SLP)
and the
multilink procedure (MLP)
are defined.

SLP
is
based on
LAP
(the
link access procedure
used in X25) and should be used where
packet-switched exchanges (PSEs)
are interconnected by a single datalink. Where more
than one parallel link is available between exchanges the more advanced
MLP
must be
used. The protocol of X.75 is similar to X.25 at layer
3,
with a few extra messages added
to cater for inter-exchange signalling requirements. Communication using X.75 occurs
between logical functions called
signalling terminals (STE)
which are software
programs within the
packet-switched exchanges (PSEs).
18.11 WHEN
X.25
PACKET SWITCHING MAY AND MAY
NOT BE
USED
The use of either a private corporate or public X.25 packet switching network is ideally
suited for the connection of a large number of data terminal devices back
to
a central

computer centre. In particular, the use of X.25 is usually economic where the volume
of
data transferred from each individual device is relatively low,
so
that by
statistically
multiplexing
the data onto a common network of lines line costs may be saved. When,
however, the data volume between two specific points exceeds a certain economic
threshold, it will be cheaper to use a direct circuit.
Common applications are the connection of point-of-sale and credit card authoriza-
tion devices in shops and stores back
to
the headquarters computer centre or bank
authorizing centre. Other applications might include connection of remote small offices
equipped with IBM 3174 terminal controllers back to a central computer centre site
offering
NPSI (network packet switching interface,
IBM’s
mainframe software product
for enabling X.25).
X.25-based packet networks are not economically viable where relatively high
volumes of data are to be carried between only a small number of sites. They are also
technically unsuitable where prolonged point-to-point carriage rates much above
256 kbit/s are required.
The strength of X.25-based packet networks is their high reliability in transporting
data accurately across even quite poor lines. Their weakness is their relative slowness
compared with more modern techniques (e.g. frame relay) and the relatively high
delays which can be incurred when transporting individual packets of information.
This delay can cause particular technical difficulties or user annoyance for certain

types of computer applications. Where the computer application has been designed
without specific thought for X.25 communication, it may run into technical
difficulties.
A
common problem incurred with X.25 networks is that which occurs when
applications conduct an unnecessarily ping-pong nature of dialogue, e.g. ‘please send
me next information
. (information). . . received. . . can
I
send next information?.
.
.
please send next information (information, part 2), etc., etc.’. Although the delay for
sending each message across the X.25 network is quite low (say looms), the fact that
four messages are actually sent by the application for each one which is really needed
multiplies the delay
to
400ms). The best applications run with minimum requests for,
and acknowledgements of, information transfer.
ALTERNATIVES
TO
X.25-BASED PACKET SWITCHING
361
18.12 ALTERNATIVES TO X.25-BASED PACKET SWITCHING
Where all the equipment within a computer data network is provided by a single
supplier (e.g. IBM, DEC, Siemens Nixdorf, Unisys) it may be possible and advisable to
use the supplier’s proprietary data communication protocol (e.g. SNA, DECNET, etc.).
This probably helps to optimize the management of the computer environment and
keep down the computer equipment costs. In addition, software programs may run
better and faster. The disadvantage of ‘proprietary’ protocols are that they generally

rule out the use of public packet switching networks as the communication transport
medium. The effect may be to demand a higher number of relatively expensive point-to-
point private lines (leaselines) to be rented from the telephone company, for dedicated
use. Conversion of the network (usually by encapsulating the same information within
X.25 packets) enables the packet switch network to be used but it is usually linked
to
further software and hardware investment costs.
At higher data volumes and higher speeds, frame relay protocol is becoming the
accepted replacement for X.25. It shares the
statistical multiplexing
benefits which
X.25-based packet networks offer, but it is prone to lower individualframe (rather than
packet)
delays. At very high speeds ATM (asynchronous transfer mode) is the emerg-
ing standard.
For extremely high speeds and for applications requiring very low jitter (variability of
delay) such as high quality speech, music or video, there is no alternative to direct
leaselines. Also, for very high point-to-point data volumes, direct leaselines and a
proprietary protocol may be cheapest.
18.13 IBM’S ‘SYSTEMS NETWORK ARCHITECTURE’
IBM’s
systems network architecture
(SNA)
defines the functions of a layered protocol
set specifically intended for use in ‘pure’ IBM computer networks. It is a ‘proprietary’
protocol, specified only by the IBM company, but is widely supported by other
manufacturers’ equipment, due to the very large numbers of IBM mainframe
computers and their associated computer networks.
SNA
was first introduced by IBM in

1974
and it has evolved through several
generations to its current form. It was developed as an all-purpose data networks
architecture, a replacement for the growing number of incompatible communication
products which IBM had at the time. The latest SNA networks allow a large number of
host
machines,
communication controllers,
and
cluster controllers
(IBM’s name for
terminal controllers) to share a sophisticated communication network. By
so
doing,
SNA creates
0
an ability for terminal users to switch dynamically between different application
programmes or even different
host
computers
0
an ability to attach dissimilar devices to the same network
0
an ability to concentrate (or
multiplex)
a number of data connections to share a
common circuit or network
362
PACKET
SWITCHING

Table
18.8
SNA physical unit (PU) classes
Class type Class purpose and example
5
Host computer or system services control point (SSCP) (network configuration
4 Communications controller (e.g. IBM 3725 or 3745) or network control program
software residing
on
a mainframe computer)
(NCP) (a software residing on a host)
3 never existed
2.1 ‘independent’ cluster controller capable of peer-to-peer operation across an
SNA
network (this class was conceived for the IBM series of AS400 midrange
computers to be able to communicate directly with one another)
2 ‘dependent’ cluster controller (e.g. IBM 3174 or 3274), a device allowing a
number of different end user terminals (dumb terminals) to share the same
statistically multiplexed line to the mainframe host computer
1
remote devices, including terminal nodes such as remote printing devices now
virtually obsolete
0
an
ability for direct interconnection between
host
computers, PCs and/or
minicomputers,
so
enabling

distributed processing
and
storage of
data
SNA
caters for communication between five different classes of
physical units
(PUS)
such as terminals and computers, classified
as
shown in Table
18.8.
The communication itself takes
place
between logical units
(LUs)
which are software
programs resident within the
PUS.
A
session
of
communication ultimately takes place
Table
18.9
Systems network architecture (SNA)
SNA
layer name Equivalent Function
NAU
services

(NAU
=Network Addressable Unit)
FMD services
(FMD
=
File Management Data)
Data flow control
Transmission control
Path control
Datalink control
Physical
7 Data exchange between logical units
(LUS)
6
Syntax. Data compression and
compaction type. ASCII, EBCDIC code
type
5
Dialogue control. (Session control)
4 Activating and deactivating data
flow
within a session
213 Routing and flow control. Message
Packetization
2 Managing bit oriented data flow. SDLC
1
X21. RS232-C
ALTERNATIVES
TO
X.25-BASED PACKET SWITCHING

363
to serve the communication needs of these programs. Thus an LU is the equivalent of
the
OS1
application layer.
Serving a
logical unit
(LU)
at either end of an SNA network, there are up to seven
layered protocols, as shown in Table
18.9.
The protocols are similar in purpose to those
of the
OS1
model but there are some significant differences in the functions
of
individual
layers.
The layered nature of SNA is immediately apparent in the message structure, as we
show in Figure
18.13.
Just as in the
OS1
case, each progressively lower layer adds an
information field, called a
header
or
trailer,
to the original data which is held in the
requestlresponse unit.

At the receiving end each progressively higher layer removes its
appropriate header and passes to the next higher layer all that is left.
The layered nature of SNA is intended to provide for modular design of computer
network software, giving greater ease of maintenance and more easily modifiable
implementations. Between them the layers are intended to meet all the data com-
munication requirements of an entire distributed data processing network. The layers
themselves may thus be realized in a number of different
forms.
Usually the layers are
either all realized in the same physical unit (PU), or, as is done with many host com-
puters, the protocols are implemented in two parts; the lowest three layers
(physical,
SNA
Layer
b-
NAU
Services
FMD
Services
Data
flow
control
Transmission
control
Path
control
Data Link
control
Message structure and relation
of

headers Itailers
to
SNA layers
FMH RRU
RH
'
TH
LH
LT
Physical
Direction
of
transmission
Figure
18.13
SNA
message structure. LH, Link Header; TH, Transmission Header; RH
Response Header; FMH, Function Management Header; RRU, Request Response Unit;
LT,
Link Trailer
364
PACKET SWITCHING
datalink
and
path control)
making up the
path control network
are conducted by the
communication controller (front end processor), and the higher layers together form a
network addressable unit

(NAU)
which resides in the host processor itself. The NAU is
held in software in the host, and it relies on the
network control program
(NCP)
software in the
front endprocessor
or
communication controller.
A
number of alternative
IBM software products are available for installation as NAUs on IBM
or
compatible
equipment. The most commonly used communication product on IBM mainframe
computers is
VTAM
(virtual telecommunication access method).
An
older, less fre-
quently used product is
TCAM
(advanced communication
functionltelecommunication
access method).
Both provide the necessary host software for telecommunications in
support of a logical unit
(LU) in the application program of a host computer.
Both
TCAM

and
VTAM
include a function called the
SSCP
(system services control
point).
This is a software function, and each SNA network must have at least one of
them to control the overall network configuration, activating and deactivating the
network and establishing communication sessions. This it does by interacting with
appropriate software in each of the other
physical units
(PUS)
of
the network.
The
communication controller,
if provided as a separate physical entity from the
host, can be any of a number of IBM 37x5 series machines. These are specialized
telecommunication hardware devices which conform to the SNA model when loaded
with IBM
network control program
(NCP)
software and act to relieve the host of
communication functions.
A
cluster controller
(e.g. IBM 3174 or 3274) allows the
connection of dumb terminals to the network.
A
typical configuration

is
shown in
Figure 18.14.
As already discussed, one of the most common SNA communication regimes is often
referred to as
3270 communication.
This is the method used for communication
between a mainframe computer and a 'dumb', 327X-type (e.g. 3270) terminal. How-
ever, the emergence of the personal computer (PC) in recent years has strained the
capabilities of this method. Nowadays it is common to use PCs as part-time mainframe
computer terminals, but to do
so
requires that they
emulate
the dumb terminals they
substitute.
So
we have
3270 emulation.
Either by hardware means (a communication
IBM
370
IBM
3725
I
B
M
3274
comrnunlcatlons cluster Terminal
host computer controller controller Node

-
_.
VTAM
Application
-
program
NC
P
LU
-
(SSCPI
i_
-
1
1
1
pu
1
j
p"
1
1
pu
Figure
18.14
A
typical
SNA
network