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

Versions: 00 01 02 03 04 05 06 RFC 3441

Internet Engineering Task Force                               Rajesh Kumar
Internet Draft                                               Cisco Systems
Document: <draft-rajeshkumar-mgcp-atm-package-05.txt>             June 2002
Category: Informational

Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol
                                     (MGCP)

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................................................................2
2.0  Conventions used in this document.......................................2
3.0  Introduction............................................................2
4.0  Local Connection Options................................................3
  4.1 ATM bearer connection..................................................4
  4.2 ATM adaptation layer (AAL).............................................8
  4.3 Service layer.........................................................16
  4.4 ATM bearer traffic management.........................................19
  4.5 AAL Dimensioning......................................................28
5.0 Signals and Events......................................................30
6.0 Statistics..............................................................36
7.0 Negotiation of profiles and codecs in ATM applications..................38
  7.1  Consistency of parameters............................................38
  7.2  Codec/Profile negotiation in ATM  networks...........................39
8.0  Security Considerations................................................44
9.0   References............................................................44
10.0  Acronyms..............................................................47

R.Kumar                      Informational                          1 
                            ATM MGCP Package                  June 2002


11.0  Acknowledgements......................................................48
12.0 Author's Address.......................................................48

1.0  Abstract

     This document describes an ATM  package for the Media Gateway Control
     Protocol (MGCP). This package includes new Local Connection Options, ATM-
     specific events and signals, and ATM connection parameters. Also included
     is a description of codec and profile negotiation. As an informational
     Internet-Draft, this document provides information for the Internet
     community.  It does not specify an Internet standard of any kind.  It
     extends the Media Gateway Control Protocol (MGCP) that is currently being
     deployed in a number of products.  Implementers should be aware of
     developments in the IETF Megaco Working Group and ITU SG16, which are
     currently working on a potential successor to this protocol.

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.

     MGCP identifiers are case-insensitive. This includes package names, event
     names, local connection options and other elements of
     the MGCP header.

3.0  Introduction

     The Media Gateway Control Protocol or MGCP [36] is used to control voice
     media gateways from external call control elements. Even though the bearer
     network might be IP, ATM, TDM or a mix of these, MGCP is transported over
     IP. Packages such as the MGCP CAS packages [38] are modular sets of
     parameters such as connection options, signal, event and statistics
     definitions that can be used to extend it into specific contexts. A
     related,  IP-based mechanism for the description of ATM connections [18]
     has been generated by the IETF MMUSIC group. Due to the IP-centric nature
     of all aspects of the MGCP device control protocol, and for consistency
     with other MGCP package definitions, it is desirable to publish the MGCP
     ATM package in an IETF document.

     MGCP [36] allows the auditing of endpoints for package versions supported.
     The package version for the MGCP ATM package, as specified in the RFC that
     will ensue from this internet draft, is 0. Even if the ATM package is the
     default package for some endpoints, the package prefix "atm" shall not be
     omitted in local connection option names, event names, signal names etc.

R.Kumar                      Informational                          2 
                            ATM MGCP Package                  June 2002


     If the ATM package is the default package for an endpoint, it will be
     listed as the first package in the audit response list. It is not
     necessary for the MGCP ATM package to be the default package for ATM to be
     supported on an endpoint.

     The ATM package in this document consists of Local Connection Options
     (Section 4.0), Events and Signals (Section 5.0) and ATM Statistics
     Parameters (Section 6.0). Section 7.1 has guidelines for consistency in
     the use of Local Connection Options. Section 7.2 describes codec and
     profile negotiation. Section 8.0 addresses security considerations.

     In the  ATM networks addressed in this document,  services are carried
     directly over ATM without an intervening IP layer. The Local Connection
     Options, Events, Signals and Statistics 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 constructs  defined elsewhere
     for IP are sufficient.

     The ATM local connection option names, event names and signal names  MUST
     always have an "atm" package prefix. Backward compatibility with older
     implementations that use ôX-atmö as the package name is desirable.

     MGCP grammar [36] must be followed with regard to the use of white spaces.
     The examples in this document attempt to follow this grammar in this and
     all other respects.

4.0  Local Connection Options

     The Local Connection Options (LCOs) defined in this section are specific
     to ATM applications. Like other Local Connection Options (LCOs), these can
     be used in create connection, modify connection and audit connection
     transactions. However, unless noted otherwise below, they are not to be
     returned when an endpoint is audited for capabilities.

     ATM Local Connection Options are divided into the following categories:
     ATM bearer connection, ATM adaptation layer, service layer, ATM bearer
     traffic management and AAL dimensioning.

     When parameter values are represented in decimal format, leading zeros are
     omitted.


R.Kumar                      Informational                          3 
                            ATM MGCP Package                  June 2002


4.1 ATM bearer connection

     These local connection options are used to parameterize ATM bearer
     connections.

       TABLE 1: Local Connection Options for ATM Bearers
  +---------+---------------+---------------------------------------+
  |  LCO    |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   ct    | Connection    |AAL1, AAL1_SDT, AAL1_UDT, AAL2, AAL3/4,|
  |         | Type          |AAL5, USER_DEFINED_AAL                 |
  +---------+---------------+---------------------------------------+
  |   vc    |VC/Bearer type | PVC, SVC, CID                         |
  +---------+---------------+---------------------------------------+
  |   se    | Enable path   | on, off                               |
  |         | set-up        |                                       |
  +---------+---------------+---------------------------------------+
  |   ci    | Connection    | See below                             |
  |         | Element       |                                       |
  |         | Identifier    |                                       |
  +---------+---------------+---------------------------------------+

     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.

     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 ôCIDö covers subchannels within AAL1 [35] and AAL2 [10]
     virtual circuits. A value of ôSVCö for atm/vc does not necessarily imply
     that the addressed media gateway should initiate signaling for bearer set-
     up, since this might be done by another node such as the far-end media
     gateway.

     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".
     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 parameter can be used with both  the backward

R.Kumar                      Informational                          4 
                            ATM MGCP Package                  June 2002


     and forward bearer connection set-up methods. In the former case, the
     call-terminating gateway sets up the bearer connection. In the latter
     case, the call-originating gateway sets up the bearer connection.

     This option may or may not be used in conjunction with atm/sc event
     notification. When this option and the atm/sc event notification are
     omitted in all create connection and modify connection commands, the call
     agent is deferring any relevant decision to set up an ATM or AAL2
     connection to the media gateways. In the absence of this parameter a media
     gateway's autonomous decision to set up an ATM or AAL2 path via bearer
     signaling depends on default/provisioned behaviors such as the
     applicability and nature (backward/forward) of a bearer connection set-up
     model, the network type ('nt'), connection type ('atm/ct') and bearer
     type/VC ('atm/vc') local connection options, and the media gateway's
     awareness of whether it is the originating gateway or terminating gateway
     in a call. This awareness may be based on the presence or absence of an
     SDP remote connection descriptor in the initial create connection command.

     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.

     The ci parameter can be in one of the following formats:

     * VCCI-<vcci>
     * VCCI-<vcci>/CID-<cid>
     * <ATMaddressType>-<ATMaddress>/VCCI-<vcci>
     * <ATMaddress>/VCCI-<vcci>
     * <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>


