Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3441

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

Pages: 50
Informational
Part 1 of 2 – Pages 1 to 19
None   None   Next

Top   ToC   RFC3441 - Page 1
Network Working Group                                           R. Kumar
Request for Comments: 3441                                 Cisco Systems
Category: Informational                                     January 2003


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

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

1.0 Conventions Used in this Document..............................2 2.0 Introduction...................................................2 3.0 Local Connection Options.......................................3 3.1 ATM Bearer Connection.........................................4 3.2 ATM Adaptation Layer (AAL)....................................8 3.3 Service Layer................................................15 3.4 ATM Bearer Traffic Management................................19 3.5 AAL Dimensioning.............................................27 4.0 Signals and Events.............................................30 5.0 Connection Parameters..........................................35 6.0 Negotiation of Profiles and Codecs in ATM Applications.........37 6.1 Consistency of Parameters...................................37 6.2 Codec/Profile Negotiation in ATM Networks...................38 7.0 Security Considerations.......................................45 8.0 IANA Considerations...........................................45 9.0 References....................................................45 10.0 Acronyms......................................................48
Top   ToC   RFC3441 - Page 2
   11.0 Acknowledgements..............................................49
   12.0 Author's Address..............................................49
   13.0 Full Copyright Statement......................................50

1.0 Conventions Used in this Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119. MGCP identifiers are case-insensitive. This includes package names, event names, local connection options and other elements of the MGCP header.

2.0 Introduction

The Media Gateway Control Protocol or MGCP [36] is used to control voice media gateways from external call control elements. Even though the bearer network might be IP, ATM, TDM or a mix of these, MGCP is transported over IP. Packages such as the MGCP CAS packages [38] are modular sets of parameters such as connection options, signal, event and statistics definitions that can be used to extend it into specific contexts. A related, IP-based mechanism for the description of ATM connections [18] has been generated by the IETF MMUSIC group. Due to the IP-centric nature of all aspects of the MGCP device control protocol, and for consistency with other MGCP package definitions, it is desirable to publish the MGCP ATM package in an IETF document. MGCP [36] allows the auditing of endpoints for package versions supported. The package version for the MGCP ATM package, as specified in 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 (Section 3.0), Events and Signals (Section 4.0) and ATM Statistics Parameters (Section 5.0). Section 6.1 has guidelines for consistency in the use of Local Connection Options. Section 6.2 describes codec and profile negotiation. Section 7.0 addresses security considerations.
Top   ToC   RFC3441 - Page 3
   In the ATM networks addressed in this document, services are carried
   directly over ATM without an intervening IP layer.  The Local
   Connection Options, Events, Signals and Statistics Parameters
   described in this section are not needed for VoIP calls which can be
   carried, in whole or in part, over an ATM network.  In that case, the
   constructs defined elsewhere for IP are sufficient.

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

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

3.0 Local Connection Options

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.
Top   ToC   RFC3441 - Page 4

3.1 ATM Bearer Connection

These local connection options are used to parameterize ATM bearer connections. TABLE 1: Local Connection Options for ATM Bearers +---------+---------------+---------------------------------------+ | LCO | Meaning | Values | +---------+---------------+---------------------------------------+ | ct | Connection |AAL1, AAL1_SDT, AAL1_UDT, AAL2, AAL3/4,| | | Type |AAL5, USER_DEFINED_AAL | +---------+---------------+---------------------------------------+ | vc |VC/Bearer type | PVC, SVC, CID | +---------+---------------+---------------------------------------+ | se | Enable path | on, off | | | set-up | | +---------+---------------+---------------------------------------+ | ci | Connection | See below | | | Element | | | | Identifier | | +---------+---------------+---------------------------------------+ Connection type (ct): This parameter describes the ATM adaptation layer. The values that can be assigned to it are: AAL1, AAL1_SDT, AAL1_UDT, AAL2, AAL3/4, AAL5 and USER_DEFINED_AAL. The user defined adaptation layer is per amendment 2 of ITU-T Q.2931. Type of Bearer/VC (vc): This indicates whether a PVC, CID or an SVC is to be used for an ATM connection. Possible values are: PVC, SVC or CID. Omitting this parameter will result in the use of a default, which could be embedded or provisioned. The value "PVC" covers both classical PVCs and SPVCs. The value "CID" covers subchannels within AAL1 [35] and AAL2 [10] virtual circuits. A value of "SVC" for atm/vc does not necessarily imply that the addressed media gateway should initiate signaling for bearer set-up, since this might be done by another node such as the far-end media gateway. Enable path set-up (se): This local connection option is used to explicitly enable or disable the use of bearer signaling for path set-up. Permitted values of this local connection option are "on" and "off". Examples of bearer signaling are SVC signaling, ITU Q.2630.1 signaling and combinations thereof. Examples of such combinations are the set-up of an AAL2 SVC and the assignment of a CID within it or the set-up of a concatenation of an AAL2 single-CID SVC and a CID channel within a multiplexed AAL2 VC. This parameter can be used with both the backward and forward bearer connection
Top   ToC   RFC3441 - Page 5
   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-<vcci>
      * VCCI-<vcci>/CID-<cid>
      * <ATMaddressType>-<ATMaddress>/VCCI-<vcci>
      * <ATMaddress>/VCCI-<vcci>
      * <ATMaddressType>-<ATMaddress>/VCCI-<vcci>/CID-<cid>
      * <ATMaddress>/VCCI-<vcci>/CID-<cid>
      * BCG-<bcg>/VCCI-<vcci>
      * BCG-<bcg>/VCCI-<vcci>/CID-<cid>
      * BCG-<bcg>/VPI-<vpi>/VCI-<vci>
      * BCG-<bcg>/VPI-<vpi>/VCI-<vci>/CID-<cid>
      * PORT-<portId>/VPI-<vpi>/VCI-<vci>
      * PORT-<portId>/VPI-<vpi>/VCI-<vci>/CID-<cid>
      * VPCI-<vpci>/VCI-<vci>
      * VPCI-<vpci>/VCI-<vci>/CID-<cid>
      * <ATMaddressType>-<ATMaddress>/VPCI-<vpci>/VCI-<vci>
      * <ATMaddress>/VPCI-<vpci>/VCI-<vci>
      * <ATMaddressType>-<ATMaddress>/VPCI-<vpci>/VCI-<vci>/CID-<cid>
      * <ATMaddress>/VPCI-<vpci>/VCI-<vci>/CID-<cid>
