<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no"?>
<rfc ipr="full2026" docName="draft-ietf-pwe3-tdm-requirements-02.txt">

<front>
<title abbrev="PWE3 TDM Requirements">
Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)
</title>

<!-- ************** MAX RIEGEL ***************-->
<author initials="M." surname="Riegel" fullname="Maximilian Riegel">
<organization>Siemens AG</organization>
<address>
     <postal>
         <street>St-Martin-Str 76</street>
         <city>Munich</city>
         <code>81541</code>
         <country>Germany</country>
     </postal>
     <phone>+49-89-636-75194</phone>
     <email>maximilian.riegel@siemens.com</email>
</address>
</author>


<!-- ************** SASHA VAINSHTEIN *************** -->
<author initials="A." surname="Vainshtein" fullname="Alexander 
(Sasha) Vainshtein">
<organization>Axerra Networks</organization>
<address>
     <postal>
         <street>24 Raoul Wallenberg St.</street>
         <city>Tel Aviv</city>
         <code>69719</code>
         <country>Israel</country>
     </postal>
     <phone>+972-3-7569993</phone>
     <email>sasha@axerra.com</email>
</address>
</author>

<!-- ************** YAAKOV STEIN *************** -->
<author initials="Y." surname="Stein" fullname="Yaakov (Jonathan) Stein">
<organization>RAD Data Communications</organization>
<address>
     <postal>
         <street>24 Raoul Wallenberg St., Bldg. C</street>
         <city>Tel Aviv</city>
         <code>69719</code>
         <country>Israel</country>
     </postal>
     <phone>+972-3-645-5389</phone>
     <email>yaakov_s@rad.com</email>
</address>
</author>

<!-- ************** PRAYSON PATE *************** -->
<author initials="P." surname="Pate" fullname="Prayson Pate">
<organization>Overture Networks, Inc.</organization>
<address>
     <postal>
         <street>507 Aviation Blvd, Suite 111</street>
         <city>Morrisville</city>
         <region>NC</region>
         <code>27560</code>
         <country>USA</country>
     </postal>
     <email>prayson.pate@overturenetworks.com</email>
</address>
</author>

<!-- ************** RON COHEN *************** -->
<author initials="R." surname="Cohen" fullname="Ron Cohen">
<organization>Lycium Networks</organization>
<address>
     <postal>
         <street>14 Hatidhar st.</street>
         <city>Raanana</city>
         <code>43000</code>
         <country>Israel</country>
     </postal>
     <phone>+972-9-7619004</phone>
     <email>ronc@lyciumnetworks.com</email>
</address>
</author>

<!-- ************** TIM FROST *************** -->
<author initials="T." surname="Frost" fullname="Tim Frost">
<organization>Zarlink Semiconductor</organization>
<address>
     <postal>
         <street>Tamerton Road</street>
         <city>Roborough</city>
         <region>Plymouth</region>
         <code>PL6 7BQ</code>
         <country>UK</country>
     </postal>
     <email>tim.frost@zarlink.com</email>
</address>
</author>

<date month="December" year="2003" />

<area>Transport</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Requirements</keyword>
<keyword>TDM</keyword>

<abstract>
<t>This document specifies the specific requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital (TDM) 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].
<vspace blankLines="0" />
It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits.</t>
</abstract>

<note title="Co-Authors">
<t>
<figure>
<preamble>The following are co-authors of this document:</preamble>
<artwork>
Sasha Vainshtein   Axerra Networks
Yaakov Stein       RAD Data Communication
Prayson Pate       Overture Networks, Inc.
Ron Cohen          Lycium Networks
Tim Frost          Zarlink Semiconductor
</artwork>
</figure>
</t>
</note>

<note title="Changes from the last revision:">
<t>
- Editorial corrections
<vspace blankLines="0" />
- Careful review of all the wording
<vspace blankLines="0" />
- Refined text for 1. Introduction
<vspace blankLines="0" />
- Corrected requirement in 4.3.3
<vspace blankLines="0" />
- Corrected wording of 5. Emulated Services
<vspace blankLines="0" />
- Refined definition for requirement on fragmentation
<vspace blankLines="0" />
- split of references into normative and informational


</t>
</note>
</front>

<middle>

<section title="Introduction">

<t>This document specifies the specific 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].
<vspace blankLines="0" />
It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits.</t>

<section title="TDM circuits">
<t>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.
<vspace blankLines="0" />
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.</t>

<t>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.
<vspace blankLines="0" />
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.</t>

<t>The framing is imposed by introducing a period 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.</t>

<t>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.</t>

