[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
Internet-Draft                                                Siemens AG
Expires: December 29, 2003                                      (Editor)
                                                           June 30, 2003



  Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet
                        Switching Networks (PSN)
                draft-ietf-pwe3-tdm-requirements-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.

   This Internet-Draft will expire on December 29, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document specifies the particular requirements for
   edge-to-edge-emulation of circuits carrying time division multiplexed
   digital signals of the PDH as well as the SONET/SDH hierarchy over
   packet-switched networks. It is based on 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.



Riegel, et al.         Expires December 29, 2003                [Page 1]


Internet-Draft           PWE3 TDM Requirements                 June 2003



Co-Authors

   The following are co-authors of this document:

   Sasha Vainshtein   Axerra Networks
   Yaakov Stein       RAD Data Communication
   Prayson Pate       Overture Networks, Inc.
   Ron Cohen          Lycium Networks
   Tim Frost          Zarlink Semiconductor


Changes from the last revision:

   - editorial corrections
   - updated references and contact information
   - Tom Johnson has left the team of authors. We thank him for all the
     effort he has put into this document.
   - Chapter 6.1: updated wording according to latest edition of
     [PWE3-REQ].
   - Chapter 7.5: added sentences for suppression of unused channels and
     for independance of edge-to-edge delay.
   - Chapter 7.8: added reference to Chapter 6.5 of [PWE3-ARCH].




























Riegel, et al.         Expires December 29, 2003                [Page 2]


Internet-Draft           PWE3 TDM Requirements                 June 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   TDM circuits . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1.1 Structured TDM circuits  . . . . . . . . . . . . . . . . . .  4
   1.1.2 Unstructured TDM circuits  . . . . . . . . . . . . . . . . .  5
   1.2   SONET/SDH circuits . . . . . . . . . . . . . . . . . . . . .  5
   2.    Motivation . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.    Reference Models . . . . . . . . . . . . . . . . . . . . . .  7
   4.1   Generic PWE3 Models  . . . . . . . . . . . . . . . . . . . .  8
   4.2   Timing Synchronization . . . . . . . . . . . . . . . . . . .  8
   4.2.1 Clock Recovery . . . . . . . . . . . . . . . . . . . . . . .  8
   4.2.2 Timed delivery . . . . . . . . . . . . . . . . . . . . . . .  8
   4.3   Network Synchronization Reference Model  . . . . . . . . . .  9
   4.3.1 Synchronous Network Scenarios  . . . . . . . . . . . . . . . 11
   4.3.2 Relative Network Scenario  . . . . . . . . . . . . . . . . . 12
   4.3.3 Adaptive Network Scenario  . . . . . . . . . . . . . . . . . 13
   5.    Emulated Services  . . . . . . . . . . . . . . . . . . . . . 14
   5.1   Unstructured TDM Circuits  . . . . . . . . . . . . . . . . . 14
   5.2   Structured TDM Circuits  . . . . . . . . . . . . . . . . . . 15
   5.3   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  . . . . . . . . . . . . . . . . . . . 16
   7.    Service-Specific Requirements  . . . . . . . . . . . . . . . 16
   7.1   Interworking . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.2   Network Synchronization  . . . . . . . . . . . . . . . . . . 17
   7.3   Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.3.1 Packet loss  . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.3.2 Out-of-order delivery  . . . . . . . . . . . . . . . . . . . 18
   7.4   CE Signaling . . . . . . . . . . . . . . . . . . . . . . . . 18
   7.5   PSN bandwidth utilization  . . . . . . . . . . . . . . . . . 19
   7.6   Packet Delay Variation . . . . . . . . . . . . . . . . . . . 19
   7.7   Compatibility with the Existing PSN Infrastructure . . . . . 20
   7.8   Congestion Control . . . . . . . . . . . . . . . . . . . . . 20
   7.9   Fault Detection and Handling . . . . . . . . . . . . . . . . 20
   7.10  Performance Monitoring . . . . . . . . . . . . . . . . . . . 21
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 21
   9.    References . . . . . . . . . . . . . . . . . . . . . . . . . 21
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
         Intellectual Property and Copyright Statements . . . . . . . 24








Riegel, et al.         Expires December 29, 2003                [Page 3]


Internet-Draft           PWE3 TDM Requirements                 June 2003


1. Introduction

   This document specifies the particular requirements for
   edge-to-edge-emulation of circuits carrying time division multiplexed
   digital signals of the PDH as well as the SONET/SDH hierarchy over
   packet-switched networks. It is based on 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.

1.1 TDM circuits

   The term "TDM" will be used in this documents as general descriptor
   of the synchronous bit streams belonging to either the PDH or the
   SONET/SDH hierarchies.
   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 each containing the same amount of bits.
   These units are called frames, and the transport mode is denoted
   "framed TDM".
   Related to the sampling frequency of voice traffic, there are always
   8000 such frames per second, 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.

   Framed TDM is using some bits in 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.751] and
   [G.752]. Unframed TDM has all bits available for payload.

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

