<pre>Network Working Group                                           R. Kumar
Request for Comments: 3441                                 Cisco Systems
Category: Informational                                     January 2003


               <span class="h1">Asynchronous Transfer Mode (ATM) Package</span>
             <span class="h1">for the Media Gateway Control Protocol (MGCP)</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

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

Table of Contents

   <a href="#section-1.0">1.0</a>  Conventions Used in this Document..............................<a href="#page-2">2</a>
   <a href="#section-2.0">2.0</a>  Introduction...................................................<a href="#page-2">2</a>
   <a href="#section-3.0">3.0</a>  Local Connection Options.......................................<a href="#page-3">3</a>
     <a href="#section-3.1">3.1</a> ATM Bearer Connection.........................................<a href="#page-4">4</a>
     <a href="#section-3.2">3.2</a> ATM Adaptation Layer (AAL)....................................<a href="#page-8">8</a>
     <a href="#section-3.3">3.3</a> Service Layer................................................<a href="#page-15">15</a>
     <a href="#section-3.4">3.4</a> ATM Bearer Traffic Management................................<a href="#page-19">19</a>
     <a href="#section-3.5">3.5</a> AAL Dimensioning.............................................<a href="#page-27">27</a>
   <a href="#section-4.0">4.0</a> Signals and Events.............................................<a href="#page-30">30</a>
   <a href="#section-5.0">5.0</a> Connection Parameters..........................................<a href="#page-35">35</a>
   <a href="#section-6.0">6.0</a> Negotiation of Profiles and Codecs in ATM Applications.........<a href="#page-37">37</a>
     <a href="#section-6.1">6.1</a>  Consistency of Parameters...................................<a href="#page-37">37</a>
     <a href="#section-6.2">6.2</a>  Codec/Profile Negotiation in ATM Networks...................<a href="#page-38">38</a>
   <a href="#section-7.0">7.0</a>  Security Considerations.......................................<a href="#page-45">45</a>
   <a href="#section-8.0">8.0</a>  IANA Considerations...........................................<a href="#page-45">45</a>
   <a href="#section-9.0">9.0</a>  References....................................................<a href="#page-45">45</a>
   <a href="#section-10.0">10.0</a> Acronyms......................................................<a href="#page-48">48</a>



<span class="grey">Kumar                        Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   <a href="#section-11.0">11.0</a> Acknowledgements..............................................<a href="#page-49">49</a>
   <a href="#section-12.0">12.0</a> Author's Address..............................................<a href="#page-49">49</a>
   <a href="#section-13.0">13.0</a> Full Copyright Statement......................................<a href="#page-50">50</a>

<span class="h3"><a class="selflink" id="section-1.0" href="#section-1.0">1.0</a>  Conventions Used in this Document</span>

   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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>.

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

<span class="h3"><a class="selflink" id="section-2.0" href="#section-2.0">2.0</a>  Introduction</span>

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

   MGCP [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>] allows the auditing of endpoints for package versions
   supported.  The package version for the MGCP ATM package, as
   specified in this document, is 0.  Even if the ATM package is the
   default package for some endpoints, the package prefix "atm" shall
   not be omitted in local connection option names, event names, signal
   names etc.  If the ATM package is the default package for an
   endpoint, it will be listed as the first package in the audit
   response list.  It is not necessary for the MGCP ATM package to be
   the default package for ATM to be supported on an endpoint.

   The ATM package in this document consists of Local Connection Options
   (<a href="#section-3.0">Section 3.0</a>), Events and Signals (<a href="#section-4.0">Section 4.0</a>) and ATM Statistics
   Parameters (<a href="#section-5.0">Section 5.0</a>).  <a href="#section-6.1">Section 6.1</a> has guidelines for consistency
   in the use of Local Connection Options.  <a href="#section-6.2">Section 6.2</a> describes codec
   and profile negotiation.  <a href="#section-7.0">Section 7.0</a> addresses security
   considerations.






<span class="grey">Kumar                        Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   In the ATM networks addressed in this document, services are carried
   directly over ATM without an intervening IP layer.  The Local
   Connection Options, Events, Signals and Statistics Parameters
   described in this section are not needed for VoIP calls which can be
   carried, in whole or in part, over an ATM network.  In that case, the
   constructs defined elsewhere for IP are sufficient.

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

   MGCP grammar [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>] must be followed with regard to the use of white
   spaces.  The examples in this document attempt to follow MGCP grammar
   in this and all other respects.

<span class="h3"><a class="selflink" id="section-3.0" href="#section-3.0">3.0</a>  Local Connection Options</span>

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

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

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





















<span class="grey">Kumar                        Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> ATM Bearer Connection</span>

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

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

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

   Type of Bearer/VC (vc): This indicates whether a PVC, CID or an SVC
   is to be used for an ATM connection.  Possible values are: PVC, SVC
   or CID.  Omitting this parameter will result in the use of a default,
   which could be embedded or provisioned.  The value "PVC" covers both
   classical PVCs and SPVCs.  The value "CID"  covers subchannels within
   AAL1 [<a href="#ref-35" title="af-vtoa-0089.000">35</a>] and AAL2 [<a href="#ref-10" title="B-ISDN ATM Adaptation Layer Specification: Type 2 AAL">10</a>] virtual circuits.  A value of "SVC" for
   atm/vc does not necessarily imply that the addressed media gateway
   should initiate signaling for bearer set-up, since this might be done
   by another node such as the far-end media gateway.

   Enable path set-up (se): This local connection option is used to
   explicitly enable or disable the use of bearer signaling for path
   set-up.  Permitted values of this local connection option are  "on"
   and "off".  Examples of bearer signaling are SVC signaling, ITU
   Q.2630.1 signaling and combinations thereof.  Examples of such
   combinations are the set-up of an AAL2 SVC and the assignment of a
   CID within it or the set-up of a concatenation of an AAL2 single-CID
   SVC and a CID channel within a multiplexed AAL2 VC.  This parameter
   can be used with both the backward and forward bearer connection





