ITU-T V 76-1996 Generic Multiplexer Using V 42 LAPM-Based Procedures - Series V Data Communication over the Telephone Network Interfaces and Voiceband Modems《使用V 42建议、基于LAPM规程的一般多路.pdf

《ITU-T V 76-1996 Generic Multiplexer Using V 42 LAPM-Based Procedures - Series V Data Communication over the Telephone Network Interfaces and Voiceband Modems《使用V 42建议、基于LAPM规程的一般多路.pdf》由会员分享，可在线阅读，更多相关《ITU-T V 76-1996 Generic Multiplexer Using V 42 LAPM-Based Procedures - Series V Data Communication over the Telephone Network Interfaces and Voiceband Modems《使用V 42建议、基于LAPM规程的一般多路.pdf（57页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL TELECOMMUNICATION UN ION ITU=T TELECOMMUNICATION STAN DARD I ZATION SECTOR OF ITU SERIES V: DATA COMMUNICAT TELEPHONE NETWORK Interfaces and voiceband modem! V.76 (08196) ON OVER THE Generic multiplexer using V.42 LAPM-based procedures ITU-T Recommendation V.76 (Previously “CCITT Recom

2、mendation“) STD*ITU-T RECMN V-7b-ENGL L77b M qAb2591 Ob24374 514 = ITU-T V-SERIES RECOMMENDATIONS DATA COMMUNICATION OVER THE TELEPHONE NETWORK - 1 - General 3 - Widebandmodems 4 - Errorcontrol 5 - Transmission quality and maintenance 6 - Interworking with other networks For ficrther details, please

3、 refir to ITU-T List of Recommendations. FOREWORD The ITU-T (Telecommunication Standardization Sector) is a permanent organ of the International Telecommunication Union (ITU). The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommen- dations on them with a

4、 view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their tuni, produce Recommendations on these topics. The approval of Recom

5、mendations by the Members of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1 (Helsinki, March 1-12,1993). ITU-T Recommendation V.76 was prepared by ITU-T Study Group 14 (1993-1996) and was approved under the WTSC Resolution No. 1 procedure on the 16th of August 1996. NOTE 1

6、telecommunication administration and a recognized operating agency. In this Recommendation, the expression “Administration” is used for conciseness to indicate both a 2 follows: The status of annexes and appendices attached to the Series V Recommendations should be interpreted as - - an annex to a R

7、ecommendation forms an integral part of the Recommendation; an appendix to a Recommendation does not form part of the Recommendation and only provides some complementary explanation or information specific to that Recommendation. O ITU 1997 All rights reserved. No part of this publication may be rep

8、roduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. Recommendation V.76 (08/96) 1 1 2 3 4 5 6 7 8 9 10 11 CONTENTS Scope 1.1 General 1.2 Definitions Abbreviations . Relationship to other internat

9、ional standards and Recommendations Overview of multiplexing operation and services 4.1 General 4.2 Overview ofthe Service User (SU) 4.3 4.4 Overview of the Multiplexing Function (MF) Communication between the SU and the MF Multiplexing platform and fiame structure 5.1 Basic fiame structure and fiel

10、ds 5.2 Format conventions 5.3 Invalid fiames . 5.4 Frame abort . 5.5 Interfiame time fill Elements of procedure and field formats . 6.1 Address field format . 6.2 Control field format 6.3 Control field parameters and associated state variables 6.5 Use of timers . DLC procedures . 7.1 Establishment o

11、f a data link connection . 7.2 Information transfer 7.3 Orderly release of a DLC 7.4 Disconnected state 7.5 Collision of unnumbered commands and responses . 7.7 Loop-back test Information transfer modes 8.1 Error recovery mode . 8.2 Unacknowledged non-error recovery mode . 8.3 Transfer of user-contr

12、ol information 8.4 Additional information-transfer procedures . System parameters ofthe multiplex iunction . 9.1 Acknowledgement timer (T401) . 9.2 Maximum number of retransmissions cN400) 9.3 Maximum number of octets in an information field (N401) . 9.4 Window size (k) 9.5 9.6 9.7 DLCI values 6.4 F

13、rame types . 7.6 Exchange identification procedures Reply delay timer (T402) - Optional Inactivity timer (T403) - Optional 9.8 Operational mode Negotiation of optional procedures Recommendation V.76 (08196) Page 1 1 1 1 1 2 2 3 3 4 5 5 7 8 9 9 9 9 10 11 12 16 16 17 19 19 20 20 20 21 21 21 28 28 28 3

14、1 31 31 31 32 32 32 32 32 32 . STD*ITU-T RECMN VJb-ENGL L77b 48b257L Ob24377 223 Annex A . Optional suspendlresume operation A . 1 Introduction A.2 Abbreviations A.3 Operation of suspend/resume A.4 Error conditions with suspendresume AS Interoperability of suspendresume with basic frame format A.6 E