R.Kumar                      Informational                          5 
                            ATM MGCP Package                  June 2002


     The subparameters of the ci parameter are defined as follows:

  |--------------|-----------------------|----------------------------|
  | Subparameter |    Meaning            |   Representation           |
  |--------------|-----------------------|----------------------------|
  |     vcci     | VC connection Id      | Decimal Integer            |
  |              |                       | (16-bit equivalent)        |
  |--------------|-----------------------|----------------------------|
  |     cid      | Channel Id            | Decimal Integer            |
  |              |                       | (8-bit equivalent)         |
  |--------------|-----------------------|----------------------------|
  |ATMaddressType| ATM address type      | "NSAP", "E164", "GWID",    |
  |              |                       | "ALIAS"                    |
  |--------------|-----------------------|----------------------------|
  | ATMaddress   | ATM address           | 40 hex digits   ("NSAP")   |
  |              |                       | upto 15 digits ("EI64")    |
  |              |                       | upto 32  chars ("GWID")    |
  |              |                       | upto 32  chars ("ALIAS")   |
  |--------------|-----------------------|----------------------------|
  |    bcg       |Bearer Connection Group| Decimal Integer            |
  |              |                       | (8-bit equivalent)         |
  |--------------|-----------------------|----------------------------|
  |    vpi       |    Virtual Path Id    | Decimal Integer            |
  |              |                       | (8 or 12-bit equivalent)   |
  |--------------|-----------------------|----------------------------|
  |    vci       |    Virtual Channel Id | Decimal Integer            |
  |              |                       | (16-bit equivalent)        |
  |--------------|-----------------------|----------------------------|
  |    portID    |    Port Id            | Decimal Integer            |
  |              |                       | (32-bit equivalent)        |
  |--------------|-----------------------|----------------------------|
  |    vpci      |    VP connection ID   | Decimal Integer            |
  |              |                       | (16-bit equivalent)        |
  |--------------|-----------------------|----------------------------|

     The CID, or Channel ID, can refer to AAL1 as well as AAL2
     applications. In AAL1 applications based on [35], it refers to
     the octet position, starting from one,  within an n x 64 SDT
     frame.

     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.


R.Kumar                      Informational                          6 
                            ATM MGCP Package                  June 2002


     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.

     In general, <vpci> and  <vcci> values are  unique between  a  pair of
     nodes. When they are unique between a pair of nodes but not unique within
     a network, 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. In this case, the ATM address of the far end is not needed to
     qualify these parameters.

     The <portId> parameter is used to identify the physical trunk port on an
     ATM module. It can be represented as a decimal or hex number of up to 32
     digits.

     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. While wildcarding, the constant
     strings that qualify the terms in the ci parameter are retained. The
     concatenation <ATMaddressType>-<ATMaddress> can be wildcarded in the
     following ways:

         * 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 AAL5 contexts
     are: VCCI-$, BCG-100/VPI-20/VCI-$.

     Examples of wildcarding the ci parameter in the AAL2 context are: VCCI-
     40/CID-$, BCG-100/VPI-20/VCI-120/CID-$.

     If the addressType is NSAP, the address is expressed in the standard
     dotted hex form. This is a string of 40 hex digits, with dots after the
     2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th digits. The
     "0x" prefix is not used, since this is always represented in hex. The last

R.Kumar                      Informational                          7 
                            ATM MGCP Package                  June 2002


     octet of the NSAP address is the 'selector' field that is available for
     non-standard use. For example:

       L: atm/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: atm/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, it means that the address is a
     Gateway Identifier or Node Alias. This may or may not be globally unique.
     In this format, the  ATMaddress is expressed as an alphanumeric string
     ("A"-"Z", "a"-"z", "0" - "9",".","-","_"). For example:

         L: atm/ci:GWID-officeABCmgx101vism12

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

         L: atm/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.

     When an endpoint supporting the ATM package is audited for capabilities,
     the following local connection options from Section 4.1 shall be returned:
     connection type (atm/ct) and VC/bearer type (atm/vc). If more than one
     value is supported, these shall be expressed as a list of semicolon-
     separated values. Although this is not very useful, it is permissible for
     these values to have overlapping semantics (e.g. AAL1 and AAL1_SDT).  An
     example of returning, in audit response, the local connection options
     defined in Section 4.1 is:

     A: atm/ct:AAL1_SDT;AAL2, atm/vc:PVC;CID

4.2 ATM adaptation layer (AAL)

     These local connection options are used to parameterize the ATM adaptation
     layer (AAL). These are further classified as: generic AAL connection

R.Kumar                      Informational                          8 
                            ATM MGCP Package                  June 2002


     options, AAL1-related connection options and AAL2-related connection
     options. Currently, there are no local connection options defined in this
     category that pertain to AAL5.

      TABLE 2: Generic Local Connection Options for the AAL
  +---------+---------------+---------------------------------------+
  |  LCO    |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  | aalApp  | Application   |itu_h323c,af83,AAL5_SSCOP,             |
  |         |               |itu_i3661_unassured, itu_i3661_assured |
  |         |               |itu_i3662, itu_i3651, itu_i3652,       |
  |         |               |itu_i3653, itu_i3654,                  |
  |         |               |FRF5, FRF8, FRF11,itu_h2221            |
  +---------+---------------+---------------------------------------+
  |   sbc   | Subchannel    | 1...24 for T1-based applications      |
  |         | Count         | 1...31 for E1-based applications      |
  +---------+---------------+---------------------------------------+

     AAL application (aalApp): This connection option specifies the controlling
     standard for an application layer above the ATM adaptation layer. Other
     strings can be defined. If used, these need to be prefixed with an "X-".

        "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].

        "AAL5_SSCOP"          SSCOP as defined in ITU Q.2110 [14]
                              running over an AAL5 CPS [27].
                              No information is provided regarding
                              any layers above SSCOP such as Service
                              Specific Coordination Function  (SSCF)
                              layers.

      "itu_i3661_unassured"   SSCS with unassured transmission,
                              per ITU I.366.1 [11].

      "itu_i3661_assured"     SSCS with assured transmission,
                              per ITU I.366.1 [11]. This uses SSCOP
                              [14].

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


R.Kumar                      Informational                          9 
                            ATM MGCP Package                  June 2002


         "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]. This uses SSCOP [14].

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

         "itu_i3654"          Service-specific coordination function,
                              as defined in ITU I.365.4 [28].


        "FRF5"                Use of the FRF.5 frame relay standard
                              [23], which references ITU I.365.1 [15].

        "FRF8"                Use of the FRF.8 frame relay standard
                              [24]. This implies a null SSCS and the
                              mapping of the frame relay header
                              into the ATM header.


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



