| draft-ranjith-sigtran-gr303ua-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ranjith-sigtran-gr303ua-00.txt. Internet Engineering Task Force Ranjith Mukundan Wipro Technologies Ken Morneault Cisco Systems Expires in six months October 2002 GR-303 extensions to the IUA protocol <draft-ranjith-sigtran-gr303ua-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http//www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http//www.ietf.org/shadow.html. Abstract This document defines a mechanism for backhauling of GR-303 [2] messages over IP by extending the ISDN User Adaptation Layer Protocol [3] and to be the base for a GR-303 User Adaptation (GR- 303UA) implementation. Table of Contents 1.0 Introduction ..................................................2 1.1 Scope ......................................................2 1.2 Terminology ................................................3 1.3 GR-303 Overview ............................................3 1.4 Proposed GR-303 Backhaul Architecture ......................5 2.0 Changes from IUA ..............................................6 2.1 New Message Classes for GR-303UA ..........................6 2.2 Message Header ............................................6 3.0 IANA Considerations ...........................................8 4.0 Security Considerations .......................................8 5.0 References ...................................................9 Ranjith Mukundan/Ken Morneault [Page 1] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 5.1 Normative References .......................................9 5.2 Informative References .....................................9 6.0 Acknowledgements .............................................10 7.0 Author's Addresses ...........................................10 1.0 Introduction This document describes a method of implementing GR-303 [2] backhaul messaging over IP using a modified version of the ISDN User Adaptation Protocol (IUAP) [3]. The GR-303UA builds on top of IUA defining the necessary extensions to IUA for GR-303 implementation. 1.1 Scope There is a need for Switched Circuit Network (SCN) GR-303 signaling protocol delivery, to cater to two scenarios: Scenario 1: Delivery from a GR-303 Signaling Gateway (SG) to a Media Gateway Controller (MGC). In this scenario, the traditional "TDM-based" Remote Digital Terminal (RDT) will interconnect to a SG. Scenario 2: Delivery from an "IP-based" distributed Remote Digital Terminal (RDT) to a Voice Gateway (VG). In this scenario, the VG will connect to a traditional "TDM-based" Local Digital Switch (LDS). The delivery mechanism should support the following GR-303 protocol entities: - Time-slot Management Channel (TMC) Protocol [2] - Common Signaling Channel (CSC) Protocol [2] - Embedded Operations Channel (EOC) Protocol [2 & 4] Unless specifically mentioned, the details in this document are applicable to all the three aforementioned GR-303 protocol entities. It is to be noted that, owing to the 'hybrid' nature of the GR-303 signaling system, in the GR-303 TMC option, call processing and terminal supervision signaling also comprises of specific in-band Robbed Bit Signaling (RBS) signals (ABCD bit patterns) for different types of subscriber-loops (e.g., Ground Start, Loop Start, Loop Reverse Battery etc). To transport the in-band signals over the IP network, other protocols like MEGACO [6]/Media Gateway Control Protocol (MGCP) [7] (with concomitant new or existing MEGACO/MGCP packages) OR RTP [8 & 9] will have to be used in conjunction with GR-303UA. Typically, MEGACO/MGCP would be used in scenario 1 and RTP in Scenario 2. Ranjith Mukundan/Ken Morneault [Page 2] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 1.2 Terminology Remote Digital Terminal (RDT) - An access system located in the outside plant. RDT's main function is to multiplex traffic from a number of subscriber lines onto a high-speed transmission facility (SONET, DS3, or DS1s) for transport to/from the central office. The maximum number of access lines per RDT is 2048 per interface group. These access lines can be made to share between 1 and 28 DS1s with the flexible concentration supported by GR-303. When the number of DS1 facilities are 2 or more, GR-303 signaling interface specification mandates a stand-by "protection" signaling channel to be supported on a DS1 facility different from the DS1 facility that hosts the primary signaling channels. Integrated Digital Terminal (IDT) - The switch resources used to manage and support a single interface group of the RDT. The IDT interface coordinates operations, administration, and management of the RDT, including facility terminations, control data links, and other functions. Local Digital Switch (LDS) - The switching system (Class-5) located in the central office that provides switched services such as POTS, ISDN, or Centrex to subscriber lines on RDTs. An IDT is a logical entity within the LDS. 1.3 GR-303 Overview GR-303 is a Bellcore specification [2] that defines a set of generic interface requirements that allow Class-5 digital switches from one vendor to interface with access systems from another. Access systems include digital loop carriers (DLCs) or hybrid fiber/coax residential broadband systems that are typically used to provide service to remote concentration groups, as well as extending the service areas. The Figure 1 below shows the major building blocks of an Integrated Digital Loop Carrier (IDLC) using GR-303 interface. An IDLC system consists of an integrated digital terminal (IDT) located in the switch and a remote digital terminal (RDT) located in the outside plant or in some cases at the customer premise. GR-303 provides for flexible concentration of bandwidth into the LDS for analog services, and 4:1 Integrated Service Digital Network (ISDN) Basic Rate Access (BRA). In addition, it provides extensive Operations, Administration, Management & Provisioning (OAM&P) capabilities for managing RDTs. Ranjith Mukundan/Ken Morneault [Page 3] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 +-----------+ GR-303 interface | LDS | Group (1 - 28 DS1s) | | +--------+ o--o | | DS1 | |------- /\ | +------|---------------------| | -- | | IDT | DS1 | RDT | | +------|---------------------| | o--o | | | |------- /\ +-----------+ +--------+ -- |<---------- IDLC system ------------->| Figure 1 GR-303 IDLC System The maximum number of DS0s supported is 672. Four of these DS0s are reserved for signaling (EOC and TMC/CSC on primary DS1, EOC and TMC/CSC on protection DS1). The GR-303 interface is composed of 1 to 28 DS-1 facilities connecting the IDT at the central office and the RDT. Standby signaling channel protection is not available when there is only D1 in the GR-303 interface. For GR-303 interface spanning 2 or more (upto 28) DS1s, two of these DS-1 facilities carry signaling channels. The first carries the primary signaling channels, while a separate DS-1 facility is used to carry the redundant signaling channels for protection. GR-303 defines three types of message-based signaling channels 1. Embedded Operations Channel (EOC) - Uses a DS0 (64kbps, clear channel) on the primary DS1 facility (time slot # 12). And another DS0 is used for EOC protection on a separate DS1 facility. The EOC channel is primarily used for carrying Path Protection Switching (PPS) and OAM&P-related messaging. The higher layer protocols used with this channel include LAPD subset for layer 2, Convergence sub-layer & Common Management Information Service Element (CMISE)/Remote Operations Services Element (ROSE)/ASN.1 sub-layer for layer 3. 2. Timeslot Management Channel (TMC) - Uses a DS0 (64kbps, clear channel) on the primary DS1 facility (time slot # 24). And another DS0 is used for TMC protection on a separate DS1 facility. The TMC channel is primarily used to perform per-call time-slot allocation and call processing messages between the RDT and the LDS. The higher layer protocols used with this channel are LAPD subset for layer 2, and a subset of Q.931 for layer 3. Ranjith Mukundan/Ken Morneault [Page 4] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 As mentioned earlier in this document, when TMC is used, the bearer channels will still need to use RBS for transmitting call-processing and subscriber line supervision in-band messages between the RDT and the LDS. In other words, signaling between the RDT and IDT is a hybrid of time slot management channel and robbed-bit (TMC/RBS) signaling. 3. Common Signaling Channel (CSC) - This signaling channel is an option that is used instead of TMC for clean out-of-band signaling implementation. In this case, bearer channels are not required to carry RBS since CSC messages handle both call supervision and time slot assignment. The higher layer protocols used with this channel are LAPD subset for layer 2, and a subset of Q.931 for layer 3. 1.4 Proposed GR-303 Backhaul Architecture Figure 2 below, depicts the backhaul architecture for the two scenarios described earlier. Scenario 1 ****** GR-303 ****** IP ******* *RDT *---------------* SG *--------------* MGC * ****** ****** ******* Scenario 2 ****** GR-303 ****** IP ******** *LDS *---------------* VG *--------------*IP-RDT* * * *(SG)* * * ****** ****** ******** +-----+ +-------+ |GR303| (NIF) | GR303 | | L3 | | L3 | +-----+ +-----+-------+ +-------+ | | | |GR303UA| |GR303UA| |GR303| |GR303+-------+ +-------+ | L2 | | L2 | SCTP | | SCTP | | | | +-------+ +-------+ | | | | IP | | IP | +-----+ +-----+-------+ +-------+ Figure 2 GR-303 Backhaul Architecture Ranjith Mukundan/Ken Morneault [Page 5] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 NIF - Nodal Interworking function SCTP - Stream Control Transmission Protocol GR303UA - GR-303 User Adaptation Layer Protocol GR303 L2 - A subset of LAPD GR303 L3 - TMC/CSC (a Q.931 subset) OR EOC Convergence & CMISE/ROSE/ASN.1 sub-layers 2.0 Changes from IUA This section outlines the differences between GR-303UA and IUA. 2.1 New Message Classes for GR-303UA The GR-303 TMC/CSC and EOC Layer 2 to Layer 3 primitives need to be handled in a different way from the IUA boundary primitive transport messages and the boundary primitive transport messages of other IUA extensions (i.e. V5 or DPNSS). Therefore, it is neccessary to distinguish between these from other IUA-based boundary primitive transport message types [3] by means of the Message Class parameter. In order to support GR-303 layer 2 <=> layer 3 interface boundary primitives, the following Message Classes are introduced (to be assigned by IANA): 12 GR-303 EOC Boundary Primitives Transport Messages (GEPTM) 13 GR-303 TMC/CSC Boundary Primitives Transport Messages (GXPTM) Similar to IUA, other valid message classes for GR-303UA are the following: 0 Management (MGMT) Message 3 ASP State Maintenance (ASPSM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages 2.2 Message Header IUA Message header [3] has the format as shown in Figure 3 below. GR-303UA, being extension of IUA, will have the same format. Ranjith Mukundan/Ken Morneault [Page 6] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI | Spare | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 IUA Message Header Where, the Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8. And the DLCI format is shown below in Figure 4. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | SPR | SAPI | +-----------------------------------------------+ | 1 | TEI | +-----------------------------------------------+ Figure 4 DLCI Format SPR : Spare 2nd bit in octet 1, (1 bit) SAPI: Service Access Point Identifier, 3rd through 8th bits in octet 1 (6 bits) TEI : Terminal Endpoint Identifier, 2nd through 8th bits in octet 2 (7 bits) The DLCI field (including the SAPI and TEI) is coded in accordance with Q.921. The following SAPI/TEI combinations shall be supported for GR-303 TMC/CSC and EOC TMC Data-link function ---------------------- SAPI TEI ------------------------------------------ Call Processing 0 0 TMC Path Switch Ops 1 0 Ranjith Mukundan/Ken Morneault [Page 7] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 EOC Data-link function ---------------------- SAPI TEI ---------------------------------------------------- TMC Path Switch Ops 1 0 RDT - Provisioning/Mem Admin 1 1 RDT - Maint/Surveillance OS 1 2 RDT - Testing OS 1 3 RDT - IDT 1 4 RDT - Test System Controller 1 1 5 RDT - Test System Controller 2 1 6 RDT - Test System Controller 3 1 7 user assignable 1 8 user assignable 1 9 user assignable 1 10 user assignable 1 11 3.0 IANA Considerations A request will be made to IANA to assign a GR-303UA value for the SCTP Payload Protocol Identifier field used in SCTP Payload Data chunks. The following value for the SCTP Payload Protocol Identifier field should be used for GR-303UA: SCTP Payload Protocol ID xxx - tba by IANA The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, to indicate which protocol the SCTP is carrying. This Payload Protocol Identifier is not directly used by SCTP but may be used by certain network entities to identify the type of information being carried in a Data chunk. The User Adaptation peer may use the Payload Protocol Identifier as a way of determining whether the message is for IUA, V5UA, DUA or GR-303UA. 4.0 Security Considerations The security considerations discussed for the IUA [3] Section 6.0 apply to this document as well. Ranjith Mukundan/Ken Morneault [Page 8] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 5.0 References 5.1 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] GR-303-CORE Issue 4, "IDLC Generic Requirements, Objectives, and Interface", December 2000 and the associated Issues List Report GR- 303-ILR Issue 4A, December 2000. [3] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001. [4] GR-303-IMD, "IDLC System Generic Operations Interface" (formerly TR-TSY-000303 Supplement 3), Issue 1, December 1998 [5] IUA (RFC3057) Implementors Guide, draft-ietf-sigtran-iua-imp- guide-01.txt, Oct 2002 5.2 Informative References [6] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. [7] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S., "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999. [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [9] Schulzrinne, H. and Petrack, S., "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [10] TR-NWT-000057, "Functional Criteria for Digital Loop Carrier Systems", Issue 2, January 1993. [11] ANSI T1.403, "Network and Customer Installation Interfaces - DS1 Electrical Interface", May 1999. [12] ANSI T1.403.02, "Network and Customer Installation Interfaces - DS1 Robbed-Bit Signaling State Definition", May 1999. Ranjith Mukundan/Ken Morneault [Page 9] Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002 6.0 Acknowledgments None 7.0 Author's Addresses Ranjith Mukundan Phone +91-80-8520408 Wipro Technologies Email ranjith.mukundan@wipro.com 72, Electronics City, Hosur Main Road, Bangalore 561229 India Ken Morneault Phone +1-703-484-3323 Cisco Systems Inc. EMail kmorneau@cisco.com 13615 Dulles Technology Drive Herndon, VA. 20171 USA Ranjith Mukundan/Ken Morneault [Page 10] | ||||||||||||||||
Last modified: Mon, 26 Aug 2024 23:57:29 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. |