idnits 2.17.1 draft-ietf-sigtran-gr303ua-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 178 has weird spacing: '...is used for E...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2002) is 7802 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 387, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 395, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 402, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 409, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 412, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 415, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 3057 (ref. '3') (Obsoleted by RFC 4233) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-02) exists of draft-ietf-sigtran-iua-imp-guide-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Obsolete informational reference (is this intentional?): RFC 3015 (ref. '6') (Obsoleted by RFC 3525) -- Obsolete informational reference (is this intentional?): RFC 2705 (ref. '7') (Obsoleted by RFC 3435) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '8') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '9') (Obsoleted by RFC 4733, RFC 4734) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Ranjith Mukundan 2 Wipro Technologies 3 Ken Morneault 4 Cisco Systems 5 Expires in June 2003 December 2002 7 GR-303 extensions to the IUA protocol 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http//www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http//www.ietf.org/shadow.html. 31 Abstract 33 This document defines a mechanism for backhauling of GR-303 [2] 34 messages over IP by extending the ISDN User Adaptation Layer 35 Protocol [3] and to be the base for a GR-303 User Adaptation (GR- 36 303UA) implementation. 38 Table of Contents 40 1.0 Introduction ..................................................2 41 1.1 Scope ......................................................2 42 1.2 Terminology ................................................3 43 1.3 GR-303 Overview ............................................3 44 1.4 Proposed GR-303 Backhaul Architecture ......................5 45 2.0 Changes from IUA ..............................................6 46 2.1 New Message Classes for GR-303UA ..........................6 47 2.2 Message Header ............................................6 48 2.3 SCTP Stream ID mapping ....................................8 49 3.0 IANA Considerations ...........................................8 50 4.0 Security Considerations .......................................8 51 5.0 References ...................................................9 52 5.1 Normative References .......................................9 53 5.2 Informative References .....................................9 54 6.0 Acknowledgements .............................................10 55 7.0 Author's Addresses ...........................................10 57 1.0 Introduction 59 This document describes a method of implementing GR-303 [2] backhaul 60 messaging over IP using a modified version of the ISDN User 61 Adaptation Protocol (IUAP) [3]. The GR-303UA builds on top of IUA 62 defining the necessary extensions to IUA for GR-303 implementation. 64 1.1 Scope 66 There is a need for Switched Circuit Network (SCN) GR-303 signaling 67 protocol delivery, to cater to two scenarios: 69 Scenario 1: Delivery from a GR-303 Signaling Gateway (SG) to 70 a Media Gateway Controller (MGC). In this scenario, the 71 traditional "TDM-based" Remote Digital Terminal (RDT) will 72 interconnect to a SG. 74 Scenario 2: Delivery from an "IP-based" distributed Remote 75 Digital Terminal (RDT) to a Voice Gateway (VG). In this 76 scenario, the VG will connect to a traditional "TDM-based" 77 Local Digital Switch (LDS). 79 The delivery mechanism should support the following GR-303 protocol 80 entities: 82 - Time-slot Management Channel (TMC) Protocol [2] 83 - Common Signaling Channel (CSC) Protocol [2] 84 - Embedded Operations Channel (EOC) Protocol [2 & 4] 86 Unless specifically mentioned, the details in this document are 87 applicable to all the three aforementioned GR-303 protocol entities. 89 It is to be noted that, owing to the 'hybrid' nature of the GR-303 90 signaling system, in the GR-303 TMC option, call processing and 91 terminal supervision signaling also comprises of specific in-band 92 Robbed Bit Signaling (RBS) signals (ABCD bit patterns) for different 93 types of subscriber-loops (e.g., Ground Start, Loop Start, Loop 94 Reverse Battery etc). To transport the in-band signals over the IP 95 network, other protocols like MEGACO [6]/Media Gateway Control 96 Protocol (MGCP) [7] (with concomitant new or existing MEGACO/MGCP 97 packages) OR RTP [8 & 9] will have to be used in conjunction with 98 GR-303UA. Typically, MEGACO/MGCP would be used in scenario 1 and RTP 99 in Scenario 2. 101 1.2 Terminology 103 Remote Digital Terminal (RDT) - An access system located in the 104 outside plant. RDT's main function is to multiplex traffic from a 105 number of subscriber lines onto a high-speed transmission facility 106 (SONET, DS3, or DS1s) for transport to/from the central office. The 107 maximum number of access lines per RDT is 2048 per interface group. 108 These access lines can be made to share between 1 and 28 DS1s with 109 the flexible concentration supported by GR-303. When the number of 110 DS1 facilities are 2 or more, GR-303 signaling interface 111 specification mandates a stand-by "protection" signaling channel to 112 be supported on a DS1 facility different from the DS1 facility that 113 hosts the primary signaling channels. 115 Integrated Digital Terminal (IDT) - The switch resources used to 116 manage and support a single interface group of the RDT. The IDT 117 interface coordinates operations, administration, and management of 118 the RDT, including facility terminations, control data links, and 119 other functions. 121 Local Digital Switch (LDS) - The switching system (Class-5) located 122 in the central office that provides switched services such as POTS, 123 ISDN, or Centrex to subscriber lines on RDTs. An IDT is a logical 124 entity within the LDS. 126 1.3 GR-303 Overview 128 GR-303 is a Bellcore specification [2] that defines a set of generic 129 interface requirements that allow Class-5 digital switches from one 130 vendor to interface with access systems from another. Access 131 systems include digital loop carriers (DLCs) or hybrid fiber/coax 132 residential broadband systems that are typically used to provide 133 service to remote concentration groups, as well as extending the 134 service areas. 136 The Figure 1 below shows the major building blocks of an Integrated 137 Digital Loop Carrier (IDLC) using GR-303 interface. An IDLC system 138 consists of an integrated digital terminal (IDT) located in the 139 switch and a remote digital terminal (RDT) located in the outside 140 plant or in some cases at the customer premise. GR-303 provides for 141 flexible concentration of bandwidth into the LDS for analog 142 services, and 4:1 Integrated Service Digital Network (ISDN) Basic 143 Rate Access (BRA). In addition, it provides extensive Operations, 144 Administration, Management & Provisioning (OAM&P) capabilities for 145 managing RDTs. 147 +-----------+ GR-303 interface 148 | LDS | Group (1 - 28 DS1s) 149 | | +--------+ o--o 150 | | DS1 | |------- /\ 151 | +------|---------------------| | -- 152 | | IDT | DS1 | RDT | 153 | +------|---------------------| | o--o 154 | | | |------- /\ 155 +-----------+ +--------+ -- 157 |<---------- IDLC system ------------->| 159 Figure 1 GR-303 IDLC System 161 The maximum number of DS0s supported is 672. Four of these DS0s 162 are reserved for signaling (EOC and TMC/CSC on primary DS1, EOC and 163 TMC/CSC on protection DS1). 165 The GR-303 interface is composed of 1 to 28 DS-1 facilities 166 connecting the IDT at the central office and the RDT. Standby 167 signaling channel protection is not available when there is only D1 168 in the GR-303 interface. For GR-303 interface spanning 2 or more 169 (upto 28) DS1s, two of these DS-1 facilities carry signaling 170 channels. The first carries the primary signaling channels, while a 171 separate DS-1 facility is used to carry the redundant signaling 172 channels for protection. 174 GR-303 defines three types of message-based signaling channels 176 1. Embedded Operations Channel (EOC) - Uses a DS0 (64kbps, clear 177 channel) on the primary DS1 facility (time slot # 12). And another 178 DS0 is used for EOC protection on a separate DS1 facility. The EOC 179 channel is primarily used for carrying Path Protection Switching (PPS) 180 and OAM&P-related messaging. The higher layer protocols used with 181 this channel include LAPD subset for layer 2, Convergence sub-layer & 182 Common Management Information Service Element (CMISE)/Remote 183 Operations Services Element (ROSE)/ASN.1 sub-layer for layer 3. 185 2. Timeslot Management Channel (TMC) - Uses a DS0 (64kbps, clear 186 channel) on the primary DS1 facility (time slot # 24). And another 187 DS0 is used for TMC protection on a separate DS1 facility. The TMC 188 channel is primarily used to perform per-call time-slot allocation 189 and call processing messages between the RDT and the LDS. The 190 higher layer protocols used with this channel are LAPD subset for 191 layer 2, and a subset of Q.931 for layer 3. 193 As mentioned earlier in this document, when TMC is used, the bearer 194 channels will still need to use RBS for transmitting call-processing 195 and subscriber line supervision in-band messages between the RDT and 196 the LDS. In other words, signaling between the RDT and IDT is a 197 hybrid of time slot management channel and robbed-bit (TMC/RBS) 198 signaling. 200 3. Common Signaling Channel (CSC) - This signaling channel is an 201 option that is used instead of TMC for clean out-of-band signaling 202 implementation. In this case, bearer channels are not required to 203 carry RBS since CSC messages handle both call supervision and time 204 slot assignment. The higher layer protocols used with this channel 205 are LAPD subset for layer 2, and a subset of Q.931 for layer 3. 207 1.4 Proposed GR-303 Backhaul Architecture 209 Figure 2 below, depicts the backhaul architecture for the two 210 scenarios described earlier. 212 Scenario 1 214 ****** GR-303 ****** IP ******* 215 *RDT *---------------* SG *--------------* MGC * 216 ****** ****** ******* 218 Scenario 2 220 ****** GR-303 ****** IP ******** 221 *LDS *---------------* VG *--------------*IP-RDT* 222 * * *(SG)* * * 223 ****** ****** ******** 225 +-----+ +-------+ 226 |GR303| (NIF) | GR303 | 227 | L3 | | L3 | 228 +-----+ +-----+-------+ +-------+ 229 | | | |GR303UA| |GR303UA| 230 |GR303| |GR303+-------+ +-------+ 231 | L2 | | L2 | SCTP | | SCTP | 232 | | | +-------+ +-------+ 233 | | | | IP | | IP | 234 +-----+ +-----+-------+ +-------+ 236 Figure 2 GR-303 Backhaul Architecture 238 NIF - Nodal Interworking function 239 SCTP - Stream Control Transmission Protocol 240 GR303UA - GR-303 User Adaptation Layer Protocol 241 GR303 L2 - A subset of LAPD 242 GR303 L3 - TMC/CSC (a Q.931 subset) OR 243 EOC Convergence & CMISE/ROSE/ASN.1 sub-layers 245 2.0 Changes from IUA 247 This section outlines the differences between GR-303UA and IUA. 249 2.1 New Message Classes for GR-303UA 251 The GR-303 TMC/CSC and EOC Layer 2 to Layer 3 primitives need to be 252 handled in a different way from the IUA boundary primitive transport 253 messages and the boundary primitive transport messages of other 254 IUA extensions (i.e. V5 or DPNSS). Therefore, it is neccessary to 255 distinguish between these from other IUA-based boundary primitive 256 transport message types [3] by means of the Message Class parameter. 258 In order to support GR-303 layer 2 <=> layer 3 interface boundary 259 primitives, the following Message Classes are introduced (to be 260 assigned by IANA): 262 12 GR-303 EOC Boundary Primitives Transport Messages (GEPTM) 263 13 GR-303 TMC/CSC Boundary Primitives Transport Messages (GXPTM) 265 Similar to IUA, other valid message classes for GR-303UA are the 266 following: 268 0 Management (MGMT) Message 269 3 ASP State Maintenance (ASPSM) Messages 270 4 ASP Traffic Maintenance (ASPTM) Messages 272 2.2 Message Header 274 IUA Message header [3] has the format as shown in Figure 3 below. 275 GR-303UA, being extension of IUA, will have the same format. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Tag (0x1) | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Interface Identifier | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | DLCI | Spare | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3 IUA Message Header 289 Where, the Tag value for the Integer-based Interface Identifier is 290 0x1. The length is always set to a value of 8. 292 And the DLCI format is shown below in Figure 4. 294 0 1 2 3 4 5 6 7 295 +-----+-----+-----+-----+-----+-----+-----+-----+ 296 | 0 | SPR | SAPI | 297 +-----------------------------------------------+ 298 | 1 | TEI | 299 +-----------------------------------------------+ 301 Figure 4 DLCI Format 303 SPR : Spare 2nd bit in octet 1, (1 bit) 304 SAPI: Service Access Point Identifier, 3rd through 8th bits in octet 305 1 (6 bits) 306 TEI : Terminal Endpoint Identifier, 2nd through 8th bits in octet 2 307 (7 bits) 309 The DLCI field (including the SAPI and TEI) is coded in accordance 310 with Q.921. 312 The following SAPI/TEI combinations shall be supported for GR-303 313 TMC/CSC and EOC 315 TMC Data-link function 316 ---------------------- 318 SAPI TEI 319 ------------------------------------------ 320 Call Processing 0 0 321 TMC Path Switch Ops 1 0 323 EOC Data-link function 324 ---------------------- 326 SAPI TEI 327 ---------------------------------------------------- 328 TMC Path Switch Ops 1 0 329 RDT - Provisioning/Mem Admin 1 1 330 RDT - Maint/Surveillance OS 1 2 331 RDT - Testing OS 1 3 332 RDT - IDT 1 4 333 RDT - Test System Controller 1 1 5 334 RDT - Test System Controller 2 1 6 335 RDT - Test System Controller 3 1 7 336 user assignable 1 8 337 user assignable 1 9 338 user assignable 1 10 339 user assignable 1 11 341 2.3 SCTP Stream ID Mapping 343 It is recommended that the primary and secondary EOC, TMC/CSC 344 channels' interface identifiers be mapped to separate SCTP 345 stream IDs. 347 3.0 IANA Considerations 349 A request will be made to IANA to assign a GR-303UA value for the 350 SCTP Payload Protocol Identifier field used in SCTP Payload Data 351 chunks. 353 The following value for the SCTP Payload Protocol Identifier field 354 should be used for GR-303UA: 356 SCTP Payload Protocol ID xxx - tba by IANA 358 The SCTP Payload Protocol Identifier is included in each SCTP Data 359 chunk, to indicate which protocol the SCTP is carrying. This 360 Payload Protocol Identifier is not directly used by SCTP but may be 361 used by certain network entities to identify the type of information 362 being carried in a Data chunk. 364 The User Adaptation peer may use the Payload Protocol Identifier as 365 a way of determining whether the message is for IUA, V5UA, DUA or 366 GR-303UA. 368 4.0 Security Considerations 370 The security considerations discussed for the IUA [3] Section 6.0 371 apply to this document as well. 373 5.0 References 375 5.1 Normative References 377 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 378 RFC 2026, October 1996. 380 [2] GR-303-CORE Issue 4, "IDLC Generic Requirements, Objectives, and 381 Interface", December 2000 and the associated Issues List Report GR- 382 303-ILR Issue 4A, December 2000. 384 [3] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, 385 February 2001. 387 [4] GR-303-IMD, "IDLC System Generic Operations Interface" (formerly 388 TR-TSY-000303 Supplement 3), Issue 1, December 1998 390 [5] IUA (RFC3057) Implementors Guide, draft-ietf-sigtran-iua-imp- 391 guide-01.txt, Oct 2002 393 5.2 Informative References 395 [6] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. 396 Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. 398 [7] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S., 399 "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 400 1999. 402 [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP 403 A Transport Protocol for Real-Time Applications", RFC 1889, January 404 1996. 406 [9] Schulzrinne, H. and Petrack, S., "RTP Payload for DTMF Digits, 407 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 409 [10] TR-NWT-000057, "Functional Criteria for Digital Loop Carrier 410 Systems", Issue 2, January 1993. 412 [11] ANSI T1.403, "Network and Customer Installation Interfaces - DS1 413 Electrical Interface", May 1999. 415 [12] ANSI T1.403.02, "Network and Customer Installation Interfaces - 416 DS1 Robbed-Bit Signaling State Definition", May 1999. 418 6.0 Acknowledgments 420 None 422 7.0 Author's Addresses 424 Ranjith Mukundan Phone +91-80-8520408 425 Wipro Technologies Email ranjith.mukundan@wipro.com 426 72, Electronics City, 427 Hosur Main Road, 428 Bangalore 561229 429 India 431 Ken Morneault Phone +1-703-484-3323 432 Cisco Systems Inc. EMail kmorneau@cisco.com 433 13615 Dulles Technology Drive 434 Herndon, VA. 20171 435 USA