Network Working Group Alexander ("Sasha") Vainshtein Israel Sasson Akiva Sadovski Internet Draft Axerra Networks Expiration Date: Eduard Metz August 2002 KPNQwest Tim Frost Zarlink Semiconductor February 2002 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) draft-vainshtein-cesopsn-02.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 this document complements similar work for SONET/SDH circuits. Proposed PW encapsulation uses RTP for clock recovery and supports signaling between Provider Edge (PE) devices. Encapsulation proposed in this document may be extended to low-rate SONET/SDH traffic as well. TABLE OF CONTENTS 1. Introduction 3 2. Summary of Changes from the -01 Revision 3 Vainshtein et al. [Page 1] TDM Circuit Emulation Service over PSN August 2002 3. Terminology and Reference Models 4 3.1. Terminology 4 3.2. Reference Models 5 3.2.1. Generic Models 5 3.2.2. Synchronization Considerations and Deployment Scenarios 5 3.2.3. Service Examples 6 4. Scope and Requirements 7 4.1. Emulated Services 7 4.1.1. PDH Circuits 7 4.1.2. SONET/SDH Circuits 7 4.2. Scope 7 4.3. Generic Requirements 7 4.3.1. Relevant Common PW Requirements 7 4.3.2. Common Circuit Payload Requirements 8 4.3.3. The Principle of Minimal Intervention 8 4.4. Service-Specific Requirements 8 4.4.1. Interworking 8 4.4.2. Network Synchronization Schemes 8 4.4.3. CE Signaling 9 4.4.4. Latency and Encapsulation Effectiveness 9 4.4.5. Fault Detection and Handling 10 4.4.6. Performance Monitoring 10 4.4.7. Bandwidth Saving 10 4.4.8. Adaptation of the Jitter Buffer 10 5. CESoPSN Encapsulation 10 5.1. Generic CESoPSN Format 10 5.2. CESoPSN Header 11 5.2.1. Usage of RTP Header 11 5.2.2. Usage and Structure of the Control Word 12 5.3. Payload Data Format 13 5.3.1. Transparent N*DS0 Circuits 14 5.3.2. N*DS0 circuits with CAS 15 5.3.3. Unstructured TDM Circuits 16 6. CESoPSN Operation 17 6.1. Payload Parameters 18 6.1.1. PW Type 18 6.1.2. Circuit Bit Rate 18 6.2. Encapsulation Layer Parameters 19 6.2.1. Usage of Control Word 19 6.2.2. RTP Payload Type 19 6.2.3. Payload Bytes 19 6.2.4. Timestamp Resolution 20 6.2.5. Synchronization Source ID 20 6.2.6. Timestamp Generation Mode 20 6.3. End Service Inactivity Behavior 20 6.4. Description of the IWF operation 20 6.4.1. PSN-bound Direction 20 6.4.2. CE-bound Direction - Normal Operation 21 6.4.3. IWF Loopback 22 6.5. CESoPSN Defects 22 6.5.1. Misconnection 22 6.5.2. Re-Ordering and Loss of Packets 23 6.5.3. Malformed Packets 23 Vainshtein et al. Expires May-2002 [Page 2] TDM Circuit Emulation Service over PSN August 2002 6.5.4. Loss of Synchronization 24 6.6. Performance Monitoring 24 6.6.1. Errored Data Blocks 24 6.6.2. Errored, Severely Errored and Unavailable Seconds 25 6.7. QoS Issues 25 7. RTP Payload Format Considerations 25 7.1. Resilience to moderate loss of individual packets 25 7.2. Ability to interpret every single packet 25 7.3. Non-usage of the RTP Header Extensions 25 7.4. Compression of RTP headers 25 8. Congestion Control (RFC 2914) Conformance 26 9. FFS Issues 26 10. Security Considerations 26 11. Applicability Statement 26 12. IANA Considerations 28 13. Intellectual Property Considerations 28 ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN 32 ANNEX B. EMULATION OF SONET/SDH CIRCUITS 34 1. Introduction This document describes requirements for edge-to-edge emulation of time division multiplexed (TDM) digital signals defined in Plesiochronous Digital Hierarchy (PDH), see [G.703], [G.704], [T.107] [T1.103] and [T1.107a] and a corresponding encapsulation technique. 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 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 native PDH traffic is generated by CE devices and does not depend upon the way this traffic reaches PE devices. However, its use may be extended to carrying SDH traffic as "unstructured TDM", thus providing an alternative to the approach defined in [MALIS]. 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 -01 Revision Note: This section will be removed from the final document. 1. A section on generic and service-specific requirements for edge-to-edge emulation of TDM circuits has been added 2. Fractional E1/T1 has been consistently replaced with N*DS0 Vainshtein et al. Expires May-2002 [Page 3] TDM Circuit Emulation Service over PSN August 2002 3. Support of channel-associated CE signaling (CAS) for N*DS0 services based upon the techniques defined in [RFC2833] has been added 4. The structure of the control word has been aligned with the [MARTINI-ENCAP] 5. References have been updated in accordance with the latest developments 6. RTP Payload Types have been decoupled from PW types. Dynamic allocation of PT values will be used instead 7. Most of the text that should logically belong to more generic PWE3 documents and/or tutorials has been removed 8. In-band CESoPSN loopback commands have been removed 9. G.826-compatible PM parameters for CESoPSN have been defined 10. A brief description of adaptive jitter buffer behavior has been added. 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. However: o The terms 'CE-bound' and 'PSN-bound' are consistently used instead of 'outbound' and 'inbound' when describing traffic directions o The term "Interworking function" (IWF) is often used for describing the protocol operation with explicit references to CE-bound or PSN-bound direction of the IWF. Some terms and acronyms 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 Channel-Associated Signaling (CAS) is one of several signaling techniques used by the telephony applications to convey various states of these applications (e.g., off-hook and ob- hook). CAS uses a certain, circuit-specific multiframe structure that is imposed on the TDM bit stream and a predefined association between the relative timeslot (= channel) number within this stream and position of certain bits within this multiframe structure. Up to 16 application states can be distinguished and signaled (see [G.704] for details). Vainshtein et al. Expires May-2002 [Page 4] TDM Circuit Emulation Service over PSN August 2002 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]. 3.2.2. Synchronization Considerations and Deployment Scenarios Two basic issues must taken into account regarding possible synchronization techniques for emulation of circuit-oriented services: o Can all the PE devices of the given pseudo-wire domain (PWD) be synchronized? Or, in more precise terms, is the same high- quality synchronization source available to all the PE devices in the given PWD? o Is the CE device synchronized to the same source as its 'local' PE? The answer to the first question depends upon design of the specific PSN. E.g. PE devices in a PSN based entirely on POS links can be easily synchronized while PE devices of a PSN based on Gigabit Ethernet links (or on a mix of Gigabit Ethernet and POS) would as often as not remain unsynchronized. The answer to the second question depends on specifics of the customers served by the PSN operator. In particular, if the CE devices are just nodes in the customers' TDM networks with their own synchronization schemes, they would probably continue to use these schemes even if the PSN is fully synchronized. Combinations of answers to these basic questions provide at least three viable deployment scenarios: 1. "One Synchronous Network" Scenario, i.e.: a. The same high-precision synchronization source is available in all the PE devices of the given PSN b. This synchronization source is also used by all the CE devices terminating TDM end services of PWs crossing the PSN c. The PW mechanisms must provide compensation only for the packets inter-arrival jitter introduced by the PSN 2. "Synchronous Carriers' Carrier" Scenario, i.e.: a. The same high-precision synchronization source is available in all the PE devices of the given PSN b. Each Emulated circuit connects two CEs that are either loop-timed to the corresponding PE or synchronized to their own synchronization source Vainshtein et al. Expires May-2002 [Page 5] TDM Circuit Emulation Service over PSN August 2002 c. The PW must carry the difference between the PSN clock and the CE clock over the PSN as well as compensate the packets' inter-arrival jitter introduced by the PSN 3. "Asynchronous Carriers' Carrier" Scenario, i.e.: a. Each PE uses its own synchronization source. The quality of this source is selected in accordance with requirements of the emulated services (e.g., a Stratum 4 clock is sufficient for E1 and T1 services) b. Each emulated circuit connects two CEs that are either loop-timed to the corresponding PE or synchronized to their own synchronization source c. Every direction of the PW must carry the original line clock of its end service across the PSN as well as compensate for the packets' inter-arrival jitter introduced by the PSN. 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=|====|M13|===========|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: o As a physical T1 line (between CE-1 and PE-1) o 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). M23 is a PDH multiplexor o 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). Vainshtein et al. Expires May-2002 [Page 6] TDM Circuit Emulation Service over PSN August 2002 4. Scope and Requirements 4.1. Emulated Services 4.1.1. PDH Circuits This specification describes service-specific encapsulation layer for edge-to-edge emulation of the following TDM services over a PSN: 1. Structured services: a. Transparent N*DS0, 1 <= N <= 31 as described in [G.704]. b. N*DS0 with channel-associated signaling (CAS) as described in [G.704], 1<= N <= 30 2. Unstructured services a. Unstructured E1 as described in [G.704] b. Unstructured T1 (DS1) as described in [T.157a] c. Unstructured E3 as defined in [G.751] d. Unstructured T3 (DS3) as described in [T.157a] 4.1.2. SONET/SDH Circuits Encapsulation layer described in this specification MAY be, with some modifications, also used for emulation of unstructured "low- rate" (STS-1/STM-0, STS-3c/STM-1) SONET/SDH circuits. Details are discussed in Annex B. 4.2. Scope This specification defines only the encapsulation layer for edge-to- edge emulation of TDM services mentioned in Section 4.1. In accordance with the logical protocol layering architecture for PWE3, the encapsulation layer MUST NOT be dependent upon specific instantiations of: 1. The PSN layer (i.e. IPv4, IPv6 or MPLS). In order to satisfy this requirement, encapsulation should be used on packets of fixed size to avoid possible need in the PSN-specific optional length service 2. Multiplexing layer. In order to satisfy this requirement and, at the same time, to allow detection of 'stray packets' the encapsulation header SHOULD provide some means for identifying the packets as belonging to the PW. 4.3. Generic Requirements Note: This and the following section should be split into a separate requirements document. 4.3.1. Relevant Common PW Requirements The encapsulation layer for TDM services considered in this document should comply with the following common PW requirements defined in [PWE3-REQ]: 1. Conveyance of Necessary L2/L1 Header Information - relevant only for TDM structured services Vainshtein et al. Expires May-2002 [Page 7] TDM Circuit Emulation Service over PSN August 2002 2. Support of Multiplexing and Demultiplexing if supported by the native services - relevant for N*DS0 circuits with or without CAS 3. Handling Control Messages of the Native Services - relevant only for structured TDM services 4. Consideration of the PSN Tunnel Header Overhead (see also Section 4.4.4 below) 5. Detection and handling of PW faults (see also Section 4.4.5 below). In particular, ability to detect loss of packets SHOULD be supported in order to allow differentiation between outages of the emulated service resulting from PSN problems and these resulting from problems beyond the PSN 6. Clock Recovery (see also Section 4.4.2 below). 4.3.2. Common Circuit Payload Requirements All the services considered in this document belong to the generic 'Circuit Payload' type defined in [PWE3-FW], Section 3.5.2.1.1. Accordingly, the encapsulation layer MUST provide the common Sequencing service and SHOULD provide timing information. The encapsulation layer for the Circuit Payload services does not necessarily have to provide the length service. 4.3.3. The Principle of Minimal Intervention The encapsulation layer SHOULD comply with the principle of minimal intervention as described in [PWE3-LAYERS], Section 4.3.5. 4.4. Service-Specific Requirements 4.4.1. Interworking 1. The encapsulation layer MUST support network interworking between end services of the same type and bit-rate. 2. The encapsulation layer SHOULD remain unaffected by specific characteristics of connection between the end services and PE devices at the two ends of the PW (see service examples in Section 3.2.3 above). 4.4.2. Network Synchronization Schemes The encapsulation layer MUST be applicable to all the network synchronization schemes mentioned in Section 3.2.2. If the same high-quality synchronization source is available to all the PE devices in the given domain the encapsulation layer SHOULD be able to infer additional benefits (e.g., facilitate better reconstruction of the native service clock) from this fact. Vainshtein et al. Expires May-2002 [Page 8] TDM Circuit Emulation Service over PSN August 2002 4.4.3. CE Signaling Unstructured TDM services do not usually require any special mechanisms for carrying CE signals as these would be carried as part of the emulated service. Structured TDM services may require application-specific CE signaling. In some cases this signaling may require synchronization with the data. E.g., code-associated signaling (CAS) reflects the state of telephony applications (like off-hook and on-hook) that must be passed across the emulated service and synchronized with data to allow normal operation of these applications. The encapsulation layer SHOULD support signaling of state of CE applications for the relevant services providing for: o Multiplexing of application-specific CE signals and data of the emulated service in the same PW o Synchronization (within the application-specific tolerance limits) between CE signals and data at the PW egress o Probabilistic recovery against possible accidental loss of signaling packets in the PSN o Deterministic recovery of the CE application state after PW setup and network outages. Some types of CE signaling associated with the TDM circuits (e.g., performance monitoring requests and responses, requests to operate and release loopbacks etc.) do not reflect application state and hence do not require synchronization with data. As a consequence, these signals can be passed out-of-band and do not have to be supported by the encapsulation layer. The payload format for the 'signaling' packets MAY be application- specific. 4.4.4. Latency and Encapsulation Effectiveness The encapsulation layer SHOULD allow for an effective trade-off between the following requirements: 1. Effective PSN bandwidth utilization. Assuming that the size of encapsulation layer header does not depend on the size of its payload, increase in the packet payload size results in increased efficiency. 2. Low edge-to-edge latency. Low end-to-end latency is the common requirement for Voice applications over TDM services. Packetization latency is one of the components comprising edge-to-edge latency and decreases with the packet payload size. Vainshtein et al. Expires May-2002 [Page 9] TDM Circuit Emulation Service over PSN August 2002 4.4.5. Fault Detection and Handling The encapsulation layer for edge-to-edge emulation of TDM services SHOULD, separately or in conjunction with the lower layers of the pWE3 stack, provide for detection of the following defects: 1. Misconnection 2. Loss of packets. Special importance of detection of this defect has been explained in Section 4.3.1 above 3. Malformed packets 4. Loss of synchronization. 4.4.6. Performance Monitoring The encapsulation layer for edge-to-edge emulation of TDM services should provide for collection of performance monitoring (PM) data that is compatible with the parameters defined for 'classic', TDM- based carriers of these services (see [G.826] for details). 4.4.7. Bandwidth Saving The encapsulation layer should provide for saving the PSN bandwidth by not sending invalid data. 4.4.8. Adaptation of the Jitter Buffer The encapsulation layer SHOULD allow adaptation of the jitter buffer size to the actually observed level of the packets' inter-arrival jitter while maintaining acceptable levels of errors that are introduced by such an adaptation. Note: The meaning of 'acceptable level of errors' depends on the application using the emulated service. In particular, Voice applications can tolerate loss or insertion of a single octet in a contiguous sequence of several non-erroneous octets. (In case of insertion, it is customary to repeat the previous, non-erroneous, octet.) 5. CESoPSN Encapsulation 5.1. Generic CESoPSN Format CESoPSN packets use format shown in Fig. 2 below. Vainshtein et al. Expires May-2002 [Page 10] TDM Circuit Emulation Service over PSN August 2002 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 or CE signaling data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. CESoPSN 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: o V (version) is always set to 2 o P (padding) is always set to 0 o X (header extension) is always set to 0 o CC (CSRC count) is always set to 0 o M (marker) is set to 0 to for CESoPSN packets carrying PDH circuits. CESoPSN packets carrying unstructured SONET/SDH circuits MAY set this bit to 1 to distinguish packets that carry the framing octets o PT (payload type) is used to distinguish between packets carrying the packetized TDM data and packets carrying CE signaling. At least one PT value should be allocated from the range of dynamic values (see [RTP-TYPES]) for every CESoPSN PW. Allocation is done during the PW setup and MUST be the same for both PW directions. The PE at the PW ingress MUST set the PT value in the RTP header to the allocated value. The PE at the PW egress MAY use this value to detect malformed packets. An additional PT value from the same range MUST be allocated for CESoPSN PWs supporting in-band CE signaling (see Section 5.3.2 below) o 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] Vainshtein et al. Expires May-2002 [Page 11] TDM Circuit Emulation Service over PSN August 2002 o Timestamp is used primarily for carrying timing information over the network. Their values are used in accordance with the rules established in [RFC1889]. Frequency of the clock used for generating timestamps MUST be a multiple of 8 KHz. Possible modes of timestamp generation are discussed below o The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections. Note: The same PT value can be safely allocated for 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 time stamps using the clock recovered from the incoming TDM bit stream 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. 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: o Differentiation between the PSN problems and the problems beyond the PSN as causes for the emulated service outages o Saving bandwidth by not transferring invalid data (AIS, idle code) o Signaling problems detected at the PW egress to its ingress Consequently, usage of the CESoPSN Control Word is the recommended default. 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|A|I|L|T|Z| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Structure of the CESoPSN Control Word Vainshtein et al. Expires May-2002 [Page 12] TDM Circuit Emulation Service over PSN August 2002 o Bits 0-3 MUST be set to 0 at ingress and MUST be ignored at egress o Bit A - carries Local AIS indication. If set, represents AIS of the carried unstructured circuit. A packet with the A bit set MAY carry no payload o Bit I - carries Local Idle Code indication. If set, represents the Idle Code in the payload of a N*DS0, a N*DS0 with CAS or an unstructured T3 circuit. A packet with the I bit set MAY carry no payload o Bit L - carries Remote Loss of Packets indication of the PW carrying CESoPSN, i.e., this bit 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 T - carries Remote Synchronization Problem indication. o Bit Z - if set, indicates that the CESoPSN IWF operates under a PW loopback command (regardless of the origin of this command). If cleared, indicates normal CESoPSN IWF operation o Reserved - these bits are reserved for possible future use. Currently they MUST be set to 0 at ingress and ignored at egress. Notes: 1. Either A or I bit (but not both) can be set in the CESoPSN control word. 2. Information about lost packets (carried via the L bit) can be used at ingress as an indication to resynchronize CE application state, see Section 5.3.2 below. 5.3. Payload Data Format A single CESoPSN packet always contains one or more native circuit frames of the carried circuit. 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 save from unstructured T1 are octet-aligned. The T1 native circuit frame (193 bits) is not, 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 (see Section 4.4.4 above) o Path MTU limitations in order to avoid fragmentation of CESoPSN packets This specification assumes that the number of native service frames in a CESoPSN packet is: o Defined during the PW setup and remains constant for the duration of a PW. Such an arrangement simplifies implementation because it implies that the CESoPSN packets are transmitted at a constant rate Vainshtein et al. Expires May-2002 [Page 13] TDM Circuit Emulation Service over PSN August 2002 o The same for both directions of the PW. Such an arrangement simplifies signaling and processing of backwards problem indications. 5.3.1. Transparent N*DS0 Circuits The payload data format for transparent N*DS0 circuits is shown in Fig. 4 below (N - number of timeslots in the circuit, 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. 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 4. Payload structure for a N*DS0 Circuit CESoPSN-based emulation of a transparent N*DS0 TDM circuit can be considered as "bundling" of N independent DS0 circuits (see [PWE3- REQ], Section 2.1.3). 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. Vainshtein et al. Expires May-2002 [Page 14] TDM Circuit Emulation Service over PSN August 2002 5.3.2. N*DS0 circuits with CAS A PW that emulates an N*DS0 circuit with CAS assumes that CE devices are PSTN switches that synchronize the state of each of N DS0 channels using channel-associated signaling. This PW carries TDM data in format described in the previous section. In addition, it carries the CAS state vector of each CE 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 o The signaling payload format described in Fig. 5 below. Format of the 32-bit timeslot signaling word is defined in [RFC2833] Section 3.5 and Section 3.14, and numbering of timeslots corresponds to that of the "columns" in the data packets' payload, see Fig. 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timeslot signaling word for TS-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timeslot signaling word for TS-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timeslot signaling word for TS-N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. Payload of a Signaling Packet for a N*DS0 Circuit with CAS Note: The "volume" field defined in the [RFC2833] Section 3.5 is not used with CAS events. CESoPSN does not require handling of loss of signaling packets; as a consequence, detection of loss of these packets is not required either. On the other hand, the same synchronization source MUST be used for timestamps in both signaling and data packets in order to synchronize data and signaling within reasonable limits. Vainshtein et al. Expires May-2002 [Page 15] TDM Circuit Emulation Service over PSN August 2002 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 b. A change in CAS state of one of the timeslots has been detected. If another change of CAS state has been detected during the 15 ms period, this process continues c. Loss of packets defect has been cleared d. Remote Loss of Packets indication has been cleared (after previously being set) 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. 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 circuit with an octet-aligned native circuit frame MUST contain one or more native circuit frames of the carried circuit, but no alignment with the framing structure of the service is required. 5.3.3.1 "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 circuit into the general CESoPSN framework, a special "T1 in E1" payload format (similar to one defined in [G.802]) is used as shown in Fig 5 below (M = number of native frames in the CESoPSN packet, D denotes the payload data bits). Vainshtein et al. Expires May-2002 [Page 16] TDM Circuit Emulation Service over PSN August 2002 "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 and hence support of this mode does not require a T1 framer in PE. 6. CESoPSN Operation Note: This section includes non-normative information and implementation considerations. These elements will be moved to an appropriate Appendix in the next update. Edge-to-edge circuit emulation of a TDM circuit 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 This document defines 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. Vainshtein et al. Expires May-2002 [Page 17] TDM Circuit Emulation Service over PSN August 2002 Description of the CESoPSN-based edge-to-edge circuit 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 N*DS0 with CAS - 66 o Unstructured E1 - 67 o Unstructured T1, bit stream mode - 68 (not defined in this specification) o Unstructured T1, T1-in-E1 mode - 69 o Unstructured E3 - 70 o Unstructured T3 - 71 o Unstructured SONET/SDH - 72 (see Annex B). 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 N*DS0 with CAS - N, 1 <= N <= 30 o Unstructured E1 - 32 o Unstructured T1, T1-in-E1 mode - 25 o Unstructured E3 - 537 o Unstructured T3 - 699 o Unstructured STS-1 - 810 o Unstructured STM-1 - 2430 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. Unstructured STS-1 and STM1 are considered in Annex A. Vainshtein et al. Expires May-2002 [Page 18] TDM Circuit Emulation Service over PSN August 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 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 1. One PT value MUST be allocated from the range of dynamically allocated payload types for each CESoPSN PW for use in the data packets: a. The same value MUST be allocated for both directions of the PW b. Ingress PW MUST set the PT in the RTP header of all the data packets to the allocated value c. Egress PW MAY use this value to detect non-data PW packets. These packets can be either relegated to signaling or considered as malformed 2. For emulation of a N*DS0 circuit with CAS, 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: a. It MUST be different from the PT value allocated for data packets b. The same value MUST be allocated for both directions of the PW c. Ingress PW MUST set the PT in the RTP header of all the signaling packets to the allocated value 3. 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: o The number of payload bytes MUST be the same for both directions of the PW o 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 circuit (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 o 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 May-2002 [Page 19] TDM Circuit Emulation Service over PSN August 2002 Note: For N*DS0 with CAS circuits this parameter defines the number of payload bytes in the data packets only. The number of payload bytes in the signaling packets is inferred from the encoded circuit bit rate in the obvious way. 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 This parameter accepts at least the following two values corresponding to operation modes described in Section 5.2.1: o Absolute (1) o Differential (2). 6.3. End Service Inactivity Behavior While the PW is inactive: o Each unstructured end service MUST send AIS to its prospective CE o Each structured end service MUST send an appropriate Idle Code to its prospective CE 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 1. End service data is packetized in accordance with the number of payload bytes specified. For N*DS0 services, the packetized data are aligned with the native circuit frames as described in Section 5.3.1 2. Sequence numbers and timestamps representing the selected synchronization clock are inserted in the CESoPSN headers Vainshtein et al. Expires May-2002 [Page 20] TDM Circuit Emulation Service over PSN August 2002 3. CESoPSN, multiplexing and PSN headers are prepended to the packetized circuit data 4. Resulting packets are transmitted via the PSN 5. If the PE detects any outage of the incoming an 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. 6. If the PE detects an Idle Code condition of the incoming an unstructured T3 end service, or an AIS-producing condition is detected in the incoming 'carrier service' of an N*DS0 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. 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 - Normal Operation 1. 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. 2. Initially the Jitter buffer is filled with the appropriate inactivity (AIS or Idle) code. 3. Immediately after start, IWF: a. 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 b. 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 c. Signals the CE-bound direction of the local IWF to transmit CESoPSN packets with the T bit set (if control word is used) 4. Once the jitter buffer contains sufficient amount of data (usually half of its capacity), the IWF starts replay of this Vainshtein et al. Expires May-2002 [Page 21] TDM Circuit Emulation Service over PSN August 2002 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. At the same moment it signals the PSN-bound direction of IWF to clear the T bit in the CESoPSN packets it transmits (if the control word is used) 5. 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. 6. 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) 7. The CE-bound direction of the IWF: a. Performs detection, correlation and handling of CESoPSN faults as described in Section 6.5 below b. Collects the PW Performance Monitoring data as defined in Section 6.6 below 8. CE application state signals received in the signaling packets SHOULD be synchronized with data using the timestamps and inserted (in an appropriate format) into the CE-bound TDM stream. Signals that cannot be inserted into the CE-bound TDM stream due to the local format limitations MUST BE ignored. Any aspects of translation of values of CE signals are out of scope of this specification. 6.4.3. IWF Loopback An IWF loopback for the CESoPSN IWF MAY be set and cleared by an external (management) command. Once such a loopback is set, the IWF will loop packets coming from the PSN back to the PSN. In addition it will mark these packets by setting Z bit in the CESoPSN control word. Once the loopback is cleared, the IWF resumes its normal operation. 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 Vainshtein et al. Expires May-2002 [Page 22] TDM Circuit Emulation Service over PSN August 2002 o 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. Out-of-order packets that cannot be reordered 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 L) 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 o 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 Its jitter buffer MUST be filled with the appropriate amount of the AIS (or Idle) code replay to be replayed into the relevant PWES 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. Vainshtein et al. Expires May-2002 [Page 23] TDM Circuit Emulation Service over PSN August 2002 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. 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, e.g.: o For E1 and T1 circuits, a data block contains 4 native service frames o For E3 and T3 circuits, a data block contains one native service frame etc. 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 Vainshtein et al. Expires May-2002 [Page 24] TDM Circuit Emulation Service over PSN August 2002 o An errored data block is a data block defined in accordance with [G.826] that has experienced at least one error event. 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. 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). Resilience to loss of an individual signaling packet is provided for by the rules described in Section 5.3.2 above. 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: o Value of the SSRC field in the CESoPSN header of data packets remains constant for the duration of a CESoPSN session Vainshtein et al. Expires May-2002 [Page 25] TDM Circuit Emulation Service over PSN August 2002 o Value of the Timestamp field in the CESoPSN header is usually incremented by a fixed value from packet to packet o 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. 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 Usage of RTCP. One particular application to be considered is retrieval of remote problems' indications without the control word o Effect of timestamp resolution on quality of clock recovery in Differential mode. 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 (transparent N*DS0, transparent N*DS0 with CAS, unstructured E1/T1 and unstructured E3/T3) over PSN. Applicability of CESoPSN MAY be extended to low-rate SONET/SDH circuits with minimal modifications. Vainshtein et al. Expires May-2002 [Page 26] TDM Circuit Emulation Service over PSN August 2002 CESoPSN allows carrying both data and clock of TDM circuits across multiple types of PSN. CESoPSN allows carrying CE signaling that requires synchronization with data (e.g., channel-associated signaling (CAS) for Voice applications) 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 uses RTP for carrying the clock across the PSN. The additional CESoPSN header (if used) is a payload format header and hence standard header compression techniques for RTP/UDP/IP profile over links 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. 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 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, the jitter buffer and packets' reordering mechanisms associated with CESoPSN increase resilience of the emulated service to fast PSN rerouting events. Vainshtein et al. Expires May-2002 [Page 27] TDM Circuit Emulation Service over PSN August 2002 12. IANA Considerations This specification requires assignment of new PW Types for CESoPSN PWs as described in Section 6.1. 13. Intellectual Property Considerations 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. Where there is a necessary dependence upon such patents and patent applications in implementing an IETF adopted standard resulting from this document, Axerra Networks will license on fair, reasonable, and non-discriminatory terms to all parties, any patent claims it owns covering such technology, solely to the extent such technology is essential to comply with such standard. Any such license to a party shall start on the date that Axerra Networks and the party enter into an agreement related thereto and shall be granted on the condition that any such party grants to Axerra Networks and its corporate affiliates a reciprocal license under such party's patents for which there is also a necessary dependence. 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 Sim Narasimha 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-FW] Prayson Pate et al, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in progress, February 2002, draft-ietf- pwe3-framework-00.txt [PWE3-LAYERS], Stewart Bryant et al., Protocol Layering in PWE3, Work in Progress, February 2002, pwe3-protocol-layering-01.txt [MALIS] Andrew G. Malis et al, SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation, Work in progress, April 2001, draft- malis-sonet-ces-mpls-04.txt [PWE3-SONET] Andrew G. Malis et al, SONET/SDH Circuit Emulation over Packet (CEP), Work in progress, September 2001, draft-malis-pwe3- sonet-00.txt Vainshtein et al. Expires May-2002 [Page 28] TDM Circuit Emulation Service over PSN August 2002 [KOMPELLA] MPLS-based Layer 2 VPNs, Work in Progress, July 2001, draft-kompella-ppvpn-l2vpn-00.txt [MARTINI-TRANS] Luca Martini et al, Transport of Layer 2 Frames Over MPLS, Work in progress, November 2001, draft-martini-l2circuit- trans-mpls-08.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 Vainshtein et al. Expires May-2002 [Page 29] TDM Circuit Emulation Service over PSN August 2002 [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 [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.103] ANSI T1.103 - 1987. Digital Hierarchy - Synchronous DS3 Format Specification [T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface Rates and Format Specifications (SONET} [T1.107] ANSI T1.107 - 1988. Digital Hierarchy - Format Specification [T1.107a] ANSI T1.107a - 1990. Digital Hierarchy - Supplement to Format Specifications (DS3 Format Specifications) [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 Vainshtein et al. Expires May-2002 [Page 30] TDM Circuit Emulation Service over PSN August 2002 Israel Sasson Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: israel@axerra.com Akiva Sadovski 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@kpnqwest.com Tim Frost Zarlink Semiconductor Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK email: tim.frost@zarlink.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 Vainshtein et al. Expires May-2002 [Page 31] TDM Circuit Emulation Service over PSN August 2002 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. 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: o Unused even UDP ports must be allocated at both PE nodes terminating a CESoPSN PW as part of the PW establishment process o IP and UDP headers must be prepended to each CESoPSN packet o 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. 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. Vainshtein et al. Expires May-2002 [Page 32] TDM Circuit Emulation Service over PSN August 2002 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: o 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 o 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 can 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- Vainshtein et al. Expires May-2002 [Page 33] TDM Circuit Emulation Service over PSN August 2002 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. ANNEX B. EMULATION OF SONET/SDH CIRCUITS B1. Relevant Types of SONET/SDH circuits o STS-1 o STM-1 B2. Native Frame Size and Payload Format Natural delineation of SONET/SDH frames (of abovementioned rates) will produce packets exceeding minimal MTU in some cases. As a consequence, a SONET/SDH frame must be fragmented into several CESoPSN packets will be used. Usage of CESoPSN for unstructured SONET/SDH circuits requires presence of an appropriate framer in the ingress and egress PEs. Each SONET/SDH frame will be fragmented into the Protocol Data Units (PDUs) of equal size. Data belonging to two and more different frames MUST NOT be combined into one PDU. For each SONET/SDH frame only one CESoPSN packet will contain the framing octets (A1, A2) of this frame. Such a packet: o MUST contain these bytes aligned with its payload data (i.e., the 1st octet of the payload MUST contain the 1st A1 byte of a SONET/SDH frame o SHOULD be marked with M bit set to 1 in the RTP header. B3. Synchronization modes External clock sources traceable (in terms of G.781) to the same high quality (at least as defined in G.812) clock source should be available at both PEs for External or Differential timing. B.3. Structure of the Control Word The same bits as defined in Section 5.2.2 are used. However the meaning of the bits are slightly different: o Bit A - if set, represents LOS (e.g., as specified in [G.783]) of the incoming SONET/SDH signal. A packet with the A bit set should not carry any data o Bit I - if set, represents an Out-of-Frame (OOF) condition (e.g., as specified in [G.707]) of the incoming SONET/SDH signal. A packet with the I bit set should not carry any data Vainshtein et al. Expires May-2002 [Page 34] TDM Circuit Emulation Service over PSN August 2002 B4. Packetization and de-packetization During normal operation, the CESoPSN packetizer will receive a fixed rate byte stream from a (physical or logical) SONET/SDH interface. When the whole SONET/SDH frame will be received, it will be partitioned into several blocks of equal size. After that, PSN and multiplexing headers are prepended to it and the resulting CESoPSN packets are transmitted into the PSN. Because all normal CESoPSN packets associated with a specific SONET/SDH channel will have the same length, the transmission of CESoPSN packets for that channel SHOULD occur at regular intervals. At the far end of the packet network, the CESoPSN de-packetizer will receive packets into a jitter buffer, rebuild native SONET/SDH frames, and then play out the received byte stream at a fixed rate onto the corresponding PDH channel. The jitter buffer SHOULD be configurable to account for various network delay behavior patterns. The received packet rate from the packet network should be exactly balanced by the transmission rate onto the SONET/SDH channel, on average. The time over which this average is taken corresponds to the depth of the jitter buffer for a specific CESoPSN channel. The RTP sequence numbers in the CESoPSN heard provide a mechanism to detect lost and/or reordered packets. The CESoPSN de-packetizer MUST detect lost or reordered packets. B6. PSN to SONET/SDH Signals Only CESoPSN defects requiring non-standard treatment are considered. The CESoPSN de-packetizer MAY re-order packets received out of order. If the CESoPSN de-packetizer does not support re-ordering, it MUST drop out-of-order packets. If any of the PDUs comprising a native SONET/SDH frame is lost, the scrambled pattern consisting of valid framing bytes ([G.707], [T1.105]) and all other bytes set to all 1s will be played out. The same pattern will be played out if a malformed packet has been detected. The rationale for this behavior: an SDH node at the egress of a CESoPSN service may continue using the SDH signal received from the egress PE node as its clock source. Vainshtein et al. Expires May-2002 [Page 35]