R.Kumar                      Informational                         10 
                            ATM MGCP Package                  June 2002


TABLE 3: Local Connection Options for AAL Type 1
  +---------+---------------+---------------------------------------+
  |  LCO    |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   pf    | Partial fill  | 1...48                                |
  |         |               |                                       |
  +---------+---------------+---------------------------------------+
  |   crt   | Clock Recovery|  NULL, SRTS, ADAPTIVE                 |
  |         | Type          |                                       |
  +---------+---------------+---------------------------------------+
  |   fe    | FEC enable    | NULL, DELAY_SENSITIVE,LOSS_SENSITIVE  |
  +---------+---------------+---------------------------------------+

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

R.Kumar                      Informational                         11 
                            ATM MGCP Package                  June 2002


     multiple of the structure size (e.g. a partial fill size of 40 is
     truncated to 36 to support six 6 x 64 channels).

     Clock recovery type (crt): This is used in AAL1 UDT (unstructured data
     transfer) applications only. It can be assigned 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 used in the absence of
     this LCO can be hardcoded or provisioned.

     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 FEC for an AAL1 connection.


        TABLE 4: Local Connection Options for AAL Type 2
  +---------+---------------+---------------------------------------+
  |  LCO    |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   pfl   | Profile List  |  See below                            |
  |         |               |                                       |
  +---------+---------------+---------------------------------------+
  | smplCPS | Simplified CPS|  on, off                              |
  |         | [21]          |                                       |
  +---------+---------------+---------------------------------------+
  |   tmcu  | Combined use  | Integer microseconds                  |
  |         | timer         | (32-bit equivalent)                   |
  +---------+---------------+---------------------------------------+
  |  aalsap |Service access | AUDIO, MULTIRATE                      |
  |         |point          |                                       |
  +---------+---------------+---------------------------------------+
  |   cktmd | Circuit mode  | on, off                               |
  |         |               |                                       |
  +---------+---------------+---------------------------------------+
  |   frmd  | Frame mode    | on,off                                |
  |         | enable        |                                       |
  +---------+---------------+---------------------------------------+
  | genpcm  | Generic PCM   | PCMA, PCMU                            |
  |         | setting       |                                       |
  +---------+---------------+---------------------------------------+



R.Kumar                      Informational                         12 
                            ATM MGCP Package                  June 2002


  +---------+---------------+---------------------------------------+
  |  ted    | Transmission  | on,off                                |
  |         |error detection|                                       |
  +---------+---------------+---------------------------------------+
  |rastimer | SSSAR         |                                       |
  |         | reassembly    | Integer microseconds                  |
  |         | timer         | (32-bit equivalent)                   |
  +---------+---------------+---------------------------------------+

     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. Spaces are used as
     delimiters within this list. Therefore, to comply with MGCP syntax [36],
     it is necessary to enclose this list in double quotes.

     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.

     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

