One document matched: draft-ietf-megaco-h248i-00.txt

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