draft-ietf-ccamp-microwave-framework-05.txt   draft-ietf-ccamp-microwave-framework-06.txt 
CCAMP Working Group J. Ahlberg, Ed. CCAMP Working Group J. Ahlberg, Ed.
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Informational M. Ye, Ed. Intended status: Informational M. Ye, Ed.
Expires: July 9, 2018 Huawei Technologies Expires: November 19, 2018 Huawei Technologies
X. Li X. Li
NEC Laboratories Europe NEC Laboratories Europe
LM. Contreras LM. Contreras
Telefonica I+D Telefonica I+D
CJ. Bernardos CJ. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
January 5, 2018 May 18, 2018
A framework for Management and Control of microwave and millimeter wave A framework for Management and Control of microwave and millimeter wave
interface parameters interface parameters
draft-ietf-ccamp-microwave-framework-05 draft-ietf-ccamp-microwave-framework-06
Abstract Abstract
The unification of control and management of microwave radio link The unification of control and management of microwave radio link
interfaces is a precondition for seamless multilayer networking and interfaces is a precondition for seamless multilayer networking and
automated network provisioning and operation. automated network 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. YANG Data 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 node. Some parts of the resulting model may be generic microwave node. Some parts of the resulting model may be generic
which could also be used by other technologies. which could also be used by other technologies, e.g., ETH technology.
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 https://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 November 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
3.2. Software Defined Networking . . . . . . . . . . . . . . . 8 3.2. Software Defined Networking . . . . . . . . . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Configuration Management . . . . . . . . . . . . . . . . 9 4.1. Configuration Management . . . . . . . . . . . . . . . . 9
4.1.1. Understand the capabilities and limitations . . . . . 9 4.1.1. Understand the capabilities and limitations . . . . . 9
4.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 4.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10
4.1.3. Radio link re-configuration and optimization . . . . 10 4.1.3. Radio link re-configuration and optimization . . . . 10
4.1.4. Radio link logical configuration . . . . . . . . . . 10 4.1.4. Radio link logical configuration . . . . . . . . . . 10
4.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Retrieve logical inventory and configuration from 4.2.1. Retrieve logical inventory and configuration from
device . . . . . . . . . . . . . . . . . . . . . . . 10 device . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Retrieve physical/equipment inventory from device . . 10 4.2.2. Retrieve physical/equipment inventory from device . . 11
4.3. Status and statistics . . . . . . . . . . . . . . . . . . 11 4.3. Status and statistics . . . . . . . . . . . . . . . . . . 11
4.3.1. Actual status and performance of a radio link 4.3.1. Actual status and performance of a radio link
interface . . . . . . . . . . . . . . . . . . . . . . 11 interface . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Performance management . . . . . . . . . . . . . . . . . 11 4.4. Performance management . . . . . . . . . . . . . . . . . 11
4.4.1. Configuration of historical measurements to be 4.4.1. Configuration of historical measurements to be
performed . . . . . . . . . . . . . . . . . . . . . . 11 performed . . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Collection of historical performance data . . . . . . 11 4.4.2. Collection of historical performance data . . . . . . 11
4.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 4.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11
4.5.1. Configuration of alarm reporting . . . . . . . . . . 11 4.5.1. Configuration of alarm reporting . . . . . . . . . . 11
4.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 4.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11
4.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 4.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 12
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 6. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13
6.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 6.1. Microwave Radio Link Functionality . . . . . . . . . . . 13
6.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14 6.2. Generic Functionality . . . . . . . . . . . . . . . . . . 15
6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Microwave radio is a technology that uses high frequency radio waves Microwave radio is a technology that uses high frequency radio waves
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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 Microwave is already today able to fully support the capacity needs
of a backhaul in a radio access network and will evolve to support of a backhaul in a radio access network and will evolve to support
multiple gigabits in traditional frequency bands and beyond 10 multiple gigabits in traditional frequency bands and beyond 10
gigabits in higher frequency bands with more band width. L2 packet gigabits in higher frequency bands with more band width. L2 Ethernet
features are normally an integrated part of microwave nodes and more features are normally an integrated part of microwave nodes and more
advanced L2 and L3 features will over time be introduced to support advanced L2 and L3 features will over time be introduced to support
the evolution of the transport services to be provided by a backhaul/ the evolution of the transport services to be provided by a backhaul/
transport network. Note that the wireless access technologies such 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 as 3/4/5G and Wi-Fi are not within the scope of this microwave model
work. 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 single management of equipment from multiple vendors, integrated in a single
system/controller. This framework addresses management and control system/controller. This framework addresses management and control
of the radio link interface(s) and the relationship to other packet of the radio link interface(s) and the relationship to other
interfaces, typically to Ethernet interfaces, in a microwave node. A interfaces, typically to Ethernet interfaces, in a microwave node. A
radio link provides the transport over the air, using one or several radio link provides the transport over the air, using one or several
carriers in aggregated or protected configurations. Managing and carriers in aggregated or protected configurations. Managing and
controlling a transport service over a microwave node involves both controlling a transport service over a microwave node involves both
radio link and packet functionality. radio link and packet transport 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 L2
packet domain. Examples are IP Management [RFC7277], Routing and L3 domains. Examples are IP Management [RFC8344], Routing
Management [RFC8022] and Provider Bridge [PB-YANG]. They are based Management [RFC8349] 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 [RFC8343], 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 functionality Since microwave nodes will contain more and more L2 and L3(packet)
which is expected to be managed using those models, there are functionality which is expected to be managed using those models,
advantages if radio link interfaces can be modeled and be managed there are advantages if radio link interfaces can be modeled and be
using the same structure and the same approach, specifically for use managed using the same structure and the same approach, specifically
cases in which a microwave node is managed as one common entity for use cases in which a microwave node is managed as one common
including both the radio link and the packet functionality, e.g. at entity including both the radio link and the L2 and L3 functionality,
basic configuration of node and connections, centralized trouble e.g. at basic configuration of node and connections, centralized
shooting, upgrade and maintenance. All interfaces in a node, trouble shooting, upgrade and maintenance. All interfaces in a node,
irrespective of technology, would then be accessed from the same core irrespective of technology, would then be accessed from the same core
model, i.e. [RFC7223], and could be extended with technology specific model, i.e. [RFC8343], and could be extended with technology specific
parameters in models augmenting that core model. The relationship/ parameters in models augmenting that core model. The relationship/
connectivity between interfaces could be given by the physical connectivity between interfaces could be given by the physical
equipment configuration, e.g. the slot in which the Radio Link equipment configuration, e.g. the slot in which the Radio Link
Terminal (modem) is plugged in could be associated with a specific 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 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 could be flexible and therefore configured via a management system or
controller. controller.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Interface [RFC7223] | | Interface [RFC8343] |
| +---------------+ | | +---------------+ |
| | Ethernet Port | | | | Ethernet Port | |
| +---------------+ | | +---------------+ |
| \ | | \ |
| +---------------------+ | | +---------------------+ |
| | Radio Link Terminal | | | | Radio Link Terminal | |
| +---------------------+ | | +---------------------+ |
| / \ | | / \ |
| +---------------------+ +---------------------+ | | +---------------------+ +---------------------+ |
| | Carrier Termination | | Carrier Termination | | | | Carrier Termination | | Carrier Termination | |
skipping to change at page 5, line 13 skipping to change at page 5, line 13
allow other parameters to be optional or to be covered by extensions allow other parameters to be optional or to be covered by extensions
to the standardized model. Furthermore, a standard that allows for a to the standardized model. Furthermore, a standard that allows for a
certain degree of freedom encourages innovation and competition which certain degree of freedom encourages innovation and competition which
is something that benefits the entire industry. It is therefore is something that benefits the entire industry. It is therefore
important that a radio link management model covers all relevant important that a radio link management model covers all 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 Microwave Modeling [ONF-model], IETF: Radio Link Model
[I-D.ahlberg-ccamp-microwave-radio-link]). The purpose of this [I-D.ietf-ccamp-mw-yang]). The purpose of this effort is to reach
effort is to reach consensus within the industry around one common consensus within the industry around one common approach, with
approach, with respect to the use cases and requirements to be respect to the use cases and requirements to be supported, the type
supported, the type and structure of the model and the resulting and structure of the model and the resulting attributes to be
attributes to be included. This document describes the use cases and included. This document describes the use cases and requirements
requirements agreed to be covered, the expected characteristics of agreed to be covered, the expected characteristics of the model and
the model and at the end includes an analysis of how the models in at the end includes an analysis of how the models in the two on-going
the two on-going initiatives fulfill these expectations and a initiatives fulfill these expectations and a recommendation on what
recommendation on what can be reused and what gaps need to be filled can be reused and what gaps need to be filled by a new and evolved
by a new and evolved radio link model. radio link model.
1.1. 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] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
While [RFC2119] describes interpretations of these key words in terms While [RFC2119] [RFC8174] describes interpretations of these key
of protocol specifications and implementations, they are used in this words in terms of protocol specifications and implementations, they
document to describe high level requirements to be met when defining are used in this document to describe high level requirements to be
the YANG Data Model for Microwave Radio Link. met when defining the YANG Data Model for Microwave Radio Link.
This document does not define any protocol extension, hence only This document does not define any protocol extension, hence only
RFC2119 can be considered as a normative reference. However, the [RFC2119] [RFC8174] can be considered as a normative reference.
list of normative references includes a number of documents that can However, the list of normative references includes a number of
be useful for a better understanding of the context. documents that can be useful for a better understanding of the
context.
2. Terminology and Definitions 2. Terminology and Definitions
Microwave radio is a term commonly used for technologies that operate Microwave radio is a term commonly used for technologies that operate
in both microwave and millimeter wave lengths and in frequency bands 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 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 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 10 Gbps. Using multi-carrier systems operating in frequency bands
with wider channels, the technology will be capable of providing with wider channels, the technology will be capable of providing
capacities up 100 Gbps. capacities up 100 Gbps.
skipping to change at page 6, line 23 skipping to change at page 6, line 26
operating from 1.4GHz to 86GHz. operating from 1.4GHz to 86GHz.
Carrier Termination and Radio Link Terminal are two concepts defined Carrier Termination and Radio Link Terminal are two concepts defined
to support modeling of microwave radio link features and parameters to support modeling of microwave radio link features and parameters
in a structured and yet simple manner. in a structured and yet simple manner.
Carrier Termination is an interface for the capacity provided over Carrier Termination is an interface for the capacity provided over
the air by a single carrier. It is typically defined by its the air by a single carrier. It is typically defined by its
transmitting and receiving frequencies. transmitting and receiving frequencies.
Radio Link Terminal is an interface providing packet capacity and/or Radio Link Terminal is an interface providing Ethernet capacity and/
Time Division Multiplexing (TDM) capacity to the associated Ethernet or Time Division Multiplexing (TDM) capacity to the associated
and/or TDM interfaces in a node and used for setting up a transport Ethernet and/or TDM interfaces in a node and used for setting up a
service over a microwave radio link. transport service over a microwave radio link.
Figure 2 provides a graphical representation of Carrier Termination Figure 2 provides a graphical representation of Carrier Termination
and Radio Link Terminal concepts. and Radio Link Terminal concepts.
/--------- Radio Link ---------\ /--------- Radio Link ---------\
Near End Far End Near End Far End
+---------------+ +---------------+ +---------------+ +---------------+
| Radio Link | | Radio Link | | Radio Link | | Radio Link |
| Terminal | | Terminal | | Terminal | | Terminal |
| | | | | | | |
| (Protected or Bonded) | | (Protected or Bonded) |
| | | | | | | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | | | Carrier A | | | | | | | | Carrier A | | | |
| | Carrier | |<--------->| | Carrier | | | | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| | | |Termination| | | |Termination| |
Packet--| | | | | | | |--Packet ETH----| | | | | | | |----ETH
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
TDM----| | | |----TDM TDM----| | | |----TDM
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | | | Carrier B | | | | | | | | Carrier B | | | |
| | Carrier | |<--------->| | Carrier | | | | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| | | |Termination| | | |Termination| |
| | | | | | | | | | | | | | | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
skipping to change at page 7, line 41 skipping to change at page 7, line 41
Figure 2: Radio Link Terminal and Carrier Termination Figure 2: Radio Link Terminal and Carrier Termination
Software Defined Networking (SDN) is an architecture that decouples Software Defined Networking (SDN) is an architecture that decouples
the network control and forwarding functions enabling the network the network control and forwarding functions enabling the network
control to become directly programmable and the underlying control to become directly programmable and the underlying
infrastructure to be abstracted for applications and network infrastructure to be abstracted for applications and network
services. SDN can be used as a term for automation of traditional services. SDN can be used as a term for automation of traditional
network management, which can be implemented using a similar network management, which can be implemented using a similar
approach. The adoption of an SDN framework for management and approach. The adoption of an SDN framework for management and
control the microwave interface is one of the key applications for control the microwave interface is the key purpose of this work.
this work.
3. Approaches to manage and control radio link interfaces 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 node. The interface for the radio link functionality in a microwave node. The
application of such an interface used for management and control of application of such an interface used for management and control of
nodes and networks typically vary from one operator to another, in nodes and networks typically vary from one operator to another, in
terms of the systems used and how they interact. A traditional terms of the systems used and how they interact. A traditional
solution is network management system, while an emerging one is SDN. solution is network management system(NMS), while an emerging one is
SDN solutions can be used as part of the network management system, SDN. SDN solutions can be used as part of the network management
allowing for direct network programmability and automated system, allowing for direct network programmability and automated
configurability by means of a centralized SDN control and configurability by means of a centralized SDN control and
standardized interfaces to program the nodes. standardized interfaces to program the nodes. It's noted that
there's idea that the NMS and SDN are evolving towards a component,
and the distinction between them is quite vague. Another fact is
that there is still plenty of networks where NMS is still considered
as the implementation of the management plane, while SDN is
considered as the centralization of the control plane. They are
still kept as separate components.
3.1. Network Management Solutions 3.1. Network Management Solutions
The classic network management solutions, with vendor specific domain The classic network management solutions, with vendor specific domain
management combined with cross domain functionality for service management combined with cross domain functionality for service
management and analytics, still dominates the market. These management and analytics, still dominates the market. These
solutions are expected to evolve and benefit from an increased focus solutions are expected to evolve and benefit from an increased focus
on standardization by simplifying multi-vendor management and remove on standardization by simplifying multi-vendor management and remove
the need for vendor/domain specific management. the need for vendor/domain specific management.
skipping to change at page 8, line 36 skipping to change at page 8, line 41
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 nodes On top of SDN applications to configure, manage and control the nodes
and their associated transport interfaces including the L2 Ethernet and their associated transport interfaces including the L2 Ethernet
and L3 packet interfaces as well as the radio interfaces, there are and L3 IP interfaces as well as the radio interfaces, there are also
also a large variety of other more advanced SDN applications that can a large variety of other more advanced SDN applications that can be
be exploited and/or developed. 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 configuration, metrics or parameters describing a complete radio link configuration,
such as capacity, availability, priority and power consumption. such as capacity, availability, priority and power 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
skipping to change at page 9, line 37 skipping to change at page 9, line 43
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.
4.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 IP/Ethernet and
and TDM interfaces. TDM interfaces.
4.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.
4.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 to an associated radio link terminal on a device at
a device at far end. It MAY also include configuration of the far end over the hop. 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 of parameters typically configured for a carrier termination and type of
aggregation/bonding or protection configurations expected for a radio aggregation/bonding or protection configurations expected for a radio
link terminal. link terminal.
4.1.3. Radio link re-configuration and optimization 4.1.3. Radio link re-configuration and optimization
skipping to change at page 11, line 11 skipping to change at page 11, line 16
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.
4.3. Status and statistics 4.3. Status and statistics
4.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. It's important to report the effective bandwidth
of a radio link since it can be configured to dynamically adjust the
modulation based on the current signal conditions.
4.4. Performance management 4.4. Performance management
4.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 Section 4.1 above. configuration use case to be supported. See Section 4.1 above.
4.4.2. Collection of historical performance data 4.4.2. Collection of historical performance data
skipping to change at page 11, line 43 skipping to change at page 11, line 50
4.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 Section 4.1 above. configuration use case to be supported. See Section 4.1 above.
4.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 radio events are generic use cases for a device and not specific to a radio
link interface and should be supported accordingly. link interface and should be supported accordingly. It's important
to report signal degradation of the radio link.
4.6. Troubleshooting and Root Cause Analysis 4.6. Troubleshooting and Root Cause Analysis
Information and actions required by a manager/operator to investigate Information and actions required by a manager/operator to investigate
and understand the underlying issue to a problem in the performance and understand the underlying issue to a problem in the performance
and/or functionality of a radio link terminal and the associated and/or functionality of a radio link terminal and the associated
carrier terminations. carrier terminations.
5. 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 transport functionality, a unified data model is desired to
modeling of the radio link interfaces and the packet interfaces using unify the modeling of the radio link interfaces and the L2/L3
the same structure and the same modelling approach. If some part of interfaces using the same structure and the same modelling approach.
model is generic for other technology usage, it should be clearly If some part of model is generic for other technology usage, it
stated. should be clearly 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 interfaces, typically to Ethernet interfaces, in a microwave
microwave node. 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. Configuration of frequency, channel bandwidth, modulation, A. Configuration of frequency, channel bandwidth, modulation,
coding and transmitter output power MUST be supported for a coding and transmitter output power MUST be supported for a
carrier termination. carrier termination.
skipping to change at page 13, line 22 skipping to change at page 13, line 31
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 the definition to support the use cases and requirements specified in the
previous chapters. It shall also make a recommendation on how the previous chapters. It shall also make a recommendation on how 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 Microwave Modeling [ONF-model], IETF: Radio Link Model
[I-D.ahlberg-ccamp-microwave-radio-link]. The analysis is expected [I-D.ietf-ccamp-mw-yang]. The analysis is expected to take these
to take these initiatives into consideration and make a initiatives into consideration and make a recommendation on how to
recommendation on how to make use of them and how to complement them make use of them and how to complement them in order to fill the gaps
in order to fill the gaps identified. 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.
6.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 interfaces which
which are all based on [RFC7223]. Furthermore, several YANG data are all based on [RFC8343]. Furthermore, several YANG data models
models have been proposed in the IETF for other transport have been proposed in the IETF for other transport technologies such
technologies such as optical transport; e.g. [RFC7277], as optical transport; e.g. [RFC8344],
[I-D.ietf-ccamp-otn-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 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 level for designers and operators, DM is defined at a lower level and
includes many details for implementers. In addition, the protocol- includes many details for implementers. In addition, the protocol-
specific details are usually included in DM. Since conceptual models specific details are usually included in DM. Since conceptual models
can be implemented in different ways, multiple DMs can be derived can be implemented in different ways, multiple DMs can be derived
from a single IM. To ensure better interoperability, it is better to from a single IM. To ensure better interoperability, it is better to
focus on DM directly. focus on DM directly.
[RFC7223] describes an interface management model, however it doesn't [RFC8343] 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.ietf-ccamp-mw-yang] provides a model proposal for radio
for radio interfaces, which includes support for basic configuration, interfaces, which includes support for basic configuration, status
status and performance but lacks full support for alarm management and performance but lacks full support for alarm management and
and interface layering, i.e. the connectivity of the transported interface layering, i.e. the connectivity of the transported capacity
capacity (TDM and Ethernet) with other internal technology specific (TDM and Ethernet) with other internal technology specific interfaces
interfaces in a microwave node. 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.ietf-ccamp-mw-yang] as the starting point, since it is a
since it is a data model providing the wanted alignment with data model providing the wanted alignment with [RFC8343]. For the
[RFC7223]. For the definition of the detailed leafs/parameters, the definition of the detailed leafs/parameters, the recommendation is to
recommendation is to use the IETF: Radio Link Model and the ONF: use the IETF: Radio Link Model and the ONF: Microwave Modeling
Microwave Modeling [ONF-model] as the basis and to define new ones to [ONF-model] as the basis and to define new ones to cover identified
cover identified gaps. The parameters in those models have been gaps. The parameters in those models have been defined by both
defined by both operators and vendors within the industry and the operators and vendors within the industry and the implementations of
implementations of the ONF Model have been tested in the Proof of the ONF Model have been tested in the Proof of Concept events in
Concept events in multi-vendor environments, showing the validity of multi-vendor environments, showing the validity of the approach
the approach proposed in this framework document. proposed in this framework document.
It is also recommended to add the required data nodes to describe the It is also recommended to add the required data nodes to describe the
interface layering for the capacity provided by a radio link terminal interface layering for the capacity provided by a radio link terminal
and the associated Ethernet and TDM interfaces in a microwave node. and the associated Ethernet and TDM interfaces in a microwave node.
The principles and data nodes for interface layering described in The principles and data nodes for interface layering described in
[RFC7223] should be used as a basis. [RFC8343] should be used as a basis.
6.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 Section 6.1. in Section 6.1.
skipping to change at page 15, line 24 skipping to change at page 15, line 33
| 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 | [RFC8348] |
+------------------------------------+-----------------------------+ +------------------------------------+-----------------------------+
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 by and synchronization are general and is recommended to be supported by
a generic model, such as [I-D.ietf-ccamp-alarm-module]. a generic model, such as [I-D.ietf-ccamp-alarm-module].
skipping to change at page 15, line 50 skipping to change at page 16, line 10
Collection of interval/historical counters is a generic function that Collection of interval/historical counters is a generic function that
needs to be supported in a node. File based collection via SSH File needs to be supported in a node. File based collection via SSH File
Transfer Protocol(SFTP) and collection via a NETCONF/YANG interfaces Transfer Protocol(SFTP) and collection via a NETCONF/YANG interfaces
are two possible options and the recommendation is to include support are two possible options and the recommendation is to include support
for the latter in the new radio link specific model. The ONF and 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 IETF Microwave Radio Link models can be used as a basis also in this
area. 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. [RFC8348] and it is
and it is thereby outside the scope of the radio link specific model. thereby outside the scope of the radio link specific model.
6.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
Sections 4 and 5 of this document. Sections 4 and 5 of this document.
2. Use the structure in the IETF: Radio Link Model 2. Use the structure in the IETF: Radio Link Model
[I-D.ahlberg-ccamp-microwave-radio-link] as the starting point. [I-D.ietf-ccamp-mw-yang] as the starting point. It augments
It augments [RFC7223] and is thereby as required aligned with the [RFC8343] and is thereby as required aligned with the structure
structure of the models for management of the packet domain. of the models for management of the L2 and L3 domains.
3. Use established microwave equipment and radio standards, such as 3. Use established microwave equipment and radio standards, such as
[EN302217-2], and the IETF: Radio Link Model [EN302217-2], and the IETF: Radio Link Model
[I-D.ahlberg-ccamp-microwave-radio-link] and the ONF: Microwave [I-D.ietf-ccamp-mw-yang] and the ONF: Microwave Modeling
Modeling [ONF-model] as the basis for the definition of the [ONF-model] as the basis for the definition of the detailed
detailed leafs/parameters to support the specified use cases and leafs/parameters to support the specified use cases and
requirements, and proposing new ones to cover identified gaps. requirements, and proposing new ones 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 and associated Ethernet and TDM interfaces, using the principles and
data nodes for interface layering described in [RFC7223] as a data nodes for interface layering described in [RFC8343] as a
basis. basis.
5. Include support for configuration of microwave specific alarms in 5. Include support for configuration of microwave specific alarms in
the Microwave Radio Link model and rely on a generic model such the Microwave Radio Link model and rely on a generic model such
as [I-D.ietf-ccamp-alarm-module] for notifications and alarm as [I-D.ietf-ccamp-alarm-module] for notifications and alarm
synchronization. synchronization.
6. Use a generic model such as [I-D.ietf-netmod-entity] for 6. Use a generic model such as [RFC8348] for physical/equipment
physical/equipment inventory. inventory.
It is furthermore recommended that the Microwave Radio Link YANG Data It is furthermore recommended that the Microwave Radio Link YANG Data
Model should be validated by both operators and vendors as part of Model should be validated by both operators and vendors as part of
the process to make it stable and mature. During the Hackathon in the process to make it stable and mature. During the Hackathon in
IETF 99, a project "SDN Applications for microwave radio link via IETF 99, a project "SDN Applications for microwave radio link via
IETF YANG Data Model" successfully validated this framework and the IETF YANG Data Model" successfully validated this framework and the
YANG data model[I-D.ietf-ccamp-mw-yang]. The project also received YANG data model[I-D.ietf-ccamp-mw-yang]. The project also received
the BEST OVERALL award from the Hackathon. the BEST OVERALL award from the Hackathon.
7. Security Considerations 7. Security Considerations
skipping to change at page 17, line 46 skipping to change at page 18, line 10
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
<https://www.rfc-editor.org/info/rfc7223>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
RFC 7277, DOI 10.17487/RFC7277, June 2014, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc7277>. <https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
9.2. Informative References 9.2. Informative References
[EN302217-2] [EN302217-2]
"Fixed Radio Systems; Characteristics and requirements for "Fixed Radio Systems; Characteristics and requirements for
point to-point equipment and antennas; Part 2: Digital point to-point equipment and antennas; Part 2: Digital
systems operating in frequency bands from 1 GHz to 86 GHz; systems operating in frequency bands from 1 GHz to 86 GHz;
Harmonised Standard covering the essential requirements of Harmonised Standard covering the essential requirements of
article 3.2 of Directive 2014/53/EU", EN 302 217-2 article 3.2 of Directive 2014/53/EU", EN 302 217-2
V3.1.1 , May 2017. V3.1.1 , May 2017.
[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-ccamp-alarm-module] [I-D.ietf-ccamp-alarm-module]
Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft-
ietf-ccamp-alarm-module-00 (work in progress), December ietf-ccamp-alarm-module-01 (work in progress), February
2017. 2018.
[I-D.ietf-ccamp-mw-yang] [I-D.ietf-ccamp-mw-yang]
Ahlberg, J., Ye, M., Li, X., Kawada, K., Bernardos, C., Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M.
Spreafico, D., and M. Vaupotic, "A YANG Data Model for Vaupotic, "A YANG Data Model for Microwave Radio Link",
Microwave Radio Link", draft-ietf-ccamp-mw-yang-02 (work draft-ietf-ccamp-mw-yang-05 (work in progress), March
in progress), October 2017. 2018.
[I-D.ietf-ccamp-otn-topo-yang] [I-D.ietf-ccamp-otn-topo-yang]
zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Liu, X., zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Liu, X.,
Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data
Model for Optical Transport Network Topology", draft-ietf- Model for Optical Transport Network Topology", draft-ietf-
ccamp-otn-topo-yang-02 (work in progress), October 2017. ccamp-otn-topo-yang-02 (work in progress), October 2017.
[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.
[I-D.ietf-ospf-yang] [I-D.ietf-ospf-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"Yang Data Model for OSPF Protocol", draft-ietf-ospf- "Yang Data Model for OSPF Protocol", draft-ietf-ospf-
yang-09 (work in progress), October 2017. yang-11 (work in progress), April 2018.
[ONF-CIM] "Core Information Model", version 1.2 , September 2016, [ONF-CIM] "Core Information Model", version 1.2 , September 2016,
<https://www.opennetworking.org/wp- <https://www.opennetworking.org/wp-
content/uploads/2014/10/TR-512_CIM_(CoreModel)_1.2.zip>. content/uploads/2014/10/TR-512_CIM_(CoreModel)_1.2.zip>.
[ONF-model] [ONF-model]
"Microwave Information Model", version 1.0 , December "Microwave Information Model", version 1.0 , December
2016, 2016,
<https://www.opennetworking.org/images/stories/downloads/ <https://www.opennetworking.org/images/stories/downloads/
sdn-resources/technical-reports/ sdn-resources/technical-reports/
TR-532-Microwave-Information-Model-V1.pdf>. TR-532-Microwave-Information-Model-V1.pdf>.
[PB-YANG] "IEEE 802.1X and 802.1Q Module Specifications", version [PB-YANG] "IEEE 802.1X and 802.1Q Module Specifications", version
0.4 , May 2015, 0.4 , May 2015,
<http://www.ieee802.org/1/files/public/docs2015/ <http://www.ieee802.org/1/files/public/docs2015/
new-mholness-YANG-8021x-0515-v04.pdf>. new-mholness-YANG-8021x-0515-v04.pdf>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
Management", RFC 8022, DOI 10.17487/RFC8022, November YANG Data Model for Hardware Management", RFC 8348,
2016, <https://www.rfc-editor.org/info/rfc8022>. DOI 10.17487/RFC8348, March 2018,
<https://www.rfc-editor.org/info/rfc8348>.
Appendix A. Contributors [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
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
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
skipping to change at page 21, line 4 skipping to change at page 21, line 27
Email: amy.yemin@huawei.com Email: amy.yemin@huawei.com
Xi Li Xi Li
NEC Laboratories Europe NEC Laboratories Europe
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Email: Xi.Li@neclab.eu Email: Xi.Li@neclab.eu
Luis M. Contreras
Luis Contreras
Telefonica I+D Telefonica I+D
Ronda de la Comunicacion, S/N Ronda de la Comunicacion, S/N
Madrid 28050 Madrid 28050
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
Carlos J. Bernardos Carlos Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
Madrid, Leganes 28911 Madrid, Leganes 28911
Spain Spain
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
 End of changes. 57 change blocks. 
140 lines changed or deleted 148 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/