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

   <Editor's Note - this section will describe the control of variables
   related to encapsulation.>

9.10.  Statistics

   <Editor's Note - this section will describe the statistics that are
   needed to monitor a PWE3 system.>

9.11.  Administrative Status

   <Editor's Note - this section will describe the control of
   administrative status.>

9.12.  Operational Status

   <Editor's Note - this section will describe the monitoring of
   operational status.>

9.13.  Management

   <Editor's Note: This section will describe the requirements for
   network management.>





Pate et al.                 Expires Nov. 2001                  [Page 13]


Internet Draft           draft-pate-pwe3-tdm-00       September 10, 2001

9.14.  Security

   <Editor's Note: This section will describe the security
   considerations.>

9.15.  QoS Considerations

   <Editor's Note: This section is to describe the QoS considerations.>

9.16.  Inter-domain PW Support Consideration

   <Editor's Note: This section is to describe the requirements for the
   PW when it is transported across service providers' domains.>

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]