R.Kumar                      Informational                         13 
                            ATM MGCP Package                  June 2002


      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. Leading zeros may be omitted. For
      example, "IEEE:00000C" and "IEEE:C" both refer 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: atm/pfl:"AAL2/ITU 8  AAL2/ATMF 7 8 AAL2/custom 100  AAL2/cisco 200"

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

       pfl  = "%x22" 1*(profileType (1*profile#))"%x22"
       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  = 1*6 HEXDIG; 1-6 hex digits per IEEE Standard 802-1990
       space = %d32

     Simplified CPS (smplCPS): This enables the AAL2 CPS simplification
     described in [21]. It can be assigned the following values: on, off. Under
     this simplification, each ATM cell contains exactly on AAL2 packet. If
     necessary, octets at the end of the cell are padded with zeros.

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

     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.


R.Kumar                      Informational                         14 
                            ATM MGCP Package                  June 2002


     Circuit mode (cktmd): This is used to enable circuit mode data [2].  It
     can be assigned a value of "on" or "off".

     Frame mode (frmd): This is used to enable frame mode data [2].  It can be
     assigned a value of "on" or "off".

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

     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. This local connection option is useful in
     qualifying the aalApp local connection option, when the value of the
     latter is "itu_i3661_unassured".

     SSSAR reassembly timer (rastimer): This is defined in ITU I.366.1 [11]. It
     is an integer number of microseconds, represented as the decimal
     equivalent of 32 bits.

     When an endpoint supporting the ATM package is audited for capabilities,
     the following local connection options from Section 4.2  shall be
     returned: application (atm/aalApp). Further, if one of the values atm/ct
     is "AAL2", the following additional local connection options shall be
     returned: profile list (atm/pfl), simplified CPS (atm/smplCPS), service
     access point (atm/aalsap), circuit mode enable(atm/cktmd), frame mode
     enable (atm/frmd) and generic PCM setting (atm/genpcm). If more than one
     value is supported, these shall be expressed as a list of semicolon-
     separated values. For atm/smplCPS, atm/cktmd and atm/frmd, an audit  can
     return "on", "off" or "on;off" depending on whether the mode is mandatory,
     unsupported or optional for the endpoint.

     An example of returning, in audit response, the local connection options
     defined in Section 4.2  is:

     A: atm/aalApp:itu_i3662, atm/pfl:"AAL2/ATMF 7 8", smplCPS:on;off,
     aalsap:MULTIRATE, cktmd:off, frmd:off, genpcm:PCMU;PCMA


R.Kumar                      Informational                         15 
                            ATM MGCP Package                  June 2002


4.3 Service layer

          TABLE 5: Local Connection Options for the Service Layer
  +--------------+---------------+----------------------------------+
  |  LCO         |    Meaning    |           Values                 |
  +--------------+---------------+----------------------------------+
  |   vsel       | Voice codec   | See below                        |
  |              | Selection     |                                  |
  +--------------+---------------+----------------------------------+
  |   dsel       | Data codec    | See below                        |
  |              | Selection     |                                  |
  +--------------+---------------+----------------------------------+
  |   fsel       | Fax codec     | See below                        |
  |              | Selection     |                                  |
  +--------------+---------------+----------------------------------+
  | ccnf         | Codec         | Even number (4 - 32) hex digits  |
  |              | Configuration |                                  |
  +--------------+---------------+----------------------------------+
  | usi          | ISUP User     | Two hex digits                   |
  |              | Information   |                                  |
  +--------------+---------------+----------------------------------+

     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. See [18] and [34] for a list of codecs with static payload
     types. 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 microseconds.

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

R.Kumar                      Informational                         16 
                            ATM MGCP Package                  June 2002


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

     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:

                "<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 microseconds.

     Since spaces are used as delimiters within the vsel, dsel and fsel lists,
     it is necessary to enclose these lists in double quotes [36].

     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: atm/vsel:"G729 10 10000 G726-32 40 10000"
        L: atm/dsel:"off PCMA 10 10000 G726-32 40 10000"
        L: atm/fsel:"PCMU 40 5000 G726-32 20 5000"
        L: atm/vsel:"G729 10 10000 G726-32 40 10000"

R.Kumar                      Informational                         17 
                            ATM MGCP Package                  June 2002


        L: atm/dsel:"on  PCMA 10 10000 G726-32 40 10000"

     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: atm/vsel:"G729 - - G726-32 - -"
        L: atm/dsel:"- G729 - - G726-32 - -"
        L: atm/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 indicate the preferred 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 in section 4.2), the profile qualified by these local
     connection options is the first profile in the list.

     Codec configuration (ccnf): This is used to convey the contents of the
     single codec information element (IE) defined in [30]. The contents of
     this IE are: a single-octet Organizational Identifier (OID) field,
     followed by a single-octet Codec Type field, followed by zero or more
     octets of a codec configuration bit-map. The semantics of the codec
     configuration bit-map are specific to the organization[30, 31]. Since this
     bit-map is always represented in hex format, the "0x" prefix is omitted.
     Leading zeros are not omitted. For example:

        L: atm/ccnf:01080C

     indicates an Organizational Identifier of 0x01(the ITU-T). Using [57], the
     second octet (0x08) indicates a codec type of G.726 (ADPCM). The last
     octet, 0x0C indicates that 16 kbps and 24 kbps rates are NOT supported,
     while the 32 kbps and 40 kbps rates ARE supported.

     ISUP User Information (usi): This is used to convey the contents of the
     'User Information Layer 1 protocol' field within the bearer capability
     information element defined in Section 4.5.5 of [32], and   reiterated as
     the user service information element (IE) in Section 3.57    of [33]. The
     'User Information Layer 1 protocol' field consists of  the five least
     significant bits of Octet 5 of this information element.

     The usi LCO represented as a string of two hex digits. The "0x"prefix is
     omitted since this value is always hexadecimal. These hex digits are

R.Kumar                      Informational                         18 
                            ATM MGCP Package                  June 2002


     constructed from an octet with three leading '0' bits and last five bits
     equal to the 'User Information Layer 1 protocol' field described above.
     Digits to the left are more significant than  digits to the right. The
     resulting values of the usi local connection option are as follows:

      VALUE   MEANING
      0x01    CCITT standardized rate adaption V.110 and X.30
      0x02    Recommendation G.711 Mu-law
      0x03    Recommendation G.711 A-law
      0x04    Recommendation G.721 32 kbps ADPCM
              and Recommendation I.460
      0x05    Recommendations H.221 and H.242
      0x06    Recommendation  H.223 and H.245
      0x07    Non-ITU-T standardized rate adaption
      0x08    ITU-T standardized rate adaption V.120
      0x09    CCITT standardized rate adaption X.31 HDLC flag stuffing

4.4 ATM bearer traffic management

     These local connection options are used to convey ATM traffic parameters.

    TABLE 6: Local Connection Options for ATM bearer traffic management
  +---------+---------------+---------------------------------------+
  | ATM LCO |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  | atc     | ATM transfer  |CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR,   |
  |         | capability or |DBR,SBR,ABT/IT,ABT/DT                  |
  |         | service       |                                       |
  |         | category      |                                       |
  +---------+---------------+---------------------------------------+
  | sbt     |atc subtype    | 1...5                                 |
  +---------+---------------+---------------------------------------+
  | qos     | QoS class     | 0...5                                 |
  +---------+---------------+---------------------------------------+
  | bcob    |Broadband      | 0...31                                |
  |         |Connection     |(Defined values listed below)          |
  |         |-Oriented      |                                       |
  |         |Bearer Class   |                                       |
  +---------+---------------+---------------------------------------+
  | eetim   |End-to-end     |on,off                                 |
  |         |timing required|                                       |
  +---------+---------------+---------------------------------------+
  | stc     |Susceptibility | 0...3                                 |
  |         |to clipping    |(Defined values listed below)          |
  +---------+---------------+---------------------------------------+


R.Kumar                      Informational                         19 
                            ATM MGCP Package                  June 2002




  +---------+---------------+---------------------------------------+
  | upcc    |User plane     |0...3                                  |
  |         |connection     |(Defined values listed below)          |
  |         |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,    |                                       |
  |         |forward        |                                       |
  |         |direction,     |                                       |
  |         |CLP=0          |                                       |
  +---------+---------------+---------------------------------------+
  | adb0+1  |ATM traffic    | List, see below                       |
  |         |descriptor,    |                                       |
  |         |backward       |                                       |
  |         |direction,     |                                       |
  |         |CLP-independent|                                       |
  +---------+---------------+---------------------------------------+
  | adb     |ATM traffic    | List, see below                       |
  |         |descriptor,    |                                       |
  |         |backward       |                                       |
  |         |direction,     |                                       |
  |         |CLP=0          |                                       |
  +---------+---------------+---------------------------------------+
  | abrf    |ABR parameters,| List, see below                       |
  |         |forward        |                                       |
  |         |direction      |                                       |
  +---------+---------------+---------------------------------------+

R.Kumar                      Informational                         20 
                            ATM MGCP Package                  June 2002




  +---------+---------------+---------------------------------------+
  | abrb    |ABR parameters,| List, see below                       |
  |         |backward       |                                       |
  |         |direction      |                                       |
  +---------+---------------+---------------------------------------+
  |abrSetup |ABR connection | List, see below                       |
  |         |set-up         |                                       |
  |         |parameters     |                                       |
  +---------+---------------+---------------------------------------+

     ATM transfer capability (atc): This parameter indicates 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.

     Subtype (sbt): This qualifies the atc local connection option. It can be
     assigned integer values of 1...5.  The following combinations of the atc
     and sbt local connection options are meaningful:

     atc         sbt   Resulting transport

     CBR/DBR      1    Voiceband signal transport (ITU G.711, G.722, I.363)
     CBR/DBR      2    Circuit transport (ITU I.363)
     CBR/DBR      4    High-quality audio signal transport (ITU I.363)
     CBR/DBR      5    Video signal transport (ITU I.363)
     nrt-VBR      1    nrt-VBR.1
     nrt-VBR      2    nrt-VBR.2
     nrt-VBR      3    nrt-VBR.3
     rt-VBR       1    rt-VBR.1
     rt-VBR       2    rt-VBR.2
     rt-VBR       3    rt-VBR.3
     UBR          1    UBR.1
     UBR          2    UBR.2
     GFR          1    GFR.1
     GFR          2    GRR.2
     SBR          1    SBR1
     SBR          2    SBR2
     SBR          3    SBR3


R.Kumar                      Informational                         21 
                            ATM MGCP Package                  June 2002


     Subtypes for the atc values of CBR or DBR are per [29]. Subtypes for the
     remaining atc values are per [8] and [19].

     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. These
     values are mapped into QoS classes 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 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). The following
     values are currently defined:

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


