Network Working Group              Alexander ("Sasha") Vainshtein 
                                                       Israel Sasson 
                                                      Akiva Sadovski 
   Internet Draft                                    Axerra Networks 
                                                                     
   Expiration Date:                                      Eduard Metz 
   August 2002                                              KPNQwest 
                                                                     
                                                           Tim Frost 
                                               Zarlink Semiconductor 
                                                                     
                                                       February 2002 
    
   TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) 
                                      
                      draft-vainshtein-cesopsn-02.txt 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of section 10 of RFC 2026.  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts.  
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."   
   The list of current Internet-Drafts can be accessed at  
   http://www.ietf.org/ietf/1id-abstracts.txt. 
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
Abstract 
    
   This document describes a method for encapsulating TDM digital 
   signals defined in the plesiochronous digital hierarchy (PDH)  
   as a pseudo-wire (PW) over various packet-switched networks (PSN).  
   In this regard this document complements similar work for SONET/SDH 
   circuits.  
    
   Proposed PW encapsulation uses RTP for clock recovery and supports 
   signaling between Provider Edge (PE) devices. 
   Encapsulation proposed in this document may be extended to low-rate 
   SONET/SDH traffic as well. 
    
   TABLE OF CONTENTS 
    
1. Introduction                                                      3 
2. Summary of Changes from the -01 Revision                          3 
 
   Vainshtein et al.                                           [Page 1]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
3. Terminology and Reference Models                                  4 
  3.1. Terminology                                                    4 
  3.2. Reference Models                                               5 
    3.2.1. Generic Models                                             5 
    3.2.2. Synchronization Considerations and Deployment Scenarios    5 
    3.2.3. Service Examples                                           6 
4. Scope and Requirements                                            7 
  4.1. Emulated Services                                              7 
    4.1.1. PDH Circuits                                               7 
    4.1.2. SONET/SDH Circuits                                         7 
  4.2. Scope                                                          7 
  4.3. Generic Requirements                                           7 
    4.3.1. Relevant Common PW Requirements                            7 
    4.3.2. Common Circuit Payload Requirements                        8 
    4.3.3. The Principle of Minimal Intervention                      8 
  4.4. Service-Specific Requirements                                  8 
    4.4.1. Interworking                                               8 
    4.4.2. Network Synchronization Schemes                            8 
    4.4.3. CE Signaling                                               9 
    4.4.4. Latency and Encapsulation Effectiveness                    9 
    4.4.5. Fault Detection and Handling                              10 
    4.4.6. Performance Monitoring                                    10 
    4.4.7. Bandwidth Saving                                          10 
    4.4.8. Adaptation of the Jitter Buffer                           10 
5. CESoPSN Encapsulation                                            10 
  5.1. Generic CESoPSN Format                                        10 
  5.2. CESoPSN Header                                                11 
    5.2.1. Usage of RTP Header                                       11 
    5.2.2. Usage and Structure of the Control Word                   12 
  5.3. Payload Data Format                                           13 
    5.3.1. Transparent N*DS0 Circuits                                14 
    5.3.2. N*DS0 circuits with CAS                                   15 
    5.3.3. Unstructured TDM Circuits                                 16 
6. CESoPSN Operation                                                17 
  6.1. Payload Parameters                                            18 
    6.1.1. PW Type                                                   18 
    6.1.2. Circuit Bit Rate                                          18 
  6.2. Encapsulation Layer Parameters                                19 
    6.2.1. Usage of Control Word                                     19 
    6.2.2. RTP Payload Type                                          19 
    6.2.3. Payload Bytes                                             19 
    6.2.4. Timestamp Resolution                                      20 
    6.2.5. Synchronization Source ID                                 20 
    6.2.6. Timestamp Generation Mode                                 20 
  6.3. End Service Inactivity Behavior                               20 
  6.4. Description of the IWF operation                              20 
    6.4.1. PSN-bound Direction                                       20 
    6.4.2. CE-bound Direction - Normal Operation                     21 
    6.4.3. IWF Loopback                                              22 
  6.5. CESoPSN Defects                                               22 
    6.5.1. Misconnection                                             22 
    6.5.2. Re-Ordering and Loss of Packets                           23 
    6.5.3. Malformed Packets                                         23 
 
   Vainshtein et al.           Expires   May-2002              [Page 2]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
    6.5.4. Loss of Synchronization                                   24 
  6.6. Performance Monitoring                                        24 
    6.6.1. Errored Data Blocks                                       24 
    6.6.2. Errored, Severely Errored and Unavailable Seconds         25 
  6.7. QoS Issues                                                    25 
7. RTP Payload Format Considerations                                25 
  7.1. Resilience to moderate loss of individual packets             25 
  7.2. Ability to interpret every single packet                      25 
  7.3. Non-usage of the RTP Header Extensions                        25 
  7.4. Compression of RTP headers                                    25 
8. Congestion Control (RFC 2914) Conformance                        26 
9. FFS Issues                                                       26 
10. Security Considerations                                         26 
11. Applicability Statement                                         26 
12. IANA Considerations                                             28 
13. Intellectual Property Considerations                            28 
ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN                          32 
ANNEX B. EMULATION OF SONET/SDH CIRCUITS                            34 
     
1. Introduction 
    
   This document describes requirements for edge-to-edge emulation of 
   time division multiplexed (TDM) digital signals defined in 
   Plesiochronous Digital Hierarchy (PDH), see [G.703], [G.704], 
   [T.107] [T1.103] and [T1.107a] and a corresponding encapsulation 
   technique. 
     
   To support TDM traffic, which includes voice, data, and private 
   leased line service, the network must emulate the circuit 
   characteristics of a TDM network.  A new circuit emulation header 
   and RTP-based mechanisms for carrying clock over PSN are used to 
   encapsulate TDM signals and provide the Circuit Emulation Service 
   over PSN (CESoPSN).  
    
   Primary application of the technique described in this document is 
   emulation of PDH circuits in situations when native PDH traffic is 
   generated by CE devices and does not depend upon the way this 
   traffic reaches PE devices. However, its use may be extended to 
   carrying SDH traffic as "unstructured TDM", thus providing an 
   alternative to the approach defined in [MALIS]. 
    
   The CESoPSN solution presented in this document fits the framework 
   for PW services as described in [PWE3-FW] and satisfies the general 
   requirements put forward in [PWE3-REQ]. 
    
2. Summary of Changes from the -01 Revision 
    
   Note: This section will be removed from the final document. 
    
      1. A section on generic and service-specific requirements for 
         edge-to-edge emulation of TDM circuits has been added 
      2. Fractional E1/T1 has been consistently replaced with N*DS0 
    
 
   Vainshtein et al.           Expires   May-2002              [Page 3]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
      3. Support of channel-associated CE signaling (CAS) for N*DS0 
         services based upon the techniques defined in [RFC2833] has 
         been added 
      4. The structure of the control word has been aligned with the 
         [MARTINI-ENCAP] 
      5. References have been updated in accordance with the latest 
         developments 
      6. RTP Payload Types have been decoupled from PW types. Dynamic 
         allocation of PT values will be used instead 
      7. Most of the text that should logically belong to more generic 
         PWE3 documents and/or tutorials has been removed 
      8. In-band CESoPSN loopback commands have been removed 
      9. G.826-compatible PM parameters for CESoPSN have been defined 
      10. A brief description of adaptive jitter buffer behavior has 
         been added. 
    
