2790_ITU TSS_X.25 2790 ITU TSS X.25

User Manual: Pdf 2790_ITU-TSS_X.25

Open the PDF directly: View PDF .
Page Count: 22

In

this report:

X.21

Interface

Specifications

....................... 5

Recommendation

X.25

....................................

10

Connections

Between

Packet

Switched

Data

Networks

............................

16

Trends

in

Packet

Switching

............................

18

DATAPRO

Data

Networking

2790

Standards

1

lTV -

TSS

Packet

Switched

Networking

Standards

X

Series

Datapro

Summary

In

1984 the ITU-TSS (fonnerly CCITT) published standards on wide-ranging topics, includ-

ing X.25 packet switching. A set

of

revisions to the X Series, the Blue Books, was published

in 1989. Since that time, standards ratification and publication has been an ongoing, con-

tinuous process. Each future addition

or

revision to the X Series standards will be made

available, as soon as

it

is finalized, in individual gray booklets. Since the major building

blocks

of

the X standards were completed by 1984, all post-1984 technical changes are

relatively minor; they are discussed in this report, however. Major developments in packet

switching center around the development

of

ISDN-related technologies, such as fast packet

switching and frame relay, which provide integration

of

voice, video, and data, and support

much higher throughput than traditional X.25 networks. ISDN's relationship with traditional

X.25 packet switching is also discussed.

A packet switched network permits a user's data

terminal equipment (PC, host computer, or ter-

minal) to communicate with the equipment of

other geographically dispersed users. A packet

assembler/disassembler (PAD), also referred to

as data circuit-terminating equipment (DTE),

serves

as

a network entry/exit point, packetizing

and depacketizing data according to the rules

specified by the X Series recommendations

of

the International Telecommunications Union's

Telecommunications Standardization Sector

(ITU-TSS, formerly known

as

CCITT).

In the early days

of

packet switching, each

Public Data Network (PDN) defined its own net-

work access protocol, which permitted an appro-

priately equipped computer to communicate

with other devices on the network through a

physical connection to the PDN. Each

of

these

protocols used a multiplexing technique that en-

abled a computer to establish and maintain one

or more virtual circuits to other network commu-

nicating equipment. No industry standard for

packet switching existed, however, and most

-By

Martin Dintzis

Assistant Analyst

computer manufacturers were reluctant to pro-

vide the necessary software to handle the variety

of

network access protocols.

With the adoption

of

the X Series Recom-

mendations by the ITU-TSS in 1976, the PDNs

could offer a standard network access protocol.

The ITU-TSS published revisions to these stan-

dards in 1984 and 1989. Since that time, the rati-

fication and publication

of

revisions have be-

come a continuous, ongoing process.

This report focuses on Recommendations

X.3, X.28, and X.29 (informally called the Inter-

active Terminal Interface [ITI] standards); X.21;

X.2S; and X.7S.

Packet

Assemblyl

Disassembly

Recommendations X.3, X.28, and X.29 define

the procedures by which asynchronous termi-

nals, computers, and other devices, often re-

ferred to as data terminal equipment (DTE),

communicate with other devices via a packet

switched network. Packet assemblers/disassem-

blers, also referred to as DTE, commonly serve

as network entry/exit points.

X.3 defines the basic and user-selectable

functions

of

a PAD.

It

also lists 22 parameters

necessary to characterize a specific device (e.g.,

bit rate, the escape character, and flow control

C

1994

McGraw-Hili.

IllCOf\lOrated.

Reproduction

Prohibited.

Datapro

Information

SenIices

Group.

Delran

NJ

08075

USA

FEBRUARY

1994

2

2790

Standards

technique). The proper setting of

these

values

enables

the

PAD

to

correctly interpret

the

communicating

device

and

vice

versa.

X.28,

a related standard, defines

the

procedures for character

intenPange

and

service initialization,

the

exchange of control in-

formation,

and

the

exchange of

user

data

between

an

asynchro-

nous

terminal device

and

a

PAD.

X.29

dermes

the

procedures for

the exchange

of

PAD

control

information

and

the

manner

in

which

user data

is

transferred

between

a packet

mode

D1E

and

a

PAD

or between

two

PADs.

Recommendation

X.3

TSS

Recommendation

X.3,

Packet Assembly/Disassembly

Facil-

ity

in

a Public

Data

Network,

outlines

the

procedures

for

packet

assembly/disassembly

in

asynchronous

transmissions. These

functions

can

1?e

programmed

and

built

into

a microprocessor- .

based

"black box" that

is

placed

between

the

terminal

and

the

X.25

network at either the customer's

premises

or

the

entry point

of

the

network

node.

The

PAD

performs a number of

functions,

some

of

which

al-

low

it

to

be

configured,

by

either

an

asynchronous

terminal

de-

vice

or another (remote)

PAD,

so

that

its

operation

is

adapted

to

the

asynchronous

terminal's characteristics. The PAD's basic

functions

include the

following:

•

The

assembly

of characters

into

packets;

•

The

disassembly

of

the

user

data

field;

•

Virtual

call setup, clearing, resetting,

and

interrupt procedures;

•

Generation

of service

signals;

• A mechanism for forwarding

packets

when

the proper

condi-

tions

exist;

• A mechanism for transmitting data characters, including start,

stop,

and

parity elements;

• A

mechanism

for handling a

break

signal

from

an

asynchro-

nous

terminal;

•

Editing

of

PAD

command

signals;

• A mechanism

for

setting

and

reading

the current

value

of

PAD

parameters;

• A

mechanism

for

the selection of a

standard

profile (optional);

•

Automatic

detection of data

rate,

code,

parity,

and

operational

characteristics (optional);

and

• A

mechanism

for

the remote

DTE

to

request a virtual

call

be-

tween

an

asynchronous

terminal

and

another

DTE

(optional).

The PAD's operation

depends

on

the selectable

values

of internal

variables called

PAD

parameters. A set of parameters exists

inde-

pendently

for

each asynchronous

terminal.

The current value

(the

binary

representation of the

decimal

value)

of

each

PAD

param-

eter delimits the operational characteristics of the related

func-

tion.

The

initial value

of

each

parameter

is

set

according

to

a

predetermined set of values,

the

initial standard profile.

Twenty-

two

PAD

parameters

have

been

standardized

by

the

ITU-

TSS.

They

are

as

follows:

•

PAD

recall using a character-allows

an

asynchronous

ter-

minal

to

initiate an escape

from

the

data

transfer state or

the

connection-in-progress

state

in

order

to

send

PAD

command

signals.

This parameter

has

the

following

selectable

values:

not

possible, possible

by

character

110

(OLE),

or possible

by

a

user-defined graphics character.

• Echo-enables characters

received

from

the

asynchronous

ter-

minal

to

be

interpreted

by

the

PAD

and

transmitted

back

to

the

asynchronous

terminal. Selectable

values

are

no

echo

(0)

and

echo

(1).

FEBRUARY

1994

ITU.TSS

Packet

Switched

Networking

Standards

X Series

Data

Networking

• Selection

of

data fonvardingcharacters-allows the

asyn-

chronous terminal

to

send

defined

sets

of characters, which the

PAD

recognizes

as

an

indication

to

complete the packet

assem-

bly

and

to

forward

a complete packet sequence

as

defined

in

X.25.

The

basic

functions of

this

parameter are encoded

and

represented

by

a decimal

value.

The

functions include

no

data

forwarding

character (represented

by

decimal

0);

alphanumeric

characters

A-Z,

a-z,

and

0-9

(decimal

I);

CR

(decimal

2);

ESC,

BEL,

ENQ,

and

ACK

(decimal

4);

DEL,

CAN,

and

DC2 (deci-

mal

8);

EfX

and

BOT

(decimal

16);

Hr,

LF,

VT,

and

FF

(deci-

mal

32);

and

all other characters

in

columns

0

and

I

of

Interna-

tional

Alphabet No.5

(lAS)

not

included

in

the above

(decimal

64).

• Selection

of

idle timer delay-permits the selection of the

duration

of

a time interval

between

successive characters.

When

data received

from

the

asynchronous

terminal

exceeds

this

interval, the

PAD

terminates the

assembly

of a packet

and

forwards

it

as

defined

in

the

X.25

protocol.

• Ancillary control-defines

flow

control

between

the

PAD

and

the

asynchronous terminal.

Decimal

0 represents

no

use

of

X-on

(DCI)

and

X-off

(DC3);

decimal

I represents

use

of

X-

onIX-off (data transfer);

and

decimal

2 represents

the

use

of

X-onlX-off (data transfer

and

command).

• Control of

PAD

service

signals-provides the asynchronous

terminal

with

the capability

to

decide

whether

and

in

what

for-

mat

PAD

service signals

are

transmitted.

• Selection

of

operation of the

PAD

on receipt

of

the break

signal-after receiving a break

signal

from

the

asynchronous

terminal,

the

PAD

may

do

nothing,

send

an

interrupt packet

to

a packet

mode

D1E or another

PAD,

reset, or send an

indica-

tion

of

break

PAD

message

to

a packet

mode

D1E

or another

PAD.

• Discard output-permits a

PAD

to

discard

the content of user

sequences

in

packets rather

than

disassembling

and

transmit-

ting

them

to

the asynchronous terminal. Selections include

nor-

mal

data delivery or discard

output.

• Padding after carriage return-permits

the

PAD

to

automati-

cally

insert padding characters

in

the

character stream

sent

to

the

asynchronous

terminal after

the

occurrence of a carriage

return character. This enables

the

asynchronous

terminal print-

ing

device to perform the carriage

return

function correctly. A

value

between 0

and

255

indicates

the number of padding

char-

acters

the

PAD

will generate.

•

Une

folding-permits

the

PAD

to

automatically insert

appro-

priate

format

effectors

in

the

character stream sent

to

the

asyn-

chronous terminal.

No

line

folding

or a predetermined

maxi-

mum

number of graphics characters per

line

may

be selected.

• Binary

speed-a

read-only parameter that neither

DTE

can

change.

It

enables the packet

mode

D1E

to

access a character-

istic

(known

by

the

PAD)

of the

asynchronous

terminal device.

Speeds

from

50

bps

to

64K

bps

are

represented.

• Flow control

of

the

PAD

by the startIstop mode DT&-gov-

ems

flow

control between the

asynchronous

terminal

and

the

PAD.

The asynchronous

terminal

transmits special characters

to

indicate whether it

is

ready

to

accept characters

from

the

PAD.

In

lAS,

these special characters switch

an

ancillary trans-

mit

device

on

and

off.

Decimal

0 represents

no

use of

X-on

(DCI)

and

X-off

(DC3);

decimal 1 represents

use

of

X-onlX-

off.

• Line-feed insertion after carriage return-permits the

PAD

to

automatically insert a line-feed character

in

the character

stream

sent

to

or received

from

the asynchronous terminal or

@ j

994

McGraw-Hili,

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Selvices

Group.

Delran

NJ08075

USA

'<

......

_-

Data

Networking

ITU·TSS

Packet

Swltolled

Networking Standards

X

..

rI

••

2790

Standards

3

Table

1.

TSS

Recommendatlons-XSerie.

TSS

Recommendation

X.1

X.2

X.3

X.4

X.20

X.20

bis

X.21

X.21

bis

X.24

X.25

X.26

X.27

X.28

X.29

X.32

X.75

X.92

X.95

X.96

X.121

Description

International user classes

of

service

in

public

data

networks:

class

8 (2400 bps); class 9

(4800

bps);

class

10

(9600

bps);

or

class

11

(48,000

bps)

International user facilities

in

public data

networks

Packet

assembly/disassembly

(PAD)

facility

in

a

public

data network; lists options

and

defaults

for

interactive asynchronous terminal connection to

X.25

packet networks

General

structure of signals of International

Alphabet

NO.5

(IA5)

code

for

data transmission over public

data

networks

(IA5

is

described

in

TSS

V.3)

Interface

between

data terminal equipment

(DTE)

and

data

circuit-terminating equipment

(DCE)

for

async

transmission services

on

public data

networks

V.21-compatible

interface

between

DTE

and

DCE

for

async

transmission services

on

public

data

network

General-purpose interface

between

DTE

and

DCE

for synchronous operation

on

public data

networks

For

use

on

public data networks

by

DTE

that

are

designed

to interface to synchronous

V-Series

modems

List

of

definitions of interchange circuits

between

DTE

and

DCE

on

public data networks

Interface

between

DTE

and

DCE

for

terminals

operating

in

the

packet

mode

on

public data

networks

Electrical characteristics

for

unbalanced double-current interchange circuits

for

data

communications

equipment

Electrical

characteristics

for

balanced double-current

interchange

circuits

for

data communications

equipment

DTElDCE

interface

for

asynchronous device

access

to

the

PAD

facility of a public

data

network

in

the

same

country

Procedure

for

the

exchange

of

control

information

and

user

data

between

a packet

mode

DTE

and

a

PAD

facility

Procedure

for

communications

between

users

and

packet networks

through

the

switched telephone

network

and

through circuit switched public

data

networks

Expanded

X.25

recommendation

for

internetwork

communications

between

packet switched

networks;

interface

is

defined

between

two

STEs

(Signaling

Terminal

Equipments)

that are a part of

ISDEs

