ETSI ETS 300 402-3 ed.1 (1996-08)

Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Data link layer; Part 3: Frame relay protocol specification

DE/SPS-05030-1

Digitalno omrežje z integriranimi storitvami (ISDN) - Protokol digitalne naročniške signalizacije št. 1 (DSS1) - Podatkovna povezovalna plast - 3. del: Specifikacija protokola blokovnega posredovanja

General Information

• Status: Published
• Publication Date: 21-Aug-1996
• Technical Committee: SPS 5 - Digital access signalling
• Current Stage: 12 - Completion
• Due Date: 06-Sep-1996
• Completion Date: 22-Aug-1996
• Ref Project: SIST ETS 300 402-3:1998 - Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Data link layer; Part 3: Frame relay protocol specification

Standards Content (Sample)

SLOVENSKI STANDARD
SIST ETS 300 402-3:1998
01-junij-1998
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'13URWRNROGLJLWDOQHQDURþQLãNH
VLJQDOL]DFLMHãW'663RGDWNRYQDSRYH]RYDOQDSODVWGHO6SHFLILNDFLMD
SURWRNRODEORNRYQHJDSRVUHGRYDQMD
Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one
(DSS1) protocol; Data link layer; Part 3: Frame relay protocol specification
Ta slovenski standard je istoveten z: ETS 300 402-3 Edition 1
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
35.100.20 Podatkovni povezovalni sloj Data link layer
SIST ETS 300 402-3:1998 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST ETS 300 402-3:1998

---------------------- Page: 2 ----------------------

SIST ETS 300 402-3:1998
EUROPEAN ETS 300 402-3
TELECOMMUNICATION August 1996
STANDARD
Source: ETSI TC-SPS Reference: DE/SPS-05030-1
ICS: 33.080, 35.100.20
Key words: ISDN, DSS1, layer 2, D-channel, LAPF
Integrated Services Digital Network (ISDN);
Digital Subscriber Signalling System No. one (DSS1) protocol;
Data link layer;
Part 3: Frame relay protocol specification
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1996. All rights reserved.

---------------------- Page: 3 ----------------------

SIST ETS 300 402-3:1998
Page 2
ETS 300 402-3: August 1996
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

---------------------- Page: 4 ----------------------

SIST ETS 300 402-3:1998
Page 3
ETS 300 402-3: August 1996
Contents
Foreword .5
1 Scope .7
2 Normative references.7
3 Abbreviations.8
4 Frame structure for peer-to-peer communication .9
4.1 General .9
4.2 Flag sequence .9
4.3 Address field .9
4.4 Control field.9
4.5 Frame Relay information field.9
4.6 Transparency.10
4.7 Frame Checking Sequence (FCS) field.10
4.8 Format convention .10
4.9 Invalid frames .10
4.10 Frame abort .10
5 Elements of procedures and formats of fields for the DL-CORE services sublayer .11
5.1 General .11
5.2 Address field format.11
5.3 Address field variables.12
5.3.1 Address field extension bit (EA) .12
5.3.2 Command/Response bit (C/R).12
5.3.3 Forward Explicit Congestion Notification (FECN).12
5.3.4 Backward Explicit Congestion Notification (BECN).12
5.3.5 Discard Eligibility indicator (DE) .12
5.3.6 Data Link Connection Identifier (DLCI).12
5.3.7 DLCI/DL-CORE control indicator (D/C).13
6 Placement of the DL-CORE sublayer protocol in the ISDN protocol architecture.14
6.1 Support by the underlying physical layer service .19
6.2 DL-CORE service .19
6.2.1 Primitives.19
6.2.2 Parameters.19
6.2.3 Procedures.19
6.2.3.1 Primitives/Frame Relay frame mapping .19
6.2.3.2 Parameters/fields mapping.19
6.3 Layer management.20
6.3.1 Primitives.20
6.3.1.1 MC-ASSIGN request .20
6.3.1.2 MC-REMOVE request .20
6.3.1.3 M2N-ASSIGN request .20
6.3.1.4 M2N-REMOVE request .20
6.3.1.5 MDL-ASSIGN request .20
6.3.1.6 MDL-REMOVE request .20
6.3.2 Parameters.20
6.3.2.1 DLCI value.20
6.3.2.2 DL-CORE Connection Endpoint Identifier (CEI).20
6.3.2.3 DL CEI .21
6.3.2.4 PH CEI.21
6.3.3 Procedures.21
6.3.3.1 DL-CORE connection establishment.21
6.3.3.2 DL-CORE connection release .21