3. Terminology and Reference Models  
 
   3.1. Terminology 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
   document are to be interpreted as described in [RFC2119]. 
    
   The terms defined in [PWE3-FW], Section 1.4 are consistently used, 
   usually without additional explanations. However: 
     o  The terms 'CE-bound' and 'PSN-bound' are consistently used 
         instead of 'outbound' and 'inbound' when describing traffic 
         directions 
     o  The term "Interworking function" (IWF) is often used for 
         describing the protocol operation with explicit references to 
         CE-bound or PSN-bound direction of the IWF. 
    
   Some terms and acronyms are commonly used in conjunction with the 
   TDM services. In particular: 
     o  Alarm Indication Signal (AIS) is a common term denoting a 
         special bit pattern in the TDM bit stream that indicates 
         presence of an upstream circuit outage 
     o  Channel-Associated Signaling (CAS) is one of several signaling 
         techniques used by the telephony applications to convey 
         various states of these applications (e.g., off-hook and ob-
         hook). CAS uses a certain, circuit-specific multiframe 
         structure that is imposed on the TDM bit stream and a 
         predefined association between the relative timeslot (= 
         channel) number within this stream and position of certain 
         bits within this multiframe structure. Up to 16 application 
         states can be distinguished and signaled (see [G.704] for 
         details). 
    
    
    
    
    
 
   Vainshtein et al.           Expires   May-2002              [Page 4]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   3.2. Reference Models 
     3.2.1. Generic Models 
    
   Generic models that have been defined in Sections 3.1 (Network 
   Reference Model), 3.2 (Maintenance Reference Model), 3.4 (Protocol 
   Stack Reference Model) and 3.5(Logical Protocol Layering Model) of 
   [PWE3-FW] are fully applicable for the purposes of this document 
   without any modifications. 
    
   All the services considered in this document represent special cases 
   of the generic circuit-oriented payload type defined in Section 
   3.5.2.1 of [PWE3-FW]. 
    
     3.2.2. Synchronization Considerations and Deployment Scenarios 
    
   Two basic issues must taken into account regarding possible 
   synchronization techniques for emulation of circuit-oriented 
   services: 
     o  Can all the PE devices of the given pseudo-wire domain (PWD) 
         be synchronized? Or, in more precise terms, is the same high-
         quality synchronization source available to all the PE devices 
         in the given PWD? 
     o  Is the CE device synchronized to the same source as its 
         'local' PE? 
   The answer to the first question depends upon design of the specific 
   PSN. E.g. PE devices in a PSN based entirely on POS links can be 
   easily synchronized while PE devices of a PSN based on Gigabit 
   Ethernet links (or on a mix of Gigabit Ethernet and POS) would as 
   often as not remain unsynchronized. 
    
   The answer to the second question depends on specifics of the 
   customers served by the PSN operator. In particular, if the CE 
   devices are just nodes in the customers' TDM networks with their own 
   synchronization schemes, they would probably continue to use these 
   schemes even if the PSN is fully synchronized.  
    
   Combinations of answers to these basic questions provide at least 
   three viable deployment scenarios: 
      1. "One Synchronous Network" Scenario, i.e.: 
           a. The same high-precision synchronization source is 
             available in all the PE devices of the given PSN  
           b. This synchronization source is also used by all the CE 
             devices terminating TDM end services of PWs crossing the 
             PSN 
           c. The PW mechanisms must provide compensation only for the 
             packets inter-arrival jitter introduced by the PSN 
      2. "Synchronous Carriers' Carrier" Scenario, i.e.: 
           a. The same high-precision synchronization source is 
             available in all the PE devices of the given PSN  
           b. Each Emulated circuit connects two CEs that are either 
             loop-timed to the corresponding PE or synchronized to 
             their own synchronization source 
    
 
   Vainshtein et al.           Expires   May-2002              [Page 5]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
    
           c. The PW must carry the difference between the PSN clock and 
             the CE clock over the PSN as well as compensate the 
             packets' inter-arrival jitter introduced by the PSN 
      3. "Asynchronous Carriers' Carrier" Scenario, i.e.: 
           a. Each PE uses its own synchronization source. The quality 
             of this source is selected in accordance with requirements 
             of the emulated services (e.g., a Stratum 4 clock is 
             sufficient for E1 and T1 services) 
           b. Each emulated circuit connects two CEs that are either 
             loop-timed to the corresponding PE or synchronized to 
             their own synchronization source 
           c. Every direction of the PW must carry the original line 
             clock of its end service across the PSN as well as 
             compensate for the packets' inter-arrival jitter 
             introduced by the PSN. 
    
     3.2.3. Service Examples 
    
   Fig.1 below presents several examples of a T1 Emulated Service.  
    
    
                              _/_  \    /    \    / \ 
   +------+ Physical          /+-+            \__/   \    _ Hub Site 
   |Site A|    T1            / |P| +---+              \      (CE-3) 
   |T1 #1=|====================|E|=| R |   +---+ +-+   \ OC12+------+ 
   |(CE-1)|                  \ |1| |   |===|   | | |---------|      | 
   +------+                  / +-+ +---+   |   | | | ========|=T1 #1| 
                            /              | R |=|P|         |      | 
   +------+ T1 +---+  DS3  /   +-+ +---+   |   | |E| ========|=T1 #2| 
   |Site B|    |   |-----------|P| | R |===|   | |3|---------|      | 
   |T1 #2=|====|M13|===========|E|=|   |   +---+ +-+    /    +------+ 
   |(CE-2)|    |   |-----------|2| +---+               / 
   +------+    +---+         \ +-+                   /        
                              \   ___      ___     /          
                               \_/   \____/   \___/ 
    
                     Figure 1: T1 Emulation Example Diagram 
    
   In this diagram, T1 circuits are attached to the PE devices in three 
   different ways: 
     o  As a physical T1 line (between CE-1 and PE-1) 
     o  As a virtual T1 signal multiplexed in DS3 using one of 
         possible multiplexing formats (between CE-2 and PE-2, see 
         [T1.103] for details). M23 is a PDH multiplexor  
     o  As a virtual T1 signal mapped into an appropriate SONET 
         virtual tributary, the latter being multiplexed in OC-12 
         (between CE-3 and PE-3 - see [T1.105] or [G.707] for details). 
    
    
    
    
    
 
   Vainshtein et al.           Expires   May-2002              [Page 6]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
4. Scope and Requirements 
   4.1. Emulated Services 
     4.1.1. PDH Circuits 
    
   This specification describes service-specific encapsulation layer 
   for edge-to-edge emulation of the following TDM services over a PSN: 
    
     1. Structured services: 
         a. Transparent N*DS0, 1 <= N <= 31 as described in [G.704]. 
         b. N*DS0 with channel-associated signaling (CAS) as described 
            in [G.704], 1<= N <= 30 
     2. Unstructured services 
         a. Unstructured E1 as described in [G.704] 
         b. Unstructured T1 (DS1) as described in [T.157a] 
         c. Unstructured E3 as defined in [G.751] 
         d. Unstructured T3 (DS3) as described in [T.157a] 
    
     4.1.2. SONET/SDH Circuits 
    
   Encapsulation layer described in this specification MAY be, with 
   some modifications, also used for emulation of unstructured  "low-
   rate" (STS-1/STM-0, STS-3c/STM-1) SONET/SDH circuits. Details are 
   discussed in Annex B. 
    
   4.2. Scope 
    
   This specification defines only the encapsulation layer for edge-to-
   edge emulation of TDM services mentioned in Section 4.1.  
    
   In accordance with the logical protocol layering architecture for 
   PWE3, the encapsulation layer MUST NOT be dependent upon specific 
   instantiations of: 
     1. The PSN layer (i.e. IPv4, IPv6 or MPLS). In order to satisfy 
         this requirement, encapsulation should be used on packets of 
         fixed size to avoid possible need in the PSN-specific optional 
         length service 
     2. Multiplexing layer. In order to satisfy this requirement and, 
         at the same time, to allow detection of 'stray packets' the 
         encapsulation header SHOULD provide some means for identifying 
         the packets as belonging to the PW.  
 
   4.3. Generic Requirements 
    
   Note: This and the following section should be split into a separate 
   requirements document. 
    
     4.3.1. Relevant Common PW Requirements 
    
   The encapsulation layer for TDM services considered in this document 
   should comply with the following common PW requirements defined in 
   [PWE3-REQ]: 
        1. Conveyance of Necessary L2/L1 Header Information - relevant 
            only for TDM structured services 
 
   Vainshtein et al.           Expires   May-2002              [Page 7]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
        2. Support of Multiplexing and Demultiplexing if supported by 
            the native services - relevant for N*DS0 circuits with or 
            without CAS 
        3. Handling Control Messages of the Native Services - relevant 
            only for structured TDM services 
    
        4. Consideration of the PSN Tunnel Header Overhead (see also 
            Section 4.4.4 below) 
        5. Detection and handling of PW faults (see also Section 4.4.5 
            below). In particular, ability to detect loss of packets 
            SHOULD be supported in order to allow differentiation 
            between outages of the emulated service resulting from PSN 
            problems and these resulting from problems beyond the PSN 
        6. Clock Recovery (see also Section 4.4.2 below). 
    
     4.3.2. Common Circuit Payload Requirements 
    
   All the services considered in this document belong to the generic 
   'Circuit Payload' type defined in [PWE3-FW], Section 3.5.2.1.1. 
    
   Accordingly, the encapsulation layer MUST provide the common 
   Sequencing service and SHOULD provide timing information. 
    
   The encapsulation layer for the Circuit Payload services does not 
   necessarily have to provide the length service. 
     
     4.3.3. The Principle of Minimal Intervention 
    
   The encapsulation layer SHOULD comply with the principle of minimal 
   intervention as described in [PWE3-LAYERS], Section 4.3.5. 
    
   4.4. Service-Specific Requirements 
    
     4.4.1. Interworking 
    
     1. The encapsulation layer MUST support network interworking 
         between end services of the same type and bit-rate.  
     2. The encapsulation layer SHOULD remain unaffected by specific 
         characteristics of connection between the end services and PE 
         devices at the two ends of the PW (see service examples in 
         Section 3.2.3 above). 
    
     4.4.2. Network Synchronization Schemes 
    
   The encapsulation layer MUST be applicable to all the network 
   synchronization schemes mentioned in Section 3.2.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 infer additional benefits (e.g., facilitate better 
   reconstruction of the native service clock) from this fact. 
    
    
 
   Vainshtein et al.           Expires   May-2002              [Page 8]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     4.4.3. CE Signaling 
    
   Unstructured TDM services do not usually require any special 
   mechanisms for carrying CE signals as these would be carried as part 
   of the emulated service.  
    
    
   Structured TDM services may require application-specific CE 
   signaling.  
    
   In some cases this signaling may require synchronization with the 
   data. E.g., code-associated signaling (CAS) reflects the state of 
   telephony applications (like off-hook and on-hook) that must be 
   passed across the emulated service and synchronized with data to 
   allow normal operation of these applications.  
    
   The encapsulation layer SHOULD support signaling of state of CE 
   applications for the relevant services providing for: 
     o  Multiplexing of application-specific CE signals and data of 
         the emulated service in the same PW 
     o  Synchronization (within the application-specific tolerance 
         limits) between CE signals and data at the PW egress  
     o  Probabilistic recovery against possible accidental loss of 
         signaling packets in the PSN 
     o  Deterministic recovery of the CE application state after PW 
         setup and network outages. 
    
   Some types of CE signaling associated with the TDM circuits (e.g., 
   performance monitoring requests and responses, requests to operate 
   and release loopbacks etc.) do not reflect application state and 
   hence do not require synchronization with data. As a consequence, 
   these signals can be passed out-of-band and do not have to be 
   supported by the encapsulation layer. 
    
   The payload format for the 'signaling' packets MAY be application-
   specific. 
    
     4.4.4. Latency and Encapsulation Effectiveness 
    
   The encapsulation layer SHOULD allow for an effective trade-off 
   between the following requirements: 
      1. Effective PSN bandwidth utilization. Assuming that the size of 
         encapsulation layer header does not depend on the size of its 
         payload, increase in the packet payload size results in 
         increased efficiency.  
      2. Low edge-to-edge latency. Low end-to-end latency is the common 
         requirement for Voice applications over TDM services. 
         Packetization latency is one of the components comprising 
         edge-to-edge latency and decreases with the packet payload 
         size. 
    
    
    
 
   Vainshtein et al.           Expires   May-2002              [Page 9]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     4.4.5. 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 of the following defects: 
       1. Misconnection 
       2. Loss of packets. Special importance of detection of this 
          defect has been explained in Section 4.3.1 above 
       3. Malformed packets 
       4. Loss of synchronization. 
      
     4.4.6. 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 (see [G.826] for details). 
    
     4.4.7. Bandwidth Saving 
    
   The encapsulation layer should provide for saving the PSN bandwidth 
   by not sending invalid data.  
    
     4.4.8. Adaptation of the Jitter Buffer 
    
   The encapsulation layer SHOULD allow adaptation of the jitter buffer 
   size to the actually observed level of the packets' inter-arrival 
   jitter while maintaining acceptable levels of errors that are 
   introduced by such an adaptation. 
    
   Note: The meaning of 'acceptable level of errors' depends on the 
   application using the emulated service. In particular, Voice 
   applications can tolerate loss or insertion of a single octet in a 
   contiguous sequence of several non-erroneous octets. (In case of 
   insertion, it is customary to repeat the previous, non-erroneous, 
   octet.) 
 