(International

Data

Switching

Exchanges),

with

expanded

support for wideband

links,

extended

sequencing,

and

an

expanded

network

utility

field

for international call establishment

Hypothetical reference connections

for

public

synchronous

data networks

Network

parameters

in

public data networks

Call

progress signals

in

public data networks

International numbering

scheme

for

multinetwork communications containing a 4-digit

DNIX

(Data

Network

Identification

Code),

3-cligit

area

code,

5-digit

host identification, a 0- to 2-digit subaddress

after echo of each carriage return character. This function

ap-

plies only

in

the data transfer state. • Echo

mask-when

echo

is

enabled, echo mask designates

that

selected defined groups of characters sent

by

the asynchronous

terminal are not transmitted back. The following

may

be

se-

lected:

no

echo

mask;

no

echo of

CR;

no

echo of

LF;

no

echo of

VT,

HT.

and

FF;

no

echo

of

BEL and

BS;

no

echo of

ESC

and

ENQ;

no

echo of

ACK,

NAK,

STX. SOH, EOT, ETB,

and

ETX;

no

echo of editing characters; or

no

echo of

all

other

characters.

• Line-feed padding-permits

the

PAD

to automatically insert

padding characters

in

the character stream transmitted

to

the

asynchronous terminal after

the

occurrence of a line-feed char-

acter.

This

enables

the

asynchronous terminal printing mecha-

nism

to

perform the line-feed operation correctly. This function

applies

only

in

the data transfer state.

• Editiog-enables character delete, line delete, and line display

editing capabilities. During

the

PAD

command state, the edit-

ing

function

is

always available;

use

or nonuse

of

the editing

function

in

the

data transfer state

is

selectable.

• Character delete,

Hne

delete, and line

display-all

editing

functions represented

by

one user-selectable character

from

lAS.

• Editing

PAD

service signals-enable

the

asynchronous termi-

nal

to

edit

PAD

service signals

for

printing devices and display

terminals; also

used

for editing via

one

character

from

lAS.

Editing

is

not selectable.

@

1994

McGraw-Hili.

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

• Parity treatment-permits the

PAD

to check parity

in

the

datastreanl

from

the asynchronous terminal andlor generate

parity

in

the datastream to the asynchronous terminal.

No

par-

ity checking or generation, parity checking, or parity genera-

tion are selectable.

• Page wait-allows the

PAD

to

suspend transmission of

addi-

tional characters

to

the asynchronous terminal after the

PAD

has

transmitted a specified number of line-feed characters.

Recommendation

X.28

TSS

Recommendation X.28, titled DTEIDCE Interface for a

Start/Stop Mode Data Terminal Equipment Accessing the Packet

FEBRUARY

1994

4

2790

Standards

Assembly/Disassembly Facility

(PAD)

in

a Public Data Network

Situated

in

the

Same

Country, describes the interfacing proce-

dures that allow the PAD to be connected to an asynchronous

tenninal. X.28 covers four areas:

• Procedures to establish an access infonnation path between an

asynchronous tenninal and a PAD;

• Procedures for character interchange and service initialization

between an asynchronous tenninal and a PAD;

• Procedures for the exchange

of

control infonnation between an

asynchronous tenninal and a PAD; and

• Procedures for the exchange

of

user data between an asynchro-

nous tenninal and a PAD.

Modems standardized for use on public switched

or

leased line

facilities establish the procedures for providing an access path

(DTFJDCE interface). Procedures for both V and X Series inter-

faces are defined.

Transmission speeds up to 1200

bps

are specified for V-Series

interfaces; they are in accordance with either the V.21, V.22,

or

V.23

standard, depending on facility type and speed. The V-Series

specifications define the procedures for setting up and discon-

necting the access infonnation path by both the DTE and the

PAD.

X-Series interfaces also are used with switched

or

leased line

facilities. The physical characteristics for the DTFJDCE interface

are specified in X.20

or

X.20 bis. Procedures for setting up and

disconnecting the path by both the DTE and the PAD are defined.

X.28 specifies procedures for character interchange and ser-

vice initialization between an asynchronous tenninal and a PAD.

Characters sent and received must confonn to lAS. The PAD

transmits and expects to receive only eight-bit characters. The

eighth bit, the last bit preceding the stop element, is used for

parity checking.

X.28 describes the action the PAD takes when the value

of

parameter

21

(X.3, parity treatment) is set to 0,

1,

2,

or

3.

If

parameter

21

is set to 0, the PAD inspects only the first seven bits

and ignores the eighth bit. When parameter

21

is set to

1,

the PAD

treats the eighth bit

of

the character as a parity bit and checks this

bit against the type

of

parity-odd,

even, space (0),

or

mark

(1}-

used between the PAD and the asynchronous tenninal.

If

it is set

to 2, the PAD replaces the eighth bit

of

the characters to be sent to

the tenninal with the bit that corresponds to the type

of

parity

used between the PAD and tenninal. When the value is set to 3,

the PAD checks the parity bit for characters received from the

asynchronous tenninal and generates the parity bit for characters

to be sent to the asynchronous tenninal (as in values 1 and 2).

Once the access infonnationpath is established, the asynchro-

nous tenninal and the PAD exchange binary 1 across the inter-

face. This places the interface in the active link state (state

1).

When the interface is in the active link state, the DTE transmits a

sequence

of

characters that indicates service request (state 2) and

initializes the PAD. The service request pennits the PAD to detect

the data rate, code, and parity used by the asynchronous tenninal

(DTE) and to select the initial profile

of

the PAD. The service

request may be bypassed,

if

the tenninal is connected to the PAD

via a leased line and the PAD knows the speed, code, and initial

profile

of

the tenninal

or

if

a default value is used. After the

request service signal is transmitted, the DTE transmits binary

1,

which places the interface in the DTE

waiting

state (state 3A).

If

parameter 6 (X.3, control

of

PAD service signals) is set to 0, the

interface immediately enters the

PAD

waiting

state (state S) after

receipt

of

service request.

If

parameter 6 is set to other than 0, the

FEBRUARY

1994

ITU·

TS$

Packet

Swltc"eeI

Networking

Stanclards

x

SerIes

Data

Networking

PAD transmits the

PAD

identification

PAD

service signal (indi-

cates PAD and port identity; is network dependent), and the inter-

face enters the service

ready

state (state 4). The DTE then trans-

mits a selection

PAD

command signal (state 6), and the PAD

transmits an acknowledgment

PAD

service signal, followed by

binary

1,

which places the interface in the connection-in-progress

state (state 7).

If

parameter 6 is 0, the PAD will not transmit PAD service

signals. In this case, the interface is placed in the connection-in-

progress state after receipt

of

a valid selection PAD command

signal.

Once the DTE receives the PAD service signal (state 8)

or

a

sequence

of

signals in response to a PAD command signal, the

interface is placed in either the PAD waiting state (state

S)

or

the

data transfer state (state 9).

Afault condition exists

if

a valid service request signal is not

received by the PAD within a selectable number

of

seconds after

the transmission

of

binary

1.

If

a fault condition occurs, the PAD

perfonns clearing by disconnecting the access infonnation path.

The procedures for the exchange

of

control infonnation be-

tween an asynchronous tenninal and a PAD include

PAD

com-

mand signals,

PAD

service signals,

break

signals, and prompt

PAD

service signals. PAD command signals flow from the DTE

to the PAD; they set up and clear a virtual call, select a standard

profile (pAD parameters) that is either ITU-TSS

or

network de-

fined, request current values

of

PAD parameters, send an interrupt

requesting circuit status, and reset a virtual call. PAD service sig-

nals flow from the PAD to the DTE; they transmit call progress

signals, acknowledge PAD command signals, and transmit oper-

ating infonnation

of

the PAD to the tenninal. Either the PAD

or

the tenninal can transmit the break signal.

It

provides signaling

without losing character transparency. The prompt

PAD

service

signal indicates the PAD's readiness to receive a PAD command

signal.

The temporary storage

of

characters in an editing buffer pro-

vides editing functions in the PAD. These functions

pennit

the

asynchronous tenninal to edit characters input to the PAD before

the PAD processes them. They include character delete, line de-

lete, and line display. Character delete removes the last character

in the editing; line delete removes the contents

of

the editing

buffer. Line display causes the PAD to send a fonnat effector

followed by the contents

of

the editing buffer to the tenninal.

Procedures for the exchange

of

user data between an asyn-

chronous tenninal and a PAD apply during the data transfer state.

The values

of

the parameters set in X.3 detennine which charac-

ters are transmitted during the data transfer state.

For

example,

if

parameters 1 (pAD recall using a character),

12

(flow control

of

the PAD by the start/stop mode DTE),

IS

(editing), and 22 (page

wait) are set to 0, any character sequence may be transmitted by

the asynchronous tenninal for delivery to the remote DTE during

the data transfer state.

User data is sent to the asynchronous tenninal in octets (eight-

bit characters) at the appropriate transmission rate for the asyn-

chronous tenninal; the start/stop bits are added to the data char-

acters. Octets are assembled into packets (see X.2S) and

forwarded when enough data has been received to fill a packet,

when the maximum assembly timer delay period has elapsed,

when a data forwarding character

is

transmitted,

or

when a break

signal is transmitted (parameter 7 is set to other than 0).

Recommendation

x.a

TSS Recommendation X.29, titled

Procedures

for

the

Exchange

of

Control Information and

User

Data

Between a Packet Assem-

bly/Disassembly Facility

(PAD)

and a Packet

Mode

DTE or An-

other

PAD,

provides the final step. X.29 describes the interfacing

procedures that allow the PAD to communicate with the X.2S

@

1994

McGraw-Hili.

Incorporated.

Reproduction

Prohibited.

Datapro

Infonnatlon

Services

Group.

Delran

NJ

08075

USA

