[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                                   Vivace Networks, Inc.
Expiration Date: July 2003
                                                         Prayson Pate
                                              Overture Networks, Inc.

                                                          January 2003

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



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

   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 has 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).










pwe3-sonet                Expires July 2003                  [Page 1]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



   Co-Authors

   The following individuals are co-authors of this document

   Craig White          Level3 Communications
   David Zelig          Corrigent Systems
   Ed Hallman           Litchfield Communications
   Jeremy Brayley       Laurel Networks
   Jim Boyle            Protocol Driven Networks
   John Shirron         Laurel Networks
   Luca Martini         Level3 Communications
   Marlene Drost        Litchfield Communications
   Ron Cohen            Lycium Networks
   Steve Vogelsang      Laurel Networks
   Tom Johnson (Editor) Litchfield Communications


   Table of Contents

   1    Conventions used in this document                2
   2    Acronyms                                         3
   3    Scope                                            4
   4    CEP Encapsulation Format                         5
   4.1  SONET/SDH Fragment                               6
   4.2  CEP Header                                       7
   4.3  RTP Header                                       9
   4.4  PSN Encapsulation                               10
   4.5  L2TP Encapsulation                              13
   5    SONET/SDH Transport Timing                      14
   6    SONET/SDH Pointer Management                    14
   6.1  Explicit Pointer Adjustment Relay (EPAR)        14
   6.2  Adaptive Pointer Management (APM)               15
   7    CEP Performance Monitors                        15
   7.1  Near-End Performance Monitors                   16
   7.2  Far-End Performance Monitors                    17
   8    Payload Compression Options                     17
   8.1  Dynamic Bandwidth Allocation                    18
   8.2  Service-Specific Payload Formats                19
   9    Open Issues                                     26
   10   Security Considerations                         27
   11   Intellectual Property Disclaimer                27
   12   References                                      27
   13   Author's Addresses                              29


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 2003                  [Page 2]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


2  Acronyms

   ADM    Add Drop Multiplexer

   AIS    Alarm Indication Signal

   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 - see [CEP-SPE]

   EBM    Equipped Bit Mask

   LOF    Loss of Frame

   LOS    Loss of Signal

   LTE    Line Terminating Equipment

   PSN    Packet Switched Network

   POH    Path Overhead

   PTE    Path Terminating Equipment

   PWE3   Pseudo-Wire Emulation Edge-to-Edge

   RDI    Remote Defect Indication

   SDH    Synchronous Digital Hierarchy

   SONET  Synchronous Optical Network

   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)


pwe3-sonet                Expires July 2003                  [Page 3]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


   VC-n   Virtual Container-n (SDH)

   VT     Virtual Tributary (SONET)

   VTG    Virtual Tributary Group (SONET)


3  Scope

   This document describes how to emulate the following digital signals
   over a packet switched network:

   1. Synchronous Payload Envelope (SPE): 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): 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 2003                  [Page 4]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




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.  The resulting packet is
   encapsulated in RTP for transmission over an arbitrary PSN.

   (Note: under certain circumstances the RTP header may be suppressed
   to conserve network bandwidth.  See section 4.4.3 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 2003                  [Page 5]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




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.

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

   VT emulation implementations MUST support payload size of 1/4 VT
   superframe fragment, and MAY support 1/2 and full VT superframe
   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 Appendix
   B.






pwe3-sonet                Expires July 2003                  [Page 6]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




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 TDM SONET over a PSN if a common reference is available at
   both ends of the PW.

   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 Appendix B.

   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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |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.  MUST be set to zero for Normal Operation.
   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 1 and section 8.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 1 and section 6.1 for more details.









pwe3-sonet                Expires July 2003                  [Page 7]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




         +---+---+---+----------------------------------------------+
         | 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    - STS Unequipped                 |
         | 1 | 0 | 1 | DBA Mode    - STS Unequipped Pos Ptr Adj     |
         | 1 | 1 | 0 | DBA Mode    - STS Unequipped Neg Ptr Adj     |
         | 1 | 1 | 1 | DBA Mode    - AIS-P/V                          |
         +---+---+---+----------------------------------------------+


   Table 1 - 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 2003                  [Page 8]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




4.3 RTP Header

   CEP uses the fixed 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) always set to 2

   P : (padding) always set to 0

   X : (header extension) always set to 0

   CC: (CSRC count) always set to 0

   M : (marker) set to 0 for CEP packets.

   PT: (payload type) used to identify packets carrying the packetized
   SONET/SDH data.  One PT value should be allocated from the range of
   dynamic values (see [RTP-TYPES]) for every CEP PW. Allocation is
   done during the PW setup and MUST be the same for both PW
   directions. The PE at the PW ingress MUST set the PT value in the
   RTP header to the allocated value.

   Sequence Number : used primarily to provide 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].

   Timestamp : 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 : (synchronization source) MAY be used for detection of
   misconnections.