5. CESoPSN Encapsulation 
    
   5.1. Generic CESoPSN Format 
    
   CESoPSN packets use format shown in Fig. 2 below. 
    
    
    
    
    
    
    
    
    
    
    
 
   Vainshtein et al.           Expires   May-2002             [Page 10]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           ...                                 | 
      |              PSN and multiplexing layer headers               | 
      |                           ...                                 | 
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
      |                       Fixed                                   | 
      +--                                                           --+ 
      |                        RTP                                    | 
      +--                                                           --+ 
      |                  Header (see [RFC1889])                       | 
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
      |               CESoPSN Control Word (optional)                 | 
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
      |           Packetized TDM data or CE signaling data            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
      Figure 2. CESoPSN Format 
    
   5.2. CESoPSN Header 
    
   The CESoPSN header includes a fixed RTP header (12 octets) and an 
   optional CESoPSN Control Word (4 octets). 
    
     5.2.1. Usage of RTP Header 
    
   CESoPSN uses the fields of the fixed RTP header (see [RFC1889], 
   Section 5.1) in the following way: 
    
     o  V (version) is always set to 2 
     o  P (padding) is always set to 0 
     o  X (header extension) is always set to 0 
     o  CC (CSRC count) is always set to 0 
     o  M (marker) is set to 0 to for CESoPSN packets carrying PDH 
         circuits. CESoPSN packets carrying unstructured SONET/SDH 
         circuits MAY set this bit to 1 to distinguish packets that 
         carry the framing octets 
     o  PT (payload type) is used to distinguish between packets 
         carrying the packetized TDM data and packets carrying CE 
         signaling. At least one PT value should be allocated from the 
         range of dynamic values (see [RTP-TYPES]) for every CESoPSN 
         PW. Allocation is done during the PW setup and MUST be the 
         same for both PW directions. The PE at the PW ingress MUST set 
         the PT value in the RTP header to the allocated value. The PE 
         at the PW egress MAY use this value to detect malformed 
         packets. An additional PT value from the same range MUST be 
         allocated for CESoPSN PWs supporting in-band CE signaling (see 
         Section 5.3.2 below) 
     o  Sequence number is used primarily to provide the common PW 
         sequencing function as well as detection of lost packets. It 
         is generated and processed in accordance with the rules 
         established in [RFC1889]  
 
   Vainshtein et al.           Expires   May-2002             [Page 11]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     o  Timestamp is used primarily for carrying timing information 
         over the network. Their values are used in accordance with the 
         rules established in [RFC1889]. Frequency of the clock used 
         for generating timestamps MUST be a multiple of 8 KHz. 
         Possible modes of timestamp generation are discussed below 
     o  The SSRC (synchronization source) value in the RTP header MAY 
         be used for detection of misconnections. 
    
   Note: The same PT value can be safely allocated for different PWs. 
    
   The RTP header in CESoPSN can be used in conjunction with at least 
   the following modes of timestamp generation: 
    
     1. Absolute mode: the ingress PE sets time stamps using the clock 
         recovered from the incoming TDM bit stream 
     2. Differential mode: PE devices connected by the PW have access 
         to the same high-quality synchronization source, and this 
         synchronization source is used for timestamp generation. 
    
   Usage of other timestamp generation modes is left for further study. 
    
   Absolute mode allows operation in the Asynchronous Carrier's Carrier 
   deployment scenario. Differential mode may improve quality of the 
   recovered clock in the One Synchronous Network and Synchronous 
   Carrier's Carrier deployment scenarios. 
    
     5.2.2. Usage and Structure of the Control Word 
    
   Usage of the CESoPSN control word allows: 
    
     o  Differentiation between the PSN problems and the problems 
         beyond the PSN as causes for the emulated service outages 
     o  Saving bandwidth by not transferring invalid data (AIS, idle 
         code) 
     o  Signaling problems detected at the PW egress to its ingress 
    
   Consequently, usage of the CESoPSN Control Word is the recommended 
   default. The PE peers MAY agree not to use it in a specific CESoPSN 
   PW as part of the PW setup process.  
    
   Note: Alternative techniques for conveying forward and backward 
   indications without using the control word are left for further 
   study. 
    
   The structure of the CESoPSN Control Word is shown in Fig. 3 below. 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|0|0|0|A|I|L|T|Z|            Reserved                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
              Figure 3. Structure of the CESoPSN Control Word 
 
   Vainshtein et al.           Expires   May-2002             [Page 12]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     o  Bits 0-3 MUST be set to 0 at ingress and MUST be ignored at 
         egress 
     o  Bit A -  carries Local AIS indication. If set, represents AIS 
         of the carried unstructured circuit. A packet with the A bit 
         set MAY carry no payload 
     o  Bit I - carries Local Idle Code indication. If set, represents 
         the Idle Code in the payload of a N*DS0, a N*DS0 with CAS or 
         an unstructured T3 circuit. A packet with the I bit set MAY 
         carry no payload 
     o  Bit L - carries Remote Loss of Packets indication of the PW 
         carrying CESoPSN, i.e., this bit is set in packets transmitted 
         by PE-2 to PE-1 if PE-2 detected loss of packets in the stream 
         received from PE-1 
     o  Bit T - carries Remote Synchronization Problem indication.  
     o  Bit Z - if set, indicates that the CESoPSN IWF operates under 
         a PW loopback command (regardless of the origin of this 
         command). If cleared, indicates normal CESoPSN IWF operation 
     o  Reserved - these bits are reserved for possible future use. 
         Currently they MUST be set to 0 at ingress and ignored at 
         egress. 
   Notes: 
     1. Either A or I bit (but not both) can be set in the CESoPSN 
         control word. 
     2. Information about lost packets (carried via the L bit) can be 
         used at ingress as an indication to resynchronize CE 
         application state, see Section 5.3.2 below. 
    
   5.3. Payload Data Format 
    
   A single CESoPSN packet always contains one or more native circuit 
   frames of the carried circuit. This provides for emulation of 
   performance monitoring parameters of "classic" carriers of TDM 
   circuits (e.g., SONET/SDH). 
    
   Note: The native circuit frames for all the circuits considered in 
   this document save from unstructured T1 are octet-aligned. The T1 
   native circuit frame (193 bits) is not, and hence requires special 
   treatment - see Section 5.3.4 below.  
    
   The PSN operator selects the number of native service frames in a 
   CESoPSN packet for a specific PW taking into account the following 
   considerations: 
     o  Packetization latency requirements vs. bandwidth utilization 
         (see Section 4.4.4 above) 
     o  Path MTU limitations in order to avoid fragmentation of 
         CESoPSN packets 
    
   This specification assumes that the number of native service frames 
   in a CESoPSN packet is: 
     o  Defined during the PW setup and remains constant for the 
         duration of a PW. Such an arrangement simplifies 
         implementation because it implies that the CESoPSN packets are 
         transmitted at a constant rate 
 
   Vainshtein et al.           Expires   May-2002             [Page 13]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     o  The same for both directions of the PW. Such an arrangement 
         simplifies signaling and processing of backwards problem 
         indications. 
 
     5.3.1. Transparent N*DS0 Circuits 
    
   The payload data format for transparent N*DS0 circuits is shown in 
   Fig. 4 below (N - number of timeslots in the circuit, M = number of 
   the native circuit frames in a CESoPSN packet, the 1st timeslot of 
   the 1st native frame is the 1st octet of the payload). The matrix 
   shown in this diagram is mapped into array of payload octets row by 
   row. 
    
   Timeslots ->|     1         |    2          | ... |       N       | 
   ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
    N  C  F   1|               |               | ... |               | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    a  i  r   2|               |               | ... |               | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    t  r  a ...|               |               | ... |               | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    i  c  m ...|               |               | ... |               | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    v  u  e ...|               |               | ... |               | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    e  i  s ...|               |               | ... |               | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       t      M|               |               | ... |               | 
               +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
    
             Figure 4. Payload structure for a N*DS0 Circuit 
    
   CESoPSN-based emulation of a transparent N*DS0 TDM circuit can be 
   considered as "bundling" of N independent DS0 circuits (see [PWE3-
   REQ], Section 2.1.3). 
    
   The payload structure described provides for adaptation of the 
   jitter buffer size for Voice applications while maintaining 
   acceptable level of errors: 
     o  Actual size of the jitter buffer can be decreased by 
         "shortening" the payload of some of the packets already in the 
         buffer by the one "row" (native circuit frame) when they are 
         transmitted. This is equivalent to dropping one octet from 
         each timeslot 
     o  Actual size of the jitter buffer can be increased by 
         "lengthening" the payload of some of the packets already in 
         the buffer by one "row" (native circuit frames) when they are 
         transmitted. This is equivalent to insertion of a single octet 
         into each timeslot; the values carried in the last actual row 
         of the matrix are repeated. 
    
    
    
 
   Vainshtein et al.           Expires   May-2002             [Page 14]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     5.3.2. N*DS0 circuits with CAS 
    
   A PW that emulates an N*DS0 circuit with CAS assumes that CE devices 
   are PSTN switches that synchronize the state of each of N DS0 
   channels using channel-associated signaling. This PW carries TDM 
   data in format described in the previous section. 
    
   In addition, it carries the CAS state vector of each CE in special 
   signaling packets using: 
    
     o  An additional PT value allocated for this purpose from the 
         range of unused values (see [IANA]). This value MUST be 
         different from one allocated for the TDM data packets for the 
         same PW 
     o  An additional SSRC value that MUST be different from one used 
         for the data packets in order to allow a separate numbering 
         sequence for the signaling packets 
     o  A sequence numbering scheme that does not depend on one used 
         for the data packets. This allows re-use of common sequence 
         numbers-based mechanisms (like reordering and detection of 
         lost packets) for the data packets for all types of circuits 
     o  The signaling payload format described in Fig. 5 below. Format 
         of the 32-bit timeslot signaling word is defined in [RFC2833] 
         Section 3.5 and Section 3.14, and numbering of timeslots 
         corresponds to that of the "columns" in the data packets' 
         payload, see Fig. 4. 
    
        0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              Timeslot signaling word for TS-1                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              Timeslot signaling word for TS-2                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        ...                                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              Timeslot signaling word for TS-N                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Figure 5. Payload of a Signaling Packet for a N*DS0 Circuit with CAS 
    
    
   Note: The "volume" field defined in the [RFC2833] Section 3.5 is not 
   used with CAS events. 
    
    
   CESoPSN does not require handling of loss of signaling packets; as a 
   consequence, detection of loss of these packets is not required 
   either. On the other hand, the same synchronization source MUST be 
   used for timestamps in both signaling and data packets in order to 
   synchronize data and signaling within reasonable limits. 
    
    
 
   Vainshtein et al.           Expires   May-2002             [Page 15]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   Signaling packets are generated by the ingress PE in accordance with 
   the following logic (adapted from [RFC2833]): 
    
        1. The CESoPSN signaling packet with the same information is 
            sent 3 times at an interval of 5 ms under one of the 
            following conditions: 
           a. The CESoPSN PW has been set up 
           b. A change in CAS state of one of the timeslots has been 
             detected. If another change of CAS state has been detected 
             during the 15 ms period, this process continues 
           c. Loss of packets defect has been cleared 
           d. Remote Loss of Packets indication has been cleared (after 
             previously being set) 
        2. Otherwise, the CESoPSN signaling packet with the current 
            CAS state information is sent every 5 seconds. 
    
   These rules allow fast probabilistic recovery after loss of a single 
   signaling packet as well as deterministic (but, possibly, slow) 
   recovery following PW setup and PSN outages. 
    
     5.3.3. Unstructured TDM Circuits 
    
   Basically, unstructured TDM circuits do not require framers in the 
   PE devices, and are transferred as bit streams. However, presence of 
   a framer allows detection of some outages of the end services. As a 
   consequence, efficiency of the CESoPSN operation under such outages 
   may be increased. 
    
   The payload of a CESoPSN packet carrying an unstructured TDM circuit 
   with an octet-aligned native circuit frame MUST contain one or more 
   native circuit frames of the carried circuit, but no alignment with 
   the framing structure of the service is required.  
    
     5.3.3.1 "T1-in-E1" Mode for Unstructured T1 Circuits 
    
   As mentioned above, unstructured T1 represents the only case of a 
   TDM circuit considered in this document with a non-octet aligned 
   native circuit frame. In order to accommodate this type of circuit 
   into the general CESoPSN framework, a special "T1 in E1" payload 
   format (similar to one defined in [G.802]) is used as shown in Fig 5 
   below (M = number of native frames in the CESoPSN packet, D denotes 
   the payload data bits).  
    
    
    
    
    
    
    
    
    
    
    
 
   Vainshtein et al.           Expires   May-2002             [Page 16]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   "Timeslots" |     1         | ... |     24        |      25       | 
               |0 1 2 3 4 5 6 7| ... |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 
   ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
    N  C  F   1|D D D D D D D D| ... |D D D D D D D D|D|  padding    | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    a  i  r   2|D D D D D D D D| ... |D D D D D D D D|D|  padding    | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    t  r  a ...|D D D D D D D D| ... |D D D D D D D D|D|  padding    | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    i  c  m ...|D D D D D D D D| ... |D D D D D D D D|D|  padding    | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    v  u  e ...|D D D D D D D D| ... |D D D D D D D D|D|  padding    | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    e  i  s ...|D D D D D D D D| ... |D D D D D D D D|D|  padding    | 
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       t      M|D D D D D D D D| ... |D D D D D D D D|D|  padding    | 
               +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
    
              Figure 6. The "T1-in-E1" CESoPSN Payload Format 
    
   Note: Each row in the matrix presented in Fig. 6 contains exactly 
   193 payload data bits (and 7 padding bits). However, no alignment of 
   the rows with the T1 framing structure is implied and hence support 
   of this mode does not require a T1 framer in PE. 
    