<t>In some cases framing also defines groups of consecutive frames called multiframes. Such grouping imposes an additional level of structure on the TDM bit-stream.</t>

<section title="TDM structure and transport modes">
<t>Unstructured TDM:
<vspace blankLines="0" />
TDM that consists of a raw bit-stream of rate defined in [G.702], with all bits are available for payload.</t>

<t>Structured TDM:
<vspace blankLines="0" />
TDM with one ore more levels of structure delineation, including frames, channelization, and multiframes (e.g. as defined in [G.704], [G.751], [T1.107]).</t>
 
<t>Structure-Agnostic Transport:
<vspace blankLines="0" />
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.</t>

<t>Structure-Aware Transport:
<vspace blankLines="0" />
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 MPLS 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.</t>

</section>

</section>

<section title="SONET/SDH circuits">
<t>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.</t>

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

<t>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 payload 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.</t>

<t>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.</t>
</section>

</section>

<section title="Motivation">

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

<t>The need for a specific document complementing [PWE3-REQ] addressing edge-to-edge-emulation of TDM circuits arises from following:
    <list style="symbols">
    <t>Specifics of the TDM circuits,
    <vspace blankLines="0" />
    e.g.:
        <list style="symbols">
        <t>the need for balance between the clock of ingress and egress attachment circuits in each direction of the PW,</t>
        <t>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.</t>
        </list>
    </t>
    <t>Specifics of applications using TDM circuits,
    <vspace blankLines="0" />
    e.g. voice applications:
        <list style="symbols">
        <t>put special emphasis on minimization of one-way delay,</t>
        <t>are relatively tolerant to errors in data.</t>
        </list>
    Other applications might have different specifics.
    <vspace blankLines="0" />
    e.g. transport of signaling information:
        <list style="symbols">
        <t>is relatively tolerant to one-way delay,</t>
        <t>is sensitive to errors in transmitted data.</t>
        </list>
    </t>
    <t>Specifics of the customers' expectations regarding end-to-end behavior of services that contain emulated TDM circuits,
    <vspace blankLines="0" />
    e.g., experience with carrying such services over SONET/SDH networks increases the need for:
        <list style="symbols">
        <t>isolation of problems introduced by the PSN from those occurring beyond the PSN bounds,</t>
        <t>sensitivity to misconnection, </t>
        <t>sensitivity to unexpected connection termination, etc.</t>
        </list>
    </t>
    </list>
</t>
</section>

<section title="Terminology">

<t>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].</t>
<t>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:</t>

<t>TDM networks employ CAS or CCS signaling 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.</t>

<t>
<list style="hanging">
<t hangText="CAS (Channel-Associated Signaling)"><vspace blankLines="0" />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 transfered at a rate slower than the TDM traffic in a timeslot, one needn't 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.</t>

<t hangText="CCS (Common Channel Signaling)"><vspace blankLines="0" />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.
<vspace blankLines="0" />
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].</t>
</list>
</t>
<t>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]).</t>
</section>

<section title="Reference Models">

<section title="Generic PWE3 Models">

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

<t>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].</t>
</section>

<section title="Clock Recovery">
<t>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.</t>
</section>

<section  anchor="syncref" title="Network Synchronization Reference Model">

<t>A generic network synchronization reference model shown in Figure 1 below:</t>

<figure>
<artwork><![CDATA[
           +---------------+               +---------------+
           |      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-----------------------------+
]]></artwork>
<postamble>Figure 1: The Network Synchronization Reference Model</postamble>
</figure>

<t>The following notations are used in Figure 1:</t>
<t>
<list style="hanging">
<t hangText='CE1, CE2'><vspace blankLines="0" />Customer edge devices terminating TDM circuits to be emulated.</t>

<t hangText='PE1, PE2'><vspace blankLines="0" />Provider edge devices adapting these end services to PW.</t>

<t hangText='S1, S2'><vspace blankLines="0" />Provider core routers</t>

<t hangText='Phy'><vspace blankLines="0" />Physical interface terminating the TDM circuit.</t>

<t hangText='Enc'><vspace blankLines="0" />PSN-bound IWF of the PW</t>

<t hangText='Dec'><vspace blankLines="0" />CE-bound IWF of the PW. It contains a compensation buffer (also known as the "jitter buffer") of limited size.</t>
<t hangText='"==>"'><vspace blankLines="0" />TDM attachment circuits</t>

