Network Working Group Alexander ("Sasha) Vainshtein Israel Sasson Akiva Sadovski Internet Draft Axerra Networks Expiration Date: Eduard Metz March 2002 KPNQwest September 2001 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) draft-vainshtein-cesopsn-00.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 carrying clock over the PSN and supports signaling between Provider Edge (PE) devices. Encapsulation proposed in this document may be extended to low-rate SONET/SDH traffic as well. CONVENTIONS USED IN THIS DOCUMENT The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Vainshtein et al [Page 1] TDM Circuit Emulation Service over PSN September 2001 TABLE OF CONTENTS 1. Introduction............................................. 4 2. Terminology and Reference Models......................... 4 3. Scope.................................................... 5 3.1. TDM Services........................................... 5 3.2. Structured vs. Unstructured TDM Circuits............... 5 3.2.1. PDH Circuits......................................... 5 3.2.2. SONET/SDH Circuits................................... 5 3.3. Relevant Types of PSN.................................. 5 3.4. Interworking and Signaling............................. 6 3.4.1. CE Signaling......................................... 6 3.4.2. PE/PW Signaling...................................... 6 3.5. PW OAM................................................. 7 3.5.1. Fault detection and Handling......................... 7 3.5.2. PW Maintenance....................................... 7 4. Specifics of Pseudo-Wire Emulation for PDH Circuits...... 7 4.1. Native Frame Size...................................... 7 4.2. Synchronization Modes.................................. 8 4.3. Conclusion............................................. 9 5. CESoPSN Encapsulation.................................... 9 5.1. Generic CESoPSN Format................................. 9 5.2. CESoPSN Header......................................... 10 5.2.1. Usage of RTP Header.................................. 10 5.2.2. Structure of the Control Word........................ 10 5.3. Payload Data Format.................................... 12 5.3.1. Fractional E1/T1 Circuits............................ 12 Vainshtein et al. Expires March-2002 [Page2] TDM Circuit Emulation Service over PSN September 2001 5.3.2. Unstructured TDM Circuits............................ 12 5.3.3. T1-in-E1 Mode for Unstructured T1 Circuits......... 13 6. CESoPSN Operation........................................ 13 6.1.1. New PW Types......................................... 14 6.2. Payload Layer Parameters............................... 14 6.3. Payload Convergence Layer Parameters................... 14 6.3.1. Payload Bytes........................................ 1 4 6.3.2. Synchronization Clock Rate........................... 15 6.3.3. Usage of Control Word................................ 15 6.4. End Service Inactivity Behavior........................ 15 6.5. Description of the IWF operation....................... 15 6.5.1. Outbound Direction................................... 15 6.5.2. Inbound Direction Normal Operation................. 16 6.5.3. Inbound-to-Outbound IWF Loopback..................... 16 6.6. CESoPSN Defects........................................ 17 6.6.1. Precedence of Faults................................. 17 6.6.2. Misconnection........................................ 17 6.6.3. Loss of Packets and Re-Ordering...................... 17 6.6.4. Payload Mistype...................................... 18 6.6.5. Loss of Synchronization.............................. 18 6.7. QoS Issues............................................. 19 7. Applicability Statement.................................. 19 8. RTP Payload Format Considerations........................ 20 9. RFC 2914 Conformance..................................... 21 10. FFS Issues.............................................. 2 1 11. Security Considerations................................. 21 12. IANA Considerations..................................... 21 Vainshtein et al. Expires March-2002 [Page3] TDM Circuit Emulation Service over PSN September 2001 13. Intellectual Property Considerations.................... 21 ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN.................. 24 ANNEX B. EMULATION OF SONET/SDH CIRCUITS.................... 26 Annex C. A Common PW Setup and Teardown Mechanism........... 29 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 transmission over a packet-switched network (PSN). In this regard this specification complements [MALIS]. 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 T DM 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. 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. Terminology and Reference Models This document uses terminology described in [PWE3-FW], Section 2. We also assume Network, Signaling and Timing reference models described respectively in Sections 3.2.1, 3.2.2 and 4.4.1 of [PWE3- FW]. In addition, this document uses the PW layering model suggested by Stewart Bryant. The following layers defined in this model will be referred to: Payload Layer Data exchanged between CE devices Payload Protocol used to allow effective Convergence regeneration of the carried service Layer at egress Common PW Presumably NULL in the data plane. Layer This document presumes that the control plane of this layer is responsible for PW/PE signaling Vainshtein et al. Expires March-2002 [Page4] TDM Circuit Emulation Service over PSN September 2001 required for PW setup and teardown Carrier Protocol used to augment the Carrier Convergence Layer. As a minimal requirement, it Layer allows demuxing of Carrier packets belonging to different PW Carrier Layer Protocol used to deliver packets from the ingress PE device to egress one 3. Scope 3.1. TDM Services 3.2. 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. 3.2.1. 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: Carrying fractional E1/T1 circuits with CAS signaling over CESoPSN is left for further study. 3.2.2. 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. 3.3. 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 March-2002 [Page5] TDM Circuit Emulation Service over PSN September 2001 The layering model for PW discussed in Section 2 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 e ncapsulation, e.g., the data plane of the payload convergence layer used for carrying circuits listed in Section 3.1 above. This encapsulation can be carried over multiple combinations of Carrier and Carrier Convergence layers. Some details are described in Annex A. Note: Some preliminary considerations on the control plane for CESoPSN are described in Chapter 6 and Annex C. 3.4. Interworking and Signaling In accordance with [PWE3-FW] this specification considers only P2P bi-directional services and network interworking. 3.4.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 s ervices while Idle Code is applicable for fractional E1/T1 and unstructured E3/T3 services. 3.4.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 6.2 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 March-2002 [Page6] TDM Circuit Emulation Service over PSN September 2001 3.5. PW OAM 3.5.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 s ignaled: 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 6.6 below. 3.5.2. PW Maintenance CESoPSN format allows to set and clear PW loopbacks. Details are described in Section 6.5.3 below. 4. 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. 4.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 STS-3c SPE is 2349 b ytes. STS-1 SPE 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, PW 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 E1 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). While packing of multiple native circuit frames into a single packet of the underlying PSN reduces overhead, it also increases impact of packet loss. However, due to a relatively low rate of the emulated service, the resulting service outage time is quite short, e.g., packing 8 native circuit frames in a single packet of the underlying PSN will result in 1 ms outage per lost packet. Vainshtein et al. Expires March-2002 [Page7] TDM Circuit Emulation Service over PSN Sept ember 2001 4.2. Synchronization Modes PDH and SONET/SDH circuits differ regarding requirements for their synchronization. These differences may be summarized as following: o Availability of a network-wide clock at both ends of a PW is quite common in the SONET/SDH environment. In a PDH environment lack of such a clock is quite common o Discrepancy between two local oscillators in a SONET/SDH environment is limited to 20 PPM by the appropriate standard and, in most cases, does not exceed 4-5 PPM (if Stratum 3E clocks are available at both ends of a PW). In a PDH environment, the worst case is a pair of Stratum 4 clocks with possible discrepancy up to 100 PPM. The first of the above-mentioned differences effectively precludes using synchronization schemes that require a network-wide clock at both ends of a PW carrying a PDH circuit as a common solution, hence limiting the choice to adaptive and RTP-based methods (see [PWE3- FW]), Section 4.4. In order to choose between purely adaptive and RTP-based synchronization schemes, the following should be considered: o In both schemes the jitter buffer used by the PW IWF MUST compensate for the packets inter-arrival jitter introduced by the PSN. This compensation results in a certain delay for the carried service o In a purely adaptive scheme, the jitter buffer must also compensate discrepancy between local oscillators at two ends of the PW, while in an RTP-based scheme such compensation is provided by the timestamps that are carried across the network. As a consequence, adaptive schemes introduce additional delay that is directly proportional to expected discrepancy of local oscillators, while RTP-based schemes do not introduce it. Both PDH and SDH circuits may carry delay-critical applications (e.g., Voice). Total delay introduced by a PW carrying these circuits over a PSN is a sum of the network propagation delay and delay introduced by the jitter buffer. A linear dependency between the size of the this buffer and expected discrepancy of local oscillators is hence translated into a similar dependency of the total PW delay while the RTP-based ones do not introduce such a dependency. These considerations do not prove, in any way, that RTP-based synchronization schemes work. They also require careful design. But, at least, their ability to survive in situations with substantial discrepancies between local oscillators inherently exceeds that of purely adaptive ones. Vainshtein et al. Expires March-2002 [Page8] TDM Circuit Emulation Service over PSN September 2001 4.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: Ability to pack multiple native circuit frames into a single packet Ability to carry timestamps across the PSN. 5. CESoPSN Encapsulation 5.1. Generic CESoPSN Format CESoPSN packets use format shown in Fig. 1 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN-specific Carrier and Carrier Convergence Headers | | ... | | Common PW Header (if not empty) | | ... | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CESoPSN Control Word (optional) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | .... | | Packetized TDM data (payload) or maintenance commands/replies | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. CESoPSN Format Usage of the CESoPSN Control Word is OPTIONAL. However: o All CESoPSN implementations MUST support usage of the control word o 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. Vainshtein et al. Expires March-2002 [Page9] TDM Circuit Emulation Service over PSN September 2001 5.2. CESoPSN Header 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 used in accordance with rules described in [RFC1889], Section 5.1 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) carries the PW type code defined in Section 6.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. 5.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| NumA|L| NumL|I| NumI|R|OAM| 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 Bits NumA represent the number of additional AIS CESoPSN packets to be replayed by the egress node. 0 value in this field means that just one AIS/idle data CESoPSN packets will be replayed. Vainshtein et al. Expires March-2002 [Page10] TDM Circuit Emulation Service over PSN September 2001 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 Bits NumL represent number of lost packets after the previous remote loss of packet indication has been sent 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 Bits NumI represent the number of additional Idle Code CESoPSN packets to be replayed by the egress node. 0 value in t his field means that just one idle data CESoPSN packets will be replayed o Bit R – if set, represents Remote Payload Mistype indication o Bits OAM are used to set, clear and detect CESopSN loopbacks. They are interpreted like following: * 00 a normal CESoPSN packet (no OAM) * 01 a command 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 working in the loopback mode, it resumes its normal operation * 11 loopback mark. The CESoPSN IWF operating under loopback marks the data it sends to its peer with this value in the OAM field of the control word 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. Upon reception of a CESoPSN packet with sequence number X and bit A (I) set in the CESoPSN control word expected sequence number of the following packet MUST be set to X+NumA+1 (X=NumI+1 respectively) 3. Sending a single CESoPSN packet with multiple AIS/Idle Code indication conserves the switching capacity of the PSN. On the other hand, it results in extension of the AIS/Idle Code condition at the egress of CESoPSN PW 4. 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 Vainshtein et al. Expires March-2002 [Page11] TDM Circuit Emulation Service over PSN September 2001 established between a pair of CE devices). PW loopbacks are established between PE devices as described in Section 6.5.3. below. 5.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 the classical 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. 5.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. 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 5.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 Vainshtein et al. Expires March-2002 [Page12] TDM Circuit Emulation Service over PSN September 2001 size of the carried circuit, but no alignment with the framing structure of the service is required. 5.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. "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. 6. 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 PWES (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 Vainshtein et al. Expires March-2002 [Page13] TDM Circuit Emulation Service over PSN September 2001 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. 6.1.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 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. 6.2. Payload Layer Parameters Only one payload layer parameter is defined in this document the Circuit Bit Rate. 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. 6.3. Payload Convergence Layer Parameters 6.3.1. Payload Bytes This parameter has been defined in [MARTINI-TRANS]. Compatibility rules include the following: Vainshtein et al. Expires March-2002 [Page14] TDM Circuit Emulation Service over PSN September 2001 This parameter MUST be the same for both directions of the PW 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 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 6.3.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.) 6.3.3. Usage of Control Word This is a Boolean parameter with TRUE value meaning 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. 6.4. 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. 6.5. Description of the IWF operation Once started, the CESoPSN IWF operates like following: 6.5.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 5.2.1 2. Sequence numbers and timestamps representing the selected synchronization clock are inserted in the CESoPSN headers 3. CESoPSN, common PW (if not empty), 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. If the AIS- producing condition persists, the CESoPSN IWF MAY reduce the Vainshtein et al. Expires March-2002 [Page15] TDM Circuit Emulation Service over PSN September 2001 rate of generated packets by using the NumA field in the CESoPSN control word. In such a case, the sequence number of the next packet MUST be increased accordingly 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. If the Idle Code condition persists, the CESoPSN IWF MAY reduce the rate of generated packets by using the NumI field in the CESoPSN control word. In such a case, the sequence number of the next packet MUST be increased accordingly. 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. 6.5.2. Inbound Direction Normal Operation 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 3. Once the jitter buffer contains sufficient amount of data (usually half of its capacity), the IWF replays this data in its end service in accordance with its (locally defined) transmission clock 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 next section. 6.5.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 appropriately using the OAM bits in the CESoPSN control word. Vainshtein et al. Expires March-2002 [Page16] TDM Circuit Emulation Service over PSN September 2001 Once the loopback is cleared, the IWF resumes its normal operation. 6.6. CESoPSN Defects 6.6.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) o Loss of synchronization. 6.6.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) Some carrier convergence/carrier techniques (UDP/IP, L2TPv3/IP) inherently provide 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 t he management system. CESoPSN packets with detected misconnection MUST NOT affect the outbound IWF functionality regarding loss of packets detection. 6.6.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 Vainshtein et al. Expires March-2002 [Page17] TDM Circuit Emulation Service over PSN September 2001 Detailed specification of rules for detection of packet loss is left for further study. Note: CESoPSN implementations MAY support limited reordering. In this case 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 code to be replayed into the relevant PWES. In addition: o Counter of lost packets must be updated 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 with the appropriate number of lost packets in the NumL field Note: In accordance with the general precedence principle, packets with a misconnection problem MUST NOT affect expected sequence number used for loss of/out-of-order packets. 6.6.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 o A remote payload mistype indication flag SHOULD be set in the next CESoPSN packet to be sent in the opposite direction 6.6.5. Loss of Synchronization Vainshtein et al. Expires March-2002 [Page18] TDM Circuit Emulation Service over PSN September 2001 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. If the jitter buffer overrun condition persists, an appropriate alarm SHULD be sent to the management system. 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. 6.7. QoS Issues As mentioned in Section 3.3.2.1, 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. 7. 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 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 property makes it suitable for Carriers Carrier applications when multiple CESoPSN PWs carry data and clock between otherwise isolated areas of PDH networks belonging to different customers, each with its own synchronization scheme. Vainshtein et al. Expires March-2002 [Page19] TDM Circuit Emulation Service over PSN September 2001 CESoPSN uses RTP for carrying clock across the network. As a consequence, its jitter buffer is used to compensate only the packet inter-arrival jitter introduced by the PSN but not discrepancy between local oscillators at the ends of a PW. This makes it suitable for carrying delay-critical applications over emulated circuits (e.g., Voice). CESoPSN allows bandwidth conservation by carrying only AIS and/or Idle Code indications instead of data. It also allows to conserve switching capacity of the PSN (i.e., number of packets per second handled by the PSN) when handling AIS or Idle Code condition. CESoPSN allows collection of TDM-like faults and performance monitoring parameters hence emulating classical 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. 8. RTP Payload Format Considerations In accordance with guidelines specified in [RFC2736], the following issues are addressed by this specification: 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]). 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. 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. 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. 5. Compression of RTP headers is left for further study. Vainshtein et al. Expires March-2002 [Page20] TDM Circuit Emulation Service over PSN September 2001 9. RFC 2914 Conformance CESoPSN carries constant bit rate services. These services, by definition, cannot behave in a TCP-friendly manner under congestion while retaining any value for the user. 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: o Usage of RTCP o Compression of RTP Headers o Fractional E1/T1 with CAS (if found to be of sufficient interest) o Explicit specification of rules for detecting loss of packets 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. IANA Considerations This specification requires assignment of new PW Types/RTP Payload Types for CESoPSN PWs as specified 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 s uch 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 Vainshtein et al. Expires March-2002 [Page21] TDM Circuit Emulation Service over PSN September 2001 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, May-2001, draft-ietf-pwe3- requirements-00.txt [PWE-FW]. Prayson Pate et al, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in progress, July 2001, draft-pate-pwe3- framework-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 [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, July 2001, draft-ietf-l2tpext-l2tp-base-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 2 474, IETF, 1998 [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 [RFC2914] S. Floid, Congestion Control Principles, RFC 2914, IETF, 2000 [RFC3140] D. Black et al, Per Hop Behavior Identification Codes, RFC 3140, IETF, June 2001 Vainshtein et al. Expires March-2002 [Page22] TDM Circuit Emulation Service over PSN September 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 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 Vainshtein et al. Expires March-2002 [Page23] TDM Circuit Emulation Service over PSN September 2001 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 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 p aragraph 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 Vainshtein et al. Expires March-2002 [Page24] TDM Circuit Emulation Service over PSN September 2001 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 Section 7.2 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: A VC label entry (see [MARTINI-TRANS] or [KOMPELLA]). This entry acts as the Carrier Convergence layer header. It MUST be present in the stack and MUST be marked as residing at the bottom of the stack 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 and Carrier Convergence layers does not provide neither frame length information nor ability to detect mis- connections. The former is not required for CESoPSN because the Payload Bytes parameter can be used for this purpose. The mis- connection detection functionality can be provided using SSRC values in the RTP part of the CESoPSN header. MPLS tunnels are conventionally established using various signaling protocols. As a consequence, parameters used for setup and teardown Vainshtein et al. Expires March-2002 [Page25] TDM Circuit Emulation Service over PSN September 2001 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]) that would act as an alternative Carrier Convergence layer over IP. 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. L2TP tunnels 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. 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 e gress 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: 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 SHOULD be marked with M bit set to 1 in the RTP header. B3. Synchronization modes Vainshtein et al. Expires March-2002 [Page26] TDM Circuit Emulation Service over PSN September 2001 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 As mentioned in Section 2.3.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 TRP-based clock recovery techniques in these situations may be beneficial. B.3. Structure of the Control Word The same bits as defined in Section 3.1.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 Bits NumA represent time (measured in 125 ms intervals) during which the SONET/SDH transmitter remains in the OFF state a t the egress node. If it is not possible, all-0 (zero) pattern should be played out 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 o Bits NumI represent time (measured in 125 ms intervals) during which the SONET/SDH transmitter should reproduce OOF condition at the egress node. If it is not possible, all-0 (zero) pattern should be played out. 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 Vainshtein et al. Expires March-2002 [Page27] TDM Circuit Emulation Service over PSN September 2001 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 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 Vainshtein et al. Expires March-2002 [Page28] TDM Circuit Emulation Service over PSN September 2001 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 6.2 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). 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 by the management system, 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. 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 g. Optionally, parameters to be transparently passed to the carrier convergence layer. Group ID (see [MARTINI-TRANS]) is one example of such a parameter 2. The control plane of the Common PW layer: Vainshtein et al. Expires March-2002 [Page29] TDM Circuit Emulation Service over PSN September 2001 a. Verifies that the specified end services are not bound to any PW yet b. If necessary, allocates a previously unused PW ID for the PW to be created. The scope of uniqueness of such an ID is left for further study c. Requests path MTU between the specified pair of PE devices from the Carrier Layer d. Passes PW Type, path MTU, end service and payload convergence layer parameters to the payload layer convergence layer in order to verify that these parameters are compatible. Compatibility rules are PW type-specific. The payload convergence layer may use services of the payload layer to verify that the end service parameters and PW type are compatible e. Passes PE, end service identification and optional transparent parameters to the Carrier Convergence layer and obtains appropriate payload convergence 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 b e signaled by the appropriate layer to the common PW layer. In this case the latter releases all the already allocated resources (if any) and sends 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. Creates a (possibly empty) common PW header b. Binds the end services to the newly created PW so that they become PW end services c. 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 d. 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 Carrier Convergence layer (e.g., indicating that the carrier convergence header used by the PW is no longer valid) c. A signal from the Carrier layer (e.g., 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 Vainshtein et al. Expires March-2002 [Page30] TDM Circuit Emulation Service over PSN September 2001 for deactivation of their respective end services towards CE b. Releases all the resources allocated to it by the carrier convergence and carrier layers c. Unbinds end services from the PW d. Releases PW ID if it has been allocated for the PW e. If necessary, sends a response to originator of the PW teardown command. Vainshtein et al. Expires March-2002 [ Page31]