6. CESoPSN Operation 
    
   Note: This section includes non-normative information and 
   implementation considerations. These elements will be moved to an 
   appropriate Appendix in the next update. 
    
   Edge-to-edge circuit emulation of a TDM circuit using CESoPSN 
   assumes the following elements: 
     o  Two PW end services of the same type and bit rate 
     o  Packetizer at the PW ingress 
     o  Jitter buffer and de-packetizer at the PW egress. 
    
   Setup of a CESoPSN PW assumes exchange of the following information: 
     o  Types of end services. In order to be connected by a CESoPSN 
         PW, these types MUST be the same and define the PW type. PW 
         types supported by CESoPSN MUST be accommodated into the 
         common enumeration of PW types 
     o  Bit rates of end services. In order to be connected, bit rates 
         of the two end services MUST be the same and define the PW bit 
         rate 
     o  Encapsulation layer-specific parameters that define specific 
         instantiation of the protocol 
    
   This document defines how the values of these parameters should be 
   encoded. The actual signaling protocols for exchanging these  
    
   parameters between the PE peers ("PE/PW signaling" in terms of 
   [PWE3-FW]) are out of scope of this document.  
 
   Vainshtein et al.           Expires   May-2002             [Page 17]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
    
   Description of the CESoPSN-based edge-to-edge circuit emulation 
   includes the following elements:  
     o  Definition of the end service inactive state behavior towards 
         the CE 
     o  Description of the IWF operation in CE-bound and PSN-bound 
         direction. 
    
   Details are presented below. 
    
   6.1. Payload Parameters 
     6.1.1. PW Type 
    
   PW types (a.k.a. VC types) have been defined in [MARTINI-TRANS]. PW 
   types used for CESoPSN PW are assigned in such a way as to avoid 
   overlap with types assigned in other PWE3 documents. 
 
   The following PW types are defined in this document for CESoPSN-
   based PWs: 
    
     o  Transparent N*DS0                  - 65  
     o  N*DS0 with CAS                     - 66  
     o  Unstructured E1                    - 67 
     o  Unstructured T1, bit stream mode   - 68 (not defined in this 
         specification) 
     o  Unstructured T1, T1-in-E1 mode     - 69 
     o  Unstructured E3                    - 70 
     o  Unstructured T3                    - 71 
     o  Unstructured SONET/SDH             - 72 (see Annex B). 
    
     6.1.2. Circuit Bit Rate 
    
   The circuit bit rate is encoded as the number of "timeslots" in the 
   matrix structure of the corresponding CESoPSN data packet. 
    
   The following values are used: 
    
     o  Transparent N*DS0                  - N, 1 <= N <= 31 
     o  N*DS0 with CAS                     - N, 1 <= N <= 30 
     o  Unstructured E1                    - 32 
     o  Unstructured T1, T1-in-E1 mode     - 25 
     o  Unstructured E3                    - 537 
     o  Unstructured T3                    - 699 
     o  Unstructured STS-1                 - 810 
     o  Unstructured STM-1                 - 2430 
    
   Note: N*DS0, unstructured E1 and unstructured T1 circuits can be 
   carried over any PSN implementing the minimal MTU as defined in 
   [RFC1122]. Unstructured E3 and T3 can be carried over any PSN 
   providing Path MTU of 1.5 Kbytes. Unstructured STS-1 and STM1 are 
   considered in Annex A. 
    
    
 
   Vainshtein et al.           Expires   May-2002             [Page 18]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
    
   6.2. Encapsulation Layer Parameters 
     6.2.1. Usage of Control Word 
    
   TRUE value (default) of this Boolean parameter means that the 
   CESoPSN control word is used. 
    
   CESoPSN MAY allow negotiation of this parameter, so that the control 
   word will not be used if both sides agree to that. 
 
     6.2.2. RTP Payload Type 
    
        1. One PT value MUST be allocated from the range of 
            dynamically allocated payload types for each CESoPSN PW for 
            use in the data packets: 
           a. The same value MUST be allocated for both directions of 
             the PW 
           b. Ingress PW MUST set the PT in the RTP header of all the 
             data packets to the allocated value 
           c. Egress PW MAY use this value to detect non-data PW 
             packets. These packets can be either relegated to 
             signaling or considered as malformed 
        2. For emulation of a N*DS0 circuit with CAS, an additional PT 
            value MUST be allocated from the range of dynamically 
            allocated payload types for each CESoPSN PW for use in the 
            data packets: 
           a. It MUST be different from the PT value allocated for data 
             packets 
           b. The same value MUST be allocated for both directions of 
             the PW 
           c. Ingress PW MUST set the PT in the RTP header of all the 
             signaling packets to the allocated value 
        3. Egress PW MAY use this value to distinguish signaling PW 
            packets. 
    
   Note: The same PT value may be allocated for multiple PWs. 
    
     6.2.3. Payload Bytes 
    
   This parameter has been defined in [MARTINI-TRANS]. In order to 
   establish a CESoPSN-based PW, the following conditions MUST be met: 
   o    The number of payload bytes MUST be the same for both 
        directions of the PW 
   o    The number of payload bytes MUST be a multiple of the encoded 
        Circuit Bit Rate (see Section 6.1.2 above). E.g., the value of 
        this parameter for an Unstructured E1 circuit (Circuit Bit Rate 
        = 32) with M native circuit frames packet into a single CESoPSN 
        packet will be 32*M, while for an Unstructured T1 it will be 
        25*M 
    
   o    The size of the resulting PW packet (including all the headers) 
        SHOULD NOT exceed the path MTU between the participating PEs as 
        provided by the Carrier layer. 
 
   Vainshtein et al.           Expires   May-2002             [Page 19]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
    
   Note: For N*DS0 with CAS circuits this parameter defines the number 
   of payload bytes in the data packets only. The number of payload 
   bytes in the signaling packets is inferred from the encoded circuit 
   bit rate in the obvious way. 
    
     6.2.4. Timestamp Resolution 
    
   This parameter encodes the rate of the clock used for setting 
   timestamps in RTP headers as a multiple of the basic 8 KHz rate. 
    
     6.2.5. Synchronization Source ID 
    
   The same 32-bit SSRC value MUST be assigned to all the data packets  
   of a given direction of a CESoPSN PW. The CE-bound direction of the 
   IWF MAY be use this value for misconnection detection, especially if 
   such a service is not provided by the PSN and/or multiplexing 
   layer(s). 
    
   If data and signaling packets are multiplexed in the same PW, the 
   signaling packets MUST use a separate SSRC value. This arrangement 
   complies with the RTP specification [RFC 1889] and allows effective 
   compression of the PW headers by the standard compressors. 
    
     6.2.6. Timestamp Generation Mode 
    
   This parameter accepts at least the following two values 
   corresponding to operation modes described in Section 5.2.1: 
    
        o  Absolute  (1) 
        o  Differential (2). 
    
   6.3. End Service Inactivity Behavior 
    
   While the PW is inactive: 
     o  Each unstructured end service MUST send AIS to its prospective 
         CE 
     o  Each structured end service MUST send an appropriate Idle Code 
         to its prospective CE 
    
   6.4. Description of the IWF operation  
    
   Once the PW is set up, the CESoPSN IWF operates like following: 
    
     6.4.1. PSN-bound Direction 
    
     1. End service data is packetized in accordance with the number 
         of payload bytes specified. For N*DS0 services, the  
         packetized data are aligned with the native circuit frames as 
         described in Section 5.3.1 
     2. Sequence numbers and timestamps representing the selected 
         synchronization clock are inserted in the CESoPSN headers 
      
 
   Vainshtein et al.           Expires   May-2002             [Page 20]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     3. CESoPSN, multiplexing and PSN headers are prepended to the 
         packetized circuit data 
     4. Resulting packets are transmitted via the PSN 
     5. If the PE detects any outage of the incoming an unstructured 
         end service that natively would result in sending the 
         "downstream AIS", the CESoPSN IWF using the control word MUST 
         set the local AIS indication flag (bit A) in the control word. 
         The packet payload MAY be omitted in order to save the PSN 
         bandwidth.  
     6. If the PE detects an Idle Code condition of the incoming an 
         unstructured T3 end service, or an AIS-producing condition is 
         detected in the incoming 'carrier service' of an N*DS0 end 
         service, the CESoPSN IWF using the control word MUST set the 
         local Idle Code indication flag (bit I) in the control word. 
         The packet payload MAY be omitted in order to save the PSN 
         bandwidth. 
    
   Local AIS and Idle Code indications in the CESoPSN control word 
   provide for the following functionality: 
     o  Ability to distinguish between the PSN problems and ones 
         beyond the PSN as causes of outages of the emulated service 
     o  Ability to save the PSN bandwidth (but not its switching 
         capacity) by not sending invalid data across the PSN. 
    
   The techniques to save the PSN switching capacity in case of an end 
   service outage are left for further study. 
    
     6.4.2. CE-bound Direction - Normal Operation 
    
     1. The CE-bound IWF includes a jitter buffer that accumulates 
         data from incoming CESoPSN packets with their respective 
         timestamps. The length of this buffer SHOULD be configurable 
         to allow adaptation to various network delay behavior 
         patterns. Size of the jitter buffer is a local parameter of 
         the CESoPSN IWF. Since any CESoPSN data packet carries a fixed 
         number of native data frames of the emulated service, the 
         jitter buffer can be considered as a matrix with "rows" 
         corresponding to native service frames, too. 
     2. Initially the Jitter buffer is filled with the appropriate 
         inactivity (AIS or Idle) code. 
     3. Immediately after start, IWF: 
         a. Begins reception of incoming CESoPSN packets. PSN and 
            multiplexing layer headers are stripped from the received 
            packets, and packetized TDM data from the received packets 
            is stored in the jitter buffer 
         b. Continues to play out its appropriate inactivity code into 
            its end service as long as the jitter buffer has not yet 
            accumulated sufficient amount of data 
         c. Signals the CE-bound direction of the local IWF to transmit 
            CESoPSN packets with the T bit set (if control word is 
            used) 
     4. Once the jitter buffer contains sufficient amount of data 
         (usually half of its capacity), the IWF starts replay of this 
 
   Vainshtein et al.           Expires   May-2002             [Page 21]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
         data in its end service in accordance with its (locally 
         defined) 8 KHz transmission clock, so that a single "row" of 
         the jitter buffer matrix is replayed per "tick" of the clock. 
         At the same moment it signals the PSN-bound direction of IWF 
         to clear the T bit in the CESoPSN packets it transmits (if the 
         control word is used) 
     5. If transmission clock must be recovered from the PW, the 
         timestamps of data packets SHOULD be used for correcting 
         initial transmission clock frequency in accordance with the 
         specified mode of their generation. 
     6. If adaptation of the jitter buffer size is implemented, it 
         SHOULD NOT introduce additional wander of the transmission 
         clock. It MAY introduce additional errors (e.g., in accordance 
         with the techniques described in Section 5.3.1 above) 
     7. The CE-bound direction of the IWF: 
         a. Performs detection, correlation and handling of CESoPSN 
            faults as described in Section 6.5 below  
         b. Collects the PW Performance Monitoring data as defined in 
            Section 6.6 below 
     8. CE application state signals received in the signaling packets 
         SHOULD be synchronized with data using the timestamps and 
         inserted (in an appropriate format) into the CE-bound TDM 
         stream. Signals that cannot be inserted into the CE-bound TDM 
         stream due to the local format limitations MUST BE ignored. 
         Any aspects of translation of values of CE signals are out of 
         scope of this specification. 
    
     6.4.3. IWF Loopback 
    
   An IWF loopback for the CESoPSN IWF MAY be set and cleared by an 
   external (management) command. 
    
   Once such a loopback is set, the IWF will loop packets coming from 
   the PSN back to the PSN. In addition it will mark these packets by 
   setting Z bit in the CESoPSN control word. 
    
   Once the loopback is cleared, the IWF resumes its normal operation. 
    
   6.5. CESoPSN Defects 
     6.5.1. Misconnection 
    
   Some combinations of PSN and multiplexing layers (see Annex A) 
   inherently provide for detection of packets that do not belong to 
   the PW ('stray packets'). 
    
   CESoPSN MAY use the SSRC field in the RTP header for detection of 
   'stray packets' even if such a capability is provided by the 
   specific combination of PSN and multiplexing layers.  
    
   Regardless of the way in which a stray packet has been detected: 
     o  It MUST be discarded by the CE-bound IWF 
     o  A counter of 'stray packets' must be incremented 
 
 
   Vainshtein et al.           Expires   May-2002             [Page 22]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     o  If reception of stray packets persists, the Misconnection 
         alarm should be reported to the management system. 
 
