idnits 2.17.1 draft-hjxl-ssn-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 23 instances of too long lines in the document, the longest one being 10 characters 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 (October 20, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 139, but not defined == Missing Reference: 'IEEE-1588' is mentioned on line 147, but not defined == Missing Reference: 'G.8273.2' is mentioned on line 148, but not defined == Unused Reference: 'G.8261' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'G.8275' is defined on line 349, 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 China Mobile 3 Internet Draft Y. Jiang 4 J. Xu 5 Intended status: Informational X. Liu 6 Huawei 7 Expires: April 2016 October 20, 2015 9 Problem Statements of Scalable Synchronization Networks 10 draft-hjxl-ssn-ps-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on April 20, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 With the wide deployment of 4G and beyond mobile networks, a great 52 number of cells need high precision frequency and/or time 53 synchronization for their normal operation. It is crucial to manage 54 the synchronization network in a scalable way and simplify the 55 monitoring and operation for synchronization networks. This document 56 analyzes the use cases and requirements in synchronization networks, 57 and provides a problem statement for scalable synchronization 58 networks. 60 Table of Contents 62 1. Introduction .............................................. 2 63 1.1. Conventions used in this document ...................... 4 64 1.2. Terminology ............................................ 4 65 2. Use cases for scalable synchronization network ............ 4 66 2.1. Synchronization configuration .......................... 4 67 2.2. Synchronization OAM .................................... 5 68 2.3. Synchronization network protection and recovery ........ 6 69 2.4. Multi-layer/Multi-domain synchronization network ....... 7 70 3. Synchronization Requirements .............................. 7 71 4. Security Considerations ................................... 8 72 5. IANA Considerations ....................................... 8 73 6. References ................................................ 8 74 6.1. Normative References ................................... 8 75 6.2. Informative References ................................. 8 76 7. Acknowledgments ........................................... 9 78 1. Introduction 80 In modern communication networks, most telecommunication services 81 require that the frequency or phase difference between the whole 82 network equipments should be kept within the reasonable range. 83 Especially for mobile networks, there is a requirement for high 84 precision network clock synchronization, including frequency 85 synchronization and phase synchronization. 87 For packet switching networks, SyncE and IEEE 1588v2 protocols are 88 widely deployed for frequency and time synchronization respectively 89 in mobile network. Synchronization path planning and provisioning are 90 very complex as so many parameters (e.g., quality level, priority, 91 synchronization enable/disable, hop limit, holdover timeout, and etc) 92 need to be configured. Furthermore, configuration of SyncE must not 93 introduce any loops in the synchronization paths. Hence, deployment 94 of synchronization network requires professional skills in 95 synchronization protocols and also the engineering capability in 96 analyzing and planning the network topology. 98 With the deployment of 4G network, the density of cells is 99 explosively growing, as a result, the size of mobile networks and its 100 backhaul network has greatly increased (it may consist of tens of 101 thousands of network equipments in a single metro city). This 102 scalability requirement will pose a great challenge to realize 103 synchronization, and the management and monitoring of the 104 synchronization network becomes dramatically more complex for service 105 providers. 107 In the past, management and monitoring of synchronization networks 108 are mainly resorted to manual configuration and manual diagnosis, 109 which are complex, error-prone and very time-consuming. Thus it is 110 hard to avoid synchronization loops, erroneous configuration and 111 other mistakes. Therefore, it is important to provide some tools to 112 improve the efficiency of fault monitoring and detection in 113 synchronization networks. 115 As the synchronization is critical for the mobile services, it will 116 beneficial to provide path protection for synchronization networks, 117 so that single point of synchronization failure can be avoided (or 118 even provide multipoint protection as much as possible, i.e., even 119 when the working path and a protection synchronization path are both 120 lost, the network can figure out a new synchronization path so that 121 frequency source is still available. This may require that a third 122 synchronization port be configured as a recovery port). 124 Furthermore, as the mobile network size increases dramatically, the 125 synchronization performance is hard to be satisfied, e.g., care must 126 be taken to guarantee that a certain hop limit (e.g. 20 hops) of 127 time-distribution from the timing source to a cell site is not 128 exceeded. 130 This document provides some use cases and requirements on 131 configuration and management of a large synchronization network and 132 provides problem statements for scalable synchronization networks. 134 1.1. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 1.2. Terminology 142 OAM: Operation Administration and Maintenance 144 BMCA: best master clock algorithm 146 T-GM: Telecom Grandmaster, a device consisting of a Boundary Clock as 147 defined in [IEEE-1588], with additional performance characteristics 148 defined in [G.8273.2]. 150 2. Use cases for scalable synchronization network 152 Following are some use cases of scalable synchronization networks 153 from a management and operation viewpoint. 155 2.1. Synchronization configuration 157 In a huge mobile backhaul network with more than 10,000 nodes, manual 158 planning and provisioning of synchronization network are very onerous. 159 For example, manual planning and configuration for a simple network 160 may need more than several weeks; furthermore, it is error-prone. And 161 the planning can't eliminate the risk of introducing loops to a 162 synchronization network. 164 To facilitate synchronization configuration, a central controller may 165 be introduced. The controller shall automatically compute, plan and 166 provision the synchronization paths based on the overall physical 167 network topology, thus it can eliminate the risks associated with 168 manual planning. 170 A typical controller for synchronization network can compute and 171 provision a synchronization network with tens of thousands of nodes 172 in just a few minutes, and it is guaranteed that no synchronization 173 loop will be introduced if the algorithm is correctly implemented. 174 Synchronization configuration via a centralized controller requires 175 that the controller be highly efficient, agile and reliable. 177 To accommodate for different types of equipment implementations, a 178 common interface is needed for synchronization network configuration 179 and management, it can further provide the ability to retrieve the 180 network's synchronization configuration and states of a protocol 181 engine in a device. For example, whether the device is locked or not, 182 what is the port state of PTP port (i.e., master, slave or passive), 183 the current port ID associated with a frequency source in syncE, and 184 etc... This capability is essential for the management and 185 maintenance of synchronization networks. 187 2.2. Synchronization OAM 189 In the maintenance of a huge synchronization network, an operator may 190 encounter various synchronization problems. The traditional manual 191 trouble shooting hop by hop is very onerous. Even if the malfunction 192 equipments are located in a single operator network, the fault 193 detection procedure is very tedious, let alone in the case of network 194 interworking with a third party. 196 Traditionally, synchronization fault detection is done by checking 197 synchronization devices on a path one by one manually. I.e., an 198 operator must login to the device (i.e. the device is adjacent to the 199 fault base station or the device nearest to the base station among 200 the devices with the clock alarm), read the configuration information, 201 status and clock alarms information. After analyzing all the 202 information, if the operator still can't locate the source for the 203 fault, the operator must find the upstream device according to the 204 synchronization status information (i.e. the port state of 1588v2 and 205 the current tracing clock port ID of syncE). The operator must login 206 to each upstream device and check the synchronization information one 207 by one, until the source device of the synchronization fault is found. 209 If the operator cannot locate the fault by the current limited 210 information from the equipments, the operator may have to test the 211 synchronization performance manually by instrument. 213 This procedure requires that the operator must have a deep 214 understanding of the synchronization protocols and principle of 215 synchronization engineering. And it also is very time-consuming, and 216 sometimes, detecting a single clock fault may even cost up to ten 217 days. 219 Sometimes the clock synchronization performance of base station 220 degraded but no clock alarm is raised. Through synchronization fault 221 detection an operator cannot locate the true reason of service 222 disruption. In that case, synchronization performance monitoring may 223 solve the problem by dynamically monitoring the synchronization 224 performance of all devices in the clock synchronization path for a 225 base station in problem. 227 Therefore, the functions of synchronization OAM shall include 228 synchronization fault detection and synchronization performance 229 monitoring, both are vital in the diagnosis of a synchronization 230 network. 232 2.3. Synchronization network protection and recovery 234 If a synchronization path is broken or degraded, it will seriously 235 influence the clock performance of the synchronization network, and 236 further affect the other services of the mobile network. Thus 237 protection and recovery of the synchronization network are very 238 necessary. 240 In general, if allowed by the network topology, the equipment should 241 be provisioned with a working and a protection synchronization path 242 for SyncE in a mobile network. Thus, the equipments in the mobile 243 network can realize synchronization protection with both the working 244 and backup clock ports. 246 Even when neither the clock signal on the working port nor on the 247 backup port is available (i.e. loss of signal or degrade of SNR 248 (Signal to Noise Ratio)), the equipment shall not lose the timing 249 source if there is connectivity to it. Ideally, the equipment should 250 select a third port with normal clock signal as a recovery port. And 251 the clock signal of the recovery port mustn't be from the equipment 252 itself (otherwise, a loop will be formed). When the clock signal of 253 the working port or backup port returns to normal, the device may 254 restore to the working or backup port. 256 In the time synchronization with the IEEE 1588v2, multiple time 257 synchronization ports of the device should be enabled. Through the 258 BMCA automatically selecting the time source can realize the 259 protection and recovery of the time source. 261 Central controller can also be a solution choice for this use case, 262 for example, provisioning and configuration of the recovery port in 263 advance or dynamic computation and configuration of the recovery port 264 on the fly. 266 2.4. Multi-layer/Multi-domain synchronization network 268 In general, to guarantee the time synchronization accuracy, the 269 suggested hop restriction value from the frequency source to the end 270 equipment is 20 in the synchronization network. And the suggested hop 271 restriction value from the time source to the end equipment is 30. 272 The values may be defined differently for different operators. 274 As tens of thousands of equipments needs to be supported in the same 275 synchronization network, the planning, maintenance and performance of 276 synchronization network face new challenges, for example, the end 277 equipments may hardly satisfy the hop restriction in synchronization. 278 Hierarchical division of a huge synchronization network into multi- 279 layers and/or multi-domains may improve the scalability. For example, 280 the whole synchronization network can be divided into several domains 281 according to their locations. 283 The operators may also face new challenges after introducing the 284 multi-layer/multi-domain synchronization network, for example, the 285 synchronization OAM for the inter-domain synchronization network is 286 more complex. In the deployment of syncE, the clock fault or 287 performance degradation of edge devices in one domain may even 288 influence the devices of other adjacent domains. 290 3. Synchronization Requirements 292 In order to facilitate the provision and management of a large 293 synchronization network, the following requirements need to be 294 addressed: 296 a) The synchronization network should support a generic, vendor-independent and 297 protocol-neutral information model for synchronization to support 298 heterogeneous networks; 300 b) The synchronization network should support automatic configuration of 301 frequency and time synchronization parameters based on the generic 302 information model, which may requires a generic configuration interface; 304 c) The synchronization network should provide high reliability and resiliency, 305 which requires that each synchronization device should maintain at least two 306 useable timing source and switch to an alternate timing source automatically 307 when faults occur in the network; furthermore, a device should restore to 308 the working path when the working path is recovered. 310 d) The synchronization network should provide high scalability, which may 311 require a network supports to be divided into multiple logical domains 312 defining the scope of synchronization distribution, or require a 313 synchronization protocol to maintain high precision timing signal along a 314 long synchronization path. From the management viewpoint, the network is 315 required to support provision and management by a central controller(even 316 for multi-layer/multi-domain case), or each synchronization device should 317 adjust its timing source automatically when the network adds or removes 318 devices; 320 e) The synchronization network should provide distributed signaling and 321 centralized signaling to support the traditional network architecture and 322 the innovative SDN architecture; 324 f) The synchronization network should provide flexible OAM (Operation 325 Administration and Maintenance) functions for synchronization, such as 326 troubleshooting and synchronization performance monitoring, which can be 327 called on demand if the requested timing performance is not met. 329 4. Security Considerations 331 It will be considered in a future revision. 333 5. IANA Considerations 335 There are no IANA actions required by this document. 337 6. References 339 6.1. Normative References 341 [IEEE-1588]IEEE 1588, Precision Clock Synchronization Protocol for 342 Networked Measurement and Control Systems, 2008 344 6.2. Informative References 346 [G.8261] ITU-T, Timing and synchronization aspects in packet networks, 347 August, 2013 349 [G.8275] ITU-T, Architecture and requirements for packet-based time 350 and phase distribution, November, 2013 352 [ptp-mib] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G., 353 Precision Time Protocol Version 2 (PTPv2) Management 354 Information Base, draft-ietf-tictoc-ptp-mib-06, work in 355 progress 357 7. Acknowledgments 359 TBD 361 Authors' Addresses 363 Liuyan Han 364 China Mobile 365 Xuanwumenxi Ave, Xuanwu District 366 Beijing 100053, China 367 Email: hanliuyan@chinamobile.com 369 Yuanlong Jiang 370 Huawei Technologies Co., Ltd. 371 Bantian, Longgang district 372 Shenzhen 518129, China 373 Email: jiangyuanlong@huawei.com 375 Jinchun Xu 376 Huawei Technologies Co., Ltd. 377 Bantian, Longgang district 378 Shenzhen 518129, China 379 Email: xujinchun@huawei.com 381 Xian Liu 382 Huawei Technologies Co., Ltd. 383 Bantian, Longgang district 384 Shenzhen 518129, China 385 Email: lene.liuxian@huawei.com