R.Kumar                      Informational                         22 
                            ATM MGCP Package                  June 2002


     End-to-end timing (eetim): This indicates whether end-to-end timing is
     required (Table 4-8 of [29]).  It can be assigned a value of "on" or
     "off".

     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><eetd><cmtd><aclr>"

           Since spaces are used in this list, it must be enclosed in double quotes
     for MGCP compliance [36].

     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                         23 
                            ATM MGCP Package                  June 2002



     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 transit delay  parameters, <eetd> and <cmtd>,  refer to the    end-to-
     end and cumulative  transit delays respectively in    milliseconds. These
     are represented as the decimal equivalents    of  16-bit fields. These
     parameters are defined in Q.2965.2 [7], UNI 4.0 [8] and Q.2931 [29].

     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: atm/aqf:"PP 8125 3455 32000 - 11"
        L: atm/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 end-to-end    transit delay of 32  ms, a backward
     end-to-end transit delay of 18  ms, an unspecified forward cumulative
     transit delay, an unspecified backward cumulative transit 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 local connection options have the following format:

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

R.Kumar                      Informational                         24 
                            ATM MGCP Package                  June 2002



     Since spaces are used in these lists, they must be enclosed in double
     quotes for MGCP compliance [36].

     These parameters are defined per the ATMF TM 4.1 specification [8]. Each
     of these parameters can be set to "-" if the intent is to not specify it
     via MGCP. These definitions are listed briefly in Table 7 below.



     TABLE 7: ATM Traffic Descriptor Parameters

   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

     The pcr, scr, cdvt and mbs can be represented as the decimal equivalents
     of 24-bit fields. The mbs and mfs can be represented as the decimal
     equivalents of 16-bit fields.

      Examples of these local connection options are:

        L: atm/adf0+1:"200   100  20   - - - on  -",
           atm/adf0:"200   80   15   - - - -  off",
           atm/adb0+1:"200   100  20   - - - on -",
           atm/adb0:"200   80   15   - - - -  off"

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


R.Kumar                      Informational                         25 
                            ATM MGCP Package                  June 2002


     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 local connection options
     have the following format:

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

           Since spaces are used in these lists, they must be enclosed in double
     quotes for MGCP compliance [36].

     These are defined per [6] and [8]. Their definition is summarized in Table
     8 below. In MGCP, these are represented as the decimal equivalent of the
     binary fields mentioned below. If any of these parameters is meant to be
     left unspecified, it is set to "-".

                   TABLE 8: ABR Parameters
+-----------+---------------------------------+-----------------------+
| 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                     |                       |
+-----------+---------------------------------+-----------------------+

     ABR set-up parameters (abrSetup): This local connection option is used to
     indicate the ABR parameters needed during call/connection establishment
     (Section 10.1.2.2 of the UNI 4.0 signaling specification [6]). The
     abrSetup local connection option has the following format:

         "<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>"

           Since spaces are used in this list, it must be enclosed in double
     quotes for MGCP compliance [36].

     These parameters are defined per [6]. Their definitions are listed
     briefly in Table 9 below. In these definitions, forward is the direction

R.Kumar                      Informational                         26 
                            ATM MGCP Package                  June 2002


     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. If any of these parameters is meant to be left unspecified, it is
     set to "-".


                    TABLE 9: ABR Set-up Parameters
+-----------+----------------------------------+---------------------+
| PARAMETER |            MEANING               | REPRESENTATION      |
+-----------+----------------------------------+---------------------+
| <ficr>    | Forward Initial Cell Rate        | Decimal equivalent  |
|           |(Cells per second)                | of 24-bit field     |
+-----------+----------------------------------+---------------------+
| <bicr>    | Backward Initial Cell Rate       | Decimal equivalent  |
|           | (Cells per second)               | of 24-bit field     |
+-----------+----------------------------------+---------------------+
| <ftbe>    | Forward transient buffer         | Decimal equivalent  |
|           | exposure (Cells)                 | of 24-bit field     |
+-----------+----------------------------------+---------------------+
| <btbe>    | Backward transient buffer        | Decimal equivalent  |
|           | exposure (Cells)                 | of 24-bit field     |
+-----------+----------------------------------+---------------------+
| <crmrtt>  | Cumulative RM round-trip time    | Decimal equivalent  |
|           | (Microseconds)                   | of 24-bit field     |
+-----------+----------------------------------+---------------------+
| <frif>    | Forward rate increase factor     | Decimal integer     |
|           | (used to derive cell count)      | 0 -15               |
+-----------+----------------------------------+---------------------+
| <brif>    | Backward rate increase factor    | Decimal integer     |
|           | (used to derive cell count)      | 0 -15               |
+-----------+----------------------------------+---------------------+
| <frdf>    | Forward rate decrease factor     | Decimal integer     |
|           | (used to derive cell count)      | 0 -15               |
+-----------+----------------------------------+---------------------+
| <brdf>    | Backward rate decrease factor    | Decimal integer     |
|           | (used to derive cell count)      | 0 -15               |
+-----------+----------------------------------+---------------------+


R.Kumar                      Informational                         27 
                            ATM MGCP Package                  June 2002


4.5 AAL Dimensioning

     The Local Connection Options in Table 10 are used to dimension the
     operation of the AAL. In these parameters, forward is the direction away
     from the media gateway. Backward is the direction towards the media
     gateway. These parameters are represented as decimal integers in the
     ranges listed in Table 10.

  TABLE 10: Local Connection Options used to dimension the AAL
  +---------+---------------+---------------------------------------+
  |  LCO    |    Meaning    | Values (Decimal Integer)              |
  +---------+---------------+---------------------------------------+
  |   str   | Structure     |  1...65,535                           |
  |         | Size          |                                       |
  +---------+---------------+---------------------------------------+
  | cbrRate | CBR rate      | Bit map per Table 4-6 of [29]         |
  +---------+---------------+---------------------------------------+
  |  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      |                                       |
  +---------+---------------+---------------------------------------+
  |fSDUrate | Forward       | 24-bit equivalent                     |
  |         | maximum AAL2  |                                       |
  |         | CPS SDU rate  |                                       |
  +---------+---------------+---------------------------------------+
  |bSDUrate | Backward      | 24-bit equivalent                     |
  |         | maximum AAL2  |                                       |
  |         | CPS SDU rate  |                                       |
  +---------+---------------+---------------------------------------+
  | ffrm    |Forward maximum| 1-65,535                              |
  |         |frame block    |                                       |
  |         |size           |                                       |
  +---------+---------------+---------------------------------------+
  | bfrm    |Backward       | 1-65,535                              |
  |         |maximum frame  |                                       |
  |         |block size     |                                       |
  +---------+---------------+---------------------------------------+
  |fsssar   |Forward maximum| 1-65,568                              |
  |         |SSSAR-SDU      |                                       |
  |         |size           |                                       |
  +---------+---------------+---------------------------------------+