The IWF mechanisms for detection of lost packets (e.g., expected next 
sequence number) MUST NOT be affected by reception of 'stray packets'. 
     6.5.2. Re-Ordering and Loss of Packets 
    
   CESoPSN implementations SHOULD use sequence numbers in the RTP 
   header and expected rate of transmission of data packets for 
   detection of our-of-order delivery and packets' loss. In particular, 
   they MAY maintain the next expected sequence number value that would 
   be: 
     o  Advanced every time a packet belonging to this PW with an 
         equal or greater (mod 65536) sequence number has been received 
         or a timeout defined by the expected packet arrival rate has 
         expired 
     o  Used as the center of a sliding window for packet reordering. 
         The size of this window SHOULD be limited by the size of the 
         jitter buffer. 
    
   Out-of-order packets that cannot be reordered MUST be considered as 
   lost. 
    
   If loss of one or more CESoPSN packets has been detected at the 
   egress of the CESoPSN PW, its jitter buffer MUST be filled with the 
   appropriate amount of the AIS (or Idle - depending on the service 
   type) code to be replayed into the relevant PWES. In addition: 
     o  If the CESoPSN control word is used, the Remote Lost Packets 
         Indication flag (bit L) MUST be set in the next packet to be 
         sent in the opposite direction of the PW 
     o  A counter of lost packets must be incremented 
     o  If the loss-of-packets condition persists, an alarm should be 
         sent to the management system. 
  
     6.5.3. Malformed Packets 
    
   CESoPSN PW detects a malformed packet using the following rules: 
        o  The PT value in its RTP header does not correspond to one 
            of the PT values allocated for this PW 
        o  The actual packet payload size can be unambiguously 
            inferred from the data link, PSN or multiplexing layer of 
            the PW and does not match the payload size defined for the 
            packets of this type in this PW.  
    
   If a malformed in-order packet has been received at the egress of a 
   CESoPSN PW, then: 
    
     o  Its jitter buffer MUST be filled with the appropriate amount 
         of the AIS (or Idle) code replay to be replayed into the 
         relevant PWES 
     o  A counter of malformed packets must be incremented 
     o  If the payload mistype condition persists, an appropriate 
         alarm should be sent to the management system. 
 
   Vainshtein et al.           Expires   May-2002             [Page 23]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
 
     6.5.4. Loss of Synchronization 
    
   The CESoPSN IWF MAY detect two types of loss of synchronization 
   errors: 
    
          6.4.5.1 Jitter Buffer Overrun 
    
   This fault is detected if the jitter buffer at the PW egress cannot 
   accommodate the newly arrived CESoPSN packet in its entirety. 
    
   A CESoPSN packet that cannot be stored in the jitter buffer MUST be 
   discarded.  
    
   If the jitter buffer overrun condition persists, an appropriate 
   alarm should be sent to the management system. In addition, the 
   Remote Loss of Synchronization (bit T) flag SHOULD be set in the 
   next packet to be send in the opposite direction of the service. 
    
          6.5.4.2. Jitter Buffer Underrun 
    
   This fault is detected if the jitter buffer at the PW egress becomes 
   empty before arrival of a new CESoPSN packet while loss of packets 
   has not been detected. CESoPSN implementations MAY never detect the 
   Jitter Buffer Underrun condition if their packets' loss detection 
   mechanisms do not allow it. 
    
   If the jitter buffer underrun condition persists, an appropriate 
   alarm should be sent to the management system. In addition, the 
   Remote Loss of Synchronization (bit T) flag SHOULD be set in the 
   next packet to be send in the opposite direction of the service. 
    
   6.6. Performance Monitoring 
     6.6.1. Errored Data Blocks     
    
   [G.826] defines the concept of an errored data block that serves as 
   the basis of for collection of performance monitoring parameters. It 
   also defines the size of the data block for most TDM circuits. These 
   definitions are aligned with the 'native circuit frame' size of 
   these circuits so that every G.826-compatible data block contains an 
   integer multiple of native circuit frames, e.g.: 
     o  For E1 and T1 circuits, a data block contains 4 native service 
         frames 
     o  For E3 and T3 circuits, a data block contains one native 
         service frame etc. 
    
   The following definitions of error events and errored data blocks 
   for CESoPSN provide for collection of [G.826]-compatible performance 
   monitoring parameters: 
     o  An error event is insertion of a single native service frame 
         of inactivity code into the jitter buffer if it does not stem 
         from receiving a CESoPSN packet with an AIS or Idle Code 
         indication 
 
   Vainshtein et al.           Expires   May-2002             [Page 24]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     o  An errored data block is a data block defined in accordance 
         with [G.826] that has experienced at least one error event. 
    
     6.6.2. Errored, Severely Errored and Unavailable Seconds 
    
   The definition of an errored data block presented above can be used 
   to define Errored Seconds, Severely Errored Seconds and Unavailable 
   Seconds in accordance with [G.826]. 
    
   6.7. QoS Issues 
    
   If the PSN providing connectivity between PE devices is Diffserv-
   enabled and implements EF PHB (see [RFC2598bis]), all the CESoPSN 
   data packets should be marked for EF PHB at ingress. Such an 
   arrangement results in decrease of the packets' inter-arrival jitter 
   and hence in decrease of latency introduced by the TDM circuit 
   emulation. 
    