pwe3-sonet                Expires July 2003                  [Page 9]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




4.4 PSN Encapsulation

   In principle, CEP packets can be carried over any packet-oriented
   network.  The following sections describe specifically how CEP
   packets MUST be 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 Demultiplex
   individual SONET channels.

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


   Figure 4 - IP Transport Encapsulation


















pwe3-sonet                Expires July 2003                 [Page 10]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



4.4.2   MPLS Encapsulation

   RTP MAY be directly encapsulated in MPLS as shown below.  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 demultiplex individual SONET
   channels.  In keeping with the conventions used in [PWE3-CONTROL],
   this demultiplexing label is referred to as the PW Label and the
   upper labels are referred to as Tunnel Labels.


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


   Figure 5 - Typical MPLS Transport Encapsulation
























pwe3-sonet                Expires July 2003                 [Page 11]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



4.4.3   RTP Header Suppression

   In addition to normal RTP header compression mechanisms as described
   in [RFC2508] and [RFC3095], an additional option may be used in CEP
   which suppresses transmission of the RTP header altogether.

   This mode may be used when both SONET Emulation PEs have access to a
   common reference clock and both support RTP Header Suppression.
   Under these conditions the following encapsulation formats may be
   used.

   The choice to utilize RTP Header Suppression may be statically
   configured using [CEM-MIB], or signaled using a PW maintenance
   protocol such as [PWE3-CONTROL].

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

   Figure 6 - IP Transport Encapsulation w/ RTP Header Suppression





















pwe3-sonet                Expires July 2003                 [Page 12]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




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


   Figure 7 - MPLS Transport Encapsulation w/ RTP Header Suppression


4.5 L2TP Encapsulation

   Encapsulation for L2TP PSNs is for future study.






























pwe3-sonet                Expires July 2003                 [Page 13]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




5  SONET/SDH Transport Timing

   It is assumed that the distribution of SONET/SDH Transport timing
   information is addressed 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 addressed through an adaptive timing
   recovery algorithm, and is therefore outside of the scope of this
   specification.


6  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], and [G707].  If there is a frequency offset
   between the frame rate of the transport overhead and that of the
   SONET/SDH SPE, 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 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 [G707].


6.1 Explicit Pointer Adjustment Relay (EPAR)




pwe3-sonet                Expires July 2003                 [Page 14]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


   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).  The mechanics of EPAR are described below.

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

   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 superframe, starting from the
   packet carrying the V5 byte and not including the packet carrying
   the V5 byte of the next VT superframe. 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
   STS-1 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 1 and section Appendix C for more details.


6.2 Adaptive Pointer Management (APM)

   Another OPTIONAL method that may be used to emulate SONET 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 SPE.

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


7  CEP Performance Monitors

   SONET/SDH as defined in [SONET], [GR253], and [G707] includes the
   definition of several counters that may be used to monitor the


pwe3-sonet                Expires July 2003                 [Page 15]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


   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.


