idnits 2.17.00 (12 Aug 2021) /tmp/idnits35081/draft-hjxl-scsn-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2016) is 2252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 145, but not defined == Missing Reference: 'IEEE-1588' is mentioned on line 153, but not defined == Missing Reference: 'G.8273.2' is mentioned on line 154, but not defined == Unused Reference: 'G.8261' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'G.8275' is defined on line 324, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group L. Han 2 Internet-Draft China Mobile 3 Intended status: Informational Y. Jiang 4 J. Xu 5 X. Liu 6 Huawei 7 D. P. Venmani 8 Orange Labs 9 Expires: September 2016 March 21, 2016 11 Problem Statements of Scalable Synchronization Networks 12 draft-hjxl-scsn-ps-00.txt 14 Abstract 16 With the wide deployment of 4G and beyond mobile networks, a great 17 number of cells need high precision frequency and/or time 18 synchronization for their normal operation. It is crucial to 19 configure and manage the synchronization network in a scalable way, 20 and simplify the monitoring and operation for synchronization 21 networks. This document analyzes the use cases and requirements in 22 synchronization networks, and provides a problem statement for 23 scalable synchronization networks. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on September 21, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction .............................................. 2 65 1.1. Conventions used in this document ...................... 4 66 1.2. Terminology ............................................ 4 67 2. Use cases for scalable synchronization network ............ 4 68 2.1. Synchronization path configuration ..................... 4 69 2.2. Synchronization OAM .................................... 5 70 2.3. Synchronization network resiliency ..................... 6 71 2.4. Multi-layer/Multi-domain synchronization network ....... 6 72 3. Synchronization Requirements .............................. 7 73 4. Security Considerations ................................... 7 74 5. IANA Considerations ....................................... 8 75 6. References ................................................ 8 76 6.1. Normative References ................................... 8 77 6.2. Informative References ................................. 8 78 7. Acknowledgments ........................................... 9 80 1. Introduction 82 In modern communication networks, most telecommunication services 83 require that the frequency or phase difference between the whole 84 network equipments should be kept within the reasonable range. 85 Especially for mobile networks, there is a requirement for high 86 precision network clock synchronization, including frequency 87 synchronization and phase synchronization. 89 One focus of the Deterministic Networking (DetNet) Working Group in 90 the IETF is to provide solutions for services with deterministic 91 properties of controlled latency, thus it requires high precision 92 time synchronization among all relay systems in a DetNet network. 94 For packet switching networks, SyncE and IEEE 1588-2008/PTPv2 95 protocols are widely deployed for frequency and time synchronization 96 respectively in mobile network. Synchronization path planning and 97 provisioning are very complex as so many parameters (e.g., quality 98 level, priority, synchronization enable/disable, hop limit, holdover 99 timeout, and etc) need to be configured. Furthermore, configuration 100 of SyncE must not introduce any loops in the synchronization paths. 101 Hence, deployment of synchronization solutions in networks requires 102 professional skills in synchronization protocols and also the 103 engineering capability in analyzing and planning the network topology. 105 With the deployment of 4G network, the density of cells is 106 explosively growing, as a result, the size of mobile networks and its 107 backhaul network has greatly increased (it may consist of tens of 108 thousands of network equipments in a single metro city nowadays). 109 This scalability requirement will pose a great challenge to realize 110 synchronization, and the management and monitoring of the 111 synchronization network becomes dramatically more complex for service 112 providers. 114 In the past, management and monitoring of synchronization networks 115 are mainly resorted to manual configuration and manual diagnosis, 116 which are complex, error-prone and very time-consuming. Thus it is 117 hard to avoid synchronization loops, erroneous configuration and 118 other mistakes. Therefore, it is important to provide some tools to 119 improve the efficiency of fault monitoring and detection in 120 synchronization networks. 122 As the synchronization is critical for the mobile services, it will 123 beneficial to provide resiliency for synchronization networks, so 124 that synchronization failure can be recovered (even provide 125 protection in the distribution layer, i.e., even when the working 126 path synchronization path is lost, the frequency source is still 127 available from the protection path). 129 Furthermore, as the mobile network size increases dramatically, the 130 synchronization performance is hard to be satisfied, e.g., care must 131 be taken to guarantee that a certain hop limit (e.g. a maximum of 20 132 hops) of time-distribution from the timing source to a cell site is 133 not exceeded. 135 This document provides some use cases and requirements on 136 configuration and management of a large synchronization network and 137 provides problem statements for the SCalable Synchronization Network 138 (SCSN). 140 1.1. Conventions used in this document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 1.2. Terminology 148 OAM: Operation Administration and Maintenance 150 BMCA: best master clock algorithm 152 T-GM: Telecom Grandmaster, a device consisting of a Boundary Clock as 153 defined in [IEEE-1588], with additional performance characteristics 154 defined in [G.8273.2]. 156 2. Use cases for scalable synchronization network 158 Following are some use cases of SCSN from a management and operation 159 viewpoint. 161 2.1. Synchronization path configuration 163 In a huge mobile backhaul network with more than 10,000 nodes, manual 164 planning and provisioning of synchronization network are very onerous. 165 For example, manual planning and configuration for a simple network 166 may need more than several weeks; furthermore, it is error-prone. And 167 the planning can't eliminate the risk of introducing loops to a 168 synchronization network. 170 To facilitate synchronization configuration, a controller may be 171 introduced into the SCSN. The controller shall automatically compute, 172 plan and provision the synchronization paths based on the overall 173 physical network topology, thus it can eliminate the risks associated 174 with manual planning. 176 A typical controller for synchronization network can compute and 177 provision a synchronization network with tens of thousands of nodes 178 in just a few minutes, and it is guaranteed that no synchronization 179 loop will be introduced if the algorithm is correctly implemented. 180 Synchronization configuration via a centralized controller requires 181 that the controller be highly efficient, agile and reliable. 183 To accommodate for different types of equipment implementations, a 184 common interface is needed for synchronization network configuration 185 and management, it can further provide the ability to retrieve the 186 network's synchronization configuration and states of a protocol 187 engine in a device. For example, whether the device is locked or not, 188 what is the port state of PTP port (i.e., master, slave or passive), 189 the current port ID associated with a frequency source in syncE, and 190 etc. This capability is essential for the management and maintenance 191 of synchronization networks. 193 2.2. Synchronization OAM 195 In the maintenance of a huge synchronization network, an operator may 196 encounter various synchronization problems. The traditional manual 197 trouble shooting hop by hop is very onerous. Even if the malfunction 198 equipments are located in a single operator network, the fault 199 detection procedure is very tedious, let alone in the case of network 200 interworking with a third party. 202 Traditionally, synchronization fault detection is done by checking 203 synchronization devices on a path one by one manually, i.e., an 204 operator must login to the device (i.e. the device is adjacent to the 205 fault base station or the device nearest to the base station among 206 the devices with the clock alarm), read the configuration information, 207 status and clock alarms information. After analyzing all the 208 information, if the operator still can't locate the source for the 209 fault, the operator must find the upstream device according to the 210 synchronization status information (i.e. the port state of 1588v2 and 211 the current tracing clock port ID of syncE). The operator must login 212 to each upstream device and check the synchronization information one 213 by one, until the source device of the synchronization fault is found. 215 If the operator cannot locate the fault with the current limited 216 information from the equipments, the operator may have to test the 217 synchronization performance manually by some external instruments. 219 This procedure requires that the operator must have a deep 220 understanding of the synchronization protocols and principle of 221 synchronization engineering. And it also is very time-consuming, and 222 sometimes, detecting a single clock fault may even cost up to ten 223 days. 225 Sometimes, the clock synchronization performance of base station 226 degraded but no clock fault alarm is raised. With synchronization 227 fault detection, an operator cannot locate the true reason of service 228 disruption. In that case, on-demand performance monitoring of a 229 synchronization path may provide the needed information for diagnosis 230 by monitoring the synchronization performance of all devices in the 231 synchronization path if a base station at the end of the path is in 232 problem. 234 Therefore, the functions of synchronization OAM shall include 235 synchronization fault detection and synchronization performance 236 monitoring, both are vital in the diagnosis of a synchronization 237 network. 239 2.3. Synchronization network resiliency 241 If a synchronization path is broken or degraded, it will seriously 242 influence the clock performance of the synchronization network, and 243 further affect the other services of the mobile network. Thus 244 resiliency of the synchronization network is very important. 246 In general, if allowed by the network topology, the equipment can be 247 provisioned with a working and a protection synchronization path for 248 SyncE in a mobile network. Thus, the equipments in the mobile network 249 can realize synchronization protection with both the working and 250 backup ports. 252 Even when neither the clock signal on the working port nor on the 253 backup port is available (i.e. loss of signal or degrade of SNR 254 (Signal to Noise Ratio)), the equipment shall not lose the timing 255 source if there is connectivity to it. Ideally, the network can 256 restore from the fault by computation of another path with the help 257 of the controller. 259 2.4. Multi-layer/Multi-domain synchronization network 261 In general, to guarantee the time synchronization accuracy, the 262 suggested maximum hop from the frequency source to the end equipment 263 is 20 in the synchronization network. And the suggested maximum hop 264 from the time source to the end equipment is 30. The maximum values 265 may be defined differently for different operators in different 266 geographies. 268 As tens of thousands of equipments needs to be supported in the same 269 synchronization network, the planning, maintenance and performance of 270 synchronization network face new challenges, for example, the end 271 equipments may hardly satisfy the hop restriction in synchronization. 272 Hierarchical division of a huge synchronization network into multi- 273 layers and/or multi-domains may improve the scalability. For example, 274 the whole synchronization network can be divided into several domains 275 according to their locations. 277 3. Synchronization Requirements 279 In order to facilitate the provision and management of a large 280 synchronization network, the following requirements need to be 281 addressed in the SCSN: 283 a)The synchronization network should support a generic, vendor- 284 independent and protocol-neutral data model for the 285 synchronization configuration to support heterogeneous networks; 287 b)The synchronization network should support computation and 288 configuration of frequency and time synchronization path; 290 c)The synchronization network should provide high reliability and 291 resiliency to protect and recover from failures in synchronization. 293 d)The synchronization network should provide high scalability, which 294 may require a network to be divided into multiple logical domains, 295 but still maintain a high precision timing signal along a long 296 synchronization path. 298 e)The synchronization network should provide flexible OAM (Operation 299 Administration and Maintenance) functions for synchronization, 300 such as troubleshooting and synchronization performance monitoring, 301 which can be called on demand if the requested timing performance 302 is not met. 304 4. Security Considerations 306 It will be considered in a future revision. 308 5. IANA Considerations 310 There are no IANA actions required by this document. 312 6. References 314 6.1. Normative References 316 [IEEE-1588]IEEE 1588, Precision Clock Synchronization Protocol for 317 Networked Measurement and Control Systems, 2008 319 6.2. Informative References 321 [G.8261] ITU-T, Timing and synchronization aspects in packet networks, 322 August, 2013 324 [G.8275] ITU-T, Architecture and requirements for packet-based time 325 and phase distribution, November, 2013 327 [ptp-mib] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G., 328 Precision Time Protocol Version 2 (PTPv2) Management 329 Information Base, draft-ietf-tictoc-ptp-mib-06, work in 330 progress 332 7. Acknowledgments 334 TBD 336 Authors' Addresses 338 Liuyan Han 339 China Mobile 340 Xuanwumenxi Ave, Xuanwu District 341 Beijing 100053, China 342 Email: hanliuyan@chinamobile.com 344 Yuanlong Jiang 345 Huawei Technologies Co., Ltd. 346 Bantian, Longgang district 347 Shenzhen 518129, China 348 Email: jiangyuanlong@huawei.com 350 Jinchun Xu 351 Huawei Technologies Co., Ltd. 352 Bantian, Longgang district 353 Shenzhen 518129, China 354 Email: xujinchun@huawei.com 356 Xian Liu 357 Huawei Technologies Co., Ltd. 358 Bantian, Longgang district 359 Shenzhen 518129, China 360 Email: lene.liuxian@huawei.com 362 Daniel Philip Venmani 363 Orange Labs 364 2, avenue Pierre Marzin, 365 Lannion 22307, France 366 Email: danielphilip.venmani@orange.com