doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc4197.txt b/doc/rfc/rfc4197.txt
new file mode 100644
index 0000000..bb5379e
--- /dev/null
+++ b/doc/rfc/rfc4197.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                          M. Riegel
+Request for Comments: 4197                                    Siemens AG
+Category: Informational                                     October 2005
+
+
+              Requirements for Edge-to-Edge Emulation of
+             Time Division Multiplexed (TDM) Circuits over
+                       Packet Switching Networks
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+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                       Informational                      [Page 1]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. TDM Circuits Belonging to the PDH Hierarchy ................3
+           1.1.1. TDM Structure and Transport Modes ...................4
+      1.2. SONET/SDH Circuits .........................................4
+   2. Motivation ......................................................5
+   3. Terminology .....................................................6
+   4. Reference Models ................................................7
+      4.1. Generic PWE3 Models ........................................7
+      4.2. Clock Recovery .............................................7
+      4.3. Network Synchronization Reference Model ....................8
+           4.3.1. Synchronous Network Scenarios ......................10
+           4.3.2. Relative Network Scenario ..........................12
+           4.3.3. Adaptive Network Scenario ..........................12
+   5. Emulated Services ..............................................13
+      5.1. Structure-Agnostic Transport of Signals out of the
+           PDH Hierarchy .............................................13
+      5.2. Structure-Aware Transport of Signals out of the
+           PDH Hierarchy .............................................14
+      5.3. Structure-Aware Transport of SONET/SDH Circuits ...........14
+   6. Generic Requirements ...........................................14
+      6.1. Relevant Common PW Requirements ...........................14
+      6.2. Common Circuit Payload Requirements .......................15
+      6.3. General Design Issues .....................................16
+   7. Service-Specific Requirements ..................................16
+      7.1. Connectivity ..............................................16
+      7.2. Network Synchronization ...................................16
+      7.3. Robustness ................................................16
+           7.3.1. Packet loss ........................................17
+           7.3.2. Out-of-order delivery ..............................17
+      7.4. CE Signaling ..............................................17
+      7.5. PSN Bandwidth Utilization .................................18
+      7.6. Packet Delay Variation ....................................19
+      7.7. Compatibility with the Existing PSN Infrastructure ........19
+      7.8. Congestion Control ........................................19
+      7.9. Fault Detection and Handling ..............................20
+      7.10. Performance Monitoring ...................................20
+   8. Security Considerations ........................................20
+   9. References .....................................................20
+      9.1. Normative References ......................................20
+      9.2. Informative References ....................................21
+   10. Contributors Section ..........................................22
+
+
+
+
+
+
+
+
+Riegel                       Informational                      [Page 2]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+1.  Introduction
+
+   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 (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 [RFC3985].  It makes references to requirements
+   in [RFC3916] where applicable and complements [RFC3916] 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 contains 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 8-bit-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.
+
+
+
+
+
+Riegel                       Informational                      [Page 3]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   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.
+
+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], and [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 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 transported bits will be 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 to 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
+
+
+
+
+
+Riegel                       Informational                      [Page 4]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   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.
+
+   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
+
+   [RFC3916] specifies common requirements for edge-to-edge emulation of
+   circuits of various types.  However, these requirements, as well as
+   references in [RFC3985], do not cover specifics of PWs carrying TDM
+   circuits.
+
+   The need for a specific document to complement [RFC3916] addressing
+   of edge-to-edge emulation of TDM circuits arises from the following:
+
+   o  Specifics of the TDM circuits.  For example,
+
+      *  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.  For example, voice
+      applications,
+
+      *  put special emphasis on minimization of one-way delay, and
+
+
+
+Riegel                       Informational                      [Page 5]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+      *  are relatively tolerant to errors in data.
+
+   o  Other applications might have different specifics.  For example,
+      transport of signaling information
+
+      *  is relatively tolerant to one-way delay, and
+
+      *  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.  For
+      example, 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 [RFC3985], Section 1.4 are used consistently.
+   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 in every TDM frame.  Hence,
+      CAS systems cycle through all the signaling bits only after some
+      number of TDM frames, which defines 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                       Informational                      [Page 6]
+
+RFC 4197                 PWE3 TDM Requirements              October 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 [RFC3985] 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 [RFC3985].
+
+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.
+
+
+
+
+
+
+
+
+Riegel                       Informational                      [Page 7]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+4.3.  Network Synchronization Reference Model
+
+   Figure 1 shows a generic network synchronization reference model.
+
+          +---------------+               +---------------+
+          |      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                       Informational                      [Page 8]
+
+RFC 4197                 PWE3 TDM Requirements              October 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                       Informational                      [Page 9]
+
+RFC 4197                 PWE3 TDM Requirements              October 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 is an adapted version of the generic network reference
+      model, and 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                       Informational                     [Page 10]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+                       +-----+                 +-----+
+      +-----+    |     |- - -|=================|- - -|     |    +-----+
+      | /-- |<---------|............PW1..............|<---------| <-\ |
+      || CE |    |     | PE1 |                 | PE2 |     |    |CE2 ||
+      | \-> |--------->|............PW2..............|--------->| --/ |
+      +-----+    |     |- - -|=================|- - -|     |    +-----+
+                       +-----+                 +-----+
+                          ^                       ^
+                          |C                      |D
+                          +-----------+-----------+
+                                      |
+                                     +-+
+                                     |I|
+                                     +-+
+
+                     Figure 2: PE Synchronized Scenario
+
+   o  CE Synchronized Network:
+
+      Figure 3 is an adapted version of the generic network reference
+      model, and 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                       Informational                     [Page 11]
+
+RFC 4197                 PWE3 TDM Requirements              October 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 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
+
+   In this case, timing information (the difference between the common
+   reference clock "I" and the incoming clock "A") MUST be explicitly
+   transferred 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.
+
+   o  No common reference clock "L" is available to CE1 and CE2.
+
+
+
+Riegel                       Informational                     [Page 12]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   Figure 5 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.
+
+   In this case, timing information MAY be explicitly transferred 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 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:
+
+   o  E1 as described in [G.704].
+
+   o  T1 (DS1) as described in [G.704].
+
+
+
+Riegel                       Informational                     [Page 13]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   o  E3 as defined in [G.751].
+
+   o  T3 (DS3) as described in [T1.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.  For this case, it would seem that structure must be taken
+   into account.
+
+6.  Generic Requirements
+
+6.1.  Relevant Common PW Requirements
+
+   The encapsulation and payload layers MUST conform to the common PW
+   requirements defined in [RFC3916]:
+
+   1.  Conveyance of Necessary Header Information:
+
+       A.  For structure-agnostic transport, this functionality MAY be
+           provided by the payload layer.
+
+       B.  For structure-aware transport, the necessary information MUST
+           be provided by the encapsulation layer.
+
+
+
+
+
+
+Riegel                       Informational                     [Page 14]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+       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 [RFC3916] 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 [RFC3985].
+
+   Structure-aware transport treats these circuits as belonging to the
+   "Structured bit-stream" payload type defined in [RFC3985].
+
+   Accordingly, the encapsulation layer MUST provide the common
+   Sequencing service and SHOULD provide Timing information
+   (Synchronization services) when required (see Section 4.3 above).
+
+
+
+Riegel                       Informational                     [Page 15]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   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 Section 3 of [RFC1958] and [RFC3985].
+
+   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, and
+
+       B.  keep the jitter and wander of the egress service clock within
+           the service-specific limits 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).
+
+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.
+
+
+
+Riegel                       Informational                     [Page 16]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+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 the 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, and
+
+   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
+   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 the changes of state of these
+   applications relative to the TDM data.
+
+
+
+
+Riegel                       Informational                     [Page 17]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   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, and
+
+   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 the encapsulation layer header does not depend on the size
+           of its payload, an 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 it decreases with the packet
+           payload size.
+
+       The compensation buffer used by the CE-bound IWF increases
+       latency to the emulated circuit.  Additional delays introduced by
+       this buffer SHOULD NOT exceed the packet delay variation observed
+       in the PSN.
+
+   2.  The encapsulation layer MAY provide for saving PSN bandwidth by
+       not sending corrupted TDM data across the PSN.
+
+
+
+
+
+
+Riegel                       Informational                     [Page 18]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   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 the 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 the 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
+   the demand to the network congestion state is, therefore, not
+   applicable.
+
+   The ability to shut down a TDM PW when congestion has been detected
+   MUST be provided.
+
+
+
+
+
+
+Riegel                       Informational                     [Page 19]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   Precautions should be taken to avoid situations wherein multiple TDM
+   PWs are simultaneously shut down or re-established, because this
+   leads to PSN instability.
+
+   Further congestion considerations are discussed in chapter 6.5 of
+   [RFC3985].
+
+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 is required 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 [RFC3916] 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 method of attack.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Riegel                       Informational                     [Page 20]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+9.2.  Informative References
+
+   [RFC3916]    Xiao, X., McPherson, D., and P. Pate, "Requirements for
+                Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
+                September 2004.
+
+   [RFC3985]    Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
+                Edge (PWE3) Architecture", RFC 3985, 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]    Carpenter, B., "Architectural Principles of the
+                Internet", RFC 1958, June 1996.
+
+   [RFC2736]    Handley, M. and C. Perkins, "Guidelines for Writers of
+                RTP Payload Format Specifications", BCP 36, RFC 2736,
+                December 1999.
+
+
+
+
+Riegel                       Informational                     [Page 21]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+   [RFC3393]    Demichelis, C. and P. Chimento, "IP Packet Delay
+                Variation Metric for IP Performance Metrics (IPPM)", RFC
+                3393, November 2002.
+
+   [T1.105]     ANSI T1.105 - 2001 Synchronous Optical Network (SONET) -
+                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
+
+10.  Contributors Section
+
+   The following have contributed to this document:
+
+   Sasha Vainshtein
+   Axerra Networks
+
+   EMail: sasha@axerra.com
+
+
+   Yaakov Stein
+   RAD Data Communication
+
+   EMail: yaakov_s@rad.com
+
+
+   Prayson Pate
+   Overture Networks, Inc.
+
+   EMail: prayson.pate@overturenetworks.com
+
+
+   Ron Cohen
+   Lycium Networks
+
+   EMail: ronc@lyciumnetworks.com
+
+
+   Tim Frost
+   Zarlink Semiconductor
+
+   EMail: tim.frost@zarlink.com
+
+
+
+
+
+Riegel                       Informational                     [Page 22]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+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                       Informational                     [Page 23]
+
+RFC 4197                 PWE3 TDM Requirements              October 2005
+
+
+Full 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.
+
+   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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Riegel                       Informational                     [Page 24]
+