Internet Engineering Task Force Q. Xie INTERNET-DRAFT Motorola Transport Working Group C. Sharp Category: Informational CISCO October 1999 I. Rytina Expires: April 2000 Ericsson R.R. Stewart Motorola Use SCTP as MEGACO Transport 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. Xie, et al. Informational [Page 1] INTERNET-DRAFT Use SCTP as MEGACO Transport 1. Introduction MEGACO 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 and each response. This timer control logic can be similar to those specified for application level framing over UDP [2], but potentially much simpler due to the fact that SCTP already provides built-in fast retransmission and congestion avoidance mechanism. The exponential timer back-off and other congestion management mechanisms are not required at the application level. 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 E.1 of document [2]. 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 follow the procedures in Annex E.2 of document [2]. 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. 5. Provisional responses Executing some transactions may require a long time. Entities that can predict that a transaction will require a long execution time may send a provisional response, "Transaction Pending" [2]. They should send this response if they receive a repetition of a transaction that is still being executed. Entities that receive a Transaction Pending shall switch to a longer repetition timer for that transaction. Entities must retain Transactions and replies until they are confirmed. The basic procedure of Annex E.4 of document [2] should be followed, but simple timer values should be sufficient. 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. 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. 8. Fighting the restart avalanche The procedures of Annex E.6 of document [2] must be followed when using SCTP as the transport mechanism. 9. Basic SCTP interface SCTP supports an API similar to that of TCP, with the exception that the SCTP API is message-oriented. This allows MEGACO implementers to easily adopt SCTP with an interface similar to the one used for supporting TCP. The following is a short summary of some SCTP API primitives. Detailed description on the SCTP API recommendations can be found in Section 9 of [1]. o ASSOCIATE primitive: This primitive allows one MEGACO entity to initiate an SCTP association to another one. o TERMINATE primitive: Gracefully terminates an SCTP association. Any locally queued application messages will be delivered to the peer entity. The association will be terminated only after the peer entity acknowledges all the messages sent. o ABORT primitive: Used for immediately termination of an association with a peer entity. o SEND primitive: This primitive sends a message via an SCTP association. The application can specify to which stream (and optionally via which network path) the message should be sent, as well as whether the message should be treated as ordered or unordered delivery, etc. o RECEIVE primitive: This primitive reads out the first message in the SCTP in-queue, if one is available. o DATA.ARRIVE notification: SCTP invokes this notification to inform the application when a message is successfully received and ready for retrieval. o NETWORK.STATUS.CHANGE notification: SCTP invokes this notification when a destination transport address (usually presenting a distinctive network path) is marked down (e.g., when SCTP detects a failure), or marked up (e.g., when SCTP detects a recovery). o COMMUNICATION.UP notification: This notification is used when an SCTP association becomes ready to send or receive messages, or when a lost communication to an endpoint is restored. o COMMUNICATION.LOST notification: Used to indicate that communication to an endpoint via an SCTP association is completely lost, or that the peer endpoint has terminated the association 10. 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 11. 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," , IETF SIGTRAN Working Group, October 1999. [2] F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Rayhan, B. Rosen, and J. Segers "Megaco Protocol," , IETF MEGACO Working Group, September 1999. [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 October 1999.