[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-malis-pwe3-sonet) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 4842

PWE3 Working Group                                     Andrew G. Malis
Internet Draft                                                 Tellabs
Expiration Date: July 2005
                                                          Prayson Pate
                                                     Overture Networks

                                                    Ron Cohen (Editor)
                                                     Resolute Networks

                                                           David Zelig
                                                     Corrigent Systems

                                                         February 2005

             SONET/SDH Circuit Emulation over Packet (CEP)
                       draft-ietf-pwe3-sonet-10.txt

IPR Statement

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


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 draft provides encapsulation formats and semantics for
   emulating SONET/SDH circuits and services over a packet-switched
   network (PSN).



pwe3-sonet               Expires     July 2005                [Page 1]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



   Co-Authors

   The following individuals are co-authors of this document. Tom
   Johnson from Litchfield Communication did most of the editing work
   for pre WG versions of the SONET SPE work up to version 01 of this
   document.

   Craig White          Level3 Communications
   Ed Hallman           Litchfield Communications
   Jeremy Brayley       Laurel Networks
   Jim Boyle            Juniper Networks
   John Shirron         Laurel Networks
   Luca Martini         Cisco Systems
   Marlene Drost        Litchfield Communications
   Steve Vogelsang      Laurel Networks
   Tom Johnson          Litchfield Communications
   Ken Hsu              Tellabs



































pwe3-sonet              Expires     July 2005                [Page 2]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005

                Table of Contents


  1  CONVENTIONS USED IN THIS DOCUMENT.................3
  2  ACRONYMS..........................................4
  3  SCOPE.............................................5
  4  CEP ENCAPSULATION FORMAT..........................6
  4.1 SONET/SDH Fragment...............................7
  4.2 CEP Header.......................................9
  4.3 RTP Header......................................11
  4.4 PSN Encapsulation...............................12
  5  CEP OPERATION....................................16
  5.1 CEP Packetizer and De-Packetizer................16
  5.2 Packet Synchronization..........................17
  6  SONET/SDH MAINTENANCE SIGNALS....................19
  6.1 SONET/SDH to PSN................................19
  6.2 PSN to SONET/SDH................................21
  7  SONET/SDH TRANSPORT TIMING.......................23
  8  SONET/SDH POINTER MANAGEMENT.....................23
  8.1 Explicit Pointer Adjustment Relay (EPAR)........23
  8.2 Adaptive Pointer Management (APM)...............24
  9  CEP PERFORMANCE MONITORS.........................25
  9.1 Near-End Performance Monitors...................25
  9.2 Far-End Performance Monitors....................26
  10  PAYLOAD COMPRESSION OPTIONS.....................27
  10.1 Dynamic Bandwidth Allocation...................27
  10.2 Service-Specific Payload Formats...............27
  11  SIGNALING OF CEP PSEUDO WIRES...................37
  11.1 CEP/TDM Payload Bytes..........................37
  11.2 CEP/TDM Bit Rate...............................38
  11.3 CEP Options....................................38
  12  SECURITY CONSIDERATIONS.........................40
  13  INTELLECTUAL PROPERTY DISCLAIMER................40
  14  REFERENCES......................................40
  15  AUTHOR INFORMATION..............................42
  Appendix A SONET/SDH Rates and Formats..............44
  Appendix B Example Network Diagrams.................46
  Full Copyright Statement............................48
  Acknowledgement.....................................48




1  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].






pwe3-sonet              Expires     July 2005                [Page 3]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


2  Acronyms

   ADM    Add Drop Multiplexer
   AIS    Alarm Indication Signal
   APM    Adaptive Pointer Management
   AU-n   Administrative Unit-n (SDH)
   AUG    Administrative Unit Group (SDH)
   BIP    Bit Interleaved Parity
   BITS   Building Integrated Timing Supply
   CEP    Circuit Emulation over Packet
   DBA    Dynamic Bandwidth Allocation
   EBM    Equipped Bit Mask
   EPAR   Explicit Pointer Adjustment Relay
   LOF    Loss of Frame
   LOS    Loss of Signal
   LTE    Line Terminating Equipment
   PSN    Packet Switched Network
   POH    Path Overhead
   PTE    Path Terminating Equipment
   PW     Pseudo-Wire
   PWE3   Pseudo-Wire Emulation Edge-to-Edge
   RDI    Remote Defect Indication
   SDH    Synchronous Digital Hierarchy
   SONET  Synchronous Optical Network
   SPE    Synchronous Payload Envelope
   STM-n  Synchronous Transport Module-n (SDH)
   STS-n  Synchronous Transport Signal-n (SONET)
   TDM    Time Division Multiplexing
   TOH    Transport Overhead
   TU-n   Tributary Unit-n (SDH)
   TUG-n  Tributary Unit Group-n (SDH)
   UNEQ   Unequipped
   VC-n   Virtual Container-n (SDH)
   VT     Virtual Tributary (SONET)
   VTG    Virtual Tributary Group (SONET)


















pwe3-sonet              Expires     July 2005                [Page 4]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



3  Scope

   The generic requirements and architecture for Pseudo Wire Emulation
   Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3-
   ARCH].  Additional requirements for emulation of SONET/SDH and
   lower-rate TDM circuits have been defined in [PWE3-TDM-REQ].

   This draft provides encapsulation formats and semantics for
   emulating SONET/SDH circuits and services over a packet-switched
   network (PSN). This document describes how to emulate the following
   digital signals over a packet switched network:

   1. Synchronous Payload Envelope (SPE)/Virtual Container (VC-n):
      STS-1/VC-3, STS-3c/VC-4, STS-12c/VC-4-4c, STS-48c/VC-4-16c,
      STS-192c/VC-4-64c.

   2. Virtual Tributary (VT)/Virtual Container (VC-n): VT1.5/VC-11,
      VT2/VC-12, VT3, VT6/VC-2


   For the remainder of this document, these constructs will be
   referred to as SONET/SDH channels.

   Although this document currently covers up to OC-192c/VC-4-64c,
   future revision MAY address higher rates.



























pwe3-sonet              Expires     July 2005                [Page 5]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005




4  CEP Encapsulation Format

   In order to transport SONET/SDH circuits through a packet-oriented
   network, the SPE (or VT) is broken into fragments, and a CEP Header
   is pre-pended to each fragment. This section describes the CEP
   header format, RTP usage and the various PSN and multiplexing
   layers used to transport the CEP packet across various PSNs.  RTP
   encapsulation is OPTIONAL. The RTP header location differs for MPLS
   PSNs (See section 4.4.2 for details).



   The basic CEP packet appears in Figure 1.

             +-----------------------------------+
             |   PSN and Multiplexing Layer      |
             |             Headers               |
             +-----------------------------------+
             |           RTP Header              |
             |           (RFC1889)               |
             +-----------------------------------+
             |           CEP Header              |
             +-----------------------------------+
             |                                   |
             |                                   |
             |           SONET/SDH               |
             |            Fragment               |
             |                                   |
             |                                   |
             +-----------------------------------+

                 Figure 1 - Basic CEP Packet



















pwe3-sonet              Expires     July 2005                [Page 6]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005




4.1 SONET/SDH Fragment

   The SONET/SDH Fragments MUST be byte aligned with the SONET/SDH SPE
   or VT.

   The first bit received from each byte of the SONET/SDH MUST be the
   Most Significant Bit of each byte in the SONET/SDH fragment.

   SONET/SDH bytes are placed into the SONET/SDH fragment in the same
   order in which they are received.

   SONET/SDH optical interfaces use binary coding and therefore are
   scrambled prior to transmission to insure an adequate number of
   transitions.  For clarity, this scrambling will be referred to as
   physical layer scrambling/descrambling.

   In addition, many payload formats (such as for ATM and HDLC) include
   an additional layer of scrambling to provide protection against
   transition density violations within the SPEs.  This function will
   be referred to as payload scrambling/descrambling.

   CEP assumes that physical layer scrambling/descrambling occurs as
   part of the SONET/SDH section/line termination Native Service
   Processing (NSP) functions.

   However, CEP makes no assumption about payload scrambling.  The
   SONET/SDH fragments MUST be constructed without knowledge or
   processing of any incidental payload scrambling.

   CEP implementations MUST include the H3 (or V3) byte in the
   SONET/SDH fragment during negative pointer adjustment events, and
   MUST remove the stuff-byte from the SONET/SDH fragment during
   positive pointer adjustment events.

   VT emulation implementations MUST NOT carry the VT pointer bytes V1,
   V2, V3 and V4 as part of the CEP payload. The only exception being
   carriage of V3 during negative pointer adjustment as described
   above.

   All CEP SPE Implementations MUST support a packet size of 783 Bytes
   and MAY support other packet sizes.

   VT emulation implementations MUST support payload size of full VT
   super-frame, and MAY support 1/2 and 1/4 VT super-frame payload
   sizes.