---------------------- Page: 5 ----------------------

SIST ETS 300 402-3:1998
Page 4
ETS 300 402-3: August 1996
7 List of system parameters . 21
8 Congestion control procedures. 22
8.1 Implicit congestion detection . 22
8.2 Explicit notification. 22
8.2.1 Explicit congestion signals. 22
8.2.2 Rate reduction strategy. 22
Annex A (normative): Consolidated Link Layer Management (CLLM) message. 23
A.1 Address octets. 24
A.2 Control field. 24
A.3 XID information field . 24
A.3.1 Format identifier field. 24
A.3.2 Group field. 24
A.3.2.1 Group identifier field. 24
A.3.2.2 Group length field . 24
A.3.2.3 Group value field. 24
A.3.3 Parameter for Parameter set identification . 25
A.3.3.1 Parameter set identification field. 25
A.3.3.2 Parameter set identification length field. 25
A.3.3.3 Parameter value field. 25
A.3.4 Parameter field for Cause identifier. 25
A.3.4.1 Parameter identifier field. 25
A.3.4.2 Parameter length field. 25
A.3.4.3 Cause value. 25
A.3.5 Parameter field for DLCI identifier. 26
A.3.5.1 Parameter identifier field. 26
A.3.5.2 Parameter length field. 26
A.3.5.3 Parameter value field. 26
A.4 Frame check sequence field. 26
A.5 Action of the congested node . 26
History. 27

---------------------- Page: 6 ----------------------

SIST ETS 300 402-3:1998
Page 5
ETS 300 402-3: August 1996
Foreword
This European Telecommunication Standard (ETS) has been produced by the Signalling Protocols and
Switching (SPS) Technical Committee of the European Telecommunications Standards Institute (ETSI).
This ETS is based on CCITT Recommendation Q.922 (1992) and provides modifications and further
requirements.
This ETS is part 3 of a multi-part standard covering the Integrated Services Digital Network (ISDN) Digital
Subscriber Signalling System No. one (DSS1) data link layer specification as described below:
Part 1: "General aspects [ITU-T Recommendation Q.920 (1993), modified]";
Part 2: "General protocol specification [ITU-T Recommendation Q.921 (1993), modified]";
Part 3: "Frame relay protocol specification";
Part 4: "Protocol Implementation Conformance Statement (PICS) proforma specification for the
general protocol";
Part 5: "PICS proforma specification for the frame relay protocol";
Part 6: "Test Suite Structure and Test Purposes (TSS&TP) specification for the general protocol";
Part 7: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing
(PIXIT) proforma specification for the general protocol".
Transposition dates
Date of adoption of this ETS: 16 August 1996
Date of latest announcement of this ETS (doa): 30 November 1996
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 May 1997
Date of withdrawal of any conflicting National Standard (dow): 31 May 1997

---------------------- Page: 7 ----------------------

SIST ETS 300 402-3:1998
Page 6
ETS 300 402-3: August 1996
Blank page

---------------------- Page: 8 ----------------------

SIST ETS 300 402-3:1998
Page 7
ETS 300 402-3: August 1996
1 Scope
This third part of ETS 300 402 specifies the frame structure, elements of procedure, format of fields and
procedures for the proper operation of the Frame Relay layer 2 protocol as described in the service
description ETS 300 399-1 [1].
NOTE 1: The Frame Relay protocol as defined in this ETS may be used with or without the
elements of procedures of Link Access Procedure for Frame mode bearer services
(LAPF) in CCITT Recommendation Q.922 [8].
LAPF as defined in CCITT Recommendation Q.922 [8] designates the link access procedures applicable
to, but not restricted to, the Frame Relay service. The protocol specified in this ETS is a subset of LAPF; it
is named "Data Link Core protocol" (DL-CORE) and it is used to support the Frame Relay service. It is
intended to:
- share the core functions of LAPF as defined in ITU-T Recommendation I.233 [5];
- be used on B- or D-channel or n × 64 kbit/s; and
- operate on the D-channel simultaneously with the Link Access Procedure on the D-channel (LAPD)
protocol as defined in ITU-T Recommendations Q.920 and Q.921 as modified by ETS 300 402-1 [2]
and ETS 300 402-2 [3].
It assumes that data link identification is determined via group signalling or by prior agreement.
NOTE 2: Group signalling is defined in appendix II of CCITT Recommendation Q.922 [8].
The functions of DL-CORE, used to support the Frame Relay service, are considered to be:
- frame delimiting, alignment and transparency;
- frame multiplexing/demultiplexing using the address field;
- inspection of the frame to ensure that it consists of an integral number of octets prior to zero bit
insertion or following zero bit extraction;
- inspection of the frame to ensure that it is neither too long nor too short;
- detection of (but not recovery from) transmission errors; and
- congestion control functions.
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest
edition of the publication referred to applies.
[1] ETS 300 399-1 (1995): "Frame relay services; Part 1: General description".
[2] ETS 300 402-1: "Integrated Services Digital Network (ISDN); Digital Subscriber
Signalling System No. one (DSS1) protocol; Data link layer; Part 1: General
aspects [ITU-T Recommendation Q.920 (1993), modified]".
[3] ETS 300 402-2: "Integrated Services Digital Network (ISDN); Digital Subscriber
Signalling System No. one (DSS1) protocol; Data link layer; Part 2: General
protocol specification [ITU-T Recommendation Q.921 (1993), modified]".
[4] ITU-T Recommendation I.122 (1993): "Framework for frame bearer services".