7. RTP Payload Format Considerations 
    
   In accordance with guidelines specified in [RFC2736], the following 
   issues are addressed by this specification: 
    
   7.1. Resilience to moderate loss of individual packets 
     
   The impact of loss of an individual data packet may be decreased by 
   decreasing the packet size (with the associated loss of efficiency). 
    
   Resilience to loss of an individual signaling packet is provided for 
   by the rules described in Section 5.3.2 above. 
    
   7.2. Ability to interpret every single packet 
    
   This requirement is met since every CESoPSN packet carries a 
   multiple of the native frame of the carried service. 
    
   7.3. Non-usage of the RTP Header Extensions 
    
   This recommendation is met, since RTP-wise, the CESoPSN Control Word 
   is part of the RTP payload. Alignment with this requirement 
   facilitates usage of standard header compression mechanisms if 
   CESoPSN uses UDP/IP as its PSN and multiplexing layers. 
 
   7.4. Compression of RTP headers 
    
   Existing relevant standards ([RFC2508], [RFC3095]) deal with 
   compression of RTP/UDP/IP headers on specific P2P links. Compression 
   techniques defined in these documents are fully applicable for 
   CESoPSN if it uses UDP/IP as PSN and multiplexing layers 
   respectively. Standard compression of CESoPSN/UDP/IP headers will be 
   very effective, since: 
     o  Value of the SSRC field in the CESoPSN header of data packets 
         remains constant for the duration of a CESoPSN session 
 
   Vainshtein et al.           Expires   May-2002             [Page 25]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
     o  Value of the Timestamp field in the CESoPSN header is usually 
         incremented by a fixed value from packet to packet 
     o  CESoPSN control word is NOT defined as RTP header extension. 
 
   As a consequence, a PSN-independent end-to-end compression technique 
   of RTP headers seems not justified. 
    
