SIST ETS 300 402-3:1998
(Main)Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Data link layer; Part 3: Frame relay protocol specification
- Abstract
ISDN User-network Layer 2 signalling protocol for Frame Relay Bearer Services. Protocol to be used in order to support the data transfer phase of the Frame Relay Bearer Service in an ISDN
- Status
- Published
- Publication Date
- 31-May-1998
- Technical Committee
- SPS - Signalling protocols and switching
- Current Stage
- 6060 - National Implementation/Publication (Adopted Project)
- Start Date
- 01-Jun-1998
- Due Date
- 01-Jun-1998
- Completion Date
- 01-Jun-1998
SIST ETS 300 402-3:1998 is the Slovenian adoption of ETS 300 402-3 Edition 1 for the Integrated Services Digital Network (ISDN) Digital Subscriber Signalling System No. one (DSS1) data link layer, Part 3: Frame relay protocol specification. It specifies the user-network layer 2 signalling and frame relay procedures used to support the data transfer phase of the Frame Relay Bearer Service in an ISDN. Engineers implementing ISDN frame relay connections, and testers checking those interfaces, use it to define the frame format, the DL-CORE procedures, and the congestion signalling methods.
What does SIST ETS 300 402-3:1998 specify?
SIST ETS 300 402-3:1998 specifies the Frame Relay layer 2 protocol used for ISDN Frame Relay Bearer Services. It covers the frame structure, field formats, procedures, and congestion control needed for DL-CORE operation.
The document is organized into:
- Scope
- Normative references
- Abbreviations
- Frame structure for peer-to-peer communication
- Elements of procedures and formats of fields for the DL-CORE services sublayer
- Placement of the DL-CORE sublayer protocol in the ISDN protocol architecture
- List of system parameters
- Congestion control procedures
- Annex A on the Consolidated Link Layer Management (CLLM) message
Annex A is normative and gives the congestion message format and its parameter fields.
| Annex | What it covers |
|---|---|
| Annex A | CLLM message format, fields, and congestion-node action |
What are the key requirements of SIST ETS 300 402-3:1998?
SIST ETS 300 402-3:1998 defines a frame-based Layer 2 protocol with a fixed peer-to-peer format, mapped service primitives, and explicit congestion signalling. In practice, this means implementers need to match the frame layout, the address coding, the management procedures, and the congestion behavior at the interface.
Frame format and transparency
Clause 4 requires every peer-to-peer exchange to use frames bounded by opening and closing flags. The frame contains an address field, an optional information field, and an FCS, while the DL-CORE view has no separate control field.
Clause 4.6 requires zero-bit insertion on transmission and removal on reception to prevent false flag or abort patterns inside the frame. This matters because interoperability depends on both ends handling bit transparency in the same way.
Address field and DLCI coding
Clause 5.2 defines a two-octet address field as the default, with optional extension to three or four octets. The extra length supports a larger Data Link Connection Identifier (DLCI) range and, where used, DL-CORE control information.
Clause 5.3.6 makes the DLCI the identifier of the virtual connection on a channel such as B-channel, D-channel, or n × 64 kbit/s. The standard also assigns DLCI ranges to user information, logical link identification, and layer 2 management, so designers must choose values that fit the intended function.
Clause 5.3.7 introduces the DLCI/DL-CORE control indicator (D/C) in the last octet of the extended address. In practice, this bit tells the receiver whether the remaining bits are DLCI bits or reserved DL-CORE control bits.
Congestion indicators
Clause 5.3.3 defines Forward Explicit Congestion Notification (FECN), and clause 5.3.4 defines Backward Explicit Congestion Notification (BECN). These bits are used to warn the destination or the source that congestion has been encountered, so equipment can reduce load rather than keep sending at the same rate.
Clause 5.3.5 defines the Discard Eligibility indicator (DE). When set, it marks frames that may be dropped first during congestion, which helps operators prioritize traffic.
Invalid frames and error handling
Clause 4.9 defines several forms of invalid frames, including frames that are not correctly bounded, are too short, have octet alignment problems, contain FCS errors, have a bad address format, or use an unsupported DLCI. Invalid frames are discarded without notification, so implementations should not expect link-layer recovery for those cases.
The same clause notes that the handling of overlong frames can vary by network design. For buyers and integrators, that means equipment behavior on oversize traffic should be checked during interoperability testing.
Service primitives and management
Clause 6 places DL-CORE in the ISDN protocol architecture and splits the user-plane layer 2 into a DL-CONTROL sublayer and a DL-CORE sublayer. It also defines the management primitives used to assign and remove DLCI mappings, including MC-ASSIGN, MC-REMOVE, M2N-ASSIGN, M2N-REMOVE, MDL-ASSIGN, and MDL-REMOVE.
This matters in deployment because connection setup and release are handled by coordinated layer 3 and layer 2 management actions, not by frame exchange alone. The document also maps DL-CORE-DATA user information, discard eligibility, congestion indicators, and protocol control information to specific frame fields.
System parameter and congestion behavior
Clause 7 defines the maximum number of octets in a Frame Relay information field, called N203. The default is 262 octets, and negotiated larger values may be used, with support for at least 1 600 octets strongly recommended for LAN interconnection use cases.
Clause 8 separates congestion control into implicit detection and explicit notification. Explicit notification uses FECN, BECN, or the optional CLLM message, and the user is expected to respond by rate reduction.
What terms does SIST ETS 300 402-3:1998 define?
- Data Link Core protocol (DL-CORE) - The subset of LAPF used here to support the Frame Relay service at layer 2.
- Data Link Connection Identifier (DLCI) - The identifier that selects a virtual Frame Relay connection on a channel.
- Forward Explicit Congestion Notification (FECN) - A bit used to tell the receiving side that congestion was encountered in the forward direction.
- Backward Explicit Congestion Notification (BECN) - A bit used to tell the sending side that congestion may affect traffic in the reverse direction.
- Discard Eligibility indicator (DE) - A bit that marks a frame as a preferred discard candidate during congestion.
- Consolidated Link Layer Management (CLLM) - A management message used to report congestion and list congested DLCIs.
- Connection Endpoint Identifier (CEI) - The identifier used to uniquely identify a DL-CORE connection or a DL connection, depending on context.
- Command/Response bit (C/R) - The bit in the address field reserved for command/response use, carried transparently by DL-CORE.
Who uses SIST ETS 300 402-3:1998?
SIST ETS 300 402-3:1998 is used by telecom equipment designers, ISDN switch and access-network engineers, and vendors implementing Frame Relay bearer services. It is also used by interoperability and conformance test teams checking frame format, DLCI mapping, connection setup and release, and congestion handling.
Network operators and integrators use it when configuring ISDN Frame Relay links on B-channel, D-channel, or n × 64 kbit/s paths. Quality managers and buyers use it to confirm that equipment supports the required layer 2 behavior for a Frame Relay service.
What changed in SIST ETS 300 402-3:1998 from the previous edition?
SIST ETS 300 402-3:1998 corresponds to ETS 300 402-3 Edition 1, the first edition of the ETSI document.
Which standards are used with SIST ETS 300 402-3:1998?
The document cites these standards and recommendations as normative references or companion parts:
- ETS 300 399-1 - General description of Frame Relay services, which provides the service context for this protocol part.
- ETS 300 402-1 - General aspects of the DSS1 data link layer, used as the companion base for the series.
- ETS 300 402-2 - General protocol specification for the DSS1 data link layer, including the referenced FCS and format conventions.
- ITU-T Recommendation I.122 - Framework for frame bearer services, referenced in the CLLM parameter set identification.
- ITU-T Recommendation I.233 - Frame mode bearer service, which provides the DL-CORE service description and parameters.
- ITU-T Recommendation I.320 - ISDN protocol reference model, used for the architectural placement of DL-CORE.
- CCITT Recommendation I.370 - Congestion management for the ISDN frame relaying bearer service, used for the congestion-control approach.
- CCITT Recommendation Q.922 - ISDN data link layer specification for frame mode bearer services, the main technical basis for this part.
- ITU-T Recommendation X.200 / ISO/IEC 7498-1 - The OSI basic reference model, used for the layered model terminology.
- ITU-T Recommendation X.210 / ISO/IEC 10731 - OSI service conventions, used for the primitive-based layer interaction model.
- CCITT Recommendation X.211 - Physical service definition, used for the physical layer assumptions.
- ISO/IEC 8885 - HDLC XID frame information field content and format, used for the CLLM message structure.
What does the SIST ETS 300 402-3:1998 document contain?
The document contains frame layouts, address-field formats, primitive mappings, management procedures, and congestion-control rules for DL-CORE operation. Figure 1 shows the basic Frame Relay frame format, and Figure 2 shows the 2-, 3-, and 4-octet address-field options.
Clause 6 includes tables and message-flow figures that relate layer 3, layer 2 management, DL-CONTROL, DL-CORE, and layer 1 primitives during connection establishment and release. Clause 7 gives the system parameter N203, and clause 8 describes how networks and users handle congestion notifications.
Annex A provides the full CLLM message structure, including its XID framing, parameter fields, and the list of cause values used by the congested node. It also explains how the message identifies congested DLCIs and how a congested node may signal both the network ingress and the source side.
Get Certified
Connect with accredited certification bodies for this standard
BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.
NYCE
Mexican standards and certification body.
ANCE
Mexican certification and testing association.
Sponsored listings
Frequently Asked Questions
SIST ETS 300 402-3:1998 is a standard published by the Slovenian Institute for Standardization (SIST). Its full title is "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Data link layer; Part 3: Frame relay protocol specification". This standard covers: ISDN User-network Layer 2 signalling protocol for Frame Relay Bearer Services. Protocol to be used in order to support the data transfer phase of the Frame Relay Bearer Service in an ISDN
ISDN User-network Layer 2 signalling protocol for Frame Relay Bearer Services. Protocol to be used in order to support the data transfer phase of the Frame Relay Bearer Service in an ISDN
SIST ETS 300 402-3:1998 is classified under the following ICS (International Classification for Standards) categories: 33.080 - Integrated Services Digital Network (ISDN); 35.100.20 - Data link layer. The ICS classification helps identify the subject area and facilitates finding related standards.
SIST ETS 300 402-3:1998 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
SLOVENSKI STANDARD
01-junij-1998
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL ,6'1 3URWRNROGLJLWDOQHQDURþQLãNH
VLJQDOL]DFLMHãW '66 3RGDWNRYQDSRYH]RYDOQDSODVWGHO 6SHFLILNDFLMD
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
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: secretariat@etsi.fr
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
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 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 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 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 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 6
ETS 300 402-3: August 1996
Blank page
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 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 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
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 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 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
(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 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 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 (bits 8 to 3) in the first octet of the address field are
referred to as the upper DLCI.
The DLCI has a default length of 10 bits. The extension bit may be used to optionally increase the length
to 16 bits or 17 bits or 23 bits, as shown in figure 2.
Table 2 shows the ranges of DLCI values which apply for specific functions to ensure compatibility. As
described in subclause 5.3.7, the D/C indication may affect the length of the DLCI.
Table 2: Use of DLCIs
DLCI range Function
10 bit DLCIs (note 1)
0 (note 2) In channel signalling, if required
1 - 15 Reserved
16 - 511 On non D-channel, available for support of user information
512 - 991 Logical link identification for support of user information
992 - 1 007 Layer 2 management of Frame Relay service
1 008 - 1 022 Reserved
1 023 (note 2) In channel layer 2 management, if required
16 bit DLCIs (note 3)
0 (note 2) In channel signalling, if required
1 - 1 023 Reserved
1 024 - 32 767 On non D-channel, available for support of user information
32 768 - 63 487 Logical link identification for support of user information
63 488 - 64 511 Layer 2 management of Frame Relay service
64 512 - 65 534 Reserved
65 535 (note 2) In channel layer 2 management, if required
17 bit DLCIs (note 4)
0 (note 2) In channel signalling, if required
1 - 2 047 Reserved
2 048 - 65 535 On non D-channel, available
...