[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Working Group                                          L. Han
                                                          China Mobile
Internet Draft                                                Y. Jiang
                                                                 J. Xu
Intended status: Informational                                  X. Liu
                                                                Huawei
Expires: April 2016                                   October 20, 2015


          Problem Statements of Scalable Synchronization Networks
                          draft-hjxl-ssn-ps-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 April 20, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Han and et al          Expires April 20, 2016                 [Page 1]


Internet-Draft                  PS in SSN                 October 2015


Abstract

   With the wide deployment of 4G and beyond mobile networks, a great
   number of cells need high precision frequency and/or time
   synchronization for their normal operation. It is crucial to manage
   the synchronization network in a scalable way and simplify the
   monitoring and operation for synchronization networks. This document
   analyzes the use cases and requirements in synchronization networks,
   and provides a problem statement for scalable synchronization
   networks.




Table of Contents

   1.   Introduction .............................................. 2
      1.1. Conventions used in this document ...................... 4
      1.2. Terminology ............................................ 4
   2.   Use cases for scalable synchronization network ............ 4
      2.1. Synchronization configuration .......................... 4
      2.2. Synchronization OAM .................................... 5
      2.3. Synchronization network protection and recovery ........ 6
      2.4. Multi-layer/Multi-domain synchronization network ....... 7
   3.   Synchronization Requirements .............................. 7
   4.   Security Considerations ................................... 8
   5.   IANA Considerations ....................................... 8
   6.   References ................................................ 8
      6.1. Normative References ................................... 8
      6.2. Informative References ................................. 8
   7.   Acknowledgments ........................................... 9



1. Introduction

   In modern communication networks, most telecommunication services
   require that the frequency or phase difference between the whole
   network equipments should be kept within the reasonable range.
   Especially for mobile networks, there is a requirement for high
   precision network clock synchronization, including frequency
   synchronization and phase synchronization.

   For packet switching networks, SyncE and IEEE 1588v2 protocols are
   widely deployed for frequency and time synchronization respectively
   in mobile network. Synchronization path planning and provisioning are
   very complex as so many parameters (e.g., quality level, priority,


Han and et al          Expires April 20, 2016                 [Page 2]


Internet-Draft                  PS in SSN                 October 2015


   synchronization enable/disable, hop limit, holdover timeout, and etc)
   need to be configured. Furthermore, configuration of SyncE must not
   introduce any loops in the synchronization paths. Hence, deployment
   of synchronization network requires professional skills in
   synchronization protocols and also the engineering capability in
   analyzing and planning the network topology.

   With the deployment of 4G network, the density of cells is
   explosively growing, as a result, the size of mobile networks and its
   backhaul network has greatly increased (it may consist of tens of
   thousands of network equipments in a single metro city). This
   scalability requirement will pose a great challenge to realize
   synchronization, and the management and monitoring of the
   synchronization network becomes dramatically more complex for service
   providers.

   In the past, management and monitoring of synchronization networks
   are mainly resorted to manual configuration and manual diagnosis,
   which are complex, error-prone and very time-consuming. Thus it is
   hard to avoid synchronization loops, erroneous configuration and
   other mistakes. Therefore, it is important to provide some tools to
   improve the efficiency of fault monitoring and detection in
   synchronization networks.

   As the synchronization is critical for the mobile services, it will
   beneficial to provide path protection for synchronization networks,
   so that single point of synchronization failure can be avoided (or
   even provide multipoint protection as much as possible, i.e., even
   when the working path and a protection synchronization path are both
   lost, the network can figure out a new synchronization path so that
   frequency source is still available. This may require that a third
   synchronization port be configured as a recovery port).

   Furthermore, as the mobile network size increases dramatically, the
   synchronization performance is hard to be satisfied, e.g., care must
   be taken to guarantee that a certain hop limit (e.g. 20 hops) of
   time-distribution from the timing source to a cell site is not
   exceeded.

    This document provides some use cases and requirements on
    configuration and management of a large synchronization network and
    provides problem statements for scalable synchronization networks.







Han and et al          Expires April 20, 2016                 [Page 3]


Internet-Draft                  PS in SSN                 October 2015


1.1. 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 [RFC2119].



1.2. Terminology

   OAM: Operation Administration and Maintenance

   BMCA: best master clock algorithm

   T-GM: Telecom Grandmaster, a device consisting of a Boundary Clock as
   defined in [IEEE-1588], with additional performance characteristics
   defined in [G.8273.2].



2. Use cases for scalable synchronization network

   Following are some use cases of scalable synchronization networks
   from a management and operation viewpoint.

2.1. Synchronization configuration

   In a huge mobile backhaul network with more than 10,000 nodes, manual
   planning and provisioning of synchronization network are very onerous.
   For example, manual planning and configuration for a simple network
   may need more than several weeks; furthermore, it is error-prone. And
   the planning can't eliminate the risk of introducing loops to a
   synchronization network.

   To facilitate synchronization configuration, a central controller may
   be introduced. The controller shall automatically compute, plan and
   provision the synchronization paths based on the overall physical
   network topology, thus it can eliminate the risks associated with
   manual planning.

   A typical controller for synchronization network can compute and
   provision a synchronization network with tens of thousands of nodes
   in just a few minutes, and it is guaranteed that no synchronization
   loop will be introduced if the algorithm is correctly implemented.
   Synchronization configuration via a centralized controller requires
   that the controller be highly efficient, agile and reliable.



Han and et al          Expires April 20, 2016                 [Page 4]


Internet-Draft                  PS in SSN                 October 2015


   To accommodate for different types of equipment implementations, a
   common interface is needed for synchronization network configuration
   and management, it can further provide the ability to retrieve the
   network's synchronization configuration and states of a protocol
   engine in a device. For example, whether the device is locked or not,
   what is the port state of PTP port (i.e., master, slave or passive),
   the current port ID associated with a frequency source in syncE, and
   etc... This capability is essential for the management and
   maintenance of synchronization networks.



2.2. Synchronization OAM

   In the maintenance of a huge synchronization network, an operator may
   encounter various synchronization problems. The traditional manual
   trouble shooting hop by hop is very onerous. Even if the malfunction
   equipments are located in a single operator network, the fault
   detection procedure is very tedious, let alone in the case of network
   interworking with a third party.

   Traditionally, synchronization fault detection is done by checking
   synchronization devices on a path one by one manually. I.e., an
   operator must login to the device (i.e. the device is adjacent to the
   fault base station or the device nearest to the base station among
   the devices with the clock alarm), read the configuration information,
   status and clock alarms information. After analyzing all the
   information, if the operator still can't locate the source for the
   fault, the operator must find the upstream device according to the
   synchronization status information (i.e. the port state of 1588v2 and
   the current tracing clock port ID of syncE). The operator must login
   to each upstream device and check the synchronization information one
   by one, until the source device of the synchronization fault is found.

   If the operator cannot locate the fault by the current limited
   information from the equipments, the operator may have to test the
   synchronization performance manually by instrument.

   This procedure requires that the operator must have a deep
   understanding of the synchronization protocols and principle of
   synchronization engineering. And it also is very time-consuming, and
   sometimes, detecting a single clock fault may even cost up to ten
   days.

   Sometimes the clock synchronization performance of base station
   degraded but no clock alarm is raised. Through synchronization fault
   detection an operator cannot locate the true reason of service


Han and et al          Expires April 20, 2016                 [Page 5]


Internet-Draft                  PS in SSN                 October 2015


   disruption. In that case, synchronization performance monitoring may
   solve the problem by dynamically monitoring the synchronization
   performance of all devices in the clock synchronization path for a
   base station in problem.

   Therefore, the functions of synchronization OAM shall include
   synchronization fault detection and synchronization performance
   monitoring, both are vital in the diagnosis of a synchronization
   network.

2.3. Synchronization network protection and recovery

   If a synchronization path is broken or degraded, it will seriously
   influence the clock performance of the synchronization network, and
   further affect the other services of the mobile network. Thus
   protection and recovery of the synchronization network are very
   necessary.

   In general, if allowed by the network topology, the equipment should
   be provisioned with a working and a protection synchronization path
   for SyncE in a mobile network. Thus, the equipments in the mobile
   network can realize synchronization protection with both the working
   and backup clock ports.

   Even when neither the clock signal on the working port nor on the
   backup port is available (i.e. loss of signal or degrade of SNR
   (Signal to Noise Ratio)), the equipment shall not lose the timing
   source if there is connectivity to it. Ideally, the equipment should
   select a third port with normal clock signal as a recovery port. And
   the clock signal of the recovery port mustn't be from the equipment
   itself (otherwise, a loop will be formed). When the clock signal of
   the working port or backup port returns to normal, the device may
   restore to the working or backup port.

   In the time synchronization with the IEEE 1588v2, multiple time
   synchronization ports of the device should be enabled. Through the
   BMCA automatically selecting the time source can realize the
   protection and recovery of the time source.

   Central controller can also be a solution choice for this use case,
   for example, provisioning and configuration of the recovery port in
   advance or dynamic computation and configuration of the recovery port
   on the fly.






Han and et al          Expires April 20, 2016                 [Page 6]


Internet-Draft                  PS in SSN                 October 2015


2.4. Multi-layer/Multi-domain synchronization network

   In general, to guarantee the time synchronization accuracy, the
   suggested hop restriction value from the frequency source to the end
   equipment is 20 in the synchronization network. And the suggested hop
   restriction value from the time source to the end equipment is 30.
   The values may be defined differently for different operators.

   As tens of thousands of equipments needs to be supported in the same
   synchronization network, the planning, maintenance and performance of
   synchronization network face new challenges, for example, the end
   equipments may hardly satisfy the hop restriction in synchronization.
   Hierarchical division of a huge synchronization network into multi-
   layers and/or multi-domains may improve the scalability. For example,
   the whole synchronization network can be divided into several domains
   according to their locations.

   The operators may also face new challenges after introducing the
   multi-layer/multi-domain synchronization network, for example, the
   synchronization OAM for the inter-domain synchronization network is
   more complex. In the deployment of syncE, the clock fault or
   performance degradation of edge devices in one domain may even
   influence the devices of other adjacent domains.

3. Synchronization Requirements

   In order to facilitate the provision and management of a large
   synchronization network, the following requirements need to be
   addressed:

   a) The synchronization network should support a generic, vendor-independent and
      protocol-neutral information model for synchronization to support
      heterogeneous networks;

   b) The synchronization network should support automatic configuration of
      frequency and time synchronization parameters based on the generic
      information model, which may requires a generic configuration interface;

   c) The synchronization network should provide high reliability and resiliency,
      which requires that each synchronization device should maintain at least two
      useable timing source and switch to an alternate timing source automatically
      when faults occur in the network; furthermore, a device should restore to
      the working path when the working path is recovered.

   d) The synchronization network should provide high scalability, which may
      require a network supports to be divided into multiple logical domains
      defining the scope of synchronization distribution, or require a