8. Congestion Control (RFC 2914) Conformance  
    
   CESoPSN PWs carry constant bit rate (CBR) services. These services, 
   by definition, cannot behave in a TCP-friendly manner prescribed by 
   [RFC2914] under congestion while retaining any value for the user. 
    
   Devices implementing CESoPSN and using IP as their PSN layer: 
     o  MUST set the ECN bits of the IP header (see [RFC3168]) to non-
         ECT ('00') value at ingress (to prevent routers in the network 
         from setting them to the CE ('11') value 
     o  SHOULD ignore these bits at egress.  
    
9. FFS Issues 
    
   Note: This section will be removed from the final revision of the 
   document. 
    
   The following issues will be addressed in the next revisions of this 
   document: 
    
     o  Techniques for saving the PSN switching capacity when the PW 
         experiences an end service outage or does not carry any valid 
         data 
     o  Usage of RTCP. One particular application to be considered is 
         retrieval of remote problems' indications without the control 
         word 
     o  Effect of timestamp resolution on quality of clock recovery in 
         Differential mode. 
    
10. Security Considerations 
    
   This document does not affect the underlying security issues of 
   specific PSN.  
   In addition, it defines misconnection detection capabilities of 
   CESoPSN. These capabilities increase resilience of CESoPSN to 
   misconfiguration and some types of DoS attacks. 
    
11. Applicability Statement 
    
   CESoPSN is an encapsulation layer intended for carrying TDM circuits 
   (transparent N*DS0, transparent N*DS0 with CAS, unstructured E1/T1 
   and unstructured E3/T3) over PSN.  
    
   Applicability of CESoPSN MAY be extended to low-rate SONET/SDH 
   circuits with minimal modifications. 
    
 
   Vainshtein et al.           Expires   May-2002             [Page 26]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   CESoPSN allows carrying both data and clock of TDM circuits across 
   multiple types of PSN.  
    
   CESoPSN allows carrying CE signaling that requires synchronization 
   with data (e.g., channel-associated signaling (CAS) for Voice 
   applications) in-band in separate signaling packets. The RTP Payload 
   Type (PT) is used to distinguish between data and signaling packets, 
   while the Timestamp field is used for synchronization. This makes 
   CESoPSN extendable to support different types of CE signaling 
   without affecting the data path in the PE devices. 
    
   CESoPSN does not presume availability of a global synchronous clock 
   at the ends of a PW. This makes it suitable for Asynchronous 
   Carriers' Carrier applications. 
    
   CESoPSN uses RTP for carrying the clock across the PSN. The 
   additional CESoPSN header (if used) is a payload format header and 
   hence standard header compression techniques for RTP/UDP/IP profile 
   over links slow and/or error-prone links are fully applicable to 
   CESoPSN PWs. 
    
   CESoPSN allows the PSN bandwidth conservation by carrying only AIS 
   and/or Idle Code indications instead of data.  
    
   Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP-
   friendly behavior under network congestion. 
    
   CESoPSN allows collection of TDM-like faults and performance 
   monitoring parameters hence emulating 'classic' carrier services of 
   TDM circuits (e.g., SONET/SDH). Similarity with these services is 
   increased by the CESoPSN ability to carry 'far end error' 
   indications. 
    
   CESoPSN provides for a carrier-independent ability to detect 
   misconnections and malformed packets. This feature increases 
   resilience of the emulated service to misconfiguration and DoS 
   attacks. 
    
   CESoPSN provides for detection of lost packets and hence allows to 
   distinguish between the PSN problems and ones beyond the PSN as 
   causes of outages of the emulated service. 
    
   Faithfulness of a CESoPSN PW may be increased if the carrying PSN is 
   Diffserv-enabled and implements EF PHB. 
     
   CESoPSN does not provide any mechanisms for protection against PSN 
   outages. As a consequence, resilience of the emulated service to 
   such outages is defined by the PSN behavior. On the other hand, the 
   jitter buffer and packets' reordering mechanisms associated with 
   CESoPSN increase resilience of the emulated service to fast PSN 
   rerouting events. 
    
    
 
   Vainshtein et al.           Expires   May-2002             [Page 27]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
12. IANA Considerations 
    
   This specification requires assignment of new PW Types for CESoPSN 
   PWs as described in Section 6.1. 
    
13. Intellectual Property Considerations 
    
   This document is being submitted for use in IETF standards 
   discussions.  Axerra Networks, Inc. has filed one or more patent    
   applications relating to the CESoPSN technology outlined in this 
   document. Where there is a necessary dependence upon such patents 
   and patent applications in implementing an IETF adopted standard 
   resulting from this document, Axerra Networks will license on fair, 
   reasonable, and non-discriminatory terms to all parties, any patent 
   claims it owns covering such technology, solely to the extent such 
   technology is essential to comply with such standard.  Any such 
   license to a party shall start on the date that Axerra Networks and 
   the party enter into an agreement related thereto and shall be 
   granted on the condition that any such party grants to Axerra 
   Networks and its corporate affiliates a reciprocal license under 
   such party's patents for which there is also a necessary dependence. 
    
ACKNOWLEDGEMENTS 
    
   We express deep gratitude to Stephen Casner who reviewed this 
   document in detail, corrected some serious errors  and provided many 
   valuable inputs. Some of his inputs will be explored in the next 
   revisions of the draft. 
    
   We thank Sim Narasimha and Yaron Raz for valuable feedbacks. 
    
   We thank Alik Shimelmits for many fruitful discussions. 
    
REFERENCES 
    
   [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation 
   Edge-to-Edge (PWE3), Work in Progress, July-2001, draft-ietf-pwe3-
   requirements-01.txt 
    
   [PWE3-FW] Prayson Pate et al, Framework for Pseudo Wire Emulation 
   Edge-to-Edge (PWE3), Work in progress, February 2002, draft-ietf-
   pwe3-framework-00.txt 
    
   [PWE3-LAYERS], Stewart Bryant et al., Protocol Layering in PWE3, 
   Work in Progress, February 2002, pwe3-protocol-layering-01.txt 
   [MALIS] Andrew G. Malis et al, SONET/SDH Circuit Emulation Service 
   Over MPLS (CEM) Encapsulation, Work in progress, April 2001, draft-
   malis-sonet-ces-mpls-04.txt  
    
   [PWE3-SONET] Andrew G. Malis et al, SONET/SDH Circuit Emulation over 
   Packet (CEP), Work in progress, September 2001, draft-malis-pwe3-
   sonet-00.txt 
    
 
   Vainshtein et al.           Expires   May-2002             [Page 28]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   [KOMPELLA] MPLS-based Layer 2 VPNs, Work in Progress, July 2001, 
   draft-kompella-ppvpn-l2vpn-00.txt 
    
   [MARTINI-TRANS] Luca Martini et al, Transport of Layer 2 Frames Over 
   MPLS, Work in progress, November 2001, draft-martini-l2circuit-
   trans-mpls-08.txt  
    
   [MARTINI-ENCAP] Luca Martini et al, Encapsulation Methods for 
   Transport of Layer 2 Frames Over MPLS, Work in progress, November 
   2001, draft-martini-l2circuit-encap-mpls-04.txt  
    
   [L2TPv3] J.Lau et al, Layer Two Tunneling Protocol "L2TP", Work in 
   progress, October 2001, draft-ietf-l2tpext-l2tp-base-01.txt 
    
   [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- 
   Communication Layers, RFC 1122, IETF, 1989  
    
   [RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-
   Time Applications, RFC 1889, IETF, 1996 
    
   [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement 
   Levels, RFC 2119, IETF, 1997 
    
   [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA 
   Considerations Section in RFCs, RFC 2434, IETF, 1998 
    
   [RFC2474] K. Nichols et al., Definition of the Differentiated 
   Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, 
   IETF, 1998 
    
   [RFC 2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for 
   Low-Speed Serial Links, RFC 2508, IETF, 1999 
    
   [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP 
   Payload Format Specifications, RFC 2736, IETF, 1999 
    
   [RFC2598bis] Bruce Davie (ed.), An Expedited Forwarding PHB, Work in 
   Progress, April 2001, draft-ietf-diffserv-rfc2598bis-01.txt 
    
   [RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, 
   Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000 
    
   [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 
   2000 
    
   [RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC): 
   Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC 
   3095, IETF, 2001 
    
   [RFC3140] D. Black et al, Per Hop Behavior Identification Codes, RFC 
   3140, IETF, June 2001 
    
    
 
   Vainshtein et al.           Expires   May-2002             [Page 29]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of 
   Explicit Congestion Notification (ECN) to IP, RFC 3168, IETF, 2001 
     
    
   [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp-
   parameters 
    
   [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.707] ITU-T Recommendation G.707 (10/00) - Network Node Interface 
   for 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.802] ITU-T Recommendation G.802 (11/88) - Interworking between 
   networks based on different digital hierarchies and speech encoding 
   laws 
    
   [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 
    
   [T1.103] ANSI T1.103 - 1987. Digital Hierarchy - Synchronous DS3 
   Format Specification 
    
   [T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface 
   Rates and Format Specifications (SONET} 
    
   [T1.107] ANSI T1.107 - 1988. Digital Hierarchy - Format 
   Specification 
    
   [T1.107a] ANSI T1.107a - 1990. Digital Hierarchy - Supplement to 
   Format Specifications (DS3 Format Specifications) 
    
   [NANOG] St. Casner, C. Alaettinoglu, Ch. Kuan, A fine-grained view 
   of high-performance networking, NANOG-22, May 2001 
    
    
AUTHORS' ADDRESSES 
    
   Alexander ("Sasha") Vainshtein 
    
   Axerra Networks 
    
   24 Raoul Wallenberg St. 
    
   Tel Aviv 69719, Israel 
   email: sasha@axerra.com 
 
   Vainshtein et al.           Expires   May-2002             [Page 30]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
    
    
   Israel Sasson  
    
   Axerra Networks 
    
   24 Raoul Wallenberg St. 
    
   Tel Aviv 69719, Israel 
    
   email: israel@axerra.com 
    
    
   Akiva Sadovski  
    
   Axerra Networks 
    
   24 Raoul Wallenberg St. 
    
   Tel Aviv 69719, Israel 
    
   email: akiva@axerra.com 
    
    
   Eduard Metz 
    
   KPNQwest 
   Scorpius 60 
   2130 GE Hoofddorp, The Netherlands 
   email: eduard.metz@kpnqwest.com 
    
   Tim Frost 
    
   Zarlink Semiconductor 
    
   Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK 
    
   email: tim.frost@zarlink.com 
    
FULL COPYRIGHT STATEMENT 
    
   Copyright (C) The Internet Society (2001). All Rights Reserved. This    
   document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other    
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
 
   Vainshtein et al.           Expires   May-2002             [Page 31]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   followed, or as required to translate it into languages other than  
   English.  
   The limited permissions granted above are perpetual and will not be    
   revoked by the Internet Society or its successors or assigns.  
   This document and the information contained herein is provided on an  
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET  ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING  
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF  
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
    
ACKNOWLEDGEMENT  
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society.  
    
ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN 
 
   A1. IP PSN 
    
   CESoPSN is RTP-based, and UDP flows are a natural way to convey RTP 
   traffic (see [RFC1889]).  
   If this technique is used for conveying CESoPSN, then: 
     o  Unused even UDP ports must be allocated at both PE nodes 
         terminating a CESoPSN PW as part of the PW establishment 
         process 
     o  IP and UDP headers must be prepended to each CESoPSN packet 
     o  These packets will be transmitted by each PE node to its peer 
         using the standard IP routing mechanisms. 
    
   UDP flows represent a multiplexing layer with limited ability to 
   detect misconnections. As a consequence, SSRC-based misconnection 
   detection by CESoPSN MAY be disabled. 
    
   IP represents a Carrier layer with inherent ability to infer the 
   payload size from the header. As a consequence, detection of 
   malformed packets SHOULD take the actual payload size into 
   consideration. 
    
   By default, manual signaling can be used for setup and teardown of 
   CESoPSN PWs over UDP flows. As a consequence, parameters defined in 
   Section 6 should be incorporated into to the appropriate service-
   specific MIB module. 
    
   [RFC1889] defines a convention for associating an RTCP session with 
   each RTP/UDP/IP one. Possible usage of RTCP for CESoPSN is left for 
   further study. 
    
   A2. MPLS PSN 
    
   Note: The text below does not define a generic RTP/MPLS stack. Such 
   a work is clearly out of scope of this document. 
    
 
   Vainshtein et al.           Expires   May-2002             [Page 32]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   This section is concerned with the case of MPLS being used as both 
   the PSN and multiplexing layer for the CESoPSN PW.  
    
   In this case, CESoPSN packet MUST be prepended with an MPLS label 
   stack including: 
     o  A VC label entry (see [MARTINI-TRANS] or [KOMPELLA]). This 
         entry acts as the multiplexing layer header. It MUST be 
         present in the stack and MUST be marked as residing at the 
         bottom of the stack 
     o  A tunnel label entry. This label, if present, acts as the PSN 
         header and must immediately precede the VC label entry. It MAY 
         be omitted in some situations. 
    
   This combination of PSN and multiplexing layers does not provide 
   either frame length information or ability to detect misconnections. 
   The former is not necessary for CESoPSN but limits ability to detect 
   malformed packets in case of a very short packet payload. The 
   misconnection detection functionality can be provided using the 
   following considerations: 
     1. The pattern in the first four bits following the bottom label 
         ('1000') can be used as indication of an RTP header as it is 
         distinct from any of the following: 
         a. IPv4 pattern ('0100') 
         b. IPv6 pattern ('0110') 
         c. Pattern produced by Layer 2 services over MPLS encapsulated 
            in accordance with [MARTINI-ENCAP] and using control word 
            ('0000') 
     2. The SSRC field of the RTP header can be further used to detect 
         misconnection. 
    
   MPLS tunnels are conventionally established using various signaling 
   protocols. As a consequence, parameters used for setup and teardown 
   of CESoPSN tunnels should be mapped to data elements of these 
   protocols. 
    
   A3. L2TP PSN 
    
   Note: The text below does not define a generic RTP/L2TPv3 stack. 
   Such a work is clearly out of scope of this document. 
    
   CESoPSN packets may be carried in L2TPv3 tunnels over IP (see 
   [L2TPv3]) that would act as an alternative multiplexing layer over 
   IP. 
    
   Since L2TPv3 provides both data and control plane for tunnel 
   establishment, parameters describing payload and encapsulation 
   layers should be defined as AVPs to allow single-ended setup and 
   teardown of CESoPSN PWs.  
    
   L2TPv3 tunnels represent a multiplexing layer with an optional 
   ability to detect misconnections using 32-bit or 64-bit "cookies". 
   As a consequence, the PSN operator may choose between the L2TPv3-
 

   Vainshtein et al.           Expires   May-2002             [Page 33]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
   based and SSRC-based misconnection detection techniques for CESoPSN 
   PWs. 
    
   IP represents a PSN layer with inherent ability to infer the payload 
   size from the header. As a consequence, malformed packets detection 
   should consider actual payload size. 
    
ANNEX B. EMULATION OF SONET/SDH CIRCUITS 
 
   B1. Relevant Types of SONET/SDH circuits 
    
     o  STS-1 
     o  STM-1 
    
   B2. Native Frame Size and Payload Format 
    
   Natural delineation of SONET/SDH frames (of abovementioned rates) 
   will produce packets exceeding minimal MTU in some cases. As a 
   consequence, a SONET/SDH frame must be fragmented into several 
   CESoPSN packets will be used. 
    
   Usage of CESoPSN for unstructured SONET/SDH circuits requires 
   presence of an appropriate framer in the ingress and egress PEs. 
    
   Each SONET/SDH frame will be fragmented into the Protocol Data Units 
   (PDUs) of equal size. Data belonging to two and more different 
   frames MUST NOT be combined into one PDU. For each SONET/SDH frame  
    
   only one CESoPSN packet will contain the framing octets (A1, A2) of 
   this frame. Such a packet: 
    
      o    MUST contain these bytes aligned with its payload data 
           (i.e., the 1st octet of the payload MUST contain the 1st A1 
           byte of a SONET/SDH frame  
      o    SHOULD be marked with M bit set to 1 in the RTP header. 
    
   B3. Synchronization modes 
    
   External clock sources traceable (in terms of G.781) to the same 
   high quality (at least as defined in G.812) clock source should be 
   available at both PEs for External or Differential timing. 
    
   B.3. Structure of the Control Word 
    
   The same bits as defined in Section 5.2.2 are used. However the 
   meaning of the bits are slightly different: 
    
     o  Bit A - if set, represents LOS (e.g., as specified in [G.783]) 
         of the incoming SONET/SDH signal. A packet with the A bit set 
         should not carry any data  
     o  Bit I - if set, represents an Out-of-Frame (OOF) condition 
         (e.g., as specified in [G.707]) of the incoming SONET/SDH 
         signal. A packet with the I bit set should not carry any data  
 
   Vainshtein et al.           Expires   May-2002             [Page 34]
 
   TDM Circuit Emulation Service over PSN                  August 2002 
          
      
   B4. Packetization and de-packetization 
    
   During normal operation, the CESoPSN packetizer will receive a fixed    
   rate byte stream from a (physical or logical) SONET/SDH interface. 
   When the whole SONET/SDH frame will be received, it will be 
   partitioned into several blocks of equal size. After that, PSN and 
   multiplexing headers are prepended to it and the resulting CESoPSN 
   packets are transmitted into the PSN.   
   Because all normal CESoPSN packets associated with a specific 
   SONET/SDH channel will have the same length, the transmission of 
   CESoPSN packets for that channel SHOULD occur at regular intervals.    
   At the far end of the packet network, the CESoPSN de-packetizer will    
   receive packets into a jitter buffer, rebuild native SONET/SDH 
   frames, and then play out the received byte stream at a fixed rate 
   onto the corresponding PDH channel. The jitter buffer SHOULD be 
   configurable to account for various network delay behavior patterns.  
   The received packet rate from the packet network should be exactly 
   balanced by the transmission rate onto the SONET/SDH channel, on 
   average.  The time over which this average is taken corresponds to 
   the depth of the jitter buffer for a specific CESoPSN channel.  
   The RTP sequence numbers in the CESoPSN heard provide a mechanism to 
   detect lost and/or reordered packets.  The CESoPSN de-packetizer 
   MUST detect lost or reordered packets.  
    
    
    
   B6. PSN to SONET/SDH Signals 
    
   Only CESoPSN defects requiring non-standard treatment are 
   considered. 
    
   The CESoPSN de-packetizer MAY re-order packets received out of 
   order.  If the CESoPSN de-packetizer does not support re-ordering, 
   it MUST drop out-of-order packets. 
    
   If any of the PDUs comprising a native SONET/SDH frame is lost, the 
   scrambled pattern consisting of valid framing bytes ([G.707], 
   [T1.105]) and all other bytes set to all 1s will be played out. The 
   same pattern will be played out if a malformed packet has been 
   detected. 
    
   The rationale for this behavior: an SDH node at the egress of a 
   CESoPSN service may continue using the SDH signal received from the 
   egress PE node as its clock source. 
    
    
    
    
    
    
    
 
 
   Vainshtein et al.           Expires   May-2002             [Page 35]