diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3441.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3441.txt')
| -rw-r--r-- | doc/rfc/rfc3441.txt | 2803 |
1 files changed, 2803 insertions, 0 deletions
diff --git a/doc/rfc/rfc3441.txt b/doc/rfc/rfc3441.txt new file mode 100644 index 0000000..39dde2c --- /dev/null +++ b/doc/rfc/rfc3441.txt @@ -0,0 +1,2803 @@ + + + + + + +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 + + + +Kumar Informational [Page 1] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + + +Kumar Informational [Page 2] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + + + + + + + + + + + + + + + + + +Kumar Informational [Page 3] + +RFC 3441 ATM MGCP Package January 2003 + + +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 + + + + + +Kumar Informational [Page 4] + +RFC 3441 ATM MGCP Package January 2003 + + + 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> + + + + + + + + +Kumar Informational [Page 5] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + +Kumar Informational [Page 6] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 + + + + + +Kumar Informational [Page 7] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + + + + +Kumar Informational [Page 8] + +RFC 3441 ATM MGCP Package January 2003 + + + 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]. + + + +Kumar Informational [Page 9] + +RFC 3441 ATM MGCP Package January 2003 + + + "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 | + +---------+---------------+---------------------------------------+ + + + + + + + + +Kumar Informational [Page 10] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + +Kumar Informational [Page 11] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + +Kumar Informational [Page 12] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + + +Kumar Informational [Page 13] + +RFC 3441 ATM MGCP Package January 2003 + + + 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". + + + + + + +Kumar Informational [Page 14] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 | | + +--------------+---------------+----------------------------------+ + + + + + + + +Kumar Informational [Page 15] + +RFC 3441 ATM MGCP Package January 2003 + + + 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>" + + + + + +Kumar Informational [Page 16] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 - -" + + + + + + + +Kumar Informational [Page 17] + +RFC 3441 ATM MGCP Package January 2003 + + + 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: + + + + + + +Kumar Informational [Page 18] + +RFC 3441 ATM MGCP Package January 2003 + + + VALUE MEANING + 0x01 CCITT standardized rate adaption V.110 and X.30 + 0x02 Recommendation G.711 Mu-law + 0x03 Recommendation G.711 A-law + 0x04 Recommendation G.721 32 kbps ADPCM + and Recommendation I.460 + 0x05 Recommendations H.221 and H.242 + 0x06 Recommendation H.223 and H.245 + 0x07 Non-ITU-T standardized rate adaption + 0x08 ITU-T standardized rate adaption V.120 + 0x09 CCITT standardized rate adaption X.31 HDLC flag stuffing + +3.4 ATM Bearer Traffic Management + + These local connection options are used to convey ATM traffic + parameters. + + TABLE 6: Local Connection Options for ATM bearer traffic management + +---------+---------------+---------------------------------------+ + | ATM LCO | Meaning | Values | + +---------+---------------+---------------------------------------+ + | atc | ATM transfer |CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR, | + | | capability or |DBR,SBR,ABT/IT,ABT/DT | + | | service | | + | | category | | + +---------+---------------+---------------------------------------+ + | sbt |atc subtype | 1...5 | + +---------+---------------+---------------------------------------+ + | qos | QoS class | 0...5 | + +---------+---------------+---------------------------------------+ + | bcob |Broadband | 0...31 | + | |Connection |(Defined values listed below) | + | |-Oriented | | + | |Bearer Class | | + +---------+---------------+---------------------------------------+ + | eetim |End-to-end |on,off | + | |timing required| | + +---------+---------------+---------------------------------------+ + | stc |Susceptibility | 0...3 | + | |to clipping |(Defined values listed below) | + +---------+---------------+---------------------------------------+ + | upcc |User plane |0...3 | + | |connection |(Defined values listed below) | + | |configuration | | + +---------+---------------+---------------------------------------+ + + + + + + +Kumar Informational [Page 19] + +RFC 3441 ATM MGCP Package January 2003 + + + +---------+---------------+---------------------------------------+ + | 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 | | + +---------+---------------+---------------------------------------+ + + + + +Kumar Informational [Page 20] + +RFC 3441 ATM MGCP Package January 2003 + + + ATM transfer capability (atc): This parameter indicates the ATM + Transfer Capability described in ITU I.371 [19], equivalent to the + ATM Service Category described in the UNI 4.1 Traffic Management + specification [8]. In applications conforming to ITU I.371, this + parameter can be assigned the following values: DBR, SBR, ABT/IT, + ABT/DT, ABR. In applications conforming to the UNI 4.1 Traffic + Management specification, this parameter can be assigned the + following values: CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR. + + Subtype (sbt): This qualifies the atc local connection option. It + can be assigned integer values of 1...5. The following combinations + of the atc and sbt local connection options are meaningful: + +atc sbt Resulting transport + +CBR/DBR 1 Voiceband signal transport (ITU G.711, G.722, I.363) +CBR/DBR 2 Circuit transport (ITU I.363) +CBR/DBR 4 High-quality audio signal transport (ITU I.363) +CBR/DBR 5 Video signal transport (ITU I.363) +nrt-VBR 1 nrt-VBR.1 +nrt-VBR 2 nrt-VBR.2 +nrt-VBR 3 nrt-VBR.3 +rt-VBR 1 rt-VBR.1 +rt-VBR 2 rt-VBR.2 +rt-VBR 3 rt-VBR.3 +UBR 1 UBR.1 +UBR 2 UBR.2 +GFR 1 GFR.1 +GFR 2 GRR.2 +SBR 1 SBR1 +SBR 2 SBR2 +SBR 3 SBR3 + + Subtypes for the atc values of CBR or DBR are per [29]. Subtypes for + the remaining atc values are per [8] and [19]. + + + + + + + + + + + + + + + + +Kumar Informational [Page 21] + +RFC 3441 ATM MGCP Package January 2003 + + + QoS class (qos): This indicates the QoS class specified in ITU + I.2965.1 [4]. It can take on the integer decimal values in the range + 0 - 5. These values are mapped into QoS classes as follows: + + ---------------------------------------------------------- + | VALUE | MEANING | + ---------------------------------------------------------- + | 0 | Default QoS | + ---------------------------------------------------------- + | 1 | Stringent | + ---------------------------------------------------------- + | 2 | Tolerant | + ---------------------------------------------------------- + | 3 | Bi-level | + ---------------------------------------------------------- + | 4 | Unbounded | + ---------------------------------------------------------- + | 5 | Stringent bi-level | + ---------------------------------------------------------- + + Broadband Connection-Oriented Bearer Class (bcob): The bcob local + connection option indicates the Broadband Connection-Oriented Bearer + Class specified in ITU Q.2961.2 [5]. It is represented as a decimal + number in the range 0 - 31, or its hex equivalent (range 0x0 - 0x1F). + The following values are currently defined: + + ---------------------------------------------------------- + | VALUE | MEANING | + ---------------------------------------------------------- + | 1 | BCOB-A | + ---------------------------------------------------------- + | 3 | BCOB-C | + ---------------------------------------------------------- + | 5 | Frame relaying bearer service | + ---------------------------------------------------------- + | 16 | BCOB-X | + ---------------------------------------------------------- + | 24 | BCOB-VP (transparent VP service) | + ---------------------------------------------------------- + + End-to-end timing (eetim): This indicates whether end-to-end timing + is required (Table 4-8 of [29]). It can be assigned a value of "on" + or "off". + + + + + + + + +Kumar Informational [Page 22] + +RFC 3441 ATM MGCP Package January 2003 + + + Susceptibility to clipping (stc): The stc local connection option + indicates susceptibility to clipping. It is represented as a decimal + number in the range 0 - 3, or its hex equivalent (range 0x0 - 0x3). + All values except those listed below are reserved. + + ---------------------------------------------------------- + | VALUE | MEANING | + ---------------------------------------------------------- + | 0 | Not susceptible to clipping | + ---------------------------------------------------------- + | 1 | Susceptible to clipping | + ---------------------------------------------------------- + + User plane connection configuration (upcc): The upcc local connection + option is represented as a decimal number in the range 0 - 3, or its + hex equivalent (range 0x0 - 0x3). All values except those listed + below are reserved. + + ---------------------------------------------------------- + | VALUE | MEANING | + ---------------------------------------------------------- + | 0 | Point to point | + ---------------------------------------------------------- + | 1 | Point to multipoint | + ---------------------------------------------------------- + + ATM QoS parameters, forward direction (aqf) and backward direction + (aqb): Here, forward is the direction away from the media gateway, + backward is the direction towards the gateway. If the directional + convention used by bearer signaling at the gateway is different, then + appropriate translations must be done by the media gateway. These + parameters have the following format: + + "<cdvType><acdv><ccdv><eetd><cmtd><aclr>" + + Since spaces are used in this list, it must be enclosed in double + quotes for MGCP compliance [36]. + + The <cdvType> parameter can take on the string values of "PP" and + "2P". These refer to the peak-to-peak and two-point CDV as defined + in UNI 4.0 [6] and ITU Q.2965.2 [7] respectively. + + The CDV parameters, <acdv> and <ccdv>, refer to the acceptable and + cumulative CDVs respectively. These are expressed in units of + microseconds and represented as the decimal or hex equivalent of 24- + bit fields. These use the cell loss ratio, <aclr>, as the "alpha" + quantiles defined in the ATMF TM 4.1 specification [8] and in ITU + I.356 [9]. + + + +Kumar Informational [Page 23] + +RFC 3441 ATM MGCP Package January 2003 + + + The transit delay parameters, <eetd> and <cmtd>, refer to the end-to- + end and cumulative transit delays respectively in milliseconds. + These are represented as the decimal equivalents of 16-bit fields. + These parameters are defined in Q.2965.2 [7], UNI 4.0 [8] and Q.2931 + [29]. + + The <aclr> parameter refers to forward and backward acceptable cell + loss ratios. This is the ratio between the number of cells lost and + the number of cells transmitted. It is expressed as the decimal or + hex equivalent of an 8-bit field. This field expresses an order of + magnitude n, where n is an integer in the range 1-15. The Cell Loss + Ratio takes on the value 10 raised to the power of minus n. + + If any of these parameters is not specified, is inapplicable or is + implied, then it is set to "-". + + Examples of the use of the aqf and aqb local connection options are: + + L: atm/aqf:"PP 8125 3455 32000 - 11" + L: atm/aqb:"PP 4675 2155 18000 - 12" + + This implies a forward acceptable peak-to-peak CDV of 8.125 ms, a + backward acceptable peak-to-peak CDV of 4.675 ms, forward cumulative + peak-to-peak CDV of 3.455 ms, a backward cumulative peak-to-peak CDV + of 2.155 ms, a forward end-to-end transit delay of 32 ms, a backward + end-to-end transit delay of 18 ms, an unspecified forward cumulative + transit delay, an unspecified backward cumulative transit delay, a + forward cell loss ratio of 10 raised to minus 11 and a backward cell + loss ratio of 10 to the minus 12. + + ATM traffic descriptors, forward direction CLP=0+1 (adf0+1), backward + direction CLP=0+1 (adb0+1), forward direction CLP=0 (adf0), backward + direction CLP=0 (adb0): Here, forward is the direction away from the + media gateway, backward is the direction towards the gateway. If the + directional convention used by bearer signaling at the gateway is + different, then appropriate translations must be done by the media + gateway. The adf0+1, adb0+1, adf0 and adb0 local connection options + have the following format: + + "<pcr><scr><mbs><cdvt><mcr><mfs><fd><te>" + + Since spaces are used in these lists, they must be enclosed in double + quotes for MGCP compliance [36]. + + These parameters are defined per the ATMF TM 4.1 specification [8]. + Each of these parameters can be set to "-" if the intent is to not + specify it via MGCP. These definitions are listed briefly in Table 7 + below. + + + +Kumar Informational [Page 24] + +RFC 3441 ATM MGCP Package January 2003 + + + 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: + + "<nrm><trm><cdf><adtf>" + + Since spaces are used in these lists, they must be enclosed in double + quotes for MGCP compliance [36]. + + + + + +Kumar Informational [Page 25] + +RFC 3441 ATM MGCP Package January 2003 + + + These ABR parameters are defined per [6] and [8]. Their definition + is summarized in Table 8 below. In MGCP, these are represented as + the decimal equivalent of the binary fields mentioned below. If any + of these parameters is meant to be left unspecified, it is set to "- + ". + +TABLE 8: ABR Parameters ++-----------+---------------------------------+-----------------------+ +| PARAMETER | MEANING | FIELD SIZE | ++-----------+---------------------------------+-----------------------+ +| NRM | Maximum number of cells per | 3 bits | +| | forward Resource Management cell| | ++-----------+---------------------------------+-----------------------+ +| TRM | Maximum time between | 3 bits | +| |forward Resource Management cells| | ++-----------+---------------------------------+-----------------------+ +| CDF | Cutoff Decrease Factor | 3 bits | ++-----------+---------------------------------+-----------------------+ +| ADTF | Allowed Cell Rate Decrease | 10 bits | +| | Time Factor | | ++-----------+---------------------------------+-----------------------+ + + ABR set-up parameters (abrSetup): This local connection option is + used to indicate the ABR parameters needed during call/connection + establishment (Section 10.1.2.2 of the UNI 4.0 signaling + specification [6]). The abrSetup local connection option has the + following format: + + "<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>" + + Since spaces are used in this list, it must be enclosed in double + quotes for MGCP compliance [36]. + + These parameters are defined per [6]. Their definitions are listed + briefly in Table 9 below. In these definitions, forward is the + direction 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 "-". + + + + + + + + + + + +Kumar Informational [Page 26] + +RFC 3441 ATM MGCP Package January 2003 + + +TABLE 9: ABR Set-up Parameters ++-----------+----------------------------------+---------------------+ +| PARAMETER | MEANING | REPRESENTATION | ++-----------+----------------------------------+---------------------+ +| <ficr> | Forward Initial Cell Rate | Decimal equivalent | +| |(Cells per second) | of 24-bit field | ++-----------+----------------------------------+---------------------+ +| <bicr> | Backward Initial Cell Rate | Decimal equivalent | +| | (Cells per second) | of 24-bit field | ++-----------+----------------------------------+---------------------+ +| <ftbe> | Forward transient buffer | Decimal equivalent | +| | exposure (Cells) | of 24-bit field | ++-----------+----------------------------------+---------------------+ +| <btbe> | Backward transient buffer | Decimal equivalent | +| | exposure (Cells) | of 24-bit field | ++-----------+----------------------------------+---------------------+ +| <crmrtt> | Cumulative RM round-trip time | Decimal equivalent | +| | (Microseconds) | of 24-bit field | ++-----------+----------------------------------+---------------------+ +| <frif> | Forward rate increase factor | Decimal integer | +| | (used to derive cell count) | 0 -15 | ++-----------+----------------------------------+---------------------+ +| <brif> | Backward rate increase factor | Decimal integer | +| | (used to derive cell count) | 0 -15 | ++-----------+----------------------------------+---------------------+ +| <frdf> | Forward rate decrease factor | Decimal integer | +| | (used to derive cell count) | 0 -15 | ++-----------+----------------------------------+---------------------+ +| <brdf> | Backward rate decrease factor | Decimal integer | +| | (used to derive cell count) | 0 -15 | ++-----------+----------------------------------+---------------------+ + +3.5 AAL Dimensioning + + The Local Connection Options in Table 10 are used to dimension the + operation of the AAL. In these parameters, forward is the direction + away from the media gateway. Backward is the direction towards the + media gateway. These parameters are represented as decimal integers + in the ranges listed in Table 10. + + TABLE 10: Local Connection Options used to dimension the AAL + +---------+---------------+---------------------------------------+ + | LCO | Meaning | Values (Decimal Integer) | + +---------+---------------+---------------------------------------+ + | str | Structure | 1...65,535 | + | | Size | | + +---------+---------------+---------------------------------------+ + + + + +Kumar Informational [Page 27] + +RFC 3441 ATM MGCP Package January 2003 + + + +---------+---------------+---------------------------------------+ + | cbrRate | CBR rate | Bit map per Table 4-6 of [29] | + +---------+---------------+---------------------------------------+ + | fcpcs | Forward | AAL2: 45 or 64 | + | | maximum CPCS | AAL5: 1-65,535 | + | | SDU size | | + +---------+---------------+---------------------------------------+ + | bcpcs | Backward | AAL2: 45 or 64 | + | | maximum CPCS | AAL5: 1-65,535 | + | | SDU size | | + +---------+---------------+---------------------------------------+ + |fSDUrate | Forward | 24-bit equivalent | + | | maximum AAL2 | | + | | CPS SDU rate | | + +---------+---------------+---------------------------------------+ + |bSDUrate | Backward | 24-bit equivalent | + | | maximum AAL2 | | + | | CPS SDU rate | | + +---------+---------------+---------------------------------------+ + | ffrm |Forward maximum| 1-65,535 | + | |frame block | | + | |size | | + +---------+---------------+---------------------------------------+ + | bfrm |Backward | 1-65,535 | + | |maximum frame | | + | |block size | | + +---------+---------------+---------------------------------------+ + |fsssar |Forward maximum| 1-65,568 | + | |SSSAR-SDU | | + | |size | | + +---------+---------------+---------------------------------------+ + |bsssar |Backward | 1-65,568 | + | |maximum SSSAR | | + | |SDU size | | + +---------+---------------+---------------------------------------+ + |fsscopsdu|Forward maximum| 1-65,528 | + | |SSCOP-SDU | | + | |size | | + +---------+---------------+---------------------------------------+ + | | | | + |bsscopsdu|Backward | 1-65,528 | + | |maximum SSCOP | | + | |SDU size | | + +---------+---------------+---------------------------------------+ + |fsscopuu |Forward maximum| 1-65,524 | + | |SSCOP-UU field | | + | |size | | + +---------+---------------+---------------------------------------+ + + + +Kumar Informational [Page 28] + +RFC 3441 ATM MGCP Package January 2003 + + + +---------+---------------+---------------------------------------+ + |bsscopuu |Backward | 1-65,524 | + | |maximum SSCOP | | + | |UU size | | + +---------+---------------+---------------------------------------+ + + Structured Data Transfer Block Size (str): This parameter is + meaningful only when structured AAL1 is used. It indicates the size + (in octets) of the block used for structured data transfer. If not + included as a local connection option, the structure size is to be + known by other means. For instance, af-vtoa-78 [20] fixes the + structure size for n x 64 service, with or without CAS. The + L: atm/str parameter is coded as the decimal equivalent of a 16-bit + field [29]. The theoretical maximum value of this parameter is + 65,535, although most services use much less. + + CBR Rate (cbrRate): This is a hexadecimal representation of the bit + map defined in Table 4-6 of ITU Q.2931 [29]. This is represented as + exactly two hex digits. For example: + + L: atm/cbrRate:04 + + implies a CBR rate of 1.544 Mbps. + + Forward maximum CPCS-SDU size (fcpcs): This is the maximum size of + the AAL2 or AA5 CPCS SDU in the forward direction. + + Backward maximum CPCS-SDU size (bcpcs): This is the maximum size of + the AAL2 or AA5 CPCS SDU in the backward direction. + + Forward maximum AAL2 CPCS-SDU rate (fSDUrate): This is the maximum + rate of the AAL2 CPCS-SDUs in the forward direction. + + Backward maximum AAL2 CPCS-SDU rate (bSDUrate): This is the maximum + rate of the AAL2 CPCS-SDUs in the backward direction. + + The fSDUrate and bSDUrate local connection options can be used to + rate-limit AAL2 CIDs, especially when used in the SSSAR [1] and frame + mode [2] contexts. + + Forward maximum frame mode block size (ffrm): This is the maximum + size, in the forward direction, of the AAL2 frame mode data unit + (I.366.2) [2]. + + Backward maximum frame mode block size (bfrm): This is the maximum + size, in the backward direction, of the AAL2 frame mode data unit + (I.366.2) [2]. + + + + +Kumar Informational [Page 29] + +RFC 3441 ATM MGCP Package January 2003 + + + Forward maximum SSSAR-SDU size (fsssar): This is the maximum size, in + the forward direction, of the AAL2-based SSSAR-SDU (I.366.1) [1]. + + Backward maximum SSSAR-SDU size (bsssar): This is the maximum size, + in the backward direction, of the AAL2-based SSSAR-SDU (I.366.1) [1]. + + Forward maximum SSCOP-SDU size (fsscopsdu): This is the maximum size, + in the forward direction, of the AAL2-based SSCOP-SDU (I.366.1) [1]. + + Backward maximum SSCOP-SDU size (bsscopsdu): This is the maximum + size, in the backward direction, of the AAL2-based SSCOP-SDU + (I.366.1) [1]. + + Forward maximum SSCOP-UU size (fsscopuu): This is the maximum size, + in the forward direction, of the AAL2-based SSCOP-UU field(I.366.1) + [1]. + + Backward maximum SSCOP-UU size (bsscopuu): This is the maximum size, + in the backward direction, of the AAL2-based SSCOP- UU field + (I.366.1) [1]. + +4.0 Signals and Events + + Standard MGCP syntax and keywords [36] are used in Table 11 to define + the events in this package. Since these are all connection events, + they cannot be requested for endpoints. For consistency with MGCP + [36], it is required that the suffix @<connection-id> NOT be omitted + even if there is only one connection to an endpoint. This suffix can + also be wildcarded per MGCP rules. + + There are no auditable event-states associated with the ATM package. + + 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 + + + +Kumar Informational [Page 30] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 # | | | | + |---------------|-----------------------|-----|------|--------------| + + + +Kumar Informational [Page 31] + +RFC 3441 ATM MGCP Package January 2003 + + + |---------------|-----------------------|-----|------|--------------| + | 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. + + + + + + + +Kumar Informational [Page 32] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + + + + +Kumar Informational [Page 33] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + + + + +Kumar Informational [Page 34] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + +5.0 Connection Parameters + + The MGCP connection parameters structure is returned in an autonomous + delete connection message, and in a response to a delete or audit + connection command. The standard connections parameters [36] it + contains are redefined below for ATM. Also, a new extension + parameter specific to the ATM package is defined. + + The standard connection parameters redefined for ATM are: + + Number of packets sent: If a VCC is assigned to the connection, this + is the total number of ATM cells transmitted for the duration of the + connection. If a CID within an AAL2 VCC is assigned to the + connection, it is the number of AAL2 common part sublayer (CPS) + packets transmitted for the duration of the connection. + + Number of octets sent: If a VCC is assigned to the connection, this + is the total number of ATM payload octets transmitted for the + duration of the connection. If a CID within an AAL2 VCC is assigned + to the connection, this is the total number of AAL2 CPS payload + octets transmitted for the duration of the connection. + + Number of packets received: If a VCC is assigned to the connection, + this is the total number of ATM cells received for the duration of + the connection. If a CID within an AAL2 VCC is assigned to the + connection, it is the number of AAL2 common part sublayer (CPS) + packets received for the duration of the connection. + + Number of octets received: If a VCC is assigned to the connection, + this is the total number of ATM payload octets received for the + duration of the connection. If a CID within an AAL2 VCC is assigned + to the connection, this is the total number of AAL2 CPS payload + octets received for the duration of the connection. + + Number of packets lost: If a VCC is assigned to the connection, this + is the total number of ATM cells lost for the duration of the + connection, in the direction towards the gateway. If a CID within an + + + +Kumar Informational [Page 35] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 + + + + +Kumar Informational [Page 36] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + +6.0 Negotiation of Profiles and Codecs in ATM Applications + +6.1 Consistency of Parameters + + For ATM networks, the "nt" local connection option in MGCP must be + set to "ATM". + + In any ATM application, the following Local Connection Options should + not be used: + + Type of service, L: t + Resource reservation, L: r + + This is because the Local Connection Options listed in Table 6 + provide information equivalent to the L: t and L: r local connection + options. + + The following Local Connection Option is not meaningful in the AAL1 + case and should not be used: + + Packetization period, L: p + + In AAL2 applications, the following Local Connection Options should + not be used: + + Encoding algorithm, L: a + Packetization period, L: p + + + + + +Kumar Informational [Page 37] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + +6.2 Codec/Profile Negotiation in ATM Networks + + In AAL1 and AAL5 applications, codec negotiation is similar to the IP + case, although some of the local connection options and SDP + connection descriptor parameters are different. See [18] for + conventions for the use of the Session Description Protocol [26] in + the ATM context. + + In AAL2 applications, the L:a and L:p parameters are disallowed. + Profile negotiation takes the place of codec negotiation. 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. + + + + + + + +Kumar Informational [Page 38] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 [18]. Whether these lists imply a + real priority or not, a profile is, as a general rule, preferred to + profiles that follow it in a list. + + Each media gateway has a policy for assigning priorities to different + lists (inter-list priority) which is different from the positional + ordering of profiles within a list (intra-list priority). This + policy might be a hardcoded default or provisioned. The inter-list + priority specifies an ordering of the following lists with respect to + each other: + + * 'C-list', which is the priority list from the call agent, + received through L: atm/pfl. + * 'R-list', which is the priority list from the remote end, + received through the SDP remote connection descriptor. + * 'L-list', which is the local priority list, hardcoded or + provisioned. + + Depending on the application, different inter-list priorities may be + used in 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. + + + + + + + + + +Kumar Informational [Page 39] + +RFC 3441 ATM MGCP Package January 2003 + + + The process of profile negotiation is as shown below: + + ORIGINATING TERMINATING + GATEWAY GATEWAY + + (1) On receiving CRCX + do a policy-based ordered + intersection of the C-list, + and L-list. No R-list present. + ----------------------------------> + (2)Send resulting ordered list + to the terminating gateway + via SDP. + + (3) On receiving CRCX do + a policy-based + ordered + intersection of the + C-list, R-list and + L-list. + (4) The highest priority + profile in the + resulting + list is the + selected + profile. + <----------------------------------- + (5) Send selected profile + to the originating gateway + via SDP. + + 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 + + + +Kumar Informational [Page 40] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 [18] are used to effect this coordination. + Using these constructs, entities such as call agents and media + gateways can indicate preferred bindings for the first, most + preferred profile in a profile list. + + When performing ordered intersections of the C-list, L-list and + R-list in the call flow above, media gateways MUST use the inter-list + priority to choose between 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 [18] 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 [18]. + + 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 + + + +Kumar Informational [Page 41] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 + + + + + + + + + + + + + + +Kumar Informational [Page 42] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 > R-list > L-list + + where '>' means 'has higher priority than'. The term 'R-list' can be + omitted from this series of inequalities since, in case under study, + profile negotiation does not include any further ordered + intersections at the originating gateway. + + In accordance with this policy, the originating gateway performs an + ordered intersection of the C-list and the L-list to produce: + + itu 8, itu 3, itu 1, custom 100 + + Since the C-list has the highest priority and the first profile in + the intersected profile list is also the first profile in the C-list, + the service bindings provided by the originating call agent are + associated with the first profile, itu 8. The originating gateway + sends this result(intersected profile list and service bindings for + the first profile, itu 8) via the SDP remote session descriptor to + the terminating gateway. The service bindings are expressed as + follows [18]: + + a=vsel:G729 10 10000 + a=dsel:on PCMU 40 5000 + + + + + + +Kumar Informational [Page 43] + +RFC 3441 ATM MGCP Package January 2003 + + + 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 > L-list > C-list + + Using this policy, gateway #2 produces the following ordered + intersection of R-list, L-list and C-list: + + itu 3, itu 1 + + The first profile in this list, itu 3, is to be used for this + connection. Gateway 2 indicates this to the call agent through the + SDP local connection descriptor. + + Note that the service bindings provided by the originating gateway + have not been specified with respect to itu 3. Therefore, these + cannot be used even though 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 + + + + + + + + + + + + +Kumar Informational [Page 44] + +RFC 3441 ATM MGCP Package January 2003 + + + 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. + +7.0 Security Considerations + + The ATM package extends the base Media Gateway Control Protocol + (MGCP) [36]. This package specifies no additional security + requirements or recommendations over those of the base MGCP protocol. + +8.0 IANA Considerations + + 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 [36]. + + The contact for the MGCP ATM package is the author of this document + (Section 12). + +9.0 References + + [1] ITU-T I.366.1, B-ISDN ATM Adaptation Layer Specification: Type 1 + AAL. + + [2] ITU-T I.366.2, AAL Type 2 Reassembly Service Specific + Convergence Sublayer for Trunking, Nov. 2000. + + [3] af-vtoa-0113.000, ATM trunking using AAL2 for narrowband + services. + + [4] ITU Q. 2965.1, Digital subscriber signalling system no.2 (DSS 2) + - Support of Quality of Service classes. + + [5] ITU Q.2961, Digital subscriber signalling system no.2 (DSS 2) - + additional traffic parameters. Also, Amendment 2 to Q.2961. + + [6] ATMF UNI 4.0 Signaling Specification, af-sig-0061.000. + + + + + +Kumar Informational [Page 45] + +RFC 3441 ATM MGCP Package January 2003 + + + [7] ITU Q. 2965.2, Digital subscriber signalling system no.2 (DSS 2) + - Signalling of individual Quality of Service parameters. + + [8] ATMF Traffic Management Specification, Version 4.1, af-tm- + 0121.000. + + [9] I.356, BISDN ATM layer cell transfer performance. + + [10] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type 2 + AAL, Sept. 1997. + + [11] ITU-T I.366.1, Segmentation and Reassembly Service Specific + Convergence Sublayer for AAL Type 2, June 1998. + + [12] H.323-2, Packet-based multimedia communications systems. + + [13] af-vtoa-0083.000, Voice and Telephony Over ATM to the Desktop. + + [14] Q.2110, B-ISDN ATM adaptation layer - service specific + connection oriented protocol (SSCOP). + + [15] I.365.1,Frame relaying service specific convergence sublayer + (FR-SSCS). + + [16] I.365.2, B-ISDN ATM adaptation layer sublayers: service specific + coordination function to provide the connection oriented network + service. + + [17] I.365.3, B-ISDN ATM adaptation layer sublayers: service specific + coordination function to provide the connection-oriented + transport service. + + [18] Kumar, R. and M. Mostafa, "Conventions for the use of the + Session Description Protocol (SDP) for ATM Bearer Connections", + RFC 3108, May 2001. + + [19] ITU I.371, Traffic Control and Congestion Control in the BISDN. + + [20] ATMF Circuit Emulation Service (CES) Interoperability + Specification, af-vtoa-0078.000. + + [21] af-vmoa-0145.000, Voice and Multimedia over ATM, Loop Emulation + Service using AAL2. + + [22] ITU-T H.222.1, Multimedia multiplex and synchronization for + audiovisual communication in ATM environments. + + + + + +Kumar Informational [Page 46] + +RFC 3441 ATM MGCP Package January 2003 + + + [23] FRF.5, Frame Relay/ATM PVC Network Interworking Implementation + Agreement. + + [24] FRF.8, Frame Relay/ATM PVC Service Interworking Implementation + Agreement. + + [25] FRF.11, Voice over Frame Relay Implementation Agreement. + + [26] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [27] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type 5 + AAL, Aug. 1996. + + [28] I.365.4, B-ISDN ATM adaptation layer sublayers: Service specific + convergence sublayer for HDLC applications. + + [29] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling. + + [30] ITU Q.765.5, Application Transport Mechanism - Bearer + Independent Call Control. + + [31] http://www.3gpp.org/ftp/Specs for specifications related to + 3GPP, including AMR codecs. + + [32] ITU Q.931, Digital Subscriber Signaling System No. 1: Network + Layer. + + [33] ITU Q.763, SS7 - ISUP formats and codes. + + [34] http://www.iana.org/assignments/rtp-parameters + + [35] ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for + Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997. + + [36] Andreasen, F. and B. Foster, "Media Gateway Control Protocol + (MGCP) Version 1.0", RFC 3435, January 2003. + + [37] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [38] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001. + + + + + + + + + +Kumar Informational [Page 47] + +RFC 3441 ATM MGCP Package January 2003 + + +10.0 Acronyms + + AAL ATM Adaptation Layer + ABR Available Bit Rate + ABT/DT ATM Block Transfer/Delayed Transmission + ABT/IT ATM Block Transfer/Immediate Transmission + ATM Asynchronous Transfer Mode + ATMF ATM Forum + BCG Bearer Connection Group + CAS Channel Associated Signaling + CBR Constant Bit Rate + CDV Cell Delay Variation + CDVT Cell Delay Variation Tolerance + CID Channel Identifier + CLR Cell Loss Ratio + CPS Common Part Sublayer + DBR Deterministic Bit Rate + FEC Forward Error Correction + FRF Frame Relay Format + GFR Guaranteed Frame Rate + GWID Gateway Identifier + IP Internet Protocol + ITU International Telecommunications Union + LCO Local Connection Option + MBS Maximum Burst Size + MCR Minimum Cell Rate + MFS Maximum Frame Size + MGCP Media Gateway Control Protocol + nrt-VBR Non-real-time Variable Bit Rate + NSAP Network Service Access Point + PCR Peak Cell Rate + PDU Protocol Data Unit + PVC Permanent Virtual Circuit + 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 + + + +Kumar Informational [Page 48] + +RFC 3441 ATM MGCP Package January 2003 + + + VCCI Virtual Circuit Connection Identifier + VCI Virtual Circuit Identifier + VP Virtual Path + VPCI Virtual Path Connection Identifier + VPI Virtual Path Identifier + +11.0 Acknowledgements + + The author wishes to thank several colleagues at Cisco and the + industry who have contributed towards the development of the MGCP ATM + package, and who have implemented and tested these constructs. + Special thanks are due to Bill Foster, Flemming Andreasen, Raghu + Thirumalai Rajan, Joe Stone, Hisham Abdelhamid, Joseph Swaminathan, + 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. + +12.0 Author's Address + + Rajesh Kumar + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + + Phone: 1-408-527-0811 + EMail: rkumar@cisco.com + + + + + + + + + + + + + + + + + + + + + + + +Kumar Informational [Page 49] + +RFC 3441 ATM MGCP Package January 2003 + + +13.0 Full Copyright Statement + + 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] + |