Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)

This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital signals of the PDH as well as the SONET/SDH hierarchy over packet-switched networks. It is based on the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH]. It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits.

The term "TDM" will be used in this documents as general descriptor of the synchronous bit streams belonging to either the PDH or the SONET/SDH hierarchies. The bit rates traditionally used in various regions of the world are detailed in the normative reference [G.702]. For example, in North America the T1 bit stream of 1.544 Mbps and the T3 bit stream of 44.736 Mbps are mandated, while in Europe the E1 bit stream of 2.048 Mbps and the E3 bit stream of 34.368 Mbps are utilized. Although TDM can be used to carry unstructured bit streams at the rates defined in [G.702], there is a standardized method of carrying bit streams in larger units each containing the same amount of bits. These units are called frames, and the transport mode is denoted "framed TDM". Related to the sampling frequency of voice traffic, there are always 8000 such frames per second, hence the T1 frame consists of 193 bits and the E1 frame of 256 bits. The number of bits in a frame is called the frame size. Framed TDM is using some bits in the bit stream to identify the boundaries of the frames (e.g. 1 framing bit per T1 frame, a sequence of 8 framing bits per E1 frame). The details of how these framing bits are generated and used are elucidated in [G.704], [G.751] and [G.752]. Unframed TDM has all bits available for payload. Framed TDM is often used to multiplex multiple voice channels each consisting of 8000 8bit-samples per second in a sequence of timeslots recurring in each frame. This multiplexing is called "channelized TDM" and introduces additional structure.

The term "structured TDM" is used in this document to refer to both 'channelized TDM' as well as 'framed TDM' whenever framing and eventually channelization exist and are deemed significant for the transport of TDM over PWs.

A TDM stream is denoted "unstructured" when it is unframed, or when it is framed or even channelized, but the framing and channelization structure are deemed inconsequential from the transport point of view. In such cases all structural overhead is transparently transported by the PW along with the payload data, and the encapsulation method employed provides no mechanisms for its location or utilization.

