RFC 3441
Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)
Pages: 50
Informational
Informational
Part 2 of 2 – Pages 19 to 50
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 | | +---------+---------------+---------------------------------------+
+---------+---------------+---------------------------------------+ | 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 | | +---------+---------------+---------------------------------------+
ATM transfer capability (atc): This parameter indicates the ATM Transfer Capability described in ITU I.371 [19], equivalent to the ATM Service Category described in the UNI 4.1 Traffic Management specification [8]. In applications conforming to ITU I.371, this parameter can be assigned the following values: DBR, SBR, ABT/IT, ABT/DT, ABR. In applications conforming to the UNI 4.1 Traffic Management specification, this parameter can be assigned the following values: CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR. Subtype (sbt): This qualifies the atc local connection option. It can be assigned integer values of 1...5. The following combinations of the atc and sbt local connection options are meaningful: atc sbt Resulting transport CBR/DBR 1 Voiceband signal transport (ITU G.711, G.722, I.363) CBR/DBR 2 Circuit transport (ITU I.363) CBR/DBR 4 High-quality audio signal transport (ITU I.363) CBR/DBR 5 Video signal transport (ITU I.363) nrt-VBR 1 nrt-VBR.1 nrt-VBR 2 nrt-VBR.2 nrt-VBR 3 nrt-VBR.3 rt-VBR 1 rt-VBR.1 rt-VBR 2 rt-VBR.2 rt-VBR 3 rt-VBR.3 UBR 1 UBR.1 UBR 2 UBR.2 GFR 1 GFR.1 GFR 2 GRR.2 SBR 1 SBR1 SBR 2 SBR2 SBR 3 SBR3 Subtypes for the atc values of CBR or DBR are per [29]. Subtypes for the remaining atc values are per [8] and [19].
QoS class (qos): This indicates the QoS class specified in ITU I.2965.1 [4]. It can take on the integer decimal values in the range 0 - 5. These values are mapped into QoS classes as follows: ---------------------------------------------------------- | VALUE | MEANING | ---------------------------------------------------------- | 0 | Default QoS | ---------------------------------------------------------- | 1 | Stringent | ---------------------------------------------------------- | 2 | Tolerant | ---------------------------------------------------------- | 3 | Bi-level | ---------------------------------------------------------- | 4 | Unbounded | ---------------------------------------------------------- | 5 | Stringent bi-level | ---------------------------------------------------------- Broadband Connection-Oriented Bearer Class (bcob): The bcob local connection option indicates the Broadband Connection-Oriented Bearer Class specified in ITU Q.2961.2 [5]. It is represented as a decimal number in the range 0 - 31, or its hex equivalent (range 0x0 - 0x1F). The following values are currently defined: ---------------------------------------------------------- | VALUE | MEANING | ---------------------------------------------------------- | 1 | BCOB-A | ---------------------------------------------------------- | 3 | BCOB-C | ---------------------------------------------------------- | 5 | Frame relaying bearer service | ---------------------------------------------------------- | 16 | BCOB-X | ---------------------------------------------------------- | 24 | BCOB-VP (transparent VP service) | ---------------------------------------------------------- End-to-end timing (eetim): This indicates whether end-to-end timing is required (Table 4-8 of [29]). It can be assigned a value of "on" or "off".
Susceptibility to clipping (stc): The stc local connection option
indicates susceptibility to clipping. It is represented as a decimal
number in the range 0 - 3, or its hex equivalent (range 0x0 - 0x3).
All values except those listed below are reserved.
----------------------------------------------------------
| VALUE | MEANING |
----------------------------------------------------------
| 0 | Not susceptible to clipping |
----------------------------------------------------------
| 1 | Susceptible to clipping |
----------------------------------------------------------
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].
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.
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].
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 "-".
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 | | +---------+---------------+---------------------------------------+
+---------+---------------+---------------------------------------+ | 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 | | +---------+---------------+---------------------------------------+
+---------+---------------+---------------------------------------+ |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].
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
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 # | | | | |---------------|-----------------------|-----|------|--------------|
|---------------|-----------------------|-----|------|--------------|
| 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.
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.
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.
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
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
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
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.
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.
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
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
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
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
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
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.
[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.
[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.
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
VCCI Virtual Circuit Connection Identifier VCI Virtual Circuit Identifier VP Virtual Path VPCI Virtual Path Connection Identifier VPI Virtual Path Identifier11.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
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.