Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
RFC 4197

Riegel                       Informational                     [Page 15]
RFC 4197                 PWE3 TDM Requirements              October 2005

   Note: Length service MAY be provided by the encapsulation layer, but
   is not required.

6.3.  General Design Issues

   The combination of payload and encapsulation layers SHOULD comply
   with the general design principles of the Internet protocols as
   presented in Section 3 of [RFC1958] and [RFC3985].

   If necessary, the payload layer MAY use some forms of adaptation of
   the native TDM payload in order to achieve specific, well-documented
   design objectives.  In these cases, standard adaptation techniques
   SHOULD be used.

7.  Service-Specific Requirements

7.1.  Connectivity

   1.  The emulation MUST support the transport of signals between
       Attachment Circuits (ACs) of the same type (see Section 5) and,
       wherever appropriate, bit-rate.

   2.  The encapsulation layer SHOULD remain unaffected by specific
       characteristics of connection between the ACs and PE devices at
       the two ends of the PW.

7.2.  Network Synchronization

   1.  The encapsulation layer MUST provide synchronization services
       that are sufficient to:

       A.  match the ingress and egress end service clocks regardless of
           the specific network synchronization scenario, and

       B.  keep the jitter and wander of the egress service clock within
           the service-specific limits defined by the appropriate
           normative references.

   2.  If the same high-quality synchronization source is available to
       all the PE devices in the given domain, the encapsulation layer
       SHOULD be able to make use of it (e.g., for better reconstruction
       of the native service clock).

7.3.  Robustness

   The robustness of the emulated service depends not only upon the
   edge-to-edge emulation protocol, but also upon proper implementation
   of the following procedures.

Riegel                       Informational                     [Page 16]
RFC 4197                 PWE3 TDM Requirements              October 2005

7.3.1.  Packet loss

   Edge-to-edge emulation of TDM circuits MAY assume very low
   probability of packet loss between ingress and egress PE.  In
   particular, no retransmission mechanisms are required.

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

   1.  Enable independent interpretation of TDM data in each packet by
       the egress PE (see [RFC2736]).  This requirement MAY be
       disregarded if the egress PE needs to interpret structures that
       exceed the path MTU between the ingress and egress PEs.

   2.  Allow reliable detection of lost packets (see next section).  In
       particular, it SHOULD allow estimation of the arrival time of the
       next packet and detection of lost packets based on this estimate.

   3.  Minimize possible effect of lost packets on recovery of the
       circuit clock by the egress PE.

   4.  Increase the resilience of the CE TDM interface to packet loss by
       allowing the egress PE to substitute appropriate data.

7.3.2.  Out-of-order delivery

   The encapsulation layer MUST provide the necessary mechanisms to
   guarantee ordered delivery of packets carrying the TDM data over the
   PSN.  Packets that have arrived out-of-order:

   1.  MUST be detected, and

   2.  SHOULD be reordered if not judged to be too late or too early for
       playout.

   Out-of-order packets that cannot be reordered MUST be treated as
   lost.

7.4.  CE Signaling

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

   Some CE applications using structured TDM circuits (e.g., telephony)
   require specific signaling that conveys the changes of state of these
   applications relative to the TDM data.

Riegel                       Informational                     [Page 17]
RFC 4197                 PWE3 TDM Requirements              October 2005

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

   1.  Ability to support different signaling schemes with minimal
       impact on encapsulation of TDM data,

   2.  Multiplexing of application-specific CE signals and data of the
       emulated service in the same PW,

   3.  Synchronization (within the application-specific tolerance
       limits) between CE signals and data at the PW egress,

   4.  Probabilistic recovery against possible, occasional loss of
       packets in the PSN, and

   5.  Deterministic recovery of the CE application state after PW setup
       and network outages.

   CE signaling that is used for maintenance purposes (loopback
   commands, performance monitoring data retrieval, etc.) SHOULD use the
   generic PWE3 maintenance protocol.

7.5.  PSN Bandwidth Utilization

   1.  The encapsulation layer SHOULD allow for an effective trade-off
       between the following requirements:

       A.  Effective PSN bandwidth utilization.  Assuming that the size
           of the encapsulation layer header does not depend on the size
           of its payload, an increase in the packet payload size
           results in increased efficiency.

       B.  Low edge-to-edge latency.  Low end-to-end latency is the
           common requirement for Voice applications over TDM services.
           Packetization latency is one of the components comprising
           edge-to-edge latency, and it decreases with the packet
           payload size.

       The compensation buffer used by the CE-bound IWF increases
       latency to the emulated circuit.  Additional delays introduced by
       this buffer SHOULD NOT exceed the packet delay variation observed
       in the PSN.

   2.  The encapsulation layer MAY provide for saving PSN bandwidth by
       not sending corrupted TDM data across the PSN.

Riegel                       Informational                     [Page 18]
RFC 4197                 PWE3 TDM Requirements              October 2005

   3.  The encapsulation layer MAY provide the ability to save the PSN
       bandwidth for the structure-aware case by not sending channels
       that are permanently inactive.

   4.  The encapsulation layer MAY enable the dynamic suppression of
       temporarily unused channels from transmission for the structure-
       aware case.

       If used, dynamic suppression of temporarily unused channels
       MUST NOT violate the integrity of the structures delivered over
       the PW.

   5.  For NxDS0, the encapsulation layer MUST provide the ability to
       keep the edge-to-edge delay independent of the service rate.