Han and et al          Expires April 20, 2016                 [Page 7]


Internet-Draft                  PS in SSN                 October 2015


      synchronization protocol to maintain high precision timing signal along a
      long synchronization path. From the management viewpoint, the network is
      required to support provision and management by a central controller(even
      for multi-layer/multi-domain case), or each synchronization device should
      adjust its timing source automatically when the network adds or removes
      devices;

   e) The synchronization network should provide distributed signaling and
      centralized signaling to support the traditional network architecture and
      the innovative SDN architecture;

   f) The synchronization network should provide flexible OAM (Operation
      Administration and Maintenance) functions for synchronization, such as
      troubleshooting and synchronization performance monitoring, which can be
      called on demand if the requested timing performance is not met.



4. Security Considerations

   It will be considered in a future revision.



5. IANA Considerations

   There are no IANA actions required by this document.



6. References

6.1. Normative References

   [IEEE-1588]IEEE 1588, Precision Clock Synchronization Protocol for
             Networked Measurement and Control Systems, 2008



6.2. Informative References

   [G.8261] ITU-T, Timing and synchronization aspects in packet networks,
             August, 2013

   [G.8275] ITU-T, Architecture and requirements for packet-based time
             and phase distribution, November, 2013



Han and et al          Expires April 20, 2016                 [Page 8]


Internet-Draft                  PS in SSN                 October 2015


   [ptp-mib] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G.,
             Precision Time Protocol Version 2 (PTPv2) Management
             Information Base, draft-ietf-tictoc-ptp-mib-06, work in
             progress



7. Acknowledgments

   TBD




   Authors' Addresses

   Liuyan Han
   China Mobile
   Xuanwumenxi Ave, Xuanwu District
   Beijing 100053, China
   Email: hanliuyan@chinamobile.com

   Yuanlong Jiang
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129, China
   Email: jiangyuanlong@huawei.com

   Jinchun Xu
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129, China
   Email: xujinchun@huawei.com

   Xian Liu
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129, China
   Email: lene.liuxian@huawei.com










Han and et al          Expires April 20, 2016                 [Page 9]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/