Internet DRAFT - draft-bouwen-megaco-isdn
draft-bouwen-megaco-isdn
Megaco WG J. Bouwen
Internet Draft B. Van Doorselaer
Document: <draft-bouwen-megaco-isdn-01.txt> 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
