Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / nist / oiw / agreemnt / 1993 / 02s_9309.txt < prev next >

Wrap

Text File | 1993-11-05 | 116KB | 4,290 lines

Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 2 - Subnetworks Output from the September 1993 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: Fred Burg, AT&T SIG Editor: Brenda Gray, NIST Part 2 - Subnetworks September 1993 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Lower Layers Special Interest Group (LLSIG) of the Open Systems Environment Implementors' Workshop (OIW). See Procedures Manual for Workshop charter. Text in this part has been approved by the Plenary of the above- mentioned Workshop. This part replaces the previously existing chapter on this subject. Annexes A and B are for information only. Future changes and additions to this version of these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as shaded. ii Part 2 - Subnetworks September 1993 (Stable) Table of Contents Part 2 - Subnetworks . . . . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Normative References . . . . . . . . . . . . . . . . . . 1 2.1 CCITT . . . . . . . . . . . . . . . . . . . . . . . 1 2.2 ISO . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 ANSI . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 Local Area Networks . . . . . . . . . . . . . . . . . . . 4 5.1 IEEE 802.2 Logical Link Control . . . . . . . . . . 4 5.2 IEEE 802.3 CSMA/CD Access Method . . . . . . . . . . 4 5.3 IEEE 802.4 Token Bus Access Method . . . . . . . . . 6 5.4 IEEE 802.5 Token Ring Access Method . . . . . . . . 7 5.5 Fiber Distributed Data Interface (FDDI) . . . . . . 8 5.5.1 Token Ring Media Access Control (MAC, X3.139-1987) . . . . . . . . . . . . . . . 9 5.5.2 Token Ring Physical Layer (PHY, X3.148- 1988) . . . . . . . . . . . . . . . . . . . 9 5.5.3 Physical Layer Media Dependent (PMD, X3.166-1989) . . . . . . . . . . . . . . . 10 6 Wide Area Networks . . . . . . . . . . . . . . . . . . . 10 6.1 CCITT Recommendation X.25 . . . . . . . . . . . . . 10 6.2 ISO 7776 . . . . . . . . . . . . . . . . . . . . . . 10 6.3 ISO 8208 . . . . . . . . . . . . . . . . . . . . . . 11 7 Integrated Services Digital Networks (ISDN) . . . . . . . 11 7.1 Introduction . . . . . . . . . . . . . . . . . . . . 11 7.2 Implementation Agreements . . . . . . . . . . . . . 12 7.2.1 Physical Layer, Basic Access at "U" . . . . 14 7.2.2 Physical Layer, Basic Access at S and T . . 14 7.2.3 Physical Layer, Primary Rate at S, T, and U . . . . . . . . . . . . . . . . . . . . . 14 7.2.4 Data Link Layer, D-Channel . . . . . . . . 15 7.2.5 Signaling . . . . . . . . . . . . . . . . . 15 7.2.6 Data Link Layer B-Channel . . . . . . . . . 15 7.2.7 Packet Layer . . . . . . . . . . . . . . . 16 8 Frame Relay Subnetworks . . . . . . . . . . . . . . . . . 16 iii Part 2 - Subnetworks September 1993 (Stable) 8.1 Introduction . . . . . . . . . . . . . . . . . . . 16 8.2 Relevant Standards . . . . . . . . . . . . . . . . . 16 8.3 Implementation Agreements for User-to-Network Interfaces . . . . . . . . . . . . . . . . . . . . . 16 8.3.1 Physical Layer Interface . . . . . . . . . 16 8.3.1.1 ANS T1.403-1989 . . . . . . . . . . . . . . 17 8.3.1.2 CCITT Recommendation V.35 . . . . . . . . . 17 8.3.1.3 CCITT Recommendation G.703 (2048 kbit/s) . 18 8.3.1.4 CCITT Recommendation G.704 (2048 kbit/s) . 18 8.3.1.5 CCITT Recommendation X.21 (non-switched operation) . . . . . . . . . . . . . . . . 18 8.3.2 Data Transfer . . . . . . . . . . . . . . . 19 8.3.2.1 Section 2.2 Flag sequence . . . . . . . . . 19 8.3.2.2 Section 2.5 Frame relay information field . 19 8.3.2.3 Section 3.3 Address field variables . . . . 20 8.3.2.4 Section 5 Congestion control . . . . . . . 20 8.3.2.5 Section 6 Consolidated link layer management (CLLM) message . . . . . . . . . 21 8.3.3 Control (Signaling) procedures . . . . . . 21 8.3.3.1 Permanent Virtual Connections (PVC) procedures . . . . . . . . . . . . . . . . 21 8.3.3.2 Switched Virtual Connections (SVCs) procedures . . . . . . . . . . . . . . . . 21 Annex A (informative) Cross Reference Between CCITT and ANSI Text Relating to ISDN Agreements . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.1 Data Link Layer, D-Channel . . . . . . . . . . . . . 22 A.2 Signaling . . . . . . . . . . . . . . . . . . . . . 22 Annex B (informative) Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 23 B.1 ANSI . . . . . . . . . . . . . . . . . . . . . . . . 23 B.2 CCITT . . . . . . . . . . . . . . . . . . . . . . . 23 B.3 ISO . . . . . . . . . . . . . . . . . . . . . . . . 23 B.4 OTHER . . . . . . . . . . . . . . . . . . . . . . . 23 Annex C (informative) Cross Reference between CCITT and ANSI Text Relating to Frame Relay Agreements . . . . . . . . . . . . . . . . . . . . . . 24 Annex D (informative) Frame Relay Network-to-Network Interface . . . . . . . . . . 25 D.1 Introduction . . . . . . . . . . . . . . . . . . . . 25 D.1.1 Purpose . . . . . . . . . . . . . . . . . . 25 D.1.2 Definitions . . . . . . . . . . . . . . . . 25 iv Part 2 - Subnetworks September 1993 (Stable) D.2 Relevant Standards . . . . . . . . . . . . . . . . . 25 D.3 Implementation Agreements . . . . . . . . . . . . . 26 D.3.1 Physical Layer Interface Guidelines . . . . 26 D.3.1.1 DS1 Interface (1544 kbit/s) . . . . . . . . 27 D.3.1.2 CCITT Recommendation G.703 (2048 kbit/s) . 28 D.3.1.3 CCITT Recommendation G.704 (2048 kbit/s) . 29 D.3.1.4 High Speed Physical Interfaces . . . . . . 29 D.3.2 Data Transfer . . . . . . . . . . . . . . . 29 D.3.2.1 Interframe Time Fill . . . . . . . . . . . 29 D.3.2.2 Frame Relay Information Field (T1.618 2.5 & Q.922 Annex A A.2.5 & A.5.1) . . . . . 29 D.3.2.3 Address Field Variables . . . . . . . . . . 30 D.3.2.4 Congestion Management . . . . . . . . . . . 30 D.3.2.5 Consolidated Link Layer Management (CLLM) Message (T1.618 6 & Q.922 Annex A A.7) . . . . . 31 D.3.3 Control (Signalling) Procedures . . . . . . 31 D.3.3.1 Permanent Virtual Connection (PVC) Procedures . . . . . . . . . . . . . . . . 31 D.3.3.2 Switched Virtual Connection (SVC) Procedures . . . . . . . . . . . . . . . . 32 D.3.4 Network Performance Parameters . . . . . . 32 D.3.5 PVC Parameter Coordination . . . . . . . . 32 D.4 Application of Bidirectional Procedures for Use at the Network-to-Network Interface . . . . . . . . . . 32 D.4.1 Bidirectional network procedures and multi-network PVCs . . . . . . . . . . . . 32 D.4.2 Polling requirements of network-to-network interfaces . . . . . . . . . . . . . . . . 34 D.4.3 Initial NNI status . . . . . . . . . . . . 36 D.4.4 Multi-network PVC active status criteria . 36 D.4.5 Adding a multi-network PVC . . . . . . . . 37 D.4.6 Deleting a multi-network PVC . . . . . . . 37 D.4.7 Response to UNI failure . . . . . . . . . . 38 D.4.8 Response to PVC segment failure . . . . . . 38 D.4.9 Response to NNI failure . . . . . . . . . . 38 D.4.10 Examples of multi-network PVC status signalling . . . . . . . . . . . . . . . . 38 D . 4 . 1 0 . 1 Generic example comments . . . . . . . . . 38 D . 4 . 1 0 . 2 Nomenclature . . . . . . . . . . . . . . . 40 D . 4 . 1 0 . 3 Example of adding a multi-network PVC . . . 40 D . 4 . 1 0 . 4 Example of deleting a multi-network PVC . . 41 D . 4 . 1 0 . 5 Example of UNI failure and restoration . . 43 D . 4 . 1 0 . 6 Example of PVC segment failure and v Part 2 - Subnetworks September 1993 (Stable) restoration . . . . . . . . . . . . . . . . . . . . . . . 44 D . 4 . 1 0 . 7 Example of NNI failure and restoration . . 45 vi Part 2 - Subnetworks September 1993 (Stable) List of Figures Figure 1 - LSAP bit pattern . . . . . . . . . . . . . . . . . 4 Figure 2 - I-Field format . . . . . . . . . . . . . . . . . . 8 Figure 3 - FDDI frame format . . . . . . . . . . . . . . . . 9 Figure 4 - Protocol Layers at S, T and U reference points when D Channel is used in ISDN . . . . . . . . . . . . . 13 Figure 5 - Protocol Layers at S, T and U reference points when B Channel is used in ISDN . . . . . . . . . . . . . 14 Figure D.1 - Multi-network PVC . . . . . . . . . . . . . . . 33 Figure D.2 - NNI Bidirectional Procedures . . . . . . . . . . 34 Figure D.3 - Configuration of a multi-network PVC . . . . . . 41 Figure D.4 - Deletion of a multi-network PVC . . . . . . . . 43 Figure D.5 - UNI failure and restoration . . . . . . . . . . 44 Figure D.6 - PVC segment failure and restoration . . . . . . 45 Figure D.7 - NNI failure and restoration . . . . . . . . . . 46 vii Part 2 - Subnetworks September 1993 (Stable) List of Tables Table A.1 - ANSI-CCITT cross-references . . . . . . . . . . . 22 Table D.1 - Relationships of CIR, Bc and Be . . . . . . . . . 31 Table D.2 - NNI system parameters . . . . . . . . . . . . . . 35 viii Part 2 - Subnetworks 0 Introduction This part provides agreements about subnetwork services used in support of the OSI Network Layer. 1 Scope These agreements cover subnetwork types including local area networks, packet switched networks, circuit switched networks, ISDN, and others. 2 Normative References 2.1 CCITT [1] Recommendation I.231 (Blue Book, 1988), Circuit-Mode Bearer Service Categories. [2] Recommendation I.232 (Blue Book, 1988), Packet-Mode Bearer Service Categories. [3] Recommendation I.431 (Blue Book, 1988), Primary Rate User- Network Interface - Layer 1 Specification. [4] Recommendation Q.921 (I.441) (Blue Book, 1988), ISDN User- Network Interface, Data Link Layer Specification. [5] CCITT Recommendation Q.922, ISDN Data Link Layer Specification for Frame Mode Bearer Services, ITU, Geneva, ( 1991). [6] Recommendation Q.931 (I.451) (Blue Book, 1988), ISDN User- Network Interface Layer 3 Specification for Basic Call Control. [7] CCITT Recommendation Q.933, ISDN Signaling Specification for Frame Mode Bearer Services, ITU, Geneva (1992). [8] Recommendation X.25 (Yellow Book 1980), Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks. [9] Recommendation X.25 (Blue Book, 1988), Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode 1 Part 2 - Subnetworks September 1993 (Stable) and Connected to Public Data Networks by Dedicated Circuit. [10] Recommendation X.31 (Blue Book, 1988), Support of Packet Mode Terminal Equipment by an ISDN. 2.2 ISO [11] ISO 7776, Information processing systems - Data communication - High-level Data Link Control Procedures - Description of the X.25 LAPB-compatible DTE data link procedures. [12] ISO/IEC 8208 Edition 2, Information technology - Data communications - X.25 Packet layer protocol for data terminal equipment. [13] ISO 8802-2, Information processing systems - Local area networks - Part 2: Logical link control. [14] ISO DIS 8802-3, Information processing systems - Local area networks - Part 3: Carrier sense multiple access method with collision detection (CSMA/CD) and physical layer specifications. [15] ISO DIS 8802-4, Information processing systems - Local area networks - Part 4: Token-passing bus access method and physical layer specifications. [16] ISO 8802-5, Information processing systems - Local area networks - Part 5: Token ring access method and physical layer specifications. [20] ISO 10039, Information Technology - Local Area Networks - MAC Service Definition 2.3 ANSI [21] ANSI/IEEE 802.2, Logical Link Control, 1987. [22] ANSI/IEEE 802.3, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) and Physical Layer Specifications, 1985. [23] ANSI/IEEE 802.3 Supplement a, MAU and Baseband Medium Specification, Type 10BASE2 (Section 10), 1988. [24] ANSI/IEEE 802.3 Supplement b, Broadband MAU and Broadband Medium Specifications, Type 10BROAD36 (Section 11), 1988. 2 Part 2 - Subnetworks September 1993 (Stable) [25] ANSI/IEEE 802.3 Supplement c, Repeater Unit for 10 Mb/s Baseband Networks (Section 9), 1988. [26] ANSI/IEEE 802.3 Supplement e, Physical Signaling, Medium Attachment, and Baseband Medium Specifications, Type 1BASE5 (Section 12), 1988. [27] ANSI/IEEE 802.4, Token-Passing Bus Access Method and Physical Layer Specifications, Draft 1987. [28] ANSI/IEEE 802.5, Token-Ring Access Method and Physical Layer Specifications, 1986. [29] ANS T1.408-1990, ISDN Primary Interface - Customer Installation Metallic Interfaces - Layer 1 Specification. [30] ANS T1.601, Integrated Services Digital Network (ISDN) - Basic Access Interface for Use on Metallic Loops for Application on the Network Side of the NT (Layer 1 Specification). [31] ANS T1.602, Integrated Services Digital Network (ISDN) - Data-Link Layer Signalling Specification for Application at the User-Network Interface. [32] ANS T1.605, Integrated Services Digital Network (ISDN) - Basic Access Interface for S and T Reference Points - Layer 1 Specification. [33] ANS T1.606 - Frame Relay Bearer Service - Architectural Framework and Service Description, 1990. [34] ANS T1.606 - Addendum 1 - Frame Relaying Bearer Service - Architectural Framework and Service Description. (Final text may be found in T1S1/91-454.) [35] ANS T1.607, Telecommunications - Digital Subscriber Signaling System #1 - Layer 3 Signaling Specification for Circuit Switched Bearer Service. [36] ANS T1.608, Telecommunications - Digital Subscriber Signaling System #1 - Layer 3 Signaling Specification for Packet Switched Bearer Service. [37] ANS T1.617 - DSS1-Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service, 1991. [38] ANS T1.618 - DSS1-Signaling Specification for Frame Relay Bearer Service, 1991. 3 Part 2 - Subnetworks September 1993 (Stable) [39] ANS X3.139, Fiber distributed data interface (FDDI) - Token ring media access control (MAC), 1987. [40] ANS X3.148, Fiber distributed data interface (FDDI) - Token ring physical layer protocol (PHY), 1988. [41] ANS X3.166, Fiber distributed data interface (FDDI) - Physical layer medium dependent (PMD), 1989. 3 Status This version was completed in March 1993. 4 Errata NOTE - This clause may contain "defect report" and resolutions material, and the versions of Implementor's Agreements to which this material applies. 5 Local Area Networks 5.1 IEEE 802.2 Logical Link Control The following decisions have been reached with respect to this protocol: a) Link Service Access Point (LSAP): 1) The code below shall be used to address systems using Network Layer protocols identified by ISO TR 9577 (e.g., ISO 8473, ISO 8208). Note that bit zero is transmitted first; 2) The most significant bit is bit 7, thus this bit pattern represents hexadecimal FE (see figure 1 below); b) Type and Class: 1) Only the connectionless type 1, class l IEEE 802 link service will be used. 4 Part 2 - Subnetworks September 1993 (Stable) +---+---+---+---+---+---+---+---+ | 0 | l | 2 | 3 | 4 | 5 | 6 | 7 | +---+---+---+---+---+---+---+---+ | 0 | l | l | l | l | l | l | 1 | +---+---+---+---+---+---+---+---+ Figure 1 - LSAP bit pattern 5.2 IEEE 802.3 CSMA/CD Access Method The following implementation agreements have been reached with respect to the IEEE 802.3 CSMA/CD Access Method and Physical Layer Specifications: a) The address length shall be 48 bits; b) For a data packet of LLC data length of n octets, the length of the pad field is as follows: 1) max(0, minFrameSize-(8n+2(addressSize)+48)) bits. The following implementation agreements have been reached with respect to 10 BROAD 36 Networks: a) Single Cable Networks: 1) The translator frequency shall be 192.25 Mhz; 2) The channel allocations are as follows: a) Reverse Channels: 1) T12, T13, T14 2) T13, T14, 2' 3) T14, 2', 3' 4) 2', 3', 4' 5) 3', 4', 4A' 6) 4', 4A', 5' b) Forward Channels: 1) L, M, N 2) M, N, O 5 Part 2 - Subnetworks September 1993 (Stable) 3) N, O, P 4) O, P, Q 5) P, Q, R 6) Q, R, S b) Dual Cable Networks: For nontranslated dual cable networks forward and reverse frequencies are the same. Permissible channel allocations are listed below: 1) T12, T13, T14 2) T13, T14, 2' 3) T14, 2', 3' 4) 2', 3', 4' 5) 3', 4', 4A' 6) 4', 4A', 5' 7) L, M, N 8) M, N, O 9) N, O, P 10) O, P, Q 11) Q, R, S c) When both IEEE 802.4 and IEEE 802.3 10 BROAD 36 networks coexist on the broadband cable system the preferred channel allocations are as follows: 1) Reverse: a) T12, T13, T14 - IEEE 802.3; b) 6', FM1' - IEEE 802.4; c) 3', 4'- Channels reserved for future use; d) 4A', 5' - Channels reserved for future use; 6 Part 2 - Subnetworks September 1993 (Stable) 2) Forward: a) L, M, N - IEEE 802.3; b) T, U - IEEE 802.4; c) P, Q - Channels reserved for future use; d) R, S - Channels reserved for future use. The following implementation agreements have been reached with respect to 10 BASE-T networks: a) Auto-partition: A repeater port which connects 10 BASE-T links either through an external or internal MAU shall implement the auto-partition and reconnections algorithm as defined in IEEE 802.3, Chapter 9. 5.3 IEEE 802.4 Token Bus Access Method The following options are agreed to with respect to Draft J of token bus: a) Data Rate: 1) 10 Mb (Broadband); 2) 5 Mb (Carrierband); b) Addressing: 48 bit; c) The lmeOption, Priority Mechanism, shall be implemented; d) Broadband Channel Assignments are as follows: 1) Forward: a) P b) Q c) R d) S e) T f) U 7 Part 2 - Subnetworks September 1993 (Stable) 2) Reverse: a) 3' b) 4' c) 4A' d) 5' e) 6' f) FM1'. 5.4 IEEE 802.5 Token Ring Access Method The following implementation agreements have been reached with respect to the IEEE Standard 802.5, Token Passing Ring Access Method and Physical Layer specification: a) The data signalling rate shall be 4 Mbit/s; b) The address length shall be 48 bits; c) The message priority (PM) of the AMP data unit shall be 7; d) The ALL_STATIONS_THIS_RING_ADDRESS shall be X'C000FFFFFFFF'; e) The TRR value shall be 4 milliseconds; f) The THT value shall be 8.9 milliseconds; g) The TQP value shall be 20 milliseconds; h) The TVX value shall be 10 milliseconds; i) The TNT value shall be 2.6 milliseconds; j) The TAM value shall be 7 seconds; k) The TSM value shall be 15 seconds; l) The MAC Information field (I-field) shall be defined as follows in figure 2 below. Sequences are as follows: 1) Starting Sequence includes: SD, AC, FC, DA, SA; 8 Part 2 - Subnetworks September 1993 (Stable) 2) Ending Sequence includes: FCS, ED, FS; m) With the above timer and MAC I-field definitions, the following limits are defined: 1) Protocol limits the I-field to a maximum of 4425 bytes; 2) All stations shall support I-fields that have a minimum of one byte and a maximum of at least 2000 bytes. +-------------------+------------------+----------------+ | Starting Sequence | I-Field | End Sequence | +-------------------+------------------+----------------+ Figure 2 - I-Field format All token ring interfaces should support the use of group MAC addressing (in addition to functional addressing) in accordance with ISO 8802-5. It is strongly recommended that group addresses be used to support all OSI uses of multicast on token ring networks. NOTE - It is expected that support for group MAC addressing for OSI usage shall be mandatory in the future. In some deployment scenarios, it may be necessary to use functional addresses so as to interoperate with existing installed systems that have limited, or no, ability to support group addresses. Refer to the appropriate base standards and implementors agreements for specific restrictions and recommendations regarding these issues. 5.5 Fiber Distributed Data Interface (FDDI) 5.5.1 Token Ring Media Access Control (MAC, X3.139-1987) The following are implementation agreements with respect to FDDI MAC: a) The address length shall be 48 bits; b) There shall be some manual or programmatic means of resetting stations and concentrators to the values specified as defaults herein or in X3.139-1987; c) The default value of T_Max shall be at least 165 milliseconds and not more than 200 milliseconds; 9 Part 2 - Subnetworks September 1993 (Stable) d) The default value of T_Req shall be equal to T_MAX_LB.1 ; e) All FDDI stations shall process Info_Fields of 0 to 4478 bytes. The frame is defined below in Figure 3; f) Stations shall not use restricted token service. P SD FC DA SA Inf FCS ED FS o Figure 3 - FDDI frame format P: Preamble - 16 Idle Symbols for Transmitting - >= 12 Idle Symbols for Copying - >=2 Idle Symbols for Repeating SD: Starting Delimiter (2 Symbols, JK) FC: Frame Control (2 Symbols) DA: Destination Address (12 Symbols) SA: Source Address (12 Symbols) INFO: Information Field (=<8956 Symbols) FCS: Frame Check Sequence (8 Symbols) ED: Ending Delimiter (1 Symbol) FS: Frame Status (3 Symbols) 5.5.2 Token Ring Physical Layer (PHY, X3.148-1988) The following implementation agreement is with respect to the FDDI PHY specifications: 1 The average delay, that is the time between when a station receives a Starting Delimiter (JK symbol pair) beginning a valid frame until it repeats that Starting Delimiter, when that Starting Delimiter is preceded by a sequence of a valid frame followed by 50 Idle Symbols shall not exceed: - 1 microsecond in a station, and - 1 microsecond times the number of ports in a concentrator, in addition to the delays contributed by the active slaves of the concentrator. The measurement method described above allows a consistent repeatable measurement, however it does not measure maximum possible delay. When the delay is one microsecond as measured above, the maximum effective delay contribution 10 Part 2 - Subnetworks September 1993 (Stable) component which can result is 1.164 microseconds. This number, not one microsecond, should be used per PHY to compute maximum possible network delay. 5.5.3 Physical Layer Media Dependent (PMD, X3.166-1989) The following implementation agreements are with respect to the FDDI PMD specification: 1 Stations shall repeat all valid packets under all signal conditions specified in section 5.2 of X3.166-1989, "Active Input Interface", with a bit error rate (BER) of not more than 2.5 x 10-10; 2 Stations shall repeat all valid packets under all signal conditions specified in section 5.2, "Active Input Interface", except that the Minimum Average Power shall be - 29 dBm (2 dB above the specified minimum), with a BER of not more than 10-12. 6 Wide Area Networks 6.1 CCITT Recommendation X.25 The procedures required to describe the DTE side of a DTE/DCE interface for systems attached to sub-networks providing an X.25 interface shall be as defined in ISO 7776 and ISO 8208 and as supplemented below. (These procedures shall also apply to a DTE operating on a DTE/DTE interface.) 6.2 ISO 7776 ISO 7776 is used as the Layer 2 Protocol with the agreements defined below: a) Address assignment information is as follows: 1) DTE = A (=11000000 binary); 2) DCE = B (=10000000 binary); 3) On a DTE/DTE interface, one of the DTEs, by a prior agreement, shall use the DCE address; b) The modulus shall be 8; 11 Part 2 - Subnetworks September 1993 (Stable) c) A window size (k) of 7 shall be supported. In addition, other window sizes may also be supported; d) The Multilink Procedures are excluded. 6.3 ISO 8208 The elements of ISO 8208 applicable for use depend on the OSI role of ISO 8208 (i.e., provision of CONS, support of CLNP). Independent of the role, ISO 8208 is used as the Layer 3 protocol, with the following agreements: a) Virtual Call Service; b) Any mutually agreed window and packet size, however, all DTEs must be capable of supporting a window size of 2, a packet size of 128 octets, and a sequence number modulus of 8; c) A DTE must be capable of receiving the Flow Control Parameter Negotiation Facility and responding appropriately (per ISO 8208); d) The Basic RPOA Selection Facility shall be implemented and its use or non-use selectable on a per virtual call basis. When ISO 8208 is used to support CONS, the optional user facilities in Clause 5.1 of ISO 8878 shall also be supported. When ISO 8208 is used to support CLNP (when providing the CLNS), Permanent Virtual Circuit Service may also be used. 7 Integrated Services Digital Networks (ISDN) 7.1 Introduction This clause defines Implementation Agreements for packet-data transfer in an ISDN context. The agreements provide a set of procedures for accessing an ISDN so that end systems implemented according to these agreements can obtain ISDN services and can successfully interoperate. The agreements are not meant to preclude vendors from implementing additional procedures as long as they do not create system interoperability problems. Capabilities will vary from ISDN to ISDN and procedures beyond those included here may be 12 Part 2 - Subnetworks September 1993 (Stable) necessary to request and utilize network services more effectively and fully. The agreements cover two fundamental ISDN services for X.25 packet mode ISDN terminals, namely, CASE I: The ISDN provides a circuit-mode (Layer 1) connection either on demand ("switched") or permanently ("dedicated circuit"). A general description of the corresponding ISDN 64 Kbps circuit-mode bearer service is described in CCITT Recommendation I.231. The circuit-mode connection is between an X.25 ISDN terminal and (i) a PSPDN, or (ii) another X.25 ISDN terminal. The circuit-mode connection to a PSPDN corresponds to CASE A of CCITT Recommendation X.31. CASE II: The ISDN provides the X.25 virtual circuit service. A general description of this service is given in CCITT Recommendation I.232. This case corresponds to CASE B of CCITT Recommendation X.31. Figures 4 and 5 give the agreed stacks for X.25 packet transfer over D and B channels, respectively. Some particular aspects are given below: a) The packet data transfer is on a B channel of a Basic Access or a Primary Rate Interface. In CASE II, it can be on a D channel of a Basic Access Interface; b) The layer 2 procedures are LAPB (ISO 7776) on a B channel and LAPD (CCITT Recommendation Q.921) on a D channel; c) X.25 PLP (ISO 8208) procedures are used, including the setting up and clearing of virtual calls; d) Q.921 and Q.931 procedures on a D channel are used for access signaling, when appropriate, to select the B or D channel for packet data transfer and for establishing and releasing a physical path in the ISDN; e) Refer to part 3 for the specification of methods for providing OSI Network Services. 13 Part 2 - Subnetworks September 1993 (Stable) 7.2 Implementation Agreements This clause gives Implementation Agreements for individual ISDN- related protocols. The relevant protocol stacks are given in figures 4 and 5. OSI LAYER +-------------------+-------------------+ 3 | | | | Q.931 | ISO 8208 | | (I.451) | (X.25 PLP) | +-------------------+-------------------+ | | 2 | Q.921 (I.441) | | (LAPD) | ++-------------------------------------++ |+------------------|------------------+| | D CHANNEL | 1 | | | ANS T1.601-1988, ANS T1.605-1988 | +---------------------------------------+ | | | | +---------|-------+ +-------|---------+ ADDITIONAL SIGNALING PACKET SWITCHED FOR INCOMING PACKET* SIGNALING AND INFORMATION CALLS TRANSFER * MAY BE NULL Figure 4 - Protocol Layers at S, T and U reference points when D Channel is used in ISDN 14 Part 2 - Subnetworks September 1993 (Stable) OSI LAYER 3 +-------------------+-------------------+ | | | | Q.931 | ISO 8208 | | (I.451) | (X.25 PLP) | +-------------------+-------------------+ | | | 2 | Q.921 | ISO 7776 | | (LAPD) | (X.25 LAPB) | ++-----------------+++-----------------++ |+--------|--------+ +--------|--------+| | D CHANNEL B CHANNEL | 1 | | | ANS T1.601-1988, ANS T1.605-1988 | | and for Primary Rate ANS T1.408-1990 | ++-----------------+-+-----------------++ | | | | +---------|-------+ +-------|---------+ Note 1 Note 2 Figure 5 - Protocol Layers at S, T and U reference points when B Channel is used in ISDN NOTES 1 This refers to signaling for circuit switched access (may be null), as well as additional signaling for incoming packet calls (may be null). 2 This refers to packet switched signaling and information transfer. 7.2.1 Physical Layer, Basic Access at "U" ANS T1.601-1988, "Integrated Services Digital Network-Basic Access Interface for Use on Metallic Loops for Application on the Network Side of the NT (Layer 1 Specification)" applies. 7.2.2 Physical Layer, Basic Access at S and T ANS T1.605-1988, "Integrated Services Digital Network-Basic Access Interface for S and T Reference Points-Layer 1 Specification" applies. 15 Part 2 - Subnetworks September 1993 (Stable) 7.2.3 Physical Layer, Primary Rate at S, T, and U ANS T1.408-1990, "ISDN Primary Rate - Customer Installation Metallic Interfaces - Layer 1 Specification" applies. 7.2.4 Data Link Layer, D-Channel CCITT Recommendation Q.921 (I.441), "ISDN User-Network Interface, Data Link Layer Specification" applies. 7.2.5 Signaling CCITT Recommendation Q.931 (I.451), "ISDN User-Network Interface Layer 3 Specification for Basic Call Control" applies. The following agreements have been reached concerning the use of Q.931: a) On a Basic Rate Interface supporting the ISDN virtual circuit service, all of Q.931 section 6 except for 6.1.1 and 6.2.1 (the sections covering the circuit-switched access case) shall apply. The following sections also apply: 2.2, packet mode access connection states; 3.2, messages for packet mode access connection control; 4-4.5, section specifying general information element handling and encoding; 4.7, information elements for packet communications; b) On a Primary Rate Interface supporting the ISDN virtual circuit service all of Q.931 section 6 shall apply except for 6.1.1 and 6.2.1 (the sections specifying the circuit switched access case), 6.1.2.2, 6.2.2.2 and 6.4.2 (the sections specifying D-Channel ISDN Virtual Circuit service case). The following sections also apply: 2.2, packet mode access connection states; 3.2, messages for packet mode access connection control; 4-4.5, sections specifying general information element handling and encoding; 4.7, information elements for packet communications; c) On a Basic or Primary Rate Interface supporting the unrestricted 64-Kbps circuit-mode service, Q.931 sections 6.1.1, 6.2.1, 6.4.1 and 6.4.3 shall apply. The following sections also apply: 2.1, circuit mode connection states; 3.1, messages for circuit mode connection control; 4-4.5, sections specifying general information element handling and encoding. 16 Part 2 - Subnetworks September 1993 (Stable) 7.2.6 Data Link Layer B-Channel The agreements on ISO 7776 specified in 6.2 shall apply here. If the ISDN provides a circuit-mode service between two ISDN packet-mode devices, then the layer 2 address shall be assigned as follows: a) For permanent ("non-switched") circuit-mode service, one terminal uses address A and the other terminal uses address B, as arranged by prior agreement; b) For demand ("switched") circuit-mode service, the terminal originating the circuit-mode call uses address A and the other terminal uses address B. 7.2.7 Packet Layer The agreements on ISO 8208 specified in 6.3 shall apply here. When ISO 8208 is used on the D-Channel, the maximum DATA packet size (i.e., actually the maximum size of the User Data Field in a DATA packet) shall be limited to 256 octets. 8 Frame Relay Subnetworks Annex D provides Implementation agreements for Frame Relay Network-to-Network Interfaces. 8.1 Introduction The following implementation agreements pertain to Frame Relay subnetworks for User-to-Network interfaces. These agreements are to guide implementors on optional aspects of the Frame Relay protocol standards. The following terminology is used in this clause: - must, shall or mandatory - the item is an absolute requirement of this implementation agreement, - should - the item is highly desirable, - may or optional - the item is not compulsory, and may be followed or ignored according to the needs of the implementor. 17 Part 2 - Subnetworks September 1993 (Stable) 8.2 Relevant Standards Normative references relevant to Frame Relay are ANS T1.606, and its addendum, ANS T1.607, ANS T1.617, ANS T1.618, CCITT Q.922, and CCITT Q.933. Additional information relevant to Frame Relay is found in CCITT I.122, and CCITT I.233.1. 8.3 Implementation Agreements for User-to-Network Interfaces 8.3.1 Physical Layer Interface The recommended physical layer interfaces supported by the Frame Relay network equipment are based on American National Standards and CCITT (Internatinal Telegraph and Telephone Consultative Committee) Recommendations. This clause provides a description of the recommended physical layer interfaces that may be supported by a Frame Relay equipment. Interfaces other than those listed below may be used where appropriate (e.g., ISDN, etc.). If the recommended interfaces are used, they should be used as follows: 8.3.1.1 ANS T1.403-1989 The ANS T1.403-1989, "Carrier to Customer Installation DS1 Metallic Interface" document is applicable with the following exceptions: a) Section 2.2 - Other Publications: The reference to CCITT, Red Book Q921 Recommendation is replaced by "CCITT, Blue Book, Volume VI - Fascicle VI.10, Recommendation Q.921, Digital Subscriber Signalling System No. 1 (DSS 1), Data Link Layer." b) Section 5.3.1 - Transmission Rate: The rate variation up to +/-200 bit/s is not applicable. c) Section 6.1 - Framing Format General: The Superframe (SF) format is not applicable. d) Section 6.3 - Superframe Format: This section is not applicable. e) Section 7 - Clear Channel Capability: The text in this section is replaced by the following: To provide DS1 Clear 18 Part 2 - Subnetworks September 1993 (Stable) Channel Capability (CCC), a DS1 signal with unconstrained information bits is altered to meet the pulse density requirement of 5.6. The method is used to provide DS1 CCC is B8ZS. This method shall be used in both directions of transmission. f) Section 8 - Maintenance: The mention of SF format and the associated note 4 is not applicable. g) Section 8.1 - Yellow Alarm: Item 1 of the list (Superframe format) and associated note 5 are not applicable. In the same section; item 3 of the list, is applicable to ESF only. h) Section 8.3.1.1 - Line Loopback Using the SF Format: This section including note 6 is not applicable. i) Section 8.4.3.3 - Format of Message-Oriented Performance Report: The sentence before last: "Throughput of the data link may be reduced to less than 4 Kbit/s in some cases" is not applicable. j) Section 8.4.5 - Special Carrier Applications: Item 3 of the list and note 12 are not applicable. k) Table 2 - Superframe Format: This table is not applicable. l) Table 3 - Extended Superframe Format: The portion of the table "Signaling Bit Use Options" and notes related to Option T. Option 2, Option 4, and Option 16 are not applicable. 8.3.1.2 CCITT Recommendation V.35 The interface specifications are: a) Electrical characteristics according to CCITT Recommendation V.35 Annex 1 and V.28; b) Connector and pin assignment according to ISO 2983; c) Interchange circuit defintions according to CCITT Recommendation V.24. 19 Part 2 - Subnetworks September 1993 (Stable) 8.3.1.3 CCITT Recommendation G.703 (2048 kbit/s) Applicable sections of this specification are: a) Introduction. Except those references which are to 1544 kbit/s; b) Section 6. Interface at 2048 kbit/s; c) Annex A. Definition of codes; d) Annex B. Specification of the overvoltage protection requirement. In addition, when the 75 ohm interface is implemented, the transmit BNC connector shall be labeled TFC OUT and the receive BNC connector shall be labeled TFC IN. 8.3.1.4 CCITT Recommendation G.704 (2048 kbit/s) Applicable sections of this specification are: a) General; b) Section 2.3. Basic frame structure at 2048 kbit/s; c) Section 5. Characteristics of frame structures carrying channels at various bit rates in 2048 kbit/s interfaces; d) Annex A.3. CRC-4 procedure for interface at 2048 kbit/s. NOTE - Section 1, "General," specifies the electrical interface characteristics to be CCITT Recommendation G.703. 8.3.1.5 CCITT Recommendation X.21 (non-switched operation) This unstructured interface uses the leased line (i.e., non- switched point to point) subset of the X.21 Recommendation. The interface specifications are: a) Electrical characteristics according to CCITT Recommendation X.27 (V.11); b) Connector and pin assignment according to ISO 4903; c) Interchange circuit definitions according to CCITT Recommendation X.24. 20 Part 2 - Subnetworks September 1993 (Stable) 8.3.2 Data Transfer Implementations shall be based on ANS T1.618. Implementation agreements on the optional parts of ANS T1.618 are proposed as follows: 8.3.2.1 Section 2.2 Flag sequence Interframe time fill shall be accomplished by transmitting one or more contiguous HDLC flags with the bit pattern `01111110' when the data link layer has no frames to send. 8.3.2.2 Section 2.5 Frame relay information field A maximum frame relay information field size of 1600 octets shall be supported by the network and the user. In addition, maximum information field sizes less than or greater than 1600 octets may be agreed to between networks and user at subscription time. 21 Part 2 - Subnetworks September 1993 (Stable) 8.3.2.3 Section 3.3 Address field variables See the following: a) Section 3.3.1 Length of address field; 1) An address field of 2 octets shall be supported. (All frames must have the EA bit set to 0 in the first octet of the address field and the EA bit set to 1 in the second octet of the address field); 2) The 3- and 4-octet address formats are outside the scope of this agreement; b) Section 3.3.6 Data link connection identifier; 1) The 2 octet address format shall be supported with DLCI values as defined in table 1(a); c) Section 3.3.6.2 DLCI on the D-channel; 1) This section is not applicable for Permanent Virtual Connections (PVCs); d) Section 3.3.7 DLCI or DL-CORE control indicator (D/C); 1) This section is not applicable. Other address structure variables and their usage are as specified in ANS T1.618. 8.3.2.4 Section 5 Congestion control Congestion control strategy for Frame Relay is defined in ANS T1.606 Addendum 1. The following implementation agreements apply to network equipment and user equipment respectively: a) Section 5.1 Network response to congestion 1) Mandatory procedures of ANS T1.606 Addendum 1 shall be implemented. When implemented, rate enforcement using the DE indicator, and/or setting of the FECN and BECN indicators, should be implemented according to T1.606 Addendum 1. b) Section 5.2 User response to congestion 22 Part 2 - Subnetworks September 1993 (Stable) 1) User equipment reaction is dependent on the protocols operating over the Data Link Core sublayer. It is recommended that the procedures of ANS T1.618 Annex A should be implemented where appropriate. 8.3.2.5 Section 6 Consolidated link layer management (CLLM) message Use of the CLLM message is not required. 8.3.3 Control (Signaling) procedures 8.3.3.1 Permanent Virtual Connections (PVC) procedures a) Managing PVCs on a bearer channel that only supports PVCs: User devices (and the network) shall implement the mandated procedures of Annex D of ANS T1.617. In addition, Annex B and optional procedures of Annex D of ANS T1.617 may also be implemented. By bilateral agreement: 1) Optional procedures of Annex D of ANS T1.617 may be used; 2) Annex B may be used instead of Annex D. Implementation Note - The number of PVCs that can be supported by Annex D is limited by the maximum frame size that can be supported by the user equipment and the network on the bearer channel (e.g., when the maximum frame relay information field size is 1600 octets then a maximum of 317 PVC status information elements may be encoded in a STATUS message). b) Managing PVCs on a bearer channel where switched virtual connections (SVCs) and PVCs co- exist: User devices (and the network) shall implement Annex B of ANS T1.617. 8.3.3.2 Switched Virtual Connections (SVCs) procedures The implementation agreements for SVCs will be provided later. 23 Part 2 - Subnetworks September 1993 (Stable) Annex A (informative) Cross Reference Between CCITT and ANSI Text Relating to ISDN Agreements This annex provides a cross-reference listing between those sections of the CCITT ISDN Recommendations given in clause 7 of this document and the sections of the corresponding ANSI ISDN Standards. This appendix does not supersede clause 7 but merely provides a pointer to those who wish to implement the ISDN procedures based on ANSI Standards. A.1 Data Link Layer, D-Channel CCITT Recommendation Q.921, which is referenced in 7.2.4 of this document, is identical to ANSI Standard T1.602. A.2 Signaling The following table provides the cross-references between those sections of CCITT Recommendation Q.931 referenced in 7.2.5 of this document and the corresponding ANSI ISDN Standards. 24 Part 2 - Subnetworks September 1993 (Stable) Table A.1 - ANSI-CCITT cross-references +------------------------------+--------------------------------+ | CCITT RECOMMENDATION Q.931 | ANS T1.608 | +------------------------------+--------------------------------+ | Section 2.1 | Section 4.1 (refers to sec. | | | 2.1.1 of ANS T1.607) | | Section 2.2 | Section 4.2 | | Section 3.1 | Section 5.1 (refers to sec. | | | 3 of ANS T1.607) | | Section 3.2 | Section 5.2 | | Section 4.1 | Section 6.1 | | Section 4.2 | Section 6.2 | | Section 4.3 | Section 6.3 | | Section 4.4 | Section 6.4 | | Section 4.5 | Section 6.5 | | Section 4.7 | Section 6.5 | | Section 6 | Section 7 | | Section 6.1.1 | Section 7.1.1 | | Section 6.1.2.2 | Section 7.1.2.2 | | Section 6.2.1 | Section 7.2.1 | | Section 6.2.2.2 | Section 7.2.2.3 | | Section 6.4.1 | Section 7.4.1 | | Section 6.4.2 | Section 7.4.2 | | Section 6.4.3 | Section 7.4.3 | | | | +------------------------------+--------------------------------+ 25 Part 2 - Subnetworks September 1993 (Stable) Annex B (informative) Bibliography B.1 ANSI ANS T1.607-1989, Telecommunications - Digital Subscriber Signaling System #1 - Layer 3 Signaling Specification for Circuit Switched Bearer Service. ANS T1.608-1989, Telecommunications - Digital Subscriber Signaling System #1 - Layer 3 Signaling Specification for Packet Switched Bearer Service. B.2 CCITT CCITT Recommendation I.122, Framework for Providing Additional Packet Mode Bearer Services, 1988. CCITT Recommendation I.233.1, ISDN Frame Mode Bearer Services (FRBS)-ISDN Frame Relaying Bearer Service, (proposed 1991). CCITT Recommendation I.430 (Blue Book), Basic User-Network Interface - Layer 1 Specification. B.3 ISO ISO 9314-1:1989, Information processing systems - Fibre distributed data interface (FDDI) - Part 1: Token ring physical layer protocol (PHY). ISO 9314-3: 1990, Information processing systems - Fibre distributed data interface (FDDI) - Part 2: Token ring media access control (MAC). ISO 9314-3: 1990, Information processing systems - Fibre distributed data interface (FDDI) - Part 3: Physical layer medium dependent (PMD). 26 Part 2 - Subnetworks September 1993 (Stable) B.4 OTHER FIPS 107, Local Area Networks: Baseband Carrier Sense Multiple Access with Collision Detection Access Method and Physical Layer Profiles and Link Layer Protocol, NTIS, U.S. Department of Commerce, 5285 Port Royal Road, Springfield, VA 22161. 27 Part 2 - Subnetworks September 1993 (Stable) Annex C (informative) Cross Reference between CCITT and ANSI Text Relating to Frame Relay Agreements (See Working Implementation Agreements Document.) 28 Part 2 - Subnetworks September 1993 (Stable) Annex D (informative) Frame Relay Network-to-Network Interface D.1 Introduction D.1.1 Purpose This document is a frame relay permanent virtual connection (PVC) network-to-network interface (NNI) implementation agreement. The agreements herein were reached in the Frame Relay Forum, and are based on the relevant frame relay standards referenced in clause D.2. They address the optional parts of these standards, and document agreements reached among vendors/suppliers of frame relay network products and services regarding the options to be implemented. Except as noted, these agreements will form the basis of conformance test suites produced by the Frame Relay Forum. This document may be submitted to different bodies involved in ratification of implementation agreements and conformance testing to facilitate multi-vendor interoperability. D.1.2 Definitions Network-to-Network Interface (NNI) - the Network-to-Network Interface is concerned with the transfer of C-Plane and U- Plane information between two network nodes belonging to two different frame relay networks; Must, Shall, or Mandatory - the item is an absolute requirement of this implementation agreement; Should - the item is highly desirable; May or Optional - the item is not compulsory, and may be followed or ignored according to the needs of the implementor; Not Applicable - the item is outside the scope of this implementation agreement. 29 Part 2 - Subnetworks September 1993 (Stable) D.2 Relevant Standards a) The following is a list of standards and implementation agreements on which this frame relay NNI implementation agreement is based: 1) ANSI T1.606 - Frame Relaying Bearer Service - Architectural Framework and Service Description, American National Standards Institute, Inc., 1990; 2) ANSI T1.606 Addendum 1 - Frame Relaying Bearer Service - Architectural Framework and Service Description, American National Standards Institute, Inc., 1991; 3) ANSI T1.606 Addendum 2 (Draft) - T1S1/92-297R1 - Frame Relaying Bearer Service - Architectural Framework and Service Description, August 1992; 4) ANSI T1.617 - DSS1 - Signaling Specification for Frame Relay Bearer Service, American National Standards Institute, Inc., 1991; 5) ANSI T1.618 - DSS1 - Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service, American National Standards Institute, Inc., 1991; 6) CCITT Blue Book I.122 Recommendation, Framework for Providing Additional Packet Mode Bearer Service, ITU, Geneva, 1988; 7) CCITT Recommendation I.233.1 - Frame Relay Bearer Services, 1991; 8) CCITT Recommendation I.370 - Congestion Management in Frame Relaying Networks, 1991; 9) CCITT Recommendation I.372 - Frame Mode Bearer Services Network-to-Network Interface Requirements, 1992; 10) CCITT I.555 Draft Recommendation - Interworking between FMBS and Other Services, June 1992; 11) CCITT Recommendation Q.922, ISDN Data Link Layer Specification for Frame Mode Bearer Services, 1991; 12) CCITT Recommendation Q.933, DSS1 Signalling Specification for Frame Mode Basic Call Control, ITU, Geneva, 1992; 30 Part 2 - Subnetworks September 1993 (Stable) 13) Frame Relay Forum - Frame Relay Implementation Agreements, Document Number FRF.1, 1992. D.3 Implementation Agreements D.3.1 Physical Layer Interface Guidelines The recommended physical layer network-to-network interfaces (NNI) supported by frame relay network equipment are based on American National Standards and CCITT (International Telegraph and Telephone Consultative Committee) Recommendations. This section provides a description of the recommended physical layer interfaces that may be supported by frame relay network equipment. This section is not intended to be used for frame relay conformance testing. Interfaces other than those listed below may be used where appropriate (e.g., ISDN, etc.). If the recommended interfaces are used, they should be implemented as follows: D.3.1.1 DS1 Interface (1544 kbit/s) a) ANSI T1.403-1989 Carrier to Customer Installation DS1 Metallic Interface: This specification will be followed, with the following exceptions: 1) Section 2.2 - Other Publications: The reference to CCITT, Red Book Q.921 Recommendation is replaced by "CCITT, Blue Book, Volume VI - Fascicle VI.10, Recommendation Q.921, Digital Subscriber Signalling System No 1 (DSS1), Data Link Layer"; 2) Section 5.3.1 - Transmission Rate: The rate variation up to +/- 200 bit/s is not applicable; 3) Section 6.1 - Framing Format General: The Superframe (SF) format is not applicable; 4) Section 6.3 - Superframe Format: This section is not applicable; 5) Section 7. - Clear Channel Capability: The text in this section is replaced by the following: a) To provide DS1 Clear Channel capability (CCC), a DS1 signal with unconstrained information bits 31 Part 2 - Subnetworks September 1993 (Stable) is altered to meet the pulse density requirement of 5.6. The method used to provide DS1 CCC is B8ZS. This method shall be used in both directions of transmission; 6) Section 8. - Maintenance: The mention of SF format and the associated note 4 is not applicable; 7) Section 8.1 - Yellow Alarm: Item 1 of the list (Superframe format) and associate note 5 are not applicable. In the same section; item 3 of the list, is applicable to ESF only; 8) Section 8.3.1.1 - Line Loopback Using the SF Format: This section, including note 6, is not applicable; 9) Section 8.4.3.3 - Format of Message-Oriented Performance Report: The sentence before last: "Throughput of the data link may be reduced to less than 4 kbit/s in some cases" is not applicable; 10) Section 8.4.5 - Special Carrier Applications: Item 3 of the list and note 12 are not applicable; 11) Table 2 - Superframe Format: This table is not applicable; 12) Table 3 - Extended Superframe Format: The portion of the table "Signaling Bit Use Options" and notes related to Option T, Option 2, Option 4, and Option 16 are not applicable. In addition to ANSI T1.403, portions of CCITT Recommendations G.703 and G.704 relating to 1544 kbit/s interface are used. Exceptions to Recommendations G.703 and G.704 are listed below: a) CCITT Recommendation G.703: The sections related to the 1544 kbit/s interface in this Recommendation apply with the following exception: 1) Section 2.5: The current text is replaced by: "The B8ZS code shall be used because connecting line systems require suitable signal content to guarantee adequate timing information." a) CCITT Recommendation G.704: 32 Part 2 - Subnetworks September 1993 (Stable) The sections related to the 1544 kbit/s interface in this Recommendation apply with the following exceptions: 1) Section 2.1.3 - Allocation of the F-bit: The current text is to be replaced by: "Table 1/G.704 provides the recommended F-bits allocation;" 2) Table 1/G.704: In the column "For character signal," all instances of "1-7" are replaced by "1-8" (related bits are: 966, 2124, 3282 and 4440): a) The column "For signalling" is not applicable; b) The column "Signalling channel designation" is not applicable; 3) Table 2/G.704: The table is not applicable; 4) Section 2.1.3.1.1 - Multiframe alignment signal: The section starting with "...as well as to identify." to the end of the sentence is not applicable; 5) Section 2.1.3.1.3 - 4 kbit/s data link, third paragraph: The entire paragraph is replaced by: "The idle data link pattern is the HDLC flag bit pattern (01111110)"; 6) Section 2.1.3.2 - Method: twelve-frame multiframe: This section is not applicable; 7) Section 3.1.2 - Use of 64 kbit/s channel time slots: This section is not applicable; 8) Section 3.1.3 - Signalling: All sections under 3.1.3 are not applicable; 9) Section 3.2 - Interface at 1544 kbit/s carrying 32 kbit/s channel time slots: All sections under 3.2 are not applicable; 10) Section 3.3 - Interface at 1544 kbit/s carrying n * 64 kbit/s: This section is not applicable. D.3.1.2 CCITT Recommendation G.703 (2048 kbit/s) a) Applicable sections of this specification are: 1) Introduction: except those references which are to 1544 kbit/s; 33 Part 2 - Subnetworks September 1993 (Stable) 2) Section 6: Interface at 2048 kbit/s; 3) Annex A: Definition of codes; 4) Annex B: Specification of the overvoltage protection requirement. In addition, when the 75 ohm interface is implemented, the transmit BNC connector shall be labeled TFC OUT and the receive BNC connector shall be labeled TFC IN. D.3.1.3 CCITT Recommendation G.704 (2048 kbit/s) a) Applicable sections of this specification are: 1) General; 2) Section 2.3: Basic frame structure at 2048 kbit/s; 3) Section 5: Characteristics of frame structures carrying channels at various bit rates in 2048 bit/s interfaces; 4) Annex A.3: CRC-4 procedure for interface at 2048 kbit/s. NOTE - that Section 1. General specifies the electrical interface characteristics to be G.703. D.3.1.4 High Speed Physical Interfaces Implementation agreements for higher speed physical interfaces are not applicable to this document. D.3.2 Data Transfer This section is intended to be used for Frame Relay conformance testing. Implementations for the Frame Relay NNI U-plane shall be based on CCITT Q.922 Annex A and ANSI T1.618. Implementation agreements on the optional parts of Q.922 Annex A and T1.618 are as follows: D.3.2.1 Interframe Time Fill Interframe time fill shall be accomplished by transmitting one or more contiguous HDLC flags with the bit pattern 01111110 when the 34 Part 2 - Subnetworks September 1993 (Stable) data link layer has no frames to send. All equipment shall be able to receive, as a minimum, consecutive frames separated by 1 flag. D.3.2.2 Frame Relay Information Field (T1.618 2.5 & Q.922 Annex A A.2.5 & A.5.1) A maximum frame relay information field size of 1600 octets shall be supported by networks. In addition, maximum information field sizes less than or greater than 1600 octets may be agreed to between networks by bilateral agreement during PVC provisioning. D.3.2.3 Address Field Variables Length of Address Field (T1.618 3.3.1 & Q.922 Annex A A.3.3.1): An address field of 2 octets shall be supported. All frames using an address field of 2 octets must have the EA bit set to 0 in the first octet of the address field and the EA bit set to 1 in the second octet of the address field. The 3 and 4 octet address formats are outside the scope of this implementation agreement. Data Link Connection Identifier (DLCI) (T1.618 3.3.6 & Q.922 Annex A A.3.3.6): The 2 octet address format shall be supported with DLCI values as defined in Table 1a of T1.618 and Table 1 (for 10 bit DLCIs) of Q.922. DLCI on the D-channel (T1.618 3.3.6.2 & Q.922 Annex A A.3.3.6): T1.618 3.3.6.2 is not applicable to Permanent Virtual Connections (PVCs). The descriptions in Q.922 Table 1 and 3.3.6 related to DLCI assignment on the D-channel are not applicable to PVCs. DLCI or DL-CORE Control Indicator (D/C) (T1.618 3.3.7 & Q.922 Annex A A.3.3.7). These sections are not applicable to address fields of 2 octets. NOTE - Other address structure variables (i.e., the 35 Part 2 - Subnetworks September 1993 (Stable) command/response (C/R), discard eligibility indicator (DE), forward explicit congestion notification (FECN), and backward explicit congestion notification (BECN) bits) and their usage are as specified in Q.922 Annex A and T1.618. D.3.2.4 Congestion Management Congestion management and control are described in ANSI T1.606 Addendum 1 and CCITT I.370. The mandatory procedures of these standards and recommendations shall be implemented. Additional congestion management principles applicable to the network-to-network interface are as follows: a) Each network should generate forward explicit congestion notification (FECN), backward explicit congestion notification (BECN), and support rate enforcement using the DE indicator in accordance with ANSI T1.606 Addendum 1 and CCITT I.370; b) Each network is responsible for protecting itself against congestion scenarios at the network-to-network interface (e.g., a given network should not rely solely on the prior network s setting of the DE bit); c) Under normal operating conditions, every effort should be made not to discard Bc committed data at the NNI. One method to assure this, is to limit the sum of the subscribed CIRs (egress from the network) of all PVCs on a given NNI to be less than the NNI access rate; d) The committed information rate (CIR), committed burst size (Bc), and excess burst size (Be) values are administratively coordinated at the network-to-network interface. To provide a consistent service along the multi-network PVC, the same CIR value should be configured on all PVC segments (see section 4.1 for definitions of multi-network PVC and PVC segment). CIR, Bc, and Be may be uniquely defined in both the forward and backward directions; e) The access rate (AR) of all NNIs involved in a multi-network PVC do not have to be equal. The access rate at one NNI may be substantially higher than at another NNI. Therefore, continuous input of Be frames at one NNI may lead to persistent congestion of the network buffers at another NNI, and a substantial amount of the input Be data may be discarded. 36 Part 2 - Subnetworks September 1993 (Stable) Table D.1 shows the relationships of CIR, Bc and Be. These constraints shall apply to selection of parameters at the NNI. Table D.1 - Relationships of CIR, Bc and Be CIR COMMITTED EXCESS BURST MEASUREMENT BURST SIZE SIZE (Be) INTERVAL (T) (Bc) >0 >0 >0 T = Bc/CIR >0 >0 =0 T = Bc/CIR =0 =0 >0 NOTE 1. NOTE - Table D.1 is a network dependent value. D.3.2.5 Consolidated Link Layer Management (CLLM) Message (T1.618 6 & Q.922 Annex A A.7) Use of the CLLM message is outside the scope of this implementation agreement. D.3.3 Control (Signalling) Procedures D.3.3.1 Permanent Virtual Connection (PVC) Procedures Networks should implement CCITT Q.933 Annex A bidirectional procedures for managing PVCs on any NNI that only supports PVCs. For an interim period, networks may implement ANSI T1.617 Annex D bidirectional procedures for managing PVCs on any NNI that only supports PVCs. Networks shall implement one or both of the above protocols. It is highly recommended that Q.933 Annex A be implemented. Networks shall follow clause D.4, Application of Bidirectional Procedures for Use at the Network-to-Network Interface, of this implementation agreement. D.3.3.2 Switched Virtual Connection (SVC) Procedures Procedures for SVCs are not applicable to this implementation agreement. 37 Part 2 - Subnetworks September 1993 (Stable) D.3.4 Network Performance Parameters Frame relay quality of service refers to service performance from the end-user standpoint. Network performance, when considered between two user-to-network interfaces, is closely tied to, and directly impacts the quality of service. Network performance parameters apply at different interfaces in the network. For a multi-network frame relay service, the values of performance parameters at the network-to-network interface contribute to the service performance from the end-user standpoint. The performance parameters applicable to frame relay network-to-network service include those specified in Annex A of CCITT Recommendation I.233.1. D.3.5 PVC Parameter Coordination The parameter values that shall be administratively coordinated at the network-to-network interface include maximum frame size per PVC segment, originating DLCI and terminating DLCI of a PVC segment, and CIR in each direction per PVC segment. Additional parameters that should be coordinated include Bc and Be in each direction per PVC segment. D.4 Application of Bidirectional Procedures for Use at the Network-to-Network Interface This section defines the unique network-to-network interface and user-to-network interactions when the bidirectional procedures are implemented at the NNI. Specific scenarios of how the PVC status information element status bits shall be interpreted in a multi-network environment are described. These scenarios include: addition of a multi-network PVC; deletion of a multi-network PVC; failure and restoration of a multi-network PVC. D.4.1 Bidirectional network procedures and multi-network PVCs When a permanent virtual connection (PVC) between two users involves more than one network, the portion of the PVC provided by each network is termed a "PVC segment." A multi-network PVC is a concatenation of two or more PVC segments. 38 Part 2 - Subnetworks September 1993 (Stable) This is depicted in the Figure D.1 below. Figure D.1 - Multi-network PVC The bidirectional network procedures shall be used to communicate status between networks. Each network at the network-to-network interface shall support both user side procedures and network side procedures simultaneously. In effect, there are two distinct user-to-network procedures taking place where each side of the NNI supports both user side and network side procedures concurrently. This is depicted in the Figure D.2 below: 39 Part 2 - Subnetworks September 1993 (Stable) Figure D.2 - NNI Bidirectional Procedures a) See two views below: Each network has two views of the other connected network at a given NNI: 1) a single user - The other network is the source of all status enquiry messages and the recipient of status messages. No special attributes are given to the other network; 2) an extended network - full status and single PVC asynchronous status reports reflect not only the status of the destination device and/or channel but also the status of any network that is traversed by the multi-network PVC to the destination. D.4.2 Polling requirements of network-to-network interfaces Two sets of sequence numbers and local in-channel signalling parameters are administered for the network-to-network interface as shown below; see Table D.2 for parameter ranges and default values 40 Part 2 - Subnetworks September 1993 (Stable) user side procedures - T391, N391, N392, and N393; network side procedures - T392, N392, and N393. Table D.2 summarizes the acceptable values when using bidirectional procedures at the NNI. The default values in Table D.2 should be used as the actual system parameter values. Parameter values other than the default values are a subscription time option. Procedures for starting and stopping T391 and T392 are described in Q.933 Annex A. Table D.2 - NNI system parameters Name Range Default Units Definitions N391 1-255 6 Polling Full status (status of all Cycles PVCs) polling cycles N392 1-101 3 Errors Number of errors during N393 monitored events which cause the channel/user side procedures to be declared inactive. This number may also be used by the user side procedures as the number of errors during N393 monitored events which cause the network side procedures to be declared inactive. N393 1-102 4 Events Monitored events count. T391 5-30 10 Seconds Link integrity verification polling timer. T392 5-303 15 Seconds Timer for verification of polling cycle. 1 N392 should be less than or equal to N393. 2 If N393 is set to a value much less than N391, then the link could go in and out of an error condition without the user side procedures or network side procedures being notified. 3 T392 should be set greater than T391. 41 Part 2 - Subnetworks September 1993 (Stable) Both networks are required to initiate status enquiry messages based on T391. A full status report is requested each N391 (default 6) polling cycles. Both networks shall have the same values for T391, T392, N392, and N393 for both user side procedures and network side procedures; N391 is not required to have the same value in both networks. PVC status information from full status reports and optionally from single PVC asynchronous status reports shall be propagated towards the user-to-network interface (UNI) of the multi-network PVC. The PVC status information element active bit state signaled at the NNI is independent of the PVC status information element active bit state signaled in the other direction at the same NNI. In addition, when a PVC segment's status has changed, or a PVC segment has been newly added or deleted, the network should respond to any poll (i.e., status enquiry) with a full status report. Alternatively, the network may generate a single PVC asynchronous status report to convey the PVC segment's status change. D.4.3 Initial NNI status The NNI access channel shall be considered non-operational when the user side procedures or network side procedures are first activated: The NNI access channel should be considered non-operational until N393 consecutive valid polling cycles occur; As an alternative, if the first polling cycle constitutes a valid exchange of sequence numbers, then the respective NNI access channel shall be considered operational. If the first polling cycle results in an error, then the respective NNI shall be considered non-operational until N393 consecutive valid polling cycles occur. D.4.4 Multi-network PVC active status criteria a) The network shall report a multi-network PVC as "active" (i.e., active bit =1) at the UNI only if all the following criteria are met: 1) All PVC segments are configured; 2) Link integrity verification is successful at all UNIs and NNIs that are associated with the multi-network PVC 42 Part 2 - Subnetworks September 1993 (Stable) (N393 consecutive valid polling cycles, or as defined in clause 4.3 above); 3) All UNIs and NNIs associated with the multi-network PVC are operational (i.e., no service affecting conditions); 4) All PVC segments within the multi-network PVC are operational (i.e., no service affecting conditions); 5) The remote user equipment, when supporting bidirectional procedures at the UNI, reports that the PVC is active by setting the active bit = 1 in a PVC status information element. Whenever these criteria are not fully met, the active bit indication propagated toward the UNIs shall be set to 0. Only a network with a PVC terminating at a UNI may set the active bit to 1 towards the remote UNI (considered the "target UNI"). Each succeeding network along the multi-network PVC may either pass the active bit unchanged or set the active bit to 0. If any PVC segment is not active along the multi-network PVC, an inactive status is propagated (when possible) to the target UNI. See clauses D.4.5 - D.4.10 for further details. D.4.5 Adding a multi-network PVC Since a multi-network PVC consists of a number of PVC segments, each managed by a different network, all PVC segments in a multi-network PVC cannot be added simultaneously. The PVCs can be thought as being added one at a time in an arbitrary order. The presence or absence of a PVC status information element in a full status report at either the user-to-network interface or at the network-to-network interface indicates only the presence or absence of a particular PVC segment within the multi-network PVC. As each PVC segment is added to a multi-network PVC, the network-to-network interface(s) and the user device (if applicable) are notified that the PVC segment has been added (i.e., new bit set to 1). The active status in a multi-network PVC is set according to the criteria given in section 4.4 and propagated towards the target UNI. See clause D.4.10.3 for an example of adding a multi-network PVC. 43 Part 2 - Subnetworks September 1993 (Stable) D.4.6 Deleting a multi-network PVC Since a multi-network PVC consists of a number of concatenated PVC segments each managed by a different network, the PVC segments in a multi-network PVC cannot be deleted simultaneously. The PVC segments can be thought of as being deleted one at a time in an arbitrary order. A multi-network PVC is considered to be deleted when the PVC status information element in the full status report has been deleted at every associated UNI and NNI. The presence or absence of the PVC status information element at either the user-to-network interface or the network-to-network interface indicates only the presence or absence of a particular PVC segment within the multi-network PVC. As a PVC segment is deleted from a multi-network PVC, the adjacent network-to-network interface(s) and/or adjacent user device (if applicable) are notified by the deletion of the PVC status information element that its associated PVC segment has been deleted. An inactive status is propagated towards the target UNI whenever the deletion of a PVC segment is detected at the NNI. See clause D.4.10.4 for an example of deleting a multi-network PVC. D.4.7 Response to UNI failure When a network detects that the user-to-network interface is inoperative, it notifies users of the multi-network PVCs associated with the failed UNI that the multi-network PVCs are inactive. The PVC status changes are propagated through the adjacent network(s) to the remote users. See clause D.4.10.5 for an example of response to UNI failure. D.4.8 Response to PVC segment failure When a network determines that a PVC segment has become inoperative, it notifies the adjacent network(s) and/or UNI that the multi-network PVC is inactive. The PVC status change is propagated through the adjacent network(s) to the remote user(s). See clause D.4.10.6 for an example of PVC segment failure. 44 Part 2 - Subnetworks September 1993 (Stable) D.4.9 Response to NNI failure When a network detects that a network-to-network interface is inoperative, each network notifies users of the PVCs associated with the NNI that the multi-network PVCs are inactive. The PVC status changes are propagated through the adjacent network(s) to the remote users. See clause D.4.10.7 for an example of response to NNI failure. D.4.10 Examples of multi-network PVC status signalling This clause provides examples of multi-network permanent virtual connection (PVC) status signalling at the user-to-network interface (UNI) and network-to-network interface (NNI). It contains examples of multi-network PVC status signalling in the following scenarios: adding a multi-network PVC (see clause D.4.10.3); deleting a multi-network PVC (see clause D.4.10.4); UNI failure & restoration (see clause D.4.10.5); PVC segment failure & restoration (see clause D.4.10.6); NNI failure & restoration (see clause D.4.10.7). D.4.10.1 Generic example comments Status enquiry/status report exchanges occur at all UNIs and NNIs to indicate that the interface is operational. The status enquiry/status report exchanges are shown only when a change in link integrity verification state occurs or when multi-network PVC status signalling is affected. The PVC status information elements are only shown when the associated PVC segment has a status change. The flows throughout this section show only the use of full status reports to signal a change in multi-network PVCs. Alternatively, the single PVC asynchronous status reports may be used to convey multi-network PVC active and inactive status changes. All examples deal with the following multi-network PVC consisting of two PVC segments: PVC segment in Network I interfaces to User A with DLCI 16 45 Part 2 - Subnetworks September 1993 (Stable) and NetworkJ with DLCI 32; PVC segment in Network J interfaces to Network I with DLCI 32 and User B with DLCI 48. NOTE - The default values of 3 errors for N392 and 4 monitored events for N393 are used throughout the examples. 46 Part 2 - Subnetworks September 1993 (Stable) D.4.10.2 Nomenclature 47 Part 2 - Subnetworks September 1993 (Stable) Notation Meaning SE This is the status enquiry message as described in Q.933 Annex A, Section A.1.2. The request for a full status report need not be present. S This is the link integrity verification status report as described in Q.933 Annex A, Section A.1.1. FS(16,N,I)This is a full status report as described in Q.933 Annex A, Section A.1.1. A full status report request is not necessary for a full status report response. In this case, DLCI 16 reported the status of "new" and "inactive" for the PVC segment. FS() This is a full status report as described in Q.933 Annex A, Section A.1.1. A full status report request is not necessary for a full status report response. In this case, the PVC segment of interest is not present (e.g., no longer configured). I->J This indicates the status generated by Network I as seen by Network J. A16-I-J32 This designates a PVC segment from User A through Network I to Network J. At the User A to Network I UNI, DLCI 16 is used. At the Network I to Network J NNI, DLCI 32 is used. C The "C" status for a particular PVC segment indicates that the PVC is configured and the PVC status information element is present in the full status report. Not C The "Not C" status for a particular PVC segment indicates that the PVC is not configured and the PVC status information element is not present in the full status report. N The "N" status for a particular PVC segment indicates that the "new" bit is set to 1 in the PVC status information element at the indicated interface. (The absence of an "N" in the diagrams indicates that the "new" bit is set to 0.) A The "A" status for a particular PVC segment indicates that the "active" bit is set to 1 in the PVC status information element at the indicated interface. 48 Part 2 - Subnetworks September 1993 (Stable) I The "I" status for a particular PVC segment indicates that the "active" bit is set to 0 in the PVC status information element at the indicated interface. ChanI The "ChanI" indicates that the channel is inactive at the UNI or NNI due to link integrity verification failure, or other network determined UNI or NNI service affecting condition (e.g., data set signals down). D.4.10.3 Example of adding a multi-network PVC When configuring a multi-network PVC, each PVC segment must be added through its associated network management system. Figure D.3 shows the addition of the multi-network PVC: Network I to User A using DLCI 16; Network I to Network J using DLCI 32; Network J to User B using DLCI 48. Simultaneous configuration of both PVC segments in the multi-network PVC is virtually impossible. After the PVC segment is configured in Network I and before the PVC segment in Network J is configured, Network I may detect that the PVC segment in Network J is not present and informs User A with a full status report indicating that the PVC segment is inactive. Note that the PVC segment has been configured locally and is therefore present (on the user interface to User A) but inactive because it is not configured on the remote network (Network J). As far as User B is concerned, the entire multi-network PVC has not been configured until the PVC segment is configured on its local network (Network J). 49 Part 2 - Subnetworks September 1993 (Stable) Legend - see D.4.10.2 Figure D.3 - Configuration of a multi-network PVC 50 Part 2 - Subnetworks September 1993 (Stable) D.4.10.4 Example of deleting a multi-network PVC When deleting a multi-network PVC, each PVC segment must be deleted through its associated network management system. Figure D.4 shows the deletion of the multi-network PVC: Network I to User A using DLCI 16; Network I to Network J using DLCI 32; Network J to User B using DLCI 48. Simultaneous deletion of both PVC segments in the multi-network PVC is virtually impossible. User A receives a full status report with DLCI 16 deleted (absent) from Network I. After the PVC segment is deleted in Network I and before the PVC segment in Network J is deleted, Network J detects that the PVC segment in Network I is not present and informs User B with a full status report indicating that the PVC segment is inactive. Note that the PVC segment on Network J has not been deleted locally and is therefore present (on the user interface to User B) but inactive because it is not configured on the remote network (Network I). As far as User B is concerned, the multi-network PVC is not deleted until the PVC segment is deleted on its local network (NetworkJ). 51 Part 2 - Subnetworks September 1993 (Stable) Legend - see D.4.10.2 Figure D.4 - Deletion of a multi-network PVC D.4.10.5 Example of UNI failure and restoration Figure D.5 shows the detection of an inactive channel (UNI channel) between User A and Network I (N393 valid polling cycles have not occurred). Network I notifies Network J that DLCI 32 is inactive. The inactive indication is forwarded to the PVC endpoint (User B) on Network J. The active/inactive indication from Network I to Network J is independent of the active/inactive indication from Network J to Network I. In Figure D.5 the active bit is still set to 1 in the PVC Status Information Element for DLCI 32 in the full status reports sent from Network J to Network I. Figure D.5 also shows the detection of an active channel (UNI restoration) between User A and Network I. Network I notifies Network J that DLCI 32 is active. The active indication is forwarded to the PVC endpoint (User B) on Network J. The 52 Part 2 - Subnetworks September 1993 (Stable) active/inactive indication from Network I to Network J is independent of the active/inactive indication from Network J to Network I. 53 Part 2 - Subnetworks September 1993 (Stable) Legend - see D.4.10.2 Figure D.5 - UNI failure and restoration D.4.10.6 Example of PVC segment failure and restoration Figure D.6 shows the failure of a PVC segment in Network I. Network I notifies Network J that DLCI 32 is inactive. The inactive indication is forwarded to the PVC endpoint (User B) on Network J. The active/inactive indication from Network I to Network J is independent of the active/inactive indication from Network J to Network I. In Figure D.6 the active bit is still set to 1 in the PVC status information element for DLCI 32 in the 54 Part 2 - Subnetworks September 1993 (Stable) full status reports sent from Network J to Network I. Figure D.6 also shows the notification of a PVC segment becoming operational in Network I. Network I notifies Network J that DLCI 32 is active. The active indication is forwarded to the PVC endpoint (User B) on Network J. The active/inactive indication from Network I to Network J is independent of the active/inactive indication from Network J to Network I. Legend - see D.4.10.2 Figure D.6 - PVC segment failure and restoration D.4.10.7 Example of NNI failure and restoration Figure D.7 shows the detection of an inactive channel (NNI failure) between Network I and Network J. Network I notifies the UserA that DLCI 16 is inactive. Network J notifies the 55 Part 2 - Subnetworks September 1993 (Stable) User B that DLCI 48 is inactive. Figure D.7 also shows the detection of an active channel (after N393 valid polling cycles) between Network I and Network J. Network I notifies the User A that DLCI 16 is active. Network J notifies the User B that DLCI 48 is active. Legend - see D.4.10.2 Figure D.7 - NNI failure and restoration 56 Part 2 - Subnetworks September 1993 (Stable) 57