pwe3-sonet              Expires     July 2005                [Page 7]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   Table 1 below describes single super-frame payload size per VT type.

            +-------------+-------------+
            | VT type     |    size     |
            +-------------+-------------+
            | VT1.5/VC-11 |  104 bytes  |
            | VT2/VC-12   |  140 bytes  |
            | VT3         |  212 bytes  |
            | VT6/VC-2    |  428 bytes  |
            +-------------+-------------+

         Table 1 - VT Super-frame Payload Sizes

   OPTIONAL SONET/SDH Fragment formats have been defined to reduce the
   bandwidth requirements of the emulated SONET/SDH circuits under
   certain conditions.  These OPTIONAL Formats are included in
   Section 10.




































pwe3-sonet              Expires     July 2005                [Page 8]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005




4.2 CEP Header

   The CEP Header supports a basic and extended mode.  The Basic CEP
   Header provides the minimum functionality necessary to accurately
   emulate a SONET/SDH circuit over a PSN.

   Enhanced functionality and commonality with other real-time Internet
   applications is provided by RTP encapsulation.

   Bit 0 of the first 32-bit CEP header indicates whether or not the
   extended header is present.  When this bit is 0, then no extended
   header is present.  When this bit is 1, then an extended header is
   present.  Extended headers are utilized for the some of the OPTIONAL
   SONET/SDH fragment formats described in Section 10.

   The Basic CEP header has the following format:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|R|D|N|P| Structure Pointer[0:12] |  Sequence Number[0:13]    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2 - Basic CEP Header Format


   The above fields are defined as follows:

   R bit: CEP-RDI.  This bit is set to one to signal to the remote CEP
   function that a loss of packet synchronization has occurred.

   D bit: Signals DBA Mode.  The D bit MUST be set to zero for Normal
   Operation.  It MUST be set to one if CEP is currently in DBA mode.
   DBA is an optional mode during which trivial payloads are not
   transmitted into the packet network.  See Table 2 and section 10.1
   for further details.

   The N and P bits: MAY be used to explicitly relay negative and
   positive pointer adjustment events across the PSN.  They are also
   used to relay SONET/SDH maintenance signals such as AIS-P/V.  See
   Table 2 and section 8.1 for more details.










pwe3-sonet              Expires     July 2005                [Page 9]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005




         +---+---+---+----------------------------------------------+
         | D | N | P |         Interpretation                       |
         +---+---+---+----------------------------------------------+
         | 0 | 0 | 0 | Normal Mode   No Ptr Adjustment              |
         | 0 | 0 | 1 | Normal Mode   Positive Ptr Adjustment        |
         | 0 | 1 | 0 | Normal Mode   Negative Ptr Adjustment        |
         | 0 | 1 | 1 | Normal Mode   AIS-P/V                        |
         |   |   |   |                                              |
         | 1 | 0 | 0 | DBA Mode      UNEQ-P/V                       |
         | 1 | 0 | 1 | DBA Mode      UNEQ-P/V Positive Ptr Adj      |
         | 1 | 1 | 0 | DBA Mode      UNEQ-P/V Negative Ptr Adj      |
         | 1 | 1 | 1 | DBA Mode      AIS-P/V                        |
         +---+---+---+----------------------------------------------+


                Table 2 - Interpretation of D, N, and P bits

   Sequence Number [0:13]:  This is a packet sequence number, which
   MUST continuously cycle from 0 to 0x3FFF.  It is generated and
   processed in accordance with the rules established in [RFC1889].
   When the RTP header is used, this sequence number MUST match the
   LSBs of the RTP sequence Number.

   Structure Pointer [0:12]: The Structure Pointer MUST contain the
   offset of the first byte of the payload structure.  For SPE
   emulation, the structure pointer locates the J1 byte within the CEP
   SONET/SDH Fragment.  For VT emulation the structure pointer locates
   the V5 byte within the SONET/SDH fragment.  The value is from 0 to
   0x1FFE, where 0 means the first byte after the CEP header. The
   Structure Pointer MUST be set to 0x1FFF if a packet does not carry
   the J1 (or V5) byte.




















pwe3-sonet              Expires     July 2005               [Page 10]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


4.3 RTP Header

   Usage of RTP header is OPTIONAL. If RTP header is used header
   compression mechanisms as described in [RFC2508] and [RFC3095] MAY
   be used.

   Usage of CEP header is mandatory. The CEP header carries both a
   sequence number and pointer adjustment indications (N,P bits). The
   pointer adjustment indications are the native service method for
   conveying difference between the service clock and a clock common to
   both PEs (See section 8 for details). All the information required
   for delivery of timing (synchronization) is therefore contained
   within the CEP header fields providing similar functions as RTP
   sequencing and timestamp fields.

   CEP uses the RTP Header as shown below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

                       Figure 3 - RTP Header

   V : Version. The Version field MUST be set to 2.

   P : Padding. No padding is required. The P bit MUST be set to 0.

   X : Header extension. No extensions are defined. The X bit MUST be
   set to 0.

   CC: CSRC count. CC field MUST be set to zero.

   M : Marker. The M bit MUST be set to 0 for CEP packets.

   PT [0:6]: Payload type. The payload type is used to identify CEP
   packets. A PT value SHOULD be allocated from the range of dynamic
   values for every CEP pseudo-wire. Allocation is done during the
   pseudo-wire setup and MUST be the same for both pseudo-wire
   directions.

   Sequence Number [0:15]: The sequence number provides the common PW
   sequencing function as well as detection of lost packets.  It is
   generated and processed in accordance with the rules established in
   [RFC1889].



pwe3-sonet              Expires     July 2005               [Page 11]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   Timestamp [0:31]: The time stamp is used primarily for carrying
   timing information over the network.  Their values are used in
   accordance with the rules established in [RFC1889].  Frequency of
   the clock used for generating timestamps MUST be 19.44 MHz based on
   a local reference.

   SSRC [0:31]: Synchronization source. The SSRC field MAY be used for
   detection of misconnections.



4.4 PSN Encapsulation

   In principle, CEP packets can be carried over any packet-oriented
   network.  The following sections describe specifically how CEP
   packets are encapsulated for carriage over MPLS or IP networks.


4.4.1   IP Encapsulation

   CEP uses the standard IP/UDP/RTP encapsulation scheme as shown
   below. The UDP destination port MUST be used to De-multiplex
   individual CEP channels. RTP header is OPTIONAL and MAY be
   suppressed to conserve network bandwidth.


                 +-----------------------------------+
                 |                                   |
                 |         IPv6/v4 Header            |
                 |                                   |
                 +-----------------------------------+
                 |            UDP Header             |
                 +-----------------------------------+
                 |            RTP Header             |
                 +-----------------------------------+
                 |            CEP Header             |
                 +-----------------------------------+
                 |                                   |
                 |                                   |
                 |       SONET/SDH Fragment          |
                 |                                   |
                 |                                   |
                 +-----------------------------------+


                 Figure 4 - IP Transport Encapsulation







pwe3-sonet              Expires     July 2005               [Page 12]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



4.4.2   MPLS Encapsulation

   Figure 5 describes CEP encapsulation over an MPLS network. To
   transport a CEP packet over an MPLS network, an MPLS label-stack
   MUST be pushed on top of the CEP packet.  The bottom label in the
   MPLS label stack MUST be used to de-multiplex individual CEP
   channels.  In keeping with the conventions used in [PWE3-CONTROL],
   this de-multiplexing label is referred to as the PW Label and the
   upper labels are referred to as Tunnel Labels.

   To allow accurate packet inspection in an MPLS PSN, and/or to
   operate correctly over MPLS networks that have deployed equal-cost
   multiple-path load-balancing (ECMP), a PW packet SHOULD not alias an
   IP packet. Since the CEP header's first 4 bits are used to carry CEP
   signaling and therefore may alias an IP packet, a CEP MPLS
   adaptation header is added. The CEP MPLS adaptation header format is
   defined in Figure 6 . The CEP MPLS adaptation header MAY be
   suppressed in MPLS networks where IP aliasing is not a problem.

   RTP header immediately follows the PW CEP header. RTP header is
   OPTIONAL and MAY be suppressed to conserve network bandwidth.




                 +-----------------------------------+
                 |  One or more MPLS Tunnel Labels   |
                 +-----------------------------------+
                 |            PW Label               |
                 +-----------------------------------+
                 |     CEP MPLS Adaptation Header    |
                 +-----------------------------------+
                 |           CEP Header              |
                 +-----------------------------------+
                 |           RTP Header              |
                 +-----------------------------------+
                 |                                   |
                 |                                   |
                 |       SONET/SDH Fragment          |
                 |                                   |
                 |                                   |
                 +-----------------------------------+


                Figure 5 - MPLS Transport Encapsulation