<span class="grey">Kumar                        Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

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

   Connection Element Identifier (ci): This indicates the Virtual
   Circuit or CID to be used for the bearer connection.  It is used when
   the call agent manages VC and/or CID resources in the bearer network.

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

      * VCCI-&lt;vcci&gt;
      * VCCI-&lt;vcci&gt;/CID-&lt;cid&gt;
      * &lt;ATMaddressType&gt;-&lt;ATMaddress&gt;/VCCI-&lt;vcci&gt;
      * &lt;ATMaddress&gt;/VCCI-&lt;vcci&gt;
      * &lt;ATMaddressType&gt;-&lt;ATMaddress&gt;/VCCI-&lt;vcci&gt;/CID-&lt;cid&gt;
      * &lt;ATMaddress&gt;/VCCI-&lt;vcci&gt;/CID-&lt;cid&gt;
      * BCG-&lt;bcg&gt;/VCCI-&lt;vcci&gt;
      * BCG-&lt;bcg&gt;/VCCI-&lt;vcci&gt;/CID-&lt;cid&gt;
      * BCG-&lt;bcg&gt;/VPI-&lt;vpi&gt;/VCI-&lt;vci&gt;
      * BCG-&lt;bcg&gt;/VPI-&lt;vpi&gt;/VCI-&lt;vci&gt;/CID-&lt;cid&gt;
      * PORT-&lt;portId&gt;/VPI-&lt;vpi&gt;/VCI-&lt;vci&gt;
      * PORT-&lt;portId&gt;/VPI-&lt;vpi&gt;/VCI-&lt;vci&gt;/CID-&lt;cid&gt;
      * VPCI-&lt;vpci&gt;/VCI-&lt;vci&gt;
      * VPCI-&lt;vpci&gt;/VCI-&lt;vci&gt;/CID-&lt;cid&gt;
      * &lt;ATMaddressType&gt;-&lt;ATMaddress&gt;/VPCI-&lt;vpci&gt;/VCI-&lt;vci&gt;
      * &lt;ATMaddress&gt;/VPCI-&lt;vpci&gt;/VCI-&lt;vci&gt;
      * &lt;ATMaddressType&gt;-&lt;ATMaddress&gt;/VPCI-&lt;vpci&gt;/VCI-&lt;vci&gt;/CID-&lt;cid&gt;
      * &lt;ATMaddress&gt;/VPCI-&lt;vpci&gt;/VCI-&lt;vci&gt;/CID-&lt;cid&gt;








<span class="grey">Kumar                        Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   The subparameters of the ci parameter are defined as follows:

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

   The CID, or Channel ID, can refer to AAL1 as well as AAL2
   applications.  In AAL1 applications based on [<a href="#ref-35" title="af-vtoa-0089.000">35</a>], it refers to the
   octet position, starting from one, within an n x 64 SDT frame.

   The VPCI is a 16 bit field defined in <a href="#section-4.5.16">Section 4.5.16</a> 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
   [<a href="#ref-14">14</a>].  The VCCI is similar to the VCI, except for the fact that it
   retains its value across VC crossconnects.





<span class="grey">Kumar                        Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   In general, &lt;vpci&gt; and &lt;vcci&gt; 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 &lt;portId&gt; 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
   &lt;bcg&gt; 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 &lt;ATMaddressType&gt;-
   &lt;ATMaddress&gt; can be wildcarded in the following ways:

      *  The entire concatenation, &lt;ATMaddressType&gt;-&lt;ATMaddress&gt;, is
         replaced with a "$".
      *  &lt;ATMaddress&gt; is replaced with a "$", but &lt;ATMaddressType&gt; is
         not.

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

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

   If the addressType is NSAP, the address is expressed in the standard
   dotted hex form.  This is a string of 40 hex digits, with dots after
   the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th
   digits.  The "0x" prefix is not used, since this is always
   represented in hex.  The last octet of the NSAP address is the
   'selector' field that is available for non-standard use.  For
   example:

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





<span class="grey">Kumar                        Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

      L: atm/ci:E164-9738294382/VCCI-100

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

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

       L: atm/ci:GWID-officeABCmgx101vism12

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

       L: atm/ci:ALIAS-officeABCmgx101vism12

   An example of a GWID (ALIAS) is the CLLI code used for telecom
   equipment.  For all practical purposes, it should be adequate for the
   GWID (ALIAS) to be a variable length string with a maximum size of 32
   characters.

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

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

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> ATM Adaptation Layer (AAL)</span>

   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.








<span class="grey">Kumar                        Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

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

      "itu_h323c"             Annex C of H.323 which specifies direct
                              RTP on AAL5 [<a href="#ref-12">12</a>].

      "af83"                  af-vtoa-0083.001, which specifies
                              variable size AAL5 PDUs with PCM voice
                              and a null SSCS [<a href="#ref-13">13</a>].

      "AAL5_SSCOP"            SSCOP as defined in ITU Q.2110 [<a href="#ref-14">14</a>]
                              running over an AAL5 CPS [<a href="#ref-27" title="B-ISDN ATM Adaptation Layer Specification: Type 5 AAL">27</a>].
                              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 [<a href="#ref-11" title="Segmentation and Reassembly Service Specific Convergence Sublayer for AAL Type 2">11</a>].

      "itu_i3661_assured"     SSCS with assured transmission,
                              per ITU I.366.1 [<a href="#ref-11" title="Segmentation and Reassembly Service Specific Convergence Sublayer for AAL Type 2">11</a>].  This uses SSCOP
                              [<a href="#ref-14">14</a>].

      "itu_i3662"             SSCS per ITU I.366.2 [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>].

      "itu_i3651"             Frame relay SSCS per ITU I.365.1 [<a href="#ref-15">15</a>].

      "itu_i3652"             Service-specific coordination function,
                              as defined in ITU I.365.2, for Connection
                              Oriented Network Service (SSCF-CONS)
                              [<a href="#ref-16">16</a>].  This uses SSCOP [<a href="#ref-14">14</a>].



<span class="grey">Kumar                        Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


      "itu_i3653"             Service-specific coordination function,
                              as defined in ITU I.365.3, for Connection
                              Oriented Transport Service (SSCF-COTS)
                              [<a href="#ref-17">17</a>].  This uses SSCOP [<a href="#ref-14">14</a>].

      "itu_i3654"             Service-specific coordination function,
                              as defined in ITU I.365.4 [<a href="#ref-28">28</a>].

      "FRF5"                  Use of the FRF.5 frame relay standard
                              [<a href="#ref-23">23</a>], which references ITU I.365.1 [<a href="#ref-15">15</a>].

      "FRF8"                  Use of the FRF.8 frame relay standard
                              [<a href="#ref-24">24</a>].  This implies a null SSCS and the
                              mapping of the frame relay header
                              into the ATM header.

      "FRF11"                 Use of the FRF.11 frame relay standard
                              [<a href="#ref-25">25</a>].

      "itu_h2221"             Use of the ITU standard H.222.1 for
                              audiovisual communication over AAL5
                              [<a href="#ref-22">22</a>].

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








<span class="grey">Kumar                        Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   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 a specified partial fill (e.g. 47) is greater than or equal to the
   maximum fill (in this example, 46 for AAL1 P-cells), then complete
   fill (46 in this example) is used.  Using a 'partial' fill of 48
   effectively disables partial fill. Values below or above the
   permissible range of 1-48 MUST be rejected with an error code of 532
   {Unsupported value(s) in LocalConnectionOptions}.

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

   If partial fill is enabled (i.e., there is padding in at least some
   cells), then AAL1 structures must not be split across cell
   boundaries.  These shall fit in any cell.  Hence, their size shall be
   less than or equal to the partial fill size.  Further, the partial
   fill size is preferably an integer multiple of the structure size.
   If it is 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.





