Megaco & Sigtran WG J. Bouwen Internet Draft Alcatel Document: K. Morneault Category: Informational Cisco February 2001 Best Current Practice for Megaco-Sigtran Interaction in ISDN Access Gateways Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 1. Abstract A Media Gateway with ISDN terminations will use both Megaco [1] and Sigtran protocols for communication with the Media Gateway Controller. In an ISDN Access Gateway the media carrying B-channels are controlled by the Media Gateway Controller using Megaco, while the User-to-Network signalling running over the D-channels will be relayed to the Media Gateway Controller using Sigtran protocols (IUA [3] over SCTP [2]). At the moment, in the absence of appropriate specifications, the Megaco and Sigtran protocols may interact in different ways in the Access Gateway, leaving room for non-interoperable solutions. This draft proposes a set of guidelines for the Megaco-Sigtran interworking, documenting a best current practice for ISDN Access Gateways. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Bouwen & Morneault Expires August 2001 1 Internet Draft Best Current Practice for ISDN MGs February 2001 3. ISDN Termination Terminology and ISDN Media Gateway Architecture This section defines basic ISDN terminology based on Q.920 [5] and I.412 [6]. An ISDN termination typically exists of a number of B channels and one D channel. A B-channel is a 64 kbit/s channel for the transfer of user information streams A D-channel carries signaling information for circuit switching by the ISDN. Typical ISDN interface structures are: Basic access (BA) 2B+D ETSI, ANSI The bit rate of the D-channel in this interface structure is 16 kbit/s 2048 kbit/s Primary rate access (PRA): 30B+D ETSI The bit rate of the D-channel in the primary rate access structure is 64 kbit/s 1544 kbit/s Primary rate interface (PRI) 23B+D ANSI The bit rate of the D-channel in the primary rate interface structure is 64 kbit/s The D-channel uses a layered protocol according to ITU-T recommendations Q.920, Q.921, Q.930 and Q.931. The Q.921 Data Link uses the DLCI to identify a connection. Figure 1 shows the use of the DLCI. DLCI Data Link Connection Identifier An address conveyed in a Q.921 message which indicates the source and destination of an intended instance of communication at the data link layer The DLCI is the combination of the TEI and the SAPI SAPI Service Access Point Identifier Portion of the DLCI associated with the service access point on the network side or the user side of the user- network interface. The Service Access Point is the point at which the Q.921 data link layer provides services to layer 3 (Q.931). TEI Terminal Endpoint Identifier Portion of a DLCI associated with one (point-to-point Bouwen & Morneault Expires August 2001 2 Internet Draft Best Current Practice for ISDN MGs February 2001 data link) or more than one (broadcast data link) terminal equipment. The TEI is used to identify a specific connection endpoint within a Service Access Point. ########################### ########################### C P # Terminal 1 # # Terminal 2 # U R # # # # S E # +--------+ +--------+ # # +---------+ # T M # | Packet | | Q.931 | # # | Q.931 | # O I # | Data | | Sign. | # # | Sign. | # M S # +--------+ +--------+ # # +---------+ # E E # | | # # |...| # R S # /|\ SAPI /|\ SAPI # # /| |\ SAPI # ' # \|/ 16 \|/ 0 # # \|...|/ 0 # S # | | # # | | # ######|###########|######## ###########|###|########### | | | | |TEI88 |TEI88 TEI3| |TEI8 | | | | | +--------+ +------------+ | +------------------+ | | +--------------+ | | | | | | | | -->| | | |<--D-Channel | | | | | | | +---------------+ N +-----------+ | +-------------+ | E | +-----------+ | | T | | | | W / \ SAPI /|'''|'''|\ SAPI O \ / 16 \|...|...|/ 0 R | | | | K +--------+ +---------+ | Packet | | Q.931 | | Data | | Sign. | +--------+ +---------+ DLCI = SAPI + TEI Figure 1 - Relationship between SAPI, TEI and DLCI (based on [5]) Signaling information arrives in the ISDN Access Gateway over the D- channel, and has to be forwarded to the call control intelligence in the Media Gateway Controller. In this way an ISDN Access Gateway contains Signaling Gateway functionality. 4. ISDN Signaling Backhaul In the decomposed architecture of Media Gateways and Media Gateway Controllers, the call control intelligence resides in the Media Gateway Controller. This implies the call control signaling, which Bouwen & Morneault Expires August 2001 3 Internet Draft Best Current Practice for ISDN MGs February 2001 is transported in the SCN over the D-channel as Q.931 messages, has to be relayed from the Media Gateway to the Media Gateway Controller and vice versa. The signaling transport protocols developed in the Sigtran WG are used for this purpose. It involves the generic signaling transport protocol SCTP [2], and the ISDN Q.921 Adaptation Layer (IUA) [3]. Figure 2 shows the envisaged architecture. An SCTP association is set up between the Media Gateway and the Media Gateway Controller for the relay of Q.931 signaling and Q.921 management information. The SCTP association contains unidirectional streams. * Every D-channel is mapped to an MG->MGC stream and an MGC->MG stream. * For a particular D-channel, the same stream identification number in both directions should be used (but not necessarily). In addition, in IUA, the physical interface associated with the D- channel is assigned an Interface Identifier. The Interface Identifier can be a locally unique 32-bit integer or text string. The Media Gateway Controller uses Megaco/H.248 to create and remove media contexts containing B-channel terminations. Signaling associated with the B-channels is transferred between Media Gateway and Media Gateway Controller as unmodified Q.931 binary messages. #################### ################ # # # # # # # # # # # +--------+ # # # SCTP # | Q.931 | # # # Association # | Sign. | # # +-----+----+ # | # +--------+ # # | | IUA| # | # | IUA | # # ****|Q.921|----+ # v # +--------+ # # * **| |SCTP|********************** SCTP | # D*********#** * +-----+----+ # # +--------+ # B1---------#- * +-----+ # # # B2---------#---*-|-o o-|-----------> RTP # # # * +-----+ # (Media) # # # * # # # D*********#**** # # # B1---------#- +-----+ # # # B2---------#-----|-o o-|-----------> RTP # # . # +-----+ # (Media) # # . # # # # B31---------#- # # # # # # # #################### ################ Media Gateway Media Gateway Controller Figure 2 - Megaco + IUA/SCTP Architecture Bouwen & Morneault Expires August 2001 4 Internet Draft Best Current Practice for ISDN MGs February 2001 5. Naming of ISDN Terminations The Megaco/H.248 protocol specification doesn't contain any recommendation for the naming of terminations. The attribution of names is a matter of implementation. The naming pattern can be pre-configured in both the Media Gateway and the Media Gateway Controller, or the Media Gateway Controller can use the Name Pattern Package [8] to retrieve the name pattern implemented by the Media Gateway. The termination name could be used as the text-based Interface Identifier in IUA [3]. However, consideration should be given to the fact that the Interface Identifier is passed in all QPTM messages. Thus, there would be some additional overhead associated with a lengthy text-based Interface Identifier. 6. Visibility of the D-channel for Megaco The Megaco implementation can be unaware of the existence of D- channels, and only be involved with the establishment of media contexts containing B-channels. It is however preferred to make the D-channels visible for Megaco for management purposes. Megaco should not be used to perform connection control on D-channels (i.e. moving D-channels in and out of contexts). The visibility of the D-channel is intended to * allow use of ServiceChange on the D-channel * allow auditing of the D-channel * allow use of the same termination identifier for D-channels in Megaco and IUA. 7. Synchronisation of Megaco ServiceChange and SCTP Association initiation/termination At start-up the Media Gateway informs the Media Gateway Controller of its existence with a Megaco/H.248 ServiceChange message. The next step is the initiation of an SCTP association for the signaling backhaul, assuming that no SCTP association has been created between the Media Gateway Controller and the ISDN acces gateway as a transport layer for the megaco/H.248 protocol. The megaco/H.248 protocol can use SCTP as a transport via annex H. If SCTP is used, it is recommended that megaco/H.248 and IUA use different SCTP associations instead of sharing an association. Table 1 lists the dependencies between ServiceChange messages and the management of the SCTP association and the IUA layer. Following assumptions have been made: Bouwen & Morneault Expires August 2001 5 Internet Draft Best Current Practice for ISDN MGs February 2001 1. The table assumes that Megaco/H.248 itself does not run over SCTP. 2. The table assumes the Media Gateway is the Sigtran client and the Media Gateway Controller is the Sigtran server. 3. The table assumes that the Media Gateway has/establishes SCTP associations to the main Media Gateway Controller MGC1 and its backup MGC2. 4. The synchronization requirements for a Restart, a Graceful or Forced Shutdown are valid when the complete Media Gateway is affected (i.e. the referenced termination is 'root'), or when the complete set of available ISDN terminations is involved (i.e. the ISDN part of the Media Gateway). For the restart of shutdown of one ISDN termination, no changes in the SCTP association are required (since once the SCTP association has been established, there is no need to set up or tear down the streams inside the association). +==================================================================+ |Megaco/H.248 ServiceChange | SCTP Association | +==================================================================+ | RESTART (Root or all ISDN terms)| INIT SCTP Associations to MGC1 | | | and MGC2 by Media Gateway | +------------------------------------------------------------------+ | GRACEFUL Shutdown (Root or all | TERMINATE SCTP Associations to | | ISDN terminations) | MGC1 and MGC2 by Media Gateway | +------------------------------------------------------------------+ | FORCED Shutdown (Root or all | ABORT SCTP Associations to | | ISDN terminations) | MGC1 and MGC2 by Media Gateway | +------------------------------------------------------------------+ | DISCONNECTED | Check if SCTP Association(s) | | | are still operational, INIT | | | otherwise | +------------------------------------------------------------------+ | HANDOFF (sent by MGC1 to MG, to | MGC1 sends IUA ASP Inactive, | | hand off from MGC1 to MGC2) | MG sends Notify to MGC2 | | | MGC2 sends IUA ASP Active | +------------------------------------------------------------------+ | FAILOVER (sent by MG1 to MGC, to| 1. If SCTP Association between | | change from MG1 to MG2) | MG1 and MGC was not aborted,| | | ABORT by MGC | | | 2. INIT SCTP Assoc. to MGC1 | | | and MGC2 by MG2 | +------------------------------------------------------------------+ | MGC1 Failure (no ServiceChange) | MG sends Notify to MGC2 | | Search for available MGC, find | MGC2 sends IUA ASP Active | | MGC2 | | +==================================================================+ Table 1 - Synchronization between ServiceChange and SCTP Association Management Bouwen & Morneault Expires August 2001 6 Internet Draft Best Current Practice for ISDN MGs February 2001 Table 2 below is the same as Table 1 except the MG is the SIGTRAN server and the MGC is the SIGTRAN client. +==================================================================+ | Megaco/H.248 ServiceChange | SCTP Association | +==================================================================+ | RESTART (Root or all ISDN terms)| MGC1 and MGC2 INIT SCTP | | | Associations to Media Gateway | +------------------------------------------------------------------+ | GRACEFUL Shutdown (Root or all | TERMINATE SCTP Associations to | | ISDN terminations) | MGC1 and MGC2 by Media Gateway | +------------------------------------------------------------------+ | FORCED Shutdown (Root or all | ABORT SCTP Associations to | | ISDN terminations) | MGC1 and MGC2 by Media Gateway | +------------------------------------------------------------------+ | DISCONNECTED | Check if SCTP Association(s) | | | are still operational, INIT | | | otherwise | +------------------------------------------------------------------+ | HANDOFF (sent by MGC1 to MG, to | MGC1 sends IUA ASP Inactive, | | hand off from MGC1 to MGC2) | MG sends Notify to MGC2 | | | MGC2 sends IUA ASP Active | +------------------------------------------------------------------+ | FAILOVER (sent by MG1 to MGC, to| 1. If SCTP Association between | | change from MG1 to MG2) | MG1 and MGC was not aborted,| | | ABORT by MGC | | | 2. MGC1 and MGC2 INIT SCTP | | | Association to MG2 | +------------------------------------------------------------------+ | MGC1 Failure (no ServiceChange) | MG sends Notify to MGC2 | | Search for available MGC, find | MGC2 sends IUA ASP Active | | MGC2 | | +==================================================================+ Table 2 - Synchronization between ServiceChange and SCTP Association Management 8. ServiceChange for Blocking/Unblocking The ServiceChange methods and ServiceChange reasons currently defined in Megaco/H.248 are sufficient to support the blocking/unblocking capabilities currently offered by the V5 specification. Table 2 maps Megaco ServiceChange methods and reasons on the V5 control function elements for the management of ISDN terminations. Bouwen & Morneault Expires August 2001 7 Internet Draft Best Current Practice for ISDN MGs February 2001 +==================================================================+ !Direct! V5 ! Megaco/H.248 ServiceChange ! !MG-MGC! Function Elements ! Method ! Reason ! +======+=========================+========+========================+ ! <- !FE201 Unblock !Restart ! 903:MGC Directed Change! +------+-------------------------+--------+------------------------+ ! -> !FE202 Unblock !Restart ! 900:Service Restored ! +------+-------------------------+--------+------------------------+ ! <- !FE203 Block !Forced ! 903:MGC Directed Change! +------+-------------------------+--------+------------------------+ ! -> !FE204 Block !Forced ! 905: Termination taken ! ! ! ! ! out of service ! +------+-------------------------+--------+------------------------+ ! -> !FE205 Block Request !Graceful! 905: Termination taken ! ! ! ! ! out of service ! +------+-------------------------+--------+------------------------+ ! -> !FE206 Performance Grading!Restart/! 916: Performance gra- ! ! ! !Forced ! ding (value in ! ! ! ! ! extension param.) ! +------+-------------------------+--------+------------------------+ ! <- !FE207 D-channel Block !Forced ! 903:MGC Directed Change! +------+-------------------------+--------+------------------------+ ! <- !FE208 D-channel Unblock !Restart ! 903:MGC Directed Change! +------+-------------------------+--------+------------------------+ ! -> !FE209 TE out of service !Forced ! 904/905/906 ... ! +------+-------------------------+--------+------------------------+ ! -> !FE210 Failure inside !Forced ! Additional reasons can ! ! ! network ! ! be defined if required ! +------+-------------------------+--------+------------------------+ Table 2: ServiceChange for blocking/unblocking of ISDN Terminations Remark 1: Termination reference Blocking and unblocking messages refer to the complete ISDN termination (B-channels and D-channel). For instance, when the B and D channels of Basic Access termination number 17 have to be blocked, the termination identifier could have the form .../BA17/*. D-channel blocking and unblocking only influences the D-channel. For the same naming pattern as above, the termination identifier will look like .../BA17/D. The name pattern of these examples only serves as an illustration. The MGC can obtain the pattern for the MG terminations with the use of the name pattern package [8]. Remark 2: performance grading Performance Grading allows the Media Gateway to inform the Media Gateway Controller predefined performance thresholds have been Bouwen & Morneault Expires August 2001 8 Internet Draft Best Current Practice for ISDN MGs February 2001 passed. A new ServiceChange reasons 916 'Performance Grading' has to be defined for this purpose, to be used with Restart and Forced ServiceChange methods. The 916 Service Change Reason 916 will use the Extension Parameter to indicate the level of performance (1 to 4). The newly defined reason will have to be registered with IANA. 9. Layer 1 Management In ISDN access gateway architectures, the layer 1 functionality for Basic Interfaces is split between the access gateway and the entity containing call control (the local exchange). The Media Gateway Controller is informed by the Media Gateway about the layer 1 availability of the ISDN termination (operational/non-operational). In addition, the Media Gateway Controller supports the activation/deactivation procedure for Basic Interfaces, as defined in ITU Recommendation I.430 [4]. Primary Rate Interfaces are permanently activated. Maintenance of the Access Digital Section and customer lines is the responsibility of the Media Gateway. The operation of loopbacks or activation/deactivation of the digital section is controlled only by the Media Gateway. No information related to these functions is transmitted to the Media Gateway Controller. The transfer of messages for the layer 1 management with the use of an extension for IUA is described in [9] Layer 2 activation/deactivation is managed with the use of IUA [3] messages. 10. Conclusion This draft proposes a set of guidelines to be considered as best current practice for ISDN access gateways that use both Megaco and Sigtran (IUA/SCTP) to communicate with a Media Gateway Controller. The adoption of the guidelines will ensure interoperability between access gateways and media gateway controllers. 11. Security Considerations Security considerations as described in IUA and Megaco apply. It is recommended to use the same security mechanism for IUA and Megaco. 12. IANA Considerations A new ServiceChange reason æPerformance GradingÆ (916) has to be registered with IANA. Bouwen & Morneault Expires August 2001 9 Internet Draft Best Current Practice for ISDN MGs February 2001 13. References [1] Megaco Protocol Version 1.0 RFC 3015, November 2000 [2] Stream Control Transmission Protocol (SCTP) RFC 2960, October 2000 [3] ISDN Q.921-User Adaptation Layer (IUA) RFC 3057, November 2000 [4] ITU-T Recommendation I.430 (1995), Basic user-network interface - layer 1 specification [5] ITU-T Recommendation Q.920 (1993), ISDN user-network interface data link layer - General Aspects [6] ITU-T Recommendation I.412 (1998), ISDN user-network interfaces, interface structures and access capabilities. [7] ISDN Package for Megaco draft-bouwen-megaco-isdn-pack-01.txt, February 2001 [8] Name Pattern Package for Megaco draft-rosen-megaco-namepatterns-00.txt, November 2000 [9] ISDN Layer 1 Activation Adaptation Layer (IL1A) draft-bouwen-sigtran-il1a-00.txt, February 2001 14. Acknowledgments 15. AuthorsÆ Addresses Jan Bouwen Alcatel F. Wellesplein 1 B-2000 Antwerpen Belgium Email: jan.bouwen@alcatel.be Ken Morneault Cisco 13615 Dulles Technology Drive Herndon, VA 20171 USA Email: kmorneau@cisco.com Bouwen & Morneault Expires August 2001 10 Internet Draft Best Current Practice for ISDN MGs February 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Bouwen & Morneault Expires August 2001 11