Media Gateway Control (Megaco) Alf Heidermark Internet Draft Ericsson Document: draft-ietf-megaco-h248i-00.txt July 2000 Category: Standards Track H.248 Annex I (Pre-Decision White Document) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex I, which is scheduled for decision in Geneva in November 2000. H.248 Annex H describes procedures for transport of the Megaco protocol over ATM. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Transport over MTP 3B/N-SAL/AAL5 Megaco/H.248 protocol messages may be transmitted over an SS 7 network. Service indicator value 14 shall be used. These protocol messages is using the services of MTP 3 B as described in recommendation Q.2210. Heidermark Standards Track - Expires January 2001 1 H.248 Annex I (White Document draft) July 2000 In a transaction-oriented protocol there are still ways for transaction requests or responses to be lost. As such it is recommended that entities using MTP 3 B transport implement application timers for each TransactionRequest. 3.1 Providing At-Most-Once Functionality Messages, being carried over MTP3B, may be subject to losses. In the absence of a timely response, commands are repeated. Most commands are not idempotent. The state of the MG would become unpredictable if, for example, Add commands were executed several times.The transmission procedures shall thus provide an "At-Most-Once" functionality. To guard against such losses, it is recommended that entities follow the procedures in Megaco/H.248 Section D.1.1 with the exception of the use of LONG-TIMER and TransactionResponseAck parameter, which shall not be used. 3.2 Transaction identifiers and three way handshake 3.2.1 Transaction identifiers Megaco/H.248 Section D.1.2.1 is recommended to be followed. 3.2.2 Three way handshake It is not applicable. 3.3 Computing retransmission timers With reliable delivery, as MTP 3B provides, the incidence of loss of a transaction request or reply is expected to be very low. Therefore, only simple timer mechanisms are required. E.g The first retransmission of a request can occur after a short interval. If additional retransmissions are required a longer time interval is recommended between the retransmissions. 3.4 Provisional responses The basic procedures in Megaco/H.248 section 8.2.3 apply. 3.5 Ordering of commands MTP 3B provides ordered delivery of transactions therefore no special procedures are required. 4. Transport using SSCOP Protocol messages described in this document may be transmitted via SSCOP links. These protocol messages are using the services of SSCOP as described in recommendation Q.2110. Heidermark Standards Track - Expires January 2000 2 H.248 Annex I (White Document draft) July 2000 In a transaction-oriented protocol there are still ways for transaction requests or responses to be lost. As such, it is recommended that entities using SSCOP transport implement application timers for each request and response. 4.1 Providing the At-Most-Once functionality Messages, being carried over SSCOP, are not subject to transport losses, but loss of a transaction request or its reply may none-the- less be noted in real implementations. In the absence of a timely response, commands are repeated. Most commands are not idempotent. The state of the MG would become unpredictable if, for example, Add commands were executed several times. To guard against such losses, it is recommended that entities follow the procedures in Megaco/H.248 Section D.1.1. 4.2 Transaction identifiers and three way handshake 4.2.1 Transaction identifiers Megaco/H.248 Section D.1.2.1 applies. 4.2.2 Three way handshake It is possible that transaction replies may be lost even with a reliable delivery protocol such as SSCOP. Entities, using SSCOP shall follow the procedures in Megaco/H.248 Section D.1.2.1. 4.3 Computing retransmission timers With reliable delivery, the incidence of loss of a transaction request or reply is expected to be very low. Therefore, only simple timer mechanisms are required. 4.4 Provisional responses The basic procedure of Megaco/H.248 Section 8.2.3 applies. Entities that receive a Transaction Pending shall switch to a longer repetition timer for that transaction. Entities shall retain Transactions and replies until they are confirmed. The procedure of Megaco/H.248 Section D.2.4 should be followed, but simple timer values should be sufficient. 4.5 Ordering of commands SSCOP provided ordered delivery of transactions. No special procedures are required. Heidermark Standards Track - Expires January 2000 3 H.248 Annex I (White Document draft) July 2000 5. Transport using TYPE 5 AAL with ALF Protocol messages defined in this document may be transmitted via type 5 AAL links. These messages are using the services of Type 5 AAL as described in recommendation I.361. In a transaction-oriented protocol there are still ways for transaction requests or responses to be lost. As such, it is recommended that entities using type 5 AAL transport implement application level timers for each request and each response, similar to those specified for application level framing over UDP. 5.1 Providing the At-Most-Once functionality Messages, being carried over Type 5 AAL, may be subject to losses. In the absence of a timely response, commands are repeated. Most commands are not idempotent. The state of the MG would become unpredictable if, for example, Add commands were executed several times. The transmission procedures shall thus provide an "At-Most- Once" functionality. To guard against such losses, it is recommended that entities follow the procedures in Megaco/H.248 Section D.1.1. 5.2 Transaction identifiers and three way handshake 5.2.1 Transaction identifiers Megaco/H.248 Section D.1.2.1 applies. 5.2.2 Three way handshake When Type 5 AAL is used as transport the entities shall follow the procedures in Megaco/H.248 Section D.1.2.2. 5.3 Computing retransmission timers When Type 5 AAL is used as transport the entities shall provide the same type of calculation as described in Megaco/H.248 Section D.1.3. 5.4 Provisional responses When Type 5 AAL is used as transport the entities shall follow the procedures in Megaco/H.248 Section D.1.4. 5.5 Ordering of commands When Type 5 AAL is used as transport the entities shall follow the procedures in Megaco/H.248 Section 9.1. Heidermark Standards Track - Expires January 2000 4 H.248 Annex I (White Document draft) July 2000 6. Security Considerations Security considerations regarding media gateway control are discussed in section 10 of [3]. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 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", Geneva, June 2000. Also to appear as RFC xxxx (currently draft-ietf- megaco-merged-01.txt). 4 ITU-T Recommendation Q.2110. 5 ITU-T Recommendation Q.2210. 6 ITU-T Recommendation I.361. 6. Authors' Addresses Alf Heidermark (editor) Ericsson Tel:+46 87273894 E-mail: alf.heidermark@uab.ericsson.se Heidermark Standards Track - Expires January 2000 5