<span class="grey">Kumar                        Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

   TABLE 4: Local Connection Options for AAL Type 2
   +---------+---------------+---------------------------------------+
   |  LCO    |    Meaning    |           Values                      |
   +---------+---------------+---------------------------------------+
   |   pfl   | Profile List  |  See below                            |
   |         |               |                                       |
   +---------+---------------+---------------------------------------+
   | smplCPS | Simplified CPS|  on, off                              |
   |         | [<a href="#ref-21" title="Voice and Multimedia over ATM">21</a>]          |                                       |
   +---------+---------------+---------------------------------------+
   |   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.
   Spaces are used as delimiters within this list.  Therefore, to comply
   with MGCP syntax [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>], it is necessary to enclose this list in double
   quotes.





<span class="grey">Kumar                        Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   The format of the pfl parameter is as follows:

   "&lt;profileType#1&gt;&lt;format list#1&gt;&lt;profileType#2&gt;&lt;format list#2&gt; ...
   &lt;profileType #M&gt;&lt;format list#M&gt;"

   where &lt;format list#i&gt; has the form &lt;profile#i_1&gt;...&lt;profile#i_N&gt;

   The &lt;profileType&gt; parameter indicates the type of profile.  It is
   expressed in the format AAL2/&lt;profileClass&gt; where &lt;profileClass&gt;
   identifies the source of the definition of the profile.

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

      -  &lt;profileClass&gt; = "ITU" indicates profiles defined by ITU.
         Examples: profiles defined in the I.366.2 specification [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>].
      -  &lt;profileClass&gt; = "ATMF"  indicates profiles defined by ATM
         forum.  Examples: profiles defined in af-vtoa-0113 [<a href="#ref-3">3</a>] or af-
         vmoa-0145.000 [<a href="#ref-21" title="Voice and Multimedia over ATM">21</a>].
      -  &lt;profileClass&gt; = "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.
      - &lt;profileClass&gt; = &lt;corporateName&gt;
         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 &lt;profileClass&gt;.  It is suggested that
         organizations maintain consistent definitions of the advertised
         AAL2 profiles that bear their corporate name.
      -  The &lt;profileClass&gt; can be based on IEEE Standard 802-1990,
         <a href="#section-5.1">Section 5.1</a>, which defines the globally unique, IEEE-
         administered, three-octet OUIs used in MAC addresses and
         protocol identifiers.  In this case, the &lt;profileClass&gt; field
         shall be assigned a string value of "IEEE:" concatenated with
         &lt;oui&gt; where &lt;oui&gt; 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 &lt;profile#&gt; parameter is expressed as a decimal number in the
   range 1-255.






<span class="grey">Kumar                        Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   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
   (<a href="./rfc2234">RFC2234</a>) form:

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

   Simplified CPS (smplCPS): This enables the AAL2 CPS simplification
   described in [<a href="#ref-21" title="Voice and Multimedia over ATM">21</a>].  It can be assigned the following values: on, off.
   Under this simplification, each ATM cell contains exactly one AAL2
   packet.  If necessary, octets at the end of the cell are padded with
   zeros.

   AAL2 combined use timer (tmcu): This is defined in ITU I.363.2 [<a href="#ref-10" title="B-ISDN ATM Adaptation Layer Specification: Type 2 AAL">10</a>].
   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 [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>].  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 [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>].
   It can be assigned a value of "on" or "off".

   Frame mode (frmd): This is used to enable frame mode data [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>].  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 [<a href="#ref-11" title="Segmentation and Reassembly Service Specific Convergence Sublayer for AAL Type 2">11</a>].  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".






<span class="grey">Kumar                        Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   SSSAR reassembly timer (rastimer): This is defined in ITU I.366.1
   [<a href="#ref-11" title="Segmentation and Reassembly Service Specific Convergence Sublayer for AAL Type 2">11</a>].  It is an integer number of microseconds, represented as the
   decimal equivalent of 32 bits.

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

   An example of returning, in audit response, the local connection
   options defined in <a href="#section-3.2">Section 3.2</a> is:

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

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Service Layer</span>

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







<span class="grey">Kumar                        Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

   The vsel local connection option is structured as follows:

      "&lt;encodingName #1&gt; &lt;packetLength #1&gt;&lt;packetTime #1&gt;
      &lt;encodingName #2&gt; &lt;packetLength #2&gt;&lt;packetTime #2&gt;
         ...
      &lt;encodingName #N&gt; &lt;packetLength #N&gt;&lt;packetTime #N&gt;"

   where the &lt;encodingName&gt; refers to a codec name such as PCMU, G726-
   32, G729 etc.  See [<a href="#ref-18" title="&quot;Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections&quot;">18</a>] and [<a href="#ref-34">34</a>] for a list of codecs with static
   payload types.  The &lt;packetLength&gt; is a decimal integer
   representation of the packet length in octets.  The &lt;packetTime&gt; 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 passthrough 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 &lt;fxIncl&gt; flag preceding the list of 3-
   tuples.  This flag indicates whether the dsel list explicitly
   addresses facsimile ("on" value) or not ("off" value).  This flag can
   also be set to "-", which is equivalent to setting it to "off".

   If &lt;fxIncl&gt; is "on", then it is rarely useful to also include an fsel
   option.  However, it is syntactically correct to do so as long as the
   dsel and fsel options include an identical set of 3-tuples, perhaps
   in a different order.

   If &lt;fxIncl&gt; is "off", then any fsel list may still be ignored if the
   media gateway does not provide separate treatment of voiceband data
   passthrough and fax.  Since, in this case, there is no distinct
   facsimile service from the media gateway's perspective, any fsel list
   does not apply.

   The dsel local connection option is structured as follows:

      "&lt;fxIncl&gt; &lt;encodingName #1&gt; &lt;packetLength #1&gt;&lt;packetTime #1&gt;
               &lt;encodingName #2&gt; &lt;packetLength #2&gt;&lt;packetTime #2&gt;
               ...
               &lt;encodingName #N&gt; &lt;packetLength #N&gt;&lt;packetTime #N&gt;"