<t hangText='"::>"'><vspace blankLines="0" />PW providing edge-to-edge-emulation for the TDM circuit.</t>
</list>
</t>
<t>The characters "A" - "L" are denoting various clocks:</t>
<t>
<list style="hanging">
<t hangText='"A"'><vspace blankLines="0" />The clock used by CE1 for transmission of the TDM attachment circuit towards CE1.</t>

<t hangText='"B"'><vspace blankLines="0" />The clock recovered by PE1 from the incoming TDM attachment circuit. "A" and "B" always have the same frequency.</t>

<t hangText='"G", "H"'><vspace blankLines="0" />The same as "A" and "B" respectively for CE2 and PE2 ("G" and "H" have the same frequency).</t>

<t hangText='"C", "D"'><vspace blankLines="0" />Local oscillators available to PE1 and PE2 respectively.</t>

<t hangText='"E"'><vspace blankLines="0" />Clock used by PE2 to transmit the TDM attachment service circuit to CE2 (the recovered clock).</t>

<t hangText='"F"'><vspace blankLines="0" />Clock recovered by CE2 from the incoming TDM attachment service ("E and "F" have the same frequency).</t>

<t hangText='"I"'><vspace blankLines="0" />If it exists, it is the common network reference clock available to PE1 and PE2.</t>

<t hangText='"J", "K"'><vspace blankLines="0" />The same as "E" and "F" respectively for PE1 and CE1 ("J" and "K" have the same frequency).</t>

<t hangText='"L"'><vspace blankLines="0" />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.</t>
</list>
</t>
<t>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.</t>

<t>The following groups of synchronization scenarios can be considered:</t>

<section title="Synchronous Network Scenarios">

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

    <list style="symbols">
    <t>PE Synchronized Network:<vspace blankLines="0" />
    The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I":
        
        <list style="symbols">
        <t>Clocks "E" and "J" are the same as "D" and "C" respectively.</t>

        <t>Clocks "A" and "G" are the same as "K" and "F" respectively (i.e., CE1 and CE2 use loop timing).</t>
        </list>
<figure>
<artwork><![CDATA[
                    +-----+                 +-----+
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   | /-- |<---------|............PW1..............|<---------| <-\ |
   || CE |    |     | PE1 |                 | PE2 |     |    |CE2 ||
   | \-> |--------->|............PW2..............|--------->| --/ |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
                    +-----+                 +-----+
                       ^                       ^
                       |C                      |D
                       +-----------+-----------+
                                   |
                                  +-+
                                  |I|
                                  +-+
]]></artwork>
<postamble>Figure 2: PE synchronized scenario</postamble>
</figure>
    </t>
    <t>CE Synchronized Network:<vspace blankLines="0" />
    The common network reference clock "L" is available to all the CE devices, and local oscillators "A" and "G" are locked to "L":
        
        <list style="symbols">

        <t>Clocks "E" and "J" are the same as "G" and "A" respectively (i.e., PE1 and PE2 use loop timing).</t>
        </list>
<figure>
<artwork><![CDATA[
                    +-----+                 +-----+
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
     ^              +-----+                 +-----+              ^
     |A                                                         G|
     +----------------------------+------------------------------+
                                  |
                                 +-+
                                 |L|
                                 +-+
]]></artwork>
<postamble>Figure 3: CE synchronized scenario</postamble>
</figure>
     </t>
     </list>
<vspace blankLines="0" />
No timing information has to be transferred in these cases.
</t>
</section>

<section title="Relative Network Scenario">

<t>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.</t>

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

    <list style="symbols">
    <t>Clocks "A" and "G" are generated locally without reference to a common clock.</t>
    <t>Clocks "E" and "J" are generated in reference to a common clock available at all PE devices.</t>
    </list>
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).
    <figure>
<artwork><![CDATA[
                                                              |G
                    +-----+                 +-----+           v
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
        ^           +-----+<-------+------->+-----+
        |A                         |
                                  +-+
                                  |I|
                                  +-+

]]></artwork>
<postamble>Figure 3: Relative network scenario</postamble>
</figure>
<vspace blankLines="1" />
Timing information (the difference between the common reference clock "I" and the incoming like clock "A") MUST be explicitly transferred in this case.
</t>
</section>


<section title="Adaptive Network Scenario">

<t>The asynchronous scenario is characterized by:
    <list style="symbols">
    <t>No common network reference clock "I" is available to PE1 and PE2.</t>
    <t>No common reference clock "L" is available to CE1 and CE2.</t>
    </list>
</t>
<figure>
<artwork><![CDATA[
                     |J                                       |G
                     v                                        |
                    +-----+                 +-----+           v
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
        ^           +-----+                 +-----+
        |                                        ^
       A|                                       E|
]]></artwork>
<postamble>Figure 4: Asynchronous Scenario</postamble>
</figure>

