ITU-T Q 922-1992 ISDN Data Link Layer Specification for Frame Mode Bearer Services《帧方式承载业务的ISDN数据链路层规程(第11研究组)112页》.pdf

《ITU-T Q 922-1992 ISDN Data Link Layer Specification for Frame Mode Bearer Services《帧方式承载业务的ISDN数据链路层规程(第11研究组)112页》.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 922-1992 ISDN Data Link Layer Specification for Frame Mode Bearer Services《帧方式承载业务的ISDN数据链路层规程(第11研究组)112页》.pdf（112页珍藏版）》请在麦多课文档分享上搜索。

1、CCITT RECMN*Q-922 92 m 4862593 0573967 524 m INTERNA IONAL TELECOMMUNICATION UN CCITT THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE DIGITAL SUBCRIBER SIGNALLING SYSTEM No. 1 (DSS 1) DATA LINK LAYER ON Q .922 ISDN DATA LINK LAYER SPECIFICATION FOR FRAME MODE BEARER SERVICES Recomme

2、ndation Q.922 Geneva, 1992 CCITT RECMN*Q*722 72 M 4862573 0573768 460 = INTERNATIONAL TELECOMMUNICATION UNION CCITT THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE DIGITAL SUBCRIBER SIGNALLING SYSTEM No. 1 (DSS 1) DATA LINK LAYER Q .922 ISDN DATA LINK LAYER SPECIFICATION FOR FRAME M

3、ODE BEARER SERVICES Recommendation Q.922 Geneva, 1992 - .- _ _ - . CCITT RECMN*Q.922 92 m YBb259L 0573969 3T7 m FOREWORD The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the International Telecommunication Union (ITU). CCW is responsible for studyi

4、ng technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The Plenary Assembly of CCIT which meets every four years, establishes the topics for study and approves Recommendations prepared by its Study Groups

5、. The approval of Recommendations by the members of CCITF between Plenary Assemblies is covered by the procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988). Recommendation Q.922 was prepared by Study Group XI and was approved under the Resolution No. 2 procedure on the 4th of February 199

6、2. CCIT NOTE In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication Administration and a recognized private operating agency. O ITU 1992 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any

7、means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. CCITT RECflNw2.922 92 = 4862591 0573970 O19 Recommendation Q.922 ISDN DATA LINK LAYER SPECIFICATION FOR FRAME MODE BEARER SERVICES CONTENTS 1 Generai 2 Frame structure for peer-to-peer

8、communication Elements of procedures and formats of fields for data link layer peer-to-peer communication 3 4 Elements of layer-to-layer communication 5 Definition of the peer-to-peer procedures of the data link layer Annex A - Core aspects of Recommendation Q.922 for use with frame relaying bearer

9、service Annex B - SDL for point-to-point procedures Appendix I - Responses to network congestion Appendix II - Signalling configurations Appendix III - Automatic negotiation of data link layer parameters Appendix IV - A convergence protocol to provide OS1 CONS above Recommendation Q.922 Appendix V -

10、 Occurrence of MDL-ERROR indication within the basic states Appendix VI - Abbreviations and acronyms used in this Recommendation References Recommendation Q.922 I 1 - - - - -_ CCITT RECNN*d.922 92 LlBb2593 0573973 T55 1 General This Recommendation specifies the frame structure, elements of procedure

11、, format of fields and procedures of the data link layer to support frame mode bearer services in the oser plane as defined in Recommendation 1.233 i. This specification of a data link layer protocol and procedures for fiame mode bearer services is based upon and is an extension of the LAPD (Link ac

12、cess procedure on the D-channel) protocol and procedures defined in Recommendation Q.921 2. The procedures are applicable to, but not restricted to, access a Frame Mode Bearer Service and are also designated link access procedures to frame mode bearer services, or LAPF. A subset of LAPF, correspondi

13、ng to the data link core sublayer (as defined in Recommendation I.233), is used to support the Frame Relaying Bearer service. This subset is named “data link core protocol” (DL-CORE) and is provided in Annex A. The remainder of the LAPF is called the data link control (DL-CONTROL) protocol. The purp

14、ose of the LAPF is to convey data link service data units between DL-service users in the U-plane for frame mode bearer services across the ISDN user-network interface on B-, D- or H-channels. Frame mode bearer connections are established using either procedures specified in Recommenation Q.933 3 or

15、 (for permanent virtual circuits) by subscription. LAW uses a physical layer service, as supported by the 1.430 141 Series Recommendations. EAPF dows for statistical multiplexing of one or more frame mode bearer connections over a single ISDN B-, D- or H-channel by use of LAPF and compatible HDLC pr