7.1 Near-End Performance Monitors

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

   The performance monitors are based on two types of defects.

   Type 1 defect is defined as: missing or dropped packet.
   Type 2 defect is defined as: buffer under run, buffer over-run,
   LOPS.

   The specific performance monitors that are 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 type 2 defect, or missing packets above
   pre-defined, configurable threshold of missing/dropped packets SHALL
   be declared both SES-CEP and ES-CEP.  Default value for missing
   packet to SES is 3.

   UAS-CEP SHALL be declared after X consecutives SES-CEP, cleared
   after X consecutive seconds without SES-CEP.  Default value of X 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 that occurred along the X seconds
   clearing period SHALL be added to the ES counts. An update is
   required even for closed intervals if  necessary.

   FC-CEP is the number of time type 1 or type 2 defect states were
   declared.  The NE SHALL have thresholding on ES-CEP, SES-CEP and
   UAS-CEP (thresholding mean activate a notification if more than pre-
   defined # of seconds are declared as ES, etc. in 15 minutes
   interval).


pwe3-sonet                Expires July 2003                 [Page 16]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


7.2 Far-End Performance Monitors

   These performance monitors provide insight into the CEM De-
   packetizer at the far-end of the PSN.

   Far end statistics are based on the RDI-CEP bit. Limited
   functionality is supported compared to [GR-253] for simplicity and
   because it is assumed that all relevant statistics are available
   from the end point of the PW. CEP-FE defect is declared when CEP-RDI
   is set in the incoming CEP packets.

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

   This draft does not attempt to define SES-CEPFE, UAS-CEPFE and FC-
   CEPFE, but they can be added if to fully emulate GR-253 far end PM
   (thresholding is required too here except for FC-CEPFE). (Note that
   ES-CEPFE is not relevant since CEP does not report back missing
   packets - only LOPS which is SES).

   The definition of additional performance monitors is for future
   study.



8  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 suppresses transmission of the CEP
   payload altogether under certain circumstances such as AIS-P/V and
   STS/VT Unequipped.  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.













pwe3-sonet                Expires July 2003                 [Page 17]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




8.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 a PW ingress, the CEP packets
   will be constructed as shown in figure C.1.

   Optional padding bytes may be included if the intervening packet
   network has a minimum packet size which is less than the DBA packet.

             +-----------------------------------+
             |   PSN and Multiplexing Layer      |
             |             Headers               |
             +-----------------------------------+
             |           RTP Header              |
             |           (RFC1889)               |
             +-----------------------------------+
             |           CEP Header              |
             +-----------------------------------+
             |       (Optional) Padding          |
             +-----------------------------------+

   Figure 8 - Basic CEP-DBA Packet


   If RTP Header suppression is utilized, the CEP packets will be
   constructed as shown in figure A2.2

             +-----------------------------------+
             |   PSN and Multiplexing Layer      |
             |             Headers               |
             +-----------------------------------+
             |           CEP Header              |
             +-----------------------------------+
             |       (Optional) Padding          |
             +-----------------------------------+

   Figure 9 - CEP-DBA Packet with RTP Header Suppression

   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.


pwe3-sonet                Expires July 2003                 [Page 18]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003






8.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:

8.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). 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 21 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


pwe3-sonet                Expires July 2003                 [Page 19]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



   Figure 10 - SONET SPE Mapping of VT1.5

   The SPE always contains seven interleaved VT groups (VTGs). Each VTG
   contains a single type of VT, and each VTG occupies 12 columns (108
   bytes) within each SPE.  A VTG can contain 4 VT1.5s (T1s), 3 VT2s
   (E1s), 2 VT3s or a single VT6.  Altogether, the SPE can carry 28 T1s
   or carry 21 E1s.

   The fractional STS-1 encapsulation 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.


8.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 23.

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

pwe3-sonet                Expires July 2003                 [Page 20]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


           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.

   The format of the EBM is defined in Figure 24.

          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 12 - Equipped Bit Mask (EBM) for fractional STS-1


   The 28 bits of the EBM are divided into groups of 4 bits, each
   corresponding to a different VTG within the STS container. All 4 bits
   are used to indicate whether VT1.5 (T1) tributaries are carried
   within a VTG.  The first 3 bits read from right to left are used to
   indicate whether VT2 (E1) tributaries are carried within a VTG.  For
   example, the EBM of a fully occupied STS-1 with VT1.5 is all ones,
   while that of an STS-1 fully occupied with VT2 (E1) tributaries has
   the binary value 0111011101110111011101110111.


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

   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

pwe3-sonet                Expires July 2003                 [Page 21]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


        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.

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

   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

   Figure 13 - Fixed columns removed within T3 mapping to STS-1

   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.

   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.

   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, 81