The term SONET refers to the North American Synchronous Optical NETwork as specified by [GR-253] [Ed-Note###: add T.105a here???]. The Synchronous Digital Hierarchy (SDH) is the international equivalent and enhancement of SONET and is specified by [G.707]. Although terminology between the two technologies is different, both have the concept of a Nx783 byte payload container repeated every 125us. This payload is referred to for SONET as an STS-1 SPE and may be concatenated into higher bandwidth circuits (e.g. STS-Nc) or sub-divided into lower bandwidth circuits (Virtual Tributaries). The higher bandwidth concatenated circuits can be used to carry anything from IP Packets to ATM cells to Digital Video Signals. Individual STS-1 SPEs are frequently used to carry individual DS3 or E3 TDM circuits. When the 783 byte containers are sub-divided for lower rate payloads, they are frequently used to carry individual T1 or E1 TDM circuits. Both SONET and SDH include a substantial amount of transport overhead that is used for performance monitoring, fault isolation, and other maintenance functions along different types of optical or electrical spans. In addition, the payload area includes dedicated overhead for end-to-end performance monitoring, fault isolation, and maintenance for the service being carried. If the main payload area is sub-divided into lower rate circuits (such as T1/E1), additional overhead is included for end-to-end monitoring of the individual T1/E1 circuits. A key feature of STS-1/Nc and VT service emulation is the carriage of the Path or VT maintenance overhead through the PSN. This requirements document discusses the requirements for emulation of the SONET/SDH services. These services include end-to-end emulation of the core 783 byte payload (e.g. STS-1 SPE), emulation of concatenated payloads (e.g. STS-Nc SPE), as well as emulation of a variety of sub-STS-1 rate circuits jointly referred to as Virtual Tributaries (VT).

[PWE3-REQ] specifies common requirements for edge-to-edge-emulation of circuits of various types. However, these requirements, as well as references in [PWE3-ARCH] do not cover specifics of PWs carrying TDM circuits. The need for a specific document complementing [PWE3-REQ] with regard to edge-to-edge-emulation of TDM circuits arises from following causes: Specifics of the TDM circuits, e.g.: the need for balance between the clock of ingress and egress end services in each direction of the PW, the need to maintain jitter and wander of the clock of the egress end service within the limits imposed by the appropriate normative documents in spite of the packet delay variation produced by the PSN. Specifics of applications using (native and emulated) TDM circuits, e.g. voice applications: put special emphasis on minimization of one-way delay, are relatively tolerant to errors in data. Other applications might have different specifics. e.g. transport of signaling information: is relatively tolerant to one-way delay, is sensitive to errors in transmitted data. Specifics of the customers' expectations regarding end-to-end behavior of services that contain emulated TDM circuits, e.g., experience with carrying such services over SONET/SDH networks increases the need for: isolation of problems introduced by the PSN from those occurring beyond the PSN bounds, higher sensitivity to misconnection, etc.

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. However some terms and acronyms are specific in conjunction with the TDM services. In particular: It is one of several signaling techniques used by the telephony applications to convey various states of these applications (e.g., off-hook and on-hook). CAS uses a certain, circuit-specific multiframe structure that is imposed on the TDM bit stream and a predefined association between the relative timeslot (= channel) number within this stream and position of certain bits within this multiframe structure. In the case of E1 there are four 500 bit/s channels for each timeslot used to distinguish and signal application states (see [G.704] for details).CAS is also used in conjunction with D4 and ESF formats of T1 using "robbed bits". In case of D4 this results in 2 channels of 333.(3) bit/s, and in case of ESF - 4 such channels.[## Ed-note##: more details to be included here?] This is an alternative to the CAS method of signaling used by the telephony applications. E.g., for SS7 Common Channel Signaling is described in [Q.700] and references therein. For the TDM network we use the terms "jitter" and "wander" as defined in [G.823] and [G.824], while for the PSN measures from IETF IPPM (like packet delay variation - see [RFC3393]) are used.

Generic models that have been defined in [PWE3-ARCH] in Sections - 4.1 (Network Reference Model), - 4.2 (PWE3 Preprocessing), - 4.3 (Maintenance Reference Model), - 4.4 (Protocol Stack Reference Model) and - 4.5 (Pre-processing Extension to Protocol Stack Reference Model). They are fully applicable for the purposes of this document without any modifications. All the services considered in this document represent special cases of the Bit-stream and Structured bit-stream payload type defined in Section 3.3 of [PWE3-ARCH].

Timing synchronization of emulated TDM services comprises Clock recovery, Timed delivery (delay), and Frame recovery. The availability of a common clock at the ends of PW is not presumed. However, without a common clock the fidelity of the recovered TDM timing will be dependent on the packet delay variation behavior of the underlying PSN and the robustness of the applied timing recovery algorithms.

Clock recovery is the extraction of the transmission bit timing information out of the delivered packet stream. Extraction of this information from a highly jittered source such as a packet stream is quite a complicated task.

Timed delivery is the delivery of non-contiguous PW PDUs to the PW output interface with a constant delay (phase shift) relative to the input interface. The delay of the delivery may be relative to a clock derived from the packet stream via clock recovery, or via an external clock.

Frame recovery is the process to detect the frame boundaries. It starts with the hunting process in the out-of-alignment state and provides the frame alignment reacquisition in the correct-alignment state. Frame recovery provides access to signaling and maintenance information embedded in the framing bits and allows for advanced functions to cope with transmission errors and to enhance bandwidth utilization in the underlying PSN.

A generic network synchronization reference model shown in Figure 1 below:

|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| | | | | |y| |c| |y| | | | | | | |y| |c| |y| | | | +---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+ ^ ^ | | ^ ^ ^ | | | ^ | ^ ^ | | | |B | | | |<------+------>| | | | | | | A | +--+ +--+ | | | +--+-E | F | | +---------------+ +-+ +---------------+ | | ^ |I| ^ | | | +-+ | | | C D | +-----------------------------L-----------------------------+ ]]> Figure 1: Timing Recovery Reference Diagram The following notations are used in Figure 1: Customer edge devices terminating TDM circuits to be emulated. Provider edge devices adapting these end services to PW. Provider core routers Physical interface terminating the TDM circuit. PSN-bound IWF of the PW CE-bound IWF of the PW. It contains a compensation buffer (also known as the "jitter buffer") of limited size. TDM end service circuits PW providing edge-to-edge-emulation for the TDM circuit. The characters "A" - "L" are denoting various clocks: The clock used by CE1 for transmission of the TDM end circuit towards CE1. The clock recovered by PE1 from the incoming TDM end circuit. "A" and "B" always have the same frequency. The same as "A" and "B" respectively for CE2 and PE2 ("G" and "H" have the same frequency). Local oscillators available to PE1 and PE2 respectively. Clock used by PE2 to transmit the TDM end service circuit to CE2 (the recovered clock). Clock recovered by CE2 from the incoming TDM end service ("E and "F" have the same frequency). If it exists, it is the common network reference clock available to PE1 and PE2. The same as "E" and "F" respectively for PE1 and CE1 ("J" and "K" have the same frequency). If it exists, it is the common reference clock of CE1 and CE2. Note that different pairs of CE devices may use different common reference clocks. One of the objectives of edge-to-edge-emulation of a TDM circuit is balance between clocks "B" and "E" (i.e., these clocks MUST have the same frequency). This objective may be achieved by different means depending on the actual network synchronization scheme deployed. The following groups of the network synchronization deployment scenarios can be considered:

Depending on which part of the network is synchronized by a common clock there are two scenarios: PE Synchronized Network: The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I": Clocks "E" and "J" are the same as "D" and "C" respectively. Clocks "A" and "G" are the same as "K" and "F" respectively (i.e., CE1 and CE2 use the so-called loop timing).

|--------->|............PW2..............|--------->| --/ | +-----+ | |- - -|=================|- - -| | +-----+ +-----+ +-----+ ^ ^ |C |D +-----------+-----------+ | +-+ |I| +-+ ]]> Figure 2: PE synchronized scenario CE Synchronized Network: The common network reference clock "L" is available to all the CE devices, and local oscillators "A" and "G" are locked to "L": Clocks "E" and "J" are the same as "G" and "A" respectively (i.e., PE1 and PE2 use the so-called loop timing).