('

Data

Networking

ITU-TIS

PIIcket

SWitched

Networkl

...

Standards

X

Series

network.

It

defines the procedures for

the

exchange

of

PAD

con-

trol infonnation and the manner

in

which

user data is transferred

between a packet mode DTE

and

a

PAD

or between two PADs.

Recommendation X.29 specifies that control infonnation and

user data

are

exchanged between a

PAD

and

a packet mode DTE

or between

PADs

using the data fields described in

X.2S.

Inter-

face characteristics-mechanical, electrical, functional, and pro-

cedural-are

also defined

as

in

X.2S.

X.29 specifies that the call

user

data

field

of

an

incoming

call

or call

request

packet going to/from the

PAD

or the packet mode

DTE must consist of protocol identifier

and

call data fields. A call

request packet need not contain a call user data field to be

ac-

cepted

by

the

PAD.

If

the call user data

field

is

present, the

PAD

transmits it, unchanged, to its destination.

A call data field's octets consist

of

user characters sent from

the DTE to the

PAD

during the call establishment phase. This

field

is

limited

to

12

octets. The octet's bits

are

numbered 8 to

I;

bit I, the

low

order bit,

is

transmitted first.

Bits 8, 7, 6, and S of octet 1

of

a user data field

of

complete

packet sequences

are

the control identifier field. This field, which

consists

of

four octets, identifies the facility to

be

controlled. The

control identifier field coding for messages

to

control a

PAD

for

an asynchronous tenninal

is

0000.

When

the

control identifier

field is set to 0000, bits

4,

3,

2,

and 1 of octet 1

are

defined as the

message code field, which

is

used to identify specific types of

PAD

messages.

User

sequences

perfonn data exchange. They are transferred

in

the

user data fields of complete packet sequences with the Q bit

set to

O.

Only one user sequence exists per complete packet se-

quence. The

PAD

transmits all data packets with the D bit set to

O.

The DTE sends a data packet to the

PAD

with the D bit set

to

1.

When the

PAD

receives

a data packet with the D bit set

to

I, it

sends the corresponding acknowledgment. The

PAD

may

reset

the

virtual call,

if

it does not support

the

D bit procedure.

Table

2.

TSS

X.21

Interchange

Circuits

Interchange Name

Circuit

G

Signal

ground

or

common

return

Ga

DTE

common

return

Gb

DCE

common

return

T

Transmit

R

Receive

C

Control

Indication

S

Signal

element

timing

B

Byte

timing

Direction

to

DCE

from DeE Circuit

X

X

X

X

X

Type

Ground

Data

Transfer

X

Control

X

X

Timing

C

1994

McGraw-Hili.

Incorporated.

Reproduction

Prohibited.

Datapro

Infonnatlon

Services

Group.

Delran

NJ

08075

USA

2790

Standards

5

Control infonnation

is

exchanged via

PAD

messages,

which

contain a control identifier field and a message code

field

that

may be followed

by

a parameter field.

PAD

messages

are

trans-

ferred in the user data fields of complete packet sequences with

the Q bit set to

1.

Only one

PAD

message exists per complete

packet sequence. The

PAD

sends

all data packets with the D bit

set to

O.

The DTE

may

send data packets to the

PAD

with both the

D bit and

the

Q bit set to I. When the

PAD

receives

a data packet

with both the Q and D bits set to

1,

the corresponding acknowl-

edgment

is

transmitted. The

PAD

may reset the virtual call if it

does not support the D bit procedure. (Figure S shows the bit

positions

for

the Q and D bits.)

The

PAD

forwards a data packet when a

set,

read,

or set and

read

PAD

message is received or when

any

of

the

conditions

listed

in

X.28

exist (e.g., enough data has been received to fill a

packet, the maximum assembly timer delay period

has

elapsed, or

a data forwarding character is transmitted). The

PAD

never for-

wards

an

empty Data packet.

By sending a

set,

read,

or set and

read

message to the

PAD,

. one can

read

and change the current values

of

PAD

parameters.

Upon receipt

of

one

of

these messages, the

PAD

delivers

to

the

DTE

any

previously received data before it acts on the

PAD

mes-

sage. The

PAD

responds to a

read

or

set and

read

PAD

message

by

sending a parameter

indication

PAD

message, which contains

a parameter field listing parameter references and current values.

Set allows the changing of parameters.

X.29 also discusses

invitation

to

clear procedures, which are

used

to

request that the

virtu",1

call be cleared

by

the

PAD;

inter-

rupt

and

discard

procedures, which are used

to

indicate that the

asynchronous tenninal has requested that the

PAD

discard re-

ceived user sequences; reset procedures,

as

defined

in

X.25;

error

handling

procedures

by

the

PAD,

which define the actions to be

taken

by

the

PAD

when errors

are

detected; and

procedures

for

inviting

the

PAD

to

reselect

the

called DTE (optional),

which

are

used

by

a packet mode DTE

to

request that the

PAD

clear the

virtual call.

X.21

Interface

Specifications

The trends

in

communications engineering lean toward all-digital

networks and the integration of voice and data. Prospective users

of

these digital, integrated networks

are

concerned about

an

inter-

face that can provide access to voice, data, video teleconferenc-

ing,

and

related services. Currently, a wide variety

of

connectors,

electrical standards, and user procedures for various services and

networks exists-leading to almost insunnountable technical and

economical problems. Therefore, it is likely that standards orga-

nizations will develop a universal service

access

interface.

Al-

though it would require certain extensions,

X.21

is

currently the

most likely to become a future standard for a universal interface

in

distributed system implementations.

TSS

Recommendation X.21, Interface

Between

Data

Termi-

nal

Equipment

(DTE)

and

Data

Circuit-Terminating

Equipment

(DCE)

for

Synchronous

Operation

on

Public

Data

Networks,

de-

fines the physical characteristics and control procedures for an

interface between DTEs and DeBs.

X.21

is

the designated interface for TSS Recommendation

X.2S,

a packet-switching protocol.

X.21

can also be used

in

a

non-packet switched environment. At least

two

X.21-based pub-

lic data circuit switched networks

are

currently implemented, one

in

Scandinavia and one

in

Japan.

The

X.21

standard has not gained wide acceptance

in

the

United States. The reluctance

in

the U.S.

to

embrace the

X.21

standard

is

due

in

part to the finn entrenchment

of

RS-232-C.

Another factor is the cost of implementing X.21. Since

X.21

FEBRUARY

1994

6

2790

Standards

transmits and interprets coded character strings, more intelligence

must be built into the interface, at a higher cost than traditional

pin-per-function. interfaces.

Certain characteristics

of

X.21 should ensure a more wide-

spread acceptance in the coming years. One immense advantage

X.21 has over traditional interfaces is its capability to assign an

almost unlimited number

of

functions, because there are

no

func-

tional boundaries associated with connector size. Also, X.21 of-

fers a much more sophisticated level

of

control over the commu-

nications process. Another important feature

of

X.21 is its

inherent dialing functions, including the provision for reporting

the reasons why a call was not completed. This eliminates the

need for a separate data call interface, such as RS-232-C's com-

panion RS-366-A, and in switched facilities, results in improved

response times.

Another important aspect is its relationship to X.25. As the

packet-switching technique becomes more widely implemented,

the demand will be greater for equipment to meet the

X.2l

stan-

dard. Internationally, the combination

of

X.2l,

the ISO HDLC

protocol, and X.25 has been used to form an effective communi-

cations path. Another boost for X.21

is

IBM's

recognition.

X.2l

has some. shortcomings.

It

does not permit the transmis-

sion

of

control information during data transfer. Also, it precludes

the insertion

of

data encryption hardware between the

DTE

and

the DCE. Another drawback is the need to modify the DTFJDCE

master/slave protocol techniques and to supply special crossover

cables to facilitate DTE-to-DTE

or

DCE-to-DCE interconnec-

tion.

X.21 uses a different interfacing technique than that which is

normally associated with physical-level interfaces. Instead

of

as-

signing each function a specific pin on the connector (e.g., Y.24

and EIA RS-232), X.21 assigns coded

character

strings to each

function.

The following is a summary

of

the X.21 standard, including

the functional descriptions

of

the interchange circuits, phases

of

operation, electrical characteristics, and mechanical characteris-

tics.

Functional Descriptions

of

Interchange

Circuits

Four types

of

X.21 interchange circuits are defined: Ground, Data

Transfer, Control, and TIming. These circuits, outlined in Table

2,

are described below.

Ground

and

Common

Return

Circuits-include

two types

of

common return circuits, DTE Common Return and

DeE

Com-

mon Return, and one ground circuit, Signal Ground.

Signal Ground (Circuit G) establishes the common reference

potential for unbalanced double-current interchange circuits.

If

required, it reduces environmental signal interference.

Lowering signaling rates may require two common return

conductors. In this case, two circuits, DTE Common Return (Cir-

cuit Ga) and

DCE

Common Return (Circuit Gb), are necessary.

For

a further explanation

of

these circuits, see the Electrical Char-

acteristics section

of

this report.

Data

Transfer

Circuits-include

two Transmit and Receive

data transfer circuits.

Transmit (Circuit

T)

transfers signals from the

DTE

to the

DeE

during the data transfer phase.

It

also transfers call control

signals to the

DeE

during call establishment and other call con-

trol phases.

Receive (Circuit

R)

receives signals transmitted by the

DeE

from a remote

DTE

during the data transfer phase. This circuit

also transfers call control signals from the

DeE

during the call

establishment and other call control phases.

Control

Circuits-include

Control and Indication circuits.

Control (Circuit C) transmits signals that control the

DeE

for

a particular signaling process. The representation

of

this signal

requires additional coding

of

the Transmit circuit, as specified for

FEBRUARY

1994

ITU-TSS

Packet

Switched

Network

....

Standards

X

.......

Data

Networking

the procedural characteristics

of

the tnterface. During the data

phase, Circuit C remains in the ON condition.

Indication (Circuit

1)

indicates the call control process to the

DTE. The representation

of

this signal requires additional coding

of

the Receive circuit. When Circuit I is on, it signifies that sig-

nals

on

the Receive circuit contain information from the remote

DTE. When Circuit I is off, it signifies a control signaling condi-

tion, defined by the Circuit R bit patterns, as specified by the

procedural characteristics

of

the interface.

Timing

Circuits-includes

Signal Element TIming and Byte

TIming.

Signal Element TIming (Circuit S) provides the DTE with sig-

nal element timing information.

For

this function, Circuit S turns

on

and off for nominally equal periods

of

time.

X.21 defines different roles for the

DTE

and

DeE

in regard to

signal element timing. During the off-ta-on transition, the

DTE

presents a binary signal

on

Circuit T and a condition

on

Circuit C.

The

DCE

presents a binary signal on Circuit R and a condition on

Circuit I during the off-to-on transition. The

DeE

transfers the

signal element timing across the interface as long as the timing

source is capable

of

generating this information.

Byte TIming (Circuit B) provides the DTE with eight-bit tim-

ing information for synchronous transmission. Use

of

this circuit

is not mandatory. Circuit B turns

off

whenever Circuit S is in

$e

ON condition, indicating the last bit

of

the eight-bit byte.

At

all

other times within the period

of

the eight-bit byte, Circuit B re-

mains on.

Phases

of

Operation

The

X.2l

standard defines four phases

of

operation: the Quies-

cent Phase, the Call Control Phase, the Data Transfer Phase, and

the Clearing Phase.

Each step

of

the operational phases places the

DTE

and

DCE

in a certain state. See Table 3 for a listing

of

these states and their

associated signals

on

the interchange circuits.

Quiescent

Phase-the

quiescent phase is the period during

which the

DTE

and the

DCE

signal their capability to enter the

call control phase

or

the data transfer phase. It

is

characterized by

the appearance

of

basic quiescent signals from the DTE and

DeE.

Various combinations

of

these quiescent signals result in different

interface states,

or

quiescent states.

There are three

DTE

quiescent signals. DTE Ready indicates

the readiness

of

the

DTE

to enter the other operational phases.

DTE Uncontrolled

Not

Ready indicates the DTE

is

incapable

of

entering certain operational phases, usually due to an abnormal

condition.

DTE

Controlled Not Ready indicates that although the

DTE

is operational, it is temporarily incapable

of

accepting in-

coming calls for circuit switched service.

There are two

DeE

quiescent signals:

DeE

Ready and DCB

Not Ready. DCE Ready indicates the

DCE

is ready to enter op-

erational phases.

DCE

Not Ready indicates that no service is

available; it is also signaled whenever possible during network

fault conditions and during the period when test loops are acti-

vated.

There are six quiescent states:

• Ready

• DTE Controlled Not Ready,

DCE

Ready

• DTE Ready,

DCE

Not Ready

•

DTE

Uncontrolled Not Ready,

DCE

Not Ready

•

DTE

Controlled

Not

Ready,

DCE

Not Ready

• DTE Uncontrolled Not Ready,

DCE

Ready

See Figure 1 for a diagram

of

the quiescent states and the transi-

tions that are allowed between these states.

@

1994

McGraw-HUI,

Incorporated.

Reproduction

PrOhibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

"'-

(-

Data Networking ITU·TSS

hcket

Switched

NetwOl'klng S

..

ndllrda

X

Serle.

Table

3.

X.21

States:

Names,

Signalling, and Transitions

Signals

on

T,C

and

ft,'

Circuits

Phase

of

State

Opera-

Number

State

Name

tlon T C R

1 Ready a 1 OFF OFF

2

call

request CC 0 ON OFF

3 Proceed-to-select CC 0 ON + OFF

4 Selection signal CC

1A5

ON + OFF

5 DTEWaiting CC

.ON

+ OFF

6A DCEWaiting CC ON SYN OFF

6B DCEWaiting CC 1 ON SYN OFF

7 Call progress signal

CC

1 ON IA5 OFF

8 Incoming call CC 1 OFF BEL OFF

9 Call accepted CC 1 ON BEL OFF

10 DCE provided information CC 1 ON

1A5

OFF

10

bis

DCE provided information CC 1 ON

1A5

OFF

11

Connection in progress CC 1 ON 1 OFF

12 Ready for data CC 1 ON 1 ON

13 Data transfer DT D ON D ON

13R Receive data DT 1 OFF D ON

13S Send data

ET

D ON OFF

14 DTE Controlled not ready, DCE

ready a

01

OFF 1 OFF

15 Call collision CC 0 ON BEL OFF

16 DTE Clear request C 0 OFF X X

(see

Note)

17 DCE Clear confirmation C 0 OFF 0 OFF

18 DTE Ready, DCE Not ready a 1 OFF 0

OFF

DCE Not ready a D ON 0 OFF

19

DCE Clear indication C X X 0 OFF

(see

Note)

20 DTE Clear confirmation C 0 OFF 0 OFF

21

DCEReady

C 0 OFF 1 OFF

22 DTE Uncontrolled not ready, DCE

not ready a 0 OFF 0 OFF

23 DTE Controlled not ready, DCE not

ready a

01

OFF 0 OFF

24 DTE Uncontrolled not ready, DCE

ready a 0 OFF OFF

Any

state

(see

Note) X X X X

"All

other

transitions

are

considered

Invalid.

Note:

DCE

Clear

indication

or

DTE

Clear

request

may

be

entered

from

any state

except

Ready.

Key

to

Table:

Q-Qulescent

Phase

CC-CaI1

Control

Phase

DT

-Data

Transfer

Phase

T -Transmit

interchange

circuit

c;.control

Interchange

circuit

R-Receive

Interchange

circuit

/-Indication

interchange

circuit

o

1994

McGraw-HiIl,

Incorporated.

Reproduction

ProhibHed.

Datapro

Information

SeMces

Group.

Delran

NJ

08075

USA

o and 1-8teady binary

conditions

01-Alternate binary 0 and

binary

1

X-Any

value

OFF-Continuous

off

(binary

1)

ON-Continuous

on

(binary

0)

lA5-Characters from

CCITT

Alphabet #5

+-IA5 character

2111

BEL-IA5 character

017

SYN-IA5

character

1/6

DTE

to

state

number

2,138,14,24

4,15

5

15,9

13R

13

7

1,24

22

20

18

18,22

16

27"

Standards

Transitions'

DeE

to

state

number

8,13R,18

3,15

6A,11,12

7,10,11,12

10bis, 11,12

6A,10,11,12

68,11,12

6A,11,12

6B,11,12

12

13

13S,DCE

not ready

1

13

23

3

17

21

1

1,13,13S

21

24

14

22

19

7

FEBRUARY

1994

8

Fi;tue

1.

flrM,eMt

S,.,.,

OCE OCE

ITU-TSS

Pllcket

.wlto

.....

Network

....

·_

....

x .......

DCE

Data

Networking

n Stale number

I Signel on T circulI

c Signal on C circuit

Signal on R clrcuH

Signal on I circuit

-

'

TranSition with Indlcation

of

whether DTE

or

OCE

Is responsible fer lransltion

The

above

diagram

indicates transitions that

are

allowed in

X.21

networks.

Other

transitions

are

possible and

may

be

allowed in

some

networks.

See

Table

J for a listing o/possible

transitions.

Call Control

Phase-the

call

control

phase

for

circuit

switched·

service contains

many

elements

and

procedures.

Char-

acters

used.

for

call control

are

selected

from

lAS,

a seven-bit plus

parity international

code

outlined

in

TSS

Recommendation

V.3.

Each

call

control sequence to

and

from

the

DeE

is preceded

by

two

or

more

continuous

SYN

characters.

For error checking

of

call

control

characters,

odd

parity

is

specified.

The

following

elements of

the

call

control

procedure

are

out-

lined

in

X.21:

events

of

call

control

procedures,

unsuccessful call,

call collision, direct call,

and

facility

registration/cancellation

procedure. These elements are

summarized

below.

The

events

of

the call control

procedures

include

the

follow-

ing:

• Call Request, signaled

by

the

DTE

to

indicate a request

for

a

calI;

•

Proceed

to

Select,

used

when

the

network

is

prepared to receive

selection information.

It

is

transmitted

by

the

DCE

to the DTE

within

three

seconds

of

the

call

request

signal.

•

Selection

Signal Sequence,tranStnitted

by

the

DTE.

A selection

sequence

consists

of

a

facility

request

block,

an

address

block,

a

facility

request block

followed

by

an

address

block, or a

fa-

Cility

registration/cancellation

block.

A

facility

request block

comprises

one

or morefacility

request

signals,

which

consist of

feBRUARY

UI94

a

facility

request

code

containing

one

or

more

facility

param-

eters.

An

address

block

contains

one

or

more

address

signals.

Address

signals

consist of either a

full

address

signal

or

an

abbreviated

address

signal.

•

DTE

Waiting.

•

Incoming

Call,

indicated

by

the

DCE.

In

response,

the

DTE

signals

Clear

Request,

DTE Uncontrolled

Not

Ready,

or

DTE

Controlled

Not

Ready.

•

DCE

Waiting.

• Call

Progress

Signal

Sequence

is

transmitted

by

the

DeE

to

the

calling

DTE

to

indicate that circumstances

have

arisen to

pre-

vent

the

connection

from

being

established,

to

report

the

progress

made

toward

establishing

the

call, or to

signal

that

problems

have

been

detected

and

that

the

call

needs

to

be

cleared

and

reset.

•

DCE-Provided

Information

Sequence,

transmitted

from

the

DeE

to

the

calling

DTE.

It

consists of DeE-provided

informa-

tion

blocks,

such

as

line identification

and

charging

informa-

tion.

Line

IdentificatiOn

is

transmitted

by

the

DeE

to

the

call-

ing

DTE

during

the

DCE-Provided

Information

state

immediately

after

all

call

progress signals, if

any,

are

transmit-

ted.

Both

calling

and

called line identification are

optional.

Line

identification

consists of the international data

number,

as

assigned

in

TSS

Recommendation

X.121,

International

Num-

bering

Plan

for Public

Data

Networks.

The

DeE

transmits

Charging

Information

during

the

DeE-Provided

Information

C 1994

McGraw-HIH.

Incorporated. Aeproductlon Prohibited.

Datapro Information Services

Group.

Delran

NJ

08075 USA

/

(-

Data

Networking ITU·TSS

Packet

Switched

Networking

Sblndanl.

X..,le.

state.

It

informs the subscriber

of

either the monetary charges

for a call, the duration

of

the call,

or

the number

of

units used

during the call.

• Connection-In-Progress, indicated by the DCE.

• Ready for Data, transmitted by the DCE when the connection

is available for data transfer between DTEs.

An unsuccessful call occurs when a required connection cannot

be established. In this case, the DCE indicates the failure and its

reason to the calling DTE through a call progress signal.

A call collision can occur in one

of

two ways: a DTE detects a

call collision when it receives Incoming Call in response to Call

Request. A DCE detects a call collision when it receives Call

Request in response to Incoming Call. When

theDCE

detects a

call collision, it will indicate Proceed to select and cancel the

incoming call.

The

DTE

indicates a request for a direct call by signaling DTE

Waiting after receiving the Proceed to Select signal.

If

necessary,

the DTE may choose an addressed call by presenting the correct

Selection signal.

The facility registration/cancellation procedure is optional. A

facility registration/cancellation signal consists

of

up to four ele-

ments in order: facility request code, indicator, registration pa-

rameter, and address signal. Not all

of

these elements are required

in the facility registration/cancellation signal. Also, a number

of

these signals may be linked to form a block. In response to accep-

tance or rejection

of

the facility registration/cancellation action,

the network provides the appropriate Call Progress Signal.

Data

Transfer

Phase-when

the DTE is in the data transfer

phase, any bit sequence may be transmitted. X.21 defines the data

transfer phase for three types

of

connections: switched; leased,

point to point; and leased, centralized multipoint.

Table

4.

X.21 Pin Assignments

Pin

Employing

Employing

Number

X.26 X.27

See

Note

(3)

See

Note

(3)

9 Ga

T(B)

2 T T(A)

10 Ga

C(B)

3 C

C(A)

11

R(B)

R(B)

4

R(A) R(A)

12

I(B) I(B)

5 I

(A)

I

(A)

13

S(B) S(B)

6

SeA) SeA)

14

B(B) B(B)

7

B(A) B(A)

15

Reserved

for

Reserved

for

future

use

future

use

8 G G

Notes:

(1)

X.21

pin

assignments

are

defined by

ISO

4903-1980.

(2)

Where

balanced ciruits

are,

the

associated pairs are

designated

"A" and

"B.

"

(3)

Pin

1 is

reserved

for

connection

of

the

shield or shielded

interconnecting

cable.

@

1994

McGraw-Hili,

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

2790

Standards

9

For operation over switched facilities, the

DTE

may send bits

to a corresponding

DTE

after receiving the Ready for Data signal.

During data transfer, control and interchange circuits are in the

ON condition, and data is transmitted over the transmit and re-

ceive circuits. Data transfer may be terminated by clearing,

which is defined below.

Two basic signals are used for operation over leased, point-to-

point facilities. Send Data transmits data by the DTE on Circuit

T;

the remote

DTE's

Receive Data signal receives data over Circuit

R.

To terminate the data transfer, the DTE signal places its trans-

mit circuit in the binary 1 condition. The

DCE

indicates termina-

tion

of

data transfer by placing its receive circuit in the binary 1

condition, its control circuit in the

OFF

condition, and its indica-

tions circuit in the

OFF

condition.

Both the central and remote DTEs use the Send Data and Re-

ceive Data signals for operation over leased, multipointfacilities.

The central

DTE

delivers data transmitted

to

all remote DTEs;

remote DTEs (one at a time) transmit data to the central DTE. A

remote DTE may send data to the central DTE while the central

DTE is sending to all remote DTEs.

Clearing

Pbase-either

the

DTE

or

the DCE may initiate

clearing. The

DTE

indicates its desire to enter the clearing phase

by transmitting

DTE

Clear Request. The

DCE

responds by sig-

naling DCE Clear Confirmation, followed by DCE Ready.

Clearing by the

DCE

takes place when it transmits DCE Clear

Indication. The DTE responds with the DTE Clear Confirmation

signal, followed by the

DCE

signaling DCE Ready.

Electrical

Characteristics

X.21 uses two types

of

electrical characteristics, each for different

system requirements.

For synchronous operation at 9600 bps and below, the inter-

change circuits at the

DCE

side

of

the interface must comply with

TSS Recommendation X.27. The

DTE

side can comply with ei-

ther X.27

or

another TSS Recommendation, X.26. For synchro-

nous operation at signaling rates above 9600 bps, interchange

circuits at both the

DTE

and DCE sides

of

the interchange circuits

must comply with X.27.

X.26 is defined in TSS Standard V.lO.

It

describes the electri-

cal characteristics for unbalanced interchange circuits. X.26 calls

for both a DTE and

DeE

common grounding arrangement. The

maximum suggested cable length is 1,000 meters, and the maxi-

mum data rate is

lOOK

bps.

X.27 is defined by TSS Standard V.II, which describes the

electrical characteristics for balanced operation. Maximum sug-

gested cable length is 1,000 meters, and the maximum data rate is

10M bps.

Mechanical

Characteristics

The mechanical characteristics for X.21 are outlined in the ISO

Standard 4903, approved by the International Organization for

Standardization (ISO).

The

standard, entitled Data Communica-

tion-15-pin

DTEIDCE Interface Connector and Pin Assign-

ments, was published in June 1980.

ISO 4903 assigns connector pin numbers to a 15-pin interface

between DTE and

DeE

equipment. Table 4 presents a chart

of

these X.21 pin assignments as they relate to the X.26 and X.27

standards.

X.21 Bis

Although X.21 is the specified interface for X.25, alternative in-

terfaces also exist. One

of

these is X.21 bis.

TSS Recommendation X.21 bis, the physical and functional

equivalent

to

TSS V.24, defines 25 interchange circuits between

DTEs and DCEs. TSS V.24 is compatible with EIA Standard RS-

232-C. The X.21 bis recommendation, accepted as the interim

FEBRUARY

1994

10

27.

Standards

Figure

2.

ITU.TSS Packet Swllc"'ed

Networking

Stan""'"

x SerIes

Data Networking

A Sampl, User T,rmilUll Conjiguration/or Operating on a

Publk

DIltll

N,twork

(PDN) in

PtlCket

Mode,

with X.25 tlS the

Int,r/ac,

to

th,

N,twork

Virtual Circuit

I DTE

Host

Computer

User

Location

DTE

Computer with

X.25 Level 2

and Level 3

Software

Front-

End

Processor

I X.25 Level 2 and 3 Software

DTE

Intelligent

Terminal with

X.25 Level 2

and Level 3

Software

I

I

DTE I

Intelligent

Terminal with

X.25 Level 2

and Level 3

Software

-

-

-

-

-

-I

I

I

I

I

I

-

-

I I

Modem

/'

I I

I

I

I

I

I

./

Modem I

I

I

I

I

I

tI)