1.1.1 Structured TDM circuits

   The term "structured TDM" is used in this document to refer to both
   'channelized TDM' as well as 'framed TDM' whenever framing and
   eventually channelization exist and are deemed significant for the



Riegel, et al.         Expires December 29, 2003                [Page 4]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   transport of TDM over PWs.

1.1.2 Unstructured TDM circuits

   A TDM stream is denoted "unstructured" when it is unframed, or when
   it is framed or even channelized, but the framing and channelization
   structure are deemed inconsequential from the transport point of
   view. In such cases all structural overhead is transparently
   transported by the PW along with the payload data, and the
   encapsulation method employed provides no mechanisms for its location
   or utilization.

1.2 SONET/SDH circuits

   The term SONET refers to the North American Synchronous Optical
   NETwork as specified by [GR-253] [Ed-Note###: add T.105a here???].
   The Synchronous Digital Hierarchy (SDH) is the international
   equivalent and enhancement of SONET and is specified by [G.707].
   Although terminology between the two technologies is different, both
   have the concept of a Nx783 byte payload container repeated every
   125us.  This payload is referred to for SONET 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.

   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. 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.  A key feature of STS-1/Nc and VT service emulation is
   the carriage of the Path or VT maintenance overhead through the PSN.

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




Riegel, et al.         Expires December 29, 2003                [Page 5]


Internet-Draft           PWE3 TDM Requirements                 June 2003


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] with regard
   to edge-to-edge-emulation of TDM circuits arises from following
   causes:

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

      *  the need for balance between the clock of ingress and egress
         end services in each direction of the 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 spite of the packet delay variation
         produced by the PSN.

   o  Specifics of applications using (native and emulated) TDM
      circuits,
      e.g. voice applications:

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

      *  are relatively tolerant to errors in data.

      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,

      *  higher sensitivity to misconnection, etc.





Riegel, et al.         Expires December 29, 2003                [Page 6]