<span class="grey">Kumar                        Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   where the &lt;encodingName&gt; refers to a codec name such as PCMU, G726-
   32, G729 etc.  The &lt;packetLength&gt; is a decimal integer representation
   of the packet length in octets.  The &lt;packetTime&gt; 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:

         "&lt;encodingName #1&gt; &lt;packetLength #1&gt;&lt;packetTime #1&gt;
         &lt;encodingName #2&gt; &lt;packetLength #2&gt;&lt;packetTime #2&gt;
         ...
         &lt;encodingName #N&gt; &lt;packetLength #N&gt;&lt;packetTime #N&gt;"

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

   Since spaces are used as delimiters within the vsel, dsel and fsel
   lists, it is necessary to enclose these lists in double quotes [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>].

   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 &lt;packetLength&gt;and &lt;packetTime&gt; can be set to "-" when not needed.
   A &lt;fxIncl&gt; 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:"G729-24 - -"







<span class="grey">Kumar                        Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   The vsel, dsel and fsel local connection options can be used in the
   AAL1, AAL2 and AAL5 contexts.  The &lt;packetLength&gt; and &lt;packetTime&gt;
   are not meaningful in the AAL1 case and should be set to "-".  In the
   AAL2 case, these local connection options indicate the preferred use
   of some or all of the rows in a given profile table.  If multiple 3-
   tuples are present, they can indicate a preferentially ordered
   assignment of some rows in that profile to voice, voiceband data
   passthrough or facsimile service (e.g., row A preferred to row B
   etc).  If multiple profiles are specified in the pfl parameter
   (described in <a href="#section-3.2">section 3.2</a>), 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 [<a href="#ref-30">30</a>].  The
   contents of this IE are: a single-octet Organizational Identifier
   (OID) field, followed by a single-octet Codec Type field, followed by
   zero or more octets of a codec configuration bit-map.  The semantics
   of the codec configuration bit-map are specific to the
   organization[30, 31].  Since this bit-map is always represented in
   hex format, the "0x" prefix is omitted.  Leading zeros are not
   omitted.  For example:

      L: atm/ccnf:01080C

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

   ISUP User Information (usi): This is used to convey the contents of
   the 'User Information Layer 1 protocol' field within the bearer
   capability information element defined in Section 4.5.5 of [<a href="#ref-32">32</a>], and
   reiterated as the user service information element (IE) in <a href="#section-3.57">Section</a>
   <a href="#section-3.57">3.57</a> of [<a href="#ref-33">33</a>].  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
   the 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:






<span class="grey">Kumar                        Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


      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

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a> ATM Bearer Traffic Management</span>

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

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






<span class="grey">Kumar                        Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   +---------+---------------+---------------------------------------+
   | 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      |                                       |
   +---------+---------------+---------------------------------------+
   |abrSetup |ABR connection | List, see below                       |
   |         |set-up         |                                       |
   |         |parameters     |                                       |
   +---------+---------------+---------------------------------------+




<span class="grey">Kumar                        Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   ATM transfer capability (atc): This parameter indicates the ATM
   Transfer Capability described in ITU I.371 [<a href="#ref-19">19</a>], equivalent to the
   ATM Service Category described in the UNI 4.1 Traffic Management
   specification [<a href="#ref-8" title="Version 4.1">8</a>].  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 [<a href="#ref-29">29</a>].  Subtypes for
   the remaining atc values are per [<a href="#ref-8" title="Version 4.1">8</a>] and [<a href="#ref-19">19</a>].
















<span class="grey">Kumar                        Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   QoS class (qos): This indicates the QoS class specified in ITU
   I.2965.1 [<a href="#ref-4">4</a>].  It can take on the integer decimal values in the range
   0 - 5.  These values are mapped into QoS classes as follows:

      ----------------------------------------------------------
      |      VALUE          |           MEANING                |
      ----------------------------------------------------------
      |        0            |         Default QoS              |
      ----------------------------------------------------------
      |        1            |         Stringent                |
      ----------------------------------------------------------
      |        2            |         Tolerant                 |
      ----------------------------------------------------------
      |        3            |         Bi-level                 |
      ----------------------------------------------------------
      |        4            |         Unbounded                |
      ----------------------------------------------------------
      |        5            |      Stringent bi-level          |
      ----------------------------------------------------------

   Broadband Connection-Oriented Bearer Class (bcob): The bcob local
   connection option indicates the Broadband Connection-Oriented Bearer
   Class specified in ITU Q.2961.2 [<a href="#ref-5" title="Digital subscriber signalling system no.2 (DSS 2) - additional traffic parameters. Also">5</a>].  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 [<a href="#ref-29">29</a>]).  It can be assigned a value of "on"
   or "off".








<span class="grey">Kumar                        Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

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

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

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

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

      "&lt;cdvType&gt;&lt;acdv&gt;&lt;ccdv&gt;&lt;eetd&gt;&lt;cmtd&gt;&lt;aclr&gt;"

   Since spaces are used in this list, it must be enclosed in double
   quotes for MGCP compliance [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>].

   The &lt;cdvType&gt; 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 [<a href="#ref-6">6</a>] and ITU Q.2965.2 [<a href="#ref-7">7</a>] respectively.

   The CDV parameters, &lt;acdv&gt; and &lt;ccdv&gt;, 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, &lt;aclr&gt;, as the "alpha"
   quantiles defined in the ATMF TM 4.1 specification [<a href="#ref-8" title="Version 4.1">8</a>] and in ITU
   I.356 [<a href="#ref-9">9</a>].



<span class="grey">Kumar                        Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   The transit delay parameters, &lt;eetd&gt; and &lt;cmtd&gt;, 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 [<a href="#ref-7">7</a>], UNI 4.0 [<a href="#ref-8" title="Version 4.1">8</a>] and Q.2931
   [<a href="#ref-29">29</a>].

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

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

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

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

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

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

      "&lt;pcr&gt;&lt;scr&gt;&lt;mbs&gt;&lt;cdvt&gt;&lt;mcr&gt;&lt;mfs&gt;&lt;fd&gt;&lt;te&gt;"

   Since spaces are used in these lists, they must be enclosed in double
   quotes for MGCP compliance [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>].

   These parameters are defined per the ATMF TM 4.1 specification [<a href="#ref-8" title="Version 4.1">8</a>].
   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.



<span class="grey">Kumar                        Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   TABLE 7: ATM Traffic Descriptor Parameters

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

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

   Examples of these local connection options are:

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

   This implies a forward and backward PCR of 200 cells per second for
   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:

      "&lt;nrm&gt;&lt;trm&gt;&lt;cdf&gt;&lt;adtf&gt;"

   Since spaces are used in these lists, they must be enclosed in double
   quotes for MGCP compliance [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>].





<span class="grey">Kumar                        Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   These ABR parameters are defined per [<a href="#ref-6">6</a>] and [<a href="#ref-8" title="Version 4.1">8</a>].  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 (<a href="#section-10.1.2.2">Section 10.1.2.2</a> of the UNI 4.0 signaling
   specification [<a href="#ref-6">6</a>]).  The abrSetup local connection option has the
   following format:

      "&lt;ficr&gt;&lt;bicr&gt;&lt;ftbe&gt;&lt;btbe&gt;&lt;crmrtt&gt;&lt;frif&gt;&lt;brif&gt;&lt;frdf&gt;&lt;brdf&gt;"

   Since spaces are used in this list, it must be enclosed in double
   quotes for MGCP compliance [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>].

   These parameters are defined per [<a href="#ref-6">6</a>].  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 "-".











