Network Working Group A. Vainshtein - Editor (Axerra Networks) Internet Draft I. Sasson (Axerra Networks) A. Sadovski (Axerra Networks) Expiration Date: E. Metz (Thrupoint) December 2003 T. Frost (Zarlink Semiconductor) P. Pate (Overture Networks) June 2003 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) draft-vainshtein-cesopsn-06.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 (Nx64 kbit/s) 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 -05 Revision..........................3 3. Terminology and Reference Models..................................4 3.1. Terminology...................................................4 3.2. Reference Models..............................................5 3.2.1. Generic Models............................................5 3.2.2. Synchronization Considerations and Deployment Scenarios...5 3.2.3. Generic and Specific Requirements.........................5 3.2.4. Non-Requirements..........................................6 Vainshtein et al. [Page 1] TDM Circuit Emulation Service over PSN June 2003 4. Scope.............................................................7 4.1. Emulated Services.............................................7 4.1.1. Unstructured services.....................................7 4.1.2. Structured services.......................................7 4.2. Affected Protocol Layers......................................8 5. CESoPSN Encapsulation Layer.......................................9 5.1. CESoPSN Packet Format.........................................9 5.2. PSN and Multiplexing Layer Headers............................9 5.3. Optional "ECMP Prevention" Word...............................9 5.4. CESoPSN Header................................................9 5.4.1. Usage of RTP Header......................................10 5.4.2. Usage and Structure of the Control Word..................11 6. CESoPSN Payload Layer............................................12 6.1. Common Payload Format Considerations.........................12 6.2. Payload Format for Structured Services.......................13 6.2.1. Common Considerations....................................13 6.2.2. Basic Nx64 kbit/s Services...............................13 6.2.3. Trunk-Specific Nx64 kbit/s Services with CAS.............15 6.3. Unstructured Services........................................18 6.3.1. Basic Payload Format.....................................18 6.3.2. Octet-aligned T1 Service.................................18 7. CESoPSN Operation................................................18 7.1. Common Considerations........................................18 7.2. End Service Inactivity Behavior..............................19 7.3. Description of the IWF operation.............................19 7.3.1. PSN-bound Direction......................................19 7.3.2. CE-bound Direction.......................................20 7.4. CESoPSN Defects..............................................21 7.4.1. Misconnection............................................21 7.4.2. Re-Ordering and Loss of Packets..........................21 7.4.3. Malformed Packets........................................22 7.4.4. Jitter Buffer Overrun....................................23 7.4.5. Remote Loss of Packet Synchronization....................23 7.5. Performance Monitoring.......................................24 7.5.1. Errored Data Blocks......................................24 7.5.2. Errored, Severely Errored and Unavailable Seconds........24 8. QoS Issues.......................................................24 9. RTP Payload Format Considerations................................24 9.1. Resilience to moderate loss of individual packets............24 9.2. Ability to interpret every single packet.....................25 9.3. Non-usage of the RTP Header Extensions.......................25 9.4. Compression of RTP headers...................................25 10. Congestion Control (RFC 2914) Conformance.......................26 11. FFS Issues......................................................26 12. Security Considerations.........................................26 13. Applicability Statement.........................................27 14. IANA Considerations.............................................28 15. Intellectual Property Disclaimer................................28 ANNEX A. A COMMON CE APPLICATION STATE SIGNALING MECHANISM..........32 Annex B. Reference PE Architecture for Emulation of NX64 kbit/s SERvices............................................................34 Annex C. Payload and Encapsulation Layer Parameters.................36 Vainshtein et al. Expires December 2003 [Page 2] TDM Circuit Emulation Service over PSN June 2003 1. Introduction This document describes a method for encapsulating unstructured (T1, E1, T3, E3) and structured (Nx64 kbit/s) 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 Nx64 kbit/s 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 -05 Revision Note: This section will be removed from the final document. 1. Nx64 kbit/s services with N exceeding the number of timeslots in a single E1 or T1 trunk are introduced 2. Insertion of an optional 32-bit word with the zeroed first nibble between the bottom label of the label stack and the CESoPSN header (including or not including the fixed RTP header) has been defined. Using this word prevents false recognition of CESoPSN packets as IPv4 or IPv6 packets by core routers implementing proprietary ECMP techniques in an MPLS- enabled IP network 3. The method for carrying trunk-specific Nx64 kbit/s with CAS has been specified 4. Format of the CESoPSN control word has been fully aligned with that defined in [PWE3-SONET]. As part of the alignment, the structure pointer (introduced in the previous revision) has been compressed to a single bit. Vainshtein et al. Expires December 2003 [Page 3] TDM Circuit Emulation Service over PSN June 2003 3. Terminology and Reference Models 3.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms defined in [PWE3-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: Vainshtein et al. Expires December 2003 [Page 4] TDM Circuit Emulation Service over PSN June 2003 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 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. Unstructured services considered in this document represent special cases of the bit stream payload type defined in Section 3.3.3 of [PWE3- ARCH]. Structured services considered in this document represent special cases of the structured bit stream payload type defined in Section 3.3.4 of [PWE3-ARCH]. In each specific case the basic service structures that are carried by a CESoPSN PW across the PSN are explicitly specified (see below). 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 Vainshtein et al. Expires December 2003 [Page 5] TDM Circuit Emulation Service over PSN June 2003 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. The CESoPSN protocol has been designed in order to satisfy the following requirements: 1. Fixed amount of TDM data per packet: All the packets belonging to a given CESoPSN PW MUST carry the same amount of TDM data. This requirement: a) Allows enhanced detection of lost packets b) Simplifies 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 SHOULD support packetization latencies in the range 1 to 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 3.a) 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. 3.2.4. Non-Requirements The following items are considered as non-requirements for CESoPSN: Vainshtein et al. Expires December 2003 [Page 6] TDM Circuit Emulation Service over PSN June 2003 1. Perfect emulation of TDM circuits. 2. "Preferential" treatment of any specific method of carrying attachment circuits between CE and PE 3. Ability to upgrade devices providing emulation of TDM circuits over ATM networks (see [ATM-CES]) to devices providing emulation of TDM circuits over PSN. 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] 4. T3 (44736 kbit/s) as described in [G.702]. This service is also known as DS3 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. All CESoPSN implementations MUST support appropriate unstructured services. E.g., implementation that supports E1 attachment circuits, MUST support emulation of unstructured E1 etc. 4.1.2. Structured services. Structured TDM services are usually carried within appropriate physical trunks, and PEs providing their emulation usually include appropriate Native Service Processing (NSP) blocks commonly referred to as Framers. The NSP may also act as a digital cross-connect, creating structured TDM services from multiple synchronous trunks. As a consequence, the service may contain more timeslots that could be carried over any single trunk. The only type of structured services considered in this specification is Nx64 kbit/s with and without CAS. This service belongs to the generic structured bit-stream payload type as defined in [PWE3-ARCH], and reference PE architecture supporting such services is described in Annex B. Vainshtein et al. Expires December 2003 [Page 7] TDM Circuit Emulation Service over PSN June 2003 The taxonomy of Nx64 kbit/s services defined in [ATM-CES] provides the following set of services: 1. Basic Nx64 kbit/s service: a) The 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 (in case of a service created by the NSP acting as a digital cross-connect from several synchronous E1 or T1 trunks, all the octets belong to the frame defined by the common frame clock pulse of these services), and i-th octet contains the data of the i- th DS0 channel (timeslot) in the bundle. The circuit generates 8000 frames per second b) This service can be optionally extended to support CAS by employing the "signaling" interpretation of CAS and carrying CE application signals in dedicated signaling packets c) Implementations MUST support N <=31 and MAY optionally support larger values of N 2. "Trunk-specific" Nx64 kbit/s service with CAS. The definition of these services employs "synchronous" interpretation of CAS, and the structures that must be preserved by the PW are trunk multiframes. Signaling information is carried appended to TDM data in the "signaling sub-structures" defines in [ATM-CES]. Since the number and bit rates of CAS bit-streams depend on the specific framing method used with an E1 or T1 trunk, the following services are considered: a) E1-Nx64 kbit/s service with CAS, 1 <= n <= 30 b) T1/ESF-Nx64 kbit/s service with CAS, 1 <= n <= 24 c) T1/SF-Nx64 kbit/s service with CAS, 1 <= n <= 24. Note: For T1 trunks using SF format (12 frames per multiframe), CESoPSN preserves the structure comprising two consecutive trunk multiframes. This consideration is aligned with [ATM-CES]. Note: As mentioned above, Nx64 kbit/s services can be formed by NSP blocks form timeslots belonging to several synchronous E1 or T1 trunks. In this case NSP acts as a digital cross-connect and provides a common frame clock for these services, and the resulting "frames" (i.e., arrays of N octets, one from each DS0 in the Nx64 kbit/s bundle and all sampled at the same frame clock signal, act as the basic structures to be preserved for emulation of basic Nx64 kbit/s services. Support of all the structured TDM services is OPTIONAL. 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 (Nx64 kbit/s) TDM services. Vainshtein et al. Expires December 2003 [Page 8] TDM Circuit Emulation Service over PSN June 2003 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 | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |0 0 0 0 Reserved (OPTIONAL - only for an MPLS-enabled IP PSN) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 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. Optional "ECMP Prevention" Word If the PSN providing connectivity between the PE devices is an MPLS- enabled IP network that employs proprietary Equal Cost Multiple Path (ECMP) load-balancing mechanisms, CESoPSN implementations SHOULD allow insertion of a 32-bit word with zeroed first nibble between the bottom label of the label stack and the RTP header. Such an arrangement guarantees that CESoPSN packets would be never be misinterpreted as IPv4 or IPv6 packets by ECMP algorithms in the core LSRs. However, the egress PE MUST NOT interpret the contents of this word in any way. 5.4. CESoPSN Header Vainshtein et al. Expires December 2003 [Page 9] TDM Circuit Emulation Service over PSN June 2003 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. If RTP header is not suppressed, the risk of CESoPSN packets aliasing IPv4 or IPv6 packets carried over the same LSP in an MPLS-enabled IP network is minimal (see below). 5.4.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 Vainshtein et al. Expires December 2003 [Page 10] TDM Circuit Emulation Service over PSN June 2003 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. Note: Differential mode of timestamp generation MAY be used for SRTS- like clock recovery. 5.4.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|N|P|S| Reserved (12 bits) | 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 - if set, carries Remote indication of Loss of Packet Synchronization (see below) o Bits D, N and P encode various conditions of the incoming TDM Attachment Circuit as shown in Table 1 below. Packets with the bit D set MAY carry no payload o Bit S - if cleared, indicates (for the structured services) that the packet payload contains the start of at least one basic structure, and in this case, the start of the first basis structure in the packet MUST be aligned with the beginning of the packet payload. If set - indicates that the packet payload does not contain the start of any basic structure. Bits S MUST be cleared for unstructured services o Reserved bits (6 to 27) - SHOULD all be set to the same value as bit S at ingress and MUST be ignored at egress Vainshtein et al. Expires December 2003 [Page 11] TDM Circuit Emulation Service over PSN June 2003 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. +---+---+---+-----------------------+ | D | N | P | Interpretation | +---+---+---+-----------------------+ | 0 | 0 | 0 | Normal Condition | | 0 | 0 | 1 | Reserved | | 0 | 1 | 0 | Reserved | | 0 | 1 | 1 | RAI in the incoming AC| | | | | | | 1 | 0 | 0 | Idle code indication | | 1 | 0 | 1 | Reserved | | 1 | 1 | 0 | Reserved | | 1 | 1 | 1 | AIS | +---+---+---+-----------------------+ Table 1. Encoding of status of the TDM Attachment Circuit Notes: o The structure of the CESoPSN control word is aligned with that defined in [PWE3-SONET]. The proposed usage of the S bit matches with the definition of the value 0x1fff as an INVALID structure pointer indication since the packet payload size for CESoPSN does not exceed 4K octets (see below) o For Nx64 kbit/s services, D, N and P bits are set or cleared in accordance with the status of the AC detected by the Framer. For unstructured E1, T1 and E3 services, the Line Interface Unit (LIU) can detect the AIS condition ("all ones"). 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. 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. All the CESoPSN packets MUST carry the same amount of valid TDM data in both directions of the PW. In other words, the time that is required to fill a CESoPSN packet with the TDM data must be constant. The PE devices terminating a CESoPSN PW MUST agree on the number of TDM payload octets in the PW packets for both directions of the PW at the time of the PW setup. Vainshtein et al. Expires December 2003 [Page 12] TDM Circuit Emulation Service over PSN June 2003 Notes: 1. CESoPSN packets MAY omit invalid TDM data in order to save the PSN BW. If the CESoPSN packet payload is omitted, the D bit in the CESoPSN control word MUST be set 2. CESoPSN PWs MAY carry CE signaling information either in separate packets or appended to packets carrying valid TDM data. If signaling information and valid TDM data are carried in the same CESoPSN packet, the amount of the former (agreed between the pair of PE devices) does not affect the amount of the latter. 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. The packet payload size for CESoPSN PWs for structures services MUST NOT exceed 4K octets. CESoPSN MUST use alignment of the basic structures with the packet payload boundaries in order to carry the structures across the PSN. This means that: 1. The amount of TDM data in a CESoPSN packet SHOULD be either an integer multiple or an integer divisor of the structure size 2. If the amount of TDM data in a CESoPSN packet is an integer multiple of the structure size, the first structure in the packet SHOULD start immediately at the beginning of the packet payload 3. If the amount of TDM data in a CESoPSN packet is an integer divisor of the structure size, the structure should start immediately at the beginning of the packet payload in all the packets that contain the first octet of some structure. The packets that do not contain the first octet of any basic structure, should be marked by setting S bit to 0 in the CESoPSN control word. This mode of operation complies with the recommendation in [PWE3-ARCH] to use similar encapsulations for structured bit stream and cell generic payload types. 6.2.2. Basic Nx64 kbit/s Services As mentioned above, the structure preserved across the PSN 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(s), and the service generates 8000 such structures per second. Vainshtein et al. Expires December 2003 [Page 13] TDM Circuit Emulation Service over PSN June 2003 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 Nx64 kbit/s services MUST support the following set of configurable packetization latency values: o For n >= 4: 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 <= 3: 5 milliseconds (with the corresponding packet payload size of 40*n octets). Usage of any other packetization latency (packet payload size) that is compatible with the restrictions given in Section 6.2.1 above is OPTIONAL. Implementations that have chosen to extend this service to support also CAS 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 of dynamically allocated types) for the signaling 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]). Vainshtein et al. Expires December 2003 [Page 14] TDM Circuit Emulation Service over PSN June 2003 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. Note: The same protocol can be used in conjunction with other signaling methods using appropriate format of signaling packets. 6.2.3. Trunk-Specific Nx64 kbit/s Services with CAS As mentioned above, the structure preserved by CESoPSN for this group of services is the trunk multiframe, and signaling information is carried appended to the TDM data using the signaling substructures defined it [ATM-CES]. These substructures comprise N consecutive nibbles, so that the i-th nibble carries CAS bits for the i-th DS0 channel, and are padded with a dummy nibble for odd values of N. CESoPSN implementations supporting trunk-specific Nx64 kbit/s services with CAS MUST NOT carry more TDM data per packet than is contained in a single trunk multiframe. The signaling substructures MUST be appended to each CESoPSN packet with the cleared S bit in the CESoPSN control word. All CESoPSN implementations supporting trunk-specific Nx64 kbit/s with CAS MUST support the default mode where a single CESoPSN packet carries exactly one trunk multiframe aligned with the packet payload. In this case: 1. Packetization latency is: a) 2 milliseconds for E1 Nx64 kbit/s b) 3 milliseconds for T1 Nx64 kbit/s 2. The packet payload size is: Vainshtein et al. Expires December 2003 [Page 15] TDM Circuit Emulation Service over PSN June 2003 a) 16*n + floor((n+1)/2) for E1-Nx64 kbit/s b) 24*n + floor((n+1)/2) for T1/ESF-Nx64 kbit/s and T1/SF-Nx64 kbit/s 3. The packet payload format coincides with the "superframe structure with signaling" defined in [ATM-CES]. In order to provide lower packetization latency, CESoPSN implementations for trunk-specific Nx64 kbit/s with CAS SHOULD support the TDM data payload sizes that satisfy the following conditions: 1. The amount of the TDM data per packet is an integer multiple of N. 2. The amount of the TDM data per packet is a divisor of the number of octets in the appropriate trunk multiframe, i.e.: a) 16*N for E1-Nx64 kbit/s with CAS b) 24*N for T1/ESF-Nx64 kbit/s with CAS and T1/SF-Nx64 kbit/s with CAS. Format of CESoPSN packets that do and do not contain signaling substructures is shown in Fig. 4 (a) and (b) respectively. Vainshtein et al. Expires December 2003 [Page 16] TDM Circuit Emulation Service over PSN June 2003 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 --- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Timeslot 1 | | Timeslot 1 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Timeslot 2 | | Timeslot 2 | Frame #1 | ... | | ... | | Timeslot n | | Timeslot n | --- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Timeslot 1 | | Timeslot 1 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Timeslot 2 | | Timeslot 2 | Frame #2 | ... | | ... | | Timeslot n | | Timeslot n | --- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ... | ... | | ... | --- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Timeslot 1 | | Timeslot 1 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Timeslot 2 | | Timeslot 2 | Frame #m | ... | | ... | | Timeslot n | | Timeslot n | --- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Nibbles 1,2 |A B C D|A B C D| +-+-+-+-+-+-+-+-+ Nibbles 3,4 |A B C D|A B C D| +-+-+-+-+-+-+-+-+ Nibble n |A B C D| (pad) | (odd) & pad +-+-+-+-+-+-+-+-+ (a) The packet with (b) The packet without the signaling structure the signaling structure (bit S cleared) (bit S set) Figure 4. The CESoPSN Packet Payload Format for Trunk-Specific Nx64 kbit/s with CAS Notes: 1. In case of T1-Nx64 kbit/s with CAS, the signaling bits are carried in the TDM data as well as in the signaling substructure. However, the receiver MUST use the CAS bits as carried in the signaling substructures 2. It is possible to emulate trunk-specific Nx64 kbit/s services with CAS by just carrying the trunk multiframe structures over the PSN (and, in case of an E1 trunk, Nx64 kbit/s, including timeslot 16 in the end service). Such an approach would be fully consistent with the Principle of Minimum Intervention. Its applicability is left for further study 3. In case of trunk-specific Nx64 kbit/s with CAS originating in a T1-SF trunk, each nibble of the signaling substructure contains A and B bits from two consecutive trunk multiframes as described in [ATM-CES]. Vainshtein et al. Expires December 2003 [Page 17] TDM Circuit Emulation Service over PSN June 2003 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 CESoPSN implementations MUST support the following packetization latency (packet payload size) values: 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 recommended 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 Nx64 kbit/s services 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. Vainshtein et al. Expires December 2003 [Page 18] TDM Circuit Emulation Service over PSN June 2003 Proposed values for the PW types supported by CESoPSN are 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 o Presence or absence of the 32-bit word with the zeroed first nibble immediately after the bottom label in the label stack (only for MPLS-enabled IP networks). 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. For Nx64 kbit/s with and without CAS, while the PW is inactive the PE MUST send some (locally configured) Idle Code to its local CE. For Nx64 kbit/s 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, and appropriate flags (R, D, N, P and S) are set or cleared as found fit o CESoPSN, multiplexing and PSN headers are prepended to the packetized service data o Resulting packets are transmitted via the PSN. Note: Indications of status of the TDM attachment circuit 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 o Ability to emulate E1/T1 trunk behavior while carrying only the actually used timeslots ("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. Vainshtein et al. Expires December 2003 [Page 19] TDM Circuit Emulation Service over PSN June 2003 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 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 code. Immediately after start, the CESoPSN IWF instance: o Enters the Loss of Packet Synchronization state. It will enter the Normal state after a number of received consequent CESoPSN packets has exceeded a locally configurable threshold (see also below) 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 Nx64 kbit/s 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 Packet Synchronization condition Vainshtein et al. Expires December 2003 [Page 20] TDM Circuit Emulation Service over PSN June 2003 b) While it plays out CESoPSN packets with the AIS indication set 2. "Force RAI" command - while it plays out CESoPSN packets with the RAI indication set. 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 only one IWF instance associated with the specific outgoing AC is configured in this way 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 NX64 kbit/s 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. Vainshtein et al. Expires December 2003 [Page 21] TDM Circuit Emulation Service over PSN June 2003 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 "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: 1. A counter of lost packets must be incremented 2. If the number of consequent lost packets exceeds a locally configurable threshold, the CESoPSN IWF instance enters the Loss of Packet Synchronization state. While in this state: a) All the CESoPSN data packets sent by the PSN-bound direction of this IWF instance MUST be marked with the R bit set in the CESoPSN control word b) If the Loss of Packet Synchronization state persists above a configurable period of time (by default, 2.5 seconds), a Loss of Packets Synchronization alarm SHOULD be sent to the management system. 3. Once the CESoPSN IWF is in the Loss of Packet Synchronization state, it will (re-)enter its Normal state after it has successfully received a number of CESoPSN packets that exceeds another locally configurable threshold. Once the CESoPSN IWF instance is in the Normal state: a) All the CESoPSN data packets sent by the PSN-bound direction of this IWF instance MUST be marked with the R bit cleared in the CESoPSN control word b) If the Normal state persists above a configurable period of time (by default, 10 seconds), a previously reported Loss of Packets Synchronization alarm SHOULD be cleared. 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). Structured services allow application-specific generation of the replacement packets (e.g., per timeslot statistical interpolation for Voice services, see [PACKETLOSS]). Trunk-specific Nx64 kbit/s with CAS services require separate replacement techniques for TDM data and signaling. It is RECOMMENDED to replace the latter with the last received value(s) for all the timeslots. 7.4.3. Malformed Packets CESoPSN PW detects a malformed packet using the following rules: Vainshtein et al. Expires December 2003 [Page 22] TDM Circuit Emulation Service over PSN June 2003 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. 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). Note: Jitter buffer underrun is in most cases undistinguishable from the packet loss. 7.4.5. Remote Loss of Packet Synchronization CESoPSN implementations SHOULD detect Remote Loss of Packet Synchronization condition based upon the presence of the Remote Loss of Packet Synchronization indication in the received packets. If the Remote Loss of Packet Synchronization condition persists above a configurable period of time (by default, 2.5 seconds), a Remote Loss of Packet Synchronization alarm SHOULD be sent to the management system. This alarm SHOULD be cleared if no packets with the Remote Loss of Packet Synchronization indication have been received for a configurable period of time (by default, 10 seconds). Vainshtein et al. Expires December 2003 [Page 23] TDM Circuit Emulation Service over PSN June 2003 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: 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). For unstructured services, resilience of the CE at the egress of a CESoPSN PW to loss of packets may be decreased by using intelligent generation of "replacement packets". These techniques are most appropriate for CESoPSN PWs carrying unstructured E1, and the default Vainshtein et al. Expires December 2003 [Page 24] TDM Circuit Emulation Service over PSN June 2003 packet payload size for these PWs has been selected as using replacement of lost packet(s) with the last received one. 9.2. Ability to interpret every single packet This requirement is always met for CESoPSN packets. 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. 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. 5 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 | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |0 0 0 0 Reserved (OPTIONAL - only for an MPLS-enabled IP PSN) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CESoPSN Control Word with mandatory sequence number | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. 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. If the PSN is an Vainshtein et al. Expires December 2003 [Page 25] TDM Circuit Emulation Service over PSN June 2003 MPLS-enabled IP network employing proprietary ECMP techniques, the 32- bit word with the zeroed first nibble SHOULD be inserted. Note: The CESoPSN PWs carrying Nx64 kbit/s accompanied with CAS rely on the RTP-based mixing techniques for synchronization between TDM data and CE application signals. As a consequence, it is not permitted 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. 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 Applicability of trunk multiframe-aligned methods for carrying trunk-specific Nx64 kbit/s 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 Nx64 kbit/s 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. Vainshtein et al. Expires December 2003 [Page 26] TDM Circuit Emulation Service over PSN June 2003 13. Applicability Statement CESoPSN is an encapsulation layer intended for carrying TDM circuits (unstructured E1/T1/E3/T3, Nx64 kbit/s with or without CAS) 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 fully complies with the principle of minimal intervention minimizing overhead and computational power required for encapsulation. CESoPSN can be used in conjunction with various clock recovery techniques and does not presume availability of a global synchronous clock at the ends of a PW. However, if the global synchronous clock is available at both ends of a CESoPSN PW, using RTP and differential mode of timestamp generation improves the quality of the recovered clock. CESoPSN allows carrying CE application state signaling that requires synchronization with data in-band in separate signaling packets. The RTP Payload Type (PT) is used to distinguish between data and signaling packets, while the Timestamp field is used for synchronization. This makes CESoPSN extendable to support different types of CE signaling without affecting the data path in the PE devices. CESoPSN also allows emulation of Nx64 kbit/s services with CAS carrying the signaling information appended to (some of) the packets carrying TDM data. CESoPSN complies with the recommendations for RTP payload specified in [RFC2736]. The 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 NX64 kbit/s 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 Vainshtein et al. Expires December 2003 [Page 27] TDM Circuit Emulation Service over PSN June 2003 (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 allows using various techniques for generation of "replacement packets". These techniques increase resilience of CE to effects of lost packets and are of special importance for emulation of unstructured E1 circuits. CESoPSN carries indications of outages of incoming attachment circuit across the PSN thus providing for effective fault isolation. 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 does not provide any mechanisms for protection against PSN outages. As a consequence, resilience of the emulated service to such outages is defined by the PSN behavior. On the other hand: o The jitter buffer and packets' reordering mechanisms associated with CESoPSN increase resilience of the emulated service to fast PSN rerouting events o Remote indication of lost packets is carried backward across the PSN from the receiver (that has detected loss of packets) to transmitter. Such an indication MAY be used as a trigger for activation of proprietary service-specific protection mechanisms. CESoPSN does not provide for upgrade of existing devices using TDM circuit emulation over ATM circuits to TDM circuit emulation over PSN. 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. Vainshtein et al. Expires December 2003 [Page 28] TDM Circuit Emulation Service over PSN June 2003 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 [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 Vainshtein et al. Expires December 2003 [Page 29] TDM Circuit Emulation Service over PSN June 2003 [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 [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, December 2002, draft-ietf-pwe3- requirements-04.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, February 2003, draft-ietf-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 [PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3), Work in progress, February 2003, draft- ietf-pwe3-iana-allocation-00.txt Vainshtein et al. Expires December 2003 [Page 30] TDM Circuit Emulation Service over PSN June 2003 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 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. Vainshtein et al. Expires December 2003 [Page 31] TDM Circuit Emulation Service over PSN June 2003 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: 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 Vainshtein et al. Expires December 2003 [Page 32] TDM Circuit Emulation Service over PSN June 2003 allocation is done during the PW setup and MUST be the same for both PW directions b) The PE at the PW ingress MUST set the PT value in the RTP header of signaling packets to the allocated value c) The PE at the PW egress MUST use this value to distinguish between TDM data and signaling packets. 7. The SSRC (synchronization source) value in the RTP header of signaling packets MUST be different from that used by the data packets 8. Sequence number is generated and processed in accordance with the rules established in [RFC1889]. There should be no connection between the sequence numbers used by the data and signaling packets 9. Timestamps are used for re-synchronization between TDM data and CE application state signals at the PW egress: a) Their values are generated in accordance with the rules established in [RFC1889] b) Frequency of the clock used for generating timestamps MUST be a multiple of 8 KHz and SHOULD be the same as that used for the data packets 10. Each PE terminating the PW SHOULD send RTCP sender reports (see RFC1889], Section 6.3.1) for the clock sources used for generation of timestamps of both TDM data and signaling packets to its peer: a) These packets MAY be limited only to the header and 'Sender Info' sections b) The PE receiving these packets SHOULD use the information contained in the 'Sender Info' in order to map (approximately) timestamps received in the signaling packets to these received in the data packets. Signaling packets are generated by the ingress PE in accordance with the following logic (adapted from [RFC2833]): 1. The CESoPSN signaling packet with the same information is sent 3 times at an interval of 5 ms under one of the following conditions: a) The CESoPSN PW has been set up. These packets MUST be marked as "urgent" 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. Vainshtein et al. Expires December 2003 [Page 33] TDM Circuit Emulation Service over PSN June 2003 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 NX64 KBIT/S 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 Nx64 kbit/s services (the only type of structured services considered in this document), the AC is either an E1 or a T1 trunk, and bundles of Nx64 kbit/s 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 Nx64 kbit/s 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 ACs into separate DS0 channels 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 Nx64 kbit/s 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) If necessary sends the AC state indications to the PSN-bound directions of all the CESoPSN instances associated with the given AC Vainshtein et al. Expires December 2003 [Page 34] TDM Circuit Emulation Service over PSN June 2003 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 NX64 kbit/s 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 o No more than one CESoPSN IWF instance should forward AC state- affecting commands to the framer. Vainshtein et al. Expires December 2003 [Page 35] TDM Circuit Emulation Service over PSN June 2003 +------------------------------------------+ | PE Device | +------------------------------------------+ | | Forwarder | | | |---------------------| | | | | | | +<-- AC State---->- | | | | | | | | | | | | E1 or T1 | | | | | AC | | | | | <=======>| |-----------------+---|--------------| | | | | At most one | | | |-->+ PW IWF | | | | instance im- | ... | +<---NX64 kbit/s TDM Data-->+ posing state | PW Instance | F | | on the X<===========> | +<---CE App State --->+ outgoing AC | E1 or T1 | R | | | AC | +<--AC Command -------+ | <=======>o A |---------------------|--------------| | | ... | ... | ... | M |-----------------+---|--------------| | | | | Zero, one or | | E | |-->+ more PW IWF | | | | instances | R +<---NX64 kbit/s TDM Data-->+ that do not | PW Instance | | | impose state X<===========> | +<---CE App State --->+ on the outgo-| | | | ing AC | +------------------------------------------+ Figure B.1. Reference PE Architecture for Nx64 kbit/s 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 [PWE3-IANA]. 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 Nx64 kbit/s - 65 o E1 - 66 o T1 - 67 o Octet-aligned T1 - 69 o E3 - 70 o T3 - 71 Vainshtein et al. Expires December 2003 [Page 36] TDM Circuit Emulation Service over PSN June 2003 o E1 Nx64 kbit/s with CAS - 72 o T1 (ESF) Nx64 kbit/s with CAS - 73 o T1 (SF) Nx64 kbit/s with CAS - 74. C.1.2. The Service Bit Rate This parameter has been also defined in [PWE3-IANA], and is irrelevant for PWs carrying unstructured services. For Nx64 kbit/s services (with and without CAS) this parameter encodes (as an integer) the number of DS0 channels that are carried by the PW. C2. Encapsulation Layer Parameters C2.1. Payload Bytes This parameter has been defined in [PWE3-IANA]. 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 Nx64 kbit/s 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 Nx64 kbit/s 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 o Egress PW MAY use this value to distinguish signaling PW packets. Note: The same PT value may be allocated for multiple PWs. Vainshtein et al. Expires December 2003 [Page 37] TDM Circuit Emulation Service over PSN June 2003 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 Nx64 kbit/s 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 December 2003 [Page 38]