E I

G>

"C

0 I

::::E

~

./

G>

)(

G>

I I

C.

:2

::I

I I

::::E

I I

I I

Public Packet-Switching

Network

DCE

-

Modem -Node

Processor

with

X.25

Level 2

and

Level 3

Software

-

Modem -

-

Modem -

r---

~

~

• Signifies an interface that must conform to X.25 Level 2, Physical Interface Standards.

interface for X.2S, will be gradually replaced by

X.21

as more

equipment

is

manufactured to meet

X.21

specifications.

Recommendation

X.25

The development

of

Recommendation X.2S was stimulated by

the need for a standard interface between the packet-switching

networks already developed

or

being developed by many indus-

trial nations and by the requirement that no terminal equipment be

denied access to packet switched services.

X.25 is a dynamic standard with many variations in the U.S.

and abroad. Currently, X.2S-based packet switched networks ex-

ist in Australia, Austria, Belgium, Canada, France, Ireland, Ger-

many, Hong Kong, Italy, Japan, Mexico, the Netherlands, Portu-

gal, Singapore, the Soviet Union, South Africa, Spain,

Switzerland, the United Kingdom, and the United States. Since

X.2S is a dynamic standard with many extensions and optional

features, these networks are not totally compatible with one an-

other. Those located in Europe have the highest level

of

mutual

compatibility.

FEBRUARY

1994

Since the establishment

of

X.2S, additional user-level proto-

cols have been developed. These protocols provide the interfaces

between different types

of

terminals and the X.2S interface. X.3,

X.28, and X.29, informally called the Interactive Terminal Inter-

face (lTI), were the first

of

the protocols to interface to X.2S.

They relate to the support

of

asynchronous, low-speed terminals

by packet switched networks. These are logical complements to

X.2S because they permit specific sets

of

terminals to interface to

the packet networks using the X.2S interface.

The X.2S interface standard provides for the connection

of

terminals and computers to public packet-switching networks.

X.2S outlines three layers

of

operation: the Physical Layer, the

Link Layer, and the Packet Layer. These layers parallel the bot-

tom three layers

of

the ISO Reference Model for Open Systems

Interconnection. The Physical Layer calls for TSS

X.21

as the

physical and electrical interface but accepts X.21 bis, a functional

equivalent

of

RS-232-C, as an interim standard. The Link Layer

uses the procedures

of

the HDLC protocol standard. The Packet

Layer defines procedures for constructing and controlling a data

packet.

@

1994

McGraw-Hili.

Incorporated.

Reproduction

ProhibHed.

Dalapro

Infonnation

Services

Group.

Delran

NJ

08075

USA

/

(

Data

Networking ITU·TSS

Packet

Switched

Networking Standards

X

Series

The 1984 revision

of

Recommendation X.25 added specifica-

tions for X.21 access and expanded the potential

of

packet opera-

tions, allowing users to actively gain access to the X.2S port,

identify themselves, and validate their connection through pass-

words. This change reoriented the X.25 standard toward switched

access through both

X.21

facilities and the public telephone net-

work.

It

now supports X.32 with regard to the public switched

telephone network

or

a circuit switched public data network,

dial-in and dial-out access, backup for leased line connections,

long-distance access to the network, and teletex.

Datagram was deleted in 1984, while the following packet-

level services were made available as options:

• Registered

Private

Operating Agent (RPOA) Selection per-

mits the use

of

one

or

more networks to route a call to its

destination.

If

the user selects only one network, either the ba-

sic

or

extended format

of

the RPOA Selection can be used; if

more than one network

is

chosen, the extended format is used.

• Call Redirection permits the rerouting

of

calls if the first tried

route fails.

• Call Redirection Notification informs the recipient

of

the for-

warded call that the call has been redirected.

• Called

Line

Address Modified Notification tells the caller,

within a call confirmation packet, that the call has been redi-

rected.

•

Hunt

Group

distributes incoming calls that have an address

associated with the hunt group.

•

Charging

Information gives the caller information on time

and charges and requires a new field in the call-clearing packet

format.

• Local

Charging

Prevention is a security facility that prevents

reverse

or

third-party call charges.

• Network User Identification accommodates user ID, billing,

and online facilities registration. This permits users to commu-

nicate directly with the packet data network

to

change the pa-

rameters

of

their subscriptions.

The packet level is an octet-oriented (eight bits per octet) struc-

ture. Packet sizes can vary from 1,024

to

2,048 octets, but only

within a network. Network-to-network exchange is limited to

128

octets. Closed user group facilities can accommodate very large

private-packet networks, although the number

of

closed user

groups to which a

DlE

can belong

is

network dependent. (See

Figure 3.)

Link-level changes implemented

in

1984 created a clear sepa-

ration between the Link Access Procedure (LAP) and the Link

Access Procedure Balanced (LAPB). Multilink procedures for a

single interface were also implemented. LAPB underwent an

alignment with the single-link procedure

of

X.7S. An extended

numbering option (modulo 128) was added to LAPB to enable the

sequencing

of

127 frames and the use

of

satellite facilities. In

addition, the 1984 revisions to X.25 refined the procedure for the

implementation

of

the D-bit, polished technical accuracy, and de-

fined the rules for new fields and formats.

X.25 Communications

X.25 is titled Interface Between Data Terminal Equipment (DTE)

and Data Circuit-Terminating Equipment (DCE)

for

Terminals

Operating in the Packet Mode on Public Data Networks.

It

pro-

vides a precise set

of

procedures for communications between

DTE and DCE for terminal equipment operating in a packet en-

vironment. The DCE in this case is a node processor that serves as

an entry/exit point on the packet network side

of

the user/network

interface.

@

1994

McGraw-HiII,

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

2790

Standards

11

The Data Terminal Equipment is a programmable device on

the user side

of

the user/network interface. The

DlE

is located at

the user site when the onsite equipment supports X.25; at such

installations, the DTE can be either a computer, a front-end pro-

cessor,

or

an intelligent terminal, as shown in Figure 2, The DTE

can be a group

of

intelligent terminals (multiplexed to avoid the

use

of

multiple lines) that transmit data over the packet network

to a remotely located host.

It

can also be a processor acting on

calls received from multiple locations that communicate over the

packet network.

Regardless

of

the device

or

application, all

DTEs

present stan-

dard formatted data and control information to the DCE over

standard communications facilities. Devices operate over the net-

work in the virtual circuit mode. Essentially, the user causes the

network

to

establish a logical circuit connection with the receiv-

ing station for the transmission

of

mUltiple contiguous packets.

(The actual physical circuit over which individual packets are

transmitted can vary during a session, but the logical circuit en-

sures presentation

of

each packet to the receiving station in the

proper order.) Information delivery is so rapid that the user ap-

pears to have an end-to-end, dedicated channel.

Users who do not support X.25 can access the public data

network for packet data transmission; however, they cannot trans-

mit directly to a DCE or network node. They must transmit to a

special network-operated PAD, discussed earlier in this report.

Terminal transmissions are stored in a buffer at the PAD. There

they are assembled into packets and sent to the device at the other

end

of

the virtual circuit. Packets arriving at the PAD from the

network are reassembled into the appropriate format before they

are

sent

on

to the terminal. The

PAD

is programmed and config-

ured to interface properly with the protocol and physical charac-

teristics

of

the user's device. Data presented to the PAD is refor-

matted into X.25 format and forwarded to the DCE.

Recommendation X.2S is divided into those specifications re-

quired for a device

or

network to comply and those that are op-

tional. Approximately one-third are required; the remaining two-

thirds

of

the specifications are optional.

The excess throughput capacity inherent in the X.25 standard

allows for future network growth and technological progress. For

example, a single X.25 interface can theoretically handle 4,095

virtual channels, packet sizes up to 2048 bytes each, and packet

sequencing

up

to

128

packets per logical channel. Most network

suppliers' nodal processors are too small to handle this much

traffic through a single interface. Therefore,

in

practice, the sup-

port offered over each interface is limited to the current capacity

of

the network's access node.

Functional

Layers

Recommendation X.25 defines three functional layers: the Physi-

cal Layer (Level 1), the Link Layer (Level 2), and the Packet

Layer (Level 3). These

are

consistent with the first three layers

of

the ISO Reference Model for Open Systems Interconnection

(OSI). (Although OSI labels its third layer the Network Layer, its

function parallels that

of

the Packet Layer. Both provide the

means to establish, maintain, and terminate connections.)

Levell:

Physical

Level-outlines

the physical, functional,

and electrical characteristics

of

the D1EIDCE interface.

X.21

uses the transmission

of

coded character strings across a 15-pin

connector to define standard interface functions, e.g., Transmit

Data. Its specifications

are

defined in TSS Recommendation

X.21.

Although

X.21

is the recommended physical-level interface

for X.25, the availability

of

data communications equipment with

X.21 capabilities is limited, especially in the United States. As a

result, the lTU-TSS has accepted an interim recommendation,

X.21

bis, as the X.25 physical interface.

X.21

bis is functionally

FEBRUARY

1994

12

Figure

3.

2790

Standards

ITU·

TSS

Packet

Switched

Networking Standards

X

SerIes

Data Networking

FrtIIIUI

FomuJIll/or

Plleut

Mode

Tmnllmisllion

Fields Generated by:

Application Program

Level 3 Software

Level 2 Software

~I""----------------------------Frame·""'---------------------------"~I

Flag

Flag

Address

Control

Packet

Control

User Data

Field Sequence

Check

Flag

Address

Size,

.bl1I

...



.....

-------packet-----t

..

~1

Control

Packet

Control User

Data

Field

Information

Description

Field

Sequence

Check

8 Value is 01111110.

8

8

Value for DTE to DCE command frame is "10000000".

Value for DTE to DCE response frame is "11000000".

Value for DCE to DTE command frame is "11000000".

Value for DCE to DTE response frame is "10000000".

I Frame:

Bit 1 is "0".

Bits 2, 3, 4, are N(S) (transmitter send sequence count).

Bit 5 is P/F (PoIVFinal) bit.

Bits 6, 7, 8 are N(R) (transmitter receive sequence count).

S Frame:

Bit 1

is

"1".

Bit 2 is "0".

Bits 3, 4 identify Supervisory Command.

Bit 5 is P/F (Poll/Final) bit.

Bits 6, 7, 8 are N(R) (transmitter receiver sequence count).

U Frame:

Bitlisl.

Bit2

is 1.

Bits 3, 4 are first part of Unnumbered Frame Command identifier.

Bit 5 is P/F (Poll/Final) bit.

Flag

Bits 6,

7,8

are second part of Unnumbered Frame Command identifier.

24

1,024

Control information.

1,024 data bits are normal maximum; exceptional maximum is 2,040 data bits.

16 Check bits for user data.

8 Value

is

"0111 H 10".

equivalent to EIA

~.s-232-C,

which assigns a separate function to

each pin across a 25-pin connector. the DTE and DCE can conduct two-way, simultaneous, indepen-

dent transmissions. The procedures use the principles and termi-

nology

of

the High-level Data Link Control (HDLC) protocol

specified by the International Organization for Standardization.

Level 2: Link

Level-describes

the link access procedures

used for data interchange between a DCE and a DTE. In the TSS

Recommendation X.21, International

User

Classes

of

Service

in

Public

Data

Networks,

X.25 specifies that the DTE and DCE

must operate in the following user classes

of

service: class 8

(2400 bps), class 9 (4800 bps), class to (9600 bps),

or

class

11

(48K bps). The procedure calls for a full-duplex facility so that

FEBRUARY

1994

Level 2 comprises three procedures: the Link Access Proce-

dure, the Link Access Procedure Balanced, and the Multilink Pro-

cedure (MLP). The original X.25 data link control procedure em-

braced LAP, which is similar to the HDLC Asynchronous

Response Mode (ARM). Due to some incompatibilities with

@

1994

McGraw-HiII,

Incorporated.

Reproduction

Prohibited.

Oatapro

Information

Services

Group.

Delran

NJ

08075

USA

Data

Networking

ITU·TSS

Packet

Switched

Networking Standards

X

Series

Table

5.

X.25

Level

2

Commands

and

Responses

Commands

(1)

Responses

Format

Information

(information)

transfer

Supervisory

RR

(3)

(receive

ready)

RNR

(receive

not

ready)

RNR

(3)

(receive

not

ready)

RNR

(receive

not

ready)

REJ

(3)

(reject)

REJ

(reject)

Unnumberad

SARM

(set

asynchronous

OM

(disconnected

(2,3)

response

mode)

(2)

mode}

SABM

(set

asynchronous

(2)

balanced

mode)

DISC

(disconnect)

UA

(unnumbered

acknowledgment)

CMDR

(connand

reject)

FRMR

(frame

reject)

(1)

The

need

for,

and use

of,

additional

commands

and

responses

are for further study.

1

0

2790

Standards

13

Encoding of Control Field

2 3 4 5 8 7 8

I-N(S}-I

P

I--N(R}-I

0 0 0

P/F

N(R}

0 1 0

P/F

N(R}

0 0

P/F

N(R}

P/F

0 0 0

P 0 0

0 0 P 0 0

0 0 F 0

0 F 0 0

(2)

DTEs

do not have

to

implement both

SARM

and

SABM;

furthermore,

OM

and

SABM

need

to

be

used if

SARM

only is

used.

(3)

RR,

RNR,

and

REJ

supervisory

command

frames

are not used by

the

DeE

when

SARM

;s

used

(LAP).

some elements

of

procedures, Level 2

of

the X.25 Recommenda-

tion was revised to incorporate LAPB. Similar to the Asynchro-

nous Balanced Mode (ABM)

of

HDLC, it provides for a

"balanced" configuration; that is, each side

ofthe

link consists

of

a combined primary/secondary station. The Multilink Procedure

is used for data transmission on one or more single links. Each

link conforms to the X.25-defined frame structure and to the ele-

ments

of

procedure described in LAPB.

Software in both DTE and DCE performs Level 2 processing.

This software appends control information onto packets that are

ready for transmission, maintains control

of

the transmissions,

performs transmission error checking, and strips a successfully

received frame down to a packet. The packet consists

of

packet

control information and (optionally) user data; packets are dis-

cussed in detail later in this report.

HDLC specifies certain control fields that must be appended

to both ends

of

a packet, resulting in a transmission format called

a frame. Appended in front

of

a packet are a beginning Flag field,

an Address field, and a Control field. Appended behind the packet

are a Frame Check Sequence field and a closing Flag field.

Figure 3 gives the size and description

of

each field. The re-

ceiving device uses the two Flag fields to ascertain the beginning

Table

6.

Summary

of

Packets

Exchanged

Between

Terminals

During a

Virtual

~all

Events

Call

Initiation

Data

Transfer

Disconnect

Activity at Calling DTE

Call

Request

packet

is

sent

Call

Connected

packet

is

received

Data

packet

sent

Ready

Receive

packet

received

Data

packet

A sent'

Data

packet

8 received'

Clear

Request

packet

sent

Clear

Confirmation

packet

received

"Two-way

(full-duplex)

transmission

of

data

packets

between

terminal

eqUipment.

@

1994

McGraw-Hili,

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

Activity at Called DTE

Incoming

Call

packet

is

received

Call

Accepted

packet

is

sent

Data

packet

received

Ready

Receive

packet

sent

Data

packet

8 sent'

Data

packet

A received'

Clear

Indication

packet

received

Clear

Confirmation

packet

sent

FEBRUARY

1994

14

Figure

4.

2790

Standards

X.25

User

and Network Software Relationships

ITU.TSS

Packet

Switched

Networking

Standard.

X

Serl

••

Data

Networking

1-------UserLocalion

------I-----Communications

------t------PubIiC

Packet-

Facility

Switching

Network

DTE

User

Program

Communicetions

Accass

Method

r----.,

r----.,

1

X.25

1 1

X.25

1

1

Level

3.

1 1 Level

2.

1

1_

P~ck~t

~~I...!

1_

F~~

~v~

...!

l

,~~"

Physicallnlerfaca

and ending

of

a frame. A single Flag field can be used as the

closing flag for one frame and the opening flag

of

the next frame.

The Address field, under HDLC, is used to identify the station(s)

for which the command is intended in command frames

or

to

identify the station sending the response in response frames.

The Control field identifies the type

of

frame and supplies

control information pertinent to that type

of

frame. A frame can be

either an Information Frame (I-Frame), a Supervisory Frame (S-

Frame),

or

an Unnumbered Frame (U-Frame). See Table 5 for the

encoding

of

this field.

An Information Frame contains a user packet. The Control

field

of

the I-Frame contains the N(S) transmitter Send Sequence

Count, the N(R) transmitter Receive Sequence Count, and the

PolllFinal

(P/F)

bit. N(S) is the sequence number

of

this frame

sent from this transmitter to this receiver. N(R) is the sequence

number

of

the next frame this transmitter expects to get from the

receiver when the receiver becomes a transmitter. The PoIIlFinal

bit indicates whether a transmission acknowledgment is required

or

when the final frame in a stream has been transmitted.

The Supervisory Frame transmits one

of

three supervisory

commands and cannot contain user data. The Control field

of

the

S-Frame contains the command, the

P/F

bit, and an N(R). Table 6

summarizes the commands and responses possible in the Control

field.

The Unnumbered Frame extends the number

of

link control

functions, without incrementing the sequence counts at either the

sending

or

receiving station.

A U-Frame control field contains the Unnumbered command

and the

P/F

bit. One

of

the U-Frarne commands initializes the

DTFJDCE network to the ARM

of

operation, which permits both

DTE and DCE to initiate transmission to each other.

The Frame Check Sequence (FCS) field contains a 16-bit

check pattern created at framing time by generating check bits

based upon the binary value

of

the data in the packet. The receiv-

ing device performs the same calculation and compares its results

with the value that the sending device had placed in the FCS field.

If

these values do not agree, the frame has a transmission error

and is discarded. Discarding causes the receiving device to send

an S-Frame with the Reject Recovery command. This S-Frame

contains the frame numbered N(R), thus acknowledging receipt

FEBRUARY

1994

DCE

Network

Node

Procassor

r - - - - - I - - - -

--I

1 1 1

1 I I

1 1 1

1 1 1

I

X.25

Level

2.

I

X.25

Level

3.

1

I

Frame

Level

I

Packet

Level

I

1 1 1

I 1 1

I 1 1

L

_____

.1

______

I

l

X.25

Levell.

Physlcat

Interface

To

Other

Network

Nodes

of

all frames numbered N(R)-I and below, and initiates retrans-

mission

of

frames N(R) and above.

In effect, Level 2 envelops the packet in control information

and prescribes procedures that ensure a high degree

of

transmis-

sion accuracy and detection

of

lost frames during transmission.

Level

3:

Packet

Level-describes

the packet format and con-

trol procedures for the exchange

of

packets between the DTE and

the

DeE.

In addition to the user data packet format, there are

several formats for DTFJDCE administrative messages.

The software for formatting packets and controlling packet

exchange is the Level 3 software resident in both the DTE and the

DCE. Figure 4 shows the relationship

of

Level 3 and Level 2

software operating in the DTE and the

DeE.

In the DTE, a user

application program normally presents the data to be transmitted

to the operating system's communications access method. The

access method invokes Level 3 software to append the packet

header information, then invokes Level 2 software to create the

frame. Packet header formats are discussed below.

Once the frame is created, it is ready for transmission. Upon

receiving the frame, the receiving DCE invokes Level 2 software

to perform error detection and sequence checking and to strip the

accepted frame down to a packet. The packet is presented to

Level 3 software for packet-level processing and to prepare the

packet for transmission to the destination DCE. The physical ad-

dress

of

the destination DTE, derived from the caIl initiation, is

inserted into the packet during Level 3 processing. At the network

destination

DeE,

Level 3 software reformats the packet control

information and presents the resulting packet to Level 2 software;

Level 2 software includes the packet in a frame for transmission

to the destination DTE (user). At the destination DTE (user),

Level 2 software performs error detection and sequence checking

and strips accepted frames down to the packet. Level 3 software is

then applied to the packet to strip the header information from the

packet and pass the user information to the appropriate applica-

tion program via the communications access method. Table 7

summarizes the types

of

packets exchanged between terminals.

The packet header consists

of

three octets. In Octet

I,

the first

four bits represent the Logical Channel Group Number, and the

final four bits represent the General Format Identifier. Octet 2

represents the Logical Channel Number, and Octet 3 represents

the Packet Type Identifier. See Figure 5.

@

1994

McGraw-Hili,

Incorporated.

Reproduction

Prohlb~ed.

Oatapro Infonnalion

Services

Group.

Delran

NJ

08075 USA

Data

Networking

ITU·TSS

Packet

Switched

Net_rldng

Standa"'"

xSerie.

2790

Standards

15

Table

7.

Packet

Types

and

Their

Use

in

Various

Functions

Packet Type Service

Function From

DCE

to

OlE

From

OlE

to

DCE

Switched Perm.

Virtual Virtual

Circuit Circuit

Can

Setup and Cleaning

In

Incoming Call Call Request X

Call Connected Call Accepted X

Clear Indication

DCE

Clear

Confirmation

Data and Interrupt

DCE

Data

DCE

Interrupt

DCE

Interrupt

Confirmation

Flow Control and Reset

DCE

RR

(Receive

Ready)

DCE

RNR

(Receive

Not

Ready)

Reset

Indication

DCE

Reset

Confirmation

Restart Restart Indication

DCE

Restart

Confirmation

Diagnostics Diagnostics

The Logical Channel Group Number and the Logical Channel

Number provide the routing information that directs the packet

over one

of

the logical channels. The numbering system for the

logical channels is dynamic and refers to a switched data path

within the packet network.

The General Format Identifier indicates the general format

of

the rest

of

the header. Specific bit patterns are established for the

following: Call Setup packets; Clearing, Flow Control, Interrupt,

Reset, Restart, and Diagnostic packets; and Data packets.

The Packet Type Identifier establishes the packet's function.

Examples

of

functions include call setup, priorities, and data.

If

applicable, it may identify the packet's place in sequence. See

Table 7 for the various packet types.

Packet·Level Procedures

X.25 Level 3 defines procedures for call initiation, data transfer,

interrupts, reset, restart, and clearing. Some

of

these procedures

are summarized below.

Call

Initiation:

The Level 3 software in a DTE initiates a

transmission by sending a Call Request packet. This packet en-

ables the calling DTE to request the opening

of

a logical channel.

The calling

DTE

designates the channel number based upon the

original assignments that were made when the user subscribed to

the network. The Call Request packet also informs the network

of

the calling

DTE's

address and

of

the called

DTE's

address. Until

the call is disconnected, the network retains the addresses

of

both

devices associated with the logical channel number. Therefore,

each Data packet that is transmitted needs to contain only the

logical channel number. The network appends the destination ad-

dress

just

before routing the packet. At the time the Call Request

is issued, the logical channel indicated by the calling DTE must

be in a Ready state, that is, not being used to handle another call.

Upon receipt

of

the Call Request by the called DTE, the specified

logical channel is designated as being in the DTE Waiting state.

The packet is then transmitted to the destination DCE.

@

1994

McGraw-Hili.

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

Clear Request X

DTE

Clear

Confirmation X

DTE

Data

X X

DTE

Interrupt X X

DTE

Interrupt

Confirmation X X

DTERR X X

DTE

RNR

X X

DTE

REJ*

X X

Reset Request X X

DTE

Reset

Confirmation X X

Restart Request X X

DTE

Restart

Confirmation X X

X X

The destination DCE transmits an Incoming Call packet to the

originating DTE and places the logical channel in the DCE Wait-

ing state.

The called DTE indicates its willingness to accept the call by

transmitting a Call Accepted packet across the DTFlDCE inter-

face. The Call Accepted packet specifies the same logical channel

that

is

indicated by the Incoming Call packet. This places the

specified logical channel in the Data Transfer state. (The logical

channel at the calling DCE is still in the Wait state.)

A Call Connected packet is then sent by the DCE to the calling

DTE and sets the logical channel status to the Data Transfer state;

the logical channel is then ready for transfer

of

Data packets. This

applies only for virtual circuit connections; for permanent virtual

circuit connections, the assigned logical channels are always in

the Data Transfer state.

It

is possible for a DCE to receive a Call Request (from a

DTE) and an Incoming Call (from the network) simultaneously,

with both messages specifying the same logical channel. This is

called a call collision; when a collision occurs, the DCE cancels

the Incoming Call and proceeds to process the Call Request.

nata

Transfer:

Once the logical channel is in the Data Trans-

fer state, Data, Flow Control, or Reset Information packets can be

transmitted.

The Data packet format includes the packet send and receive

sequence numbers. The calling DTE can transmit up to a prede-

termined number

of

packets before requiring a response. This

number is referred to as the window. All packet networks must

accommodate a lower window edge

of

at least eight, permitting at

least seven packets to be outstanding before an acknowledgment

is required. The upper window value (the maximum number

of

outstanding packets) may not exceed 127 (modulo 128).

Upon receipt

of

an authorized packet, the receiving device can

either authorize additional transmission by transmitting a Receive

Ready packet to the sending device

or

deny authorization to trans-

mit by issuing a Receive Not Ready packet.

When transmitting Data packets, the Interrupt packet can by-

pass flow control (authorization procedures). A DTE can transmit

FEBRUARY

1994

te

Fig/ll'e

5.

2790

Standards

X.25 PIIe"t

He_r

Fot7nllI

ITUoTSS

Packet

SWitched

Networking

StandIIrcI.

X

Serle.

Data

Networking

Octet 1 Octet 2 *

Octet

3--1

D-Bit

Q..Bit

M-Bit

Bits 1 2 3

4:

5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

Logical

Channel

Group

Number

General

Format

Identifier

Logical

Channel

Number

Packet

Type

Identifier

an

Interrupt packet

to

another

DTE.

To

avoid

swamping

the

re-

ceiver

with

Interrupt. packets,

the

sender cannot

send

a

second

Interrupt packet until the first Interrupt packet

is

acknowledged

by

an

Interrupt Confirmation packet.

While

Data packets

or

Interrupt

packets

are

being

transmitted,

issuing

a Reset Request packet

can

reset

the

call. A

DCE

initiates

a reset

by

issuing

a Reset Indication

packet.

In

either

case,

the

logical

channel

is

placed

in

the

Data

Transfer

state.

Any

Data,

Interrupt, Receive Ready (RR), or

Receive

Not

Ready

(RNR)

packets

in

the

network at

the

time

of reset

are

ignored.

If a

DTE

and

DCE

transmit Reset packets

simultaneously,

a

reset

collision

occurs.

The

net effect

is

to

place

the

logical

channel

in

the

Data

Transfer state,

ready

for

Data

and

Interrupt

packets.

A

DTE

or

a

DCE

initiates a request

for

clearing (disconnect-

ing)

a

logical

channel.

Upon

confirmation

by

the

other device,

the

logical

channel

is

placed

in

the

Ready

state.

Error Handling (Packet Level):

When

an

error

occurs,

the

DCE

transmits Reset,

Clear,

and

Restart indication

packets

to

the

DTE.

Reset reinitializes a virtual call or

permanent

virtual

circuit.

Reset

removes

all Data

and

Interrupt

packets

on

the

logical

chan-

nel

and

resets

the

lower

window

edge

to

zero.

It

affects

only

one

logical

channel

number

(one

user).

Reset

procedures,

which

ap-

ply

only

in

the

Data

Transfer state,

handle

specific error events,

such

as

local

procedure error,

remote

procedure

error,

network

congestion, incompatible destination,

network

out of

order,

etc.

Clear

affects

only

one

logical channel

number

(one

user).

It

clears

a session

when,

for example, the host or host

link

crashes.

In

this

case;

the

network

initiates Clear

procedures

on

the

terminal

link.

It effectively logs off

the

terminal

user.

Clear resets

the

lower

window

edge

to

O.

Restart affects all

users

(all

logical

channels

on

a

given

link)

and

clears

all

calls

on

that

link.

Restart

is

used

when

a

failed

link

returns to service;

it

makes

sure

that

all

calls

were

cleared

when

the link

went

down.

Restart also

is

used

when

either

side

(DTEor

DCE)

reports error conditions at

the

packet

level;

the

good

side initiates the restart procedures.

In

some

networks, a Diagnostic packet indicates

unusual

error

conditions. A Diagnostic packet

from

the

DCE

provides

informa-

tion

on

events that are considered unrecoverable

at

the packet

level;

the information permits

the

DTE

to

analyze

and

initiate

recovery

by

higher levels.

No

conftrmation

is

required

on receipt

of a Diagnostic packet.

FEBRUARY

1994

Implementation

Considerations

for

Users

X.2S

recognizes

that

DTEs differ

in

their degree of sophistication.

A simple

DTE

may

have

fixed

packet

formats

and

built-in

param-

eter

values,

while

a sophisticated

DTE

may

work

with

varying

packet

formats

and

provide variable parameters

to

take

advantage

of

the

many

network

functions

and

signaling capabilities

offered.

At

the physical level, the transmission

rate

DTE

uses

to

access

an

X.2S

network

should

be

governed

by

the

throughput

and

re-

sponse

time

requirements of the

user.

Factors

to

consider include

the

maximum

number of virtual circuits operating

simultaneously

and

traffic

characteristics of throughput-critical

and

response-

time-critical virtual circuits.

At

the

link

level,

LAPs

and

LAPBs

are

defined.

A

DTE

might

implement

only

LAPB.

Parameters

that

are

part of

the

LAPB

procedures

can

be

set

to

constants

for

all

network

connections.

For example, a timer (Tl)

may

be

set

according

to

the

slowest

required

line

speed;

a constant

such

as

three

seconds

may

be

used.

Also,

the

maximum

permitted number of

unacknowledged

I-Frames (information

frames)

may

be

determined.

The

network

provider

must

agree

to

this.

All

networks

support a

window

of

at

least

seven

I-Frames.

The

maximum

packet size

(number

of

bits)

of

the

I-Frame

must

also

be

established.

If

the

DTE

handles

certain character sizes (octets),

the

frame

level

should

be

capable of

accommodating

any

number

of

bits

correctly (generate acknowledgment, calculate

frame

check

se-

quence).

How

such

a properly

received

frame

is

processed

de-

pends

on

the

individual

system

and

may

include

actions

such

as

discarding

the

frame,

padding

it, clearing

the

call,

or

resetting.

Connections

Between

Packet

Switched

Data

Networks

TSS

Recommendation

X.7S

describes

the

procedures

for

the

in-

terconnection of packet switched

networks.

Many

public packet

switched data

networks

support

X.7S

procedures,

including

AT&T

Accunet,

TransCanada's Datapac, Graphnet

Freedom

Net-

work

II,

US

Sprint's SprintNet,

and

WangPac

networks.

X.7S

is

similar to

X.25

in

that

it

specifies

procedures

for

the

physical, link,

and

packet levels. Signal

Terminal

Equipment

(STE),

which

acts

as

a bridge

node

between

networks,

imple-

ments

X.7S

procedures. A related standard,

TSS

X.121,

defines

the international numbering plan for public data

networks.

Cl

1994

McGraw-HiII.

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

{

'--

./

Data

Networking

Recommendation

X.75

ITU·

TSS

Pecket

SwRebecl

Networking

Standards

X

Series

Recommendation X.75, Terminal

and

Transmit Call Control Pro-

cedures

and

Data Transfer System on International Circuits Be-

tween Packet-Switched Data Networks, provides the rules for

transmitting data between different data networks. The basic sys-

tem structure is made

up

of

communicating elements that func-

tion independently. These elements include the physical circuits,

which comprise links

Al

or

G I (as defined in X.92), and a set

of

mechanical, electrical, functional, and procedural interface char-

acteristics; packet transfer procedures, which operate over the

physical circuits and provide for the transport

of

packets between

STEs; and packet signaling procedures, which use the packet data

transfer procedures and provide for the exchange

of

call control

information and user traffic between STEs.

Figure 6 shows the basic system structure

of

the signaling and

data transfer procedures. The international link is assumed to be

data link

Al

and/or data link

G1

as defined in Recommendation

X.92. The international link should be capable

of

supporting full-

duplex operation.

Link-level packet transfer procedures between STEs consist

of

the Single Link Procedure (SLP) and the Multilink Procedure

(MLP). The SLP

is

used for data interchange over a single physi-

cal circuit between two STEs. When multiple physical circuits are

used in parallel, the SLP is used independently on each circuit.

The MLP is used for data interchange over multiple parallel links.

The MLP may be used over a single link when the communicat-

ing parties agree to this procedure. Transmissions are full duplex.

SLP is based upon the LAPB as described in X.25 and uses the

principle and terminology

of

the International Organization for

Standardization's (ISO's) HOLC. For

SLP,

either modulo 8 (non-

extended mode) or the modulo

128

(extended mode) may be

used. The MLP is based on the multilink procedures specified

by

the ISO and performs the functions

of

distributing packets across

available SLPs.

Three channel states are defined: the link channel state, which

provides transmission in one direction; the active channel state,

which means that the incoming or outgoing channel is receiving

or

transmitting a frame; and the idle channel state, which means

that the incoming or outgoing channel is receiving

or

transmitting

at least

15

contiguous I bits.

Data is transmitted in frames. Each frame must contain an

Opening Flag (8 bits), an Address field

(8

bits), a Control field (8

bits), a FCS field (16 bits), and a Closing Flag (8 bits). An Infor-

mation field

of

an unspecified number

of

bits, which follows the

Control field, is optional.

Figure

6.

Basic System Structure

of

X.75

Signaling and

Data

Transfer Procedures

2790

Standards

17

The Control field contains a command

or

response, and se-

quence numbers

if

applicable. Control field formats may be one

of

three types: numbered information transfer (I format), num-

bered supervisory functions (S format), and unnumbered control

functions (U format). The I format performs information transfer

functions. The S format performs link supervisory control func-

tions, such as acknowledging I frames, requesting transmission

of

I frames, and requesting a temporary suspension

of

transmission

of

I frames. The U format provides additional link control func-

tions.

Each I frame is numbered sequentially. The send state variable

V(S) represents the sequence number

of

the next in-sequence I

frame to be transmitted. The value

of

the V(S) is incremented by

one with each successive I frame transmission but cannot exceed

N(R)

of

the last received I

or

S format frame by more than the

maximum number

of

outstanding frames. The send sequence

number N(S), contained only in I frames, is set equal to the value

of

YeS). The receive state variable V(R) represents the sequence

number

of

the next in-sequence I frame expected to be received.

The value

of

V(R) is incremented by one when an error-free,

in-sequence I frame whose N(S) equals V(R) is received. Both I

frames and S frames contain the receive sequence number N(R).

N(R) is the expected send sequence number

of

the next received I

frame. When the STE transmits N(R), it indicates that all I frames

numbered

up

to

and including N(R)-l have been received cor-

rectly.

All frames contain the PolVFinal (P/F) bit, which is referred to

as the P bit in command frames and the F bit in response frames.

The STE solicits a response from another STE by setting the P bit

to I; the answering STE responds

by

setting the F bit to I. The

following commands and responses are supported:

•

Information

(I)

command-transfers

sequentially numbered

frames that contain an information field;

• Receive

ready

(RR)

command

and

response-used

by the

STE to indicate that it is ready to receive an I frame or to

acknowledge a previously received I frame;

• Receive

not

ready

(RNR) command and

response-used

by

the STE to indicate a busy condition;

• Reject

(REJ)

command

and

response-used

by

the STE to

request retransmission

of

I frames beginning with frame num-

bered N(R);

• Set asynchronous

balanced

mode

(SABM)

command-an

unnumbered command used to set the addressed STE in the

r---------------------,

Higher Level Functions Packet Packet

-Call

Control Signaling

f--

Transfer

-Network

Control Procedures Procedures

-User

Traffic Signaling Terminal (STE)

GatewayITransit Data Switching Exchange X or Y

@

1994

McGraw-Hill,

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

I

I

I I

I

I

I

XN

Interface

I

Link

A1

or

G1

FEBRUARY

1994

18

2790

Standards

asynchronous balanced mode infonnation transfer phase; all

command/response control fields are one octet (eight bits);

•

Set

asynchronous

balanced

mode

extended (SABME)

com-

mand-an

unnumbered command used to set the addressed

STE

in the asynchronous balanced mode infonnation transfer

phase; all numbered command/response control fields are two

octets; all unnumbered command/response control fields are

one octet;

•

Disconnect

(DISC)

command-tenninates

the previously set

mode; DISC indicates that the STE transmitting DISC is sus-

pending operation;

•

Unnumbered

acknowledge (UA)

response-used

by the

STE

to acknowledge mode-setting commands;

• Disconnected

mode

(DM)

response-reports

STE

status

when it is logically disconnected from the link and is in the

disconnected phase; and

•

Frame

reject

(FRMR)

response-indicates

an error condition

that is not recoverable by retransmission

of

the frame.

Packet-level signaling procedures relate to the transfer

of

packets

at the STE-XlSTE-Y

(XlY)

interface. Recommendation X.7S

specifies signaling procedures for virtual call setup and clearing,

for pennanent virtual circuit service, for data and interrupt trans-

fer, for flow control, and for reset.

Logical channels are used to complete simultaneous virtual

calls and/or pennanent virtual circuits. A logical channel group

number and a logical channel number (in the range 0 to IS inclu-

sive and 0 to 255 inclusive, respectively) are assigned to each

virtual call and pennanent virtual circuit. The logical channel

group number and the logical channel number are contained in

each packet type, except restart packets.

The procedures for virtual call setup and clearing are used

only when a logical channel is in the packet-level ready (RL)

state.

If

call setup

is

possible, and no call

or

call attempt exists, the

logical channel is in the ready (PL) state (within the

RL

state).

Call setup is initiated when the

STE

sends a Call Request packet

across the

XlY

interface. The Call Request packet specifies a

logical channel in the

PL

state.

The

logical channel is then placed

in the call request state. The called STE indicates acceptance by

the called

DTE

by sending a Call Connected packet across the

XlY

interface.

It

specifies the same logical channel as that re-

quested by the Call Request packet. The logical channel

is

then

placed in the flow control ready (DL) state within the data trans-

fer (P4) state.

A logical channel (in any state) can be cleared when the

STE

sends a Clear Request packet, which specifies the logical chan-

nel, across the

XlY

interface. Upon receipt

of

a Clear Request

packet, STE-X

or

STE-Y frees the logical channel and transmits a

Clear Confirmation packet that specifies the same channel. This

places the logical channel in the ready state within the

RL

state.

Permanent virtual circuits require no call setup

or

clearing.

Data transfer procedures apply independently to each logical

channel at the

XlY

interface. In the data transfer (P4) state, Data,

Interrupt, Flow Control, and Reset packets may be sent and re-

ceived by the STE. The data transfer state exists within the

packet-level ready state

of

a logical channel. Each Data packet

contains a sequence number called the packet send sequence

number peS); only Data packets contain the peS).