R.Kumar                      Informational                         28 
                            ATM MGCP Package                  June 2002


  +---------+---------------+---------------------------------------+
  |bsssar   |Backward       | 1-65,568                              |
  |         |maximum SSSAR  |                                       |
  |         |SDU size       |                                       |
  +---------+---------------+---------------------------------------+
  |fsscopsdu|Forward maximum| 1-65,528                              |
  |         |SSCOP-SDU      |                                       |
  |         |size           |                                       |
  +---------+---------------+---------------------------------------+
  |         |               |                                       |
  |bsscopsdu|Backward       | 1-65,528                              |
  |         |maximum SSCOP  |                                       |
  |         |SDU size       |                                       |
  +---------+---------------+---------------------------------------+
  |fsscopuu |Forward maximum| 1-65,524                              |
  |         |SSCOP-UU field |                                       |
  |         |size           |                                       |
  +---------+---------------+---------------------------------------+
  |bsscopuu |Backward       | 1-65,524                              |
  |         |maximum SSCOP  |                                       |
  |         |UU size        |                                       |
  +---------+---------------+---------------------------------------+

     Structured Data Transfer Block Size (str): This parameter is meaningful
     only when structured AAL1 is used. 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: atm/str  parameter is coded as the decimal
     equivalent of a 16-bit field [29]. The theoretical maximum value  of this
     parameter is 65,535, although most services use much less.

     CBR Rate (cbrRate): This is a hexadecimal representation of the bit map
     defined in Table 4-6 of ITU Q.2931 [29]. This is represented as exactly
     two hex digits. For example:

         L: atm/cbrRate:04

     implies a CBR rate of 1.544 Mbps.

     Forward maximum CPCS-SDU size (fcpcs): This is the maximum size of the
     AAL2 or AA5 CPCS SDU in the forward direction.

     Backward maximum CPCS-SDU size (bcpcs): This is the maximum size of the
     AAL2 or AA5 CPCS SDU in the backward direction.

R.Kumar                      Informational                         29 
                            ATM MGCP Package                  June 2002



     Forward maximum AAL2 CPCS-SDU rate (fSDUrate): This is the maximum rate of
     the AAL2 CPCS-SDUs in the forward direction.

     Backward maximum AAL2 CPCS-SDU rate (bSDUrate): This is the maximum rate
     of the AAL2 CPCS-SDUs in the backward direction.

     The fSDUrate and bSDUrate local connection options can be used to rate-
     limit AAL2 CIDs, specially when used in the SSSAR [1] and frame mode [2]
     contexts.

     Forward maximum frame mode block size (ffrm):  This is the maximum size,
     in the forward direction, of the AAL2 frame mode data unit (I.366.2) [2].

     Backward maximum frame mode block size (bfrm):  This is the maximum size,
     in the backward direction, of the AAL2 frame mode data unit (I.366.2) [2].

     Forward maximum SSSAR-SDU size (fsssar):  This is the maximum size, in the
     forward direction, of the AAL2-based SSSAR-SDU (I.366.1) [1].

     Backward maximum SSSAR-SDU size (bsssar):  This is the maximum size, in
     the backward direction, of the AAL2-based SSSAR-SDU (I.366.1) [1].

     Forward maximum SSCOP-SDU size (fsscopsdu):  This is the maximum size, in
     the forward direction, of the AAL2-based SSCOP-SDU (I.366.1) [1].

     Backward maximum SSCOP-SDU size (bsscopsdu):  This is the maximum size, in
     the backward direction, of the AAL2-based SSCOP-SDU (I.366.1) [1].

     Forward maximum SSCOP-UU size (fsscopuu):  This is the maximum size, in
     the forward direction, of the AAL2-based SSCOP-UU field(I.366.1) [1].

     Backward maximum SSCOP-UU size (bsscopuu):  This is the maximum size, in
     the backward direction, of the AAL2-based SSCOP- UU field (I.366.1) [1].

5.0 Signals and Events

     Standard MGCP syntax and keywords [36] are used in Table 11 to define the
     events in this package. Since these are all connection events, they cannot
     be requested for endpoints.  For consistency with MGCP [36], it is
     required that the suffix @<connection-id> NOT be omitted even if there is
     only one connection to an endpoint. This suffix can also be wildcarded per
     MGCP rules.

     There are no auditable event-states associated with the ATM package.

R.Kumar                      Informational                         30 
                            ATM MGCP Package                  June 2002



     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.

     This event is included for backward compatibility. It is preferred that
     the call agent and the media gateway rely on provisional acknowledgements
     in the case in which connection set-up has a long latency. However, if
     this event is requested, the media gateway must issue notification of
     connection set-up via this event. In this case, a provisional
     acknowledgement is not very useful, and full acknowledgement of the create
     connection or modify connection need not be deferred until connection set
     up.

     The designated trigger for an ATM OR AAL2 connection set-up is an  "on"
     value of the L: atm/se local connection option provided with a create or
     modify connection command. However, it is recognized that certain
     applications use the presence of an atm/sc event notification to initiate
     the set-up of an ATM or AAL2 connection.




R.Kumar                      Informational                         31 
                            ATM MGCP Package                  June 2002


