InfoMagic Standards 1993 July/Disc.iso/ccitt/1988/troff/8_2_05.tro

Text File | 1991-12-22 | 129.7 KB | 3,983 lines

.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\"                 Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P

.rs
\v'|.5i'
.LP
\fBMONTAGE : \(sc 2.4.8.6 EN T\*\|ETE DE CETTE PAGE\fR
.sp 1P
.LP
\v'10P'
2.5
    \fIMultilink procedure\fR \fI(MLP) (\fR \fISubscription\(hytime\fR
\fIselectable option\fR \fI)\fR
.sp 9p
.RT
.PP
The multilink procedure (MLP) exists as an added upper sublayer of the
Data Link Layer, operating between the Packet Layer and a multiplicity
of single data link protocol functions (SLPs) in the Data Link Layer (see
Figure\ 1/X.25).
.EF '%    Fascicle\ VIII.2\ \(em\ Rec.\ X.25''
.OF '''Fascicle\ VIII.2\ \(em\ Rec.\ X.25    %'
.PP
A multilink procedure (MLP) must perform the functions of accepting
packets from the Packet Layer, distributing those packets across the available
DCE or DTE\ SLPs for transmission to the DTE or DCE\ SLPs, respectively,
and
resequencing the packets received from the DTE or DCE\ SLPs for delivery
to the DTE or DCE Packet Layer, respectively.
.RT
.LP
.rs
.sp 26P
.ad r
\fBFigure 1/X.25, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
2.5.1
    \fIField of application\fR
.sp 9p
.RT
.PP
The optional multilink procedure (MLP) described below is used for data
interchange over one or more single link procedures (SLPs), each
conforming to the description in \(sc\(sc\ 2.2, 2.3 and 2.4, in parallel
between a DCE and a DTE. The multilink procedure provides the following
general
features:
.RT
.LP
    a)
    achieve economy and reliability of service by providing
multiple SLPs between DCE and a DTE;
.LP
    b)
    permit addition and deletion of SLPs without interrupting
the service provided by the multiple SLPs;
.LP
    c)
    optimize bandwidth utilization of a group of SLPs through
load sharing;
.LP
    d)
    achieve graceful degradation of service when an SLP(s)
fails;
.LP
    e)
     provide each multiple SLP group with a single logical Data Link Layer
appearance to the Packet Layer; and
.LP
    f
)
     provide resequencing of the received packets prior to delivering them
to the Packet Layer.
.sp 1P
.LP
2.5.2
    \fIMultilink frame\fR \fIstructure\fR
.sp 9p
.RT
.PP
All information transfers over an SLP are in multilink frames
conforming to one of the formats shown in Table\ 9/X.25.
.RT
.LP
.rs
.sp 16P
.ad r
\fBTable 9/X.25 (comme figure), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
2.5.2.1
    \fIMultilink control field\fR
.sp 9p
.RT
.PP
The multilink control field (MLC) consists of two octets, and its contents
are described in \(sc\ 2.5.3.
.RT
.sp 1P
.LP
2.5.2.2
    \fIMultilink information field\fR
.sp 9p
.RT
.PP
The information field of a multilink frame, when present, follows the MLC.
See \(sc\(sc\ 2.5.3.2.3 and\ 2.5.3.2.4 for the various codings and groupings
of bits in the multilink information field.
.RT
.sp 2P
.LP
2.5.3
    \fIMultilink control field format and parameters\fR
.sp 1P
.RT
.sp 1P
.LP
2.5.3.1
    \fIMultilink control field format\fR
.sp 9p
.RT
.PP
The relationship shown in Table 10/X.25 exists between the order of bits
delivered to/received from an SLP and the coding of the fields in the
multilink control field.
.RT
.sp 1P
.LP
2.5.3.2
    \fIMultilink control field parameters\fR
.sp 9p
.RT
.PP
The various parameters associated with the multilink control
field format are described below. See Table\ 10/X.25 and
Figure\ 2/X.25.
.bp
.RT
.LP
.rs
.sp 19P
.ad r
\fBTableau 10/X.25 (comme figure), p. 3\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 31P
.ad r
\fBFigure 2/X.25, p. 4\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
2.5.3.2.1
    \fIVoid sequencing bit (V)\fR
.sp 9p
.RT
.PP
The
void sequencing bit (V)
indicates if a received
multilink frame shall be subjected to sequencing constraints. V set to\
1 means sequencing shall not be required. V set to\ 0 means sequencing
shall be
required.
.PP
\fINote\fR \ \(em\ For purposes of this Recommendation, this bit shall be set
to\ 0.
.RT
.sp 1P
.LP
2.5.3.2.2
    \fISequence check option bit (S)\fR
.sp 9p
.RT
.PP
The
sequence check option bit (S)
is only significant when V is set to\ 1 (indicating that sequencing of
received multilink frames shall
not be required). S set to\ 1 shall mean no MN(S) number has been assigned.
S\ set to\ 0 shall mean an MN(S) number has been assigned, so that although
sequencing shall not be required, a duplicate multilink frame check may be
made, as well as a missing multilink frame identified.
.PP
\fINote\fR \ \(em\ For purposes of this Recommendation, this bit shall be set
to\ 0.
.RT
.sp 1P
.LP
2.5.3.2.3
    \fIMLP reset request bit (R)\fR
.sp 9p
.RT
.PP
The
MLP reset request bit (R)
is used to request a
multilink reset (see \(sc\ 2.5.4.2). R set to\ 0 is used in normal communication,
i.e.\ no request for a multilink reset. R set to 1 is used by the DCE MLP
or DTE MLP to request the reset of the DTE MLP or DCE MLP state variables,
respectively. In this R\ =\ 1\ case, the multilink information field does not
contain Packet Layer information, but may contain an optional 8\ bit Cause
Field that incorporates the reason for the reset.
.PP
\fINote\fR \ \(em\ The encoding of the Cause Field is a subject for further
study.
.RT
.sp 1P
.LP
2.5.3.2.4
    \fIMLP reset confirmation bit (C)\fR
.sp 9p
.RT
.PP
The MLP
reset confirmation bit (C)
is used in reply to an R bit set to\ 1 (see \(sc\ 2.5.3.2.3) to confirm
the resetting of the multilink state variables (see \(sc\ 2.5.4.2). C set
to\ 0 is used in normal communications,
i.e.\ no multilink reset request has been activated. C set to\ 1 is used
by the DCE MLP or DTE MLP in reply to a DTE MLP or DCE MLP multilink frame,
respectively, with R set to\ 1, and indicates that the DCE MLP or DTE MLP
state variable reset process has been completed by the DCE or DTE, respectively.
In this C\ =\ 1 case, the multilink frame is used without an information
field.
.RT
.sp 1P
.LP
2.5.3.2.5
    \fIMultilink send state variable MV(S)\fR
.sp 9p
.RT
.PP
The
multilink send state variable MV(S)
denotes the
sequence number of the next in\(hysequence multilink frame to be assigned to an
SLP. This variable can take on the value 0 through 4095 (modulo\ 4096). The
value of MV(S) is incremented by 1 with each successive multilink frame
assignment.
.RT
.sp 1P
.LP
2.5.3.2.6
    \fIMultilink sequence number MN(S)\fR
.sp 9p
.RT
.PP
Multilink frames contain the
multilink sequence number
MN(S)
. Prior to the assignment of an in\(hysequence multilink frame to an
available SLP, the value of MN(S) is set equal to the value of the multilink
send state variable MV(S). The multilink sequence number is used to resequence
and to detect missing and duplicate multilink frames at the receiver before
the contents of a multilink frame information field is delivered to the
Packet
Layer.
.RT
.sp 1P
.LP
2.5.3.2.7
    \fITransmitted multilink frame acknowledged state\fR
\fIvariable MV(T)\fR
.sp 9p
.RT
.PP
MV(T) is the state variable at the transmitting DCE MLP or DTE MLP denoting
the oldest multilink frame which is awaiting an indication that a DCE SLP
or DTE SLP has received an acknowledgement from its remote DTE SLP or DCE
SLP, respectively. This variable can take on the value 0 through 4095
(modulo\ 4096). Some multilink frames with sequence numbers higher than MV(T)
may already have been acknowledged.
.RT
.sp 1P
.LP
2.5.3.2.8
    \fIMultilink receive state variable MV(R)\fR
.sp 9p
.RT
.PP
The
multilink receive state variable MV(R)
denotes the
sequence number at the receiving DCE MLP or DTE MLP of the next in\(hysequence
multilink frame to be received and delivered to the Packet Layer. This
variable can take on the value\ 0 through\ 4095 (modulo\ 4096). The value
of MV(R) is
updated as described in \(sc\ 2.5.4.3.2 below. Multilink frames with higher
sequence numbers in the DCE MLP or DTE MLP receive window may already have
been received.
.bp
.RT
.sp 1P
.LP
2.5.3.2.9
    \fIMultilink window size MW\fR
.sp 9p
.RT
.PP
MW is the maximum number of sequentially numbered multilink frames that
the DCE MLP or DTE MLP may transfer to its SLPs beyond the lowest numbered
multilink frame which has not yet been acknowledged. MW is a system parameter
which can never exceed 4095\ \(em\ MX. The value of MW shall be agreed
for a period of time with the Administration and shall have the same value
for both the
DCE\ MLP and the DTE MLP for a given direction of information transfer.
.PP
\fINote\fR \ \(em\ Factors which will affect the value of parameter MW
include, but are not limited to, single link transmission and propagation
delays, the
number of links, the range of multilink frame lengths, and SLP parameters
N2, T1, and\ k.
.PP
The MLP transmit window contains the sequence numbers MV(T) to MV(T) +
MW\ \(em\ 1 inclusive.
.PP
The MLP receive window contains the sequence numbers MV(R) to MV(R) + MW\
\(em\ 1 inclusive. Any multilink frame received within this window shall
be
delivered to the Packet Layer when its MN(S) becomes the same as
MV(R).
.RT
.sp 1P
.LP
2.5.3.2.10\ \
\fIReceive MLP window guard region MX\fR
.sp 9p
.RT
.PP
MX is a system parameter which defines a guard region of multilink sequence
numbers of fixed size beginning at MV(R)\ +\ MW. The range of MX shall
be large enough for the receiving MLP to recognize the highest MN(S) outside
of its receive window that it may legitimately receive after a multilink
frame
loss has occurred.
.PP
A multilink frame with sequence number MN(S)\ =\ Y received in this
guard region indicates that those missing multilink frame(s) in the range
MV(R) to Y\ \(em\ MW has(have) been lost. MV(R) is then updated to Y\ \(em\
MW\ +\ 1.
.PP
\fINote\fR \ \(em\ A number of methods may be selected in calculating a value
for the guard region MX:
.RT
.LP
    a)
    In a system where the transmitting MLP assigns \fIh\fR\d\fIi\fR\u\|
in\(hysequence contiguous multilink frames at a time to the
\fIi\fR th SLP, MX should be greater than or equal to the
sum of the \fIh\fR\d\fIi\fR\u\ +\ 1\ \(em\ \fIh\fR\d\fIm\fR\\d\fIi\fR\\d\fIn\fR\u,
where
\fIh\fR\d\fIm\fR\\d\fIi\fR\\d\fIn\fR\uequals the smallest \fIh\fR\d\fIi\fR\uencountered.
Where there are \fIL\fR \ SLPs in the multilink group, MX should
be greater than or equal to:
\v'6p'
.sp 1P
.ce 1000
@ pile {\fIL\fR above sum above \fIi\fR =1
} @ \fIh
\di\u\fR + 1 = \fIh
\dmin
\u\fR ; or
.ce 0
.sp 1P
.LP
.sp 1
    b)
    In a system where the transmitting MLP assigns on a rotation
basis \fIh\fR \| in\(hysequence contiguous multilink frames at a time to
each SLP, MX at the receiving MLP should be greater than or
equal to \fIh\fR (\fIL\fR \ \(em\ 1)\ +\ 1, where \fIL\fR is the number of SLPs
in the multilink group; or
.LP
    c)
    MX should be no larger than MW.
.LP
Additional methods of selecting MX values are for further
study.
.sp 1P
.LP
2.5.4
    \fIDescription of \fR \fImultilink procedure (MLP)\fR
.sp 9p
.RT
.PP
The procedure below is presented from the perspective of the
transmitter and receiver of multilink frames.
.PP
The arithmetic is performed modulo 4096.
.RT
.sp 1P
.LP
2.5.4.1
    \fIInitialization\fR
.sp 9p
.RT
.PP
The DCE or DTE will perform an MLP initialization by first
resetting MV(S), MV(T) and MV(R) to zero and then initializing each of its
SLPs. Upon successful initialization of at least one of the SLPs, the DCE
shall, and the DTE should, perform the multilink resetting procedure as
described in \(sc\ 2.5.4.2. An SLP initialization is performed according to
\(sc\ 2.4.4.1 of this Recommendation.
.PP
\fINote\fR \ \(em\ An SLP that cannot be initialized should be declared
out of service and appropriate recovery action should be taken.
.RT
.sp 1P
.LP
2.5.4.2
    \fIMultilink resetting\fR \fIprocedure\fR
.sp 9p
.RT
.PP
The multilink resetting procedure provides the mechanism for
synchronizing the sending and receiving MLPs in both the DCE and the DTE,
when deemed necessary by either the DCE or the DTE. Exact cases where the
MLP
resetting procedures are invoked is for further
.bp
.PP
study. Following a
successful
multilink resetting procedure, the multilink sequence numbering in each
direction begins with the value\ 0. Appendix\ III provides examples of the
multilink resetting procedures when initiated by either the DCE or the
DTE, or by both the DCE and the DTE simultaneously.
.PP
A multilink frame with R\ =\ 1 is used to request multilink reset, and
a multilink frame with C\ =\ 1 confirms that the multilink reset process
has been completed. An MLP resets MV(S) and MV(T) to zero on transfer of
a multilink
frame with R\ =\ 1; and resets MV(R) to zero on receipt of a multilink
frame with R\ =\ 1.
.PP
When the DCE MLP or DTE MLP initiates the resetting procedure, it
removes all of the unacknowledged multilink frames that are held in that MLP
and its associated SLPs, and retains control of those frames. Hereafter, the
initiating MLP does not transfer a multilink frame with R\ =\ C\ =\ 0 until the
reset process is completed. (One method to remove multilink frames in the
SLP is to disconnect the data link of that SLP.) The initiating MLP then
resets its multilink send state variable MV(S) and its transmitted multilink
frame
acknowledged state variable MV(T) to zero. The initiating MLP then transfers
a multilink frame with R\ =\ 1 as a reset request on one of its SLPs and
starts
Timer\ MT3. The value of the MN(S) field in the R\ =\ 1 frame may be any value,
since when R\ =\ 1 the MN(S) field is ignored by the receiving MLP. The
initiating MLP continues to receive and process multilink frames from the
remote MLP, in accordance with the procedures as described in \(sc\ 2.5.4.4
below until it receives a multilink frame with R\ =\ 1 from the remote
MLP.
.PP
An MLP which has received a multilink frame with R\ =\ 1 (reset request)
in the normal communication status from an initiating MLP starts the operation
as described above; the MLP should receive no multilink frame with R\ =\
C\ =\ 0
from the other MLP until the reset process is completed. Any such multilink
frame received is discarded. When an MLP has already initiated its own
multilink resetting procedure and has transferred the multilink frame with
R\ =\ 1 to one of its SLPs for transmission, that MLP does not repeat the
above operation upon receipt of a multilink frame with R\ =\ 1 from the
other
MLP.
.PP
Receipt of a frame with R\ =\ 1 (reset request) causes the receiving MLP
to deliver to the Packet Layer those packets already received and to identify
those multilink frames assigned to SLPs but unacknowledged. The Packet
Layer
may be informed of the packet loss at the original value of MV(R) and at any
subsequent value(s) of MV(R) for which there has been no multilink frame
received up to and including the highest numbered multilink frame received.
The receiving MLP then resets its multilink receive state variable MV(R) to
zero.
.PP
After an MLP assigns a multilink frame with R\ =\ 1 to one of its SLPs,
it shall receive indication of successful or unsuccessful transmission
from
that SLP as one of the conditions before transferring a multilink frame with
C\ =\ 1; when the initiating MLP then receives a multilink frame with R\
=\ 1, and has completed the multilink state variable resetting operation
described above, the initiating MLP transfers a multilink frame with C\
=\ 1 (reset confirmation) to the other MLP. When an MLP has:
.RT
.LP
    (1)
    received a multilink frame with R\ =\ 1,
.LP
    (2)
    transferred a multilink frame with R\ =\ 1 on one of its
SLPs, and
.LP
    (3)
    completed the multilink state variable resetting operation
above,
.LP
that MLP then transfers a multilink frame with C\ =\ 1 (reset confirmation) to
the other MLP as soon as possible, given that indication of the successful
or unsuccessful transmission of the R\ =\ 1 multilink frame has been received
from that MLP's SLP. The C\ =\ 1 multilink frame is a reply to the multilink
frame
with R\ =\ 1. The value of the MN(S) field in the above C\ =\ 1 frame may
be any
value, since when C\ =\ 1 the MN(S) field is ignored by the receiving MLP. The
multilink sequence number MN(S) received in each direction following multilink
reset will begin with the value zero.
.PP
When an MLP uses only one SLP to transmit the multilink frame with R\ =\
1 and the multilink frame with C\ =\ 1, the MLP can transfer the multilink
frame with C\ =\ 1 immediately after the multilink frame with R\ =\ 1 without
waiting for SLP indication of transmission completion. An MLP shall not
retransmit a multilink frame with R\ =\ 1 or a multilink frame with C\
=\ 1 unless Timer MT3 (see \(sc\ 2.5.5.3 below) runs out. An MLP may use
two different SLPs as long as one is used for transmitting the multilink
frame with R\ =\ 1 and the
other is used for transmitting the multilink frame with C\ =\ 1 following
receipt of the SLP indication of successful or unsuccessful transmission
of the R\ =\ 1 multilink frame. A multilink frame with R\ =\ C\ =\ 1 is
never used.
.PP
When an MLP receives the multilink frame with C\ =\ 1, the MLP stops its
Timer\ MT3. The transmission of the multilink frame with C\ =\ 1 to a remote
SLP and the reception of a multilink frame with C\ =\ 1 from the remote
MLP completes the multilink resetting procedure for an MLP. The first multilink
frame
transferred with R\ =\ C\ =\ 0 shall have a multilink sequence number MN(S)
value of zero. After an MLP transfers a multilink frame with C\ =\ 1 to
an SLP, the MLP may receive one or more multilink frames with R\ =\ C\
=\ 0. After an MLP receives a multilink frame with C\ =\ 1, the MLP may
transfer one or more multilink frames with R\ =\ C\ =\ 0 to its SLPs.
.bp
.PP
When an MLP additionally receives one or more multilink frames with
R\ =\ 1 between receiving a multilink frame with R\ =\ 1 and transferring a
multilink frame with C\ =\ 1, the MLP shall discard the extra multilink frames
with R\ =\ 1. When an MLP receives a multilink frame with C\ =\ 1, which
is not a reply to a multilink frame with R\ =\ 1, the MLP shall discard
the multilink
frame with C\ =\ 1.
.PP
After an MLP transfers a multilink frame with C\ =\ 1 on one of its
SLPs, the MLP may receive a multilink frame with R\ =\ 1 from the other
MLP. The MLP shall regard the multilink frame with R\ =\ 1 as a new reset
request and
shall start the multilink resetting procedure from the beginning. When
an MLP which has not received a multilink frame with R\ =\ 1, transfers
a multilink
frame with R\ =\ 1, and therefore receives a multilink frame with C\ =\
1, the MLP shall restart the resetting procedure from the beginning.
.PP
When Timer MT3 runs out, the MLP restarts the multilink resetting
procedure from the beginning. The value of Timer MT3 shall be large enough
to include the transmission, retransmission and propagation delays in the
SLPs,
and the operation time of the MLP that receives a multilink frame with R\ =\ 1
and responds with a multilink frame with C\ =\ 1.
.RT
.sp 2P
.LP
2.5.4.3
    \fITransmitting\fR
\fImultilink frames\fR
.sp 1P
.RT
.sp 1P
.LP
2.5.4.3.1
    \fIGeneral\fR
.sp 9p
.RT
.PP
The transmitting DCE or DTE MLP shall be responsible for
controlling the flow of packets from the Packet Layer into multilink frames
and then to the SLPs for transmission to the receiving DTE or DCE\ MLP,
respectively.
.PP
The functions of the transmitting DCE or DTE MLP shall be
to:
.RT
.LP
    a)
    accept packets from the Packet Layer;
.LP
    b)
    allocate multilink control fields, containing the
appropriate sequence number MN(S), to the packets;
.LP
    c)
    assure that MN(S) is not assigned outside the MLP transmit   window (MW);
.LP
    d)
    pass the resultant multilink frames to the SLPs for
transmission;
.LP
    e)
    accept indications of successful transmission
acknowledgements from the SLPs;
.LP
    f)
    monitor and recover from transmission failures or
difficulties that occur at the SLP sublayer; and
.LP
    g)
    accept flow control indications from the SLPs and take
appropriate actions.
.sp 1P
.LP
2.5.4.3.2
    \fITransmission of multilink frames\fR
.sp 9p
.RT
.PP
When the transmitting DCE MLP accepts a packet from the Packet
Layer, it shall place the packet in a multilink frame, set the MN(S) equal
to MV(S), assure that MN(S) is not assigned outside the transmit window
(MW), set V, S, R and C to\ 0, and then increment MV(S) by\ 1.
.PP
In the following, incrementing send and receive state variables is in reference
to a continuously repeated sequence series, i.e.\ 4095 is 1 higher
than\ 4094, and 0 is 1 higher than\ 4095 for modulo 4096\ series.
.PP
If the MN(S) is less than MV(T)\ +\ MW, and the DTE has not indicated a
busy condition on all available DCE SLPs, the transmitting DCE MLP may
then
assign the new multilink frame to an available DCE SLP. The transmitting DCE
MLP shall always assign the lowest MN(S) unassigned multilink frame first.
Also, the transmitting DCE MLP may assign a multilink frame to more than one
DCE SLP. When the DCE SLP successfully completes the transmission of (a)
multilink frame(s) by receiving an acknowledgement from the DTE SLP, it
shall indicate this to the transmitting DCE MLP. The transmitting DCE MLP
may then
discard the acknowledged multilink frame(s). As the transmitting DCE receives
new indications of acknowledgements from the DCE SLPs, MV(T) shall be advanced
to denote the lowest numbered multilink frame not yet acknowledged.
.PP
Whenever a DCE SLP indicates that it has attempted to transmit a
multilink frame N2 times, the DCE MLP will then assign the multilink frame
to the same or one or more other DCE SLPs unless the MN(S) has been acknowledged
on some previous DCE SLP. The DCE MLP shall always assign the lowest MN(S)
multilink frame first.
.bp
.PP
\fINote\fR \ \(em\ If a DCE MLP implementation is such that a multilink
frame is assigned to more than one DCE SLP (e.g.\ to increase the probability
of
successful delivery) there is a possibility that one of these multilink
frames (i.e.\ a duplicate) may be delivered to the remote DTE MLP after
an earlier one has been acknowledged [the earlier multilink frame would
have resulted in the receiving DTE MLP having incremented its MV(R) and
the transmitting DCE MLP
having incremented its MV(T)]. To ensure that an old duplicate multilink
frame is not mistaken for a new frame by the receiving DTE MLP, it is required
that the transmitting DCE MLP shall never assign to a DCE SLP a new multilink
frame with MN(S) equal to MN(S)`\ \(em\ MW\ \(em\ MX, where MN(S)` is associated
with a
duplicate multilink frame that was earlier assigned to other DCE SLPs,
until all DCE SLPs have either successfully transmitted the multilink frame
MN(S)` or have attempted the transmission the maximum number of times.
Alternatively, the incrementing of MV(T) may be withheld until all DCE SLPs
that were assigned the multilink frame MN(S)` have either successfully
transferred the multilink frame MN(S)` or have attempted the transmission
the maximum number of times. These and other alternatives are for further
study.
.PP
Flow control is achieved by the window size parameter MW, and through busy
conditions being indicated by the DTE SLPs.
.PP
The DCE MLP will not assign a multilink frame with an MN(S) greater
than MV(T) + MW\ \(em\ 1. At the point where the next DCE multilink frame to be
assigned has an MN(S) = MV(T) + MW, the DCE MLP shall hold this and
subsequent multilink frames until an indication of an acknowledgement that
advances MV(T) is received from the DCE SLPs.
.PP
The DTE MLP may exercise flow control of the DCE MLP by indicating a busy
condition over one or more DTE SLPs. The number of SLPs made busy will
determine the degree of DCE MLP flow control realized. When the DCE MLP
receives an indication of a DTE SLP busy condition from one or more of
its DCE SLPs, the DCE MLP may reassign any unacknowledged multilink frames
that were
assigned to those DCE SLPs. The DCE MLP will assign the multilink frames
containing the lowest MN(S) to an available DCE SLP as specified
above.
.PP
\fINote\ 1\fR \ \(em\ The action to be taken on the receipt of an RNR frame by
the DCE SLP whose unac
knowledged\ multilink frames have been reassigned is
for further study.
.PP
In the event of a circuit failure, a DCE SLP reset, or a DCE SLP or
DTE SLP disconnection, all DCE MLP multilink frames that were unacknowledged
on the affected DCE SLPs shall be reassigned to an operational DCE SLP(s)
which
is(are) not in the busy condition.
.PP
\fINote\ 2\fR \ \(em\ The means of detecting transmitting DCE MLP malfunctions
(e.g.\ sending more than MW multilink frames) and the actions to be taken are
for further study.
.RT
.sp 1P
.LP
2.5.4.4
    \fIReceiving multilink frames\fR
.sp 9p
.RT
.PP
Any multilink frame less than two octets in length shall be
discarded by the receiving DCE MLP.
.PP
\fINote\fR \ \(em\ The procedures to be followed by the receiving DCE MLP
when V and/or S is equal to 1 are for further study. The procedures to
be followed by the receiving DCE MLP when R or C is equal to 1 are described
in \(sc\ 2.5.4.2
above.
.PP
When the DCE MLP receives multilink frames from one of the DCE SLPs, the
DCE MLP will compare the multilink sequence number MN(S) of the received
multilink frame to its multilink receive state variable MV(R), and act
on the multilink frame as follows:
.RT
.LP
    a)
    If the received MN(S) is equal to the current value of
MV(R), i.e.\ is the next expected in\(hysequence multilink frame,
the DCE MLP delivers the packet to the Packet Layer.
.LP
    b)
    If the MN(S) is greater than the current value of MV(R) but
less than MV(R) + MW + MX, the DCE MLP keeps the received
multilink frame until condition a) is met, or discards it if it
is a duplicate.
.LP
    c)
    If the MN(S) is other than in a) and b) above, the multilink
frame is discarded.
.PP
\fINote\fR \ \(em\ In case c) above, the recovery from desynchronization
greater than MX between the local and the remote MLP, i.e.,\ the value
of MN(S) reassigned to new multilink frames at the remote MLP is higher
than
MV(R)\ +\ MW\ +\ MX at the local MLP, is for further study.
.bp
.PP
On receipt of each multilink frame, MV(R) is incremented by the
DCE\ MLP in the following way:
.RT
.LP
    i)
    If MN(S) is equal to the current value of MV(R), the MV(R)
is incremented by the number of consecutive in\(hysequence
multilink frames that have been received. If additional
multilink frames are awaiting delivery pending receipt of a
multilink frame with MN(S) equal to the updated MV(R), then
Timer MT1 (see \(sc\ 2.5.5.1 below) is restarted; otherwise Timer
MT1 is stopped.
.LP
    ii)
    If MN(S) is greater than the current value of MV(R) but
less than MV(R) + MW, MV(R) remains unchanged. Timer\ MT1 is
started, if not already running.
.LP
    iii)
    If MN(S) is \(>=" MV(R) + MW but < MV(R) + MW + MX, MV(R) is
incremented to MN(S) \(em MW + 1 and then the Packet Layer may
be informed of the packet loss at the original value of MV(R).
As MV(R) is being incremented, if any multilink frame with
MN(S) =\ MV(R) has not yet been received, the Packet Layer may be
informed of that packet loss also; if the multilink frame with
MN(S)\ =\ MV(R) has been received, it is delivered to the Packet
Layer. After MV(R) reaches MN(S) \(em MW\ +\ 1, it will then be
incremented further (as in i) above) until the first
unacknowledged MN(S) is encountered. See Figure\ 3/X.25.
.LP
    iv)
    If the MN(S) is other than that in i), ii) and iii) above,
MV(R) remains unchanged.
.LP
.rs
.sp 23P
.ad r
\fBFigure 3/X.25, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
If Timer MT1 runs out, MV(R) is incremented to the MN(S) of the
next multilink frame awaiting delivery to the Packet Layer and then the
Packet Layer may be informed of the packet loss at the original MV(R).
The procedure follows\ a) and\ i) above as long as there are consecutive
in\(hysequence multilink frames which have been received.
.PP
When flow control of the DTE MLP is desired, one or more DCE
SLP(s) may be made to indicate a busy condition. The number of DCE SLPs made
busy determines the degree of flow control realized.
.bp
.PP
If the DCE MLP can exhaust its receive buffer capacity before
resequencing can be completed, Timer MT2 (see \(sc\ 2.5.5.2 below) may be
implemented. Whenever a busy condition is indicated by the DCE MLP on all
DCE SLPs, and multilink frames at the DCE MLP are awaiting resequencing,
Timer\ MT2 shall be started. When the busy condition is cleared on one
or more DCE SLPs by the DCE MLP, Timer MT2 shall be stopped.
.PP
If Timer MT2 runs out, the multilink frame with MN(S) = MV(R) is
blocked and shall be considered lost. MV(R) shall be incremented to the next
sequence number not yet received, and the packets contained in multilink
frames with intervening multilink sequence numbers are delivered to the
Packet Layer. Timer MT2 shall be restarted if the busy condition remains
in effect on all DCE SLPs and more multilink frames are awaiting resequencing.
.RT
.sp 1P
.LP
2.5.4.5
    \fITaking an SLP out of service\fR
.sp 9p
.RT
.PP
A DCE SLP may be taken out of service for maintenance, traffic, or performance
considerations.
.PP
A DCE SLP is taken out of service by disconnecting at the Physical
Layer or the Data Link Layer. Any outstanding DCE MLP multilink frames
will be reassigned to one or more other DCE SLPs, unless the MN(S) has
been previously acknowledged on some other DCE SLP. The usual procedure
for taking a DCE SLP
out of service at the Data Link Layer would be to flow control the DTE
SLP with an RNR frame, and then logically disconnect the DCE\ SLP
(see \(sc\ 2.4.4.3 above).
.PP
If the DCE SLP Timer T1 has run out N2 times and the DCE SLP data link
resetting procedure is unsuccessful, then the DCE SLP will enter the
disconnected phase, taking the DCE SLP out of service (see \(sc\(sc\ 2.4.5.8
and\ 2.4.7.2 above).
.PP
\fINote\fR \ \(em\ In the case where all SLPs are out of service, the recovery
mechanism is based on initiating the multilink resetting procedures. Other
recovery procedures are for further study.
.RT
.sp 2P
.LP
2.5.5
    \fIList of \fR \fImultilink system parameters\fR
.sp 1P
.RT
.sp 1P
.LP
2.5.5.1
    \fILost\(hyframe Timer MT1 (multilink)\fR
.sp 9p
.RT
.PP
Timer MT1 is used at a receiving DCE MLP to provide a means to
identify during low traffic periods that the multilink frame with MN(S)
equal to MV(R) is lost.
.RT
.sp 1P
.LP
2.5.5.2
    \fIGroup busy Timer MT2 (multilink)\fR
.sp 9p
.RT
.PP
Timer MT2 is provided at a receiving DCE MLP to identify a
\*Qblocked\*U multilink frame condition (e.g.\ a buffer exhaust situation) that
occurs before required resequencing can be accomplished. Timer MT2 is started
when all DCE SLPs are busy and there are multilink frames awaiting
resequencing. If Timer MT2 runs out before the \*Qblocked\*U multilink
frame MV(R) is received, the \*Qblocked\*U multilink frame(s) is(are) declared
lost. MV(R) is incremented to the value of the next in\(hysequence multilink
frame to be
received, and any packets in intervening multilink frames are delivered
to the Packet Layer.
.PP
\fINote\fR \ \(em\ Timer MT2 may be set to infinity; e.g.\ when the receiving
DCE always has sufficient storage capacity.
.RT
.sp 1P
.LP
2.5.5.3
    \fIMLP reset confirmation Timer MT3 (multilink)\fR
.sp 9p
.RT
.PP
Timer MT3 is used by the DCE MLP to provide a means of identifying that
the DTE MLP multilink frame with the C bit set to\ 1 that is expected
following the transmission of the DCE MLP multilink frame with R bit set
to\ 1, has not been received.
.RT
.sp 2P
.LP
2.6
    \fILAP elements of procedure\fR
.sp 1P
.RT
.PP
2.6.1
The LAP elements of procedure are defined in terms of actions that occur
on receipt of frames at the DCE or DTE.
.bp
.sp 9p
.RT
.PP
The elements of procedure specified below contain the selection of commands
and responses relevant to the LAP data link and system configurations described
in \(sc\ 2.1\ above. Together, \(sc\(sc\ 2.2 and\ 2.6 form the general
requirements for the proper management of a LAP access data link.
.sp 2P
.LP
2.6.2
    \fILAP control field formats and parameters\fR
.sp 1P
.RT
.sp 1P
.LP
2.6.2.1
    \fIControl field formats\fR
.sp 9p
.RT
.PP
The control field contains a command or a response, and sequence
numbers where applicable.
.PP
Three types of control field formats (see Table\ 11/X.25) are used to perform
numbered information transfer (I\ format), numbered supervisory
functions (S\ format) and unnumbered control functions (U\ format).
.RT
.LP
.sp 1
.ce
\fBH.T. [T9.25]\fR
.ce
TABLE\ 11/X.25
.ce
\fBLAP control field formats (modulo 8)\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
Control field bits    1    2    3    4    5    6    7    8
_
.T&
lw(36p) | cw(24p) | cw(72p) | cw(24p) | cw(72p) .
I format    0    N(S)    P    N(R)
_
.T&
lw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(72p) .
S format    1    0    S    S    P/F    N(R)
_
.T&
lw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
U format    1    1    M    M    P/F    M    M    T{
M
N(S)
Transmitter send sequence number (bit 2\|=\|low\(hyorder bit)
.parag
N(R)
Transmitter receive sequence number (bit 6\|=\|low\(hyorder bit)
.parag
S
Supervisory function bit
.parag
M
Modifier function bit
.parag
P/F
Poll bit when issued as a command, final bit when issued as a
response. (1\|=\|Poll/Final)
.parag
P
Poll bit (1\|=\|Poll)
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 11/X.25 [T9.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
2.6.2.1.1
    \fIInformation transfer format\ \(em\ I\fR
.sp 9p
.RT
.PP
The I format is used to perform an information transfer. The
functions of N(S), N(R) and P are independent, i.e.\ each I\ frame has
an N(S), an N(R) which may or may not acknowledge additional I\ frames
received by the
DCE or DTE, and a P\ bit that may be set to\ 0 or\ 1.
.RT
.sp 1P
.LP
2.6.2.1.2
    \fISupervisory format\ \(em\ S\fR
.sp 9p
.RT
.PP
The S format is used to perform data link supervisory control
functions such as acknowledge I frames, request retransmission of I frames,
and to request a temporary suspension of transmission of I\ frames. The
functions
of N(R) and P/F are independent, i.e.\ each supervisory frame has an N(R)
which may or may not acknowledge additional I\ frames received by the DCE
or DTE, and a P/F bit that may be set to 0 or\ 1.
.bp
.RT
.sp 1P
.LP
2.6.2.1.3
    \fIUnnumbered format\ \(em\ U\fR
.sp 9p
.RT
.PP
The U format is used to provide additional data link control
functions. This format contains no sequence numbers, but does include a
P/F bit that may be set to\ 0 or\ 1.
.RT
.sp 1P
.LP
2.6.2.2
    \fIControl field parameters\fR
.sp 9p
.RT
.PP
The various parameters associated with the control field formats
are described below.
.RT
.sp 1P
.LP
2.6.2.2.1
    \fIModulus\fR
.sp 9p
.RT
.PP
Each I frame is sequentially numbered and may have the value\ 0
through modulus minus 1 (where \*Qmodulus\*U is the modulus of the sequence
numbers). The modulus equals\ 8 and the sequence numbers cycle through the
entire range.
.RT
.sp 1P
.LP
2.6.2.2.2
    \fISend state variable V(S)\fR
.sp 9p
.RT
.PP
The send state variable V(S) denotes the sequence number of the
next in\(hysequence I\ frame to be transmitted. V(S) can take on the value\ 0
through modulus minus\ 1. The value of V(S) is incremented by\ 1 with each
successive I\ frame transmission, but cannot exceed N(R) of the last received\
I or supervisory frame by more than the maximum number of outstanding I\
frames
(k).  The value of k is defined in \(sc\ 2.7.7.6 below.
.RT
.sp 1P
.LP
2.6.2.2.3
    \fISend sequence number N(S)\fR
.sp 9p
.RT
.PP
Only I frames contain N(S), the send sequence number of transmitted I\
frames. At the time that an in\(hysequence I\ frame is designated for
transmission, the value of N(S) is set equal to the value of the send state
variable\ V(S).
.RT
.sp 1P
.LP
2.6.2.2.4
    \fIReceive state variable V(R)\fR
.sp 9p
.RT
.PP
The receive state variable V(R) denotes the sequence number of the next
in\(hysequence I\ frame expected to be received. V(R) can take on the values\
0 through modulus minus\ 1. The value of V(R) is incremented by\ 1 with
the receipt of an error free, in\(hysequence I\ frame whose send sequence
number N(S) equals
the receive state variable V(R).
.RT
.sp 1P
.LP
2.6.2.2.5
    \fIReceive sequence number N(R)\fR
.sp 9p
.RT
.PP
All I frames and supervisory frames contain N(R), the expected send sequence
number of the next received I\ frame. At the time that a frame of the above
types is designed for transmission, the value of N(R) is set equal to the
current value of the receive state variable V(R). N(R) indicates that the
DCE or DTE transmitting the N(R) has received correctly all I\ frames numbered
up to and including N(R)\ \(em\ 1.
.RT
.sp 1P
.LP
2.6.2.2.6
    \fIPoll/Final bit P/F\fR
.sp 9p
.RT
.PP
All frames contain P/F, the Poll/Final bit. In command frames the P/F bit
is referred to as the P\ bit. In response frames it is referred to as
the F\ bit.
.RT
.sp 1P
.LP
2.6.3
    \fIFunctions of the \fR \fIPoll/Final bit\fR
.sp 9p
.RT
.PP
The Poll bit set to 1 is used by the DCE or DTE to solicit (poll) a response
from the DTE or DCE, respectively. The Final bit set to\ 1 is used by the
DCE or DTE to indicate the response frame transmitted by the DTE or DCE,
respectively, as a result of the soliciting (poll) command.
.PP
The use of the P/F bit is described in \(sc\ 2.7.2 below.
.RT
.sp 1P
.LP
2.6.4
    \fICommands and responses\fR
.sp 9p
.RT
.PP
The commands and responses represented in Table\ 12/X.25 will be
supported by the DCE and the DTE.
.RT
.PP
For purposes of the LAP procedures, the supervisory function bit encoding
\*Q11\*U and those encodings of the modifier function bits in
Table\ 11/X.25 not identified in Table\ 12/X.25 are identified as \*Qundefined
or not implemented\*U command and response control fields.
.bp
.RT
.ce
\fBH.T. [T10.25]\fR
.ce
TABLE\ 12/X.25
.ce
\fBLAP commands and responses\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(126p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(12p) | cw(12p) | cw(12p) .
    1    2    3    4    5    6    7    8
.T&
cw(36p) | cw(48p) | cw(42p) | cw(102p) .
Format    Command    Response    Encoding
_
.T&
lw(36p) | lw(18p) | lw(30p) | lw(42p) | cw(12p) | cw(36p) | cw(18p) | cw(36p) .
Information transfer    I    (information)        0    N(S)    P    N(R)
_
.T&
lw(36p) | lw(18p) | lw(30p) | lw(18p) | lw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(36p) .
Supervisory    RR    (receive ready)    RR    (receive ready)    1    0    0    0    P/F    N(R)
.T&
lw(36p) | lw(18p) | lw(30p) | lw(18p) | lw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(36p) .
    RNR    (receive not ready)    RNR    (receive not ready)    1    0    1    0    P/F    N(R)
.T&
lw(36p) | lw(18p) | lw(30p) | lw(18p) | lw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(36p) .
    REJ    (reject)    REJ    (reject)    1    0    0    1    P/F    N(R)
_
.T&
lw(36p) | lw(18p) | lw(30p) | lw(42p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
1 1 1 1 P 0 0 0
.T&
lw(36p) | lw(18p) | lw(30p) | lw(42p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
DISC (disconnect)    1 1 0 0 P 0 1 0
_
.T&
lw(84p) | lw(18p) | lw(24p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
T{
CMDR
(command reject)
1
1
1
0
F
0
0
1
T}
_
.T&
lw(84p) | lw(18p) | lw(24p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
T{
UA
(unnumbered acknowledge
ment)
1
1
0
0
F
1
1
0
\fINote\fR
\ \(em\ RR, RNR and REJ supervisory commands are transmitted by the DCE.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 12/X.25 [T10.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
The commands and responses in Table\ 12/X.25 are defined as
follows:
.RT
.sp 1P
.LP
2.6.4.1
    \fIInformation (I)  command\fR
.sp 9p
.RT
.PP
The function of the information (I) command is to transfer across a data
link a sequentially numbered frame containing an information
field.
.RT
.sp 1P
.LP
2.6.4.2
    \fIReceive ready (RR) command and response\fR
.sp 9p
.RT
.PP
The receive ready (RR) supervisory frame is used by the DCE or DTE  to:
.RT
.LP
    1)
    indicate it is ready to receive an I frame; and
.LP
    2)
    acknowledge previously received I frames numbered up to and
including N(R)\ \(em\ 1.
.PP
An RR frame may be used to indicate the clearance of a busy
condition that was reported by the earlier transmission of an RNR frame
by that same station (DCE or DTE). The RR command with the P bit set to\
1 may be used by the DTE to ask for the status of the DCE.
.sp 1P
.LP
2.6.4.3
    \fIReject (REJ) command and response\fR
.sp 9p
.RT
.PP
The reject (REJ) supervisory frame is used by the DCE or DTE to
request transmission of I\ frames starting with the frame numbered N(R).
I\ frames numbered N(R)\ \(em\ 1 and below are acknowledged. Additional
I\ frames
pending initial transmission may be transmitted following the retransmitted
I\ frame(s).
.bp
.PP
For a given direction of information transfer, only one REJ exception condition
may be established at any time. The REJ exception condition is
cleared (reset) upon the receipt of an I\ frame with an N(S) equal to the
N(R) of the REJ\ frame.
.PP
An REJ frame may be used to indicate the clearance of a busy condition
that was reported by the earlier transmission of an RNR frame by that same
station (DCE or DTE). The REJ command with the P\ bit set to\ 1 may be used by
the DTE to ask for the status of the DCE.
.RT
.sp 1P
.LP
2.6.4.4
    \fIReceive not ready (RNR) command and response\fR
.sp 9p
.RT
.PP
The receive not ready (RNR) supervisory frame is used by the DCE or DTE
to indicate a busy condition, i.e.\ temporary inability to accept
additional incoming I\ frames. I\ frames numbered up to and including N(R)\
\(em\ 1
are acknowledged. I\ frame N(R) and any subsequent I\ frames received, if any,
are not acknowledged; the acceptance status of these I\ frames will be
indicated in subsequent exchanges.
.PP
The RNR command with the P bit set to 1 may be used by the DTE to ask for
the status of the DCE.
.RT
.sp 1P
.LP
2.6.4.5
    \fISet asynchronous response mode (SARM) command\fR
.sp 9p
.RT
.PP
The SARM unnumbered command is used to place the addressed DCE or DTE in
the asynchronous response mode (ARM) information transfer phase, where
all command/response control fields will be one octet in length.
.PP
No information field is permitted with the SARM command. A DCE or DTE confirms
acceptance of an SARM command by the transmission at the first
opportunity of a UA response. Upon acceptance of this command, the DCE
or DTE receive state variable V(R) is set to\ 0.
.PP
Previously transmitted I frames that are unacknowledged when this
command is actioned remain unacknowledged. It is the responsibility of
a higher layer (e.g.\ Packet Layer) to recover from the possible loss of
the contents
(packets) of such I\ frames.
.RT
.sp 1P
.LP
2.6.4.6
    \fIDisconnect (DISC) command\fR
.sp 9p
.RT
.PP
The DISC unnumbered command is used to terminate the mode
previously set. It is used to inform the DCE or DTE receiving the DISC
that the DTE or DCE sending the DISC command is suspending operation. No
information
field is permitted with the DISC command. Prior to actioning the DISC command,
the DCE or DTE receiving the DISC command confirms the acceptance of the
DISC command by the transmission of a UA response. The DTE or DCE sending
the DISC command enters the disconnected phase when it receives the acknowledging
UA
response.
.PP
Previously transmitted I frames that are unacknowledged when this
command is actioned remain unacknowledged. It is the responsibility of
a higher layer (e.g.\ Packet Layer) to recover from the possible loss of
the contents
(packets) of such I\ frames.
.RT
.sp 1P
.LP
2.6.4.7
    \fIUnnumbered acknowledgement (UA) response\fR
.sp 9p
.RT
.PP
The UA unnumbered response is used by the DCE or DTE to acknowledge the
receipt and acceptance of the mode\(hysetting commands. Received mode\(hysetting
commands are not actioned until the UA response is transmitted. The UA
response is transmitted as directed by the received U\ format command.
No information
field is permitted with the UA response.
.RT
.sp 1P
.LP
2.6.4.8
    \fICommand reject (CMDR) response\fR
.sp 9p
.RT
.PP
The CMDR unnumbered response is used by the DCE or DTE to report an error
condition not recoverable by retransmission of the identical frame,
i.e.\ at least one of the following conditions, which results from the
receipt of a valid command frame:
.RT
.LP
    1)
    the receipt of a command control field that is undefined or
not implemented;
.LP
    2)
    the receipt of an I frame with an information field which
exceeds the maximum established length;
.LP
    3)
    the receipt of an invalid N(R) (see \(sc\ 2.7.5.1), or
.LP
    4)
    the receipt of a frame with an information field which is
not permitted or the receipt of a supervisory or unnumbered
frame with incorrect length.
.bp
.PP
An undefined or not implemented control field is any of the
control field encodings that are not identified in Table\ 12/X.25.
.PP
An invalid N(R) is defined as one which points to an I frame which has
previously been transmitted and acknowledged or to an I\ frame which has
not
been transmitted and is not the next sequential I\ frame awaiting transmission.
.PP
An information field which immediately follows the control field, and consists
of 3\ octets, is returned with this response and provides the reason
for the CMDR response. This format is given in Table\ 13/X.25.
.RT
.LP
.sp 1
.ce
\fBH.T. [T11.25]\fR
.ce
TABLEAU\ 13/X.25
.ce
\fBLAP CMDR information field format\fR
.ce
Information field bits
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(42p) | cw(12p) | cw(30p) | cw(18p) | cw(30p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) .
T{
1\ \|2\ \|3\ \|4\ \|5\ \|6\ \|7\ \|8 \fR
T}    9    10\ \|11\ \|12    13    14\ 15\ 16    17    18    19    20    21    22    23    24
_
.T&
lw(42p) | cw(12p) | cw(30p) | cw(18p) | cw(30p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) .
T{
Rejected command control field
T}    0    V(S)    0    V(R)    W    X    Y    Z    0    0    0    T{
0
\(em
Rejected command control field is the control field of the received
command which caused the command reject.
.parag
\(em
V(S) is the current send state variable value at the DCE or DTE reporting the rejection condition (bit 10\|=\|low\(hyorder bit).
.parag
\(em
V(R) is the current receive state variable value at the DCE or DTE
reporting the rejection condition (bit 14\|=\|low\(hyorder bit).
.parag
\(em
W set to 1 indicates that the control field received and returned in bits 1 through 8 was undefined or not implemented.
.parag
\(em
X set to 1 indicates that the control field received and returned in bits 1 through 8 was considered invalid because the frame contained an information field which is not permitted with this frame or is a supervisory or unnumbered frame with an incorrect length. Bit W must be set to 1 conjunction with this
bit.
.parag
\(em
Y set to 1 indicates that the information field received exceeded the
maximum established capacity of the DCE or DTE reporting the rejection
condition.
.parag
\(em
Z set to 1 indicates the control field received and returned in bits 1
through 8 contained an invalid N(R).
.parag
\fINote\fR
\ \(em\ Bits 9, 13 and 21 to 24 shall be set to 0.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 13/X.25 [T11.25], p.
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
2.6.5
    \fIException condition reporting and recovery\fR
.sp 9p
.RT
.PP
The error recovery procedures which are available to effect
recovery following the detection/occurrence of an exception condition at the
Data Link Layer are described below. Exception conditions described are
those situations which may occur as the result of transmission errors,
DCE or DTE
malfunction, or operational situations.
.RT
.sp 1P
.LP
2.6.5.1
    \fIBusy condition\fR
.sp 9p
.RT
.PP
The busy condition results when the DCE or DTE is temporarily
unable to continue to receive I\ frames due to internal constraints,
e.g.\ receive buffering limitations. In this case an RNR frame is transmitted
from the busy DCE or DTE. I\ frames pending transmission may be transmitted
from the busy DCE or DTE prior to or following the RNR frame.
.PP
An indication that the busy condition has cleared is communicated by the
transmission of a UA (only in response to a SARM command), RR, REJ or SARM
frame.
.bp
.RT
.LP
.sp 1P
.LP
2.6.5.2
    \fIN(S) sequence error condition\fR
.sp 9p
.RT
.PP
The information field of all I frames received whose N(S) does not equal
the receive state variable V(R) will be discarded.
.PP
An N(S) sequence error exception condition occurs in the receiver when
an I\ frame received contains an N(S) which is not equal to the receive
state
variable V(R) at the receiver. The receiver does not acknowledge (increment
its receive state variable) the I\ frame causing the sequence error, or
any I\ frames which may follow, until an I\ frame with the correct N(S)
is received.
.PP
A DCE or DTE which receives one or more valid I frames having sequence
errors but otherwise errorless shall accept the control information contained
in the N(R) field and the P\ bit to perform data link control functions,
e.g.\ to receive acknowledgement of previously transmitted I\ frames and
to cause the DCE or DTE to respond (P\ bit set to\ 1). Therefore, the retransmitted
frame may
contain an N(R) and a P\ bit that are updated from, and therefore different
from, those contained in the originally transmitted I\ frame.
.PP
The methods specified in \(sc\(sc\ 2.6.5.2.1 and\ 2.6.5.2.2 shall be available
for initiating the retransmission of lost of errored I\ frames following
the
occurrence of an N(S) sequence error condition.
.RT
.sp 1P
.LP
2.6.5.2.1
    \fIREJ recovery\fR
.sp 9p
.RT
.PP
The REJ frame is used by a receiving DCE or DTE to initiate a
recovery (retransmission) following the detection of an N(S) sequence error.
.PP
With respect to each direction of transmission on the data link, only one
\*Qsent REJ\*U exception condition from a DCE or DTE, to a DTE or DCE,
is
established at a time. A \*Qsent REJ\*U exception condition is cleared when the
requested I\ frame is received.
.PP
A DCE or DTE receiving an REJ frame initiates sequential
(re)transmission of I\ frames starting with the I frame indicated by the N(R)
obtained in the REJ frame.
.RT
.sp 1P
.LP
2.6.5.2.2
    \fITime\(hyout recovery\fR
.sp 9p
.RT
.PP
If a DCE or DTE, due to a transmission error, does not receive (or receives
and discards) a single I\ frame or the last I\ frame(s) in a sequence of
I\ frames, it will not detect an N(S) sequence error condition and, therefore,
will not transmit an REJ frame. The DTE or DCE, which transmitted the
unacknowledged I\ frame(s) shall, following the completion of a system
specified time\(hyout period (see \(sc\(sc\ 2.7.4.8 and 2.7.7.1 below),
take appropriate recovery action to determine at which I\ frame retransmission
must begin.
.RT
.sp 1P
.LP
2.6.5.3
    \fIInvalid frame\fR \fIcondition\fR
.sp 9p
.RT
.PP
Any frame which is invalid will be discarded, and no action will be taken
as the result of that frame. An invalid frame is defined as one
which:
.RT
.LP
    a)
    is not properly bounded by two flags;
.LP
    b)
    contains fewer than 32 bits between flags;
.LP
    c)
    contains a Frame Check Sequence (FCS) error; or
.LP
    d)
    contains an address other than A or B.
.PP
For those networks that are octet\(hyaligned, a detection of
non\(hyoctet alignment may be made at the Data Link Layer by adding a frame
validity check that requires the number of bits between the opening flag and
the closing flag, excluding bits inserted for transparency, to be an integral
number of octets in length. Otherwise the frame is considered invalid.
.sp 1P
.LP
2.6.5.4
    \fICommand rejection\fR \fIcondition\fR
.sp 9p
.RT
.PP
A command rejection condition is established upon the receipt of an error\(hyfree
command frame with one of the conditions listed in \(sc\ 2.6.4.8
above.
.PP
At the DCE or DTE, this command rejection exception condition is
reported by a CMDR response for appropriate DTE or DCE action, respectively.
Once a DCE has established such an exception condition, no additional I\
frames are accepted until the condition is reset by the DTE, except for
examination
of the P bit. The CMDR response may be repeated at each opportunity, as
specified in \(sc\ 2.7.6.5, until recovery is effected by the DTE, or until
the DCE initiates its own recovery.
.bp
.RT
.sp 1P
.LP
2.6.5.5
    \fIExcessive idle channel state condition on the incoming channel\fR
.sp 9p
.RT
.PP
Upon detection of an idle channel state condition (see \(sc\ 2.2.12.2 above)
on the incoming channel, the DCE shall not take any action for a period
T3 (see \(sc\ 2.7.7.3\ below), while waiting for detection of a return
to the active channel state (i.e.\ detection of at least one flag sequence).
After the period T3, the DCE shall notify the Packet Layer of the excessive
idle channel state condition, but shall not take any action that would
preclude the DTE from
establishing the data link by normal data link set\(hyup procedures.
.PP
\fINote\fR \ \(em\ Other actions to be taken by the DCE at the Data Link
Layer upon expiration of period T3 is a subject for further study.
.RT
.sp 2P
.LP
2.7
    \fIDescription of the LAP procedure\fR
.sp 1P
.RT
.sp 1P
.LP
2.7.1
    \fILAP procedure for addressing\fR
.sp 9p
.RT
.PP
The address field identifies a frame as either a command or a
response. A command frame contains the address of the DCE or DTE to which
the command is being sent. A response frame contains the address of the
DCE or DTE sending the frame.
.PP
Frames containing commands transferred from the DCE to the DTE
will contain the address\ A.
.PP
Frames containing responses transferred from the DCE to the DTE will contain
the address\ B.
.PP
Frames containing commands transferred from the DTE to the DCE shall contain
the address\ B.
.PP
Frames containing responses transferred from the DTE to the DCE shall contain
the address\ A.
.PP
A and B addresses are coded as follows:
.RT
.LP
    Address
    1\ 2\ 3\ 4\ 5\ 6\ 7\ 8
.LP
    \ \ A
    1\ 1\ 0\ 0\ 0\ 0\ 0\ 0
.LP
    \ \ B
    1\ 0\ 0\ 0\ 0\ 0\ 0\ 0
.PP
\fINote\fR \ \(em\ The DCE will discard all frames received with an address
other than A or B; the DTE should do the same.
.sp 1P
.LP
2.7.2
    \fILAP procedure for the use of the P/F bit\fR
.sp 9p
.RT
.PP
The DCE or DTE receiving an SARM, DISC, supervisory command or
I\ frame with the P\ bit set to\ 1 will set the F\ bit to\ 1 in the next
response
frame it transmits.
.PP
The response frame returned by the DCE to an SARM or DISC command with
the P\ bit set to\ 1 will be a UA response with the F\ bit set to\ 1. The
response frame returned by the DCE to an I\ frame with the P\ bit set to\
1, received
during the information transfer phase, will be an RR, REJ, RNR or CMDR
response with the F\ bit set to\ 1. The response frame returned by the
DCE to a
supervisory command frame with the P\ bit set to\ 1, received during the
information transfer phase, will be an RR, RNR, REJ or CMDR response with
the F\ bit set to\ 1.
.PP
The P bit may be used by the DCE in conjunction with the timer
recovery condition (see \(sc\ 2.7.4.8 below).
.PP
\fINote\fR \ \(em\ Other use of the P bit by the DCE is a subject for further
study.
.RT
.sp 2P
.LP
2.7.3
    \fILAP procedures for data link set\(hyup and disconnection\fR
.sp 1P
.RT
.sp 1P
.LP
2.7.3.1
    \fIData link set\(hyup\fR
.sp 9p
.RT
.PP
The DCE will indicate that it is able to set up the data link by
transmitting contiguous flags (active channel state).
.PP
The DTE shall indicate a request for setting up the data link by
transmitting an SARM command to the DCE. Whenever receiving an SARM command,
the DCE will return a UA response to the DTE and set its receive state
variable V(R) to\ 0.
.bp
.PP
Should the DCE wish to indicate a request for setting up the data
link, or after transmission of a UA response to a first SARM command from
the DTE as a request for setting up the data link, the DCE will transmit
an SARM
command to the DTE and start Timer\ T1 in order to determine when too much
time has elapsed waiting for a reply (see \(sc\ 2.7.7.1 below). The DTE
will confirm the reception of the SARM command by transmitting a UA response.
When receiving the UA response the DCE will set its send state variable
to 0 and stop its
Timer\ T1.
.PP
If Timer T1 runs out before the UA response is received by the DCE,
the DCE will retransmit an SARM command and restart Timer T1. After
transmission of the SARM command N2 times by the DCE, appropriate recovery
action will be initiated. The value of N2 is defined in \(sc\ 2.7.7.4
below.
.RT
.sp 1P
.LP
2.7.3.2
    \fIInformation transfer phase\fR
.sp 9p
.RT
.PP
After having both transmitted the UA response to a received SARM
command and having received the UA response to a transmitted SARM command,
the DCE will accept and transmit I and supervisory frames according to
the
procedures described in \(sc\ 2.7.4 below.
.PP
When receiving an SARM command, the DCE will conform to the data link resetting
procedure described in \(sc\ 2.7.6 below. The DTE may also receive an
SARM command while in the information transfer phase.
.RT
.sp 1P
.LP
2.7.3.3
    \fIData link disconnection\fR
.sp 9p
.RT
.PP
During the information transfer phase the DTE shall indicate a
request for disconnecting the data link by transmitting a DISC command
to the DCE. Whenever receiving a DISC command, the DCE will return a UA
response to
the DTE.
.PP
During an information transfer phase, should the DCE wish to indicate a
request for disconnecting the data link, or when receiving from the DTE
a
first DISC command as a request for disconnecting the data link, the DCE
will transmit a DISC command to the DTE and start Timer T1 (see \(sc\ 2.7.7.1
below).
The DTE will confirm reception of the DISC command by returning a UA response.
After transmitting an SARM command, the DCE will not transmit a DISC command
until a UA response is received for this SARM command or until Timer T1 runs
out. When receiving a UA response to the DISC command, the DCE will stop its
Timer\ T1.
.PP
If Timer T1 runs out before a UA response is received by the DCE, the DCE
will retransmit a DISC command and restart Timer\ T1. After transmission
of the DISC command N2 times by the DCE, appropriate recovery action will
be
initiated. The value of N2 is defined in \(sc\ 2.7.7.4 below.
.RT
.sp 1P
.LP
2.7.4
    \fILAP procedures for information transfer\fR
.sp 9p
.RT
.PP
The procedures which apply to the transmission of I frames in each direction
during the information transfer phase are described below.
.PP
In the following, \*Qnumber 1 higher\*U is in reference to a continuously
repeated sequence series, i.e.\ 7 is 1 higher than 6, and\ 0 is\ 1 higher
than\ 7 for modulo 8\ series.
.RT
.sp 1P
.LP
2.7.4.1
    \fISending I frames\fR
.sp 9p
.RT
.PP
When the DCE has an I frame to transmit (i.e.\ an I frame not
already transmitted, or having to be retransmitted as described in \(sc\
2.7.4.5
below), it will transmit it with an N(S) equal to its current send state
variable V(S), and an N(R) equal to its current receive state variable
V(R). At the end of the transmission of the I\ frame, the DCE will increment
its send
state variable V(S) by\ 1.
.PP
If Timer T1 is not running at the time of transmission of an I frame, it
will be started.
.PP
If the send state variable V(S) is equal to the last value of N(R)
received plus \fIk\fR (where \fIk\fR is the maximum number of outstanding
I\ frames\ \(em\ see \(sc\ 2.7.7.6 below), the DCE will not transmit any
new I\ frames,
but may retransmit an I frame as described in \(sc\ 2.7.4.6 or \(sc\ 2.7.4.9
below.
.PP
When the DCE is in the busy condition, it may still transmit I frames provided
that the DTE is not busy. When the DCE is in the command rejection
condition, it may still transmit I\ frames.
.bp
.RT
.sp 1P
.LP
2.7.4.2
    \fIReceiving an I frame\fR \v'3p'
.sp 9p
.RT
.PP
2.7.4.2.1
When the DCE is not in a busy condition and receives a valid I\ frame whose
send sequence number N(S) is equal to the DCE receive state variable V(R),
the DCE will accept the information field of this frame,
increment by\ 1 its receive state variable V(R), and act as follows:
.LP
    i)
    If an I frame is available for transmission by the DCE, it
may act as in \(sc\ 2.7.4.1 above and acknowledge the received
I\ frame by setting N(R) in the control field of the next
transmitted I\ frame to the value of the DCE receive state
variable V(R). Alternatively the DCE may acknowledge the
received I\ frame by transmitting an RR response with
the N(R) equal to the value of the DCE receive state
variable V(R).
.LP
    ii)
    If no I frame is available for transmission by the DCE, it
will transmit an RR response with\ N(R) equal to the value of the
DCE receive state variable\ V(R).
.PP
2.7.4.2.2
When the DCE is in a busy condition, it may ignore the
information field contained in any received I\ frame.
.sp 1P
.LP
2.7.4.3
    \fIReception of invalid frames\fR
.sp 9p
.RT
.PP
When the DCE receives an invalid frame (see \(sc\ 2.6.5.3), this frame
will be discarded.
.RT
.sp 1P
.LP
2.7.4.4
    \fIReception of out\(hyof\(hysequence I frames\fR
.sp 9p
.RT
.PP
When the DCE receives a valid I frame whose FCS is correct, but
whose send sequence number N(S) is incorrect, i.e.\ not equal to the current
DCE receive state variable V(R), it will discard the information field
of the I\ frame and transmit an REJ response with the N(R) set to one higher
than the N(S) of the last correctly received I\ frame. The DCE will then
discard the
information field of all I\ frames received until the expected I\ frame is
correctly received. When receiving the expected I\ frame, the DCE will then
acknowledge the I\ frame as described in \(sc\ 2.7.4.2 above. The DCE will
use the N(R) and P bit information in the discarded I\ frames as described
in \(sc\ 2.6.5.2 above.
.RT
.sp 1P
.LP
2.7.4.5
    \fIReceiving acknowledgement\fR
.sp 9p
.RT
.PP
When correctly receiving an I frame or a supervisory frame (RR, RNR or
REJ), even in the busy condition, the DCE will consider the N(R) contained
in this frame as an acknowledgement for all I\ frames it has transmitted
with an N(S) up to and including the received N(R)\ \(em\ 1. The DCE will
stop Timer T1 when it correctly receives an I\ frame or a supervisory frame
with the N(R) higher
than the last received N(R) (actually acknowledging some I\ frames) or an REJ
frame with an N(R) equal to the last received N(R).
.PP
If Timer T1 has been stopped and if there are outstanding I frames
still unacknowledged, the DCE will restart Timer T1. If Timer T1 then runs
out, the DCE will follow the recovery procedure (in \(sc\(sc\ 2.7.4.6 and\
2.7.4.9 below)
with respect to the unacknowledged I\ frames.
.RT
.sp 1P
.LP
2.7.4.6
    \fIReceiving an REJ frame\fR
.sp 9p
.RT
.PP
When receiving an REJ frame, the DCE will set its send state
variable V(S) to the value of the N(R) received in the REJ control field. It
will transmit the corresponding I\ frame as soon as it is available or
retransmit it in accordance with the procedures described in \(sc\ 2.7.4.1
above. (Re)transmission will conform to the following:
.RT
.LP
    i)
    If the DCE is transmitting a supervisory or unnumbered
command or response when it receives the REJ frame, it will
complete that transmission before commencing transmission of the
requested I\ frame.
.LP
    ii)
    If the DCE is transmitting an I\ frame when the REJ frame is
received, it may abort the I\ frame and commence transmission
of the requested I\ frame immediately after abortion.
.LP
    iii)
    If the DCE is not transmitting any frame when the REJ
frame is received, it will commence transmission of the
requested I\ frame immediately.
.bp
.PP
In all cases, if other unacknowledged I frames have already been transmitted
following the one indicated in the REJ frame, then those I\ frames will
be retransmitted by the DCE following the retransmission of the requested
I\ frame. Other I\ frames not yet transmitted may be transmitted following
the
retransmitted I\ frames.
.PP
If the REJ frame was received from the DTE as a command with the P bit
set to\ 1, the DCE will transmit an RR or RNR response with the F\ bit
set to\ 1 before transmitting or retransmitting the corresponding I\ frame.
.RT
.sp 1P
.LP
2.7.4.7
    \fIReceiving an RNR frame\fR
.sp 9p
.RT
.PP
After receiving an RNR frame, the DCE may transmit or retransmit
the I\ frame with the send sequence number equal to the N(R) indicated in the
RNR frame. If Timer T1 runs out after the reception of the RNR frame, the
DCE will follow the procedure described in \(sc\ 2.7.4.9 below. In any
case, the DCE
will not transmit any other I\ frames before receiving an RR or REJ frame, or
before the completion of a data link resetting procedure.
.RT
.sp 1P
.LP
2.7.4.8
    \fIDCE busy condition\fR
.sp 9p
.RT
.PP
When the DCE enters a busy condition, it will transmit an RNR
response at the earliest opportunity. While in the busy condition, the
DCE will accept and process supervisory frames, will accept and process
the contents of the N(R) fields of I\ frames, and will return an RNR response
with the F\ bit set to\ 1 if it receives a supervisory command or\ I command
frame with the P\ bit set to\ 1. To clear the busy condition, the DCE will
transmit either an REJ response or an RR response, with N(R) set to the
current receive state variable V(R),
depending on whether or not it discarded information fields of correctly
received I\ frames.
.PP
\fINote\fR \ \(em\ The DTE when encountering a DCE busy condition, may send
supervisory command frames with the P bit set to\ 1. In the event that
the DTE has not implemented supervisory commands, it may follow the procedures
of the DCE (see \(sc\ 2.7.4.7).
.RT
.sp 1P
.LP
2.7.4.9
    \fIWaiting acknowledgement\fR
.sp 9p
.RT
.PP
The DCE maintains an internal transmission attempt variable which is set
to\ 0 when the DCE sends a UA response, when the DCE receives a UA
response or an RNR command or response, or when the DCE correctly receives
an I\ frame or supervisory frame with the N(R) higher than the last received
N(R) (actually acknowledging some outstanding I\ frames).
.PP
If Timer T1 runs out waiting for the acknowledgement from the DTE for an
I\ frame transmitted, the DCE will enter the timer recovery condition,
add
one to its transmission attempt variable and set an internal variable \fIx\fR
to
the current value of its send state variable\ V(S).
.PP
The DCE will restart Timer T1, set its send state variable V(S) to the
last N(R) received from the DTE, and retransmit the corresponding I\ frame
with the P\ bit set to\ 1.
.PP
The timer recovery condition is cleared when the DCE receives a valid supervisory
frame from the DTE, with the F\ bit set to\ 1.
.PP
If, while in the timer recovery condition, the DCE correctly receives a
supervisory frame with the F\ bit set to\ 1 and with an N(R) within the
range from its current send state variable V(S) to\ \fIx\fR included, it
will clear the
timer recovery condition (including stopping Timer\ T1) and set its send
state variable V(S) to the received N(R), and may then resume with I\ frame
transmission or retransmission, as appropriate.
.PP
If, while in the timer recovery condition, the DCE correctly receives an\
I or supervisory frame with the P/F bit set to\ 0 and with N(R) within
the
range from its current send state variable V(S) to \fIx\fR included, it
will not
clear the timer recovery condition. The value of the received N(R) may
be used to update the send state variable V(S). However, the DCE may decide
to keep the last transmitted I frame in store (even if it is acknowledged)
in order to be able to retransmit it with the P\ bit set to\ 1 when Timer
T1 runs out at a later time.
.PP
If Timer T1 runs out in the timer recovery condition, the DCE will add
one to its transmission attempt variable, restart Timer T1, and retransmit
the I\ frame sent with the P\ bit set to\ 1.
.bp
.PP
If the transmission attempt variable is equal to N2, the DCE will
initiate a data link resetting procedure for the direction of transmission
from the DCE as described in \(sc\ 2.7.6.3 below. N2 is a system parameter
(see
\(sc\ 2.7.7.4 below).
.PP
\fINote\fR \ \(em\ Although the DCE may implement the internal variable
\fIx\fR ,
other mechanisms do exist that achieve the identical function. Therefore,
the internal variable \fIx\fR is not necessarily implemented in the DTE.
.RT
.sp 2P
.LP
2.7.5
    \fILAP command rejection conditions\fR
.sp 1P
.RT
.sp 1P
.LP
2.7.5.1
    \fIRejection conditions causing a data link resetting of the\fR
\fItransmission of information from the DCE\fR
.sp 9p
.RT
.PP
The DCE will initiate a data link resetting procedure as described in \(sc\
2.7.6.3 below when receiving a frame which is not invalid (see \(sc\ 2.6.5.3)
with the address\ A (coded\ 11000000) and with one of the following
conditions:
.RT
.LP
    \(em
    the frame type is unknown as one of the responses supported;
.LP
    \(em
    the information field is invalid;
.LP
    \(em
    the N(R) contained in the control field is invalid; or
.LP
    \(em
    the response contains an F bit set to 1 except during a timer
recovery condition as described in \(sc\ 2.7.4.9
above.
.PP
The DCE will also initiate a data link resetting procedure as
described in \(sc\ 2.7.6.3 below when receiving an I or supervisory frame
which is not invalid (see \(sc\ 2.6.5.3) with the address\ B (coded\ 10000000)
and with an
invalid N(R) contained in the control field.
.PP
A valid N(R) must be within the range from the lowest send sequence
number N(S) of the still unacknowledged frame(s) to the current DCE send
state variable V(S) included, even if the DCE is in a rejection condition,
but
not if the DCE is in the timer recovery condition (see \(sc\ 2.7.4.9
above).
.RT
.sp 1P
.LP
2.7.5.2
    \fIRejection conditions causing the DCE to request a data link\fR
\fIresetting of the transmission of information from the DTE\fR
.sp 9p
.RT
.PP
The DCE will enter the command rejection condition as described in \(sc\
2.7.6.5 below when receiving a frame which is not invalid (see \(sc\ 2.6.5.3)
with the address\ B (coded\ 10000000) and with one of the following
conditions:
.RT
.LP
    \(em
    the frame type is unknown as one of the commands supported;   or
.LP
    \(em
    the information field is invalid.
.sp 1P
.LP
2.7.6
    \fILAP procedures for data link resetting\fR \v'3p'
.sp 9p
.RT
.PP
2.7.6.1
The data link resetting procedure is used to reinitialize one
direction of information transfer according to the procedure described
below. The data link resetting procedures only apply during the information
transfer phase.
.PP
2.7.6.2
The DTE will indicate a data link resetting of the information
transmission from the DTE by transmitting an SARM command to the DCE. When
receiving an SARM command correctly, the DCE will return, at the earliest
opportunity, a UA response to the DTE and set its receive state variables
V(R) to zero. This also indicates a clearance of a DCE and/or DTE busy
condition, if present.
.PP
2.7.6.3
The DCE will indicate a data link resetting of the information
transmitted from the DCE by transmitting an SARM command to the DTE and will
start Timer\ T1 (see \(sc\ 2.7.7.1 below). The DTE will confirm reception
of the
SARM command by returning a UA response to the DCE. When receiving this UA
response to the SARM command, the DCE will set its send state variable V(S)
to\ 0 and stop its Timer T1. If Timer T1 runs out before the UA response is
received by the DCE, the DCE will retransmit an SARM command and restart
Timer\ T1. After transmission of the SARM command\ N2 times, appropriate
higher layer recovery action will be initiated. The value of N2 is defined
in
\(sc\ 2.7.7.4 below.
.PP
The DCE will not act on any received response frame which arrives before
the UA response command. The value of N(R) contained in any correctly
received\ I command frame arriving before the UA response will also be
ignored.
.PP
2.7.6.4
When receiving a CMDR response from the DTE, the DCE will
initiate a data link resetting of the information transmission from the
DCE as described in \(sc\ 2.7.6.3 above.
.bp
.PP
2.7.6.5
If the DCE transmits a CMDR response, it enters the command
rejection condition. The command rejection condition is cleared when the DCE
receives an SARM or DISC command. Any other command received while in the
command rejection condition will cause the DCE to retransmit the CMDR
response. The coding of the CMDR response will be as described in \(sc\ 2.6.4.8
above.
.sp 1P
.LP
2.7.7
    \fIList of\fR
\fILAP system parameters\fR
.sp 9p
.RT
.PP
The DCE and DTE system parameters are as follows:
.RT
.sp 1P
.LP
2.7.7.1
    \fITimer T1\fR
.sp 9p
.RT
.PP
The value of the DTE Timer\ T1 system parameter may be different
than the value of the DCE Timer\ T1 system parameter. These values shall
be made known to both the DTE and the DCE, and agreed to for a period of
time by both the DTE and the DCE.
.PP
The period of Timer\ T1, at the end of which retransmission of a frame
may be initiated (see \(sc\(sc\ 2.7.4 and\ 2.7.5 above for the DCE), shall
take into
account whether T1 is started at the beginning or the end of the transmission
of a frame.
.PP
The proper operation of the procedure requires that the transmitter's (DCE
or DTE) Timer\ T1 be greater than the maximum time between transmission
of a frame (SARM, DISC, I, or supervisory command, or CMDR response) and
the
reception of the corresponding frame returned as an answer to that frame
(UA or acknowl
edging\ frame). Therefore, the receiver (DCE or DTE) should not delay the
response or acknowledging frame returned to one of the above frames by
more than a value\ T2, where T2 is a system parameter (see \(sc\ 2.7.7.2).
.PP
The DCE will not delay the response or acknowledging frame returned to
one of the above DTE frames by more than a period\ T2.
.RT
.sp 1P
.LP
2.7.7.2
    \fIParameter T2\fR
.sp 9p
.RT
.PP
The value of the DTE parameter T2 may be different than the value of the
DCE parameter\ T2. These values shall be made known to both the DTE
and the DCE, and agreed to for a period of time by both the DTE and the
DCE.
.PP
The period of parameter T2 shall indicate the amount of time available
at the DCE or DTE before the acknowledging frame must be initiated in order
to ensure its receipt by the DTE or DCE, respectively, prior to Timer\
T1 running out at the DTE or DCE (parameter T2\ <\ Timer T1).
.PP
\fINote\fR \ \(em\ The period of parameter T2 shall take into account the
following timing factors: the transmission time of the acknowledging frame,
the propagation time over the access data link, the state processing times
at the DCE and the DTE, and the time to complete the transmission of the
frames in the DCE or DTE transmit queue that are neither displaceable or
modifiable in an
orderly manner.
.PP
Given a value for Timer\ T1 for the DTE or DCE, the value of
parameter\ T2 at the DCE or DTE, respectively, must be no larger than T1
minus 2\ times the propagation time over the access data link, minus the
frame
processing time at the DCE, minus the frame processing time at the DTE, and
minus the transmission time of the acknowledging frame by the DCE or DTE,
respectively.
.RT
.sp 1P
.LP
2.7.7.3
    \fITimer T3\fR
.sp 9p
.RT
.PP
The DCE shall support a Timer T3 system parameter, the value of
which shall be made known to
the\ DTE.
.PP
The period of Timer T3, at the end of which an indication of an
observed excessively long idle link channel state condition is passed to the
Packet Layer, shall be sufficiently greater than the period of the DCE
Timer\ T1 (i.e.\ T3\ >\ T1) so that the expiration of T3 provides the desired
level of
assurance that the data link channel is in a non\(hyactive, non\(hyoperational
state, and is in need of data link set\(hyup before normal data link operation
can resume.
.RT
.sp 1P
.LP
2.7.7.4
    \fIMaximum number of attempts to complete a transmission N2\fR
.sp 9p
.RT
.PP
The value of the DTE N2 system parameter may be different than the value
of the DCE N2 system parameter. These values shall be made known to both
the DTE and the DCE, and agreed to for a period of time by both the DTE
and the DCE.
.PP
The value of N2 shall indicate the maximum number of attempts made by the
DCE or DTE to complete the successful transmission of a frame to the DTE
or DCE, respectively.
.bp
.RT
.sp 1P
.LP
2.7.7.5
    \fIMaximum number of bits in an I frame N1\fR
.sp 9p
.RT
.PP
The value of the DTE N1 system parameter may be different than the value
of the DCE\ N1 system parameter. These values shall be made known to both
the DTE and the DCE.
.PP
The values of N1 shall indicate the maximum number of bits in an
I\ frame (excluding flags and 0\ bits inserted for transparency) that the
DCE or DTE is willing to accept from the DTE or DCE, respectively.
.PP
In order to allow for universal operation, a DTE should support a
value of DTE\ N1 which is not less than 1080\ bits (135\ octets). DTEs
should be aware that the network may transmit longer packets (see \(sc\
5.2), that may result in a data link layer problem.
.PP
All networks shall offer to a DTE which requires it, a value of DCE\ N1
which is greater than or equal to 2072\ bits (259\ octets) plus the length
of the address, control and FCS fields at the DTE/DCE interface, and greater
than or equal to the maximum length of the data packets which may cross
the DTE/DCE
interface plus the length of the address, control and FCS fields at the
DTE/DCE interface.
.RT
.sp 1P
.LP
2.7.7.6
    \fIMaximum number of outstanding I frames k\fR
.sp 9p
.RT
.PP
The value of the DTE k\ system parameter shall be the same as the
value of the DCE k\ system parameter. This value shall be agreed to for a
period of time by both the DTE and the DCE.
.PP
The value of k shall indicate the maximum number of sequentially
numbered I\ frames that the DTE of DCE may have outstanding
(i.e.\ unacknowledged) at any given time. The value of\ k shall never exceed
seven. All networks (DCEs) shall support a value of seven. Other values of\ k
(less than seven) may also be supported by networks (DCEs).
.RT
.sp 2P
.LP
\fB3\fR     \fBDescription of the\fR
\fBpacket level DTE/DCE interface\fR
.sp 1P
.RT
.PP
This and subsequent sections of the Recommendation relate to the
transfer of packets at the DTE/DCE interface. The procedures apply to packets
which are successfully transferred across the DTE/DCE interface.
.PP
Each packet to be transferred across the DTE/DCE interface shall be
contained within the data link layer information field which will delimit
its length, and only one packet shall be contained in the information field.
.PP
\fINote\fR \ \(em\ Some networks require the data fields of packets to
contain an integral number of octets. The transmission by the DTE of data
fields not
containing an integral number of octets to the network may cause a loss
of data integrity. DTEs wishing universal operation on all networks should
transmit
all packets with data fields containing only an integral number of octets.
Full data integrity can only be assured by exchange of octet\(hyoriented
data fields in both directions of transmission.
.PP
This section covers a description of the packet layer interface for
virtual call and permanent virtual circuit services.
.PP
Procedures for the virtual circuit service (i.e.,\ virtual call and
permanent virtual circuit services) are specified in \(sc\ 4. Packet formats
are
specified in \(sc\ 5. Procedures and formats for optional user facilities are
specified in \(sc\(sc\ 6 and\ 7.
.RT
.sp 1P
.LP
3.1
    \fILogical channels\fR
.sp 9p
.RT
.PP
To enable simultaneous virtual calls and/or permanent virtual
circuits, logical channels are used. Each virtual call or permanent virtual
circuit is assigned a logical channel group number (less than or equal
to\ 15) and a logical channel number (less than or equal to\ 255). For
virtual calls, a logical channel group number and a logical channel number
are assigned during the call set\(hyup phase. The range of logical channels
used for virtual calls is agreed with the Administration at the time of
subscription to the service (see Annex\ A). For permanent virtual circuits,
logical channel group numbers and
logical channel numbers are assigned in agreement with the Administration at
the time of subscription to the service (see Annex\ A).
.bp
.RT
.sp 1P
.LP
3.2
    \fIBasic structure of packets\fR
.sp 9p
.RT
.PP
Every packet transferred across the DTE/DCE interface consists of at least
three octets. These three octets contain a general format identifier, a
logical channel identifier and a packet type identifier. Other packet fields
are appended as required (see \(sc\ 5).
.PP
Packet types and their use in association with various services are
given in Table\ 14/X.25.
.RT
.LP
.sp 4
.ce
\fBH.T. [T12.25]\fR
.ce
TABLE\ 14/X.25
.ce
\fBPacket types and their use in various services\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(174p) | cw(36p) .
Packet type    Service
_
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
From DCE to DTE    From DTE to DCE    VC      PVC
_
.T&
cw(174p) | lw(18p) | lw(18p) .
T{
\fICall set\(hyup and clearing\fR
(see Note 1)
T}
.T&
lw(90p) | lw(84p) | cw(18p) | lw(18p) .
Incoming call    Call request    X
.T&
lw(90p) | lw(84p) | cw(18p) | lw(18p) .
Call connected    Call accepted    X
.T&
lw(90p) | lw(84p) | cw(18p) | lw(18p) .
Clear indication    Clear request    X
.T&
lw(90p) | lw(84p) | cw(18p) | lw(18p) .
DCE clear confirmation    DTE clear confirmation    X
.T&
cw(174p) | lw(18p) | lw(18p) .
T{
\fIData and interrupt\fR
(see Note 2)
T}
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
DCE data    DTE data    X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
DCE interrupt    DTE interrupt    X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
DCE interrupt confirmation    DTE interrupt confirmation    X    X
.T&
cw(174p) | lw(18p) | lw(18p) .
T{
\fIFlow control and reset\fR
(see Note 3)
T}
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
DCE RR    DTE RR    X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
DCE RNR    DTE RNR    X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
    DTE REJ\|\ua\d\u)\d    X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
Reset indication    Reset request    X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
DCE reset confirmation    DTE reset confirmation    X    X
.T&
cw(174p) | lw(18p) | lw(18p) .
T{
\fIRestart\fR
(see Note 4)
T}
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
Restart indication    Restart request    X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
DCE restart confirmation    DTE restart confirmation    X    X
.T&
cw(174p) | lw(18p) | lw(18p) .
T{
\fIDiagnostic\fR
(see Note 5)
T}
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
Diagnostic\|\ua\d\u)\d        X    X
.T&
cw(174p) | lw(18p) | lw(18p) .
T{
\fIRegistration\fR
\|\ua\d\u)\d (see Note 6)
T}
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
Registration Confirmation        X    X
.T&
lw(90p) | lw(84p) | cw(18p) | cw(18p) .
    Registration Request    X    T{
X
\ua\d\u)\d\ Not necessarily available on all networks.
.parag
VC
Virtual call
PVC
Permanent virtual circuit
.parag
\fINote\ 1\fR
\ \(em\ See \(sc\(sc\ 4.1 and 6.16 for procedures, \(sc\ 5.2 for formats.
.parag
\fINote\ 2\fR
\ \(em\ See \(sc\ 4.3 for procedures and \(sc\ 5.3 for formats.
.parag
\fINote\ 3\fR
\ \(em\ See \(sc\(sc\ 4.4 and 6.4 for procedures, \(sc\(sc\ 5.4 and 5.7.1 for formats.
.parag
\fINote\ 4\fR
\ \(em\ See \(sc\ 3.3 for procedures and \(sc\ 5.5 for formats.
.parag
\fINote\ 5\fR
\ \(em\ See \(sc\ 3.4 for procedures and \(sc\ 5.6 for formats.
.parag
\fINote\ 6\fR
\ \(em\ See \(sc\ 6.1 for procedures and \(sc\ 5.7.2 for formats.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 14/X.25 [T12.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
3.3
    \fIProcedure for\fR
\fIrestart\fR
.sp 9p
.RT
.PP
The restart procedure is used to initialize or reinitialize the
packet layer DTE/DCE interface. The restart procedure simultaneously clears
all the virtual calls and resets all the permanent virtual circuits at
the
DTE/DCE interface (see \(sc\ 4.5).
.PP
Figure\ B\(hy1/X.25 gives the state diagram which defines the logical
relationships of events related to the restart procedure.
.PP
Table C\(hy2/X.25 specifies actions taken by the DCE on the receipt of
packets from the DTE for the restart procedure.
.RT
.sp 1P
.LP
3.3.1
    \fIRestart by the DTE\fR
.sp 9p
.RT
.PP
The DTE may at any time request a restart by transferring across
the DTE/DCE interface a \fIrestart request\fR packet. The interface for each
logical channel is then in the \fIDTE restart request\fR state\ (r2).
.PP
The DCE will confirm the restart by transferring a \fIDCE restart\fR
\fIconfirmation packet\fR \| and placing the logical channels used for
virtual calls in the \fIready\fR state (p1), and the logical channels used
for permanent virtual circuits in the \fIflow control ready\fR state (d1).
.PP
\fINote\fR \ \(em\ States p1 and d1 are specified in \(sc\ 4.
.PP
The \fIDCE restart confirmation\fR \|packet can only be interpreted
universally as having local significance. The time spent in the \fIDTE
restart\fR \fIrequest\fR state (r2) will not exceed time\(hylimit T20 (see
Annex\ D).
.RT
.sp 1P
.LP
3.3.2
    \fIRestart by the DCE\fR
.sp 9p
.RT
.PP
The DCE may indicate a restart by transferring across the DTE/DCE
interface a \fIrestart indication\fR \|packet. The interface for each logical
channel is then in the \fIDCE restart indication\fR state (r3). In this
state of
the DTE/DCE interface, the DCE will ignore all packets except for \fIrestart\fR
\fIrequest\fR and \fIDTE restart confirmation\fR .
.PP
The DTE will confirm the restart by transferring a \fIDTE restart\fR
\fIconfirmation\fR \|packet and placing the logical channels used for virtual
calls in the \fIready\fR state\ (p1), and the logical channels used for
permanent virtual circuits in the \fIflow control ready\fR state\ (d1).
.PP
The action taken by the DCE when the DTE does not confirm the restart within
time\(hyout T10 is given in Annex\ D.
.RT
.sp 1P
.LP
3.3.3
    \fIRestart collision\fR
.sp 9p
.RT
.PP
Restart collision occurs when a DTE and a DCE simultaneously
transfer a \fIrestart request\fR \|and a \fIrestart indication\fR packet.
Under these
circumstances, the DCE will consider that the restart is completed. The DCE
will not expect a \fIDTE restart confirmation\fR packet and will not transfer a
\fIDCE restart confirmation\fR packet. This places the logical channels
used for
virtual calls in the \fIready\fR state\ (p1), and the logical channels used for
permanent virtual circuits in the \fIflow control ready\fR state\ (d1).
.RT
.sp 1P
.LP
3.4
    \fIError handling\fR
.sp 9p
.RT
.PP
Table C\(hy1/X.25 specifies the reaction of the DCE when special error
conditions are encountered. Other error conditions are discussed in
\(sc\ 4.
.RT
.sp 1P
.LP
3.4.1
    \fIDiagnostic packet\fR
.sp 9p
.RT
.PP
The \fIdiagnostic\fR \|packet is used by some networks to indicate error
conditions under circumstances where the usual methods of indication
(i.e.\ \fIreset\fR , \fIclear\fR and \fIrestart\fR with cause and diagnostic)
are
inappropriate (see Tables\ C\(hy1/X.25 and D\(hy1/X.25). The \fIdiagnostic\fR
packet from the DCE supplies information on error situations which are
considered
unrecoverable at the packet layer of Recommendation\ X.25; the information
provided permits an analysis of the error and recovery by higher layers
at the DTE if desired or possible.
.PP
A \fIdiagnostic\fR \|packet is issued only once per particular instance
of an error condition. No confirmation is required to be issued by the
DTE on
receipt of a \fIdiagnostic\fR packet.
.bp
.RT
.sp 2P
.LP
\fB4\fR     \fBProcedures for virtual circuit services\fR
.sp 1P
.RT
.sp 1P
.LP
4.1
    \fIProcedures for\fR
\fIvirtual call service\fR
.sp 9p
.RT
.PP
Figures B\(hy1/X.25, B\(hy2/X.25 and B\(hy3/X.25 show the state diagrams
which define the events at the packet layer DTE/DCE interface for each
logical channel
used for virtual calls.
.PP
Annex C gives details of the action taken by the DCE on receipt of
packets in each state shown in Annex\ B.
.PP
The call set\(hyup and clearing procedures described in the following
points apply independently to each logical channel assigned to the
virtual call
service at the DTE/DCE interface.
.RT
.sp 1P
.LP
4.1.1
    \fIReady state\fR
.sp 9p
.RT
.PP
If there is no call in existence, a logical channel is in the
ready state\ (p1).
.RT
.LP
.sp 1P
.LP
4.1.2
    \fICall request packet\fR
.sp 9p
.RT
.PP
The calling DTE shall indicate a call request by transferring a
\fIcall request\fR \|packet across the DTE/DCE interface. The logical channel
selected by the DTE is then in the \fIDTE waiting\fR state\ (p2). The \fIcall
request\fR packet includes the called DTE address.
.PP
\fINote\ 1\fR \ \(em\ A DTE address may be a DTE network address or any
other DTE identification agreed for a period of time between the DTE and
the DCE.
.PP
\fINote\ 2\fR \ \(em\ The call request packet should use the logical channel
in the \fIready\fR \| state with the highest number in the range which has been
agreed with the Administration (see Annex\ A). Thus the risk of call collision
is minimized.
.RT
.sp 1P
.LP
4.1.3
    \fIIncoming call packet\fR
.sp 9p
.RT
.PP
The DCE will indicate that there is an incoming call by
transferring across the DTE/DCE interface an \fIincoming call\fR packet. This
places the logical channel in the \fIDCE waiting\fR state\ (p3).
.PP
The \fIincoming call\fR \|packet will use the logical channel in the \fIready\fR
\| state with the lowest number (see Annex\ A). The \fIincoming call\fR
packet includes the calling DTE address.
.PP
\fINote\fR \ \(em\ A DTE address may be a DTE network address or any other
DTE identification agreed for a period of time between the DTE and the
DCE.
.RT
.sp 1P
.LP
4.1.4
    \fICall accepted packet\fR
.sp 9p
.RT
.PP
The called DTE shall indicate its acceptance of the call by
transferring across the DTE/DCE interface a \fIcall accepted\fR packet
specifying the same logical channel as that of the \fIincoming call\fR
packet. This places the specified logical channel in the \fIdata transfer\fR
state\ (p4).
.PP
If the called DTE does not accept the call by a \fIcall accepted\fR \|packet
or does not reject it by a \fIclear request\fR packet as described in \(sc\
4.1.7
within time\(hyout T11 (see Annex\ D), the DCE will consider it as a procedure
error from the called DTE and will clear the virtual call according to the
procedure described in \(sc\ 4.1.8.
.RT
.sp 1P
.LP
4.1.5
    \fICall connected packet\fR
.sp 9p
.RT
.PP
The receipt of a \fIcall connected\fR \|packet by the calling DTE
specifying the same logical channel as that specified in the \fIcall request\fR
packet indicates that the call has been accepted by the called DTE by means
of a \fIcall accepted\fR packet. This places the specified logical channel
in the
\fIdata transfer\fR state\ (p4).
.PP
The time spent in the \fIDTE waiting\fR \|state (p2) will not exceed
time\(hylimit T21 (see Annex\ D).
.bp
.RT
.sp 1P
.LP
4.1.6
    \fICall collision\fR
.sp 9p
.RT
.PP
Call collision occurs when a DTE and DCE simultaneously transfer a \fIcall
request\fR \|packet and an \fIincoming call\fR packet specifying the same
logical channel. The DCE will proceed with the \fIcall request\fR and cancel
the
\fIincoming call\fR .
.RT
.sp 1P
.LP
4.1.7
    \fIClearing by the DTE\fR
.sp 9p
.RT
.PP
At any time, the DTE may indicate clearing by transferring across the DTE/DCE
interface a \fIclear request\fR packet (see \(sc\ 4.5). The logical channel
is then in the \fIDTE clear request\fR state (p6). When the DCE is prepared
to
free the logical channel, the DCE will transfer across the DTE/DCE interface
a \fIDCE clear confirmation\fR packet specifying the logical channel. The
logical
channel is then in the \fIready\fR state\ (p1).
.PP
The \fIDCE clear confirmation\fR \|packet can only be interpreted
universally as having local significance; however, within some Administrations'
networks, clear confirmation may have end\(hyto\(hyend significance. In
all cases,
the time spent in the \fIDTE clear request\fR state\ (p6) will not exceed
time\(hylimit\ T23 (see Annex\ D).
.PP
It is possible that subsequent to transferring a \fIclear request\fR
\|packet the DTE will receive other types of packets, depending upon the
state of the logical channel, before receiving a \fIDCE clear confirmation\fR
packet.
.PP
\fINote\fR \ \(em\ The calling DTE may abort a call by clearing it before
it has received a \fIcall connected\fR or \fIclear indication\fR packet.
.PP
The called DTE may refuse an incoming call by clearing it as described
in this point rather than transmitting a \fIcall accepted\fR packet as
described in \(sc\ 4.1.4.
.RT
.sp 1P
.LP
4.1.8
    \fIClearing by the DCE\fR
.sp 9p
.RT
.PP
The DCE will indicate clearing by transferring across the DTE/DCE interface
a \fIclear indication\fR \|packet (see \(sc\ 4.5). The logical channel
is then in the \fIDCE clear indication\fR state\ (p7). The DTE shall respond
by transferring across the DTE/DCE interface a \fIDTE clear confirmation
packet\fR . The logical
channel is then in the \fIready\fR state\ (p1).
.PP
The action taken by the DCE when the DTE does not confirm clearing
within time\(hyout T13 is given in Annex\ D.
.RT
.sp 1P
.LP
4.1.9
    \fIClear collision\fR
.sp 9p
.RT
.PP
Clear collision occurs when a DTE and DCE simultaneously transfer a \fIclear
request\fR \|packet and a \fIclear indication\fR packet specifying the
same
logical channel. Under these circumstances the DCE will consider that the
clearing is completed. The DCE will not expect a \fIDTE clear confirmation\fR
packet and will not transfer a \fIDCE clear confirmation\fR packet. This
places the logical channel in the \fIready\fR state\ (p1).
.RT
.sp 1P
.LP
4.1.10
    \fIUnsuccessful call\fR
.sp 9p
.RT
.PP
If a call cannot be established, the DCE will transfer a \fIclear\fR \fIindication\fR
\|packet specifying the logical channel indicated in the \fIcall\fR
\fIrequest\fR packet.
.RT
.sp 1P
.LP
4.1.11
    \fICall progress signals\fR
.sp 9p
.RT
.PP
The DCE will be capable of transferring to the DTE \fIclearing call\fR
\fIprogress\fR \|signals as specified in Recommendation\ X.96.
.PP
\fIClearing call progress\fR \|signals will be carried in \fIclear\fR
\fIindication\fR \|packets which will terminate the call to which the packet
refers. The method of coding \fIclear indication\fR packets containing
\fIcall progress\fR
signals is detailed in \(sc\ 5.2.3.
.RT
.sp 1P
.LP
4.1.12
    \fIData transfer state\fR
.sp 9p
.RT
.PP
The procedures for the control of packets between DTE and DCE while in
the \fIdata transfer\fR \|state are contained in \(sc\ 4.3.
.bp
.RT
.sp 1P
.LP
4.2
    \fIProcedures for\fR
\fIpermanent virtual circuit service\fR
.sp 9p
.RT
.PP
Figures B\(hy1/X.25 and B\(hy3/X.25 show the state diagrams which give
a definition of events at the packet layer DTE/DCE interface for logical
channels assigned for
permanent virtual circuits
.
.PP
Annex C gives details of the action taken by the DCE on receipt of
packets in each state shown in Annex\ B.
.PP
For permanent
virtual circuits
there is no call set\(hyup or
clearing. The procedures for the control of packets between DTE and DCE
while in the \fIdata transfer\fR state are contained in \(sc\ 4.3.
.PP
If a momentary failure occurs within the network, the DCE will reset the
permanent virtual circuit as described in \(sc\ 4.4.3, with the cause \*QNetwork
congestion\*U, and then will continue to handle data traffic.
.PP
If the network has a temporary inability to handle data traffic, the DCE
will reset the permanent virtual circuit with the cause \*QNetwork out
of
order\*U. When the network is again able to handle data traffic, the DCE
should reset the permanent virtual circuit with the cause \*QNetwork
operational\*U.
.RT
.sp 1P
.LP
4.3
    \fIProcedures for data and interrupt transfer\fR
.sp 9p
.RT
.PP
The data transfer and interrupt procedures described in this
section apply independently to each logical channel assigned for virtual
calls or permanent virtual circuits existing at the DTE/DCE interface.
.PP
Normal network operation dictates that user data in \fIdata\fR \|and
\fIinterrupt\fR \|packets are all passed transparently, unaltered through the
network in the case of packet DTE to packet DTE communications. The order of
bits in \fIdata\fR and \fIinterrupt\fR packets is preserved. Packet sequences
are
delivered as complete packet sequences. DTE diagnostic codes are treated as
described in \(sc\(sc\ 5.2.4, 5.4.3 and 5.5.1.
.RT
.sp 1P
.LP
4.3.1
    \fIStates for data transfer\fR
.sp 9p
.RT
.PP
A
virtual call logical channel
is in the \fIdata transfer\fR \|state\ (p4) after completion of call establishment
and prior to a clearing or a restart procedure. A
permanent virtual circuit logical channel
is
continually in the \fIdata transfer\fR state\ (p4) except during the restart
procedure. \fIData\fR , \fIinterrupt\fR , \fIflow control\fR and \fIreset\fR
packets may be
transmitted and received by a DTE in the \fIdata transfer\fR state of a logical
channel at the DTE/DCE interface. In this state, the flow control and reset
procedures described in \(sc\ 4.4 apply to data transmission on that logical
channel to and from the DTE.
.PP
When a virtual call is cleared, \fIdata\fR \|and \fIinterrupt\fR \|packets
may be discarded by the network (see \(sc\ 4.5). In addition, \fIdata\fR
, \fIinterrupt\fR ,
\fIflow control\fR and \fIreset\fR packets transmitted by a DTE will be
ignored by the DCE when the logical channel is in the \fIDCE clear indication\fR
state\ (p7).
Hence it is left to the DTE to define DTE to DTE protocols able to cope with
the various possible situations that may occur.
.RT
.sp 1P
.LP
4.3.2
    \fIUser data field length of data packets\fR
.sp 9p
.RT
.PP
The standard maximum user data field length is
128\ octets.
.PP
In addition, other maximum user data field lengths may be offered by Administrations
from the following list: 16, 32, 64, 256, 512, 1024, 2048
and\ 4096\ octets. An optional maximum user data field length may be selected
for a period of time as the default maximum user data field length common
to all
virtual calls at the DTE/DCE interface (see \(sc\ 6.9). A value other than the
default may be selected for a period of time for each permanent virtual
circuit (see \(sc\ 6.9). Negotiation of maximum user data field lengths
on a per call basis may be made with the \fIflow control parameter negotiation\fR
facility (see
\(sc\ 6.12).
.PP
The user data field of \fIdata\fR \|packets transmitted by a DTE or DCE
may contain any number of bits up to the agreed maximum.
.PP
\fINote\fR \ \(em\ Some networks require the user data field to contain an
integral number of octets (see the note in \(sc\ 3).
.bp
.PP
If the user data field in a \fIdata\fR \|packet exceeds the locally
permitted maximum user data field length, then the DCE will reset the virtual
call or permanent virtual circuit with the resetting cause \*QLocal procedure
error\*U.
.RT
.sp 1P
.LP
4.3.3
    \fIDelivery Confirmation bit\fR
.sp 9p
.RT
.PP
The setting of the Delivery Confirmation bit (
D\ bit
) is
used to indicate whether or not the DTE wishes to receive an end\(hyto\(hyend
acknowledgement of delivery, for data it is transmitting, by means of the
packet receive sequence number\ P(R) (see \(sc\ 4.4).
.PP
\fINote\fR \ \(em\ The use of the
D bit procedure
does not obviate the need for a higher layer protocol agreed between the
communicating DTEs which
may be used with or without the D\ bit procedure to recover from user or
network generated resets and clearings.
.PP
The calling DTE may, during call establishment, ascertain that the
D\ bit procedure can be used for the call by setting bit\ 7 in the General
Format Identifier of the \fIcall request\fR packet to\ 1 (see \(sc\ 5.1.1).
Every network or
part of the international network will pass this bit transparently. If the
remote DTE is able to handle the D\ bit procedure, it should not regard
this bit being set to\ 1 in the \fIincoming call\fR packet as invalid.
.PP
Similarly, the called DTE can set bit\ 7 in the General Format
Identifier of the \fIcall accepted\fR \|packet to\ 1. Every network or
part of the
international network will pass this bit transparently. If the calling
DTE is able to handle the D\ bit procedure, it should not regard this bit
being set
to\ 1 in the \fIcall connected\fR packet as invalid.
.PP
The use by DTEs of the above mechanism in the \fIcall request\fR \|and
\fIcall accepted\fR \|packets is recommended but is not mandatory for using the
D\ bit procedure during the virtual call.
.RT
.sp 1P
.LP
4.3.4
    \fIMore Data mark\fR
.sp 9p
.RT
.PP
If a DTE or DCE wishes to indicate a sequence of more than one
packet, it uses a more data mark (M\ bit) as defined below.
.PP
The
M bit
can be set to 1 in any \fIdata\fR \|packet. When it is
set to\ 1 in a full \fIdata\fR \|packet or in a partially full \fIdata\fR
packet also
carrying the D\ bit set to\ 1, it indicates that more data is to follow.
Recombination with the following \fIdata\fR packet may only be performed within
the network when the M\ bit is set to\ 1 in a full \fIdata\fR packet which
also has the D\ bit set to\ 0.
.PP
A sequence of \fIdata\fR \|packets with every M\ bit set to 1 except for
the last one will be delivered as a sequence of \fIdata\fR packets with
the M\ bit set to 1 except for the last one when the original packets having
the M\ bit set to 1 are either full (irrespective of the setting of the
D\ bit) or partially full but have the D\ bit set to 1.
.PP
Two categories of \fIdata\fR \|packets, A and B, have been defined as shown
in Table\ 15/X.25. Table\ 15/X.25 also illustrates the network's treatment
of the M\ and D\ bits at both ends of a virtual call or permanent virtual
circuit.
.RT
.sp 1P
.LP
4.3.5
    \fIComplete packet sequence\fR
.sp 9p
.RT
.PP
A complete packet sequence is defined as being composed of a single \fIcategory\
B\fR \|packet and all contiguous preceding \fIcategory\ A\fR packets (if
any). \fICategory\ A\fR packets have the exact maximum user data field
length with the M\ bit set to\ 1 and the D\ bit set to\ 0. All other \fIdata\fR
packets are
\fIcategory\ B\fR packets.
.PP
When transmitted by a source DTE, a complete packet sequence is
always delivered to the destination DTE as a single complete packet
sequence.
.PP
Thus, if the receiving end has a larger maximum user data field length
than the transmitting end, then packets within a complete packet sequence
will be combined within the network. They will be delivered in a complete
packet
sequence where each packet, except the last one, has the exact maximum user
data field length, the M\ bit set to\ 1, and the D\ bit set to\ 0. The
user data
field of the last packet of the sequence may have less than the maximum
length and the M and D\ bits are set as described in Table\ 15/X.25.
.bp
.RT
.ce
\fBH.T. [T13.25]\fR
.ce
TABLEAU\ 15/X.25
.ce
\fBDefinition of two categories of data packets and network treatment
.ce
of the M and D bits\fR
.T&
lw(30p) | lw(30p) | lw(18p) | lw(30p) | lw(60p) | lw(30p) | lw(30p) .

.T&
cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
B    0 or 1    0    No    No    0  (see Note 1)    0
_
.T&
cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
B    0    1    No    No    0    1
_
.T&
cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
B    1    1    No    No    1    1
_
.T&
cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
B    0    0    Yes    No    0    0
_
.T&
cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
B    0    1    Yes    No    0    1
_
.T&
cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
A    1    0    Yes    Yes (see Note 2)    1    0
_
.T&
cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
B    1    1    Yes    No    1    T{
1
\ua\d\u)\d
Refers to the delivered \fIdata\fR
\| packet whose last bit of user data corresponds to the last bit of user
data, if any, that was present in the
\fIdata\fR
packet sent by the source DTE.
.parag
\fINote\ 1\fR
\ \(em\ The originating network will force the M bit to 0.
.parag
\fINote\ 2\fR
\ \(em\ If the \fIdata\fR
 packet sent by the source DTE is combined with other packets, up to and
including a \fIcategory B\fR
\| packet, the M and D bit settings in the \fIdata\fR
 packet received by the destination DTE will be according to that given
in the two right hand columns for the last \fIdata\fR
packet sent by the
source DTE that was part of the combination.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 15/X.25 [T13.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.PP
If the maximum user data field length is the same at both ends, then
user data fields of \fIdata\fR packets are delivered to the receiving DTE
exactly as they have been received by the network, except as follows. If
a full packet with the M\ bit set to\ 1 and D\ bit set to\ 0 is followed
by an empty packet, then the two packets may be merged so as to become
a single \fIcategory\ B\fR full
packet. If the last packet of a complete packet sequence transmitted by the
source DTE has a data field less than the maximum length, the M\ bit set to 1
and the D\ bit set to\ 0, then the last packet of the complete packet sequence
delivered to the receiving DTE will have the M\ bit
set\ to\ 0.
.PP
If the receiving end has a smaller maximum user data field length than
the transmitting end, the packets will be segmented within the network,
and the M and D\ bits will be set by the network as described to maintain
complete
packet sequences.
.RT
.sp 1P
.LP
4.3.6
    \fIQualifier bit\fR
.sp 9p
.RT
.PP
In some cases, an indicator may be needed with the user data field to distinguish
between two types of information. It may be necessary to
differentiate, for example, between user data and control information. An
example of such a case is contained in Recommendation\ X.29.
.PP
If such a mechanism is needed, an indicator in the data packet
header called the Qualifier bit (Q\ bit) may be used.
.bp
.PP
The use of the
Q\ bit
is optional. If this mechanism is not
needed, the Q\ bit is always set to\ 0. If the Q\ bit mechanism is used, the
transmitting DTE should set the Q\ bit so as to have the same value (i.e.\ 0
or\ 1) in all \fIdata\fR packets of the same complete packet sequence.
A complete
packet sequence transferred by the DTE to the DCE in this fashion will be
delivered to the distant DTE as a complete packet sequence having the Q\
bit set in all packets to the value assigned by the transmitting DTE.
.PP
If the Q\ bit is not set by the DTE to the same value in all the \fIdata\fR
\|packets of a complete packet sequence, the value of the Q\ bit in any
of the
\fIdata\fR packets of the corresponding packet sequence transferred to
the distant DTE is not guaranteed by the network. Moreover, some networks
may reset
the virtual call or permanent virtual circuit as described in
Annex\ C/X.25.
.PP
Successive \fIdata\fR \| packets are numbered consecutively (see \(sc\
4.4.1.1) regardless of the value of the Q\ bit.
.RT
.sp 1P
.LP
4.3.7
    \fIInterrupt procedure\fR
.sp 9p
.RT
.PP
The interrupt procedure allows a DTE to transmit data to the
remote DTE, without following the flow control procedure applying to \fIdata\fR
packets (see \(sc\ 4.4). The interrupt procedure can only apply in the
\fIflow\fR
\fIcontrol ready\fR state\ (d1) within the \fIdata transfer\fR state\ (p4).
.PP
The interrupt procedure has no effect on the transfer and flow control
procedures applying to the \fIdata\fR packets on the virtual call or permanent
virtual circuit.
.PP
To transmit an interrupt, a DTE transfers across the DTE/DCE interface
a \fIDTE interrupt\fR \|packet. The DTE should not transmit a second \fIDTE
interrupt\fR packet until the first one is confirmed with a \fIDCE interrupt
confirmation\fR
packet (see Table\ C\(hy4/X.25). The DCE, after the interrupt procedure is
completed at the remote end, will confirm the receipt of the interrupt by
transferring a \fIDCE interrupt confirmation\fR packet. The receipt of
a \fIDCE\fR
\fIinterrupt confirmation\fR packet indicates that the interrupt has been
confirmed by the remote DTE by means of a \fIDTE interrupt confirmation\fR
packet.
.PP
The DCE indicates an interrupt from the remote DTE by transferring
across the DTE/DCE interface a \fIDCE interrupt\fR packet containing the
same data field as in the \fIDTE interrupt\fR packet transmitted by the
remote DTE. A \fIDCE\fR \fIinterrupt\fR packet is delivered at or before
the point in the stream of \fIdata\fR packets at which the \fIDTE interrupt\fR
packet was generated. The DTE will confirm the receipt of the \fIDCE interrupt\fR
packet by transferring a \fIDTE interrupt\fR
\fIconfirmation\fR packet.
.RT
.sp 1P
.LP
4.3.8
    \fITransit delay\fR \fIof data packets\fR
.sp 9p
.RT
.PP
Transit delay
is an inherent characteristic of a virtual
call or a permanent virtual circuit, common to the two directions of
transmission.
.PP
This transit delay is the \fIdata\fR \| packet transfer delay as defined
in \(sc\ 3.1/X.135, measured between boundaries\ B\d2\uand B\fI\fI\d\fIn\fR\\d\\u(em\d1\u,
as defined in Figure\ 2/X.135 (that means, excluding the access lines),
with the conditions given in \(sc\ 3.2/X.135, and is expressed in terms
of a mean value.
.PP
Selection of transit delay on a per call basis, and indication to both
the calling and called DTEs of the value of transit delay applying for
a given virtual call, may be made by the means of the \fItransit delay
selection and\fR
\fIindication\fR facility (see \(sc\ 6.27).
.RT
.sp 1P
.LP
4.4
    \fIProcedures for flow control\fR
.sp 9p
.RT
.PP
Paragraph\ 4.4 only applies to the \fIdata transfer\fR \|state (p4) and
specifies the procedures covering flow control of \fIdata\fR packets and
reset on each logical channel used for a virtual call or a permanent virtual
circuit.
.RT
.sp 1P
.LP
4.4.1
    \fIFlow control\fR
.sp 9p
.RT
.PP
At the DTE/DCE interface of a logical channel used for a virtual
call or permanent virtual circuit, the transmission of \fIdata\fR packets is
controlled separately for each direction and is based on authorizations from
the receiver.
.PP
On a virtual call or permanent virtual circuit, flow control also
allows a DTE to limit the rate at which it accepts packets across the DTE/DCE
interface, noting that there is a network\(hydependent limit on the number
of
\fIdata\fR packets which may be in the network on the virtual call or permanent
virtual circuit.
.bp
.RT
.sp 1P
.LP
4.4.1.1
    \fINumbering of data packets\fR
.sp 9p
.RT
.PP
Each \fIdata\fR \|packet transmitted at the DTE/DCE interface for each
direction of transmission in a virtual call or permanent virtual circuit
is
sequentially numbered.
.PP
The sequence numbering scheme of the packets is performed modulo\ 8.
The packet sequence numbers cycle through the entire range\ 0 to\ 7. Some
Administrations will provide the \fIextended packet sequence numbering\fR
facility (see \(sc\ 6.2) which, if selected, provides a sequence numbering
scheme for
packets being performed modulo\ 128. In this case, packet sequence numbers
cycle through the entire range\ 0 to\ 127. The packet sequence numbering
scheme,
modulo\ 8 or\ 128, is the same for both directions of transmission and
is common for all logical channels at the DTE/DCE interface.
.PP
Only \fIdata\fR \|packets contain this sequence number called the
packet send sequence number P(S)
.
.PP
The first \fIdata\fR \|packet to be transmitted across the DTE/DCE
interface for a given direction of data transmission, when the logical
channel has just entered the \fIflow control ready\fR state (d1), has a
packet send
sequence number equal to\ 0.
.RT
.sp 1P
.LP
4.4.1.2
    \fIWindow description\fR
.sp 9p
.RT
.PP
At the DTE/DCE interface, a window is defined for each direction of data
transmission of a logical channel used for a virtual call or permanent
virtual circuit. The window is the ordered set of W consecutive packet send
sequence numbers of the \fIdata\fR packets authorized to cross the
interface.
.PP
The lowest sequence number in the window is referred to as the
lower window edge
. When a virtual call or permanent virtual circuit at the DTE/DCE interface
has just entered the \fIflow control ready\fR state (d1), the window related
to each direction of data transmission has a lower window edge equal to\
0.
.PP
The packet send sequence number of the first \fIdata\fR \|packet not
authorized to cross the interface is the value of the lower window edge
plus W (modulo\ 8, or 128\ when extended).
.PP
The standard window size W is 2 for each direction of data
transmission at the DTE/DCE interface. In addition, other window sizes
may be offered by Administrations. An optional
window size
may be selected for a period of time as the default window size common
to all virtual calls at the DTE/DCE interface (see \(sc\ 6.10). A value
other than the default may be selected for a period of time for each permanent
virtual circuit (see \(sc\ 6.10).
Negotiation of window sizes
on a per call basis may be made with the
\fIflow control parameter negotiation\fR facility (see \(sc\ 6.12).
.RT
.sp 1P
.LP
4.4.1.3
    \fIFlow control principles\fR
.sp 9p
.RT
.PP
When the sequence number P(S) of the next \fIdata\fR \|packet to be
transmitted by the DCE is within the window, the DCE is authorized to transmit
this \fIdata\fR packet to the DTE. When the sequence number\ P(S) of the
next data packet to be transmitted by the DCE is outside of the window,
the DCE will not transmit a \fIdata\fR packet to the DTE. The DTE should
follow the same
procedure.
.PP
When the sequence number P(S) of the \fIdata\fR \|packet received by the
DCE is the next in sequence and is within the window, the DCE will accept
this \fIdata\fR packet. A received \fIdata\fR packet containing a P(S)
that is out of
sequence (i.e.,\ there is a duplicate or a gap in the P(S) numbering),
outside the window, or not equal to\ 0 for the first \fIdata\fR packet
after entering the
\fIflow control ready\fR state\ (d1) is considered by the DCE as a local
procedure error. The DCE will reset the virtual call or permanent virtual
circuit (see
\(sc\ 4.4.3). The DTE should follow the same procedure.
.PP
A number (modulo 8, or 128 when extended), referred to as a
packet receive sequence number P(R)
, conveys across the DTE/DCE interface
information from the receiver for the transmission of \fIdata\fR packets. When
transmitted across the DTE/DCE interface, a\ P(R) becomes the lower window
edge. In this way, additional \fIdata\fR packets may be authorized by the
receiver to
cross the DTE/DCE interface.
.PP
The packet receive sequence number, P(R), is conveyed in \fIdata\fR ,
\fIreceive ready\fR \|(RR) and \fIreceive not ready\fR (RNR) packets.
.bp
.PP
The value of a P(R) received by the DCE must be within the range from the
last P(R) received by the DCE up to and including the packet send sequence
number of the next \fIdata\fR packet to be transmitted by the DCE. Otherwise,
the DCE will consider the receipt of this P(R) as a procedure error and
will reset the virtual call or permanent virtual circuit. The DTE should
follow the same procedure.
.PP
The receive sequence number P(R) is less than or equal to the sequence
number of the next expected \fIdata\fR packet and implies that the DTE
or DCE
transmitting P(R) has accepted at least all \fIdata\fR packets numbered
up to and including P(R)\ \(em\ 1.
.RT
.sp 1P
.LP
4.4.1.4
    \fIDelivery confirmation\fR
.sp 9p
.RT
.PP
When the D\ bit is set to 0 in a \fIdata\fR \|packet having P(S) = p, the
significance of the returned P(R) corresponding to that \fIdata\fR packet
[i.e.,\ P(R)\ \(>="\ p\ +\ 1] is a
local updating of the window
across the
packet level interface so that the achievable throughput is not constrained
by the DTE to DTE round trip delay across the network(s).
.PP
When the D\ bit is set to 0 in a \fIdata\fR \|packet, the returned P(R)
corresponding to that \fIdata\fR \|packet does not signify that a P(R) has been
received from the remote DTE.
.PP
When the D\ bit is set to 1 in a \fIdata\fR \|packet having P(S)\ =\ p, the
significance of the returned P(R) corresponding to that \fIdata\fR packet
[i.e.\ P(R)\ \(>="\ p\ +\ 1] is an indication that a\ P(R) has been received
from the
remote DTE for all data bits in the \fIdata\fR packet in which the D\ bit had
originally been set to\ 1.
.PP
\fINote\ 1\fR \ \(em\ A DTE, on receiving a \fIdata\fR \|packet with the
D\ bit set
to\ 1, should transmit the corresponding P(R) as soon as possible in order to
avoid the possibility of deadlocks (e.g.\ without waiting for further \fIdata\fR
packets). A \fIdata\fR , \fIRR\fR or \fIRNR\fR packet may be used to convey
the P(R) (see
Note to \(sc\ 4.4.1.6). Likewise, the DCE is required to send P(R) to the
DTE as
soon as possible from when the P(R) is received from the remote DTE. When
the DTE is not currently operating the D\ bit procedure, the receipt of
a \fIdata\fR
packet with the D\ bit set to\ 1 may be treated by the DTE as an error
condition.
.PP
\fINote\ 2\fR \ \(em\ If a P(R) for a \fIdata\fR \|packet with the D\ bit
set to 1 is outstanding, local updating of the window will be deferred
for subsequent
\fIdata\fR packets with the D\ bit set to\ 0. Some networks may also defer
updating the window for previous \fIdata\fR packets (within the window)
with the D\ bit set to 0 until the corresponding P(R) for the packet with
the outstanding D\ bit set to 1 is transmitted to the DTE.
.PP
\fINote\ 3\fR \ \(em\ P(R) values corresponding to the data contained in
\fIdata\fR \|packets with the D\ bit set to\ 1 need not be the same at
the DTE/DCE interfaces at each end of a virtual call or a permanent virtual
circuit.
.PP
\fINote\ 4\fR \ \(em\ If the DTE has sent \fIdata\fR \|packets with the
D\ bit set
to\ 0, the DTE does not have to wait for local updating of the window by
the DCE before initiating a resetting or clearing procedure.
.RT
.sp 1P
.LP
4.4.1.5
    \fIDTE and DCE receive ready (RR) packets\fR
.sp 9p
.RT
.PP
\fIRR\fR \|packets are used by the DTE or DCE to indicate that it is
ready to receive the W\ \fIdata\fR \|packets within the window starting
with P(R),
where P(R) is indicated in the \fIRR\fR \ packet.
.RT
.sp 1P
.LP
4.4.1.6
    \fIDTE and DCE receive not ready (RNR) packets\fR
.sp 9p
.RT
.PP
\fIRNR\fR \|packets are used by the DTE or DCE to indicate a temporary
inability to accept additional \fIdata\fR packets for a given virtual call
or
permanent virtual circuit. A DTE or DCE receiving an \fIRNR\fR packet shall
stop
transmitting \fIdata\fR packets on the indicated logical channel, but the
window is updated by the P(R) value of the \fIRNR\fR packet. The receive
not ready situation indicated by the transmission of an \fIRNR\fR packet
is cleared by the transmission in the same direction of an \fIRR\fR packet
or by the initiation of a reset
procedure.
.PP
The transmission of an \fIRR\fR \|packet after an \fIRNR\fR \| packet at the
packet level is not to be taken as a demand for retransmission of packets
which have already been transmitted.
.PP
\fINote\fR \ \(em\ The \fIRNR\fR \|packet may be used to convey across
the DTE/DCE
interface the P(R) value corresponding to a \fIdata\fR packet which had
the D\ bit set to\ 1 in the case that additional \fIdata\fR packets cannot
be
accepted.
.bp
.RT
.sp 1P
.LP
4.4.2
    \fIThroughput characteristics\fR \fIand\fR
\fIthroughput\fR
\fIclasses\fR
.sp 9p
.RT
.PP
The definitions of throughput and steady state throughput are given in
\(sc\ 4 of Recommendation\ X.135.
.PP
A throughput class for one direction of transmission is an inherent
characteristic of the virtual call or permanent virtual circuit related
to the amount of resources allocated to this virtual call or permanent
virtual
circuit. It is a measure of the steady state throughput that can be provided
under optimal conditions on a virtual call or permanent virtual circuit.
However, due to the statistical sharing of transmission and switching
resources, it is not guaranteed that the throughput class can be reached
100% of the time.
.PP
The relations between throughput class and the throughput parameters and
objectives described in Recommendation\ X.135 require further study. The
complete definition of the optimal conditions where the measure of the
steady state throughput in relation to throughput class is meaningful also
requires
further study. Pending the results of these further studies, it cannot be
guaranteed or verified that a network supporting a given throughput class
value (64\ kbit/s for instance) offers better performance to its users than a
network not supporting that throughput class. However, a network may offer a
guarantee to its users on a contribution basis.
.PP
The optimal conditions for measurement include the
following:
.RT
.LP
    1)
    the access line characteristics of the local and remote
DTEs do not constrain the throughput class;
.LP
     \fINote\fR \ \(em\ In particular, because of the overhead due to the
frame and packet headers, when the throughput class corresponding to the
user class of service of the DTE is applicable to a virtual call or permanent
virtual
circuit, a steady state throughput equal to that throughput class can never
be reached.
.LP
    2)
     the window sizes at the local and remote DTE/DCE interfaces do not constrain
the throughput;
.LP
    3)
    the traffic characteristics of other logical channels at
local and remote DTE/DCE interfaces do not constrain the throughput;
.LP
    4)
     the receiving DTE is not flow controlling the DCE such that the throughput
class is not attainable;
.LP
    5)
     the transmitting DTE sends only \fIdata\fR \|packets which have the maximum
data field length;
.LP
    6)
    the D bit is not set to 1.
.PP
The throughput class is expressed in bits per second. The maximum data
field length is specified for a virtual call or permanent virtual circuit,
and thus the throughput class can be interpreted by the DTE as the number
of
full \fIdata\fR packets/second that the DTE/DCE interface.
.PP
In the absence of the \fIdefault throughput classes assignment\fR
\|facility (see \(sc\ 6.11), the default throughput classes for both directions
of transmission correspond to the user class of service of the DTE (see
\(sc\ 7.2.2.2) but do not exceed the maximum throughput class supported
by the network.
Negotiation of throughput classes on a per call basis may be made with the
\fIthroughput class negotiation\fR \|facility (see \(sc\ 6.13).
.PP
\fINote\fR \ \(em\ The sum of the throughput classes of all virtual calls and
permanent virtual circuits supported at a DTE/DCE interface may be greater
than the data transmission rate of the access line.
.RT
.sp 1P
.LP
4.4.3
    \fIProcedure for reset\fR
.sp 9p
.RT
.PP
The reset procedure is used to reinitialize the virtual call or
permanent virtual circuit and in so doing removes in each direction all
\fIdata\fR and \fIinterrupt\fR packets which may be in the network (see
\(sc\ 4.5). When a virtual call or permanent virtual circuit at the DTE/DCE
interface has just been reset, the window related to each direction of
data transmission has a lower window
edge equal to\ 0, and the numbering of subsequent \fIdata\fR packets to
cross the
DTE/DCE interface for each direction of data transmission shall start
from\ 0.
.PP
The reset procedure can only apply in the \fIdata transfer\fR \|state (p4)
of the DTE/DCE interface. In any other state of the DTE/DCE interface,
the
reset procedure is abandoned. For example, when a clearing or restarting
procedure is initiated, \fIreset request\fR and \fIreset indication\fR
packets can be left unconfirmed.
.bp
.PP
For flow control, there are three states d1, d2 and d3 within the
\fIdata transfer\fR \|state\ (p4). There are \fIflow control ready\fR \
(d1), \fIDTE reset\fR \fIrequest\fR \ (d2), and \fIDCE reset indication\fR
\ (d3) as shown in the state diagram in Figure\ B\(hy3/X.25. When entering
state p4, the logical channel is placed in
state d1. Table\ C\(hy4/X.25 specifies actions taken by the DCE on the
receipt of packets from the DTE.
.RT
.sp 1P
.LP
4.4.3.1
    \fIReset request\fR \fIpacket\fR
.sp 9p
.RT
.PP
The DTE shall indicate a request for reset by transmitting a
\fIreset request\fR \|packet specifying the logical channel to be reset.
This places the logical channel in the \fIDTE reset request\fR state\ (d2).
.RT
.sp 1P
.LP
4.4.3.2
    \fIReset indication\fR \fIpacket\fR
.sp 9p
.RT
.PP
The DCE will indicate a reset by transmitting to the DTE a \fIreset\fR
\fIindication\fR \|packet specifying the logical channel being reset and
the reason for the resetting. This places the logical channel in the \fIDCE
reset\fR
\fIindication\fR state\ (d3). In this state, the DCE will ignore \fIdata\fR ,
\fIinterrupt\fR , \fIRR\fR and \fIRNR\fR packets.
.RT
.sp 1P
.LP
4.4.3.3
    \fIReset collision\fR
.sp 9p
.RT
.PP
Reset collision occurs when a DTE and a DCE simultaneously transmit a \fIreset
request\fR \|packet and a \fIreset indication\fR packet specifying the
same logical channel. Under these circumstances the DCE will consider that
the reset is completed. The DCE will not expect a \fIDTE reset confirmation\fR
packet and
will not transfer a \fIDCE reset confirmation\fR packet. This places the
logical
channel in the \fIflow control ready\fR state\ (d1).
.RT
.sp 1P
.LP
4.4.3.4
    \fIReset confirmation\fR \fIpackets\fR
.sp 9p
.RT
.PP
When the logical channel is in the \fIDTE reset request\fR \|state (d2),
the DCE will confirm reset by transmitting to the DTE a \fIDCE reset\fR
\fIconfirmation\fR packet. This places the logical channel in the \fIflow
control\fR \fIready\fR state\ (d1).
.PP
The \fIDCE reset confirmation\fR \|packet can only be interpreted
universally as having local significance; however, within some Administrations'
networks, \fIreset confirmation\fR may have end\(hyto\(hyend significance.
In all cases the time spent in the \fIDTE reset request\fR state\ (d2)
will not exceed
time\(hylimit\ T22 (see Annex\ D).
.PP
When the logical channel is in the \fIDCE reset indication\fR \|state (d3),
the DTE will confirm reset by transmitting to the DCE a \fIDTE reset\fR
\fIconfirmation\fR packet. This places the logical channel in the \fIflow
control\fR \fIready\fR state (d1). The action taken by the DCE when the
DTE does not confirm the reset within time\(hyout T12 is given in Annex\
D.
.RT
.sp 1P
.LP
4.5
    \fIEffects of clear, reset and restart procedures on the transfer\fR
\fIof packets\fR
.sp 9p
.RT
.PP
All \fIdata\fR \|and \fIinterrupt\fR \|packets generated by a DTE (or the
network) before initiation by the DTE or the DCE of a clear, reset or restart
procedure at the local interface will either be delivered to the remote
DTE
before the DCE transmits the corresponding indication on the remote interface,
or be discarded by the network.
.PP
No \fIdata\fR \|or \fIinterrupt\fR packets generated by a DTE (or the network)
after the completion of a reset (or for permanent virtual circuits also
a
restart) procedure at the local interface will be delivered to the remote
DTE before the completion of the corresponding reset procedure at the remote
interface.
.PP
When a DTE initiates a clear, reset or restart procedure at its local interface,
all \fIdata\fR \|and \fIinterrupt\fR packets which were generated by the
remote DTE (or the network) before the corresponding indication is transmitted
to the remote DTE will be either delivered to the initiating DTE before
DCE
confirmation of the initial clear, reset or restart request, or be discarded
by the network.
.PP
\fINote\fR \ \(em\ The maximum number of packets which may be discarded is a
function of network end\(hyto\(hyend delay and throughput characteristics
and, in
general, has no relation to the local window size. For virtual calls and
permanent virtual circuits on which all \fIdata\fR packets are transferred
with the D\ bit set to\ 1, the maximum number of packets which may be discarded
in one
direction of transmission is not larger than the window size of the direction
of transmission.
.bp
.RT
.sp 2P
.LP
4.6
     \fIEffects of the physical layer and the data link layer on the\fR \fIpacket
layer\fR
.sp 1P
.RT
.sp 1P
.LP
4.6.1
    \fIGeneral principles\fR
.sp 9p
.RT
.PP
In general, if a problem is detected in one layer (physical, data link
or packet layer) and can be solved in this layer according to the DCE
error recovery procedures provided in this Recommendation without loss or
duplication of data, the adjacent layers are not involved in the error
recovery.
.PP
If an error recovery by the DCE implies a possible loss or duplication
of data, then the higher layer is informed.
.PP
The reinitialization of one layer by the DCE is only performed if a
problem cannot be solved in this layer.
.PP
Changes of operational states of the physical layer and the data link layer
of the DTE/DCE do not implicitly change the state of each logical channel
at the packet layer. Such changes when they occur are expliciltly indicated
at the packet layer by the use of restart, clear or reset procedures as
appropriate.
.RT
.sp 1P
.LP
4.6.2
    \fIDefinition of an\fR
\fIout of order condition\fR
.sp 9p
.RT
.PP
In the case of a single link procedure, there is an out of order
condition when:
.RT
.LP
    \(em
     a failure on the physical and/or data link layer is detected: such a
failure is defined as a condition in which the DCE cannot transmit or
cannot receive any frame because of abnormal conditions caused by, for
instance, a line default between DTE and\ DCE;
.LP
     \fINote\fR \ \(em\ Short physical layer outages (e.g. loss of carrier)
are not considered as physical layer failures by the DCE and the data link
layer
and packet layer are not informed.
.LP
    \(em
    the DCE has received or transmitted a DISC
command.
.PP
There may be other out of order network\(hydependent conditions such as:
reset of the data link layer, expiration of T3\ timer (see \(sc\ 2.4.5.3),
receipt or transmission of a DM\ response,\ .\|.\|.\ etc.
.PP
In the case of the Multilink procedure, an out of order condition is considered
as having occured when it is present at the same time for every
single link procedure of the DTE/DCE interface. There may be other out
of order network\(hydependent conditions such as the performance by DTE
or DCE of the
multilink resetting procedure (see \(sc\ 2.5.4.2), loss of multilink frame(s)
(see \(sc\ 2.5.4.4),\ etc.
.RT
.sp 1P
.LP
4.6.3
    \fIActions on the packet layer when an out of order condition is\fR
\fIdetected\fR
.sp 9p
.RT
.PP
When an out of order ocndition is detected, the DCE will transmit to the
remote end:
.RT
.LP
    1)
    a reset with the cause \*QOut of order\*U for each permanent
virtual circuit; and
.LP
    2)
    a clear with the cause \*QOut of order\*U for each existing
virtual call.
.sp 1P
.LP
4.6.4
    \fIActions on the packet layer during an out of order condition\fR
.sp 9p
.RT
.PP
During an out of order condition:
.RT
.LP
    1)
    the DCE will clear any incoming virtual call with the cause
\*QOut of order\*U;
.LP
    2)
    for any \fIdata\fR \|or \fIinterrupt\fR \|packet received from the
remote DTE on a permanent virtual circuit, the DCE will reset
the permanent virtual circuit with the cause \*QOut of
order\*U;
.LP
    3)
    a \fIreset\fR \|packet received from the remote DTE on a
permanent virtual circuit will be confirmed to the remote DTE by
either \fIreset confirmation\fR or \fIreset indication\fR packet.
.sp 1P
.LP
4.6.5
     \fIActions on the packet layer when the out of order condition is\fR
\fIrecovered\fR
.sp 9p
.RT
.PP
When the out of order condition is recovered:
.RT
.LP
    1)
    the DCE will send a \fIrestart indication\fR \|packet with the
cause \*QNetwork operational\*U to the local\ DTE;
.LP
    2)
    a reset with the cause \*QRemote DTE operational\*U will be
transmitted to the remote end of each permanent virtual
circuit.
.LP
.bp