Overview of Link Access Procedure D
Overview of Link Access Procedure D
Table of Contents
Purpose ................................................................................................................................3
What is a Data-link? ............................................................................................................4
Data-link Protocols .............................................................................................................6
Functions of the Data-link ..................................................................................................8
Link Access Procedure - D ...............................................................................................10
Data-link Layer Service ....................................................................................................12
Primitives Associated with LAP-D ...................................................................................14
Applicability of DL Primitives .........................................................................................16
Data-link Functions ...........................................................................................................18
HDLC Classification Chart ...............................................................................................20
HDLC Frame Format ........................................................................................................22
HDLC Bit Stuffing / Removal ..........................................................................................24
LAP-D Frame Formats .....................................................................................................26
HDLC Address Field Format ............................................................................................28
Address Field & C/R Bit Usage ........................................................................................30
SAPI and TEI Values ........................................................................................................32
Addressing and the D-Channel .........................................................................................34
HDLC Control Field Formats ...........................................................................................36
Commands and Responses of LAP-D ...............................................................................38
Use of the P / F Bit ............................................................................................................40
Frame Reject (FRMR) Format ..........................................................................................42
XID Message Parameter Coding ......................................................................................44
Numbering Conventions Used ..........................................................................................46
Data-link Connections ......................................................................................................48
The Layer 2 Multiplexor ...................................................................................................50
An Example of D-Channel Multiplexing ..........................................................................52
Relationship of SAPI, TEI, DLCI & CES ........................................................................54
Frame Exchange Examples ...............................................................................................56
Actions for Unsolicited Response Frames ........................................................................58
TEI Assignment Procedure ...............................................................................................60
TEI Check Procedure ........................................................................................................62
TEI Identity Verify ...........................................................................................................64
TEI Management Procedures ............................................................................................66
TEI Management Messages and Codes ............................................................................68
Conceptual Model of Deactivation Procedures ................................................................70
Deactivation State Transitions ..........................................................................................72
Deactivation State Transitions ..........................................................................................74
Q.921 State Transition Tables ...........................................................................................76
Summary ...........................................................................................................................78
Notes: ................................................................................................................................80
Purpose
The purpose of this chapter is to cover the Layer 2 signaling protocol - Link Access Procedure -
D. While the ITU-T Study Group 11 initially designed this procedure for the signaling, or D-
Channel, it is now beginning to see use on the B-Channels as well. This use is for a rate adaptation
protocol specified in Recommendation V.120 and is also proposed for some forthcoming packet
mode services.
LAP - D is a true subset of the ISO HDLC protocol, but has some interesting features that
distinguish it from previous applications of this protocol.
At the end of this chapter we will have set the foundation for the complex protocol used for
signaling at Layer 3.
What is a Data-link?
A data-link, apart from being the second layer of the OSI model, is simply a protocol that operates
over the physical media in order to exchange information between two systems.
Although they were not specifically called data-link protocols, such protocols have been with us
since the first computer and computer terminal operated over a serial communications link. Some
of these first protocols were rather primitive, however they did manage to accomplish the
information transfer.
Typical of these early protocols were the simple ASCII echoplex mode Teletype machine-to-
computer serial mode protocols. Echoplexing is the practice of having the Teletype keyboard
logically separated from the Teletype printer. The keyboard only sends to the computer and the
computer sends to the printer. This was an early form of error checking since the computer echoed
back to the printer every character entered at the keyboard. If the operator typed an X, and saw an
X printed, it could be safely assumed that the computer had received the character correctly.
What is a Data-link?
SYSTEM A SYSTEM B
DATA-LINK
PROTOCOL
DATA-LINK DATA-LINK
LAYER LAYER
PHYSICAL MEDIA
Data-link Protocols
The earlier data-link protocols were character oriented, which is to say that they sent information
in the form of ASCII or EBCDIC characters. This imposed some limitations upon what could be
sent between systems since they used some of the characters in the set(s) for data-link control.
If a user or system wished to send the binary representation of one of these control characters in
the information part of a data-link message, it was necessary to use an arbitrarily assigned escape
character. This escape character was placed ahead of the control character to indicate that the
receiver should not interpret that character as a control character.
Some of the better known early character oriented protocols were the ISO IS1745 standard, ANSI’s
X3.28 standard, and IBM’s Binary Synchronous (Bisync) protocol.
In the early 1970s, ISO started working on a bit-oriented data-link protocol. It is bit-oriented
because the information portion may be any length and is totally transparent to the data-link control
function.
The earliest version made the same error as the older protocols had; it contained many functions
unrelated to data-link control. There were codes for out-of-paper conditions, terminal error
conditions, etc. However, even though the OSI model had not even been started at this point, the
decision was taken in 1974 to change the protocol and remove all non data-link functions from the
standard.
This was the birth of the High-level Data-link Control protocol (HDLC). It is a robust, simple data
protocol totally transparent to the user.
The ISO version is contained in two base standards, IS3309 and IS4335. ANSI calls its version
Advanced Data Communications Control Procedures (ADCCP). Most computer manufacturers
offer HDLC in various proprietary versions - IBM’s SDLC, Univac’s UDLC, Burrough’s BDLC,
etc. They all adhere to the ISO or ANSI standard.
Data-link Protocols
Character-oriented
ISO 1745
ANSI X3.28
Bit-oriented
ANSI ADCCP
A serial data line, or the Physical Layer of OSI, provides a bit-stream. Some interesting and
powerful protocols can operate using a single bit, e.g., is the bit on or off, where is it in relation to
other bits, etc. However, for useful work this bit stream must be given a form, or format.
The data-link’s function is to provide this format. It shows where the useful bits begin and end. It
defines a character length usable by the end systems, usually octets (8 bit characters). In effect, it
provides a syntax and semantic, much as any language does with an alphabet. Twenty-six letters
do not convey much useful information without a dictionary.
Having given the bit stream a format, it is quite possible, by use of various algorithms, to perform
an error checking function upon the data-link information. For example, HDLC uses a 16 bit Cyclic
Redundancy Check (CRC) upon all the transmitted data. The transmitter appends the result of this
check to the transmitted data. The receiver performs the same check upon the received data and
compares its result with that sent by the transmitter. If they match, it is reasonably safe to assume
that the received data is what was sent.
Having checked for errors, it is a trivial exercise to have the data-link protocol provide a means for
requesting re-transmission of the data that was received in error. HDLC does this by numbering
its messages (frames) and providing a code that requests re-transmission.
Acknowledging frames, or messages, provides a means of controlling the flow of frames between
sender and receiver so that the receiver is not overrun with data it cannot handle. In this manner a
slower device can throttle a faster device down to its own speed.
Error detection
Error correction
Acknowledges receipt
Link Access Procedure - D (LAP-D), the fourth in a line of ITU-T implementations of the High-
Level Data-link Control procedures defined by ISO, is the data-link protocol of the D-Channel. If
you wonder about LAP-C, it lived briefly in the ISDN study but was abandoned.
LAP-D is a fully standard implementation of the HDLC standard that does not depart from the ISO
standard in any way. The Q.921 Recommendation repeats the text of the ISO version, but in
ITU-T language.
LAP-D differs slightly from previous incarnations of HDLC in using a two-octet address. This is
in compliance with the standard; it is simply that the previous implementations only used a single
octet address. Unfortunately, many of the early silicon implementations of HDLC only provided
for a single octet address
LAP-D performs a multiplexing function by use of its address structure, providing a coarse and
fine grained multiplex. The basis of the first level of multiplexing (coarse) is the first address octet
and within that level, the basis of the second level (fine) of multiplexing is the second address octet.
There are Large Scale Integration (LSI) silicon chips for the LAP-D functions available today.
Available in LSI
The ITU-T modeled the ISDN Data-link Layer service according to the OSI Reference Model
structure. As illustrated in the diagram, the Layer 3 entities access the Data-link service using the
four primitives:
• Request,
• Indication,
• Response, and
• Confirmation.
Two peer entities within Layer 2, that communicate using a peer-to-peer protocol (Q.921), provide
the necessary Data-link service functions. Access to the data-link service is via the service access
points on the Layer 2 to 3 boundary.
OSI models the data-link service as a pair of queues, one from left to right, and another from right
to left in the diagram. The sender places objects (frames) into the queue and the receiver removes
them from the queue.
Confirmation
Response
Request Service Access Points Indication
Data-link Layer
Peer-to-peer
Protocol
Like a proper OSI layer service description, Recommendation I.440 (Q.920) has a list of primitives
for communication both upward and downward. LAP-D has slight twist in that there are also a set
of primitives, which Q.920 sometimes shows as communicating sideways (this is just the drawing
technique) that communicate with management functions. These are best thought of as layer
management functions.
Although the last two groups of primitives in the facing table show the Layer 1 functions (probably
because the Layer 1 documents did not), you will note that Layer 2 does not deactivate Layer 1.
This will be discussed later, but since there can be multiple logical data-links running over a single
Physical Layer, it is logical that one data-link entity cannot deactivate the Physical Layer, since it
cannot know if there are other active data-links.
The management-to-Layer 2 primitives relate to the TEI assignment procedures, which we will
also discuss later.
M MPH_Activate _ X _ _ _ _
MPH_Deactivate X X _ _ _ _
L1 MPH_Information _ X _ _ _ X connected/disconnected
L
M Q.931 Entity
E
L3 - L2 Primitives
L
L2 - M Primitives M LAP-D Entity
E
L1 - L2 Primitives
L
L1 - M Primitives M Layer 1 Entity
E
Applicability of DL Primitives
Acknowledged information transfer uses the complete LAP-D set of commands and responses and
acknowledges all frames. It also provides error recovery procedures and flow control procedures.
Referring to the diagram, it will be seen that Layer 2 does not confirm data (I frames). I frames sent
by Layer 2 are protected against errors and are flow controlled. However, since Layer 3
acknowledges the signaling messages that they contain, there is no need for Layer 2 confirmation
procedures.
Applicability of DL Primitives
Point-to-point Information
Generic Name Transfer Mode Broadcast
of Primitive Information
Acknowledged Unacknowledged Transfer Mode
Establish Confirmed
Service
Release Confirmed
Service
Unconfirmed
Data Service
Data-link Functions
Any data-link protocol must perform a set of functions to provide a service. The data-link entity
receives a stream of bits from the Physical Layer. Whether it receives those bits individually or in
octets is irrelevant to the data-link entity since they must be given a context for them to be
meaningful.
In a bit-oriented protocol like HDLC, this means grouping the bit stream into frames and this is the
first function of our data-link entity. In order to ensure that corruption of the bits does not occur
during the transmission, the protocol does a form of error checking. The next function does this
checking and throws out any frames that do not pass the error check.
Assuming all is well, the error checker passes the good frames to a frame sequencer, a function that
ensures we receive the frames in the same sequence as they were transmitted.
The next function, assuming a good frame that is in the proper sequence, is to analyze the frame to
determine its purpose, i.e., protocol control, error reporting, information for the Network Layer,
etc.
All these functions are under the control of the protocol state machine manager, whose function is
to issue re-transmission requests, keep the sequence counters, etc.
Although we used HDLC as an example, these functions apply to almost any data-link design.
We will devote the balance of this chapter to the two data-link Recommendations, Q.920 and
Q.921. We do not intend to cover all parts of HDLC, but only the class and options implemented
by LAP-D. The ANSI T1.602 standard is effectively the body of Q.921 with an ANSI format and
apart from this both documents are identical.
Data-link Functions
FRAME ANALYZER
FRAME SEQUENCER
PROTOCOL
STATE
MACHINE
MANAGER
FRAME CHECKER
BIT FRAMER
The ISO standard divides HDLC into three basic classes and any class may also select options
from among the fourteen provided. The Unbalanced Normal (UN) class consists of a primary, or
master, station and one or more secondary, or slave stations. The Unbalanced Asynchronous (UA)
class consists of a single primary and a single secondary station. The Balanced Asynchronous (BA)
class consists of two combined stations, i.e., stations with both primary and secondary
functionality.
Primary stations have sole responsibility for error recovery; secondary stations can only report
errors. In UN class, the secondary stations only transmit when the primary gives them permission
to do so, not unlike a form of polling. In UA class the secondary station transmits whenever it
needs to do so (NB: This is the meaning of asynchronous in HDLC, as it is a synchronous protocol
in the transmission sense). Finally, in BA class, either station transmits as needed and each station
is responsible for recovery of its own detected errors.
In each class block are the list of commands and responses that each station may issue in its basic
configuration. To use other commands or responses, the designer selects options from the lists
below. The shading in the diagram represents the class and options used by LAP-D. This is a very
convenient way of defining a protocol for if you order a chip to do HDLC - BA,1,2,4,7,8,10 - you
will get exactly what you need for LAP-D. If you simply order an HDLC chip you might get
LAP-B (Link Access Procedure - Balanced) or IBM’s SDLC, quite different protocol subsets.
Legend:
UN UA BA
PRI SEC PRI SEC COMBINED
STA STA STA STA STATION
CMD RES CMD RES CMD RES
I I I I I I
RR RR RR RR RR RR
RNR RNR RNR RNR RNR RNR
SNRM UA SARM UA SABM UA
DISC DM DISC DM DISC DM
FRMR FRMR FRMR
MOD 8 FCS 16 MOD 8 FCS 16 MOD 8 FCS 16
We get transparency by framing the bits into groups, or frames, delimited by special characters
called flags. A flag is the 8-bit pattern 01111110. To prevent the flag character from occurring
anywhere else in the frame, a process of bit insertion/deletion (described later) is used.
There are three other fields in an HDLC frame; the Address, Control, and FCS fields. To identify
the stations on the data-link, the Address field is used. All data-link control functions use the
Control field. The FCS, or Frame Check Sum, carries the result of a cyclic redundancy check that
is done on the transmitted data and identifies frames that are received with bit errors.
Between the Control and FCS fields is the Information field that may be of any practical length.
You may use odd numbers of bits; however, most protocols are octet aligned in practice.
The delimiter of HDLC frames is the 01111110 flag character, inserted before and after the
information transmitted. There may be as many flag characters between frames as you wish. The
closing flag of one frame may also serve as the opening flag of the next frame.
To prevent a duplication of the 01111110 bit pattern anywhere else within the frames, we use a
process of bit insertion / deletion. This is the function that gives HDLC its transparency, i.e., the
complete tolerance of any bit pattern between flags. The transmitter scans the outbound
information and counts the binary one bits. After any occurrence of five contiguous one bits, it
inserts a zero bit regardless of the value of the next bit.
On reception, the receiver first secures frame alignment by scanning the bit stream for the
01111110 pattern. Once it has achieved frame alignment, it scans all subsequent bits. When it finds
five contiguous one bits, it examines the next bit’s value. It removes this bit if the value is zero, if
the bit value is one, the receiver assumes it (the last eight bits) to be the closing flag.
This is a very simple and effective mechanism for achieving transparent operation, which only
adds about 2-3% overhead to the transmission.
Direction of Transmission
Send
1 1 1 1 1 1 1 1 1 1 0 0 1 1
Stuff zeroes
0
1 1 1 1 1 0 1 1 1 1 1 0 0 1 1
Recv
1 1 1 1 1 1 1 1 1 1 0 0 1 1
0
0
Remove zeroes
1 1 1 1 1 1 1 1 1 1 0 0 1 1
There are two basic frame formats for LAP-D. Non-information carrying frames use Format A,
e.g., supervisory, or unnumbered frames which have no information field.
Format B frames carry information and thus have an information field, e.g., I frames, UI frames,
XID frames, and FRMR frames.
One exception to these diagrams is in the Control field. For unacknowledged operation the control
field is one octet in length. For acknowledged operation, only frames with sequence numbers
require the two-octet Control field. The difference in size is caused by LAP-D’s use of the modulo-
128 version of HDLC where there is a seven-bit sequence number.
FORMAT A FORMAT B
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
FLAG FLAG
ADDRESS ADDRESS
ADDRESS ADDRESS
CONTROL CONTROL
CONTROL CONTROL
FCS INFORMATION
FCS FCS
FLAG FCS
FLAG
The first implementations of HDLC only used a single address octet. For this reason, early LSI
implementations of HDLC only provided for a single octet address.
However, the ISO standard provides for a limitless address space. The first (least significant)
address bit is an Extended Address (EA) bit. If this bit is set to binary zero, it means that the address
continues into the next octet. If this bit is set to one it means that this is the only (or last) address
octet.
LAP-D uses the two address octets shown in the diagram. The first address octet contains the
Service Access Point Identifier (SAPI) which identifies the service that is accessed on the D-
Channel. The second address octet contains the Terminal Endpoint Identifier (TEI) which
identifies the terminal using the D-Channel.
The Command Response (CR) bit in the first octet is an interpretation of SG 11, the designers of
LAP-D. It was their contention that this bit serves solely to identify whether the frame was a
Command or Response frame. Under the rules of HDLC, this is true for the BA class which LAP-
D uses, but not necessarily true for other classes of operation.
It is this double address that gives LAP-D its multiplexing functions. The SAPI address provides
a coarse address for up to 64 potential services, while the TEI address provides for multiple virtual
LAP-D links within each SAPI service.
HDLC Standard
1st Octet 2nd Octet 3rd Octet
Addr E Addr E Addr E
A A A
SAPI C TEI
R 0 1
Study Group 11 based their reasoning for calling the second bit of the first octet of the address a
command/response on the HDLC rule for distinguishing commands from responses.
This rule states that commands are sent with the address of the data-link peer, i.e., if you are
sending a command it is sent to some station. Responses are sent with the address of the sender,
i.e., if you are sending a response, it is sent from some station. According to SG 11’s interpretation,
a LAP-B data-link does not have addresses, merely a C/R bit.
This reasoning works with the balanced class of HDLC, but would limit the total address space if
used in the unbalanced normal class by a power of 2 since they could only use even station
addresses, or 6-bit addressing to put it another way.
The table at the bottom of the diagram shows the convention adopted by LAP-D.
8 7 6 5 4 3 2 1
C/R
Command/Response Direction Value
Network to User 1
Command
User to Network 0
Network to User 0
Response
User to Network 1
These tables show the assigned SAPI and TEI values for LAP-D. As can be seen, out of the
possible 64 SAPIs, there are only 4 assigned. This leaves ample room for growth in the future.
• The TEIs are all potentially assigned simply because they are already assigned to a specific
use, namely terminal identification.
• TEI 127 is the broadcast TEI address, used mainly during TEI assignment procedures.
• TEIs 0 - 63 are set aside for use by terminals with fixed TEI assignment. These would be
terminals where the TEI is set by hardware switches or strapping.
• TEIs 64 - 126 are set aside for terminals with software control of their address. Such
terminals are capable of negotiating with the network to obtain a working TEI.
The advantage of this dynamic TEI assignment is for terminal portability. Imagine a terminal, such
as a portable computer used in the office, perhaps having a TEI of 120. If that same terminal were
moved to another passive bus (S/T), or even taken home, it might find that particular TEI (120)
already used by another terminal. For the dynamic terminal, it is a simple matter to negotiate a new
TEI with the network or NT2. This capability virtually eliminates wiring changes in a business
whenever staff movement occurs.
First, remember that the D-Channel (the one that runs between the terminal and the exchange
switch) does not have an address. We hesitate to call this the physical D-Channel since it is really
a multiplexed bit stream derived from the total 192 kbit/s bit stream, at least as seen at the S/T
reference point. However, for lack of a better name we will refer to this as the physical D-Channel.
The Data-link Connection (DLC) between TEs and the NT are logical connections that operate
over this physical D-Channel.
The combination of the SAPI and TEI identifies each logical Data-link Connection or DLC.
The TEI is consistent for each terminal, but may identify two or more DLCs as long as it involves
different SAPIs. In the illustration on the facing page the logical DLCs from terminals 24, 33, and
68 are all involved in signaling and thus all use SAPI 0. Terminal 77 is performing both a signaling
function and a packet-mode transfer function and has two logical DLCs in operation. When we say
that all of these logical DLCs are running at the same time, we mean that they are running in a
sequential fashion. Remember that the Layer 1 Collision Resolution function ensures that each
terminal gets its fair share of the single physical D-Channel in a round-robin manner.
The reason for discussing addressing at length is because it sometimes gets confusing. ISDN
customers have numbers and sub-addresses. An ISDN number, like present day telephone
numbers, points to the T reference point, i.e., it does not identify any specific terminal. For this
reason, the ITU-T introduced the sub-address, which can identify a particular terminal when
coupled with the ISDN number. Layer 3 messages convey these numbers and sub-addresses, but
they are not Layer 3 addresses, nor are they network addresses. The individual subscribers will
have to maintain such sub-addressing information.
Layer 2 also has addresses, the SAPI, and TEI, which identify logical data-link connections on the
D-Channel. Layer 1 did not have any addresses until the addition of device addressing that the T1
committee introduced for equipment maintenance, i.e., see reference to worst case reference
configuration in Chapter 2.
Address = 0,24
24
Address = 0,33
33
0
Physical D-Channel has no address
68 Address = 0,68
Address = 0,77
77
Address = 16,77
16
Terminals (TEI)
Network (SAPI)
The HDLC control field has three basic formats; an Information frame (I) format, a Supervisory
frame (S) format, and an Unnumbered (U) frame format.
The extended numbering format is shown in the diagram. Extended numbering (modulo 128)
allows for more outstanding frames (127) than the regular (modulo 8) format. The larger seven-bit
sequence numbers (Ns & Nr) for the extended numbering doubles the I and S format control fields
to two octets. Unnumbered frames do not carry a sequence number and remain the same as in
normal sequence numbering mode.
I frames are identified by the zero in the first bit of the first octet.
S frames are sub-divided by the two SS bits; thus there are only four possible types.
U frames are sub-divided by the five MMMMM bits allowing for 32 possible types.
In addition to using sequence numbers in information and supervisory frames, each LAP-D entity
maintains three counters (or values):
V(s) is the sequence number of the next numbered frame to be transmitted and is set to 0 (zero)
upon initialization. This number is incremented by 1 each time a frame is transmitted until
it reaches modulus-1, i.e., 127, when it is reset to zero.
V(r) is the sequence number in the sequence numbered frame that is expected to be received.
The Ns number of a correctly received frame is compared to this value and if a match is
found, the frame is accepted and the V(r) value is incremented by 1. The same modulus-1
rule applies.
V(a) is the sequence number of the last frame acknowledged by the LAP-D entity’s peer entity.
Actually, V(a)-1 is the last acknowledged frame, since V(a) is updated by the Nr value of
each correctly received frame, and by the rules Nr represents, the sequence number
expected in the next frame to be sent to the peer entity. Thus, by implication, it indicates
that frames numbered up to Nr-1 have been correctly received.
8 7 6 5 4 3 2 1
Ns 0
I Format
Nr P/F
X X X X S S 0 1
S Format
Nr P/F
M M M P/F M M 1 1 U Format
This diagram illustrates the complete command and response set of LAP-D. Note that the selection
of option 8 deletes I frames as responses. With the balanced class of station there is no need to have
response I frames and eliminating them also provides a means of loopback detection.
The remainder of the commands and responses are used in the normal HDLC manner.
REJ requests a re-transmission of frames received with CRC errors and all subsequent frames
(back up and retransmit).
SABME (Set Asynchronous Balance Mode Extended) is a little different from what is shown in
the HDLC chart. The E on the end of any mode setting command shows that the extended
numbering option is to be used (option 10). A SABM would mean modulo-8 sequence numbering,
a SABME means modulo-128 sequence numbering. LAP-D only uses extended sequence
numbering.
DM means that the station data-link has not been set into operation by a SABME and cannot accept
any frames (other than UI).
FRMR means that the frame received had a good CRC, but is simply of a type that the receiving
station does not have in its repertoire. A frame that is too short or too long will also get a FRMR
response.
XID (Exchange Identification) is a means of negotiating parameters with the network. The user
puts the parameters they would like in the XID information field. When the network responds with
XID, the parameters in the information field are its final offer (one time negotiation). If the network
sends an XID frame with no information field it means that the network does not support parameter
negotiation (at least not on-line). Note that the description (see page 4 - 44) has been removed from
Q.921 and the Recommendation only states that it may be received and ignored.
Note: The earliest published versions of the Blue Book for Q.920 and Q.921 had errors in this table,
i.e., most of the encodings were shown as all zeroes. The table in this workbook is correct and you
may use it if you have not obtained the errata sheets for the Blue Book or the March 93 version.
Encoding
Format Commands Responses
8 7 6 5 4 3 2 1
Information Ns 0
Transfer I(nformation)
Nr P
0 0 0 0 0 0 0 1
RR RR
Nr P/F
0 0 0 0 0 1 0 1
Supervisory RNR RNR
Nr P/F
0 0 0 0 1 0 0 1
REJ REJ
Nr P/F
SABME 0 1 1 P 1 1 1 1
DM 0 0 0 F 0 0 1 1
UI 0 0 0 P 0 0 1 1
Unnumbered DISC 0 1 0 P 0 0 1 1
UA 0 1 1 F 0 0 1 1
FRMR 1 0 0 F 0 1 1 1
The P / F bit controls the dialogue in the unbalanced normal class. In UA and BA classes it solicits
an immediate response. Because of HDLC’s extended sequence numbering, receiving stations are
not obliged to acknowledge every frame immediately. This is the meaning of the modulus number
specified in HDLC. With a 3-bit sequence number in HDLC frames, (modulus-8) frames received
need only be acknowledged after seven frames have been received. With a seven-bit sequence
number (modulus-128) acknowledgment is only necessary after 127 frames have been received.
This scheme improves data-link efficiency greatly over the older every-frame acknowledgment
schemes. However, it may sometimes place high demands on storage capacity in the terminal
equipment, since all unacknowledged frames must be held in case re-transmission is required.
Thus a window, or K factor was introduced whereby the data-link entities agree to some value
lower than the full modulus-1 that HDLC provides. For example, if in a modulus 128 data-link a
window size of 33 is agreed to by the entities, the receiver must acknowledge after receiving 33
frames.
Should a transmitting station find itself running out of frame storage space, or should it suspect
some loss of frame sequence number synchronization, it may demand an acknowledgment from its
peer entity. By setting the P bit in a Command frame, the transmitting station obliges the receiving
station to respond at the first opportunity. Setting the F bit in the response frame means that the
frame is a response to this request.
This table shows the usage specified by LAP-D for P / F bit usage.
This diagram shows the significant octets of the Frame Reject (FRMR) frame. This use of this
frame is for when the station receives any frame that:
The first two octets (5 & 6 of the frame) contain the control field of the rejected frame. The seventh
octet contains the receiving station’s current send state variable (send sequence number it next
expects to use). The eighth octet contains the receiving station’s current receive state variable
(receive sequence number of the frame it next expects to receive).
If the rejected frame is an unnumbered frame, the control field of the rejected frame is placed in
octet 5 and octet 6 is set to all zeroes.
The C/R bit is set to 1 if the rejected frame was a response and set to 0 if the rejected frame was a
command.
If bit W is set (1) the control field returned contains an unimplemented command.
If bit X is set (1) the frame contained an information field that is not permitted, or the supervisory
or unnumbered frame was of incorrect length.
If bit Z is set (1) the frame control field contained an invalid Nr number. Unused bits must be set
to zero as shown in the figure.
Recommendation Q.921 now states that a station should never send FRMR but should be prepared
to receive it! That seems strange at first look, but is presumably because older TEs may send the
FRMR, and any X.25 TEs using LAP-B are permitted to send FRMR.
* The window is the range of frames that a station may receive without sending an
acknowledgment. The maximum window size is modulus-1.
HDLC Header
Control Field of
Rejected Frame
Vs 0
Vr CR
0 0 0 0 Z Y X W
HDLC Trailer
Coding of the XID information field is shown in this diagram. This coding follows the common
procedures in use today. After the format and group identifiers is the length (GL) of the complete
parameter group. A Parameter Indicator (PI) precedes each parameter, followed by a length of the
parameter field (PL), followed by the actual parameter. The two PI fields indicate the total frame
size the DL entities should use during transmission and reception.
The format and group identifiers serve to indicate the format of the information portion of the XID
frame as being the ISDN LAP-D type.
The Group Length (GL) serves to indicate the length of the balance of the frame, in this case 14
octets.
The next field (PI) indicates that the parameter to follow refers to the frame size to be transmitted
by the entity sending this XID frame, the next value (PL) indicates that the value to follow occupies
two octets. In these two octets is the actual binary value of parameter N201 that is the frame size.
Default is 260 octets of information plus the LAP-D header and trailer.
The next group negotiates the same value for the receive direction.
Window size is negotiated next in octets 17 - 19, i.e., the K value. The default values for K are:
The final parameter (octets 20 - 22) is for the value of timer T200 and is set in 0.1 second
increments with a maximum value of 25.5 seconds. T200 has a default value of 1 second for
normal loops. If the user access to an ISDN is via a satellite connection, a value of 2.5 seconds is
recommended.
8 7 6 5 4 3 2 1
Octet 5 1 0 0 0 0 0 1 0 Format Identifier (FI)
6 1 0 0 0 0 0 0 0 Group Identifier (GI)
7 0 0 0 0 0 0 0 0
Group Length (GL)
8 0 0 0 0 1 1 1 0
9 0 0 0 0 0 1 0 1 PI = Frame Size (Transmit)
10 0 0 0 0 0 0 1 0 PL = 2
11 215 28 PV = N201 Value of Transmitter
12 27 20
13 0 0 0 0 0 1 1 0 PI = Frame Size (Receive)
14 0 0 0 0 0 0 1 0 PL = 2
15 215 28 PV = N201 Value of Receiver
16 27 20
17 0 0 0 0 0 1 1 1 PI = Window Size (Transmit)
18 0 0 0 0 0 0 0 1 PL = 1
19 0 26 20 PV = K Value
20 0 0 0 0 1 0 0 1 PI = Re-transmission Timer (T200)
21 0 0 0 0 0 0 0 1 PL = 1
22 27 20 PV = T200 Value
If a field spans or partially spans two octets, as in the upper right figure, the high order bits appear
in the lowest numbered octet and the low order bits in the highest numbered octet. The bits are
ordered in the same way as a single octet fields, i.e., bit one has a lower significance than bit 2, etc.
The only departure from this convention is the Frame Check Sum (FCS) field. In the FCS, bit 1 is
the higher order bit and bit 8 is the lower order bit.
Knowing the conventions used is very important to anyone building or programming to any
standard, and not all standards illustrate bits and octets in the same manner.
8 7 6 5 4 3 2 1
First octet
Octet 1 24 23 22 of field
1 0
Second octet
Octet 2 2 2 of field
Octet 3
Octet 4
First octet
28 216 of field
20 27 Second
of field
octet
Octet n
Data-link Connections
The function of the Data-link Layer is to convey information between Layer 3 entities. In the
discussion in Chapter 2, you will remember that there is a possibility of up to eight terminal devices
(TEs) connected to a single ISDN S/T reference point. This means that there must be multiple data-
link connections available for these potential Layer 3 entities.
The addressing functions of the data-link perform this multiplexing. Addresses subdivide into
Service Access Points (SAPs) and Connection Endpoints (CEs) within the SAPs. In ISDN
terminology, these are Service Access Point Identifiers (SAPIs) and Terminal Endpoint Identifiers
(TEIs) respectively.
The diagram illustrates how the D-Channel provides these Data-link Connections (DLCs). The top
figure shows a simple point-to-point data-link connection between the user’s TE and the network’s
Exchange Termination (ET). Note that this illustration includes the NT2, i.e., there is no difference
at the S reference point whether provided by an ISDN exchange or an NT2.
The middle figure illustrates two user TEs connected to the same S/T reference point with separate
data-link connections attached to the same SAPI. Finally, in the bottom figure there are two TEs
connected to the same S/T reference point attached to separate SAPIs. The data-link connections
are unique in every case.
Data-link Connections
ET/NT2
TE
SAPIx
D-Channel
ET/NT2
TEa TEb
SAPIx
ET/NT2
TEa TEb
SAPIx SAPIy
Data-link Connection
Within the Q.920/441 Recommendations and others, there is a multiplexor function defined in
Layer 2. This function examines the SAPI of each incoming frame and routes the frame to the
appropriate Data-link Service Access Point (DLSAP in OSI terminology).
Within each SAPI there can be multiple logical D-Channel or LAP-D operations. The TEI thus
equates to the OSI connection endpoint identifier, completing the relationship with the OSI
reference model.
The shaded arrows serve to illustrate the unused SAPIs that exist within ISDN. Whatever new
services the ITU-T may introduce, there is no shortage of protocol address space for them.
Potential SAPIs, or services, might be directory services, customer services, etc.
ISDN has the potential for pre-wiring a city or exchange area and leaving unused subscriber access
points with only a single SAPI active. This SAPI could be the customer service agent; new
subscribers could simply plug in their ISDN terminals and negotiate the provision of full service
without human intervention on the part of the network operator.
FRAME DISTRIBUTOR
Layer 2
FRAME ASSEMBLER & CHECKER
D-Bits
Layer 1
Although there is only one physical D-Channel, with the passive bus arrangements there could be
many logical D-Channels. Since each logical device (TE) would have a separate address (TEI),
the exchange switch has a means of distinguishing one virtual D-Channel from another.
As noted on the previous page, there are potentially 127 TEIs in the D-Channel address space of
LAP-D. It is, therefore, quite possible to have multiple logical devices within a single physical
device as illustrated here. In each logical device there is a TEI, and therefore there would also be
a logical D-Channel
In effect, there is no practical limit on the number of logical D-Channels that could exist other than
the data rate of the physical D-Channel itself.
Physical Device
Logical
Device
Logical D-Channel
Logical D-Channel
Physical Device
Logical
Device
As if SAPIs and TEIs were not enough, SG 11 introduced two other identifiers in connection with
the data-link connection, a Data Link Connection Identifier (DLCI) and a Connection Endpoint
Suffix (CES). This diagram is SG 11’s way of making it all perfectly clear.
Basic to the understanding of these relationships is that a terminal device must have a TEI assigned
in order to establish a peer-to-peer data-link connection with the network. This is because the TEI
is part of the LAP-D address and the address is what identifies one particular data-link connection
from any other data-link connections that may be operating over the same D-channel, for example,
on a passive bus there could be as many as eight data-link connections.
A data-link connection is identified by a Data Link Connection Identifier (DLCI) carried in the
address field of each frame. The DLCI consists of two elements: the SAPI and the TEI. The DLCI
is a data-link concept. It is used internally by the data-link entity and is not known by the Layer 3
entity or the management entity. In these two latter entities, the concept of the connection endpoint
identifier is used. In the diagram, the user terminal TE(2) has, for signaling, a DLCI of 0+3 or 0+8.
We will see the DLCI used as a logical link identifier in rate adaptation with Recommendation
V.120 as well as in Frame Relay modes.
The Connection Endpoint Identifier (CEI) is composed of the SAPI information and a reference
value named the Connection Endpoint Suffix (CES). The CES is a value selected by the Layer 3
or management entity to address the data-link entity. When the relevant TEI is known by this
entity, it will internally associate the DLCI to the CEI. The Layer 3 and management entities will
use these CEIs to address their peer entities. In the diagram, the user terminal TE(1) would know
its peer entity for signaling as 0,1 and the peer would also happen to use 0,1 although this need not
be the case. The CES values are also used with supplementary service protocols in
Recommendation Q.932.
USER NETWORK
CESs
B 1 B 1 B 1 2 3 2 1 B 1 B
16 0 0 0 16
TEI
TEI TEI TEI TEI TEI 3
127 88 127 88 127
TEI
8
This diagram simply illustrates a normal exchange between a user and the network. In this
instance the user requests DLC establishment with SABME and the network acknowledges with
UA (Note: P/F bits are not shown). The “letter, number, number” designation indicates the frame
type, the send sequence number, and the next expected receive sequence number respectively.
In the example, the user’s I frame I,2,2 is corrupted during transmission and is discarded by the
network. The network simply knows that there was a non-productive reception and does not issue
a REJ until the next valid frame arrives. Thus, the next frame that the network transmits indicates
that the next frame it expects to see is still frame number 2.
Frames I,5,4 from the user and I,4,5 from the network simply indicates that this is a full duplex
channel and frames may cross each other.
Finally, when there are no more I frames to send, each station resorts to the use of RR supervisory
frames to acknowledge each other’s transmissions. At this point, the DISC - UA sequence may be
used to disconnect the DLC.
SABME REJ,2
UA I,2,3
I,3,3
I,0,0 I,4,3
I,0,1 I,3,5
I,1,2 RR,5
I,2,2 RR,6
x
I,2,2 DISC
I,3,3 UA
This table categorizes the actions to be taken in the various states of the Data-link Connection
(DLC).
Here, the MDL_ERROR_indication would trigger the TEI check procedures to verify if two
terminals were using the same TEI and whether action should be taken to remove the TEI
assignment from one or both.
At this time At this time the At this time the At this time the TE has an operat-
the TE has TE has issued a TE has issued a ional DLC with the NT and the
a TEI assigned SABME, but DISC, but has network. The DLC may be running
has not received not yet received normally or may be in a timer
but has not est- a UA response a UA response recovery condition.
ablished a DLC
DM Response MDL_Error
Ignore Solicited Solicited Solicited
F=1 Indication
Supervisory MDL_Error
Response Ignore Ignore Ignore Solicited
F=1 Indication
Supervisory
Response Ignore Ignore Ignore Solicited Solicited
F=0
This diagram illustrates a very important function of the Data-link Layer, the assignment of TEIs.
Since we cannot establish a DLC without a TEI (the frames would be incomplete without all the
address, e.g., SAPI plus TEI), the UI frame is the only one that we can use. The terminal issues a
UI frame addressed to SAPI 63, with TEI 127 that contains an ID request message, a Reference
Indicator (Ri) and an Action Indicator (Ai).
The Ri is very important, since it is the only reference that the terminal has with which to associate
the network response. In a multi-use D-Channel, several terminals could be requesting IDs at the
same instant. The Ri is a randomly generated number that should be unique to each terminal.
UI frames receive no acknowledgment, so the terminal starts a timer (T202, default is 2 seconds)
with the transmission of the frame. If the network does not respond, the terminal retransmits the
same frame N202 times (N202 = 3) before abandoning the attempt. Each transmission is given a
new value of Ri.
In the case of terminals with a fixed TEI, the value is placed in the Ai field. In the case of terminals
with dynamic TEI assignment capability, the Ai field is set to 127 to indicate that whatever the
network assigns is acceptable. The network responds with a UI frame containing the Ri from the
terminal’s request UI frame, and either assigns or denies a TEI.
The Assignment Source Point (ASP) may, when the identity request is received:
• deny requests with values in the range 64-126 or ignore requests with values in the range 0
- 63,
• ignore the request if it has already received a request with an identical Ri, and that request
has not yet been issued a response. In this event, neither request will get a response. This
may seem strange, but the network has no way of determining if a single terminal had
neglected to change the Ri value on a re-transmission, or if two terminals had somehow
selected identical TEIs and Ri values.
When the ASP responds with an assigned TEI value, all terminals should examine the message. If
a terminal already has that TEI, but did not make the original request, it should initiate a removal
or verify procedure. If the terminal originated the request and the Ri values match, it will accept
the TEI value and enter the TEI assigned state.
- OR -
When the network desires to check the TEIs that are in use, it issues the TEI check request. This
could be for a variety of reasons, either to check its records, or because it has noted double
answering (two terminals using the same TEI).
If the Ai field is 127, it means that the network wants everyone to respond. If the Ai field is set to
a specific TEI, then only the terminal(s) using that TEI are to respond.
The multiple use of identical TEIs is illustrated by the possibility that the network could receive
multiple responses even in the single Ai case. The normal response when the network discovers
two terminals using the same TEI is for the network to issue an ID Remove (request) to both
terminals. The two terminals would then need to request new TEI assignments if they use dynamic
assignment. If the terminals are of the fixed assignment variety, some form of maintenance action
should be initiated.
Start
T201
- and possibly -
- then -
Recommendation Q.921 provides the ID verify request so that terminals will have a means of
checking the TEIs in use on their passive bus. This request is only set for the Ai equal to a specific
TEI case: an Ai value of 127 is not allowed.
A user’s ID verify request simply triggers the ID check procedure by the network.
- and possibly -
This diagram illustrates the format of the information field of the UI frames used in TEI
management procedures.
The management entity identifier is set to Hex 0F (0000 1111) and all other values are reserved.
The message type identifies the type of request (see next table).
The action indicator is set to 127 or a specific TEI value (see next table).
The E bit is an extension indicator, set to zero to indicate an extension, or set to one to indicate the
last, or only, Ai field. Thus, a single transmission could request assignment of several TEIs.
8 7 6 5 4 3 2 1
Reference Number 2
Message Type 4
Action Indicator E 5
Action Indicator E
Action Indicator E n
This table shows all the possible values that may be used in the various fields of the TEI
management messages.
Note that for certain cases, where there is no need to establish a relationship between UI frames
sent and UI frames received, the Ri value is set to zero.
These procedures are for terminal devices using the dynamic TEI range of values. Terminal
devices using fixed TEI values do not need to negotiate a TEI value with the network. As you will
note in the table, a terminal always uses the Broadcast TEI, i.e., 127, when requesting a TEI
assignment. When requesting that the network verify a specific TEI, or when responding to an
identity check, then the terminal uses its actual TEI.
Identity Request 0000 1111 0 - 65535 0000 0001 Ai = 127, Any TEI
(user to net) Value acceptable
Ai = 64 - 126, Denied
Identity Denied 0000 1111 0 - 65535 0000 0011 TEI Value. Ai = 127, No
(net to user) TEI Value available
Identity Check Ai = 127, Check all TEI
Not Used
Request 0000 1111 Coded 0 0000 0100 Values. Ai = 0 - 126,
(net to user) TEI value to be checked
Identity Check Ai = 0 - 126, TEI Value
Response 0000 1111 0 - 65535 0000 0101 in use
(user to net)
The next three pages are not an actual part of the Recommendation, but simply serve to illustrate
a deactivation problem with LAP-D.
Given that each DLC on the D-Channel is an entity unto itself, it follows that no one DLC can be
allowed to deactivate the Physical Layer (in those networks that deactivate the physical interface).
For all that any single DLC could know, there may be several more DLCs in operation, so that a
deactivation of Layer 1 would have undesirable results.
In actual fact, it would be possible for any given DLC to know that other DLCs were operating on
the D-channel, since it would see frames bearing addresses other than its own address. However,
since it does not process these frames, nor maintain a state table for other DLCs, it is true to state
that the DLC would not know the state of other DLCs on Layer 1.
This model suggests a monitor function on the boundary between Layers 2 and 3 whose function
is to monitor all information flow and report to the system management whether the D-Channel is
free, in use, or simply has unit data flowing on it.
The model shows Layer 1 interacting with system management via MPH_primitives, being
deactivated by system management and also reporting actual activation or deactivation. Note that
Layer 2 is the entity to request Layer 1 activation, and not system management.
Higher Layers
System Status (Enable/Disable)
Management
Deactivation Monitor
Information
Procedure
(Free/In Use/Unit Data)
Layer 2
MPH_DEACTIVATE_Req
Layer 1
MPH_DEACTIVATE_Ind
MPH_ACTIVATE_Ind
This state diagram is for implementations that have the optional MPH_DEACTIVATE_
indication provided by the Layer 1 entity. It also shows the use of the free and in use indications
provided by the monitor.
State 1 represents the state where the Physical Layer is not activated and no data-link connections
are operational.
State 2 represents the state where the physical layer is activated but no data-link connections are
currently operational, nor are any mode setting commands outstanding. Timer TM01 is running
and upon expiry, if deactivation is enabled, an MPH_Deactivate_request primitive may be issued
to Layer 1.
State 3 represents the state where the Physical Layer is activated and at least one data-link
connection is in a mode setting or fully operational state.
State 4 represents the state where the physical layer is in a transitional state, i.e., at least one data-
link connection is in the mode setting or operational state. This condition arises when an activation
request has been given to Layer 1, but it has not yet sent an activation indication to system
management.
State 5 represents the state where the Physical Layer is in another transitional state, i.e., the
Physical Layer is neither activated nor deactivated, and no data-link connection is operational. In
this state, when timer TM01 expires, and deactivation is enabled, an MPH_DEACTIVATE_
request will be issued to Layer 1.
State 6 represents the state where the Physical Layer is in yet another transitional state, but in this
case at least one data-link connection is in a mode setting or operational state.
The number of states, especially the transitional states, may seem excessive, but it is simply a
method of accounting for the situations where some action has been requested by higher layers and
the performance of the action has not been reported.
Information
(Unit Data) TM01 Expiry
[Restart TM01] Deactivation Disabled
5 [Start TM01]
TM01 Expiry
Info Deactivation Enabled
Interrupted
and Free [MPH_DEACTIVATE_Req] 1
Note 1 No
Info Transfer
I MPH_ACTIVATE_Ind and Free
n
f TM01 Expiry Information
o Deactivation Enabled (In Use)
[Start r MPH_DEACTIVATE_Ind [MPH_DEACTIVATE_Req] Information
TM01] m
a (Free)
t
I i
n o 2
f n Information TM01 Expiry
o (Unit Data) Info Transfer Deactivation Disabled 4
r I [Restart TM01] and Free [Start TM01] No
m n Info Transfer
a and In Use
t U
i s Information
o e (In Use)
n [Stop [Stop TM01]
TM01] Information
F
r (Free)
e [Start TM01] 3
e
Info Transfer
6 MPH_ACTIVATE_Ind and In Use
Info
Interrupted
and In Use MPH_DEACTIVATE_Ind
MPH_ACTIVATE_Ind
Note 1: The Recommendation did not mark this path with any event or primitive. It would
seem logical that a MPH_ACTIVATE_request or PH_ACTIVATE_request would be the
event to trigger this transition.
This state diagram is for implementations that do not have the optional MPH_DEACTIVATE_
indication provided by the Layer 1 entity. It also shows the use of the free and in use indications
provided by the monitor.
States 1 to 4 are the same as in the previous description. States 5 and 6 are not possible since Layer
1 does not use the MPH_DEACTIVATE_indication, there is no need for the transitional states
associated with awaiting receipt of this primitive.
MPH_ACTIVATE_Ind Information
[Start TM01] (In Use)
1
No Info Transfer
and Free
2 4
Info Transfer TM01 Expiry No Info Transfer
and free Deactivation Disabled and In Use
[Start TM01]
Information (Free)
[Start TM01] MPH_ACTIVATE_Ind
In Annex A of Recommendation Q.921, there are some 35 state transition tables that cover the
eight major LAP-D states. Some of these major states also have minor states, e.g., State 5 is sub-
divided into three minor states, 5.0, 5.1, and 5.2.
The explanation of these state tables could be better; there is a typo in the plenary assembly
versions (AP-IX-122-E) that may or may not get corrected for the Blue Book versions.
The basic state table is divided into rows and columns (top diagram). The states are listed
horizontally across the top of the tables. The events that may occur are listed vertically down the
left side of the tables. In each row/column intersection (or cell), the action to be taken when, for
example, Event a occurs and the LAP-D state machine is in State 1, is listed (Action) and the
number of the next state is given in the bottom right corner of the cell (N).
What is not immediately apparent from the explanation is the case where the boundaries between
the row/column blocks are shown as dashed lines (middle diagram). Where this occurs, you will
find only a single action and transition number listed in the top left block of these sets. This is
effectively the same as if this same action and transition number were to be listed in all blocks of
the set (bottom diagram).
Regarding the typo, it concerns the use of the vertical bar “|” to indicate that such and such an event
occurring in such and such a state is impossible by the definition of the Data-link Layer service.
The actual tables in the first Blue Book appear to have substituted the numeric “1” in places where
the vertical bar “|”should have been used. Presumably this has been corrected in the March 93
version.
These state transition tables will be useful in creating an actual implementation of the LAP-D
protocol along with the prose description of the protocol. Depending upon the actual technology
used in an implementation (much of LAP-D is available in VLSI), you may need to use these
tables, or you may not.
A full set of conformance tests was developed in Tree and Tabular Combined Notation (TTCN), a
language that some test sets are able to implement directly. A group was established by COS to
write TTCN tests for National ISDN-1. It was originally planned to have this group write the tests
for National ISDN-2 but TTCN is an extremely tedious language and the group suffered from
burnout and was not able to continue with NISDN-2.
Event b
Event c
••••
Event z
Action
N
Action Action
N N
Action Action
N N
Summary
As at the end of earlier chapters, we include a similar diagram to illustrate just where in the seven-
layer stack the protocol of this chapter operates. You will note that this diagram is considerably
simpler than that of Chapter 2, since only a single protocol is involved. At the risk of overemphasis,
it is hoped that this makes clear that when we spoke of addresses in LAP-D we only referred to the
SAPI and TEI at Layer 2 and that these addresses are not to be confused with end-user addresses
or numbers.
Summary
TE
ET
Layer 2 Layer 2
ITU-T Q.921 LAP-D ITU-T Q.921
or or
ANSI T1.602 ANSI T1.602
NT
Notes: