Network Working Group A. Vainshtein - Editor (Axerra Networks) Internet Draft I. Sasson (Axerra Networks) A. Sadovski (Axerra Networks) Expiration Date: E. Metz (KPNQwest) March 2003 T. Frost (Zarlink Semiconductor) P. Pate (Overture Networks) October 2002 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) draft-vainshtein-cesopsn-04.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 structured TDM signals (n*DS0) digital signals as pseudo-wires over packet-switching networks (PSN). In this regard it complements similar work for unstructured TDM and structured SONET circuits. Proposed PW encapsulation uses RTP for clock recovery and leverages it for application state signaling between Customer Edge (CE) devices. TABLE OF CONTENTS 1. Introduction......................................................2 2. Summary of Changes from the -03 Revision..........................3 3. Terminology and Reference Models..................................3 3.1. Terminology...................................................3 3.2. Reference Models..............................................4 3.2.1. Generic Models............................................4 3.2.2. Synchronization Considerations and Deployment Scenarios...4 4. Scope.............................................................4 4.1. Emulated Services.............................................4 4.2. Protocol Layers...............................................4 Vainshtein et al. [Page 1] TDM Circuit Emulation Service over PSN October 2002 4.3. Framers and Structured TDM Services...........................5 5. CESoPSN Encapsulation.............................................7 5.1. CESoPSN Format................................................7 5.2. CESoPSN Header................................................8 5.2.1. Usage of RTP Header.......................................8 5.2.2. Usage and Structure of the Control Word..................10 5.3. Payload Data Format..........................................11 6. CESoPSN Operation................................................12 6.1. Payload Parameters...........................................12 6.1.1. PW Type..................................................12 6.1.2. Payload Bytes............................................13 6.1.3. Number of Timeslots......................................13 6.2. CESoPSN-specific Parameters..................................13 6.2.1. RTP Payload Types........................................13 6.2.2. Timestamp Resolution.....................................14 6.2.3. Synchronization Source ID................................14 6.2.4. Timestamp Generation Mode................................14 6.3. End Service Inactivity Behavior..............................14 6.4. Description of the IWF operation.............................14 6.4.1. PSN-bound Direction......................................14 6.4.2. CE-bound Direction.......................................15 6.5. CESoPSN Defects..............................................16 6.5.1. Misconnection............................................16 6.5.2. Re-Ordering and Loss of Packets..........................16 6.5.3. Malformed Packets........................................17 6.5.4. Loss of Synchronization..................................17 6.6. Performance Monitoring.......................................17 6.7. QoS Issues...................................................18 7. RTP Payload Format Considerations................................18 7.1. Resilience to moderate loss of individual packets............18 7.2. Ability to interpret every single packet.....................18 7.3. Non-usage of the RTP Header Extensions.......................18 7.4. Compression of RTP headers...................................18 8. Congestion Control (RFC 2914) Conformance........................18 9. FFS Issues.......................................................19 10. Security Considerations.........................................19 11. Applicability Statement.........................................19 12. IANA Considerations.............................................21 13. Intellectual Property Disclaimer................................21 ANNEX A. A COMMON CE APPLICATION STATE SIGNALING MECHANISM..........24 1. Introduction This document describes a method for encapsulating structured TDM signals (n*DS0) as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for SONET/SDH (see [PWE3- SONET]) and unstructured TDM (see [PWE3-UCESoPSN] signals. To support structured TDM traffic, which includes voice and data services, the network must emulate the circuit characteristics of a TDM network. A circuit emulation header and RTP-based mechanisms for Vainshtein et al. Expires March 2003 [Page 2] TDM Circuit Emulation Service over PSN October 2002 carrying the clock over PSN are used to encapsulate TDM signals to provide the Circuit Emulation Service over PSN (CESoPSN). RTP-based mixing capabilities are used to carry CE application state signals across the PSN if necessary while retaining the necessary degree of synchronization between these signals and the TDM data. Ability to carry structured TDM traffic allows to save PSN bandwidth and to enhance 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 -03 Revision Note: This section will be removed from the final document. 1. The scope has been limited to structured TDM (n*DS0) signals. Encapsulation of unstructured TDM services has been remove to a separate document ([UCESoPSN]) 2. A reference PE architecture for emulation of n*DS0 has been described in detail. 3. Ability to define local methods for generating replacement packets have been added in order to improve quality of Voice services. 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, usually without additional explanations. This document uses 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 and T1 circuits 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. For E1 and T1 circuits the AIS condition can be detected not only by the framers but also by Line Interface Units (LIU) o Loss of Frame (LOF) is a common term denoting the state of the framer when the FAS could not be found for some predefined duration while the AIS condition is not experienced Vainshtein et al. Expires March 2003 [Page 3] TDM Circuit Emulation Service over PSN October 2002 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 some failure condition of the incoming service (including AIS and LOF). 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]. The structures to be carried are relatively short and hence methods used for their encapsulation are similar to ones used for the cell payload type. 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. 4. Scope 4.1. Emulated Services This specification describes service-specific encapsulation layer for edge-to-edge emulation of the structured (n*DS0, 1 <= n <= 31) TDM services as described in [G.704]. Note: The method described in this specification can be easily extended to carrying n*DS0 services with n exceeding 31 provided that these services are synchronous. Limiting the specification to carrying bundles of DS0 services that originated in a single E1 or T1 attachment circuit (AC) automatically guarantees synchronization. Edge-to-edge emulation of n*DS0 circuits carrying Voice services may require conveyance of application-specific CE signaling in addition to TDM data. The common example is Channel-Associated signaling (CAS) that reflect changes in the state of telephony applications (like off-hook and on-hook). These signals SHOULD be synchronized with the data passing between these applications to allow their normal operation. This specification describes a mechanism for carrying CAS signaling between CE devices that does not affect encapsulation of TDM data. This method is essentially a generalization of technique developed in [RFC2833] for a single DS0 service. In its turn, [RFC2833] uses the techniques first developed in [I.366.2] for carrying CAS along with ATM AAL2 circuits. Details can be found in Annex A below. 4.2. Protocol Layers Vainshtein et al. Expires March 2003 [Page 4] TDM Circuit Emulation Service over PSN October 2002 This specification defines the encapsulation layer for edge-to-edge emulation of structured TDM services (n*DS0). In accordance with the principle of minimum intervention ([PWE3-ARCH], Section 3.3.5) the TDM payload is encapsulated without any changes. The structures considered in this specification are relatively short (up to 31 byte); as a consequence, they are treated in a way that is similar to treatment of cell payload type ([PWE3-ARCH], Sections 3.3.4 and 3.3.2). 4.3. Framers and Structured TDM Services Generally speaking, 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 (usually referred to as Framer) that extracts required structures from the AC bit stream. In case of n*DS0 services, the AC is either an E1 or a T1 bit-stream using one of the framing methods described in [G.704]. E1 and T1 framers usually support some additional functionality including: 1. Detection of special states of the incoming AC (e.g., AIS, LOF or RAI) 2. Forcing special states (usually the same that can be detected in the incoming AC) on the outgoing AC upon an explicit request 3. Extraction and insertion of CE application signals that may accompany the specific TDM payload. The resulting PE architecture for n*DS0 services is shown in Fig. 1 below. In this diagram: 1. In the PSN-bound direction: a) The framer: i) Detects the 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) In accordance with its configuration, creates one or more n*DS0 bundles. Each bundle is associated with a single instance of a CESopSN IWF ii) Sends the data received in each such bundle to the PSN-bound direction of the respective CESoPSN IWF instance iii) If necessary, sends the current CE application state data of separate DS0 services in the bundle to the PSN- bound direction of the associated PW IWF instance Vainshtein et al. Expires March 2003 [Page 5] TDM Circuit Emulation Service over PSN October 2002 iv) Sends the AC state indications to PSN-bound directions of all the CESoPSN instances associated with the given AC 2. In the CE-bound direction: a) Each CE-bound instance of the CESoPSN IWF sends the de- packetized TDM data to the forwarder. This data MAY be accompanied by: i) Commands reflecting the desired state of the AC ii) CE application state associated with the relevant DS0 services b) 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 outgoing AC accordingly. This process includes: i) Generation of the appropriate Frame Alignment Signal (FAS) ii) Insertion of the required CE state signals per DS0 service in the generated framing structure in accordance with the framing-specific rules (see [G.704]) iii) Application of the required AC state (AIS, RAI) as requested by the appropriately designated CE-bound instance of the CESoPSN IWF. Vainshtein et al. Expires March 2003 [Page 6] TDM Circuit Emulation Service over PSN October 2002 +-------------------------------------------+ | PE Device | +-------------------------------------------+ | | Forwarder | | | |---------------------| | | | | | | + -- AC State---->- | | | | | | | | |-----------------+---|---------------| | | | | At most one | | | |-->+ designated | | | ... |PW IWF instance| | | | imposing state| PW | +<---n*DS0 TDM Data-->+ on the out- |Instance | F | | going AC X<=======> | +<---CE App State --->+ | A single | R | | | E1 or T1 | +<--AC Command -------+ | <=======>o A |---------------------|---------------| AC | | ... | ... | ... | 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 1. PE Architecture for n*DS0 Services 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. 5. CESoPSN Encapsulation 5.1. CESoPSN Format Format of CESoPSN packets carrying n*DS0 data is shown in Fig. 2a, and format of packets carrying CE application state signals - in Fig. 2b below. Vainshtein et al. Expires March 2003 [Page 7] TDM Circuit Emulation Service over PSN October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CESoPSN Control Word | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2a. CESoPSN Data Packet Format 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 | +-- --+ | (per DS0 service) | +-- --+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2b. CESoPSN Signaling Packet Format 5.2. CESoPSN Header The CESoPSN header includes a fixed RTP header (12 octets) and an optional CESoPSN Control Word (4 octets). 5.2.1. Usage of RTP Header CESoPSN uses the fields of the fixed RTP header (see [RFC1889], Section 5.1) in the following way: 1. V (version) is always set to 2 Vainshtein et al. Expires March 2003 [Page 8] TDM Circuit Emulation Service over PSN October 2002 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): a) Set to 0 in the packets carrying TDM data and "regular" signaling packets b) Set to 1 in the "urgent" packets carrying CE application signals. See Annex A for details 6. PT (payload type) MAY be used to distinguish between packets carrying the packetized TDM data and packets carrying CE application state signaling as following: a) One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for every CESoPSN PW b) If CE application state signaling is conveyed over a CESoPSN PW, one more PT value MUST be allocated from the same range c) Allocation is done during the PW setup and MUST be the same for both PW directions d) The PE at the PW ingress MUST set the PT value (or values) in the RTP header to the allocated value (or values) e) The PE at the PW egress MAY use this value (these values) to detect malformed packets f) The same PT value (or pair of PT values) MAY be used across different CESoPSN PWs without any restrictions 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]. If the PW carries both packetized TDM data and CE application state signals, sequence numbers for two types of packets are totally independent 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 a multiple of 8 KHz 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. If the PW carries both packetized TDM data and CE application state signals, it MUST use different SSRC values for the two types of packets. The RTP header in CESoPSN packets carrying TDM data 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 the 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 Vainshtein et al. Expires March 2003 [Page 9] TDM Circuit Emulation Service over PSN October 2002 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. Absolute mode allows operation in the Asynchronous Carrier's Carrier deployment scenario. Differential mode may improve quality of the recovered clock in the One Synchronous Network and Synchronous Carrier's Carrier deployment scenarios. See [PWE3-REQ-TDM] for details. CESoPSN SHOULD use the standard RTCP-based mixing techniques for synchronizing packets carrying TDM data and CE application signals at egress if necessary. See Annex A for details. 5.2.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) 3. Signaling problems detected at the PW egress to its ingress The structure of the CESoPSN Control Word is shown in Fig. 3 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|D|A|X| Reserved | Optional sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. 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 - unused, MUST be set to 0 at ingress and MUST be ignored at egress o Bit A - carries Local AIS indication. If set, represents AIS of the 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 RAI condition of the carrying E1 or T1 AC o Reserved - MUST be set to 0 at ingress and SHOULD be ignored at egress Vainshtein et al. Expires March 2003 [Page 10] TDM Circuit Emulation Service over PSN October 2002 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. Notes: 1. The structure of the CESoPSN control word is aligned with that defined in [PWE3-SONET]. In particular, the reserved bits in the CESoPSN control word correspond to the structure pointer bits in the CEP one. For n*DS0 circuits these bits MAY be treated as the (valid) pointer to the native circuit frame carried in the CESoPSN packet (see Section 5.3.2 below). This arrangement potentially allows decoupling between the number of timeslots (n) of the emulated n*DS0 service and the packet payload size 2. Information about lost packets (carried via the bit R) can be used at ingress as an indication to resynchronize CE application state (see Annex A) 3. Information carried in bit X can be used in the Fractional E1/T1 applications (see below). 5.3. Payload Data Format The payload data format for n*DS0 service emulation is shown in Fig. 2 below (N - number of timeslots in the service, M = number of the native circuit frames in a CESoPSN packet, the 1st timeslot of the 1st native frame is the 1st octet of the payload). The matrix shown in this diagram is mapped into array of payload octets row by row. Timeslots ->| 1 | 2 | ... | N | ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ N C F 1| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a i r 2| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t r a ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i c m ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v u e ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e i s ...| | | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t M| | | ... | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 2. Payload structure for a n*DS0 Service The number of native service frames in a CESoPSN packet is: 1. Defined during the PW setup and remains constant for the duration of a PW. Such an arrangement: a) Simplifies implementation because it implies that the CESoPSN packets are transmitted at a constant rate b) Allows insertion of a predefined amount of data instead of each lost packet at the PW egress Vainshtein et al. Expires March 2003 [Page 11] TDM Circuit Emulation Service over PSN October 2002 2. The same for both directions of the PW. Such an arrangement simplifies signaling and processing of backwards problem indications. CESoPSN uses the so-called "Telecom" bit ordering, i.e., each payload octet is: o Filled by the consecutive bits coming from the PWES from its most significant bit to the least significant one o Played out into the PWES in the same order 6. CESoPSN Operation Note: This section includes some implementation considerations. These considerations represent non-normative information and will be moved to an appropriate Appendix in the next update. Edge-to-edge service emulation of a TDM service using CESoPSN assumes the following elements: o Two PW attachment circuits, with the same number of timeslots (not necessary in the same absolute positions) selected in each 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 Number of timeslots (DS0 services). In order to be connected, these numbers MUST be the same at the two ends of a PW o Encapsulation layer-specific parameters that define specific instantiation of the protocol This document defines only how the values of these parameters should be encoded. The actual signaling protocols for exchanging these parameters between the PE peers ("PE/PW signaling" in terms of [PWE3-FW]) are out of scope of this document. Description of the CESoPSN-based edge-to-edge service emulation includes the following elements: o Definition of the end service inactive state behavior towards the CE o Description of the IWF operation in CE-bound and PSN-bound direction. Details are presented below. 6.1. Payload Parameters 6.1.1. PW Type PW types (a.k.a. VC types) have been defined in [PWE3-CONTROL]. 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 type is defined in this document for CESoPSN-based PWs: Vainshtein et al. Expires March 2003 [Page 12] TDM Circuit Emulation Service over PSN October 2002 n*DS0 - 65 6.1.2. Payload Bytes This parameter has been defined in [PWE3-CONTROL]. 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 number of payload bytes MUST be a multiple of the number of timeslots (see previous section) 3. The size of the resulting PW packet (including all the headers) MUST NOT exceed the path MTU between the participating PEs as provided by the Carrier layer. Note: The Payload Bytes parameter refers only to CESoPSN packets carrying packetized TDM data. 6.1.3. Number of Timeslots This number is encoded as a 16-bit integer. 6.2. CESoPSN-specific Parameters 6.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: o The same value MUST be allocated for both directions of the PW o Ingress PW MUST set the PT in the RTP header of all the data packets to the allocated value o Egress PW MAY use this value to detect non-data PW packets. These packets can be either relegated to signaling or considered as malformed If a CESoPSN PW must carry CE application state signaling as well as TDM data, an additional PT value MUST be allocated from the range of dynamically allocated payload types for each CESoPSN PW for use in the data packets: o It MUST be different from the PT value allocated for data packets o The same value MUST be allocated 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. Notes: 1. For PWs that combine TDM data with CE application state signaling this parameter defines the number of payload bytes in the data packets only Vainshtein et al. Expires March 2003 [Page 13] TDM Circuit Emulation Service over PSN October 2002 2. Packetization latency (PL) of a CESoPSN PW can be inferred from its Payload Bytes (PB) and number of timeslots (NTS) parameters using the following formula: PL = 0.125*(PB/NTS) (milliseconds) 6.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. 6.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). If data and signaling packets are multiplexed in the same PW, the signaling packets MUST use a separate SSRC value. This arrangement complies with the RTP specification [RFC 1889] and allows effective compression of the PW headers by the standard compressors. 6.2.4. Timestamp Generation Mode Encoding of the timestamp generation modes described in Section 5.2.1 MUST be supported as following: 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. 6.3. End Service Inactivity Behavior While the PW is inactive, the PE MUST send some (locally configured) Idle Code to its local CE. In addition, it MAY also send Force AIS command to the Framer. 6.4. Description of the IWF operation Once the PW is set up, the CESoPSN IWF operates like following: 6.4.1. PSN-bound Direction o End service data is packetized in accordance with the number of payload bytes specified and aligned with the native circuit frames as described in Section 5.2.1. o Sequence numbers and timestamps representing the selected synchronization clock are inserted in the CESoPSN headers o CESoPSN, multiplexing and PSN headers are prepended to the packetized service data o Resulting packets are transmitted via the PSN Vainshtein et al. Expires March 2003 [Page 14] TDM Circuit Emulation Service over PSN October 2002 o If the PE detects any outage of the incoming unstructured end service that natively would result in sending the "downstream AIS", the CESoPSN IWF using the control word MUST set the local AIS indication flag (bit A) in the control word. The packet payload MAY be omitted in order to save the PSN bandwidth. o 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 Local AIS and Idle Code indications in the CESoPSN control word provide for the following functionality: o Ability to distinguish between the PSN problems and ones beyond the PSN as causes of outages of the emulated service o Ability to save the PSN bandwidth (but not its switching capacity) by not sending invalid data across the PSN. 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. 6.4.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. Since any CESoPSN data packet carries a fixed number of native data frames of the emulated service, the jitter buffer can be considered as a matrix with "rows" corresponding to native service frames, too. Initially the Jitter buffer is filled with the appropriate inactivity code ("all ones"). 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 to its end service in accordance with its (locally defined) 8 KHz transmission clock, so that a single "row" of the jitter buffer matrix is replayed per "tick" of the clock. If transmission clock must be recovered from the PW, the timestamps of data packets SHOULD be used for correcting Vainshtein et al. Expires March 2003 [Page 15] TDM Circuit Emulation Service over PSN October 2002 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 indication in the control word MUST be replaced with the appropriate amount of "all ones" code in the jitter buffer. The CE-bound direction of the IWF: o Performs detection, correlation and handling of CESoPSN faults as described in Section 6.5 below o Collects the PW Performance Monitoring data as defined in Section 6.6 below The CE-bound IWF instance MAY be configured to send the following commands to its NSP (see Fig. 1): 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. Notes: 1. The IWF configuration described above: a) Is specific per IWF instance b) Is a local issue. In particular, it should be 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 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). 6.5. CESoPSN Defects 6.5.1. Misconnection See [UCESoPSN] for the reference. The IWF mechanisms for detection of lost packets (e.g., expected next sequence number) MUST NOT be affected by reception of 'stray packets'. 6.5.2. Re-Ordering and Loss of Packets CESoPSN implementations SHOULD use sequence numbers in the RTP header and expected rate of transmission of data packets for detection of our- of-order delivery and packets' loss. In particular, they MAY maintain the next expected sequence number value that would be: Vainshtein et al. Expires March 2003 [Page 16] TDM Circuit Emulation Service over PSN October 2002 o Advanced every time a packet belonging to this PW with an equal or greater (mod 65536) sequence number has been received or a timeout defined by the expected packet arrival rate has expired o Used as the center of a sliding window for packet reordering. The size of this window SHOULD be limited by the size of the jitter buffer. Out-of-order packets that cannot be reordered (e.g. because their sequence numbers are out of the sliding window mentioned above) MUST be considered as lost. If loss of one or more CESoPSN packets has been detected at the egress of the CESoPSN PW, its jitter buffer MUST be filled with the appropriate amount of the "replacement" packets to be replayed into the relevant PWES. Packets with the payload set to "All ones" (AIS) packets MAY be used for this purpose. Other techniques for selecting replacement code MAY be defined locally in order to improve voice quality (see [PWE3-PACKETLOSS]). In addition: o If the CESoPSN control word is used, 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 A counter of lost packets must be incremented. If the loss-of-packets condition persists, an alarm should be sent to the management system. 6.5.3. Malformed Packets CESoPSN PW detects a malformed packet using the following rules: o The PT value in its RTP header does not correspond to one of the PT values allocated for this PW o The actual packet payload size can be unambiguously inferred from the data link, PSN or multiplexing layer of the PW and does not match the payload size defined for the packets of this type in this PW. If a malformed in-order packet has been received at the egress of a CESoPSN PW, then: o 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, an appropriate alarm should be sent to the management system. 6.5.4. Loss of Synchronization See [UCESoPSN] for the reference, 6.6. Performance Monitoring See [UCESoPSN] for the reference. Vainshtein et al. Expires March 2003 [Page 17] TDM Circuit Emulation Service over PSN October 2002 6.7. QoS Issues If the PSN providing connectivity between PE devices is Diffserv- enabled and implements EF PHB (see [RFC3246]), all the CESoPSN data packets should be marked for EF PHB at ingress. Such an arrangement results in decrease of the packets' inter-arrival jitter and hence in decrease of latency introduced by the TDM circuit emulation. 7. RTP Payload Format Considerations In accordance with guidelines specified in [RFC2736], the following issues are addressed by this specification: 7.1. Resilience to moderate loss of individual packets The impact of loss of an individual data packet may be decreased by decreasing the packet size (with the associated loss of efficiency). 7.2. Ability to interpret every single packet This requirement is met since every CESoPSN packet carries a multiple of the native frame of the carried service. 7.3. Non-usage of the RTP Header Extensions This recommendation is met, since RTP-wise, the CESoPSN Control Word is part of the RTP payload. Alignment with this requirement facilitates usage of standard header compression mechanisms if CESoPSN uses UDP/IP as its PSN and multiplexing layers. 7.4. Compression of RTP headers Existing relevant standards ([RFC2508], [RFC3095]) deal with compression of RTP/UDP/IP headers on specific P2P links. Compression techniques defined in these documents are fully applicable for CESoPSN if it uses UDP/IP as PSN and multiplexing layers respectively. Standard compression of CESoPSN/UDP/IP headers will be very effective, since: Value of the SSRC field in the CESoPSN header of data packets remains constant for the duration of a CESoPSN session Value of the Timestamp field in the CESoPSN header is usually incremented by a fixed value from packet to packet CESoPSN control word is NOT defined as RTP header extension. As a consequence, a PSN-independent end-to-end compression technique of RTP headers seems not justified. 8. Congestion Control (RFC 2914) Conformance CESoPSN PWs carry constant bit rate (CBR) services. These services, by definition, cannot behave in a TCP-friendly manner prescribed by [RFC2914] under congestion while retaining any value for the user. Vainshtein et al. Expires March 2003 [Page 18] TDM Circuit Emulation Service over PSN October 2002 Devices implementing CESoPSN and using IP as their PSN layer: o MUST set the ECN bits of the IP header (see [RFC3168]) to non- ECT ('00') value at ingress (to prevent routers in the network from setting them to the CE ('11') value) o SHOULD ignore these bits at egress. 9. FFS Issues Note: This section will be removed from the final revision of the document. The following issues will be addressed in the next revisions of this document: o Techniques for saving the PSN switching capacity when the PW experiences an end service outage or does not carry any valid data o Effect of timestamp resolution on quality of clock recovery in Differential mode o Techniques for end-to-end suppression of the RTP header and their applicability. 10. Security Considerations This document does not affect the underlying security issues of specific PSN. In addition, it defines misconnection detection capabilities of CESoPSN. These capabilities increase resilience of CESoPSN to misconfiguration and some types of DoS attacks. 11. Applicability Statement CESoPSN is an encapsulation layer intended for carrying n*DS0 circuits over PSN. CESoPSN allows carrying both data and clock of n*DS0 circuits across multiple types of PSN as well as CE application state signaling (CAS). CE application state signaling is carried in separate signaling packets. The RTP Payload Type (PT) is used to distinguish between data and signaling packets, while the Timestamp field is used for synchronization. This makes CESoPSN extendable to support different types of CE signaling without affecting the data path in the PE devices. CESoPSN does not presume availability of a global synchronous clock at the ends of a PW. This makes it suitable for Asynchronous Carriers' Carrier applications. CESoPSN carries the TDM data "as is" in accordance with the Principle of Minimal Intervention (see [PWE3-ARCH], Section 3.3.5). Vainshtein et al. Expires March 2003 [Page 19] TDM Circuit Emulation Service over PSN October 2002 CESoPSN uses RTP for carrying the clock across the PSN. 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 indications instead of data. CESoPSN allows using local replacement techniques to improve quality of Voice services under packet loss. 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. CESoPSN allows collection of TDM-like faults and performance monitoring parameters hence emulating 'classic' carrier services of TDM circuits (e.g., SONET/SDH). Similarity with these services is increased by the CESoPSN ability to carry 'far end error' indications. CESoPSN provides for a carrier-independent ability to detect misconnections and malformed packets. This feature increases resilience of the emulated service to misconfiguration and DoS attacks. CESoPSN provides for detection of lost packets and hence allows to distinguish between the PSN problems and ones beyond the PSN as causes of outages of the emulated service. Faithfulness of a CESoPSN PW may be increased if the carrying PSN is Diffserv-enabled and implements EF PHB. CESoPSN 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: 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 Vainshtein et al. Expires March 2003 [Page 20] TDM Circuit Emulation Service over PSN October 2002 for activation of proprietary service-specific protection mechanisms. 12. IANA Considerations This specification requires assignment of one new PW Type for CESoPSN PWs as described in Section 6.1. 13. 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. Some of his inputs will be explored in the next revisions of the draft. We thank Maximilian Riegel, Sim Narasimha, Tom Johnson and Yaron Raz for valuable feedbacks. We thank Alik Shimelmits for many fruitful discussions. References [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in Progress, July-2001, draft-ietf-pwe3- requirements-01.txt [PWE3-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] Andrew G. Malis et al, SONET/SDH Circuit Emulation over Packet (CEP), Work in progress, June 2002, draft-malis-pwe3-sonet- 03.txt [PWE3-UCESoPSN], A.Vainshtein, Y. Stein et al, Unstructured TDM Circuit Emulation Service over Packet Switched Network, Work in progress, October 2002, draft-vainshtein-pwe3-ucesopsn-00.txt Vainshtein et al. Expires March 2003 [Page 21] TDM Circuit Emulation Service over PSN October 2002 [PWE3-CONTROL] L. Martini, N. El-Aawar, E. Rosen, Transport of Layer 2 Frames Over MPLS, Work in progress, August 2002, draft-ietf-pwe3- control-protocol-00.txt [L2TPv3] J.Lau et al, Layer Two Tunneling Protocol "L2TP", Work in progress, October 2001, draft-ietf-l2tpext-l2tp-base-01.txt [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- Communication Layers, RFC 1122, IETF, 1989 [RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, IETF, 1996 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels, RFC 2119, IETF, 1997 [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, RFC 2434, IETF, 1998 [RFC2474] K. Nichols et al., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, IETF, 1998 [RFC 2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, RFC 2508, IETF, 1999 [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP Payload Format Specifications, RFC 2736, IETF, 1999 [RFC3246] Bruce Davie (ed.), An Expedited Forwarding PHB, RFC 3246.IETF, 2002 [RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000 [RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC 3095, IETF, 2001 [RFC3140] D. Black et al, Per Hop Behavior Identification Codes, RFC 3140, IETF, June 2001 [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, IETF, 2001 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- parameters [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s hierarchical levels Vainshtein et al. Expires March 2003 [Page 22] TDM Circuit Emulation Service over PSN October 2002 [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 [I.363.2] ITU-T Recommendation I.363.2 (02/99) AAL type 2 service specific convergence sublayer for trunking [PWE3-PACKETLOSS] Y. Stein, I. Druker, The Effect of Packet Loss on Voice Quality for TDM over Pseudowires, Work in progress, September 2002, draft-stein-pwe3-tdm-packetloss-00.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 Eduard Metz Thrupoint Paasheuvelweg 16, 1105 BH Amsterdam, Netherlands email: eduard.metz@hetnet.nl, emetz@thrupoint.net Tim Frost Zarlink Semiconductor Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK email: tim.frost@zarlink.com Prayson Pate Overture Networks P. O. Box 14864, RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Full Copyright Statement Vainshtein et al. Expires March 2003 [Page 23] TDM Circuit Emulation Service over PSN October 2002 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 application state 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 Vainshtein et al. Expires March 2003 [Page 24] TDM Circuit Emulation Service over PSN October 2002 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 a) PT (payload type) is used to distinguish between packets carrying the packetized TDM data and signaling packets. 6. The SSRC (synchronization source) value in the RTP header of signaling packets MUST be different from that used by the data packets 7. 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 8. 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 9. 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" Vainshtein et al. Expires March 2003 [Page 25] TDM Circuit Emulation Service over PSN October 2002 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. Vainshtein et al. Expires March 2003 [Page 26]