Internet DRAFT - draft-barr-megaco-aal2bearer
draft-barr-megaco-aal2bearer
Media Gateway Control David Barr
Internet Draft Nortel Networks
Document: draft-barr-megaco-aal2bearer-00.txt June 2002
Category: Informational
Media Gateway AAL2 Bearer-Path Establishment
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
This document proposes specific procedures that Media Gateways (MGs)
shall follow for AAL2 bearer-path establishment under the control of
H.248 (Megaco) capable Media Gateway Controllers (MGCs). The
procedures cover MGs which use provisioned VCCs and backward call
setup mode dynamic SVCs, and which do not use AAL2 signalling (i.e.
no Q.2630.x).
Although this document refers to the use of the H.248 (Megaco)
gateway control protocol, many of the concepts and procedures are
not specific to this protocol.
2 Conventions used in this document
The following terminology is used:
- ATM signalling: Signalling as defined in Q.2931 [1]
- Connection: A service-level concept, that allows the
transmission of a bidirectional packet media stream between two
MGs. For AAL2, a connection is carried within an AAL2 channel.
- VCCI: Virtual Channel Connection Identifier, used to identify
the end-to-end ATM VCC path.
- CID: Channel IDentifier, used to identify an AAL2 channel within
a VCC.
- Master MG: This MG selects VCCI/CID.
Barr Informational - Expires Nov. 2002 1
Media Gateway AAL2 Bearer-Path Establishment June 2002
- Slave MG: This MG uses a VCCI/CID selected by the master MG.
The association of being a master or slave is for that connection
only, i.e. a MG can be the master for some connections, and the
slave for other connections.
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 [2].
3 Introduction
Although the H.248 [3] and RFC3108 [4] standards mention the use of
AAL2, they do not clearly specify the required messaging or
procedures for AAL2 bearer-path establishment between two MGs. To
avoid different interpretations creating incompatible solutions,
this document proposes specific procedures for use by MGs which use
provisioned VCCs and backward call setup mode dynamic SVCs, and
which do not use AAL2 signalling (i.e. no Q.2630.x).
This document makes no changes to H.248, RFC3108, nor any other
standard. It merely attempts to clarify how the standards fit
together to ensure interoperability.
It is assumed the MG can support either one, or both, of the
following classes of VCCs:
- Provisioned VCCs: These are already established (typically on
MG startup) and are already available when needed by a
connection. They can include (but are not restricted to):
o PVC: Both MGs are provisioned with the VCCI and the remote
peer's ATM address. Each MG associates this information with
a local VPI/VCI.
o SVC: Both MGs are provisioned with the VCCI and the remote
peer's ATM address. One MG is configured to initiate SVC
setup to its peer, while the peer MG is configured to
terminate it. The SVC would be created on MG startup.
- Dynamic SVCs: These are created as needed between MGs.
This document does not cover the case where there is a pool of
VPI/VCIs for dynamic PVC allocation.
VCC operations (creation, deletion, assignment of connections, etc.)
is done by MGs and is transparent to the MGC. I.e. the MGC does not
send explicit messages to establish ATM VCCs. The MGC only needs to
create ephemeral terminations at both MGs in order to create a
connection between them.
For a given VCC between two MGs, connections can be assigned by
either party, regardless of which party originated the setup of the
VCC.
4 Basic Control Flow
Barr Informational - Expires Nov. 2002 2
Media Gateway AAL2 Bearer-Path Establishment June 2002
The basic control flow is independent of whether the VCC is
provisioned or dynamically created.
The following description shows the SDP exchange using the Local and
Remote descriptors as sent in H.248 commands/replies applied on the
ephemeral (AAL2) terminations of the two MGs: MG1 (slave) and MG2
(master).
The purpose of the SDP exchange between MG1 and MG2 is:
- to determine a VCC, with sufficient bandwidth available, for
the connection. The VCC is identified by VCCI. If there is
inadequate bandwidth on existing VCCs between the two MGs,
then a new VCC may be created.
- to select an AAL2 channel within the VCC. The CID
identifies the channel.
- to agree on ONE common AAL2 profile. An AAL2 profile may
include multiple codecs, however an AAL2 channel can only
use one profile. Note: the detailed procedures for AAL2
profile negotiation, and the selection of the preferred
codec within the profile, is beyond the scope of this
document.
It is assumed the reader is familiar with RFC-3108. In particular,
the following media information line format is used:
m=<media> <virtualConnectionId> <transport#1> <format list#1>
<transport#2> <format list#2> ... <transport#M> <format list#M>
<virtualConnectionId> = <ex_vcci>/<ex_cid>
<ex_vcci> = VCCI-<vcci>
<ex_cid> = CID-<cid>
The control flow is as follows:
1) Add from MGC to MG1
Local{
v=0
c=ATM $ $
m=audio $ $ $
}
The MGC sends MG1 a request to create an ephemeral termination. MG1
is requested to return the ATM addressType, ATM address, VCCI/CID,
and AAL2 profiles that it supports.
2) Add reply from MG1 to MGC
Local{
v=0
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
m=audio - AAL2/ITU 7 2 1
}
Barr Informational - Expires Nov. 2002 3
Media Gateway AAL2 Bearer-Path Establishment June 2002
The Add reply from MG1 includes MG1's ATM address, and the AAL2
profiles that it supports. Since MG1 does not know which peer MG
will be used, it cannot return VCCI nor CID. Therefore it uses "-"
in the VCCI/CID field.
3) Add from MGC to MG2
Local{
v=0
c=ATM $ $
m=audio $ $ $
},
Remote{
v=0
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
m=audio - AAL2/ITU 7 2 1
}
The MGC sends MG2 a request to create an ephemeral termination. The
details of MG1 are sent in the Remote descriptor.
4) Add reply from MG2 to MGC
Local{
v=0
c=ATM NSAP 47.0072.8100.0000.0060.3e64.fd01.0060.3e64.3301.00
m=audio VCCI-2/CID-13 AAL2/ITU 2
}
The Add reply from MG2 includes MG2's ATM address. Since MG2 knows
the identity of the peer MG, it is able to select an appropriate VCC
to use (identified by VCCI) and a channel within that VCC
(identified by CID.) In addition, MG2 MUST select only one AAL2
profile from the list provided by MG1.
How this VCCI and CID is selected will be discussed in section 6.
If a provisioned VCC or a previously created dynamic SVC is
selected, the bearer-path is ready for use. If a new dynamic SVC is
required, then MG2 will initiate the required ATM signalling (this
is explained in more detail in section 5).
5) Modify from MGC to MG1
Remote{
v=0
c=ATM NSAP 47.0072.8100.0000.0060.3e64.fd01.0060.3e64.3301.00
m=audio VCCI-2/CID-13 AAL2/ITU 2
}
The MGC sends MG1 a Modify to inform it of the remote MG ATM
address, and the selected VCCI/CID and AAL2 profile.
6) Modify reply from MG1 to MGC
Barr Informational - Expires Nov. 2002 4
Media Gateway AAL2 Bearer-Path Establishment June 2002
MG1 acknowledges the command from the MGC, but does not send a Local
nor Remote descriptor.
5 Dynamic SVC Setup
A MG MAY support dynamic SVC creation in order to create extra
bandwidth between itself and a peer.
In the control flow shown in section 4, the master MG was requested
to choose a VCC on which to carry the connection. If there was not
sufficient bandwidth remaining on existing VCCs, the master MG could
decide that a new dynamic SVC needs to be created, and it would send
an ATM SETUP message to the slave MG.
Once the SVC is established it can be used for multiple connections,
each using its own CID. Subsequent connections between the same MGs
do not require a SVC setup as long as sufficient bandwidth is
available. Both MGs may assign connections to the new VCC.
Whether an existing VCC is usable for a connection can be determined
by a voice connection admission control algorithm based on the
projected bandwidth for the connection versus the available VCC
bandwidth and/or the number of available CIDs.
Although SVC creation is triggered by a connection request from the
MGC, once initiated the lifecycle of the SVC is independent from the
connection that initiated it. The SVC may well survive well beyond
the connection that initiated it, if it is used for other
connections.
5.1 Delayed or Immediate Reply
There are two implementation options regarding how a MG replies to
control commands: the reply can be either delayed or immediate. A
MG SHOULD only use one method, although provisioning can be used to
select which method for MGs that support both methods. Networks
containing both delayed reply and immediate reply MGs are possible.
In control flow step (3) of section 4, the master MG has two
implementation options on how it can progress the control flow:
1. Delayed reply:
In this method, the MG does not allocate the connection to a
VCC until bandwidth is available on an active VCC. This could
be either when the SVC setup is completed (i.e. an ATM
CONNECT is received back from the slave), or earlier if
bandwidth becomes available on an existing VCC following an
unrelated connection deletion on that VCC. I.e. the
connection that initiated the SVC may in fact be allocated to
a different VCC. The MG does not acknowledge the Add command
until the connection is allocated to an active VCC.
2. Immediate reply:
In this method, the MG immediately allocates the connection
to the dynamic SVC that is being created. The MG is
Barr Informational - Expires Nov. 2002 5
Media Gateway AAL2 Bearer-Path Establishment June 2002
therefore able to immediately acknowledge the Add command,
even though the SVC setup may not have been completed yet.
In control flow step (5) of section 4, the slave MG is requested to
accept the chosen VCCI/CID. The slave MG will act differently
depending on which implementation option it uses:
1. Delayed reply:
The MG does not acknowledge the Modify command until the
specified VCC becomes available, e.g. the slave MG receives
the appropriate ATM SETUP message.
The MG MUST NOT immediately reject the Modify if the VCC does
not exist, because the master MG may be using the immediate
reply method.
2. Immediate reply:
The MG immediately acknowledges the Modify command, even if
the specified VCC is not available yet.
5.2 SVC Setup Failure
On sending the ATM SETUP message, the MG will start a timer for that
SVC. If an ATM CONNECT message has not been received before the
timer expires, then the following procedures will be followed,
depending on implementation:
1. Delayed reply implementation:
The MG will reply to the Add commands with an error for each
termination (i.e. connection) waiting for the SVC to
complete.
2. Immediate reply implementation:
The MG will send an aal2/netfail event (as defined in the
H.248 Network package and section 8.1) with an appropriate
optional cause string for each termination (i.e. connection)
waiting for the SVC to complete. This implies that the MGC
MUST request the aal2/netfail event.
If the SVC completes following a time-out it will be placed in the
bandwidth pool and may be used for subsequent connections or may be
timed out (explained in section 5.5) if it remains unused.
On receiving a VCCI (in the Modify message) that does not currently
exist, the slave MG will start a timer for that termination. If an
ATM SETUP message has not been received for that VCCI before the
timer expires, then the following procedures will be followed,
depending on implementation:
1. Delayed reply implementation:
The MG will reply to the Modify with an error.
2. Immediate reply implementation:
The MG will send an aal2/netfail event (as defined in the
H.248 Network package and section 8.1) with an appropriate
optional cause string for the termination. This implies that
the MGC MUST request the aal2/netfail event.
5.3 Bearer-path Connection Available
Barr Informational - Expires Nov. 2002 6
Media Gateway AAL2 Bearer-Path Establishment June 2002
Since MGs may implement the immediate reply method, it is possible
for the service-level connection to be established before the
bearer-path has been established. With some configurations, it MAY
be desirable for the MGC to be notified when the bearer-path is
available for each termination so that it can manage the control
flow appropriately.
This can be achieved by the MGC requesting the aal2/sc event (as
defined in section 8.1) on the termination when it is Added. This
event indicates to the MGC that a termination has an established
bearer-path on which to communicate.
It is recommended that if the bearer-path is immediately available
(e.g. when using provisioned VCCs, or reusing a previously
established dynamic SVC) then the Notify should be returned in the
same message as the Add/Modify acknowledgement. This is to minimise
the amount of messaging.
A SVC-originating MG will wait for the ATM CONNECT message to be
received before reporting aal2/sc for all appropriate terminations.
A SVC-terminating MG will wait for the ATM SETUP message to be
received before reporting aal2/sc for all appropriate terminations.
5.4 Pre-creation
In addition to setting up SVCs when there is not sufficient
bandwidth available for a connection, a MG MAY optionally set up
SVCs when it only has bandwidth left for a limited number of
connections (typically 1) to a remote MG. This is termed pre-
creation of SVCs and can be used to reduce average connection setup
latency, especially if the delayed reply method is being used.
SVC pre-creation reduces connection setup latency by causing SVCs to
be created before they are needed. This means that most connections
do not incur the latency associated with a SVC setup. For example,
in trunk tandem networks, where there are multiple VCCs between most
MGs, this will reduce the number of connections that incur a SVC
setup delay to a small fraction of the total connections. The only
connections to incur the SVC delay are those between MGs that do not
yet have a VCC.
It is not always appropriate to use pre-creation. For example, if
there were a large number of MGs (e.g. line MGs), then it would not
be efficient for the network to reserve a large amount of bandwidth
for pre-created VCCs.
5.5 SVC Deletion
SVCs are deleted when they are no longer required, to conserve
allocated bandwidth in the ATM network. A SVC is deemed to be no
longer required when it has been empty for a provisionable period of
time: defined as the SVC persistence. Increasing this time has the
benefit of improving average connection latency, and reducing
Barr Informational - Expires Nov. 2002 7
Media Gateway AAL2 Bearer-Path Establishment June 2002
overall SVC setup rate, but also has the negative effect of reducing
network bandwidth efficiency.
Under normal circumstances only the end which created the SVC will
delete it when the persistence timer expires. However for network
robustness, the SVC-terminating MG MAY release a SVC if deemed
appropriate, e.g. after a long timeout that exceeds the persistence
timer. Therefore a SVC-originating MG MUST honour SVC release by
the SVC-terminating MG. Although the SVC-originating MG will
recreate a SVC due to network failure, etc., it MUST NOT try to
recreate a SVC explicitly released by the SVC-terminating MG.
In order to avoid the SVC-terminating MG assigning a connection to a
VCC which is about to be cleared by the SVC-originating MG, the SVC-
terminating MG will always run a SVC persistence timer which is less
than the provisioned value used for originated SVCs. Once this
shorter persistence timer has expired for a terminated VCC, the SVC-
terminating MG will mark the SVC as unavailable to trunk selection.
A persistence timer difference of 5 seconds is appropriate as it
allows adequate time for the SVC-terminating MG (acting as the
master) to inform the SVC-originating MG (acting as the slave) of
the selected VCCI, using SDP via the MGC, before the SVC-originating
MG persistence timer expires.
If the SVC persistence timer is set to less than 5 seconds, then the
shorter persistence timer will expire immediately when a terminated
SVC is empty, and therefore empty terminated SVCs will not be
available for allocation of connections by the SVC-terminating MG.
5.6 ATM SETUP Message
MGs which create dynamic SVCs MUST implement the appropriate
functionality (e.g. UNI4.0) to carry the VCCI within the Generic
Identifier Transport (GIT) Information Element (IE) as defined in
Q.2941.2 [5].
6 Selecting VCCs and Channels
6.1 Channel Assignment Rules
Channels are assigned to VCCs as follows:
1st: assign to any provisioned VCCs if capacity available.
2nd: assign to the fullest SVC.
Within a set of equally full SVCs assign as follows:
1st: to your originated SVCs starting at the highest VCCI.
2nd: to terminated SVCs starting at the lowest VCCI.
3rd: if no capacity is available, set up a new SVC.
Note that this is optimized to allow VCCs to be emptied out over
time so that they can be deleted during periods of low usage. There
is a remote possibility of a SVC being over allocated by one channel
if both ends allocate the last channel at the same time. This can
result in more channels being allocated to the VCC than the
Barr Informational - Expires Nov. 2002 8
Media Gateway AAL2 Bearer-Path Establishment June 2002
provisioned maximum allowed number. In this case the MG will allow
the extra channel, so as to not lose the connection. In general the
incidence of over allocation is expected to be so small as to not
affect the performance of the network.
If the ATM network performs policing of voice traffic VCCs it may be
necessary to provision the PCR & SCR of the VCCs to accommodate an
extra channel to avoid traffic loss on over allocation. In general,
however, it is strongly recommended that policing is not performed
on voice SVCs since these are generally well behaved traffic
sources.
6.2 VCCI Selection
Provisioned VCCs and dynamic SVCs SHOULD have mutually exclusive
VCCI ranges. The VCCI is a 14-bit number. Provisioned VCCs are in
the range of 0 to 4095 and dynamic SVCs are in the range 4096 to
8191. The most significant (MSb) bit of the 14-bit word is used to
indicate the SVC-originating end as explained below.
Two MGs avoid simultaneously selecting the same VCCI ("VCCI glare")
by using the Q.2941.2 [5] appendix II.1 and af-vtoa-0113.000 [6]
annex C.2.5 specified technique to identify whether it is locally or
remotely generated using the MSb of the 14-bit VCCI. The MSb is
always set to 0 on the SVC-originating MG and 1 on the SVC-
terminating MG. It works as follows:
- If creating a new dynamic SVC, the SVC-originating MG will send
VCCI with MSb=0 in the ATM SETUP.
- When the SVC-terminating MG receives the SVC SETUP, it will
store the VCCI with MSb=1. The two MGs refer to the VCC using
different VCCIs, i.e. the MSb is different.
- When a master MG decides to use a dynamic SVC (whether it was
previously created or is newly created), it will return a VCCI
(in the Add response) with the VCCI MSb inverted.
Note: The 14-bit VCCI value is packed into a 16-bit field of the GIT
IE in a special way. Refer to Q.2941.2 appendix II.1 and af-vtoa-
0113.000 annex C.2.5 for details.
Example:
1. CONNECTION 1: MG2 is the master and needs to select a VCC to
MG1. Since there is inadequate bandwidth on existing VCCs,
MG2 creates a new SVC to MG1. MG2 identifies the VCC with
VCCI=5000 (0x1388). The identifier sent in the ATM SETUP GIT
IE is: 0x08 0x08 0x02 0x27 0x88 (see Q.2941.2 appendix II.1)
2. MG1 receives the ATM SETUP message. It extracts the 14-bit
VCCI from the GIT IE, and sets the MSb to 1. I.e. MG1
identifies the new VCC as VCCI=13192 (0x3388).
3. MG2 assigns the connection to the new VCCI. It responds with
VCCI=13192 (MSb is inverted) in the "m=" line of its Local
descriptor SDP. The MGC will forward this VCCI to MG1 in the
Remote descriptor SDP.
Barr Informational - Expires Nov. 2002 9
Media Gateway AAL2 Bearer-Path Establishment June 2002
4. When MG1 receives the VCCI in the Remote descriptor SDP, it
knows to assign the connection to the newly established VCC,
with VCCI=13192.
5. CONNECTION 2: MG1 is now the master for an unrelated
connection, and needs to select a VCC to MG2. It decides to
use the SVC created by MG2 in step 1. MG1 identifies this
VCC as VCCI=13192. It responses with VCCI=5000 (MSb is
inverted) in the "m=" line of its Local descriptor SDP. The
MGC will forward this VCCI to MG2 in the Remote descriptor
SDP.
6. When MG2 receives the VCCI in the Remote descriptor SDP, it
knows to assign the connection to the previously established
VCC, with VCCI=5000.
6.3 CID Selection
It is possible that two MGs may allocate CIDs to a particular VCC at
exactly the same time for unrelated connections. The two MGs avoid
selecting the same CID ("CID glare") by having the master MG compare
its ATM address with the peer MG's ATM address. The higher address
assigns CID values from the top down (from 255), while the lower
address assigns from the bottom up (from 9).
7 Security Considerations
If dynamic SVCs are used, there is the possibility that attackers
may attempt a denial of service (DoS) attack by establishing many
SVCs with a MG, thereby using up resources.
This section describes a simple OPTIONAL security mechanism to
authenticate the SVC setup, thereby minimising DoS attacks. If this
mechanism is employed, then all MGs in the network will need to
implement it.
With this mechanism, the SVC-terminating MG authenticates the SVC
setup using a one-time password (OTP) embedded in the ATM SETUP
message from the SVC-originating MG. The OTP was previously passed
from the SVC-terminating MG to the SVC-originating MG via the H.248
control protocol.
This example control flow shows how it works:
A) Add from MGC to MG1 (slave)
B) Add reply from MG1 to MGC containing a MG1-generated OTP in the
Local descriptor SDP. MG1 adds this OTP to its list of pending
OTPs, and starts an expiry timer for the OTP.
C) Add from MGC to MG2 (master). The Local descriptor SDP
(including OTP) from MG1 is forwarded to MG2 in the Remote
descriptor.
D) If MG2 needs to establish a dynamic SVC (either for the current
connection, or for pre-creation) then it sends the OTP (from step-C)
in the ATM SETUP message. If it does not need to create a dynamic
SVC, then the OTP is discarded.
E) When MG1 receives an ATM SETUP message, it checks the OTP in the
message against its list of pending OTPs. If there is a match, the
Barr Informational - Expires Nov. 2002 10
Media Gateway AAL2 Bearer-Path Establishment June 2002
SVC setup is accepted and the OTP is taken off the pending list. If
there is not a match, then the SVC setup is rejected.
F) The rest of the flow continues as normal.
An OTP generated by the slave MG MUST be random and not equal to any
pending OTPs. The OTP MUST be a true random number, and not one
that can be predicted (i.e. not pseudo-random).
An OTP is removed from the pending list if:
- the MG receives an ATM SETUP with that OTP; or
- a timer expires. The timer should be long enough to easily
allow the peer MG time to receive the OTP (in the SDP) and
then send the OTP (in the ATM SETUP).
Note, an OTP will need to be sent by the slave MG with every reply
to an Add, regardless of what type of VCC (provisioned or dynamic
SVC) is subsequently used.
The generic description above does not explain how the OTP is
carried. The proposed method of carrying the OTP is by using fields
reserved for EECID.
The a=eecid:<eecid> line of the SDP (RFC3108) is used to carry the
OTP from the slave MG to the master MG, via the MGC.
Example:
v=0
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
m=audio - AAL2/ITU 7 2 1
a=eecid:A24F553E
If required to setup a new SVC, the master MG then forwards the OTP
in the ATM SETUP EECID field of the GIT IE.
The EECID is NOT being used as an end-to-end connection identifier -
VCCI is used for this purpose. The use of EECID is a convenient way
to represent the OTP because there are fields defined for it in
existing standards.
The EECID is 32-bits in length. This gives an attacker a chance in
4000-million of guessing a correct EECID. The attacker has to guess
the correct number while the EECID is in the pending list.
Since this security mechanism uses H.248 to carry OTPs, the H.248
protocol needs to be secured to prevent the attacker from
determining the OTPs by snooping the control protocol. This
security may be achieved by suitable network configuration, or by
the use of IPSec encryption.
Although one may think of a mechanism to use EECID for both an end-
to-end connection identifier AND an OTP, keeping the functionality
separate has the following advantages:
1. VCCI is well defined for AAL2 in standards Q.2941.2 and af-
vtoa-0113.000.
Barr Informational - Expires Nov. 2002 11
Media Gateway AAL2 Bearer-Path Establishment June 2002
2. It is useful to separate the main protocol (i.e. using VCCI)
from the security protocol (e.g. using EECID for OTP.) This
allows its use to be optional, or for it to be replaced if a
vulnerability (or better solution) is found without needing
to redefine the whole protocol.
Note: the mechanism described in this section cannot prevent DoS
attacks due to flooding of the signalling channel.
8 Packages
8.1 AAL2 Package
PackageID: aal2
Version: 1
Extends: Network package version 1
Termination-types supporting this package: AAL2.
8.1.1 Properties
None.
8.1.2 Events
Set-up complete (Bearer-path connection available)
EventID: sc
Detects whether the termination has a bearer-path connection
available for it to use.
EventsDescriptor parameters: none.
ObservedEventsDescriptor parameters: none.
8.1.3 Signals
None.
8.1.4 Statistics
Packets Sent
StatisticID: ps
Number of AAL2 packets sent.
Type: double
Possible values: any 32-bit integer
Packets Received
StatisticID: pr
Number of AAL2 packets received.
Type: double
Possible values: any 32-bit integer
Connection Type
StatisticID: ct
Type: enumeration
Barr Informational - Expires Nov. 2002 12
Media Gateway AAL2 Bearer-Path Establishment June 2002
Possible values: CCD64K, CCD56K, Voice, VBD, Fax, Modem
Buffer Underflows
StatisticID: bu
Number of times the de-jitter buffer has underflowed
Type: double
Possible values: any 32-bit integer
Buffer Overflows
StatisticID: bo
Number of times the de-jitter buffer has overflowed
Type: double
Possible values: any 32-bit integer
Total Packets Lost
StatisticID: tpl
Number of packets expected but not received.
Type: double
Possible values: any 32-bit integer
Packets Discarded
StatisticID: pd
Number of packets discarded (implementation-specific.)
Type: double
Possible values: any 32-bit integer
8.1.5 Procedures
If the MGC needs to know when a termination has a bearer-path
connection available (e.g. for managing the control flow), it can
request the MG to detect the aal2/sc event.
9 References
1 ITU-T Recommendation Q.2931, B-ISDN - DSS 2 - UNI Layer 3
specification for Basic Call/Connection Control
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 ITU-T Recommendation H.248, Gateway Control Protocol, 06/2000.
ALSO: RFC-3015, "Megaco Protocol Version 1.0", November 2000, The
Internet Society.
4 RFC-3108, "Conventions for the use of the Session Description
Protocol (SDP) for ATM Bearer Connections", May 2001, The
Internet Society.
5 ITU-T Recommendation Q.2941.2, B-ISDN - DSS 2 - Generic
Identifiers Transport Extensions, 12/1999.
6 AF-VTOA-0113.000, "ATM Trunking using AAL2 for Narrowband
Services", The ATM Forum, Technical Committee, February 1999.
10 Acknowledgments
Concepts and procedures in this document were derived from work by
the following people (in alphabetical order): David Barr, Jean-
Pierre Caron, Yolande Cates, Berry Credle, Ismail Dahel, Graeme
Gibbs, and Rade Gvozdanovic.
11 Author's Address
Barr Informational - Expires Nov. 2002 13
Media Gateway AAL2 Bearer-Path Establishment May 2002
David Barr
Nortel Networks
London Road
Harlow, Essex, CM17 9NA
United Kingdom
Email: David.Barr@nortelnetworks.com
Barr Informational - Expires Nov. 2002 14
Media Gateway AAL2 Bearer-Path Establishment May 2002
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 implementation 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 languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
12 Expiration Date
This memo is filed as <draft-barr-megaco-aal2bearer-00.txt>, and
expires November 21, 2002.
Barr Informational - Expires Nov. 2002 15
