Network Working Group A. Vainshtein - Editor (Axerra Networks) Internet Draft I. Sasson (Axerra Networks) A. Sadovski (Axerra Networks) Expiration Date: E. Metz (KPNQwest) December 2002 T. Frost (Zarlink Semiconductor) P. Pate (Overture Networks) June 2002 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) draft-vainshtein-cesopsn-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. 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 describes a method for encapsulating TDM digital signals defined in the plesiochronous digital hierarchy (PDH) as a pseudo-wire (PW) over various packet-switched networks (PSN). In this regard it complements similar work for SONET/SDH circuits. Proposed PW encapsulation uses RTP for clock recovery and leverages it for application state signaling between Customer Edge (CE) devices. TABLE OF CONTENTS 1. Introduction......................................................3 2. Summary of Changes from the -02 Revision..........................3 3. Terminology and Reference Models..................................4 3.1. Terminology...................................................4 3.2. Reference Models..............................................4 3.2.1. Generic Models............................................4 3.2.2. Synchronization Considerations and Deployment Scenarios...4 3.2.3. Service Examples..........................................5 4. Scope.............................................................5 4.1. Emulated Services.............................................5 Vainshtein et al. [Page 1] TDM Circuit Emulation Service over PSN June 2002 4.2. Protocol Layers...............................................5 4.3. Framers and N*DS0 Services....................................6 4.4. CE Signaling..................................................7 5. CESoPSN Encapsulation.............................................8 5.1. Generic CESoPSN Format........................................8 5.2. CESoPSN Header................................................8 5.2.1. Usage of RTP Header.......................................8 5.2.2. Usage and Structure of the Control Word...................9 5.3. Payload Data Format..........................................11 5.3.1. Common Considerations....................................11 5.3.2. N*DS0....................................................11 5.3.3. Unstructured TDM Circuits................................12 5.3.4. "T1-in-E1" Mode for Unstructured T1 Circuits.............12 6. CESoPSN Operation................................................13 6.1. Payload Parameters...........................................14 6.1.1. PW Type..................................................14 6.1.2. Circuit Bit Rate.........................................14 6.2. Encapsulation Layer Parameters...............................15 6.2.1. Usage of Control Word....................................15 6.2.2. RTP Payload Type.........................................15 6.2.3. Payload Bytes............................................15 6.2.4. Timestamp Resolution.....................................16 6.2.5. Synchronization Source ID................................16 6.2.6. Timestamp Generation Mode................................16 6.3. End Service Inactivity Behavior..............................16 6.4. Description of the IWF operation.............................16 6.4.1. PSN-bound Direction......................................16 6.4.2. CE-bound Direction - Normal Operation....................17 6.5. CESoPSN Defects..............................................19 6.5.1. Misconnection............................................19 6.5.2. Re-Ordering and Loss of Packets..........................19 6.5.3. Malformed Packets........................................20 6.5.4. Loss of Synchronization..................................20 6.6. Performance Monitoring.......................................21 6.6.1. Errored Data Blocks......................................21 6.6.2. Errored, Severely Errored and Unavailable Seconds........21 6.7. QoS Issues...................................................21 7. RTP Payload Format Considerations................................22 7.1. Resilience to moderate loss of individual packets............22 7.2. Ability to interpret every single packet.....................22 7.3. Non-usage of the RTP Header Extensions.......................22 7.4. Compression of RTP headers...................................22 8. Congestion Control (RFC 2914) Conformance........................22 9. FFS Issues.......................................................23 10. Security Considerations.........................................23 11. Applicability Statement.........................................23 12. IANA Considerations.............................................25 13. Intellectual Property Disclaimer................................25 ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN..........................29 ANNEX B. A COMMON CE APPLICATION STATE SIGNALING MECHANISM..........31 Vainshtein et al. Expires December-2002 [Page 2] TDM Circuit Emulation Service over PSN June 2002 1. Introduction This document describes a method for encapsulating TDM digital signals defined in the plesiochronous digital hierarchy (PDH) as a pseudo-wire (PW) over various packet-switched networks (PSN). In this regard, it complements similar work for SONET/SDH circuits (see [PWE3-SONET]). To support TDM traffic, which includes voice, data, and private leased line service, the network must emulate the circuit characteristics of a TDM network. A new circuit emulation header and RTP-based mechanisms for carrying the clock over PSN are used to encapsulate TDM signals and provide the Circuit Emulation Service over PSN (CESoPSN). Primary application of the technique described in this document is emulation of PDH circuits in situations when CE devices natively generate and terminate PDH traffic. The encapsulation technique does not depend upon the way this traffic reaches PE devices. The CESoPSN solution presented in this document fits the framework for PW services as described in [PWE3-FW] and satisfies the general requirements put forward in [PWE3-REQ]. 2. Summary of Changes from the -02 Revision Note: This section will be removed from the final document. 1. Section 13 "Intellectual Property Considerations" has been replaced with an "Intellectual Property Disclaimer" 2. Requirements for edge-to-edge emulation of TDM circuits have been moved to a separate document (see [PWE3-TDM-REQ]) 3. Considerations related to edge-to-edge emulation of unstructured SONET/SDH circuits have been removed 4. N*DS0 with CAS is not considered as a dedicated service type any more. Instead, a common mechanism for CE application state signaling is defined. This mechanism allows integration of arbitrary CR state signaling with transmission of CESoPSN- encapsulated TDM data within specific application. It leverages standard RTP "mixing" mechanisms for this purpose and uses well- known IETF techniques to guarantee robustness of signaling under occasional loss of packets and fast state recovery in case of the PSN outages 5. Format of the CESoPSN control word has been aligned with that of CEP ([PWE3-SONET] 6. A reference PE architecture for emulation of N*DS0 has been explicitly described 7. "Fractional E1/T1" applications have been defined. Vainshtein et al. Expires December-2002 [Page 3] TDM Circuit Emulation Service over PSN June 2002 3. Terminology and Reference Models 3.1. Terminology 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 [RFC2119]. The terms defined in [PWE3-FW], Section 1.4 are consistently used, usually without additional explanations. This document uses terms and acronyms that are commonly used in conjunction with the TDM services. In particular: o Alarm Indication Signal (AIS) is a common term denoting a special bit pattern in the TDM bit stream that indicates presence of an upstream circuit outage o Remote Alarm Indication (RAI) is a common term denoting a special pattern in the framing of a TDM service that is sent back by the receiver that experiences an AIS condition. 3.2. Reference Models 3.2.1. Generic Models Generic models that have been defined in Sections 3.1 (Network Reference Model), 3.2 (Maintenance Reference Model), 3.4 (Protocol Stack Reference Model) and 3.5(Logical Protocol Layering Model) of [PWE3-FW] are fully applicable for the purposes of this document without any modifications. All the services considered in this document represent special cases of the generic circuit-oriented payload type defined in Section 3.5.2.1 of [PWE3-FW]. Structured services discussed in this model leverage the reference models defined in [PWE3-LAYERS], Section 4.2. 3.2.2. Synchronization Considerations and Deployment Scenarios The Network Synchronization reference model and deployment scenarios for emulation of TDM services have been described in [PWE3-TDM-REQ], Section 4.2. Vainshtein et al. Expires December-2002 [Page 4] TDM Circuit Emulation Service over PSN June 2002 3.2.3. Service Examples Fig.1 below presents several examples of a T1 Emulated Service. _/_ \ / \ / \ +------+ Physical /+-+ \ / \__/ \ _ Hub Site |Site A| T1 / |P| +---+ \ (CE-3) |T1 #1=|====================|E|=| R | +---+ +-+ \ OC12+------+ |(CE-1)| \ |1| | |===| | | |---------| | +------+ / +-+ +---+ | | | | ========|=T1 #1| / | R |=|P| | | +------+ T1 +---+ DS3 / +-+ +---+ | | |E| ========|=T1 #2| |Site B| | |-----------|P| | R |===| | |3|---------| | |T1 #2=|====| M |===========|E|=| | +---+ +-+ / +------+ |(CE-2)| | |-----------|2| +---+ / +------+ +---+ \ +-+ / \ ___ ___ / \_/ \____/ \___/ Figure 1: T1 Emulation Example Diagram In this diagram, T1 circuits are attached to the PE devices in three different ways: 1. As a physical T1 line (between CE-1 and PE-1) 2. As a virtual T1 signal multiplexed in DS3 using one of possible multiplexing formats (between CE-2 and PE-2, see [T1.103] for details). M denotes a PDH multiplexor 3. As a virtual T1 signal mapped into an appropriate SONET virtual tributary, the latter being multiplexed in OC-12 (between CE-3 and PE-3 - see [T1.105] or [G.707] for details). 4. Scope 4.1. Emulated Services This specification describes service-specific encapsulation layer for edge-to-edge emulation of the following TDM circuits over a PSN: 1. Unstructured: a) Unstructured E1 as described in [G.704] b) Unstructured T1 (DS1) as described in [T.107] c) Unstructured E3 as defined in [G.751] d) Unstructured T3 (DS3) as described in [T.107] 2. Structured: N*DS0, 1 <= N <= 31 as described in [G.704]. 4.2. Protocol Layers This specification defines the encapsulation layer for edge-to-edge emulation of TDM services mentioned in Section 4.1. In accordance with the principle of minimum intervention (see PWE3- LAYERS], Section 3.3.5) the TDM payload is, whenever possible, encapsulated without any changes. This specification only imposes limitations on payload size of CESoPSN packets and, in case of Vainshtein et al. Expires December-2002 [Page 5] TDM Circuit Emulation Service over PSN June 2002 structured services, on alignment of the structures within CESoPSN packets. 4.3. Framers and N*DS0 Services N*DS0 services (as most structured TDM services) do not exist as physical circuits. They are always carried within a single physical E1 or T1 attachment circuit (AC), and the PE providing emulation of N*DS0 includes a Native Processing Block (usually referred to as Framer) that separates the specific group of N*DS0 from the AC. Framers may also support additional functionality including: 1. Detection of special states of the incoming AC (e.g., AIS or RAI) 2. Forcing special states (usually the same that can be detected on the outgoing AC. The resulting PE architecture for N*DS0 services is shown in Fig. 2 below. In this diagram: 1. In the PSN-bound direction: a) A single E1 or T1 AC undergoes de-framing: i) It is split into separate DS0 services ii) Special AC state is detected b) The forwarder creates one or more N*DS0 bundles and sends them to the PSN-bound direction of respective CESoPSN IWF instances accompanied by the AC state indications (common to all the bundles) 2. In the CE-bound direction: a) Each CE-bound instance of the CESoPSN IWF sends the de- packetized TDM data to the forwarder. This data MAY be accompanied by commands reflecting the desired state of the AC b) The framer accepts all the data of one or more N*DS0 bundles and, possibly, commands referring to the desired AC state, and generates a single AC accordingly. Notes: 1. This model is clearly asymmetric: a) AC state indication can be forwarded from the framer to multiple instances of the CESoPSN IWF, b) No more than one CESoPSN IWF instance should forward AC state-affecting commands to the framer 2. Fidelity of emulation of some unstructured services can be often improved by presence of a Framer NSP block in the PE. E.g., AIS and Idle Code states of a T3 circuit cannot be detected without a framer. Vainshtein et al. Expires December-2002 [Page 6] TDM Circuit Emulation Service over PSN June 2002 +------------------------------------------+ | PE Device | +------------------------------------------+ | | Forwarder | | | |---------------------| | | | | | | +<---N*DS0 TDM Data-->+ Single | PW Instance | F | | PW IWF X<===========> | | | Instance | Singe E1 | R | | | or T1 AC | +<--AC State/Command->+ | <=======>o A | |--------------| | | ... ... | ... | M | |--------------| | | | | | E | | | | +<---N*DS0 TDM Data-->+ Single | PW Instance | R | | PW IWF X<===========> | | | Instance | | | | | | +<--AC State/Command->+ | | | | | +------------------------------------------+ Figure 2. PE Architecture for N*DS0 Services 4.4. CE Signaling Edge-to-edge emulation of both structured and unstructured TDM circuits may require conveyance of application-specific CE signaling in addition to TDM data. In some cases these signals represent maintenance operations that do not require synchronization with the TDM data (e.g., requests to operate and release loopbacks). As a consequence, these signals can be passed out-of-band. In other cases these signals represent changes in the state of CE applications and hence SHOULD be synchronized with the data passing between these applications. E.g., Channel-Associated Signaling (CAS) or Common Channel Signaling (CCS) reflect changes in the state of telephony applications (like off-hook and on-hook) that must be synchronized with data exchanged between these applications to allow their normal operation. A common mechanism for conveying such signals (regardless of both the nature of CE applications and actual way in which these signals could be carried in the native TDM circuits) is described in Annex B below. It is based on ideas described in [RFC2833]. Application-specific details of this mechanism (e.g., encoding of specific CE signals) will be discussed in a separate document. Vainshtein et al. Expires December-2002 [Page 7] TDM Circuit Emulation Service over PSN June 2002 5. CESoPSN Encapsulation 5.1. Generic CESoPSN Format CESoPSN packets use format shown in Fig. 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CESoPSN Control Word (optional) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. CESoPSN Packet Format 5.2. CESoPSN Header The CESoPSN header includes a fixed RTP header (12 octets) and an optional CESoPSN Control Word (4 octets). 5.2.1. Usage of RTP Header CESoPSN uses the fields of the fixed RTP header (see [RFC1889], Section 5.1) in the following way: 1. V (version) is always set to 2 2. P (padding) is always set to 0 3. X (header extension) is always set to 0 4. CC (CSRC count) is always set to 0 5. M (marker) is set to 0 6. PT (payload type) MAY be used to distinguish between packets carrying the packetized TDM data and packets carrying CE application state signaling as following a) One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for every CESoPSN PW b) If CE application state signaling is conveyed over a CESoPSN PW, one more PT value MUST be allocated from the same range c) Allocation is done during the PW setup and MUST be the same for both PW directions Vainshtein et al. Expires December-2002 [Page 8] TDM Circuit Emulation Service over PSN June 2002 d) The PE at the PW ingress MUST set the PT value (or values) in the RTP header to the allocated value e) The PE at the PW egress MAY use this value (these values) to detect malformed packets 7. Sequence number is used primarily to provide the common PW sequencing function as well as detection of lost packets. It is generated and processed in accordance with the rules established in [RFC1889] 8. Timestamps are used primarily for carrying timing information over the network: a) Their values are generated in accordance with the rules established in [RFC1889] b) Frequency of the clock used for generating timestamps MUST be a multiple of 8 KHz c) Possible modes of timestamp generation are discussed below 9. The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections Note: The same PT value (or pair of PT values) can be reused between different PWs. The RTP header in CESoPSN can be used in conjunction with at least the following modes of timestamp generation: 1. Absolute mode: the ingress PE sets timestamps using the clock recovered from the incoming TDM circuit. As a consequence, the timestamps are closely correlated with the sequence numbers 2. Differential mode: PE devices connected by the PW have access to the same high-quality synchronization source, and this synchronization source is used for timestamp generation. As a consequence, the second derivative of the timestamp series represents the difference between the common timing source and the clock of the incoming TDM circuit. Usage of other timestamp generation modes is left for further study. Absolute mode allows operation in the Asynchronous Carrier's Carrier deployment scenario. Differential mode may improve quality of the recovered clock in the One Synchronous Network and Synchronous Carrier's Carrier deployment scenarios. 5.2.2. Usage and Structure of the Control Word Usage of the CESoPSN control word allows: 1. Differentiation between the PSN problems and the problems beyond the PSN as causes for the emulated service outages 2. Saving bandwidth by not transferring invalid data (AIS, idle code) 3. Signaling problems detected at the PW egress to its ingress Vainshtein et al. Expires December-2002 [Page 9] TDM Circuit Emulation Service over PSN June 2002 Consequently, usage of the CESoPSN Control Word is the default that MUST be supported by all the implementations. The PE peers MAY agree not to use it in a specific CESoPSN PW as part of the PW setup process. Note: Alternative techniques for conveying forward and backward indications without using the control word are left for further study. The structure of the CESoPSN Control Word is shown in Fig. 4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|D|A|X| Reserved | Optional sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Structure of the CESoPSN Control Word o Bit E - if set, indicates presence of an extended control word. Extensions of the control word are not defined in this specification, hence currently this bit MUST be always set to 0 o Bit R - carries Remote Loss of Packets indication, i.e., is set in packets transmitted by PE-2 to PE-1 if PE-2 detected loss of packets in the stream received from PE-1 o Bit D - carries Local Idle Code indication. If set, represents the Idle Code state in the payload of an unstructured T3 circuit. A packet with the I bit set MAY carry no payload o Bit A - carries Local AIS indication. If set, represents AIS of the AC of the emulated service. A packet with the A bit set MAY carry no payload o Bit X - for N*DS0 circuits MAY carry indication of RAI condition of the carrying E1 or T1 AC o Reserved - MUST be set to 0 at ingress and SHOULD be ignored at egress o Optional sequence number - implementation MAY copy 14 least significant bits of the RTP sequence number into this field. Otherwise it SHOULD be set to 0 at ingress. Notes: o The structure of the CESoPSN control word is aligned with that defined in [PWE3-SONET]. In particular, the reserved bits in the CESoPSN control word correspond to the structure pointer bits in the CEP one. For N*DS0 circuits these bits MAY be treated as the (valid) pointer to the native circuit frame carried in the CESoPSN packet (see Section 5.3.2 below) o Either A or D bit (but not both) can be set in the CESoPSN control word o Information about lost packets (carried via the bit R) can be used at ingress as an indication to resynchronize CE application state (see Annex A) o Information carried in bit X can be used in the Fractional E1/T1 applications (see below). Vainshtein et al. Expires December-2002 [Page 10] TDM Circuit Emulation Service over PSN June 2002 5.3. Payload Data Format 5.3.1. Common Considerations A single CESoPSN packet always contains one or more native circuit frames of the carried service. This provides for emulation of performance monitoring parameters of "classic" carriers of TDM circuits (e.g., SONET/SDH). Note: The native circuit frames for all the circuits considered in this document excluding unstructured T1 are octet-aligned. The T1 native circuit frame (193 bits) is not octet-aligned, and hence requires special treatment - see Section 5.3.4 below. The PSN operator selects the number of native service frames in a CESoPSN packet for a specific PW taking into account the following considerations: o Packetization latency requirements vs. bandwidth utilization o Path MTU limitations in order to avoid fragmentation of CESoPSN packets The number of native service frames in a CESoPSN packet is: 1. Defined during the PW setup and remains constant for the duration of a PW. Such an arrangement: a) Simplifies implementation because it implies that the CESoPSN packets are transmitted at a constant rate b) Allows insertion of a predefined amount of data instead of each lost packet at the PW egress 2. The same for both directions of the PW. Such an arrangement simplifies signaling and processing of backwards problem indications. CESoPSN uses the so-called "Telecom" bit ordering, i.e., each payload octet is: o Filled by the consecutive bits coming from the PWES from its most significant bit to the least significant one o Played out into the PWES in the same order 5.3.2. N*DS0 The payload data format for N*DS0 service emulation is shown in Fig. 5 below (N - number of timeslots in the service, M = number of the native circuit frames in a CESoPSN packet, the 1st timeslot of the 1st native frame is the 1st octet of the payload). The matrix shown in this diagram is mapped into array of payload octets row by row. Vainshtein et al. Expires December-2002 [Page 11] TDM Circuit Emulation Service over PSN June 2002 Timeslots ->| 1 | 2 | ... | N | ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ N C F 1| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a i r 2| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t r a ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i c m ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v u e ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e i s ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t M| | | ... | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 5. Payload structure for a N*DS0 Service The payload structure described provides for adaptation of the jitter buffer size for Voice applications while maintaining acceptable level of errors: o Actual size of the jitter buffer can be decreased by "shortening" the payload of some of the packets already in the buffer by the one "row" (native circuit frame) when they are transmitted. This is equivalent to dropping one octet from each timeslot o Actual size of the jitter buffer can be increased by "lengthening" the payload of some of the packets already in the buffer by one "row" (native circuit frames) when they are transmitted. This is equivalent to insertion of a single octet into each timeslot; the values carried in the last actual row of the matrix are repeated. 5.3.3. Unstructured TDM Circuits Basically, unstructured TDM circuits do not require framers in the PE devices, and are transferred as bit streams. However, presence of a framer allows detection of some outages of the end services. As a consequence, efficiency of the CESoPSN operation under such outages may be increased. The payload of a CESoPSN packet carrying an unstructured TDM service with an octet-aligned native circuit frame MUST contain one or more native circuit frames of the carried service, but no alignment with the framing structure of the service is required. 5.3.4. "T1-in-E1" Mode for Unstructured T1 Circuits As mentioned above, unstructured T1 represents the only case of a TDM circuit considered in this document with a non-octet aligned native circuit frame. In order to accommodate this type of service into the general CESoPSN framework, a special "T1 in E1" payload format is used. Vainshtein et al. Expires December-2002 [Page 12] TDM Circuit Emulation Service over PSN June 2002 This format (shown in Fig. 6 below) is based on mapping of an unstructured T1 circuit into a 25*DS0 service defined in [G.802] (M = number of native frames in the CESoPSN packet, D denotes the payload data bits). "Timeslots" | 1 | ... | 24 | 25 | |0 1 2 3 4 5 6 7| ... |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ N C F 1|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a i r 2|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t r a ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i c m ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v u e ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e i s ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t M|D D D D D D D D| ... |D D D D D D D D|D| padding | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 6. The "T1-in-E1" CESoPSN Payload Format Note: Each row in the matrix presented in Fig. 6 contains exactly 193 payload data bits and 7 padding bits. However, no alignment of the rows with the T1 framing structure is implied. 6. CESoPSN Operation Note: This section includes some implementation considerations. These considerations represent non-normative information and will be moved to an appropriate Appendix in the next update. Edge-to-edge service emulation of a TDM service using CESoPSN assumes the following elements: o Two PW end services of the same type and bit rate o Packetizer at the PW ingress o Jitter buffer and de-packetizer at the PW egress. Setup of a CESoPSN PW assumes exchange of the following information: o Types of end services. In order to be connected by a CESoPSN PW, these types MUST be the same and define the PW type. PW types supported by CESoPSN MUST be accommodated into the common enumeration of PW types o Bit rates of end services. In order to be connected, bit rates of the two end services MUST be the same and define the PW bit rate o Encapsulation layer-specific parameters that define specific instantiation of the protocol Vainshtein et al. Expires December-2002 [Page 13] TDM Circuit Emulation Service over PSN June 2002 This document defines only how the values of these parameters should be encoded. The actual signaling protocols for exchanging these parameters between the PE peers ("PE/PW signaling" in terms of [PWE3-FW]) are out of scope of this document. Description of the CESoPSN-based edge-to-edge service emulation includes the following elements: o Definition of the end service inactive state behavior towards the CE o Description of the IWF operation in CE-bound and PSN-bound direction. Details are presented below. 6.1. Payload Parameters 6.1.1. PW Type PW types (a.k.a. VC types) have been defined in [MARTINI-TRANS]. PW types used for CESoPSN PW are assigned in such a way as to avoid overlap with types assigned in other PWE3 documents. The following PW types are defined in this document for CESoPSN-based PWs: o Transparent N*DS0 - 65 o Unstructured E1 - 66 o Unstructured T1, no mapping - 67 (see Note below) o Unstructured T1, T1-in-E1 mode - 69 o Unstructured E3 - 70 o Unstructured T3 - 71 Note: This specification reserves a PW type for carrying unstructured T1 without any NSP mapping (i.e., unpadded 193 bits per 0.125 msec). However it does not define any encapsulation supporting this PW. 6.1.2. Circuit Bit Rate The circuit bit rate is encoded as the number of "timeslots" in the matrix structure of the corresponding CESoPSN data packet. The following values are used: o Transparent N*DS0 - N, 1 <= N <= 31 o Unstructured E1 - 32 o Unstructured T1, T1-in-E1 mode - 25 o Unstructured E3 - 537 o Unstructured T3 - 699 Note: N*DS0, unstructured E1 and unstructured T1 circuits can be carried over any PSN implementing the minimal MTU as defined in [RFC1122]. Unstructured E3 and T3 can be carried over any PSN providing Path MTU of 1.5 Kbytes. Vainshtein et al. Expires December-2002 [Page 14] TDM Circuit Emulation Service over PSN June 2002 6.2. Encapsulation Layer Parameters 6.2.1. Usage of Control Word TRUE value (default) of this Boolean parameter means that the CESoPSN control word is used. CESoPSN implementations MAY allow negotiation of this parameter, so that the control word will not be used if both sides agree to that. 6.2.2. RTP Payload Type One PT value MUST be allocated from the range of dynamically allocated payload types for each CESoPSN PW for use in the data packets: o The same value MUST be allocated for both directions of the PW o Ingress PW MUST set the PT in the RTP header of all the data packets to the allocated value o Egress PW MAY use this value to detect non-data PW packets. These packets can be either relegated to signaling or considered as malformed If a CESoPSN PW must be accompanied by some application state signaling, an additional PT value MUST be allocated from the range of dynamically allocated payload types for each CESoPSN PW for use in the data packets: o It MUST be different from the PT value allocated for data packets o The same value MUST be allocated for both directions of the PW o Ingress PW MUST set the PT in the RTP header of all the signaling packets to the allocated value o Egress PW MAY use this value to distinguish signaling PW packets. Note: The same PT value may be allocated for multiple PWs. 6.2.3. Payload Bytes This parameter has been defined in [MARTINI-TRANS]. In order to establish a CESoPSN-based PW, the following conditions MUST be met: 1. The number of payload bytes MUST be the same for both directions of the PW 2. The number of payload bytes MUST be a multiple of the encoded Circuit Bit Rate (see Section 6.1.2 above). E.g., the value of this parameter for an Unstructured E1 service (Circuit Bit Rate = 32) with M native circuit frames packet into a single CESoPSN packet will be 32*M, while for an Unstructured T1 it will be 25*M 3. The size of the resulting PW packet (including all the headers) SHOULD NOT exceed the path MTU between the participating PEs as provided by the Carrier layer. Vainshtein et al. Expires December-2002 [Page 15] TDM Circuit Emulation Service over PSN June 2002 Notes: 1. For PWs that combine TDM data with CE application state signaling this parameter defines the number of payload bytes in the data packets only 2. Packetization latency (PL) of a CESoPSN PW can be inferred from its Payload Bytes (PB) and Circuit Bit Rate (BR) parameters using the following formula: PL = 0.125*(PB/BR) (msec) 6.2.4. Timestamp Resolution This parameter encodes the rate of the clock used for setting timestamps in RTP headers as a multiple of the basic 8 KHz rate. 6.2.5. Synchronization Source ID The same 32-bit SSRC value MUST be assigned to all the data packets of a given direction of a CESoPSN PW. The CE-bound direction of the IWF MAY be use this value for misconnection detection, especially if such a service is not provided by the PSN and/or multiplexing layer(s). If data and signaling packets are multiplexed in the same PW, the signaling packets MUST use a separate SSRC value. This arrangement complies with the RTP specification [RFC 1889] and allows effective compression of the PW headers by the standard compressors. 6.2.6. Timestamp Generation Mode At least the following two values corresponding to modes described in Section 5.2.1 MUST be supported: o Absolute (1) - the timestamps are generated in accordance with the line clock of the incoming AC o Differential (2) - the timestamps are generated in accordance with a common reference clock of the pair of PEs. 6.3. End Service Inactivity Behavior While the PW is inactive, the PE MUST: o In case of emulation of unstructured services - send AIS to its local CE o In case of emulation of an N*DS0 service - send some (locally configured) Idle Code to its local CE. In addition, it MAY also send Force AIS command to the Framer. 6.4. Description of the IWF operation Once the PW is set up, the CESoPSN IWF operates like following: 6.4.1. PSN-bound Direction Vainshtein et al. Expires December-2002 [Page 16] TDM Circuit Emulation Service over PSN June 2002 o End service data is packetized in accordance with the number of payload bytes specified. For N*DS0 services, the packetized data is aligned with the native circuit frames as described in Section 5.3.1. For unstructured T1, the standard [G.802] mapping into 25*DS0 is performed prior to packetization o Sequence numbers and timestamps representing the selected synchronization clock are inserted in the CESoPSN headers o CESoPSN, multiplexing and PSN headers are prepended to the packetized service data o Resulting packets are transmitted via the PSN o If the PE detects any outage of the incoming unstructured end service that natively would result in sending the "downstream AIS", the CESoPSN IWF using the control word MUST set the local AIS indication flag (bit A) in the control word. The packet payload MAY be omitted in order to save the PSN bandwidth. The same rule applies to PWs carrying a N*DS0 service if an outage of its E1 or T1 AC has been detected o For N*DS0 services, if the PE detects an RAI condition of the E1 or T1 AC, the CESoPSN IWF using the control word SHOULD set RAI flag (bit X) in the control word o If the PE detects an Idle Code condition of the incoming an unstructured T3 end service, the CESoPSN IWF using the control word MUST set the local Idle Code indication flag (bit I) in the control word. The packet payload MAY be omitted in order to save the PSN bandwidth. Local AIS and Idle Code indications in the CESoPSN control word provide for the following functionality: o Ability to distinguish between the PSN problems and ones beyond the PSN as causes of outages of the emulated service o Ability to save the PSN bandwidth (but not its switching capacity) by not sending invalid data across the PSN. RAI indication is useful in the so-called "Fractional E1/T1" applications (see below). The techniques to save the PSN switching capacity in case of an end service outage are left for further study. 6.4.2. CE-bound Direction The CE-bound IWF includes a jitter buffer that accumulates data from incoming CESoPSN packets with their respective timestamps. The length of this buffer SHOULD be configurable to allow adaptation to various network delay behavior patterns. Size of the jitter buffer is a local parameter of the CESoPSN IWF. Since any CESoPSN data packet carries a fixed number of native data frames of the emulated service, the jitter buffer can be considered as a matrix with "rows" corresponding to native service frames, too. Initially the Jitter buffer is filled with the appropriate inactivity (AIS or Idle) code. Vainshtein et al. Expires December-2002 [Page 17] TDM Circuit Emulation Service over PSN June 2002 Immediately after start, the IWF: o Begins reception of incoming CESoPSN packets. PSN and multiplexing layer headers are stripped from the received packets, and packetized TDM data from the received packets is stored in the jitter buffer. o Continues to play out its appropriate inactivity code into its end service as long as the jitter buffer has not yet accumulated sufficient amount of data o Once the jitter buffer contains sufficient amount of data (usually half of its capacity), the IWF starts replay of this data in its end service in accordance with its (locally defined) 8 KHz transmission clock, so that a single "row" of the jitter buffer matrix is replayed per "tick" of the clock. If transmission clock must be recovered from the PW, the timestamps of data packets SHOULD be used for correcting initial transmission clock frequency in accordance with the specified mode of their generation. o If adaptation of the jitter buffer size is implemented, it SHOULD NOT introduce additional wander of the transmission clock. It MAY introduce additional errors (e.g., in accordance with the techniques described in Section 5.3.1 above) The CE-bound IWF SHOULD provide access to the value of the timestamp of the packet that is currently played out. This value MAY be used for synchronization between TDM data and CE application signals. CESoPSN packets marked with an AIS indication in the control word MUST be replaced with the appropriate amount of AIS (for unstructured services) or Idle code (for N*DS0) in the jitter buffer. CESoPSN packets marked with an Idle Code indication in the control world (for PWs carrying unstructured T3 service) MUST be replaced with the appropriate amount of the T3 Idle Code. The CE-bound direction of the IWF: o Performs detection, correlation and handling of CESoPSN faults as described in Section 6.5 below o Collects the PW Performance Monitoring data as defined in Section 6.6 below The CE-bound IWF for an N*DS0 service MAY be configured to send the following commands to its NSP (see Fig. 2): 1. "Force AIS" command: o If it detects a Loss of Packets condition o While it plays out CESoPSN packets with the AIS indication set 2. "Force RAI" command - while it plays out CESoPSN packets with RAI indication set. Vainshtein et al. Expires December-2002 [Page 18] TDM Circuit Emulation Service over PSN June 2002 Notes: 1. The IWF configuration described above: a. Is specific per IWF instance b. Is a local issue. In particular, it is possible to configure only one of the two IWF instances associated with the given PW to force AIS and RAI states on its outgoing AC c. Makes sense only if the IWF instance in question is the only IWF instance associated with the specific outgoing AC 2. If both IWF instances associated with the given PW are configured to force AIS and RAI states on their respective outgoing ACs, the CE devices may effectively treat the PW as part of an emulated E1 or T1 service while the PSN carries only an N*DS0 service (thus possibly saving BW). 3. Extension of mechanisms allowing the CE-bound IWF to force some special states on the outgoing AC to other services is left for further study. 6.5. CESoPSN Defects 6.5.1. Misconnection Some combinations of PSN and multiplexing layers (see Annex A) inherently provide for detection of packets that do not belong to the PW ('stray packets'). CESoPSN MAY use the SSRC field in the RTP header for detection of 'stray packets' even if such a capability is provided by the specific combination of PSN and multiplexing layers. Regardless of the way in which a stray packet has been detected: o It MUST be discarded by the CE-bound IWF o A counter of 'stray packets' must be incremented If reception of stray packets persists, the Misconnection alarm should be reported to the management system. The IWF mechanisms for detection of lost packets (e.g., expected next sequence number) MUST NOT be affected by reception of 'stray packets'. 6.5.2. Re-Ordering and Loss of Packets CESoPSN implementations SHOULD use sequence numbers in the RTP header and expected rate of transmission of data packets for detection of our- of-order delivery and packets' loss. In particular, they MAY maintain the next expected sequence number value that would be: o Advanced every time a packet belonging to this PW with an equal or greater (mod 65536) sequence number has been received or a timeout defined by the expected packet arrival rate has expired o Used as the center of a sliding window for packet reordering. The size of this window SHOULD be limited by the size of the jitter buffer. Vainshtein et al. Expires December-2002 [Page 19] TDM Circuit Emulation Service over PSN June 2002 Out-of-order packets that cannot be reordered (e.g. because their sequence numbers are out of the sliding window mentioned above) MUST be considered as lost. If loss of one or more CESoPSN packets has been detected at the egress of the CESoPSN PW, its jitter buffer MUST be filled with the appropriate amount of the AIS (or Idle - depending on the service type) code to be replayed into the relevant PWES. In addition: o If the CESoPSN control word is used, the Remote Lost Packets Indication flag (bit R) MUST be set in the next packet to be sent in the opposite direction of the PW o A counter of lost packets must be incremented If the loss-of-packets condition persists, an alarm should be sent to the management system. 6.5.3. Malformed Packets CESoPSN PW detects a malformed packet using the following rules: o The PT value in its RTP header does not correspond to one of the PT values allocated for this PW o The actual packet payload size can be unambiguously inferred from the data link, PSN or multiplexing layer of the PW and does not match the payload size defined for the packets of this type in this PW. If a malformed in-order packet has been received at the egress of a CESoPSN PW, then: o The packet MUST be discarded and appropriate amount of AIS (or Idle Code) inserted in the jitter buffer o A counter of malformed packets must be incremented o If the payload mistype condition persists, an appropriate alarm should be sent to the management system. 6.5.4. Loss of Synchronization The CESoPSN IWF MAY detect two types of loss of synchronization errors: 6.4.5.1 Jitter Buffer Overrun This fault is detected if the jitter buffer at the PW egress cannot accommodate the newly arrived CESoPSN packet in its entirety. A CESoPSN packet that cannot be stored in the jitter buffer MUST be discarded. If the jitter buffer overrun condition persists, an appropriate alarm should be sent to the management system. In addition, the Remote Loss of Synchronization (bit T) flag SHOULD be set in the next packet to be send in the opposite direction of the service. Vainshtein et al. Expires December-2002 [Page 20] TDM Circuit Emulation Service over PSN June 2002 6.5.4.2. Jitter Buffer Underrun This fault is detected if the jitter buffer at the PW egress becomes empty before arrival of a new CESoPSN packet while loss of packets has not been detected. CESoPSN implementations MAY never detect the Jitter Buffer Underrun condition if their packets' loss detection mechanisms do not allow it. If the jitter buffer underrun condition persists, an appropriate alarm should be sent to the management system. In addition, the Remote Loss of Synchronization (bit T) flag SHOULD be set in the next packet to be send in the opposite direction of the service. 6.6. Performance Monitoring 6.6.1. Errored Data Blocks [G.826] defines the concept of an errored data block that serves as the basis of for collection of performance monitoring parameters. It also defines the size of the data block for most TDM circuits. These definitions are aligned with the 'native circuit frame' size of these circuits so that every G.826-compatible data block contains an integer multiple of native circuit frames. The following definitions of error events and errored data blocks for CESoPSN provide for collection of [G.826]-compatible performance monitoring parameters: o An error event is insertion of a single native service frame of inactivity code into the jitter buffer if it does not stem from receiving a CESoPSN packet with an AIS or Idle Code indication o An errored data block is a data block defined in accordance with [G.826] that has experienced at least one error event o A defect is insertion of a contiguous sequence of native service frames of inactivity code into the jitter buffer if it does not stem from receiving a CESoPSN packet with an AIS or Idle Code indication and if the length of this sequence exceeds the limits defined by the defect detection rules of the emulated service. 6.6.2. Errored, Severely Errored and Unavailable Seconds The definition of an errored data block presented above can be used to define Errored Seconds, Severely Errored Seconds and Unavailable Seconds in accordance with [G.826]. 6.7. QoS Issues If the PSN providing connectivity between PE devices is Diffserv- enabled and implements EF PHB (see [RFC2598bis]), all the CESoPSN data packets should be marked for EF PHB at ingress. Such an arrangement results in decrease of the packets' inter-arrival jitter and hence in decrease of latency introduced by the TDM circuit emulation. Vainshtein et al. Expires December-2002 [Page 21] TDM Circuit Emulation Service over PSN June 2002 7. RTP Payload Format Considerations In accordance with guidelines specified in [RFC2736], the following issues are addressed by this specification: 7.1. Resilience to moderate loss of individual packets The impact of loss of an individual data packet may be decreased by decreasing the packet size (with the associated loss of efficiency). 7.2. Ability to interpret every single packet This requirement is met since every CESoPSN packet carries a multiple of the native frame of the carried service. 7.3. Non-usage of the RTP Header Extensions This recommendation is met, since RTP-wise, the CESoPSN Control Word is part of the RTP payload. Alignment with this requirement facilitates usage of standard header compression mechanisms if CESoPSN uses UDP/IP as its PSN and multiplexing layers. 7.4. Compression of RTP headers Existing relevant standards ([RFC2508], [RFC3095]) deal with compression of RTP/UDP/IP headers on specific P2P links. Compression techniques defined in these documents are fully applicable for CESoPSN if it uses UDP/IP as PSN and multiplexing layers respectively. Standard compression of CESoPSN/UDP/IP headers will be very effective, since: Value of the SSRC field in the CESoPSN header of data packets remains constant for the duration of a CESoPSN session Value of the Timestamp field in the CESoPSN header is usually incremented by a fixed value from packet to packet CESoPSN control word is NOT defined as RTP header extension. As a consequence, a PSN-independent end-to-end compression technique of RTP headers seems not justified. 8. Congestion Control (RFC 2914) Conformance CESoPSN PWs carry constant bit rate (CBR) services. These services, by definition, cannot behave in a TCP-friendly manner prescribed by [RFC2914] under congestion while retaining any value for the user. Devices implementing CESoPSN and using IP as their PSN layer: o MUST set the ECN bits of the IP header (see [RFC3168]) to non- ECT ('00') value at ingress (to prevent routers in the network from setting them to the CE ('11') value) o SHOULD ignore these bits at egress. Vainshtein et al. Expires December-2002 [Page 22] TDM Circuit Emulation Service over PSN June 2002 9. FFS Issues Note: This section will be removed from the final revision of the document. The following issues will be addressed in the next revisions of this document: o Techniques for saving the PSN switching capacity when the PW experiences an end service outage or does not carry any valid data o Effect of timestamp resolution on quality of clock recovery in Differential mode o Extension of techniques for forcing states on outgoing ACs to emulation of other services. 10. Security Considerations This document does not affect the underlying security issues of specific PSN. In addition, it defines misconnection detection capabilities of CESoPSN. These capabilities increase resilience of CESoPSN to misconfiguration and some types of DoS attacks. 11. Applicability Statement CESoPSN is an encapsulation layer intended for carrying TDM circuits (N*DS0, unstructured E1/T1 and unstructured E3/T3) over PSN. CESoPSN allows carrying both data and clock of TDM circuits across multiple types of PSN. CESoPSN allows carrying CE application state signaling that requires synchronization with data in-band in separate signaling packets. The RTP Payload Type (PT) is used to distinguish between data and signaling packets, while the Timestamp field is used for synchronization. This makes CESoPSN extendable to support different types of CE signaling without affecting the data path in the PE devices. CESoPSN does not presume availability of a global synchronous clock at the ends of a PW. This makes it suitable for Asynchronous Carriers' Carrier applications. CESoPSN performs only the minimally necessary mapping of the TDM data (in case of an unstructured T1 service), or none at all, hence minimizing overhead at the payload layer. PE devices implementing CESoPSN do not require local oscillators of quality that is better than natively required for the carried service. CESoPSN uses RTP for carrying the clock across the PSN. The additional CESoPSN control word is a "payload format header" and hence standard Vainshtein et al. Expires December-2002 [Page 23] TDM Circuit Emulation Service over PSN June 2002 header compression techniques for RTP/UDP/IP profile over slow and/or error-prone links are fully applicable to CESoPSN PWs. CESoPSN allows the PSN bandwidth conservation by carrying only AIS and/or Idle Code indications instead of data. CESoPSN allows deployment of BW-saving Fractional point-to-point E1/T1 applications. These applications can be described like following: o The pair of CE devices operates as if they were connected by an emulated E1 or T1 circuit. In particular they react to AIS and RAI states of their local ACs in the standard way o The PSN carries only an N*DS0 service where N is the number of actually used timeslots in the circuit connecting the pair of CE devices thus saving the BW. Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP- friendly behavior under network congestion. CESoPSN allows collection of TDM-like faults and performance monitoring parameters hence emulating 'classic' carrier services of TDM circuits (e.g., SONET/SDH). Similarity with these services is increased by the CESoPSN ability to carry 'far end error' indications. CESoPSN provides for a carrier-independent ability to detect misconnections and malformed packets. This feature increases resilience of the emulated service to misconfiguration and DoS attacks. CESoPSN provides for detection of lost packets and hence allows to distinguish between the PSN problems and ones beyond the PSN as causes of outages of the emulated service. Faithfulness of a CESoPSN PW may be increased if the carrying PSN is Diffserv-enabled and implements EF PHB. CESoPSN carries indications of outages of incoming attachment circuit across the PSN and provides of detection of lost packets. The combination of these abilities provides for effective fault isolation. CESoPSN does not provide any mechanisms for protection against PSN outages. As a consequence, resilience of the emulated service to such outages is defined by the PSN behavior. On the other hand: o The jitter buffer and packets' reordering mechanisms associated with CESoPSN increase resilience of the emulated service to fast PSN rerouting events o Remote indication of lost packets is carried backward across the PSN from the receiver (that has detected loss of packets) to transmitter. Such an indication MAY be used as a trigger for activation of proprietary service-specific protection mechanisms. Vainshtein et al. Expires December-2002 [Page 24] TDM Circuit Emulation Service over PSN June 2002 12. IANA Considerations This specification requires assignment of new PW Types for CESoPSN PWs as described in Section 6.1. 13. Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. Axerra Networks, Inc. has filed one or more patent applications relating to the CESoPSN technology outlined in this document. Axerra Networks, Inc. will grant free unlimited licenses for use of this technology to the users who will register and sign up at the Axerra web site. ACKNOWLEDGEMENTS We express deep gratitude to Stephen Casner who reviewed this document in detail, corrected some serious errors and provided many valuable inputs. Some of his inputs will be explored in the next revisions of the draft. We thank Maximilian Riegel, Sim Narasimha, Tom Johnson and Yaron Raz for valuable feedbacks. We thank Alik Shimelmits for many fruitful discussions. References [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in Progress, July-2001, draft-ietf-pwe3- requirements-01.txt [PWE3-TDM-REQ] Maximilan Riegel et al, Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN), Work in Progress, June 2002, draft-riegel-pwe3-tdm-requirements-00.txt [PWE3-FW] Prayson Pate et al, Framework for Pseudo Wire Emulation Edge- to-Edge (PWE3), Work in progress, June 2002, draft-ietf-pwe3-framework- 01.txt [PWE3-LAYERS], Stewart Bryant et al., Protocol Layering in PWE3, Work in Progress, June 2002, draft-ietf-pwe3-protocol-layer-00.txt [PWE3-SONET] Andrew G. Malis et al, SONET/SDH Circuit Emulation over Packet (CEP), Work in progress, June 2002, draft-malis-pwe3-sonet- 03.txt [KOMPELLA] MPLS-based Layer 2 VPNs, Work in Progress, July 2001, draft- kompella-ppvpn-l2vpn-00.txt Vainshtein et al. Expires December-2002 [Page 25] TDM Circuit Emulation Service over PSN June 2002 [MARTINI-TRANS] Luca Martini et al, Transport of Layer 2 Frames Over MPLS, Work in progress, April 2002, draft-martini-l2circuit-trans-mpls- 09.txt [MARTINI-ENCAP] Luca Martini et al, Encapsulation Methods for Transport of Layer 2 Frames Over MPLS, Work in progress, November 2001, draft- martini-l2circuit-encap-mpls-04.txt [L2TPv3] J.Lau et al, Layer Two Tunneling Protocol "L2TP", Work in progress, October 2001, draft-ietf-l2tpext-l2tp-base-01.txt [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- Communication Layers, RFC 1122, IETF, 1989 [RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, IETF, 1996 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels, RFC 2119, IETF, 1997 [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, RFC 2434, IETF, 1998 [RFC2474] K. Nichols et al., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, IETF, 1998 [RFC 2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, RFC 2508, IETF, 1999 [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP Payload Format Specifications, RFC 2736, IETF, 1999 [RFC2598bis] Bruce Davie (ed.), An Expedited Forwarding PHB, Work in Progress, April 2001, draft-ietf-diffserv-rfc2598bis-01.txt [RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000 [RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC 3095, IETF, 2001 [RFC3140] D. Black et al, Per Hop Behavior Identification Codes, RFC 3140, IETF, June 2001 [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, IETF, 2001 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- parameters Vainshtein et al. Expires December-2002 [Page 26] TDM Circuit Emulation Service over PSN June 2002 [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s hierarchical levels [G.707] ITU-T Recommendation G.707 (10/00) - Network Node Interface for Synchronous Digital Hierarchy (SDH) [G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex equipments operating at the third order bit rate of 34 368 Kbit/s and the fourth order bit rate of 139 264 Kbit/s and using positive justification [G.802] ITU-T Recommendation G.802 (11/88) - Interworking between networks based on different digital hierarchies and speech encoding laws [G.826] ITU-T Recommendation G.826 (02/99) - Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate [T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface Rates and Format Specifications (SONET} [T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format Specification [NANOG] St. Casner, C. Alaettinoglu, Ch. Kuan, A fine-grained view of high-performance networking, NANOG-22, May 2001 Authors' addresses Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: sasha@axerra.com Israel Sasson Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: israel@axerra.com Akiva Sadovski Vainshtein et al. Expires December-2002 [Page 27] TDM Circuit Emulation Service over PSN June 2002 Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: akiva@axerra.com Eduard Metz KPNQwest Scorpius 60 2130 GE Hoofddorp, The Netherlands email: eduard.metz@hetnet.nl, eduard.metz@kpnqwest.com Tim Frost Zarlink Semiconductor Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK email: tim.frost@zarlink.com Prayson Pate Overture Networks P. O. Box 14864, RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Vainshtein et al. Expires December-2002 [Page 28] TDM Circuit Emulation Service over PSN June 2002 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN A1. IP PSN CESoPSN is RTP-based, and UDP flows are a natural way to convey RTP traffic (see [RFC1889]). If this technique is used for conveying CESoPSN, then: Unused even UDP ports must be allocated at both PE nodes terminating a CESoPSN PW as part of the PW establishment process IP and UDP headers must be prepended to each CESoPSN packet These packets will be transmitted by each PE node to its peer using the standard IP routing mechanisms. UDP flows represent a multiplexing layer with limited ability to detect misconnections. As a consequence, SSRC-based misconnection detection by CESoPSN MAY be disabled. IP represents a Carrier layer with inherent ability to infer the payload size from the header. As a consequence, detection of malformed packets SHOULD take the actual payload size into consideration. By default, manual signaling can be used for setup and teardown of CESoPSN PWs over UDP flows. As a consequence, parameters defined in Section 6 should be incorporated into to the appropriate service- specific MIB module. [RFC1889] defines a convention for associating an RTCP session with each RTP/UDP/IP one. Possible usage of RTCP for CESoPSN is left for further study, see also Annex B. A2. MPLS PSN Note: The text below does not define a generic RTP/MPLS stack. Such a work is clearly out of scope of this document. This section is concerned with the case of MPLS being used as both the PSN and multiplexing layer for the CESoPSN PW. In this case, CESoPSN packet MUST be prepended with an MPLS label stack including: Vainshtein et al. Expires December-2002 [Page 29] TDM Circuit Emulation Service over PSN June 2002 1. A VC label entry (see [MARTINI-TRANS] or [KOMPELLA]). This entry acts as the multiplexing layer header. It MUST be present in the stack and MUST be marked as residing at the bottom of the stack 2. A tunnel label entry. This label, if present, acts as the PSN header and must immediately precede the VC label entry. It MAY be omitted in some situations. This combination of PSN and multiplexing layers does not provide either frame length information or ability to detect misconnections. The former is not necessary for CESoPSN but limits ability to detect malformed packets in case of a very short packet payload. The misconnection detection functionality can be provided using the following considerations: 1.The pattern in the first four bits following the bottom label ('1000') can be used as indication of an RTP header as it is distinct from any of the following: a. IPv4 pattern ('0100') b. IPv6 pattern ('0110') c. Pattern produced by Layer 2 services over MPLS encapsulated in accordance with [MARTINI-ENCAP] and using control word ('0000') 2.The SSRC field of the RTP header may be further used to detect misconnection. MPLS tunnels are conventionally established using various signaling protocols. As a consequence, parameters used for setup and teardown of CESoPSN tunnels should be mapped to data elements of these protocols. A3. L2TP PSN Note: The text below does not define a generic RTP/L2TPv3 stack. Such a work is clearly out of scope of this document. CESoPSN packets may be carried in L2TPv3 tunnels over IP (see [L2TPv3]) that would act as an alternative multiplexing layer over IP. Since L2TPv3 provides both data and control plane for tunnel establishment, parameters describing payload and encapsulation layers should be defined as AVPs to allow single-ended setup and teardown of CESoPSN PWs. L2TPv3 tunnels represent a multiplexing layer with an optional ability to detect misconnections using 32-bit or 64-bit "cookies". As a consequence, the PSN operator may choose between the L2TPv3-based and SSRC-based misconnection detection techniques for CESoPSN PWs. IP represents a PSN layer with inherent ability to infer the payload size from the header. As a consequence, malformed packets detection should consider actual payload size. Vainshtein et al. Expires December-2002 [Page 30] TDM Circuit Emulation Service over PSN June 2002 ANNEX B. A COMMON CE APPLICATION STATE SIGNALING MECHANISM A PW that requires conveyance of CE application state signals that must be synchronized with data carries encoded CE applications in special signaling packets using: o An additional PT value allocated for this purpose from the range of unused values (see [IANA]). This value MUST be different from one allocated for the TDM data packets for the same PW o An additional SSRC value that MUST be different from one used for the data packets in order to allow a separate numbering sequence for the signaling packets o A sequence numbering scheme that does not depend on one used for the data packets. This allows re-use of common sequence numbers-based mechanisms (like reordering and detection of lost packets) for the data packets for all types of circuits General format of the signaling packets is shown in Fig. B.1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Encoded CE Application State | +-- --+ | ... | +-- --+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B.1. Generic Format of Signaling Packets Handling of loss of signaling packets is not required; as a consequence, detection of loss of these packets is not required either. The RTP header of the signaling packets is used in the following way: 1. V (version) is always set to 2 2. P (padding) MAY be used in accordance with the application- specific CE state encoding rules 3. X (header extension) is always set to 0 4. CC (CSRC count) is always set to 0 Vainshtein et al. Expires December-2002 [Page 31] TDM Circuit Emulation Service over PSN June 2002 5. M (marker) is set to 1 to for "urgent" signaling packets. The CE application state carried in these packets will be conveyed to the CE at the egress of the PW immediately, without any re- synchronization with the data. State carried in "normal" signaling packets will be conveyed to the CE at the PW egress after re-synchronization with the TDM data 6. PT (payload type) is used to distinguish between packets carrying the packetized TDM data and signaling packets. In accordance with that, CESoPSN PWs using the CE application state signaling mechanism MUST: a) Allocate an additional PT value from the range of dynamic values (see [RTP-TYPES]) for its signaling packets. The allocation is done during the PW setup and MUST be the same for both PW directions b) The PE at the PW ingress MUST set the PT value in the RTP header of signaling packets to the allocated value c) The PE at the PW egress MUST use this value to distinguish between TDM data and signaling packets. 7. The SSRC (synchronization source) value in the RTP header of signaling packets MUST be different from that used by the data packets 8. Sequence number is generated and processed in accordance with the rules established in [RFC1889]. There should be no connection between the sequence numbers used by the data and signaling packets 9. Timestamps are used for re-synchronization between TDM data and CE application state signals at the PW egress: a) Their values are generated in accordance with the rules established in [RFC1889] b) Frequency of the clock used for generating timestamps MUST be a multiple of 8 KHz and SHOULD be the same as that used for the data packets 10. Each PE terminating the PW SHOULD send RTCP sender reports (see RFC1889], Section 6.3.1) for the clock sources used for generation of timestamps of both TDM data and signaling packets to its peer: a) These packets MAY be limited only to the header and 'Sender Info' sections b) The PE receiving these packets SHOULD use the information contained in the 'Sender Info' in order to map (approximately) timestamps received in the signaling packets to these received in the data packets. Signaling packets are generated by the ingress PE in accordance with the following logic (adapted from [RFC2833]): 1. The CESoPSN signaling packet with the same information is sent 3 times at an interval of 5 ms under one of the following conditions: a) The CESoPSN PW has been set up. These packets MUST be marked as "urgent" Vainshtein et al. Expires December-2002 [Page 32] TDM Circuit Emulation Service over PSN June 2002 b) A change in the CE application state has been detected. If another change of the CE application state has been detected during the 15 ms period, this process continues c) Loss of packets defect has been cleared. These packets SHOULD be marked as "urgent" d) Remote Loss of Packets indication has been cleared (after previously being set) These packets SHOULD be marked as "urgent" 2. Otherwise, the CESoPSN signaling packet with the current CAS state information is sent every 5 seconds. These rules allow fast probabilistic recovery after loss of a single signaling packet as well as deterministic (but, possibly, slow) recovery following PW setup and PSN outages. Encoding of CE application state for various common applications will be considered in separate documents. Vainshtein et al. Expires December-2002 [Page 33]