---------------------- Page: 9 ----------------------

SIST ETS 300 402-3:1998
Page 8
ETS 300 402-3: August 1996
[5] ITU-T Recommendation I.233 (1993): "Frame mode bearer service".
[6] ITU-T Recommendation I.320 (1993): "ISDN protocol reference model".
[7] CCITT Recommendation I.370 (1991): "Congestion management for the ISDN
frame relaying bearer service".
[8] CCITT Recommendation Q.922 (1992): "ISDN data link layer specification for
frame mode bearer services".
[9] ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1 (1994): "Information
technology - Open Systems Interconnection - Basic reference model: The basic
model".
[10] ITU-T Recommendation X.210 (1993) | ISO/IEC 10731 (1994): "Information
technology - Open systems interconnection - Basic reference model:
Conventions for the definitions of OSI services".
[11] CCITT Recommendation X.211 (1988): "Physical service definition of open
systems interconnection for CCITT applications".
[12] ISO/IEC 8885 (1993): "Information technology - Telecommunications and
information exchange between systems - High-level data link control (HDLC)
procedures - General purpose XID frame information field content and format".
3 Abbreviations
For the purposes of this ETS, the following abbreviations apply:
BECN Backward Explicit Congestion Notification
C-plane Control plane
C/R Command/Response field bit
CEI Connection Endpoint Identifier
CLLM Consolidated Link Layer Management
D/C DLCI or DL-CORE control indicator
DE Discard Eligibility indicator
DL Data Link (layer)
DL- communication between layer 3 and data link layer
DL-CORE Data Link Core protocol
DL-CORE- communication between the DL-CORE user and DL-CORE
DLCI Data Link Connection Identifier
EA Address field Extension bit
FECN Forward Explicit Congestion Notification
FCS Frame Check Sequence
HDLC High-level Data Link Control
ISDN Integrated Services Digital Network
LAN Local Area Network
LAPD Link Access Procedure on the D-channel
LAPF Link Access Procedure for Frame mode bearer services
M2N- communication between layer 3 and layer 2 management entities
MC- communication between DL-CORE and layer 2 management
MDL- communication between layer 2 management and data link layer
OSI Open Systems Interconnection
PH Physical (layer)
PH- communication between data link layer and physical layer
PDU Protocol Data Unit
SAP Service Access Point
SAPI Service Access Point Identifier
TEI Terminal Endpoint Identifier
U-plane User plane
XID eXchange IDentification

---------------------- Page: 10 ----------------------