<t>Balancing clocks "A" and "E" for this case is clearly more challenging than in the other scenarios.</t>

<t>Note that the balance between clocks "A" and "E" must be exact over the period required for playing out of the jitter buffer.</t>

<t>Timing information MAY be explicitly transferred in this case.</t>

</section>

</section>

</section>

<section anchor="types" title="Emulated Services">

<t>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.</t>

<t>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.</t>

<t>The service-specific encapsulation layer for edge-to-edge emulation comprises the following services over a PSN:</t>

<section title="Structure-Agnostic Transport">
<t>
<list style="symbols">
<t>E1 as described in [G.704].</t>

<t>T1 (DS1) as described in [G.704].</t>

<t>E3 as defined in [G.751].</t>

<t>T3 (DS3) as described in [T.107].</t>

</list>
</t>
</section>

<section title="Structure-Aware Transport">
<t>
<list style="symbols">
<t>E1/T1 with one of the structures imposed by framing as described in  [G.704]</t>

<t>NxDS0 with or without CAS</t>
</list>
</t>
</section>

<section title="Structure-Aware Transport of SONET/SDH Circuits">
<t>
<list style="symbols">
<t>SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3</t>

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

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

<t>SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3</t>
</list>
</t>

<t>Note: Structure-agnostic transport of SONET/SDH is out of scope of these requirements. It would seem that structure must be taken into account for this case.</t>

</section>

</section>

<section title="Generic Requirements">

<section title="Relevant Common PW Requirements">

<t>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]:

    <list style="numbers">
    <t>Conveyance of Necessary Header Information:

        <list style="numbers">
        <t>For structure-agnostic transport, this functionality MAY be provided by the payload layer.</t>
        <t>For structure-aware transport, the necessary information MUST be provided by the encapsulation layer.</t>
        <t>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.</t>
        </list>
        
    </t>
    <t>Support of Multiplexing and Demultiplexing if supported by the native services:

        <list style="numbers">
        <t>Relevant for Nx DS0 circuits with or without signaling and Nx VT-x in a single STS-1 SPE or VC-4.</t>
        <t>For these circuits the combination of encapsulation and payload layers MUST provide for separate treatment of every sub-circuit.</t>
        <t>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.</t>
        </list>
    </t>

    <t>Intervention or transparent transfer of Maintenance Messages of the Native Services depending on the particular scenario.</t>

    <t>Consideration of Per-PSN Packet Overhead (see also <xref target="overhead" /> below).</t>

    <t>Detection and handling of PW faults. The list of faults is given in <xref target="faults" /> below.</t>

     <t>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.</t>

    </list>
</t>
<t>The following requirement listed in [PWE3-REQ] is not applicable to emulation of TDM services:
    <list style="symbols">
    <t>Support of variable length PDUs.</t>
    </list>
</t>

</section>

<section title="Common Circuit Payload Requirements">

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

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

<t>Accordingly, the encapsulation layer MUST provide the common Sequencing service and SHOULD provide Timing information (Synchronization services) when required (see <xref target="syncref" /> above).</t>

<t>Note: Length service MAY be provided by the encapsulation layer but is not required.</t>
</section>

<section title="General Design Issues">

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

<t>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.</t>

</section>

</section>

<section title="Service-Specific Requirements">

<section title="Interworking">
<t>
<list style="numbers">
<t>The emulation MUST support network interworking between ACs of the same type (see <xref target="types" />) and, wherever appropriate, bit-rate.</t>

<t>The encapsulation layer SHOULD remain unaffected by specific characteristics of connection between the ACs and PE devices at the two ends of the PW.</t>
</list>
</t>
</section>

<section anchor="clocking" title="Network Synchronization">
<t>
<list style="numbers">
<t>The encapsulation layer MUST provide synchronization services that are sufficient for:

    <list style="numbers">
    <t>balancing of clock of ingress and egress end services regardless of the specific network synchronization scenario,</t>

    <t>keeping the jitter and wander of the clock of the egress service within the service-specific limits as defined by the appropriate normative references.</t>
    </list>
</t>

<t>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).</t>
</list>
</t>
</section>

<section title="Robustness">

<t>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.</t>

<section anchor="packetloss" title="Packet loss">

<t>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.</t>

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

    <list style="numbers">
    <t>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.</t>

    <t>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.</t>

    <t>Minimize possible effect of lost packets on recovery of the circuit clock by the egress PE.</t>

    <t>Facilitate increased resilience of CE TDM interfaces against effects produced by packet loss by allowing the egress PE to substitute appropriate data.</t>
    </list>