The

procedures for flow control and reset apply only in the

data transfer state. Flow control applies to Data packets. A win-

dow is defined for each direction

of

transmission at the

XlY

in-

terface.

The

lowest number in the window is called the lower

window edge. The maximum window edge does not exceed

modulo 8

or

128, is unique to each logical channel, and is re-

served for a period

of

time.

For

a particular call, two window

FEBRUARY

1994

ITU·TSS

P.cket

SwHcheci

Networking

SgnUni.

X

.......

Data

Networking

sizes, one for each direction

of

transmission, may be selected. The

packet receive sequence number peR) (modulo 8

or

128) conveys

information from the receiver for the transmission

of

data pack-

ets.

The

PeR) becomes the lower window edge when transmitted

across the

XlY

interface, thereby authorizing additional data

packets to cross the

XlY

interface.

Reset procedures are used to reinitialize a single call and apply

only in the data transfer state. The

STE

sends a Reset Request

packet that specifies the logical channel to indicate a request for

reset.

The

logical channel is placed in the reset request state.

The

requested

STE

confinns by sending a Reset Confirmation packet,

which places the logical channel in the flow control ready state.

Restart procedures are used to clear all calls simultaneously.

When the STE sends a Restart Request packet, the

XlY

interface

for eacb logical channel is placed in the restart request state. In

