Network Working Group A. Vainshtein - Editor (Axerra Networks) Internet Draft I. Sasson (Axerra Networks) A. Sadovski (Axerra Networks) Expiration Date: E. Metz (Thrupoint) August 2003 T. Frost (Zarlink Semiconductor) P. Pate (Overture Networks) February 2003 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) draft-vainshtein-cesopsn-05.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 unstructured (T1, E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for SONET/SDH. Proposed PW encapsulation uses RTP for clock recovery and leverages RTP-based mixing capabilities for application state signaling between Customer Edge (CE) devices. TABLE OF CONTENTS 1. Introduction......................................................3 2. Summary of Changes from the -04 Revision..........................3 3. Terminology and Reference Models..................................3 3.1. Terminology...................................................3 3.2. Reference Models..............................................5 3.2.1. Generic Models............................................5 3.2.2. Synchronization Considerations and Deployment Scenarios...5 3.2.3. Generic and Specific Requirements.........................5 4. Scope.............................................................6 Vainshtein et al. [Page 1] TDM Circuit Emulation Service over PSN February 2003 4.1. Emulated Services.............................................6 4.1.1. Unstructured services.....................................6 4.1.2. Structured services.......................................7 4.2. Affected Protocol Layers......................................8 5. CESoPSN Encapsulation Layer.......................................8 5.1. CESoPSN Packet Format.........................................8 5.2. PSN and Multiplexing Layer Headers............................8 5.3. CESoPSN Header................................................8 5.3.1. Usage of RTP Header.......................................9 5.3.2. Usage and Structure of the Control Word..................10 6. CESoPSN Payload Layer............................................11 6.1. Common Payload Format Considerations.........................11 6.2. Payload Format for Structured Services.......................11 6.2.1. Common Considerations....................................11 6.2.2. Synchronous n*DS0 Services without CAS...................12 6.2.3. Logical n*DS0 with CAS: Data and Signaling Packets.......12 6.2.4. Trunk-Specific n*DS0 Services with CAS...................13 6.3. Unstructured Services........................................13 6.3.1. Basic Payload Format.....................................13 6.3.2. Octet-aligned T1 Service.................................14 7. CESoPSN Operation................................................14 7.1. Common Considerations........................................14 7.2. End Service Inactivity Behavior..............................14 7.3. Description of the IWF operation.............................15 7.3.1. PSN-bound Direction......................................15 7.3.2. CE-bound Direction.......................................15 7.4. CESoPSN Defects..............................................17 7.4.1. Misconnection............................................17 7.4.2. Re-Ordering and Loss of Packets..........................17 7.4.3. Malformed Packets........................................18 7.4.4. Loss of Synchronization..................................18 7.4.5. Remote Packet Loss.......................................19 7.5. Performance Monitoring.......................................19 7.5.1. Errored Data Blocks......................................19 7.5.2. Errored, Severely Errored and Unavailable Seconds........20 8. QoS Issues.......................................................20 9. RTP Payload Format Considerations................................20 9.1. Resilience to moderate loss of individual packets............20 9.2. Ability to interpret every single packet.....................20 9.3. Non-usage of the RTP Header Extensions.......................20 9.4. Compression of RTP headers...................................21 10. Congestion Control (RFC 2914) Conformance.......................21 11. FFS Issues......................................................22 12. Security Considerations.........................................22 13. Applicability Statement.........................................22 14. IANA Considerations.............................................24 15. Intellectual Property Disclaimer................................24 ANNEX A. A COMMON CE APPLICATION STATE SIGNALING MECHANISM..........27 Annex B. Reference PE Architecture for Emulation of N*DS0 SERvices..29 Annex C. Payload and Encapsulation Layer Parameters.................31 Vainshtein et al. Expires August 2003 [Page 2] TDM Circuit Emulation Service over PSN February 2003 1. Introduction This document describes a method for encapsulating unstructured (T1, E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for SONET/SDH (see [PWE3-SONET]). To support emulation of TDM traffic, which includes leased line, voice and data services, it is necessary to emulate the circuit characteristics of a TDM network. A circuit emulation header and RTP- based mechanisms for carrying the clock over PSN are used to encapsulate TDM signals and provide the Circuit Emulation Service over PSN (CESoPSN). Ability to carry unstructured TDM traffic best suits the leased line applications. Ability to emulate n*DS0 circuits provides for saving PSN bandwidth, supports DS0-level grooming and distributed cross-connect applications. It also enhances resilience of CE devices to effects of loss of packets in the PSN. The CESoPSN solution presented in this document fits the PWE3 architecture described in [PWE3-ARCH] and satisfies the general requirements put forward in [PWE3-REQ]. 2. Summary of Changes from the -04 Revision Note: This section will be removed from the final document. 1. Emulation of structured and unstructured services has been blended into a single document 2. A reference PE architecture for emulation of N*DS0 has been explicitly described 3. The packet payload size has been decoupled from the frame size of the emulated circuit. On the other hand, frame size- dependent "must-be-implemented" default packet payload size has been specified in such a way as to simplify the PW operation 4. Following [ATM-CES], two modes for n*DS0 services with CAS have been introduced: "logical" and "trunk-specific". 5. The QoS section has been re-written in accordance with suggestions by Kathleen Nichols. 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]. Vainshtein et al. Expires August 2003 [Page 3] TDM Circuit Emulation Service over PSN February 2003 The terms defined in [PWE3-ARCH], Section 1.4 are consistently used without additional explanations. This document uses some terms and acronyms that are commonly used in conjunction with the TDM services. In particular: o Frame Alignment Signal (FAS) is a common term denoting a special periodic pattern that is used to impose synchronous structures on E1, T1, E3 and T3 circuits. Actual FAS patterns are described in [G.704] and [G.751] o Out of Frame Synchronization (OOF) is a common term denoting the state of the receiver of a TDM signal when it failed to find valid FAS. Actual conditions for declaring and clearing OOF are described in [G.706] o Alarm Indication Signal (AIS) is a common term denoting a special bit pattern in the TDM bit stream that indicates presence of an upstream circuit outage. Actual methods for detecting the AIS condition in a TDM stream are defined in [G.775] o Remote Alarm Indication (RAI) is a common term denoting a special pattern in the framing of a TDM service that is sent back by the receiver that experiences an AIS condition o Channel-Associated Signaling (CAS) is a common term describing one of the methods of exchanging signals between telephony applications. CAS is based on allocation of up to 4 constant- rate synchronous bit-streams for each Voice-carrying DS0 channel in an E1 or T1 trunk. These bit-streams are commonly denoted A, B, C and D. The actual methods of carrying the sets of these bit streams isochronously in an E1 or T1 trunk and establishing association between a specific DS0 channel with an appropriate set of these bit streams are described in [G.704]. Note: CAS can be interpreted in two different ways. A "synchronous" interpretation treats it as a set of bit-streams, while a "signaling" interpretation treats it as a method to encode signals reflecting change of state of telephony applications based upon generation and detection of certain stable bit patterns in the CAS-related bit- streams. The most commonly used patterns include "stable ones" and "stable zeroes"; (i.e., two states per bit-stream); in some cases they are augmented by a "stable alternate pattern" (providing the 3rd state of the bit-stream). The combination of these patterns allows encoding of up to 16 different telephony application states. Most modern E1 and T1 framers support both approaches by providing: 1. For the synchronous approach - dedicated pins that allow extraction/insertion of the relevant constant-rate bit-streams into appropriate positions in the E1 or T1 trunk 2. For the signaling approach: a) Dedicated memory-mapped registers which allow reading the actual stabilized CAS bits values/writing the desired combination of CAS bits values Vainshtein et al. Expires August 2003 [Page 4] TDM Circuit Emulation Service over PSN February 2003 b) Generation of interrupts when a de-bounced change of CAS bits has been detected. Note: Another method of exchanging signals between telephony applications is called Common Channel Signaling (CCS). This method is not considered in this document. 3.2. Reference Models 3.2.1. Generic Models Generic models that have been defined in Sections 4.1, 4.2 and 4.4 of [PWE3-ARCH] are fully applicable for the purposes of this document without any modifications. The services considered in this document represent special cases of the structured bit stream payload type defined in Section 3.3.4 of [PWE3- ARCH]. 3.2.2. Synchronization Considerations and Deployment Scenarios The Network Synchronization reference model and deployment scenarios for emulation of TDM services have been described in [PWE3-TDM-REQ], Section 4.2. 3.2.3. Generic and Specific Requirements The protocol defined in this document has been designed in order to satisfy the requirements presented in [PWE3-REQ] and [PWE3-TDM-REQ]. In addition it places a strong emphasis on emulation of end-to-end delay characteristics of TDM networks. These networks are built using "fixed delay" increments and for this purpose consistently use 125 microseconds' frames at all the levels of hierarchy. Among other things, this approach guarantees the same end-to-end delay for all the channels carried between any two given points in the network. Faithful emulation of TDM networks cannot ignore these properties because they form an important part of the overall network design that, generally, speaking, includes both the "native TDM" segments and the "TDM PW" segments comprising a single end-to-end emulated service that is subject to delay budget restrictions. Edge-to-edge delay for PWs carrying TDM services is defined by the following factors: 1. The PSN transport delay between the given pair of PEs 2. The delay required for compensation of the packet delay variation (PDV) between the given pair of PEs. 3. The packetization latency (i.e. the time required to fill a single TDM PW packet with the TDM data). The first two factors are essentially out of control of the PWE3 protocol designer. This leaves only the packetization latency to play with. Vainshtein et al. Expires August 2003 [Page 5] TDM Circuit Emulation Service over PSN February 2003 The CESoPSN protocol has been designed in order to satisfy the following requirements: 1. Fixed packet payload size: All the packets belonging to a given CESoPSN PW MUST carry the same amount of TDM data. This requirement allows compensation of a lost PW packet with a packet carrying exactly the same amount of "replacement" data 2. Fixed end-to-end delay: CESoPSN implementations SHOULD provide the same end-to-end delay between any given pair of PEs regardless of the bit-rate of the emulated service. 3. Packetization latency range: a) All the implementations of CESoPSN: i. MUST support packetization latencies that do not exceed 6 milliseconds. This requirement is based on the limitations on the total processing time of TDM equipment dealing with speech signals stated in [G.114] ii. SHOULD support packetization latencies in the range 1 ... 3 milliseconds b) CESoPSN implementations that support configurable packetization latency: i. MUST allow configuration of this parameter with the granularity which is a multiple of 125 microseconds ii. SHOULD allow configuration of this parameter with the resolution of 1 millisecond. 4. Exceptions to requirements 2, 3.a) ii. and 3.b) ii. above can be considered, e.g., when: a) The required packet size (or increment/decrement to this size) exceeds reasonable Path MTU expectations due to high bit-rate of the emulated service. This consideration justifies lower packetization latencies and lower granularity of configuration b) The BW effectiveness of the resulting PW is unreasonably low due to low bit-rate of the emulated service. This consideration justifies higher packetization latencies. 4. Scope 4.1. Emulated Services This specification describes service-specific encapsulation layer for edge-to-edge emulation of the following TDM services: 4.1.1. Unstructured services CESoPSN supports edge-to-edge emulation of the following unstructured TDM services: 1. E1 (2048 kbit/s) as described in [G.702] 2. T1 (1544 kbit/s) as described in [G.702]. This service is also called DS1 3. E3 (34368 kbit/s) as described in [G.751]T3 (44736 kbit/s) as described in [G.702]. This service is also known as DS3 Vainshtein et al. Expires August 2003 [Page 6] TDM Circuit Emulation Service over PSN February 2003 All the unstructured TDM services discussed in this document represent specific cases of the generic bit stream payload type defined in [PWE3- ARCH]. The protocol used for emulation of these services does not depend on the physical format of the attachment circuits at both ends of the PW. 4.1.2. Structured services. Structured TDM services do not exist as physical circuits. They are always carried within appropriate physical trunks, and PEs providing their emulation always include appropriate Native Processing Blocks (NSP) commonly referred to as Framers. The only type of structured services considered in this specification are n*DS0 services with and without CAS carried in E1 or T1 trunks. The basic PE architecture supporting such services is described in Annex B. The taxonomy of n*DS0 services with CAS defined in [ATM-CES] provides the following set of services: 1. Synchronous n*DS0 service (or n*64 kbit/s) without CAS, 1 <= n <= 31. The basic structure ("frame") associated with this service that MUST be preserved in edge-to-edge emulation is an array of n octets, where the all the octets belong to the same frame of the "trunk" E1 or T1 circuit, and i-th octet contains the data of the i-th DS0 channel (timeslot) in the bundle. The circuit generates 8000 frames per second 2. "Logical" n*DS0 service with CAS, 1<= n <= 30. The definition of these services employs the "signaling" interpretation of CAS, and their emulation preserves the same basic structure as the n*DS0 without CAS. Additionally, the PW carries across the PSN changes in the state of telephony applications connected over a bundle of n independent Voice signals. The method for carrying these signals is based on [RFC8233] and is described in Annex A 3. "Trunk-specific" n*DS0 service with CAS. The definition of these services employs synchronous interpretation of CAS. Since the number and bit rates of CAS bit-streams depend on the specific framing method used with an E1 or T1 trunk, we end with the following non-interoperable services: a) E1 n*DS0 service with CAS, 1 <= n <= 30 b) T1/ESF n*DS0 service with CAS, 1 <= n <= 24 c) T1/SF n*DS0 service with CAS, 1 <= n <= 24. All the structured TDM services discussed in this document represent specific cases of the generic structured bit stream payload type defined in [PWE3-ARCH]. Vainshtein et al. Expires August 2003 [Page 7] TDM Circuit Emulation Service over PSN February 2003 4.2. Affected Protocol Layers This specification defines the encapsulation layer and payload format for edge-to-edge emulation of unstructured (T1, E1, T3, E3) and structured (n*DS0) TDM services. In accordance with the principle of minimum intervention ([PWE3-ARCH], Section 3.3.5) the TDM payload is encapsulated without any changes. 5. CESoPSN Encapsulation Layer 5.1. CESoPSN Packet Format The basic format of CESoPSN packets is 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 and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CESoPSN Control Word | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Basic CESoPSN Data Packet Format 5.2. PSN and Multiplexing Layer Headers The total size of a CESoPSN packet for a specific PW MUST NOT exceed path MTU between the pair of PEs terminating this PW. CESoPSN implementations working with IPv4 PSN SHOULD set the "Don't Fragment" flag in IP headers of the packets they generate. 5.3. CESoPSN Header The CESoPSN header comprises a fixed RTP header (12 octets) and a CESoPSN Control Word (4 octets). Note: Under certain circumstances the RTP header MAY be suppressed in order to conserve network bandwidth. See section 9.4 for details. Vainshtein et al. Expires August 2003 [Page 8] TDM Circuit Emulation Service over PSN February 2003 5.3.1. Usage of RTP Header CESoPSN uses the fields of the fixed RTP header (see [RFC1889], Section 5.1) in the following way: 1. V (version) is always set to 2 2. P (padding) is always set to 0 3. X (header extension) is always set to 0 4. CC (CSRC count) is always set to 0 5. M (marker) is set to 0 6. PT (payload type) are used as following: a) One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for each direction of the PW. The same PT value MAY be reused for both directions of the PW and also reused between different PWs b) The PE at the PW ingress MUST set the PT field in the RTP header to the allocated value c) The PE at the PW egress MAY use the received value to detect malformed packets 7. Sequence number is used primarily to provide the common PW sequencing function as well as detection of lost packets. It is generated and processed in accordance with the rules established in [RFC1889] 8. Timestamps are used primarily for carrying timing information over the network: a) Their values are generated in accordance with the rules established in [RFC1889] b) Frequency of the clock used for generating timestamps MUST be an integer multiple of 8 kHz. All implementations of CESoPSN MUST support the 8 kHz clock. Other frequencies that are integer multiples of 8 kHz MAY be used if both sides agree to that c) Possible modes of timestamp generation are discussed below 9. The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections. The RTP header in CESoPSN can be used in conjunction with at least the following modes of timestamp generation: 1. Absolute mode: the ingress PE sets timestamps using the clock recovered from the incoming TDM circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. All CESoPSN implementations MUST support this mode 2. Differential mode: PE devices connected by the PW have access to the same high-quality synchronization source, and this synchronization source is used for timestamp generation. As a consequence, the second derivative of the timestamp series represents the difference between the common timing source and the clock of the incoming TDM circuit. Support of this mode is OPTIONAL. Usage of other timestamp generation modes is left for further study. Vainshtein et al. Expires August 2003 [Page 9] TDM Circuit Emulation Service over PSN February 2003 Note: Differential mode of timestamp generation MAY be used for SRTS- like clock recovery. 5.3.2. Usage and Structure of the Control Word Usage of the CESoPSN control word allows: 1. Differentiation between the PSN problems and the problems beyond the PSN as causes for the emulated service outages 2. Saving bandwidth by not transferring invalid data (AIS, idle code) 3. Signaling problems detected at the PW egress to its ingress 4. Decoupling packet payload size from the size of the structures in case of structured emulation. The structure of the CESoPSN Control Word is shown in Fig. 2 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|D|A|X| Structure Pointer | Optional sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Structure of the CESoPSN Control Word o Bit E - if set, indicates presence of an extended control word. Extensions of the control word are not defined in this specification, hence currently this bit MUST be always set to 0 o Bit R - carries Remote Loss of Packets indication, i.e., is set in packets transmitted by PE-2 to PE-1 if PE-2 detected loss of packets in the stream received from PE-1 o Bit D - Idle Code indication, MUST be set to 1 at ingress if the packet does not carry any valid TDM data. Packets with the D bit SHOULD NOT carry any payload o Bit A - carries Local AIS indication. If set, represents an AIS condition (or any other outage that should be normally translated into AIS) of the AC of the emulated service. A packet with the A bit set MAY carry no payload o Bit X - for n*DS0 circuits MAY carry indication of the RAI condition of the carrying E1 or T1 AC o Structure pointer - for unstructured services MUST be set to 0 at ingress and MUST be ignored at egress. For structured services contains the offset (in octets) of the first octet of the first basic structure of the appropriate service in the packet from the packet payload boundary, or 0x1fff for packets that do not contain the first octet of any such structure o Optional sequence number - implementation MAY copy 14 least significant bits of the RTP sequence number into this field. Otherwise it SHOULD be set to 0 at ingress. Vainshtein et al. Expires August 2003 [Page 10] TDM Circuit Emulation Service over PSN February 2003 Notes: o The structure of the CESoPSN control word is aligned with that defined in [PWE3-SONET]. The idea to use the structure pointer in order to decouple the packet payload size from the structure size for emulation of structured services has been adapted to the structured TDM service emulation that deals with relatively short structures o For n*DS0 services, bits A and X are filled according to the AC state indications generated by the Framer. For unstructured E1, T1 and E3 services, the AIS condition ("all ones") can be detected by the Line Interface Unit (LIU). Detection of the RAI condition for all types of services as well as detection of the AIS condition for the T3 service requires operation of an appropriate Framer in the "transparent" mode o Information carried in bits A and X can be used in the Fractional E1/T1 applications (see below). 6. CESoPSN Payload Layer 6.1. Common Payload Format Considerations CESoPSN always uses the so-called "Telecom" ordering, i.e.: o The order of the payload octets corresponds to their order on the PWES line o Consecutive bits coming from the PWES line fill each payload octet starting from its most significant bit to the least significant one. In any case, the PE devices terminating a CESoPSN PW MUST agree on the common packet payload size for both directions of the PW at the time of the PW setup. 6.2. Payload Format for Structured Services 6.2.1. Common Considerations All the structured services are considered in this document are treated as sequences of "basic structures" (see Section 4.1 above). The payload of a CESoPSN packet always consists of a fixed number of octets filled, octet by octet, with the data contained in the corresponding consequent basic structures preserving octet alignment between these structures and the packet payload boundaries. By default, CESoPSN SHOULD use alignment of the basic structures with the packet payload boundaries. This means that: 1. The packet payload size SHOULD be an integer multiple of the structure size 2. The first structure in the packet SHOULD start immediately at the beginning of the packet payload (in other words, the structure pointer will be 0). Vainshtein et al. Expires August 2003 [Page 11] TDM Circuit Emulation Service over PSN February 2003 This mode of operation complies with the recommendation in [PWE3-ARCH] to use similar encapsulations for structured bit stream and cell generic payload types. However, CESoPSN allows decoupling between the packet payload size and the size of the basic structure by using the structure pointer in the control word as defined in [PWE3-SONET]. This pointer would then point to the first occurrence of the first octet of the structure in the packet payload. If the packet does not contain the 1st octet of any structure, the pointer MUST be set to 0x1fff. 6.2.2. Synchronous n*DS0 Services without CAS As mentioned above, the basic structure for this service consists of n octets filled with the data of the corresponding DS0 channels belonging to the same frame of the originating trunk, and the service generates 8000 such structures per second. Packetization latency, number of timeslots and payload size are linked by the following obvious relationship: L = 8*n*D where: o D is packetization latency, milliseconds o L is packet payload size, octets o n is number of DS0 channels. CESoPSN implementations supporting synchronous n*DS0 Services without CAS MUST support the following set of configurable packetization latency values: o For n >= 5 - 1, 2 and 3 milliseconds (with the corresponding packet payload size of 8*n, 16*n and 24*n octets respectively) o For 1 <= n <= 4 - 6 milliseconds (with the corresponding packet payload size of 48*n octets). Usage of any other packetization latency (packet payload size) is OPTIONAL. 6.2.3. Logical n*DS0 with CAS: Data and Signaling Packets The basic structure for this service consists of n octets filled with the data of the corresponding DS0 channels belonging to the same frame of the originating trunk. All CESoPSN implementations supporting logical n*DS0 service with CAS MUST support the same set of configurable packetization latency values (and packet payload sizes) as n*DS0 without CAS (see above). In addition to TDM data, the PWs supporting this service carry encoded CE application state in separate signaling packets. In order to do that, they MUST allocate an additional RTP payload type (from the range Vainshtein et al. Expires August 2003 [Page 12] TDM Circuit Emulation Service over PSN February 2003 of dynamically allocated types) for these packets. In addition, the signaling packets use their own SSRC value (different from that used for the TDM data packets) and their own sequence numbers. Format of the signaling packets is shown in Fig. 3 below. Received signaling packets are played out after synchronization with the TDM data. The synchronization uses the standard RT-based mixing procedures (see [RFC1889]). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Encoded CE application state entry for the DS0 channel #1 | +-- --+ | ... | +-- --+ | Encoded CE application state entry for the DS0 channel #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. CESoPSN Signaling Packet Format CE application state is represented by the current value of CAS bits for the DS0 channel and is encoded in accordance with the rules presented in [RFC2833]. Details of the protocol are discussed in Annex A. 6.2.4. Trunk-Specific n*DS0 Services with CAS Payload format for trunk-specific n*DS0 services with CAS is left for further study. 6.3. Unstructured Services 6.3.1. Basic Payload Format For unstructured services, the payload of a CESoPSN packet consists of a fixed number of octets filled with the raw TDM data received from the incoming line. The packet payload size MUST be defined during the PW setup, MUST be the same for both directions of the PW and MUST remain unchanged for the life span of the PW. All the CESoPSN implementations MUST support the following packetization latency (packet payload size) values: Vainshtein et al. Expires August 2003 [Page 13] TDM Circuit Emulation Service over PSN February 2003 1. E1 - 1 millisecond (256 octets) 2. T1 - 1 millisecond (193 octets) 3. E3 - 125 microseconds (535 octets) 4. T3 - 125 microseconds (699 octets). Usage of any other packetization latency (packet payload size) is OPTIONAL. Note: The default packetization latency for E1 provides for deployment of local methods for handling occasional loss of packets that improve resilience of CEs to bursts of errors in the emulated service that result from such a loss (see below). 6.3.2. Octet-aligned T1 Service Support of n*DS0 services without CAS provides an additional option for transferring unstructured T1: o First, it is mapped into 25*DS0 bundle in accordance with the rules described in [G.802] o The 25*DS0 bundle is then carried over the PSN as an appropriate CESoPSN PW. Support of octet-aligned T1 service is OPTIONAL. CESoPSN implementations supporting this service MUST support applicable set of packetization latency values from Section 6.2.2. 7. CESoPSN Operation 7.1. Common Considerations Edge-to-edge service emulation of a TDM service using CESoPSN assumes the following elements: o Two PW end services of the same type and bit rate o Packetizer at the PW ingress o Jitter buffer and de-packetizer at the PW egress. Setup of a CESoPSN PW assumes exchange of the following information: o Types of end services. In order to be connected by a CESoPSN PW, these types MUST be the same and define the PW type. Proposed values for the PW types supported by CESoPSN is given in Annex C o Bit rates of end services. In order to be connected, bit rates of the two end services MUST be the same o Encapsulation layer-specific parameters. These parameters are described in Annex C. 7.2. End Service Inactivity Behavior For PWs carrying unstructured services, the PE MUST send "all ones" code to its local PE while the PW is inactive. Vainshtein et al. Expires August 2003 [Page 14] TDM Circuit Emulation Service over PSN February 2003 For n*DS0 with and without CAS, while the PW is inactive the PE MUST send some (locally configured) Idle Code to its local CE. For n*DS0 with CAS (logical or trunk-specific) it MUST also play out the CAS bits values representing the Idle state of the telephony application at the other end each of the DS0 channels (the specific value is a local matter). In addition, it MAY also send a Force AIS command to the Framer. 7.3. Description of the IWF operation Once the PW is set up, the CESoPSN IWF operates like following: 7.3.1. PSN-bound Direction o End service data is packetized in accordance with the number of payload bytes specified. o Sequence numbers and timestamps representing the selected synchronization clock are inserted in the CESoPSN headers as well as (for structured services) appropriate values of the structure pointers. o CESoPSN, multiplexing and PSN headers are prepended to the packetized service data o Resulting packets are transmitted via the PSN o If the PE detects any outage of the incoming end service that natively would result in sending the "downstream AIS", the CESoPSN IWF using the control word MUST set the local AIS indication flag (bit A) in the control word. The packet payload MAY be omitted in order to save the PSN bandwidth. o For N*DS0 services, if the PE detects an RAI condition of the E1 or T1 AC, the CESoPSN IWF using the control word SHOULD set RAI flag (bit X) in the control word o The PE SHOULD set bit D in the CESoPSN control word if it decides, for some reason, that the packet cannot contain any valid TDM data. In this case the packet payload MUST be omitted. Local AIS indications in the CESoPSN control word provide for the following functionality: o Ability to distinguish between the PSN problems and ones beyond the PSN as causes of outages of the emulated service o Ability to save the PSN bandwidth (but not its switching capacity) by not sending invalid data across the PSN. RAI indication is useful in the so-called "Fractional E1/T1" applications (see below). The techniques to save the PSN switching capacity in case of an end service outage are left for further study. 7.3.2. CE-bound Direction The CE-bound IWF includes a jitter buffer that accumulates data from incoming CESoPSN packets with their respective timestamps. The length Vainshtein et al. Expires August 2003 [Page 15] TDM Circuit Emulation Service over PSN February 2003 of this buffer SHOULD be configurable to allow adaptation to various network delay behavior patterns. Size of the jitter buffer is a local parameter of the CESoPSN IWF. Initially the Jitter buffer is filled with the appropriate inactivity (AIS or Idle) code. Immediately after start, the IWF: o Begins reception of incoming CESoPSN packets. PSN and multiplexing layer headers are stripped from the received packets, and packetized TDM data from the received packets is stored in the jitter buffer. o Continues to play out its appropriate inactivity code into its end service as long as the jitter buffer has not yet accumulated sufficient amount of data o Once the jitter buffer contains sufficient amount of data (usually half of its capacity), the IWF starts replay of this data in its end service in accordance with its (locally defined) 8 KHz transmission clock. If transmission clock must be recovered from the PW, the timestamps of data packets SHOULD be used for correcting initial transmission clock frequency in accordance with the specified mode of their generation The CE-bound IWF SHOULD provide access to the value of the timestamp of the packet that is currently played out. This value MAY be used for synchronization between TDM data and CE application signals. CESoPSN packets marked with an AIS or Idle Code indication in the control word MUST be replaced with the appropriate amount of AIS (for unstructured services) or Idle code (for structured services) in the jitter buffer. The CE-bound direction of the IWF: o Performs detection, correlation and handling of CESoPSN faults as described in Section 7.4 below o Collects the PW Performance Monitoring data as defined in Section 7.5 below The CE-bound IWF for an n*DS0 service with or without CAS MAY be configured to send the following commands to its NSP (see Annex B): 1. "Force AIS" command: a) If it detects a Loss of Packets condition b) While it plays out CESoPSN packets with the AIS indication set 2. "Force RAI" command - while it plays out CESoPSN packets with RAI indication set. Vainshtein et al. Expires August 2003 [Page 16] TDM Circuit Emulation Service over PSN February 2003 Notes: 1. The IWF configuration described above: a) Is specific per IWF instance b) Is a local issue. In particular, it is possible to configure only one of the two IWF instances associated with the given PW to force AIS and RAI states on its outgoing AC c) Makes sense only if the IWF instance in question is the only IWF instance associated with the specific outgoing AC 2. If both IWF instances associated with the given PW are configured to force AIS and RAI states on their respective outgoing ACs, the CE devices may effectively treat the PW as part of an emulated E1 or T1 service while the PSN carries only an N*DS0 service (thus possibly saving BW). 3. Extension of mechanisms allowing the CE-bound IWF to force some special states on the outgoing AC to other services is left for further study. 7.4. CESoPSN Defects 7.4.1. Misconnection Some combinations of PSN and multiplexing layers inherently provide for detection of packets that do not belong to the PW ('stray packets'). CESoPSN MAY use the SSRC field in the RTP header for detection of 'stray packets' even if such a capability is provided by the specific combination of PSN and multiplexing layers. Regardless of the way in which a stray packet has been detected: o It MUST be discarded by the CE-bound IWF o A counter of 'stray packets' must be incremented If reception of stray packets persists above a configurable period of time (by default, 2.5 seconds), the Misconnection alarm SHOULD be reported to the management system. This alarm SHOULD be cleared if no stray packets have been detected for a configurable period of time (by default, 10 seconds). The IWF mechanisms for detection of lost packets (e.g., expected next sequence number) MUST NOT be affected by reception of 'stray packets'. 7.4.2. Re-Ordering and Loss of Packets CESoPSN implementations SHOULD use sequence numbers in the RTP header and expected rate of transmission of data packets for detection of our- of-order delivery and packet loss. If RTP header is suppressed, they MUST use the sequence number in the CESoPSN control word. Out-of-order packets that cannot be reordered MUST be considered as lost. Vainshtein et al. Expires August 2003 [Page 17] TDM Circuit Emulation Service over PSN February 2003 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 "replacement packets" in order to substitute exactly one "replacement octet" for every lost octet of TDM data. The content of these packets is a local matter. All CESoPSN implementations MUST support generation of replacement packets filled with "all ones" replacement octets for the TDM data. Use of other methods of generation of "replacement packets" is OPTIONAL. In addition: o A counter of lost packets must be incremented o The Remote Lost Packets Indication flag (bit R) MUST be set in the next packet to be sent in the opposite direction of the PW o If the packet loss condition persists above a configurable period of time (by default, 2.5 seconds), a Loss of Packets alarm SHOULD be sent to the management system. This alarm SHOULD be cleared if no stray packets have been detected for a configurable period of time (by default, 10 seconds). Note: Selected default packet payload size for unstructured E1 services allows using the last received CESoPSN packet as a replacement packet while preserving valid FAS. Such a mode of generation of replacement packets prevents early detection of AIS or OOF condition by CEs using simple E1 framers. The rest of the unstructured services are more resilient to using "all ones" replacement packets (see [G.706] and [G.775] for details). 7.4.3. Malformed Packets CESoPSN PW detects a malformed packet using the following rules: o The PT value in its RTP header does not correspond to one of the PT values allocated for this direction of the PW o The actual packet payload size can be unambiguously inferred from the data link, PSN or multiplexing layer of the PW and does not match the payload size defined for the packets of this type in this PW. If a malformed in-order packet has been received at the egress of a CESoPSN PW, then: o The packet MUST be discarded and appropriate amount of AIS (or Idle Code) inserted in the jitter buffer o A counter of malformed packets must be incremented o If the payload mistype condition persists above a configurable period of time (by default, 2.5 seconds), a Malformed Packets alarm SHOULD be sent to the management system. This alarm SHOULD be cleared if no malformed packets have been detected for a configurable period of time (by default, 10 seconds). 7.4.4. Loss of Synchronization The CESoPSN IWF MAY detect two types of loss of synchronization errors: Vainshtein et al. Expires August 2003 [Page 18] TDM Circuit Emulation Service over PSN February 2003 7.4.5.1 Jitter Buffer Overrun This fault is detected if the jitter buffer at the PW egress cannot accommodate the newly arrived CESoPSN packet in its entirety. A CESoPSN packet that cannot be stored in the jitter buffer MUST be discarded. If the jitter buffer overrun condition persists above a configurable period of time (by default, 2.5 seconds), a Jitter Buffer Overrun alarm should be sent to the management system. This alarm SHOULD be cleared if no cases of overrun have been detected for a configurable period of time (by default, 10 seconds). 7.5.4.2. Jitter Buffer Underrun This fault is detected if the jitter buffer at the PW egress becomes empty before arrival of a new CESoPSN packet while loss of packets has not been detected. Ability to detect the Jitter Buffer Underrun defect depends upon the capabilities of the packet loss detection and is OPTIONAL. If the jitter buffer underrun can be detected condition persists above a configurable period of time (by default, 2.5 seconds), a Jitter Buffer Underrun alarm should be sent to the management system. This alarm SHOULD be cleared if no cases of underrun have been detected for a configurable period of time (by default, 10 seconds). 7.4.5. Remote Packet Loss CESoPSN implementations SHOULD detect Remote Packet Loss condition based upon the presence of the Remote Loss of Packets indication in the received packets. If the Remote Packet Loss condition persists above a configurable period of time (by default, 2.5 seconds), a Remote Packet Loss alarm SHOULD be sent to the management system. This alarm SHOULD be cleared if no packets with the Remote Loss of Packets indication have been received for a configurable period of time (by default, 10 seconds). 7.5. Performance Monitoring 7.5.1. Errored Data Blocks [G.826] defines the concept of an errored data block that serves as the basis of for collection of performance monitoring parameters. It also defines the size of the data block for most TDM circuits. These definitions are aligned with the 'native circuit frame' size of these circuits so that every G.826-compatible data block contains an integer multiple of native circuit frames. The following definitions of error events and errored data blocks for CESoPSN provide for collection of [G.826]-compatible performance monitoring parameters: Vainshtein et al. Expires August 2003 [Page 19] TDM Circuit Emulation Service over PSN February 2003 o An error event is insertion of a single native service frame of inactivity code into the jitter buffer if it does not stem from receiving a CESoPSN packet with an AIS or Idle Code indication o An errored data block is a data block defined in accordance with [G.826] that has experienced at least one error event o A defect is insertion of a contiguous sequence of native service frames of inactivity code into the jitter buffer if it does not stem from receiving a CESoPSN packet with an AIS or Idle Code indication and if the length of this sequence exceeds the limits defined by the defect detection rules of the emulated service. 7.5.2. Errored, Severely Errored and Unavailable Seconds The definition of an errored data block presented above can be used to define Errored Seconds, Severely Errored Seconds and Unavailable Seconds in accordance with [G.826]. 8. QoS Issues If the PSN providing connectivity between PE devices is Diffserv- enabled and provides a PDB [RFC3086] that guarantees low-jitter and low-loss, the CESoPSN PW SHOULD use this PDB in compliance with the admission and allocation rules the PSN has put in place for that PDB (e.g., marking packets as directed by the PSN). 9. RTP Payload Format Considerations In accordance with guidelines specified in [RFC2736], the following issues are addressed by this specification: 9.1. Resilience to moderate loss of individual packets The impact of loss of an individual data packet may be decreased by decreasing the packet size (with the associated loss of efficiency). 9.2. Ability to interpret every single packet This requirement is always met for CESoPSN packets carrying unstructured services. For structured services it is met in the default situation when the packet payload boundaries are aligned with the structures so that the transmitter generates zero structure pointers. 9.3. Non-usage of the RTP Header Extensions This recommendation is met, since RTP-wise, the CESoPSN Control Word is part of the RTP payload. Alignment with this requirement facilitates usage of standard header compression mechanisms if CESoPSN uses UDP/IP as its PSN and multiplexing layers. Vainshtein et al. Expires August 2003 [Page 20] TDM Circuit Emulation Service over PSN February 2003 9.4. Compression of RTP headers Existing relevant standards ([RFC2508], [RFC3095]) deal with compression of RTP/UDP/IP headers on specific P2P links. Compression techniques defined in these documents are fully applicable for CESoPSN if it uses UDP/IP as PSN and multiplexing layers respectively. Standard compression of CESoPSN/UDP/IP headers will be very effective, since: o Value of the SSRC field in the CESoPSN header of data packets remains constant for the duration of a CESoPSN session 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. In addition to these methods, the RTP header shown in Fig. 1 MAY be completely suppressed if the both PEs support such suppression. In this case the sequence number in the CESoPSN control word MUST be used and MUST be generated in accordance with rules stated in [RFC1889]. The resulting structure of the CESoPSN packet is shown in Fig. 4 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CESoPSN Control Word with mandatory sequence number | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. CESoPSN Packet Format with Suppressed RTP Header If the RTP header has been compressed, the sequence number in the CESoPSN control word MUST be used and MUST be generated according to the same rules as if the RTP header were present. Note: The CESoPSN PWs carrying logical n*DS0 with CAS rely on the RTP- based mixing techniques for synchronization between TDM data and CE application signals. As a consequence, it is impossible to suppress the RTP header for these PWs. 10. Congestion Control (RFC 2914) Conformance CESoPSN PWs represent a special case of PWs carrying constant bit rate (CBR) services across the PSN. These services, by definition, cannot behave in a TCP-friendly manner prescribed by [RFC2914] under congestion while retaining any value for the user. CESoPSN will use the generic PWE3 approach for handling congestion in PWs carrying CBR services when such an approach has been specified. Vainshtein et al. Expires August 2003 [Page 21] TDM Circuit Emulation Service over PSN February 2003 11. 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 CESoPSN payload format for carrying trunk-specific n*DS0 with CAS o Techniques for saving the PSN switching capacity when the PW experiences an end service outage or does not carry any valid data o Effect of timestamp resolution on quality of clock recovery in Differential mode o Extension of techniques for forcing states on outgoing ACs to emulation of other services o Usage of extended control word for suppression of "idle" channels in n*DS0 services with and without CAS. 12. Security Considerations This document does not affect the underlying security issues of specific PSN. In addition, it defines misconnection detection capabilities of CESoPSN. These capabilities increase resilience of CESoPSN to misconfiguration and some types of DoS attacks. 13. Applicability Statement CESoPSN is an encapsulation layer intended for carrying TDM circuits (n*DS0 with and without CAS, unstructured E1/T1 and unstructured E3/T3) over PSN. CESoPSN allows, within reasonable limits, to emulate end-to-end delay properties of TDM networks. In particular, in most cases the edge-to- edge delay introduced by CESoPSN PWs does not depend upon the type and bit-rate of the emulated service. CESoPSN allows carrying both data and clock of TDM circuits across multiple types of PSN. CESoPSN allows carrying CE application state signaling that requires synchronization with data in-band in separate signaling packets. The RTP Payload Type (PT) is used to distinguish between data and signaling packets, while the Timestamp field is used for synchronization. This makes CESoPSN extendable to support different types of CE signaling without affecting the data path in the PE devices. Vainshtein et al. Expires August 2003 [Page 22] TDM Circuit Emulation Service over PSN February 2003 CESoPSN does not presume availability of a global synchronous clock at the ends of a PW. This makes it suitable for Asynchronous Carriers' Carrier applications. CESoPSN fully complies with the principle of minimal intervention minimizing overhead and computational power required for encapsulation. CESoPSN uses RTP for carrying the clock across the PSN whenever necessary. The additional CESoPSN control word is a "payload format header" and hence standard header compression techniques for RTP/UDP/IP profile over slow and/or error-prone links are fully applicable to CESoPSN PWs. CESoPSN allows the PSN bandwidth conservation by carrying only AIS and/or Idle Code indications instead of data. CESoPSN allows deployment of BW-saving Fractional point-to-point E1/T1 applications. These applications can be described like following: o The pair of CE devices operates as if they were connected by an emulated E1 or T1 circuit. In particular they react to AIS and RAI states of their local ACs in the standard way o The PSN carries only an N*DS0 service where N is the number of actually used timeslots in the circuit connecting the pair of CE devices thus saving the BW. Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP- friendly behavior under network congestion. If the service encounters congestion, it should be temporarily shut down. CESoPSN allows collection of TDM-like faults and performance monitoring parameters hence emulating 'classic' carrier services of TDM circuits (e.g., SONET/SDH). Similarity with these services is increased by the CESoPSN ability to carry 'far end error' indications. CESoPSN provides for a carrier-independent ability to detect misconnections and malformed packets. This feature increases resilience of the emulated service to misconfiguration and DoS attacks. CESoPSN provides for detection of lost packets and hence allows distinguishing between the PSN problems and ones beyond the PSN as causes of outages of the emulated service. Faithfulness of a CESoPSN PW may be increased if the carrying PSN is Diffserv-enabled and implements a PDB that guarantees low loss and low jitter. CESoPSN carries indications of outages of incoming attachment circuit across the PSN and provides of detection of lost packets. The combination of these abilities provides for effective fault isolation. CESoPSN does not provide any mechanisms for protection against PSN outages. As a consequence, resilience of the emulated service to such outages is defined by the PSN behavior. On the other hand: Vainshtein et al. Expires August 2003 [Page 23] TDM Circuit Emulation Service over PSN February 2003 o The jitter buffer and packets' reordering mechanisms associated with CESoPSN increase resilience of the emulated service to fast PSN rerouting events o Remote indication of lost packets is carried backward across the PSN from the receiver (that has detected loss of packets) to transmitter. Such an indication MAY be used as a trigger for activation of proprietary service-specific protection mechanisms. 14. IANA Considerations This specification requires assignment of new PW Types for CESoPSN PWs listed in Section 4.1. 15. Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. Axerra Networks, Inc. has filed one or more patent applications relating to the CESoPSN technology outlined in this document. Axerra Networks, Inc. will grant free unlimited licenses for use of this technology to the users who will register and sign up at the Axerra web site. ACKNOWLEDGEMENTS We express deep gratitude to Stephen Casner who reviewed this document in detail, corrected some serious errors and provided many valuable inputs. The present version of the text of the QoS section has been suggested by Kathleen Nichols. We thank Maximilian Riegel, Sim Narasimha, Tom Johnson, Ron Cohen and Yaron Raz for valuable feedbacks. We thank Yaakov (Jonathan) Stein for his constructive role in preparation of a document that described emulation of unstructured TDM services. We thank Alik Shimelmits for many fruitful discussions. MANDATORY REFERENCES [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 Vainshtein et al. Expires August 2003 [Page 24] TDM Circuit Emulation Service over PSN February 2003 [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, RFC 2434, 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 [RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000 [RFC3086] K. Nichols, B. Carpenter, Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification, RFC 3086, IETF, 2001 [RFC3095] C. Bormann (Ed.), RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC 3095, IETF, 2001 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- parameters [G.114] ITU-T Recommendation G.114 (05/2000) - International telephone connections and circuits - Recommendations on the transmission quality for an entire international telephone connection. One-way transmission time [G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit Rates [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.706] ITU-T Recommendation G.706 (04/91) - Frame Alignment and Cyclic Redundancy Check (CRC) Procedures Relating to Basic Frame Structured Defined in Recommendation G.704 [G.751] ITU-T Recommendation G.751 (xx/93) - Digital Multiplex Equipments Operating at the Third Order Bit Rate of 34368 kbit/s and the Fourth Order Bit Rate of 139264 kbit/s and Using Positive Justification [G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect Detection and Clearance Criteria for PDH Signals Vainshtein et al. Expires August 2003 [Page 25] TDM Circuit Emulation Service over PSN February 2003 [G.826] ITU-T Recommendation G.826 (02/99) - Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate [T1.107] American National Standard for Telecommunications - Digital Hierarchy - Format Specifications, ANSI T1.107-1988 [ATM-CES] The ATM Forum Technical Committee. Circuit Emulation Service Interoperability Specification version 2.0 af-vtoa-0078.000, January 1997. INFORMATIONAL REFERENCES [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in Progress, July-2001, draft-ietf-pwe3- requirements-01.txt [PWE3-TDM-REQ] Maximilian Riegel et al, Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN), Work in Progress, June 2002, draft-riegel-pwe3-tdm-requirements-00.txt [PWE3-ARCH] S. Bryant, P. Pate et al, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in progress, June 2002, draft-ietf- pwe3-framework-01.txt [PWE3-SONET] A. Malis, P. Pate, SONET/SDH Circuit Emulation over Packet (CEP), Work in progress, January 2003, draft-ietf-pwe3-sonet-01.txt [MARTINI-TRANS] Luca Martini et al, Transport of Layer 2 Frames Over MPLS, Work in progress, April 2002, draft-martini-l2circuit-trans-mpls- 09.txt Authors' Addresses Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St., Tel Aviv 69719, Israel email: sasha@axerra.com Israel Sasson Axerra Networks 24 Raoul Wallenberg St., Tel Aviv 69719, Israel email: israel@axerra.com Akiva Sadovski Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: akiva@axerra.com Vainshtein et al. Expires August 2003 [Page 26] TDM Circuit Emulation Service over PSN February 2003 Eduard Metz Thrupoint Paasheuvelweg 16, email: eduard.metz@hetnet.nl Tim Frost Zarlink Semiconductor Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK email: tim.frost@zarlink.com Prayson Pate Overture Networks 507 Airport Boulevard Building 111 Morrisville, North Carolina, 27560 Email: prayson.pate@overturenetworks.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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. A COMMON CE APPLICATION STATE SIGNALING MECHANISM A PW that requires conveyance of CE application state signals that must be synchronized with data carries encoded CE applications in special signaling packets using: Vainshtein et al. Expires August 2003 [Page 27] TDM Circuit Emulation Service over PSN February 2003 o An additional PT value allocated for this purpose from the range of unused values (see [IANA]). This value MUST be different from one allocated for the TDM data packets for the same PW o An additional SSRC value that MUST be different from one used for the data packets in order to allow a separate numbering sequence for the signaling packets o A sequence numbering scheme that does not depend on one used for the data packets. This allows re-use of common sequence numbers-based mechanisms (like reordering and detection of lost packets) for the data packets for all types of circuits Handling of loss of signaling packets is not required; as a consequence, detection of loss of these packets is not required either. The RTP header of the signaling packets is used in the following way: 1. V (version) is always set to 2 2. P (padding) MAY be used in accordance with the application- specific CE state encoding rules 3. X (header extension) is always set to 0 4. CC (CSRC count) is always set to 0 5. M (marker) is set to 1 to for "urgent" signaling packets. The CE application state carried in these packets will be conveyed to the CE at the egress of the PW immediately, without any re-synchronization with the data. State carried in "normal" signaling packets will be conveyed to the CE at the PW egress after re-synchronization with the TDM data 6. PT (payload type) is used to distinguish between packets carrying the packetized TDM data and signaling packets. In accordance with that, CESoPSN PWs using the CE application state signaling mechanism MUST: a) Allocate an additional PT value from the range of dynamic values (see [RTP-TYPES]) for its signaling packets. The allocation is done during the PW setup and MUST be the same for both PW directions b) The PE at the PW ingress MUST set the PT value in the RTP header of signaling packets to the allocated value c) The PE at the PW egress MUST use this value to distinguish between TDM data and signaling packets. 7. The SSRC (synchronization source) value in the RTP header of signaling packets MUST be different from that used by the data packets 8. Sequence number is generated and processed in accordance with the rules established in [RFC1889]. There should be no connection between the sequence numbers used by the data and signaling packets 9. Timestamps are used for re-synchronization between TDM data and CE application state signals at the PW egress: a) Their values are generated in accordance with the rules established in [RFC1889] Vainshtein et al. Expires August 2003 [Page 28] TDM Circuit Emulation Service over PSN February 2003 b) Frequency of the clock used for generating timestamps MUST be a multiple of 8 KHz and SHOULD be the same as that used for the data packets 10. Each PE terminating the PW SHOULD send RTCP sender reports (see RFC1889], Section 6.3.1) for the clock sources used for generation of timestamps of both TDM data and signaling packets to its peer: a) These packets MAY be limited only to the header and 'Sender Info' sections b) The PE receiving these packets SHOULD use the information contained in the 'Sender Info' in order to map (approximately) timestamps received in the signaling packets to these received in the data packets. Signaling packets are generated by the ingress PE in accordance with the following logic (adapted from [RFC2833]): 1. The CESoPSN signaling packet with the same information is sent 3 times at an interval of 5 ms under one of the following conditions: a) The CESoPSN PW has been set up. These packets MUST be marked as "urgent" b) A change in the CE application state has been detected. If another change of the CE application state has been detected during the 15 ms period, this process continues c) Loss of packets defect has been cleared. These packets SHOULD be marked as "urgent" d) Remote Loss of Packets indication has been cleared (after previously being set) These packets SHOULD be marked as "urgent" 2. Otherwise, the CESoPSN signaling packet with the current CAS state information is sent every 5 seconds. These rules allow fast probabilistic recovery after loss of a single signaling packet as well as deterministic (but, possibly, slow) recovery following PW setup and PSN outages. Encoding of CE application state for various common applications will be considered in separate documents. ANNEX B. REFERENCE PE ARCHITECTURE FOR EMULATION OF N*DS0 SERVICES Structured TDM services do not exist as physical circuits. They are always carried within appropriate physical attachment circuits (AC), and the PE providing their emulation always includes a Native Processing Block (NSP) commonly referred to as Framer. As a consequence, the architecture of a PE device providing edge-to-edge emulation for these services includes the Framer and Forwarder blocks. In case of n*DS0 services (the only type of structured services considered in this document), the AC is either an E1 or a T1 trunk, and Vainshtein et al. Expires August 2003 [Page 29] TDM Circuit Emulation Service over PSN February 2003 bundles of n*DS0 are cut out of it using one of the framing methods described in [G.704]. In addition to detecting the FAS and imposing associated structure on the "trunk" AC, E1 and T1 framers commonly support some additional functionality including: 1. Detection of special states of the incoming AC (e.g., AIS, OOF or RAI) 2. Forcing special states (e.g., AIS and RAI) on the outgoing AC upon an explicit request 3. Extraction and insertion of CE application signals that may accompany specific DS0 channel(s). The resulting PE architecture for n*DS0 services is shown in Fig. B.1 below. In this diagram: 1. In the PSN-bound direction: a) The Framer: i) Detects frame alignment signal (FAS) and splits the incoming AC into separate DS0 services ii) Detects special AC states iii) If necessary, extracts CE application signals accompanying each of the separate DS0 services b) The Forwarder: i) Creates one or more n*DS0 bundles ii) Sends the data received in each such bundle to the PSN-bound direction of a respective CESoPSN IWF instance iii) If necessary, sends the current CE application state data of the DS0 services in the bundle to the PSN-bound direction of the respective CESoPSN IWF instance iv) Sends the AC state indications to the PSN-bound directions of all the CESoPSN instances associated with the given AC c) Each PSN-bound PW IWF instance encapsulates the received data, application state signal and the AC state into PW PDUs and sends the resulting packets to the PSN 2. In the CE-bound direction: i) Each CE-bound instance of the CESoPSN IWF receives the PW PDUs from the PSN, extracts the TDM data, AC state and CE application state signals and sends them b) The Forwarder sends the TDM data, application state signals and, if necessary, a single command representing the desired AC state, to the Framer c) The Framer accepts all the data of one or more N*DS0 bundles possibly accompanied by the associated CE application state and commands referring to the desired AC state, and generates a single AC accordingly with correct FAS. Notes: This model is asymmetric: o AC state indication can be forwarded from the framer to multiple instances of the CESoPSN IWF Vainshtein et al. Expires August 2003 [Page 30] TDM Circuit Emulation Service over PSN February 2003 o No more than one CESoPSN IWF instance should forward AC state- affecting commands to the framer. +------------------------------------------+ | PE Device | +------------------------------------------+ | | Forwarder | | | |---------------------| | | | | | | +<-- AC State---->- | | | | | | | | | | | | | | | | | | | | | | | |-----------------+---|--------------| | | | | At most one | | | |-->+ PW IWF | | | | instance im- | | +<---N*DS0 TDM Data-->+ posing state | PW Instance | F | | on the X<===========> | +<---CE App State --->+ outgoing AC | Singe E1 | R | | | or T1 AC | +<--AC Command -------+ | <=======>o A |---------------------|--------------| | | ... | ... | ... | M |-----------------+---|--------------| | | | | Zero, one or | | E | |-->+ more PW IWF | | | | instances | R +<---N*DS0 TDM Data-->+ that do not | PW Instance | | | impose state X<===========> | +<---CE App State --->+ on the outgo-| | | | ing AC | +------------------------------------------+ Figure B.1. PE Architecture for n*DS0 Services ANNEX C. PAYLOAD AND ENCAPSULATION LAYER PARAMETERS C.1 Payload Parameters C.1.1. PW Types PW types (a.k.a. VC types) have been defined in [MARTINI-TRANS]. PW types used for CESoPSN PW are assigned in such a way as to avoid overlap with types assigned in other PWE3 documents. The following PW types are defined in this document for CESoPSN-based PWs: o n*DS0 without CAS - 65 o E1 - 66 o T1 - 67 Vainshtein et al. Expires August 2003 [Page 31] TDM Circuit Emulation Service over PSN February 2003 o Octet-aligned T1 - 69 o E3 - 70 o T3 - 71 o Logical n*DS0 with CAS - 72 o E1 n*DS0 with CAS - 73 o T1 (ESF) n*DS0 with CAS - 74 o T1 (SF) n*DS0 with CAS - 75. C.1.2. The Service Bit Rate For n*DS0 services (with and without CAS) this parameter encodes (as an integer) the number of DS0 channels that are carried by the PW. This parameter is irrelevant for PWs carrying unstructured services. C2. Encapsulation Layer Parameters C2.1. Payload Bytes This parameter has been defined in [MARTINI-TRANS]. In order to establish a CESoPSN-based PW, the following conditions MUST be met: 1. The number of payload bytes MUST be the same for both directions of the PW 2. The size of the resulting PW packet (including all the headers) SHOULD NOT exceed the path MTU between the participating PEs as provided by the Carrier layer. Note: For PWs carrying logical n*DS0 with CAS this parameter defines the number of payload bytes in the TDM data packets only. C2.2 RTP-Related Parameters The following parameters MUST be specified if RTP header is not suppressed. Otherwise, they are irrelevant. C2.2.1. RTP Payload Types One PT value MUST be allocated from the range of dynamically allocated payload types for each CESoPSN PW for use in the data packets as described in Section 5.3.1 above. For logical n*DS0 with CAS additional PT values MUST be allocated from the range of dynamically allocated payload types for each direction of the CESoPSN PW for use in the signaling packets so that: o They MUST be different from the PT value(s) allocated for data packets o The same value MAY be re-used for both directions of the PW o Ingress PW MUST set the PT in the RTP header of all the signaling packets to the allocated value Vainshtein et al. Expires August 2003 [Page 32] TDM Circuit Emulation Service over PSN February 2003 o Egress PW MAY use this value to distinguish signaling PW packets. Note: The same PT value may be allocated for multiple PWs. C2.2.2. Timestamp Resolution This parameter encodes the rate of the clock used for setting timestamps in RTP headers as a multiple of the basic 8 KHz rate. C.2.2.3. Synchronization Source ID The same 32-bit SSRC value MUST be assigned to all the data packets of a given direction of a CESoPSN PW. The CE-bound direction of the IWF MAY be use this value for misconnection detection, especially if such a service is not provided by the PSN and/or multiplexing layer(s). For PWs carrying logical n*DS0 with CAS, the signaling packets MUST use a separate SSRC value. C.2.2.4. Timestamp Generation Mode This parameter encodes the selected timestamp generation mode. The values assigned to the modes described in Section 5.2.1 are: o Absolute (1) - the timestamps are generated in accordance with the line clock of the incoming AC o Differential (2) - the timestamps are generated in accordance with a common reference clock of the pair of PEs. Vainshtein et al. Expires August 2003 [Page 33]