15、rror-recovery performance . Annex B - Procedures and encoding for conveying break signals . Procedures for transfer of break signais . Encoding of break information . B.l B.2 Annex C - Parameter values and optional procedures for operation with Recommendation V.70 Appendix I - Data retransmission .

16、Introduction . I . 1 Appendix II - Additions for “Unnumbered information with header check” feature . II . 1 Introduction i . 11.2 Abbreviations 11.3 Changes for ULH feature . Appendix III - Cross-reference between Recommendations V.76 and V.42 Page 33 33 33 33 35 31 37 31 37 39 41 42 42 46 46 46 46

17、 48 Recommendation V.76 (08/96) . 111 STD-ITU-T RECMN V.7b-ENGL 1996 m 48b257L 062Li378 LbT m r Y STD-ITU-T RECMN V-7b-ENGL 177b 48b257L Ub2q377 OTb Recommendation V.76 GENERIC MULTIPLEXER USING V.42 LAPM-BASED PROCEDURES (Geneva, 1996) 1 Scope 1.1 General This Recommendation describes a set of proc

18、edures for use between peer stations for multiplexing multiple streams of information at the same time. These procedures are based on V.42 LAPM procedures but are independent of the application requiring multiplexing support. They provide two basic information-transfer modes known as Error Recovery

19、Mode (ERM) and Unacknowledged Non Error-Recovery Mode (UNERM). For each stream, an information-transfer mode is chosen independently of those selected for other streams; other characteristics can also be chosen in the same fashion. All streams use a common multiplexing platform. 1.2 Relationship to

20、other international standards and Recommendations The protocol defined in this Recommendation can be specified in terms of the High-Level Data Link Control (HDLC) formats and procedures. In particular, it makes use of the balanced asynchronous class (BAC) of HDLC procedures with the HDLC “optional f

21、unctions” (1,2,4,7, 8, 10, 18 and 19 for the basic features and 3.1,3.3, 12, 14 and 20 as optional features). 2 Definitions The following terms are used in this Recommendation as defined here: 2.1 initiator: A role taken on by a Multiplexing Function (MF) that determines how it operates for various

22、functions. The information to determine that a station takes on this role is provided to the MF by means not specified in this Recommendation. The two stations involved in an instance of communication take on opposite roles. 2.2 responder: A role taken on by a Multiplexing Function (MF) that determi

23、nes how it operates for various functions. The information to determine that a station takes on this role is provided to the MF by means not specified in this Recommendation. The two stations involved in an instance of communication take on opposite roles. 3 Abbreviations For the purposes this Recom

24、mendation, the following abbreviations are used. C/R CommandMesponse CRC Cyclic Redundancy Check DCE Data Circuit-Terminating Equipment DISC Disconnect (fiame) DLC Data Link Connection Recommendation V.76 (08/96) 1 DLCI DM DTE EA ERM FCS FMR HDLC I LAPM MF m-SREJ REJ RNR RR SABME SREJ S-SREJ su UA U

25、1 UNERM XID Data Link Connection Identifier Disconnect Mode (frame) Data Terminal Equipment Address Extension Error Recovery Mode Frame Check Sequence Frame Reject (frame) High-Level Data Link Control Information (frame) Link Access Procedure for Modems Multiplexing Function multi-Selective Reject (

26、procedure) Reject (frame) Receive Not Ready (frame) Receive Ready (frame) Set Asynchronous Balanced Mode Extended (fiame) Selective Reject (frame) single-Selective Reject (procedure) Service User Unnumbered Acknowledgement (frame) Unnumbered Information (frame) Unacknowledged Non-Error Recovery Mode

27、 Exchange Identification (frame) 4 Overview of multiplexing operation and services 4.1 General The multiplexing operation described in this Recommendation can be viewed as consisting of two parts: a) a multiplex “platform” that provides a core set of functions of frame delimiting, protection from bi

28、t corruption and multiplexing and demultiplexing of multiple information streams known as Data Link Connections (DLCs); b) one DLC entity per DLC to operate the procedures for setting up a DLC (including negotiatiodindication of appropriate parameters and functions such as selection of ERM or UNERM)

29、; transfer of information in the selected mode; and release of the DLC. 2 Recommendation V.76 (08/96) The above division is depicted in Figure 1. Service User (SU) _ Services provided tl Multiplexing function (MF) DLC-1 (ERMa) . Based on DLCI 1-1 I I Multiplex plaform T1402990-96/601 a) Selection of

30、 an operational mode for one DLC is independant of other selections on other DLCs. FIGURE 1N.76 Division of multiplexing operation The multiplex operations are provided by a Multiplexing Function (MF), which provides the resulting set of services to a “higher layer“ called, for purposes of discussio

31、n here, the Service User (SU). It is the responsibility of the SU to request services of the MF in a meaningful way for a specific application. 4.2 Specification of the SU for specific applications is beyond the scope of this Recommendation. However, it is described here in a generic way so as to pr