7.6.  Packet Delay Variation

   The encapsulation layer SHOULD provide for the ability to compensate
   for packet delay variation, while maintaining jitter and wander of
   the egress end service clock with tolerances specified in the
   normative references.

   The encapsulation layer MAY provide for run-time adaptation of delay
   introduced by the jitter buffer if the packet delay variation varies
   with time.  Such an adaptation MAY introduce a low level of errors
   (within the limits tolerated by the application) but SHOULD NOT
   introduce additional wander of the egress end service clock.

7.7.  Compatibility with the Existing PSN Infrastructure

   The combination of encapsulation and PSN tunnel layers used for edge-
   to-edge emulation of TDM circuits SHOULD be compatible with existing
   PSN infrastructures.  In particular, compatibility with the
   mechanisms of header compression over links where capacity is at a
   premium SHOULD be provided.

7.8.  Congestion Control

   TDM circuits run at a constant rate, and hence offer constant traffic
   loads to the PSN.  The rate varying mechanism that TCP uses to match
   the demand to the network congestion state is, therefore, not
   applicable.

   The ability to shut down a TDM PW when congestion has been detected
   MUST be provided.

Riegel                       Informational                     [Page 19]
RFC 4197                 PWE3 TDM Requirements              October 2005

   Precautions should be taken to avoid situations wherein multiple TDM
   PWs are simultaneously shut down or re-established, because this
   leads to PSN instability.

   Further congestion considerations are discussed in chapter 6.5 of
   [RFC3985].

7.9.  Fault Detection and Handling

   The encapsulation layer for edge-to-edge emulation of TDM services
   SHOULD, separately or in conjunction with the lower layers of the
   PWE3 stack, provide for detection, handling, and reporting of the
   following defects:

   1.  Misconnection, or Stray Packets.  The importance of this
       requirement stems from customer expectation due to reliable
       misconnection detection in SONET/SDH networks.

   2.  Packet Loss.  Packet loss detection is required to maintain clock
       integrity, as discussed in Section 7.3.1 above.  In addition,
       packet loss detection mechanisms SHOULD provide for localization
       of the outage in the end-to-end emulated service.

   3.  Malformed packets.

7.10.  Performance Monitoring

   The encapsulation layer for edge-to-edge emulation of TDM services
   SHOULD provide for collection of performance monitoring (PM) data
   that is compatible with the parameters defined for 'classic',
   TDM-based carriers of these services.  The applicability of [G.826]
   is left for further study.

8.  Security Considerations

   The security considerations in [RFC3916] are fully applicable to the
   emulation of TDM services.  In addition, TDM services are sensitive
   to packet delay variation [Section 7.6], and need to be protected
   from this method of attack.

9.  References

9.1.  Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

Riegel                       Informational                     [Page 20]
RFC 4197                 PWE3 TDM Requirements              October 2005

9.2.  Informative References

   [RFC3916]    Xiao, X., McPherson, D., and P. Pate, "Requirements for
                Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
                September 2004.

   [RFC3985]    Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
                Edge (PWE3) Architecture", RFC 3985, March 2005.

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

   [G.704]      ITU-T Recommendation G.704 (10/98) - Synchronous frame
                structures used at 1544, 6312, 2048, 8448 and 44 736
                Kbit/s hierarchical levels

   [G.706]      ITU-T Recommendation G.706 (04/91) - Frame alignment and
                cyclic redundancy check (CRC) procedures relating to
                basic frame structures defined in Recommendation G.704

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

   [G.751]      ITU-T Recommendation G.751 (11/88) - Digital multiplex
                equipments operating at the third order bit rate of 34
                368 Kbit/s and the fourth order bit rate of 139 264
                Kbit/s and using positive justification

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

   [G.826]      ITU-T Recommendation G.826 (02/99) - Error performance
                parameters and objectives for international, constant
                bit rate digital paths at or above the primary rate

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

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

   [RFC1958]    Carpenter, B., "Architectural Principles of the
                Internet", RFC 1958, June 1996.

   [RFC2736]    Handley, M. and C. Perkins, "Guidelines for Writers of
                RTP Payload Format Specifications", BCP 36, RFC 2736,
                December 1999.

Riegel                       Informational                     [Page 21]
RFC 4197                 PWE3 TDM Requirements              October 2005

   [RFC3393]    Demichelis, C. and P. Chimento, "IP Packet Delay
                Variation Metric for IP Performance Metrics (IPPM)", RFC
                3393, November 2002.

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

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

   [TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and
                Objectives, Bellcore, TR-NWT-170, January 1993

10.  Contributors Section

   The following have contributed to this document:

   Sasha Vainshtein
   Axerra Networks

   EMail: sasha@axerra.com

   Yaakov Stein
   RAD Data Communication

   EMail: yaakov_s@rad.com

   Prayson Pate
   Overture Networks, Inc.

   EMail: prayson.pate@overturenetworks.com

   Ron Cohen
   Lycium Networks

   EMail: ronc@lyciumnetworks.com

   Tim Frost
   Zarlink Semiconductor

   EMail: tim.frost@zarlink.com

Riegel                       Informational                     [Page 22]
RFC 4197                 PWE3 TDM Requirements              October 2005

Author's Address

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

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

Riegel                       Informational                     [Page 23]
RFC 4197                 PWE3 TDM Requirements              October 2005

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

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

Riegel                       Informational                     [Page 24]