Internet Engineering Task Force Sophia Scoggins INTERNET DRAFT Michael Brown Nortel Networks Oct. 22, 1999 Megaco ATM MG Implementation Considerations Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. In compliance with Section 10.3.1.6 of RFC 2026, the contributor has personal knowledge that Nortel Networks Corporation and/or one of its subsidiaries ("Nortel Networks") has intellectual property rights embodied in this contribution. Specifically, Nortel Networks has applied for and/or has the following U.S. patent(s) and foreign equivalent(s) relating to inventions disclosed in this contribution: U.S. Patent Filing Date: August 23, 1999 U.S. Patent Application No: 60/150,271 Title: Improved Packet Media Gateway The contributor does not represent that he or she personally knows of all potentially pertinent proprietary and intellectual property rights owned or claimed by Nortel Networks (if any) or third parties. In the event any part of this contribution is included in an Internet Standard approved by Nortel Networks, Nortel Networks agrees to license any of its intellectual property rights embodied in such included part to any party implementing the Internet Standard upon reasonable, non-discriminatory terms on a reciprocal basis. In this context, "reciprocal basis" means that the licensee must be willing to license any of its intellectual property rights essential to the implementation of the Internet Standard to Nortel Networks and its subsidiaries upon reasonable, non-discriminatory terms. Any party wishing such a license should write to: Nortel Networks Corporation Intellectual Property Law Group IP Licensing & Transactions Mail Stop 036NO151 Suite 100 8200 Dixie Road Brampton, Ontario Canada L6T 5P6 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This document proposes mechanisms needed to address issues associated with connection oriented packet networks such as an ATM network or an IP network which use some form of network path reservation. These issues are to: - allow for determination of which Media Gateway (MG) should initiate the creation of the network connection path and correlation of the network connection path between MGs, - allow for a wait state while an end-to-end network path between MGs is being established to effect the ADD of an connection oriented ephemeral termination, for example, UNI/PNNI setup of an ATM SVC, - allow for recognition and generation of events and signals to support access/use of a connection oriented packet based network. First, this document contains a proposal for use of a unique identifier to be passed between the two MGs that allows for correlation of a network path with a specific request or call attempt. Second, this document describes several alternatives to address the setup and teardown of a connection oriented packet network path, that provides the necessary wait state during path setup. Examples of the alternatives are provided to illustrate the associated pros and cons of each approach. Although there is a recommendation among the alternatives to reduce the number of possible implementations and associated inter- operability issues, it should be noted that this section is intended to stimulate discussion on the use of these mechanisms which could include the use of both. Third, this document contains a description of the events and signals specific to connection oriented packet networks and proposes an event/ signal package to be used in the Megaco/H.248 protocol [1]. It does not address the properties or statistics portions of a package definition. This area is open for future study. To illustrate the issues and the proposed solutions, this draft uses examples of two types of packet network architectures, the VTOA packet network architecture and the XDSL packet network architecture, which are described in section 2. Section 3 details the use of an End-to-End Call Identifier (EECID) to allow for correlation of the termination points of a packet network path between two MGs. This section includes discussion of the various EECID formats have been proposed by different standards bodies such as T1S1 and ATM Forum. These proposals suggest the use of possible fields and values in different protocols such as SIP+ or ISUP+ to pass this information back and forth across the packet network, but do not address the mechanism for the Megaco/H.248 protocol to communicate the EECID between the MG and it's MGC. This section proposes such a mechanism using the Megaco/H.248 termination descriptor. This document proposes a simple generic packet pipe event/signal package, called PacketPipe, in section 4. This proposal describes two mechanisms to inform the MG to initiate the creation of the network path to uniquely identify and allow correlation the termination points of a packet network path. The mechanisms are 1.) the explicit use of signals and events to establish the network path and 2.) implicit use of the Megaco/H.248 ADD command with provisioning wait state 'Transaction Pending' and followed with a completion 'Transaction Reply'. This proposal is based on the assumption that the type of underlying packet network should be transparent to the Media Gateway Controller. Examples of the possible and recommended use of the PacketPipe Event/ Signal Package and EECID are given in section 5. Example syntax for an ATM termination descriptor in SDP is shown in section 6. Section 7 provides a summary of the recommendations in this proposal. 2. Example Packet Network Architecture The following diagrams show examples of the packet network architectures to be supported by this proposal. Note that while there is significant background discussion of the mechanisms between the MGCs, the focus of this proposal is to address the mechanisms required in Megaco/H.248. 2.1. VToA MG Network Architecture Proprietary/ +--------+ ISUP+/SIP +--------+ | MGC |--------------| MGC | +--------+ +--------+ | | |Megaco |Megaco | | +--------+ ATM +--------+ +--------+TDM|--+ +--| Network |--+ +--|TDM+--------+ |Terminal|---|TT|--|AT|--------------|AT|--|TT|---|Terminal| +--------+ |--+ +--| |--+ +--| +--------+ |VTOA MG | |VTOA MG | +--------+ +--------+ TT (TDM Termination): a logical representation of a phone AT (ATM Termination): a logical representation of an ATM port 2.2. XDSL MG Packet Network Architecture Proprietary/ +---------+ ISUP+/SIP +---------+ | MGC |------------------| MGC | +---------+ +---------+ | | |Megaco |Megaco | | +----------------+ ATM +----------------+ +--------+ |XDSL +--+ +---| Network |---+ +--+ XDSL| +--------+ |Terminal|--|-X----|TT|--|ANT|----------|ANT|--|TT|----X-|--|Terminal| +--------+ | |TDM |--+ +---| |---+ +--|TDM | | +--------+ | | | | | | | | | | | |---+ | | | | +---| | | | +----|AUT|---+ | | +---|AUT|----+ | | ATM +---+ | | +---+ ATM | | | | | | XDSL MG | | XDSL MG | +----------------+ +----------------+ 'X' is where the voice and data split. The splitter can be inside or outside of the XDSL MG. AUT (ATM User Termination) ANT (ATM Network Termination) After the XDSL voice and data split, the voice is treated the same as any other plain telephone call. The voice call is logically represented by a TT. Meanwhile, the ATM data will be entering an ATM cell processing box, which is logically represented by an AUT. The communication between the AUT and ANT would be a cell bus, or frame bus, or any other data links. 3. End-to-End Call Identifier (EECID) 3.1. The Definition of an EECID When a call is made, it may go through several different telecommunica- tions switching offices and/or packet networks to form a complete network path as shown in the following diagrams. Scenario 1 - TDM Network Call +------+ +-------+ +------+ +------+ | End |bearer| Toll |bearer| End | +------+ |caller|--|Office|------|Office |------|Office|--|Callee| +------+ | A | | | | B | +------+ +------+ +-------+ +------+ | | | signaling (ISUP) | +----------------------------+ |<--first call-->|<----second call---->|<--third call-->| |<--leg -->|<----leg ---->|<--leg -->| Scenario 2 - TDM to Packet to TDM Network Call +------+ +-------+ +------+ +------+ |Switch|bearer|Packet |bearer|Switch| +------+ |caller|--|Office|------|Network|------|Office|--|Callee| +------+ | A | | A | | B | +------+ +------+ +-------+ +------+ | | | signaling (ISUP+ or SIP+) | +----------------------------+ |<--first call-->|<----second call---->|<--third call-->| |<--leg -->|<----leg ---->|<--leg -->| Note that the existence of an MGC and an associated TDM to Packet MG is implied between each of the TDM switching offices and the Packet Network. When a call involves a connection oriented packet network as shown in scenario 2, it is necessary to have a means to uniquely identify the two endpoints of packet bearer path to allow proper correlation of the path, the call leg, with a specific network path request or call attempt. An End-to-End Call Identifier (EECID) can be used to identify a call leg. In the above examples, each call involves three call legs. Each of these call legs has its own EECID. Each call leg may actually go through more than one network node to complete the network path. For example, in an ATM network, there are likely to be many virtual circuits (VCs), one between each ATM switch, to complete a call leg within the packet network. The EECID is used to identify this call leg uniquely end-to-end across a packet network type, regardless of number of nodes used in completing the network path. The EECID can be generated either by the MGC or by the MG. This choice makes a difference in the messaging call flows between the MGC and MG. The kep decision point is what can the MGC and MG do with the EECID upon the EECID is generated. According to the T1S1 and ATM Forum, an EECID equivalent identifier can be generated by either the MGC or by the MG as long as it is unique in an autonomous system. The primary requirement of the EECID is that it must be unique at a minimum within the context of the MG, which provides access into the packet network and will be originating the request to establish the path. This is required to ensure accurate correlation of the network path between the MGs for a specific call attempt. It is also desirable that this value be only as large as needed to guarantee the uniqueness required to reduce transmission bandwidth and processing time for correlation of the network path. 3.2. EECID Formats Depending on the type of underlying networks and/or protocols, the EECID can be carried across the network in various ways. The following describes proposals brought forward by various standards bodies and industry forums based on the focus of those groups. Note that this discussion, which is not intended to be exhaustive, is informational only. Specifying the format of the EECID and the means by which it is carried across the packet network is outside the scope of this proposal. 3.2.1. EECID within an ATM UNI signaling system There are three possible fields where the EECID could be transported for an ATM UNI Signaling System. (1) One option is to place the EECID in the Generic Transport Information Element (GTIE) field. This field is currently recommended by the ATM Forum WG. This is also the field that we recommend to us. (2) Another possible place for the EECID is in the ATM sub-addressing field, even though the sub-addressing field usually has only local significance/uniqueness. (3) Another possible place for the EECID is the ATM Address user part. The ATM network routing only uses the first 13-byte network prefix of the ATM AESA address. The following 7 bytes of the user part could contain the EECID. This method is not desirable as the most significant 19 bytes of the ATM address need to be registered with ILMI. We don't want to register every call with ILMI. 3.2.2. ISUP+/BICC The ITU SG recommended putting the call-related information in the Application Transport Mechanism (ATM) field of the ISUP+ protocol. 3.2.3. SIP/SIP+ The EECID can be carried as a term in the SDP defined and used by this protocol. Section 6 shows a suggested syntax in SDP for the EECID. 3.3. The Possible Value of an EECID An EECID can be any arbitrary number, which meets the requirement of uniqueness previously described to allow correlation of the end-to-end network path between two MGs. As with the format of the EECID for transport across the network, several standard groups have identified different parameters for different networks that could be used as an EECID. Note that choice of the value for the EECID has implications on the call flow. In some cases, the proposed value can only be derived by the network. In addition, this proposal recommends that the value of an EECID does not need to be and should not be dependent on the underlying packet network. The recommendation of this proposal is to use the T1S1 Backward Network Connection Identifier (BNC-ID), which meets the requirements of uniqueness and minimal size described above. The following sections provide brief descriptions of some of the proposed values to be used as an EECID. 3.3.1. PNNI Network Call Correlation Identifier (NCCI) The NCCI [3] is used to uniquely identify a call. Currently only one connection can exist per call, therefore the NCCI can also be used to uniquely identify the connection associated with this call. While this is true, the use of the NCCI is undesirable from two perspectives. First, the NCCI can not be generated by the MGC for the MG since it is an identifier based on the setup by the actual network path to be used as the bearer path. In addition, the NCCI is a 28-byte field which is unnecessarily large for the purpose of EECID. Another limitation with NCCI is that it can only be used in an ATM PNNI network. 3.3.2. MSF SessionID In reference [4] the MGC chooses a session ID and passes it to the MG. The MG then passes the session ID along with the UNI SETUP message as an EECID. This session ID is also passed through an ISUP+ message to the remote MGC. This is done in both forward and backward UNI setup. Reference [4] didn't mention where the session ID can be in either an ISUP+ message or an ATM SETUP message. This session ID cannot be chosen by the MG and passed back to the MGC. 3.3.3. ATM Forum CALLID and BNC-ID A call ID (CID) is used in an ATM Forum contribution [5] as an EECID. Similar to the MSF session ID, this CID is chosen by the MGC and is passed to the MG by an ISUP+ message in both the forward and backward setup methods. In contrast to the MSF session ID, the CID is not meant to be included in the UNI SETUP message. Reference [5] has not specified where the CID would be carried in signaling across the network. Another suggestion makes use of a new value proposed initially in T1S1 and currently under discussion in ATM Forum, which is the 4-byte BNC-ID (Backward Network Connection Identifier). Discussion is ongoing in T1S1 and the ATM Forum to determine how this value could be carried across the network in either an ISUP+ or an UNI message. The BNC-ID would be generated by the MGC or MG. 3.4. EECID in the Megaco Protocol Description With respect to the Megaco protocol, the format for transport across the network and the actual value of the EECID is relevant only to the extent that it is unique to allow accurate correlation of the network path between the MGs. The issue is that in the existing Megaco protocol, there is no mechanism for specifying the EECID and communicating it between the MGC and MG. This paper proposes two possible places to specify an EECID. One place is to put the EECID in the Stream Descriptor in addition to the Local Control Descriptor (LCD), Local Descriptor (LD), and Remote Descriptor (RD). This is under the rational that the EECID should not be tied with LCD, or LD, or RD. It also eliminates the parsing SDP effort. This also allows for passing the EECID as a parameter in an event or in a signal. The syntax is StreamParm = (localDescriptor | remoteDescriptor | LocalControlDescriptor | EECID) The other method is to extend the SDP to include a term to specify an EECID. This new SDP term can then be used in the Megaco/H.248 Termination Descriptor to specify the value of EECID. The rational behind using SDP is that SDP has been used to describe termination properties. c=eecid:(eecid value) 4. PacketPipe Event/Signal Package This section describes two alternative mechanisms using the Megaco/ H.248 protocol to setup and correlate the packet network path. The difference between the two alternatives is the way in which the wait state for the establishment of the network path is manifested. They are: 1) Define an package with a signal that explicitly request the establishment of the packet network path and an event that explicitly reports the successful completion of the path, and 2) Make use of the Provisional Response mechanism (Transaction Pending) in the Megaco protocol to implicitly request and report successful completion of the establishment of the network path. Note that these alternatives are not necessarily mutually exclusive. The following discussion covers the use of these approaches separately and together. 4.1. PacketPipe Event Package >From the perspective of the event and signal packages the type of packet network should be transparent to the Megaco MGC. Therefore, it is the MG's responsibility to convert the native packet network messages to/ from the Megaco events and signals. Note that in this event package the ATM or IP interface is simply defined as a packet pipe rather than a trunk. As such, it does not consist of trunk events/signals. Package Name: PacketPipe ___________________________________________________________________ |Symbol | Definition | R | S | Paramter(s) | |________|_______________________________|___|____|_______________| |coav |bearer connection available | X | BR | EECID (O) | |cont |bearer connection not available| X | BR | EECID (O) | |co1 |continuity check | X | TO | | |co2 |continuity response | X | TO | | |of |report failure | X | | | |_________________________________________________________________| EECID (O) means that EECID is an optional parameter. This section will be modified to reflect the agreed upon formatting conventions for package definition. 4.2. Explicit Request Using Signals and Events Note that this alternative is one that was envisioned prior to the existence of the provisional response mechanism in the protocol definition. While one could argue that this mechanism supplants the need for the use of explicit signals and events for connection establishment, this mechanism described in this section has desirable characteristics that should be considered as an alternative. In particular, the use of explicit signals and events eliminates the need for the MG to maintain "state" of a ADD transaction request, reduces the transaction request state monitoring in the MGC, and eliminates the need to potentially send multiple Transaction Pending replies. This mechanism also potentially reduces complexity when multiple ADD commands in a single transaction, which require provisional responses, are being processed. When requesting establishment of a network path, an ADD command is sent to the MG, which explicitly specifies the "connection available" signal or event (coav) and the "connection not available" (cont) events. The coav signal is sent only to the ATM termination, which is responsible for the origination of the setup sequence for the network path. The transaction, which specifies these requests, is acknowledged on receipt. The MG as per the type of packet network manifests the coav signal (e.g., PNNI/UNI setup for an ATM network. A NOTIFY of the coav or cont event is sent from the MG to the MGC upon the connection becoming available (i.e., setup of the network path is complete) or upon failure to establish the connection, respectively. The event 'connection not availabe' (cont) is not necessary a failure on connection. The cont event can be used to determine bearer connection status. The continuity check and response can be used automatically by the MG without an instruction from the MGC. This is under the assumption that the MG is intelligent to apply the continuity check and response whenever it is appropriate. However, these two events/signals can also be requested by the MGC during call processing. An additional characteristic of this approach is that embedded signals and events can be used to allow for additional processing to be invoked automatically for such things as continuity checking of the network path. Refer to section 5 for examples of the PacketPipe Event Package flow diagrams. 4.2. Implicit Request using Provisional Response Mechanism An alternative way of making a connection request is based on the Megaco provisional response Transaction Pending reply wait state. This command is used when a command is received but pending for completion of processing. The MG can respond to the MGC with a command Transaction Pending response, so that the MGC won't be blocked for the completion response. When the MG finishes executing the command, it can then send the Transaction Reply command to acknowledge that the command has been successfully completed or has failed. The command Transaction Pending in the implicit method corresponds functionally to the Transaction Reply response in the explicit method, while the command Transaction Reply corresponds functionally to the Notify command. The difference is that the command Transaction Reply is an acknowledgement at the command level, while the Notify command is an acknowledgement at the event level. Instead of using connection available (coav) signal explicitly, the connection request is expressed implicitly by the ADD command. The rational behind this approach is that the packet connection does not exist until it is added to the context. Therefore, the ADD command implies setting up the bearer connection. The EECID, which is previously generated by the MGC, is present in the either the Stream Descriptor or the Termination Descriptor for the network path. The MG must the use the EECID to determine if it is required to initiate the network path setup. The MG will keep a record of all requests received from other MGs for setup of network path. When the ADD command is received, the MG will determine if a request with the specified EECID has been received. If a network path with the EECID exists this means the network path bearer connection already exists and the correlation is reported back to the MGC via the Transaction Reply. If no pending network path is found with the same EECID, then the path initialization is invoked. In this approach, there won't be the connection available (coav) signal and bearer connection available event notification (coav). If the MG determines that there will be sufficient delay setting up the bearer connection to cause the transaction request to time out, the MG will respond to the MGC with an Transaction Pending response. Upon completing the bearer connection, the MG will respond to the MGC with a Transaction Reply indicating success or failure of the attempt. The scenario is shown in the example of section 5.2. Obviously, this method incurs processing overhead in determining whether or not network path setup is required, in that the ADD command requires more processing in the MG to do so and the MG has to be more intelligent. Another negative consideration is that there is no mechanism to use embedded signals and events to allow for automatic processing of subsequent actions, such as continuity checking of the network bearer path. The MGC has to issue a separate message for continuity check and response. Combination of using both coav and using the provisional wait state could also valid. This would eliminate the need for the MG to search though pending network path requests to determine if the network path setup is required. If the coav signal is present, this setup will begin immediately. The main issue with using the two mechanisms simultaneously is the redundant messaging to report the completion of the ADD command and the reporting of the coav or cont event. This could be eliminated by not specifying the coav or cont event in the ADD command, but would remove the capability to use embedded signals and events. 5. Examples of the PacketPipe Event Package There are many ways to handle the call processing, depending on (1) Whether it is backward or forward setup, (2) Either the MG or the MGC creates the EECID. (3) Whether the connection available (coav) event/signal and connection not available (cont) are explicitly used, or the provisioning wait state is used (pending and ACK on the commands). (4) Whether the continuity check (CO1) and response (CO2) are used. This section illustrates several scenarios with different combinations. A high level functional description of the messaging is used in these examples. Only the steps related to bearer path setups are shown. (1) Section 5.1: backward setup, MG creates EECID, use coav (explicitly) (2) Section 5.2: forward setup, MGC creates EECID, use coav (explicitly) with continuity check and response (3) Section 5.3: forward setup, MG creates EECID, use pending and ACK (implicitly) (4) Section 5.4: forward setup, MGC creates EECID, use pending and ACK (implicitly), with continuity checking Whether backward or forward setup or both are supported is outside of the scope of this proposal. Selection of the MGC to MGC communication protocols, such as ISUP+ or SIP+, is also outside the scope of this paper. However, both factors affect the call processing and messaging flow. The liaison of MEGACO WG with other standards bodies will be needed to resolve these questions and issues. Due to potential inter-operability issues it is recommended that a choice must be made to select one mechanism for the MEGACO protocol implementations. This proposal recommends the scenarios in section 5.1. 5.1. Explicit Backward Setup, MG Creates EECID The examples in section 5.1 shows backward SVC setup in an ATM environment. The MG-B chooses an End-to-End Call Identifier (EECID) and passes it back to the MGC-B, which in terms passes the EECID to the MGC-A. The MGC-A then passes the EECID to the MG-A. MG-A MGC-A MGC-B MG-B | | | | |Notify(offhook) | | | |------------------>| | | |Add(Perm.Term) |Negotiate connection | | |<------------------| paramters | | | |--------------------->| | | |Agree on connection | | | |parameters(backward) |Add(PermTerm) | | |<---------------------|Add(ATMTerm, | 1 | | | event=coav, | | | | signal=coav) | | | |-------------------->| 2 | | |TransactionReply(Add)| | | |<--------------------| 3 | UNI SETUP (EECID) | |<---------------------------------------------------------------| 4 | UNI CONNECT (EECID) | |--------------------------------------------------------------->| 5 | | |Notify(event=coav | | | | (EECID)) | | |Pipe ConnectACK(EECID)|<--------------------| 6 |Add(ATMTerm(EECID),|<---------------------| | 7 | event=coav) | | | |<------------------| | | 8 |Notify(event=coav) | | | |TransactionReply | | | | (Add) | | | |------------------>|Pipe Connect Complete | | 9 | |--------------------->| | | | | | Selected steps: 1) The MGC-A and MGC-B agrees to use backward ATM setup. 2) The MGC-B sends an Add command to the MG-B with explict event=coav and signal=coav. 3) The MG-B immediately sends the MGC-B with an TransactionReply(Add). This does not mean that the Add command is finished. It only means that the MG-B is working on adding the ATM termination. 4) The MG-B chooses an EECID and includes the EECID in the UNI Setup message. The UNI Setup message is sent ot the MG-A through the ATM network. 5) The MG-A has to blindly accept the UNI Setup message even though it has not received any information from the MGC-A regarding adding the ATM termination. 6) After receiving the UNI Connect message from the MG-A, the MG-B notifies the MGC-B that event=coav has occurred and the MG-B passes the EECID to the MGC-B. The MG-B does not send the MGC-B with a TransactionReply(Add) since there is only one TransactionReply per transaction. 7) The MGC-B passes the EECID to the MGC-A through ISUP+ or other means. 8) The MGC-A asks the MG-A to add the ATM termination using the EECID and with an event=coav. 9) The MG-A will use the EECID to match with the bearer connection that has been setup. Once the MG-A finds the match, it returns the MGC-A with a notification with event=coav. The MG-A also sends a transac- tionReply(Add) to the MGC-A. In this example, the MGC-A cannot add the ATM termination until the UNI SVC has been setup. This is because that the EECID is needed to create an ATM Termination. The trade off is that the MG-A underlying ATM network has to blindly accept the connection before the MGC-A asks it to do so. The MG-A is not able to mix media from the ATM Termination into the context and the permanent Termination has not yet been created, so there is no risk of accepting the ATM connection. 5.2. Explicit Forward Setup, MGC creates EECID with CO1 and CO2 Ihe following example, the MGC chooses the EECID and passes it to the MG. Only the messaging which is different from the example in section 5.1 will be described. MG-A MGC-A MGC-B MG-B | | | | |Notify(offhook) | | | |------------------>| | | |Add(Perm. Term) |Negotiate connection | | |<------------------|parameters | | | |--------------------->| | | |Agree on connection | | | |parameters(forward) | | |Add(ATMTerm, EECID,|<---------------------| | | event=coav | | | | (event=co1 | | | | (signal=co2)), | | | | sig=coav) | | | |<------------------| | | 1 |TransactionReply | | | | (Add) | | | |------------------>| | | 2 | UNI SETUP (EECID) | |--------------------------------------------------------------->| 3 | UNI CONNECT(EECID) | |<---------------------------------------------------------------| |Notify(event=coav) | | | |------------------>|Pipe ConnectACK(EECID)|Add(PermTerm) | | |--------------------->|Add(ATMTerm, EECID | | | | event=coav | | | | (signal=co1), | | | | event=co2) | | | |-------------------->| 4 | | |TransactionReply(Add)| | | |Notify(event=coav) | | | |<--------------------| 5 | CO1 | | | |<---------------------------------------------------------------| 6 | CO2 | |--------------------------------------------------------------->| 7 |Notify(event=co1) | |Notify(event=co2) | |------------------>| |<--------------------| 8 | |Pipe Connect Complete | | | |<---------------------| | | | | | Selected steps: 1) The MGC-A chooses the EECID and passes it to the MG-A. There is an embedded event=co1 applied after the event=coav occurs and with the embedded signal for c02 associated with the c01 event. 2) The MG-A sends a TransactionReply(Add) to acknowledge that the transaction is accepted. This does not mean the ADD command has been executed. The MGC-A does not yet notify MGC-B, since the network path has not been created. 3) The MG-A sends an ATM UNI SETUP message with an EECID to the MG-B. 4) The MGC-B asks the MG-B to add its permanent termination and to add the ATM termination using this EECID, which will have a matched connection. 5) Since the connection does exist, the MG-B responds with an event=coav (connection available) event. The MG-B also sends TransactionReply (Add) to the MGC-B to complete the transaction. 6) The CO1 (continuity check) signal is applied by the MG-B since the event=coav has occurred. 7) The MG-A applies signal=CO2 since it receives co1 event. 8) The MG-A notifies the MGC-A that event=co1 occurred. Similarly, the MG-B notifies the MGC-B that event=coav and event=co2 occurred. 5.3. Implicit Forward Setup, MG Creates EECID The following example shows how to do forward setup with an EECID assigned by the MG. The difference here is the use of the provisional response without the events and signals coav. MG-A MGC-A MGC-B MG-B | | | | |Notify(offhook) | | | |------------------>| | | |Add(PermTerm) |Negotiate connection | | |<------------------|parameters | | | |--------------------->| | | |Agree on connection | | | |parameters(forward) | | |Add(ATMTerm) |<---------------------| | |<------------------| | | |TransactionPending | | | | (Add) | | | |------------------>| | | 1 | UNI SETUP (EECID) | |--------------------------------------------------------------->| 2 | UNI CONNECT(EECID) | |<---------------------------------------------------------------| |TransactionReply | | | | (Add, EECID) | | | |------------------>|Pipe ConnectACK(EECID)| | 3 | |--------------------->|Add(PermTerm) | | | |Add(ATMTerm, EECID) | | | |-------------------->| | | |TransactionReply | | | | (Add) | | |Pipe Connect Complete |<--------------------| 4 | |<---------------------| | | | | | Selected steps: 1) The MG-A sends an TransactionPending(Add) response to the MGC-A to wait for setup. 2) The MG-A chooses the EECID and passes it in the UNI Setup message to the MG-B. 3) When the connection setup is complete, the MG-A sends Transaction Reply(Add) and the EECID to the MGC-A. 4) Since the connection already exists, there is no pending for the command Add. Therefore, the MG-B immediately sends an TransactionReply (Add) to the MGC-B. 5.4. Implicit Forward setup; MGC creates EECID with CO1 and CO2 In this example the MODIFY command is used by the MGC-A to invoke and report continuity checking on the network bearer path. MG-A MGC-A MGC-B MG-B | | | | |Notify(offhook) | | | |------------------>| | | 1 |Add(PermTerm) |Negotiate connection | | |<------------------|parameters | | 2 | |--------------------->| | 3 | |Agree on connection | | | |parameters(forward) | | |Add(ATMTerm,EECID) |<---------------------| | 4 |<------------------| | | 5 |TransactionPending | | | | (Add) | | | |------------------>| | | 6 | UNI SETUP (EECID) | |--------------------------------------------------------------->| 7 | UNI CONNECT(EECID) | |<---------------------------------------------------------------| 8 |TransactionReply | | | | (Add) | | | |------------------>|Pipe ConnectACK(EECID)| | 9 | |--------------------->|Add(PermTerm) | 10 | | | Add(ATMTerm,EECID) | | | |-------------------->| 11 | | |TransactionReply(Add)| | |Pipe Connect Complete |<--------------------| 12 |Modify(ATMTerm, |<---------------------|Modify(ATMTerm, | 13 | event=CO1 | | signal=CO1) | | (signal=CO2) | | | |<------------------| |-------------------->| 14 | CO1 | |<---------------------------------------------------------------| 15 | CO2 | |--------------------------------------------------------------->| 16 |Notify(event=co1) | |Notify(event=co2, | |------------------>| |<--------------------| 17 | | | | 6. Syntax 6.1 ATM Termination Descriptor Megaco/H.248 allows the use of either SDP or Native tags for specifiying the packet Termination Descriptor. Below are the SDP descriptions for the ATM Termination Descriptor. In addition to the ones defined in reference [2] the new ones added by the proposed syntax in this draft are also included. Not all of them are required. The text inside the closed parentheses are text descriptions rather than actual values. v=(protocol version) i=(session information or media title) s=(session name) o=(owner/creator and session identifier) m=(transport port number or remote address) m=(transport protocol) m=(encoding method) m=(media type; ex:audio/data/video) m=(media format; ex: H.261/G.711) c=(connection information) c=eecid:(eecid value) c=(connection type; either ATM/LOCAL) c=(addressing scheme; ex: E.164 AESA) c=(ATM address) b=(bandwidth information) a=ptime:(packet time) a=(terminationMode; ex: sendrecv/recvonly/sendonly) a=(connection type; ex: AAL1/AAL2/AAL5) a=echo:off (echo cancellation) Note that the term 'c=eecid: (eecid value)' may not be used if one chooses to specify the EECID value in the Stream Descriptor. 7. Summary of recommendations The draft contains several recommendations for support of MGs that make use of connection oriented network paths. EECID is required in order to allow for correlation by the MGs of the end-to-end network path. The value of the EECID should be an arbitrary identifier not tied to the underlying packet network and that the format of the BNC-ID (4 byte numeric value) be used for this purpose. It is recommended that either SDP be extended to add a term for passing the EECID from the MGC to MG, or adding the EECID parameter in the Stream Descriptor. The recommended approach for establishing the network path is to use the explicit signals and events rather than provisional response. It is felt that that this mechanism is more straightforward and results in a much simpler MG implementation than using the provisional response mechanism. If the provisional response mechanism is used, it is still recommended that the signals and events for establishing the network path connection be used. This is recommended to reduce the processing overhead in the MG to determine whether or not to initiate the setup of the network path. 8. Acknowledgements The authors would like to thank their colleagues who are participating in the MEGACO VTOA implementation. Together, we have explored many issues and alternative solutions. 9. References [1] Fernando Cuervo, et al, "H.248/MEGACO Protocol", IETF and ITU, Ver. 11, Oct. 1999. [2] M. Handley & V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April, 1998. [3] "PNNI Addendum for the Network Call Correlation Identifier", ATM_Forum/BTD-CS-PNNI-NCCI-01.03, 26-30 July, 1999. [4] "Physical Realization of the MSF Functional Architecture", MSF Architecture Working Group White Paper MSF99.138, 10 Aug., 1999. [5] Trici So and Roderick Wilson, "A Generic ATM Trunking Architecture for Integration of PSTN/ISDN Narrowband Services", ATM Forum/99-0048, 7-12 Feb., 1999. [6] "Signaling Requirements for the Support of Narrow Band Services via Broadband Transport Technologies", (also known as ISUP+), proposed ITU-T TRQ.SCOBB_req, 8-16 July, 1999. [7] "CC-ISUP", ITU-T, July 1999. 10. Address Information Sophia Scoggins Nortel Networks 35 Davis Drive, MS: D15/02/0E2 RTP, NC 27709 scoggins@nortelnetworks.com (919)991-2182 Michael Brown Nortel Networks 35 Davis Drive, MS: D15/02/0E2 RTP, NC 27709 mahubard@nortelnetworks.com (919)991-7767