16、ocedures. In particular, EAPF is characterized by: - close relationship with the peer-to-peer procedures of LAPD; - symmetric procedural behavior with respect to the user-network interface, thus allowing also direct user-to-user interworking with the network side being passive (or only supporting th

17、e DL-CORE protocol); - a core sublayer comprising the DL-CORE procedures, as given in Annex A; - applicability on any ISDN channel, i.e. on B-, D- or H-channels; - shared use of the D-channel, concurrently with LAPD (see Recommendation Q.921 2); - use of data link connection identifiers (DLCIs) to u

18、niquely identify frame mode virtual links being assigned to the bearer connections multiplexed on a B-, D- or H-channel; - provision of a dedicated DLCI for layer management; - use within a layered protocol suite which allows interworking between: - frame relaying and fiame switching services; - fra

19、me relaying and X.25-based services; - frame switching and X.25-based services. Network layer protocols which provide and support the N-Data-Transfer phase of the OS1 connection oriented network service (CONS - See Recommendation X.213 5) may be conveyed by the service provided by this Recommendatio

20、n. Two such network layer protocols are: - the Data Transfer phase of Recommendation X.25 6, and - the protocol specified in Appendix IV. DLCI assignment is performed using group signalling (as defined in Appendix II) or by subscription or prior agreemen t. The concepts, terminology, overview descri

21、ption of data link functions and procedures and the relationship with other Recommendations are described in general terms in Recommendation 4.920 7. 2 Recommenation 4.922 Note 1 - As stated in Recommendation Q.920 7, the term “data link layer” is used in the main text of this Recommendation. Howeve

22、r, mainly in figures and tables the terms “layer 2” and “L2” are used as abbreviations. Furthermore, the term “layer 3” is used to indicate the layer above the data link layer. Note 2 - Ail references within this document to the “layer management entity” and/or “connection management entity” refer t

23、o tbose entities at the data BI has fewer than three octets between the address field (as defined in $ 3.2) and the closing flag; does not consist of an integral number of octets prior to “0” bit insertion or following “0” bit extraction; Recommendation Q.922 a _- - - _I _. _. - . CCITT RECMN*Q.922

24、92 4862591 0573973 828 d) e) f) contains a frame check sequence error; contains a single octet address fiel: or contains a 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. 2.10 Frame

25、 aborts The definition of and the reaction to frame aborts is as in Recommendation Q.921 2. 3 Elements of procedures and formats of fields for data link layer peer-to-peer communication 3.1 General The elements of procedures define the commands and responses that are used for peer-to-peer communicat

26、ion using the data link layer connections. Procedures are derived from these elements of proceures and are Bescribed in Q 5. 3.2 Addressfieldformat The address field format shown in Figure UQ.922 contains the address field extension bits, a commandresponse indication, 3 bits reserved for forward and

27、 backward explicit congestion notification and discard eligibility (used with frame relaying services per Annex A), a data link connection identifier (DLCI) field and a bit to indicate whether the final octet of a 3 or 4 octet “address field” is lower DLCI or DL-CORE control (see Q 3.3.7) informatio

28、n. The minimum and default length of the adress field is 2 octets and it may be extended to 3 or 4 octets to support a larger DLCI address range or to support optional DL-CORE control functions. The 3-octet and 4-octet address field formats may be supported at the user-network interface or at the ne

29、twork-network interface based on negotiation or bilateral agreement. The support of address fields longer than two octets is an option chosen by bilateral agreement. This option includes distinctions for supporting the address field length varying on an interface basis or on a per chruinel basis. 3.

30、3 Addressfield variables 3.3.1 Address jeld 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 O in the frst bit of an address field octet signals that another

31、octet of the address field 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”. 3.3.2 Co

32、mmandresponse fiel bit (Ch) The C/R bit identifies a frame as either a command or a response. When the frame to be sent is a command frame, the C/R bit shall be set to O. When the fiame to be sent is a response frame, the C/R bit shail be set to 1. 3.3.3 Forward explicit congestion notcation bit (FE

33、CN) This bit is reserved for use with frame relaying service, as described in Annex A an8 Appendix I. 4 Recommendation Q.922 CCITT RECMN*Qm922 92 W 4862591 0573974 764 W FECN BECN (Note) (Note) Default address field format (2 octets) 3 octets address field format 4 octets address field format CIR EA

