Megaco WG J. Bouwen Internet Draft B. Van Doorselaer Document: M. Dekeyser Category: Informational Alcatel July, 2000 Issues for Megaco - Sigtran Interworking 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 [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. 1. Abstract This document introduces the concept of an ISDN access gateway in the context of Megaco/H.248 and Sigtran protocols. For these ISDN access gateways, the ISDN B channels may be controlled by the Media Gateway Controller using megaco/H.248 while the User-to-Network signaling running over the D channels may be relayed to the Media Gateway Controller using the Sigtran protocols. The main issues involved are: * Megaco/H.248 and Sigtran protocols may interwork in different ways in ISDN access gateways, leaving room for non - interoperable solutions; * Megaco needs additional packages in order to support ISDN terminations in the ISDN access gateway; * A data service may be offered to ISDN users via the ISDN D- channel, introducing the need to introduce a NAS package for the D-channel. This document addresses these issues, proposes and explains different solutions and suggests best practice guideline for megaco / sigtran interworking in ISDN access gateways. 2. Conventions used in this document Bouwen, Van Doorselaer, Dekeyser 1 Internet Draft ISDN Access Gateways Issues July 2000 3. Introduction The Megaco/H.248 protocol [1] defines a framework for the control of ISDN Access Gateways by Media Gateway Controllers. Packages specify extensions for a specific type of termination in the Media Gateway. This Internet Draft investigates issues involved with the support of ISDN terminations in ISDN Access Gateways. An important set of issues are related to the interaction between Megaco/H.248 and Sigtran [2,3] protocols that can be used for the transport of ISDN signaling between the ISDN Access Gateway and the Media Gateway Controller. This document lists several alternative approaches for the Megaco/H.248 - Sigtran interworking. It proposes Megaco/H.248 extensions for the description of ISDN termination properties in the form of an ISDN package. However, not all issues can be solved by a new package definition, and it is felt that a best common practice document is needed to guarantee interoperability. We hope this internet draft can start the discussion that will eventually lead to such a document. Following topics are addressed in this draft: * A general naming scheme for ISDN terminations; * Levels of interworking between Megaco/H.248 and Sigtran. Different levels can be discerned, depending on the visibility of the signaling transport for Megaco/H.248; * Required new termination properties for ISDN; * Alternative mechanisms for the control of termination properties; * A preliminary discussion on support for packet data transfer in an ISDN D-channel. This draft does not pretend to present an exhaustive treatment of the subject, and several sections require further study. Fax and ISDN modems are not addressed. The package definitions are examples containing partial functionality tied to a particular implementation option. A future complete ISDN package would consist of a combination of selected package definitions in this draft. The draft focuses on the text-encoded version of the Megaco/H.248 protocol. 4. ISDN Termination Terminology and ISDN Media Gateway Architecture This section defines basic ISDN terminology based on Q.920 [5] and I.412 [9]. 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 Bouwen, Van Doorselaer, Dekeyser 2 Internet Draft ISDN Access Gateways Issues July 2000 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 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. Bouwen, Van Doorselaer, Dekeyser 3 Internet Draft ISDN Access Gateways Issues July 2000 ########################### ########################### 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 forwarded to the call control intelligence in the Media Gateway Controller. In this way an ISDN Access Gateway contains Signaling Gateway functionality. 5. Naming of ISDN Terminations 5.1 Complete provisioning The Megaco/H.248 protocol specification doesn't contain any recommendation for the naming of terminations. The attribution of names is considered a matter of implementation. An arbitrary naming Bouwen, Van Doorselaer, Dekeyser 4 Internet Draft ISDN Access Gateways Issues July 2000 scheme necessitates a complete pre-provisioning in both Media Gateway and Media Gateway Controller of: * A table of ISDN B-channel terminations in Media Gateway and Media Gateway Controller, for use in Megaco/H.248 commands for media connection establishment. * A table of ISDN D-channel terminations in Media Gateway and Media Gateway Controller, for transfer of Q.931 message contents between Media Gateway and Media Gateway Controller. (See further for possible transfer mechanisms) * A binding table in the Media Gateway Controller between B-channels and the associated D-channels (i.e. a view of the BRI and PRI structures). 5.2 Advantages of a general ISDN Naming Scheme The adoption of a consistent naming scheme of ISDN terminations would simplify configuration of Media Gateways and Media Gateway Controllers, and facilitate their interoperability. The extension of a Media Gateway with new terminations - a current practice in Access Gateways - could be more easily automated. And finally the use of one naming pattern in Megaco/H.248 and IUA/SCTP protocols (see further) is almost a prerequisite for a transparent Media Gateway Controller implementation. 5.3 Proposal for an ISDN Termination Naming Pattern A possible naming pattern for ISDN terminations could be: ISDNTerm / [BA[1-{#BA}] / [D, B[1-2]], PRI[1-{#PRI}] / [D[1-2], B[1-23]], PRA[1-{#PRA}] / [D, B[1-30]] ] Examples of termination names constructed according to this scheme: ISDNTerm/BA93/B1 ISDNTerm/PRI17/B18 ISDNTerm/PRI22/D ISDNTerm/PRA88/B28 The use of D1 and D2 in a PRI is optional. It is intended to differentiate between the primary and backup D-channel, when the latter is present. 5.3 Visibility of the D-channel for Megaco/H.248 The advantages of a naming scheme are coupled to the visibility of D-channels to the Megaco/H.248 implementation. Megaco/H.248 can be unaware of the existence of D-channels, and only be involved with the establishment of media contexts containing B-channels. It's also Bouwen, Van Doorselaer, Dekeyser 5 Internet Draft ISDN Access Gateways Issues July 2000 possible to treat D-channels similarly to B-channels, and allow all Megaco/H.248 operations on D-channels. This draft discusses a set of implementation options, which translate to an increasing visibility of the D-channels to Megaco/H.248: * Megaco/H.248 is unaware of the existence of D-channels (par. 7.1) * Reference to D-channels is used in Megaco/H.248 for management purposes (e.g. blocking/unblocking) (par. 7.2) * Megaco/H.248 references D-channels to set up signaling connections (par. 7.3) * Megaco/H.248 references D-channels to set up media (packet data) connections over the D-channel (par. 10) 6. 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 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, as proposed in [3]. The mapping of a particular D-channel to an SCTP stream is a matter of implementation, but the use of the same stream identification number in both directions seems a logical choice. The Media Gateway Controller uses Megaco/H.248 to create and remote 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. Megaco/H.248 is not directly concerned with the Q.931 backhaul mechanism. However, some interaction between the two protocols is required. References to D-channels can show up in both Megaco/H.248 and IUA messages. Some synchronization is needed between the Megaco/H.248 ServiceChange messages and the initiation/release of SCTP associations. These issues are explored in more detail in the next chapter. Figure 3 shows the contents of a message conveyed over an SCTP stream. Only some elements of the SCTP message header are shown. The IUA header contains a reference to the relevant D-channel, and the Q.921 addressing information. Bouwen, Van Doorselaer, Dekeyser 6 Internet Draft ISDN Access Gateways Issues July 2000 SCTP Association | | ################ | ################ # # v # +--------+ # # *************#********************#*** Q.931 | # # * ***********#********************#*** Sign. | # D*********#** * # ^ # +--------+ # B1---------#- * +-----+ # # | IUA | # B2---------#---*-|-o o-|--#--------> RTP # +--------+ # # * +-----+ # (Media) # | SCTP | # # * # # +--------+ # D*********#**** # # # B1---------#- +-----+ # # # B2---------#-----|-o o-|--#--------> RTP # # . # +-----+ # (Media) # # . # # # # B31---------#- # # # # # # # ################ ################ Media Gateway Media Gateway Controller Figure 2 - Megaco + IUA/SCTP Architecture +-------------------------------------+ ^ ! ... ! ! ! ! ! +------------------+------------------+ ! ! Originating Port ! Destination Port ! ! +------------------+------------------+ ! ! StreamID = 17 ! ! ! +-------------------------------------+ ! ! ! ! ! +-----------------------------+ ! ^ ! ! ! Adaptation Layer ! ! ! ! ! ! Common Header ! ! ! ! ! +-----------------------------+ ! ! ! ! ! 'ISDN/PRI17/D' ! ! ! !S ! +-----------------------------+ ! !I !C ! ! SAPI ! ! !U !T ! +-----------------------------+ ! !A !P ! ! TEI ! ! ! ! ! +-----------------------------+ ! ! ! ! ! Q.931 ! ! ! ! ! ! DATA ! ! ! ! ! +-----------------------------+ ! v ! +-------------------------------------+ v Figure 3 - Contents of IUA/SCTP Q.931 Backhauling Message Bouwen, Van Doorselaer, Dekeyser 7 Internet Draft ISDN Access Gateways Issues July 2000 7. Megaco - Sigtran interworking 7.1 Minimal interworking A first scenario encompasses minimal interworking between Megaco/h.248 and IUA/SCTP. The Megaco/H.248 implementation is unaware of the existence of D-channels and the backhauling mechanism. 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). In case the megaco/H.248 protocol uses one or more SCTP streams, one should take care that different stream identifiers are used for the Q.931 backhauling and for the streams used by the megaco/H.248 protocol. Table 1 lists the dependencies between ServiceChange messages and the management of the SCTP association. +==================================================================+ | Megaco/H.248 ServiceChange | SCTP Association | +==================================================================+ | RESTART (Root or all ISDN terms)| INIT SCTP Association | | | by Media Gateway | +------------------------------------------------------------------+ | GRACEFUL Shutdown (Root or all | TERMINATE SCTP Association | | ISDN terminations) | by Media Gateway | +------------------------------------------------------------------+ | FORCED Shutdown (Root or all | ABORT SCTP Association | | ISDN terminations) | by Media Gateway | +------------------------------------------------------------------+ | DISCONNECTED | Check if SCTP Association is | | | still operational, INIT other- | | | wise | +------------------------------------------------------------------+ | HANDOFF (sent by MGC1 to MG, to | 1. MG TERMINATEs SCTP Assoc. | | hand off from MGC1 to MGC2) | to MGC1 | | | 2. MG INITs SCTP Association | | | to MGC2 | +------------------------------------------------------------------+ | 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. by MG2 | +------------------------------------------------------------------+ Table 1 - Synchronization between ServiceChange and SCTP Association Management for minimal Megaco - SCTP interworking Bouwen, Van Doorselaer, Dekeyser 8 Internet Draft ISDN Access Gateways Issues July 2000 Remarks: 1. The table assumes Megaco/H.248 itself doesn't run over SCTP. If this is the case, the same SCTP association could also be used for signaling backhaul. 2. 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 flows inside the association). 7.2 Referencing D-channels for management In a second scenario D-channels are visible for the Megaco/H.248 implementation, and can hence be addressed in Megaco/H.248 messages. This would be a logical situation if a standardized naming pattern is used, which is downloaded by the Media Gateway Controller from the Media Gateway when it restarts (a feature scheduled for the next Megaco/H.248 version). If D-channels are only used for the transfer of Q.931 signaling, D- channel terminations will not be added to Megaco/H.248 contexts. They can however be audited to get their current status (see par. for ISDN termination properties), and can be referenced in ServiceChange commands (to block/unblock a D-channel). When D-channels can contain packet data, visibility of the D-channel for Megaco/H.248 is clearly a necessity. In this case, a specific type of NAS package could be foreseen. See chapter 10 for a preliminary discussion of this topic. The synchronization requirements between Megaco/H.248 ServiceChange and the establishment/release of the SCTP association are identical to the ones presented in paragraph 7.1 (Table 1). 7.3 Megaco/H.248 controlled SCTP stream set-up In this scenario the set-up of the SCTP association is controlled by the Media Gateway Controller. The Media Gateway Controller furthermore uses Megaco/H.248 commands to explicitly bind D-channels to SCTP streams. It creates contexts for this purpose that contain the D-channel and the associated SCTP streams. The properties of the SCTP terminations are described with SDP. Extensions to SDP are required to indicate the transport protocol is SCTP, the format is IUA (Q.921 Adaptation Layer), and to reference the SCTP stream Bouwen, Van Doorselaer, Dekeyser 9 Internet Draft ISDN Access Gateways Issues July 2000 identifier. The example Megaco message below creates a signaling context: MEGACO/1 [123.123.123.4]:55555 Transaction = 10003 { Context = $ { Add = ISDNTerm/BA17/D, Add = $ { Media { Stream = 65 { LocalControl { Mode = SendReceive}, Local { v=0 c=IN IP4 124.124.124.22 m=control 7777 sctp iua a=stream:17 } Remote { v=0 c=IN IP4 123.123.123.4 m=control 7777 sctp iua a=stream:17 } } } } } } A few new items are introduced in this message: Stream = 65 A number different from 1 has been chosen, as this is reserved for audio. M = control 7777 sctp iua control: already defined in the SDP specification 7777: sctp port number for this association sctp: transport protocol, new protocol in SDP iua: format, new protocol in SDP a= stream:17 New SDP attribute specifying the SCTP stream to be added to the newly created context The Media Gateway will assign a name to the SCTP ephemeral termination in its response, as is defined for RTP sessions. This mechanism offers the Media Gateway Controller detailed control of the binding between D-channels and SCTP streams. The advantages for the backhauling application are not immediately clear. However, future applications may require the by the Media Gateway Controller managed establishment of SCTP streams (for further study). Remark that Megaco/H.248 is not used for the establishment/release of an SCTP association. Only SCTP streams are addressed with Megaco/H.248 commands. The requirements for synchronization between Bouwen, Van Doorselaer, Dekeyser 10 Internet Draft ISDN Access Gateways Issues July 2000 Megaco/H.248 ServiceChange and the management of the SCTP association are listed in Table 2. +==================================================================+ | Megaco/H.248 ServiceChange | SCTP Association | +==================================================================+ | RESTART (Root or all ISDN terms)| INIT SCTP Association | | | by Media Gateway Controller | +------------------------------------------------------------------+ | GRACEFUL Shutdown (Root or all | TERMINATE SCTP Association | | ISDN terminations) | by Media Gateway | +------------------------------------------------------------------+ | FORCED Shutdown (Root or all | ABORT SCTP Association | | ISDN terminations) | by Media Gateway | +------------------------------------------------------------------+ | DISCONNECTED | Check if SCTP Association is | | | still operational, INIT other- | | | wise | +------------------------------------------------------------------+ | HANDOFF (sent by MGC1 to MG, to | 1. MGC1 TERMINATEs SCTP Assoc | | hand off from MGC1 to MGC2) | to MG | | | 2. MGC2 INITs SCTP Association | | | to MG | +------------------------------------------------------------------+ | 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. by MGC | +------------------------------------------------------------------+ Table 2 - Synchronisation between ServiceChange and SCTP Association Management for MGC controlled association set-up 7.4 Data in D-channel When D-channels can contain packet data, visibility of the D-channel for Megaco/H.248 is clearly a necessity. See chapter 10 for a preliminary discussion of this topic. 8. Properties of ISDN Terminations 8.1 ISDN Termination type It may be interesting for the Media Gateway Controller to find out the channel type of a particular ISDN termination, if it is not able to deduce it from its name. (In cases where no self-explanatory naming pattern is used, or when Media Gateway Controller doesn't support implicit definition of channel type by the naming pattern.) Bouwen, Van Doorselaer, Dekeyser 11 Internet Draft ISDN Access Gateways Issues July 2000 PROPERTIES Channel Type PropertyID: chantype (0x0001) Identifies the type of ISDN channel for a ISDN termination Type: Enumeration Possible Values: "BA D" D-channel in basic access interface "BA B" B-channel in basic access interface "PRA2048 D" D-channel in 2048kbit primary rate interface "PRA2048 B" B-channel in 2048kbit primary rate interface "PRI1544 D" D-channel in 1544kbit primary rate interface "PRI1544 B" B-channel in 1544kbit primary rate interface Defined in: TerminationState Characteristics: Read 8.2 Interface Identifiers and Associated D-channel A D-channel in one PRI may be used to transfer signaling for a set of PRI's. The other PRI's have in this case 24 or 31 B-channels. The Q.931 messages received on the D-channel refer to the relevant B- channel in the Interface Identifier information element [6]. The Interface Identifier is a binary provisioned identifier for the primary rate interfaces. The ISDN package 'Interface Identifier' property contains this value. Another B-channel property 'Associated D-channel' contains the associated D-channel, in the naming convention used by the Media Gateway to refer to ISDN terminations. These properties are defined as read-only, as it is not the intention to use Megaco/H.248 to make such configurations. PROPERTIES Q.931 Interface Identifier PropertyID: interfaceid (0x0002) Contains the binary interface identifier used in Q.931 messages when a D-channel in a PRI has been provisioned to act as signalling channel for several PRIs. Type: Integer Possible Values: Defined in: TerminationState Characteristics: Read Associated D-channel PropertyID: assocd (0x0003) Contains the name of the D-channel termination that is associated with this B-channel Type: String Possible Values: Defined in: TerminationState Bouwen, Van Doorselaer, Dekeyser 12 Internet Draft ISDN Access Gateways Issues July 2000 Characteristics: Read 8.3 Layer 1 Activation In current 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). In this draft we model the required interaction related to layer 1 between the Media Gateway and the Media Gateway Controller on the existing decomposition practice in the SCN. More specifically, the control protocol messages defined in V5 [7,8] are used as a basis for the information exchange within Megaco/H.248. 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 only controlled 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 event/signal mechanism is discussed in paragraph 9.3.1. Primary Rate Interfaces are permanently activated and don't make use of the activation/deactivation procedure. Also Basic Interfaces can be permanently activated. The activation policy for a Basic Interface is specified in a new ISDN termination property: PROPERTIES Activation Policy PropertyID: permact (0x0004) Specifies if the Basic Interface is permanently activated, or if the activation/deactivation procedure should be followed. Type: Boolean Possible Values: True: permanent activation is installed False: activation/de-activation procedure Defined in: TerminationState Characteristics: Read 8.4 Blocked/Unblocked States Bouwen, Van Doorselaer, Dekeyser 13 Internet Draft ISDN Access Gateways Issues July 2000 The blocked/unblocked states for ISDN terminations are directly mapped onto the Megaco/H.248 defined termination states of inservice and outofservice. See paragraph 9.2 for the related Megaco/H.248 messages 9. Controlling ISDN Termination Properties 9.1 Modifying Termination Properties Megaco/H.248 offers three methods to modify and retrieve the state of terminations: 1. The Media Gateway Controller can change the state of a termination with the Modify method, and can read it with the Audit method. This mechanism doesn't allow the Media Gateway to report changes in state. 2. The event/signal mechanism allows the Media Gateway Controller to order the Media Gateway to modify a termination state (signal), and to report state changes (event notification). It is the appropriate mechanism for call-related states. 3. The ServiceChange method is used by the Media Gateway Controller to modify states that are not call-related (inservice, outofservice). The Media Gateway can use it to send unsolicited state change reports. 9.2 ServiceChange for Blocking/Unblocking The ServiceChange methods and servicechange reasons currently defined in Megaco/H.248 seem sufficient to support the blocking/unblocking capabilities currently offered by the V5 specification. Table 3 maps Megaco ServiceChange methods and reasons on the V5 control function elements for the management of ISDN terminations. Remark 1: Termination reference Blocking and unblocking messages refer to the complete ISDN termination (B-channels and D-channel), and will for example contain a termination identifier of the form ISDNTerm/BA17/*. D-channel blocking and unblocking only influences the D-channel. The termination identifier will look like ISDNTerm/BA17/D. Remark 2: performance grading Performance Grading allows the Media Gateway to inform the Media Gateway Controller predefined performance thresholds have been passed. New ServiceChange reasons 'Normal Performance' and 'Degraded Bouwen, Van Doorselaer, Dekeyser 14 Internet Draft ISDN Access Gateways Issues July 2000 Performance level X' can be defined for this purpose, to be used with Restart and Forced ServiceChange methods. Alternatively, a new event can be defined, with an additional parameter specifying the performance grade (remark that this contradicts the earlier defined philosophy to use signals and events for call-related state exchange). EVENTS Performance Grade EventID: perfgrade (0x0001) Media Gateway reports change in performance grade Additional Parameters Grade ParameterID: grade (0x0001) Type: Enumeration Possible Values: normalGrade, degraded +==================================================================+ !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! ? ! See remark 2 ! +------+-------------------------+--------+------------------------+ ! <- !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 in required ! +------+-------------------------+--------+------------------------+ Table 3: ServiceChange for blocking/unblocking of ISDN Terminations Bouwen, Van Doorselaer, Dekeyser 15 Internet Draft ISDN Access Gateways Issues July 2000 9.3 Messages for Layer 1 Activation 9.3.1 Megaco/H.248 Signals/Events Following package description defines the events and signals for layer 1 management by the Media Gateway Controller: ISDN Layer 1 Management Package Package ID: isdnlay1 Version: 1 Extends: none Description: This package defines signals/events for the activation/de- activation procedure for ISDN Basic Interfaces, as defined in ITU-T Recommendation I.430 [4]. EVENTS Event name: Activation initiated by user EventID: useract(0x0001) Description: Event name: DS activated EventID: dsact (0x0002) Description: Event name: Access activated EventID: accessact (0x0003) Description: Event name: Access deactivated EventID: accessdeact (0x0004) Description: SIGNALS Signal name: Activate access SignalID: activaccess (0x0005) Description: SignalType: OO Signal name: Deactivation access SignalID: deactivaccess (0x0006) Description: SignalType: OO PROCEDURES Bouwen, Van Doorselaer, Dekeyser 16 Internet Draft ISDN Access Gateways Issues July 2000 See G.964 chapter 14 [7] 9.3.2 SCTP Transport of Activation Messages An alternative approach is to exchange layer 1 management messages within the SCTP streams that are used for the layer 2 management. Messages for this purpose are based on the format for Sigtran adaptation layer messages, as shown in Figure 4. 0 7 8 15 16 31 +---------------+---------------+ | Vers | Spare | Msg Type | +-------------------------------+ | Tag (0x1) | Length | +-------------------------------+ | Interface Identifier | +-------------------------------+ Figure 4 - Layer 1 Activation Management Messages Version: version of layer 1 activation management protocol = 01 Spare Msg Type: see further Tag: code for Interface Identifier information element Length: length in number of octets of Interface Identifier Interface ID:String identifier for the ISDN termination, constructed According to the ISDN termination naming pattern The defined messages are: Activation Initiated by User 0101 DS Activated 0102 Access Activated 0103 Access Deactivated 0104 Activate Access 0105 Deactivate Access 0106 A protocol id for the layer 1 activation management protocol will have to be defined in SCTP. 9.4 ServiceChange for new Terminations To support the on-line installation of new (ISDN) terminations in the Media Gateway, and new ServiceChange reason is defined "New Termination(s)", to be used with the Restart method. 10. Packet data in the D-channel Bouwen, Van Doorselaer, Dekeyser 17 Internet Draft ISDN Access Gateways Issues July 2000 Data connections over the B-channel (e.g. for Internet access) are not discussed in this draft. The D-channel however can also be used for the transport of packet data. In this way an always-on internet connection can be offered to the user. An internet connection over the D-channel can be used to signal the arrival of new messages in the user's mailbox. A B-channel will be opened for download of the packet data. This section addresses required extensions to the Megaco/H.248 protocol and SDP to support the use of the D-channel for packet data different from Q.931 signaling. The Q.921 SAPI differentiates between Q.931 signaling and packet data. The SAPI has the value of 0 for Q.931, and 16 for packet data. The presence of both Q.931 signaling and packet data necessitates the creation of ephemeral terminations on top of the ISDN D-channel termination. The Megaco/H.248 message below shows a possible approach to the problem. MEGACO/1 [123.123.123.4]:55555 Transaction = 10003 { Context = $ { Add = ISDNTerm/BA17/D/$ { Media { Stream = 66 { LocalControl { Mode = SendReceive}, Remote { v=0 c=ISDN DLCI 88 m=data 16 ppp } } }, Add = $ { Media { Stream = 66 { LocalControl { Mode = SendReceive}, --Remote and Local descriptors for IP network data session-- }} } } } The message contains the following new items: Add = ISDNTerm/BA17/D/$ Requests the Media Gateway to create an ephemeral termination within the D-channel. The Media Gateway will indicate in its response the assigned termination identifier. This is new functionality in Megaco/H.248 for SCN terminations. Stream = 66 Bouwen, Van Doorselaer, Dekeyser 18 Internet Draft ISDN Access Gateways Issues July 2000 A value different from 1 has been selected, as this one is reserved for audio c=ISDN DLCI 88 The network is the ISDN, with Q.921 DLCI as addressing scheme The Terminal Equipment Identifier is 88. m=data 16 ppp A data stream is set up to Service Access Point 16, over PPP. The creation of an ephemeral termination on the IP side is basically no different from dial-in connections from analogue lines, and is not further discussed. 11. Conclusion - Recommendations This draft discusses issues related to the support of ISDN terminations in Access Gateways. Several approaches to the identified problems have been introduced. We propose to follow the next guidelines for the further development of this effort: 11.2 VoIP ISDN Access Gateways The IUA/SCTP Sigtran protocols should be used for Q.931 signaling backhaul. The interworking scenario of paragraph 7.2 is preferred: D-channels are visible for the Megaco/H.248 protocol, but Megaco/H.248 is not used for the establishment of SCTP backhauling streams. An ISDN Access Gateway ISDN package should contain the following components: * The ISDN termination properties defined in paragraph 8; ISDN ChannelType (paragraph 8.1) Q.931 Interface Identifier (paragraph 8.2) Associated D-Channel (paragraph 8.3) Activation Policy (paragraph 8.4) * Layer 1 management events/signals (paragraph 9.3). New ServiceChange reasons should be registered with IANA for * Performance Grading reporting (if possible within the ISDN package) (paragraph 9.2 Remark 2, ServiceChange option); * Installation of new terminations (paragraph 9.4). Furthermore, a best practice document should contain: * A standardized naming pattern for ISDN terminations (paragraph 5.2); * Synchronization between ServiceChange and SCTP association management (Table 1); Bouwen, Van Doorselaer, Dekeyser 19 Internet Draft ISDN Access Gateways Issues July 2000 11.3 Packet Data in D-Channel Applications This subject needs additional study. Procedures have to be defined to interoperate with NAS packages (for ISDN terminations). The preliminary proposal in this draft requires: * An extension of SDP for the description of packet data streams in ISDN D-channels; * The possibility in the next version of Megaco/H.248 to define ephemeral terminations on top of SCN terminations (D-channels). 12. Security Considerations For further study. 13. Differences between draft-00 and draft-01 Draft-01 focuses on the interworking issues between Megaco/H.248 and Sigtran. The draft-00 discussion of alternative backhaul mechanisms (tunneling Q.931 in Megaco messages) has been removed completely. 14. References [1] Megaco Protocol draft-ietf-megaco-protocol-08.txt, April 2000 [2] Stream Control Transmission Protocol (SCTP) draft-ietf-sigtran-sctp-11.txt, July 2000 [3] ISDN Q.921-User Adaptation Layer (IUA) draft-ietf-sigtran-iua-03.txt, June 1999 [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 Q.931 (1998), ISDN user-network interface layer 3 specification [7] ITU-T Recommendation G.964 (1994), V-Interfaces at the digital local local exchange - V5.1-interface for the support of access network [8] ETSI Standard ETS 300 324 (1994), V interfaces at the digital Local Exchange - V5.1 interface for the support of Access Network [9] ITU-T Recommendation I.412 (1998), ISDN user-network interfaces, interface structures and access capabilities. Bouwen, Van Doorselaer, Dekeyser 20 Internet Draft ISDN Access Gateways Issues July 2000 15. Acknowledgements 16. Author's Addresses Jan Bouwen Alcatel Bell F. Wellesplein 1 B-2000 Antwerpen Belgium Email: jan.bouwen@alcatel.be Bart Van Doorselaer Alcatel Bell F. Wellesplein 1 B-2000 Antwerpen Belgium Email: bart.van_doorselaer@alcatel.be Miek Dekeyser Prins Boudewijnlaan 47-49 B-2650 Edegem Belgium Email: miek.dekeyser@alcatel.be Bouwen, Van Doorselaer, Dekeyser 21 Internet Draft ISDN Access Gateways Issues July 2000 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, Van Doorselaer, Dekeyser 22