PWE3 Working Group T. Frost û Editor INTERNET-DRAFT S. Rodrigues Zarlink Semiconductor Expires: January 2006 July 2005 Requirements for Pseudo Wires carrying Timing and Synchronization draft-frost-pwe3-timing-pw-reqs-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the requirements for the transmission of network timing and synchronization across packet-switched networks using pseudo-wires. Such services enable the function of real-time, synchronous applications across the asynchronous packet switched network. In particular, it complements the emulation of TDM bit streams over the packet switched network. Frost et al. Informational Page 1 Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 Table of Contents 1. Introduction......................................................2 2. Terminology and Reference Models..................................2 2.1. Terminology....................................................2 2.2. Reference Model................................................3 3. Applications......................................................3 3.1. Use in conjunction with TDM emulation..........................3 4. Requirements......................................................6 4.1. Performance Requirements.......................................6 4.2. Connectivity and Compatibility Requirements....................6 4.3. Robustness requirements........................................7 4.3.1. Packet loss................................................7 4.3.2. Out-of-order delivery......................................7 4.3.3. Absolute delay.............................................7 4.3.4. Delay Variation............................................7 4.3.5. Congestion Control.........................................8 4.3.6. Connection Defects.........................................8 4.4. Redundancy requirements........................................8 4.4.1. Redundancy and Failover....................................8 4.4.2. Synchronization quality indication.........................9 5. Security Considerations...........................................9 6. References.......................................................10 1. Introduction The PWE3 Working Group has produced several drafts related to the edge- to-edge emulation of TDM circuits, e.g. [PWE3-SAToP], [PWE3-CESoPSN] and [PWE3-TDMoIP]. These drafts all rely on the presence of accurate timing at both edges of the network. This timing may be recovered by some means from the received packet stream, or distributed by some external means. This document describes the requirements on distribution of accurate network timing and synchronization over the packet network using pseudo-wires, rather than using the conventional TDM synchronization network. It builds on the general requirements for pseudo-wire emulation described in [RFC3916], and the architecture described in [RFC3985]. 2. Terminology and Reference Models 2.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 [RFC3985], Section 1.4 are consistently used without additional explanations. Frost et al. Expires January 2006 [Page 2] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 2.2. Reference Model The network reference model in Figure 2 of [RFC3985] applies to customer applications requiring timing, where: - CE1 is a master clock source of some type - The attachment circuit is a physical means of distributing the clock (for example, it could be a TDM circuit) - CE2 is customer equipment requiring synchronization There may be NSP units at both PE units to transform the clock, for example the use of phase-locked loops (PLLs) to generate related clock frequencies. Some applications may require a bi-directional link, e.g. the provision of a "time of day" reference. Other applications only require the provision of a uni-directional link, e.g. those requiring frequency and phase information. 3. Applications There are two basic classes of applications that require timing and synchronization services: - Real time services, e.g. synchronization of IP PBXs or VoIP gateways, IP video services - Use in conjunction with TDM emulation, to improve the quality of timing available over TDM emulation services 3.1. Use in conjunction with TDM emulation The following figures show how the use of a timing pseudo-wire can be used in conjunction with the various synchronization scenarios for TDM emulation described in [PWE3-TDMREQS], section 4.3. The clock notation relates to the network synchronization reference model shown in Figure 1 of [PWE3-TDMREQ]. o PE Synchronized Network The common network reference clock "I" is available to both PE devices, via transmission over pseudo-wire PW3. PE Local oscillators "C" and "D" are locked to "I". CE1 and CE2 use loop timing (i.e. time the output AC from the input). Frost et al. Expires January 2006 [Page 3] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 |<------- Pseudo-wires ------->| | | | |<-- PSN Tunnel -->| | V V V V AC +-----+ +-----+ AC +-----+ | | |==================| | | +-----+ | /-- |<---------|.............PW1..............|<---------| <-\ | || CE1| | | PE1 | | PE2 | | |CE2 || | \-> |--------->|.............PW2..............|--------->| --/ | +-----+ | | | | | | +-----+ +->|.............PW3..............|--+ | | |==================| | | | +-----+ +-----+ | | ^ ^ | | |C |D | +-----+ +-----+ | +-+ |I| +-+ Figure 1: Relationship to the PE Synchronized Scenario o CE Synchronized Network The common network reference clock "L" is available to both CE devices, via transmission over pseudo-wire PW3. CE Local oscillators "A" and "G" are locked to "L". PE1 and PE2 use loop timing (i.e. time the output AC from the input). |<------- Pseudo-wires ------->| | | | |<-- PSN Tunnel -->| | V V V V AC +-----+ +-----+ AC +-----+ | | |==================| | | +-----+ | |<---------|.............PW1..............|<---------| | | CE1 | | | PE1 | | PE2 | | | CE2 | | |--------->|.............PW2..............|--------->| | +-----+ | | | | | | +-----+ ^ | | | | ^ |A | | | | G| +------------>|.............PW3..............|-------------- | | |==================| | +-+ +-----+ +-----+ |L| +-+ Figure 2: Relationship to the CE Synchronized Scenario Frost et al. Expires January 2006 [Page 4] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 o Relative Network Scenario The common network reference clock "I" is available to both PE devices, via transmission over pseudo-wire PW3. Clocks "A" and "G" are generated locally without reference to a common clock. Timing information (the difference between the common reference clock "I" and the incoming clock "A" or "G") is explicitly transferred from the ingress PE to the egress PE. Clocks "E" and "J" (the TDM output clocks at the egress PE û see Fig. 1 of [PWE3-TDMREQ]) are generated in reference to the common clock "I" using the timing information received from the ingress PE. In a slight modification of this scenario, one (but not both) of the CE devices may use its receive clock as its transmission clock (i.e. use loop timing). |<------- Pseudo-wires ------->| | | | |<-- PSN Tunnel -->| | V V V V |G AC +-----+ +-----+ AC V +-----+ | | |==================| | | +-----+ | |<---------|.............PW1..............|<---------| | | CE1 | | | PE1 | | PE2 | | | CE2 | | |--------->|.............PW2..............|--------->| | +-----+ | | | | | | +-----+ ^ +->|.............PW3..............|--+ |A | | |==================| | | | +-----+<-+ +->+-----+ | | | | | | | | | +-----------+ +-----------+ | +-+ |I| +-+ Figure 3: Relationship to the Relative Network Scenario o Adaptive Network Scenario The adaptive network scenario does not require the presence of a common clock at either CE or PE devices. Therefore it does not require the use of a timing pseudo-wire. Frost et al. Expires January 2006 [Page 5] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 4. Requirements The requirements on Timing and Synchronization pseudo-wires may be divided into the following groups: - Performance requirements - Connectivity and Compatibility Requirements - Robustness requirements - Redundancy requirements - Security requirements 4.1. Performance Requirements In general, performance requirements are dependent on the application. Some applications will have much stricter requirements on the quality of the clock than others. Therefore this document will not attempt to define performance requirements, but leave this to the relevant documents describing the various applications. For example, Study Group 15, Question 13 of ITU is working on a recommendation called [G.pactiming] that analyses synchronization aspects for the transmission of TDM circuits over a packet network. This document will set out the requirements for the synchronization function of network elements where it is intended to connect such services into the TDM network. The first version of [G.pactiming] is planned to be consented in February 2006. 4.2. Connectivity and Compatibility Requirements The emulation MUST support the transfer of timing between Attachment Circuits (ACs) carrying clock signals of the same rate. Phase-locked loops (PLLs) MAY be used as NSP (Native Service Processing) devices to transform the clock rate at either ingress and/or egress PEs. The encapsulation layer SHOULD remain unaffected by specific characteristics of connection between the ACs and PE devices at the two ends of the PW. The combination of encapsulation and PSN tunnel layers used for edge- to-edge emulation of timing and synchronization MUST 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. Frost et al. Expires January 2006 [Page 6] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 4.3. Robustness requirements The robustness of the clock recovery mechanism depends upon the proper handling of the following packet network effects: - Packet loss - Out-of-order delivery - Absolute delay - Packet delay variation (PDV) - Congestion events - Connection defects 4.3.1. Packet loss The encapsulation layer MUST allow reliable detection of lost packets, and SHOULD minimize the possible effect of lost packets on recovery of the clock by the egress PE without requiring retransmission of the original packet. 4.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 MUST be detected, and MUST be either reordered, or discarded and treated as lost. 4.3.3. Absolute delay The recovery of the clock MUST provide the ability to compensate for absolute delay while maintaining jitter and wander of the egress end service clock within tolerances specified in the normative references for the application. 4.3.4. Delay Variation The recovery of the clock MUST provide for ability to compensate for packet delay variation while maintaining jitter and wander of the egress end service clock within tolerances specified in the normative references for the application. In particular, clocks to be used in the TDM network have requirements on wander to be maintained within tolerance over very long periods of time (24 hours or longer). As such, the clock recovery mechanism SHOULD be immune to very low frequency packet delay variation, such as that caused by different network usage levels during the day-time as compared to night-time. Frost et al. Expires January 2006 [Page 7] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 4.3.5. Congestion Control Unlike TDM circuits, the transfer of timing and synchronization does not require a constant packet rate. Therefore, some means of responding to congestion by reducing traffic load SHOULD be provided, including in the limit, the ability to temporarily shut down a Timing PW when severe congestion has been detected. The egress PE MUST provide some means of maintaining the timing and synchronization service to the CE under these conditions, e.g. by providing "holdover" capability. Further congestion considerations are discussed in chapter 6.5 of [RFC3985]. 4.3.6. Connection Defects Misconnected packets are defined as packets that have been wrongly identified as belonging to this pseudo-wire. If such packets pass the classification stage, they may be identified by checking the values of additional header fields, for example checking for an invalid source address, cookie value or SSRC value. Malformed packets are defined as packets that have passed the classification stage and misconnection checks, but that are malformed in some way, e.g. wrong length, or incorrect header or payload format. The encapsulation layer for timing PWs SHOULD, separately or in conjunction with the lower layers of the PWE3 stack, provide the ability to detect, report and discard both misconnected and malformed packets. 4.4. Redundancy requirements Timing and synchronization are heavily protected services in TDM networks, and a redundancy strategy to allow failover to an alternative timing source is always provided. 4.4.1. Redundancy and Failover The ability for an egress PE to switch to an alternative timing source MUST be provided. This alternative source MAY be another packet timing connection, or an alternative physical clock source. The switchover between the two MUST be transparent, so that the timing and synchronization service is not affected. Any resulting phase transient generated in the output clock MUST be within the tolerances for a clock re-arrangement operation specified in the normative references for the application. Frost et al. Expires January 2006 [Page 8] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 4.4.2. Synchronization quality indication The encapsulation layer SHOULD provide some means of indicating the quality level of a clock to downstream equipment. This SHOULD include indication of whether the master clock source has failed, and as a result gone into a holdover condition. This indication MAY be used by the egress PE to decide whether to switch over to an alternative clock source, if available. 5. Security Considerations The security considerations in [RFC3916] are fully applicable to the transmission of network timing and synchronization. The ability to disrupt synchronization services could be used as a key to disrupting an entire network, and especially any real-time services carried over the network. Therefore it is particularly important to know where a source of packet timing is coming from, and whether it is genuine. Therefore, it MUST be possible to provide some means of authentication of timing PWs. In addition these services are sensitive to packet delay variation, and need to be protected from this as a method of attack. Frost et al. Expires January 2006 [Page 9] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 6. References [RFC2119] S. Bradner, Key Words in RFCs to Indicate Requirement Levels, RFC 2119, IETF, 1997 [RFC3916] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to- Edge (PWE3), RFC3916, IETF, December 2004 [RFC3985] Stewart Bryant et al, Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture, RFC3985, IETF, March 2005 [PWE3-TDMREQ] Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switched Networks, Work in Progress, April 2005, draft-ietf-pwe3-tdm-requirements-08.txt [PWE3-SAToP] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over Packet (SAToP), Work in Progress, July 2005, draft-ietf-pwe3-satop-02.txt [PWE3-CESoPSN] A. Vainshtein et al, Structure-Aware TDM Circuit Emulation Services over Packet Switched Networks (CESoPSN), Work in Progress, July 2005, draft-ietf-pwe3-cesopsn-03.txt [PWE3-TDMoIP] Y. Stein et al, TDM over IP, Work in Progress, February 2005, draft-ietf-pwe3-tdmoip-03.txt [G.pactiming] S. Ruffini (editor), ITU Study Group 15, Question 13, Work in Progress, May 2005 Authors' Addresses Tim Frost, Zarlink Semiconductor, Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK Email: tim.frost@zarlink.com Silvana Rodrigues, Zarlink Semiconductor, 400 March Road, Kanata, Ottawa, Canada, K2K 3H4 Email: silvana.rodrigues@zarlink.com Frost et al. Expires January 2006 [Page 10] Internet Draft draft-frost-pwe3-timing-pw-reqs-00 July 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Frost et al. Expires January 2006 [Page 11]