Internet Draft Ron Cohen draft-cohen-pwe3-tdmsonetapp-00.txt Lycium Networks Expires: December 2002 Alexander (Sasha) Vainshtein Axerra Networks Tom K. Johnson Litchfield Communications David Zelig Corrigent Systems Andrew G. Malis Vivace Networks Prayson Pate Overture Networks Yaron Raz Atrica Ray Counterman Avaya Communications Tim Frost Zarlink Semiconductor June 2002 Applicability statement for edge to edge emulation of Time Division Multiplexing (TDM) services over Packet Switched Networks (PSN). Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 provides an applicability statement for the transport of TDM circuits over PSN. The document describes the various deployment scenarios and the recommended encapsulations and Expires - December 2002 [Page 1] TDM emulation applicability statement June 2002 services to be used. In particular, it describes the scenarios applicable for SONET/SDH derived circuit emulation and scenarios applicable for native TDM emulation. Table of Contents 1. Overview......................................................2 2. Fidelity of Emulated TDM services.............................3 2.1 Timing....................................................3 2.2 Service Reliability.......................................4 2.3 End to End delay..........................................4 2.4 Error Rate................................................4 3. Fault Isolation and Performance Monitoring....................5 4. PSN Considerations............................................5 4.1 Path MTU..................................................5 4.2 Bandwidth effectiveness...................................6 4.3 Congestion................................................6 5. Deployment scenarios..........................................6 5.1 Point to Point PDH emulation..............................7 5.2 Multi-Point to Multi-Point SONET/SDH emulation............8 5.3 Multi-point to point PDH to SONET/SDH emulation...........8 6. Security Considerations.......................................9 7. References....................................................9 Author's Addresses..............................................11 1. Overview This document provides an applicability statement for the transport of TDM circuits over PSN. The document describes the various deployment scenarios and the recommended encapsulations and services to be used. In particular, it describes the scenarios applicable for SONET/SDH derived circuit emulation and scenarios applicable for native TDM emulation. SONET/SDH SPE circuit emulation is described in [CEP-SPE]. Extension of SONET/SDH emulation for SONET VT1.5/2/3/6 and SDH VC- 11/12/2 circuits is described in [CEP-VT]. This draft also describes bandwidth saving modes for SONET STS-1 and SDH VC-3/4 circuits carrying tributaries or asynchronous E3/T3 signals. Native TDM circuit emulation for unstructured T1/E1/T3/E3 and structured N*DS0 circuit emulation is described in [CESoPSN]. The native encapsulation also supports generic mechanism for carrying CE application state signaling. All proposals support the same set of PSN encapsulations, multiplexing techniques and share a common control word, differing only in payload. The proposals and the applicability statement all follow the PWE3 framework [PWE3-FW] and requirements [PWE3-REQ] as Expires - December 2002 [Page 2] TDM emulation applicability statement June 2002 well as the protocol layering architectural document [PWE3-LAYERS] and the design guidelines of the architectual principals of the Internet document [RFC1958]. In particular, the principle of minimum intervention that states the payload should, where possible, be transported as received without modification is followed. 2. Fidelity of Emulated TDM Services Emulated TDM services may differ from the alternative to carry them as native TDM services end to end on the following parameters: timing, service reliability, end-to-end delay, and bit-error-rate. Each of these parameters is discussed below. 2.1 Timing The most predominant differentiator between emulation of TDM services and emulation of layer-2 services is the need to stand within the stringent timing and synchronization standards [G.823], [G.824] and [T1.101]. The requirements on the clock accuracy, jitter and wander are tighter for the higher rate services. All protocols allow carrying an emulated signal and the timing of the emulated signal, independent of the provider network timing scheme and source. All protocols do not presume availability of a common synchronous clock at the ends of a PW (i.e. at the PEs). However, the fidelity of the recovered TDM timing in this case will be dependent on the packet-delay variation behavior of the underlying PSN and the robustness of the timing recovery algorithm used. In all protocols, it is possible to decouple the timing quality of the emulated signal from the PSN characteristics by providing a synchronized clock to both PEs. The required quality of this synchronization depends on the emulated signal requirements and application, and is beyond the scope of this document. Given the rigorous synchronization requirements implied by emulating core SONET/SDH circuits, it is expected that SONET/SDH SPE emulation [CES-SPE] will frequently be deployed in situations where a common timing reference is available at the PW end-points. It is expected that in point to point PDH circuit emulation and in PDH to SONET/SDH emulation scenarios common timing reference will not be available at the PW end points. Expires - December 2002 [Page 3] TDM emulation applicability statement June 2002 2.2 Service Reliability Service Reliability may be impacted by two components: the robustness of the underlying PSN and whether specific steps have been taken to protect the emulated service (such as 1+1 protection switching on the emulated service). The PE's de-jitter buffer and packet reordering mechanisms reduce the impact of fast PSN rerouting events on the emulated service. In the case of a failure, fast protection mechanism in the PSN can guarantee performance similar to that of the equivalent recovery mechanisms in the native TDM network. Occasional loss of a single packet does not result in losing more information than carried in this packet, since all the protocols allow independent play out of each packet, as recommended in [RFC2736]. 2.3 End to End Delay The end-to-end delay will be impacted by the packetization delay, the transit delay through the PSN and the packet-delay-variation characteristics of the PSN, as the latter define the minimum de- jitter buffer length and therefore the incremental delay caused by the de-jitter buffer operation. The protocol makes no assumption regarding the delay and delay variation introduced by the PSN. However, the tighter the bound on transit delay and delay variation, the shorter the end-to-end delay of the emulated circuit will be. The packetization delay within all payload formats is constant for the duration of the PW and configurable at set up time. The payload formats differ in the maximal configurable packetization delay. Longer packetization delay adds to the total delay but increase the bandwidth efficiency. Native emulation [CESoPSN] has no restriction on the maximal packetization delay. SPE based SONET/SDH emulation [CEP-SPE] restricts the packetization delay to 0.125 ms equivalent to a single SPE frame. VT based SONET/SDH emulation [CEP-VT] restricts the packetization delay to 0.5 ms equivalent to 4 T1/E1 frames. Echo cancellers may be required when one-way end to end delay exceeds 25 ms [G.131]. 2.4 Error Rate BER will be dependent on the characteristics of the PSN. A BER on a physical link in the PSN is translated in current PSN links to a packet drop. Congestion may also lead to packet drop. Packets arriving too late for the de-jitter buffer depth are effectively Expires - December 2002 [Page 4] TDM emulation applicability statement June 2002 dropped. Each such packet drop event will result in a number of byte errors equivalent to packet length on the emulated signal. The use of shorter packet lengths can minimize the effect at the cost of additional total overhead. All payload formats allow packet length flexibility. New transport technologies enable forwarding PSN packets for selected services even when there is BER on the physical links. This will enable in the future better BER performance of the emulated service. 3. Fault Isolation and Performance Monitoring The protocol allows collection of PDH and SONET/SDH-like faults and performance monitoring parameters. Similarity with existing PDH and SONET/SDH services is increased by the protocol's ability to carry 'far end error' indications (i.e. RDI). The protocol performance monitoring capabilities are based on PDH and SONET/SDH requirements as reflected by the available standards, and adapted to the nature of the protocol. The protocol provides the ability to detect lost packets and hence allows it to distinguish between PSN problems and problems external to the PSN as causes of outages and/or degradations of the emulated service. In addition, the protocol supports fast detection of defects, enabling deployment of rapid fault recovery mechanisms for the emulated circuit. 4. PSN Considerations Limitation on Path MTU, bandwidth considerations and congestion control implications are discussed below. 4.1 Path MTU Some assumptions on path MTU are made. The assumptions are as follows: Path MTU between a pair of PEs SHOULD allow carrying CEP payload of 783 bytes for SONET/SDH circuit emulation defined in [CEP-SPE] and for fractional STS-1/VC-3/VC-4 defined in [CEP-VT]. Path MTU between a pair of PEs MUST allow carrying payload of 537 bytes (for unstructured E3) and 699 bytes (for unstructured T3) [CESoPSN]. While these requirements exceed the minimal IP path MTU defined in [RFC1122], they are easily met in most modern core packet-switching networks. Expires - December 2002 [Page 5] TDM emulation applicability statement June 2002 4.2 Bandwidth Effectiveness The protocol allows for bandwidth conservation in the PSN by carrying only AIS and/or unequipped/Idle indications instead of empty payloads. Payload compression of SONET/SDH STS-1/VC-3/VC-4 circuits carrying tributaries and SONET/SDH STS-1/VC-3 carrying asynchronous DS-3/E3 PDH signals is defined in [CEP-VT]. The first method provides the ability to carry any number of tributaries 1-28 within a SONET STS- 1 emulated circuit and 1-84 tributaries for an SDH VC-4 emulated circuit omitting unequipped or unswitched tributaries. The second method drops the fixed columns within the STS-1/VC-3 asynchronous DS-3/E3 emulated circuit providing up to 28% bandwidth saving. [CESoPSN] N*DS0 structured service provides bandwidth efficient encapsulation for Fractional T1/E1 applications, carrying only the relevant DS0 across the PSN. Longer packetization delay increases the bandwidth effectiveness but adds to the total end to end delay and to the cost of packet loss (BER). The tradeoffs and limitations on the maximal packetization delay are discussed in a previous section. In addition to the encapsulation overhead, each protocol adds PSN specific overhead and control word and RTP header. In some scenarios, and depending on the protocol, the RTP header may be compressed. Specifically, in [CEP-VT]and [CEP-SPE] the RTP overhead may be compressed independent of the timing mode used. 4.3 Congestion Being a constant bit rate (CBR) service, the protocol cannot provide TCP-friendly behavior under network congestion. It will operate best in environments where the Diff-Serv EF PHB with allocated bandwidth is available end-to-end between the PW endpoints and the EF bandwidth is sized to meet the requirements of the emulated TDM circuits, or over a well engineered path as available through the relevant signaling protocols like RSVP-TE and CR-LDP for MPLS PSNs. Using these methods will prevent contention between the TDM Emulation protocol and TCP traffic. Unusable service characteristics from the packet switched network may be used to trigger circuit/PW teardown or switch-over. 5. Deployment Scenarios This section describes the various TDM emulation deployment scenarios and recommends the best encapsulation type for each. In Expires - December 2002 [Page 6] TDM emulation applicability statement June 2002 deployment scenarios where more then one option exists, the considerations for selecting one of the recommended options are indicated. The considerations include (not in order of importance) simplicity, flexibility, bandwidth utilization, operation and maintenance features, and the services expected by deployment of (non-emulated) circuits in similar environments. 5.1 Point to Point PDH Emulation Point to Point PDH emulation deployment scenario refers to scenarios where a structured or unstructured PDH circuit is emulated across the PSN. The lists of services are: 1. Structured services: a. N*DS0, 1 <= N <= 31 as described in [G.704]. 2. Unstructured services a. Unstructured E1 as described in [G.704][G.703] b. Unstructured T1 (DS1) as described in [T.157a] c. Unstructured E3 as defined in [G.751] d. Unstructured T3 (DS3) as described in [T.157a] The native payload format defined in [CESoPSN] provides a simple and efficient encapsulation for emulation of these point to point PDH services. The payload of each packet includes constant number TDM data bytes. Apart of aligning T1s 193 bits into a 25 byte payload, no other overhead is added. Application state signaling (e.g., CAS) can be supported using the appropriate generic mechanism. Structured N*DS0 emulated service includes fractional E1/T1 applications that save bandwidth at the PSN by transferring only "used" timeslots of an E1/T1 circuit, yet allow the CEs to use traditional circuit state indications (AIS/RDI). The payload formats defined in [CEP-VT] can be used to emulate structured PDH services using the SONET/SDH byte-synchronous mapping into SONET/SDH encapsulation and unstructured services using the SONET/SDH bit-asynchronous mappings [GR.253][G.707]. These payload formats add SONET/SDH overhead bytes, and therefore are less bandwidth efficient. This encapsulation effectively creates SONET/SDH circuits between the PEs to carry the PDH signals. The additional overhead may be justified in scenarios where multiple PDH circuits are carried from one PE to the other, or when the service expectations include SONET/SDH like operation, administration, maintenance and provisioning (OAM&P) capabilities. Expires - December 2002 [Page 7] TDM emulation applicability statement June 2002 5.2 Multi-Point to Multi-Point SONET/SDH Emulation [CEP-SPE] defines SONET/SDH circuit emulation for SONET STS-1/SDH VC-3 SPEs as well as for the higher concatenated STS-Nc SPE (N = 3, 12, 48, or 192)/SDH VC-4, VC-4-4c, VC-4-16c, or VC-4-64c SPEs. Because the protocol terminates the SONET/SDH section and line before emulating the individual SPEs, the protocol allows the PSN to operate as a distributed SONET/SDH STS level cross-connect. [CEP-VT] adds circuit emulation for SONET VT1.5/2/3/6 and SDH VC- 11/12/2 circuits. Together the provide emulation for the complete SONET/SDH circuit hierarchy. Because the protocol can also terminate the SONET/SDH path [CEP-VT] before emulating the individual SONET VTs or SDH VC-11/12/2, the protocol allows the PSN to operate as a distributed SONET/SDH VT level cross-connect. [CEP-VT] defines fractional STS-1/VC-3/VC-4 payload formats removing all unequipped or unswitched tributaries. Alternatively, only the relevant tributaries can be switched using the SONET VT1.5/2/3/6 or SDH VC-11/12/2 payload format. The fractional STS-1/VC-3/VC-4 encapsulation is the only technique that allows carriage of virtually concatenated tributaries. It ensures that the delay variation introduced by the emulation process would be the same for all tributaries within the concatenated service, enabling easier implementation of the virtual concatenation termination. An example of use of virtual concatenation for delivering PPP streams is defined in [RFC3255]. 5.3 Multi-point to point PDH to SONET/SDH Emulation The access and metro networks can benefit from the deployment of circuit emulation technology, aggregating multiple PDH circuits into a SONET/SDH uplink. This deployment is fostered by the development of new layer 2 packet technologies adapted specifically for the access and metro network requirements. Multiple provider edge (PE) access devices provide PDH links (T1/E1/T3/E3) to their CEs while a PE closer to the central office aggregates the circuits to a SONET/SDH OC-3/OC-12 trunk. Two approaches can be taken. The first approach is to extend the SONET/SDH trunk across the PSN [CEP-VT] towards the PDH PEs. The second approach is using the native TDM emulation [CESoPSN] to extend the PDH links over the PSN and map the PDH signals into the SONET/SDH trunk at the SONET/SDH PE. Expires - December 2002 [Page 8] TDM emulation applicability statement June 2002 Using the [CEP-VT] payload format the relevant circuits are extracted from the SONET/SDH trunk and sent unmodified across the PSN to the access PEs. The SONET/SDH overhead bytes are used to extend the OAM&P functionality up to the access PEs. This extension of OAM&P includes the ability to monitor errors across the entire SONET/SDH path, including bit parity, remote error indications, end to end path trace functionality and protection functionality. The SONET/SDH emulation allows the required flexibility of the number of circuits distributed over the PSN to each access device. A SONET VT1.5 circuit delivering a T1 circuit across the PSN can be extended into a fractional STS-1 circuit carrying 5 VT1.5 and finally extended to a complete STS-1 carrying 28 VT1.5 circuits, according to the increasing demand for emulated circuit ports within the same access PE. Using the native payload format [CESoPSN], the PDH circuits can be extended across the PSN and mapped to the SONET/SDH trunk at the SONET/SDH PE. The flexibility in the maximal payload size and the N*DS0 payload format can be used to optimize bandwidth efficiency. 6. Security Considerations TDM circuit emulation does not introduce additional security considerations beyond those discussed in section 9 of [PWE3- LAYERS]. 7. References [CEP-SPE] Malis et al, "SONET/SDH Circuit Emulation over Packet (CEP)", draft-malis-pwe3-sonet-03.txt, work in progress, June 2002. [CESoPSN] Vainshtein et al, "TDM Circuit Emulation Service over Packet Switched Network", draft-vainshtein-cesopsn-03.txt, work in progress, June 2002. [CEP-VT] Pate et al, "TDM Service Specification for Pseudo-Wire Emulation Edge-to-Edge", draft-pate-pwe3-tdm-04.txt, work in progress, June 2001. [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-FW] Prayson Pate et al, "Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)", Work in progress, February 2002, draft-ietf- pwe3-framework-00.txt Expires - December 2002 [Page 9] TDM emulation applicability statement June 2002 [PWE3-LAYERS], Stewart Bryant et al., "Protocol Layering in PWE3", Work in Progress, February 2002, draft-bryant-pwe3-protocol-layer-01.txt [RFC1958] B. Carpenter, "Architectual Principles of the Interenet", RFC 1958, IETF, June 1996. [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.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.703] ITU-T Recommendation G.703 (91) - Physical Electrical Characteristics of Hierarchical Digital Interface [G.707] ITU-T Recommendation G.707 (10/00) - Network Node Interface for Synchronous Digital Hierarchy (SDH) [G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex equipments operating at the third order bit rate of 34 368 Kbit/s and the fourth order bit rate of 139 264 Kbit/s and using positive justification [G.802] ITU-T Recommendation G.802 (11/88) - Interworking between networks based on different digital hierarchies and speech encoding laws [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 [GR.253] Telcordia Technologies, "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", GR-253-CORE, Issue 3, September 2000. [GR.1244] Telcordia Technologies, "Clocks for the Synchronized Network: Common Generic Criteria", GR-1244-CORE, Issue 2, December 2000. [T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface Rates and Format Specifications (SONET} Expires - December 2002 [Page 10] TDM emulation applicability statement June 2002 [T1.101] ANSI T1.101-1999. Synchronization interface standards. [T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format Specification [RFC3255] N. Jones, C. Murton, "Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads", RFC 3255, IETF, April 2002 [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP Payload Format Specifications, RFC 2736, IETF, 1999 [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- Communication Layers, RFC 1122, IETF, 1989 [G.131] ITU-T Recommendation G.131 (08/96) - Control of talker echo. Author's Addresses Ron Cohen Lycium Networks 9 Hamanofim St. Phone: +972-9-971-7794 Herzelia 46733, Israel Email: ronc@lyciumnetworks.com Alexander (Sasha) Vainshtein Axerra Networks 24 Raoul Wallenberg St. Phone: +972-3-7569993 Tel Aviv 69719, Israel Email: sasha@axerra.com Tom K. Johnson Litchfield Communications Princeton Building East 27 Princeton Road, Watertown Phone: +1-203-591-7063 CT, 06795, USA. Email:tom_johnson@litchfieldcomm.com David Zelig Corrigent Systems LTD. 126, Yigal Alon st. Phone: +972-3-6945273 Tel Aviv, Israel Email: davidz@corrigent.com Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Email: Andy.Malis@vivacenetworks.com Prayson Pate Overture Networks P.O.Box 14864 Phone: +1-919-5582200 RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Expires - December 2002 [Page 11] TDM emulation applicability statement June 2002 Yaron Raz Atrica 5 Shenkar St. Phone: +972-9-9707227 Herzelia 46733, Israel Email: yaron_raz@atrica.com Ray Counterman Avaya Communications 300 Baker Avenue, Suite 100 Concord, MA 01742, USA Email: rcounterman@avaya.com Tim Frost Zarlink Semiconductor Tamerton Road, Roborough Phone: +44-1752-693840 Plymouth, PL6 7BQ, U.K. Email: tim.frost@zarlink.com Acknowledgement The authors wish to thank Aharon Segev from AxonLink for his review of the draft. Funding for the RFC Editor function is currently provided by the Internet Society. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF Expires - December 2002 [Page 12] TDM emulation applicability statement June 2002 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires - December 2002 [Page 13]