<span class="grey">Kumar                        Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a> AAL Dimensioning</span>

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

   TABLE 10: Local Connection Options used to dimension the AAL
   +---------+---------------+---------------------------------------+
   |  LCO    |    Meaning    | Values (Decimal Integer)              |
   +---------+---------------+---------------------------------------+
   |   str   | Structure     |  1...65,535                           |
   |         | Size          |                                       |
   +---------+---------------+---------------------------------------+




<span class="grey">Kumar                        Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   +---------+---------------+---------------------------------------+
   | cbrRate | CBR rate      | Bit map per Table 4-6 of [<a href="#ref-29">29</a>]         |
   +---------+---------------+---------------------------------------+
   |  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       |                                       |
   +---------+---------------+---------------------------------------+
   |fsscopuu |Forward maximum| 1-65,524                              |
   |         |SSCOP-UU field |                                       |
   |         |size           |                                       |
   +---------+---------------+---------------------------------------+



<span class="grey">Kumar                        Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   +---------+---------------+---------------------------------------+
   |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 [<a href="#ref-20">20</a>] 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 [<a href="#ref-29">29</a>].  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 [<a href="#ref-29">29</a>].  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, especially when used in the SSSAR [<a href="#ref-1">1</a>] and frame
   mode [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>] 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) [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>].

   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) [<a href="#ref-2" title="AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking">2</a>].




<span class="grey">Kumar                        Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   Forward maximum SSSAR-SDU size (fsssar): This is the maximum size, in
   the forward direction, of the AAL2-based SSSAR-SDU (I.366.1) [<a href="#ref-1">1</a>].

   Backward maximum SSSAR-SDU size (bsssar): This is the maximum size,
   in the backward direction, of the AAL2-based SSSAR-SDU (I.366.1) [<a href="#ref-1">1</a>].

   Forward maximum SSCOP-SDU size (fsscopsdu): This is the maximum size,
   in the forward direction, of the AAL2-based SSCOP-SDU (I.366.1) [<a href="#ref-1">1</a>].

   Backward maximum SSCOP-SDU size (bsscopsdu): This is the maximum
   size, in the backward direction, of the AAL2-based SSCOP-SDU
   (I.366.1) [<a href="#ref-1">1</a>].

   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)
   [<a href="#ref-1">1</a>].

   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) [<a href="#ref-1">1</a>].

<span class="h3"><a class="selflink" id="section-4.0" href="#section-4.0">4.0</a> Signals and Events</span>

   Standard MGCP syntax and keywords [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>] are used in Table 11 to define
   the events in this package.  Since these are all connection events,
   they cannot be requested for endpoints.  For consistency with MGCP
   [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>], it is required that the suffix @&lt;connection-id&gt; NOT be omitted
   even if there is only one connection to an endpoint.  This suffix can
   also be wildcarded per MGCP rules.

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

   Set-up complete ("sc"):

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

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

   This event is included for backward compatibility.  It is preferred
   that the call agent and the media gateway rely on provisional
   acknowledgements in the case in which connection set-up has a long



