Network Working Group Kuiwen Ji Huawei Internet Draft Category: Informational Expires: August 2008 February, 2008 IEEE1588V2 telecom profile framework draft-ji-tictoc-1588-telecom-profile-framework-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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August, 2008. Abstract This Internet draft proposes the framework of IEEE1588V2 telecom profile. Ji Expires August 3, 2008 [Page 1] Internet-Draft IEEE1588V2 telecom profile framework February 2008 Conventions used in this document 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 RFC-2119. Table of Contents 1. Introduction................................................3 2. Requirement.................................................3 2.1. Wireless...............................................3 2.1.1. CDMA2000 Base Station (frequency and time synchronization).........................................3 2.1.2. UMTS TDD Base Station (frequency and phase synchronization).........................................4 2.1.3. TD-SCDMA Base Station (frequency and phase synchronization).........................................4 2.2. Other domains..........................................5 2.3. Scenario...............................................5 3. Interface...................................................6 3.1. Interface type.........................................6 3.2. Performance............................................6 4. Modeling....................................................6 4.1. On-pass support........................................6 4.1.1. BC................................................7 4.1.2. E2ETC.............................................8 4.1.3. P2PTC.............................................8 4.2. No on-pass support.....................................9 4.3. Hybrid................................................11 5. Time Distribution..........................................11 6. Security Considerations....................................11 7. IANA Considerations........................................11 8. Acknowledgments............................................11 9. References.................................................12 9.1. Normative References.................................12 9.2. Informative References...............................12 Author's Addresses............................................12 Intellectual Property Statement...............................12 Disclaimer of Validity........................................13 Copyright Statement...........................................13 Acknowledgment................................................13 Ji Expires August 3, 2008 [Page 2] Internet-Draft IEEE1588V2 telecom profile framework February 2008 1. Introduction There are various telecommunications applications that can potentially be supported by methods of timing distribution. Timing distribution includes frequency, phase and time synchronization. In this document we only consider about phase or time synchronization (they may need frequency synchronization also). To allow PTP-IEEE-1588 to satisfy the need(s) of the applications requiring timing, it is necessary to ensure that all IEEE 1588- capable devices have the features and performance to support the applications at the appropriate level. That is, the timing distribution method must be fit-for-purpose. It's necessary to define a telecom profile immediately. Some of the considerations in developing the profile are described below include: -- Requirement -- Interface -- Modeling -- TOD Distribution 2. Requirement Various of applications in telecom need different kinds of synchronous. At first, it's important to provide some explanatory information about it. Of course the profile and solution should suit for them. G.8261 summarizes some of it. 2.1. Wireless Within this general use-case category there are several applications of importance. The application, from the viewpoint of timing, is to deliver the appropriate timing information to a base station (e.g. Node B). 2.1.1. CDMA2000 Base Station (frequency and time synchronization) The relevant CDMA2000 standards are the 3GPP2 C.S0010-B and 3GPP2 C S0002-B. According to the CDMA2000 specifications the average frequency difference between the actual CDMA transmit carrier frequency and Ji Expires August 3, 2008 [Page 3] Internet-Draft IEEE1588V2 telecom profile framework February 2008 specified CDMA transmit frequency assignment shall be less than ?0 ppb. In the CDMA2000 specifications it is also specified that each base station shall use a time base reference that is time-aligned to CDMA System Time. CDMA System Time is synchronous to UTC time (except for leap seconds) and uses the same time origin as GPS time. All base stations use the same System Time (within a small error tolerance). For all base stations, the pilot time alignment error should be less than 3s and shall be less than 10s. Because of the above requirements it is a common practice to equip CDMA base stations with GPS receivers. 2.1.2. UMTS TDD Base Station (frequency and phase synchronization) The timing requirement applicable to the WCDMA TDD radio interface can be found in the technical specification TS 125.105 [B5]. The radio interface requirement for UMTS TDD base stations is a frequency accuracy of ?0ppb; for the TDD mode there is the additional requirement for the phase alignment of neighboring base stations to within 2.5s. As for the case of GSM networks there are not so strict frequency accuracy requirements related to limit the slip rate because of the large buffer used to store data of a single user. 2.1.3. TD-SCDMA Base Station (frequency and phase synchronization) The timing requirement applicable to the TD-SCDMA radio interface can be found in the technical specification 3GPP TR 25.836. The radio interface requirement for TD-SCDMA base stations is a frequency accuracy of ?0ppb; there is the additional requirement for the phase alignment of neighboring base stations to within 3s (this requirement is then measured comparing the phase between adjacent Base Stations). Because of the above requirements it is a common practice to equip TD-SCDMA base stations with GPS receivers. Notes The requirements listed in the previous clauses apply to the radio interface. When time or frequency reference is carried by the network, other requirements apply. These depend on several factors such as Radio Base Station oscillator characteristics, filter capability of the Radio Base Station, etc. As an example a long term Ji Expires August 3, 2008 [Page 4] Internet-Draft IEEE1588V2 telecom profile framework February 2008 frequency accuracy significantly better than 50 ppb may be required for the reference timing signal carried over the network in case of 50 ppb frequency accuracy requirement shall be fulfilled on the radio interface. The value of 16 ppb (ITU-T G.812 Type II frequency accuracy) has sometimes been mentioned. Similarly, in case accurate time and/or phase shall be distributed to the Radio Base Stations, the budget to be allocated to the network might be much smaller than the requirements defined by the wireless standards to be fulfilled on the radio interface. These aspects are for further study. 2.2. Other domains Besides wireless application there still some aspects need phase or time synchronization such as DVB, IPTV, etc. We propose consideration about wireless application at first time. 2.3. Scenario +---+---+ | Time | + Server+ | | +-------+ / / / +--+--+ +--+--+ +----+----+ | | | | | Base | + NE +-------------+ NE +-----+ Station + | | | | | | +-----+ +-----+ +---------+ | | | | | | +--+--+ +--+--+ | | | | + NE +-------------+ NE + | | | | +-----+ +-----+ | | | | | | +----+----+ +----+----+ | Base | | Base | + Station + + Station + | | | | +---------+ +---------+ Figure1. Wireless scenario Ji Expires August 3, 2008 [Page 5] Internet-Draft IEEE1588V2 telecom profile framework February 2008 Figure 1 shows the scenario for wireless application. Base stations get time information from server though backhaul network. Time server can be a SSU or be integrated in the RNC (BSC). 3. Interface As the wireless scenario shows, there are two important time interfaces we should consider about. One is the interface between time server and NE (interface A). Another is the interface between Base station and NE (interface B). 3.1. Interface type To transport time information, using the Ethernet interface like FE, GE with IEEE1588V2 is a natural solution. 2048 kbit/s or 1544 kbit/s interfaces defined in G.703 have been use for a long time for transport frequency information in telecom. Is it necessary to define such a standard time interface? 3.2. Performance The requirements listed above apply to the radio interface in Base station. Interface B is network interface of Base station. It's necessary to talk about the requirement of interface B with different wireless standard body. Then we can specify the requirement of interface A. The budget between interface A and B is the specification for network equipments. 4. Modeling There was much discussion about different solution. The most important is 1588 on-pass support or not. 4.1. On-pass support First of all, we need to define what '1588 on-pass support' means. Here it means every node in the synchronous chain from master to slave (server to client) can support 1588. Three situations list below. In this case, many parameters are required to specify a profile, a list of them is proposed, but it is certainly not yet exhaustive. -- Size of the network (the limitation number of NEs in a synchronization chain). Ji Expires August 3, 2008 [Page 6] Internet-Draft IEEE1588V2 telecom profile framework February 2008 -- Characteristic of clocks (bandwidth, tolerance, noise generation, etc.). -- Types of 1588 V2 messages and packet sending rate periodically. -- Network Limits (see section 3.2). -- Availability of a master clock protection mechanism (see section 5). 4.1.1. BC The general concept of delivering time information by boundary clock modeling is given in Figure 2. There may be a number of BC Nodes involved in the distribution of the reference time signal. In such cases the synchronization function providing filtering and may require holdover within these nodes must be able to recover time synchronization from master. Synchronization transports one by one in a similar way to Sync-E. +----+----+ +--+---+ +--+---+ +----+----+ | Time | | | | | | | | Server M|<<--->>|S BC M|<<--->>|S BC M|<<--->>|S Client | | | | | | | | | +---------+ +------+ +------+ +---------+ Figure2. BC modeling Notes: it's mostly different for several parameters with Sync-E or not. It has been mentioned 1588 can be used combinative with Sync-E. Shall we consider about it? Ji Expires August 3, 2008 [Page 7] Internet-Draft IEEE1588V2 telecom profile framework February 2008 4.1.2. E2ETC As shows in figure3, the end-to-end transparent clock is totally different from boundary clock. Each ETETC node involved in the distribution of the reference time signal doesn't need to synchronize to the master. They measure the residence time of PTP event messages (the time the message takes to traverse the transparent clock node). These residence times are accumulated in a special field - Correction Field. +----+----+ +--+---+ +--+---+ +----+----+ | Time | | | | | | | | Server M|<<--->>|T TC T|<<--->>|T TC T|<<--->>|S Client | | || || || ^| | | | +---------+| |+------+| ^+------+ +---------+ | v v ^ | v v | | +-+-+-+-+-+ | | | Resident| | | | time | | v +-+-+-+-+-+ | v | | +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | ...... | | | ...... | | | | | | +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | PTP paylord | | | PTP paylord | | | v | | +-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+ | Correction | v | Correction | | field |>>+>>>| field | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | ...... | | ...... | | | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Figure 3, E2ETC modeling 4.1.3. P2PTC The peer-to-peer transparent clock differs from the end-to-end transparent clock in the way it corrects and handles the PTP timing messages of Pdelay_Req, Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up to compute the link delay. The P2PTC nodes compute the link delay between each port and a similarly equipped port on another node sharing the link. The appropriate Correction Field is updated for both the Ji Expires August 3, 2008 [Page 8] Internet-Draft IEEE1588V2 telecom profile framework February 2008 residence time of the message within the P2PTC nodes and for the link delay on the port receiving the message. Note: performance may be better if E2ETC or P2PTC nodes have well frequency synchronization like OC or Sync-E. 4.2. No on-pass support The second methods relies on time information such as 1588 messages carried by the network without 1588 support (like BC, TC, etc.) as shown in Figure 5. In case the intermediate nodes are not 1588 support especially where legacy equipment is used, this is the only alternative to time synchronization distributed approach. It's not necessary for the support of a network-wide 1588 reference. Therefore the performance is highly impacted by Packet Delay Variation in the network. In order to minimize the impact from the packet network, specific algorithms may need to be implemented at the slave side, depending on the required accuracy. Ji Expires August 3, 2008 [Page 9] Internet-Draft IEEE1588V2 telecom profile framework February 2008 In this case, many parameters are required to specify a profile, a list of them is proposed, but it is certainly not yet exhaustive. -- Size of the network and relevant PDV. -- Characteristic of clocks (bandwidth, tolerance, noise generation, etc.). -- Types of 1588 V2 messages and packet sending rate periodically. -- Network Limits (see section 3.2). -- Availability of a master clock protection mechanism (see section 5). /\-----+-----/\ +----+----+ //// \\\\ +----+----+ | Time | || Packet swithed || | | | Server M|<<-----| network Cloud |----->>|S Client | | | || || | | +---------+ \\\\ //// +---------+ \-------+-----/ Figure 5, No on-pass support modeling Notes: the key point is network PDV for this situation which ITU-T Q13/SG15 is talking about. Consider about potential asymmetry of two- way delay and high PDV infection, it has been mentioned difficult to meet the time synchronization of wireless requirement. It's also different if the intermediate network supports Sync-E or not. Physical layer clock can be utilized to stabilize the local oscillator time base to improve the estimation of time offset by increasing the sample size and addresses short periods when the PTP timing flow is either unavailable or experience large delay. Shall we consider about it? Ji Expires August 3, 2008 [Page 10] Internet-Draft IEEE1588V2 telecom profile framework February 2008 4.3. Hybrid It's complex situation for example a network with some of legacy equipments and some of E2ETC equipments. We propose discussion it later. 5. Time Distribution Distribution mechanism is very important for network time synchronization. BMC introduced in the IEEEE1588V2 is a solution. RON's daft 'PTP over MPLS' is another good suggestion for time distribution in MPLS/IP network. A list of aspects may be considered about to specify a suitable telecom mechanism, but it is certainly not yet exhaustive. -- Find the best grandmaster. -- Calculating the traceability paths if possible and path selection. -- Building a tree like distribution (prevent timing-loop any time). -- Fast switching when failure occurs to maintain a degree of performance. 6. Security Considerations An experimental security protocol is defined in [PTPv2]. The PTP security extension and protocol provide group source authentication, message integrity, and replay attack protection for PTP messages. 7. IANA Considerations No IANA actions are required as a result of the publication of this document. 8. Acknowledgments Add any acknowledgements Ji Expires August 3, 2008 [Page 11] Internet-Draft IEEE1588V2 telecom profile framework February 2008 9. References 9.1. Normative References [PTPv2] IEEE, ''IEEE P1588/D2.2 Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". [G.8261] ITU-T, "G.8261 - Timing and Synchronization aspects in Packet Networks". 9.2. Informative References Author's Addresses Kuiwen Ji Huawei Technologies Co. Ltd. F3 3A, Huawei Industrial Base Longgang Shenzhen 518129 P.R.China China Email: Jikuiwen@huawei.com Xiaodong Duan China Mobile Communications Corporation 53A, Xibianmennei Ave., Xuanwu District Beijing, 100053 P.R.China Email: duanxiaodong@Chinamobile.com 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 Ji Expires August 3, 2008 [Page 12] Internet-Draft IEEE1588V2 telecom profile framework February 2008 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, THE IETF TRUST 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ji Expires August 3, 2008 [Page 13]