[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-01.txt>
January 2001
Category: Informational


                            ATM MGCP Package

Status of this Document

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time. It is inappropriate to use Internet- Drafts
     as reference material or to cite them other than as work in
     progress.

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt.

      The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

1.0. Abstract.........................................................2
2.0. Conventions used in this document................................2
3.0. ATM Package......................................................2
 3.1. ATM Local Connection Options...................................2
     3.1.1 ATM bearer connection......................................2
     3.1.2 ATM adaptation layer (AAL).................................6
     3.1.3 Service layer.............................................12
     3.1.4  ATM bearer traffic management............................15
     3.1.5  AAL Dimensioning.........................................22
 3.2. Signals and Events............................................25
 3.3. Statistics....................................................29
4.0. Negotiation of profiles and codecs in ATM applications..........31
 4.1. Consistency of parameters.....................................31
 4.2. Codec/Profile negotiation in ATM  networks....................31
5.0. References......................................................35
6.0. Acknowledgements................................................37
7.0. Author's Address................................................37








R.Kumar                      Informational                          1
                            ATM MGCP Package               January 2001

1.0. Abstract

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

2.0. Conventions used in this document

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     RFC-2119.

3.0. ATM Package

     The ATM package in this document consists of Local Connection
     Options (Section 3.1), Events and Signals (Section 3.2) and ATM
     Statistics Parameters (Section 3.3). Also included in the document
     is a section on what Local Connection Options should not be
     included to insure consistency with the ATM parameters (Section
     4.1), and a section on the negotiation of codecs and profiles in
     ATM networks (Section 4.2).

     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  should always have an "atm" package prefix.

3.1. ATM 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, and in the capabilities
     structure in audit endpoint transactions.

     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.

3.1.1 ATM bearer connection

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


R.Kumar                      Informational                          2
                            ATM MGCP Package               January 2001


       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 "SVC" does not
     imply that the gateway will or should set up a bearer path (an SVC
     or Q.2630.1-assigned CID). Rather, an L: atm/se:on parameter
     (described below) is used to explicitly request an bearer path
     set-up.

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

     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:


R.Kumar                      Informational                          3
                            ATM MGCP Package               January 2001


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

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


R.Kumar                      Informational                          4
                            ATM MGCP Package               January 2001


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

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

     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
     AAL5contexts 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 octet of the NSAP address is the



R.Kumar                      Informational                          5
                            ATM MGCP Package               January 2001

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

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



R.Kumar                      Informational                          6
                            ATM MGCP Package               January 2001


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

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




R.Kumar                      Informational                          7
                            ATM MGCP Package               January 2001

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

     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.


R.Kumar                      Informational                          8
                            ATM MGCP Package               January 2001


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






























R.Kumar                      Informational                          9
                            ATM MGCP Package               January 2001

        TABLE 4: Local Connection Options for AAL Type 2
  +---------+---------------+---------------------------------------+
  |  LCO    |    Meaning    |           Values                      |
  +---------+---------------+---------------------------------------+
  |   pfl   | Profile List  |  See below                            |
  |         | Type          |                                       |
  +---------+---------------+---------------------------------------+
  | 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       |                                       |
  +---------+---------------+---------------------------------------+
  |  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.

     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



R.Kumar                      Informational                         10
                            ATM MGCP Package               January 2001

     <profileType> field.  The following rules apply to the contents of
     the <profileClass> field:

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


R.Kumar                      Informational                         11
                            ATM MGCP Package               January 2001


     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.

     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.

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


R.Kumar                      Informational                         12
                            ATM MGCP Package               January 2001

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




R.Kumar                      Informational                         13
                            ATM MGCP Package               January 2001

     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.

     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
        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 determine
     the use of some or all of the rows in a given profile table. If
     multiple 3-tuples are present, they can indicate a preferentially
     ordered assignment of some rows in that profile to voice,
     voiceband data or facsimile service e.g. row A preferred to row B
     etc. If multiple profiles are specified in the pfl parameter
     (described in section 3.1.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.


R.Kumar                      Informational                         14
                            ATM MGCP Package               January 2001


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

3.1.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,ABR              |
  |         | service       |                                       |
  |         | category      |                                       |
  +---------+---------------+---------------------------------------+
  | sbt     |atc subtype    | 1...5                                 |
  +---------+---------------+---------------------------------------+
  | qos     | QoS class     | 0...5                                 |
  +---------+---------------+---------------------------------------+
  | bcob    |Broadband      | 0...31                                |
  |         |Connection     |(Defined values listed below)          |
  |         |-Oriented      |                                       |
  |         |Bearer Class   |                                       |
  +---------+---------------+---------------------------------------+




R.Kumar                      Informational                         15
                            ATM MGCP Package               January 2001

  +---------+---------------+---------------------------------------+
  | eetim   |End-to-end     |on,off                                 |
  |         |timing required|                                       |
  +---------+---------------+---------------------------------------+
  | stc     |Susceptibility | 0...3                                 |
  |         |to clipping    |(Defined values listed below)          |
  +---------+---------------+---------------------------------------+
  | 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      |                                       |
  +---------+---------------+---------------------------------------+
  | abrb    |ABR parameters,| List, see below                       |
  |         |backward       |                                       |
  |         |direction      |                                       |
  +---------+---------------+---------------------------------------+



R.Kumar                      Informational                         16
                            ATM MGCP Package               January 2001

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

     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:









R.Kumar                      Informational                         17
                            ATM MGCP Package               January 2001

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

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




R.Kumar                      Informational                         18
                            ATM MGCP Package               January 2001

     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>

     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.

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







R.Kumar                      Informational                         19
                            ATM MGCP Package               January 2001

     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>

     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.








R.Kumar                      Informational                         20
                            ATM MGCP Package               January 2001

     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.

     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>

     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


R.Kumar                      Informational                         21
                            ATM MGCP Package               January 2001

     specification [6]). The abrSetup local connection option has the
     following format:

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

     These parameters are defined per [6]. Their definitions are listed
     briefly in Table 9 below. In these definitions, 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. 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               |
+-----------+----------------------------------+---------------------+

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




R.Kumar                      Informational                         22
                            ATM MGCP Package               January 2001

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







R.Kumar                      Informational                         23
                            ATM MGCP Package               January 2001


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

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




R.Kumar                      Informational                         24
                            ATM MGCP Package               January 2001

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

3.2. Signals and Events

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

     Set-up complete ( "sc"):

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

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

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








R.Kumar                      Informational                         25
                            ATM MGCP Package               January 2001

     TABLE 11: Signals and Events in the ATM package
|---------------|-----------------------|-----|------|--------------|
|    SYMBOL     |  DEFINITION           | R   |   S  |   DURATION   |
|---------------|-----------------------|-----|------|--------------|
|      sc       |  Bearer path set-up   |  x  |      |              |
|               |  complete             |     |      |              |
|---------------|-----------------------|-----|------|--------------|
|      sf       |  Bearer path set-up   |  x  |      |              |
|               |  failed               |     |      |              |
|---------------|-----------------------|-----|------|--------------|
|      ec       |  Enable CAS via       |     |  oo  |              |
|               |  type 3 packets       |     |      |              |
|---------------|-----------------------|-----|------|--------------|
|     etd       |  Enable DTMF tone     |     |  oo  |              |
|               |  forwarding via       |     |      |              |
|               |  packets              |     |      |              |
|---------------|-----------------------|-----|------|--------------|
|     etm       |  Enable MF tone       |     |  oo  |              |
|               |  forwarding via       |     |      |              |
|               |  packets              |     |      |              |
|---------------|-----------------------|-----|------|--------------|
|     etr1      |  Enable MF-R1 tone    |     |  oo  |              |
|               |  forwarding via       |     |      |              |
|               |  packets              |     |      |              |
|---------------|-----------------------|-----|------|--------------|
|     etr2      |  Enable MF-R2 tone    |     |  oo  |              |
|               |  forwarding via       |     |      |              |
|               |  packets              |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| uc (string)   |  Used codec changed   |  x  |      |              |
|               |  to codec named by    |     |      |              |
|               |  the string           |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| ptime (#)     |  Packetization period |  x  |      |              |
|               |  changed to #         |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| pftrans (#)   |  Profile element      |  x  |      |              |
|               |  changed to  row #    |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| cle  (#)      |  Cell Loss            |  x  |      |              |
|               |  threshold (# )       |     |      |              |
|               |  exceeded             |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| pl   (#)      |  Packet Loss Threshold|  x  |      |              |
|               |  exceeded (# )        |     |      |              |
|---------------|-----------------------|-----|------|--------------|
| of   (#)      |  Operation failure:   |  x  |      |              |
|               |  Loss of connectivity |     |      |              |
|               |  with reason code #   |     |      |              |
 -------------------------------------------------------------------






R.Kumar                      Informational                         26
                            ATM MGCP Package               January 2001

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




R.Kumar                      Informational                         27
                            ATM MGCP Package               January 2001

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


R.Kumar                      Informational                         28
                            ATM MGCP Package               January 2001

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

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

3.3. Statistics

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

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

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

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

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


R.Kumar                      Informational                         29
                            ATM MGCP Package               January 2001

     assigned to the connection, this is the total number of AAL2 CPS
     payload octets received for the duration of the connection.

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

     Interarrival jitter: If a VCC is assigned to the connection, this
     is the interarrival jitter for ATM cells. If a CID within an AAL2
     VCC is assigned to the connection, this is the interarrival jitter
     for AAL2 common part sublayer (CPS)  packets. If this cannot be
     determined, then it is omitted.

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

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

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

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

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

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

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

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



R.Kumar                      Informational                         30
                            ATM MGCP Package               January 2001

     shall be recognized as null values for all parameters in the
     Connection Parameters structure for ATM.

4.0. Negotiation of profiles and codecs in ATM applications

4.1. Consistency of parameters

     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

     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 can either be
     flagged as an error or ignored. If it is flagged as an error, a
     return code of 510 (protocol error) is used. If it is ignored, it
     is for the sake of maintaining backward compatibility in some
     applications. A  return code of 524 (inconsistent local connection
     options) should not be used.

4.2. Codec/Profile negotiation in ATM  networks

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




R.Kumar                      Informational                         31
                            ATM MGCP Package               January 2001

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

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

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

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

     Each media gateway has a policy for assigning priorities to
     different lists (inter-list priority) which is different from the
     positional ordering of profiles within a list (intra-list
     priority). This policy might be a hardcoded default or
     provisioned. The inter-list priority specifies an ordering of the
     following lists when the gateway originates a call, and another
     ordering when the gateway terminates a call:

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

     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


R.Kumar                      Informational                         32
                            ATM MGCP Package               January 2001

     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.

     The process of profile negotiation is as shown below:

            ORIGINATING                      TERMINATING
             GATEWAY                           GATEWAY

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

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

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

     One way of mapping profile rows to service types (voice, voiceband
     data and facsimile) on a call-by-call basis is to let the
     terminating gateway make this decision. In step 6 of the call flow
     above, it


R.Kumar                      Informational                         33
                            ATM MGCP Package               January 2001

     indicates it to the originating gateway via SDP vsel, dsel and
     fsel media attribute lines [18].

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

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

     Examples of profile negotiation:


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

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

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

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

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

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

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

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


R.Kumar                      Informational                         34
                            ATM MGCP Package               January 2001


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

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

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

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

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

5.0. References

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

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

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

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

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

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


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

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

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



R.Kumar                      Informational                         35
                            ATM MGCP Package               January 2001

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

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

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

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

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

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

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

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

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

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

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

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


R.Kumar                      Informational                         36
                            ATM MGCP Package               January 2001

        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.

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

6.0. Acknowledgements

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

7.0. Author's Address

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

Full Copyright Statement

   Copyright (C) The Internet Society (March 2, 2000). All Rights
   Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than


R.Kumar                      Informational                         37
                            ATM MGCP Package               January 2001

   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                         38


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/