pwe3-sonet              Expires     July 2005               [Page 13]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005







     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0|0|0|                     Reserved                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 6 - CEP MPLS Adaptation Header


   First four bits of the CEP MPLS Adaptation Header are set to zero.
   The rest of the bits are reserved for future use. The reserved bits
   MUST be set to zero by transmitter and ignored by the receiver.


4.4.3   L2TPv3 Encapsulation

   Figure 7 describes CEP encapsulation over Layer 2 Tunneling Protocol
   version 3 [L2TPv3]. RTP header is OPTIONAL and MAY be suppressed to
   conserve network bandwidth. The L2TPv3 header MUST be used to
   de-multiplex individual CEP channels.



                 +-----------------------------------+
                 |           L2TPv3 Header           |
                 +-----------------------------------+
                 |            RTP Header             |
                 +-----------------------------------+
                 |            CEP Header             |
                 +-----------------------------------+
                 |                                   |
                 |                                   |
                 |       SONET/SDH Fragment          |
                 |                                   |
                 |                                   |
                 +-----------------------------------+


                Figure 7 - L2TPv3 Transport Encapsulation









pwe3-sonet              Expires     July 2005               [Page 14]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



   CEP uses the L2TPv3 header as defined below:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Session ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Cookie                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Cookie (Long)                        |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


                       Figure 8 - L2TPv3 Header


   Session ID: Used to de-multiplex individual CEP channels

   Cookie: Optional 0/32/64 bit field. The cookie MAY be used for
   detection of misconnections. Cookie field is suppressed by default.
   Use of the Cookie field and its length may be statically configured
   or signaled using [L2TPv3].





























pwe3-sonet              Expires     July 2005               [Page 15]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


5  CEP operation


   CEP MUST support a normal mode of operation and MAY support
   additional bandwidth conserving modes described in section 10.
   During normal operation, SONET/SDH payloads are fragmented, pre-
   pended with the appropriate headers and then transmitted into the
   packet network.


5.1 CEP Packetizer and De-Packetizer

   As with all adaptation functions, CEP has two distinct components:
   adapting TDM SONET/SDH into a CEP packet stream, and converting the
   CEP packet stream back into a TDM SONET/SDH.  The first function
   will be referred to as CEP Packetizer and the second as CEP De-
   Packetizer.  This terminology is illustrated in Figure 9.


                +------------+              +---------------+
                |            |              |               |
      SONET --> |    CEP     | --> PSN  --> |      CEP      | --> SONET
       SDH      | Packetizer |              | De-Packetizer |      SDH
                |            |              |               |
                +------------+              +---------------+

                        Figure 9 - CEP Terminology

   Note: the CEP de-packetizer requires a buffering mechanism to
   account for delay variation in the CEP packet stream.  This
   buffering mechanism will be generically referred to as the CEP
   jitter buffer.

   During normal operation, the CEP packetizer will receive a fixed
   rate byte stream from a SONET/SDH interface.  When a packet worth
   of data has been received from a SONET/SDH channel, the necessary
   headers are pre-pended to the SPE fragment and the resulting CEP
   packet is transmitted into the packet network.  Because all CEP
   packets associated with a specific SONET/SDH channel will have the
   same length, the transmission of CEP packets for that channel SHOULD
   occur at regular intervals.

   At the far end of the packet network, the CEP de-packetizer will
   receive packets into a jitter buffer and then play out the received
   byte stream at a fixed rate onto the corresponding SONET/SDH
   channel.  The jitter buffer SHOULD be adjustable in length to
   account for varying network delay behavior.  The receive packet rate
   from the packet network should be exactly balanced by the
   transmission rate onto the SONET/SDH channel, on average.  The time
   over which this average is taken corresponds to the depth of the
   jitter buffer for a specific CEP channel.


pwe3-sonet              Expires     July 2005               [Page 16]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   The RTP sequence numbers provide a mechanism to detect lost and/or
   mis-ordered packets.  The sequence number in the CEP header MUST be
   used when transmission of the RTP header is suppressed. The CEP
   de-packetizer MUST detect lost or miss-ordered packets.  The CEP
   de-packetizer SHOULD play out an all ones pattern (AIS) in place of
   any dropped packets.  The CEP de-packetizer MAY re-order packets
   received out of order.  If the CEP de-packetizer does not support
   re-ordering, it MUST drop miss-ordered packets.



5.2 Packet Synchronization

   A key component in declaring the state of a CEP service is whether
   or not the CEP de-packetizer is in or out of packet synchronization.
   The following paragraphs describe how that determination is made.

   As packets are received from the PSN, they are placed into a jitter
   buffer prior to play out on the SONET/SDH interface.  If a CEP de-
   packetizer supports re-ordering, any packet received before its play
   out time will still be considered valid.

   If a CEP de-packetizer does not support re-ordering, a number of
   approaches may be used to minimize the impact of miss-ordered or
   lost packets on the final re-assembled SONET/SDH stream. For
   example, [AAL1] uses a simple state-machine to re-order packets in a
   sub-set of possible cases.

   However, the final determination as to whether or not to declare
   acquisition or loss of packet synchronization MUST be based on the
   same criteria regardless of whether an implementation supports or
   does not support re-ordering.

   Therefore, the determination of acquisition or loss of packet
   synchronization is always made at SONET/SDH play-out time.  During
   SONET/SDH play-out, the CEP de-packetizer will play received CEP
   packets onto the SONET/SDH interface.  However, if the jitter buffer
   is empty or the packet to be played out has not been received, the
   CEP de-packetizer will play out an empty packet onto the SONET/SDH
   interface in place of the unavailable packet.

   The acquisition of packet synch is based on the number of sequential
   CEP packets that are played onto the SONET/SDH interface.  Loss of
   packet synch is based on the number of sequential 'empty' packets
   that are played onto the SONET/SDH interface.  Specific details of
   these two cases are described below.







pwe3-sonet              Expires     July 2005               [Page 17]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


5.2.1   Acquisition of Packet Synchronization

   At startup, a CEP de-packetizer will be out of packet
   synchronization by default.  To declare packet synchronization at
   startup or after a loss of packet synchronization, the CEP de-
   packetizer must play-out a configurable number of CEP packets with
   sequential sequence numbers towards the SONET/SDH interface.

5.2.2   Loss of Packet Synchronization

   Once a CEP de-packetizer is in packet sync, it may encounter a set
   of events that will cause it to lose packet synchronization.

   If the CEP de-packetizer encounters more than a configurable number
   of sequential empty packets, the CEP de-packetizer MUST declare loss
   of packet synchronization (LOPS) defect.

   Loss of Packet Synchronization (LOPS) failure is declared after 2.5
   +/- 0.5 seconds of LOPS defect, and cleared after 10 seconds free of
   LOPS defect state. The circuit is considered down as long as LOPS
   failure is declared.
































pwe3-sonet              Expires     July 2005               [Page 18]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


6  SONET/SDH Maintenance Signals

   This section describes mapping of maintenance and alarm signals
   between the SONET/SDH network and the CEP pseudo-wire. For clarity,
   the mappings are split into two groups: SONET/SDH to PSN, and PSN to
   SONET/SDH.

   For coherent failure detection, isolation, monitoring and trouble
   shooting, SONET/SDH failure indications MUST be transferred
   correctly over the CEP pseudo-wire, and CEP connection failures MUST
   be mapped to SONET/SDH PATH/VT failure indications. Failure detection
   capabilities and performance monitoring capabilities will be
   dependent on the NSP functionality e.g. LTE, PTE, Tandem Connection
   Monitoring (refer to [G.707]), or Non-intrusive Monitoring
   (intermediate connection monitoring).


6.1 SONET/SDH to PSN

   The following sections describe how SONET/SDH Maintenance Signals
   and Alarm conditions are mapped into a CEP pseudo-wire.