SIST ETS 300 402-3:1998
Page 9
ETS 300 402-3: August 1996
4 Frame structure for peer-to-peer communication
4.1 General
All data link layer peer-to-peer exchanges are in frames conforming to the format shown in figure 1 (other
3 or 4 octet address formats are available).
Bits Octet
8 7 6 543 21
Flag 1
0 1 1 111 10
high order octet of address field 2
low order octet of address field 3
4
Frame Relay Information field
N-3
FCS 1st octet N-2
FCS 2nd octet N-1
Flag
0 1 1 111 10 N
Figure 1: Frame Relay frame format with two octet address
4.2 Flag sequence
All frames shall start and end with the flag sequence consisting of one "0" bit followed by six contiguous
"1" bits and one "0" bit. The flag preceding the address field is defined as the opening flag. The flag
following the Frame Check Sequence (FCS) field is defined as the closing flag. The closing flag may also
serve as the opening flag of the next frame, in some applications. However, all receivers shall be able to
accommodate receipt of one or more consecutive flags.
Flags shall be used as interframe fill (on channels other than D-channels).
4.3 Address field
The address field shall consist of at least two octets as illustrated in figure 1 but may optionally be
extended up to 4 octets. The format of the address field is defined in subclause 5.2.
4.4 Control field
A control field, as seen by the DL-CORE sublayer, does not exist in a Frame Relay frame structure.
4.5 Frame Relay information field
The Frame Relay information field of a frame, when present, follows the address field (see subclause 5.2)
and precedes the frame check sequence field (see subclause 4.7). The contents of the Frame Relay
information field shall consist of an integral number of octets.
The maximum number of octets in the Frame Relay information field is defined in clause 7.

---------------------- Page: 11 ----------------------

SIST ETS 300 402-3:1998
Page 10
ETS 300 402-3: August 1996
4.6 Transparency
A transmitting data link layer entity shall examine the frame content between the opening and closing flag
sequences, (address, information and FCS fields) and shall insert a "0" bit after all sequences of five
contiguous "1" bits (including the last five bits of the FCS) to ensure that a flag or an abort sequence is not
simulated within the frame. A receiving data link layer entity shall examine the frame contents between the
opening and closing flag sequences and shall discard any "0" bit which directly follows five contiguous "1"
bits.
4.7 Frame Checking Sequence (FCS) field
The definition and use of the FCS is specified in subclause 2.7 of ITU-T Recommendation Q.921 as
modified by ETS 300 402-2 [3].
4.8 Format convention
The definition of formats and numbering conventions is specified in subclause 2.8 of ITU-T
Recommendation Q.921 as modified by ETS 300 402-2 [3].
4.9 Invalid frames
An invalid frame is a frame which:
a) is not properly bounded by two flags; or
b) has fewer than three octets between the address field (as defined in subclause 5.2) and the closing
flag; or
c) does not consist of an integral number of octets prior to "0" bit insertion or following "0" bit
extraction; or
d) contains a frame check sequence error; or
e) contains a single octet address field or an address field too long i.e. the extension address (EA) bit
set to "0" instead of "1" in the last octet of the address; or
f) contains a Data Link Connection Identifier (DLCI) which is not supported by the receiver.
Invalid frames shall be discarded without notification to the sender. No action is taken as the result of
invalid frames.
If a frame which is too long is received by the network, the network may:
- discard the frame (see note); or
- send the complete frame toward the destination user with a valid FCS.
NOTE: This approach implies that the implementation of the Frame Relay protocol cannot
exploit the capabilities to discriminate among corrupted or too long frames.
Selection of one or more of these behaviour is an option for designers of Frame Relay network equipment
and is not subject to further standardization. Users shall not make any assumption as to which of these
actions the network will take. In addition, the network may optionally clear the Frame Relay call if the
number or frequency of too long frames exceeds a network specified threshold.
4.10 Frame abort
The definition of and the reaction to frame aborts is specified in subclause 2.10 of ITU-T
Recommendation Q.921 as modified by ETS 300 402-2 [3].

---------------------- Page: 12 ----------------------

SIST ETS 300 402-3:1998
Page 11
ETS 300 402-3: August 1996
5 Elements of procedures and formats of fields for the DL-CORE services
sublayer
5.1 General
The elements of procedures contained in this ETS are used by the DL-CORE service sublayer to
implement optional procedures for congestion management which are found in clause 8.
5.2 Address field format
The format of the address field is shown in figure 2. This field includes the address field extension bits, a
bit reserved for use by end user equipment intended to support a command/response indication, forward
and backward congestion notification bits, discard eligibility indication, an indicator for DLCI or DL-CORE
control interpretation of a 3 or 4 octet "address field" and a DLCI field. The minimum and default length of
the address field is 2 octets and it may be extended to 3 or 4 octets to support a larger DLCI address
range or to support the optional DL-CORE control functions. The 3 octet or 4 octet address field formats
may be supported at the user-network interface or the network-network interface based on bilateral
agreement.
In each channel, the frames shall have the same length for the address field.
Default 87 65 432 1
Address (upper DLCI) * EA
Field 0
Format (lower DLCI) FECN BECN DE EA
(2 octets) 1
or
87 65 432 1
3 octet (upper DLCI) * EA
Address 0
Field DLCI FECN BECN DE EA
Format 0
(lower DLCI) or D/C EA
DL-CORE control 1
or
87 65 432 1
(upper DLCI) * EA
4 octet 0
Address DLCI FECN BECN DE EA
Field 0
Format DLCI EA
0
(lower DLCI) or D/C EA
DL-CORE control 1
D/C = DLCI or DL-CORE control indicator (see subclause 5.3.7)
DE = Discard Eligibility Indicator (see subclause 5.3.5)
EA = Address Field Extension Bit (see subclause 5.3.1)
* = Bit intended to support a command/response indication. The coding is application specific
(see subclause 5.3.2)
FECN= Forward Explicit Congestion Notification (see subclause 5.3.3)
BECN= Backward Explicit Congestion Notification (see subclause 5.3.4)
DLCI = Data Link Connection Identifier (see subclause 5.3.6)
Figure 2: Address field format