<span class="grey">Kumar                        Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   latency.  However, if this event is requested, the media gateway must
   issue notification of connection set-up via this event.  In this
   case, a provisional acknowledgement is not very useful, and full
   acknowledgement of the create connection or modify connection need
   not be deferred until connection set up.

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

   TABLE 11: Signals and Events in the ATM package
   |---------------|-----------------------|-----|------|--------------|
   |    SYMBOL     |  DEFINITION           | R   |   S  |   DURATION   |
   |---------------|-----------------------|-----|------|--------------|
   |      sc       |  Bearer path set-up   |  C  |      |              |
   |               |  complete             |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   |      sf       |  Bearer path set-up   |  C  |      |              |
   |               |  failed               |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   |      ec       |  Enable CAS via       |     |  oo  |              |
   |               |  type 3 packets       |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   |     etd       |  Enable DTMF tone     |     |  oo  |              |
   |               |  forwarding via       |     |      |              |
   |               |  packets              |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   |     etm       |  Enable MF tone       |     |  oo  |              |
   |               |  forwarding via       |     |      |              |
   |               |  packets              |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   |     etr1      |  Enable MF-R1 tone    |     |  oo  |              |
   |               |  forwarding via       |     |      |              |
   |               |  packets              |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   |     etr2      |  Enable MF-R2 tone    |     |  oo  |              |
   |               |  forwarding via       |     |      |              |
   |               |  packets              |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   | uc (string)   |  Used codec changed   |  C  |      |              |
   |               |  to codec named by    |     |      |              |
   |               |  the string           |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   | ptime (#)     |  Packetization period |  C  |      |              |
   |               |  changed to #         |     |      |              |
   |---------------|-----------------------|-----|------|--------------|



<span class="grey">Kumar                        Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   |---------------|-----------------------|-----|------|--------------|
   | pftrans (#)   |  Profile element      |  C  |      |              |
   |               |  changed to  row #    |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   | cle  (#)      |  Cell Loss            |  C  |      |              |
   |               |  threshold (# )       |     |      |              |
   |               |  exceeded             |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   | pl   (#)      |  Packet Loss Threshold|  C  |      |              |
   |               |  exceeded (# )        |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   | qa            |  Quality Alert        |  C  |      |              |
   |               |                       |     |      |              |
   |---------------|-----------------------|-----|------|--------------|
   | of   (#)      |  Operation failure:   |  C  |      |              |
   |               |  Loss of connectivity |     |      |              |
   |               |  with reason code #   |     |      |              |
   -------------------------------------------------------------------

   Set-up failed ("sf"):

   Within the RequestedEvents (R:) structure, "sf" is used to request
   notification of a failed ATM OR AAL2 connection set-up.  The ATM OR
   AAL2 connection set-ups addressed by "sf" are the same as for the
   "sc" event.

   In some ATM OR AAL2 applications with SVC set-up or bearer-signalled
   AAL2 path assignment, the "sf" event might not be used.  In these
   cases, the following options are available:

      *  the call agent receives a spontaneous delete from the media
         gateway with an appropriate reason code (902).
      *  the call agent receives the "of" event described below with the
         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.







<span class="grey">Kumar                        Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

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

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

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

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

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

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







<span class="grey">Kumar                        Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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




<span class="grey">Kumar                        Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   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.

<span class="h3"><a class="selflink" id="section-5.0" href="#section-5.0">5.0</a> Connection Parameters</span>

   The MGCP connection parameters structure is returned in an autonomous
   delete connection message, and in a response to a delete or audit
   connection command.  The standard connections parameters [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>] it
   contains are redefined below for ATM.  Also, a new extension
   parameter specific to the ATM package is defined.

   The standard connection parameters redefined for ATM are:

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

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

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

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

   Number of packets lost: If a VCC is assigned to the connection, this
   is the total number of ATM cells lost for the duration of the
   connection, in the direction towards the gateway.  If a CID within an



<span class="grey">Kumar                        Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

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

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

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

      1              ATM Virtual Circuit Connection (VCC)

      2              AAL2 Channel Identifier (CID)

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

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

      *  The default interpretations for MGCP in Ref. 36.
      *  The call agent's prior knowledge, if it governs the type of
         network and connection through the network type 'nt' LCO [Ref.
         36] and/or the connection type 'ct' LCO defined here.
      *  The call agent's snooping of the local connection descriptor
         provided by one or more media gateway.  This is used to
         determine the network and connection type.

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

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




<span class="grey">Kumar                        Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

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

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

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

<span class="h3"><a class="selflink" id="section-6.0" href="#section-6.0">6.0</a> Negotiation of Profiles and Codecs in ATM Applications</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>  Consistency of Parameters</span>

   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





<span class="grey">Kumar                        Informational                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   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 passthrough codec selections,
   L: atm/dsel
   Priority list of fax codec selections, L: atm/fsel

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

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>  Codec/Profile Negotiation in ATM Networks</span>

   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 [<a href="#ref-18" title="&quot;Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections&quot;">18</a>] for
   conventions for the use of the Session Description Protocol [<a href="#ref-26" title="&quot;SDP: Session Description Protocol&quot;">26</a>] in
   the ATM context.

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

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

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







<span class="grey">Kumar                        Informational                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   The call agent conveys its priority list through the pfl local
   connection option.  The gateway conveys intersection results through
   the media information line in SDP [<a href="#ref-18" title="&quot;Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections&quot;">18</a>].  Whether these lists imply a
   real priority or not, a profile is, as a general rule, preferred to
   profiles that follow it in a list.

   Each media gateway has a policy for assigning priorities to different
   lists (inter-list priority) which is different from the positional
   ordering of profiles within a list (intra-list priority).  This
   policy might be a hardcoded default or provisioned.  The inter-list
   priority specifies an ordering of the following lists with respect to
   each other:

      *  'C-list', which is the priority list from the call agent,
         received through L: atm/pfl.
      *  'R-list', which is the priority list from the remote end,
         received through the SDP remote connection descriptor.
      *  'L-list', which is the local priority list, hardcoded or
         provisioned.

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

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

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

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









<span class="grey">Kumar                        Informational                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   The process of profile negotiation is as shown below:

          ORIGINATING                     TERMINATING
                GATEWAY                           GATEWAY

   (1) On receiving CRCX
       do a policy-based ordered
       intersection of the C-list,
       and L-list. No R-list present.
                         ----------------------------------&gt;
                         (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.
                              &lt;-----------------------------------
                               (5) Send selected profile
                                   to the originating gateway
                                   via SDP.

   Prior to receiving the final profile in step 5, if the originating
   gateway has indicated multiple profiles in step 2, the originating
   gateway does not always have a usable basis for decoding AAL2
   packets.  This is because a combination of packet length and UUI
   (user-to-user indication) codepoint range may indicate different
   codecs in different profiles.  The time lag between when the
   terminating gateways start sending AAL2 packets and when the
   originating gateway becomes aware of the selected AAL2 profile should
   be minimized so that any ensuing clipping of the front-end of the
   audio stream is tolerable for voice circuits.  It is unlikely that
   this will introduce errors in modem or fax circuits since these will
   not have entered their user data transfer phase at this time.

   When connection establishment is complete, there is only one profile
   associated with a connection.  This implies that both endpoints are
   ready to receive, on the fly, packets that comply with any row in the
   profile.  Some applications may elect to associate profile rows with



<span class="grey">Kumar                        Informational                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   one or more of the following service types: voice service, voiceband
   data (modem) passthrough service and fax service.  This binding can
   be by default, through provisioning or as part of profile negotiation
   during call establishment.  Such service type associations, when
   communicated to another entity, are advisory and do not limit the
   requirement for supporting, at any time, on-the-fly switches to any
   profile element.

   Media gateways can have internal default (or provisioned) bindings
   between service types and profile elements.  Note that not all of
   these bindings might be meaningful in an application context (e.g.,
   the fax service binding might be ignored and omitted).  As part of
   profile negotiation, applications might choose to coordinate those
   bindings that are meaningful.  When this is done, the vsel, dsel and
   fsel LCOs described in this document, and the vsel, dsel and fsel
   media attribute lines [<a href="#ref-18" title="&quot;Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections&quot;">18</a>] are used to effect this coordination.
   Using these constructs, entities such as call agents and media
   gateways can indicate preferred bindings for the first, most
   preferred profile in a profile list.

   When performing ordered intersections of the C-list, L-list and
   R-list in the call flow above, media gateways MUST use the inter-list
   priority to choose between a service to profile row binding suggested
   by the call agent, the remote gateway or it own internal (provisioned
   or default) binding.  Thus, a service type to profile row binding
   inherits its relative priority from the profile list generated by the
   same source.  If the C-list has the highest priority, and the first
   profile in the C-list is selected as the first profile of the
   intersected list, then any service type to profile row bindings
   provided by the call agent via the vsel, dsel and fsel LCOs are
   associated with the first profile.  If the R-list has the highest
   priority, and the first profile in the R-list is selected as the
   first profile of the intersected list, then any service type to
   profile row bindings provided by the remote gateway via the vsel,
   dsel and fsel SDP attributes [<a href="#ref-18" title="&quot;Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections&quot;">18</a>] are associated with the first
   profile.  If the L-list has the highest priority, then any internal
   (default or provisioned) service to profile row bindings are
   associated with the first profile.  At the end of profile negotiation
   (step 4 in the call flow above), there is one profile selected by the
   terminating media gateway.  It MAY convey any applicable service type
   to profile row bindings for this profile to the originating gateway
   via the vsel, dsel and fsel SDP attributes [<a href="#ref-18" title="&quot;Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections&quot;">18</a>].

   If the first profile in the intersected list is not the first profile
   in the highest priority profile list, then any service to profile row
   bindings associated with the highest priority profile list cannot be
   used with the first (or only profile) in the intersected list.  In
   this case, the originating or terminating media gateway MUST attempt



<span class="grey">Kumar                        Informational                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   to associate internal (default or provisioned) service to profile row
   bindings with the first (or only profile) in the intersected list.

   Since there is more than one service type, it is possible that the
   service type to profile row bindings for the first profile in the
   intersected list be derived from different sources (the call agent,
   the remote media gateway, internal defaults or provisioning).  For
   consistency, if the voiceband data (passthrough) service mappings
   include fax, then a different set of fax service mappings cannot
   apply to the profile under consideration.  If applied in this case,
   the set of fax service mappings must include the same codecs, packet
   lengths and packetization periods as the voiceband data service
   mappings.  However, they may be in a different order.

   If the media gateway lumps fax service with voiceband data (modem)
   passthrough service, then it can ignore any fax service to profile
   row bindings provided by another entity such as the call agent or the
   remote gateway.  From the media gateway's perspective, there is no
   distinct fax service in this case.  In this case, the media gateway
   will not indicate a separate preference for the use of certain
   profile rows in conjunction with fax service.

   It is possible that the procedure described in this section for
   associating service types with profile rows fail to yield mappings
   between a given service type and the row(s) of the first profile in
   the intersected list of profiles.  This is acceptable since these
   bindings are merely indications of the preferred codecs and
   packetizations in the context of a given service.  They do not
   obviate the AAL2 requirement that, given a profile that is bound to a
   connection, a transmitter may switch to any profile row on the fly.

   An example of profile negotiation:

   The L-list at gateway #1, which is the originating gateway in this
   example, is:

      custom 100, itu 3, itu 1, itu 8














<span class="grey">Kumar                        Informational                     [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

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

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

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

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

   In step 1 at the originating gateway, there is no remote connection
   descriptor, hence no R-list.  The policy for originating calls at
   gateway #1 is:

      C-List &gt; R-list &gt; L-list

   where '&gt;' means 'has higher priority than'.  The term 'R-list' can be
   omitted from this series of inequalities since, in case under study,
   profile negotiation does not include any further ordered
   intersections at the originating gateway.

   In accordance with this policy, the originating gateway performs an
   ordered intersection of the C-list and the L-list to produce:

      itu 8, itu 3, itu 1, custom 100

   Since the C-list has the highest priority and the first profile in
   the intersected profile list is also the first profile in the C-list,
   the service bindings provided by the originating call agent are
   associated with the first profile, itu 8.  The originating gateway
   sends this result(intersected profile list and service bindings for
   the first profile, itu 8) via the SDP remote session descriptor to
   the terminating gateway.  The service bindings are expressed as
   follows [<a href="#ref-18" title="&quot;Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections&quot;">18</a>]:

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






<span class="grey">Kumar                        Informational                     [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   The intersected profile list produced by gateway 1 becomes the R-list
   for gateway #2.  The terminating call agent sends the following
   profile list (C-list) to the terminating gateway in the first create
   connection command:

      itu 1, itu 4,   itu 3, custom 110, custom 100, itu 2

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

   The policy for terminating calls at gateway #2 is:

      R-list &gt; L-list &gt; C-list

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

      itu 3, itu 1

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

   Note that the service bindings provided by the originating gateway
   have not been specified with respect to itu 3.  Therefore, these
   cannot be used even though the R-list has the highest priority at the
   terminating gateway.  Any existing internal (default or provisioned)
   service bindings for AAL2 profile itu 3 must be associated by the
   terminating gateway with the selected profile, itu 3.  Those service
   bindings that are internally unavailable are left unspecified.

   Since the internal service type bindings do exist for the profile itu
   3 at the terminating gateway, they are selected and bound to the
   connection.  In these, fax service is lumped with voiceband data
   passthrough.  These bindings are indicated to the originating gateway
   via the following SDP media attribute lines:

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












<span class="grey">Kumar                        Informational                     [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


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

<span class="h3"><a class="selflink" id="section-7.0" href="#section-7.0">7.0</a>  Security Considerations</span>

   The ATM package extends the base Media Gateway Control Protocol
   (MGCP) [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>].  This package specifies no additional security
   requirements or recommendations over those of the base MGCP protocol.

<span class="h3"><a class="selflink" id="section-8.0" href="#section-8.0">8.0</a>  IANA Considerations</span>

   The ATM package described in this document has been registered as an
   MGCP package under the name "atm", without the quotes.  The current
   version of this package is 0 (default).  This registration has been
   completed per the IANA considerations in the MGCP specification [<a href="#ref-36" title="&quot;Media Gateway Control Protocol (MGCP) Version 1.0&quot;">36</a>].

   The contact for the MGCP ATM package is the author of this document
   (<a href="#section-12">Section 12</a>).

<span class="h3"><a class="selflink" id="section-9.0" href="#section-9.0">9.0</a>   References</span>

   [<a id="ref-1">1</a>]  ITU-T I.366.1, B-ISDN ATM Adaptation Layer Specification: Type 1
        AAL.

   [<a id="ref-2">2</a>]  ITU-T I.366.2, AAL Type 2 Reassembly Service Specific
        Convergence Sublayer for Trunking, Nov. 2000.

   [<a id="ref-3">3</a>]  af-vtoa-0113.000, ATM trunking using AAL2 for narrowband
        services.

   [<a id="ref-4">4</a>]  ITU Q. 2965.1, Digital subscriber signalling system no.2 (DSS 2)
        - Support of Quality of Service classes.

   [<a id="ref-5">5</a>]  ITU Q.2961, Digital subscriber signalling system no.2 (DSS 2) -
        additional traffic parameters.  Also, Amendment 2 to Q.2961.

   [<a id="ref-6">6</a>]  ATMF UNI 4.0 Signaling Specification, af-sig-0061.000.





<span class="grey">Kumar                        Informational                     [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   [<a id="ref-7">7</a>]  ITU Q. 2965.2, Digital subscriber signalling system no.2 (DSS 2)
        - Signalling of individual Quality of Service parameters.

   [<a id="ref-8">8</a>]  ATMF Traffic Management Specification, Version 4.1, af-tm-
        0121.000.

   [<a id="ref-9">9</a>]  I.356, BISDN ATM layer cell transfer performance.

   [<a id="ref-10">10</a>] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type 2
        AAL, Sept. 1997.

   [<a id="ref-11">11</a>] ITU-T I.366.1, Segmentation and Reassembly Service Specific
        Convergence Sublayer for AAL Type 2, June 1998.

   [<a id="ref-12">12</a>] H.323-2, Packet-based multimedia communications systems.

   [<a id="ref-13">13</a>] af-vtoa-0083.000, Voice and Telephony Over ATM to the Desktop.

   [<a id="ref-14">14</a>] Q.2110, B-ISDN ATM adaptation layer - service specific
        connection oriented protocol (SSCOP).

   [<a id="ref-15">15</a>] I.365.1,Frame relaying service specific convergence sublayer
        (FR-SSCS).

   [<a id="ref-16">16</a>] I.365.2, B-ISDN ATM adaptation layer sublayers: service specific
        coordination function to provide the connection oriented network
        service.

   [<a id="ref-17">17</a>] I.365.3, B-ISDN ATM adaptation layer sublayers: service specific
        coordination function to provide the connection-oriented
        transport service.

   [<a id="ref-18">18</a>] Kumar, R. and M. Mostafa, "Conventions for the use of the
        Session Description Protocol (SDP) for ATM Bearer Connections",
        <a href="./rfc3108">RFC 3108</a>, May 2001.

   [<a id="ref-19">19</a>] ITU I.371, Traffic Control and Congestion Control in the BISDN.

   [<a id="ref-20">20</a>] ATMF Circuit Emulation Service (CES) Interoperability
        Specification, af-vtoa-0078.000.

   [<a id="ref-21">21</a>] af-vmoa-0145.000, Voice and Multimedia over ATM, Loop Emulation
        Service using AAL2.

   [<a id="ref-22">22</a>] ITU-T H.222.1, Multimedia multiplex and synchronization for
        audiovisual communication in ATM environments.





<span class="grey">Kumar                        Informational                     [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   [<a id="ref-23">23</a>] FRF.5, Frame Relay/ATM PVC Network Interworking Implementation
        Agreement.

   [<a id="ref-24">24</a>] FRF.8, Frame Relay/ATM PVC Service Interworking Implementation
        Agreement.

   [<a id="ref-25">25</a>] FRF.11, Voice over Frame Relay Implementation Agreement.

   [<a id="ref-26">26</a>] Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", <a href="./rfc2327">RFC 2327</a>, April 1998.

   [<a id="ref-27">27</a>] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type 5
        AAL, Aug. 1996.

   [<a id="ref-28">28</a>] I.365.4, B-ISDN ATM adaptation layer sublayers: Service specific
        convergence sublayer for HDLC applications.

   [<a id="ref-29">29</a>] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling.

   [<a id="ref-30">30</a>] ITU Q.765.5, Application Transport Mechanism - Bearer
        Independent Call Control.

   [<a id="ref-31">31</a>] <a href="http://www.3gpp.org/ftp/Specs">http://www.3gpp.org/ftp/Specs</a> for specifications related to
        3GPP, including AMR codecs.

   [<a id="ref-32">32</a>] ITU Q.931, Digital Subscriber Signaling System No. 1: Network
        Layer.

   [<a id="ref-33">33</a>] ITU Q.763, SS7 - ISUP formats and codes.

   [<a id="ref-34">34</a>] <a href="http://www.iana.org/assignments/rtp-parameters">http://www.iana.org/assignments/rtp-parameters</a>

   [<a id="ref-35">35</a>] ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for
        Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997.

   [<a id="ref-36">36</a>] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
        (MGCP) Version 1.0", <a href="./rfc3435">RFC 3435</a>, January 2003.

   [<a id="ref-37">37</a>] Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", <a href="./rfc2327">RFC 2327</a>, April 1998.

   [<a id="ref-38">38</a>] Foster, B., "MGCP CAS Packages", <a href="./rfc3064">RFC 3064</a>, February 2001.









<span class="grey">Kumar                        Informational                     [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


<span class="h3"><a class="selflink" id="section-10.0" href="#section-10.0">10.0</a>  Acronyms</span>

   AAL  ATM Adaptation Layer
   ABR  Available Bit Rate
   ABT/DT ATM Block Transfer/Delayed Transmission
   ABT/IT ATM Block Transfer/Immediate Transmission
   ATM  Asynchronous Transfer Mode
   ATMF ATM Forum
   BCG  Bearer Connection Group
   CAS  Channel Associated Signaling
   CBR  Constant Bit Rate
   CDV  Cell Delay Variation
   CDVT Cell Delay Variation Tolerance
   CID  Channel Identifier
   CLR  Cell Loss Ratio
   CPS  Common Part Sublayer
   DBR  Deterministic Bit Rate
   FEC  Forward Error Correction
   FRF  Frame Relay Format
   GFR  Guaranteed Frame Rate
   GWID Gateway Identifier
   IP   Internet Protocol
   ITU  International Telecommunications Union
   LCO  Local Connection Option
   MBS  Maximum Burst Size
   MCR  Minimum Cell Rate
   MFS  Maximum Frame Size
   MGCP Media Gateway Control Protocol
   nrt-VBR   Non-real-time Variable Bit Rate
   NSAP Network Service Access Point
   PCR  Peak Cell Rate
   PDU  Protocol Data Unit
   PVC  Permanent Virtual Circuit
   QoS  Quality of Service
   rt-VBR    Real-time Variable Bit Rate
   SAR  Segmentation and Re-assembly
   SCR  Sustained Cell Rate
   SDT  Structured Data Transfer
   SDU  Service Data Unit
   SPVC Switched Permanent Virtual Circuit
   SRTS Synchronous Residual Time-Stamp
   SSCOP Service-specific Connection Oriented Protocol
   SSSAR Service-specific Segmentation and Re-assembly
   SVC  Switched Virtual Circuit
   TDM  Time-Division Multiplexing
   UBR  Unspecified Bit Rate
   UDT  Unstructured Data Transfer
   VC   Virtual Circuit



<span class="grey">Kumar                        Informational                     [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


   VCCI Virtual Circuit Connection Identifier
   VCI  Virtual Circuit Identifier
   VP   Virtual Path
   VPCI Virtual Path Connection Identifier
   VPI  Virtual Path Identifier

<span class="h3"><a class="selflink" id="section-11.0" href="#section-11.0">11.0</a>  Acknowledgements</span>

   The author wishes to thank several colleagues at Cisco and the
   industry who have contributed towards the development of the MGCP ATM
   package, and who have implemented and tested these constructs.
   Special thanks are due to Bill Foster, Flemming Andreasen, Raghu
   Thirumalai Rajan, Joe Stone, Hisham Abdelhamid, Joseph Swaminathan,
   Sushma Srikanth, Amit Agrawal, Mohamed Mostafa, Latha Idury, David
   Auerbach and Robert Biskner of Cisco systems and to Mahamood Hussain
   of Hughes Software Systems for their contributions.  Finally, thanks
   are due to Scott Bradner for guiding the final phase of the
   publication of this document.

<span class="h3"><a class="selflink" id="section-12.0" href="#section-12.0">12.0</a> Author's Address</span>

   Rajesh Kumar
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706

   Phone: 1-408-527-0811
   EMail: rkumar@cisco.com























<span class="grey">Kumar                        Informational                     [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc3441">RFC 3441</a>                    ATM MGCP Package                January 2003</span>


<span class="h3"><a class="selflink" id="section-13.0" href="#section-13.0">13.0</a> Full Copyright Statement</span>

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kumar                        Informational                     [Page 50]
</pre>