Internet DRAFT - draft-bouwen-megaco-isdn-bcp
draft-bouwen-megaco-isdn-bcp
Megaco & Sigtran WG J. Bouwen
Internet Draft Alcatel
Document: <draft-bouwen-megaco-isdn-bcp-01.txt> 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
