Internet Draft Prayson Pate Document: draft-ietf-pwe3-sonet-vt-00.txt Overture Networks Expires: February 2003 Ron Cohen Lycium Networks David Zelig Corrigent Systems August 2002 TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3) 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 describes the service-specific implementation and requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) of TDM circuits using SONET/SDH payload formats over packet networks using IP or MPLS. This draft extends SONET/SDH SPE emulation proposal [CEP-SPE], providing SONET VT1.5/2/3/6 and SDH VC-11/12/2 circuit emulation. This draft also provides bandwidth saving modes for SONET STS-1 and SDH VC-3/4 carrying tributaries or asynchronous T3/E3 signals. This proposal is optimized for VT level cross connect applications, for PDH to SONET/SDH emulation and for carrying PDH circuits across a PSN. The applicability statement for TDM circuit emulation (PDH and SONET/SDH) is described in [TDM- APP]. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Pate et. al. Expires - February 2003 [Page 1]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 Authors Prayson Pate Overture Networks Ron Cohen Lycium Networks David Zelig Corrigent Systems LTD. Ashwin Moranganti Appian Communications Table of Contents 1. Introduction..................................................2 2. Example Network Diagrams......................................5 3. Encapsulation Overview.......................................10 4. VT Encapsulation.............................................12 5. Fractional STS-1 (VC-3) Encapsulation........................15 6. DS3 Encapsulation............................................20 7. E3 Encapsulation.............................................21 8. Fractional VC-4 Encapsulation................................22 9. Operational Considerations...................................27 10. Security Considerations.....................................32 11. Appendix A: NSP Functions...................................32 12. Intellectual Property Disclaimer............................35 13. Acknowledgments.............................................35 14. References..................................................35 15. Author's Addresses..........................................36 16. Full Copyright Section......................................36 1. Introduction 1.1 Overview This document describes the service-specific implementation and requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) of TDM circuits using SONET/SDH payload formats. This draft extends SONET/SDH SPE emulation proposal [CEP-SPE], providing SONET VT1.5/2/3/6 and SDH VC-11/12/2 circuit emulation. This draft also provides bandwidth saving modes for SONET STS-1 and SDH VC-3/4 carrying tributaries or asynchronous T3/E3 signals. This proposal is optimized for VT level cross connect applications, for PDH to SONET/SDH emulation and for carrying PDH circuits across a PSN. The applicability statement for TDM circuit emulation (PDH and Pate et. al. Expires - February 2003 [Page 2]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 SONET/SDH) is described in [TDM-APP]. This draft discusses the emulation of these circuits over packet networks using IP or MPLS. 1.2 Acronyms ADM Add Drop Multiplexer AIS Alarm Indication Signal AU-n Administrative Unit-n (SDH) AUG Administrative Unit Group (SDH) BIP Interleaved Parity BITS Building Integrated Timing Supply CEP Circuit Emulation over Packet - see [CEP-SPE] CI Customer Installation DBA Dynamic Bandwidth Allocation - see [CEP-SPE] EBM Equipped Bit Mask LOF Loss of Frame LOS Loss of Signal NI Network Interface NPRM Network Performance Report Message PSN Packet Switched Network POH Path Overhead PTE Path Terminating Equipment PWE3 Pseudo-Wire Emulation Edge-to-Edge RAI Remote Alarm Indication SDH Synchronous Digital Hierarchy SONET Synchronous Optical Network SPRM Supplementary Performance Report Message STM-n Synchronous Transport Module-n (SDH) Pate et. al. Expires - February 2003 [Page 3]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 STS-n Synchronous Transport Signal-n (SONET) TDM Time Division Multiplexing TSA Time Slot Assignment TU-n Tributary Unit-n (SDH) TUG-n Tributary Unit Group-n (SDH) VC-n Virtual Container-n (SDH) VT Virtual Tributary VTG Virtual Tributary Group Pate et. al. Expires - February 2003 [Page 4]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 2. Example Network Diagrams 2.1 Example 1 - T1 Transport Figure 1 below shows a T1 being used to connect Sites A and B via a TDM/SONET network. The node marked "M" is an M13 multiplexer, while the nodes marked "S" are SONET ADMs. The framing would be terminated at the M13 and SONET ADM in a structured application and carried transparently in an unstructured application. Note that Figure 1 is also applicable for the transport of E1, E3 and DS3. SONET/TDM Network ____ ___ ____ _/ \___/ \ _/ \__ Physical T1s +------+ / \__/ \ | |Site A| / +---+ DS3 \ | Hub Site |T1 #1=|=================|\M/|-------------+-----+ \ | +------+ | | ^ \ |/ \|=============|\ /| \ v | | +------+ | /\ +---+-------------| \ / |========|=T1 #1| Physical T1s / | S | / | | +------+ | / +---+-------------| / \ |========|=T1 #2| |Site B| v \ |\S/|=============|/ \| \ | | |T1 #2=|=================|/ \|-------------+-----+ / +------+ | | \ +---+ OC3 __ / +------+ \ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 1: T1 Transport Example Diagram Figure 2 below shows the same pair of T1s being carried over a packet network using the VT encapsulation defined in Section 4 of this draft. 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. Pate et. al. Expires - February 2003 [Page 5]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 SONET/TDM/Packet Network ____ ___ ____ _/ \__/ \ _/ \__ Physical T1s +------+ /+-+ \__/ \_ | |Site A| / | | +---+ \ | Hub Site |T1 #1=|=============|P|=| R | +---+ +-+ +-----+ \ | +------+ | | ^ \ |E| | |===| | | |=|\ /| \ v | | +------+ | /\+-+ +---+ | | | | | \ / |========|=T1 #1| Physical T1s / | R |=|P| | S | / | | +------+ | / +-+ +---+ | | |E| | / \ |========|=T1 #2| |Site B| v \ |P| | R |===| | | |=|/ \| \ | | |T1 #2=|=============|E|=| | +---+ +-+ +-----+ / +------+ | | \ | | +---+ __ / +------+ \ +-+ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 2: T1 Transport Emulation Example Diagram 2.2 Example 2 - T1 Access Figure 3 below shows a pair of T1s being carried over a TDM/SONET network. This example differs from the previous one in that the signal format differs between the ingress and egress nodes. Note that Figure 3 is also applicable for E1, E3 and DS3 access. 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 3: T1 Access Example Diagram Figure 4 below shows the same pair of T1s being carried over a packet network, again using the VT encapsulation defined in Section 4 of this draft. As with the previous example, the emulation, Pate et. al. Expires - February 2003 [Page 6]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 routing and/or SONET functions could be combined in the same device. Such combinations are likely, so the VT encapsulation format defined in this draft facilitates implementation of such applications and devices. SONET/TDM/Packet Network ____ ___ ____ _/ \___/ \ _/ \__ +------+ Physical /+-+ \__/ \_ |Site A| T1 / | | +---+ \ Hub Site |T1 #1=|=============|P|=| R | +---+ +-+ +-----+ \ OC12+------+ | | \ |E| | |===| | | |=|\ /| \----| | +------+ /\+-+ +---+ | | | | | \ / |========|=T1 #1| / | R |=|P| | S | / | | +------+ Physical/ +-+ +---+ | | |E| | / \ |========|=T1 #2| |Site B| T1 \ |P| | R |===| | | |=|/ \| \----| | |T1 #2=|=============|E|=| | +---+ +-+ +-----+ / +------+ | | \ | | +---+ __ / +------+ \ +-+ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 4: T1 Access Emulation Example Diagram Pate et. al. Expires - February 2003 [Page 7]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 2.3 Example 3 - Fractional SONET Transport Figure 5 below shows an example of fractional SONET transport. OC3 #1 and OC3 #2 are both channelized and are partially equipped. SONET Network ____ ___ ____ _/ \___/ \ _/ \__ +------+ Physical / \__/ \ |Site A| OC3 / +---+ OC3 \ Hub Site |OC3#1=|=================|\S/|-------------+-----+ \ OC12+------+ | | \ |/ \|=============|\ /| \----| | +------+ /\ +---+-------------| \ / |========|=OC3#1| / | S | / | | +------+ Physical/ +---+-------------| / \ |========|=OC3#2| |Site B| OC3 \ |\S/|=============|/ \| \----| | |OC3#2=|=================|/ \|-------------+-----+ / +------+ | | \ +---+ OC3 __ / +------+ \ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 5: Fractional SONET Transport Example Diagram Figure 6 below shows the same pair of OC3s being emulated over a PSN using the fractional STS mapping defined in Section 5 of this draft. Note that the PWE3 emulation device is not acting as Path Terminating Equipment (PTE) and should preserve the path BIP and OAM functions. SONET/TDM/Packet Network ____ ___ ____ _/ \___/ \ _/ \__ +------+ Physical / \__/ \ |Site A| OC3 / +---+ OC3 \ Hub Site |OC3#1=|=============|P|=| R | +---+ +-+ +-----+ \ OC12+------+ | | \ |E| | |===| | | |=|\ /| \----| | +------+ /\+-+ +---+ | | | | | \ / |========|=OC3#1| / | R |=|P| | S | / | | +------+ Physical/ +-+ +---+ | | |E| | / \ |========|=OC3#2| |Site B| OC3 \ |P| | R |===| | | |=|/ \| \----| | |OC3#2=|=============|E|=| | +---+ +-+ +-----+ / +------+ | | \ | | +---+ __ / +------+ \ +-+ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 6: Fractional SONET Transport Emulation Example Diagram Pate et. al. Expires - February 2003 [Page 8]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 2.4 Example 4 - SONET Interconnect Figure 7 below shows an example of SONET interconnect. As with the previous example, OC3 #1 and OC3 #2 are both channelized and are partially equipped. However, the VTs in OC3 #1 and OC3 #2 are groomed into OC3 #3. The right hand SONET ADM is acting as PTE, and the path BIP and OAM functions are terminated. SONET Network ____ ___ ____ _/ \___/ \ _/ \__ +------+ Physical / \__/ \ |Site A| OC3 / +---+ OC3 \ Hub Site |OC3#1=|=================|\S/|-------------+-----+ \ +------+ | | \ |/ \|=============|\ /| \ | | +------+ /\ +---+-------------| \ / | / | | / | S |========|=OC3#3| +------+ Physical/ +---+-------------| / \ | \ | | |Site B| OC3 \ |\S/|=============|/ \| \ | | |OC3#2=|=================|/ \|-------------+-----+ / +------+ | | \ +---+ OC3 __ / +------+ \ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 7: SONET Interconnect Example Diagram Figure 8 below shows the same pair of OC3s being emulated over a PSN, again using the fractional STS mapping defined in Section 5 of this draft. SONET/TDM/Packet Network ____ ___ ____ _/ \___/ \ _/ \__ +------+ Physical /+-+ \__/ \_ |Site A| OC3 / | | +---+ \ Hub Site |OC3#1=|=============|P|=| R | +---+ +-+ +-----+ \ +------+ | | \ |E| | |===| | | |=|\ /| \ | | +------+ /\+-+ +---+ | | | | | \ / | / | | / | R |=|P| | S |========|=OC3#3| +------+ Physical/ +-+ +---+ | | |E| | / \ | \ | | |Site B| OC3 \ |P| | R |===| | | |=|/ \| \ | | |OC3#2=|=============|E|=| | +---+ +-+ +-----+ / +------+ | | \ | | +---+ __ / +------+ \ +-+ __/ \ / \ ___ ___ / \_/ \_/ \____/ \___/ Figure 8: SONET Interconnect Emulation Example Diagram Pate et. al. Expires - February 2003 [Page 9]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 3. Encapsulation Overview 3.1 Packet Format Section 5 of [CEP-SPE] 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 9 below. +---------------------------------------------+ | PSN and Multiplexing Layer Headers | | IPv4, IPv6, MPLS | +---------------------------------------------+ | RTP Header | +---------------------------------------------+ | CEP Header (CEP-SPE) | +---------------------------------------------+ | Extended Fractional STS-1/VC-3/VC-4 Header | | (optional) | +---------------------------------------------+ | | | TDM Data | | | +---------------------------------------------+ Figure 9: TDM CEP Packet Format The RTP header may be suppressed to conserve network bandwidth [CEP-SPE]. The formats of the "Extended Fractional STS-1/VC-3/VC-4 Header" and "TDM Data" are described in the following sections. 3.2 Payload Formats This document builds upon the existing standards for its definitions of 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 [CEP- SPE] to carry the tributary TDM signals. SONET terminology is mostly used throughout this document. SDH equivalent terms are indicated. All SONET discussions are Pate et. al. Expires - February 2003 [Page 10]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 applicable for SDH terminology as well. Section 8 describes the fractional VC-4 encapsulation that is SDH specific. The encapsulations described in this document use SONET/SDH containers to carry TDM signals. Three formats are defined in this document: - The VT encapsulation maps a single T1, E1, DS1C or DS2 into a VT and then into packets. - The fractional STS-1 (VC3) encapsulation defined herein can carry any number of VTs up to the maximal allowed within a single STS-1. - A DS3 is encapsulated within an STS-1 (VC3) container and sent over an STS-1 emulated circuit. Optionally, fixed byte columns are removed providing 7% bandwidth saving. - An E3 signal is encapsulated within an STS-1 (VC3) container and sent over an STS-1 emulated circuit. Optionally, fixed byte columns are removed providing 28% bandwidth saving. - The fractional SDH VC-4 encapsulation defined herein can carry any number of VC-3, VC-11, VC-12 and VC-2 up to the maximal allowed within a single VC-4. These encapsulations are described in more detail in the following sections. Pate et. al. Expires - February 2003 [Page 11]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 4. VT Encapsulation The VT encapsulation carries a single SONET VT1.5 (T1), VT2 (E2), VT3 or VT6 or their SDH equivalents VC-11, VC-12 and VC-2 circuit. The VT encapsulation extends [CEP-SPE] providing sub-STS-1 circuit emulation. Together, they provide circuit emulation for the entire SONET/SDH hierarchy. E1 or T1 signal may be carried either in byte-synchronous mapping or asynchronous mapping. Byte-synchronous mode is typically used for applications that require DS0 access for voice switching, CCS and fractional data transfer (e.g. for Frame Relay). Byte- synchronous mapping may require that a framer is available at the T1 or E1 connection point. A framer is needed for performance monitoring on the incoming signal, loopback commands detection and extracting and insertion of the CCS signaling for T1 within the overheads bytes. In this case the T1 or E1 signals MAY be mapped using the byte-synchronous mode as defined in section 3.4.1.1 in [GR253]. If transparent transmission of the data and clock signals is required, without changing the framing patterns, bit- asynchronous mapping is used as defined in section 3.4.1.2 in [GR253]. Bit-asynchronous mapping does not require a framer at the T1 connection point. 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 VT encapsulation does not carry the overhead bytes V1-V4 within the payload, but rather maps the relevant information into the CEP pointer and N/P indications. The CEP pointer indicates the position of the V5 byte within the payload. Pate et. al. Expires - February 2003 [Page 12]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 Figure 10 below indicates the number of bytes occupied by a VT within a multi-frame. Mapping Bytes per Multi-frame Reference ------------------------------------------------------------- VT1.5/VC-11 108 bytes [GR253] Section 3.4.1.1 VT2/VC-12 144 bytes [G.707] Section 10.1.4.1 VT3 216 bytes [GR253] Section 3.4.1.3 VT6/VC-2 432 bytes [GR253] Section 3.4.1.4 Figure 10: Number of Bytes in a Multi-Frame 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 104 bytes of payload (leaving out V1-V4). Implementation MUST support payload sizes corresponding to a single frame, and SHOULD support payload sizes corresponding to two frames or a complete super-frame. 4.2 VT Header The basic VT CEP header is defined in Figure 11 per Section 4 of [CEP-SPE]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Basic VT CEP Header Format The following fields are used within the header: - E: Extension bit. The E bit indicates whether the extended header (to be defined in future revision of [CEP-SPE]) is used. E=0: indicates that extended header is not used. E=1: indicates that extended header is carried within the packet. - R bit: RDI indication. The RDI indication is sent whenever a Pate et. al. Expires - February 2003 [Page 13]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 remote defect indication needs to be sent to the PW far side. See [CEP-SPE] for more details. - D bit: Support for DBA mode for unequipped and AIS indication payload. See Section 9.5 below for more details. - N/P bits: 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. - Structure pointer: 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. Pate et. al. Expires - February 2003 [Page 14]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 5. Fractional STS-1 (VC-3) Encapsulation An example of VT1.5 mapping into an STS-1 SPE is shown in Figure 12 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 12: 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. The fractional STS-1 encapsulation carries VTs within an STS-1 container. This format is suitable for applications such as those shown in Figures 6 and 8, i.e. as either to compress STS-1 container containing VTs or to carry multiple PDH signals efficiently from a PE to a SONET MUX.. 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, giving the ability to be used as a compressed version of the STS-1 encapsulation defined in [CEP-SPE]. Pate et. al. Expires - February 2003 [Page 15]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 The fractional STS-1 encapsulation can optionally carry a bit mask that specifies which VTs are 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. The use of bit mask enables "on the fly" compression, whereby only equipped VTs (carrying actual data) are sent. This compression saves bandwidth in the PSN. 5.1 Fractional STS-1 Payload Format Figure 13 below shows a mapping of 3 VT1.5s, designated 1-1, 2-1 and 3-1. 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 13: Fractional SPE Mapping of VT1.5 Note that the fixed stuffs shown in Figure 12 are not sent when using this mode. Also note that Figure 13 shows the bytes from the VTs interleaved, as with the SONET SPE shown in Figure 12. 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 1. The "fractional" SPE in Figure 13 could be expanded out to a full SPE by the addition of "dummy" VTs, fixed stuff columns and updating the B3 POH byte. Pate et. al. Expires - February 2003 [Page 16]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 5.2 Fractional STS-1 CEP header The fractional STS-1 CEP header uses the STS-1 CEP header encapsulation as defined in [CEP-SPE]. Optionally, an additional 4 byte header extension word is added. The extended header is described in Figure 14. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Extended Fractional STS-1 Header The following fields are used within the extended header: - R, D, N, P, Structured Pointer and Sequence Number: All fields are used as defined in [CEP-SPE] for STS-1 encapsulation. - E: Extension bit. E=0: indicates that extended header is not used. E=1: indicates that extended header is carried within the packet. The E bit in the first word is set to 1 to indicate use of the Equipped Bit Mask (EBM). The E bit in the second word indicates whether the extended header (to be defined in future revision of [CEP-SPE]) is used. - EBM: Each bit within the bit mask refers to a different VT within the STS-1 container. A bit set to 1 indicates that the corresponding VT is equipped, hence carried within the fractional STS-1 payload. Pate et. al. Expires - February 2003 [Page 17]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 The format of the EBM is defined in Figure 15. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTG7 | VTG6 | VTG5 | VTG4 | VTG3 | VTG2 | VTG1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Equipped Bit Mask (EBM) for fractional STS-1 The 28 bits of the EBM are divided into groups of 4 bits, each corresponding to a different VTG within the STS container. All 4 bits are used to indicate whether VT1.5 (T1) tributaries are carried within a VTG. The first 3 bits read from right to left are used to indicate whether VT2 (E1) tributaries are carried within a VTG. For example, the EBM of a fully occupied STS-1 with VT1.5 is all ones, while that of an STS-1 fully occupied with VT2 (E1) tributaries has the binary value 0111011101110111011101110111. 5.3 BIP The B3 byte within the POH indicates the bit-wise parity of the payload. Case 1: Path Terminating Equipment (PTE) In some applications the Path is terminated at the PE, and some PEs may integrate many fractional STS-1s into one STS-1. Figure 8 shows an example of PTE, where a PE is using a fractional STS-1 to carry TDM signals between the ingress and egress emulation edges. In these cases B3 is re-generated at the concentrating PE toward the SONET equipment, and B3 is calculated as the payload is sent, including VTs and POH bytes. Case 2: Non-PTE In some applications the Path is not terminated at the PE. For example, the PEs in Figure 6 are using a fractional STS-1 to carry a partially-equipped STS-1, and are not acting as PTEs. In this case the B3 value should be modified to reflect the removal of the unequipped VTs. Pate et. al. Expires - February 2003 [Page 18]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 Since the BIP-8 value in a given frame reflects the parity check over the previous frame, the changes made to BIP-8 bits in the previous frame shall also be considered in the compensation of BIP- 8 in the current frame. Therefore the following equation shall be used for compensation of the individual bits of the BIP-8: B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B*3[i](t-1) Where: B3[i] = the existing B3[i] value in the incoming signal B3[i]' = the new (compensated) B3[i] value. B3*[i] = the B3[i] value of the unequipped VT(VC)s in the incoming signal || = exclusive OR operator. t = the time of the current frame. t-1 = the time of the previous frame. The egress PE MUST reconstruct the unequipped VTs and modify the B3 parity value in the same manner to accommodate for the additional VTs added. In this way the end-to-end BIP is preserved. Pate et. al. Expires - February 2003 [Page 19]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 6. DS3 Encapsulation A DS3 is encapsulated asynchronously into an STS-1 SPE using the format defined in section 3.4.2.1 of [GR253]. The STS-1 SPE is then encapsulated as defined in Section 4 of [CEP-SPE]. 1 2 3 * * * 29 30 31 32 * * * 58 59 60 61 * * * 87 +--+--+--+-----------+--+--+--------------+--+--+-------------+ 1 |J1|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 2 |B3|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 3 |C2|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 4 |G1|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 5 |F2|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 6 |H4|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 7 |Z3|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 8 |Z4|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ 9 |Z5|R |R | |R |R | |R |R | | | | +--+--+--+-----------+--+--+--------------+--+--+-------------+ R - Fixed byte Figure 16: Fixed Columns in DS3 Mapping Optionally, the STS-1 (VC3) SPE can be compressed by removing fixed columns leaving only data columns. The fixed columns in the DS3 mapping to STS-1 (VC3) are denoted by the letter R in figure 16. Bandwidth saving is approximately 7% (6 columns out of 87). The B3 parity byte need not be modified as the parity of the fixed columns amounts to zero. Pate et. al. Expires - February 2003 [Page 20]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 7. E3 Encapsulation An E3 is encapsulated asynchronously into a VC-3 SPE using the format defined in section 10.1.2.2 of [G.707]. The VC-3 SPE is then encapsulated as defined in [CEP-SPE]. Optionally, the VC3 SPE can be compressed by removing the fixed columns leaving only data columns. VC-3 columns are numbered 1 to 85 (and not 87), starting from the POH column numbered 1. The following columns have fixed values and are removed: 2, 6, 10, 14, 18, 19, 23, 27, 31, 35, 39, 44, 48, 52, 56, 60, 61, 65, 69, 73, 77, 81 Figure 17: Fixed columns removed within E3 mapping to VC-3 Bandwidth saving is approximately 28% (24 columns out of 87). The B3 parity byte need not be modified as the parity of the fixed columns amounts to zero. Pate et. al. Expires - February 2003 [Page 21]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 8. Fractional VC-4 Encapsulation SDH defines a mapping of VC-11, VC-12, VC-2 and VC-3 directly into VC-4. This mapping does not have an equivalent within the SONET hierarchy. The VC-4 mapping is common in SDH implementations. VC-4 <--x3-- TUG-3 <----x1-------- TU-3 <---- VC-3 >---- E3/T3 | +--x7-- TUG-2 <--x1- TU-2 <-- VC-2 <---- DS-2 | +----x3---- TU-12 <-- VC-12<---- E1 | +----x4---- TU-11 <-- VC-11<---- T1 Figure 18: Mapping of VCs into VC-4 Figure 18 describes the mappings of VC-11, VC-12, VC-2 and VC-3 into VC-4. T1 signals are mapped to VC-11. 4 VC-11s are byte interleaved into a TUG-2, which is the equivalent to a SONET VTG. Similarly 3 E1 signals are mapped to VC-12 and byte interleaved within a TUG-2. 7 TUG-2s are interleaved within an AUG-3. 3 TUG-3 are byte interleaved within the VC-4 container. Possible configuration of VC-4 include therefore: 3 VC-3s, 1 VC-3 and 42 VC-12s, 63 VC-12s, etc. The VC-4 container includes the path overhead bytes, and the normal SONET/SDH encapsulation is used. The additional benefit in using the fractional VC-4 encapsulation is that it does not require sending any unused VCs, giving the ability to be used as a compressed version of the VC-4 encapsulation defined in [CEP-SPE]. The fractional VC-4 encapsulation can optionally carry a bit mask that specifies which VCs are carried within the VC-4 payload and which VCs have been removed. This optional bit mask attribute allows the ingress circuit emulation node to remove an unequipped VCs on the fly, providing the egress circuit emulation node enough information for reconstructing the VCs in the right order. The use of bit mask enables "on the fly" compression, whereby only equipped VCs (carrying actual data) are sent. This compression saves bandwidth in the PSN. The fractional VC-4 carries VC-3 in compressed mode, as defined in sections 6 and 7, saving up to 28% bandwidth. Pate et. al. Expires - February 2003 [Page 22]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 8.1 Fractional VC-4 Mapping [G.707] defines the mapping of TUG-3 to a VC-4 in section 7.2.1. Each TUG-3 includes 86 columns. TUG-3#1, TUG-3#2 and TUG-3#3 are byte multiplexed, starting from column 4. Column 1 is the VC-4 POH, while columns 2 and 3 are fixed, and therefore removed within the fractional VC-4 encapsulation. The mapping of TU-3 into TUG-3 is defined in section 7.2.2 of [G.707]. The TU-3 consists of the VC-3 with a 9-byte VC-3 POH and the TU-3 pointer. The first column of the 9-row by 86-column TUG-3 is allocated to the TU-3 pointer (bytes H1, H2, H3) and fixed stuff. The phase of the VC-3 with respect to the TUG-3 is indicated by the TU-3 pointer. The mapping of TUG-2 into TUG-3 is defined in section 7.2.3 of [G707]. The first two columns of the TUG-3 are fixed and therefore removed in the fractional VC-4 encapsulation. The 7 TUG-2, each 12 columns wide, are byte multiplexed starting from column 3 of the AUG-3. This is the equivalent of multiplexing 7 VTGs within STS-1 container in SONET terminology, except for the location of the fixed columns. The static fractional VC-4 mapping assumes that both the ingress and egress nodes are preconfigured with the set of equipped VCs carried within the fractional VC-4 encapsulation. The ingress emulation edge removes the fixed columns as well as columns of the VCs agreed upon by the two edges, and updates the B3 VC-4 byte. The egress side adds the fixed columns and the unequipped VCs and updates B3. Pate et. al. Expires - February 2003 [Page 23]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 8.2 Fractional VC-4 CEP Header The fractional VC-4 CEP header uses the VC-4 CEP header encapsulation defined Section 4 in [CEP-SPE]. Optionally, an additional 12 byte header extension word is added. The extended header is described in Figure 19. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|0| Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: Extended Fractional VC-4 Header The following fields are used within the extended header: - R, D, N, P, Structured Pointer and Sequence Number: All fields are used as defined in [CEP-SPE] for VC-4 encapsulation. - E: Extension bit. E=0: indicates that extended header is not used. E=1: indicates that extended header is carried within the packet. The E bit in the first word is set to 1 to indicate use of the Equipped Bit Mask (EBM). The E bit in the forth word indicates whether the extended header (to be defined in future revision of [CEP-SPE]) is used. The MSB bit of word two and three is always set to 1 to indicate that header is extended. Pate et. al. Expires - February 2003 [Page 24]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 - EBM: The Equipped Bit Mask indicate which tributaries are carried within the fractional VC-4 payload. Three EBM fields are used. Each EBM field corresponds to a different AUG-3 within the VC-4. The EBM includes 7 groups of 4 bits per TUG-2. A bit set to 1 indicates that the corresponding VC is equipped, hence carried within the fractional VC-4 payload. Additional 2 bit within the EBM indicates whether VC-3 carried within the TUG-3 is equipped and whether it is in AIS mode. The format of the EBM for fractional VC-4 is defined corresponding to one of the TUG-3 is defined in Figure 20. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|T|TUG2#7 |TUG2#6 |TUG2#5 |TUG2#4 |TUG2#3 |TUG2#2 |TUG2#1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: Equipped Bit Mask (EBM) for fractional VC-4 The 30 bits of the EBM are divided into two bits that control the VC-3 within the TUG-3 and 7 groups of 4 bits, each corresponding to a different TUG-2 within the TUG-3 container. For a TUG-3 containing TUG-2, the first two A and T bits MUST be set to zero. The TUG-2 bits indicate whether the VCs within the TUG-2 are equipped. All 4 bits are used to indicate whether VC11 (T1) tributaries are carried within a TUG-2. The first 3 bits read right to left are used to indicate whether VC12 (E1) tributaries are carried within a TUG-2. The first bit is used to indicate a VC- 2 is carried within a TUG-2. For example, 28 bits of the EBM of a fully occupied TUG-3 with VC11 is all ones, while that of a TUG-3 fully occupied with VC12 (E1) tributaries has the binary value 0111011101110111011101110111. Pate et. al. Expires - February 2003 [Page 25]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 For a TUG-3 containing VC-3, all TUG-2 bits MUST be set to zero. The A and T bits are defined as follows: T : TUG-3 carried bit. If set to 1, the VC-3 payload is carried within the TUG-3 container. If set to 0, all the TUG-3 columns are not carried within the fractional VC-4 encapsulation. The TUG-3 columns are removed either because the VC-3 is unequipped or in AIS mode. A: VC-3 AIS bit. The A bit MUST be set to 0 when the T bit is 1 (i.e. when the TUG-3 columns are carried within the fractional VC-4 encapsulation). The A bit indicate the reason for removal of the entire TUG-3 columns. If set to 0, the TUG-3 columns were removed because the VC-3 is unequipped. If set to 1, the TUG-3 columns were removed because the VC-3 is in AIS mode. 8.3 BIP The VC-4 BIP needs to be recalculated to compensate for the removal of unequipped VCs. The same compensation as described in section 5.3 is applicable in the fractional VC-4 encapsulation as well. Pate et. al. Expires - February 2003 [Page 26]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 9. Operational Considerations 9.1 Payload Size Payload sizes are statically provisioned for each TDM stream as described in [CEP-SPE], using the same management information base [MIB]. CEP packets are normally fixed in length for all of the packets of a particular emulated TDM stream. The exceptions are DBA CEP packets and on the fly compression within the fractional STS-1 mode. When the fractional STS-1 encapsulation does not carry the equipped flag indications, the VTs to be transmitted MUST be statically provisioned at both ends. The static EBM provisioned at the egress must equal in the number of VTs equipped at the ingress, but the actual VT positions could vary. The length of each CEP packet does not need to be carried in the CEP header because it can be uniquely determined for each CEP packet as a function of the provisioned payload size, the type of VTs carried within the STS-1 signal, the DBA indication and the equipped flags (either dynamically or statically provisioned). Only the following payload lengths can be statically provisioned for fractional STS-1 encapsulations: 1. Full SPE length (783 bytes) 2. Third of SPE length (261 bytes) An implementation MUST support at least the full SPE length. Pate et. al. Expires - February 2003 [Page 27]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 The actual payload sizes would be smaller, depending on the number of virtual tributaries carried within the fractional SPE. Figure 21 provides the actual payload length as a function of N, the number of tributaries carried within the fractional STS-1. In particular, when all VTs are equipped, the fractional STS-1 full SPE payload size is 765 bytes. VT Type Full SPE SPE/3 ---------------------------------------------- VT1.5 (T1) 27*N+9 9*N+3 N=0..28 VT2 (E1) 36*N+9 12*N+3 N=0..21 Figure 21: Fractional STS-1 Actual Payload Size Only the following payload lengths can be statically provisioned for fractional VC-4 encapsulation: 1. Full SPE length (2349 bytes) 2. 8/9 SPE length (2088 bytes) 3. 7/9 SPE length (1827 bytes) 4. 6/9 SPE length (1566 bytes) 5. 5/9 SPE length (1305 bytes) 6. 4/9 SPE length (1044 bytes) 7. 1/3 SPE length (783 bytes) The actual payload sizes would be smaller, depending on the number of virtual tributaries carried within the fractional SPE. Each equipped VC contributes the following number of bytes per SPE: Each VC-11 contributes 27 bytes Each VC-12 contributes 36 bytes Each VC-2 contributes 108 bytes Each VC-3(DS-3) contributes 738 bytes (including pointers) Each VC-3(E-3) contributes 576 bytes (including pointers) Figure 22: Fractional VC-4 Actual Payload Size For example, the payload size of a fractional VC-4 configured to third SPE encapsulation that carries a single T3 VC-3 and 6 VC-12s would be: 9 (VC-4 POH) + 6 * 36 + 738 / 3 = 221 bytes payload per each packet. Pate et. al. Expires - February 2003 [Page 28]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 9.2 Operational Modes Figure 23 defines the various options for PW encapsulations and user interfaces physical connections, described in this document. +---------+----------------+----------------------+ | Mode # |User Interface | PW Encapsulation | +---------+----------------+----------------------+ | 1 * | T1/E1 | VT | | 2 | T1/E1 |Fractional STS-1/VC-3 | | 3 | T1/E1 |Fractional VC-4 | | 4 * | T3/E3 | STS-1/VC-3 | | 5 | T3/E3 |Fractional VC-4 | | 6 | STS-1/VC-3 | VT | | 7 * | STS-1/VC-3 |Fractional STS-1/VC-3 | | 8 | VC-4 | VC-11/VC-12/VC-2 | | 9 | VC-4 | VC-3 | | 10 * | VC-4 |Fractional VC-4 | +---------+----------------+----------------------+ * Most common uses. Figure 23: PW Encapsulations Related to User Interfaces 9.3 Timing This section provides clarifications about the EPAR operation and its applicability to this document in the various modes defined above. The term REFCLK is used to indicate the local PE node system clock that is synchronized via the network timing distribution to the source clock feeding the peer PE system clock. Mode #1 : The VT framing timing is based on the REFCLK. If asynchronous mode is used, there is no use of pointer adjustments on the CEP VT header, and timing differences between the incoming T1 signal and REFCLCK are accommodated by the use of stuffing bits as defined in [GR253]. If byte-synchronous mode is used, the timing difference is accommodated by the use of pointer adjustments indication on the VT CEP header. Mode #2 : The signal is first mapped to a VT as defined in [GR253], which than maps into fractional STS-1. The pointers at the CEP level are fixed. Mode #3 operates similarly. Mode #4 : The STS-1 framing timing is based on the Pate et. al. Expires - February 2003 [Page 29]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 REFCLK. There is no use of pointer adjustments on the CEP STS-1 header, and timing differences between the incoming T1 signal and REFCLCK are accommodated by the use of stuffing bits as defined in [GR253][G707] Mode #5 : The signal is first mapped to a VC-3 as defined in [G707], which than maps into fractional VC-4. The pointers at the CEP level are fixed. Mode #6 : Relative pointer adjustments of the incoming STS to REFCLCK are added to the VT to STS pointer adjustments and played on the VT CEP header as defined in [CEP-SPE]. Modes #8 and #9 operate similarly Mode #7,10 : Same as in [CEP-SPE]. Notes: 1) In mode #1 the originator of the PW is not known to be operating in mode #1 or mode #6, so the receiver may need to accommodate both stuffing bits and CEP VT pointer adjustments. 2) If one STS-1 is created from multiple sources, the timing of the generated STS-1 toward the user is typically based on the local REFCLCK. In this case each VT's pointer bytes should be played to reflect the pointer adjustments on the incoming CEP header + the VT itself V1-V4 pointer adjustments (if they exist on the incoming encapsulation). Each pointer justification in [CEP-SPE] is indicated by 3 consecutive CEP headers marking. The same procedure is used for the fractional STS-1/VC-3/VC-4 encapsulation. For VT encapsulation, pointer justification events are indicated only on the packet(s) that carry the justified multi-frame. 9.4 Performance Monitoring [CEP-SPE] defines CEP level Errored Seconds (ES), Severely Errored Seconds (SES) and handling and reporting of CEP defects and failures. The same functionality is applicable here for both the fractional STS encapsulation and the VT encapsulation. 9.5 DBA Operation Dynamic Bandwidth Allocation (DBA) is an optional mode defined in [CEP-SPE] for dynamically reducing the bandwidth utilized by emulated SONET/SDH circuits when the circuit is in AIS-P or UNEQ-P Pate et. al. Expires - February 2003 [Page 30]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 status. The procedures defined in [CEP-SPE] hold for the fractional STS-1/VC-3/VC-4 encapsulation. DBA mode is extended in this draft for the VT encapsulation when the circuit is in AIS-V or UNEQ-V status. If a PW was set up but an association to a user interface is not yet available, or the PW is in an administrative down state, then the relevant UNEQ indication MUST be sent toward the PSN. 9.6 Missing Packet In the case of a missing packet, all ones should be inserted instead of the missing bytes at the output signal. The only exception is where a single STS-1 is fed by multiple PWs. In this case the output POH is generated normally as this PE is PTE, and the all ones should be generated for the affected VTs only. 9.7 Packet Length Considerations While the MTU introduced in this document is not an issue for packet networks (783 bytes for fully equipped STS-1 + PW + PSN header), some networks may have minimum packet length requirements. The following is defined to handle these cases: a. DBA operation: As specified in [CEP-SPE], the DBA packet may be an arbitrary length. This length may be configured at the PW ingress side to handle minimum packet length requirements. The PW egress ignores the DBA packet length (i.e. does not consider it as length error), eliminating the need to negotiate the DBA length. PW edges SHOULD support the ability to set the DBA packet length to accommodate minimum packet length requirements. b. VT encapsulation: Selection of the packet length should be done based on the PSN minimum packet length requirement. c. Fractional STS-1/VC-3/VC-4: PW ingress SHOULD have the option to be configured to add padding to the PW packet if the packet is less than the minimum packet requirement. At egress, the PE can calculate the number of payload byte using the procedures defined in Section 9.1. The PE MUST ignore the additional padding bytes and should not consider padding bytes as length errors. 9.8 Session Multiplexing Session multiplexing is described in [CEP-SPE]. Pate et. al. Expires - February 2003 [Page 31]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 10. Security Considerations This document is an extension of [CEP-SPE]. No additional security issues are introduced in this document. 11. Appendix A: NSP Functions Native Service Processing (NSP) is defined in [PWE3-LAYERS] to be the processing of the data received by the PE from the CE before presentation to the PW for transmission across the core. 11.1 Time Slot Assignment (TSA) For an application like that shown in Figure 8, 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 VT on the egress side. The PE MAY allow the operator to configure the assignment of Time Slots at each end of the PW. 11.2 PDH Loopbacks Figure 24 below shows a T1 being delivered to a customer site. The nomenclature at the top of the figure is that used in Figure 7 of [T1.403]. NT2 NT1 Network DSU CSU Interface +-------+-+ +-------------+ | | |F| | | | | /->|r|=========>|---\ /-->|======>|====> | | |a| Physical | | | | | | | |m| T1 | | | | | | \--|e|<=========|<--/ \---|<======|<==== | |r| | | | +-------+-+ +-------------+ Payload CI/CSU Line Loopback Loopback Loopback Figure 24: T1 Loopback Example Note there are two types of loopback commands: - Inband patterns as defined in Section 9.4.1 of [T1.403]. This type of loopback command was originally defined for voice equipment, and it often causes problems when used with data systems. Processing of inband loopbacks is usually disabled in newer equipment and applications and SHOULD NOT be implemented in a PE. Pate et. al. Expires - February 2003 [Page 32]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 - FDL messages that carry loopback commands as defined in Section 9.4.2 of [T1.403]. Support of these messages requires the use of a framer. Depending on the application, it may be desirable to process loopback messages and inband codes. The relevant considerations are: - Whether the PE implements a CSU functionality. If not, the appropriate hardware may not be present to implement the loopbacks. - What administrative domains are involved. A carrier will not want a customer to send commands that can interfere with network operation. - Whether the T1 service is structured or unstructured. Processing of FDL loopback commands requires the use of a framer. Whenever loopback processing is supported, there MUST be a means to disable such processing. The following examples point out when it may be appropriate to process loopback commands. 1) Neither End of T1 is in Carrier's Administrative Domain A network like that shown in Figure 2 may be providing T1 transport. In this case, the carrier may not wish to generate or process any loopback messages. 2) One End of T1 is in Carrier's Administrative Domain Consider the left-hand PEs in Figure 4. These PEs are within the administrative domain of the carrier. If these PEs are implementing the CSU functionality, then it would be desirable for these PEs to process loopback messages originating from within the carrier's network e.g. from the ADM on the right side. 11.3 PDH Performance Processing and Reports [T1.403] defines a Network Performance Report Message (NPRM) and a supplementary Performance Report Message (SPRM). These messages are 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. Many framers automatically generate and send these reports. Pate et. al. Expires - February 2003 [Page 33]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 11.4 Alarms and Failure Propagation This section discuss propagation of alarms and failure conditions between PDH line and the PW. [GR253] and [G707] defines procedures for propogation of alarms and failure conditions between PDH line and SONET circuits. These procedures MUST be followed. In particular: PW Ingress: T1/E1 is propagated transparently inside the VT. Physical layer defects are propagated as T1/E1 AIS inside the VT. PW Egress: AIS-V or UNEQ-V indications are played out as T1/E1 AIS on the user interface. PW Ingress: T3/E3 is propagated transparently inside the STS-1/VC-3. Physical layer defects are propagated as T3/E3 AIS inside the STS-1/VC-3. PW Egress: AIS-P or UNEQ-P indications are played out as T3/E3 AIS on the user interface. The procedures below MAY be implemented when a VT encapsulation for is used on the PW to conserve BW for AIS and UNEQ states. PW Ingress: T1/E1 AIS or T1/E1 physical layer defects are propagated as VT AIS DBA. The procedures below MAY be implemented when an STS-1 encapsulation for is used on the PW to conserve BW for AIS and UNEQ states. PW Ingress: T3/E3 AIS or T3/E3 physical layer defects are propagated as STS-1/VC-3 AIS DBA. Pate et. al. Expires - February 2003 [Page 34]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 12. Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. Lycium Networks has filed one or more patent applications that may be related to the CEP technology outlined in this document. Lycium Networks grants free unlimited licenses for use of this technology. 13. Acknowledgments The authors wish to acknowledge the comments and input received from Ashwin Moranganti, Chuck Lee and Sasha Vainshtein. 14. References [TDM-APP] Cohen et al, "Applicability statement for edge to edge emulation of Time Division Multiplexing (TDM) services over Packet Switched Networks (PSN)", draft-cohen-pwe3-tdmsonetapp-00.txt, work in progress, June 2002. [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. [PWE3-REQ] Xiao et al, "Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)" (draft-pwe3-requirements-02.txt), work in progress, November 2001. [PWE3-FW] Pate et al, "Framework for Pseudo-Wire Emulation Edge-to-Edge (PWE3)" (draft-ietf-pwe3-framework-01.txt), work in progress, June 2002. [CEP-SPE] Malis et al, "SONET/SDH Circuit Emulation over Packet (CEP)" (draft-malis-pwe3-sonet-01.txt), work in progress, November 2001. [MIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over PSN (CEP) Management Information Base Using SMIv2", draft-danenberg-pw-cem-mib-02.txt, work in progress, May 2002. Pate et. al. Expires - February 2003 [Page 35]
Internet draft draft-ietf-pwe3-sonet-vt-00.txt August 2002 15. Author's Addresses Prayson Pate Overture Networks P.O.Box 14864 Phone: +1-919-5582200 RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Ron Cohen Lycium Networks 9 Hamanofim St. Phone: +972-9-971-7794 Herzelia 46733, Israel Email: ronc@lyciumnetworks.com David Zelig Corrigent Systems LTD. 126, Yigal Alon st. Phone: +972-3-6945273 Tel Aviv, Israel Email: davidz@corrigent.com 16. Full Copyright Section Copyright (C) The Internet Society (2002). 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 - February 2003 [Page 36]