Media Gateway Control David Barr Internet Draft Nortel Networks Document: draft-barr-megaco-aal2bearer-00.txt June 2002 Category: Informational Media Gateway AAL2 Bearer-Path Establishment Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1 Abstract This document proposes specific procedures that Media Gateways (MGs) shall follow for AAL2 bearer-path establishment under the control of H.248 (Megaco) capable Media Gateway Controllers (MGCs). The procedures cover MGs which use provisioned VCCs and backward call setup mode dynamic SVCs, and which do not use AAL2 signalling (i.e. no Q.2630.x). Although this document refers to the use of the H.248 (Megaco) gateway control protocol, many of the concepts and procedures are not specific to this protocol. 2 Conventions used in this document The following terminology is used: - ATM signalling: Signalling as defined in Q.2931 [1] - Connection: A service-level concept, that allows the transmission of a bidirectional packet media stream between two MGs. For AAL2, a connection is carried within an AAL2 channel. - VCCI: Virtual Channel Connection Identifier, used to identify the end-to-end ATM VCC path. - CID: Channel IDentifier, used to identify an AAL2 channel within a VCC. - Master MG: This MG selects VCCI/CID. Barr Informational - Expires Nov. 2002 1 Media Gateway AAL2 Bearer-Path Establishment June 2002 - Slave MG: This MG uses a VCCI/CID selected by the master MG. The association of being a master or slave is for that connection only, i.e. a MG can be the master for some connections, and the slave for other connections. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3 Introduction Although the H.248 [3] and RFC3108 [4] standards mention the use of AAL2, they do not clearly specify the required messaging or procedures for AAL2 bearer-path establishment between two MGs. To avoid different interpretations creating incompatible solutions, this document proposes specific procedures for use by MGs which use provisioned VCCs and backward call setup mode dynamic SVCs, and which do not use AAL2 signalling (i.e. no Q.2630.x). This document makes no changes to H.248, RFC3108, nor any other standard. It merely attempts to clarify how the standards fit together to ensure interoperability. It is assumed the MG can support either one, or both, of the following classes of VCCs: - Provisioned VCCs: These are already established (typically on MG startup) and are already available when needed by a connection. They can include (but are not restricted to): o PVC: Both MGs are provisioned with the VCCI and the remote peer's ATM address. Each MG associates this information with a local VPI/VCI. o SVC: Both MGs are provisioned with the VCCI and the remote peer's ATM address. One MG is configured to initiate SVC setup to its peer, while the peer MG is configured to terminate it. The SVC would be created on MG startup. - Dynamic SVCs: These are created as needed between MGs. This document does not cover the case where there is a pool of VPI/VCIs for dynamic PVC allocation. VCC operations (creation, deletion, assignment of connections, etc.) is done by MGs and is transparent to the MGC. I.e. the MGC does not send explicit messages to establish ATM VCCs. The MGC only needs to create ephemeral terminations at both MGs in order to create a connection between them. For a given VCC between two MGs, connections can be assigned by either party, regardless of which party originated the setup of the VCC. 4 Basic Control Flow Barr Informational - Expires Nov. 2002 2 Media Gateway AAL2 Bearer-Path Establishment June 2002 The basic control flow is independent of whether the VCC is provisioned or dynamically created. The following description shows the SDP exchange using the Local and Remote descriptors as sent in H.248 commands/replies applied on the ephemeral (AAL2) terminations of the two MGs: MG1 (slave) and MG2 (master). The purpose of the SDP exchange between MG1 and MG2 is: - to determine a VCC, with sufficient bandwidth available, for the connection. The VCC is identified by VCCI. If there is inadequate bandwidth on existing VCCs between the two MGs, then a new VCC may be created. - to select an AAL2 channel within the VCC. The CID identifies the channel. - to agree on ONE common AAL2 profile. An AAL2 profile may include multiple codecs, however an AAL2 channel can only use one profile. Note: the detailed procedures for AAL2 profile negotiation, and the selection of the preferred codec within the profile, is beyond the scope of this document. It is assumed the reader is familiar with RFC-3108. In particular, the following media information line format is used: m= ... = / = VCCI- = CID- The control flow is as follows: 1) Add from MGC to MG1 Local{ v=0 c=ATM $ $ m=audio $ $ $ } The MGC sends MG1 a request to create an ephemeral termination. MG1 is requested to return the ATM addressType, ATM address, VCCI/CID, and AAL2 profiles that it supports. 2) Add reply from MG1 to MGC Local{ v=0 c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 m=audio - AAL2/ITU 7 2 1 } Barr Informational - Expires Nov. 2002 3 Media Gateway AAL2 Bearer-Path Establishment June 2002 The Add reply from MG1 includes MG1's ATM address, and the AAL2 profiles that it supports. Since MG1 does not know which peer MG will be used, it cannot return VCCI nor CID. Therefore it uses "-" in the VCCI/CID field. 3) Add from MGC to MG2 Local{ v=0 c=ATM $ $ m=audio $ $ $ }, Remote{ v=0 c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 m=audio - AAL2/ITU 7 2 1 } The MGC sends MG2 a request to create an ephemeral termination. The details of MG1 are sent in the Remote descriptor. 4) Add reply from MG2 to MGC Local{ v=0 c=ATM NSAP 47.0072.8100.0000.0060.3e64.fd01.0060.3e64.3301.00 m=audio VCCI-2/CID-13 AAL2/ITU 2 } The Add reply from MG2 includes MG2's ATM address. Since MG2 knows the identity of the peer MG, it is able to select an appropriate VCC to use (identified by VCCI) and a channel within that VCC (identified by CID.) In addition, MG2 MUST select only one AAL2 profile from the list provided by MG1. How this VCCI and CID is selected will be discussed in section 6. If a provisioned VCC or a previously created dynamic SVC is selected, the bearer-path is ready for use. If a new dynamic SVC is required, then MG2 will initiate the required ATM signalling (this is explained in more detail in section 5). 5) Modify from MGC to MG1 Remote{ v=0 c=ATM NSAP 47.0072.8100.0000.0060.3e64.fd01.0060.3e64.3301.00 m=audio VCCI-2/CID-13 AAL2/ITU 2 } The MGC sends MG1 a Modify to inform it of the remote MG ATM address, and the selected VCCI/CID and AAL2 profile. 6) Modify reply from MG1 to MGC Barr Informational - Expires Nov. 2002 4 Media Gateway AAL2 Bearer-Path Establishment June 2002 MG1 acknowledges the command from the MGC, but does not send a Local nor Remote descriptor. 5 Dynamic SVC Setup A MG MAY support dynamic SVC creation in order to create extra bandwidth between itself and a peer. In the control flow shown in section 4, the master MG was requested to choose a VCC on which to carry the connection. If there was not sufficient bandwidth remaining on existing VCCs, the master MG could decide that a new dynamic SVC needs to be created, and it would send an ATM SETUP message to the slave MG. Once the SVC is established it can be used for multiple connections, each using its own CID. Subsequent connections between the same MGs do not require a SVC setup as long as sufficient bandwidth is available. Both MGs may assign connections to the new VCC. Whether an existing VCC is usable for a connection can be determined by a voice connection admission control algorithm based on the projected bandwidth for the connection versus the available VCC bandwidth and/or the number of available CIDs. Although SVC creation is triggered by a connection request from the MGC, once initiated the lifecycle of the SVC is independent from the connection that initiated it. The SVC may well survive well beyond the connection that initiated it, if it is used for other connections. 5.1 Delayed or Immediate Reply There are two implementation options regarding how a MG replies to control commands: the reply can be either delayed or immediate. A MG SHOULD only use one method, although provisioning can be used to select which method for MGs that support both methods. Networks containing both delayed reply and immediate reply MGs are possible. In control flow step (3) of section 4, the master MG has two implementation options on how it can progress the control flow: 1. Delayed reply: In this method, the MG does not allocate the connection to a VCC until bandwidth is available on an active VCC. This could be either when the SVC setup is completed (i.e. an ATM CONNECT is received back from the slave), or earlier if bandwidth becomes available on an existing VCC following an unrelated connection deletion on that VCC. I.e. the connection that initiated the SVC may in fact be allocated to a different VCC. The MG does not acknowledge the Add command until the connection is allocated to an active VCC. 2. Immediate reply: In this method, the MG immediately allocates the connection to the dynamic SVC that is being created. The MG is Barr Informational - Expires Nov. 2002 5 Media Gateway AAL2 Bearer-Path Establishment June 2002 therefore able to immediately acknowledge the Add command, even though the SVC setup may not have been completed yet. In control flow step (5) of section 4, the slave MG is requested to accept the chosen VCCI/CID. The slave MG will act differently depending on which implementation option it uses: 1. Delayed reply: The MG does not acknowledge the Modify command until the specified VCC becomes available, e.g. the slave MG receives the appropriate ATM SETUP message. The MG MUST NOT immediately reject the Modify if the VCC does not exist, because the master MG may be using the immediate reply method. 2. Immediate reply: The MG immediately acknowledges the Modify command, even if the specified VCC is not available yet. 5.2 SVC Setup Failure On sending the ATM SETUP message, the MG will start a timer for that SVC. If an ATM CONNECT message has not been received before the timer expires, then the following procedures will be followed, depending on implementation: 1. Delayed reply implementation: The MG will reply to the Add commands with an error for each termination (i.e. connection) waiting for the SVC to complete. 2. Immediate reply implementation: The MG will send an aal2/netfail event (as defined in the H.248 Network package and section 8.1) with an appropriate optional cause string for each termination (i.e. connection) waiting for the SVC to complete. This implies that the MGC MUST request the aal2/netfail event. If the SVC completes following a time-out it will be placed in the bandwidth pool and may be used for subsequent connections or may be timed out (explained in section 5.5) if it remains unused. On receiving a VCCI (in the Modify message) that does not currently exist, the slave MG will start a timer for that termination. If an ATM SETUP message has not been received for that VCCI before the timer expires, then the following procedures will be followed, depending on implementation: 1. Delayed reply implementation: The MG will reply to the Modify with an error. 2. Immediate reply implementation: The MG will send an aal2/netfail event (as defined in the H.248 Network package and section 8.1) with an appropriate optional cause string for the termination. This implies that the MGC MUST request the aal2/netfail event. 5.3 Bearer-path Connection Available Barr Informational - Expires Nov. 2002 6 Media Gateway AAL2 Bearer-Path Establishment June 2002 Since MGs may implement the immediate reply method, it is possible for the service-level connection to be established before the bearer-path has been established. With some configurations, it MAY be desirable for the MGC to be notified when the bearer-path is available for each termination so that it can manage the control flow appropriately. This can be achieved by the MGC requesting the aal2/sc event (as defined in section 8.1) on the termination when it is Added. This event indicates to the MGC that a termination has an established bearer-path on which to communicate. It is recommended that if the bearer-path is immediately available (e.g. when using provisioned VCCs, or reusing a previously established dynamic SVC) then the Notify should be returned in the same message as the Add/Modify acknowledgement. This is to minimise the amount of messaging. A SVC-originating MG will wait for the ATM CONNECT message to be received before reporting aal2/sc for all appropriate terminations. A SVC-terminating MG will wait for the ATM SETUP message to be received before reporting aal2/sc for all appropriate terminations. 5.4 Pre-creation In addition to setting up SVCs when there is not sufficient bandwidth available for a connection, a MG MAY optionally set up SVCs when it only has bandwidth left for a limited number of connections (typically 1) to a remote MG. This is termed pre- creation of SVCs and can be used to reduce average connection setup latency, especially if the delayed reply method is being used. SVC pre-creation reduces connection setup latency by causing SVCs to be created before they are needed. This means that most connections do not incur the latency associated with a SVC setup. For example, in trunk tandem networks, where there are multiple VCCs between most MGs, this will reduce the number of connections that incur a SVC setup delay to a small fraction of the total connections. The only connections to incur the SVC delay are those between MGs that do not yet have a VCC. It is not always appropriate to use pre-creation. For example, if there were a large number of MGs (e.g. line MGs), then it would not be efficient for the network to reserve a large amount of bandwidth for pre-created VCCs. 5.5 SVC Deletion SVCs are deleted when they are no longer required, to conserve allocated bandwidth in the ATM network. A SVC is deemed to be no longer required when it has been empty for a provisionable period of time: defined as the SVC persistence. Increasing this time has the benefit of improving average connection latency, and reducing Barr Informational - Expires Nov. 2002 7 Media Gateway AAL2 Bearer-Path Establishment June 2002 overall SVC setup rate, but also has the negative effect of reducing network bandwidth efficiency. Under normal circumstances only the end which created the SVC will delete it when the persistence timer expires. However for network robustness, the SVC-terminating MG MAY release a SVC if deemed appropriate, e.g. after a long timeout that exceeds the persistence timer. Therefore a SVC-originating MG MUST honour SVC release by the SVC-terminating MG. Although the SVC-originating MG will recreate a SVC due to network failure, etc., it MUST NOT try to recreate a SVC explicitly released by the SVC-terminating MG. In order to avoid the SVC-terminating MG assigning a connection to a VCC which is about to be cleared by the SVC-originating MG, the SVC- terminating MG will always run a SVC persistence timer which is less than the provisioned value used for originated SVCs. Once this shorter persistence timer has expired for a terminated VCC, the SVC- terminating MG will mark the SVC as unavailable to trunk selection. A persistence timer difference of 5 seconds is appropriate as it allows adequate time for the SVC-terminating MG (acting as the master) to inform the SVC-originating MG (acting as the slave) of the selected VCCI, using SDP via the MGC, before the SVC-originating MG persistence timer expires. If the SVC persistence timer is set to less than 5 seconds, then the shorter persistence timer will expire immediately when a terminated SVC is empty, and therefore empty terminated SVCs will not be available for allocation of connections by the SVC-terminating MG. 5.6 ATM SETUP Message MGs which create dynamic SVCs MUST implement the appropriate functionality (e.g. UNI4.0) to carry the VCCI within the Generic Identifier Transport (GIT) Information Element (IE) as defined in Q.2941.2 [5]. 6 Selecting VCCs and Channels 6.1 Channel Assignment Rules Channels are assigned to VCCs as follows: 1st: assign to any provisioned VCCs if capacity available. 2nd: assign to the fullest SVC. Within a set of equally full SVCs assign as follows: 1st: to your originated SVCs starting at the highest VCCI. 2nd: to terminated SVCs starting at the lowest VCCI. 3rd: if no capacity is available, set up a new SVC. Note that this is optimized to allow VCCs to be emptied out over time so that they can be deleted during periods of low usage. There is a remote possibility of a SVC being over allocated by one channel if both ends allocate the last channel at the same time. This can result in more channels being allocated to the VCC than the Barr Informational - Expires Nov. 2002 8 Media Gateway AAL2 Bearer-Path Establishment June 2002 provisioned maximum allowed number. In this case the MG will allow the extra channel, so as to not lose the connection. In general the incidence of over allocation is expected to be so small as to not affect the performance of the network. If the ATM network performs policing of voice traffic VCCs it may be necessary to provision the PCR & SCR of the VCCs to accommodate an extra channel to avoid traffic loss on over allocation. In general, however, it is strongly recommended that policing is not performed on voice SVCs since these are generally well behaved traffic sources. 6.2 VCCI Selection Provisioned VCCs and dynamic SVCs SHOULD have mutually exclusive VCCI ranges. The VCCI is a 14-bit number. Provisioned VCCs are in the range of 0 to 4095 and dynamic SVCs are in the range 4096 to 8191. The most significant (MSb) bit of the 14-bit word is used to indicate the SVC-originating end as explained below. Two MGs avoid simultaneously selecting the same VCCI ("VCCI glare") by using the Q.2941.2 [5] appendix II.1 and af-vtoa-0113.000 [6] annex C.2.5 specified technique to identify whether it is locally or remotely generated using the MSb of the 14-bit VCCI. The MSb is always set to 0 on the SVC-originating MG and 1 on the SVC- terminating MG. It works as follows: - If creating a new dynamic SVC, the SVC-originating MG will send VCCI with MSb=0 in the ATM SETUP. - When the SVC-terminating MG receives the SVC SETUP, it will store the VCCI with MSb=1. The two MGs refer to the VCC using different VCCIs, i.e. the MSb is different. - When a master MG decides to use a dynamic SVC (whether it was previously created or is newly created), it will return a VCCI (in the Add response) with the VCCI MSb inverted. Note: The 14-bit VCCI value is packed into a 16-bit field of the GIT IE in a special way. Refer to Q.2941.2 appendix II.1 and af-vtoa- 0113.000 annex C.2.5 for details. Example: 1. CONNECTION 1: MG2 is the master and needs to select a VCC to MG1. Since there is inadequate bandwidth on existing VCCs, MG2 creates a new SVC to MG1. MG2 identifies the VCC with VCCI=5000 (0x1388). The identifier sent in the ATM SETUP GIT IE is: 0x08 0x08 0x02 0x27 0x88 (see Q.2941.2 appendix II.1) 2. MG1 receives the ATM SETUP message. It extracts the 14-bit VCCI from the GIT IE, and sets the MSb to 1. I.e. MG1 identifies the new VCC as VCCI=13192 (0x3388). 3. MG2 assigns the connection to the new VCCI. It responds with VCCI=13192 (MSb is inverted) in the "m=" line of its Local descriptor SDP. The MGC will forward this VCCI to MG1 in the Remote descriptor SDP. Barr Informational - Expires Nov. 2002 9 Media Gateway AAL2 Bearer-Path Establishment June 2002 4. When MG1 receives the VCCI in the Remote descriptor SDP, it knows to assign the connection to the newly established VCC, with VCCI=13192. 5. CONNECTION 2: MG1 is now the master for an unrelated connection, and needs to select a VCC to MG2. It decides to use the SVC created by MG2 in step 1. MG1 identifies this VCC as VCCI=13192. It responses with VCCI=5000 (MSb is inverted) in the "m=" line of its Local descriptor SDP. The MGC will forward this VCCI to MG2 in the Remote descriptor SDP. 6. When MG2 receives the VCCI in the Remote descriptor SDP, it knows to assign the connection to the previously established VCC, with VCCI=5000. 6.3 CID Selection It is possible that two MGs may allocate CIDs to a particular VCC at exactly the same time for unrelated connections. The two MGs avoid selecting the same CID ("CID glare") by having the master MG compare its ATM address with the peer MG's ATM address. The higher address assigns CID values from the top down (from 255), while the lower address assigns from the bottom up (from 9). 7 Security Considerations If dynamic SVCs are used, there is the possibility that attackers may attempt a denial of service (DoS) attack by establishing many SVCs with a MG, thereby using up resources. This section describes a simple OPTIONAL security mechanism to authenticate the SVC setup, thereby minimising DoS attacks. If this mechanism is employed, then all MGs in the network will need to implement it. With this mechanism, the SVC-terminating MG authenticates the SVC setup using a one-time password (OTP) embedded in the ATM SETUP message from the SVC-originating MG. The OTP was previously passed from the SVC-terminating MG to the SVC-originating MG via the H.248 control protocol. This example control flow shows how it works: A) Add from MGC to MG1 (slave) B) Add reply from MG1 to MGC containing a MG1-generated OTP in the Local descriptor SDP. MG1 adds this OTP to its list of pending OTPs, and starts an expiry timer for the OTP. C) Add from MGC to MG2 (master). The Local descriptor SDP (including OTP) from MG1 is forwarded to MG2 in the Remote descriptor. D) If MG2 needs to establish a dynamic SVC (either for the current connection, or for pre-creation) then it sends the OTP (from step-C) in the ATM SETUP message. If it does not need to create a dynamic SVC, then the OTP is discarded. E) When MG1 receives an ATM SETUP message, it checks the OTP in the message against its list of pending OTPs. If there is a match, the Barr Informational - Expires Nov. 2002 10 Media Gateway AAL2 Bearer-Path Establishment June 2002 SVC setup is accepted and the OTP is taken off the pending list. If there is not a match, then the SVC setup is rejected. F) The rest of the flow continues as normal. An OTP generated by the slave MG MUST be random and not equal to any pending OTPs. The OTP MUST be a true random number, and not one that can be predicted (i.e. not pseudo-random). An OTP is removed from the pending list if: - the MG receives an ATM SETUP with that OTP; or - a timer expires. The timer should be long enough to easily allow the peer MG time to receive the OTP (in the SDP) and then send the OTP (in the ATM SETUP). Note, an OTP will need to be sent by the slave MG with every reply to an Add, regardless of what type of VCC (provisioned or dynamic SVC) is subsequently used. The generic description above does not explain how the OTP is carried. The proposed method of carrying the OTP is by using fields reserved for EECID. The a=eecid: line of the SDP (RFC3108) is used to carry the OTP from the slave MG to the master MG, via the MGC. Example: v=0 c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 m=audio - AAL2/ITU 7 2 1 a=eecid:A24F553E If required to setup a new SVC, the master MG then forwards the OTP in the ATM SETUP EECID field of the GIT IE. The EECID is NOT being used as an end-to-end connection identifier - VCCI is used for this purpose. The use of EECID is a convenient way to represent the OTP because there are fields defined for it in existing standards. The EECID is 32-bits in length. This gives an attacker a chance in 4000-million of guessing a correct EECID. The attacker has to guess the correct number while the EECID is in the pending list. Since this security mechanism uses H.248 to carry OTPs, the H.248 protocol needs to be secured to prevent the attacker from determining the OTPs by snooping the control protocol. This security may be achieved by suitable network configuration, or by the use of IPSec encryption. Although one may think of a mechanism to use EECID for both an end- to-end connection identifier AND an OTP, keeping the functionality separate has the following advantages: 1. VCCI is well defined for AAL2 in standards Q.2941.2 and af- vtoa-0113.000. Barr Informational - Expires Nov. 2002 11 Media Gateway AAL2 Bearer-Path Establishment June 2002 2. It is useful to separate the main protocol (i.e. using VCCI) from the security protocol (e.g. using EECID for OTP.) This allows its use to be optional, or for it to be replaced if a vulnerability (or better solution) is found without needing to redefine the whole protocol. Note: the mechanism described in this section cannot prevent DoS attacks due to flooding of the signalling channel. 8 Packages 8.1 AAL2 Package PackageID: aal2 Version: 1 Extends: Network package version 1 Termination-types supporting this package: AAL2. 8.1.1 Properties None. 8.1.2 Events Set-up complete (Bearer-path connection available) EventID: sc Detects whether the termination has a bearer-path connection available for it to use. EventsDescriptor parameters: none. ObservedEventsDescriptor parameters: none. 8.1.3 Signals None. 8.1.4 Statistics Packets Sent StatisticID: ps Number of AAL2 packets sent. Type: double Possible values: any 32-bit integer Packets Received StatisticID: pr Number of AAL2 packets received. Type: double Possible values: any 32-bit integer Connection Type StatisticID: ct Type: enumeration Barr Informational - Expires Nov. 2002 12 Media Gateway AAL2 Bearer-Path Establishment June 2002 Possible values: CCD64K, CCD56K, Voice, VBD, Fax, Modem Buffer Underflows StatisticID: bu Number of times the de-jitter buffer has underflowed Type: double Possible values: any 32-bit integer Buffer Overflows StatisticID: bo Number of times the de-jitter buffer has overflowed Type: double Possible values: any 32-bit integer Total Packets Lost StatisticID: tpl Number of packets expected but not received. Type: double Possible values: any 32-bit integer Packets Discarded StatisticID: pd Number of packets discarded (implementation-specific.) Type: double Possible values: any 32-bit integer 8.1.5 Procedures If the MGC needs to know when a termination has a bearer-path connection available (e.g. for managing the control flow), it can request the MG to detect the aal2/sc event. 9 References 1 ITU-T Recommendation Q.2931, B-ISDN - DSS 2 - UNI Layer 3 specification for Basic Call/Connection Control 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 ITU-T Recommendation H.248, Gateway Control Protocol, 06/2000. ALSO: RFC-3015, "Megaco Protocol Version 1.0", November 2000, The Internet Society. 4 RFC-3108, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", May 2001, The Internet Society. 5 ITU-T Recommendation Q.2941.2, B-ISDN - DSS 2 - Generic Identifiers Transport Extensions, 12/1999. 6 AF-VTOA-0113.000, "ATM Trunking using AAL2 for Narrowband Services", The ATM Forum, Technical Committee, February 1999. 10 Acknowledgments Concepts and procedures in this document were derived from work by the following people (in alphabetical order): David Barr, Jean- Pierre Caron, Yolande Cates, Berry Credle, Ismail Dahel, Graeme Gibbs, and Rade Gvozdanovic. 11 Author's Address Barr Informational - Expires Nov. 2002 13 Media Gateway AAL2 Bearer-Path Establishment May 2002 David Barr Nortel Networks London Road Harlow, Essex, CM17 9NA United Kingdom Email: David.Barr@nortelnetworks.com Barr Informational - Expires Nov. 2002 14 Media Gateway AAL2 Bearer-Path Establishment May 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). 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." 12 Expiration Date This memo is filed as , and expires November 21, 2002. Barr Informational - Expires Nov. 2002 15