pwe3-sonet                Expires July 2003                 [Page 22]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



   Figure 14 - Fixed columns removed within E3 mapping to VC-3

   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.

   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. The actual payload size are smaller and are
   described in appendix B.


8.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 <---- DS-2
                               |
                               +----x3---- TU-12 <-- VC-12<---- E1
                               |
                               +----x4---- TU-11 <-- VC-11<---- T1


   Figure 15 - Mapping of VCs into VC-4

   Figure 27 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


pwe3-sonet                Expires July 2003                 [Page 23]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


   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 7.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. The possible actual payload sizes are described
   in appendix B.


8.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
   [G707]. The first two columns of the TUG-3 are fixed and therefore
   removed in the fractional VC-4 encapsulation. The 7 TUG-2, each 12
   columns wide, are byte multiplexed starting from column 3 of the 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.


8.2.3.2 Fractional VC-4 CEP Header

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

pwe3-sonet                Expires July 2003                 [Page 24]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



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

   The following fields are used within the extended header:

        -  R, D, N, P, Structured Pointer and Sequence Number: All
           fields are used as defined in 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 bit of
           word two and three is 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 29.

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

pwe3-sonet                Expires July 2003                 [Page 25]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



   Figure 17 - Equipped Bit Mask (EBM) for fractional VC-4

   The 30 bits of the EBM are divided into two bits that control the VC-
   3 within the TUG-3 and 7 groups of 4 bits, each corresponding to a
   different TUG-2 within the TUG-3 container.

   For a TUG-3 containing TUG-2, the first two A and T bits MUST be set
   to zero. The TUG-2 bits indicate whether the VCs within the TUG-2 are
   equipped. All 4   bits are used to indicate whether VC11 (T1)
   tributaries are carried within a TUG-2.  The first 3 bits read right
   to left are used to indicate whether VC12 (E1) tributaries are
   carried within a TUG-2. The first bit is used to indicate a VC-2 is
   carried within a TUG-2. For example, 28 bits of the EBM of a fully
   occupied TUG-3 with VC11 is all ones, while that of a TUG-3 fully
   occupied with VC12 (E1) tributaries has the binary value
   0111011101110111011101110111.

   For a TUG-3 containing VC-3, all TUG-2 bits MUST be set to zero. The
   A and T bits are defined as follows:

   T : TUG-3 carried bit. If set to 1, the VC-3 payload is carried
   within the TUG-3 container. If set to 0, all the TUG-3 columns are
   not carried within the fractional VC-4 encapsulation. The TUG-3
   columns are removed either because the VC-3 is unequipped or in AIS
   mode.

   A: VC-3 AIS bit. The A bit MUST be set to 0 when the T bit is 1 (i.e.
   when the TUG-3 columns are carried within the fractional VC-4
   encapsulation). The A bit indicate the reason for removal of the
   entire TUG-3 columns. If set to 0, the TUG-3 columns were removed
   because the VC-3 is unequipped. If set to 1, the TUG-3 columns were
   removed because the VC-3 is in AIS mode.


8.2.3.3 B3
   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.


9  Open Issues




pwe3-sonet                Expires July 2003                 [Page 26]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


   This version of the draft does not tie into PWE3 maintenance
   mechanisms for the setup and tear down of services.  That short-
   coming will be addressed in future revisions of this document.

   Underlying MPLS QoS requirements are not covered by this revision of
   the draft.  Future revisions may discuss underlying QoS
   requirements.

   An alternate version of DBA has been suggested that would suppress
   transmission of the entire CEP packet stream under certain
   circumstances.  Future versions of this draft may define such a
   mechanism.

   It is possible to define SONET Emulation specific redundancy
   mechanisms, such as 1+1 or N:1.  Future versions of this draft may
   define such mechanisms.


10 Security Considerations

   This document does not address or modify security issues within the
   relevant PSNs.



11 Intellectual Property Disclaimer

   This document is being submitted for use in IETF standards
   discussions.  Vivace Networks, Inc. has filed one or more patent
   applications relating to the CEP technology outlined in this
   document.  Vivace Networks, Inc. will grant free unlimited licenses
   for use of this technology. Also, Lycium Networks has filed one or
   more patent applications that may be related to the CEP technology
   outlined in this document.  Lycium Networks grants free unlimited
   licenses for use of this technology.

