PWE3 Working Group T. Frost - Editor INTERNET-DRAFT Silvana Rodrigues Zarlink Semiconductor Stewart Bryant Cisco Systems Matthew Bocci John Tatham Yaakov Stein Alcatel RAD Data Communications Sasha Vainshtein Ron Cohen Axerra Networks Resolute Networks Expires: September 2006 March 2006 Requirements for Pseudo Wires carrying Timing and Synchronization draft-frost-pwe3-timing-pw-reqs-01.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-01 March 2006 Table of Contents 1. Introduction......................................................2 2. Terminology and Reference Models..................................3 2.1. Terminology....................................................3 2.2. Reference Model................................................3 3. Aspects of Time and Frequency Synchronization over Packet Networks3 3.1. Current Approaches.............................................4 4. Applications......................................................5 4.1. Cellular Phone Network Infrastructure..........................5 4.2. Use in conjunction with TDM emulation..........................6 5. Requirements......................................................9 5.1. Performance Requirements.......................................9 5.2. Robustness requirements........................................9 5.2.1. Packet loss................................................9 5.2.2. Out-of-order delivery......................................9 5.2.3. Absolute delay............................................10 5.2.4. Delay Variation...........................................10 5.2.5. Congestion Control........................................10 5.2.6. Connection Defects........................................10 5.3. Redundancy requirements.......................................11 5.3.1. Redundancy and Failover...................................11 5.3.2. Synchronization quality indication........................11 6. Security Considerations..........................................11 7. References.......................................................12 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. Similarly, the use of ATM pseudo- wires [PWE3-ATM] to carry AAL1 or AAL2 cells may also require accurate timing at both edges. 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]. Frost et al. Expires September 2006 [Page 2] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 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. 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. Aspects of Time and Frequency Synchronization over Packet Networks There are three aspects to the distribution of timing and synchronization: - Frequency distribution - i.e. the distribution of an accurate frequency reference from one point to another - Phase lock - i.e. the limiting of phase wander accumulation between two clocks to a maximum value - Time alignment - i.e. the synchronization of absolute time between two or more points Different applications require some or all of these three aspects. For example, basestations for a cellular phone network all require to operate at the same frequency (within a tolerance), to allow call handoff from cell to cell. Traditional wired telecommunication networks require both frequency and phase lock, to eliminate buffer slips. Third generation CDMA cellular networks require each Frost et al. Expires September 2006 [Page 3] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 basestation to have an absolute time reference, accurate to within a given tolerance value. 3.1. Current Approaches There are existing protocols for distribution of time synchronization over packet networks. These include NTP (Network Time Protocol, RFC1305), PTP (Precision Time Protocol, IEEE1588), and RTP (Real-time Transfer Protocol, RFC3550). NTP was developed for general synchronization of computer clocks over the internet, to an accuracy of 1 to 50 ms. This is not sufficient for many of the applications listed in section 4 below IEEE1588 was developed for the industrial machine segment, where a sub-microsecond accuracy was required. However, it was intended to be used over dedicated networks, with specialized hardware to generate, transmit and process the timing packets. It was not designed with a general-purpose routed network in mind. RTP was developed for transmission of real-time services (e.g. voice and video) over a packet network. As such, the frequency of the clock may be recovered from the arrival rate of packets and knowledge of the clock used to generate the timestamp field, although many applications of RTP do not require such clock recovery. The accuracy is limited depending on the frequency of the timestamp clock. 3.2 Timing Pseudo-Wires The use of pseudo-wires for timing transmission allows for customers of a packet network operator to distribute their own timing in parallel with their data networks. This timing will be contained within their own pseudo-wires, and hence invisible to other customers. Therefore multiple customers will be able to distribute independent time services across their own pseudo-wire connections. It is possible that existing protocols may be used within the pseudo- wire (e.g. an NTP or IEEE1588 pseudo-wire), although existing protocols may need modification before this is feasible. It should be noted that both NTP and IEEE15888 are undergoing revision at this time. Frost et al. Expires September 2006 [Page 4] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 4. Applications There are several applications that require timing and synchronization services over packet networks: - Cellular phone network infrastructure, for synchronization of basestations to the basestation controller when migrating to a packet-based backhaul infrastructure - Use in conjunction with TDM emulation, to improve the quality of timing available over TDM emulation services - Real time services, e.g. synchronization of IP PBXs or VoIP gateways, IP video services - industrial machines, e.g. synchronization of computer controlled robots over a factory network - scientific applications, e.g. synchronization of radio telescopes for long-baseline radio-astronomy 4.1. Cellular Phone Network Infrastructure It is becoming common in cellular phone infrastructure to migrate from leased-line TDM connections out to the basestation (e.g. E1 or T1) to a packet-based connection. This reduces the cost of For example, Figure 1 below shows a basestation controller connected to two basestations via an ATM link. Traditionally this has been carried over a TDM leased line, but in the diagram below this is replaced by a pair of ATM pseudo-wires. However, there is still a requirement for time services to the basestation, which is provided naturally by the synchronous nature of the TDM leased line. In this new configuration, a Time Server, driven from the same Primary Reference Source (PRS) as the basestation controller, is shown providing time and synchronization to the basestations via a timing pseudo-wire. The performance requirements for the cellular infrastructure application varies depending on the type of cellular network. GSM and UMTS FDD networks simply require accurate frequency distribution, since there is a maximum frequency difference of 50ppb (parts per billion) allowed between adjacent cells to permit efficient call handoff. CDMA and UMTS TDD networks additionally require absolute time synchronization of better than 10us. Frost et al. Expires September 2006 [Page 5] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 \|/ | +--------+ +-----+ +-----+ Clock +----+ | Time | Clock |.....|.......Timing PW1..| |-------| | | Server |--------| | | PE1 | ATM | BS | +--------+ |.....|..... ...ATM PW1...|.....|=======| | | | | . . +-----+ +----+ | | | . . PRS (~) | | . . | | PE | ..... | | | . . \|/ +-------------+ | | . . | | | | | . . +-----+ Clock +----+ | Basestation | ATM |.....|... ...Timing PW2..|.....|-------| | | |=====| | | PE2 | ATM | BS | | Controller | |.....|.........ATM PW2...|.....|=======| | | | | | +-----+ +----| +-------------+ +-----+ Figure 1: Use of Timing Pseudo-Wires in Cellular Infrastructure 4.2. 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 [RFC4197], section 4.3. The clock notation relates to the network synchronization reference model shown in Figure 1 of [RFC4197]. 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 September 2006 [Page 6] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 |<------- Pseudo-wires ------->| | | | |<-- PSN Tunnel -->| | V V V V AC +-----+ +-----+ AC +-----+ | | |==================| | | +-----+ | /-- |<---------|.............PW1..............|<---------| <-\ | || CE1| | | PE1 | | PE2 | | |CE2 || | \-> |--------->|.............PW2..............|--------->| --/ | +-----+ | | | | | | +-----+ +->|.............PW3..............|--+ | | |==================| | | | +-----+ +-----+ | | ^ ^ | | |C |D | +-----+ +-----+ | +-+ |I| +-+ Figure 2: 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 3: Relationship to the CE Synchronized Scenario Frost et al. Expires September 2006 [Page 7] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 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 [RFC4197]) 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 4: 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 September 2006 [Page 8] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 5. 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 5.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.8261] 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. 5.2. 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 5.2.1. Packet loss The encapsulation layer MUST allow the egress PE to minimise the effect of lost timing packets on the clock recovery process, without requiring retransmission of the original packet. 5.2.2. Out-of-order delivery The encapsulation layer MUST allow the egress PE to minimise the effect of out-of-order delivery of timing packets on the clock recovery process. Frost et al. Expires September 2006 [Page 9] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 5.2.3. Absolute delay The recovery of the clock MUST provide the ability to compensate for absolute delay, whererequired by the application (e.g. for those applications that require an absolute time reference). Delay compensation MUST be achieved while maintaining jitter and wander of the egress end service clock within tolerances specified in the normative references for the application. 5.2.4. Delay Variation Delay variation in packet networks is caused by a number of different mechanims, including competition for resources within network elements, output queuing, QoS mechanisms such as traffic shaping, quantisation effects caused by the underlying physical layer technology etc. 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. 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 throughout the day. 5.2.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]. 5.2.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. Frost et al. Expires September 2006 [Page 10] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 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. 5.3. 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. 5.3.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. 5.3.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. 6. 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 September 2006 [Page 11] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 7. References [RFC1305] D. Mills, Network Time Protocol (Version 3) Specification, Implementation", RFC1305, IETF, March 1992 [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 [RFC4197] M. Riegel (Ed.), "Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switched Networks", RFC4197, IETF, October 2005 [PWE3-SAToP] A. Vainshtein, Y. Stein, "Structure-Agnostic TDM over Packet (SAToP)", Work in Progress, February 2006, draft-ietf-pwe3-satop-05.txt [PWE3-CESoPSN] A. Vainshtein et al, "Structure-Aware TDM Circuit Emulation Services over Packet Switched Networks (CESoPSN)", Work in Progress, November 2005, draft-ietf-pwe3-cesopsn-06.txt [PWE3-TDMoIP] Y. Stein et al, "TDM over IP", Work in Progress, September 2005, draft-ietf-pwe3-tdmoip-04.txt [PWE3-ATM] L. Martini et al, "Encapsulation Methods for Transport of ATM Over MPLS Networks", Work in Progress, September 2005, draft-ietf-pwe3-atm-encap-10.txt [IEEE1588] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std. 1588-2002, November 2002 [G.8261] "Timing and Synchronization Aspects in Packet Networks", ITU-T, Work in Progress, February 2006 Frost et al. Expires September 2006 [Page 12] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 Authors' Addresses Tim Frost, Zarlink Semiconductor, Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK Email: tim.frost@zarlink.com Matthew Bocci, John Tatham Alcatel Grove House, Waltham Road Rd White Waltham, Berks, UK. SL6 3TN Email: matthew.bocci@alcatel.co.uk, john.p.tatham@alcatel.co.uk Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St., Tel Aviv 69719, Israel Email: sasha@axerra.com Stewart Bryant Cisco Systems, 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom. EMail: stbryant@cisco.com Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL Email: mailto:yaakov_s@rad.com Ron Cohen, Resolute Networks Ltd. Ligad Center 15 Central Avenue P.O.Box 101, Modi'in Business Park Modi'in 71700 Israel Email: ronc@resolutenetworks.com Silvana Rodrigues, Zarlink Semiconductor, 400 March Road, Kanata, Ottawa, Canada, K2K 3H4 Email: silvana.rodrigues@zarlink.com Frost et al. Expires September 2006 [Page 13] Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006 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 (2006). 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 September 2006 [Page 14]