Top   ToC   RFC3441 - Page 6
   The subparameters of the ci parameter are defined as follows:

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

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

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

   The VCCI is a 16 bit field defined in ITU Recommendation Q.2941.2
   [14].  The VCCI is similar to the VCI, except for the fact that it
   retains its value across VC crossconnects.
Top   ToC   RFC3441 - Page 7
   In general, <vpci> and <vcci> values are unique between a pair of
   nodes.  When they are unique between a pair of nodes, but not unique
   within a network, they need to be qualified at any node, by the ATM
   address of the remote node.  These parameters can be pre-provisioned
   or signaled via SVC signaling messages.  When VPCI and VCCI values
   are pre-provisioned, administrations have the option of provisioning
   them uniquely in a network.  In this case, the ATM address of the far
   end is not needed to qualify these parameters.

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

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

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

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

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

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

   If the addressType is NSAP, the address is expressed in the standard
   dotted hex form.  This is a string of 40 hex digits, with dots after
   the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th
   digits.  The "0x" prefix is not used, since this is always
   represented in hex.  The last 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
Top   ToC   RFC3441 - Page 8
   If the ATMaddressType is E164, the ATMaddress is expressed as a
   decimal number with up to 15 digits.  For example:

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

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

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

       L: atm/ci:GWID-officeABCmgx101vism12

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

       L: atm/ci:ALIAS-officeABCmgx101vism12

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

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

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

3.2 ATM Adaptation Layer (AAL)

These local connection options are used to parameterize the ATM adaptation layer (AAL). These are further classified as: generic AAL connection options, AAL1-related connection options and AAL2-related connection options. Currently, there are no local connection options defined in this category that pertain to AAL5.
Top   ToC   RFC3441 - Page 9
   TABLE 2: Generic Local Connection Options for the AAL
   +---------+---------------+---------------------------------------+
   |  LCO    |    Meaning    |           Values                      |
   +---------+---------------+---------------------------------------+
   | aalApp  | Application   |itu_h323c,af83,AAL5_SSCOP,             |
   |         |               |itu_i3661_unassured, itu_i3661_assured |
   |         |               |itu_i3662, itu_i3651, itu_i3652,       |
   |         |               |itu_i3653, itu_i3654,                  |
   |         |               |FRF5, FRF8, FRF11,itu_h2221            |
   +---------+---------------+---------------------------------------+
   |   sbc   | Subchannel    | 1...24 for T1-based applications      |
   |         | Count         | 1...31 for E1-based applications      |
   +---------+---------------+---------------------------------------+

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

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

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

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

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

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

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

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

      "itu_i3652"             Service-specific coordination function,
                              as defined in ITU I.365.2, for Connection
                              Oriented Network Service (SSCF-CONS)
                              [16].  This uses SSCOP [14].
Top   ToC   RFC3441 - Page 10
      "itu_i3653"             Service-specific coordination function,
                              as defined in ITU I.365.3, for Connection
                              Oriented Transport Service (SSCF-COTS)
                              [17].  This uses SSCOP [14].

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

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

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

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

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

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

   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  |
   +---------+---------------+---------------------------------------+
Top   ToC   RFC3441 - Page 11
   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.