12 References

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

   [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation
   Edge-to-Edge (PWE3), Work in Progress, July-2001, draft-ietf-pwe3-
   requirements-01.txt

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

   [PWE3-ARCH] Stewart Bryant and Prayson Pate, PWE3 Architecture, Work
   in progress, November 2002, draft-ietf-pwe3-arch-01.txt


pwe3-sonet                Expires July 2003                 [Page 27]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



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

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

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

   [G707] ITU Recommendation G.707, "Network Node Interface For The
   Synchronous Digital Hierarchy", 1996.

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

   [ROHC-LLA] Lars-Eric Jonsson et al, A Link-Layer Assisted ROHC
   Profile for IP/UDP/RTP draft-ietf-rohc-rtp-lla-03.txt.

   [CEP-MIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over
   PSN (CEP) Management Information Base Using SMIv2", draft-danenberg-
   pw-cem-mib-02.txt, work in progress, Feb 2002.

   [PWE3-CONTROL] Martini et al, " Transport of Layer 2 Frames Over
   MPLS", draft-ietf-pwe3-control-protocol-01.txt, work in progress,
   November 2002.

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

   [T1.403] ANSI, "Network and Customer Installation Interfaces - DS1
   Electrical Interfaces", T1.403-1999, May 24, 1999.













pwe3-sonet                Expires July 2003                 [Page 28]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




13 Author's Addresses

   Andrew G. Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   Email: Andy.Malis@vivacenetworks.com

   Ken Hsu
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   Email: Ken.Hsu@vivacenetworks.com

   Jeremy Brayley
   Laurel Networks, Inc.
   2706 Nicholson Rd.
   Sewickley, PA 15143
   Email: jbrayley@laurelnetworks.com

   Steve Vogelsang
   Laurel Networks, Inc.
   2706 Nicholson Rd.
   Sewickley, PA 15143
   Email: sjv@laurelnetworks.com

   John Shirron
   Laurel Networks, Inc.
   2607 Nicholson Rd.
   Sewickley, PA 15143
   Email: jshirron@laurelnetworks.com

   Luca Martini
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO 80021
   Email: luca@level3.net

   Tom Johnson (Editor)
   Litchfield Communications, Inc.
   76 Westbury Park Rd.
   Watertown, CT 06795
   Email: tom_johnson@litchfieldcomm.com

   Ed Hallman
   Litchfield Communications, Inc.
   76 Westbury Park Rd.
   Watertown, CT 06795
   Email: ed_hallman@litchfieldcomm.com


pwe3-sonet                Expires July 2003                 [Page 29]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


   Marlene Drost
   Litchfield Communications, Inc.
   76 Westbury Park Rd.
   Watertown, CT 06795
   Email: marlene_drost@litchfieldcomm.com

   Jim Boyle
   Protocol Driven Networks, Inc.
   1381 Kildaire Farm #288
   Cary, NC 27511
   Email: jboyle@pdnets.com

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

   Ron Cohen
   Lycium Networks
   14 Hatidhar St., P.O.Box 2088
   Ra'anana 43000, Israel
   Email: ronc@lyciumnetworks.com

   Prayson Pate
   Overture Networks
   P. O. Box 14864
   RTP, NC, USA 27709
   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 2003                 [Page 30]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


   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 2 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 2 - Standard SONET Line Rates

   Each SONET frame is 125 us 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 2
   lists the SPE and payload rates supported.








pwe3-sonet                Expires July 2003                 [Page 31]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003




   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 3 - 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 superframes, where a SONET superframe is
   a sequence of four SONET SPEs.  The SPE path overhead byte H4
   indicates the SPE number within the superframe. 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.

   Table 3 below indicates the number of bytes occupied by a VT within
   a superframe.

        Mapping         VT size           Reference
       -------------------------------------------------------------
        VT1.5/VC-11   104 bytes           [GR253] Section  3.4.1.1
        VT2/VC-12     140 bytes           [G.707] Section 10.1.4.1
        VT3           212 bytes           [GR253] Section  3.4.1.3
        VT6/VC-2      428 bytes           [GR253] Section  3.4.1.4


   Table 4 - Number of Bytes in a VT Superframe


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















pwe3-sonet                Expires July 2003                 [Page 32]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



   Appendix B. Payload sizes

   CEP packets are normally fixed in length for all packets of a
   particular emulated SONET/SDH stream.  The exceptions are DBA CEP
   packets and on the fly compression within the fractional STS-1/VC-
   3/VC-4 mode.  When the fractional encapsulation does not carry the
   equipped flag indications, the EBM to be transmitted MUST be
   statically provisioned at both ends.  The length of each CEP packet
   does not need to be carried in the CEP header because it can be
   uniquely determined for each CEP packet as a function of the
   provisioned payload size, the type of VTs carried within the STS-1
   signal, the DBA indication and the equipped flags (either
   dynamically or statically provisioned).

   The following payload lengths can be statically provisioned for
   fractional STS-1 encapsulations:

       1. Full SPE length (783 bytes)
       2. Third of SPE length (261 bytes)

   The actual payload sizes would be smaller, depending on the number
   of virtual tributaries carried within the fractional SPE.  Figure 21
   provides the actual payload length as a function of N, the number of
   tributaries carried within the fractional STS-1. In particular, when
   all VTs are equipped, the fractional STS-1 full SPE payload size is
   765 bytes.

              VT Type       Full SPE     SPE/3
          ----------------------------------------------
              VT1.5 (T1)    27*N+9       9*N+3    N=0..28
              VT2 (E1)      36*N+9       12*N+3   N=0..21

   Figure 18 - Fractional STS-1 Actual Payload Size

   The following payload lengths can be statically provisioned for
   fractional VC-4 encapsulation:

      1. Full SPE length (2349 bytes)
      2. 8/9 SPE length  (2088 bytes)
      3. 7/9 SPE length  (1827 bytes)
      4. 6/9 SPE length  (1566 bytes)
      5. 5/9 SPE length  (1305 bytes)
      6. 4/9 SPE length  (1044 bytes)
      7. 1/3 SPE length  (783 bytes)

   The actual payload sizes would be smaller, depending on the number
   of virtual tributaries carried within the fractional SPE. Each
   equipped VC contributes the following number of bytes per SPE:

      Each VC-11       contributes 27 bytes
      Each VC-12       contributes 36 bytes
      Each VC-2        contributes 108 bytes

pwe3-sonet                Expires July 2003                 [Page 33]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003


      Each VC-3(DS-3)  contributes 738 bytes (including pointers)
      Each VC-3(E-3)   contributes 576 bytes (including pointers)
      Each VC-3(not compressed) contributes 774 bytes (including
   pointers)

   Figure 19 - Fractional VC-4 Actual Payload Size

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

    The following payload lengths can be statically provisioned for
   asynchronous T3/E3 STS-1/VC-3 encapsulations:

       1. Full SPE length (783 bytes)
       2. Third of SPE length (261 bytes)

   The actual payload sizes would be smaller as described in figure 23.

                Signal        Full SPE     SPE/3
          ----------------------------------------------
                  T3            729        243
                  E3            567        189

   Figure 20 - Asynchronous T3/E3 STS-1/VC-3 Actual Payload Size




























pwe3-sonet                Expires July 2003                 [Page 34]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



   Appendix C:  Example Network Diagram

   Figure 7 below shows an example of SONET interconnect.  Site A and
   Site B are connected back to a Hub Site, Site C by means of a SONET
   infrastructure.  The OC3 from Site A and the OC12 from Site B are
   partially equipped.  Each of them is transported through a SONET
   network back to a hubbing 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 21 - SONET Interconnect Example Diagram

























pwe3-sonet                Expires July 2003                 [Page 35]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003



   Figure 8 below shows 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 8.

                            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 22 - SONET Interconnect Emulation Example Diagram





























pwe3-sonet                Expires July 2003                 [Page 36]

Internet Draft         draft-ietf-pwe3-sonet-01           January 2003






Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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



















pwe3-sonet                Expires July 2003                 [Page 37]


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