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

Versions: (draft-riegel-pwe3-tdm-requirements) 00 01 02 03 04 05 06 07 08 RFC 4197

Network Working Group                                     M. Riegel, Ed.
Internet-Draft                                                Siemens AG
Expires: October 12, 2005                                 April 10, 2005


  Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet
                           Switching Networks
                draft-ietf-pwe3-tdm-requirements-08.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on October 12, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines the specific requirements for edge-to-edge
   emulation of circuits carrying Time Division Multiplexed (TDM)
   digital signals of the Plesiochronous Digital Hierarchy as well as
   the Synchronous Optical NETwork/Synchronous Digital Hierarchy over
   packet-switched networks.  It is aligned to the common architecture
   for Pseudo Wire Emulation Edge-to-Edge (PWE3).
   It makes references to the generic requirements for PWE3 where
   applicable and complements them by defining requirements originating
   from specifics of TDM circuits.



Riegel                  Expires October 12, 2005                [Page 1]

Internet-Draft            PWE3 TDM Requirements               April 2005



Contributors Section

   The following have contributed to this document:

   Sasha Vainshtein          Axerra Networks
   sasha@axerra.com

   Yaakov Stein              RAD Data Communication
   yaakov_s@rad.com

   Prayson Pate              Overture Networks, Inc.
   prayson.pate@overturenetworks.com

   Ron Cohen                 Lycium Networks
   ronc@lyciumnetworks.com

   Tim Frost                 Zarlink Semiconductor
   tim.frost@zarlink.com


Changes from the last revision:

   - Expanded security considerations section due to IESG review



























Riegel                  Expires October 12, 2005                [Page 2]

Internet-Draft            PWE3 TDM Requirements               April 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   TDM circuits belonging to the PDH hierarchy  . . . . . . .  4
       1.1.1   TDM structure and transport modes  . . . . . . . . . .  5
     1.2   SONET/SDH circuits . . . . . . . . . . . . . . . . . . . .  5
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Reference Models . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1   Generic PWE3 Models  . . . . . . . . . . . . . . . . . . .  8
     4.2   Clock Recovery . . . . . . . . . . . . . . . . . . . . . .  8
     4.3   Network Synchronization Reference Model  . . . . . . . . .  8
       4.3.1   Synchronous Network Scenarios  . . . . . . . . . . . . 11
       4.3.2   Relative Network Scenario  . . . . . . . . . . . . . . 13
       4.3.3   Adaptive Network Scenario  . . . . . . . . . . . . . . 13
   5.  Emulated Services  . . . . . . . . . . . . . . . . . . . . . . 14
     5.1   Structure-Agnostic Transport of signals out of the PDH
           hierarchy  . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.2   Structure-Aware Transport of signals out of the PDH
           hierarchy  . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.3   Structure-Aware Transport of SONET/SDH Circuits  . . . . . 15
   6.  Generic Requirements . . . . . . . . . . . . . . . . . . . . . 15
     6.1   Relevant Common PW Requirements  . . . . . . . . . . . . . 15
     6.2   Common Circuit Payload Requirements  . . . . . . . . . . . 16
     6.3   General Design Issues  . . . . . . . . . . . . . . . . . . 17
   7.  Service-Specific Requirements  . . . . . . . . . . . . . . . . 17
     7.1   Connectivity . . . . . . . . . . . . . . . . . . . . . . . 17
     7.2   Network Synchronization  . . . . . . . . . . . . . . . . . 17
     7.3   Robustness . . . . . . . . . . . . . . . . . . . . . . . . 18
       7.3.1   Packet loss  . . . . . . . . . . . . . . . . . . . . . 18
       7.3.2   Out-of-order delivery  . . . . . . . . . . . . . . . . 18
     7.4   CE Signaling . . . . . . . . . . . . . . . . . . . . . . . 18
     7.5   PSN bandwidth utilization  . . . . . . . . . . . . . . . . 19
     7.6   Packet Delay Variation . . . . . . . . . . . . . . . . . . 20
     7.7   Compatibility with the Existing PSN Infrastructure . . . . 20
     7.8   Congestion Control . . . . . . . . . . . . . . . . . . . . 20
     7.9   Fault Detection and Handling . . . . . . . . . . . . . . . 21
     7.10  Performance Monitoring . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24









Riegel                  Expires October 12, 2005                [Page 3]

Internet-Draft            PWE3 TDM Requirements               April 2005


1.  Introduction

   This document defines the specific requirements for edge-to-edge
   emulation of circuits carrying time division multiplexed digital
   signals of the Plesiochronous Digital Hierarchy (PDH) as well as the
   Synchronous Optical NETwork (SONET)/Synchronous Digital Hierarchy
   (SDH) over Packet-Switched Networks (PSN).  It is aligned to the
   common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as
   defined in [PWE3-ARCH].
   It makes references to requirements in [PWE3-REQ] where applicable
   and complements [PWE3-REQ] by defining requirements originating from
   specifics of TDM circuits.

   The term "TDM" will be used in this documents as a general descriptor
   for the synchronous bit streams belonging to either the PDH or the
   SONET/SDH hierarchies.