Top   ToC   RFC3441 - Page 12
   Forward Error Correction Enable (fe): This indicates whether FEC, as
   defined in ITU I.363.1 [1], is enabled or not.  Possible values are:
   "NULL", "DELAY_SENSITIVE" and "LOSS_SENSITIVE".  FEC can be enabled
   differently for delay-sensitive and loss-sensitive connections.  A
   "NULL" value implies disabling FEC for an AAL1 connection.

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

   Profile List (pfl): This is a list of profiles.  Profile types are
   followed by profile numbers for each type.  The ordering of profiles
   can imply preference, with the most preferred profile first.  There
   can be multiple instances of the same profile type in this list.
   Spaces are used as delimiters within this list.  Therefore, to comply
   with MGCP syntax [36], it is necessary to enclose this list in double
   quotes.
Top   ToC   RFC3441 - Page 13
   The format of the pfl parameter is as follows:

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

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

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

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

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

   The <profile#> parameter is expressed as a decimal number in the
   range 1-255.
Top   ToC   RFC3441 - Page 14
   An example of the use of the pfl parameter is:

L: atm/pfl:"AAL2/ITU 8  AAL2/ATMF 7 8 AAL2/custom 100  AAL2/cisco 200"

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

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

   Simplified CPS (smplCPS): This enables the AAL2 CPS simplification
   described in [21].  It can be assigned the following values: on, off.
   Under this simplification, each ATM cell contains exactly 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 [10].
   It is an integer number of microseconds, represented as the decimal
   equivalent of 32 bits.

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

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

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

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

   Transmission error detection (ted): Transmission error detection is
   defined in ITU I.366.1 [11].  The ted local connection option can
   take on the following values: on, off.  This local connection option
   is useful in qualifying the aalApp local connection option, when the
   value of the latter is "itu_i3661_unassured".
Top   ToC   RFC3441 - Page 15
   SSSAR reassembly timer (rastimer): This is defined in ITU I.366.1
   [11].  It is an integer number of microseconds, represented as the
   decimal equivalent of 32 bits.

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

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

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

3.3 Service Layer

TABLE 5: Local Connection Options for the Service Layer +--------------+---------------+----------------------------------+ | LCO | Meaning | Values | +--------------+---------------+----------------------------------+ | vsel | Voice codec | See below | | | Selection | | +--------------+---------------+----------------------------------+ | dsel | Data codec | See below | | | Selection | | +--------------+---------------+----------------------------------+ | fsel | Fax codec | See below | | | Selection | | +--------------+---------------+----------------------------------+ | ccnf | Codec | Even number (4 - 32) hex digits | | | Configuration | | +--------------+---------------+----------------------------------+ | usi | ISUP User | Two hex digits | | | Information | | +--------------+---------------+----------------------------------+
Top   ToC   RFC3441 - Page 16
   Voice codec selection (vsel): This is a prioritized list of one or
   more 3-tuples describing voice service.  Each vsel 3-tuple indicates
   a codec, an optional packet length and an optional packetization
   period.

   The vsel local connection option is structured as follows:

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

   where the <encodingName> refers to a codec name such as PCMU, G726-
   32, G729 etc.  See [18] and [34] for a list of codecs with static
   payload types.  The <packetLength> is a decimal integer
   representation of the packet length in octets.  The <packetTime> is a
   decimal integer representation of the packetization interval in
   microseconds.

   Voiceband data codec selection (dsel): This is a prioritized list of
   one or more 3-tuples describing voiceband data 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 <fxIncl> 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 <fxIncl> 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 <fxIncl> 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:

      "<fxIncl> <encodingName #1> <packetLength #1><packetTime #1>
               <encodingName #2> <packetLength #2><packetTime #2>
               ...
               <encodingName #N> <packetLength #N><packetTime #N>"
Top   ToC   RFC3441 - Page 17
   where the <encodingName> refers to a codec name such as PCMU, G726-
   32, G729 etc.  The <packetLength> is a decimal integer representation
   of the packet length in octets.  The <packetTime> is a decimal
   integer representation of the packetization interval in microseconds.

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

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

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

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

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

   Examples of the use of these parameters are:

      L: atm/vsel:"G729 10 10000 G726-32 40 10000"
      L: atm/dsel:"off PCMA 10 10000 G726-32 40 10000"
      L: atm/fsel:"PCMU 40 5000 G726-32 20 5000"
      L: atm/vsel:"G729 10 10000 G726-32 40 10000"
      L: atm/dsel:"on  PCMA 10 10000 G726-32 40 10000"

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

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

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

      L: atm/ccnf:01080C

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

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

   The usi LCO represented as a string of two hex digits.  The "0x"
   prefix is omitted since this value is always hexadecimal.  These hex
   digits are 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:
Top   ToC   RFC3441 - Page 19
      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



(page 19 continued on part 2)

Next Section