6.1.1   AIS-P/V Indication

   SONET/SDH Path outages are signaled using maintenance alarms such as
   Path AIS (AIS-P).  In particular, AIS-P indicates that the SONET/SDH
   Path is not currently transmitting valid end-user data, and the SPE
   contains all ones. Similarly, AIS-V indicates that the VT is not
   currently transmitting valid end-user data, and the VT contains all
   ones.

   It should be noted that nearly every type of service-affecting
   section or line defect would result in an AIS-P/V condition.

   The mapping of SONET/SDH failures into the PATH/VT layer is
   considered part of the NSP function, and is based on the principles
   specified in [GR253], [SONET], [G.707], [G.806], and [G.783]. Should
   for example the Section Layer detect a Loss of Signal (LOS) or Loss
   of Frame (LOF) or Section Trace Mismatch (TIM) conditions, it sends
   AIS-L up to the Line Layer. If the Line Layer detects AIS-L or Loss
   of Pointer (LOP), it sends AIS-P to the Path Layer. If the Path
   Layer detects AIS-P or UNEQ-P or TIM-P or PLM-P and is terminated at
   the NSP (i.e. PTE), it sends AIS-V to the VT Layer. Note, a non-
   intrusive monitor only detects failures, it must not do AIS
   insertion.








pwe3-sonet              Expires     July 2005               [Page 19]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   The AIS-P indication is transferred to the CEP packetizer. During
   AIS-P, SPE CEP packets are generated as usual. The N and P bits MUST
   be set to 11 binary to signal AIS-P explicitly through the packet
   network.  The D-bit MUST be set to zero to indicate that the SPE is
   being carried through the packet network.  Normal CEP packets with
   the SPE fragment, CEP Header, the Circuit ID Word, and PSN Header
   MUST be transmitted into the packet network. If DBA has been enabled
   for AIS SPE/VT the D-bit MUST be set to one to indicate DBA is
   active and only the necessary headers and optional padding are
   transmitted into the packet network. The same rules are followed for
   VT CEP packets during AIS-V condition.

6.1.2   Unequipped Indication

   The declaration of SPE/VT Unequipped MUST conform to [GR253],
   [SONET], or [G.806] and [G.783]. [GR253] detection is based on the
   presence of an Unequipped Signal Label. [SONET] or SDH detection is
   based on the presence of an Unequipped Signal Label and an all zeros
   Trail Trace Identifier (TTI) to distinguish the presence of an
   Unequipped signal or a [SONET] test signal (Supervisory-Unequipped
   [G.707]).

   Unequipped indication is used for DBA bandwidth conserving mode as a
   trigger for payload removal.

   During SPE/VT Unequipped, the N and P bits MUST be interpreted as
   usual.  The SPE/VT MUST be transmitted into the packet network along
   with the appropriate headers, and the D-Bit MUST be set to zero.
   If DBA has been enabled for Unequipped SPE/VT the D-bit MUST be set
   to one to indicate DBA is active and only the necessary headers and
   optional padding are transmitted into the packet network.  The N and
   P bits MAY be used to signal pointer adjustments as normal.

6.1.3   CEP-RDI

   The CEP function MUST send CEP-RDI towards the packet network during
   loss of packet synchronization.  This MUST be accomplished by
   setting the R bit to one in the CEP header.















pwe3-sonet              Expires     July 2005               [Page 20]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


6.2 PSN to SONET/SDH

   The following sections discuss how the various conditions on the
   packet network are converted into SONET/SDH indications.

   The SONET/SDH hierarchy combined with CEP is illustrated below.

                             +----------+
                             |    VT    |
                             +----------+
                                ^     ^
                                |     |
                                |    LOPS
                                |     |     +------------+
                                |     +-----| CEP VT PW  |
                                |           +------------+
                              AIS-V
                                |
                             +----------+
                             |   PATH   |
                             +----------+
                                ^     ^
                                |     |
                                |    LOPS
                                |     |     +------------+
                                |     +-----| CEP SPE PW |
                                |           +------------+
              ----------------  |  -----------------------
                                ^
                              AIS-P
                  NSP           |
                             +----------+
                             |   LINE   |
                             + ---------+
                                ^     ^
                                |     |
                              AIS-L   +------ LOP
                                |
                             +----------+
                             | SECTION  |
                             +----------+
                                ^    ^
                                |    |
                               LOS  LOF

             Figure 10 - SONET/SDH and CEP AIS Fault Hierarchy







pwe3-sonet              Expires     July 2005               [Page 21]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


6.2.1   AIS-P/V Indication

   There are several conditions in the packet network that will cause
   the CEP de-packetization function to play out an AIS-P/V indication
   towards a SONET/SDH channel.

   The first of these is the receipt of CEP packets with the N and P
   bits set to one.  This is an explicit indication of AIS-P or AIS-V
   being received at the far-end of the packet network.  The CEP de-
   packetizer MUST play out one packet's worth of all ones for each
   packet received, and MUST set the SONET/SDH Overhead to signal AIS-
   P/V as defined in [SONET], [GR253] and [G.707].


   The second case that will cause a CEP de-packetization function to
   play out an AIS-P indication onto a SONET/SDH channel is during loss
   of packet synchronization.  In this case, the CEP de-packetizer MUST
   set the SONET/SDH Overhead to signal AIS-P/V as defined in [SONET],
   [GR253] and [G.707].

6.2.2   Unequipped Indication

   There are several conditions in the packet network that will cause
   the CEP function to transmit Unequipped indications onto the
   SONET/SDH channel.

   The first, which is transparent to CEP, is the receipt of regular
   CEP packets that happen to be carrying an SPE that contains the
   appropriate Path overhead or VT overhead set to unequipped.  This
   case does not require any special processing on the part of the CEP
   de-packetizer.

   The second case is the receipt of CEP packets that have the D-bit
   set to one to indicate DBA active and the N and P bits set to 00
   binary, 01 binary, or 10 binary to indicate SPE Unequipped with or
   without pointer adjustments.  The CEP de-packetizer MUST use this
   information to transmit a packet of all zeros onto the SONET/SDH
   interface, and adjust the payload pointer as necessary.

   The third case when a CEP de-packetizer MUST play out an SPE/VT
   Unequipped Indication towards the SONET/SDH interface is when the
   circuit has been de-provisioned.











pwe3-sonet              Expires     July 2005               [Page 22]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


7  SONET/SDH Transport Timing

   It is assumed that the distribution of SONET/SDH Transport timing
   information is addressed either through external mechanisms such as
   Building Integrated Timing System (BITS), Stand Alone
   Synchronization Equipment (SASE), Global Positioning System (GPS) or
   other such methods, or is through an adaptive timing recovery
   mechanism.

8  SONET/SDH Pointer Management

   A pointer management system is defined as part of the definition of
   SONET/SDH. Details on SONET/SDH pointer management can be found in
   [SONET], [GR253], [G.707] and [G.783].  If there is a frequency
   offset between the frame rate of the transport overhead and that of
   the SONET/SDH SPE or VT, then the alignment of the SPE (or VT) will
   periodically slip back or advance in time through positive or
   negative stuffing.

   The emulation of this aspect of SONET/SDH networks may be
   accomplished using a variety of techniques including (but not
   limited to) explicit pointer adjustment relay (EPAR) and adaptive
   pointer management (APM).

   In any case, the handling of the SPE data by the CEP packetizer is
   the same.

   During a negative pointer adjustment event, the CEP packetizer MUST
   incorporate the H3 (or V3) byte from the SONET/SDH stream into the
   CEP packet payload in order with the rest of the SPE.  During a
   positive pointer adjustment event, the CEP packetizer MUST strip the
   stuff byte from the CEP packet payload.

   When playing out a negative pointer adjustment event, the
   appropriate byte of the CEP payload MUST be placed into the H3 (or
   V3) byte of the SONET/SDH stream.  When playing out a positive
   pointer adjustment, the CEP de-packetizer MUST insert a stuff-byte
   into the appropriate position within the SONET/SDH stream.

   The details regarding the use of the H3 (and V3) byte and stuff byte
   during positive and negative pointer adjustments can be found in
   [SONET], [GR253] and [G.707].


8.1 Explicit Pointer Adjustment Relay (EPAR)

   CEP provides an OPTIONAL mechanism to explicitly relay pointer
   adjustment events from one side of the PSN to the other.  This
   technique will be referred to as Explicit Pointer Adjustment Relay
   (EPAR).  EPAR is only effective when both ends of the PW have access
   to a common timing reference.