this state all packets, except Restart Request and Restart Confir-

mation packets, are discarded by the

XlY

interface. An

STE

con-

firms by sending a Restart Confirmation packet, which places all

channels in the ready state.

Packet fonnats are based on the general structure

of

packets as

defined in X.2S.

Trends in

Packet

Switching

X.2S packet switching is widely supported in existing data pro-

cessing and data communications equipment. All major host

computer and communications processor vendors, for example,

have incorporated X.2S interfaces into their products. This is part

of

an overall trend in accepting international standards and the

increasing availability

of

products conforming to these standards.

The

ITU-TSS published revisions to the X Series standards in

1984 and in 1989. Since that time, the ratification and publication

of

revisions has become a continuous, ongoing process. Since the

major building blocks for X.2S were laid by 1984, all subsequent

changes have been, and will continue to be, relatively minor.

Some recent changes have revolved around efforts to make TSS

X Series standards compatible with those

of

the International Or-

ganization for Standardization. Currently, discussions on how to

provide greater interoperability between various X.2S networks

and between X.2S and frame-relay networks is taking place. Ma-

jor

developments in packet switching today, however, center not

around X.2S, but around the development

of

new ISDN-related

technologies, such as frame relay and Broadband ISDN, which

provide much higher throughput through simplified packetization