|............PW2..............|--------->| | +-----+ | |- - -|=================|- - -| | +-----+ ^ +-----+ +-----+ ^ |A G| +----------------------------+------------------------------+ | +-+ |L| +-+ ]]> Figure 3: CE synchronized scenario No timing information has to be transferred in these cases.

In this case each CE uses its own transmission clock source that must be carried across the PSN and recovered by the remote PE, respectively. The common PE clock "I" can be used as reference for this purpose. The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I": Clocks "A" and "G" are generated locally without reference to a common clock. Clocks "E" and "J" are generated in reference to a common clock available at all PE devices. In a slight modification of this scenario, one (but not both!) of the CE devices may use its receive clock as its transmission clock (i.e. use the so-called loop timing).

|............PW2..............|--------->| | +-----+ | |- - -|=================|- - -| | +-----+ ^ +-----+<-------+------->+-----+ |A | +-+ |I| +-+ ]]> Figure 3: Relative network scenario Timing information may be transferred in this case.

The asynchronous scenario is characterized by: No common network reference clock "I" is available to PE1 and PE2. No common reference clock "L" is available to CE1 and CE2.

|............PW2..............|--------->| | +-----+ | |- - -|=================|- - -| | +-----+ ^ +-----+ +-----+ | ^ A| E| ]]> Figure 4: Asynchronous Scenario Asynchronous Carrier of Carriers scenario clearly represents the worst case for achieving the goal of balancing clocks "A" and "E". Note that one of the means available for achieving this goal is the compensation buffer in the CE-bound IWF, and the balance between clocks "A" and "E" must be exact over the period required for replaying out of this buffer. Timing information must be transferred in this case.

This document defines requirements for the payload and encapsulation layers for edge-to-edge emulation of TDM services with bit-stream payload as well as structured bit-stream payload. Wherever possible, the requirements specified in this document SHOULD be satisfied by appropriate arrangements of the encapsulation layer only. The (rare) cases when the requirements apply to both the encapsulation and payload layers (or even only to the payload layer only) will be explicitly noted. The service-specific encapsulation layer for edge-to-edge emulation comprises the following services over a PSN:

Unstructured E1 as described in [G.704]. Unstructured T1 (DS1) as described in [G.704]. Unstructured E3 as defined in [G.751]. Unstructured T3 (DS3) as described in [T.107].

Structured E1/T1 with or without CAS as described in [G.704] NxDS0 with or without CAS

SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 SONET STS-Nc SPE (N = 3, 12, 48, 192) / SDH VC-4, VC-4-4c, VC-4-16c, VC-4-64c SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2 SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3