pwe3-sonet              Expires     July 2005               [Page 23]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   The following text only applies to implementations that choose to
   implement EPAR.  Any CEP implementation that does not support EPAR
   MUST either set the N and P bits to zero or utilize them to relay
   AIS-P/V and STS/VT Unequipped as shown in Table 2.

   When working in EPAR mode, it is assumed that a common reference
   clock is available for both the de-packetizer and the packetizer.
   The CEP service relay the pointer adjustments which represents the
   difference between the SPE/VT frequency and the reference clock,
   keeping the SPE/VT payload rate equal at the de-packetizer and
   packetizer outputs.

   The mechanics of EPAR are described below.

   For SPE Emulation, the pointer adjustment event MUST be transmitted
   in three consecutive packets by the packetizer. The de-packetizer
   MUST play out the pointer adjustment event when any one packet with
   N/P bit set is received.

   The CEP de-packetizer MUST utilize the CEP sequence numbers to
   insure that SONET/SDH pointer adjustment events are not played any
   more frequently than once per every three CEP packets transmitted by
   the remote CEP packetizer.

   For VT emulation, a pointer adjustment event MUST be transmitted in
   all packets carrying a single VT super-frame, starting from the
   packet carrying the V5 byte and not including the packet carrying
   the V5 byte of the next VT super-frame. Pointer adjustment events at
   the VT and STS-1 levels are mapped to N and P indications. Pointer
   adjustments at the VT level are mapped 1:1 to CEP indications, while
   SPE pointer indications are mapped according to the ratio of VT/SPE
   byte rates.

   If both bits are set, then an AIS-P/V event has been detected at the
   PW ingress, making the pointer invalid.

   When DBA is invoked (i.e. the D-bit = 1), N and P have additional
   meanings.  See Table 2 and section 10.1 for more details.


8.2 Adaptive Pointer Management (APM)

   Another OPTIONAL method that may be used to emulate SONET/SDH
   pointer management is Adaptive Pointer Management (APM).  In basic
   terms, APM uses information about the depth of the CEP jitter
   buffers to introduce pointer adjustments in the reassembled
   SONET/SDH SPE.

   Details about specific APM algorithms are not considered to be
   within scope for this document.



pwe3-sonet              Expires     July 2005               [Page 24]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


9  CEP Performance Monitors

   SONET/SDH as defined in [SONET], [GR253], [G.707] and [G.784]
   includes the definition of several counters that may be used to
   monitor the performance of SONET/SDH services.  These counters
   are referred to as Performance Monitors.

   In order for CEP to be utilized by traditional SONET/SDH network
   operators, CEP SHOULD provide similar functionality.  To this end,
   the following sections describe a number of counters that will
   collectively be referred to as CEP Performance Monitors.


9.1 Near-End Performance Monitors

   These performance monitors are maintained by the CEP De-Packetizer
   during reassembly of the SONET/SDH stream.

   The performance monitors are based on two types of defects.

   Type 1 : missing or dropped packet.
   Type 2 : buffer under run, buffer over-run, LOPS, missing packets
   above pre-defined configurable threshold.

   The specific performance monitors defined for CEP are as follows:

   ES-CEP       - CEP Errored Seconds
   SES-CEP      - CEP Severely Errored Seconds
   UAS-CEP      - CEP Unavailable Seconds

   Each second that contain at least one type 1 defect SHALL be
   declared as ES-CEP. Each second that contain at least one type 2
   defect SHALL be declared as SES-CEP.


   UAS-CEP SHALL be declared after configurable number of consecutives
   SES-CEP, and cleared after a configurable number of consecutive
   seconds without SES-CEP.  Default value for each is 10 seconds.

   Once unavailability is declared, ES and SES counts SHALL be
   inhibited up to the point where the unavailability was started. Once
   unavailability is removed, ES and SES that occurred along the
   clearing period SHALL be added to the ES and SES counts.

   CEP-NE failure is declared after 2.5 +/- 0.5 seconds of CEP-NE
   Type-2 defect, and cleared after 10 seconds free of CEP-NE defect
   state. Sending notification to the OS for CEP-NE failure is local
   policy.





pwe3-sonet              Expires     July 2005               [Page 25]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


9.2 Far-End Performance Monitors

   Far-End performance monitors provide insight into the CEP De-
   packetizer at the far-end of the PSN.

   Far end statistics are based on the CEP-RDI bit. CEP-FE defect is
   declared when CEP-RDI is set in the incoming CEP packets.

   CEP-FE failure is declared after 2.5 +/- 0.5 seconds of CEP-FE
   defect, and cleared after 10 seconds free of CEP-FE defect state.
   Sending notification to the OS for CEP-FE failure is local policy.










































pwe3-sonet              Expires     July 2005               [Page 26]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


10 Payload Compression Options

   In addition to pure emulation, CEP also offers a number of options
   for reducing the total bandwidth utilized by the emulated circuit.
   These options fall into two categories: Dynamic Bandwidth Allocation
   and Service-Specific Payload Formats.

   Dynamic Bandwidth Allocation (DBA) suppresses transmission of the
   CEP payload altogether under certain circumstances such as AIS-P/V
   and STS/VT Unequipped. The use of DBA will be dependent on network
   architectures e.g. support of Tandem Connection Monitoring, test
   signals (TEST-P [SONET]) or Supervisory Unequipped [G.806] signals.
   Service-Specific Payload formats reduce bandwidth by suppressing
   transmission of portions of the SPE based on specific knowledge
   of the SPE payload.

   Details on these payload compression options are described in the
   following subsections.


10.1    Dynamic Bandwidth Allocation

   Dynamic Bandwidth Allocation (DBA) is an OPTIONAL mechanism for
   suppressing the transmission of the SPE (or VT) fragment when one of
   two trigger conditions are met, AIS-P/V or STS/VT Unequipped.

   Implementations that support DBA MUST include a mechanism for
   disabling DBA on a channel-by-channel basis to allow for
   interoperability with implementations that do not support DBA.

   When a DBA trigger is recognized at PW ingress, the CEP payload will
   be suppressed. Padding bytes SHOULD be added if the intervening
   packet network has a minimum packet size which is larger than the
   payload-suppressed DBA packet.

   Other than the suppression of the CEP payload, the CEP behavior
   during DBA should be equivalent to normal CEP behavior.  In
   particular, the packet transmission rate during DBA should be
   equivalent to the normal packet transmission rate.



10.2    Service-Specific Payload Formats

   In addition to the standard payload encapsulations for SPE and VT
   transport, several OPTIONAL payload formats have been defined to
   provide varying amounts of payload compression depending on the type
   and amount of user traffic present within the SPE.  These are
   described below.




pwe3-sonet              Expires     July 2005               [Page 27]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


10.2.1  Fractional STS-1 (VC-3) Encapsulation

   Fractional STS-1 (VC-3) encapsulation carries only selected set of
   VTs within an STS-1 container. This mode is applicable for STS-1
   with POH signal label byte C2=2 (VT-structured SPE) and for C2=3
   (Locked VT mode).

   Implementations of fractional STS-1 (VC-3) encapsulation MUST
   support payload length of one SPE and MAY support payload length of
   1/3 SPE.

   The mapping of VTs into an STS-1 container is described in section
   3.2.4 of [GR253] and the mapping into VC-3 is defined in section
   7.2.4 in [G.707]. The CEP packetizer removes all fixed column bytes
   (columns 30 and 59) and all bytes that belong to the removed VTs.
   Only STS-1 POH bytes and bytes that belong to the selected VTs are
   carried within the payload. The CEP de-packetizer adds the fixed
   stuff bytes and generates unequipped VT data replacing the removed
   VT bytes. Figure 11 below describes VT mapping into an STS-1 SPE.


      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 11 - 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.

pwe3-sonet              Expires     July 2005               [Page 28]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



   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.


10.2.1.1        Fractional STS-1 CEP header

   The fractional STS-1 CEP header uses the STS-1 CEP header
   encapsulation as defined in this draft.  Optionally, an additional 4
   byte header extension word is added.  The extended header is
   described in Figure 12.

    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 12 - 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 this draft 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 this draft) 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.


pwe3-sonet              Expires     July 2005               [Page 29]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   The format of the EBM is defined in Figure 13.

          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 13 - 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. The
   first two bits are used to indicate whether VT3 (DS1C) tributaries
   are carried within a VTG and the right most bit is used to indicate
   whether a VT6 (DS2) is carried within the VTG. The VTs within the VTG
   are numbered from right to left, starting from the first VT as the
   first bit on the right. 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.















10.2.1.2        B3 Compensation

   Fractional STS-1 encapsulation can be implemented in Line
   Terminating Equipment (LTE) or in Path Terminating Equipment (PTE).
   PTE implementations terminate the path layer at the ingress PE and
   generate a new path layer at the egress PE.

   LTE implementations do not terminate the path layer, and therefore
   need to keep the content and integrity of the POH bytes across the
   PSN. In LTE implementations, special care must be taken to maintain
   the B3 bit-wise parity POH byte. The B3 compensation algorithm is
   defined below.


pwe3-sonet              Expires     July 2005               [Page 30]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   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.



