draft-ietf-ccamp-microwave-framework-03.txt   draft-ietf-ccamp-microwave-framework-04.txt 
CCAMP WG J. Ahlberg CCAMP WG J. Ahlberg
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Informational LM. Contreras Intended status: Informational LM. Contreras
Expires: May 6, 2018 TID Expires: June 11, 2018 TID
M.Ye M.Ye
Huawei Technologies CO., Ltd Huawei Technologies CO., Ltd
M. Vaupotic M. Vaupotic
Aviat Networks Aviat Networks
J. Tantsura J. Tantsura
Individual Individual
K. Kawada K. Kawada
NEC Corporation NEC Corporation
X. Li X. Li
NEC Laboratories Europe NEC Laboratories Europe
I. Akiyoshi I. Akiyoshi
NEC NEC
CJ. Bernardos CJ. Bernardos
UC3M UC3M
D. Spreafico D. Spreafico
Nokia - IT Nokia - IT
November 12, 2017 December 8, 2017
A framework for Management and Control of microwave and A framework for Management and Control of microwave and
millimeter wave interface parameters millimeter wave interface parameters
draft-ietf-ccamp-microwave-framework-03 draft-ietf-ccamp-microwave-framework-04
Abstract Abstract
To ensure an efficient data transport, meeting the requirements To ensure an efficient data transport, meeting the requirements
requested by today's transport services, the unification of control requested by today's transport services, the unification of control
and management of microwave and millimeter wave radio link interfaces and management of microwave and millimeter wave radio link interfaces
is a precondition for seamless multilayer networking and automated is a precondition for seamless multilayer networking and automated
network wide provisioning and operation. network wide provisioning and operation.
This document describes the required characteristics and use cases This document describes the required characteristics and use cases
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 http://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 May 6, 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) 2017 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 (http://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 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions used in this document . . . . . . . . . . . . . . 7 3. Conventions used in this document . . . . . . . . . . . . . . 7
4. Approaches to manage and control radio link interfaces . . . 8 4. Approaches to manage and control radio link interfaces . . . 8
4.1. Network Management Solutions . . . . . . . . . . . . . . 8 4.1. Network Management Solutions . . . . . . . . . . . . . . 8
4.2. Software Defined Networking . . . . . . . . . . . . . . . 8 4.2. Software Defined Networking . . . . . . . . . . . . . . . 8
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Configuration Management . . . . . . . . . . . . . . . . 9 5.1. Configuration Management . . . . . . . . . . . . . . . . 9
5.1.1. Understand the capabilities & limitations . . . . . . 9 5.1.1. Understand the capabilities and limitations . . . . . 9
5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10
5.1.3. Radio link re-configuration & optimization . . . . . 10 5.1.3. Radio link re-configuration and optimization . . . . 10
5.1.4. Radio link logical configuration . . . . . . . . . . 10 5.1.4. Radio link logical configuration . . . . . . . . . . 10
5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Retrieve logical inventory & configuration from device 10 5.2.1. Retrieve logical inventory and configuration
from device . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Retrieve physical/equipment inventory from device . . 10 5.2.2. Retrieve physical/equipment inventory from device . . 10
5.3. Status & statistics . . . . . . . . . . . . . . . . . . . 11 5.3. Status and statistics . . . . . . . . . . . . . . . . . . 11
5.3.1. Actual status & performance of a radio link interface 11 5.3.1. Actual status and performance of
a radio link interface . . . . . . . . . . . . . . . 11
5.4. Performance management . . . . . . . . . . . . . . . . . 11 5.4. Performance management . . . . . . . . . . . . . . . . . 11
5.4.1. Configuration of historical measurements to be 5.4.1. Configuration of historical measurements to be
performed . . . . . . . . . . . . . . . . . . . . . . 11 performed . . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Collection of historical performance data . . . . . . 11 5.4.2. Collection of historical performance data . . . . . . 11
5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11
5.5.1. Configuration of alarm reporting . . . . . . . . . . 11 5.5.1. Configuration of alarm reporting . . . . . . . . . . 11
5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11
5.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 5.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 6, line 9 skipping to change at page 6, line 9
Microwave/millimeter wave (hereafter referred to as microwave, but Microwave/millimeter wave (hereafter referred to as microwave, but
including the frequency bands represented by millimeter wave) are including the frequency bands represented by millimeter wave) are
important technologies to fulfill this goal today, but also in the important technologies to fulfill this goal today, but also in the
future when demands on capacity and packet features increases. future when demands on capacity and packet features increases.
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 the millimeter wave. L2 packet features are normally an gigabits in the millimeter wave. L2 packet features are normally an
integrated part of microwave nodes and more advanced L2 & L3 integrated part of microwave nodes and more advanced L2 and L3
features will over time be introduced to support the evolution of features will over time be introduced to support the evolution of
the transport services to be provided by a backhaul/transport the transport services to be provided by a backhaul/transport
network. Note that the wireless access technologies such as 3/4/5G & network. Note that the wireless access technologies such as 3/4/5G
WiFi are not within the scope of this microwave model work. 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.
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 system/controller. This framework addresses management and single system/controller. This framework addresses management and
skipping to change at page 6, line 44 skipping to change at page 6, line 44
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 which is expected to be managed using those models, functionality which is expected to be managed using those models,
there are advantages if radio link interfaces can be modeled and be there are advantages if radio link interfaces can be modeled and be
managed using the same structure and the same approach, specifically managed using the same structure and the same approach, specifically
for use cases in which a microwave node are managed as one common for use cases in which a microwave node are managed as one common
entity including both the radio link and the packet functionality, entity including both the radio link and the packet functionality,
e.g. at basic configuration of node & connections, centralized e.g. at basic configuration of node and connections, centralized
trouble 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 irrespective of technology, would then be accessed from the same
core model, i.e. [RFC7223], and could be extended with technology core model, i.e. [RFC7223], and could be extended with technology
specific parameters in models augmenting that core model. The specific parameters in models augmenting that core model. The
relationship/connectivity between interfaces could be given by the relationship/connectivity between interfaces could be given by the
physical equipment configuration, e.g the slot in which the Radio physical equipment configuration, e.g the slot in which the Radio
Link Terminal (modem) is plugged in could be associated with a Link Terminal (modem) is plugged in could be associated with a
specific Ethernet port due to the wiring in the backplane of the specific Ethernet port due to the wiring in the backplane of the
system, or it could be flexible and therefore configured via a system, or it could be flexible and therefore configured via a
management system or controller. management system or controller.
skipping to change at page 7, line 37 skipping to change at page 7, line 37
and to allow other parameters to be optional or to be covered by and to allow other parameters to be optional or to be covered by
extensions to the standardized model. Furthermore, a standard that extensions to the standardized model. Furthermore, a standard that
allows for a certain degree of freedom encourages innovation and allows for a certain degree of freedom encourages innovation and
competition which is something that benefits the entire industry. It competition which is something that benefits the entire industry. It
is therefore important that a radio link management model covers all is therefore important that a radio link management model covers all
relevant functions but also leaves room for product/feature-specific relevant 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 [I-
D.ahlbergccamp-microwave-radio-link]. The purpose of this effort is D.ahlbergccamp-microwave-radio-link]). The purpose of this effort is
to reach consensus within the industry around one common approach, to reach consensus within the industry around one common approach,
with respect to the use cases and requirements to be supported, the with respect to the use cases and requirements to be supported, the
type and structure of the model and the resulting attributes to be type and structure of the model and the resulting attributes to be
included. This document describes the use cases and requirements included. This document describes the use cases and requirements
agreed to be covered, the expected characteristics of the model and agreed to be covered, the expected characteristics of the model and
at the end includes an analysis of how the models in the two on- at the end includes an analysis of how the models in the two on-
going initiatives fulfill these expectations and a recommendation on going initiatives fulfill these expectations and a recommendation on
what can be reused and what gaps need to be filled by a new and what can be reused and what gaps need to be filled by a new and
evolved radio link model. evolved radio link model.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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 and their associated transport interfaces including the L2 and nodes and their associated transport interfaces including the L2
L3 packet/Ethernet interfaces as well as the radio interfaces, there Ethernet and L3 packet interfaces as well as the radio interfaces,
are also a large variety of other more advanced SDN applications there are also a large variety of other more advanced SDN
that can be exploited and/or developed. applications that can 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, such as capacity, availability, priority and power configuration, 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),
skipping to change at page 9, line 46 skipping to change at page 9, line 46
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 5.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 & limitations 5.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 & 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 5.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 aggregation/bonding or protection configurations expected for a of aggregation/bonding or protection configurations expected for a
radio link terminal. radio link terminal.
5.1.3. Radio link re-configuration & optimization 5.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 5.1.4. Radio link logical configuration
skipping to change at page 10, line 42 skipping to change at page 10, line 42
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 provides flexible management by mapping a logical control provides flexible management by mapping a logical
configuration to a set of physical attributes. This could also be configuration to a set of physical attributes. This could also be
applied in a hierarchical SDN environment where some domain applied in a hierarchical SDN environment where some domain
controllers are located between the SDN controller and the radio controllers are located between the SDN controller and the radio
link terminal. link terminal.
5.2. Inventory 5.2. Inventory
5.2.1. Retrieve logical inventory & configuration from device 5.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 5.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 & statistics 5.3. Status and statistics
5.3.1. Actual status & performance of a radio link interface 5.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 5.4. Performance management
5.4.1. Configuration of historical measurements to be performed 5.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
skipping to change at page 11, line 41 skipping to change at page 11, line 41
5.5. Fault Management 5.5. Fault Management
5.5.1. Configuration of alarm reporting 5.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 5.1 above.
5.5.2. Alarm management 5.5.2. Alarm management
Alarm synchronization, visualization & handling, and notifications & 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 link interface and should be supported accordingly. radio link interface and should be supported accordingly.
5.6. Troubleshooting and Root Cause Analysis 5.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 and understand the underlying issue to a problem in the investigate and understand the underlying issue to a problem in the
performance and/or functionality of a radio link terminal and the performance and/or functionality of a radio link terminal and the
associated carrier terminations. associated carrier terminations.
skipping to change at page 13, line 28 skipping to change at page 13, line 28
take these initiatives into consideration and make a recommendation take these initiatives into consideration and make a recommendation
on how to make use of them and how to complement them in order to on how to make use of them and how to complement them in order to
fill the gaps identified. 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 7.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
skipping to change at page 14, line 11 skipping to change at page 14, line 11
conceptual models can be implemented in different ways, multiple DMs conceptual models can be implemented in different ways, multiple DMs
can be derived from a single IM. To ensure better interoperability, can be derived from a single IM. To ensure better interoperability,
it is better to focus on DM directly. it is better to 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 & 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 cover identified gaps. The parameters in those models have been to 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
skipping to change at page 15, line 21 skipping to change at page 15, line 21
| Alarm Configuration | New Radio Link Model | | Alarm Configuration | New Radio Link Model |
| | | | | |
| Alarm notifications/ | [I-D.vallin-ccamp- | | Alarm notifications/ | [I-D.vallin-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 & | | 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 a generic model, such as [I-D.vallin-ccamp-alarm-module]. by a generic model, such as [I-D.vallin-ccamp-alarm-module].
Activation of interval counters & 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 needs to be supported in a node. File based collection via SFTP that needs to be supported in a node. File based collection via SFTP
and collection via a Netconf/YANG interfaces are two possible and collection via a Netconf/YANG interfaces are two possible
options and the recommendation is to include support for the latter options and the recommendation is to include support for the latter
in the new radio link specific model. The ONF and IETF Microwave in the new radio link specific model. The ONF and IETF Microwave
Radio Link models can be used as a basis also in this area. Radio Link models can be used as a basis also in this area.
skipping to change at page 18, line 41 skipping to change at page 18, line 41
Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model
for Layer 1 (ODU) Network Topology", draft-zhang-ccamp-l1- for Layer 1 (ODU) Network Topology", draft-zhang-ccamp-l1-
topo-yang-03 (work in progress), July 2016. topo-yang-03 (work in progress), July 2016.
[I.D.ietf-ospf-yang] [I.D.ietf-ospf-yang]
Yeung D., Qu Y., Zhang J., Bogdanovic D., Sreenivasa K., Yeung D., Qu Y., Zhang J., Bogdanovic D., Sreenivasa K.,
"Yang Data Model for OSPF Protocol", draft-ietf-ospf-yang- "Yang Data Model for OSPF Protocol", draft-ietf-ospf-yang-
05,(work in progress), July 2016. 05,(work in progress), July 2016.
[ONF-model] [ONF-model]
"Microwave Modeling - ONF Wireless Transport Group", May ONF TR-532, "Microwave Information Model", version 1.0,
2016. December 2016, available at
https://www.opennetworking.org/images/stories/downloads/
sdn-resources/technical-reports/TR-532-Microwave-
Information-Model-V1.pdf
[ONF CIM] "Core Information Model", ONF TR-512, ONF, September 2016 [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 [PB-YANG] "IEEE 802.1X and 802.1Q YANG models", Marc,H., October
2015. 2015.
[EN 302 217-2] [EN 302 217-2]
ETSI, "Fixed Radio Systems; Characteristics and ETSI, "Fixed Radio Systems; Characteristics and
requirements for point to-point equipment and antennas; requirements for point to-point equipment and antennas;
Part 2: Digital systems operating in frequency bands from Part 2: Digital systems operating in frequency bands from
1 GHz to 86 GHz; Harmonised Standard covering the 1 GHz to 86 GHz; Harmonised Standard covering the
essential requirements of article 3.2 of Directive essential requirements of article 3.2 of Directive
 End of changes. 26 change blocks. 
32 lines changed or deleted 40 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/