1.1  TDM circuits belonging to the PDH hierarchy

   The bit rates traditionally used in various regions of the world are
   detailed in the normative reference [G.702].  For example, in North
   America the T1 bit stream of 1.544 Mbps and the T3 bit stream of
   44.736 Mbps are mandated, while in Europe the E1 bit stream of 2.048
   Mbps and the E3 bit stream of 34.368 Mbps are utilized.

   Although TDM can be used to carry unstructured bit streams at the
   rates defined in [G.702], there is a standardized method of carrying
   bit streams in larger units called frames, each frame containing the
   same number of bits.
   Related to the sampling frequency of voice traffic the bitrate is
   always a multiple of 8000, hence the T1 frame consists of 193 bits
   and the E1 frame of 256 bits.  The number of bits in a frame is
   called the frame size.

   The framing is imposed by introducing a periodic pattern into the bit
   stream to identify the boundaries of the frames (e.g. 1 framing bit
   per T1 frame, a sequence of 8 framing bits per E1 frame).  The
   details of how these framing bits are generated and used are
   elucidated in [G.704], [G.706] and [G.751].  Unframed TDM has all
   bits available for payload.

   Framed TDM is often used to multiplex multiple channels (e.g., voice
   channels each consisting of 8000 8bit-samples per second) in a
   sequence of "timeslots" recurring in the same position in each frame.
   This multiplexing is called "channelized TDM" and introduces
   additional structure.

   In some cases framing also defines groups of consecutive frames



Riegel                  Expires October 12, 2005                [Page 4]

Internet-Draft            PWE3 TDM Requirements               April 2005


   called multiframes.  Such grouping imposes an additional level of
   structure on the TDM bit-stream.

1.1.1  TDM structure and transport modes

   Unstructured TDM:
   TDM that consists of a raw bit-stream of rate defined in [G.702],
   with all bits available for payload.

   Structured TDM:
   TDM with one or more levels of structure delineation, including
   frames, channelization, and multiframes (e.g. as defined in [G.704],
   [G.751], [T1.107]).

   Structure-Agnostic Transport:
   Transport of unstructured TDM, or of structured TDM when the
   structure is deemed inconsequential from the transport point of view.
   In structure-agnostic transport any structural overhead that may be
   present is transparently transported along with the payload data, and
   the encapsulation provides no mechanisms for its location or
   utilization.

   Structure-Aware Transport:
   Transport of structured TDM taking at least some level of the
   structure into account.  In structure-aware transport there is no
   guarantee that all bits of the TDM bit-stream will be actually
   transported over the PSN network (specifically, the synchronization
   bits and related overhead may be stripped at ingress and usually will
   be regenerated at egress), or that bits transported are always
   situated in the packet in their original order (but in this case, bit
   order is usually recovered at egress; one known exception is loss of
   multiframe synchronization between the TDM data and CAS bits
   introduced by a digital cross-connect acting as a Native Service
   Processing (NSP) block, see [TR-NWT-170]).

1.2  SONET/SDH circuits

   The term SONET refers to the North American Synchronous Optical
   NETwork as specified by [T1.105].  It is based on the concept of a
   Nx783 byte payload container repeated every 125us.  This payload is
   referred as an STS-1 SPE and may be concatenated into higher
   bandwidth circuits (e.g.  STS-Nc) or sub-divided into lower bandwidth
   circuits (Virtual Tributaries).  The higher bandwidth concatenated
   circuits can be used to carry anything from IP Packets to ATM cells
   to Digital Video Signals.  Individual STS-1 SPEs are frequently used
   to carry individual DS3 or E3 TDM circuits.  When the 783 byte
   containers are sub-divided for lower rate payloads, they are
   frequently used to carry individual T1 or E1 TDM circuits.



Riegel                  Expires October 12, 2005                [Page 5]

Internet-Draft            PWE3 TDM Requirements               April 2005


   The Synchronous Digital Hierarchy (SDH) is the international
   equivalent and enhancement of SONET and is specified by [G.707].

   Both SONET and SDH include a substantial amount of transport overhead
   that is used for performance monitoring, fault isolation, and other
   maintenance functions along different types of optical or electrical
   spans.  This also includes a pointer based mechanism for carrying
   payloads asynchronously.  In addition, the payload area includes
   dedicated overhead for end-to-end performance monitoring, fault
   isolation, and maintenance for the service being carried.  If the
   main payload area is sub-divided into lower rate circuits (such as
   T1/E1), additional overhead is included for end-to-end monitoring of
   the individual T1/E1 circuits.

   This document discusses the requirements for emulation of SONET/SDH
   services.  These services include end-to-end emulation of the SONET
   payload (STS-1 SPE), emulation of concatenated payloads (STS-Nc SPE),
   as well as emulation of a variety of sub-STS-1 rate circuits jointly
   referred to as Virtual Tributaries (VT) and their SDH analogs.

