CCAMP WG J. Ahlberg
Internet-Draft Ericsson AB
Intended status: Informational LM. Contreras
Expires: April 28, 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
CJ. Bernardos
UC3M
October 28, 2016
A framework for Management and Control of microwave and
millimeter wave interface parameters
draft-mwdt-ccamp-fmwk-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 April 28, 2017 [Page 1]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 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 April 27, 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.
Ahlberg, et al. Expires April 28, 2017 [Page 2]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
Table of Contents
1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions used in this document . . . . . . . . . . . . . . 7
4. Approaches to manage and control radio link interfaces . . . 8
4.1. Network Management Solutions . . . . . . . . . . . . . . 8
4.2. Software Defined Networking . . . . . . . . . . . . . . . 8
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Configuration Management . . . . . . . . . . . . . . . . 9
5.1.1. Understand the capabilities & limitations . . . . . . 10
5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10
5.1.3. Radio link re-configuration & optimization . . . . . 10
5.1.4. Radio link logical configuration . . . . . . . . . . 10
5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Retrieve logical inventory & configuration from device 10
5.2.2. Retrieve physical/equipment inventory from device . . 11
5.3. Status & statistics . . . . . . . . . . . . . . . . . . . 11
5.3.1. Actual status & 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.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13
7.1. Microwave Radio Link Functionality . . . . . . . . . . . 13
7.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14
7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Ahlberg, et al. Expires April 28, 2017 [Page 3]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
1. Terminology and Definitions
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 can be used for a broad range of
fixed and mobile services 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 setting up a transport service over a
microwave/millimeter wave link.
Figure 1 provides a graphical representation of Carrier Termination
and Radio Link Terminal concepts.
Ahlberg, et al. Expires April 28, 2017 [Page 4]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
/--------- Radio Link ---------\
Near End Far End
+---------------+ +---------------+
| Radio Link | | Radio Link |
| Terminal | | Terminal |
| | | |
| (Protected or Bonded) |
| | | |
| +-----------+ | | +-----------+ |
| | | | Carrier A | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
Packet--| | | | | | | |--Packet
| +-----------+ | | +-----------+ |
TDM----| | | |----TDM
| +-----------+ | | +-----------+ |
| | | | Carrier B | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
| | | | | | | |
| +-----------+ | | +-----------+ |
| | | |
+---------------+ +---------------+
\--- Microwave Node ---/ \--- Microwave Node ---/
Figure 1. Radio Link Terminal and Carrier Termination
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
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.
2. 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.
Ahlberg, et al. Expires April 28, 2017 [Page 5]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
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
gigabits in the millimeter wave. L2 packet features are normally an
integrated part of microwave nodes and more advanced L2 & L3
features will over time be introduced to support the evolution of
the transport services to be provided by a backhaul/transport
network. Note that the wireless access technologies such as 3/4/5G &
WiFi are not within the scope of this microwave model work.
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.
Open and standardized interfaces are a pre-requisite for efficient
management of equipment from multiple vendors, integrated in a
single system/controller. 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 [RFC2863].
Since microwave nodes will contain more and more packet
functionality which is 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 basic configuration of node & connections, centralized
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 could be given by the
physical equipment configuration, e.g the slot in which the Radio
Link Terminal (modem) is plugged in could be associated with a
specific Ethernet port due to the wiring in the backplane of the
system, or it could be flexible and therefore configured via a
management system or controller.
Ahlberg, et al. Expires April 28, 2017 [Page 6]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
+------------------------------------------------------------------+
| Interface [RFC7223] |
| +------------------+ |
| |Ethernet Port | |
| +------------------+ |
| \ |
| +-----------------------+ |
| |Radio Link Terminal | |
| +-----------------------+ |
| \ |
| +------------------------+ |
| |Carrier Termination | |
| +------------------------+ |
+------------------------------------------------------------------+
Figure 2: 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
extensions.
For microwave radio link functionality work has been initiated (ONF:
Microwave Modeling [ONF-model], IETF: Radio Link Model [I-
D.ahlbergccamp-microwave-radio-link]. The purpose of this effort is
to reach consensus within the industry around one common approach,
with respect to the use cases and requirements to be supported, the
type and structure of the model and the resulting attributes to be
included. This document describes the use cases and requirements
agreed to be covered, the expected characteristics of the model and
at the end includes an analysis of how the models in the two on-
going initiatives fulfill these expectations and a recommendation on
what can be reused and what gaps need to be filled by a new and
evolved radio link model.
3. 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 RFC 2119 [RFC2119].
Ahlberg, et al. Expires April 28, 2017 [Page 7]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
While [RFC2119] describes interpretations of these key words in
terms of protocol specifications and implementations, they are used
in this document to describe requirements for the YANG Data Model
for Microwave Radio Link.
4. Approaches to manage and control radio link interfaces
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 another, in terms of the systems used and how they interact. A
traditional solution is network management system, while an emerging
one is SDN. SDN solutions can be used as part of the network
management system, allowing for direct network programmability and
automated configurability by means of a centralized SDN control and
defining standardized interfaces to program the nodes.
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 and
remove the need for vendor/domain specific management.
4.2. Software Defined Networking
One of the main drivers for applying SDN from an operator
perspective is simplification and automation of network provisioning
as well as E2E network service management. The vision is to have a
global view of the network conditions spanning across different
vendors? equipment and multiple technologies.
If nodes from different vendors shall be managed by the same SDN
controller via a node management interface (north bound interface,
NBI), without the extra effort of introducing intermediate systems,
all nodes must align their node management interfaces. Hence, an
open and standardized node management interface are required in a
multi-vendor environment. Such standardized interface enables a
unified management and configuration of nodes from different vendors
by a common set of applications.
On top of SDN applications to configure, manage and control the
nodes and their associated transport interfaces including the L2 and
L3 packet/Ethernet interfaces as well as the radio interfaces, there
are also a large variety of other more advanced SDN applications
that can be exploited and/or developed.
Ahlberg, et al. Expires April 28, 2017 [Page 8]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
A potential flexible approach for the operators is to use SDN in a
logical control way to manage the radio links by selecting a
predefined operation mode. The operation mode is a set of logical
metrics or parameters describing a complete radio link
configuration, such as capacity, availability, priority and power
consumption.
An example of an operation mode table is shown in Figure 3. Based on
its operation policy (e.g., power consumption or traffic priority),
the SDN controller selects one operation mode and translates that
into the required configuration of the individual parameters for the
radio link terminals and the associated carrier terminations.
+----+---------------+------------+-------------+-----------+------+
| ID |Description | Capacity |Availability | Priority |Power |
+----+---------------+------------+-------------+-----------+------+
| 1 |High capacity | 400 Mbps | 99.9% | Low |High |
+----+---------------+------------+-------------+-----------+------+
| 2 |High avail- | 100 Mbps | 99.999% | High |Low |
| | ability | | | | |
+----+---------------+------------+-------------+-----------+------+
Figure 3. Example of an operation mode table
An operation mode bundles together the values of a set of different
parameters. How each operation mode maps into certain set of
attributes is out of scope of this document. Effort on a
standardizing operation mode is required to implement a smoothly
operator environment.
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.
Other product specific use cases, addressing e.g. installation, on-
site trouble shooting and fault resolution, are outside the scope of
this framework. If required, these use cases are expected to be
supported by product specific extensions to the standardized model.
5.1. Configuration Management
Configuration of a radio link terminal, the constituent carrier
terminations and when applicable the relationship to packet/Ethernet
and TDM interfaces.
Ahlberg, et al. Expires April 28, 2017 [Page 9]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
5.1.1. Understand the capabilities & limitations
Exchange of information between a manager and a device about the
capabilities supported and specific limitations in the parameter
values & enumerations that can be used.
Support for the XPIC (Cross Polarization Interference Cancellation)
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 between a radio link terminal and an associated traffic
interface, e.g. an 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 & 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.1.4. Radio link logical 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 directly, a logical
control provides flexible management by mapping a logical
configuration to a set of physical attributes. This could also be
applied in a hierarchical SDN environment where some domain
controllers are located between the SDN controller and the radio
link terminal.
5.2. Inventory
5.2.1. Retrieve logical inventory & configuration from device
Request from manager and response by device with information about
radio interfaces, their constitution and configuration.
Ahlberg, et al. Expires April 28, 2017 [Page 10]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
5.2.2. Retrieve physical/equipment inventory from device
Request from manager about physical and/or equipment inventory
associated with the radio link terminals and carrier terminations.
5.3. Status & statistics
5.3.1. Actual status & 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 & handling, and notifications &
events are generic use cases for a device and not specific to a
radio link interface and should be supported accordingly.
5.6. 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 April 28, 2017 [Page 11]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
6. Requirements
For managing a microwave node including both the radio link and the
packet functionality, a unified data model is desired to unify the
modeling of the radio link interfaces and the packet interfaces
using the same structure and the same modelling approach.
The purpose of the YANG Data Model is for management and control of
the radio link interface(s) and the relationship/connectivity to
other packet interfaces, typically to Ethernet interfaces, in a
microwave node.
The capability of configuring and managing microwave nodes includes
the following requirements for the modelling:
1) It MUST be possible to configure, manage and control a radio link
terminal and the constituent carrier terminations.
a) Frequency, channel bandwidth, modulation, coding and
transmitter power are examples of parameters typically
configured for a carrier termination.
b) A radio link terminal MUST configure the associated carrier
terminations and the type of aggregation/bonding or protection
configurations expected for the radio link terminal.
c) The capability, e.g. the maximum modulation supported, and the
actual status/statistics, e.g. administrative status of the
carriers, SHOULD also be supported by the data model.
2) It MUST be possible to map different traffic types (e.g. TDM,
Ethernet) to the transport capacity provided by a specific radio
link terminal.
3) It MUST be possible to configure and collect historical
measurements (for the use case described in section 5.4) to be
performed on a radio link interface, e.g. minimum, maximum and
average transmit power and receive level in dBm.
4) It MUST be possible to configure and retrieve alarms reporting
associated with the radio interfaces, e.g. configuration of alarm
severity, supported alarms like configuration fault, signal lost,
modem fault, radio fault.
Ahlberg, et al. Expires April 28, 2017 [Page 12]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
7. Gap Analysis on Models
The purpose of the gap analysis is to identify and recommend what
existing and established models as well as draft models under
definition to support the use cases and requirements specified in
the previous chapters. It shall also make a recommendation on how
the gaps not supported should be filled, including the need for
development of new models and evolution of existing models and
drafts.
For microwave radio link functionality work has been initiated (ONF:
Microwave Modeling [ONF-model], IETF: Radio Link Model [I-
D.ahlbergccamp-microwave-radio-link]. The analysis is expected to
take these initiatives into consideration and make a recommendation
on how to make use of them and how to complement them in order to
fill the gaps identified.
For generic functionality, not specific for radio link, the ambition
is to refer to existing or emerging models that could be applicable
for all functional areas in a microwave node.
7.1. Microwave Radio Link Functionality
[ONF CIM] defines a CoreModel of the ONF Common Information Model.
An information model describes the things in a domain in terms of
objects, their properties (represented as attributes), and their
relationships. The ONF information model is expressed in Unified
Modeling Language (UML). The ONF CoreModel is independent of
specific data plane technology. Data plane technology specific
properties are acquired in a runtime solution via "filled in" cases
of specification (LtpSpec etc). These can be used to augment the
CoreModel to provide a data plane technology specific representation.
IETF Data Model defines an implementation and NETCONF-specific
details. YANG is a data modeling language used to model the
configuration and state data. It is well aligned with the structure
of the Yang data models proposed for the different packet interfaces
which are all based on RFC 7223. Furthermore, several YANG data
models have been proposed in the IETF for other transport
technologies such as optical transport; e.g., RFC 7277 [RFC7277],
[I.D.zhang-ccamp-l1-topo-yang], [I.D.ietf-ospf-yang]. In light of
this trend, the IETF data model is becoming a popular approach for
modeling most packet transport technology interfaces and it is
thereby well positioned to become an industry standard.
Ahlberg, et al. Expires April 28, 2017 [Page 13]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
RFC 3444 [RFC3444] explains the difference between Information
Model(IM) and Data Models(DM). IM is to model managed objects at a
conceptual level for designers and operators, DM is defined at a
lower level and includes many details for implementers. In addition,
the protocol-specific details are usually included in DM. Since
conceptual models can be implemented in different ways, multiple DMs
can be derived from a single IM. To ensure better interoperability,
it is better to focus on DM directly.
RFC 7223 describes an interface management model, however it doesn?t
include technology specific information, e.g., for radio interface.
[I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal
for radio interfaces, which includes support for basic configuration,
status and performance but lacks full support for alarm management
and interface layering, i.e. the connectivity of the transported
capacity (TDM & Ethernet) with other internal technology specific
interfaces in a microwave node.
The recommendation is to use the structure of the IETF: Radio Link
Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point,
since it is a data model providing the wanted alignment with RFC
7223. For the definition of the detailed leafs/parameters, the
recommendation is to use the IETF: Radio Link Model and the ONF:
Microwave Modeling [ONF-model] as the basis and to define new ones
to cover identified gaps. The parameters in those models have been
defined by both operators and vendors within the industry and the
implementations of the ONF Model have been tested in the Proof of
Concept events in multi-vendor environments, showing the validity of
the approach proposed in this framework document.
It is also recommended to add the required data nodes to describe
the interface layering for the capacity provided by a radio link
terminal and the associated Ethernet and TDM interfaces in a
microwave node. The principles and data nodes for interface layering
described in RFC 7223 should be used as a basis.
7.2. Generic Functionality
For generic functionality, not specific for radio link, the
recommendation is to refer to existing RFCs or emerging drafts
according to the table in figure 4 below. New Radio Link Model is
used in the table for the cases where the functionality is
recommended to be included in the new radio link model as described
in chapter 7.1.
Ahlberg, et al. Expires April 28, 2017 [Page 14]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
+------------------------------------+-----------------------------+
| Generic Functionality | Recommendation |
| | |
+------------------------------------+-----------------------------+
|1.Fault Management | |
| | |
| Alarm Configuration | New Radio Link Model |
| | |
| Alarm notifications/ | [I-D.vallin-netmod- |
| synchronization | alarm-module] |
+------------------------------------+-----------------------------+
|2.Performance Management | |
| | |
| Performance Configuration/ | New Radio Link Model |
| Activation | |
| | |
| Performance Collection | New Radio Link Model & |
| | XML files |
+------------------------------------+-----------------------------+
|3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] |
+------------------------------------+-----------------------------+
Figure 4. Recommendation on how to support generic functionality
Microwave specific alarm configurations are recommended to be
included in the new radio link model and could be based on what is
supported in the IETF and ONF Radio Link Models. Alarm notifications
and synchronization are general and is recommended to be supported
by a generic model, such as [I-D.vallin-netmod-alarm-module].
Activation of interval counters & thresholds could be a generic
function but it is recommended to be supported by the new radio link
specific model and can be based on both the ONF and IETF Microwave
Radio Link models.
Collection of interval/historical counters is a generic function
that needs to be supported in a node. File based collection via SFTP
and collection via a Netconf/YANG interfaces are two possible
options and the recommendation is to include support for the latter
in the new radio link specific model. The ONF and IETF Microwave
Radio Link models can be used as a basis also in this area.
Physical and/or equipment inventory associated with the radio link
terminals and carrier terminations is recommended to be covered by a
model generic for the complete node, e.g. [I-D.ietf-netmod-entity]
and it is thereby outside the scope of the radio link specific
model.
Ahlberg, et al. Expires April 28, 2017 [Page 15]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
7.3. Summary
The conclusions and recommendations from the analysis can be
summarized as follows:
1) A Microwave Radio Link YANG Data Model should be defined with a
scope enough to support the use cases and requirements in
chapter 5 and 6 of this document.
2) Use the structure in the IETF: Radio Link Model [I-D.ahlberg-
ccamp-microwave-radio-link] as the starting point. It augments
RFC 7223 and is thereby as required aligned with the structure
of the models for management of the packet domain.
3) Use the IETF: Radio Link Model [I-D.ahlberg-ccamp-microwave-
radio-link] and the ONF: Microwave Modeling [ONF-model] as the
basis for the definition of the detailed leafs/parameters to
support the specified use cases and requirements, and proposing
new ones to cover identified gaps.
4) Add the required data nodes to describe the interface layering
for the capacity provided by a radio link terminal and the
associated Ethernet and TDM interfaces, using the principles
and data nodes for interface layering described in RFC 7223 as
a basis.
5) Include support for configuration of microwave specific alarms
in the Microwave Radio Link model and rely on a generic model
such as [I.D.vallin-netmod-alarm-module] for notifications and
alarm synchronization.
6) Use a generic model such as [I-D.ietf-netmod-entity] for
physical/equipment inventory.
It is furthermore recommended that the Microwave Radio Link YANG
Date Model should be validated by both operators and vendors as
part of the process to make it stable and mature.
8. Security Considerations
TBD
9. IANA Considerations
This memo includes no request to IANA.
Ahlberg, et al. Expires April 28, 2017 [Page 16]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
10. References
10.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>.
[RFC2863] McCloghrie K. and Kastenholz F., "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<http://www.rfc-editor.org/info/rfc2863>.
[RFC3444] Pras A., Schoenwaelder J., "On the Difference between
Information Models and Data Models", RFC 3444, DOI
10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[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>.
[RFC7277] Bjorklund M., "A YANG Data Model for IP Management", RFC
7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
10.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-entity]
Bierman A., Bjorklund M., Dong J., Romascanu D., "A YANG
Data Model for Entity Management", draft-ietf-netmod-
entity-00 (work in progress), May 2016.
[I-D.vallin-netmod-alarm-module]
Vallin S. and Bjorklund M., "YANG Alarm Module", draft-
vallin-netmod-alarm-module-00 (work in progress), October
2016.
[I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-24 (work in
progress), October 2016.
Ahlberg, et al. Expires April 28, 2017 [Page 17]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
[I.D.zhang-ccamp-l1-topo-yang]
Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model
for Layer 1 (ODU) Network Topology", draft-zhang-ccamp-l1-
topo-yang-03 (work in progress), July 2016.
[I.D.ietf-ospf-yang]
Yeung D., Qu Y., Zhang J., Bogdanovic D., Sreenivasa K.,
"Yang Data Model for OSPF Protocol", draft-ietf-ospf-yang-
05,(work in progress), July 2016.
[ONF-model]
"Microwave Modeling - ONF Wireless Transport Group", May
2016.
[ONF CIM]
"Core Information Model", ONF TR-512, ONF, September 2016
[PB-YANG] "IEEE 802.1X and 802.1Q YANG models, Marc,H.", October
2015.
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
Ahlberg, et al. Expires April 28, 2017 [Page 18]
Internet-Draft draft-mwdt-ccamp-fmwk-00 October 2016
Marko Vaupotic
Aviat Networks
Motnica 9
Trzin-Ljubljana 1236
Slovenia
Email: Marko.Vaupotic@aviatnet.com
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
69115 Heidelberg
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
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Ahlberg, et al. Expires April 28, 2017 [Page 19]