32、ovide a context in which the MF provides its services. The SU is responsible for requesting services of the MF. The services that may be requested are: Overview of the Service User (SU) a) establish a DLC between the station and its peer for the purposes of establishing a control channel or transfer

33、ring information as characterized by various parameters - more than one DLC can be established (the maximum number is implementation-dependent); transfer of information in ERM or UNERM; b) c) release of a DLC. The SU shall make known to the MF whether the station is to operate as an initiator or res

34、ponder for various MF procedures. The SU is also responsible for transfemng supervisorykontrol information of two types. The first type affects a specific DLCI (e.g. break for a data channel) and is sent on that DLCI. The second type affects all DLCIs as a whole or is independent of any DLCI (e.g. o

35、rderly release of all DLCIs with one message); it is sent on a DLCI separate from those carrying user information. These SU functions are transparent to the MF. 4.3 Overview of the Multiplexing Function (MF) The multiplexing procedures in this Recommendation provide for: a) b) frame delimiting, alig

36、nment and transparency; provision for multiple DLCs; discrimination between these connections is by means of a Data Link Connection Identifier (DLCI) contained in each fiame; Recommendation V.76 (08/96) 3 c) detection of transmission errors; d) e) f) g) transfer of user information; h) i) j) initial

37、ization and orderly release of a DLC; independent selection of ERM or UNERM for each DLC; negotiatiodindication of parameter values and optional procedures relating to DLC operation; detection of format and operational errors; transparent transfer of higher-layer information or protocols; and when t

38、ransferring information in EM: - recovery from detected transmission, format and operational errors with notification of unrecoverable errors; - sequence control; and - flowcontrol. Types In terms of Figure 1, items a), b) and c) constitute the multiplex platform; the remaining items constitute the

39、operation of each individual DLC. Parametersa) I 4.4 Primitives are specified here for descriptive purposes only to illustrate, in an abstract fashion, how the capabilities of the MF are seen by the SU. The use of primitives is not meant to imply any requirements on implementations. The primitives a

40、re provided in Table 1. Communication between the SU and the MP - request - indication - response - confm - request - indication TABLE 1N.76 Primitives for communication between the SU and MF - user data - mode - userdata I -. I -. . Release a DLC aervice mimitive Establish a DLC between peer SUS L-

41、ESTABLISH L-RELEASE Transfer data in ERM Conduct a loop-back test between SU entities I L-UNITDATA Transfer data in UNERM I L-TEST - request - indication Transfer control information - user data L-SIGN AL Negotiateindicate parameter values and optional procedures L-SETPARM request I I userdata I ind

42、ication request user data indication - request - indication - responseb) - confirmb) - user data 1 - request - indication - response - confirm - user data a Primitives pertain to a specific DLC. Although not specified here as a parameter, a local mechanism is needed to map the DLC b, The need for an

43、d use of the response and confirm forms of the L-SIGNAL primitive depend on the type of control information to a “connection endpoint identifier” understood by the SU. to be transferred. 4 Recommendation V.76 (08/96) - STD-ITU-T RECMN V.7b-ENGL Lb LiAb2591 Ob2Li383 527 m 5 The frame structure and ge

44、neral procedures for basic operation of the MF are specified below. Optional modifications to the basic operation are specified in Annex A and Appendix II. Multiplexing platform and frame structure 5.1 Basic frame structure and fields 5.1.1 Basic frame structure All communications using the basic fr

45、ame format are accomplished using the structure shown in Figure 2. Depending on the fiame type, an information field may also be present in the frame. 8 7 6 5 4 3 2 1 Octet 1 Control (Note 2) I 3 I Information (Note 3) I I FCS (Note 4) I 1 1 1 1 1 1 Closing flag N NOTES 1 The maximum size of this fi

46、eld is limited to two octets. 2 without sequence numbers, see 6.2. 3 4 The control field is two octets for frame types with sequence numbers and one octet for frame types Not ail frame types have an information field. The FCS field can be 8, 16 or 32 bits long. FIGURE 2N.76 Basic frame structure 5.1

47、.2 Flag sequence and transparency All frames using the basic frame structure are delimited by the unique bit pattern “O1 1 1 11 lo”, known as a flag. The flag preceding the address field is defined as the opening flag. The flag following the frame check sequence field is defined as the closing flag.

48、 The closing flag of one frame may also serve as the opening flag of the next fiame. Transparency is maintained by the transmitters examining the frame content between the opening and closing flags and inserting a “o” bit after all sequences of five contiguous “1” bits. The receiver examines the fia

49、me content between the opening and closing flags and discards any “0” bit that directly follows five contiguous “1” bits. 5.1.3 Address field The primary purpose of the address field is to identify, by means of a DLCI, an individual stream of information and the DLC entity associated with it. The format of this field is defined in 6.1. Recommendation V.76 (08/96) 5 STD*ITU-T RECMN V.7b-ENGL L77L 48b257L b24384 4b3 5.1.4 Control field The control field is used to distinguish between different frame types. This field is further described in 6