Internet-Draft           PWE3 TDM Requirements                 June 2003


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 specific in conjunction with the
   TDM services. In particular:

   CAS (Channel-Associated Signaling)
      It is one of several signaling techniques used by the telephony
      applications to convey various states of these applications (e.g.,
      off-hook and on-hook). CAS uses a certain, circuit-specific
      multiframe structure that is imposed on the TDM bit stream and a
      predefined association between the relative timeslot (= channel)
      number within this stream and position of certain bits within this
      multiframe structure. In the case of E1 there are four 500 bit/s
      channels for each timeslot used to distinguish and signal
      application states (see [G.704] for details).
      CAS is also used in conjunction with D4 and ESF formats of T1
      using "robbed bits". In case of D4 this results in 2 channels of
      333.(3) bit/s, and in case of ESF - 4 such channels.
      [## Ed-note##: more details to be included here?]

   CCS (Common Channel Signaling)
      This is an alternative to the CAS method of signaling used by the
      telephony applications. E.g., for SS7 Common Channel Signaling is
      described in [Q.700] and references therein.

   SDH (Synchronous Digital Hierarchy)

   SONET (Synchronous Optical NETwork)

   SPE (Synchronous Payload Envelope)

   STS-n (Synchonous Transport Signal n (SONET))

   VT (Virtual Tributary (SONET))

   VC-n (Virtual Container N (SDH))

   For the TDM network we use the terms "jitter" and "wander" as defined
   in [G.823] and [G.824], while for the PSN measures from IETF IPPM
   (like packet delay variation - see [RFC3393]) are used.

4. Reference Models




Riegel, et al.         Expires December 29, 2003                [Page 7]


Internet-Draft           PWE3 TDM Requirements                 June 2003


4.1 Generic PWE3 Models

   Generic models that have been defined in [PWE3-ARCH] in Sections
   - 4.1 (Network Reference Model),
   - 4.2 (PWE3 Preprocessing),
   - 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
   any modifications.

   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 Timing Synchronization

   Timing synchronization of emulated TDM services comprises

      Clock recovery,

      Timed delivery (delay), and

      Frame recovery.

   The availability of a common clock at the ends of PW is not presumed.
   However, without a common clock the fidelity of the recovered TDM
   timing will be dependent on the packet delay variation behavior of
   the underlying PSN and the robustness of the applied timing recovery
   algorithms.

4.2.1 Clock Recovery

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

4.2.2 Timed delivery

   Timed delivery is the delivery of non-contiguous PW PDUs to the PW
   output interface with a constant delay (phase shift) relative to the
   input interface. The delay of the delivery may be relative to a clock
   derived from the packet stream via clock recovery, or via an external
   clock.

4.2.2.1 Frame Recovery




Riegel, et al.         Expires December 29, 2003                [Page 8]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   Frame recovery is the process to detect the frame boundaries. It
   starts with the hunting process in the out-of-alignment state and
   provides the frame alignment reacquisition in the correct-alignment
   state.
   Frame recovery provides access to signaling and maintenance
   information embedded in the framing bits and allows for advanced
   functions to cope with transmission errors and to enhance bandwidth
   utilization in the underlying PSN.

4.3 Network Synchronization Reference Model

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

                 +---------------+               +---------------+
                 |      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: Timing Recovery Reference Diagram

   The following notations are used in Figure 1:

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






Riegel, et al.         Expires December 29, 2003                [Page 9]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   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 IWF of the PW

   Dec
      CE-bound IWF of the PW. It contains a compensation buffer (also
      known as the "jitter buffer") of limited size.

   "==>"
      TDM end service circuits

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

   The characters "A" - "L" are denoting various clocks:

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

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

   "G", "H"
      The same as "A" and "B" respectively for CE2 and PE2 ("G" and "H"
      have the same frequency).

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

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

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





Riegel, et al.         Expires December 29, 2003               [Page 10]


Internet-Draft           PWE3 TDM Requirements                 June 2003


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

   "J", "K"
      The same as "E" and "F" respectively for PE1 and CE1 ("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.

   One of the objectives of edge-to-edge-emulation of a TDM circuit is
   balance between clocks "B" and "E" (i.e., these clocks MUST have the
   same frequency). This objective may be achieved by different means
   depending on the actual network synchronization scheme deployed.

   The following groups of the network synchronization deployment
   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:
      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 the so-called loop timing).

















Riegel, et al.         Expires December 29, 2003               [Page 11]


Internet-Draft           PWE3 TDM Requirements                 June 2003


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

      Figure 2: PE synchronized scenario

   o  CE Synchronized Network:
      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 the so-called 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.

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



Riegel, et al.         Expires December 29, 2003               [Page 12]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   this purpose.

   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 the so-called loop timing).

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


   Figure 3: Relative network scenario

   Timing information may be transferred in this case.

4.3.3 Adaptive Network Scenario

   The asynchronous scenario is characterized by:

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

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











Riegel, et al.         Expires December 29, 2003               [Page 13]