10.2.1.3        Actual Payload Size

   The actual CEP payload size depends on the number of virtual
   tributaries carried within the fractional SPE. The contributions of
   each tributary to the fractional STS-1 payload size as well as the
   path overhead contribution are described below.

      Each VT1.5                   contributes 27 bytes
      Each VT2                     contributes 36 bytes
      Each VT3                     contributes 54 bytes
      Each VT6                     contributes 108 bytes
      STS-1 POH                    contributes 9 bytes

   For example, a fractional STS-1 carrying 7 VT2 circuit in full-SPE
   encapsulation would have an actual size of 261=36*7+9 bytes. Divide
   by 3 to calculate the third-SPE encapsulation actual payload sizes.













pwe3-sonet              Expires     July 2005               [Page 31]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


10.2.2  Asynchronous T3/E3 STS-1 (VC-3) Encapsulation

   Asynchronous T3/E3 STS-1 (VC-3) encapsulation is applicable for STS-
   1 with POH signal label byte C2=4, carrying asynchronous mapping of
   T3 or E3 signals.

   Implementations of asynchronous T3/E3 STS-1 (VC-3) encapsulation
   MUST support payload length of one SPE and MAY support payload
   length of 1/3 SPE.


10.2.2.1        T3 payload compression

   A T3 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 this draft.

   Optionally, the STS-1 SPE can be compressed by removing the fixed
   columns leaving only data columns. STS-1 columns are numbered 1 to
   87, starting from the POH column numbered 1. The following columns
   have fixed values and are removed:  2, 3, 30, 31, 59, 60.

   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. The actual payload size for full-SPE encapsulation
   would be 729 bytes and 243 bytes for third-SPE encapsulation.

   A T3 is encapsulated asynchronously into a VC-3 container as
   described in section 10.1.2.1 of [G.707]. VC-3 container has only 85
   data columns, which is identical to the STS-1 container with the two
   fixed stuff columns 30 and 59 removed. Other than that, the mapping
   is identical.


10.2.2.2        E3 payload compression

   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 this draft.


   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 and 81.

   Bandwidth saving is approximately 28% (24 columns out of 85). The B3
   parity byte need not be modified as the parity of the fixed columns
   amounts to zero. The actual payload size for full-SPE encapsulation
   would be 567 bytes and 189 bytes for third-SPE encapsulation.


pwe3-sonet              Expires     July 2005               [Page 32]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


10.2.3  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 <---- DS2
                               |
                               +----x3---- TU-12 <-- VC-12<---- E1
                               |
                               +----x4---- TU-11 <-- VC-11<---- T1


                   Figure 14 - Mapping of VCs into VC-4

   Figure 14 describes the mapping options of VCs into VC-4. A VC-4
   contains three TUG-3s. Each TUG-3 is composed of either a single TU-
   3, or 7 TUG-2s. A TU-3 contains a single VC-3. A TUG-2 contains
   either 4 VC-11s (T1s), 3 VC-12s (E1s) or one VC-2. Therefore a VC-4
   may contain 3 VC-3s, 1 VC-3 and 42 VC-12s, 63 VC-12s, etc.

   Fractional VC-4 encapsulation carries only selected set of VCs
   within a VC-4 container. This mode is applicable for VC-4 with POH
   signal label byte C2=2 (TUG structure) and for C2=3 (Locked TU-n).
   The mapping of VCs into a VC-4 container is described in section 7.2
   of [G.707]. The CEP packetizer removes all fixed column bytes and
   all bytes that belong to the removed VCs. Only VC-4 POH bytes and
   bytes that belong to the selected VCs are carried within the
   payload. The CEP de-packetizer adds the fixed stuff bytes and
   generates unequipped VC data replacing the removed VC bytes.

   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.

   VC-3 carrying asynchronous T3/E3 signals within the VC-4 container
   can optionally be compressed by removing the fixed column bytes as
   described in section 10.2.2, providing additional bandwidth saving.

   Implementations of fractional VC-4 encapsulation MUST support
   payload length of 1/3 SPE and MAY support payload lengths of 4/9,
   5/9, 6/9, 7/9, 8/9 and full SPE. The actual payload size of
   fractional VC-4 encapsulation depends on the number of VCs carried
   within the payload.


pwe3-sonet              Expires     July 2005               [Page 33]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


10.2.3.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
   [G.707]. 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 TUG-
   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.


10.2.3.2 Fractional VC-4 CEP Header

   The fractional VC-4 CEP header uses the VC-4 CEP header defined
   Section 3.3 in this draft.  Optionally, an additional 12 byte header
   extension word is added.  The extended header is described in Figure
   15.

     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 15 - Extended Fractional VC-4 Header


pwe3-sonet              Expires     July 2005               [Page 34]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005

   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 this draft 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 this draft) is used. The MSB bits of
           second and third words are always set to 1 to indicate that
           header is extended.

        -  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
   TUG-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 16.

        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 16 - 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. The VCs within the VUG-2 are numbered from
   right to left, starting from the first VC as the first bit on the

pwe3-sonet              Expires     July 2005               [Page 35]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   right. 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 000111011101110111011101110111.

   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.

10.2.3.3        B3 Compensation

   Fractional VC-4 encapsulation can be implemented in Line Terminating
   Equipment (LTE) or in Path Terminating Equipment (PTE). PTE
   implementations terminate the path layer at the ingress PE and
   generate a new path layer at the egress PE. LTE implementations do
   not terminate the path layer, and therefore need to keep the content
   and integrity of the POH bytes across the PSN. In LTE
   implementations, special care must be taken to maintain the B3 bit-
   wise parity POH byte. The same procedures for B3 compensation as
   described in section 7.2.1.2 for fractional STS-1 encapsulation are
   used.


10.2.3.4        Actual Payload Sizes

   The actual CEP payload size depends on the number of virtual
   tributaries carried within the fractional SPE. The contributions of
   each tributary to the fractional VC-4 payload length as well as the
   path overhead contribution are described below.

      Each VC-11                   contributes 27 bytes
      Each VC-12                   contributes 36 bytes
      Each VC-2                    contributes 108 bytes
      Each VC-3(T3)                contributes 738 bytes
      Each VC-3(E3)                contributes 576 bytes
      Each VC-3(uncompressed)      contributes 774 bytes
      VC-4 POH                     contributes 9 bytes

   The VC-3 contribution includes the AU-3 pointer. For example, the
   payload size of a fractional VC-4 configured to third-SPE
   encapsulation that carries a single compressed T3 VC-3 and 6 VC-12s
   would be: 321=(9 + 6*36 + 738) / 3 bytes payload per each packet.

pwe3-sonet              Expires     July 2005               [Page 36]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


11 Signaling of CEP Pseudo Wires

   [PWE3-CONTROL] specifies the use of the MPLS Label Distribution
   Protocol, LDP, as a protocol for setting up and maintaining pseudo
   wires. It enables LDP to identify pseudo-wires and to signal
   attributes of pseudo-wires. In particular it provides a way to bind
   a de-multiplexer field value to a pseudo-wire, specifies procedures
   for reporting pseudo-wire status changes and for releasing the
   bindings. [PWE3-CONTROL] assumes the pseudo-wire de-multiplexer
   field is an MPLS label; however the PSN tunnel itself can be either
   an IP or MPLS PSN.

   The use of LDP for setting up and maintaining CEP pseudo-wires is
   OPTIONAL. This section describes the use of the CEP-specific fields
   and error codes.

   The PW Type field in PWid FEC and PW generalized ID FEC elements
   MUST be set to SONET/SDH Circuit Emulation over Packet (CEP)[IANA].

   The control word is REQUIRED for CEP pseudo-wires. Therefore the
   C-bit in PWid FEC and PW generalized ID FEC elements MUST be set. If
   the C-bit is not set the pseudo-wire MUST not be established and a
   Label Release MUST be sent with an Illegal C-bit status code [IANA].

   The PWid FEC and PW generalized ID FEC elements can include one or
   more Interface Parameters fields. The Interface Parameters fields
   are used to validate that the two ends of the pseudo-wire have the
   necessary capabilities to interoperate with each other. The CEP
   specific Interface Parameters fields are the CEP/TDM Payload Bytes,
   the CEP Option and the CEP/TDM Bit Rate parameters.

11.1    CEP/TDM Payload Bytes

   This parameter MUST contain the expected CEP payload size in bytes.
   The payload size does not include network headers, control word or
   padding. If payload compression is used, the CEP/TDM Payload Bytes
   parameter MUST be set to the uncompressed payload size as if payload
   compression was disabled. In particular, when Fractional SPE (STS-
   1/VC-3 or VC-4) payload compression is used, the payload bytes
   parameter MUST be set to the payload size before removal of the
   unequipped VT containers and fixed value columns. Therefore, when
   fractional SPE mode is used, the actual (i.e. on the wire) packet
   length would normally be less than advertised, and in dynamic
   fractional SPE, even change while the connection is active.
   Similarly when DBA payload compression is used, the CEP/TDM Payload
   Bytes parameter MUST be set to the payload size prior to
   compression.

   The CEP/TDM Payload Bytes parameter is OPTIONAL. Default payload
   sizes are assumed if this parameter is not included as part of the
   Interface Parameters fields. The default payload size for VT is a
   single super frame. The default payload size for SPE is 783 bytes.