---------------------- Page: 13 ----------------------

SIST ETS 300 402-3:1998
Page 12
ETS 300 402-3: August 1996
5.3 Address field variables
5.3.1 Address field extension bit (EA)
The address field range is extended by reserving the first transmitted bit of the address field octets to
indicate the final octet of the address field. The presence of a "0" in the first bit of an address field octet
signals that another octet of the address follows this one. The presence of a "1" in the first bit of an
address field octet signals that it is the final octet of the address field. For example, the two octet address
field has bit one of the first octet set to "0" and bit one of the second octet set to "1".
5.3.2 Command/Response bit (C/R)
The C/R bit is not used by the DL-CORE protocol. The coding is application specific. The C/R bit is
conveyed transparently by the DL-CORE protocol between DL-CORE services users.
5.3.3 Forward Explicit Congestion Notification (FECN)
This bit may be set by a congested network to notify the user that congestion avoidance procedures
should be initiated where applicable for traffic in the direction of the frame carrying the FECN indication.
This bit is set to "1" to indicate to the receiving end-system that the frames it receives have encountered
congested resources. This bit may be used by destination controlled transmitter rate adjustment.
While setting this bit by the network or user is optional, no network shall ever clear (set to "0") this bit.
Networks that do not provide FECN shall pass this bit unchanged. An example of the use of this bit is
contained in appendix I of CCITT Recommendation Q.922 [8].
5.3.4 Backward Explicit Congestion Notification (BECN)
This bit may be set by a congested network to notify the user that congestion avoidance procedures
should be initiated, where applicable for traffic in the opposite direction of the frame carrying the BECN
indicator. This bit is set to "1" to indicate to the receiving end-system that the frames it transmits may
encounter congested resources. This bit may be used by source controlled transmitter rate adjustment.
While setting this bit by the network or user is optional, no network shall ever clear (set to "0") this bit.
Networks that do not provide BECN shall pass this bit unchanged. An example of the use of this bit is
contained in appendix I of CCITT Recommendation Q.922 [8].
5.3.5 Discard Eligibility indicator (DE)
This bit, if used, is set to "1" to indicate a request that a frame should be discarded in preference to other
frames in a congestion situation. Setting of this bit by the network or user is optional. No network shall
ever clear (i.e. set to "0") this bit. Networks that do not provide DE shall pass this bit unchanged. Networks
are not constrained to discard only frames with DE = 1 in the presence of congestion.
5.3.6 Data Link Connection Identifier (DLCI)
The DLCI identifies a virtual connection on a channel (e.g. D-channel, B-channel, or n × 64 kbit/s) at a
user-network interface. In consequence, a DLCI specifies a Core data link layer entity to/from which
information is delivered/received and which is to be carried in frames by data link layer entities. The DLCI
field may be either unstructured or structured. In the former case, the least significant bit is determined as
shown in table 1.
Table 1: Least significant bit determination
Address field size D/C = 0 D/C = 1
2 octets see note see note
3 octets bit 3 of octet 3 bit 5 of octet 2
4 octets bit 3 of octet 4 bit 2 of octet 3
NOTE: Not applicable; least significant DLCI bit is bit 5 of octet 2.

---------------------- Page: 14 ----------------------

SIST ETS 300 402-3:1998
Page 13
ETS 300 402-3: August 1996
A structure to the DLCI field may be established by the network at the user to network interface subject to
negotiation or bilateral agreement.
For notation purposes, the six most significant bits (bit
...