[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3441

Internet Engineering Task Force                               R. Kumar
Internet Draft                                           Cisco Systems
Document: <draft-rajeshkumar-mgcp-atm-package-00.txt>
November 2000
Category: Informational


                            ATM MGCP Package

Status of this Document

  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.0. Abstract

  This document describes an ATM MGCP package which includes new Local
  Connection Options, ATM specific events and signals and ATM
  statistics parameters. Also included in a description of profile
  negotiation.

2.0. 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.

3.0. ATM Package

  The ATM package in this document consists of Local Connection Options
  which are described in section 3.1, Events and Signals - section 3.2
  and ATM statistics parameters - section 3.3. Also included in the
  document is a section on what Local Connection Options should not be
  included to insure consistency with the ATM parameters - section 4.1,
  and a section on profile negotiation - section 4.2.






R.Kumar                      Informational                          1
                            ATM MGCP Package               October 2000

3.1. ATM Local Connection Options

  For ATM networks, the "nt" local connection option in MGCP must be
  set to "ATM". Some additional Local Connection Option (LCO)
  parameters are also required. Besides being included in the LCO used
  in the create connection, modify connection and audit connection
  transactions, these parameters are included in the capabilities
  structure in audit endpoint transactions.

  In the  ATM networks addressed here,  services are carried directly
  over ATM without an intervening IP layer. The LCO parameters
  described in this section are not needed for VoIP calls which can be
  carried, in whole or in part, over an ATM network. In that case, the
  LCO parameters  defined for IP are sufficient.

  ATM Local Connection Options are divided into the following
  categories: basic, bearer assignment, AAL1, AAL2, AAL5 and traffic
  management.

  Note that the local connection option names described are used
  without the ("atm") package prefix.

3.1.1 Basic ATM local connection options

  Basic local connection options are common to a wide range of
  applications. These are listed in the following table and then
  explained in detail.

  +---------+---------------+---------------------------------------+
  | ATM LCO |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   ct    | Connection    |AAL1, AAL1_SDT, AAL1_UDT, AAL2, AAL3/4,|
  |         | Type          |AAL5, USER_DEFINED_AAL                 |
  +---------+---------------+---------------------------------------+
  | aalApp  | Application   |itu_h323c,af83,assuredSSCOP,           |
  |         |               |nonassuredSSCOP, itu_i3661, itu_i3662, |
  |         |               |itu_i3651,itu_i3652, itu_i3653,        |
  |         |               |FRF5, FRF8, FRF11,itu_h2221            |
  +---------+---------------+---------------------------------------+
  |   sbc   | Subchannel    | 1...24 for T1-based applications      |
  |         | Count         | 1...31 for E1-based applications      |
  +---------+---------------+---------------------------------------+
  |   vc    |VC/Bearer type | PVC, SVC, CID                         |
  +---------+---------------+---------------------------------------+
  |   pf    | Partial fill  | 1...48                                |
  |         |               |                                       |
  +---------+---------------+---------------------------------------+
  |   vsel  | Voice codec   | See below                             |
  |         | Selection     |                                       |
  +---------+---------------+---------------------------------------+
  |   dsel  | Data codec    | See below                             |
  |         | Selection     |                                       |
  +---------+---------------+---------------------------------------+



R.Kumar                      Informational                          2
                            ATM MGCP Package               October 2000

  +---------+---------------+---------------------------------------+
  |   fsel  | Fax codec     | See below                             |
  |         | Selection     |                                       |
  +---------+---------------+---------------------------------------+
  |  fcpcs  | Forward       | AAL2: 45 or 64                        |
  |         | maximum CPCS  | AAL5: 1-65,535                        |
  |         | SDU size      |                                       |
  +---------+---------------+---------------------------------------+
  |  bcpcs  | Backward      | AAL2: 45 or 64                        |
  |         | maximum CPCS  | AAL5: 1-65,535                        |
  |         | SDU size      |                                       |
  +---------+---------------+---------------------------------------+

Connection type (ct): This parameter describes the ATM adaptation
layer. The values that can be assigned to it are: AAL1, AAL1_SDT,
AAL1_UDT, AAL2, AAL3/4, AAL5 and USER_DEFINED_AAL. The user defined
adaptation layer is per amendment 2 of ITU-T Q.2931.

AAL application (aalApp): This specifies the application layer on top
of the adaptation layer. The following is a non-exhaustive list of
strings describing certain applications. Other strings are possible. If
used, these need to be defined a priori for an application.

        "itu_h323c"           Annex C of H.323 which specifies direct
                              RTP on AAL5 [12].

         "af83"               af-vtoa-0083.001, which specifies
                              variable size AAL5 PDUs with PCM voice
                              and a null SSCS [13].

      "assuredSSCOP"          SSCOP as defined in ITU Q.2110 [14].
                              assured operation.

      "nonassuredSSCOP"       SSCOP as defined in ITU Q.2110 [14],
                              non-assured operation.

         "itu_i3661"          SSCS per ITU I.366.1 [11].

         "itu_i3662"          SSCS per ITU I.366.2 [2].

         "itu_i3651"          Frame relay SSCS per ITU I.365.1 [15].

         "itu_i3652"          Service-specific coordination function,
                              as defined in ITU I.365.2, for Connection
                              Oriented Network Service (SSCF-CONS)
                              [16].

         "itu_i3653"          Service-specific coordination function,
                              as defined in ITU I.365.3, for Connection
                              Oriented Transport Service (SSCF-COTS)
                              [17].

        "FRF5"                Use of the FRF.5 frame relay standard
                              [23].


R.Kumar                      Informational                          3
                            ATM MGCP Package               October 2000


        "FRF8"                Use of the FRF.8 frame relay standard
                              [24].

        "FRF11"               Use of the FRF.11 frame relay standard
                              [25].

        "itu_h2221"           Use of the ITU standard H.222.1 for
                              audiovisual communication over AAL5
                              [22].

Subchannel count (sbc): This parameter indicates the number of DS0s in
an n x 64 connection. Such connections use an ATM adaptation layer 1
(ATM forum af-vtoa-78) or 2 (ITU I.366.2). For T1-based applications,
it can take on integral values in the inclusive range [1...24]. For E1-
based applications, it can take on integral values in the inclusive
range [1...31]. When this parameter is omitted, the subchannel count
must be known by other means.

Type of Bearer/VC (vc): This indicates whether a PVC, CID or an SVC is
to be used for an ATM connection. Possible values are: PVC, SVC or CID.
Omitting this parameter will result in the use of a default, which
could be embedded or provisioned. The value "PVC" covers both classical
PVCs and SPVCs.The value "SVC" does not imply that the gateway will or
should set up an SVC. Rather, an L:se:on parameter (described below) is
used to explicitly request an SVC set-up.

Partial Fill Count (pf): When present, the 'pf' parameter is used to
indicate the fill level of cells. When this local connection option is
absent, then other means (such as provisionable defaults) are used to
determine the presence and level of partial fill.

This parameter indicates the number of non-pad payload octets, not
including any AAL SAR or convergence sublayer octets. For example, in
some AAL1 applications that use partially filled cells with padding at
the end, this attribute indicates the number of leading payload octets
not including any AAL overhead.

In general, permitted values of the pf parameter are integers in  the
range 1 - 48 inclusive. However, this upper bound is  different for
different adaptations since the AAL overhead, if any, is different. If
the specified partial fill is greater than or equal to the maximum
fill,  then complete fill is used. Using a 'partial' fill of 48 always
disables partial fill.

In the AAL1 context, this parameter applies uniformly to both P and
non-P cells. In AAL1 applications that do not distinguish between P and
non-P cells, a value of 47 indicates complete fill (i.e. the absence of
partial fill). In AAL1 applications that distinguish between P and non-
P cells, a value of 46 indicates no padding in P-cells and a padding of
one in non-P cells.

If partial fill is enabled (i.e there is padding in at least some
cells), then AAL1 structures must not be split across cell boundaries.


R.Kumar                      Informational                          4
                            ATM MGCP Package               October 2000

These shall fit in any cell. Hence, their size shall be less than or
equal to the partial fill size. Further, the partial fill size is
preferably  an integer multiple of the structure size. If not, then the
partial fill size stated in the local connection options shall be
truncated to an integer multiple of the structure size (e.g. a partial
fill size of 40 is truncated to 36 to support six 6 x 64 channels).

Voice codec selection (vsel): This is a prioritized list of one or more
3-tuples describing voice service. Each vsel 3-tuple indicates a codec,
an optional packet length and an optional packetization period. The
vsel local connection option is structured as follows:

                <encodingName #1> <packetLength #1><packetTime #1>
                <encodingName #2> <packetLength #2><packetTime #2>
                ...
                <encodingName #N> <packetLength #N><packetTime #N>

where the <encodingName> refers to a codec name such as PCMU, G726-32,
G729  etc. The <packetLength> is a decimal integer representation of
the packet length in octets. The <packetTime> is a decimal integer
representation of the packetization interval in ms.

Voiceband data codec selection (dsel): This is a prioritized list of
one or more 3-tuples describing voiceband data service. Each dsel 3-
tuple indicates a codec, an optional packet length and an optional
packetization period. Depending on the application, the dsel local
connection option may or may not cover facsimile service. This is
indicated via an <fxIncl> flag preceding the list of 3-tuples. This
flag indicates whether the definition of voiceband data includes
facsimile ("on" value) or not ("off" value). This flag can also be set
to "-", which is equivalent to setting it to "off". If <fxIncl> is
"on", then the dsel connection option must be consistent the fsel
connection option. The dsel local connection option is structured as
follows:

       <fxIncl> <encodingName #1> <packetLength #1><packetTime #1>
                <encodingName #2> <packetLength #2><packetTime #2>
                ...
                <encodingName #N> <packetLength #N><packetTime #N>

where the <encodingName> refers to a codec name such as PCMU, G726-32,
G729  etc. The <packetLength> is a decimal integer representation of
the packet length in octets. The <packetTime> is a decimal integer
representation of the packetization interval in ms.


Facsimile codec selection (fsel): This is a prioritized list of one or
more 3-tuples describing fax service. Each fsel 3-tuple indicates a
codec, an optional packet length and an optional packetization period.
If the dsel option includes facsimile, the fsel connection option
should be consistent with it.   Each fsel 3-tuple indicates a codec, an
optional packet length and an optional packetization period. The fsel
local connection option is structured as follows:



R.Kumar                      Informational                          5
                            ATM MGCP Package               October 2000

                <encodingName #1> <packetLength #1><packetTime #1>
                <encodingName #2> <packetLength #2><packetTime #2>
                ...
                <encodingName #N> <packetLength #N><packetTime #N>

where the <encodingName> refers to a codec name such as PCMU, G726-32,
G729  etc. The <packetLength> is a decimal integer representation of
the packet length in octets. The <packetTime> is a decimal integer
representation of the packetization interval in ms.

The vsel, fsel and dsel parameters complement the rest of the  local
connection options and should be consistent with them.

Examples of the use of these parameters are:

     L: vsel:G729 10 10 G726-32 40 10
     L: dsel:off PCMA 10 10 G726-32 40 10
     L: fsel:PCMU 40 5 G726-32 20 5

     L: vsel:G729 10 10 G726-32 40 10
     L: dsel:on  PCMA 10 10 G726-32 40 10

The <packetLength>and <packetTime> can be set to "-" when not needed. A
<fxIncl> value of "-" is equivalent to setting it to "off". For
example:

     L: vsel:G729 - - G726-32 - -
     L: dsel:- G729 - - G726-32 - -
     L:fsel:FXDMOD-3 - -

The vsel, dsel and fsel local connection options can be used in the
AAL1, AAL2 and AAL5 contexts. The <packetLength> and <packetTime> are
not meaningful in the AAL1 case and should be set to "-". In the AAL2
case, these local connection options determine the use of some or all
of the rows in a given profile table. If multiple 3-tuples are present,
they can indicate a preferentially ordered assignment of some rows in
that profile to voice, voiceband data or facsimile service e.g. row A
preferred to row B etc. If multiple profiles are specified in the pfl
parameter (described below), the profile qualified by these local
connection options is the first profile in the list.

Forward maximum CPCS-SDU size (fcpcs): Here, forward is the direction
away from the media gateway. The format of this parameter is described
below.

Backward maximum CPCS-SDU size (bcpcs): Here, backward is the direction
towards the media gateway. The format of this parameter is described
below.

The range of values for fcpcs and bcpcs depends on the adaptation as
follows:





R.Kumar                      Informational                          6
                            ATM MGCP Package               October 2000

                  |--------------|-----------------------|
                  | Adaptation   |    Range              |
                  |--------------|-----------------------|
                  |     AAL5     |  1 - 65,535           |
                  |--------------|-----------------------|
                  |     AAL2     | 45 or 64              |
                  |--------------|-----------------------|

3.1.2 ATM Bearer Assignment local connection options

These are listed in the following table and then explained in detail.

  +---------+---------------+---------------------------------------+
  | ATM LCO |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   se    | Enable path   | on, off                               |
  |         | set-up        |                                       |
  +---------+---------------+---------------------------------------+
  |   ci    | Connection    | See below                             |
  |         | Element       |                                       |
  |         | Identifier    |                                       |
  +---------+---------------+---------------------------------------+


Enable path set-up (se): This local connection option is used to
explicitly enable or disable the use of bearer signaling for path set-
up. Permitted   values of this local connection option are  "on" and
"off". When this option is omitted, other means are used to determine
if bearer signaling is to be used for path set-up. Examples of bearer
signaling are SVC signaling, ITU Q.2630.1 signaling and combinations
thereof. Examples of such combinations are the set-up of an AAL2 SVC
and the assignment of a CID within it or the set-up of a concatenation
of an AAL2 single-CID SVC and a CID channel within a multiplexed AAL2
VC. This option allows the flexible support of both the backwards and
forward SVC set-up methods. In the former case, the call-terminating
gateway sets up the SVC. In the latter case, the call-originating
gateway sets up the SVC.

Connection Element Identifier (ci): This indicates the Virtual Circuit
or CID to be used for the bearer connection. It is used when the call
agent manages VC and/or CID resources in the bearer network. It can be
expressed with implicit or explicit designation of subparameter types.

With explicit designation, subparameters are identified by constant
strings followed by a hyphen and the actual subparameter. With implicit
designation, the constant strings are omitted.

With explicit subparameter type designation, the ci parameter can be in
one of the following formats:

        * VCCI-<vcci>
        * VCCI-<vcci>/CID-<cid>
        * <ATMaddressType>-<ATMaddress>/VCCI-<vcci>
        * <ATMaddress>/VCCI-<vcci>


R.Kumar                      Informational                          7
                            ATM MGCP Package               October 2000

        * <ATMaddressType>-<ATMaddress>/VCCI-<vcci>/CID-<cid>
        * <ATMaddress>/VCCI-<vcci>/CID-<cid>
        * BCG-<bcg>/VCCI-<vcci>
        * BCG-<bcg>/VCCI-<vcci>/CID-<cid>
        * BCG-<bcg>/VPI-<vpi>/VCI-<vci>
        * BCG-<bcg>/VPI-<vpi>/VCI-<vci>/CID-<cid>
        * PORT-<portId>/VPI-<vpi>/VCI-<vci>
        * PORT-<portId>/VPI-<vpi>/VCI-<vci>/CID-<cid>
        * VPCI-<vpci>/VCI-<vci>
        * VPCI-<vpci>/VCI-<vci>/CID-<cid>
        * <ATMaddressType>-<ATMaddress>/VPCI-<vpci>/VCI-<vci>
        * <ATMaddress>/VPCI-<vpci>/VCI-<vci>
        * <ATMaddressType>-<ATMaddress>/VPCI-<vpci>/VCI-<vci>/CID-<cid>
        * <ATMaddress>/VPCI-<vpci>/VCI-<vci>/CID-<cid>

With implicit subparameter type designation, the ci parameter can be in
one of the following formats:

        * <vcci>
        * <vcci>/<cid>
        * <ATMaddressType>-<ATMaddress>/<vcci>
        * <ATMaddress>/<vcci>
        * <ATMaddressType>-<ATMaddress>/<vcci>/<cid>
        * <ATMaddress>/<vcci>/<cid>
        * <bcg>/<vcci>
        * <bcg>/<vcci>/<cid>
        * <bcg>/<vpi>/<vci>
        * <bcg>/<vpi>/<vci>/<cid>
        * <portId>/<vpi>/<vci>
        * <portId>/<vpi>/<vci>/<cid>
        * <vpci>/<vci>
        * <vpci>/<vci>/<cid>
        * <ATMaddressType>-<ATMaddress>/<vpci>/<vci>
        * <ATMaddress>/<vpci>/<vci>
        * <ATMaddressType>-<ATMaddress>/<vpci>/<vci>/<cid>
        * <ATMaddress>/<vpci>/<vci>/<cid>

The subparameters of the ci parameter are defined as follows:


  |--------------|-----------------------|----------------------------|
  | Subparameter |    Meaning            |   Representation           |
  |--------------|-----------------------|----------------------------|
  |     vcci     | VC connection Id      | 16-bit equivalent          |
  |--------------|-----------------------|----------------------------|
  |     cid      | Channel Id            |  8-bit equivalent          |
  |--------------|-----------------------|----------------------------|
  |ATMaddressType| ATM address type      | "NSAP", "E164", "GWID",    |
  |              |                       | "ALIAS"
  |--------------|-----------------------|----------------------------|






R.Kumar                      Informational                          8
                            ATM MGCP Package               October 2000

  |--------------|-----------------------|----------------------------|
  | ATMaddress   | ATM address           | 40 hex digits   ("NSAP")   |
  |              |                       | upto 15 digits ("EI64")    |
  |              |                       | upto 32  chars ("GWID")    |
  |              |                       | upto 32  chars ("ALIAS")   |
  |--------------|-----------------------|----------------------------|
  |    bcg       |Bearer Connection Group| 8-bit equivalent           |
  |--------------|-----------------------|----------------------------|
  |    vpi       |    Virtual Path Id    | 8 or 12-bit equivalent     |
  |--------------|-----------------------|----------------------------|
  |    vci       |    Virtual Channel Id | 16-bit equivalent          |
  |--------------|-----------------------|----------------------------|
  |    portID    |    Port Id            | Upto 32 digits (decimal or |
  |              |                       | hex) or up to 32 characters|
  |--------------|-----------------------|----------------------------|
  |    vpci      |    VP connection ID   | 16-bit equivalent          |
  |              |                       |                            |
  |--------------|-----------------------|----------------------------|


The VPCI is a 16 bit field defined in Section 4.5.16 of ITU Q.2931. The
VPCI  is similar to the VPI,except for its width and the fact that it
retains  its value across VP crossconnects.

The VCCI is a 16 bit field defined in ITU Recommendation Q.2941.2 [14].
The VCCI is similar to the VCI, except for the fact that it retains
its value across VC crossconnects.

Since <vpci> and  <vcci> values are  unique between  a  pair of nodes,
they need to be qualified, at any node, by the ATM address of the
remote  node. These parameters can be pre-provisioned or signaled via
SVC signaling messages. When VPCI and VCCI values are pre-provisioned,
administrations have the option of provisioning them uniquely in a
network or in a subnet. In this case, the ATM address of the far end is
not needed to qualify theseparameters.

The <portId> parameter is used to identify the physical trunk port on a
stand-alone  ATM node  or on a multiplexer into  which the gateway is
plugged as a tributary module. It can be represented as a decimal or
hex number of up to 32 digits, or an alphanumeric string of up to 32
characters.

In some applications, it is meaningful to bundle  a set of connections
between a pair of ATM nodes into a bearer connection group. The <bcg>
subparameter is an eight bit field that allows the bundling of up
to 255 VPCs or VCCs.

In some applications, it is necessary to wildcard some elements of the
ci local connection option. The "$" wildcard character can be
substituted for some of the terms of this parameter. A wildcarded ci
parameter can use the explicit or implicit formats described above. In
the former, the constant strings that qualify the terms in the ci
parameter are retained. The concatenation <ATMaddressType>-<ATMaddress>
can be wildcarded in the following ways:


R.Kumar                      Informational                          9
                            ATM MGCP Package               October 2000


  * The entire concatenation, <ATMaddressType>-<ATMaddress>, is
    replaced with a "$".
  * <ATMaddress> is replaced with a "$", but <ATMaddressType> is
    not.

Examples of wildcarding the ci parameter in the AAL1 and AAL5contexts
are: $, 62/$, 100/20/$, VCCI-$, BCG-100/VPI-20/VCI-$.

Examples of wildcarding the <virtualConnectionId> in the AAL2 context
are: $, 62/$, 100/20/$, VCCI-40/CID-$, BCG-100/VPI-20/VCI-120/CID-$.

If the ATMaddressType is NSAP, the ATMaddress is expressed as
a string of 40  hex characters. As an option, dots can be included
after 16-bit fields, with the first dot following an 8-bit field
(standard dotted hex NSAP format). The last octet of the NSAP
address is the 'selector' field that is not used for ATM addressing
and is available for non-standard use.  For example:

 L: ci:NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00/VCCI-65

If the ATMaddressType is E164, the ATMaddress is expressed as a decimal
number  with up to 15 digits. For example:

 L: ci:E164 9738294382/VCCI-100

The E.164 numbers used can be in the International Format E.164 or
conform to a private numbering plan.

If the ATMaddressType is GWID meaning that the address is a
Gateway Identifier or Node Alias. This may or may not be globally
unique. In this case, the  ATMaddress is expressed as alphanumeric
string ("A"-"Z", "a"-"z", "0" - "9",".","-","_"). For example:

L: ci:GWID officeABCmgx101vism12

The keyword "ALIAS" can be substituted for "GWID". For example:

L: ci:ALIAS officeABCmgx101vism12

An example of a GWID (ALIAS)is the CLLI code used for telecom
equipment. For all practical purposes, it should be adequate for the
GWID (ALIAS) to be a variable length string with a maximum size of 32
characters. Some network administrations  might restrict it to a
smaller size (e.g. 15 characters).

3.1.3  AAL1 local connection options

These are useful in AAL1 applications. All AAL1 applications do not use
all these options. These options are first listed and then explained in
detail.





R.Kumar                      Informational                         10
                            ATM MGCP Package               October 2000

  +---------+---------------+---------------------------------------+
  | ATM LCO |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   crt   | Clock Recovery|  NULL, SRTS, ADAPTIVE                 |
  |         | Type          |                                       |
  +---------+---------------+---------------------------------------+
  |   str   | Structure     |  1...65,535                           |
  |         | Size          |                                       |
  +---------+---------------+---------------------------------------+
  |   fe    | FEC enable    | NULL, DELAY_SENSITIVE,LOSS_SENSITIVE  |
  +---------+---------------+---------------------------------------+

Clock recovery type (crt): This is used in AAL1 UDT (unstructured data
transfer) applications only. It takes on the values: "NULL", "SRTS", or
"ADAPTIVE". A value of "NULL" is equivalent to omitting this  parameter
and implies that the stream (T1 or E1)  encapsulated in ATM is either
synchronous to the ATM network or is re-timed, before AAL1
encapsulation,  via slip buffers. The default value is "NULL".

Structured Data Transfer Block Size (str): This parameter is meaningful
only when structured AAL1 is used (L: ct:AAL1_SDT). It indicates the
size (in octets) of the block used for structured data transfer. If not
included as a local connection option, the structure size  is to be
known by other means. For instance, af-vtoa-78 [20]  fixes the
structure size for  n x 64 service, with or without CAS. The L:str
parameter is coded as a 16-bit field along the lines of ITU Q.2931. The
theoretical maximum value  of this parameter is is 65,535, although
most services use much less.

Forward Error Correction Enable (fe): This indicates whether FEC, as
defined in ITU I.363.1 [1], is enabled or not. Possible values are:
"NULL", "DELAY_SENSITIVE" and "LOSS_SENSITIVE". FEC can be enabled
differently for delay-sensitive and loss-sensitive connections. A null
value implies disabling this capability and indicates that FEC is not
enabled for an AAL1 connection.

3.1.4 AAL2 local connection options

These are useful in AAL2 applications. All AAL2 applications do not use
all these options. These options are first listed and then explained in
detail.















R.Kumar                      Informational                         11
                            ATM MGCP Package               October 2000


  +---------+---------------+---------------------------------------+
  | ATM LCO |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   pfl   | Profile List  |  See below                            |
  |         | Type          |                                       |
  +---------+---------------+---------------------------------------+
  |   mxcd  | Maximum number|  1...255                              |
  |         | of CIDs       |                                       |
  +---------+---------------+---------------------------------------+
  |   tmcu  | Combined use  | Integer microseconds                  |
  |         | timer         |                                       |
  +---------+---------------+---------------------------------------+
  |   frmd  | Frame mode    | on,off                                |
  |         | enable        |                                       |
  +---------+---------------+---------------------------------------+
  | genpcm  | Generic PCM   | PCMA, PCMU                            |
  |         | setting       |                                       |
  +---------+---------------+---------------------------------------+
  | adt     | Assured data  | on, off                               |
  |         | transfer      |                                       |
  +---------+---------------+---------------------------------------+
  | ted     | Transmission  | on, off                               |
  |         |error detection|                                       |
  +---------+---------------+---------------------------------------+
  | aalsap  |Service access | AUDIO, MULTIRATE                      |
  |         |point          |                                       |
  +---------+---------------+---------------------------------------+
  | ffrm    |Forward maximum| 1-65,535                              |
  |         |frame block    |                                       |
  |         |size           |                                       |
  +---------+---------------+---------------------------------------+
  | bfrm    |Backward       | 1-65,535                              |
  |         |maximum frame  |                                       |
  |         |block size     |                                       |
  +---------+---------------+---------------------------------------+


Profile List (pfl): This is a list of profiles. Profile types are
followed by profile numbers for each type. The ordering of profiles can
imply preference, with the most preferred profile first. There can be
multiple instances of the same profile type in this list.

The format of the pfl parameter is as follows:

<profileType#1><format list#1><profileType#2><format list#2> ...
<profileType #M><format list#M>

where <format list#i> has the form <profile#i_1>...<profile#i_N>

The <profileType> parameter indicates the type of profile. It is
expressed in the format AAL2/<profileClass> where <profileClass>
identifies the  source of the definition of the profile.



R.Kumar                      Informational                         12
                            ATM MGCP Package               October 2000

The <profileClass> can be assigned  a string value indicating the
source of the subsequent profile numbers until the next <profileType>
field.  The following rules apply to the contents of the <profileClass>
field:

    - <profileClass> = "ITU" indicates profiles defined by ITU.
      Examples: profiles defined in the I.366.2 specification [2].
    - <profileClass> = "ATMF"  indicates profiles defined by ATM
      forum. Examples: profiles defined in af-vtoa-0113 [3]
      or af-vmoa-0145.000 [21].
    - <profileClass> = "custom"  indicates profiles defined by a
      corporation or a multi-vendor agreement. Since there is no
      standard administration of this convention, care should be taken
      to preclude inconsistencies within the scope of a deployment.
    - <profileClass> = <corporateName>
      An equipment vendor or service provider can use its registered,
      globally unique corporate name (e.g. Cisco, Telcordia etc.) as a
      string value of the <profileClass>. It is suggested that
      organizations maintain consistent definitions of the advertised
      AAL2 profiles that bear their corporate name.
    - The <profileClass> can be based on IEEE Standard 802-1990,
      Section 5.1, which defines the globally unique, IEEE-
      administered, three-octet OUIs used in MAC addresses and protocol
      identifiers.  In this case, the <profileClass> field shall be
      assigned a string value of "IEEE:" concatenated with <oui> where
      <oui> is the hex representation of a three-octet field identical
      to the IEEE OUI. Since this is always represented in hex,  the
      "0x" prefix is not used. For example, "IEEE:00000C" is one of the
      <oui> values that refers to Cisco Systems, Inc.

The <profile#> parameter is expressed as a decimal number in the range
1-255.

An example of the use of the pfl parameter is:

L: pfl:AAL2/ITU 8  AAL2/ATMF 7  AAL2/custom 100  AAL2/cisco 200,
AAL2/IEEE:00000C 150

The syntax for pfl can be represented compactly in the following ABNF
(rfc2234) form:

  pfl  = 1*(profileType (1*profile#))
  profileType = "AAL2/" profileClass space
  profile# = 1-255 space ; decimal integer followed by space
  profileClass  = "ATMF"/"ITU"/"custom"/corporateName/("IEEE:"oui)
  corporateName =  1*ALPHA   ;one or more alphanumeric characters
  oui  = 6 HEXDIG;exactly 6 hex digits per IEEE Standard 802-1990
  space = %d32

Maximum number of multiplexed CIDs (mxcd): This can take on values in
the range 1...255. It is represented  in decimal or hex (0x prefix)
format.




R.Kumar                      Informational                         13
                            ATM MGCP Package               October 2000

AAL2 combined use timer (tmcu): This is defined in ITU I.363.2 [10]. It
is represented as an integer number of microseconds.

AAL2 frame mode data enabled (frmd): Frame mode data is defined in ITU
I.366.2 [2].  The frmd local connection option can take on the
following values: on, off.

Generic PCM setting (genpcm): This indicates whether generic PCM
encoding in AAL2 profiles is A-law or Mu-law.  It takes on string
values of "PCMA" and "PCMU".

Assured data transfer (adt): Assured data transfer is defined in  ITU
I.366.1 [11].  The adt local connection option can take on the
following values: on, off.

Transmission error detection (ted): Transmission error detection is
defined in  ITU I.366.1 [11].  The ted local connection option can take
on the following values: on, off.

AAL service access point (aalsap): The service access point for AAL2 is
defined in ITU I.366.2 [2]. The aalsap local connection option can take
on the following string values: AUDIO, MULTIRATE.

Forward maximum frame mode block size (ffrm) and backward maximum frame
mode block size (bfrm):  This is the maximum size of the frame mode
data unit (I.366.2) [2] or the SSSAR-SDU (I.366.1)[11].  Here, forward
refers to the direction away from the media gateway. Backward refers to
the direction towards the media gateway. The range of values is 1 -
65,535.

3.1.5 AAL5 local connection options

In the future, local connection options specific to AAL5 might be
defined. Currently, there are none. AAL5 applications are adequately
addressed by other local connection options.

3.1.6 ATM Traffic Management local connection options

These are listed in the following table and then explained in detail.

















R.Kumar                      Informational                         14
                            ATM MGCP Package               October 2000


  +---------+---------------+---------------------------------------+
  | ATM LCO |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  | atc     | ATM transfer  |CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR,   |
  |         | capability or |DBR,SBR,ABT/IT,ABT/DT,ABR              |
  |         | service       |                                       |
  |         | category      |                                       |
  +---------+---------------+---------------------------------------+
  | subtype |atc subtype    | 1...3                                 |
  +---------+---------------+---------------------------------------+
  | qos     | QoS class     | 0...5                                 |
  +---------+---------------+---------------------------------------+
  | bcob    |Broadband      | 0...31                                |
  |         |Connection     |                                       |
  |         |-Oriented      |                                       |
  |         |Bearer Class   |                                       |
  +---------+---------------+---------------------------------------+
  | stc     |Susceptibility |0...3                                  |
  |         |to clipping    |                                       |
  +---------+---------------+---------------------------------------+
  | upcc    |User plane     |0...3                                  |
  |         |connection     |                                       |
  |         |configuration  |                                       |
  +---------+---------------+---------------------------------------+
  | aqf     |ATM QoS        | List, see below                       |
  |         |parameters,    |                                       |
  |         |forward        |                                       |
  |         |direction      |                                       |
  +---------+---------------+---------------------------------------+
  | aqb     |ATM QoS        | List, see below                       |
  |         |parameters,    |                                       |
  |         |backward       |                                       |
  |         |direction      |                                       |
  +---------+---------------+---------------------------------------+
  | adf0+1  |ATM traffic    | List, see below                       |
  |         |descriptor,    |                                       |
  |         |forward        |                                       |
  |         |direction,     |                                       |
  |         |CLP-independent|                                       |
  +---------+---------------+---------------------------------------+
  | adf0    |ATM traffic    | List, see below                       |
  |         |descriptor,    |                                       |
  |         |backward       |                                       |
  |         |direction,     |                                       |
  |         |CLP=0          |                                       |
  +---------+---------------+---------------------------------------+
  | adb0+1  |ATM traffic    | List, see below                       |
  |         |descriptor,    |                                       |
  |         |forward        |                                       |
  |         |direction,     |                                       |
  |         |CLP-independent|                                       |
  +---------+---------------+---------------------------------------+



R.Kumar                      Informational                         15
                            ATM MGCP Package               October 2000

  +---------+---------------+---------------------------------------+
  | adb     |ATM traffic    | List, see below                       |
  |         |descriptor,    |                                       |
  |         |backward       |                                       |
  |         |direction,     |                                       |
  |         |CLP=0          |                                       |
  +---------+---------------+---------------------------------------+
  | abrf    |ABR parameters,| List, see below                       |
  |         |forward        |                                       |
  |         |direction      |                                       |
  +---------+---------------+---------------------------------------+
  | abrb    |ABR parameters,| List, see below                       |
  |         |backward       |                                       |
  |         |direction      |                                       |
  +---------+---------------+---------------------------------------+

ATM transfer capability (atc): This parameter indicates the the ATM
Transfer Capability described in ITU I.371 [19], equivalent to the ATM
Service Category described in the UNI 4.1 Traffic Management
specification [8]. In applications conforming to ITU I.371, this
parameter can be assigned the following values: DBR, SBR, ABT/IT,
ABT/DT, ABR. In applications conforming to the UNI 4.1 Traffic
Management specification, this parameter can be assigned the following
values: CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR.

atc Subtype (subtype): This qualifies the atc local connection option.
It can be assigned integer values of 1...3. Combining the atc and the
subtype parameters yields the following ATM transfer capabilities and
service categories defined in [19] and [8]: UBR.1, UBR.2, GFR.1, GFR.2,
SBR.1, SBR.2, SBR.3, nrt-VBR.1, nrt-VBR.2, nrt-VBR.3, rt-VBR.1, rt-
VBR.2, rt-VBR.3.

QoS class (qos): This indicates the QoS class specified in ITU I.2965.1
[4]. It can take on the integer decimal values in the range 0 - 5.
Their hex equivalents, 0x0 - 0x5 shall also be accepted. These values
are mapped into QoS clases as follows:

          ----------------------------------------------------------
          |      VALUE          |           MEANING                |
          ----------------------------------------------------------
          |        0            |         Default QoS              |
          ----------------------------------------------------------
          |        1            |         Stringent                |
          ----------------------------------------------------------
          |        2            |         Tolerant                 |
          ----------------------------------------------------------
          |        3            |         Bi-level                 |
          ----------------------------------------------------------
          |        4            |         Unbounded                |
           ----------------------------------------------------------
           |        5            |      Stringent bi-level          |
           --------------------------------------------------------
Broadband Connection-Oriented Bearer Class (bcob): The bcob local
connection option indicates the Broadband Connection-Oriented Bearer


R.Kumar                      Informational                         16
                            ATM MGCP Package               October 2000

Class specified in ITU Q.2961.2 [5]. It is represented as a decimal
number in the range 0 - 31, or its hex equivalent (range 0x0 - 0x1F).
All values except those listed below are reserved.

          ----------------------------------------------------------
          |      VALUE          |         MEANING                  |
          ----------------------------------------------------------
          |        1            |         BCOB-A                   |
          ----------------------------------------------------------
          |        3            |         BCOB-C                   |
          ----------------------------------------------------------
          |        16           |         BCOB-X                   |
          ----------------------------------------------------------
          |        24           | BCOB-VP (transparent VP service) |
          ----------------------------------------------------------

Susceptibility to clipping (stc): The stc  local connection option
indicates susceptibility to clipping. It is represented as a decimal
number in the range 0 - 3, or its hex equivalent (range 0x0 - 0x3). All
values except those listed below are reserved.

          ----------------------------------------------------------
          |      VALUE          |           MEANING                |
          ----------------------------------------------------------
          |        0            |  Not susceptible to clipping     |
          ----------------------------------------------------------
          |        1            |  Susceptible to clipping         |
          ----------------------------------------------------------

User plane connection configuration (upcc): The upcc  local connection
option is represented as a decimal number in the range 0 - 3, or its
hex equivalent (range 0x0 - 0x3). All values except those listed below
are reserved.

          ----------------------------------------------------------
          |      VALUE          |           MEANING                |
          ----------------------------------------------------------
          |        0            |  Point to point                  |
          ----------------------------------------------------------
          |        1            |  Point to multipoint             |
          ----------------------------------------------------------

ATM QoS parameters, forward direction (aqf) and backward direction
(aqb): Here, forward is the direction away from the media gateway,
backward is the direction towards the gateway. If the directional
convention used by bearer signaling at the gateway is different, then
appropriate translations must be done by the media gateway. These
parameters have the following format:

             <cdvType><acdv><ccdv><actd><cctd><aclr>

The <cdvType> parameter can take on the string values of "PP" and "2P".
These refer to the peak-to-peak and two-point CDV as defined in UNI 4.0
[6] and ITU Q.2965.2 [7] respectively.


R.Kumar                      Informational                         17
                            ATM MGCP Package               October 2000


The CDV parameters, <acdv> and <ccdv>, refer to  the acceptable and
cumulative  CDVs respectively. These are expressed in units of
microseconds and represented as the decimal or hex equivalent of 24-bit
fields.  These use the cell loss ratio, <aclr>, as the "alpha"
quantiles defined in the ATMF TM 4.1 specification [8] and in ITU I.356
[9].

The CTD  parameters, <actd> and <cctd>,  refer to the acceptable and
cumulative  CTDs respectively in milliseconds. These are represented as
the decimal or hex  equivalent of  16-bit fields. These parameters are
equivalent to the maximum end-to-end transit delay defined in   ATMF TM
4.1 specification [8] and Q.2965.2 [7].

The <aclr> parameter refers to forward and backward acceptable cell
loss ratios. This is the ratio between the number of cells lost and the
number of cells transmitted. It is expressed as the decimal or hex
equivalent of an 8-bit field. This field  expresses an order of
magnitude n, where n is an integer in the range  1-15. The Cell Loss
Ratio takes on the value 10 raised to the power of minus n.

If any of these parameters is not specified, is inapplicable or is
implied, then it is set to   "-".

Examples of the use of the aqf and aqb local connection options are:

   L: aqf:PP 8125 3455 32000 -  11
   L: aqb:PP 4675 2155 18000 -  12

This implies a forward acceptable peak-to-peak CDV of 8.125 ms, a
backward acceptable peak-to-peak CDV of 4.675 ms, forward cumulative
peak-to-peak CDV of 3.455 ms, a backward cumulative peak-to-peak CDV of
2.155 ms, a forward acceptable maximum cell transfer delay of 32  ms, a
backward acceptable maximum cell transfer delay of 18 ms, an
unspecified forward cumulative cell transfer delay, an unspecified
backward cumulative cell transfer delay, a forward cell loss ratio of
10 raised to  minus 11 and a backward cell loss ratio of 10 to the
minus 12.

ATM traffic descriptors, forward direction CLP=0+1 (adf0+1), backward
direction CLP=0+1 (adb0+1), forward direction CLP=0 (adf0), backward
direction CLP=0 (adb0): Here, forward is the direction away from the
media gateway, backward is the direction towards the gateway. If the
directional convention used by bearer signaling at the gateway is
different, then appropriate translations must be done  by the media
gateway. The adf0+1, adb0+1, adf0 and adb0 parameters have the
following format:

             <pcr><scr><mbs><cdvt><mcr><mfs><fd><te>

These parameters are defined in the ATMF TM 4.1 specification [8].
These definitions are reiterated briefly in the table below.




R.Kumar                      Informational                         18
                            ATM MGCP Package               October 2000

Each of these parameters can be set to "-" if the intent is to not
specify it via MGCP. The meaning and units of these parameters are as
follows:

   PARAMETER        MEANING                            UNITS
     pcr            Peak Cell Rate                     Cells per second
     scr            Sustained Cell Rate                Cells per second
     mbs            Maximum Burst Size                 Cells
     cdvt           Cell Delay Variation Tolerance     Microseconds
     mcr            Minimum Cell Rate                  Cells per second
     mfs            Maximum Frame Size                 Cells
     fd             Frame Discard Allowed              on/off
     te             CLP tagging enabled                on/off

Examples of these local connection options are:

     L: adf0+1: 200   100  20   - - - on  -,
        adf0: 200   100  20   - - - on -,
        adb0+1: 200   100  20   - - - on -,
        adb0: 0   200   80   15   - - - -  off

This example applies to an  rt-VBR, single-CID AAL2 voice VC. It
implies a forward and backward PCR of 200 cells per second
all cells regardless of CLP,  forward and backward PCR of 200 cells
per second for cells with CLP=0, a forward and backward SCR of 100
cells per second for all cells regardless of CLP, a forward and
backward SCR of 80 cells per second for cells with CLP=0,
a forward and backward MBS of 20 cells  for all cells regardless
of CLP, a forward and backward MBS of 15 cells for cells with
CLP=0,  an unspecified CDVT which can be known by other means,
and an  MCR and MFS which are unspecified because they are
inapplicable. Frame discard is enabled in both the forward and
backward directions. Tagging is not enabled in either direction.

ABR parameters, forward direction  (abrf) and backward direction
(abrb). Here, forward is the direction away from the media gateway,
backward is the direction towards the gateway. If the convention used
by bearer signaling at the gateway is different, then appropriate
translations must be done  by the media gateway. The abrf and abrb
parameters have the following format:

        <nrm><trm><cdf><adtf>














R.Kumar                      Informational                         19
                            ATM MGCP Package               October 2000

These are defined in [6] and [8]. Their definition is summarized in the
table below. In MGCP, these are represented as the decimal equivalent
of the binary fields mentioned below.

+-----------+---------------------------------+-----------------------+
| PARAMETER |            MEANING              | FIELD SIZE            |
+-----------+---------------------------------+-----------------------+
|  NRM      | Maximum number of cells per     |    3 bits             |
|           | forward Resource Management cell|                       |
+-----------+---------------------------------+-----------------------+
|  TRM      | Maximum time between            |    3 bits             |
|           |forward Resource Management cells|                       |
+-----------+---------------------------------+-----------------------+
|  CDF      | Cutoff Decrease Factor          |    3 bits             |
+-----------+---------------------------------+-----------------------+
|  ADTF     | Allowed Cell Rate Decrease      |    10 bits            |
|           | Time Factor                     |                       |
+-----------+---------------------------------+-----------------------+

3.2. Signals and Events

  All the events in this package are connection events.  The suffix
  @<connection-id> can be omitted if there is only one connection to an
  endpoint. This suffix can also be wildcarded per MGCP rules.

  Package Name: ATM
   ---------------|-----------------------|-----|------|--------------
  |    SYMBOL     |  DEFINITION           | R   |   S  |   DURATION   |
  |---------------|-----------------------|-----|------|--------------|
  |      sc       |  Bearer path set-up   |  x  |      |              |
  |               |  complete             |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  |      sf       |  Bearer path set-up   |  x  |      |              |
  |               |  failed               |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  |      ec       |  Enable CAS via       |     |  oo  |              |
  |               |  type 3 packets       |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  |     etd       |  Enable DTMF tone     |     |  oo  |              |
  |               |  forwarding via       |     |      |              |
  |               |  packets              |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  |     etm       |  Enable MF tone       |     |  oo  |              |
  |               |  forwarding via       |     |      |              |
  |               |  packets              |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  |     etr1      |  Enable MF-R1 tone    |     |  oo  |              |
  |               |  forwarding via       |     |      |              |
  |               |  packets              |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  |     etr2      |  Enable MF-R2 tone    |     |  oo  |              |
  |               |  forwarding via       |     |      |              |
  |               |  packets              |     |      |              |
  |---------------|-----------------------|-----|------|--------------|


R.Kumar                      Informational                         20
                            ATM MGCP Package               October 2000

  |---------------|-----------------------|-----|------|--------------|
  | uc (string)   |  Used codec changed   |  x  |      |              |
  |               |  to codec named by    |     |      |              |
  |               |  the string           |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  | ptime (#)     |  Packetization period |  x  |      |              |
  |               |  changed to #         |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  | pftrans (#)   |  Profile element      |  x  |      |              |
  |               |  changed to  row #    |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  | cle  (#)      |  Cell Loss            |  x  |      |              |
  |               |  threshold (# )       |     |      |              |
  |               |  exceeded             |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  | pl   (#)      |  Packet Loss Threshold|  x  |      |              |
  |               |  exceeded (# )        |     |      |              |
  |---------------|-----------------------|-----|------|--------------|
  | of   (#)      |  Operation failure:   |  x  |      |              |
  |               |  Loss of connectivity |     |      |              |
  |               |  with reason code #   |     |      |              |
   -------------------------------------------------------------------

  Set-up complete ( "sc"):

     Within the RequestedEvents (R: ) structure,  "sc " is used to
     request notification of successful ATM OR AAL2 connection set-up.
     The ATM OR AAL2  bearer path is ready for subscriber payload
     carriage when this notification is sent.

     This could be the set-up of an SVC, the assignment of an AAL2 CID
     path and combinations thereof. Examples of such combinations are
     the set-up of an AAL2 SVC and the assignment of a CID within it or
     the set-up of a concatenation of an AAL2 single-CID SVC and a CID
     channel within a multiplexed AAL2 VC.

     An R: ATM/sc event notification request does not automatically
     cause the gateway to initiate the set-up of an ATM OR AAL2 path.
     The trigger for an ATM OR AAL2 connection set-up is an  "on" value
     of the L:se local connection option provided with a create or
     modify connection command.

  Set-up failed ("sf"):

     Within the RequestedEvents (R: ) structure, "sf " is used to
     request notification of a failed ATM OR AAL2 connection set-up.
     The   ATM OR AAL2 connection set-ups addressed by "sf" are the
     same as for the "sc" event.
     In some ATM OR AAL2 applications with SVC set-up or bearer-
     signalled AAL2 path assignment, the  "sf " event might not be
     used. In these cases, the following options are available:

      * the call agent receives a spontaneous delete from the media
        gateway with appropriate reason code (902).


R.Kumar                      Informational                         21
                            ATM MGCP Package               October 2000


      * the call agent  receives the  "of" event described below with
        optional reason code (902).

  Enable CAS via type 3 packets ( "ec"):

     This signal indicates that the media gateway is to forward CAS
     signaling via type 3 packets on an AAL2 connection. This does not
     preclude the call agent from requesting notification of CAS state
     changes. On receiving this signal request, the gateway sustains a
     bidirectional type 3 CAS protocol over the AAL2 path. This comes
     to an end when the request is cancelled through a subsequent
     NotificationRequest command or when the VoAAL2 connection is
     deleted.

  Enable DTMF tones via type 3 packets ( "etd"):

     A gateway will ignore this signal request if it normally forwards
     and receives DTMF tones via type 3 packets. This signal indicates
     that the media gateway is to forward  and receive DTMF tones via
     type 3 packets on an AAL2 connection. This does not preclude the
     call agent from requesting notification of DTMF tones.

  Enable MF tones via type 3 packets ( "etm"):

     A gateway will ignore this signal request if it normally forwards
     and receives MF tones via type 3 packets. This signal indicates
     that the media gateway is to forward  and receive MF tones via
     type 3 packets on an AAL2 connection. This does not preclude the
     call agent from requesting notification of MF tones. This signal
     request does not specify the MF tone type, which is known by other
     means.

  Enable R1 MF tones via type 3 packets ( "etr1"):

     A gateway will ignore this signal request if it normally forwards
     and receives R1 MF tones via type 3 packets. This signal indicates
     that the media gateway is to forward  and receive R1 MF tones via
     type 3 packets on an AAL2 connection. This does not preclude the
     call agent from requesting notification of R1 MF tones.

  Enable MF tones via type 3 packets ( "etr2"):

     A gateway will ignore this signal request if it normally forwards
     and receives R2 MF tones via type 3 packets. This signal indicates
     that the media gateway is to forward  and receive R2 MF tones via
     type 3 packets on an AAL2 connection. This does not preclude the
     call agent from requesting notification of R2 MF tones.

  Used codec changed ( "uc (string) "):

     If armed via an R:uc, a media gateway signals a codec change
     through an O:uc.  The alphanumeric string in parentheses is
     optional. It is the encoding name of the codec to which the switch


R.Kumar                      Informational                         22
                            ATM MGCP Package               October 2000

     is made.  Although this event can be used with all ATM adaptations
     (AAL1, AAL2 and AAL5):

     * The pftrans event is more suited to AAL2 applications.
     * Codec switches do not generally occur mid-call in AAL1
       applications.

  Packet time changed ( "ptime(#)"):

     If armed via an R:ptime, a media gateway signals a packetization
     period change through an O:ptime.  The decimal number in
     parentheses is optional. It is the new packetization period in
     milliseconds. In AAL2 applications, the pftrans event can be used
     to cover packetization period changes (and codec changes)

   Profile element changed ( "pftrans(#)"):

     If armed via an R: pftrans, a media gateway signals a mid-call
     profile element change through an O:ptime. This event is used with
     AAL2 adaptation only.  A profile element is a row in a profile
     table.  Profile elements indicating silence should not trigger
     this event. The decimal number in parentheses is optional. It is
     the row number to which the switch is made. Rows are counted
     downward, beginning from 1.

  Cell loss exceeded ( "cle(#) "):

     This event indicates that the cell loss rate exceeds the threshold
     #. If the threshold is omitted in the requested events and
     observed events parameters, it is known by other means. The
     optional decimal number is the number of dropped cells per 100,000
     cells.  For example, cle(10) indicates cells are being dropped at
     a rate of 1 in 10,000 cells.

  Packet loss exceeded ( "ple(#)"):

     This event indicates that the packet loss rate exceeds the
     threshold #. If the threshold is omitted in the requested events
     and observed events parameters, it is known by other means. The
     optional decimal number is the number of dropped packets per
     100,000 packets.  For example, ple(10) indicates packets are being
     dropped at a rate of 1 in 10,000 packets.

     When the bearer connection uses an AAL2 CID within a multiplexed
     VCC rather than an entire VCC, the 'ple' event is used instead of
     'cle'. The packets are AAL2 CPS  PDUs.

  Quality alert ( "qa"):

     This event indicates that the bearer path fails to  any
     predetermined combination of quality criteria such as loss, delay,
     jitter etc. This criterion is not defined and is left to the
     application. The gateway reports this quality violation to the
     call agent if armed to do so.


R.Kumar                      Informational                         23
                            ATM MGCP Package               October 2000


  Report failure ( "of (#)"):

     This indicates a  connection failure. It can also indicate failure
     to establish a connection, in lieu of "sf".

     The most common response to these events is for the media gateway
     to delete the connection. Some applications might choose to report
     an "of" with the appropriate reason code, a decimal number,
     optionally included in parentheses. Reason codes are the same as
     for spontaneous deletes by the gateway.

3.3. Statistics

  Connection statistics reported in the MGCP connection parameters
  structure as a result of a delete connection command are redefined
  for ATM. These parameters are:

  Number of packets sent: If a VCC is assigned to the connection, this
  is the total number of ATM cells transmitted for the duration of the
  connection. If a CID within an AAL2 VCC is assigned to the
  connection, it is the number of AAL2 common part sublayer (CPS)
  packets transmitted for the duration of the connection.

  Number of octets sent: If a VCC is assigned to the connection, this
  is the total number of ATM payload octets transmitted for the
  duration of the connection. If a CID within an AAL2 VCC is assigned
  to the connection, this is the total number of AAL2 CPS payload
  octets transmitted for the duration of the connection.

  Number of packets received: If a VCC is assigned to the connection,
  this is the total number of ATM cells received for the duration of
  the connection. If a CID within an AAL2 VCC is assigned to the
  connection, it is the number of AAL2 common part sublayer (CPS)
  packets received for the duration of the connection.

  Number of octets received: If a VCC is assigned to the connection,
  this is the total number of ATM payload octets received for the
  duration of the connection. If a CID within an AAL2 VCC is assigned
  to the connection, this is the total number of AAL2 CPS payload
  octets received for the duration of the connection.

  Number of packets lost: If a VCC is assigned to the connection, this
  is the total number of ATM cells lost, for the duration of the
  connection, in the direction towards the gateway. If a CID within an
  AAL2 VCC is assigned to the connection, it is the number of AAL2
  common part sublayer (CPS)  packets lost, for the duration of the
  connection, in the direction towards the gateway. If these losses
  cannot be assessed, then the gateway omits this parameter.

  Interarrival jitter: If a VCC is assigned to the connection, this is
  the interarrival jitter for ATM cells. If a CID within an AAL2 VCC is
  assigned to the connection, this is the interarrival jitter for AAL2



R.Kumar                      Informational                         24
                            ATM MGCP Package               October 2000

  common part sublayer (CPS)  packets. If this cannot be determined,
  then it is omitted.

  Average Transmission Delay: This should be understood to be the
  average cell transmission delay in both cases: VCC assignment and CID
  assignment to the connection. This requires the use of ATM
  performance monitoring techniques. If it is not possible to assess
  this delay, it is omitted.

  An example of connection parameter encoding for Voice-over-ATM is the
  following:

    P: PS=1245, OS=59760, PR=1244, OR=59712, PL=20, JI=0, LA=0

  Note that the PL value refers to the receive direction and is
  unrelated to PS.

  As in other applications, any of these parameters can be omitted if
  not relevant to an application. Also, the entire P: structure is
  optional.


  If a VCC is assigned to an MGCP-controlled connection, PS, PR and PL
  refer to cells sent, received and lost rather than to packets. OS and
  OR refer to sent and received ATM payload octets. Interarrival jitter
  (JI)  is understood to be for cells within the VCC. This VCC could be
  AAL1, AAL2 single-CID or AAL5.

  If a CID within an AAL2 VCC is assigned to an MGCP-controlled
  connection, PS, PR and PL refer to AAL2 common part sublayer (CPS)
  packets. OS and OR refer to sent and received AAL2 payload octets.
  Interarrival jitter (JI)  is understood to be for CPS packets. If
  this cannot be determined, the interarrival jitter for cells can be
  substituted.

  Estimation of average transmission delay (LA) is difficult in an ATM
  network and requires elaborate performance monitoring techniques.
  Methods for measuring latency at the CID level are not standardized.
  If the latency parameter or any other parameter cannot be determined,
  it is set to a null value.   Zero values shall be recognized as null
  values for all parameters in the Connection Parameters structure for
  ATM.

4.0. Negotiation of profiles and codecs in ATM applications

4.1. Consistency of parameters

In any ATM application, the following Local Connection Options should
not be used:
          Type of service, L:t
          Resource reservation, L:r

The following ATM  Local Connection Options provide equivalent
information:


R.Kumar                      Informational                         25
                            ATM MGCP Package               October 2000

          ATM traffic descriptors, L:adf0+1, adb0+1, adf0, adb0
          ATM transfer capability, L:atc
          QoS class, L:qos
         Broadband Connection-Oriented Bearer Class, L:bcob
          Susceptibility to clipping, L:stc
          ATM QoS parameters, L:aqf, aqb
          ABR parameters, L:abrf, abrb

The following Local Connection Option is not meaningful in the AAL1
case and should not be used:
          Packetization period, L:p

In AAL2 applications, the following Local Connection Options should not
be used :
          Encoding algorithm, L:a
          Packetization period, L:p

The following ATM  Local Connection Options provide equivalent
information in the AAL2 case:
          Profile list, L:pfl
          Priority list of  voice codec selections, L: vsel
          Priority list of voiceband data codec selections, L: dsel
          Priority list of fax codec selections, L: fsel

The use of a disallowed local connection option can either be flagged
as an error or ignored. If it is flagged as an error, a return code of
510 (protocol error) is used. If it is ignored, it is for the sake of
maintaining backward compatibility in some applications. A  return code
of 524 (inconsistent local connection options) should not be used.

4.2. Codec/Profile negotiation in ATM  networks

In AAL1 and AAL5 applications, codec negotiation is similar to the IP
case, although some of the local connection options and SDP connection
descriptor parameters are  different. See [18] for conventions for the
use of the Session Description Protocol [26] in the ATM context.

In AAL2 applications, the L:a and L:p parameters are disallowed.
Profile negotiation takes the place of codec negotiation. This
remainder of this  section addresses how this is done.

The specifics of the AAL2 bearer are not germane to profile
negotiation. The bearer could be PVC-based or SVC-based, based on
single-CID  or multi-CID VCs, subcell multiplexed or not.

The most general case involves different prioritized lists of profiles
at the originating gateway, the terminating gateway, the originating
call agent and the terminating gateway. Whether these lists are based
on network policies, end subscriber service level agreements or
equipment design is immaterial to the profile negotiation that is done
as part of the connection establishment process. It is also irrelevant
whether these lists are hardcoded defaults or provisionable. In the
connection establishment process, a series of ordered intersections is



R.Kumar                      Informational                         26
                            ATM MGCP Package               October 2000

performed. This leaves a single ordered list in the end. The highest
priority profile in this list is the selected profile.

The call agent conveys it priority list through the pfl local
connection option. The gateway conveys intersection results through the
media information line in SDP [18]. Whether these lists imply a real
priority or not, a profile is always chosen before the profiles that
follow it in a list.

Each media gateway has a policy for assigning priorities to different
lists (inter-list priority) which is different from the positional
ordering of profiles within a list (intra-list priority). This policy
might be a hardcoded default or provisioned. The inter-list priority
specifies an ordering of the following lists when the gateway
originates a call, and another ordering when the gateway terminates a
call:
    * 'C-list', which is the priority list from the call agent,
       received through L:pfl.
    * 'R-list', which is the priority list from the remote end,
       received through the SDP remote connection descriptor.
    * 'L-list', which is the local priority list, hardcoded or
       provisioned.

This policy will vary depending on the type, capabilities and
deployment of the media gateway. Network administrations or equipment
vendors will provision/default this policy for various reasons such as
resource usage optimization, quality of service, likelihood of finding
a common profile etc.

When doing an ordered intersection of lists, the intra-list priorities
of the highest priority list are used. Any profile that cannot be
supported due to resource (bandwidth, processing power etc.)
limitations is eliminated from the intersection.


In the absence of one or more of these lists, the remaining list(s) are
used in the profile selection process.  If the call agent does not
provide a list of profiles, the C-list is absent. In this case, the
intersection of the C-list, R-list and L-list simply becomes the
intersection of the R-list and the L-list. If the R-list is also
absent, no intersection is performed and the result is this null
operation is the L-list.














R.Kumar                      Informational                         27
                            ATM MGCP Package               October 2000

  The process of profile negotiation is as shown below:

         ORIGINATING                        TERMINATING
          GATEWAY                              GATEWAY

   (1) On receiving CRCX
       do a policy-based ordered
       intersection of the C-list,
       R-list and L-list.
                         ---------------------------------->
                         (2)Send resulting ordered list
                            to the terminating gateway
                            via SDP.

                                               (3) On receiving CRCX do
                                                   a policy-based
                                                   ordered
                                                   intersection of the
                                                   C-list, R-list and
                                                   L-list.
                                               (4) The highest priority
                                                   profile in the
                                                   resulting
                                                   list is the
                                                   selected
                                                    profile.
                         <-----------------------------------
                          (5) Send selected profile
                              to the originating gateway
                              via SDP.
                          (6) Optionally, send vsel, dsel,
                              and fsel via SDP to map
                              profile rows into service
                              types.

  When connection establishment is complete, there is only one profile
  associated with a connection. This implies that both endpoints are
  ready to receive, on the fly, packets that comply with any row in the
  profile. This can be restricted in some applications to map profile
  rows into voice service, voiceband data (modem) service and fax
  service. This binding can be by default, through provisioning or as
  part of profile negotiation during call establishment.

  One way of mapping profile rows to service types (voice, voiceband
  data and facsimile) on a call-by-call basis is to let the terminating
  gateway make this decision. In step 6 of the call flow above, it
  indicates it to the originating gateway via SDP vsel, dsel and fsel
  media attribute lines [18].

  Another way is to let the call agent(s) determine it and communicate
  it to the gateways as vsel, dsel and fsel LCOs.

  In addition, call agents and the originating gateway can indicate
  their preferred mapping of  profile rows to service types with


R.Kumar                      Informational                         28
                            ATM MGCP Package               October 2000

  respect to  the highest priority profile listed. This is done through
  the vsel, dsel and fsel LCOs and media attribute lines. When one
  profile is selected, the originating gateway is obliged to honor any
  mapping of profile rows to service types provided by the terminating
  gateway. Additionally, such a  mapping can be suggested by call
  agents and media gateways prior to this step (i.e. prior to  step 6
  in the call flow above), but the recipients are not obliged to honor
  these suggestions.

  Examples of profile negotiation:


  The L-list  at gateway #1, which is the originating gateway in this
  example,  is:
    custom 100, itu 7, itu 1, itu 2

  The L-list  at gateway #2, which is the terminating gateway in this
  example,  is:
     itu 2, itu 7, itu 1, itu 5

  The originating call agent sends the following profile list (C-list)
  to the originating gateway in the first create connection command:
      itu 8, itu 9, atmf 7, itu 7, itu 1, custom 100

  There is no remote connection descriptor, hence no R-list. The policy
  for originating calls at gateway #1 is:
      C-List > R-list > L-list

  where '>' means 'has higher priority than'. In accordance with this
  policy, the originating gateway performs an ordered intersection of
  the C-list and the L-list to produce:
       itu 7, itu 1, custom 100

  It sends this result via the SDP remote session descriptor. This
  becomes the R-list for gateway #2. The terminating call agent sends
  the following profile list (C-list) to the terminating  gateway in
  the first create connection command:
      itu 1, itu 4,   itu 7, custom 110, custom 100, itu 2

  The policy for gateway #2 is:
     R-list > L-list > C-list

  Using this policy, gateway #2 produces the following ordered
  intersection of R-list, L-list and C-list:
     itu 7, itu 1

  The first profile in this list, itu 7, is to be used for this
  connection. Gateway 2 indicates this to the call agent through the
  SDP local connection descriptor. Along with it,  is sends the
  following SDP media attribute lines to indicate the use of the
  different profile rows [18]:

     a=vsel:G729 10 10
     a=dsel:on PCMU 40 5


R.Kumar                      Informational                         29
                            ATM MGCP Package               October 2000


  These lines map voice (vsel) and voiceband data (dsel) to rows in the
  profile itu 7. The "on" in the dsel line indicates that voiceband
  data includes fax, otherwise a separate fsel line would be used.

  If the call agent(s) make(s) this decision, then the originating call
  agent can send the following LCOs in the modify connection command
  that has the selected profile in its remote connection descriptor:
          L: vsel:G729 10 10, dsel: G729 10 10, fsel:G729 10 10

  In this case, the terminating call agent can send the vsel, dsel and
  fsel options in another modify connection command to the terminating
  gateway.

5.0. References

[1]    ITU-T I.366.1, B-ISDN ATM Adaptation Layer Specification:
        Type 1 AAL.

[2]    ITU-T I.366.2, AAL Type 2 Reassembly Service Specific
        Convergence Sublayer  for Trunking, Feb. 99.

[3]   af-vtoa-0113.000, ATM trunking using AAL2 for narrowband
       services.

[4]    ITU Q. 2965.1, Digital subscriber signalling system no.2 (DSS
        2) - Support of Quality of Service classes.

[5]    ITU Q.2961, Digital subscriber signalling system no.2 (DSS 2)
        - additional traffic parameters. Also, Amendment 2 to Q.2961.

[6]    ATMF UNI 4.0 Signaling Specification, af-sig-0061.000.

[7]    ITU Q. 2965.2, Digital subscriber signalling system no.2 (DSS
        2) - Signalling of individual Quality of Service parameters.

[8]    ATMF Traffic Management Specification, Version 4.1, af-tm-
        0121.000.

[9]   I.356, BISDN ATM layer cell transfer performance.

[10]    ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type
        2 AAL, Sept. 1997.

[11]    ITU-T I.366.1, Segmentation and Reassembly Service Specific
        Convergence Sublayer  for AAL Type 2, June 1998.

[12]    H.323-2, Packet-based multimedia communications systems.

[13]    af-vtoa-0083.000, Voice and Telephony Over ATM to the Desktop.

[14]   Q.2110, B-ISDN ATM adaptation layer - service specific
       connection oriented protocol (SSCOP).



R.Kumar                      Informational                         30
                            ATM MGCP Package               October 2000

[15]   I.365.1,Frame relaying service specific convergence sublayer
       (FR-SSCS).

[16]   I.365.2, B-ISDN ATM adaptation layer sublayers: service
       specific coordination function to provide the connection
       oriented network service.

[17]  I.365.3, B-ISDN ATM adaptation layer sublayers: service
      specific coordination function to provide the
      connection-oriented transport service.

[18]    Conventions for the use of the Session Description Protocol
        (SDP) for ATM Bearer Connections, draft-ietf-mmusic-sdp-atm-
        02.txt.

[19]    ITU I.371, Traffic Control and Congestion Control in the BISDN.

[20]    ATMF Circuit Emulation Service (CES) Interoperability
        Specification, af-vtoa-0078.000.

[21]    af-vmoa-0145.000, Voice and Multimedia over ATM, Loop Emulation
        Service using AAL2.

[22]    ITU-T H.222.1, Multimedia multiplex and synchronization for
        audiovisual communication in ATM environments.

[23]   FRF.5, Frame Relay/ATM PVC Network Interworking Implementation
       Agreement.

[24]   FRF.8, Frame Relay/ATM PVC Service Interworking Implementation
       Agreement.

[25]   FRF.11, Voice over Frame Relay Implementation Agreement.

[26]   IETF RFC 2327, 'SDP: Session Description Protocol', April '98,
       Mark Handley and Van Jacobson.

6.0. Acknowledgements

  The author wishes to thank several colleagues at Cisco and the
  industry who have contributed towards the development of the MGCP ATM
  package, and who have implemented and tested these constructs.
  Special thanks are due to Bill Foster, Flemming Andreasen, Raghu
  Thirumalai Rajan, Joe Stone, Mohamed Mostafa, David Auerbach and
  Robert Biskner of Cisco systems for their contribution.











R.Kumar                      Informational                         31
                            ATM MGCP Package               October 2000

7.0. Author's Address

   Rajesh Kumar
   Cisco Systems, Inc.
   M/S SJC01/3
   170 West Tasman Drive
   San Jose, CA 95134-1706
   Phone: 1-800-250-4800
   Email: rkumar@cisco.com

Full Copyright Statement

   Copyright (C) The Internet Society (March 2, 2000). 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."


















R.Kumar                      Informational                         32


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/