idnits 2.17.1 draft-bouwen-megaco-isdn-bcp-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 11) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 2001) is 8471 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 488, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3015 (ref. '1') (Obsoleted by RFC 3525) ** Obsolete normative reference: RFC 2960 (ref. '2') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3057 (ref. '3') (Obsoleted by RFC 4233) == Outdated reference: A later version (-01) exists of draft-rosen-megaco-namepatterns-00 == Outdated reference: A later version (-01) exists of draft-bouwen-sigtran-il1a-00 Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Megaco & Sigtran WG J. Bouwen 3 Internet Draft Alcatel 4 Document: K. Morneault 5 Category: Informational Cisco 7 February 2001 9 Best Current Practice for Megaco-Sigtran Interaction 10 in ISDN Access Gateways 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 A Media Gateway with ISDN terminations will use both Megaco [1] and 33 Sigtran protocols for communication with the Media Gateway 34 Controller. In an ISDN Access Gateway the media carrying B-channels 35 are controlled by the Media Gateway Controller using Megaco, while 36 the User-to-Network signalling running over the D-channels will be 37 relayed to the Media Gateway Controller using Sigtran protocols (IUA 38 [3] over SCTP [2]). 39 At the moment, in the absence of appropriate specifications, the 40 Megaco and Sigtran protocols may interact in different ways in the 41 Access Gateway, leaving room for non-interoperable solutions. 42 This draft proposes a set of guidelines for the Megaco-Sigtran 43 interworking, documenting a best current practice for ISDN Access 44 Gateways. 46 2. Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 50 this document are to be interpreted as described in RFC-2119 [1]. 52 Bouwen & Morneault Expires August 2001 1 53 3. ISDN Termination Terminology and ISDN Media Gateway Architecture 55 This section defines basic ISDN terminology based on Q.920 [5] and 56 I.412 [6]. 58 An ISDN termination typically exists of a number of B channels and 59 one D channel. 61 A B-channel is a 64 kbit/s channel for the transfer of user 62 information streams 64 A D-channel carries signaling information for circuit switching by 65 the ISDN. 67 Typical ISDN interface structures are: 69 Basic access (BA) 70 2B+D 71 ETSI, ANSI 72 The bit rate of the D-channel in this interface structure is 16 73 kbit/s 75 2048 kbit/s Primary rate access (PRA): 76 30B+D 77 ETSI 78 The bit rate of the D-channel in the primary rate access 79 structure is 64 kbit/s 81 1544 kbit/s Primary rate interface (PRI) 82 23B+D 83 ANSI 84 The bit rate of the D-channel in the primary rate interface 85 structure is 64 kbit/s 87 The D-channel uses a layered protocol according to ITU-T 88 recommendations Q.920, Q.921, Q.930 and Q.931. The Q.921 Data Link 89 uses the DLCI to identify a connection. Figure 1 shows the use of 90 the DLCI. 92 DLCI Data Link Connection Identifier 93 An address conveyed in a Q.921 message which indicates 94 the source and destination of an intended instance of 95 communication at the data link layer 96 The DLCI is the combination of the TEI and the SAPI 98 SAPI Service Access Point Identifier 99 Portion of the DLCI associated with the service access 100 point on the network side or the user side of the user- 101 network interface. The Service Access Point is the point 102 at which the Q.921 data link layer provides services to 103 layer 3 (Q.931). 104 TEI Terminal Endpoint Identifier 105 Portion of a DLCI associated with one (point-to-point 107 Bouwen & Morneault Expires August 2001 2 108 data link) or more than one (broadcast data link) 109 terminal equipment. The TEI is used to identify a 110 specific connection endpoint within a Service Access 111 Point. 113 ########################### ########################### C P 114 # Terminal 1 # # Terminal 2 # U R 115 # # # # S E 116 # +--------+ +--------+ # # +---------+ # T M 117 # | Packet | | Q.931 | # # | Q.931 | # O I 118 # | Data | | Sign. | # # | Sign. | # M S 119 # +--------+ +--------+ # # +---------+ # E E 120 # | | # # |...| # R S 121 # /|\ SAPI /|\ SAPI # # /| |\ SAPI # ' 122 # \|/ 16 \|/ 0 # # \|...|/ 0 # S 123 # | | # # | | # 124 ######|###########|######## ###########|###|########### 125 | | | | 126 |TEI88 |TEI88 TEI3| |TEI8 127 | | | | 128 | +--------+ +------------+ | 129 +------------------+ | | +--------------+ 130 | | | | 131 | | | | 132 -->| | | |<--D-Channel 133 | | | | 134 | | | +---------------+ N 135 +-----------+ | +-------------+ | E 136 | +-----------+ | | T 137 | | | | W 138 / \ SAPI /|'''|'''|\ SAPI O 139 \ / 16 \|...|...|/ 0 R 140 | | | | K 141 +--------+ +---------+ 142 | Packet | | Q.931 | 143 | Data | | Sign. | 144 +--------+ +---------+ 146 DLCI = SAPI + TEI 148 Figure 1 - Relationship between SAPI, TEI and DLCI (based on [5]) 150 Signaling information arrives in the ISDN Access Gateway over the D- 151 channel, and has to be forwarded to the call control intelligence in 152 the Media Gateway Controller. In this way an ISDN Access Gateway 153 contains Signaling Gateway functionality. 155 4. ISDN Signaling Backhaul 157 In the decomposed architecture of Media Gateways and Media Gateway 158 Controllers, the call control intelligence resides in the Media 159 Gateway Controller. This implies the call control signaling, which 161 Bouwen & Morneault Expires August 2001 3 162 is transported in the SCN over the D-channel as Q.931 messages, has 163 to be relayed from the Media Gateway to the Media Gateway Controller 164 and vice versa. The signaling transport protocols developed in the 165 Sigtran WG are used for this purpose. 167 It involves the generic signaling transport protocol SCTP [2], and 168 the ISDN Q.921 Adaptation Layer (IUA) [3]. Figure 2 shows the 169 envisaged architecture. An SCTP association is set up between the 170 Media Gateway and the Media Gateway Controller for the relay of 171 Q.931 signaling and Q.921 management information. The SCTP 172 association contains unidirectional streams. 173 * Every D-channel is mapped to an MG->MGC stream and an MGC->MG 174 stream. 175 * For a particular D-channel, the same stream identification number 176 in both directions should be used (but not necessarily). 178 In addition, in IUA, the physical interface associated with the D- 179 channel is assigned an Interface Identifier. The Interface 180 Identifier can be a locally unique 32-bit integer or text string. 182 The Media Gateway Controller uses Megaco/H.248 to create and remove 183 media contexts containing B-channel terminations. Signaling 184 associated with the B-channels is transferred between Media Gateway 185 and Media Gateway Controller as unmodified Q.931 binary messages. 187 #################### ################ 188 # # # # 189 # # # # 190 # # # +--------+ # 191 # # SCTP # | Q.931 | # 192 # # Association # | Sign. | # 193 # +-----+----+ # | # +--------+ # 194 # | | IUA| # | # | IUA | # 195 # ****|Q.921|----+ # v # +--------+ # 196 # * **| |SCTP|********************** SCTP | # 197 D*********#** * +-----+----+ # # +--------+ # 198 B1---------#- * +-----+ # # # 199 B2---------#---*-|-o o-|-----------> RTP # # 200 # * +-----+ # (Media) # # 201 # * # # # 202 D*********#**** # # # 203 B1---------#- +-----+ # # # 204 B2---------#-----|-o o-|-----------> RTP # # 205 . # +-----+ # (Media) # # 206 . # # # # 207 B31---------#- # # # 208 # # # # 209 #################### ################ 211 Media Gateway Media Gateway 212 Controller 213 Figure 2 - Megaco + IUA/SCTP Architecture 215 Bouwen & Morneault Expires August 2001 4 216 5. Naming of ISDN Terminations 218 The Megaco/H.248 protocol specification doesn't contain any 219 recommendation for the naming of terminations. The attribution of 220 names is a matter of implementation. 222 The naming pattern can be pre-configured in both the Media Gateway 223 and the Media Gateway Controller, or the Media Gateway Controller 224 can use the Name Pattern Package [8] to retrieve the name pattern 225 implemented by the Media Gateway. 227 The termination name could be used as the text-based Interface 228 Identifier in IUA [3]. However, consideration should be given to 229 the fact that the Interface Identifier is passed in all QPTM 230 messages. Thus, there would be some additional overhead associated 231 with a lengthy text-based Interface Identifier. 233 6. Visibility of the D-channel for Megaco 235 The Megaco implementation can be unaware of the existence of D- 236 channels, and only be involved with the establishment of media 237 contexts containing B-channels. It is however preferred to make the 238 D-channels visible for Megaco for management purposes. Megaco should 239 not be used to perform connection control on D-channels (i.e. moving 240 D-channels in and out of contexts). The visibility of the D-channel 241 is intended to 242 * allow use of ServiceChange on the D-channel 243 * allow auditing of the D-channel 244 * allow use of the same termination identifier for D-channels in 245 Megaco and IUA. 247 7. Synchronisation of Megaco ServiceChange and SCTP Association 248 initiation/termination 250 At start-up the Media Gateway informs the Media Gateway Controller 251 of its existence with a Megaco/H.248 ServiceChange message. The next 252 step is the initiation of an SCTP association for the signaling 253 backhaul, assuming that no SCTP association has been created between 254 the Media Gateway Controller and the ISDN acces gateway as a 255 transport layer for the megaco/H.248 protocol. 257 The megaco/H.248 protocol can use SCTP as a transport via annex H. 258 If SCTP is used, it is recommended that megaco/H.248 and IUA use 259 different SCTP associations instead of sharing an association. 261 Table 1 lists the dependencies between ServiceChange messages and 262 the management of the SCTP association and the IUA layer. Following 263 assumptions have been made: 265 Bouwen & Morneault Expires August 2001 5 266 1. The table assumes that Megaco/H.248 itself does not run over 267 SCTP. 268 2. The table assumes the Media Gateway is the Sigtran client and the 269 Media Gateway Controller is the Sigtran server. 270 3. The table assumes that the Media Gateway has/establishes SCTP 271 associations to the main Media Gateway Controller MGC1 and its 272 backup MGC2. 273 4. The synchronization requirements for a Restart, a Graceful or 274 Forced Shutdown are valid when the complete Media Gateway is 275 affected (i.e. the referenced termination is 'root'), or when the 276 complete set of available ISDN terminations is involved (i.e. the 277 ISDN part of the Media Gateway). For the restart of shutdown of 278 one ISDN termination, no changes in the SCTP association are 279 required (since once the SCTP association has been established, 280 there is no need to set up or tear down the streams inside the 281 association). 283 +==================================================================+ 284 |Megaco/H.248 ServiceChange | SCTP Association | 285 +==================================================================+ 286 | RESTART (Root or all ISDN terms)| INIT SCTP Associations to MGC1 | 287 | | and MGC2 by Media Gateway | 288 +------------------------------------------------------------------+ 289 | GRACEFUL Shutdown (Root or all | TERMINATE SCTP Associations to | 290 | ISDN terminations) | MGC1 and MGC2 by Media Gateway | 291 +------------------------------------------------------------------+ 292 | FORCED Shutdown (Root or all | ABORT SCTP Associations to | 293 | ISDN terminations) | MGC1 and MGC2 by Media Gateway | 294 +------------------------------------------------------------------+ 295 | DISCONNECTED | Check if SCTP Association(s) | 296 | | are still operational, INIT | 297 | | otherwise | 298 +------------------------------------------------------------------+ 299 | HANDOFF (sent by MGC1 to MG, to | MGC1 sends IUA ASP Inactive, | 300 | hand off from MGC1 to MGC2) | MG sends Notify to MGC2 | 301 | | MGC2 sends IUA ASP Active | 302 +------------------------------------------------------------------+ 303 | FAILOVER (sent by MG1 to MGC, to| 1. If SCTP Association between | 304 | change from MG1 to MG2) | MG1 and MGC was not aborted,| 305 | | ABORT by MGC | 306 | | 2. INIT SCTP Assoc. to MGC1 | 307 | | and MGC2 by MG2 | 308 +------------------------------------------------------------------+ 309 | MGC1 Failure (no ServiceChange) | MG sends Notify to MGC2 | 310 | Search for available MGC, find | MGC2 sends IUA ASP Active | 311 | MGC2 | | 312 +==================================================================+ 314 Table 1 - Synchronization between ServiceChange 315 and SCTP Association Management 317 Bouwen & Morneault Expires August 2001 6 318 Table 2 below is the same as Table 1 except the MG is the SIGTRAN 319 server and the MGC is the SIGTRAN client. 321 +==================================================================+ 322 | Megaco/H.248 ServiceChange | SCTP Association | 323 +==================================================================+ 324 | RESTART (Root or all ISDN terms)| MGC1 and MGC2 INIT SCTP | 325 | | Associations to Media Gateway | 326 +------------------------------------------------------------------+ 327 | GRACEFUL Shutdown (Root or all | TERMINATE SCTP Associations to | 328 | ISDN terminations) | MGC1 and MGC2 by Media Gateway | 329 +------------------------------------------------------------------+ 330 | FORCED Shutdown (Root or all | ABORT SCTP Associations to | 331 | ISDN terminations) | MGC1 and MGC2 by Media Gateway | 332 +------------------------------------------------------------------+ 333 | DISCONNECTED | Check if SCTP Association(s) | 334 | | are still operational, INIT | 335 | | otherwise | 336 +------------------------------------------------------------------+ 337 | HANDOFF (sent by MGC1 to MG, to | MGC1 sends IUA ASP Inactive, | 338 | hand off from MGC1 to MGC2) | MG sends Notify to MGC2 | 339 | | MGC2 sends IUA ASP Active | 340 +------------------------------------------------------------------+ 341 | FAILOVER (sent by MG1 to MGC, to| 1. If SCTP Association between | 342 | change from MG1 to MG2) | MG1 and MGC was not aborted,| 343 | | ABORT by MGC | 344 | | 2. MGC1 and MGC2 INIT SCTP | 345 | | Association to MG2 | 346 +------------------------------------------------------------------+ 347 | MGC1 Failure (no ServiceChange) | MG sends Notify to MGC2 | 348 | Search for available MGC, find | MGC2 sends IUA ASP Active | 349 | MGC2 | | 350 +==================================================================+ 352 Table 2 - Synchronization between ServiceChange 353 and SCTP Association Management 355 8. ServiceChange for Blocking/Unblocking 357 The ServiceChange methods and ServiceChange reasons currently 358 defined in Megaco/H.248 are sufficient to support the 359 blocking/unblocking capabilities currently offered by the V5 360 specification. Table 2 maps Megaco ServiceChange methods and reasons 361 on the V5 control function elements for the management of ISDN 362 terminations. 364 Bouwen & Morneault Expires August 2001 7 365 +==================================================================+ 366 !Direct! V5 ! Megaco/H.248 ServiceChange ! 367 !MG-MGC! Function Elements ! Method ! Reason ! 368 +======+=========================+========+========================+ 369 ! <- !FE201 Unblock !Restart ! 903:MGC Directed Change! 370 +------+-------------------------+--------+------------------------+ 371 ! -> !FE202 Unblock !Restart ! 900:Service Restored ! 372 +------+-------------------------+--------+------------------------+ 373 ! <- !FE203 Block !Forced ! 903:MGC Directed Change! 374 +------+-------------------------+--------+------------------------+ 375 ! -> !FE204 Block !Forced ! 905: Termination taken ! 376 ! ! ! ! out of service ! 377 +------+-------------------------+--------+------------------------+ 378 ! -> !FE205 Block Request !Graceful! 905: Termination taken ! 379 ! ! ! ! out of service ! 380 +------+-------------------------+--------+------------------------+ 381 ! -> !FE206 Performance Grading!Restart/! 916: Performance gra- ! 382 ! ! !Forced ! ding (value in ! 383 ! ! ! ! extension param.) ! 384 +------+-------------------------+--------+------------------------+ 385 ! <- !FE207 D-channel Block !Forced ! 903:MGC Directed Change! 386 +------+-------------------------+--------+------------------------+ 387 ! <- !FE208 D-channel Unblock !Restart ! 903:MGC Directed Change! 388 +------+-------------------------+--------+------------------------+ 389 ! -> !FE209 TE out of service !Forced ! 904/905/906 ... ! 390 +------+-------------------------+--------+------------------------+ 391 ! -> !FE210 Failure inside !Forced ! Additional reasons can ! 392 ! ! network ! ! be defined if required ! 393 +------+-------------------------+--------+------------------------+ 395 Table 2: ServiceChange for blocking/unblocking of ISDN Terminations 397 Remark 1: Termination reference 399 Blocking and unblocking messages refer to the complete ISDN 400 termination (B-channels and D-channel). For instance, when the B and 401 D channels of Basic Access termination number 17 have to be blocked, 402 the termination identifier could have the form .../BA17/*. 404 D-channel blocking and unblocking only influences the D-channel. For 405 the same naming pattern as above, the termination identifier will 406 look like .../BA17/D. 408 The name pattern of these examples only serves as an illustration. 409 The MGC can obtain the pattern for the MG terminations with the use 410 of the name pattern package [8]. 412 Remark 2: performance grading 414 Performance Grading allows the Media Gateway to inform the Media 415 Gateway Controller predefined performance thresholds have been 417 Bouwen & Morneault Expires August 2001 8 418 passed. A new ServiceChange reasons 916 'Performance Grading' has to 419 be defined for this purpose, to be used with Restart and Forced 420 ServiceChange methods. The 916 Service Change Reason 916 will use 421 the Extension Parameter to indicate the level of performance (1 to 422 4). The newly defined reason will have to be registered with IANA. 424 9. Layer 1 Management 426 In ISDN access gateway architectures, the layer 1 functionality for 427 Basic Interfaces is split between the access gateway and the entity 428 containing call control (the local exchange). The Media Gateway 429 Controller is informed by the Media Gateway about the layer 1 430 availability of the ISDN termination (operational/non-operational). 431 In addition, the Media Gateway Controller supports the 432 activation/deactivation procedure for Basic Interfaces, as defined 433 in ITU Recommendation I.430 [4]. Primary Rate Interfaces are 434 permanently activated. 436 Maintenance of the Access Digital Section and customer lines is the 437 responsibility of the Media Gateway. The operation of loopbacks or 438 activation/deactivation of the digital section is controlled only by 439 the Media Gateway. No information related to these functions 440 is transmitted to the Media Gateway Controller. 442 The transfer of messages for the layer 1 management with the use of 443 an extension for IUA is described in [9] 445 Layer 2 activation/deactivation is managed with the use of IUA [3] 446 messages. 448 10. Conclusion 450 This draft proposes a set of guidelines to be considered as best 451 current practice for ISDN access gateways that use both Megaco and 452 Sigtran (IUA/SCTP) to communicate with a Media Gateway Controller. 453 The adoption of the guidelines will ensure interoperability between 454 access gateways and media gateway controllers. 456 11. Security Considerations 458 Security considerations as described in IUA and Megaco apply. 459 It is recommended to use the same security mechanism for IUA and 460 Megaco. 462 12. IANA Considerations 464 A new ServiceChange reason �Performance Grading� (916) has to be 465 registered with IANA. 467 Bouwen & Morneault Expires August 2001 9 468 13. References 470 [1] Megaco Protocol Version 1.0 471 RFC 3015, November 2000 473 [2] Stream Control Transmission Protocol (SCTP) 474 RFC 2960, October 2000 476 [3] ISDN Q.921-User Adaptation Layer (IUA) 477 RFC 3057, November 2000 479 [4] ITU-T Recommendation I.430 (1995), Basic user-network interface 480 - layer 1 specification 482 [5] ITU-T Recommendation Q.920 (1993), ISDN user-network interface 483 data link layer - General Aspects 485 [6] ITU-T Recommendation I.412 (1998), ISDN user-network interfaces, 486 interface structures and access capabilities. 488 [7] ISDN Package for Megaco 489 draft-bouwen-megaco-isdn-pack-01.txt, February 2001 491 [8] Name Pattern Package for Megaco 492 draft-rosen-megaco-namepatterns-00.txt, November 2000 494 [9] ISDN Layer 1 Activation Adaptation Layer (IL1A) 495 draft-bouwen-sigtran-il1a-00.txt, February 2001 497 14. Acknowledgments 499 15. Authors� Addresses 501 Jan Bouwen 502 Alcatel 503 F. Wellesplein 1 504 B-2000 Antwerpen 505 Belgium 506 Email: jan.bouwen@alcatel.be 508 Ken Morneault 509 Cisco 510 13615 Dulles Technology Drive 511 Herndon, VA 20171 512 USA 513 Email: kmorneau@cisco.com 515 Bouwen & Morneault Expires August 2001 10 516 Full Copyright Statement 518 "Copyright (C) The Internet Society (date). All Rights Reserved. 519 This document and translations of it may be copied and furnished to 520 others, and derivative works that comment on or otherwise explain it 521 or assist in its implmentation may be prepared, copied, published 522 and distributed, in whole or in part, without restriction of any 523 kind, provided that the above copyright notice and this paragraph 524 are included on all such copies and derivative works. However, this 525 document itself may not be modified in any way, such as by removing 526 the copyright notice or references to the Internet Society or other 527 Internet organizations, except as needed for the purpose of 528 developing Internet standards in which case the procedures for 529 copyrights defined in the Internet Standards process must be 530 followed, or as required to translate it into 532 Bouwen & Morneault Expires August 2001 11