2.  Motivation

   [PWE3-REQ] specifies common requirements for edge-to-edge-emulation
   of circuits of various types.  However, these requirements, as well
   as references in [PWE3-ARCH] do not cover specifics of PWs carrying
   TDM circuits.

   The need for a specific document complementing [PWE3-REQ] addressing
   edge-to-edge-emulation of TDM circuits arises from following:

   o  Specifics of the TDM circuits,
      e.g.:

      *  the need for balance between the clock of ingress and egress
         attachment circuits in each direction of the Pseudo Wire (PW),

      *  the need to maintain jitter and wander of the clock of the
         egress end service within the limits imposed by the appropriate
         normative documents in the presence of the packet delay
         variation produced by the PSN.

   o  Specifics of applications using TDM circuits,
      e.g. voice applications:

      *  put special emphasis on minimization of one-way delay,

      *  are relatively tolerant to errors in data.




Riegel                  Expires October 12, 2005                [Page 6]

Internet-Draft            PWE3 TDM Requirements               April 2005


      Other applications might have different specifics.
      e.g. transport of signaling information:

      *  is relatively tolerant to one-way delay,

      *  is sensitive to errors in transmitted data.

   o  Specifics of the customers' expectations regarding end-to-end
      behavior of services that contain emulated TDM circuits,
      e.g., experience with carrying such services over SONET/SDH
      networks increases the need for:

      *  isolation of problems introduced by the PSN from those
         occurring beyond the PSN bounds,

      *  sensitivity to misconnection,

      *  sensitivity to unexpected connection termination, etc.


3.  Terminology

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

   The terms defined in [PWE3-ARCH], Section 1.4 are consistently used.
   However some terms and acronyms are used in conjunction with the TDM
   services.  In particular:

   TDM networks employ Channel-Associated Signaling (CAS) or Common
   Channel Signaling (CCS) to supervise and advertise status of
   telephony applications, provide alerts to these applications (as to
   requests to connect or disconnect), and to transfer routing and
   addressing information.  These signals must be reliably transported
   over the PSNs for the telephony end-systems to function properly.

   CAS (Channel-Associated Signaling)
      CAS is carried in the same T1 or E1 frame as the voice signals,
      but not in the speech band.  Since CAS signaling may be
      transferred at a rate slower than the TDM traffic in a timeslot,
      one need not update all the CAS bits every TDM frame.  Hence CAS
      systems cycle through all the signaling bits only after some
      number of TDM frames, defining a new structure known as a
      multiframe or superframe.  Common multiframes are 12, 16, or 24
      frames in length, corresponding to 1.5, 2 and 3 milliseconds in
      duration.




Riegel                  Expires October 12, 2005                [Page 7]

Internet-Draft            PWE3 TDM Requirements               April 2005


   CCS (Common Channel Signaling)
      CCS signaling uses a separate digital channel to carry
      asynchronous messages pertaining to the state of telephony
      applications over related TDM timeslots of a TDM trunk.  This
      channel may be physically situated in one or more adjacent
      timeslots of the same TDM trunk (trunk associated CCS) or may be
      transported over an entirely separate network.
      CCS is typically HDLC-based, with idle codes or keep-alive
      messages being sent until a signaling event (e.g. on-hook or off-
      hook) occurs.  Examples of HDLC-based CCS systems are SS7 [Q.700]
      and ISDN PRI signaling [Q.931].

   Note: For the TDM network we use the terms "jitter" and "wander" as
   defined in [G.810] to describe short- and long-term variance of the
   significant instants of the digital signal, while for the PSN we use
   the term packet delay variation (PDV) (see [RFC3393]).

4.  Reference Models

4.1  Generic PWE3 Models

   Generic models that have been defined in [PWE3-ARCH] in Sections
   - 4.1 (Network Reference Model),
   - 4.2 (PWE3 Pre-processing),
   - 4.3 (Maintenance Reference Model),
   - 4.4 (Protocol Stack Reference Model) and
   - 4.5 (Pre-processing Extension to Protocol Stack Reference Model).
   They are fully applicable for the purposes of this document without
   modification.

   All the services considered in this document represent special cases
   of the Bit-stream and Structured bit-stream payload type defined in
   Section 3.3 of [PWE3-ARCH].

4.2  Clock Recovery

   Clock recovery is extraction of the transmission bit timing
   information from the delivered packet stream.  Extraction of this
   information from a highly jittered source such as a packet stream may
   be a complex task.