</t>

</section>

<section title="Out-of-order delivery">

<t>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:

    <list style="numbers">
    <t>MUST be detected,</t>

    <t>SHOULD be reordered if not judged to be too late or too early for playout.</t>
    </list>
</t>

<t>Out-of-order packets that cannot be reordered MUST be treated as lost.</t>
</section>

</section>

<section title="CE Signaling">

<t>Unstructured TDM circuits would not usually require any special mechanism for carrying CE signaling as this would be carried as part of the emulated service.</t>

<t>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.</t>

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

    <list style="numbers">
    <t>Ability to support different signaling schemes with minimal impact on encapsulation of TDM data,</t>

    <t>Multiplexing of application-specific CE signals and data of the emulated service in the same PW,</t>

    <t>Synchronization (within the application-specific tolerance limits) between CE signals and data at the PW egress,</t>

    <t>Probabilistic recovery against possible occasional loss of packets in the PSN,</t>

    <t>Deterministic recovery of the CE application state after PW setup and network outages.</t>
    </list>
</t>

<t>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.</t>

</section>

<section anchor="overhead" title="PSN bandwidth utilization">
<t>
<list style="numbers">
<t>The encapsulation layer SHOULD allow for an effective trade-off between the following requirements:

    <list style="numbers">
    <t>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.</t>

    <t>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.</t>
    </list>
<vspace blankLines="0" />
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.</t>

<t>The encapsulation layer MAY provide for saving PSN bandwidth by not sending corrupted TDM data across the PSN.</t>

<t>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.</t>

<t>The encapsulation layer MAY enable the dynamic suppression of temporarily unused channels from transmission for the structure-aware case.
<vspace blankLines="0" />
If used, dynamic suppression of temporarily unused channels MUST NOT violate integrity of the structures delivered over the PW.</t>

<t>For NxDS0 the encapsulation layer MUST provide the ability to keep the edge-to-edge delay independent of the service rate.</t>

</list>
</t>
</section>

<section title="Packet Delay Variation">

<t>In accordance with the PWE3 principles, the PWs do not exert any control over the underlying PSN. In particular, the encapsulation layer for edge-to-edge-emulation of TDM circuits neither affects one-way delay of packets from ingress to egress PE, nor its variation.</t>

<t>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.</t>

<t>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.</t>

</section>

<section title="Compatibility with the Existing PSN Infrastructure">

<t>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.</t>

</section>

<section title="Congestion Control">

<t>Edge-to-edge emulation of TDM circuits generate constant traffic loads in the PSN, and hence when congestion is detected back-off mechanisms similar to those of TCP may not be applicable.</t>
<t>The ability to shut down a TDM PW when congestion has been detected MUST be provided.</t>
<t>Precautions should be taken to avoid situations wherein multiple TDM PWs are simultaneously shut down or re-established, thus leading to PSN instability.</t>
<t>Further congestion considerations are discussed in chapter 6.5 of [PWE3-ARCH].</t>

</section>

<section anchor="faults" title="Fault Detection and Handling">

<t>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:

    <list style="numbers">
    <t>Misconnection, or Stray Packets. The importance of this requirement stems from customer expectation due to reliable misconnection detection in SONET/SDH networks.</t>

    <t>Packet Loss. Packet loss detection required in order to maintain clock integrity, as discussed in <xref target="packetloss" /> above. In addition, packet loss detection mechanisms SHOULD provide for localization of the outage in the end-to-end emulated service.</t>

    <t>Malformed packets.</t>

    </list>
</t>

</section>

<section title="Performance Monitoring">

<t>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.</t>
</section>

</section>

<section title="Security Considerations">

<t>The security considerations listed in [PWE3-REQ] fully apply also to the emulation of TDM circuits.</t>

</section>

<section title="References">

<section title="Normative References">

<t>[PWE3-REQ] draft-ietf-pwe3-requirements-07.txt XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to- Edge (PWE3), Work in Progress, October 2003</t>

<t>[PWE3-ARCH] draft-ietf-pwe3-arch-06.txt Stewart Bryant et al, PWE3 Architecture, Work in progress, October 2003</t>

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

<t>[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</t>

<t>[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</t>

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

<t>[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</t>

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

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

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

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

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

<t>[T1.105] ANSI T1.105 - 2001 Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates, and Formats, May 2001</t>

<t>[T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format Specification</t>

</section>

<section title="Informative References">

<t>[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</t>

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

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

</section>

</section>

</middle>

<back>

</back>

</rfc>
