Network Working Group Alexander ("Sasha") Vainshtein Israel Sasson Akiva Sadovski Internet Draft Axerra Networks Expiration Date: Eduard Metz May 2002 KPNQwest November 2001 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) draft-vainshtein-cesopsn-01.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 -00 Revision 3 3. Terminology and Reference Models 4 3.1. Terminology 4 3.2. Reference Models 5 3.2.1. Generic Models 5 3.2.2. Service Examples 5 Vainshtein et al. [Page 1] TDM Circuit Emulation Service over PSN November 2001 3.2.3. Layering and Protocol Stack Layering Model 5 3.2.4. Timing Reference Models 6 4. Scope 7 4.1. TDM Services 7 4.1.1. Structured vs. Unstructured TDM Circuits 7 4.1.2. PDH Circuits 7 4.1.3. SONET/SDH Circuits 7 4.2. Relevant Types of PSN 7 4.3. Interworking and Signaling 8 4.3.1. CE Signaling 8 4.3.2. PE/PW Signaling 8 4.4. PW OAM 9 4.4.1. Fault detection and Handling 9 4.4.2. PW Maintenance 9 5. Specifics of Pseudo-Wire Emulation for PDH Circuits 9 5.1. Native Frame Size 9 5.2. Synchronization 10 5.3. Conclusion 10 6. CESoPSN Encapsulation 10 6.1. Generic CESoPSN Format 10 6.2. CESoPSN Header 11 6.2.1. Usage of RTP Header 11 6.2.2. Structure of the Control Word 12 6.3. Payload Data Format 13 6.3.1. Fractional E1/T1 Circuits 13 6.3.2. Unstructured TDM Circuits 14 6.3.3. "T1-in-E1" Mode for Unstructured T1 Circuits 14 7. CESoPSN Operation 15 7.1. New PW Types 15 7.2. Circuit Bit Rate 16 7.3. Usage of Control Word 16 7.4. Common L1 (Circuit)PW Layer Parameters 16 7.4.1. Payload Bytes 16 7.4.2. Synchronization Clock Rate 17 7.5. End Service Inactivity Behavior 17 7.6. Description of the IWF operation 17 7.6.1. Outbound Direction 17 7.6.2. Inbound Direction - Normal Operation 17 7.6.3. Inbound-to-Outbound IWF Loopback 18 7.7. CESoPSN Defects 18 7.7.1. Precedence of Faults 18 7.7.2. Misconnection 19 7.7.3. Loss of Packets and Re-Ordering 19 7.7.4. Payload Mistype 20 7.7.5. Loss of Synchronization 20 7.8. QoS Issues 21 8. RTP Payload Format Considerations 21 8.1. Resilience to moderate loss of individual packets 21 8.2. Ability to interpret every single packet 21 8.3. Non-usage of the RTP Header Extensions 21 8.4. Treatment of the decoder internal data-driven state 22 8.5. Compression of RTP headers 22 9. Congestion Control (RFC 2914) Conformance 22 Vainshtein et al. Expires May-2002 [Page 2] TDM Circuit Emulation Service over PSN November 2001 10. FFS Issues 22 11. Security Considerations 23 12. Applicability Statement 23 13. IANA Considerations 24 14. Intellectual Property Considerations 24 ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN 28 ANNEX B. EMULATION OF SONET/SDH CIRCUITS 30 ANNEX C. A COMMON PW SETUP AND TEARDOWN MECHANISM 32 ANNEX D. COMPARISON of DIFFERENT APPROACHES 35 1. Introduction This document describes a method for encapsulating time division multiplexed (TDM) digital signals defined in Plesiochronous Digital Hierarchy (PDH), see [G.704], [T.107] [T1.103] and [T1.107a], for emulation over a packet-switched network (PSN). In this regard this specification complements [MALIS] and [PWE3-SONET]. To support TDM traffic, which includes voice, data, and private leased line service, the network must emulate the circuit characteristics of PDH. 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 (see reference model 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 PWE3 services as described in [PWE3-FW] and satisfies the requirements put forward in [PWE3-REQ]. 2. Summary of Changes from the -00 Revision Note: This section will be removed from the final document. 1. Text related to compression of RTP headers compression has been added 2. Compliance with requirements for congestion handling is described in some detail 3. Explanation of differences between PDH and SDH circuits has been updated 4. Considerations regarding two major applications - "One Network" and "Carriers' Carrier" - have been added 5. The structure of the control word has been simplified and minor bugs fixed 6. References have been updated in accordance with the latest developments Vainshtein et al. Expires May-2002 [Page 3] TDM Circuit Emulation Service over PSN November 2001 7. Comparison of different approaches for carrying PDH traffic over PSN has been added as Annex D (to be removed from the final version of the document). 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 following terms have been originally defined in Section 2 of [PWE3-FW]. The text below has been slightly modified limiting the scope to the services considered in this document: Packet Switched A Packet Switched Network (PSN) is a network Network using IP, MPLS or L2TP as the unit of switching. Pseudo Wire Emulation Pseudo Wire Emulation Edge to Edge (PWE3) is a Edge to Edge mechanism that emulates the essential attributes of a service (such as a T1 leased line) over a PSN. Customer Edge A Customer Edge (CE) is a device where one end of an emulated service originates and terminates. The CE is not aware that it is using an emulated service rather than a "real" service. Provider Edge A Provider Edge (PE) is a device that provides PWE3 to a CE. Pseudo Wire A Pseudo Wire (PW) is a connection between two PEs carried over a PSN. The PE provides the adaptation between the CE and the PW. PW End Service A Pseudo Wire End Service (PWES) is the interface between a PE and a CE. This can be o A physical interface like T1 o A virtual interface like: o T1 carried in DS3 (using M13 or M23 multiplexing structure - see [T1.103]) o T1 carried in VT1.5/VC12 in a SONET/SDH stream Pseudo Wire PDU A Pseudo Wire PDU is a PDU sent on the PW that contains all of the data and control information necessary to provide the desired service. PSN Tunnel A PSN Tunnel is a tunnel inside which multiple PWs can be nested so that they are transparent to core network devices. Vainshtein et al. Expires May-2002 [Page 4] TDM Circuit Emulation Service over PSN November 2001 3.2. Reference Models 3.2.1. Generic Models Generic Network and Signaling Reference Models for PWE3 have been defined in Sections 3.2.1 and 3.2.2 of [PWE3-FW] and are fully applicable for the purposes of this document without any modifications. 3.2.2. Service Examples Fig.1 below presents examples of T1 Emulated Service. These examples have been adapted from ones presented in Section 4.1 of [PWE3-FW]. ___ ___ _/ \ / \ /\ +------+ 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=|====|M23|===========|E|=| | +---+ +-+ / +------+ |(CE-2)| | |-----------|2| +---+ / +------+ +---+ \ +-+ / \ ___ ___ / \_/ \____/ \___/ Figure 1: T1 Emulation Example Diagram In this diagram, T1 end services are perceived by 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 a DS3 using one of possible multiplexing formats (between CE-2 and PE-2, see [T1.103] for details). M23 is a PDH multiplexor implementing muxing of physical T1 lines into DS3 signal o As a virtual T1 signal mapped into a VT1.5 virtual tributary which, in its term is multiplexed in OC-12 (between CE-3 and PE-3 - see [T1.105] or [G.707] for details). The CESoPSN PW discussed in this document should be able to cope with all these use cases in a uniform way. 3.2.3. Layering and Protocol Stack Layering Model This document uses logical protocol layering model described in [BRYANT-LAYERS], Section 1: Payload Layer Data exchanged between CE Vainshtein et al. Expires May-2002 [Page 5] TDM Circuit Emulation Service over PSN November 2001 devices Payload Protocol used to allow The header Convergence Layer effective regeneration of the associated with carried service at egress these two layers Common PW Layer Protocol that provides common (without the PW services required by PWs demuxing field) carrying L1 circuits will be later including demuxing, referred to as sequencing and "the CESoPSN synchronization header" Carrier Protocol used to augment the Empty for PWs Convergence Layer Carrier Layer with services considered in like packet length and this document fragmentation Carrier Layer Protocol used to deliver packets from the ingress PE device to egress one Note: This model represents an alternative to the generic Protocol Stack Reference Model described in Section 3.2.3 of [PWE3-FW]. 3.2.4. Timing Reference Models Section 4.4.1 of [PWE3-FW] describes in detail a timing reference model for a single L1 PW. However, it seems reasonable to expect more than one such PW to be supported by a single PE. This raises the question of possible interaction between clocks for multiple PWs. Timing-wise, two polar scenarios can be considered: "One Network" Scenario In this scenario the same high-precision external clock is available in all the PE devices of the given PSN and, in addition, is used as the synchronization source by all the CE devices terminating L1 PWs crossing the PSN. As a consequence, the L1 PW clock recovery schemes must provide compensation only for the packets inter-arrival jitter introduced by the PSN. "Carriers' Carrier" Scenario L1 PWs connect (otherwise, isolated) components of TDM networks, and each of these networks uses each its own synchronization source(s) and its own timing distribution scheme. Precision of these sources is selected in accordance with the native requirements of the TDM network, so that sources used by different networks may differ accordingly. Each network relies on L1 PWs to be part of its timing distribution scheme in addition to carrying L1 data. This means that the L1 PW clock recovery schemes must provide for: Vainshtein et al. Expires May-2002 [Page 6] TDM Circuit Emulation Service over PSN November 2001 o Compensation of the packets inter-arrival jitter introduced by the PSN o Compensation of the native jitter of the incoming line clock o Recovery, within the standards-defined precision limits, of the native wander of the incoming line clock. Real-life deployment may present a mix of these two use cases, and CESoPSN should be able with such a mix. 4. Scope 4.1. TDM Services 4.1.1. Structured vs. Unstructured TDM Circuits The difference between structured and unstructured TDM circuits is discussed in some detail in [PWE3-FW], Section 4.2.2. CESoPSN may be used for emulating both structured and unstructured PDH circuits and unstructured SONET/SDH Circuits. 4.1.2. PDH Circuits Encapsulation format described in this specification is designed for carrying the following PDH services over a PSN: o Fractional E1/T1 (also referred to as N*DS0). This is the only structured PDH circuit considered in this document. Up to 31 timeslots may be transferred over a structured E1, and up to 24 timeslots - over a structured T1 o Unstructured E1 as described in [G.704] o Unstructured T1 (DS1) as described in [T.157a] o Unstructured E3 as defined in [G.751] o Unstructured T3 (DS3) as described in [T.157a] Note: Fractional E1/T1 circuits with CAS signaling over CESoPSN are left for further study. 4.1.3. SONET/SDH Circuits Encapsulation format described in this specification may be, with some modifications, also applied to unstructured "low-rate" (STS- 1/STM-0, STS-3c/STM-1) SONET/SDH circuits. Details are discussed in Annex B. 4.2. Relevant Types of PSN In accordance with [PWE3-FW] the PW encapsulation for a specific service should be equally applicable to at least the following types of PSN networks: o IP o L2TP o MPLS. Vainshtein et al. Expires May-2002 [Page 7] TDM Circuit Emulation Service over PSN November 2001 The layering model for PW discussed in Section .3.2.3 above allows the following interpretation of this requirement: o IP and MPLS are considered as two different carrier layers o L2TP, L2TPv3, GRE, and UDP are considered as different carrier convergence layers over IP o MPLS can be also considered as a convergence layer over both IP (in the MPLS-in-IP model) and MPLS carrier layers. This document is limited to describing the CESoPSN encapsulation, e.g., the data plane of the payload convergence layer used for carrying circuits listed in Section .4.1 above. This encapsulation can be carried over multiple combinations of Carrier layers and PW demuxing techniques. Some details are described in Annex A. Note: Some preliminary considerations on the control plane for CESoPSN are described in Section .7 and Annex C. 4.3. Interworking and Signaling In accordance with [PWE3-FW] this specification considers only P2P bi-directional services and network interworking. 4.3.1. CE Signaling For unstructured TDM services, CE signaling is carried as part of the PW payload, and hence MUST NOT be treated by the PW mechanisms. For structured TDM services considered in this document CE signaling is terminated by the PE and does not have to be carried over the PSN. There is only one exception to these basic rules: AIS or Idle Code (for both structured and unstructured services) MAY not be carried "as is" over the PSN. Instead, only appropriate bandwidth-conserving AIS or Idle Code indications SHOULD be sent. CESoPSN provides appropriate mechanisms for this purpose. Note: AIS is applicable to unstructured E1/T1 and E3/T3 services while Idle Code is applicable for fractional E1/T1 and unstructured E3/T3 services. 4.3.2. PE/PW Signaling [PWE3-FW] defines PE/PW signaling as a mechanism used for PW setup and teardown. This document does not specify any specific signaling mechanisms for this purpose as it assumes that such a mechanism belongs to the common PW layer, while CESoPSN describes a certain payload convergence layer. However, it defines a set of parameters describing payload and payload convergence layers that MUST be used by the setup mechanism (see Section .7 below). A tentative description of the common PW layer mechanisms for setup and teardown of PWs is given in Annex C. Vainshtein et al. Expires May-2002 [Page 8] TDM Circuit Emulation Service over PSN November 2001 4.4. PW OAM 4.4.1. Fault detection and Handling CESoPSN PW provides for detection of a wide range of defects (misconnection, loss of packets, mistype, loss of synchronization) by the outbound direction of its IWF. These defects are signaled: To the corresponding PWES and, eventually, to the CE To the peer IWF at the other end of the PW. Details are described in Section .7.7 below. 4.4.2. PW Maintenance CESoPSN format allows to set and clear PW loopbacks. Details are described in Section .7.6.3 below. 5. Specifics of Pseudo-Wire Emulation for PDH Circuits In this section we discuss specific characteristics of PDH circuits (e.g., as opposed to SONET/SDH circuits covered by [MALIS]) that justify usage of dedicated techniques for carrying them in PW over PSN. 5.1. Native Frame Size As mentioned in [PWE3-FW], natural delineation for TDM services is a time frame of 125 us. Data units produced by this delineation will be later referred to as the native circuit frames. When it comes to packetization, difference in the line rates results in the following difference between the circuit native frames of a high-rate TDM circuit (e.g., SONET/SDH) and these of a low-rate one (e.g., T1/E1): o Native circuit frames of high-rate TDM circuits in most cases cannot be packetized into a single packet of the underlying PSN. E.g., the native frame size for an STS-3c SPE circuit is 2349 bytes. A STS-1 SPE circuit with its native frame size of 783 bytes is probably a borderline case (exceeds the minimal IP MTU defined in [RFC1122] but can be packetized in a single packet for most modern PSN types). As a consequence, PWs handling these circuits must use some fragmentation techniques o Native circuit frames of low-rate TDM services are relatively short. E.g., the native frame size for an E1 circuit is just 32 bytes. As a consequence, packing multiple native circuit frames into a single packet of the underlying PSN is both possible and advantageous for effective PW operation (reduces overhead). Packing of multiple native circuit frames into a single packet of the underlying PSN results in the following effects: 1. It reduces overhead associated with carrier, carrier convergence and common PW headers Vainshtein et al. Expires May-2002 [Page 9] TDM Circuit Emulation Service over PSN November 2001 2. It saves the PSN switching capacity (i.e., number of packets per second carried by the PW) 3. It may increase requirements on Path MTU between PE devices 4. It increases transport delay of the emulated circuit 5. It increases impact of loss of a single packet on the service outage time. Actual packing factors (i.e., number of native circuit frames per packet) will probably represent a trade-off between beneficial and detrimental effects described above. E.g., packing factor introducing 1 ms packetization delay looks like a good enough trade-off for low- rate services like E1 and T1. 5.2. Synchronization [PWE3-FW] provides, in Section 4.4.2, classification of different techniques of clock recovery for L1 PWs. Some of these techniques explicitly depend upon availability of a common external clock. [PWE3-FW] notes that this "is not commonly available in a data network or in a multi-carrier network". Adaptive clock recovery does not depend upon availability of a common external clock. However, since clock correction cannot occur more than once per received packet, its convergence time is in inverse proportion to the packet rate of the PW. And, of course, the buffer at the PW egress must be sufficient to avoid overrun or underrun during the convergence process, hence introducing additional delay. RTP-based techniques (more complicated than ones described in [PWE3- FW]) allow fast compensation of initial discrepancy between line clock at ingress and local oscillator of egress. Effectiveness of these techniques depends upon: o Quality of local oscillators at PE devices. E.g., Stratum 4 local oscillators are sufficient for recovering E1 and T1 clock o Resolution of timestamps used by RTP. 5.3. Conclusion Both effectiveness and faithfulness of edge-to-edge emulation of PDH circuits over a PSN can be improved by using a dedicated encapsulation format that combines: o Ability to pack multiple native circuit frames into a single packet o Ability to carry timestamps across the PSN. 6. CESoPSN Encapsulation 6.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 November 2001 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-specific Carrier Header | | ... | | PW Demuxing Field | | ... | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CESoPSN Control Word | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | .... | | Packetized TDM data (payload) or maintenance commands/replies | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. CESoPSN Format Usage of the CESoPSN Control Word is RECOMMENDED. However, PE peers MAY agree not to use it in a specific CESoPSN PW as part of the PW setup process. Usage of the CESoPSN control word allows: o To preserve bandwidth by not transferring absent data (AIS, idle code) o To signal problems detected at the PW egress to its ingress o To carry maintenance (loopback) commands from PW ingress to egress. 6.2. CESoPSN Header CESoPSN header includes a fixed RTP header (12 octets) and an optional CESoPSN Control Word (4 octets). 6.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 used in accordance with rules described in [RFC1889], Section 5.1 o X (header extension) is always set to 0 Vainshtein et al. Expires May-2002 [Page 11] TDM Circuit Emulation Service over PSN November 2001 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) carries the PW type code defined in Section . 7.1 below. Egress PE of a CESoPSN PW MAY detect payload mistype defects if it receives packets with PT value that differs from the service type of the PWES o Sequence number and timestamp are used in accordance with the rules established in [RFC1889]. Frequency of clock used for generating timestamps MUST be a multiple of 8 KHz o The SSRC (synchronization source) value in the RTP header is treated as logically belonging to the common PW header and MAY be used for detection of misconnections if the Carrier Convergence layer does not provide for it. Accordingly it is assigned by the common PW layer. Rules of such an assignment are left for further study. 6.2.2. Structure of the Control Word 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|I|L|R|OAM|Z| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Structure of the CESoPSN Control Word o Bit A - if set, represents AIS of the carried unstructured circuit. A packet with the A bit set MUST NOT carry any data 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 I - if set, represents the Idle Data in the payload of a fractional E1/T1 or unstructured T3 circuit. A packet with the I bit set MUST NOT carry any data o Bit R - if set, represents remote synchronization defects' indication. o Bits OAM are used to set and clear remote CESopSN loopbacks. They are interpreted like following: * 00 - a normal CESoPSN packet * 01 - a command to the peer end point to set a CESoPSN loopback. If this command is reliably received by the outbound IWF, it begins transmitting back payload data it receives from the PSN instead of packetized data of its PWES. The IWF under a PW loopback continues to transmit data received from the PSN to its PWES * 10 - a command to clear a CESoPSN loopback. If this command is reliably received by the egress that has been Vainshtein et al. Expires May-2002 [Page 12] TDM Circuit Emulation Service over PSN November 2001 working in the loopback mode, it resumes its normal operation * 11 - illegal value o Bit Z - if set, indicates that the CESoPSN IWF operates under a loopback command (regardless of the origin of this command). If cleared, indicates normal CESoPSN IWF operation o Reserved - for PDH circuits these bits SHOULD be set to 0 at ingress and MUST be ignored at egress. These bits may be used if an unstructured SDH circuit is carried in the CESoPSN format, see Annex B. Notes: 1. Either A or I bit (but not both) can be set in the CESoPSN control word. 2. Some PDH circuits allow to set and clear loopbacks in the remote device using in-band signaling. However, these signals MUST NOT be translated into in-band PW loopback commands: for structured circuits, they MUST be terminated by the local PE (so that the loop in question will be set or cleared between CE and its local PE) while for unstructured circuits they will be carried "as is" to the remote CE (so that the loop will be established between a pair of CE devices). PW loopbacks are established between PE devices as described in Section .7.6.3 below. 3. Information about lost packets (carried via the L bit) can be used at ingress as an indication of congestion in the transport tunnel between ingress and egress PEs (see also Section .9 below). If the PSN supports some traffic engineering capabilities, such an indication may trigger creation of an alternative transport tunnel bypassing congested links and/or nodes. 6.3. Payload Data Format A single CESoPSN packet always contains one or more native service frames of the carried circuit. This arrangement allows to emulate performance monitoring parameters of "classic" carriers of such a circuit (e.g., SONET/SDH). Number of native service frames in a CESoPSN packet MUST be: o Defined during the PW setup and remain constant for the duration of a PW o The same for both directions of the PW. 6.3.1. Fractional E1/T1 Circuits The payload data format for fractional T1/E1 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. Vainshtein et al. Expires May-2002 [Page 13] TDM Circuit Emulation Service over PSN November 2001 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 Fractional E1/T1 Circuit 6.3.2. 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 carried circuit and increase efficiency of CESoPSN. Payload of a CESoPSN packet carrying an unstructured TDM circuit MUST contain a number of octets that is a multiple of the native frame size of the carried circuit, but no alignment with the framing structure of the service is required. 6.3.3. "T1-in-E1" Mode for Unstructured T1 Circuits CESoPSN MAY support a special mode for transferring unstructured T1, which is similar to "T1 in E1" mode defined in [G.802]. Support of this mode does not require framers in PE, and the resulting structure of the CESoPSN payload data for this mode is shown in Fig. 5 (M = number of native frames in the CESoPSN packet, bit D is the most significant bit of the octet in the 25-th column and is considered as part of the payload data. Vainshtein et al. Expires May-2002 [Page 14] TDM Circuit Emulation Service over PSN November 2001 "Timeslots" | 1 | 2 | ... | 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| Data |D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a i r 2| Data |D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t r a ...| Data |D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i c m ...| Data |D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v u e ...| Data |D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e i s ...| Data |D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t M| Data |D| padding | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 5. Payload structure for an Unstructured T1 Circuit Note: This mode allows to overcome possible octet alignment limitations of packetizers and de-packetizers. 7. CESoPSN Operation Description of the CESoPSN operation assumes a reference model similar to ones described in [PWE3-FW], Section 4.1, Fig. 7 and in [MALIS](the latter explicitly introduces jitter buffer), Section 6.1.1, Fig. 5. It includes the following elements: o Two PW ESs (of the same type and bit rate) o Packetizer at the PW ingress o Jitter buffer and de-packetizer at the PW egress. In accordance with the generic PW setup scheme, the CESoPSN operation description includes the following elements: o Definition of new PW types (common PW layer) o Definition of the payload layer-specific parameters and their compatibility rules o Definition of the payload convergence layer specific parameters and their compatibility rules o Definition of the end service inactive state towards CE o Description of the IWF operation in inbound and outbound direction. Details are presented below. 7.1. New PW Types PW types (a.k.a. VC types) have been defined in [MARTINI-TRANS]. PW types used for CESoPSN PW are assigned taking into consideration that: o They belong to the common PW layer. Hence there should be no overlap with types assigned in other PWE3 documents Vainshtein et al. Expires May-2002 [Page 15] TDM Circuit Emulation Service over PSN November 2001 o They are carried in the PT field of the RTP header. Hence they should be limited to 7 bits and produce no overlap with the RTP payload types assigned/reserved by IANA (see [RTP-TYPES]). The following PW types are hence defined in this document for CESoPSN: o Fractional E1/T1 - 65. o Unstructured E1 - 66 o Unstructured T1, bit stream mode - 67 o Unstructured T1, T1-in-E1 mode - 68 o Unstructured E3 - 69 o Unstructured T3 - 70 o Unstructured SONET/SDH - 71 (see Annex B). The CESoPSN setup mechanism MUST NOT allow establishment of a PW of a certain type between end services if at least one of them does not suit this type. 7.2. Circuit Bit Rate Circuit Bit Rate is a parameter that describes specific Payload Layer. It MUST be a 16-bit integer representing the bit rate of the end service as multiple of the basic rate of 64 Kbit/s. Note: This definition scales up to 4 Gbit/s. This by far exceeds both the presently defined CESoPSN and its possible extensions. Note: This parameter MUST be set to 25 for an unstructured T1 circuit Compatibility rule for this parameter states that it MUST be same for both end services of a prospective PW. 7.3. Usage of Control Word This is a Boolean parameter that described payload convergence layer of a CESoPSN PW. TRUE value (default) means that the CESoPSN control work is used. CESoPSN MAY allow negotiation of this parameter, so that the control word will not be used if both sides agree to that. 7.4. Common L1 (Circuit)PW Layer Parameters 7.4.1. Payload Bytes This parameter has been defined in [MARTINI-TRANS]. Compatibility rules include the following: o This parameter MUST be the same for both directions of the PW o This parameter MUST be a multiple of the Circuit Bit Rate (see above). E.g., the value of this parameter for an Unstructured E1 circuit (Circuit Bit Rate = 32) with N native circuit frames Vainshtein et al. Expires May-2002 [Page 16] TDM Circuit Emulation Service over PSN November 2001 packet into a single CESoPSN packet will be 32*N, while for an Unstructured T1 it will be 25*N The size of the resulting PW packet (including all the headers) MUST NOT exceed the path MTU between the participating PEs as provided by the Carrier layer. 7.4.2. Synchronization Clock Rate This parameter is a 16-bit integer representing the synchronization clock rate as a multiple of the basic 8 KHz rate. CESoPSN MAY allow negotiation of this parameter if two different values have been initially specified by end services. (If negotiation is allowed, the PW MAY eventually use the clock rate value, which is the least common denominator of the two suggested values.) 7.5. End Service Inactivity Behavior While inactive, each unstructured end service MUST send AIS to its prospective CE. Idle Code is sent to CE in case of a fractional E1/T1 end service. 7.6. Description of the IWF operation Once started, the CESoPSN IWF operates like following: 7.6.1. Outbound Direction 1. End service data is packetized in accordance with the number of payload bytes specified. For fractional E1/T1 services, chunks of packetized data are aligned with the native circuit frames as described in Section .6.3.1 2. Sequence numbers and timestamps representing the selected synchronization clock are inserted in the CESoPSN headers 3. CESoPSN, Carrier Convergence and Carrier headers are prepended to the packetized circuit data 4. Resulting packets are transmitted via the PSN 5. If the end service detects any of conditions that natively produce the "downstream AIS" condition (LOS, LOF, AIS), the CESoPSN IWF MAY, instead of packetizing AIS, send just packet with the AIS indication flag set to its peer. 6. If the inbound direction of a T3 end service detects an Idle Code condition, the CESoPSN IWF MAY, instead of packetizing Idle Code, send just packet with the Idle Code indication flag set to its peer. Note: LOS detection of the end service does not require a framer in a PE. AIS detection for E1/T1 and E3 also does not require framer, while AIS detection for T3 does. LOF detection (for all types of services) and Idle Code detection (for T3) also require a framer. 7.6.2. Inbound Direction - Normal Operation Vainshtein et al. Expires May-2002 [Page 17] TDM Circuit Emulation Service over PSN November 2001 1. The inbound 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 payload convergence layer at each end of a PW 2. Immediately after start, IWF: a. Begins reception of incoming CESoPSN packets. Carrier, Carrier convergence and common PW headers are stripped from the received packets, and packetized TDM data from the received packets is stored with the timestamps 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 outbound direction of IWF to transmit CESoPSN packets with bit R set 3. 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) transmission clock. At the same moment it signals the outbound direction of IWF to clear R bit in the CESoPSN packets it transmits 4. If transmission clock must be recovered, the timestamps stored with the data are used for this purpose 5. Inbound direction of the CESoPSN IWF performs monitoring and handling of CESoPSN faults as described in the Section .7.7. 7.6.3. Inbound-to-Outbound IWF Loopback An Inbound-to-Outbound IWF loopback for the CESoPSN IWF MAY be set and cleared either by an external (management) or an in-band command. Once such a loopback is set, the outbound IWF will replace packetized TDM data coming from the CE with data received by the inbound IWF from 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. 7.7. CESoPSN Defects 7.7.1. Precedence of Faults Various CESoPSN faults are detected in accordance with a predefined precedence, i.e., if a fault with a higher precedence has been detected, faults of lower precedence are ignored. The following precedence MUST be maintained between various CESoPSN faults: o Misconnection (if is enabled) o Loss of packets o Payload mistype (if enabled) Vainshtein et al. Expires May-2002 [Page 18] TDM Circuit Emulation Service over PSN November 2001 o Loss of synchronization. 7.7.2. Misconnection Misconnection is detected by the PW egress if it receives a packet which has not been originated by what is considers to be the legitimate ingress of this PW. It may be caused by any of the following reasons: o PW mis-configuration o DoS attacks o Network mis-configuration o Forwarding errors (both in the network and in the egress PE) o "Stray packets" in the core PSN. These may appear due to fast reuse of identifiers used by egress PE for demuxing specific PW. Some demuxing techniques (UDP/IP, L2TPv3/IP) inherently provide for ingress identification, while others (e.g., MPLS/MPLS) require carrying such identification in the common PW header (at least logically). CESoPSN MAY detect misconnection faults using SSRC field in the RTP header regardless of the Carrier/Carrier Convergence layers it uses. CESoPSN packets carrying 0 value of SSRC MUST NOT be checked for misconnection using SSRC. CESoPSN packets with detected misconnection MUST be discarded with counter of such packets incremented. If the misconnection condition persists, an appropriate alarm indication SHOULD be sent to the management system. CESoPSN packets with detected misconnection MUST NOT affect the outbound IWF functionality regarding loss of packets detection. 7.7.3. Loss of Packets and Re-Ordering CESoPSN uses packet sequence numbers in the RTP fixed header and locally defined timeouts for detection of: o Out-of-order packets o Lost packets Detailed specification of rules for detection of packet loss is left for further study. Note: CESoPSN implementations SHOULD support limited reordering. Only 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) code to be replayed into the relevant PWES. In addition: o Counter of lost packets must be updated Vainshtein et al. Expires May-2002 [Page 19] TDM Circuit Emulation Service over PSN November 2001 o If the loss-of-packets condition persists, an alarm SHOULD be sent to the management system o Remote lost packets indication flag SHOULD be set in the next packet to be send in the opposite direction of the service. Note: In accordance with the general precedence principle, packets with a misconnection problem MUST NOT affect expected sequence number used for detection of lost packets. 7.7.4. Payload Mistype Payload mistype is detected by the outbound direction of the PW IWF if it receives a packet with PW type or payload size that it does not expect. Payload mistype may be caused by: o Mis-configuration o Problems at ingress or egress PE CESoPSN SHOULD detect payload mistype faults if: o The PT value in the RTP header differs from expected or 0 o The combination of Carrier/Carrier Convergence layers allows definition of the payload size, and this size does not correspond to the Payload Bytes parameter for the specified service. If an in-order packet with a payload mistype problem 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 code replay to be replayed into the relevant PWES o Counter of payload mistype packets must be incremented o If the payload mistype condition persists, an appropriate alarm SHOULD be sent to the management system. 7.7.5. Loss of Synchronization CESoPSN MAY detect two types of loss of synchronization errors: 6.6.5.1. Jitter Buffer Overrun This fault is detected if the jitter buffer at the egress of CESoPSN cannot accommodate the newly arrived CESoPSN packet in its entirety. A CESoPSN packet that cannot be stored in the jitter buffer MUST be discarded. o If the jitter buffer overrun condition persists, an appropriate alarm SHOULD be sent to the management system. In addition, Remote Loss of Synchronization (bit R) flag SHOULD be set in the next packet to be send in the opposite direction of the service. Vainshtein et al. Expires May-2002 [Page 20] TDM Circuit Emulation Service over PSN November 2001 6.6.5.2. Jitter Buffer Underrun This fault is detected if the jitter buffer at the egress of CESoPSN becomes empty before arrival of a new CESoPSN packet. Mis-connection, packets loss, or reception of packets with payload mistype defects SHOULD NOT result in the jitter buffer underrun since erroneous or lost packets would be replaced by an appropriate amount of AIS/idle code data. If the jitter buffer underrun condition persists, an appropriate alarm SHOULD be sent to the management system. In addition, Remote Loss of Synchronization (bit R) flag SHOULD be set in the next packet to be send in the opposite direction of the service. 7.8. QoS Issues As mentioned in Annex C below, the PW setup process may receive identification of the PHB to be used for the specific PW and use it to request appropriate Carrier header from the Carrier layer. EF PHB (see [RFC2598bis]) SHOULD be always used for setup of CESoPSN PWs if it is implemented by the PSN. 8. RTP Payload Format Considerations In accordance with guidelines specified in [RFC2736], the following issues are addressed by this specification: 8.1. Resilience to moderate loss of individual packets Impact of loss of an individual packet may be decreased by decreasing the packet size (with the associated loss of efficiency). In particular, limiting the packet size to 1 ms (i.e., carrying 8 native frames of the carried PDH service) will result in service outage of 50 ms in the presence of a 5% packet loss (the benchmark value discussed in [RFC2736]). 8.2. Ability to interpret every single packet This requirement is met for PDH services since every CESoPSN packet carries a multiple of the native frame of the carried service. 8.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. In addition, alignment with this requirement facilitates usage of standard header compression mechanisms if CESoPSN uses UDP/IP as its Carrier Convergence/Carrier layer (see below). Vainshtein et al. Expires May-2002 [Page 21] TDM Circuit Emulation Service over PSN November 2001 8.4. Treatment of the decoder internal data-driven state This requirement is met by using the CESoPSN Control Word that conveys such encoder internal states as AIS. 8.5. Compression of RTP headers Existing relevant standards ([RFC2508], [RFC3095]) deal with compression of RTP/UDP/IP headers on specific P2P links. Compression techniques defines in these documents is fully applicable for CESoPSN if it uses UDP/IP as Carrier Convergence/Carrier layer. Standard compression of CESoPSN/UDP/IP headers will be very effective, since: o Value of the SSRC field in the CESoPSN header remains constant for the duration of a CESoPSN session 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. On the other hand, link capacity gain for some typical CESoPSN PWs is minimal, e.g.: o If CESoPSN is used to carry an unstructured E1 circuit with packetization delay of 1 ms, even total removal of the RTP header would result in gaining about 92 Kbit/s of the link capacity, i.e., less than 0.01% of capacity of a Gigabit Ethernet link. o Link capacity gain achieved by total removal of the RTP header from CESoPSN carrying an unstructured T1 circuit in the "T1-in-E1" mode would be about 88 Kbit/s. As a consequence, PSN-independent end-to-end compression of RTP headers seems not justified. 9. 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 Carrier 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. 10. 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: Vainshtein et al. Expires May-2002 [Page 22] TDM Circuit Emulation Service over PSN November 2001 o Usage of RTCP o Fractional E1/T1 with CAS (if found to be of sufficient interest) o Explicit specification of rules for detecting loss of packets o Effect of timestamp resolution on quality of clock recovery. 11. Security Considerations This document does not affect the underlying security issues of specific PSN. In addition, it defines mis-connection and payload mistype capabilities of CESoPSN. These capabilities increase resilience of CESoPSN to mis-configuration and some types of DoS attacks. 12. Applicability Statement CESoPSN is a payload convergence layer intended for carrying PDH circuits (fractional E1/T1, unstructured E1/T1 and unstructured E3/T3) over packet-switching networks. Applicability of CESoPSN MAY be extended to low-rate SONET/DH circuits with minimal modifications. CESoPSN allows to conserve switching capacity of the PSN (i.e., number of packets per second handled by the PSN per a PW) by using configurable packetization delay that is not limited by encapsulation techniques. It also allows to conserve the PSN bandwidth in case of outages of the end service. CESoPSN allows to carry both data and clock of PDH circuits across multiple types of PSN. CESoPSN does not presume availability of a global synchronous clock at the ends of a PW. This makes it suitable for Carriers' Carrier applications when multiple CESoPSN PWs must carry data and clock between otherwise isolated areas of PDH networks belonging to different customers, each with its own synchronization scheme. CESoPSN uses RTP for carrying clock across the network. As a consequence, its jitter buffer is only used to compensate the packet inter-arrival jitter introduced by the PSN and does not introduce additional delay for compensation of discrepancy between the ingress end service line clock and egress PE local oscillator. This makes it specially suitable for emulation of TDM circuits carrying delay- sensitive (e.g., Voice) applications. Standard RTP header is extended to the CESoPSN header in a way that guarantees applicability of standard header compression techniques for RTP/UDP/IP profile over links slow and/or error-prone links. Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP- friendly behavior under network congestion. Vainshtein et al. Expires May-2002 [Page 23] TDM Circuit Emulation Service over PSN November 2001 CESoPSN allows collection of TDM-like faults and performance monitoring parameters hence emulating traditional carrier services of PDH circuits (e.g., SONET/SDH). Similarity with these services is increased by CESoPSN ability to carry Far End Error indications. CESoPSN provides for a carrier-independent ability to detect mis- connections and payload mistype errors. This feature increases resilience of the emulated service to mis-configuration and DoS attacks. Faithfulness of a CESoPSN PW is increased if the carrying PSN is Diffserv-enabled and implements EF PHB. In this case, all the CESoPSN packets SHOULD be EF-marked. CESoPSN does not provide any mechanisms for protection against PSN failures. Hence its resilience to such failures is defined exclusively by that of the PSN itself. 13. IANA Considerations This specification requires assignment of new PW Types/RTP Payload Types for CESoPSN PWs as described in Section .7.1. 14. 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 The authors would like to thank Alik Shimelmits for many fruitful discussions. REFERENCES [PWE-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 Vainshtein et al. Expires May-2002 [Page 24] TDM Circuit Emulation Service over PSN November 2001 [PWE-FW] Prayson Pate et al, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in progress, September 2001, draft-pate- pwe3-framework-02.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 [PATE-TDM] P. Pate, R. Cohen, D. Zelig, TDM Service Specification for Pseudo-Wire Emulation Edge-to-Edge (PWE3), Work in Progress, September 2001, draft-pate-pwe3-tdm-00.txt [ANAVI-TDM] M. Anavi et al, TDM over IP, Work in Progress, September 2001, August 2001, draft-anavi-tdmoip-02.txt [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, June 2001, draft-martini-l2circuit-trans- mpls-07.txt [L2TPv3] J.Lau et al, Layer Two Tunneling Protocol "L2TP", Work in progress, October 2001, draft-ietf-l2tpext-l2tp-base-01.txt [BRYANT-LAYERS] S. Bryant, L. Wood, Protocol Layering in PWE3, Work in progress, November 2001, draft-bryant-pwe3-protocol-layer-00.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 Vainshtein et al. Expires May-2002 [Page 25] TDM Circuit Emulation Service over PSN November 2001 [RFC2598bis] Bruce Davie (ed.), An Expedited Forwarding PHB, Work in Progress, April 2001, draft-ietf-diffserv-rfc2598bis-01.txt [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 [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 [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). AUTHORS' ADDRESSES Alexander ("Sasha") Vainshtein Vainshtein et al. Expires May-2002 [Page 26] TDM Circuit Emulation Service over PSN November 2001 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 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 Vainshtein et al. Expires May-2002 [Page 27] TDM Circuit Emulation Service over PSN November 2001 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. 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 Carrier Convergence layer with inherent 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, payload mistype detection 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 Vainshtein et al. Expires May-2002 [Page 28] TDM Circuit Emulation Service over PSN November 2001 Section .7 MUST be added 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. This section is concerned with the case of MPLS being used as both the Carrier and Carrier Convergence layer for the CESoPSN PW. In this case, CESoPSN packet MUST be prepended with an MPLS label stack including: o VC label entry (see [MARTINI-TRANS] or [KOMPELLA]). This entry acts as the PW demuxing field. 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 Carrier header and must immediately pressed the VC label entry. It MAY be omitted in some situations. This combination of Carrier layer and PW demuxing technique does not provide ability to detect mis-connections. The mis-connection detection functionality can be provided using SSRC values in the RTP part of the CESoPSN header. Since MPLS does nor allow to infer actual payload size, CESoPSN ability to detect mis-type defects is limited. MPLS tunnels are conventionally established using various signaling protocols. As a consequence, parameters used for setup and teardown of CESoPSN tunnels MUST be mapped to data elements of these protocols. A3. L2TP PSN CESoPSN packets may be carried in L2TPv3 tunnels over IP (see [L2TPv3]). Since L2TP provides both data and control plane for tunnel establishment, parameters describing payload and payload convergence layers SHOULD be defined as AVPs to allow single-ended setup and teardown of CESoPSN PWs. L2TPv3 tunnels represent a PW demuxing technique with optional ability to detect misconnections (using "cookies"). As a consequence, SSRC-based misconnection detection by CESoPSN MAY be disabled. Vainshtein et al. Expires May-2002 [Page 29] TDM Circuit Emulation Service over PSN November 2001 IP represents a Carrier layer with inherent ability to infer the payload size from the header. As a consequence, payload mistype detection SHOULD take the actual payload size into consideration. ANNEX B. EMULATION OF SONET/SDH CIRCUITS B1. Relevant Types of SONET/SDH circuits o OC-1 o OC-3 o OC-3c o STM-1 B2. Native Frame Size and Payload Format Since natural delineation of SONET/SDH frames (of abovementioned rates) will produce packets exceeding minimal MTU in some cases, the fragmentation of the SONET/SDH frame into few packets will be used. As an intentional contradiction to general principles stated in [PWE3-FW], 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 contains 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 The following techniques, described in [PWE3-FW] may be used for defining "SONET/SDH as unstructured TDM" transmission clock. o External timing o Adaptive timing o Differential (SRTS) timing o RTP-based timing. The applicability of these techniques may be defined as follows: B3.1. External and Differential Timing The 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 and SRTS timing. B3.2 Adaptive Timing Vainshtein et al. Expires May-2002 [Page 30] TDM Circuit Emulation Service over PSN November 2001 As mentioned in Section .5.2 above, adaptive timing seems sufficient for SONET/SDH circuits if Stratum 3E clocks are available at each end of a PW. If the worst case of clock deviation (.20 ppm) is taken into account, this method reduces in unacceptable increase of jitter buffer. Using RTP-based clock recovery techniques in these situations may be beneficial. B.3. Structure of the Control Word The same bits as defined in Section .6.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 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, Carrier Convergence and Carrier 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 receive 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 mis-ordered packets. The CESoPSN de-packetizer MUST detect lost or mis-ordered packets. If any of the packets carrying the any PDU of native SONET/SDH frame is lost or mis- ordered, the CESoPSN de-packetizer MUST play out a scrambled pattern consisting of valid framing bytes ([G.707], [T1.105]) and all other bytes set to all 1s in place of this frame. The CESoPSN de- packetizer MAY re-order packets received out of order. If the Vainshtein et al. Expires May-2002 [Page 31] TDM Circuit Emulation Service over PSN November 2001 CESoPSN de-packetizer does not support re-ordering, it MUST drop mis- ordered packets. B5. Clock recovery issues. Since "SONET/SDH as Unstructured TDM" application is a "trunking" application, separate, independent clock signals per CESoPSN PW and for each direction of CESoPSN are required. B6. PSN to SONET/SDH Signals The common CESoPSN fault precedence rules equally apply to CESoPSN carrying unstructured SONET/SDH. As a consequence, only defects requiring non-standard treatment are considered. B6.1. Loss of Packets If any of the PDUs, comprising the 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 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. B6.2. Payload Mistype The scrambled pattern consisting of valid framing bytes ([G.707], [T1.105]) and all other bytes set to all 1s will be played out with local clock available at this PW, until synchronization restoration. B6.3. Loss of Synchronization The scrambled pattern consisting of all bytes (including A1, A2) set to all 1s will be played out with local clock available at this PW, until synchronization restoration. ANNEX C. A COMMON PW SETUP AND TEARDOWN MECHANISM Note: Description of such a mechanism belongs to one of the more generic PWE3 documents. It is presented here only to provide a reference point for CESoPSN parameters defined in Section .7 and presumably will be removed in the final release of the document. C1. PW Setup Two PW end services must exist before a PW is set up. Initially, each of them is considered unbound to any PW and behaves as inactive towards the appropriate CE (exact definition of inactivity is payload layer-specific). Vainshtein et al. Expires May-2002 [Page 32] TDM Circuit Emulation Service over PSN November 2001 The PW setup is controlled by the common PW layer that implements the following logic: 1. PW setup is initiated by an external command. This command can be initiated either by the management system or by the L1/L2 VPN auto-discovery process (e.g., see [KOMPELLA]) etc. and carries the following parameters: a. Identification of PEs terminating each of the two end services to be connected by a PW. Router ID of PE SHOULD be used for this purpose b. Local, within each PE, identification of each of the end services to be connected by a prospective PW. In most cases, ifIndex of the end service MAY be used for this purpose c. PW Type. This parameter MUST uniquely identify the combination of payload and payload convergence layers to be used with the prospective PW d. Payload-specific parameters of each of the end services e. Payload convergence layer-specific parameters defining behavior of this layer f. For L1 (Circuit) PWs - common PW layer parameters g. Optionally (if the carrier layer is Diffserv-enabled) - identification of the PHB that should be implemented by the PSN for providing desired quality of the PW emulation. PHB Identification Codes (see [RFC3140]) MUST be used for this purpose 2. The Common PW layer: a. Verifies that the specified end services are not bound to any PW yet b. Requests path MTU between the specified pair of PE devices from the Carrier Layer c. Uses services of the payload layer to verify that the end service parameters and PW type are compatible d. In case of L1 (Circuit) PWs verifies that the number of payload bytes defined in the request is compatible with the Path MTU provided by the Carrier Layer e. Uses identification of the pair of PEs and relative identification of ESs within each PE in order to create common PW headers. This includes allocation of PW demuxing fields in these headers f. Passes PE identification and desired PHBID to the Carrier layer and obtains appropriate Carrier headers 3. Failure of any of the above-mentioned operations MUST result in: a. Release of all already allocated resources (if any) b. Indication of a PW setup failure response to the originator of the external command 4. Once all the operations mentioned above has been successfully completed, the common PW layer: a. Binds the end services to the newly created PW so that they become PW end services Vainshtein et al. Expires May-2002 [Page 33] TDM Circuit Emulation Service over PSN November 2001 b. Passes Common PW, Carrier and Carrier Convergence headers to the IWF functions (in the Payload Conversion layer) at both ends of the PW and signals them to start operation c. Sends a PW setup success response to the originator of the external command 5. Each of the IWF functions at both ends of the PW, upon receiving this signal: a. Signals the payload layer for activation of the respective end service towards its CE b. Starts its operation in inbound and outbound directions C2. PW Teardown 1. The PW tear-down can be initiated by: a. An external command b. A signal from the peer indicating that the PW demuxing field used by the PW is no longer valid c. A signal from the Carrier layer indicating that the Carrier header used by the PW is no longer valid 2. In any case the PW common layer, upon receiving such a command: a. Signals the IWF functions at both ends of the PW to stop operation. In their turn, these signal the payload layer for deactivation of their respective end services towards CE b. Releases all the resources allocated to this service (including PW demuxing field values) c. Unbinds end services from the PW d. If necessary, sends a response to originator of the PW teardown command. Vainshtein et al. Expires May-2002 [Page 34] TDM Circuit Emulation Service over PSN November 2001 ANNEX D. COMPARISON OF DIFFERENT APPROACHES Note: This annex will be removed from the final document. The following techniques for carrying PDH traffic over PSN are compared: 1. TDMoIP as described in [ANAVI-TDM] 2. CESoP as defined in [PATE-TDM] 3. CESoPSN as defined in this document. Criteria and results of evaluation are presented below. All the results refer to the latest available releases of the documents. 1. Supported Services a. Unstructured E1/T1 - supported by TDMoIP, CEoP and CESoPSN b. Fractional E1/T1 - supported in TDMoIP and CESoPSN, not supported in CEoP c. Fractional E1/T1 with CAS - supported by TDMoIP, left FFS by CESoPSN, not supported by CEoP d. Unstructured E3/T3 - supported by TDMoIP, CESoPSN and CEoP (by reference to [MALIS-SONET]) e. The following "bundling" services are supported only by CEoP i. TUG2/VTG - supported only by CEoP ii. Fractional STS-1/STM-0 - supported only by CEoP f. Unstructured STS-3c/STM-1 is supported only by CESoPSN 2. Basic approach: a. TDMoIP is AAL1 or AAL2-based with the packet payload internally subdivided into 47-byte "cells" b. CEoP uses standard mapping of PDH data streams into SONET VT/SDH low-order VC c. CESoPSN uses raw TDM data packetization that preserves native circuit delineation and, for structured services, alignment of the circuit structure with the packet 3. Synchronization models and dependency upon availability of network-wide central clock: a. TDMoIP preferably uses network-wide central clock, but can also use adaptive and RTP-based techniques b. CEoP requires Stratum 3 (or better) network-wide central clock and uses SONET/SDH pointer justification c. CESoPSN uses RTP-based synchronization by default. (Optionally, adaptive synchronization or network-wide central clock can be used) 4. Relevant PSN types and demuxing techniques: a. TDMoIP requires UDP/IP (some bits in the UDP source port field are used to distinguish between packets with and without RTP header) b. CEoP and CESoPSN are invariant to the PSN type (IP or MPLS) c. CEoP uses MPLS for PW demuxing d. CESoPSN is invariant to the demuxing technique 5. Packetization delay and PW Switching Rate: Vainshtein et al. Expires May-2002 [Page 35] TDM Circuit Emulation Service over PSN November 2001 a. Configurable for TDMoIP and CESoPSN b. Limited configuration capabilities (packetization delay <= 0.5 ms, PW switching rate >= 2000 pps) for CEoP 6. Basic Encapsulation efficiency: a. Unstructured E1: i. TDMoIP - depends on packetization delay. For 1 ms delay - 3.7% overhead without RTP, 8.4% with RTP ii. CEoP - cannot be improved over 12.5% iii. CESoPSN - depends on packetization delay. For 1 ms delay - 6.25% overhead b. Unstructured T1: i. TDMoIP - depends on packetization delay. For 1 ms delay - 4.2% overhead without RTP, 10.4% with RTP ii. CEoP - cannot be improved over 11.9% iii. CESoPSN - depends on packetization delay. For 1 ms delay - 11.9% overhead c. Unstructured E3: i. Not evaluated for TDMoIP ii. More than 47% overhead for CEoP iii. Depends on packetization delay. For 125 us packetization delay - 3% overhead d. Unstructured T3: i. Not evaluated for TDMoIP ii. More than 12% overhead for CEoP iii. Depends on packetization delay. For 125 us packetization delay - 2.3% overhead 7. OAM Capabilities: a. One type of defect (LOPS)defined for CeoP b. Lost packets are signaled from egress to ingress TDMoIP c. Multiple defects and their hierarchy defined for CESoPSN as well as loopback capabilities 8. Dynamic Bandwidth Allocation (DBA) Capabilities: a. Not defined for TDMoIP b. Wrong type of DBA defined for CEoP (based on SONET/SDH AIS and Unequipped indications instead of condition of the payload) c. Based on payload state indications (AIS, Idle Code) for CESoPSN Vainshtein et al. Expires May-2002 [Page 36]