Internet DRAFT - draft-hjxl-scsn-ps
draft-hjxl-scsn-ps
Internet Working Group L. Han
Internet-Draft China Mobile
Intended status: Informational Y. Jiang
J. Xu
X. Liu
Huawei
D. P. Venmani
Orange Labs
Expires: September 2016 March 21, 2016
Problem Statements of Scalable Synchronization Networks
draft-hjxl-scsn-ps-00.txt
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
configure and 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.
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 September 21, 2016.
Han and et al Expires September 21, 2016 [Page 1]
Internet-Draft Problem Statement of SCSN March 2016
Copyright Notice
Copyright (c) 2016 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.
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 path configuration ..................... 4
2.2. Synchronization OAM .................................... 5
2.3. Synchronization network resiliency ..................... 6
2.4. Multi-layer/Multi-domain synchronization network ....... 6
3. Synchronization Requirements .............................. 7
4. Security Considerations ................................... 7
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.
Han and et al Expires September 21, 2016 [Page 2]
Internet-Draft Problem Statement of SCSN March 2016
One focus of the Deterministic Networking (DetNet) Working Group in
the IETF is to provide solutions for services with deterministic
properties of controlled latency, thus it requires high precision
time synchronization among all relay systems in a DetNet network.
For packet switching networks, SyncE and IEEE 1588-2008/PTPv2
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, 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 solutions in networks 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 nowadays).
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 resiliency for synchronization networks, so
that synchronization failure can be recovered (even provide
protection in the distribution layer, i.e., even when the working
path synchronization path is lost, the frequency source is still
available from the protection path).
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. a maximum of 20
hops) of time-distribution from the timing source to a cell site is
not exceeded.
Han and et al Expires September 21, 2016 [Page 3]
Internet-Draft Problem Statement of SCSN March 2016
This document provides some use cases and requirements on
configuration and management of a large synchronization network and
provides problem statements for the SCalable Synchronization Network
(SCSN).
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 SCSN from a management and operation
viewpoint.
2.1. Synchronization path 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 controller may be
introduced into the SCSN. 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
Han and et al Expires September 21, 2016 [Page 4]
Internet-Draft Problem Statement of SCSN March 2016
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.
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 with the current limited
information from the equipments, the operator may have to test the
synchronization performance manually by some external instruments.
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
Han and et al Expires September 21, 2016 [Page 5]
Internet-Draft Problem Statement of SCSN March 2016
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 fault alarm is raised. With synchronization
fault detection, an operator cannot locate the true reason of service
disruption. In that case, on-demand performance monitoring of a
synchronization path may provide the needed information for diagnosis
by monitoring the synchronization performance of all devices in the
synchronization path if a base station at the end of the path is 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 resiliency
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
resiliency of the synchronization network is very important.
In general, if allowed by the network topology, the equipment can 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 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 network can
restore from the fault by computation of another path with the help
of the controller.
2.4. Multi-layer/Multi-domain synchronization network
In general, to guarantee the time synchronization accuracy, the
suggested maximum hop from the frequency source to the end equipment
is 20 in the synchronization network. And the suggested maximum hop
from the time source to the end equipment is 30. The maximum values
may be defined differently for different operators in different
geographies.
Han and et al Expires September 21, 2016 [Page 6]
Internet-Draft Problem Statement of SCSN March 2016
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.
3. Synchronization Requirements
In order to facilitate the provision and management of a large
synchronization network, the following requirements need to be
addressed in the SCSN:
a)The synchronization network should support a generic, vendor-
independent and protocol-neutral data model for the
synchronization configuration to support heterogeneous networks;
b)The synchronization network should support computation and
configuration of frequency and time synchronization path;
c)The synchronization network should provide high reliability and
resiliency to protect and recover from failures in synchronization.
d)The synchronization network should provide high scalability, which
may require a network to be divided into multiple logical domains,
but still maintain a high precision timing signal along a long
synchronization path.
e)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.
Han and et al Expires September 21, 2016 [Page 7]
Internet-Draft Problem Statement of SCSN March 2016
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
[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
Han and et al Expires September 21, 2016 [Page 8]
Internet-Draft Problem Statement of SCSN March 2016
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
Daniel Philip Venmani
Orange Labs
2, avenue Pierre Marzin,
Lannion 22307, France
Email: danielphilip.venmani@orange.com
Han and et al Expires September 21, 2016 [Page 9]
