CCAMP WG J. Ahlberg
Internet-Draft Ericsson AB
Intended status: Informational LM. Contreras
Expires: January 9, 2017 TID
A. Ye Min
Huawei
M. Vaupotic
Aviat Networks
J. Tantsura
Individual
K. Kawada
NEC Corporation
X. Li
NEC Laboratories Europe
I. Akiyoshi
NEC
July 8, 2016
A framework for Management and Control of microwave and millimeter wave
interface parameters - problem statement
draft-mwdt-ccamp-problem-statement-00
Abstract
To ensure an efficient data transport, meeting the requirements
requested by today's transport services, the unification of control
and management of microwave and millimeter wave radio link interfaces
is a precondition for seamless multilayer networking and automated
network wide provisioning and operation.
This document describes the required characteristics and use cases
for control and management of radio link interface parameters using a
YANG Data Model. It focuses on the benefits of a standardized
management model that is aligned with how other packet technology
interfaces in a microwave/millimeter wave node are modeled, the need
to support core parameters and at the same time allow for optional
product/feature specific parameters supporting new, unique innovative
features until they have become mature enough to be included in the
standardized model.
The purpose is to create a framework for identification of the
necessary information elements and definition of a YANG Data Model
for control and management of the radio link interfaces in a
microwave/millimeter wave node.
Ahlberg, et al. Expires January 9, 2017 [Page 1]
Internet-Draft Problem Statement July 2016
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 9, 2017.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
4. Application . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Network Management Solutions . . . . . . . . . . . . . . 7
4.2. Software Defined Networking . . . . . . . . . . . . . . . 7
4.2.1. SDN example of radio link configuration . . . . . . . 7
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Configuration Management . . . . . . . . . . . . . . . . 9
5.1.1. Understand the capabilities and limitations . . . . . 10
5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10
5.1.3. Radio link re-configuration and optimization . . . . 10
5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Retrieve logical inventory and configuration from
Ahlberg, et al. Expires January 9, 2017 [Page 2]
Internet-Draft Problem Statement July 2016
device . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Retrieve logical inventory and configuration from
device . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Status and statistics . . . . . . . . . . . . . . . . . . 10
5.3.1. Actual status and performance of a radio link
interface . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Performance management . . . . . . . . . . . . . . . . . 11
5.4.1. Configuration of historical measurements to be
performed . . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Collection of historical performance data . . . . . . 11
5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11
5.5.1. Configuration of alarm reporting . . . . . . . . . . 11
5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11
5.5.3. Troubleshooting and Root Cause Analysis . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Network requirements vary between operators globally as well as
within individual countries. The overall goal is however the same -
to deliver the best possible network performance and quality of
experience in a cost-efficient way.
Microwave/millimeter wave (hereafter referred to as microwave, but
including the frequency bands represented by millimeter wave) are
important technologies to fulfill this goal today, but also in the
future when demands on capacity and packet features increases.
Microwave is already today able to fully support the capacity needs
of a backhaul in a radio access network and will evolve to support
multiple gigabits in traditional frequency bands and beyond 10
gigabit in the millimeter wave. L2 packet features are normally an
integrated part of microwave nodes and more advanced L2 and L3
features will over time be introduced to support the evolution of the
transport services to be provided by a backhaul/transport network.
The main application for microwave is backhaul for mobile broadband.
Those networks will continue to be modernized using a combination of
microwave and fiber technologies. The choice of technology is a
question about fiber presence and cost of ownership, not about
capacity limitations in microwave. In 2020, more than 65% of all
cell sites are expected to be connected with microwave solutions.
Ahlberg, et al. Expires January 9, 2017 [Page 3]
Internet-Draft Problem Statement July 2016
Open and standardized interfaces are a pre-requisite for efficient
management of equipment from multiple vendors. This framework
addresses management and control of the radio link interface(s) and
the relationship to other packet interfaces, typically to Ethernet
interfaces, in a microwave node. A radio link provides the transport
over the air, using one or several carriers in aggregated or
protected configurations. Managing and controlling a transport
service over a microwave node involves both radio link and packet
functionality.
Already today there are numerous IETF data models, RFCs and drafts,
with technology specific extensions that cover a large part of the
packet domain. Examples are IP Management [RFC7277], Routing
Management [I-D.ietf-netmod-routing-cfg] and Provider Bridge [PB-
YANG]. They are based on RFC 7223 [RFC7223], which is the IETF YANG
model for Interface Management, and is an evolution of the SNMP IF-
MIB [RFC 2863].
Since microwave nodes will contain more and more packet functionality
and the interfaces for those technologies are expected to be managed
using those models, there are advantages if radio link interfaces can
be modeled and be managed using the same structure and the same
approach, specifically for use cases in which a microwave node are
managed as one common entity including both the radio link and the
packet functionality, e.g. at installation, initial setup, trouble
shooting, upgrade and maintenance. All interfaces in a node,
irrespective of technology, would then be accessed from the same core
model, i.e. RFC 7223, and could be extended with technology specific
parameters in models augmenting that core model. The relationship/
connectivity between interfaces would be given by the equipment
configuration and slot positions or be configured via management
systems or controllers.
Ahlberg, et al. Expires January 9, 2017 [Page 4]
Internet-Draft Problem Statement July 2016
+------------------------------------------------------------------+
| Interface [RFC7223] |
| +------------------+ |
| |Ethernet Port | |
| +------------------+ |
| \ |
| +-----------------------+ |
| |Radio link terminal | |
| +-----------------------+ |
| \ |
| +------------------------+ |
| |Carrier termination | |
| +------------------------+ |
+------------------------------------------------------------------+
Figure 1: Relationship between interfaces in a node
There will always be certain implementations that differ among
products and it is therefore practically impossible to achieve
industry consensus on every design detail. It is therefore important
to focus on the parameters that are required to support the use cases
applicable for centralized, unified, multi-vendor management and to
allow other parameters to be optional or to be covered by extensions
to the standardized model. Furthermore, a standard that allows for a
certain degree of freedom encourages innovation and competition which
is something that benefits the entire industry. It is therefore
important that a radio link management model covers all relevant
functions but also leaves room for product/feature-specific
parameters.
For microwave radio link functionality work has been initiated (ONF:
Microwave Modeling [ONF-model], IETF: Radio Link Model [I-D.ahlberg-
ccamp-microwave-radio-link]). This effort is expected to take these
initiatives into consideration and complement them on the gaps
identified with the ambition to reach consensus within the industry
around one common approach.
2. 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 [RFC2119].
3. Terminology and Definitions
Software Defined Networking (SDN) is an emerging architecture that
decouples the network control and forwarding functions enabling the
network control to become directly programmable and the underlying
Ahlberg, et al. Expires January 9, 2017 [Page 5]
Internet-Draft Problem Statement July 2016
infrastructure to be abstracted for applications and network
services. This results in an extremely dynamic, manageable, cost-
effective, and adaptable architecture that gives administrators
unprecedented programmability, automation, and control. The SDN
concept is widely applied for network management, the adoption of SDN
framework to manage and control the microwave and millimeter wave
interface is one of the key applications of this work.
Microwave is a band of spectrum with wavelengths ranging from 1 meter
to 1 millimeter and with frequencies ranging between 300 MHz and 300
GHz. Microwave radio technology is widely used for point-to-point
telecommunications because of their small wavelength that allows
conveniently-sized antennas to direct them in narrow beams, and their
comparatively higher frequencies that allows broad bandwidth and high
data transmission rates.
Millimeter wave is also known as extremely high frequency (EHF) or
very high frequency (VHF) by the International Telecommunications
Union (ITU), which can be used for high-speed wireless broadband
communications. Millimeter wave is an undeveloped band of spectrum
that can be used for a broad range of services on mobile and wireless
networks including high-speed, point-to-point wireless local area
networks (WLANs) and broadband access. This band has short
wavelengths that range from 10 millimeters to 1 millimeter, namely
millimeter band or millimeter wave. The 71 - 76 GHz, 81 - 86 GHz and
92-95 GHz bands are used for point-to-point high-bandwidth
communication links, which allows for higher data rates up to 10
Gbit/s but requires a license. Unlicensed short-range data links can
be used on 60 GHz millimeter wave. For instance, the upcoming IEEE
Wi-Fi standard 802.11ad will run on the 60 GHz spectrum with data
transfer rates of up to 7 Gbit/s.
Carrier Termination is an interface for the capacity provided over
the air by a single carrier. It is typically defined by its
transmitting and receiving frequencies.
Radio Link Terminal is an interface providing packet capacity and/or
TDM capacity to the associated Ethernet and/or TDM interfaces in a
node and used for the capacity required for setting up a transport
service over a microwave/millimeter wave link.
4. Application
This framework addresses the definition of an open and standardized
interface for the radio link functionality in a microwave/millimeter
wave node. The application of such an interface used for management
and control of nodes and networks typically vary from one operator to
Ahlberg, et al. Expires January 9, 2017 [Page 6]
Internet-Draft Problem Statement July 2016
another, in terms of the systems used, what they are called and how
they interact.
4.1. Network Management Solutions
The classic network management solutions, with vendor specific domain
management combined with cross domain functionality for service
management and analytics, still dominates the market.
These solutions are expected to evolve and benefit from an increased
focus on standardization by simplifying multi-vendor management,
remove the need for vendor/domain specific management, and enabling
use of open source systems.
4.2. Software Defined Networking
SDN is another application emerging on the market. The main drivers
for SDN introduction from an operator perspective is simplification
and automation of network provisioning as well as E2E network
services. The vision is to have a global view of the network
conditions spanning across different vendors' equipment and multiple
technologies. A variety of different SDN architectures and functions
are being discussed and proposed within the industry, but they all
have in common a very clear relationship to network management. In
some proposals the SDN controller completely replaces the role of a
network management system while in some cases the SDN controller is
seen as an entity managed by the NMS. In any case the SDN functions
shall be seen as part of an overall NMS strategy, no matter how the
functionality is partitioned across units and no matter what
terminology is used.
If nodes from different vendors shall be managed by the same SDN
functions, without the extra effort of introducing mediation layers,
all nodes must align their interfaces. Hence, open and standardized
node interfaces are closely associated with the introduction of SDN.
4.2.1. SDN example of radio link configuration
Radio link terminals comprising a group of carriers are widely used
in microwave technology. There are several kinds of groups:
aggregation/bonding, 1+1 protection/redundancy, etc. To avoid
configuration on each carrier termination, a logical control provides
flexible management without configuring parameters on each carrier
termination directly. An operator using SDN manages radio links by
selecting an allowed operation mode. Alternatively, an operator can
prefer the complete configuration of all the parameters of interest.
Such case is not described in the document for simplicity). The
operation mode is a set of logical metrics or parameters describing a
Ahlberg, et al. Expires January 9, 2017 [Page 7]
Internet-Draft Problem Statement July 2016
complete radio link configuration, such as capacity, availability,
priority and power consumption.
+------+ +-----+ +-----+ +-------+
| |-------| CT1 | ~~~~~~~~~~~ | CT1 |-------| |
| | +-----+ +-----+ | |
| RLT1 | | RLT2 |
| | +-----+ +-----+ | |
| |-------| CT2 | ~~~~~~~~~~~ | CT2 |-------| |
+------+ +-----+ +-----+ +-------+
Figure 2: Radio link example
Example of an operation mode table is shown Table 1. One mode (ID =
1) provides high capacity but requires high power consumption;
another mode (ID = 2) provides low power consumption but low
capacity. SDN controller selects one of the operation modes
dynamically, according to the actual capacity need.
+------+--------------+-----------+--------------+----------+-------+
| ID | Description | Capacity | Availability | Priority | Power |
+------+--------------+-----------+--------------+----------+-------+
| 1 | High capacity| 400 | 99.9% | Low | High |
+------+--------------+-----------+--------------+----------+-------+
| 2 | High avail- | 100 | 99.999% | High | Low |
| | ability | | | | |
+------+--------------+-----------+--------------+----------+-------+
Figure 3: Example of an operation mode table
The procedure of logical control is as following:
1/ SDN controller gets the supported operation modes by reporting
from the node NE or by other means, e.g., NMS.
2/ According to its operation policy, SDN controller selects one
operation mode from the table and translates that into the required
configuration of the individual parameters for the radio link
terminals and the associated carrier terminations.
The operation mode could be selected based on power consumption.
Nowadays, more and more operators have strong requirement to decrease
the node power consumption. The SDN controller can monitor the real
time traffic distribution, and generated corresponding policy: to set
the operation mode to high capacity on the radio links with heavy
Ahlberg, et al. Expires January 9, 2017 [Page 8]
Internet-Draft Problem Statement July 2016
traffic load; to set the operation mode to low power consumption on
the radio links with light traffic load
Radio link aggregation/bonding is widely used in microwave: multiple
carriers are used to carry the traffic in cases where the needed
capacity is beyond the capability of single carriers. During night
time, the actual traffic load may be 1/3 of the peak day time. The
operation mode of low power consumption could be set to turn off some
of the radios within the group to save power consumption.
The operation mode could also be configured based on traffic
priority.
For high priority traffic, it is necessary to assure high
availability. On the other hand, low priority traffic is often high
volume and requires high capacity. The SDN controller can generate
corresponding policy based on the priority of traffic: to set the
operation mode to high availability on the radio links with high
priority traffic; to set the operation mode to high capacity on the
radio links with low priority traffic.
Radio protection/redundancy like a 1+1 Hot Standby is used to
increase overall availability of links between nodes while radio link
aggregation is used to achieve higher capacity. If traffic is
predominately TDM traffic, high availability is required on radio
links. In this case, SDN controller set operation mode as high
availability. On the other hand, if traffic is packet traffic, e.g.,
LTE traffic, capacity is more of a concern. In this case, SDN
controller set the operation mode as high capacity.
5. Use cases
The use cases described should be the basis for identification and
definition of the parameters to be supported by a YANG Data model for
management of radio links, applicable for centralized, unified,
multi-vendor management.
Use cases addressing installation, on-site trouble shooting, fault
resolution and other activities not performed from a centralized
system and which in most cases are product specific are outside the
scope of this framework.
5.1. Configuration Management
Configuration of a radio link terminal, the constituent carrier
terminations and when applicable the relationship to packet/Ethernet
interfaces.
Ahlberg, et al. Expires January 9, 2017 [Page 9]
Internet-Draft Problem Statement July 2016
5.1.1. Understand the capabilities and limitations
Exchange of information between a manager and a device about the
capabilities supported and specific limitations in the parameter
values and enumerations that can be used.
Support for the XPIC feature or not and the maximum modulation
supported are two examples on information that could be exchanged.
5.1.2. Initial Configuration
Initial configuration of a radio link terminal, enough to establish
L1 connectivity over the hop to an associated radio link terminal on
a device at far end. It MAY also include configuration of the
relationship to a packet/Ethernet interface, unless that is given by
the equipment configuration.
Frequency, modulation, coding and output power are examples of
parameters typically configured for a carrier termination and type of
aggregation/bonding or protection configurations expected for a radio
link terminal.
5.1.3. Radio link re-configuration and optimization
Re-configuration, update or optimization of an existing radio link
terminal. Output power and modulation for a carrier termination and
protection schemas and activation/de-activation of carriers in a
radio link terminal are examples on parameters that can be re-
configured and used for optimization of the performance of a network.
5.2. Inventory
5.2.1. Retrieve logical inventory and configuration from device
Request from manager and response by device with information about
radio interfaces, their constitution and configuration.
5.2.2. Retrieve logical inventory and configuration from device
Request from manager about physical and/or equipment inventory
associated with the radio link terminals and carrier terminations
5.3. Status and statistics
Ahlberg, et al. Expires January 9, 2017 [Page 10]
Internet-Draft Problem Statement July 2016
5.3.1. Actual status and performance of a radio link interface
Manager requests and device responds with information about actual
status and statistics of configured radio link interfaces and their
constituent parts.
5.4. Performance management
5.4.1. Configuration of historical measurements to be performed
Configuration of historical measurements to be performed on a radio
link interface and/or its constituent parts is a subset of the
configuration use case to be supported. See 5.1 above.
5.4.2. Collection of historical performance data
Collection of historical performance data in bulk by the manager is a
general use case for a device and not specific to a radio link
interface.
Collection of an individual counter for a specific interval is in
same cases required as a complement to the retrieval in bulk as
described above.
5.5. Fault Management
5.5.1. Configuration of alarm reporting
Configuration of alarm reporting associated specifically with radio
interfaces, e.g. configuration of alarm severity, is a subset of the
configuration use case to be supported. See 5.1 above.
5.5.2. Alarm management
Alarm synchronization, visualization and handling, and notifications
and events are generic use cases for a device and not specific to a
radio link interface an should be supported accordingly.
5.5.3. Troubleshooting and Root Cause Analysis
Information and actions required by a manager/operator to investigate
and understand the underlying issue to a problem in the performance
and/or functionality of a radio link terminal and the associated
carrier terminations.
Ahlberg, et al. Expires January 9, 2017 [Page 11]
Internet-Draft Problem Statement July 2016
6. Requirements
This is a placeholder for a separate chapter about requirements.
7. Security Considerations
TBD.
8. IANA Considerations
N/A.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <http://www.rfc-editor.org/info/rfc2234>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<http://www.rfc-editor.org/info/rfc2863>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
9.2. Informative References
[I-D.ahlberg-ccamp-microwave-radio-link]
Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M.,
and M. Vaupotic, "Microwave Radio Link YANG Data Models",
draft-ahlberg-ccamp-microwave-radio-link-01 (work in
progress), May 2016.
[I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-22 (work in
progress), July 2016.
Ahlberg, et al. Expires January 9, 2017 [Page 12]
Internet-Draft Problem Statement July 2016
[ONF-model]
"Microwave Modeling - ONF Wireless Transport Group", May
2016.
[PB-YANG] "IEEE 802.1X and 802.1Q YANG models, Marc,H.", October
2015.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>.
Authors' Addresses
Jonas Ahlberg
Ericsson AB
Lindholmspiren 11
Goeteborg 417 56
Sweden
Email: jonas.ahlberg@ericsson.com
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, S/N
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Ye Min (Amy)
Huawei Technologies CO., Ltd
No.1899, Xiyuan Avenue
Chengdu 611731
P.R.China
Email: amy.yemin@huawei.com
Marko Vaupotic
Aviat Networks
Motnica 9
Trzin-Ljubljana 1236
Slovenia
Email: Marko.Vaupotic@aviatnet.com
Ahlberg, et al. Expires January 9, 2017 [Page 13]
Internet-Draft Problem Statement July 2016
Jeff Tantsura
Individual
Email: jefftant.ietf@gmail.com
Koji Kawada
NEC Corporation
1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan
Email: k-kawada@ah.jp.nec.com
Xi Li
NEC Laboratories Europe
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Email: Xi.Li@neclab.eu
Ippei Akiyoshi
NEC
1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan
Email: i-akiyoshi@ah.jp.nec.com
Ahlberg, et al. Expires January 9, 2017 [Page 14]