The combination of encapsulation and payload layers for edge-to- edge-emulation considered in this document should comply with the following common PW requirements defined in [PWE3-REQ]: Conveyance of Necessary Header Information: For unstructured circuits this functionality MAY be provided by the payload layer. For structured circuits, the necessary information MUST be provided by the encapsulation layer. Support of Multiplexing and Demultiplexing if supported by the native services: Relevant for Nx DS0 circuits with or without signaling and Nx VT-x in a single STS-1 or VC-4. For these circuits means that the combination of encapsulation and payload layers MUST provide for separate treatment of every sub-circuit. Enough information SHOULD be provided by the pseudo wire to allow multiplexing and demultiplexing by the NSP. Reduction of the complexity of the PW emulation by using NSP circuitry for multiplexing and demultiplexing MAY be the favorite solution. Intervention or transparent transfer of Maintenance Messages of the Native Services depending on the particular scenario. Consideration of Per-PSN Packet Overhead (see also below). Detection and handling of PW faults. The list of faults is given in below. The following requirements listed in [PWE3-REQ] are not applicable to emulation of TDM services: Support of variable length PDUs, Fragmentation.

Structured circuits considered in this document belong to the 'Structured bit-stream' payload type defined in [PWE3-ARCH]. Unstructured circuits considered in this document belong to the 'Bit-stream' payload type defined in [PWE3-ARCH]. Accordingly, the encapsulation layer MUST provide the common Sequencing service and SHOULD provide Timing information (Synchronization services). Note: The encapsulation layer for the (Structured) Bit-stream payload circuits MAY NOT provide the length service.

The combination of payload and encapsulation layers SHOULD comply with the general design principles of the Internet protocols as presented in [RFC1958], Section 3 and [PWE3-ARCH].

The emulation MUST support network interworking between end services of the same type (see ) and, wherever appropriate, bit-rate. The encapsulation layer SHOULD remain unaffected by specific characteristics of connection between the end services and PE devices at the two ends of the PW.

The encapsulation layer MUST provide synchronization services that are sufficient for: balancing of clock of ingress and egress end services regardless of the specific network synchronization scenario, keeping the jitter and wander of the clock of the egress service within the service-specific limits as defined by the appropriate normative references. If the same high-quality synchronization source is available to all the PE devices in the given domain, the encapsulation layer SHOULD be able to offer additional benefits (e.g., facilitate better reconstruction of the native service clock).

The robustness of the emulated service does not only depend upon means applied to the edge-to-edge-emulation but also upon proper implementation of the procedures of the native TDM service.