Internet-Draft           PWE3 TDM Requirements                 June 2003


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

   Figure 4: Asynchronous Scenario

   Asynchronous Carrier of Carriers scenario clearly represents the
   worst case for achieving the goal of balancing clocks "A" and "E".

   Note that one of the means available for achieving this goal is the
   compensation buffer in the CE-bound IWF, and the balance between
   clocks "A" and "E" must be exact over the period required for
   replaying out of this buffer.

   Timing information must be transferred in this case.

5. Emulated Services

   This document 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 Unstructured TDM Circuits

   o  Unstructured E1 as described in [G.704].

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

   o  Unstructured E3 as defined in [G.751].

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



Riegel, et al.         Expires December 29, 2003               [Page 14]


Internet-Draft           PWE3 TDM Requirements                 June 2003


5.2 Structured TDM Circuits

   o  Structured E1/T1 with or without CAS as described in [G.704]

   o  NxDS0 with or without CAS


5.3 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


6. Generic Requirements

6.1 Relevant Common PW Requirements

   The combination of encapsulation and payload layers for edge-to-
   edge-emulation considered in this document should comply with the
   following common PW requirements defined in [PWE3-REQ]:

   1.  Conveyance of Necessary Header Information:

       1.  For unstructured circuits this functionality MAY be provided
           by the payload layer.

       2.  For structured circuits, the necessary information MUST be
           provided by the encapsulation layer.

   2.  Support of Multiplexing and Demultiplexing if supported by the
       native services:

       1.  Relevant for Nx DS0 circuits with or without signaling and Nx
           VT-x in a single STS-1 or VC-4.

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

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



Riegel, et al.         Expires December 29, 2003               [Page 15]


Internet-Draft           PWE3 TDM Requirements                 June 2003


           for multiplexing and demultiplexing MAY be the favorite
           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.

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

   o  Support of variable length PDUs,

   o  Fragmentation.


6.2 Common Circuit Payload Requirements

   Structured circuits considered in this document belong to the
   'Structured bit-stream' payload type defined in [PWE3-ARCH].

   Unstructured circuits considered in this document belong to the
   'Bit-stream' payload type defined in [PWE3-ARCH].

   Accordingly, the encapsulation layer MUST provide the common
   Sequencing service and SHOULD provide Timing information
   (Synchronization services).

   Note: The encapsulation layer for the (Structured) Bit-stream payload
   circuits MAY NOT provide the length service.

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

7. Service-Specific Requirements

7.1 Interworking

   1.  The emulation MUST support network interworking between end
       services of the same type (see Section 5) and, wherever
       appropriate, bit-rate.



Riegel, et al.         Expires December 29, 2003               [Page 16]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   2.  The encapsulation layer SHOULD remain unaffected by specific
       characteristics of connection between the end services 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 for:

       1.  balancing of clock of ingress and egress end services
           regardless of the specific network synchronization scenario,

       2.  keeping the jitter and wander of the clock of the egress
           service 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 offer additional benefits (e.g., facilitate
       better reconstruction of the native service clock).


