RFC 4197 - Requirements for Edge-to-Edge Emulation of Time D

时间:2006-11-01 来源: 作者: 点击:
NetworkWorkingGroupM.Riegel RequestforComments:4197SiemensAG Category:Informational October2005 RequirementsforEdge-to-EdgeEmulationof TimeDivisionMultiplexed(TDM)Circuitsover PacketSwitchingNetworks StatusofThisMemo Thismemoprovidesinformationforthe
  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.

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

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.

   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

   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

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

   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.

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.

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

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

                       +-----+                 +-----+
      +-----+    |     |- - -|=================|- - -|     |    +-----+
      | /-- |<---------|............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|
                                    +-+
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容