Edge-to-edge-emulation of TDM circuits MAY assume very low probability of packet loss between ingress and egress PE. In particular, no retransmission mechanisms are required. In order to minimize effect of lost packets on the egress service, the encapsulation layer SHOULD: Allow independent interpretation of TDM data in each specific packet by the egress PE (see [RFC2736]. This requirement MAY be disregarded if the egress PE has to interpret structures that exceed the path MTU between the ingress and egress PEs. Allow reliable detection of lost packets (See next section). In particular, it should allow prediction (within reasonable limits) of the arrival time of the next PW packet and detection of lost packets that takes such a prediction into account. Minimize possible effect of lost packets on recovery of the circuit clock by the egress PE depending on the actual network synchronization scheme deployed. In case of unstructured emulation, facilitate increased resilience of CEs against lost packets by allowing the egress PE to substitute appropriate data.

The encapsulation layer MUST provide the necessary mechanisms that guarantee ordered delivery of packets carrying the TDM data over the PSN. Packets that have arrived out-of-order: MUST be detected, SHOULD be reordered if not judged to be too late or too early for playout. Out-of-order packets that cannot be reordered MUST be treated as lost.

Unstructured TDM circuits do usually not require any special mechanisms for carrying CE signals as these would be carried as part of the emulated service. Some CE applications using structured TDM circuits (e.g., telephony) require specific signaling that conveys changes of state of these applications relative to the TDM data. The encapsulation layer SHOULD support signaling of state of CE applications for the relevant circuits providing for: Ability to support different signaling schemes with minimal impact on encapsulation of TDM data, Multiplexing of application-specific CE signals and data of the emulated service in the same PW, Synchronization (within the application-specific tolerance limits) between CE signals and data at the PW egress, Probabilistic recovery against possible occasional loss of packets in the PSN, Deterministic recovery of the CE application state after PW setup and network outages. CE signaling that is used for maintenance purposes (loopback commands, performance monitoring data retrieval, etc.) SHOULD be dealt within the scope of the generic PWE3 maintenance protocol.

The encapsulation layer SHOULD allow for an effective trade-off between the following requirements: Effective PSN bandwidth utilization. Assuming that the size of encapsulation layer header does not depend on the size of its payload, increase in the packet payload size results in increased efficiency. Low edge-to-edge latency. Low end-to-end latency is the common requirement for Voice applications over TDM services. Packetization latency is one of the components comprising edge- to-edge latency and decreases with the packet payload size. The compensation buffer used by the CE-bound IWF increases latency to the emulated circuit. Additional delay introduced by this buffer SHOULD NOT exceed the packet delay variation observed in the PSN. The encapsulation layer SHOULD provide for saving the PSN bandwidth by not sending corrupted TDM data across the PSN. The encapsulation layer MAY provide the ability to save the PSN bandwidth for the structured case by not sending channels that are permanent inactive. The encapsulation layer MAY enable the dynamic suppression of temporarily unused channels from transmission for the structured case. If used, dynamic suppression of temporarily unused channels MUST NOT violate integrity of the structures delivered over the PW. For NxDS0 the encapsulation layer MUST provide the ability to keep the edge-to-edge delay independent from the service rate.

In accordance with the PWE3 principles, the PWs do not exert any control over the underlying PSN. In particular, the encapsulation layer for edge-to-edge-emulation of TDM circuits does neither affect one-way delay of packets from ingress to egress PE, nor its variation. The encapsulation layer SHOULD provide for ability to compensate for the packet delay variation without affecting jitter and wander of the egress end service clock. The encapsulation layer MAY provide for run-time adaptation of delay introduced by the jitter buffer if the packet delay variation varies with time. Such an adaptation MAY introduce low level of errors (within the limits tolerated by the application) but SHOULD NOT introduce additional wander of the egress end service clock.

The combination of encapsulation and PSN tunnel layers used for edge-to-edge emulation of TDM circuits SHOULD be compatible with the existing PSN infrastructures. In particular, compatibility with the mechanisms of header compression over links where capacity is at a premium SHOULD be provided.

Edge-to-edge emulation of TDM circuits may result in constant bit rate flows in the PSN. When transfered over the Internet congestion control of TDM PWs MUST be provided by appropriate means. It MUST be avoided that all pseudo wires in the congested network are switched down simultaneously or the pseudo wires are reestablished again simultaneously to avoid unstable behaviour of the network. Further considerations are listed in chapter 6.5 of [PWE3-Arch].

The encapsulation layer for edge-to-edge emulation of TDM services SHOULD, separately or in conjunction with the lower layers of the PWE3 stack, provide for detection, handling and reporting of the following defects: Misconnection, or Stray Packets. Importance of this requirement stems from the customers' expectations based upon powerful means of misconnection detection in SONET/SDH networks. Loss of packets. Importance of this requirement stems from the providers' need to distinguish between various causes of the end-to-end outage of the emulated service. Malformed packets. Loss of synchronization.

The encapsulation layer for edge-to-edge emulation of TDM services SHOULD provide for collection of performance monitoring (PM) data that is compatible with the parameters defined for 'classic', TDM- based carriers of these services. The applicability of [G.826] is left for further study.

The security considerations listed in [PWE3-REQ] fully apply also to the emulation of TDM circuits.

[PWE3-REQ] draft-ietf-pwe3-requirements-05.txt XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to- Edge (PWE3), Work in Progress, March 2003 [PWE3-ARCH] draft-ietf-pwe3-arch-04.txt Stewart Bryant et al, PWE3 Architecture, Work in progress, June 2003 [RFC1958] B. Carpenter (ed.). Architectural Principles of the Internet, RFC 1958, IETF, 1996 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels, RFC 2119, IETF, 1997 [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP Payload Format Specifications, RFC 2736, IETF, 1999 [RFC3393] C. Demichelis, P. Chimento, IP Packet Delay Variation Metric for IPPM, RFC 3393, IETF, 2002 [GR253] Telecordia Technologies, "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", GR-253-CORE, Issue 3, (09/00) [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.707] ITU-T Recommendation G.707 (10/00) - Network node interface for the synchronous digital hierarchy (SDH) [G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex equipments operating at the third order bit rate of 34 368 Kbit/s and the fourth order bit rate of 139 264 Kbit/s and using positive justification [G.752] ITU-T Recommendation G.752 (11/88) - Characteristics of digital multiplex equipments based on a second order bit rate of 6312 kbit/s and using positive justification [G.823] ITU-T Recommendation G.823 (03/00) - The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy [G.824] ITU-T Recommendation G.824 (03/00) - The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy [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 [Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT Signalling System No. 7 [T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format Specification