and routing schemes. This section discusses post-1984 changes to

X.2S and its relationship to ISDN.

Major

Changes in

1988

Revisions

In the 1988 revised standards, there were no changes at the physi-

cal and link levels. At the packet level, however, a new facility for

redirecting calls, Call Deflection, was established. In 1984 the

ITU-TSS had made available a new Call Redirection facility, al-

lowing the network to redirect all calls destined for a given ad-

dress. This redirection could occur when the destination was out

of

order

or

busy,

or

it could be based

on

time

of

day

or

other

criteria. The 1988 facility extended this capability, allowing the

destination subscriber to clear incoming calls to another party

on

a call-selective basis. The Clear Request packet contains the Call

Deflection infonnation that profiles the desired alternate party.

Relationship

Between

lTU-

TSS

and

ISO

ElTorts

TSS X.2S packet-level protocol specifies a virtual circuit service;

the

ISO

has issued a compatible version

of

the packet standard,

ISO 8208. In recent years, ITU-

TSS

and ISO organizations have

worked

on

standards to carry longer addresses in the

DTE

field to

facilitate interworking with ISDN (E.164).

@

1994

McGraw-Hili.

Incorporated.

Reproduction

Prohib~ed.

Dalapro

Information

Services

Group.

Dalran

NJ

08075

