Network Working Group Kevin Fang(Cisco Systems) Internet Draft Feng Cai(Cisco Systems) Document:draft-zhiyfang-fecai-cesosctp-00.txt Shiwei Hu(Cisco Systems) Oct 2010 Min Wang(Cisco Systems) Expires: April 2011 Circuit Emulation Services over SCTP Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on Jan 10, 2011. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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]. K.Fang et al. Expires April 2011 [Page 1] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 Abstract This memo defines the mechanism for Time Division Multiplexing (TDM) transport over SCTP or Circuit Emulation Services over SCTP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 1.1. Motivation. . . . . . . . . . . . . . . . . . . . . . . .3 1.2. Potential Benefits . . . . . . . . . . . . . . . . . . .4 1.2.1. Sequencing . . . . . . . . . . . . . . . . . . .4 1.2.2. Fast Retransmission. . . . . . . . . . . . . . . .4 1.2.2. SCTP Multistreaming. . . . . . . . . . . . . . . .4 1.2.2. SCTP Multi-homing. . . . . . . . . . . . . . . . .4 2. CESoSCTP Encapsulation Layer. . . . . . . . . . . . . . . . . .5 2.1. CESoSCTP Packet Format . . . . . . . . . . . . . . . . . .5 2.2. CESoSCTP Multiplexing and Demultiplexing behavior. . . . .8 2.3. Packetized TDM data format . . . . . . . . . . . . . . . .8 3. CESoSCTP Operation . . . . . . . . . . . . . . . . . . . . . .8 3.1. Precision Time Protocol(IEEE1588) over SCTP. . . . . . . .8 3.2. SCTP transportation parameter. . . . . . . . . . . . . . .9 3.3. Adaptive token bucket for De-jitter mechanism. . . . . . .9 3.4. Pseudowire Redundancy . . . . . . . . . . . . . . . . . 10 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10 6. Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 K.Fang et al. Expires April 2011 [Page 2] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 1. Introduction This section explains the reasoning for Circuit Emulation Services over SCTP(CESoSCTP). 1.1 Motivation Tradition Circuit Emulation Services transport over Packet Switch Network mainly transport over a MPLS based Pseudo wire or over an UDP based Pseudowire. But with these implementation, it have many Issues: a. Packet Sequences : Unlike TDM networks, Ethernet does not carry synchronization information. When it used to carry TDM frame, it request to use a control word to record the sequence number or use Synchronous Ethernet(Sync-E) to maintain the packet sequences. b. Reliable Transmit: MPLS or UDP based Pseudowire does not have packet retransmit mechanism. When packet lost, it will cause bad TDM frame. c. Redundancy and Backup mechanism : MPLS or UDP based Pseudowire request use other mechanism(like BFD) to detect the remote node failure. d. Multiplexing and Demultiplexing : MPLS or UDP based Pseudowire does not have multiplexing or demultiplexing transmit mechanism on single Pseudowire. It request to use different PW-ID (like VC Label) or different UDP port to handle multiplexing or demultiplexing. The Stream Control Transmission Protocol(SCTP)[RFC2960] is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network. PSTN signaling(like Signaling System No.7,SS7) are originally carried by TDM link, SIGTRAN is designed by IETF signaling transport working group to use SCTP provide reliable datagram service and user layer adaptations for Signaling System 7 (SS7) and ISDN communications protocols. In this case SCTP is used for handle TDM based signaling transport, and it can also leverage for Circuit Emulation Service to carrier the TDM frame over IP network. K.Fang et al. Expires April 2011 [Page 3] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 1.2. Potential Benefits SCTP offers the following services to its users: acknowledged error-free non-duplicated transfer of user data, data fragmentation to conform to discovered path MTU size, sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, optional bundling of multiple user messages into a single SCTP packet, and network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance Behavior and resistance to flooding and masquerade attacks. 1.2.1. Sequencing SCTP support strict order-of-transmission and partial ordering transmission. For TDM over SCTP, it request to use strict order-of-transmission to maintain the packet order. 1.2.2. Fast Retransmission SCTP can quickly determine the loss of a packet, as a result of its usage of SACK and a mechanism which sends SACK messages faster than normal when losses are detected. When the router working with CESoSCTP receive a packet with error or there are some packet lost during the transmit. The router will using the SACK mechanism and ask the source retransmission selectively. 1.2.3. SCTP Multi-Streaming SCTP supports the delivery of multiple independent user message streams within a single SCTP association. This can be particularly useful for multiple TDM VC transport over an single association. So TDM over SCTP can easily support Multiplexing and Demultiplexing. 1.2.4. SCTP Multi-Homing SCTP provides transparent support for communications between two endpoints of which one or both is multi-homed. SCTP provides monitoring of the reachability of the addresses on the remote endpoint and in the case of failure can transparently failover from the primary address to an alternate address, without upper layer intervention. So TDM over SCTP can easily support Pseudowire Redundancy and Backup by using build-in multi-homing mechanism. K.Fang et al. Expires April 2011 [Page 4] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 2. CESoSCTP Encapsulation Layer 2.1. CESoSCTP Packet Format CESoSCTP is carried by a SCTP DATA chunk. Detailed DATA format is shown in Figure.1. With this special CESoSCTP DATA chunk, CESoPSN Control-Word can be simply merge in data chunk header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 64 |L|R| M |U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Packetized TDM data (Payload) \ / ... / \ ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure.1 CESoSCTP DATA chunk format Chunk Type: Chunk Type is set to 64 to indicate this is a CESoSCTP DATA chunk. Payload Protocol Identifier: used to defined the payload type Payload Protocol-ID = 0x1 : PTP payload Payload Protocol-ID = 0x0 : TDM or ATM L: if set, indicates some abnormal condition of the attachment circuit. M: a 2-bit modifier field. In case of L cleared, this field allows discrimination of signaling packets and carrying RDI of the attachment circuit across the PSN. In case of L set, only the '00' value is currently defined; other values are reserved for future extensions. L and M bits can be treated as a 3-bit code point space that is described in detail in Table 1 below. R: if set by the PSN-bound IWF, indicates that its local CEbound K.Fang et al. Expires April 2011 [Page 5] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 IWF is in the packet loss state, i.e., has lost a pre- configured number of consecutive packets. The R bit MUST be cleared by the PSN-bound IWF once its local CE-bound IWF has exited the packet loss state, i.e., has received a pre-configured number of consecutive packets. |=================================================================| | L | M | Code Point Interpretation | |===|=====|=======================================================| | 0 | 00 | CESoPSN data packet - normal situation. All CESoPSN | | | | implementations MUST recognize this code point. | | | | Payload MUST be played out "as received". | |---|-----|-------------------------------------------------------| | 0 | 01 | Reserved for future extensions. | |---|-----|-------------------------------------------------------| | 0 | 10 | CESoPSN data packet, RDI condition of the AC. All | | | | CESoPSN implementations MUST support this codepoint: | | | | payload MUST be played out "as received", and, if | | | | so configured, the receiving CESoPSN IWF instance | | | | SHOULD be able to command the NSP to force the RDI | | | | condition on the outgoing TDM chunk. | |---|-----|-------------------------------------------------------| | 0 | 11 | Reserved for CESoPSN signaling packets. | |---|-----|-------------------------------------------------------| | 1 | 00 | TDM data is invalid; payload MAY be omitted. All | | | | implementations MUST recognize this code point and | | | | insert appropriate amount of the configured "idle | | | | code" in the outgoing attachment circuit. In addition,| | | | if so configured, the receiving CESoPSN IWF instance | | | | SHOULD be able to force the AIS condition on the | | | | outgoing TDM chunk. | |---|-----|-------------------------------------------------------| | 1 | 01 | Reserved for future extensions | |---|-----|-------------------------------------------------------| | 1 | 10 | Reserved for future extensions | |---|-----|-------------------------------------------------------| | 1 | 11 | Reserved for future extensions | |=================================================================| Table 1. Interpretation of bits L and M in the CESoSCTP data chunk hdr B: The (B)eginning fragment bit(1bit). if set, indicates the first fragment of a user message. E bit: 1 bit (E)nding fragment bit(1bit), if set, indicates the The last fragment of a user message. An unfragmented user message shall have both the B and E bits set to '1'. Setting both B and E bits to '0' indicates a middle fragment of K.Fang et al. Expires April 2011 [Page 6] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 a multi-fragment user message, as summarized in the following table: B E Description ============================================================ | 1 0 | First piece of a fragmented user message | +----------------------------------------------------------+ | 0 0 | Middle piece of a fragmented user message | +----------------------------------------------------------+ | 0 1 | Last piece of a fragmented user message | +----------------------------------------------------------+ | 1 1 | Unfragmented message | ============================================================ Table 2: Fragment Description Flags When a user message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the message. This means that the TSNs for each fragment of a fragmented user message MUST be strictly sequential. Stream Identifier S: used for TDM Multiplexing and Demultiplexing. S = 0 defined to transmit management and Control message. Like TDM timeslot or ATM PI/VCI to Stream-ID mapping table. Timestamp : This is an optional header. Since SCTP DATA chunk header already have Stream-ID and Sequence No, thus does not require the full RTP header as optional, one optional timestamp header is enough. The fully CESoSCTP Packet is defined as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4/IPv6 and SCTP Common headers | | ... | +---------------------------------------------------------------+ | SCTP DATA chunk header | +---------------------------------------------------------------+ | TimeStamp (Optional) | +---------------------------------------------------------------+ | Packetized TDM data (Payload) | | ... | +---------------------------------------------------------------+ | SCTP DATA chunk header | +---------------------------------------------------------------+ | TimeStamp (Optional) | +---------------------------------------------------------------+ | Packetized TDM data (Payload) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure.2 CESoSCTP packet format K.Fang et al. Expires April 2011 [Page 7] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 2.2 CESoSCTP Multiplexing and Demultiplexing behavior The total size of a CESoSCTP packet for a specific PW MUST NOT exceed the SCTP DATA chunk size, From RFC4960 definition , the max-size could be 65,535 bytes. Consider for the Ethernet MTU and transportation delay, the CESoSCTP Payload length has been set to 512 bytes. SCTP multi-stream feature is used for CESoSCTP Multiplexing and Demultiplexing. Stream Identifier MUST be manually configured by both endpoints of the PW. CESoSCTP Multiplexing and Demultiplexing also can be handle by Multiple SCTP associations. Users MAY manually config SCTP Port. But NOT RECOMMENDED to use multi-associations transport over NAT. 2.3 Packetized TDM data format CESoSCTP Packetized TDM data encapsulation format follow the RFC5086 definition. If use SCTP multi-stream feature handle the multiplexing function. Each data chunk only handle one time slot and also strictly control the sequence number to synchronize the multi-stream. 3. CESoSCTP Operation When CESoSCTP data-chunk lost, it will required retransmit, but the retransmission packets will cause a high jitter. So we need some mechanism to de-jitter by using an adaptive token bucket and also use Precision Time Protocol(PTP,IEEE1588) to measure the delay and jitter for adaptive control. 3.1 Precision Time Protocol(IEEE1588) over SCTP Precision Time Protocol(PTP) transport over SCTP with Stream-ID = 0x0, and the packet format is defined as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 64 |L|R| M |U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier=0x0 | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier =0x1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K.Fang et al. Expires April 2011 [Page 8] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Precision Time Protocol(PTP) Payload \ / ... / \ ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure.3 CESoSCTP DATA chunk format 3.2 SCTP transportation parameter The RECOMMANDED CESoSCTP transportation parameter defined as below Association_Max_Retransmit 25 Heartbeat_interval 100ms INIT Retries 25 MAX PATH retransmit 5 Retry timeout initial 0ms Retry timeout MAX 0ms Retry timeout MIN 0ms SACK timeout adaptive by PTP delay measure result 3.3. Adaptive token bucket for De-jitter mechanism Adaptive token bucket used reduce the link jitter which caused by retransmission. DELAYaver = (1-Weight) * DELAYaver + Weight * ( PTPmeasure-delay - DELAYaver) SACKtimeout = DELAYaver +JITTERthreshold BUFFERsize = 4 * SACKtimeout * PACKET(input-rate) JITTERnow = (1-Weight) * JITTERnow + Weight * abs (DELAYrcv * DELAYaver) IF ( BUFFERnow < 25% * BUFFERsize or JITTERnow > JITTERthreshold ) // TOKEN-INJECTrate Reduce by: TOKENrate = Weight * BUFFERnow / BUFFERhalf * TOKENrate + ( 1-Weight ) TOKENrate IF ( BUFFERnow > 75% ) // TOKEN-INJECTrate increase by: TOKENrate = Weight * BUFFERnow / BUFFERhalf * TOKENrate + ( 1-Weight ) TOKENrate K.Fang et al. Expires April 2011 [Page 9] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 3.4. Pseudowire Redundancy Pseudowire redundancy and failure detection follow the SCTP multi- homing mechanism. 4. Security Considerations CESoSCTP does not enhance or detract from the security performance of the underlying PSN; rather, it relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required. 5. IANA Considerations This document defines a new SCTP DATA chunk type Chunk Type: Chunk Type is set to 64 to indicate this is a CESoSCTP DATA chunk. Under this type , it defined a new Payload Protocol Identifier: Payload Protocol Identifier: used to defined the payload type Payload Protocol-ID = 0x1 : PTP payload Payload Protocol-ID = 0x0 : TDM or ATM 6. Reference [RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [PWE3-MS] Martini, L., Metz, C., Nadeau, T., and M. Duckett, "Segmented Pseudo Wire", Work in Progress, November 2007. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006. [RFC3257] Coene, L., "Stream Control Transmission Protocol Applicability Statement", RFC 3257, April 2002 [RFC5086] I. Sasson, E. Metz, T. Frost and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC5086, December 2007 [IEEE 1588-2002] Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems K.Fang et al. Expires April 2011 [Page 10] Internet-Draft Circuit Emulation Services over SCTP Oct 2010 Authors' Addresses Kevin Fang Cisco Systems EMail: zhiyfang&cisco.com Feng Cai Cisco Systems EMail: fecai&cisco.com Shiwei Hu Cisco Systems EMail: shhu&cisco.com Min Wang Cisco Systems EMail: minwan&cisco.com K.Fang et al. Expires April 2011 [Page 11]