4.3  Network Synchronization Reference Model

   A generic network synchronization reference model is shown in Figure
   1 below:






Riegel                  Expires October 12, 2005                [Page 8]

Internet-Draft            PWE3 TDM Requirements               April 2005


          +---------------+               +---------------+
          |      PE1      |               |      PE2      |
       K  |   +--+        |               |        +--+   |  G
       |  |   | J|        |               |        | H|   |  |
       v  |   v  |        |               |        v  |   |  v
   +---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
   |   |  | |P|  |D|  |P| |  |  |   |  |  | |P|  |E|  |P| |  |   |
   |   |<===|h|<:|e|<:|h|<:::|  |<::|  |<:::|h|<:|n|<=|h|<===|   |
   |   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
   | C |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | C |
   | E |  |               |  |S1|   |S2|  |               |  | E |
   | 1 |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | 2 |
   |   |  | |P|  |E|  |P| |  |  |   |  |  | |P|  |D|  |P| |  |   |
   |   |===>|h|=>|n|:>|h|:::>|  |::>|  |:::>|h|:>|e|=>|h|===>|   |
   |   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
   +---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
    ^  ^  |   |  ^        |               |        |  ^   |  ^  ^
    |  |  |   |B |        |<------+------>|        |  |   |  |  |
    |  A  |   +--+        |       |       |        +--+-E |  F  |
    |     +---------------+      +-+      +---------------+     |
    |             ^              |I|               ^            |
    |             |              +-+               |            |
    |             C                                D            |
    +-----------------------------L-----------------------------+

   Figure 1: The Network Synchronization Reference Model

   The following notation is used in Figure 1:

   CE1, CE2
      Customer edge devices terminating TDM circuits to be emulated.

   PE1, PE2
      Provider edge devices adapting these end services to PW.

   S1, S2
      Provider core routers

   Phy
      Physical interface terminating the TDM circuit.

   Enc
      PSN-bound interface of the PW, where the encapsulation takes
      place.







Riegel                  Expires October 12, 2005                [Page 9]