34、 O DE EA (Note) 1 8 7 6 5 4 3 2 I Upper DLCI DLCI FECN BECN (Note) (Note) Lower DLCI or DL-CORE control Upper DLCI CIR EA O DE EA (Note) O DIC EA 1 Lower DLCI DLCI FECN BECN DE EA (Note) (Note) (Note) O or 8 7 6 5 DLCI 4 3 2 1 EA O Lower DLCI or DL-CORE control 8 7 6 5 4 3 2 1 DIC EA 1 EA Address fi

35、eld extension bit C/R Command response bit FECN Forward explicit congestion notification BECN Backward explicit congestion notification DLCI Data link connection identifier DE Discard eligibility indicator DIC Note - See Annex A and Appendix I for the use of these 3 bits whiche are reserved for cong

36、estion notification signaihg with frame relaying. DLCI or DL-CORE control indicator FIGURE 114.922 Address field formats Recommendation Q.922 5 CCITT RECMN*2.922 92 I 4862573 0573975 bTO I 3.3.4 Backward explicit congestion notification bit (BECN) This bit is reserved for use with fiame relaying ser

37、vice, as described in Annex A and Appendix I. 3.3.5 Discard eligibility indicator (DE) This bit is reserved for use with fiame relaying service, as described in Annex A and Appepndix I. 3.3.6 Data link connection identer (DLCI) The DLCI identifies a virtud connection on a bearer channel (Le. D, B or

38、 H) at a user to network or network to network interface. Consequeniiy, a DLCI specifies a least significant DLCI bit is bit 5 of octet 2. A structure to the DLCI field may be established by the network at the user to network interface or at a network to network interface subject to negotiation or b

39、ilateral agreement. For notation purposes, the 6 most significant bits (bits 8 to 3) in the first octet of the address field (which correspond to the SAP1 field in Recommendation Q.921 2) are referred to as the upper DLCI. Table UQ.922 shows the ranges of DLCI values which apply for specific functio

40、ns to ensure compatibility with operation on a D-channel, which also may use the Q.921 2 protocol. A two octet address field format for this Recommendation is assumed when used on a D-channel. For further study is whether 3 or 4 octet address field formats may be used on a D-channel. 3.3.7 DLCUDLCOR

41、E control indicator (DK) The D/C indicates whether the remaining six usable bits of that octet are to be interpreted as the lower DLCI bits or as DL-CORE control bits. The bit is set to O to indicate that the octet contains DLCI information. This bit is set to 1 to indicate that the octet contains D

42、L-CORE control information. This indicator is limited to use in the last octet of the three or four octet type “address field”. The use of this indication for DL-CORE control is reserved as there have not been any additional control functions defined which need to be carried in the “address field”;

43、this indicator has been added to provide for possible future expansion of the protocol. Note - The optional DL-CORE control field is part of the address field and therefore must not be confused with the control field of an HDLC fiame as defined in Figure UQ.921. 3.4 Controlpeld formats The control f

44、ield identifies the type of frame, which will be either a command or response. The control will contain sequence numbers where applicable. Three types of control field formats are specified: numbered information transfer (I format), supervisory fractions (S format), and unnumbered information transf

45、ers and control functions (U format). The control field formats are shown in Table 2/Q.922. 6 Recommendation Q.922 CCITT RECMN*d.722 72 = 4862591 0573776 537 DLCI range TABLE UQ.922 Use of DLCIs Function 1-15 16-511 512-991 992-1007 1008- 1022 1023 (Note 2) Reserved Network option: on non-D-channels

46、, availabIe for support of user information Logical link identification for support of user information (Note 6) Layer 2 management of frame mode bearer service Reserved In channel layer 2 management, if require$ I DLCI range I Function I O (Note 2) 1-1023 1024-32 767 32768-63 487 63 488-64 51 1 64

47、512-65 534 65 535 (Note 2) In channel signalling, if required Reserved Network option: on non-D-channels, available for support of user information Logical link identification for support of user information (Note 6) Layer 2 management of frame mode bearer service Reserved In channel layer 2 managem

48、ent, if required DLCI range O (Note 2) 1-2047 2048-65 535 65536-126975 126 976-129 023 129024-131 070 131 071 (Note 2) Function In channel signalling, if required Reserved Network option: on non-D-channels, available for support of user information Logical link identification for support of user inf

49、ormation (Note 6) Layer 2 management of frame mode bearer service Reserved In channel layer 2 management, if required DLCI range Note 1 -These DLCIs apply when a 2 octet address field is used or when a 3 octet address field is used with D/C = 1. Note 2 -Only available within non-D-channel. Note 3 -These DLCIs apply for non-D-channels when a 3 octet address field is used with D/C = O. Note 4 - These DLCIs apply for non-D-channels when a 4 octet address field is used with D/C = 1. Note 5 -These DLCIs apply for non-D-channels when a 4 octet addre