USA

Data

Networking

ITU·

TSS

P.cket

Switched

Networking Stllndllrds

XSe,'e.

In 1988 the ITU-TSS also modified the Address Extension

facilities to be consistent with ISO address length. Previously, a

provisional 32-decimaIlI6-octet field had been recommended;

this address length was increased to 40 decimalsl20 octets. The

ISO also added these address recommendations to Addendum 2

ofISO

8348 (Connection-Mode Network Service); the ITU-TSS

adoption is X.213.

Connectionless Issues: Relationships

With

ISO

EtTorts

At any layer

of

the OSI Reference Model, two basic forms

of

operation are possible: connection oriented and connectionless.

Connection-oriented service involves a connection establishment

phase, a data transfer phase, and a connection termination phase.

A logical connection is set

up

between end entities prior to ex-

changing data. In a connectionless service, typical

of

local area

networks, each packet

is

independently routed to the destination.

No connection establishment activities are required since each

data unit is independent

of

the previous

or

subsequent one.

Each transmission mode has a niche where it represents the

best approach. For example, file transfers may benefit from a

connection-oriented service, while point-of-sale inquiries may be

best served

by

a connection less service.

Traditionally, the ITU-TSS has pursued a connection-oriented

philosophy, while ISO has addressed both connection and con-

nectionless services. The original OSI standard, ISO 7498, is con-

nection oriented. ISO provided connection less service, however,

by issuing an addendum to that protocol: ISO 7498/DADI. ISO

has issued a standard for connection-mode network service (ISO

8348), while the lTU-TSS has issued an identical service, X.213.

In regard to X.25 itself, however, ISO has decided not to pursue

the connectionless service, formerly known as "datagram" ser-

vice.

Packet

Switching

in

ISDN

The goal

of

the Integrated Services Digital Network (ISDN) is to

provide an end-to-end digital path over a set

of

standardized user

interfaces, giving the user the capability to signal the network

through an out-of-band channel. (In contrast, in X.25, the user

signals the network in-band

by

issuing packets such as Call Re-

quest, Call Accepted, etc.)

Currently, different types

of

interfaces to the telephone net-

work exist for different services. These interfaces include two-

wire switched, two-wire dedicated, four-wire dedicated, and

DDS. ISDN provides a small set

of

interfaces that can be used for

multiple applications. The lTU-TSS has defined the following

interfaces for ISDN:

•

2B+D-two

64K bps channels and a 16K bps packet/signaling

channel (also called the Basic Rate Interface).

• 23B+D-twenty-three 64K bps channels and a 64K bps

packet/signaling channel (also called the Primary Rate Inter-

face).

•

3HO+D-three

384K bps channels and one 64K bps packet/

signaling channel.

•

HlI-nonchannelized

1.536M bps.

•

Hl2-nonchannelized

I.920M bps.

• Multislotted-multiples

of

64K bps channels (up to I.536M

bps) under the customer's control.

•

Broadband-high

data rates, based on an approach called syn-

chronous optical network (Sonet), building on multiples

of

51.84M bps. Sonet standards negotiations began in 1986. The

lTU-TSS approved phase I

of

the standards in 1988 and phase

II in 1989. This architecture has been called Broadband ISDN,

in contrast to the other interfaces that have been considered part

of

Narrowband ISDN.

Ii:>

1994

McGraw-Hili.

Incorporated.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

2790

Standards

19

With the exception

of

Broadband ISDN, all

of

the above inter-

faces can be carried on unloaded copper loops. Using fiber has

also been considered, as it would make the local loop more ro-

bust. Out-of-band signaling makes possible a new class

of

ser-

vices. In addition, the 16K bps D-channel connects directly to the

BOC's packet switched network, providing the subscriber with

the data multiplexing advantages packet switching offers.

lTU-TSS ISDN

Standards

ISDN provides a specific protocol that users can employ to signal

the network. Currently, a three-layer protocol suite is defined. At

the Basic Rate, the Physical Layer manages a 192K bps, full-

duplex bitstream using time-compression techniques and time-

division methods to recover the two B-channels and one D-chan-

nel. The remaining 48K bps stream

is

used for Physical Layer

control information. The defined standards are 1.420 (Basic Rate

Interface Definition), 1.430 (Basic Rate Interface Layer 1),1.421

(primary Rate Interface Definition), and

1.431

(Primary Rate In-

terface Layer 1).

The Data Link Layer is not defined for transparent B-channels

used for circuit switched voice or data, but it is defined for the

D-channel. For Narrowband ISDN, the D-channel employs a

LAP-D Link Layer protocol, which

is

a subset

of

the ISO HDLC

Data Link protocol, as specified in TSS Recommendations Q.920

(1.440) and X.921 (1.441). It provides statistical multiplexing for

three channel types: signaling information for managing the B-

channels; packet switched service over the D-channel; and op-

tional channels, used for telemetry

of

other applications.

The Network Layer protocol for the signaling channel is

specified in TSS Q.930 (1.450) and Q.931 (1.451) specifications.

It

provides the mechanism for establishing and terminating con-

nections on the B-channels and other network control functions.

For the packet switched service over the D-channel, the Network

Layer protocol is X.25.

A technique is required for specifying whether user-to-net-

work signaling, user packet data,

or

user telemetry data

is

being

sent over the D-channel. This technique involves the use

of

a

service access

point

identifier (SAPI).

Each layer in the OSI Reference Model communicates with

the layers above and below it across an interface. The interface is

through one

or

more service access points (SAPs). SAPs have a

number

of

uses, including subaddressing for intemetworking

situations, Transport Layer applications, and for user data packet

service over an ISDN D-channel.

Considering the applications to the Transport Layer, one

should note that two general types

of

addressing in a communica-

tions architecture are available. Each host on the network is as-

signed a network address, allowing the network to deliver data to

the proper computer. Each process within a host, moreover, is

given an address that is unique within the host itself, allowing the

Transport Layer to deliver data to the proper process. These pro-

cess addresses are identified using SAPs. A similar approach is

followed for ISDN.

LAP-D must deal with two levels

of

multiplexing. First, at a

subscriber location, multiple-user devices may be sharing the

same physical interface. Second, each user device may support

multiple types

of

traffic, including packet switched data and sig-

naling.

To

accomplish this type

of

mUltiplexing, LAP-D employs

a two-part address consisting

of

a terminal endpoint identifier

(TEl) and a SAPI.

"JYpically,

each user terminal

is

given a distin-

guishing TEL The SAPI identifies the traffic type and the Data

Link Layer services directed to Layer 3. For example, the SAPI

value

of

0 directs the frames to Layer 3 for call-control proce-

dures; a SAPI value

of

16 indicates a packet communication pro-

cedure. See Figure 7.

FEBRUARY

1994

figure 7."

'.

...,

"

SAP~

Action/or a BtlSk

Rat,

JU:1um",1

ITU~TSS

Packet SwItched

Networking ShindanII.

XSeri

••

Data

Networking

Signaling Packet Telemetry

.J

J• Layer 4

J•

J~

J.

•

~

________________

.

-r:._,

----------

-------------,~E------------11rr:,.------------,

..

----

--

-;Ii

.

"r'

· r r

Layer 3

B1

Entity

~~

Layer 3

B2 Entity

Layer 3

s Entity

ISAP1=O)

~"

-----~------------~------------

1~

1r

Layer 2 Layer 2

B1

Entity B2 Entity

64K bos 64K bos

J~

I~

-------------------

,

Layer 1

ISDN Physical Entity

192K bps

,

Layer 3

P Entity

ISAP1=16)

~~

Layer 2

LAPD Entity

64K bps

Layer 3

t Entity

Network

Data Link

~-----~~:~----~

Protocols

I~

_______________________________

~~l~J.

______________________________________________

~a1~~1

Frame

Relay

Frame relay is a rapidly emerging, standards-based addressing

technique that has great potential in LANIWAN networking and

other interactive applications requiring high-throughput, low-de-

lay transmission. Frame relay is based on the TSS Layer 2

pro~o

col developed for ISDN, Link Access Protocol D (LAPD). U?hke

conventional X.25 packet switching, frame relay uses vanable

packet lengths and performs error ch'7king only

a~

the

re~ote

end

of

transmission. Any errors occumng between mtermedlate

network nodes are assumed caught and corrected by higher-layer

protocols. Thus, intermediate nodes simply forward packets

(called frames) without processing the datastream.

In

addition,

frames must be received in the order in which they were sent,

unlike some X.25 networks, which involves considerably less

machine processing at the opposite end

of

transmission. These

efficiencies result in superior performance, with data rates up to

or

above

TIlEl

levels.

Vendors from several different networking disciplines have

established themselves

as

frame-relay equipment providers.

These include traditional packet switched equipment suppliers

such as Northern Thlecom, Alcatel Data Networks, BBN Systems

and Thchnologies,

BT

North America, and Hughes Network Sys-

tems; T-carrier nodal processor vendors such

as

Ascom

Ti~eplex,

General DataComm, Newbridge Networks, Network Equipment

Technologies, and StrataCom; and LAN internetworking (bridge

and router) vendors.

Most commercial frame-relay products are based on some

or

all

of

the following American National Standards Institute

(ANSI) specifications:

FEBRUARY

1994

• T1.602: Data Link Layer Signaling Specification for Applica-

tions at the User-Network Interface

• T1.606: Frame Relaying Bearer Service-Architectural

Framework and Service Description (TIS1I88-225)

•

T1

Sl.2:

Addendum to TI.606 (Frame Relaying Bearer Ser-

vice-Architectural Framework and Service Description)

~n

Congestion Management Principles

• T1.617: Signaling Specification for Frame Relay Bearer Ser-

vice

• T1.618: Core Aspects

of

Frame Protocol for use with Frame

Relay Bearer Service

The ITU-TSS has released frame-relay specification

1.122,

en-

titled "Framework for Providing Additional Packet Mode Bearer

Services.

" TSS

1.462

(X.31), .. Support

of

Packet Mode Terminal

Equipment by an ISDN," describes a packet mode service.

Broadband

ISDN

and

Cell Relay

Broadband ISDN (BISDN) is the blueprint for public networks in

the mid-1990s (1994 and beyond).

It

is being developed to sup-

port switched (on demand),

se~iperman~nt,

and permanent

broadband connections for both pOint-to-pomt and pomt-to-mul-

tipoint applications. Channels operating at

l?5M

bps

~d

.622M

bps will be available under BISDN, allowmg.

transmls~lon

of

data, video, and digitized voice. Broadband

servtc~s

are aimed at

both business applications and residential subscnbers. Connec-

tions will support both circuit mode and packet mode services

of

a single media, mixed-media, and multimedia.

@

1994

McGraw-HIII,

Incorporated.

Reproduction

Prohibited.

Datapro

InfOrmation

Services

Group.

Detran

NJ

08075

USA

\",.

Data

Networking

ITU.TSS

hoket

Switched

NetwoIIclng StancIIIrds

x

SerIes

BISON's

foundation

is

Asynchronous

Transfer

Mode

(ATM),

a high-bandwidth,

low-delay

switching

and

multiplexing

technol-

ogy

in

which

information

is

packetized

into

fixed-size slots

called

cells. A

cell

consists

of

an

information

field

that

is

transported

transparently

by

the

network

and

a

header

containing

routing

in-

formation.

With

simplified

protocols

and

cells

with

a

fixed,

short

length

(53

bytes),

ATM

makes

very

high

data

rates

possible.

The

ITU-

TSS

has

issued

several

Broadband

ISDN

specifica-

tions

in

its

I-Series

recommendations.

1.361,

the

BISDN ATM

Layer Specification.

defines

the

ATM

cell

structure

and

coding,

including

header

formats

and

coding

at

both

the

User-Network

C

1994

McGrilw-HHi.

Incorponlted.

Reproduction

Prohibited.

Datapro

Information

Services

Group.

Delran

NJ

08075

USA

2780

Standards

21

Interface

(UNI)

and

Network

Node

Interface

(NNI).

It

also

de-

fines

ATM

protocol

procedures. 1.311, entitled BISDN General

Network Aspects, describes networking techniques,

signaling

principles,

traffic

control,

and

resource

management

for

BISON.

It

defines

ATM

virtual section, virtual

path,

and

virtual

channel

concepts.

Several

off-the-shelf

ATM

products

were

released

in

late

1993

by

vendors

of packet

and

frame-relay switches, T Carrier

multi-

plexers,

and

LAN

routers vendors.

Many

more

end-user

ATM

products,

along

with

AN

public carrier services,

will

gradually

become

available

in

1994

and

1995

.•

FEBRUARY

1994

\