Internet-Draft            PWE3 TDM Requirements               April 2005


   Dec
      CE-bound interface of the PW, where the decapsulation takes place.
      It contains a compensation buffer (also known as the "jitter
      buffer") of limited size.

   "==>"
      TDM attachment circuits

   "::>"
      PW providing edge-to-edge-emulation for the TDM circuit.

   The characters "A" - "L" denote various clocks:

   "A"
      The clock used by CE1 for transmission of the TDM attachment
      circuit towards CE1.

   "B"
      The clock recovered by PE1 from the incoming TDM attachment
      circuit.  "A" and "B" always have the same frequency.

   "G"
      The clock used by CE2 for transmission of the TDM attachment
      circuit towards CE2.

   "H"
      The clock recovered by PE2 from the incoming TDM attachment
      circuit.  "G" and "H" always have the same frequency.

   "C", "D"
      Local oscillators available to PE1 and PE2 respectively.

   "E"
      Clock used by PE2 to transmit the TDM attachment service circuit
      to CE2 (the recovered clock).

   "F"
      Clock recovered by CE2 from the incoming TDM attachment service
      ("E and "F" have the same frequency).

   "I"
      If the clock exists, it is the common network reference clock
      available to PE1 and PE2.

   "J"
      Clock used by PE1 to transmit the TDM attachment service circuit
      to CE1 (the recovered clock).




Riegel                  Expires October 12, 2005               [Page 10]

Internet-Draft            PWE3 TDM Requirements               April 2005


   "K"
      Clock recovered by CE1 from the incoming TDM attachment service
      ("J" and "K" have the same frequency).

   "L"
      If it exists, it is the common reference clock of CE1 and CE2.
      Note that different pairs of CE devices may use different common
      reference clocks.

   A requirement of edge-to-edge-emulation of a TDM circuit is that
   clock "B" and "E" as well as clock "H" and "J" are of the same
   frequency.  The most appropriate method will depend on the network
   synchronization scheme.

   The following groups of synchronization scenarios can be considered:


4.3.1  Synchronous Network Scenarios

   Depending on which part of the network is synchronized by a common
   clock there are two scenarios:

   o  PE Synchronized Network:

      Figure 2 below, an adapted version of the generic network
      reference model, presents the PE synchronized network scenario.

      The common network reference clock "I" is available to all the PE
      devices, and local oscillators "C" and "D" are locked to "I":

      *  Clocks "E" and "J" are the same as "D" and "C" respectively.

      *  Clocks "A" and "G" are the same as "K" and "F" respectively
         (i.e., CE1 and CE2 use loop timing).

















Riegel                  Expires October 12, 2005               [Page 11]

Internet-Draft            PWE3 TDM Requirements               April 2005


                       +-----+                 +-----+
      +-----+    |     |- - -|=================|- - -|     |    +-----+
      | /-- |<---------|............PW1..............|<---------| <-\ |
      || CE |    |     | PE1 |                 | PE2 |     |    |CE2 ||
      | \-> |--------->|............PW2..............|--------->| --/ |
      +-----+    |     |- - -|=================|- - -|     |    +-----+
                       +-----+                 +-----+
                          ^                       ^
                          |C                      |D
                          +-----------+-----------+
                                      |
                                     +-+
                                     |I|
                                     +-+

      Figure 2: PE synchronized scenario

   o  CE Synchronized Network:

      Figure 3 below, an adapted version of the generic network
      reference model, presents the CE synchronized network scenario.

      The common network reference clock "L" is available to all the CE
      devices, and local oscillators "A" and "G" are locked to "L":

      *  Clocks "E" and "J" are the same as "G" and "A" respectively
         (i.e., PE1 and PE2 use loop timing).


                       +-----+                 +-----+
      +-----+    |     |- - -|=================|- - -|     |    +-----+
      |     |<---------|............PW1..............|<---------|     |
      | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
      |     |--------->|............PW2..............|--------->|     |
      +-----+    |     |- - -|=================|- - -|     |    +-----+
        ^              +-----+                 +-----+              ^
        |A                                                         G|
        +----------------------------+------------------------------+
                                     |
                                    +-+
                                    |L|
                                    +-+

      Figure 3: CE synchronized scenario

   No timing information has to be transferred in these cases.





Riegel                  Expires October 12, 2005               [Page 12]

Internet-Draft            PWE3 TDM Requirements               April 2005


4.3.2  Relative Network Scenario

   In this case each CE uses its own transmission clock source that must
   be carried across the PSN and recovered by the remote PE,
   respectively.  The common PE clock "I" can be used as reference for
   this purpose.

   Figure 4 below shows the relative network scenario.

   The common network reference clock "I" is available to all the PE
   devices, and local oscillators "C" and "D" are locked to "I":

   o  Clocks "A" and "G" are generated locally without reference to a
      common clock.

   o  Clocks "E" and "J" are generated in reference to a common clock
      available at all PE devices.

   In a slight modification of this scenario, one (but not both!) of the
   CE devices may use its receive clock as its transmission clock (i.e.
   use loop timing).

                                                              |G
                    +-----+                 +-----+           v
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
        ^           +-----+<-------+------->+-----+
        |A                         |
                                  +-+
                                  |I|
                                  +-+


   Figure 4: Relative network scenario

   Timing information (the difference between the common reference clock
   "I" and the incoming clock "A") MUST be explicitly transferred in
   this case from the ingress PE to the egress PE.

4.3.3  Adaptive Network Scenario

   The adaptive scenario is characterized by:

   o  No common network reference clock "I" is available to PE1 and PE2.




Riegel                  Expires October 12, 2005               [Page 13]

Internet-Draft            PWE3 TDM Requirements               April 2005


   o  No common reference clock "L" is available to CE1 and CE2.

   Figure 5 below presents the adaptive network scenario.

                     |J                                       |G
                     v                                        |
                    +-----+                 +-----+           v
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
        ^           +-----+                 +-----+
        |                                        ^
       A|                                       E|

   Figure 5: Adaptive scenario

   Synchronizing clocks "A" and "E" in this scenario is more difficult
   than it is in the other scenarios.

   Note that the tolerance between clocks "A" and "E" must be small
   enough to ensure that the jitter buffer does not overflow or
   underflow.

   Timing information MAY be explicitly transferred in this case from
   the ingress PE to the egress PE, e. g. by RTP.

5.  Emulated Services

   This section defines requirements for the payload and encapsulation
   layers for edge-to-edge emulation of TDM services with bit-stream
   payload as well as structured bit-stream payload.

   Wherever possible, the requirements specified in this document SHOULD
   be satisfied by appropriate arrangements of the encapsulation layer
   only.  The (rare) cases when the requirements apply to both the
   encapsulation and payload layers (or even only to the payload layer
   only) will be explicitly noted.

   The service-specific encapsulation layer for edge-to-edge emulation
   comprises the following services over a PSN.

5.1  Structure-Agnostic Transport of signals out of the PDH hierarchy

   Structure-agnostic transport is considered for the following signals:





Riegel                  Expires October 12, 2005               [Page 14]

Internet-Draft            PWE3 TDM Requirements               April 2005


   o  E1 as described in [G.704].

   o  T1 (DS1) as described in [G.704].

   o  E3 as defined in [G.751].

   o  T3 (DS3) as described in [T.107].


5.2  Structure-Aware Transport of signals out of the PDH hierarchy

   Structure-aware transport is considered for the following signals:

   o  E1/T1 with one of the structures imposed by framing as described
      in  [G.704]

   o  NxDS0 with or without CAS


5.3  Structure-Aware Transport of SONET/SDH Circuits

   Structure-aware transport is considered for the following SONET/SDH
   circuits:

   o  SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3

   o  SONET STS-Nc SPE (N = 3, 12, 48, 192) / SDH VC-4, VC-4-4c, VC-4-
      16c, VC-4-64c

   o  SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2

   o  SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3

   Note: There is no requirement for the structure-agnostic transport of
   SONET/SDH.  It would seem that structure must be taken into account
   for this case.

6.  Generic Requirements

6.1  Relevant Common PW Requirements

   The encapsulation and payload layers MUST conform to the common PW
   requirements defined in [PWE3-REQ]:

   1.  Conveyance of Necessary Header Information:

       A.  For structure-agnostic transport, this functionality MAY be
           provided by the payload layer.



Riegel                  Expires October 12, 2005               [Page 15]

Internet-Draft            PWE3 TDM Requirements               April 2005


       B.  For structure-aware transport, the necessary information MUST
           be provided by the encapsulation layer.

       C.  Structure-aware transport of SONET/SDH circuits MUST preserve
           path overhead information as part of the payload.  Relevant
           components of the transport overhead MAY be carried in the
           encapsulation layer.

   2.  Support of Multiplexing and Demultiplexing if supported by the
       native services.  This is relevant for Nx DS0 circuits with or
       without signaling and Nx VT-x in a single STS-1 SPE or VC-4.:

       A.  For these circuits the combination of encapsulation and
           payload layers MUST provide for separate treatment of every
           sub-circuit.

       B.  Enough information SHOULD be provided by the pseudo wire to
           allow multiplexing and demultiplexing by the NSP.  Reduction
           of the complexity of the PW emulation by using NSP circuitry
           for multiplexing and demultiplexing MAY be the preferred
           solution.

   3.  Intervention or transparent transfer of Maintenance Messages of
       the Native Services depending on the particular scenario.

   4.  Consideration of Per-PSN Packet Overhead (see also Section 7.5
       below).

   5.  Detection and handling of PW faults.  The list of faults is given
       in Section 7.9 below.

   Fragmentation indications MAY be used for structure-aware transport
   when the structures in question either exceed desired packetization
   delay or exceed Path MTU between the pair of PEs.

   The following requirement listed in [PWE3-REQ] is not applicable to
   emulation of TDM services:

   o  Support of variable length PDUs.


6.2  Common Circuit Payload Requirements

   Structure-agnostic transport treats TDM circuits as belonging to the
   'Bit-stream' payload type defined in [PWE3-ARCH].

   Structure-aware transport treats these circuits as belonging to the
   "Structured bit-stream" payload type defined in [PWE3-ARCH].



Riegel                  Expires October 12, 2005               [Page 16]

Internet-Draft            PWE3 TDM Requirements               April 2005


   Accordingly, the encapsulation layer MUST provide the common
   Sequencing service and SHOULD provide Timing information
   (Synchronization services) when required (see Section 4.3 above).

   Note: Length service MAY be provided by the encapsulation layer but
   is not required.

6.3  General Design Issues

   The combination of payload and encapsulation layers SHOULD comply
   with the general design principles of the Internet protocols as
   presented in [RFC1958], Section 3 and [PWE3-ARCH].

   If necessary, the payload layer MAY use some forms of adaptation of
   the native TDM payload in order to achieve specific well-documented
   design objectives.  In these cases standard adaptation techniques
   SHOULD be used.

7.  Service-Specific Requirements

7.1  Connectivity

   1.  The emulation MUST support the transport of signals between
       Attachment Circuits (ACs) of the same type (see Section 5) and,
       wherever appropriate, bit-rate.

   2.  The encapsulation layer SHOULD remain unaffected by specific
       characteristics of connection between the ACs and PE devices at
       the two ends of the PW.


7.2  Network Synchronization

   1.  The encapsulation layer MUST provide synchronization services
       that are sufficient to:

       A.  match the ingress and egress end service clocks regardless of
           the specific network synchronization scenario,

       B.  keep the jitter and wander of the egress service clock within
           the service-specific limits as defined by the appropriate
           normative references.

   2.  If the same high-quality synchronization source is available to
       all the PE devices in the given domain, the encapsulation layer
       SHOULD be able to make use of it (e.g., for better reconstruction
       of the native service clock).




Riegel                  Expires October 12, 2005               [Page 17]

Internet-Draft            PWE3 TDM Requirements               April 2005


7.3  Robustness

   The robustness of the emulated service depends not only upon the
   edge-to-edge-emulation protocol but also upon proper implementation
   of the following procedures.

7.3.1  Packet loss

   Edge-to-edge-emulation of TDM circuits MAY assume very low
   probability of packet loss between ingress and egress PE.  In
   particular, no retransmission mechanisms are required.

   In order to minimize effect of lost packets on the egress service,
   the encapsulation layer SHOULD:

   1.  Enable independent interpretation of TDM data in each packet by
       the egress PE (see [RFC2736]).  This requirement MAY be
       disregarded if the egress PE needs to interpret structures that
       exceed the path MTU between the ingress and egress PEs.

   2.  Allow reliable detection of lost packets (see next section).  In
       particular, it SHOULD allow estimation of the arrival time of the
       next packet and detection of lost packets based on this estimate.

   3.  Minimize possible effect of lost packets on recovery of the
       circuit clock by the egress PE.

   4.  Increase the resilience of the CE TDM interface to packet loss by
       allowing the egress PE to substitute appropriate data.


7.3.2  Out-of-order delivery

   The encapsulation layer MUST provide the necessary mechanisms to
   guarantee ordered delivery of packets carrying the TDM data over the
   PSN.  Packets that have arrived out-of-order:

   1.  MUST be detected,

   2.  SHOULD be reordered if not judged to be too late or too early for
       playout.

   Out-of-order packets that cannot be reordered MUST be treated as
   lost.

7.4  CE Signaling

   Unstructured TDM circuits would not usually require any special



Riegel                  Expires October 12, 2005               [Page 18]

Internet-Draft            PWE3 TDM Requirements               April 2005


   mechanism for carrying CE signaling as this would be carried as part
   of the emulated service.

   Some CE applications using structured TDM circuits (e.g., telephony)
   require specific signaling that conveys changes of state of these
   applications relative to the TDM data.

   The encapsulation layer SHOULD support signaling of state of CE
   applications for the relevant circuits providing for:

   1.  Ability to support different signaling schemes with minimal
       impact on encapsulation of TDM data,

   2.  Multiplexing of application-specific CE signals and data of the
       emulated service in the same PW,

   3.  Synchronization (within the application-specific tolerance
       limits) between CE signals and data at the PW egress,

   4.  Probabilistic recovery against possible occasional loss of
       packets in the PSN,

   5.  Deterministic recovery of the CE application state after PW setup
       and network outages.

   CE signaling that is used for maintenance purposes (loopback
   commands, performance monitoring data retrieval, etc.)  SHOULD use
   the generic PWE3 maintenance protocol.

7.5  PSN bandwidth utilization

   1.  The encapsulation layer SHOULD allow for an effective trade-off
       between the following requirements:

       A.  Effective PSN bandwidth utilization.  Assuming that the size
           of encapsulation layer header does not depend on the size of
           its payload, increase in the packet payload size results in
           increased efficiency.

       B.  Low edge-to-edge latency.  Low end-to-end latency is the
           common requirement for Voice applications over TDM services.
           Packetization latency is one of the components comprising
           edge-to-edge latency and decreases with the packet payload
           size.

       The compensation buffer used by the CE-bound IWF increases
       latency to the emulated circuit.  Additional delay introduced by
       this buffer SHOULD NOT exceed the packet delay variation observed



Riegel                  Expires October 12, 2005               [Page 19]

Internet-Draft            PWE3 TDM Requirements               April 2005


       in the PSN.

   2.  The encapsulation layer MAY provide for saving PSN bandwidth by
       not sending corrupted TDM data across the PSN.

   3.  The encapsulation layer MAY provide the ability to save the PSN
       bandwidth for the structure-aware case by not sending channels
       that are permanently inactive.

   4.  The encapsulation layer MAY enable the dynamic suppression of
       temporarily unused channels from transmission for the structure-
       aware case.
       If used, dynamic suppression of temporarily unused channels
       MUST NOT violate integrity of the structures delivered over the
       PW.

   5.  For NxDS0 the encapsulation layer MUST provide the ability to
       keep the edge-to-edge delay independent of the service rate.


7.6  Packet Delay Variation

   The encapsulation layer SHOULD provide for ability to compensate for
   packet delay variation while maintaining jitter and wander of the
   egress end service clock with tolerances specified in the normative
   references.

   The encapsulation layer MAY provide for run-time adaptation of delay
   introduced by the jitter buffer if the packet delay variation varies
   with time.  Such an adaptation MAY introduce a low level of errors
   (within the limits tolerated by the application) but SHOULD NOT
   introduce additional wander of the egress end service clock.

7.7  Compatibility with the Existing PSN Infrastructure

   The combination of encapsulation and PSN tunnel layers used for edge-
   to-edge emulation of TDM circuits SHOULD be compatible with existing
   PSN infrastructures.  In particular, compatibility with the
   mechanisms of header compression over links where capacity is at a
   premium SHOULD be provided.

7.8  Congestion Control

   TDM circuits run at a constant rate, and hence offer constant traffic
   loads to the PSN.  The rate varying mechanism that TCP uses to match
   demand to the network congestion state is therefore not applicable.

   The ability to shut down a TDM PW when congestion has been detected



Riegel                  Expires October 12, 2005               [Page 20]

Internet-Draft            PWE3 TDM Requirements               April 2005


   MUST be provided.

   Precautions should be taken to avoid situations wherein multiple TDM
   PWs are simultaneously shut down or re-established, thus leading to
   PSN instability.

   Further congestion considerations are discussed in chapter 6.5 of
   [PWE3-ARCH].

7.9  Fault Detection and Handling

   The encapsulation layer for edge-to-edge emulation of TDM services
   SHOULD, separately or in conjunction with the lower layers of the
   PWE3 stack, provide for detection, handling and reporting of the
   following defects:

   1.  Misconnection, or Stray Packets.  The importance of this
       requirement stems from customer expectation due to reliable
       misconnection detection in SONET/SDH networks.

   2.  Packet Loss.  Packet loss detection required in order to maintain
       clock integrity, as discussed in Section 7.3.1 above.  In
       addition, packet loss detection mechanisms SHOULD provide for
       localization of the outage in the end-to-end emulated service.

   3.  Malformed packets.


7.10  Performance Monitoring

   The encapsulation layer for edge-to-edge emulation of TDM services
   SHOULD provide for collection of performance monitoring (PM) data
   that is compatible with the parameters defined for 'classic', TDM-
   based carriers of these services.  The applicability of [G.826] is
   left for further study.

8.  Security Considerations

   The security considerations in [PWE3-REQ] are fully applicable to the
   emulation of TDM services.  In addition TDM services are sensitive to
   packet delay variation [Section 7.6], and need to be protected from
   this as a method of attack.

9.  References

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




Riegel                  Expires October 12, 2005               [Page 21]

Internet-Draft            PWE3 TDM Requirements               April 2005


   [PWE3-ARCH] Stewart Bryant et al, Pseudo Wire Emulation Edge-to-Edge
   (PWE3) Architecture, RFC3985, March 2005

   [G.702] ITU-T Recommendation G.702 (11/88) - Digital hierarchy bit
   rates

   [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame
   structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s
   hierarchical levels

   [G.706] ITU-T Recommendation G.706 (04/91) - Frame alignment and
   cyclic redundancy check (CRC) procedures relating to basic frame
   structures defined in Recommendation G.704

   [G.707] ITU-T Recommendation G.707 (10/00) - Network node interface
   for the synchronous digital hierarchy (SDH)

   [G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex
   equipments operating at the third order bit rate of 34 368 Kbit/s and
   the fourth order bit rate of 139 264 Kbit/s and using positive
   justification

   [G.810] ITU-T Recommendation G.810 (08/96) - Definitions and
   terminology for synchronization networks

   [G.826] ITU-T Recommendation G.826 (02/99) - Error performance
   parameters and objectives for international, constant bit rate
   digital paths at or above the primary rate

   [Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT
   Signalling System No. 7

   [Q.931] ITU-T Recommendation Q.931 (05/98) - ISDN user-network
   interface layer 3 specification for basic call control

   [RFC1958] B. Carpenter (ed.), Architectural Principles of the
   Internet, RFC 1958, IETF, 1996

   [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement
   Levels, RFC 2119, IETF, 1997

   [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP
   Payload Format Specifications, RFC 2736, IETF, 1999

   [RFC3393] C. Demichelis, P. Chimento, IP Packet Delay Variation
   Metric for IPPM, RFC 3393, IETF, 2002

   [T1.105] ANSI T1.105 - 2001 Synchronous Optical Network (SONET) -



Riegel                  Expires October 12, 2005               [Page 22]

Internet-Draft            PWE3 TDM Requirements               April 2005


   Basic Description including Multiplex Structure, Rates, and Formats,
   May 2001

   [T1.107] ANSI T1.107 - 1995.  Digital Hierarchy - Format
   Specification

   [TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and
   Objectives, Bellcore, TR-NWT-170, January 1993


Author's Address

   Maximilian Riegel
   Siemens AG
   St-Martin-Str 76
   Munich  81541
   Germany

   Phone: +49-89-636-75194
   Email: maximilian.riegel@siemens.com































Riegel                  Expires October 12, 2005               [Page 23]

Internet-Draft            PWE3 TDM Requirements               April 2005


Intellectual Property Statement

   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 procedures with respect to rights in RFC 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.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.





Riegel                  Expires October 12, 2005               [Page 24]

Internet-Draft            PWE3 TDM Requirements               April 2005


Acknowledgment

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















































Riegel                  Expires October 12, 2005               [Page 25]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/