draft-ietf-ccamp-microwave-framework-04.txt   draft-ietf-ccamp-microwave-framework-05.txt 
CCAMP WG J. Ahlberg CCAMP Working Group J. Ahlberg, Ed.
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Informational LM. Contreras Intended status: Informational M. Ye, Ed.
Expires: June 11, 2018 TID Expires: July 9, 2018 Huawei Technologies
M.Ye
Huawei Technologies CO., Ltd
M. Vaupotic
Aviat Networks
J. Tantsura
Individual
K. Kawada
NEC Corporation
X. Li X. Li
NEC Laboratories Europe NEC Laboratories Europe
I. Akiyoshi LM. Contreras
NEC Telefonica I+D
CJ. Bernardos CJ. Bernardos
UC3M Universidad Carlos III de Madrid
D. Spreafico January 5, 2018
Nokia - IT
December 8, 2017
A framework for Management and Control of microwave and A framework for Management and Control of microwave and millimeter wave
millimeter wave interface parameters interface parameters
draft-ietf-ccamp-microwave-framework-04 draft-ietf-ccamp-microwave-framework-05
Abstract Abstract
To ensure an efficient data transport, meeting the requirements The unification of control and management of microwave radio link
requested by today's transport services, the unification of control interfaces is a precondition for seamless multilayer networking and
and management of microwave and millimeter wave radio link interfaces automated network provisioning and operation.
is a precondition for seamless multilayer networking and automated
network wide provisioning and operation.
This document describes the required characteristics and use cases This document describes the required characteristics and use cases
for control and management of radio link interface parameters using a for control and management of radio link interface parameters using a
YANG Data Model. It focuses on the benefits of a standardized YANG Data Model.
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 The purpose is to create a framework for identification of the
necessary information elements and definition of a YANG Data Model necessary information elements and definition of a YANG Data Model
for control and management of the radio link interfaces in a for control and management of the radio link interfaces in a
microwave/millimeter wave node. Some part of the resulting model MAY microwave node. Some parts of the resulting model may be generic
be generic which COULD also be used by other technology. which could also be used by other technologies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2018.
This Internet-Draft will expire on June 11, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 5
3. Conventions used in this document . . . . . . . . . . . . . . 7 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
4. Approaches to manage and control radio link interfaces . . . 8 3. Approaches to manage and control radio link interfaces . . . 7
4.1. Network Management Solutions . . . . . . . . . . . . . . 8 3.1. Network Management Solutions . . . . . . . . . . . . . . 8
4.2. Software Defined Networking . . . . . . . . . . . . . . . 8 3.2. Software Defined Networking . . . . . . . . . . . . . . . 8
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Configuration Management . . . . . . . . . . . . . . . . 9 4.1. Configuration Management . . . . . . . . . . . . . . . . 9
5.1.1. Understand the capabilities and limitations . . . . . 9 4.1.1. Understand the capabilities and limitations . . . . . 9
5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 4.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10
5.1.3. Radio link re-configuration and optimization . . . . 10 4.1.3. Radio link re-configuration and optimization . . . . 10
5.1.4. Radio link logical configuration . . . . . . . . . . 10 4.1.4. Radio link logical configuration . . . . . . . . . . 10
5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Retrieve logical inventory and configuration 4.2.1. Retrieve logical inventory and configuration from
from device . . . . . . . . . . . . . . . . . . . . . 10 device . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Retrieve physical/equipment inventory from device . . 10 4.2.2. Retrieve physical/equipment inventory from device . . 10
5.3. Status and statistics . . . . . . . . . . . . . . . . . . 11 4.3. Status and statistics . . . . . . . . . . . . . . . . . . 11
5.3.1. Actual status and performance of 4.3.1. Actual status and performance of a radio link
a radio link interface . . . . . . . . . . . . . . . 11 interface . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Performance management . . . . . . . . . . . . . . . . . 11 4.4. Performance management . . . . . . . . . . . . . . . . . 11
5.4.1. Configuration of historical measurements to be 4.4.1. Configuration of historical measurements to be
performed . . . . . . . . . . . . . . . . . . . . . . 11 performed . . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Collection of historical performance data . . . . . . 11 4.4.2. Collection of historical performance data . . . . . . 11
5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 4.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11
5.5.1. Configuration of alarm reporting . . . . . . . . . . 11 4.5.1. Configuration of alarm reporting . . . . . . . . . . 11
5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 4.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11
5.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 4.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 6. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13
7.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 6.1. Microwave Radio Link Functionality . . . . . . . . . . . 13
7.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14 6.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14
7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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.
ETSI EN 302 217 series defines the characteristics and requirements
of microwave/millimeter wave equipment and antennas. Especially ETSI
EN 302 217-2 specifies the essential parameters for the systems
operating from 1.4GHz to 86GHz.
Carrier Termination and Radio Link Terminal are two concepts defined
to support modeling of microwave radio link features and parameters
in a structured and yet simple manner.
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.
/--------- 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 1. Introduction
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 Microwave radio is a technology that uses high frequency radio waves
of a backhaul in a radio access network and will evolve to support to provide high speed wireless connections that can send and receive
multiple gigabits in traditional frequency bands and beyond 10 voice, video, and data information. It is a general term used for
gigabits in the millimeter wave. L2 packet features are normally an systems covering a very large range of traffic capacities, channel
integrated part of microwave nodes and more advanced L2 and L3 separations, modulation formats and applications over a wide range of
features will over time be introduced to support the evolution of frequency bands from 1 GHz up to and above 100 GHz.
the transport services to be provided by a backhaul/transport
network. Note that the wireless access technologies such as 3/4/5G
and WiFi are not within the scope of this microwave model work.
The main application for microwave is backhaul for mobile broadband. The main application for microwave is backhaul for mobile broadband.
Those networks will continue to be modernized using a combination of Those networks will continue to be modernized using a combination of
microwave and fiber technologies. The choice of technology is a microwave and fiber technologies. The choice of technology is a
question about fiber presence and cost of ownership, not about question about fiber presence and cost of ownership, not about
capacity limitations in microwave. capacity limitations in microwave.
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 higher frequency bands with more band width. 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. Note that the wireless access technologies such
as 3/4/5G and Wi-Fi are not within the scope of this microwave model
work.
Open and standardized interfaces are a pre-requisite for efficient Open and standardized interfaces are a pre-requisite for efficient
management of equipment from multiple vendors, integrated in a management of equipment from multiple vendors, integrated in a single
single system/controller. This framework addresses management and system/controller. This framework addresses management and control
control of the radio link interface(s) and the relationship to other of the radio link interface(s) and the relationship to other packet
packet interfaces, typically to Ethernet interfaces, in a microwave interfaces, typically to Ethernet interfaces, in a microwave node. A
node. A radio link provides the transport over the air, using one or radio link provides the transport over the air, using one or several
several carriers in aggregated or protected configurations. carriers in aggregated or protected configurations. Managing and
Managing and controlling a transport service over a microwave node controlling a transport service over a microwave node involves both
involves both radio link and packet functionality. radio link and packet functionality.
Already today there are numerous IETF data models, RFCs and drafts, Already today there are numerous IETF data models, RFCs and drafts,
with technology specific extensions that cover a large part of the with technology specific extensions that cover a large part of the
packet domain. Examples are IP Management [RFC7277], Routing packet domain. Examples are IP Management [RFC7277], Routing
Management [RFC8022] and Provider Bridge [PB-YANG] They are based Management [RFC8022] and Provider Bridge [PB-YANG]. They are based
on the IETF YANG model for Interface Management [RFC7223], which is on the IETF YANG model for Interface Management [RFC7223], which is
an evolution of the SNMP IF-MIB [RFC2863]. an evolution of the SNMP IF-MIB [RFC2863].
Since microwave nodes will contain more and more packet Since microwave nodes will contain more and more packet functionality
functionality which is expected to be managed using those models, which is expected to be managed using those models, there are
there are advantages if radio link interfaces can be modeled and be advantages if radio link interfaces can be modeled and be managed
managed using the same structure and the same approach, specifically using the same structure and the same approach, specifically for use
for use cases in which a microwave node are managed as one common cases in which a microwave node is managed as one common entity
entity including both the radio link and the packet functionality, including both the radio link and the packet functionality, e.g. at
e.g. at basic configuration of node and connections, centralized basic configuration of node and connections, centralized trouble
trouble shooting, upgrade and maintenance. All interfaces in a node, shooting, upgrade and maintenance. All interfaces in a node,
irrespective of technology, would then be accessed from the same irrespective of technology, would then be accessed from the same core
core model, i.e. [RFC7223], and could be extended with technology model, i.e. [RFC7223], and could be extended with technology specific
specific parameters in models augmenting that core model. The parameters in models augmenting that core model. The relationship/
relationship/connectivity between interfaces could be given by the connectivity between interfaces could be given by the physical
physical equipment configuration, e.g the slot in which the Radio equipment configuration, e.g. the slot in which the Radio Link
Link Terminal (modem) is plugged in could be associated with a Terminal (modem) is plugged in could be associated with a specific
specific Ethernet port due to the wiring in the backplane of the Ethernet port due to the wiring in the backplane of the system, or it
system, or it could be flexible and therefore configured via a could be flexible and therefore configured via a management system or
management system or controller. controller.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Interface [RFC7223] | | Interface [RFC7223] |
| +------------------+ | | +---------------+ |
| |Ethernet Port | | | | Ethernet Port | |
| +------------------+ | | +---------------+ |
| \ | | \ |
| +-----------------------+ | | +---------------------+ |
| |Radio Link Terminal | | | | Radio Link Terminal | |
| +-----------------------+ | | +---------------------+ |
| \ | | / \ |
| +------------------------+ | | +---------------------+ +---------------------+ |
| |Carrier Termination | | | | Carrier Termination | | Carrier Termination | |
| +------------------------+ | | +---------------------+ +---------------------+ |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Figure 2: Relationship between interfaces in a node Figure 1: Relationship between interfaces in a node
There will always be certain implementations that differ among There will always be certain implementations that differ among
products and it is therefore practically impossible to achieve products and it is therefore practically impossible to achieve
industry consensus on every design detail. It is therefore important industry consensus on every design detail. It is therefore important
to focus on the parameters that are required to support the use to focus on the parameters that are required to support the use cases
cases applicable for centralized, unified, multi-vendor management applicable for centralized, unified, multi-vendor management and to
and to allow other parameters to be optional or to be covered by allow other parameters to be optional or to be covered by extensions
extensions to the standardized model. Furthermore, a standard that to the standardized model. Furthermore, a standard that allows for a
allows for a certain degree of freedom encourages innovation and certain degree of freedom encourages innovation and competition which
competition which is something that benefits the entire industry. It is something that benefits the entire industry. It is therefore
is therefore important that a radio link management model covers all important that a radio link management model covers all relevant
relevant functions but also leaves room for product/feature-specific functions but also leaves room for product/feature-specific
extensions. extensions.
For microwave radio link functionality work has been initiated (ONF: For microwave radio link functionality work has been initiated (ONF:
Microwave Modeling [ONF-model], IETF: Radio Link Model [I- Microwave Modeling [ONF-model], IETF: Radio Link Model
D.ahlbergccamp-microwave-radio-link]). The purpose of this effort is [I-D.ahlberg-ccamp-microwave-radio-link]). The purpose of this
to reach consensus within the industry around one common approach, effort is to reach consensus within the industry around one common
with respect to the use cases and requirements to be supported, the approach, with respect to the use cases and requirements to be
type and structure of the model and the resulting attributes to be supported, the type and structure of the model and the resulting
included. This document describes the use cases and requirements attributes to be included. This document describes the use cases and
agreed to be covered, the expected characteristics of the model and requirements agreed to be covered, the expected characteristics of
at the end includes an analysis of how the models in the two on- the model and at the end includes an analysis of how the models in
going initiatives fulfill these expectations and a recommendation on the two on-going initiatives fulfill these expectations and a
what can be reused and what gaps need to be filled by a new and recommendation on what can be reused and what gaps need to be filled
evolved radio link model. by a new and evolved radio link model.
3. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
While [RFC2119] describes interpretations of these key words in While [RFC2119] describes interpretations of these key words in terms
terms of protocol specifications and implementations, they are used of protocol specifications and implementations, they are used in this
in this document to describe requirements for the YANG Data Model document to describe high level requirements to be met when defining
for Microwave Radio Link. the YANG Data Model for Microwave Radio Link.
4. Approaches to manage and control radio link interfaces This document does not define any protocol extension, hence only
RFC2119 can be considered as a normative reference. However, the
list of normative references includes a number of documents that can
be useful for a better understanding of the context.
2. Terminology and Definitions
Microwave radio is a term commonly used for technologies that operate
in both microwave and millimeter wave lengths and in frequency bands
from 1.4 GHz up to and beyond 100 GHz. In traditional bands it
typically supports capacities of 1-3 Gbps and in 70/80 GHz band up to
10 Gbps. Using multi-carrier systems operating in frequency bands
with wider channels, the technology will be capable of providing
capacities up 100 Gbps.
The microwave radio technology is widely used for point-to-point
telecommunications because of its small wavelength that allows
conveniently-sized antennas to direct them in narrow beams, and the
comparatively higher frequencies that allow broad bandwidth and high
data transmission rates. It is used for a broad range of fixed and
mobile services including high-speed, point-to-point wireless local
area networks (WLANs) and broadband access.
ETSI EN 302 217 series defines the characteristics and requirements
of microwave equipment and antennas. Especially ETSI EN 302 217-2
[EN302217-2] specifies the essential parameters for the systems
operating from 1.4GHz to 86GHz.
Carrier Termination and Radio Link Terminal are two concepts defined
to support modeling of microwave radio link features and parameters
in a structured and yet simple manner.
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
Time Division Multiplexing (TDM) capacity to the associated Ethernet
and/or TDM interfaces in a node and used for setting up a transport
service over a microwave radio link.
Figure 2 provides a graphical representation of Carrier Termination
and Radio Link Terminal concepts.
/--------- 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 2: Radio Link Terminal and Carrier Termination
Software Defined Networking (SDN) is an 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. SDN can be used as a term for automation of traditional
network management, which can be implemented using a similar
approach. The adoption of an SDN framework for management and
control the microwave interface is one of the key applications for
this work.
3. Approaches to manage and control radio link interfaces
This framework addresses the definition of an open and standardized This framework addresses the definition of an open and standardized
interface for the radio link functionality in a microwave/millimeter interface for the radio link functionality in a microwave node. The
wave node. The application of such an interface used for management application of such an interface used for management and control of
and control of nodes and networks typically vary from one operator nodes and networks typically vary from one operator to another, in
to another, in terms of the systems used and how they interact. A terms of the systems used and how they interact. A traditional
traditional solution is network management system, while an emerging solution is network management system, while an emerging one is SDN.
one is SDN. SDN solutions can be used as part of the network SDN solutions can be used as part of the network management system,
management system, allowing for direct network programmability and allowing for direct network programmability and automated
automated configurability by means of a centralized SDN control and configurability by means of a centralized SDN control and
defining standardized interfaces to program the nodes. standardized interfaces to program the nodes.
4.1. Network Management Solutions 3.1. Network Management Solutions
The classic network management solutions, with vendor specific The classic network management solutions, with vendor specific domain
domain management combined with cross domain functionality for management combined with cross domain functionality for service
service management and analytics, still dominates the market. management and analytics, still dominates the market. These
These solutions are expected to evolve and benefit from an increased solutions are expected to evolve and benefit from an increased focus
focus on standardization by simplifying multi-vendor management and on standardization by simplifying multi-vendor management and remove
remove the need for vendor/domain specific management. the need for vendor/domain specific management.
4.2. Software Defined Networking 3.2. Software Defined Networking
One of the main drivers for applying SDN from an operator One of the main drivers for applying SDN from an operator perspective
perspective is simplification and automation of network provisioning is simplification and automation of network provisioning as well as
as well as E2E network service management. The vision is to have a end to end network service management. The vision is to have a
global view of the network conditions spanning across different global view of the network conditions spanning across different
vendors' equipment and multiple technologies. vendors' equipment and multiple technologies.
If nodes from different vendors shall be managed by the same SDN If nodes from different vendors shall be managed by the same SDN
controller via a node management interface (north bound interface, controller via a node management interface (north bound interface,
NBI), without the extra effort of introducing intermediate systems, NBI), without the extra effort of introducing intermediate systems,
all nodes must align their node management interfaces. Hence, an all nodes must align their node management interfaces. Hence, an
open and standardized node management interface are required in a open and standardized node management interface are required in a
multi-vendor environment. Such standardized interface enables a multi-vendor environment. Such standardized interface enables a
unified management and configuration of nodes from different vendors unified management and configuration of nodes from different vendors
by a common set of applications. by a common set of applications.
On top of SDN applications to configure, manage and control the On top of SDN applications to configure, manage and control the nodes
nodes and their associated transport interfaces including the L2 and their associated transport interfaces including the L2 Ethernet
Ethernet and L3 packet interfaces as well as the radio interfaces, and L3 packet interfaces as well as the radio interfaces, there are
there are also a large variety of other more advanced SDN also a large variety of other more advanced SDN applications that can
applications that can be exploited and/or developed. be exploited and/or developed.
A potential flexible approach for the operators is to use SDN in a A potential flexible approach for the operators is to use SDN in a
logical control way to manage the radio links by selecting a logical control way to manage the radio links by selecting a
predefined operation mode. The operation mode is a set of logical predefined operation mode. The operation mode is a set of logical
metrics or parameters describing a complete radio link metrics or parameters describing a complete radio link configuration,
configuration, such as capacity, availability, priority and power such as capacity, availability, priority and power consumption.
consumption.
An example of an operation mode table is shown in Figure 3. Based on An example of an operation mode table is shown in Figure 3. Based on
its operation policy (e.g., power consumption or traffic priority), its operation policy (e.g., power consumption or traffic priority),
the SDN controller selects one operation mode and translates that the SDN controller selects one operation mode and translates that
into the required configuration of the individual parameters for the into the required configuration of the individual parameters for the
radio link terminals and the associated carrier terminations. radio link terminals and the associated carrier terminations.
+----+---------------+------------+-------------+-----------+------+ +----+---------------+------------+-------------+-----------+------+
| ID |Description | Capacity |Availability | Priority |Power | | ID |Description | Capacity |Availability | Priority |Power |
+----+---------------+------------+-------------+-----------+------+ +----+---------------+------------+-------------+-----------+------+
| 1 |High capacity | 400 Mbps | 99.9% | Low |High | | 1 |High capacity | 400 Mbps | 99.9% | Low |High |
+----+---------------+------------+-------------+-----------+------+ +----+---------------+------------+-------------+-----------+------+
| 2 |High avail- | 100 Mbps | 99.999% | High |Low | | 2 |High avail- | 100 Mbps | 99.999% | High |Low |
| | ability | | | | | | | ability | | | | |
+----+---------------+------------+-------------+-----------+------+ +----+---------------+------------+-------------+-----------+------+
Figure 3. Example of an operation mode table Figure 3: Example of an operation mode table
An operation mode bundles together the values of a set of different An operation mode bundles together the values of a set of different
parameters. How each operation mode maps into certain set of parameters. How each operation mode maps into certain set of
attributes is out of scope of this document. Effort on a attributes is out of scope of this document. Effort on a
standardizing operation mode is required to implement a smoothly standardizing operation mode is required to implement a smoothly
operator environment. operator environment.
5. Use Cases 4. Use Cases
The use cases described should be the basis for identification and The use cases described should be the basis for identification and
definition of the parameters to be supported by a YANG Data model definition of the parameters to be supported by a YANG Data model for
for management of radio links, applicable for centralized, unified, management of radio links, applicable for centralized, unified,
multi-vendor management. multi-vendor management.
Other product specific use cases, addressing e.g. installation, on- Other product specific use cases, addressing e.g. installation, on-
site trouble shooting and fault resolution, are outside the scope of site trouble shooting and fault resolution, are outside the scope of
this framework. If required, these use cases are expected to be this framework. If required, these use cases are expected to be
supported by product specific extensions to the standardized model. supported by product specific extensions to the standardized model.
5.1. Configuration Management 4.1. Configuration Management
Configuration of a radio link terminal, the constituent carrier Configuration of a radio link terminal, the constituent carrier
terminations and when applicable the relationship to packet/Ethernet terminations and when applicable the relationship to packet/Ethernet
and TDM interfaces. and TDM interfaces.
5.1.1. Understand the capabilities and limitations 4.1.1. Understand the capabilities and limitations
Exchange of information between a manager and a device about the Exchange of information between a manager and a device about the
capabilities supported and specific limitations in the parameter capabilities supported and specific limitations in the parameter
values and enumerations that can be used. values and enumerations that can be used.
Support for the XPIC (Cross Polarization Interference Cancellation) Support for the XPIC (Cross Polarization Interference Cancellation)
feature or not and the maximum modulation supported are two examples feature or not and the maximum modulation supported are two examples
on information that could be exchanged. on information that could be exchanged.
5.1.2. Initial Configuration 4.1.2. Initial Configuration
Initial configuration of a radio link terminal, enough to establish Initial configuration of a radio link terminal, enough to establish
L1 connectivity over the hop to an associated radio link terminal on L1 connectivity over the hop to an associated radio link terminal on
a device at far end. It MAY also include configuration of the a device at far end. It MAY also include configuration of the
relationship between a radio link terminal and an associated traffic relationship between a radio link terminal and an associated traffic
interface, e.g. an Ethernet interface, unless that is given by the interface, e.g. an Ethernet interface, unless that is given by the
equipment configuration. equipment configuration.
Frequency, modulation, coding and output power are examples of Frequency, modulation, coding and output power are examples of
parameters typically configured for a carrier termination and type parameters typically configured for a carrier termination and type of
of aggregation/bonding or protection configurations expected for a aggregation/bonding or protection configurations expected for a radio
radio link terminal. link terminal.
5.1.3. Radio link re-configuration and optimization 4.1.3. Radio link re-configuration and optimization
Re-configuration, update or optimization of an existing radio link Re-configuration, update or optimization of an existing radio link
terminal. Output power and modulation for a carrier termination and terminal. Output power and modulation for a carrier termination and
protection schemas and activation/de-activation of carriers in a protection schemas and activation/de-activation of carriers in a
radio link terminal are examples on parameters that can be re- radio link terminal are examples on parameters that can be re-
configured and used for optimization of the performance of a configured and used for optimization of the performance of a network.
network.
5.1.4. Radio link logical configuration 4.1.4. Radio link logical configuration
Radio link terminals comprising a group of carriers are widely used Radio link terminals comprising a group of carriers are widely used
in microwave technology. There are several kinds of groups: in microwave technology. There are several kinds of groups:
aggregation/bonding, 1+1 protection/redundancy, etc. To avoid aggregation/bonding, 1+1 protection/redundancy, etc. To avoid
configuration on each carrier termination directly, a logical configuration on each carrier termination directly, a logical control
control provides flexible management by mapping a logical provides flexible management by mapping a logical configuration to a
configuration to a set of physical attributes. This could also be set of physical attributes. This could also be applied in a
applied in a hierarchical SDN environment where some domain hierarchical SDN environment where some domain controllers are
controllers are located between the SDN controller and the radio located between the SDN controller and the radio link terminal.
link terminal.
5.2. Inventory 4.2. Inventory
5.2.1. Retrieve logical inventory and configuration from device 4.2.1. Retrieve logical inventory and configuration from device
Request from manager and response by device with information about Request from manager and response by device with information about
radio interfaces, their constitution and configuration. radio interfaces, their constitution and configuration.
5.2.2. Retrieve physical/equipment inventory from device 4.2.2. Retrieve physical/equipment inventory from device
Request from manager about physical and/or equipment inventory Request from manager about physical and/or equipment inventory
associated with the radio link terminals and carrier terminations. associated with the radio link terminals and carrier terminations.
5.3. Status and statistics 4.3. Status and statistics
5.3.1. Actual status and performance of a radio link interface 4.3.1. Actual status and performance of a radio link interface
Manager requests and device responds with information about actual Manager requests and device responds with information about actual
status and statistics of configured radio link interfaces and their status and statistics of configured radio link interfaces and their
constituent parts. constituent parts.
5.4. Performance management 4.4. Performance management
5.4.1. Configuration of historical measurements to be performed 4.4.1. Configuration of historical measurements to be performed
Configuration of historical measurements to be performed on a radio Configuration of historical measurements to be performed on a radio
link interface and/or its constituent parts is a subset of the link interface and/or its constituent parts is a subset of the
configuration use case to be supported. See 5.1 above. configuration use case to be supported. See Section 4.1 above.
5.4.2. Collection of historical performance data 4.4.2. Collection of historical performance data
Collection of historical performance data in bulk by the manager is Collection of historical performance data in bulk by the manager is a
a general use case for a device and not specific to a radio link general use case for a device and not specific to a radio link
interface. interface.
Collection of an individual counter for a specific interval is in Collection of an individual counter for a specific interval is in
same cases required as a complement to the retrieval in bulk as same cases required as a complement to the retrieval in bulk as
described above. described above.
5.5. Fault Management 4.5. Fault Management
5.5.1. Configuration of alarm reporting 4.5.1. Configuration of alarm reporting
Configuration of alarm reporting associated specifically with radio Configuration of alarm reporting associated specifically with radio
interfaces, e.g. configuration of alarm severity, is a subset of the interfaces, e.g. configuration of alarm severity, is a subset of the
configuration use case to be supported. See 5.1 above. configuration use case to be supported. See Section 4.1 above.
5.5.2. Alarm management 4.5.2. Alarm management
Alarm synchronization, visualization, handling, notifications and Alarm synchronization, visualization, handling, notifications and
events are generic use cases for a device and not specific to a events are generic use cases for a device and not specific to a radio
radio link interface and should be supported accordingly. link interface and should be supported accordingly.
5.6. Troubleshooting and Root Cause Analysis 4.6. Troubleshooting and Root Cause Analysis
Information and actions required by a manager/operator to Information and actions required by a manager/operator to investigate
investigate and understand the underlying issue to a problem in the and understand the underlying issue to a problem in the performance
performance and/or functionality of a radio link terminal and the and/or functionality of a radio link terminal and the associated
associated carrier terminations. carrier terminations.
6. Requirements 5. Requirements
For managing a microwave node including both the radio link and the For managing a microwave node including both the radio link and the
packet functionality, a unified data model is desired to unify the packet functionality, a unified data model is desired to unify the
modeling of the radio link interfaces and the packet interfaces modeling of the radio link interfaces and the packet interfaces using
using the same structure and the same modelling approach. If some the same structure and the same modelling approach. If some part of
part of model is generic for other technology usage, it should be model is generic for other technology usage, it should be clearly
clearly stated. stated.
The purpose of the YANG Data Model is for management and control of The purpose of the YANG Data Model is for management and control of
the radio link interface(s) and the relationship/connectivity to the radio link interface(s) and the relationship/connectivity to
other packet interfaces, typically to Ethernet interfaces, in a other packet interfaces, typically to Ethernet interfaces, in a
microwave node. microwave node.
The capability of configuring and managing microwave nodes includes The capability of configuring and managing microwave nodes includes
the following requirements for the modelling: the following requirements for the modelling:
1) It MUST be possible to configure, manage and control a radio link 1. It MUST be possible to configure, manage and control a radio link
terminal and the constituent carrier terminations. terminal and the constituent carrier terminations.
a) Frequency, channel bandwidth, modulation, coding and A. Configuration of frequency, channel bandwidth, modulation,
transmitter power are examples of parameters typically coding and transmitter output power MUST be supported for a
configured for a carrier termination. carrier termination.
b) A radio link terminal MUST configure the associated carrier B. A radio link terminal MUST configure the associated carrier
terminations and the type of aggregation/bonding or protection terminations and the type of aggregation/bonding or
configurations expected for the radio link terminal. protection configurations expected for the radio link
terminal.
c) The capability, e.g. the maximum modulation supported, and the C. The capability, e.g. the maximum modulation supported, and
actual status/statistics, e.g. administrative status of the the actual status/statistics, e.g. administrative status of
carriers, SHOULD also be supported by the data model. the carriers, SHOULD also be supported by the data model.
d) The definition of the features and parameters SHOULD be based D. The definition of the features and parameters SHOULD be based
on established microwave equipment and radio standards, such on established microwave equipment and radio standards, such
as ETSI EN 302 217 [EN 302 217-2] which specifies the essential as ETSI EN 302 217 [EN302217-2] which specifies the essential
parameters for microwave systems operating from 1.4GHz to parameters for microwave systems operating from 1.4GHz to
86GHz. 86GHz.
2) It MUST be possible to map different traffic types (e.g. TDM, 2. It MUST be possible to map different traffic types (e.g. TDM,
Ethernet) to the transport capacity provided by a specific radio Ethernet) to the transport capacity provided by a specific radio
link terminal. link terminal.
3) It MUST be possible to configure and collect historical 3. It MUST be possible to configure and collect historical
measurements (for the use case described in section 5.4) to be measurements (for the use case described in section 5.4) to be
performed on a radio link interface, e.g. minimum, maximum and performed on a radio link interface, e.g. minimum, maximum and
average transmit power and receive level in dBm. average transmit power and receive level in dBm.
4) It MUST be possible to configure and retrieve alarms reporting 4. It MUST be possible to configure and retrieve alarms reporting
associated with the radio interfaces, e.g. configuration of alarm associated with the radio interfaces, e.g. configuration of alarm
severity, supported alarms like configuration fault, signal lost, severity, supported alarms like configuration fault, signal lost,
modem fault, radio fault. modem fault, radio fault.
7. Gap Analysis on Models 6. Gap Analysis on Models
The purpose of the gap analysis is to identify and recommend what The purpose of the gap analysis is to identify and recommend what
existing and established models as well as draft models under existing and established models as well as draft models under
definition to support the use cases and requirements specified in definition to support the use cases and requirements specified in the
the previous chapters. It shall also make a recommendation on how previous chapters. It shall also make a recommendation on how the
the gaps not supported should be filled, including the need for gaps not supported should be filled, including the need for
development of new models and evolution of existing models and development of new models and evolution of existing models and
drafts. drafts.
For microwave radio link functionality work has been initiated (ONF: For microwave radio link functionality work has been initiated (ONF:
Microwave Modeling [ONF-model], IETF: Radio Link Model [I- Microwave Modeling [ONF-model], IETF: Radio Link Model
D.ahlbergccamp-microwave-radio-link]. The analysis is expected to [I-D.ahlberg-ccamp-microwave-radio-link]. The analysis is expected
take these initiatives into consideration and make a recommendation to take these initiatives into consideration and make a
on how to make use of them and how to complement them in order to recommendation on how to make use of them and how to complement them
fill the gaps identified. in order to fill the gaps identified.
For generic functionality, not specific for radio link, the ambition For generic functionality, not specific for radio link, the ambition
is to refer to existing or emerging models that could be applicable is to refer to existing or emerging models that could be applicable
for all functional areas in a microwave node. for all functional areas in a microwave node.
7.1. Microwave Radio Link Functionality 6.1. Microwave Radio Link Functionality
[ONF-CIM] defines a CoreModel of the ONF Common Information Model. [ONF-CIM] defines a CoreModel of the ONF Common Information Model.
An information model describes the things in a domain in terms of An information model describes the things in a domain in terms of
objects, their properties (represented as attributes), and their objects, their properties (represented as attributes), and their
relationships. The ONF information model is expressed in Unified relationships. The ONF information model is expressed in Unified
Modeling Language (UML). The ONF CoreModel is independent of Modeling Language (UML). The ONF CoreModel is independent of
specific data plane technology. Data plane technology specific specific data plane technology. Data plane technology specific
properties are acquired in a runtime solution via "filled in" cases properties are acquired in a runtime solution via "filled in" cases
of specification (LtpSpec etc). These can be used to augment the of specification (LtpSpec etc.). These can be used to augment the
CoreModel to provide a data plane technology specific representation. CoreModel to provide a data plane technology specific representation.
IETF Data Model defines an implementation and NETCONF-specific IETF Data Model defines an implementation and NETCONF-specific
details. YANG is a data modeling language used to model the details. YANG is a data modeling language used to model the
configuration and state data. It is well aligned with the structure configuration and state data. It is well aligned with the structure
of the Yang data models proposed for the different packet interfaces of the YANG data models proposed for the different packet interfaces
which are all based on [RFC7223]. Furthermore, several YANG data which are all based on [RFC7223]. Furthermore, several YANG data
models have been proposed in the IETF for other transport models have been proposed in the IETF for other transport
technologies such as optical transport; e.g. [RFC7277], technologies such as optical transport; e.g. [RFC7277],
[I.D.zhang-ccamp-l1-topo-yang], [I.D.ietf-ospf-yang]. In light of [I-D.ietf-ccamp-otn-topo-yang], [I-D.ietf-ospf-yang]. In light of
this trend, the IETF data model is becoming a popular approach for this trend, the IETF data model is becoming a popular approach for
modeling most packet transport technology interfaces and it is modeling most packet transport technology interfaces and it is
thereby well positioned to become an industry standard. thereby well positioned to become an industry standard.
[RFC3444] explains the difference between Information Model(IM) and [RFC3444] explains the difference between Information Model(IM) and
Data Models(DM). IM is to model managed objects at a conceptual level Data Models(DM). IM is to model managed objects at a conceptual
for designers and operators, DM is defined at a lower level and level for designers and operators, DM is defined at a lower level and
includes many details for implementers. In addition, the includes many details for implementers. In addition, the protocol-
protocol-specific details are usually included in DM. Since specific details are usually included in DM. Since conceptual models
conceptual models can be implemented in different ways, multiple DMs can be implemented in different ways, multiple DMs can be derived
can be derived from a single IM. To ensure better interoperability, from a single IM. To ensure better interoperability, it is better to
it is better to focus on DM directly. focus on DM directly.
[RFC7223] describes an interface management model, however it doesn't [RFC7223] describes an interface management model, however it doesn't
include technology specific information, e.g., for radio interface. include technology specific information, e.g., for radio interface.
[I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal [I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal
for radio interfaces, which includes support for basic configuration, for radio interfaces, which includes support for basic configuration,
status and performance but lacks full support for alarm management status and performance but lacks full support for alarm management
and interface layering, i.e. the connectivity of the transported and interface layering, i.e. the connectivity of the transported
capacity (TDM and Ethernet) with other internal technology specific capacity (TDM and Ethernet) with other internal technology specific
interfaces in a microwave node. interfaces in a microwave node.
The recommendation is to use the structure of the IETF: Radio Link The recommendation is to use the structure of the IETF: Radio Link
Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point, Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point,
since it is a data model providing the wanted alignment with since it is a data model providing the wanted alignment with
[RFC7223]. For the definition of the detailed leafs/parameters, the [RFC7223]. For the definition of the detailed leafs/parameters, the
recommendation is to use the IETF: Radio Link Model and the ONF: recommendation is to use the IETF: Radio Link Model and the ONF:
Microwave Modeling [ONF-model] as the basis and to define new ones Microwave Modeling [ONF-model] as the basis and to define new ones to
to cover identified gaps. The parameters in those models have been cover identified gaps. The parameters in those models have been
defined by both operators and vendors within the industry and the defined by both operators and vendors within the industry and the
implementations of the ONF Model have been tested in the Proof of implementations of the ONF Model have been tested in the Proof of
Concept events in multi-vendor environments, showing the validity of Concept events in multi-vendor environments, showing the validity of
the approach proposed in this framework document. the approach proposed in this framework document.
It is also recommended to add the required data nodes to describe It is also recommended to add the required data nodes to describe the
the interface layering for the capacity provided by a radio link interface layering for the capacity provided by a radio link terminal
terminal and the associated Ethernet and TDM interfaces in a and the associated Ethernet and TDM interfaces in a microwave node.
microwave node. The principles and data nodes for interface layering The principles and data nodes for interface layering described in
described in [RFC7223] should be used as a basis. [RFC7223] should be used as a basis.
7.2. Generic Functionality 6.2. Generic Functionality
For generic functionality, not specific for radio link, the For generic functionality, not specific for radio link, the
recommendation is to refer to existing RFCs or emerging drafts recommendation is to refer to existing RFCs or emerging drafts
according to the table in figure 4 below. New Radio Link Model is according to the table in Figure 4 below. New Radio Link Model is
used in the table for the cases where the functionality is used in the table for the cases where the functionality is
recommended to be included in the new radio link model as described recommended to be included in the new radio link model as described
in chapter 7.1. in Section 6.1.
+------------------------------------+-----------------------------+ +------------------------------------+-----------------------------+
| Generic Functionality | Recommendation | | Generic Functionality | Recommendation |
| | | | | |
+------------------------------------+-----------------------------+ +------------------------------------+-----------------------------+
|1.Fault Management | | |1.Fault Management | |
| | | | | |
| Alarm Configuration | New Radio Link Model | | Alarm Configuration | New Radio Link Model |
| | | | | |
| Alarm notifications/ | [I-D.vallin-ccamp- | | Alarm notifications/ | [I-D.ietf-ccamp- |
| synchronization | alarm-module] | | synchronization | alarm-module] |
+------------------------------------+-----------------------------+ +------------------------------------+-----------------------------+
|2.Performance Management | | |2.Performance Management | |
| | | | | |
| Performance Configuration/ | New Radio Link Model | | Performance Configuration/ | New Radio Link Model |
| Activation | | | Activation | |
| | | | | |
| Performance Collection | New Radio Link Model and | | Performance Collection | New Radio Link Model and |
| | XML files | | | XML files |
+------------------------------------+-----------------------------+ +------------------------------------+-----------------------------+
|3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] | |3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] |
+------------------------------------+-----------------------------+ +------------------------------------+-----------------------------+
Figure 4. Recommendation on how to support generic functionality Figure 4: Recommendation on how to support generic functionality
Microwave specific alarm configurations are recommended to be Microwave specific alarm configurations are recommended to be
included in the new radio link model and could be based on what is 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 supported in the IETF and ONF Radio Link Models. Alarm notifications
and synchronization are general and is recommended to be supported and synchronization are general and is recommended to be supported by
by a generic model, such as [I-D.vallin-ccamp-alarm-module]. a generic model, such as [I-D.ietf-ccamp-alarm-module].
Activation of interval counters and thresholds could be a generic Activation of interval counters and thresholds could be a generic
function but it is recommended to be supported by the new radio link 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 specific model and can be based on both the ONF and IETF Microwave
Radio Link models. Radio Link models.
Collection of interval/historical counters is a generic function Collection of interval/historical counters is a generic function that
that needs to be supported in a node. File based collection via SFTP needs to be supported in a node. File based collection via SSH File
and collection via a Netconf/YANG interfaces are two possible Transfer Protocol(SFTP) and collection via a NETCONF/YANG interfaces
options and the recommendation is to include support for the latter are two possible options and the recommendation is to include support
in the new radio link specific model. The ONF and IETF Microwave for the latter in the new radio link specific model. The ONF and
Radio Link models can be used as a basis also in this area. 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 Physical and/or equipment inventory associated with the radio link
terminals and carrier terminations is recommended to be covered by a terminals and carrier terminations is recommended to be covered by a
model generic for the complete node, e.g. [I-D.ietf-netmod-entity] 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 and it is thereby outside the scope of the radio link specific model.
model.
7.3. Summary 6.3. Summary
The conclusions and recommendations from the analysis can be The conclusions and recommendations from the analysis can be
summarized as follows: summarized as follows:
1) A Microwave Radio Link YANG Data Model should be defined with a 1. A Microwave Radio Link YANG Data Model should be defined with a
scope enough to support the use cases and requirements in scope enough to support the use cases and requirements in
chapter 5 and 6 of this document. Sections 4 and 5 of this document.
2) Use the structure in the IETF: Radio Link Model [I-D.ahlberg- 2. Use the structure in the IETF: Radio Link Model
ccamp-microwave-radio-link] as the starting point. It augments [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point.
[RFC7223] and is thereby as required aligned with the structure It augments [RFC7223] and is thereby as required aligned with the
of the models for management of the packet domain. structure of the models for management of the packet domain.
3) Use established microwave equipment and radio standards, such 3. Use established microwave equipment and radio standards, such as
as [EN 302 217-2], and the IETF: Radio Link Model [EN302217-2], and the IETF: Radio Link Model
[I-D.ahlberg-ccamp-microwave-radio-link] and the [I-D.ahlberg-ccamp-microwave-radio-link] and the ONF: Microwave
ONF: Microwave Modeling [ONF-model] as the basis for the Modeling [ONF-model] as the basis for the definition of the
definition of the detailed leafs/parameters to support the detailed leafs/parameters to support the specified use cases and
specified use cases and requirements, and proposing new ones requirements, and proposing new ones to cover identified gaps.
to cover identified gaps.
4) Add the required data nodes to describe the interface layering 4. Add the required data nodes to describe the interface layering
for the capacity provided by a radio link terminal and the for the capacity provided by a radio link terminal and the
associated Ethernet and TDM interfaces, using the principles associated Ethernet and TDM interfaces, using the principles and
and data nodes for interface layering described in [RFC7223] as data nodes for interface layering described in [RFC7223] as a
a basis. basis.
5) Include support for configuration of microwave specific alarms 5. Include support for configuration of microwave specific alarms in
in the Microwave Radio Link model and rely on a generic model the Microwave Radio Link model and rely on a generic model such
such as [I.D.vallin-ccamp-alarm-module] for notifications and as [I-D.ietf-ccamp-alarm-module] for notifications and alarm
alarm synchronization. synchronization.
6) Use a generic model such as [I-D.ietf-netmod-entity] for 6. Use a generic model such as [I-D.ietf-netmod-entity] for
physical/equipment inventory. physical/equipment inventory.
It is furthermore recommended that the Microwave Radio Link YANG It is furthermore recommended that the Microwave Radio Link YANG Data
Date Model should be validated by both operators and vendors as Model should be validated by both operators and vendors as part of
part of the process to make it stable and mature. During the the process to make it stable and mature. During the Hackathon in
Hackathon in IETF 99, a project "SDN Applications for microwave IETF 99, a project "SDN Applications for microwave radio link via
radio link via IETF YANG Data Model" successfully validated this IETF YANG Data Model" successfully validated this framework and the
framework and the YANG data model[I.D.ietf-ccamp-mw-yang]. The YANG data model[I-D.ietf-ccamp-mw-yang]. The project also received
project also received the BEST OVERALL award from the Hackathon. the BEST OVERALL award from the Hackathon.
8. Security Considerations 7. Security Considerations
Security issue concerning the access control to Management interfaces Security issue concerning the access control to Management interfaces
can be generally addressed by authentication techniques providing can be generally addressed by authentication techniques providing
origin verification, integrity and confidentiality. In additon, origin verification, integrity and confidentiality. In addition,
management interfaces can be physically or logically isolated, management interfaces can be physically or logically isolated, by
by configuring them to be only accessible out-of-band, through configuring them to be only accessible out-of-band, through a system
a system that is physically or logically separated from the rest of that is physically or logically separated from the rest of the
the network infrastructure. In case where management interfaces are network infrastructure. In case where management interfaces are
accessible in-band at the client device or within the microwave accessible in-band at the client device or within the microwave
transport netork domain, filtering or firewalling techniques transport network domain, filtering or firewalling techniques can be
can be used to restrict unauthorized in-band traffic. Authentication used to restrict unauthorized in-band traffic. Authentication
techniques may be additionally used in all cases. techniques may be additionally used in all cases.
This framework describes the requirements and charactersitics of This framework describes the requirements and characteristics of a
of a YANG Data Model for control and management of the radio link YANG Data Model for control and management of the radio link
interfaces in a microwave node. It is supposed to be accessed via a interfaces in a microwave node. It is supposed to be accessed via a
management protocol with a secure transport layer, such as NETCONF management protocol with a secure transport layer, such as NETCONF
[RFC6241]. [RFC6241].
9. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2863] McCloghrie K. and Kastenholz F., "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<http://www.rfc-editor.org/info/rfc2863>. <https://www.rfc-editor.org/info/rfc2863>.
[RFC3444] Pras A., Schoenwaelder J., "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, DOI Information Models and Data Models", RFC 3444,
10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC7223] Bjorklund M., "A YANG Data Model for Interface [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund M., "A YANG Data Model for IP Management", RFC [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
7277, DOI 10.17487/RFC7277, June 2014, RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>. <https://www.rfc-editor.org/info/rfc7277>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 9.2. Informative References
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
10.2. Informative References [EN302217-2]
"Fixed Radio Systems; Characteristics and requirements for
point to-point equipment and antennas; Part 2: Digital
systems operating in frequency bands from 1 GHz to 86 GHz;
Harmonised Standard covering the essential requirements of
article 3.2 of Directive 2014/53/EU", EN 302 217-2
V3.1.1 , May 2017.
[I-D.ahlberg-ccamp-microwave-radio-link] [I-D.ahlberg-ccamp-microwave-radio-link]
Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M.,
and M. Vaupotic, "Microwave Radio Link YANG Data Models", and M. Vaupotic, "Microwave Radio Link YANG Data Models",
draft-ahlberg-ccamp-microwave-radio-link-01 (work in draft-ahlberg-ccamp-microwave-radio-link-01 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-netmod-entity] [I-D.ietf-ccamp-alarm-module]
Bierman A., Bjorklund M., Dong J., Romascanu D., "A YANG Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft-
Data Model for Entity Management", draft-ietf-netmod- ietf-ccamp-alarm-module-00 (work in progress), December
entity-05 (work in progress), October 2017.
[I-D.vallin-ccamp-alarm-module]
Vallin S. and Bjorklund M., "YANG Alarm Module", draft-
vallin-ccamp-alarm-module-01 (work in progress), October
2017. 2017.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [I-D.ietf-ccamp-mw-yang]
Management", RFC 8022, DOI 10.17487/RFC8022, November 2016 Ahlberg, J., Ye, M., Li, X., Kawada, K., Bernardos, C.,
Spreafico, D., and M. Vaupotic, "A YANG Data Model for
[I.D.zhang-ccamp-l1-topo-yang] Microwave Radio Link", draft-ietf-ccamp-mw-yang-02 (work
Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model in progress), October 2017.
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]
ONF TR-532, "Microwave Information Model", version 1.0,
December 2016, available at
https://www.opennetworking.org/images/stories/downloads/
sdn-resources/technical-reports/TR-532-Microwave-
Information-Model-V1.pdf
[ONF-CIM] ONF TR-512, "Core Information Model", version 1.2,
September 2016, available at
https://www.opennetworking.org/wp-content/uploads/2014/10/
TR-512_CIM_(CoreModel)_1.2.zip
[PB-YANG] "IEEE 802.1X and 802.1Q YANG models", Marc,H., October
2015.
[EN 302 217-2]
ETSI, "Fixed Radio Systems; Characteristics and
requirements for point to-point equipment and antennas;
Part 2: Digital systems operating in frequency bands from
1 GHz to 86 GHz; Harmonised Standard covering the
essential requirements of article 3.2 of Directive
2014/53/EU", EN 302 217-2 V3.1.1, May 2017.
[I.D.ietf-ccamp-mw-yang] [I-D.ietf-ccamp-otn-topo-yang]
Ahlberg, J., Ye, M., Li,X., Kawada K., Bernardos C., zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Liu, X.,
Spreafico D., Vaupotic M., "A YANG Data Model for Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data
Microwave Radio Link", draft-ietf-ccamp-mw-yang-01,(work Model for Optical Transport Network Topology", draft-ietf-
in progress), July 2016. ccamp-otn-topo-yang-02 (work in progress), October 2017.
Authors' Addresses [I-D.ietf-netmod-entity]
Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", draft-ietf-
netmod-entity-07 (work in progress), December 2017.
Jonas Ahlberg [I-D.ietf-ospf-yang]
Ericsson AB Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
Lindholmspiren 11 "Yang Data Model for OSPF Protocol", draft-ietf-ospf-
Goeteborg 417 56 yang-09 (work in progress), October 2017.
Sweden
Email: jonas.ahlberg@ericsson.com [ONF-CIM] "Core Information Model", version 1.2 , September 2016,
<https://www.opennetworking.org/wp-
content/uploads/2014/10/TR-512_CIM_(CoreModel)_1.2.zip>.
Luis M. Contreras [ONF-model]
Telefonica I+D "Microwave Information Model", version 1.0 , December
Ronda de la Comunicacion, S/N 2016,
Madrid 28050 <https://www.opennetworking.org/images/stories/downloads/
Spain sdn-resources/technical-reports/
TR-532-Microwave-Information-Model-V1.pdf>.
Email: luismiguel.contrerasmurillo@telefonica.com [PB-YANG] "IEEE 802.1X and 802.1Q Module Specifications", version
0.4 , May 2015,
<http://www.ieee802.org/1/files/public/docs2015/
new-mholness-YANG-8021x-0515-v04.pdf>.
Ye Min [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Huawei Technologies CO., Ltd Management", RFC 8022, DOI 10.17487/RFC8022, November
No.1899, Xiyuan Avenue 2016, <https://www.rfc-editor.org/info/rfc8022>.
Chengdu 611731
P.R.China
Email: amy.yemin@huawei.com Appendix A. Contributors
Marko Vaupotic Marko Vaupotic
Aviat Networks Aviat Networks
Motnica 9 Motnica 9
Trzin-Ljubljana 1236 Trzin-Ljubljana 1236
Slovenia Slovenia
Email: Marko.Vaupotic@aviatnet.com Email: Marko.Vaupotic@aviatnet.com
Jeff Tantsura Jeff Tantsura
Individual Huawei Technologies CO., Ltd
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Koji Kawada Koji Kawada
NEC Corporation NEC Corporation
1753, Shimonumabe Nakahara-ku 1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666 Kawasaki, Kanagawa 211-8666
Japan Japan
Email: k-kawada@ah.jp.nec.com 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 Ippei Akiyoshi
NEC NEC
1753, Shimonumabe Nakahara-ku 1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666 Kawasaki, Kanagawa 211-8666
Japan Japan
Email: i-akiyoshi@ah.jp.nec.com 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
Daniela Spreafico Daniela Spreafico
Nokia - IT Nokia - IT
Via Energy Park, 14 Via Energy Park, 14
Vimercate (MI) 20871 Vimercate (MI) 20871
Italy Italy
Email: daniela.spreafico@nokia.com Email: daniela.spreafico@nokia.com
Authors' Addresses
Jonas Ahlberg (editor)
Ericsson AB
Lindholmspiren 11
Goteborg 417 56
Sweden
Email: jonas.ahlberg@ericsson.com
Ye Min (editor)
Huawei Technologies
No.1899, Xiyuan Avenue
Chengdu 611731
P.R.China
Email: amy.yemin@huawei.com
Xi Li
NEC Laboratories Europe
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Email: Xi.Li@neclab.eu
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, S/N
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Madrid, Leganes 28911
Spain
Email: cjbc@it.uc3m.es
 End of changes. 143 change blocks. 
594 lines changed or deleted 532 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/