Internet DRAFT - draft-xie-sctp4megaco

draft-xie-sctp4megaco



Network Working Group                                          Q. Xie
INTERNET-DRAFT                                               Motorola
Category: Informational                                      C. Sharp
                                                                CISCO
                                                            I. Rytina
                                                             Ericsson
                                                         R.R. Stewart
                                                             Motorola


Expires in six months                                      March 2000



                 Use SCTP as MEGACO Transport
                <draft-xie-sctp4megaco-01.txt> 



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.


Abstract

This document discusses the use of the Simple Control Transmission 
Protocol (SCTP) [1], for carrying MEGACO [2] messages between an MGC 
and an MG. SCTP is currently being developed by IETF SIGTRAN Working 
Group. The framework architecture defined in RFC 2719 [3] can be used 
as a guideline for transporting MEGACO messages using SCTP.

MEGACO implementations targeting for high capacity and high 
availability deployment can especially benefit from the stream 
capability, redundant network support, congestion avoidance, and 
strong security features provided by SCTP.  
















1. Introduction

MEGACO protocol messages may be transmitted over the Simple Control
Transmission Protocol (SCTP) [1].

The MEGACO implementation may take advantage of the following services 
provided by SCTP:

  o Datagram-based transport  

  o Reliable delivery --- As a reliable transport protocol, SCTP 
    provides recovery mechanisms for transmission loss and duplicate 
    packet receipt. This simplifies the design of application level 
    repetition and timer control.

  o Ordered and unordered reliable message delivery --- Settable on a 
    per-message basis by the application, SCTP allows high priority 
    transactions be sent through unordered delivery for possible 
    expedited treatment. 

  o Stream capability --- SCTP can provide up to 65536 unidirectional 
    streams in each direction of an MGC-MG association. SCTP transmits 
    messages and processes received messages in one stream independent 
    to the order or status of messages in any other streams. The 
    application may effectively avoid head-of-line blocking by 
    transmitting unrelated transactions on different streams. 

  o Protection against "SYN" attacks --- The encryption cookie 
    mechanism built into the SCTP provides protection against the 
    equivalent of TCP "SYN" attacks on a MG or MGC node.

  o Network congestion management --- SCTP provides effective means 
    for detecting and handling network congestion. 

  o Redundant path management --- It may become strongly desirable for 
    a large MG to have fault resilient network-level connectivity 
    towards an MGC.  SCTP supports multi-homed IP nodes for redundant 
    path deployment. SCTP provides reachability monitoring, fast switch-
    over/fail-over, and potentially load balancing over redundant paths.

In a transaction-oriented protocol like MEGACO, there are still ways 
for transaction requests or responses to be lost, e.g., caused by 
entity/component failure.  As such, it is recommended that 
entities using SCTP transport implement application level timers for 
each request.


2. Providing the At-Most-Once functionality

SCTP is designed to recover from transport losses or duplications, but
loss of a transaction request or its reply may nonetheless be noted in
real implementations. In the absence of a timely response, MEGACO may
repeat commands. Most MEGACO 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 Annex D.1.1 of
document [2], with the exception LONG-TIMER or the use of the
TransactionResponseAck parameter, which shall not be used.


3. Transaction identifiers and three way handshake

For the same reasons as discussed above, it is possible that
transaction replies may be lost even with a reliable delivery protocol
such as SCTP. It is recommended that entities use transaction
identifers following the procedures in Annex D.1.2.1 of document [2].

Three way handshake is not applicable when SCTP is used.


4. Computing retransmission timers

With reliable non-duplicate delivery guaranteed by SCTP, application
level timers are only used to guard against entity/component failure.
Therefore, only simple timer mechanisms are required. Exponential
back-off algorithms shall not be necessary. 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.


5. Provisional responses

The basic procedures in section 8.2.3 of document [2] apply.


6. Ordering of commands

SCTP provides both ordered and unordered reliable delivery, settable
on a per-transaction basis.  Therefore, MEGACO can take advantage of
the ordered capability of SCTP.  High priority transactions can get
expedited treatment by properly using unordered delivery. No special
procedures are therefore required.


7.  Stream independence

SCTP can provide up to 65536 unidirectional streams in each direction
of an MGC-MG association.  SCTP transmits messages and processes
received messages in one stream independent to the order or status of
messages in any other streams. MEGACO may avoid head-of-line blocking
by transmitting unrelated transactions on different
streams. Reliability is still provided. Ordering of messages is 
available per-stream. It is recommended that transactions related to
one context are transported over the same stream.


8.  Authors' Addresses

Qiaobing Xie                            Tel: +1-847-632-3028
Motorola, Inc.                          EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309	    
Arlington Heights, IL 60004	    
USA				    
				    
Chip Sharp                              Tel: 
Cisco Systems Inc.                      EMail:chsharp@cisco.com
7025 Kit Creek Road		    
Research Triangle Park, NC  27709   
USA				    

Randall R. Stewart                      Tel: +1-847-632-7438
Motorola, Inc.                          EMail: rstewar1@email.mot.com
1501 W. Shure Drive, #2315	    
Arlington Heights, IL 60004	    
USA				
	    		   
Ian Rytina                              Tel:
Ericsson Australia                      EMail:ian.rytina@ericsson.com
37/360 Elizabeth Street		   
Melbourne, Victoria 3000	   
Australia			   


9. References

[1] R.R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.J. Schwarzbauer,
    T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Simple
    Control Transmission Protocol," <draft-ietf-sigtran-sctp-07.txt>,
    IETF SIGTRAN Working Group, March, 2000.

[2] F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Rayhan, B. Rosen,
    and J. Segers "Megaco Protocol,"
    <draft-ietf-megaco-protocol-07.txt>, IETF MEGACO Working Group,
    February, 2000. 

[3] L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin,
    I. Juhasz, M. Holdrege, and C. Sharp, "Framework Architecture for
    Signaling Transport," RFC 2719, IETF, Oct. 1999.









      This Internet Draft expires in 6 months from March 2000.