pwe3-sonet              Expires     July 2005               [Page 37]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



   A PE that receives a label-mapping message with request for a
   CEP/TDM Payload Bytes value that is not locally supported MUST
   return CEP/TDM mis-configuration status error code [IANA] and the
   pseudo wire MUST not be established.

11.2    CEP/TDM Bit Rate

   The CEP/TDM Bit Rate parameter MUST be set to the data rate in
   64Kbps units of the CEP payload. If payload compression is used, the
   CEP/TDM Bit Rate parameter MUST be set to the uncompressed payload
   data rate as if payload compression was disabled. Table 3 specifies
   the CEP/TDM Bit Rate parameters that MUST be set for each of the
   pseudo-wire circuits.

         +-----------------+---------------------------+
         |  Circuit        |   Bit Rate Parameter      |
         +-----------------+---------------------------+
         | VT1.5/VC-11     |   26                      |
         | VT2/VC-12       |   35                      |
         | VT3             |   53                      |
         | VT6/VC-2        |   107                     |
         | STS-Nc          |   783*N  N=1,3,12,48,192  |
         +-----------------+---------------------------+

                 Table 3 - CEP/TDM Bit Rates

   The CEP/TDM Bit Rate parameter is MANDATORY. Attempts to establish a
   pseudo-wire between two peers with different bit-rates MUST be
   rejected with incompatible bit rate status error code [IANA] and
   the pseudo wire MUST not be established.


11.3    CEP Options

   The CEP Options parameter is MANDATORY. The format of the CEP
   Options parameter is shown in Figure 17.

     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |AIS|UNE|RTP|EBM|MAH|    RESERVED [0:5]     | CEP Type  | Async |
   |   |   |   |   |   |                       |    [0:2]  |T3 |E3 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                      Figure 17 - CEP Options


   AIS - When set, indicates that the PE sending the label-mapping
   message is able to accept DBA packets with AIS indication.



pwe3-sonet              Expires     July 2005               [Page 38]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005

   UNE - When set, indicates that the PE sending the label-mapping
   message is able to accept DBA packets with unequipped indication.

   RTP - When set, indicates that RTP header is required.

   EBM - When set, indicates that EBM header is required.

   MAH - When set, indicates that CEP MPLS Adaptation Header is
   required.

   CEP Type - indicates the CEP connection type:

       0x0  SPE mode (STS-1/STS-Mc)
       0x1  VT mode (VT1.5/VT2/VT3/VT6)
       0x2  Fractional SPE (STS-1/VC-3/VC-4)

   Async Type - indicates the Async E3/T3 bandwidth reduction
   capabilities. Relevant only when CEP type is set to fractional SPE,
   and fractional SPE is expected to carry Asynchronous T3/E3
   payload:

   T3 - When set, indicates that the PE sending the label-mapping
   message is able to accept Fractional SPE packets with T3 bandwidth
   reduction.

   E3 - When set, indicates that the PE sending the label-mapping
   message is able to accept Fractional SPE packets with E3 bandwidth
   reduction.

   A PE that does not support the DBA option or one of the DBA sub
   option, can simply ignore label-mapping messages with either AIS or
   UNE bits set, and no further protocol action is required. A PE that
   is configured to use one of the DBA options but receives a label-
   mapping message indicating that its peer cannot process DBA packets
   MUST not use the DBA option, and SHOULD report the mismatch to the
   operator.

   A PE that does not support the Async bandwidth reduction mode can
   simply ignore label-mapping messages with either T3 or E-3 bits
   set, and no further protocol action is required. A PE that is
   configured to use one of the Async options but receives a label-
   mapping message indicating that its peer cannot process Async
   bandwidth reduction T3/E3 payloads MUST not use the Async option,
   and SHOULD report the mismatch to the operator.

   The setting of the CEP type, RTP, EBM and MAH bits MUST be
   consistent between peers. If a peer receives a label-mapping message
   with inconsistent setting compared with the local configuration, it
   MUST send a label-release message with status code of CEP/TDM
   mis-configuration [IANA], report to the operator and wait for a new
   (consistent) label mapping. A PE MUST send a new label-mapping
   message once it is re-configured or when it receives a label-mapping
   message from its peer with consistent configuration.

pwe3-sonet              Expires     July 2005               [Page 39]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005

12 Security Considerations

   The CEP encapsulation is subject to all of the general security
   considerations discussed in [PWE3-ARCH].  In addition, this document
   specifies only encapsulations, and not the protocols used to carry
   the encapsulated packets across the PSN.  Each such protocol may
   have its own set of security issues, but those issues are not
   affected by the encapsulations specified herein. Note that the
   security of the transported CEP service will only be as good as the
   security of the PSN.  This level of security may be less rigorous
   then that available from a native TDM service due to the inherent
   differences between circuit-switched and packet-switched public
   networks.

13 Intellectual Property Disclaimer

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