7.3 Robustness

   The robustness of the emulated service does not only depend upon
   means applied to the edge-to-edge-emulation but also upon proper
   implementation of the procedures of the native TDM service.

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.  Allow independent interpretation of TDM data in each specific
       packet by the egress PE (see [RFC2736]. This requirement MAY be
       disregarded if the egress PE has 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 prediction (within reasonable limits)
       of the arrival time of the next PW packet and detection of lost
       packets that takes such a prediction into account.




Riegel, et al.         Expires December 29, 2003               [Page 17]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   3.  Minimize possible effect of lost packets on recovery of the
       circuit clock by the egress PE depending on the actual network
       synchronization scheme deployed.

   4.  In case of unstructured emulation, facilitate increased
       resilience of CEs against lost packets by allowing the egress PE
       to substitute appropriate data.


7.3.2 Out-of-order delivery

   The encapsulation layer MUST provide the necessary mechanisms that
   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 do usually not require any special
   mechanisms for carrying CE signals as these 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,




Riegel, et al.         Expires December 29, 2003               [Page 18]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   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 be
   dealt within the scope of 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:

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

       2.  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
       in the PSN.

   2.  The encapsulation layer SHOULD provide for saving the 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 structured case by not sending channels
       that are permanent inactive.

   4.  The encapsulation layer MAY enable the dynamic suppression of
       temporarily unused channels from transmission for the structured
       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 from the service rate.


7.6 Packet Delay Variation

   In accordance with the PWE3 principles, the PWs do not exert any



Riegel, et al.         Expires December 29, 2003               [Page 19]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   control over the underlying PSN. In particular, the encapsulation
   layer for edge-to-edge-emulation of TDM circuits does neither affect
   one-way delay of packets from ingress to egress PE, nor its
   variation.

   The encapsulation layer SHOULD provide for ability to compensate for
   the packet delay variation without affecting jitter and wander of the
   egress end service clock.

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

   Edge-to-edge emulation of TDM circuits may result in constant bit
   rate flows in the PSN. When transfered over the Internet congestion
   control of TDM PWs MUST be provided by appropriate means. It MUST be
   avoided that all pseudo wires in the congested network are switched
   down simultaneously or the pseudo wires are reestablished again
   simultaneously to avoid unstable behaviour of the network.
   Further considerations are listed 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. Importance of this requirement
       stems from the customers' expectations based upon powerful means
       of misconnection detection in SONET/SDH networks.

   2.  Loss of packets. Importance of this requirement stems from the
       providers' need to distinguish between various causes of the
       end-to-end outage of the emulated service.




Riegel, et al.         Expires December 29, 2003               [Page 20]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   3.  Malformed packets.

   4.  Loss of synchronization.


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 listed in [PWE3-REQ] fully apply also to
   the emulation of TDM circuits.

9. References

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

   [PWE3-ARCH] draft-ietf-pwe3-arch-04.txt Stewart Bryant et al, PWE3
   Architecture, Work in progress, June 2003

   [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

   [GR253] Telecordia Technologies, "Synchronous Optical Network (SONET)
   Transport Systems: Common Generic Criteria", GR-253-CORE, Issue 3,
   (09/00)

   [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



Riegel, et al.         Expires December 29, 2003               [Page 21]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   hierarchical levels

   [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.752] ITU-T Recommendation G.752 (11/88) - Characteristics of
   digital multiplex equipments based on a second order bit rate of 6312
   kbit/s and using positive justification

   [G.823] ITU-T Recommendation G.823 (03/00) - The control of jitter
   and wander within digital networks which are based on the 2048 kbit/s
   hierarchy

   [G.824] ITU-T Recommendation G.824 (03/00) - The control of jitter
   and wander within digital networks which are based on the 1544 kbit/s
   hierarchy

   [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

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


Authors' Addresses

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

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









Riegel, et al.         Expires December 29, 2003               [Page 22]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   Alexander  (Sasha) Vainshtein
   Axerra Networks
   24 Raoul Wallenberg St.
   Tel Aviv  69719
   Israel

   Phone: +972-3-7569993
   EMail: sasha@axerra.com


   Yaakov (Jonathan) Stein
   RAD Data Communications
   24 Raoul Wallenberg St., Bldg. C
   Tel Aviv  69719
   Israel

   Phone: +972-3-645-5389
   EMail: yaakov_s@rad.com


   Prayson Pate
   Overture Networks, Inc.
   507 Aviation Blvd, Suite 111
   Morrisville, NC  27560
   USA

   EMail: prayson.pate@overturenetworks.com


   Ron Cohen
   Lycium Networks
   14 Hatidhar st.
   Raanana  43000
   Israel

   Phone: +972-9-7619004
   EMail: ronc@lyciumnetworks.com


   Tim Frost
   Zarlink Semiconductor
   Tamerton Road
   Roborough, Plymouth  PL6 7BQ
   UK

   EMail: tim.frost@zarlink.com





Riegel, et al.         Expires December 29, 2003               [Page 23]


Internet-Draft           PWE3 TDM Requirements                 June 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   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



Riegel, et al.         Expires December 29, 2003               [Page 24]


Internet-Draft           PWE3 TDM Requirements                 June 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Riegel, et al.         Expires December 29, 2003               [Page 25]


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