Internet Draft Prayson Pate Document: draft-pate-pwe3-tdm-00.txt Overture Networks Expires: March 10, 2001 Ron Cohen Lycium Networks David Zelig Corrigent Systems TDM Service Specification for Pseudo-Wire Emulation Edge-to-Edge (PWE3) draft-pate-pwe3-tdm-00.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-00 September 10, 2001 Table of Contents 1 Introduction ................................................. 3 2 Example Network Diagrams ..................................... 4 3 Encapsulation Overview ....................................... 5 4 VT Encapsulation ............................................. 7 5 VTG Encapsulation ............................................ 8 6 Fractional STS-1 Encapsulation ............................... 9 7 DS3 Encapsulation ............................................ 10 8 Comparison of Encapsulations ................................. 11 9 Operational Considerations ................................... 11 10 TDM over MPLS ............................................... 14 11 TDM over IP/GRE ............................................. 14 12 TDM over L2TP ............................................... 14 13 Security Considerations ..................................... 15 14 Acknowledgments ............................................. 15 15 References .................................................. 15 16 Authors' Addresses .......................................... 16 17 Full Copyright Section ...................................... 16 Pate et al. Expires Nov. 2001 [Page 2] Internet Draft draft-pate-pwe3-tdm-00 September 10, 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. See [PATE] and [XIAO] for background, motivation and requirements concerning circuit emulation over PSNs. [MARTINI] and [JOHNSON] provide information on the very similar emulation of SONET circuits. 1.1. Goals o Definition of encapsulation for T1, E1 and T3. 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 DBA Dynamic Bandwidth Allocation - see [JOHNSON] L2TP Layer Two Tunneling Protocol LOF Loss of Frame LOS Loss of Signal NPRM Network Performance Report Message PSN Packet Switched Network POH Path Overhead PWE3 Pseudo-Wire Emulation Edge-to-Edge Pate et al. Expires Nov. 2001 [Page 3] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 RAI Remote Alarm Indication SDH Synchronous Digital Hierarchy SEoP SONET/SDH Emulation over Packet - see [JOHNSON] 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 and should be considered when creating an encapsulation format. Pate et al. Expires Nov. 2001 [Page 4] Internet Draft draft-pate-pwe3-tdm-00 September 10, 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 [JOHNSON] 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 SEoP (SONET/SDH Emulation over Packet) packet is shown in Figure 3 below. +-----------------------------------+ | PSN Header | | IPv4/IPv6, MPLS, L2TP | +-----------------------------------+ | PW Label (MARTINI) | +-----------------------------------+ | SEoP Header (JOHNSON) | +-----------------------------------+ | | | TDM Data | | | +-----------------------------------+ Figure 3: TDM SEoP Packet Format The "PSN Header" could be an IP or GRE header, MPLS label or L2TP header. See [MARTINI] and [JOHNSON] for a description of the overall structure, and see [JOHNSON] for the definitions of the SEoP Header. The format of the "TDM Data" is described in the following sections. Pate et al. Expires Nov. 2001 [Page 5] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 3.2. Overview of TDM Encapsulation SONET VT mapping into an SONET SPE is defined for T1 and T3 in [GR253]. [G.707] defines the mapping of E1s into the SDH hierarchy. 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, The encapsulations described in this document use SONET containers to carry TDM signals. Four formats are defined in this document: o The VT encapsulation maps a single T1, E1 or DS3 into a VT and then into packets. o The VTG encapsulation carries either 4 VT1.5, 3 VT2s or 2 VT3s. 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. Pate et al. Expires Nov. 2001 [Page 6] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 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. VT4 is currently unused. The structured VT mode does not carry the overhead bytes V1-V4 within the payload, but rather maps them into the SEoP pointer and N/P indications. The SEoP 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 ?? 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 Each SEoP 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 SEoP 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). Pate et al. Expires Nov. 2001 [Page 7] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 4.2. VT Header The basic VT SEoP header is defined in Figure 6 per [JOHNSON]: 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 SEoP 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 [JOHNSON] 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 SEoP 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 SEoP 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. 5. VTG Encapsulation VTG encapsulation allows carrying either 4 VT1.5s, 3 VT2s or 2 VT3s. A VT6 should be carried using a VT encapsulation as VTG encapsulation does not add any benefit. The VTs are byte interleaved within the VTG, and the SONET VTG structure is preserved. The maximal payload size corresponds to a complete multi-frame, which is 432 bytes. Only unstructured mode is supported. The flags shown in Figure 6 are redefined here to hold RDI indications for each of the VTs within the Pate et al. Expires Nov. 2001 [Page 8] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 VTG. The structured pointer higher order bits are used to carry DBA and AIS indications when all VTs within the VTG are either unequipped or in AIS mode, as shown in Figure 7. 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| R1-4 |D|A| Str. Pointer[0:10] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: VTG Header Format o R1 bit: Indicate RDI for first VT within the VTG o R2 bit: Indicate RDI for the second VT within the VTG o R3 bit: Indicate RDI for the third VT within the VTG. o R4 bit: Indicate RDI for the forth VT within the VTG o D bit: Indicate DBA mode. When set to 1 no payload is being sent. Either all VTs within the VTG are unequipped, or all VTs are sending AIS-V indications. o A bit: AIS indications, sent only if all VTs within the VTG are in AIS state. o Structure Pointer: The Structure Pointer MUST contain the offset of the V1 byte of the first VT within the VTG Fragment. A value 0 means the first byte after the SEoP header. The maximal structure pointer value is 0x1AF that corresponds to the VTG multi-frame size. The Structure Pointer MUST be set to 0x1FF if a packet does not carry the V1 byte of the first VT. 6. 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. Pate et al. Expires Nov. 2001 [Page 9] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 Figure 8 below shows a mapping of 3 VT1.5s. 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 | | | | | | | | | | | +---+ | | | | | | | | | 4 | . | | | | | | | | | | +---+ | | | | | | | | | 5 | | | | | | | | | | | +---+1-1|2-1|3-1|1-1|2-1|3-1|1-1|2-1|3-1| 6 | | | | | | | | | | | +---+ | | | | | | | | | 7 | | | | | | | | | | | +---+ | | | | | | | | | 8 | | | | | | | | | | | +---+ | | | | | | | | | 9 | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+ Figure 8: Fractional SPE Mapping of VT1.5 Note that Figure 8 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 8 could be expanded out to a full SPE by the addition of "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. 7. DS3 Encapsulation TBD. Pate et al. Expires Nov. 2001 [Page 10] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 8. Comparison of Encapsulations Figure 9 below shows a comparison of the VT mapping defined in this document with the AAL1 mapping defined in [ANAVI]. +------------------------+--------------------+---------------------+ |Category | VTx | ATM AAL1 | +------------------------+--------------------+---------------------+ |Basic Encapsulation | | | | Overhead bytes | 2 bytes per frame | 1 byte per 2 frames | | Payload bytes | 26 bytes per frame |47 bytes per 2 frames| | Efficiency | 24/26 = 92% | 47/48 = 98% | +------------------------+--------------------+---------------------+ |Total Encapsulation | | | | IP Overhead | 20 | 20 | | RTP Overhead(optional)| 4 | 6 | | PW Overhead | 4 | 6 | +------------------------+--------------------+---------------------+ |T1 frames per packet | variable | variable | +------------------------+--------------------+---------------------+ |Timing | Ext./Adaptive/RTP | Ext./Adaptive/RTP | +------------------------+--------------------+---------------------+ |Session multiplexing |yes - PW identifier | yes - UDP src. port | |Sequence number |yes - in SEoP header| yes - in RTP header | +------------------------+--------------------+---------------------+ |Structured Mode | yes | yes | |Unstructured Mode | yes | yes | +------------------------+--------------------+---------------------+ |Encapsulations defined |T1/E1/T3/OCn | T1, E1, T3 | +------------------------+--------------------+---------------------+ |PSNs supported |IP/GRE, MPLS, L2TP | IP only | +------------------------+--------------------+---------------------+ |Consistency with |Same control headers|Different headers and| |[MARTINI] and [JOHNSON] |and encapsulation |encapsulation | +------------------------+--------------------+---------------------+ |Scalability/Integration |Can be integrated |Can be integrated | | |with ubiquitous |with ATM AAL1 CES, | | |SONET infrastructure|(not widely deployed)| +------------------------+--------------------+---------------------+ |Intellectual Property |None known |RAD has IP claims | +------------------------+--------------------+---------------------+ Figure 9: Comparison of Encapsulation Methods 9. Operational Considerations 9.1. BIP If the PE sends the POH, then the path BIP8 will have to be calculated. Pate et al. Expires Nov. 2001 [Page 11] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 9.2. 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 SHOULD allow the operator to configure the assignment of Time Slots at each end of the PW. 9.3. Timing 9.3.1. External The simplest method for communicating timing from one end of a system to the other is an external timing source. This external timing source is normally a T1 or E1. This T1 or E1 could be a circuit from the CE, or the network interface into the PSN, or it could be a separate BITS clock. Its rate is extracted and used to clock the reconstructed data streams, or it is used as an input to a phase- locked loop to synthesize the desired clock. The drawback to this method is that a common external clock is not commonly available in a data network or in a multi-carrier network. 9.3.2. RTP TBD 9.4. 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. 9.5. 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. 9.6. 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 stream. Bandwidth can be saved by suppressing the AIS signal in the Pate et al. Expires Nov. 2001 [Page 12] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 emulated stream and sending instead an indication in the control overhead. [JOHNSON] 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. 9.7. Session Multiplexing Session multiplexing is accomplished by use of the PW label shown in Figure 3. 9.8. PW Maintenance TBD - this section will describe the signaling used to establish and destroy sessions, as well as any variable parameters related to encapsulation or operation. 9.8.1. PW Establishment 9.8.2. Link State Monitoring 9.8.3. Fault Detection & Recovery 9.9. Encapsulation Control 9.10. Statistics 9.11. Administrative Status 9.12. Operational Status 9.13. Management Pate et al. Expires Nov. 2001 [Page 13] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 9.14. Security 9.15. QoS Considerations 9.16. Inter-domain PW Support Consideration 10. TDM over MPLS 10.1. Packet Processing 10.2. Maintenance 10.3. Management 10.4. Security 10.5. QoS Considerations 11. TDM over IP/GRE 11.1. Packet Processing 11.2. Maintenance 11.3. Management 11.4. Security 11.5. QoS Considerations 12. TDM over L2TP 12.1. Packet Processing 12.2. Maintenance 12.3. Management 12.4. Security 12.5. QoS Considerations Pate et al. Expires Nov. 2001 [Page 14] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 13. Security Considerations TBD. 14. Acknowledgments TBD. 15. References [ANAVI] Anavi et al, "TDM over IP" draft-anavi-tdmoip-01.txt, work in progress, February 2001. [MARTINI] Martini et al, "Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-trans-mpls-06.txt, work in progress, July 2001. [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP Specification", RFC3036, January 2001. [RFC2661] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [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. [RTP] H. Schulzrinne et al, "RTP: A Transport Protocol for Real- Time Applications", RFC1889, January 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-ietf-pwe3-framework-00.txt), work in progress, August 2001. [JOHNSON] Johnson et al, "SONET/SDH Emulation over Packet (SEoP)" (draft-ietf-pwe3-sonet-00.txt), work in progress, September 2001. Pate et al. Expires Nov. 2001 [Page 15] Internet Draft draft-pate-pwe3-tdm-00 September 10, 2001 16. Authors' Addresses Prayson Pate Overture Networks, Inc. P. O. Box 14864 RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Ron Cohen Lycium Networks Email: ronc@lyciumnetworks.com David Zelig Corrigent Systems LTD. 126, Yigal Alon st. Tel Aviv, Israel EMail: Davidz@corrigent.com 17. 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 Nov. 2001 [Page 16]