TABLE 11: Signals and Events in the ATM package
|---------------|-----------------------|-----|------|--------------|
|    SYMBOL     |  DEFINITION           | R   |   S  |   DURATION   |
|---------------|-----------------------|-----|------|--------------|
|      sc       |  Bearer path set-up   |  C  |      |              |
|               |  complete             |     |      |              |
|---------------|-----------------------|-----|------|--------------|
|      sf       |  Bearer path set-up   |  C  |      |              |
|               |  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              |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| uc (string)   |  Used codec changed   |  C  |      |              |
|               |  to codec named by    |     |      |              |
|               |  the string           |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| ptime (#)     |  Packetization period |  C  |      |              |
|               |  changed to #         |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| pftrans (#)   |  Profile element      |  C  |      |              |
|               |  changed to  row #    |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| cle  (#)      |  Cell Loss            |  C  |      |              |
|               |  threshold (# )       |     |      |              |
|               |  exceeded             |     |      |              |
|---------------|-----------------------|-----|------|--------------|

R.Kumar                      Informational                         32 
                            ATM MGCP Package                  June 2002


|---------------|-----------------------|-----|------|--------------|
| pl   (#)      |  Packet Loss Threshold|  C  |      |              |
|               |  exceeded (# )        |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| qa            |  Quality Alert        |  C  |      |              |
|               |                       |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| of   (#)      |  Operation failure:   |  C  |      |              |
|               |  Loss of connectivity |     |      |              |
|               |  with reason code #   |     |      |              |
-------------------------------------------------------------------


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

      * 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

R.Kumar                      Informational                         33 
                            ATM MGCP Package                  June 2002


     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:atm/uc, a media gateway signals a codec change through
     an O:atm/uc.  The alphanumeric string in parentheses is optional. It is
     the encoding name of the codec to which the switch 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:atm/ptime, a media gateway signals a packetization
     period change through an O:atm/ptime.  The decimal number in parentheses
     is optional. It is the new packetization period in milliseconds. In AAL2

R.Kumar                      Informational                         34 
                            ATM MGCP Package                  June 2002


     applications, the pftrans event can be used to cover packetization period
     changes (and codec changes).

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

     If armed via an R:atm/pftrans, a media gateway signals a mid-call profile
     element change through an O:atm/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.

     Report failure ( "of (#)"):

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


R.Kumar                      Informational                         35 
                            ATM MGCP Package                  June 2002


     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.

6.0 Connection Parameters

     The MGCP connection parameters structure is returned in an autonomous
     delete connection message, and in a response to a delete or audit
     connection command. The standard connections parameters [36] it contains
     are redefined below for ATM. Also, a new extension parameter specific to
     the ATM package is  defined.

     The standard connection parameters redefined for ATM 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

R.Kumar                      Informational                         36 
                            ATM MGCP Package                  June 2002


     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 common part
     sublayer (CPS)  packets. If this cannot be determined, then it is omitted
     or set to 0.

     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 or
     set to 0.

     The following extension parameter is defined for the connection parameters
     structure:

     Connection qualification ("atm/CQ"): This qualifies the connection with
     enough granularity to be able to use the other connection parameters
     without a priori knowledge of network or connection type. Defined values
     are:
                     1              ATM Virtual Circuit Connection (VCC)

                     2              AAL2 Channel Identifier (CID)

                     3              Direct transfer i.e. without an ATM or other
                                    packet path

     When omitted, the connection parameters must be interpreted on one of the
     following bases:

     *   The default interpretations for MGCP in Ref. 36.

     *   The call agent's prior knowledge,  if it governs the type of network
          and connection through the network type 'nt' LCO [Ref. 36] and/or the
          connection type 'ct' LCO defined here.

     *   The call agent's  snooping  of the local connection descriptor
          provided by one or more media gateway. This is used to determine the
          network and connection type.

     An example of connection parameter encoding for an ATM VCC  is the
     following:


R.Kumar                      Informational                         37 
                            ATM MGCP Package                  June 2002


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

     Note that the PL value refers to the receive direction and is unrelated to
     PS. Also, since atm/CQ=1, these parameters refer to ATM cells rather than
     to AAL2 CPS packets.

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

     When connection parameters are audited, all parameters normally returned
     with a delete connection are returned. This includes the connection
     qualification parameter, atm/CQ.

     The measurement or estimation of some or all of these connection
     parameters might not be feasible or beneficial in some applications. In
     such cases, these may be individually omitted, or the entire connection
     parameters structure, which is optional in MGCP, might be omitted.
     Further, parameters which indicate impairments might be set to 0 to
     nullify their impact, if any.

7.0 Negotiation of profiles and codecs in ATM applications

7.1  Consistency of parameters

     For ATM networks, the "nt" local connection option in MGCP  must be set to
     "ATM".

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

     This is because the Local Connection Options listed in Table 6 provide
     information equivalent to the L: t and L: r local connection options.

     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

R.Kumar                      Informational                         38 
                            ATM MGCP Package                  June 2002



     The following ATM  Local Connection Options provide equivalent information
     in the AAL2 case:

           Profile list, L: atm/pfl
           Priority list of  voice codec selections, L: atm/vsel
           Priority list of voiceband data codec selections, L: atm/dsel
     Priority list of fax codec selections, L: atm/fsel

     The use of a disallowed local connection option should be flagged with a
     return code of 524 (inconsistent local connection options). Although it is
     not recommended that these be ignored, it is recognized some applications
     choose to do so for the sake of backward compatibility. Note that the
     inconsistency in this case is between the local connection option (e.g.
     L:a) and the application (e.g. AAL2)  which does not allow it.


7.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 call agent. 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 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 its priority list through the pfl local connection
     option. The gateway conveys intersection results through the media

R.Kumar                      Informational                         39 
                            ATM MGCP Package                  June 2002


     information line in SDP [18]. Whether these lists imply a real priority or
     not, a profile is, as a general rule, preferred to 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 with respect to each other:

       * 'C-list', which is the priority list from the call agent,
          received through L: atm/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.

     Depending on the application, different inter-list priorities may be used
     in the cases when the gateway originates and terminates a call.

     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. Previous
     values, if any, of the C-list and R-list are not used.


R.Kumar                      Informational                         40 
                            ATM MGCP Package                  June 2002


     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,
     and L-list. No R-list present.
                       ---------------------------------->
                       (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.


     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.
     Some applications may elect to associate profile rows with one or more of
     the following service types:  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.
     Such service type associations, when communicated to another entity, are
     advisory and do not limit the requirement for supporting, at any time,
     on-the-fly switches to any profile element.

     Media gateways can have internal default (or provisioned) bindings between
     service types and profile elements. Note that not all of these bindings

R.Kumar                      Informational                         41 
                            ATM MGCP Package                  June 2002


     might be meaningful an in application context e.g. the fax service binding
     might be omitted. As part of profile negotiation, applications might
     choose to coordinate those bindings that are meaningful. When this is
     done, the vsel, dsel and fsel LCOs described in this document, and the
     vsel, dsel and fsel media attribute lines [18] are used to effect this
     coordination. Using these constructs, entities such as call agents and
     media gateways can indicate preferred bindings for the first, most
     preferred profile in a profile list.

     When performing ordered intersections of the C-list, L-list and R-list in
     the call flow above, media gateways MUST use the inter-list priority to
     choose between service to profile row bindings suggested by the call
     agent, the remote gateway or its own internal bindings. If the C-list has
     the highest priority, and the first profile in the C-list is selected as
     the first profile of the intersected list, then any service type to
     profile row bindings provided by the call agent via the vsel, dsel and
     fsel LCOs are associated with the first profile. If the R-list has the
     highest priority, and the first profile in the R-list is selected as the
     first profile of the intersected list, then any service type to profile
     row bindings provided by the remote gateway via the vsel, dsel and fsel
     SDP attributes [18]  are associated with the first profile. If the L-list
     has the highest priority, then internal (default, provisioned) service to
     profile row bindings are associated with the first profile. Also, even if
     the C-list or the R-list have the highest inter-list priority, the first
     profile in the intersected list may not be the first profile in the
     highest priority list, since the latter may be eliminated by the
     intersection process. In this case, internal (default, provisioned)
     service to profile row bindings are associated with the first profile.

     In any of the cases above, the selected service to profile row bindings
     might address some or all of the following services: voice, voiceband
     data, and facsimile.  At the end of profile negotiation (step 4 in the
     call flow above), there is one selected profile. Any applicable service
     type to profile row bindings can are conveyed to the originating gateway
     as vsel, dsel and fsel SDP attributes [18].

     An example of profile negotiation:

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

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

R.Kumar                      Informational                         42 
                            ATM MGCP Package                  June 2002



     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 3, itu 1, custom 100

     Further, the originating call agent qualifies the first profile in its
     list with the following service type bindings:

     L: atm/vsel:"G729 10 10000", atm/dsel:"on PCMU 40 5000"

     There is no atm/fsel local connection option. Facsimile is included with
     voiceband data in the atm/dsel local connection option.

     In step 1 at the originating gateway, 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'. The term 'R-list' can be
     omitted from this series of inequalities since, in case under study,
     profile negotiation does not include any further ordered intersections at
     the originating gateway.

     In accordance with this policy, the originating gateway performs an
     ordered intersection of the C-list and the L-list to produce:
          itu 8, itu 3, itu 1, custom 100

     Since the C-list has the highest priority and the first profile in the
     intersected profile list is also the first profile in the C-list, the
     service bindings provided by the originating call agent are associated
     with the first profile, itu 8. The originating gateway sends this
     result(intersected profile list and service bindings for the first
     profile, itu 8)  via the SDP remote session descriptor to the terminating
     gateway. The service bindings are expressed as follows [18]:

          a=vsel:G729 10 10000
          a=dsel:on PCMU 40 5000

     The intersected profile list produced by gateway 1 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 3, custom 110, custom 100, itu 2

R.Kumar                      Informational                         43 
                            ATM MGCP Package                  June 2002



     Any service bindings (not shown) sent by the terminating call agent apply
     to the first profile in this list, itu 1.

     The policy for terminating calls at 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 3, itu 1

     The first profile in this list, itu 3, is to be used for this connection.
     Gateway 2 indicates this to the call agent through the SDP local
     connection descriptor.

     Note that the service bindings provided by the originating gateway have
     not been specified with respect to itu 3. Therefore, these cannot be used,
     even though, at the terminating gateway, the R-list has the highest
     priority. The service bindings for itu 3 are the internal (default or
     provisioned) service bindings at the terminating gateway. These are
     indicated to the originating gateway in via the following SDP media
     attribute lines:


           a=vsel:G726-32 20 5000 G726-24 15 5000
           a=dsel:on PCMU 40 5000 G726-40 25 5000

     These lines map voice (vsel) and voiceband data (dsel) to rows in the
     profile itu 3. The "on" in the dsel line indicates that voiceband data
     includes fax, otherwise a separate fsel line might have been used. Two
     codecs each are indicated for voice and for voiceband data, with the first
     codec being the preferred one. Although the originating gateway is not
     constrained by these advisory indications of profile element to service
     type mapping, applications may choose to limit on-the-fly switches based
     on the current service state (voice, voiceband data etc.). If done, this
     provides greater simplicity at the expense of flexibility.

8.0  Security Considerations

     The ATM package extends the base Media Gateway Control Protocol (MGCP)
     [36]. This package specifies no additional security requirements or
     recommendations over those of the base MGCP protocol.

9.0   References


R.Kumar                      Informational                         44 
                            ATM MGCP Package                  June 2002


[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).

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

R.Kumar                      Informational                         45 
                            ATM MGCP Package                  June 2002



[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, RFC 3108, May 2001.

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

[27]    ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type
        5 AAL, Aug. 1996.

[28]    I.365.4, B-ISDN ATM adaptation layer sublayers:
        Service specific convergence sublayer for HDLC applications.

[29]    ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling.

[30]   ITU Q.765.5, Application Transport Mechanism - Bearer
       Independent Call Control.

[31]   http://www.3gpp.org/ftp/Specs for specifications related to
       3GPP, including AMR codecs.

[32]   ITU Q.931, Digital Subscriber Signaling System No. 1: Network
       Layer.

[33]   ITU Q.763, SS7 - ISUP formats and codes.


R.Kumar                      Informational                         46 
                            ATM MGCP Package                  June 2002


[34]   http://www.isi.edu/in-notes/iana/assignments/rtp-parameters.

[35]   ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for
       Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997.

[36]   Andreasen, Flemming and Foster, Bill,
       "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705 bis.

[37]   Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, April 1998.

[38]   Foster, B., ôMGCP CAS Packagesö, RFC 3064, February 2001.

10.0  Acronyms

     AAL  ATM Adaptation Layer
     ABR  Available Bit Rate
     ABT/DT ATM Block Transfer/Delayed Transmission
     ABT/IT ATM Block Transfer/Immediate Transmission
     ATM  Asynchronous Transfer Mode
     ATMF ATM Forum
     BCG  Bearer Connection Group
     CAS  Channel Associated Signaling
     CBR  Constant Bit Rate
     CDV  Cell Delay Variation
     CDVT Cell Delay Variation Tolerance
     CID  Channel Identifier
     CLR  Cell Loss Ratio
     CPS  Common Part Sublayer
     DBR  Deterministic Bit Rate
     FEC  Forward Error Correction
     FRF  Frame Relay Format
     GFR  Guaranteed Frame Rate
     GWID Gateway Identifier
     IP   Internet Protocol
     ITU  International Telecommunications Union
     LCO  Local Connection Option
     MBS  Maximum Burst Size
     MCR  Minimum Cell Rate
     MFS  Maximum Frame Size
     MGCP Media Gateway Control Protocol
     nrt-VBR   Non-real-time Variable Bit Rate
     NSAP Network Service Access Point
     PCR  Peak Cell Rate
     PDU  Protocol Data Unit
     PVC  Permanent Virtual Circuit

R.Kumar                      Informational                         47 
                            ATM MGCP Package                  June 2002


     QoS  Quality of Service
     rt-VBR    Real-time Variable Bit Rate
     SAR  Segmentation and Re-assembly
     SCR  Sustained Cell Rate
     SDT  Structured Data Transfer
     SDU  Service Data Unit
     SPVC Switched Permanent Virtual Circuit
     SRTS Synchronous Residual Time-Stamp
     SSCOP Service-specific Connection Oriented Protocol
     SSSAR Service-specific Segmentation and Re-assembly
     SVC  Switched Virtual Circuit
     TDM  Time-Division Multiplexing
     UBR  Unspecified Bit Rate
     UDT  Unstructured Data Transfer
     VC   Virtual Circuit
     VCCI Virtual Circuit Connection Identifier
     VCI  Virtual Circuit Identifier
     VP   Virtual Path
     VPCI Virtual Path Connection Identifier
     VPI  Virtual Path Identifier

11.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,
     Hisham Abdelhamid, Joseph Swaminathan, David Auerbach and  Robert Biskner
     of Cisco systems and to Mahamood Hussain of Hughes Software Systems for
     their contributions.

12.0 Author's Address

   Rajesh Kumar
   Cisco Systems, Inc.
   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 (May 2, 2002). 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

R.Kumar                      Informational                         48 
                            ATM MGCP Package                  June 2002


   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                         49


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