Internet Draft Prayson Pate Document: draft-pate-pwe3-tdm-02.txt Overture Networks Expires: May 21, 2002 Ron Cohen Lycium Networks David Zelig Corrigent Systems TDM Service Specification for Pseudo-Wire Emulation Edge-to-Edge (PWE3) draft-pate-pwe3-tdm-02.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 the service-specific implementation and requirements for Pseudo-Wires Emulation Edge-to-Edge (PWE3) of TDM circuits. It discusses the emulation of circuits (such as T1, E1, T3 and E3) over packet networks using IP, L2TP or MPLS. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 Table of Contents 1 Introduction ................................................. 3 2 Example Network Diagrams ..................................... 4 3 Encapsulation Overview ....................................... 5 4 VT Encapsulation ............................................. 7 5 Fractional STS-1 Encapsulation ............................... 9 6 DS3 Encapsulation ............................................ 11 7 Operational Considerations ................................... 11 8 Security Considerations ...................................... 12 9 References ................................................... 12 10 Authors' Addresses .......................................... 12 11 Full Copyright Section ...................................... 13 Pate et al. Expires May 2002 [Page 2]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 1. Introduction This document describes the service-specific implementation and requirements for Pseudo-Wires Emulation Edge-to-Edge (PWE3) of TDM circuits. It discusses the emulation of circuits (such as T1, E1, T3 and E3) over packet networks using IP, L2TP or MPLS. It is structured as an extension to [MALIS]. See [PATE] and [XIAO] for background, motivation and requirements concerning circuit emulation over PSNs. [MARTINI] and [MALIS] provide information on the very similar emulation of SONET circuits. 1.1. Goals o Definition of encapsulation for T1, E1, DS1C, DS2 and T3 as an extension to [MALIS]. o Definition of mapping to IP, MPLS and L2TP PSNs. o Compatibility with existing circuit networks. o Compatibility with ongoing work in PWE3. 1.2. Non-Goals o Replication of existing works. 1.3. Acronyms ADM Add Drop Multiplexer AIS Alarm Indication Signal BIP Interleaved Parity BITS Building Integrated Timing Supply CEP Circuit Emulation over Packet - see [MALIS] DBA Dynamic Bandwidth Allocation - see [MALIS] L2TP Layer Two Tunneling Protocol LOF Loss of Frame LOS Loss of Signal NPRM Network Performance Report Message PSN Packet Switched Network Pate et al. Expires May 2002 [Page 3]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 POH Path Overhead PWE3 Pseudo-Wire Emulation Edge-to-Edge RAI Remote Alarm Indication SDH Synchronous Digital Hierarchy SONET Synchronous Optical Network TDM Time Division Multiplexing TSA Time Slot Assignment VT Virtual Tributary VTG Virtual Tributary Group 2. Example Network Diagrams Figure 1 below shows a pair of T1s being carried over a TDM/SONET network. The node marked "M" is an M13 multiplexer, while the nodes marked "S" are SONET ADMs. Note that the physical T1s are terminated at the M13 and SONET ADM, but the framing and payload are carried transparently to the hub site. SONET/TDM Network ____ ___ ____ _/ \___/ \ _/ \__ +------+ Physical / \__/ \ |Site A| T1 / +---+ DS3 \ Hub Site |T1 #1=|=================|\M/|-------------+-----+ \ OC12+------+ | | \ |/ \|=============|\ /| \----| | +------+ /\ +---+-------------| \ / |========|=T1 #1| / | S | / | | +------+ Physical/ +---+-------------| / \ |========|=T1 #2| |Site B| T1 \ |\S/|=============|/ \| \----| | |T1 #2=|=================|/ \|-------------+-----+ / +------+ | | \ +---+ OC3 __ / +------+ \ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 1: T1/SONET Example Diagram Figure 2 below shows the same pair of T1s being carried over a packet network. Here the emulation is performed by the boxes marked "E", and the routers marked "R" carry the resulting packets. Note that the emulation, routing and/or SONET functions could be combined in the same device. Such combinations are likely, so an encapsulation format should be easy to incorporate into such applications and devices. Pate et al. Expires May 2002 [Page 4]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 SONET/TDM/Packet Network ____ ___ ____ _/ \___/ \ _/ \__ +------+ Physical / \__/ \_ |Site A| T1 / +-+ +---+ \ Hub Site |T1 #1=|=============|E|=| R | +---+ +-+ +-----+ \ OC12+------+ | | \ +-+ | |===| | | |=|\ /| \----| | +------+ /\ +---+ | | | | | \ / |========|=T1 #1| / | R |=|E| | S | / | | +------+ Physical/ +---+ | | | | | / \ |========|=T1 #2| |Site B| T1 \ +-+ | R |===| | | |=|/ \| \----| | |T1 #2=|=============|E|=| | +---+ +-+ +-----+ / +------+ | | \ +-+ +---+ __ / +------+ \ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 2: T1 Emulation Example Diagram 3. Encapsulation Overview 3.1. Packet Format Section 4 of [MALIS] defines a mapping for SONET SPEs into a format for transport over various Packet Switched Networks (PSNs). That format is extended here to sub-SPE rates using the standard VT (virtual tributary) mapping mechanism. The format for a TDM CEP (Circuit Emulation over Packet) packet is shown in Figure 3 below. +-----------------------------------+ | PSN Header | | IPv4/IPv6, MPLS, L2TP | +-----------------------------------+ | PW Label (MARTINI) | +-----------------------------------+ | CEP Header (MALIS) | +-----------------------------------+ | | | TDM Data | | | +-----------------------------------+ Figure 3: TDM CEP Packet Format The "PSN Header" could be an IP or GRE header, MPLS label or L2TP header. See section 4 of [MALIS] for a description of the overall structure, and for the definition of the CEP Header. The format of the "TDM Data" is described in the following sections. Pate et al. Expires May 2002 [Page 5]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 3.2. TDM Encapsulation This document builds upon existing standards for defining its encapsulations. The SONET VT mapping for DS1/T1, E1, DS1C and DS2 into VT1.5, VT2, VT3 and VT6 is defined in [GR253]. [G.707] defines the mapping of T1s, E1s and DS2 into VC-11, VC-12 and VC-2 containers within the SDH hierarchy. Mapping of E3 and T3 into SDH VC-3 container and to the SONET STS-1 container are defined as well. Both synchronous and asynchronous mappings are defined for E1s and T1s. These mapping are well known and widely used for various applications. This draft extends SONET/SDH circuit emulation [MALIS] to carry the tributary TDM signals. In order to save paper and wear and tear on the reader's eyeballs, SONET terminology is used throughout this document. All SONET discussions are applicable for SDH terminology as well. An example of VT1.5 mapping into an STS-1 SPE is shown in Figure 4 below. 1 2 3 * * * 29 30 31 32 * * * 58 59 60 61 * * * 87 +--+------------------+-+------------------+-+------------------+ 1 |J1| Byte 1 (V1-V4) |R| | | | |R| | | | | +--+---+---+------+---+-+------------------+-+------------------+ 2 |B3|VT | | | |R| | | | |R| | | | | +--+1.5| | | +-+---+---+------+---+-+------------------+ 3 |C2| | | | |R| | | | |R| | | | | +--+ | | | +-+---+---+------+---+-+------------------+ 4 |G1| | | | |R| | | | |R| | | | | +--+ | | | +-+---+---+------+---+-+------------------+ 5 |F2| | | | |R| | | | |R| | | | | +--|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4| 6 |H4| | | | |R| | | | |R| | | | | +--+ | | | +-+---+---+------+---+-+------------------+ 7 |Z3| | | | |R| | | | |R| | | | | +--+ | | | +-+---+---+------+---+-+------------------+ 8 |Z4| | | | |R| | | | |R| | | | | +--+ | | | +-+---+---+------+---+-+------------------+ 9 |Z5| | | | |R| | | | |R| | | | | +--+---+---+------+---+-+---+---+------+---+-+------------------+ | | | +-- Path Overhead +--------------------+-- Fixed Stuffs Figure 4: SONET SPE Mapping of VT1.5 The SPE always contains seven interleaved VT groups (VTGs). Each VTG contains a single type of VT, and each VTG occupies 12 columns (108 bytes) within each SPE. A VTG can contain 4 VT1.5s (T1s), 3 VT2s (E1s), 2 VT3s or a single VT6. Altogether, the SPE can carry 28 T1s or carry 21 E1s. SONET carries DS3 signals within a single STS-1, Pate et al. Expires May 2002 [Page 6]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 The encapsulations described in this document use SONET containers to carry TDM signals. Three formats are defined in this document: o The VT encapsulation maps a single T1, E1, DS1C or DS2 into a VT and then into packets. o The fractional STS-1 encapsulation defined herein can carry any number of VTs up to the maximal allowed within a single STS-1. o A DS3 is encapsulated within an STS-1 container and sent over an STS-1 emulated circuit. These encapsulations are described in more detail in the following sections. 4. VT Encapsulation The VT encapsulation carries a single VT1.5 (T1), VT2 (E2), VT3 or VT6 circuit. Structured and unstructured modes are supported. 4.1. Multi-frame Format VTs are organized in SONET multi-frames, where a SONET multi-frame is a sequence of four SONET SPEs. The SPE path overhead byte H4 indicates the SPE number within the multi-frame. The VT overhead bytes (V1, V2, V3 and V4) of each VT occupy the same SPE byte at a fixed position in SPEs 1, 2, 3 and 4 of the multi-frame, respectively. The VT data can float relative to the SPE position. The VT overhead bytes V1, V2 and V3 are used as pointer and stuffing byte similar to the use of the H1, H2 and H3 TOH bytes. V4 is currently unused. The structured VT mode does not carry the overhead bytes V1-V4 within the payload, but rather maps them into the CEP pointer and N/P indications. The CEP pointer indicates the V5 byte within the payload. The unstructured mode carries these overhead bytes within the payload, and uses the pointer to indicate the beginning of the multi-frame byte by pointing to the V1 byte. Figure 5 below indicates the number of bytes occupied by a VT within a multi-frame. Mapping Bytes per Multi-frame Reference ------------------------------------------------------------- VT1.5 108 bytes [GR253] section 3.4.1.1 VT2 144 bytes [G.707] section 10.1.4.1 VT3 216 bytes [GR253] section 3.4.1.3 VT6 432 bytes [GR253] section 3.4.1.4 Figure 5: Number of Bytes in a Multi-Frame Pate et al. Expires May 2002 [Page 7]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 Each CEP packet carries a fixed payload size that can go up to a single SONET multi-frame. This limitation is due to the restriction of carrying only one pointer within each CEP header. In particular, a VT1.5 emulation packet can carry up to 108 bytes of payload in unstructured mode and up to 104 bytes in structured mode (leaving out V1-V4). 4.2. VT Header The basic VT CEP header is defined in Figure 6 per section 4 of [MALIS]: 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Basic VT CEP Header Format The following fields are used within the header: o R bit: RDI indication. The RDI indication is sent whenever a remote defect indication needs to be sent to the far side. o D bit: Support for DBA mode for unequipped and AIS indication payload. See [MALIS] for more details. o N/P bits: (structured mode only) Indicate negative and positive pointer adjustment events. They are also used to relay SONET/SDH maintenance signals such as AIS-V. N indicates a negative pointer event, and P indicates a positive pointer event. Both N and P are set to 1 to indicate AIS-V signal. o Structure pointer: - In structured mode, the Structure Pointer MUST contain the offset of the V5 byte within the VT Fragment. A value 0 means the first byte after the CEP header. The maximal structure pointer value corresponds to the maximal number of VT bytes contained within a multi-frame, minus the 4 overhead bytes. The Structure Pointer MUST be set to 0x1FF if a packet does not carry the V5 byte. - In unstructured mode, the Structure Pointer MUST contain the offset of the V1 byte within the VT Fragment. Value 0 means the first byte after the CEP header. The maximal structure pointer value corresponds to the maximal number of VT bytes contained within a multi-frame. The Structure Pointer MUST be set to 0x1FF if a packet does not carry the V1 byte. Pate et al. Expires May 2002 [Page 8]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 5. Fractional STS-1 Encapsulation The fractional STS-1 encapsulation carries VTs within an STS-1 container. The STS-1 container includes the path overhead bytes, and the normal SONET encapsulation is used. The additional benefit in using the fractional STS-1 encapsulation is that it does not require sending any unused VTs. The fractional STS-1 encapsulation can optionally carry a bit mask that specifies which VT is carried within the STS-1 payload and which VTs have been removed. This optional bit mask attribute allows the ingress circuit emulation node to remove an unequipped VT on the fly, providing the egress circuit emulation node enough information for reconstructing the VTs in the right order. In particular, the fractional STS-1 encapsulation can be used as a compressed version of the STS-1 encapsulation defined in [MALIS]. 5.1. Fractional STS-1 Mapping Figure 7 below shows a mapping of 3 VT1.5s, designated 1-1, 2-1 and 3-1. Note that the fixed stuffs shown in Figure 4 are not sent when using this mode. POH|VT1 VT2 VT3 VT1 VT2 VT3 VT1 VT2 VT3 +---+---+---+---+---+---+---+---+---+---+ 1 |J1 | V1-V4 | | | | | | | +---+---+---+---+ | | | | | | 2 |B3 | | | | | | | | | | +---+ | | | | | | | | | 3 |C2 | | | | | | | | | | +---+ | | | | | | | | | 4 |G1 | | | | | | | | | | +---+ | | | | | | | | | 5 |F2 | | | | | | | | | | +---+1-1|2-1|3-1|1-1|2-1|3-1|1-1|2-1|3-1| 6 |H4 | | | | | | | | | | +---+ | | | | | | | | | 7 |Z3 | | | | | | | | | | +---+ | | | | | | | | | 8 |Z4 | | | | | | | | | | +---+ | | | | | | | | | 9 |Z5 | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+ Figure 7: Fractional SPE Mapping of VT1.5 Note that Figure 7 shows the bytes from the VTs interleaved, as with the SONET SPE shown in Figure 4. This interleaving reduces the buffering required at the ingress and egress PEs. It also helps simplify the construction of combined PW/ADM PEs to operate in networks such as that shown in Figure 2. The "fractional" SPE in Figure 7 could be expanded out to a full SPE by the addition of Pate et al. Expires May 2002 [Page 9]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 "dummy" VTs, Path Overhead and fixed stuffs. Section 3.3.3 of [GR253] states that "Four bytes (V5, J2, Z6 and Z7) are allocated for VT POH." The same section also defines how these bits are set. 5.2. Fractional STS-1 CEP header The fractional STS-1 CEP header uses the STS-1 CEP header encapsulation as defined in [MALIS]. Optionally, an additional 4 byte header extension word is added. The extended header is described in Figure . The E bit is set to 1 to indicate use of the extended header [MALIS] 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| Unequipped Bit Mask [0:27] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Extended fractional STS-1 Header The following fields are used within the extended header: o R, D, N, P, Structured Pointer, Sequence Number: All fields are used as defined in [MALIS] for STS-1 encapsulation. o E: Extension bit. E = 1 indicates that extended header is used. E = 0 indicates that extended header is not carried within the packet. o Unequipped Bit Mask: Each bit within the bit mask refers to a different VT within the STS-1 container. Bit zero refers to the first VT within the STS-1 SPE. For an STS-1 carrying VT1.5s, all 28 bits are used. For an STS-1 carrying VT2s, only the first 21 bits are used. A bit set to 0 indicates that the fractional STS-1 payload carries the corresponding VT. 5.3. BIP The B3 byte within the POH indicates the bit wise parity of the payload. In applications where the Path is terminated at the PE (i.e. the fractional STS-1 is used to carry TDM signals between the ingress and egress emulation edges), the B3 is generated and should equal the bit-wise parity of the VTs carried within the fractional STS-1 payload. In applications where the Path is not terminated at the PE (i.e. the fractional STS-1 is used to carry a compressed STS-1), the B3 value should be modified to reflect the removal of the unequipped VTs. Let B3* be the bit wise parity of the removed unequipped VTs, and let B3p be the value carried within the Pate et al. Expires May 2002 [Page 10]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 fractional STS-1 payload. Then B3p = B3 || B3*, where || indicates a bit-wise OR operation. The egress PE can reconstruct the unequipped VTs and modify the B3p value in the same manner to accommodate for the additional VTs added. In this way the end-to-end B3 parity is preserved. 6. DS3 Encapsulation A DS3 is encapsulated into an STS-1 SPE using the format defined in sections 3.4.2.1 (synchronous) and 3.4.2.2 (asynchronous) of [GR253]. The STS-1 SPE is then encapsulated as defined in section 4 of [MALIS]. 7. Operational Considerations 7.1. Time Slot Assignment (TSA) For an application like that shown in Figure 2, it may be desirable to change the TSA for a given VT. For example, an operator may desire to take an E1 appearing in the first VT on the ingress side and place it in a different E1 on the egress side. The PE MAY allow the operator to configure the assignment of Time Slots at each end of the PW. 7.2. Timing See section 8 of [MALIS]. 7.3. Loopbacks When operating in a structured mode, a PE SHOULD process loopback messages as defined in [T1.403]. This allows better isolation of faults in a network. It also facilitates the certification of equipment for operation in a carrier's network. There are also inband loopbacks that are used for voice equipment. These are falling out of favor due to their incompatibility with data services. A PE that implements inband loopbacks must have the capability to disable them. 7.4. Performance Processing [T1.403] defines a Network Performance Report Message (NPRM) that carries periodic reports on the performance of the link. A PE operating in a structured mode SHOULD generate these messages, as they are frequently used for surveillance and trouble-shooting. 7.5. LOS/AIS A TDM multiplexer, switch or other path-terminating device generates AIS in the downstream direction in response to a LOS or LOF condition. This is done by sending a certain pattern in the data Pate et al. Expires May 2002 [Page 11]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 stream. Bandwidth can be saved by suppressing the AIS signal in the emulated stream and sending instead an indication in the control overhead. [MALIS] discusses the propagation of AIS using the pointer bits in the TDM control word. A PE emulating TDM circuit must either replicate the AIS indication or indicate this condition in the control overhead. 7.6. Session Multiplexing Session multiplexing is accomplished by use of the PW label shown in Figure 3. 8. Security Considerations See section 11 of [MALIS]. 9. References [MARTINI] Martini et al, "Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-trans-mpls-08.txt, work in progress, November 2001. [GR253] Bellcore, "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria" (GR253CORE), Issue 3, September 2000. [G.707] ITU, ITU Recommendation G.707, "Network Node Interface For The Synchronous Digital Hierarchy", 1996. [T1.403] ANSI, "Network and Customer Installation Interfaces - DS1 Electrical Interfaces", T1.403-1999, May 24, 1999. [XIAO] Xiao et al, "Requirements for Pseudo Wire Emulation Edge-to- Edge (PWE3)" (draft-pwe3-requirements-01.txt), work in progress, July 2001. [PATE] Pate et al, "Framework for Pseudo-Wire Emulation Edge-to- Edge (PWE3)" (draft-pate-pwe3-framework-02.txt), work in progress, September 2001. [MALIS] Malis et al, "SONET/SDH Circuit Emulation over Packet (CEP)" (draft-malis-pwe3-sonet-01.txt), work in progress, November 2001. 10. Authors' Addresses Prayson Pate Overture Networks, Inc. P. O. Box 14864 RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Pate et al. Expires May 2002 [Page 12]
Internet Draft draft-pate-pwe3-tdm-02 November 21, 2001 Ron Cohen Lycium Networks P.O.Box 12256 Herzeliya, Israel 46733 Email: ronc@lyciumnetworks.com David Zelig Corrigent Systems LTD. 126, Yigal Alon st. Tel Aviv, Israel EMail: Davidz@corrigent.com 11. Full Copyright Section Copyright (C) The Internet Society (2000). 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. Pate et al. Expires May 2002 [Page 13]