14 References

   Normative References

   [RFC2026] Bradner, S., The Internet Standards Process - Revision 3,
   BCP 9, RFC2026, October 1996.

   [RFC2119] Bradner, S., Key words for use in RFCs to Indicate
   Requirement Levels, BCP 14, RFC 2119, March 1997.

   [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation
   Edge-to-Edge (PWE3), RFC3916, September 2004.




pwe3-sonet              Expires     July 2005               [Page 40]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005

   [PWE3-TDM-REQ] Max Riegel, Requirements for Edge-to-Edge Emulation
   of TDM Circuits over Packet Switching Networks (PSN), Work in
   Progress, April 2004, draft-ietf-pwe3-tdm-requirements-05.txt.

   [PWE3-ARCH] Stewart Bryant and Prayson Pate, PWE3 Architecture, Work
   in progress, March 2004, draft-ietf-pwe3-arch-07.txt

   [PWE3-CONTROL] Martini et al, Pseudo-wire Setup and Maintenance
   using LDP, work in progress, December 2004, draft-ietf-pwe3-control-
   protocol-14.txt.

   [SONET] American National Standards Institute, Synchronous Optical
   Network (SONET) - Basic Description including Multiplex Structure,
   Rates and Formats, ANSI T1.105-2001.

   [GR253] Telcordia Technologies, Synchronous Optical Network (SONET)
   Transport Systems: Common Generic Criteria, GR-253-CORE, Issue 3,
   September 2000.

   [G.707] ITU-T Recommendation G.707, Network Node Interface For The
   Synchronous Digital Hierarchy, 2003.

   [G.783] ITU-T Recommendation G.783, Characteristics of synchronous
   digital hierarchy (SDH) equipment functional blocks, 2004.

   [G.806] ITU-T Recommendation G.806 Characteristics of transport
   equipment-Description methodology and generic functionality (2004).

   [G.784] ITU-T Recommendation G.784, Synchronous Digital Hierarchy
   (SDH) management, 1999.

   [RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-
   Time Applications, RFC 1889, IETF, 1996


   Informative References


   [CEP-MIB] Danenberg et al, SONET/SDH Circuit Emulation Service Over
   PSN (CEP) Management Information Base Using SMIv2,draft-ietf-pwe3-
   cep-mib-04.txt, work in progress, December 2003.

   [RFC2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for
   Low-Speed Serial Links, RFC 2508, IETF, 1999

   [RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC):
   Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC
   3095, IETF, 2001

   [AAL1] ITU-T, Recommendation I.363.1, B-ISDN Adaptation Layer
   Specification: Type AAL1, Appendix III, August 1996.



pwe3-sonet              Expires December 2003               [Page 41]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   [IANA] Luca Martini and Mark Townsley, IANA Allocations for pseudo
   Wire Edge to Edge Emulation (PWE3), Work in Progress, October 2004,
   draft-ietf-pwe3-iana-allocation-07.txt.

   [L2TPv3] Layer Two Tunneling Protocol (Version 3) 'L2TPv3', J Lau,
   et. al., work in progress, December 2004, draft-ietf-l2tpext-l2tp-
   base-15.txt.


15 Author Information

   Andrew G. Malis
   Tellabs, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   Email: Andy.Malis@tellabs.com

   Ken Hsu
   Tellabs, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   Email: Ken.Hsu@tellabs.com

   Jeremy Brayley
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   Email: jbrayley@laurelnetworks.com

   Steve Vogelsang
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   Email: sjv@laurelnetworks.com

   John Shirron
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   Email: jshirron@laurelnetworks.com

   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   Email: lmartini@cisco.com




pwe3-sonet              Expires     July 2005               [Page 42]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005

   Tom Johnson
   Litchfield Communications, Inc.

   Ed Hallman
   Litchfield Communications, Inc.

   Marlene Drost
   Litchfield Communications, Inc.

   Jim Boyle
   Juniper Networks, Inc.
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089

   David Zelig
   Corrigent Systems
   126, Yigal Alon st.
   Tel Aviv, ISRAEL
   Email: davidz@corrigent.com

   Ron Cohen
   Resolute Networks, Inc.
   2480 Sand Hill Road, suite 200
   Menlo-Park, CA, 94025
   Email: ronc@resolutenetworks.com

   Prayson Pate
   Overture Networks, Inc.
   507 Airport Blvd, Suite 111
   Morrisville, NC, USA 27560
   Email: prayson.pate@overturenetworks.com

   Craig White
   Level3 Communications, LLC.
   1025 Eldorado Blvd,
   Broomfield CO 80021
   Email: Craig.White@Level3.com

















pwe3-sonet              Expires     July 2005               [Page 43]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   Appendix A. SONET/SDH Rates and Formats

   For simplicity, the discussion in this section uses SONET
   terminology, but it applies equally to SDH as well.  SDH-equivalent
   terminology is shown in the tables.

   The basic SONET modular signal is the synchronous transport signal-
   level 1 (STS-1). A number of STS-1s may be multiplexed into higher-
   level signals denoted as STS-N, with N synchronous payload envelopes
   (SPEs). The optical counterpart of the STS-N is the Optical Carrier-
   level N, or OC-N. Table 4 lists standard SONET line rates discussed
   in this document.


     OC Level          OC-1    OC-3    OC-12      OC-48     OC-192
     SDH Term             -   STM-1    STM-4     STM-16     STM-64
     Line Rate(Mb/s) 51.840 155.520  622.080  2,488.320  9,953.280

                   Table 4 - Standard SONET Line Rates

   Each SONET frame is 125us and consists of nine rows. An STS-N frame
   has nine rows and N*90 columns. Of the N*90 columns, the first N*3
   columns are transport overhead and the other N*87 columns are SPEs.
   A number of STS-1s may also be linked together to form a super-rate
   signal with only one SPE. The optical super-rate signal is denoted
   as OC-Nc, which has a higher payload capacity than OC-N.

   The first 9-byte column of each SPE is the path overhead (POH) and
   the remaining columns form the payload capacity with fixed stuff
   (STS-Nc only).  The fixed stuff, which is purely overhead, is N/3-1
   columns for STS-Nc.  Thus, STS-1 and STS-3c do not have any fixed
   stuff, STS-12c has three columns of fixed stuff, and so on.

   The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The
   payload capacity of an STS-1 is 86 columns (774 bytes) per frame.
   The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame.
   Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340
   bytes per frame. As another example, the payload capacity of an STS-
   192c is 149,760 bytes, which is 64 times the capacity of an STS-3c.

   There are 8,000 SONET frames per second. Therefore, the SPE size,
   (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112
   Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame
   or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760
   bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 5
   lists the SPE and payload rates supported.







pwe3-sonet              Expires     July 2005               [Page 44]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005




   SONET STS Level     STS-1   STS-3c  STS-12c    STS-48c   STS-192c
   SDH VC Level            -     VC-4  VC-4-4c   VC-4-16c   VC-4-64c
   Payload Size(Bytes)   774    2,340    9,360     37,440    149,760
   Payload Rate(Mb/s) 49.536  149.760  599.040  2,396.160  9,584.640
   SPE Size(Bytes)       783    2,349    9,396     37,584    150,336
   SPE Rate(Mb/s)     50.112  150.336  601.344  2,405.376  9,621.504

                 Table 5 - Payload Size and Rate

   To support circuit emulation, the entire SPE of a SONET STS or SDH
   VC level is encapsulated into packets, using the encapsulation
   defined in section 4, for carriage across packet-switched networks.

   VTs are organized in SONET super-frames, where a SONET super-frame
   is a sequence of four SONET SPEs.  The SPE path overhead byte H4
   indicates the SPE number within the super-frame. The VT data can
   float relative to the SPE position.  The 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.
































pwe3-sonet              Expires     July 2005               [Page 45]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005


   Appendix B:  Example Network Diagrams

   Figure 18 below illustrates a SONET interconnect example.  Site A
   and Site B are connected back to a Hub Site, Site C by means of a
   SONET infrastructure.  The OC12 from Site A and the OC12 from Site B
   are partially equipped.  Each of them is transported through a SONET
   network back to a hub site (C).  Equipped SPEs (or VTs) are then
   groomed onto the OC-12 towards site C.


                             SONET Network
                           ____     ___       ____
                         _/    \___/   \    _/    \__
    +------+ Physical    /               \__/         \
    |Site A|    OC-12   /    +---+     OC-12           \       Hub Site
    |      |=================|\S/|-------------+-----+  \      +------+
    |      |           \     |/ \|=============|\   /|   \     |      |
    +------+           /\    +---+-------------| \ / |  / OC12 |      |
                      /                        |  S  |=========|Site C|
    +------+ Physical/       +---+-------------| / \ |  \      |      |
    |Site B|   OC-12 \       |\S/|=============|/   \|   \     |      |
    |      |=================|/ \|-------------+-----+   /     +------+
    |      |          \      +---+     OC12      __     /
    +------+           \                      __/  \   /
                        \   ___      ___     /      \_/
                         \_/   \____/   \___/

                 Figure 18 - SONET Interconnect Example Diagram

























pwe3-sonet              Expires     July 2005               [Page 46]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



   Figure 19 below illustrates the same pair of OC12s being emulated
   over a PSN.  This configuration frees up bandwidth in the grooming
   network, since only equipped SPEs (or VTs) are sent through the PSN.
   Additional bandwidth savings can be realized by taking advantage of
   the various payload compression options described in section 10.

                            SONET/TDM/Packet Network
                           ____     ___       ____
                          /    \___/   \     /    \__
     +------+ Physical   /+-+            \__/         \_
     |Site A|    OC12   / | | +---+                     \      Hub Site
     |      |=============|P|=| R |   +---+ +-+ +-----+  \     +------+
     |      |           \ |E| |   |===|   | | |=|\   /|   \    |      |
     +------+           /\+-+ +---+   |   | | | | \ / |  / OC12|      |
                       /              | R |=|P| |  S  |========|Site C|
     +------+ Physical/   +-+ +---+   |   | |E| | / \ |  \     |      |
     |Site B|    OC12 \   |P| | R |===|   | | |=|/   \|   \    |      |
     |      |=============|E|=|   |   +---+ +-+ +-----+   /    +------+
     |      |          \  | | +---+               __     /
     +------+           \ +-+                  __/  \   /
                         \   ___      ___     /      \_/
                          \_/   \____/   \___/

          Figure 19 - SONET Interconnect Emulation Example Diagram


   Figure 20 below shows an example of T1 grooming into OC-12 in access
   networks. The VT encapsulation is used to transport the T1s from the
   Hub site to customer sites, maintaining SONET/SDH OA&M.



                          SONET/TDM/Packet Network
                           ____     ___       ____
                         _/    \___/   \    _/    \__
     +------+ Physical   /+-+            \__/         \_
     |Site A|    T1     / | | +---+                     \      Hub Site
     |      |=============|P|=| R |   +---+ +-+ +-----+  \     +------+
     |      |           \ |E| |   |===|   | | |=|\   /|   \    |      |
     +------+           /\+-+ +---+   |   | | | | \ / |  / OC12|      |
                       /              | R |=|P| |  S  |========|Site C|
     +------+ Physical/   +-+ +---+   |   | |E| | / \ |  \     |      |
     |Site B|    T1   \   |P| | R |===|   | | |=|/   \|   \    |      |
     |      |=============|E|=|   |   +---+ +-+ +-----+   /    +------+
     |      |          \  | | +---+               __     /
     +------+           \ +-+                  __/  \   /
                         \   ___      ___     /      \_/
                          \_/   \____/   \___/

          Figure 20 - T1 to OC-12 Grooming Emulation Example Diagram


pwe3-sonet              Expires     July 2005               [Page 47]

Internet Draft         draft-ietf-pwe3-sonet-10          February 2005



Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

   The authors would like to thank the members of the PWE3 working group
   for their assistance on this draft. We thank Sasha Vainshtein,
   Deborah Brungard, Juergen Heiles and Nick Weeds for their review
   and valuable feedback.





























pwe3-sonet              Expires     July 2005               [Page 48]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/