draft-ietf-ccamp-microwave-framework-02.txt   draft-ietf-ccamp-microwave-framework-03.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: April 23, 2018 TID Expires: May 6, 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
October 20, 2017 November 12, 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-02 draft-ietf-ccamp-microwave-framework-03
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 April 23, 2018. This Internet-Draft will expire on May 6, 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 . . . . . . 10 5.1.1. Understand the capabilities & 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 & 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 & configuration from device 10
5.2.2. Retrieve physical/equipment inventory from device . . 11 5.2.2. Retrieve physical/equipment inventory from device . . 10
5.3. Status & statistics . . . . . . . . . . . . . . . . . . . 11 5.3. Status & statistics . . . . . . . . . . . . . . . . . . . 11
5.3.1. Actual status & performance of a radio link interface 11 5.3.1. Actual status & 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
7.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 7.1. Microwave Radio Link Functionality . . . . . . . . . . . 13
7.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14 7.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14
7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Terminology and Definitions 1. Terminology and Definitions
Microwave is a band of spectrum with wavelengths ranging from 1 Microwave is a band of spectrum with wavelengths ranging from 1
meter to 1 millimeter and with frequencies ranging between 300 MHz meter to 1 millimeter and with frequencies ranging between 300 MHz
and 300 GHz. Microwave radio technology is widely used for point-to- and 300 GHz. Microwave radio technology is widely used for point-to-
point telecommunications because of their small wavelength that point telecommunications because of their small wavelength that
allows conveniently-sized antennas to direct them in narrow beams, allows conveniently-sized antennas to direct them in narrow beams,
and their comparatively higher frequencies that allows broad and their comparatively higher frequencies that allows broad
bandwidth and high data transmission rates. bandwidth and high data transmission rates.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
packet interfaces, typically to Ethernet interfaces, in a microwave packet interfaces, typically to Ethernet interfaces, in a microwave
node. A radio link provides the transport over the air, using one or node. A radio link provides the transport over the air, using one or
several carriers in aggregated or protected configurations. several carriers in aggregated or protected configurations.
Managing and controlling a transport service over a microwave node Managing and controlling a transport service over a microwave node
involves both radio link and packet functionality. involves both radio link and packet functionality.
Already today there are numerous IETF data models, RFCs and drafts, Already today there are numerous IETF data models, RFCs and drafts,
with technology specific extensions that cover a large part of the with technology specific extensions that cover a large part of the
packet domain. Examples are IP Management [RFC7277], Routing packet domain. Examples are IP Management [RFC7277], Routing
Management [RFC8022] and Provider Bridge [PB-YANG] They are based Management [RFC8022] and Provider Bridge [PB-YANG] They are based
on RFC 7223 [RFC7223], which is the IETF YANG model for Interface on the IETF YANG model for Interface Management [RFC7223], which is
Management, and 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 & 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. RFC 7223, 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.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Interface [RFC7223] | | Interface [RFC7223] |
skipping to change at page 7, line 52 skipping to change at page 7, line 52
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.
3. Conventions used in this document 3. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
While [RFC2119] describes interpretations of these key words in While [RFC2119] describes interpretations of these key words in
terms of protocol specifications and implementations, they are used terms of protocol specifications and implementations, they are used
in this document to describe requirements for the YANG Data Model in this document to describe requirements for the YANG Data Model
for Microwave Radio Link. for Microwave Radio Link.
4. Approaches to manage and control radio link interfaces 4. Approaches to manage and control radio link interfaces
This framework addresses the definition of an open and standardized This framework addresses the definition of an open and standardized
interface for the radio link functionality in a microwave/millimeter interface for the radio link functionality in a microwave/millimeter
skipping to change at page 13, line 42 skipping to change at page 13, line 42
Modeling Language (UML). The ONF CoreModel is independent of Modeling Language (UML). The ONF CoreModel is independent of
specific data plane technology. Data plane technology specific specific data plane technology. Data plane technology specific
properties are acquired in a runtime solution via "filled in" cases properties are acquired in a runtime solution via "filled in" cases
of specification (LtpSpec etc). These can be used to augment the of specification (LtpSpec etc). These can be used to augment the
CoreModel to provide a data plane technology specific representation. CoreModel to provide a data plane technology specific representation.
IETF Data Model defines an implementation and NETCONF-specific IETF Data Model defines an implementation and NETCONF-specific
details. YANG is a data modeling language used to model the details. YANG is a data modeling language used to model the
configuration and state data. It is well aligned with the structure configuration and state data. It is well aligned with the structure
of the Yang data models proposed for the different packet interfaces of the Yang data models proposed for the different packet interfaces
which are all based on RFC 7223. Furthermore, several YANG data which are all based on [RFC7223]. Furthermore, several YANG data
models have been proposed in the IETF for other transport models have been proposed in the IETF for other transport
technologies such as optical transport; e.g., RFC 7277 [RFC7277], technologies such as optical transport; e.g. [RFC7277],
[I.D.zhang-ccamp-l1-topo-yang], [I.D.ietf-ospf-yang]. In light of [I.D.zhang-ccamp-l1-topo-yang], [I.D.ietf-ospf-yang]. In light of
this trend, the IETF data model is becoming a popular approach for 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.
RFC 3444 [RFC3444] explains the difference between Information [RFC3444] explains the difference between Information Model(IM) and
Model(IM) and Data Models(DM). IM is to model managed objects at a Data Models(DM). IM is to model managed objects at a conceptual level
conceptual level for designers and operators, DM is defined at a for designers and operators, DM is defined at a lower level and
lower level and includes many details for implementers. In addition, includes many details for implementers. In addition, the
the protocol-specific details are usually included in DM. Since protocol-specific details are usually included in DM. Since
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.
RFC 7223 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 & 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 RFC since it is a data model providing the wanted alignment with
7223. 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
implementations of the ONF Model have been tested in the Proof of implementations of the ONF Model have been tested in the Proof of
Concept events in multi-vendor environments, showing the validity of Concept events in multi-vendor environments, showing the validity of
the approach proposed in this framework document. the approach proposed in this framework document.
It is also recommended to add the required data nodes to describe It is also recommended to add the required data nodes to describe
the interface layering for the capacity provided by a radio link the interface layering for the capacity provided by a radio link
terminal and the associated Ethernet and TDM interfaces in a terminal and the associated Ethernet and TDM interfaces in a
microwave node. The principles and data nodes for interface layering microwave node. The principles and data nodes for interface layering
described in RFC 7223 should be used as a basis. described in [RFC7223] should be used as a basis.
7.2. Generic Functionality 7.2. Generic Functionality
For generic functionality, not specific for radio link, the For generic functionality, not specific for radio link, the
recommendation is to refer to existing RFCs or emerging drafts recommendation is to refer to existing RFCs or emerging drafts
according to the table in figure 4 below. New Radio Link Model is according to the table in figure 4 below. New Radio Link Model is
used in the table for the cases where the functionality is used in the table for the cases where the functionality is
recommended to be included in the new radio link model as described recommended to be included in the new radio link model as described
in chapter 7.1. in chapter 7.1.
skipping to change at page 16, line 16 skipping to change at page 16, line 16
The conclusions and recommendations from the analysis can be The conclusions and recommendations from the analysis can be
summarized as follows: summarized as follows:
1) A Microwave Radio Link YANG Data Model should be defined with a 1) A Microwave Radio Link YANG Data Model should be defined with a
scope enough to support the use cases and requirements in scope enough to support the use cases and requirements in
chapter 5 and 6 of this document. chapter 5 and 6 of this document.
2) Use the structure in the IETF: Radio Link Model [I-D.ahlberg- 2) Use the structure in the IETF: Radio Link Model [I-D.ahlberg-
ccamp-microwave-radio-link] as the starting point. It augments ccamp-microwave-radio-link] as the starting point. It augments
RFC 7223 and is thereby as required aligned with the structure [RFC7223] and is thereby as required aligned with the structure
of the models for management of the packet domain. of the models for management of the packet domain.
3) Use established microwave equipment and radio standards, such 3) Use established microwave equipment and radio standards, such
as ETSI EN 302 217 [EN 302 217-2], and the IETF: Radio Link as [EN 302 217-2], and the IETF: Radio Link Model
Model [I-D.ahlberg-ccamp-microwave-radio-link] and the [I-D.ahlberg-ccamp-microwave-radio-link] and the
ONF: Microwave Modeling [ONF-model] as the basis for the ONF: Microwave Modeling [ONF-model] as the basis for the
definition of the detailed leafs/parameters to support the definition of the detailed leafs/parameters to support the
specified use cases and requirements, and proposing new ones specified use cases and requirements, and proposing new ones
to cover identified gaps. to cover identified gaps.
4) Add the required data nodes to describe the interface layering 4) Add the required data nodes to describe the interface layering
for the capacity provided by a radio link terminal and the for the capacity provided by a radio link terminal and the
associated Ethernet and TDM interfaces, using the principles associated Ethernet and TDM interfaces, using the principles
and data nodes for interface layering described in RFC 7223 as and data nodes for interface layering described in [RFC7223] as
a basis. a basis.
5) Include support for configuration of microwave specific alarms 5) Include support for configuration of microwave specific alarms
in the Microwave Radio Link model and rely on a generic model in the Microwave Radio Link model and rely on a generic model
such as [I.D.vallin-ccamp-alarm-module] for notifications and such as [I.D.vallin-ccamp-alarm-module] for notifications and
alarm synchronization. alarm synchronization.
6) Use a generic model such as [I-D.ietf-netmod-entity] for 6) Use a generic model such as [I-D.ietf-netmod-entity] for
physical/equipment inventory. physical/equipment inventory.
It is furthermore recommended that the Microwave Radio Link YANG It is furthermore recommended that the Microwave Radio Link YANG
Date Model should be validated by both operators and vendors as Date Model should be validated by both operators and vendors as
part of the process to make it stable and mature. During the part of the process to make it stable and mature. During the
Hackathon in IETF 99, a project "SDN Applications for microwave Hackathon in IETF 99, a project "SDN Applications for microwave
radio link via IETF YANG Data Model" successfully validated this radio link via IETF YANG Data Model" successfully validated this
framework and the YANG data model[I.D.ietf-ccamp-mw-yang]. The framework and the YANG data model[I.D.ietf-ccamp-mw-yang]. The
project also received the BEST OVERALL award from the Hackathon. project also received the BEST OVERALL award from the Hackathon.
8. Security Considerations 8. Security Considerations
TBD Security issue concerning the access control to Management interfaces
can be generally addressed by authentication techniques providing
origin verification, integrity and confidentiality. In additon,
management interfaces can be physically or logically isolated,
by configuring them to be only accessible out-of-band, through
a system that is physically or logically separated from the rest of
the network infrastructure. In case where management interfaces are
accessible in-band at the client device or within the microwave
transport netork domain, filtering or firewalling techniques
can be used to restrict unauthorized in-band traffic. Authentication
techniques may be additionally used in all cases.
This framework describes the requirements and charactersitics of
of a YANG Data Model for control and management of the radio link
interfaces in a microwave node. It is supposed to be accessed via a
management protocol with a secure transport layer, such as NETCONF
[RFC6241].
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 17, line 31 skipping to change at page 18, line 5
<http://www.rfc-editor.org/info/rfc3444>. <http://www.rfc-editor.org/info/rfc3444>.
[RFC7223] Bjorklund M., "A YANG Data Model for Interface [RFC7223] Bjorklund M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <http://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund M., "A YANG Data Model for IP Management", RFC [RFC7277] Bjorklund M., "A YANG Data Model for IP Management", RFC
7277, DOI 10.17487/RFC7277, June 2014, 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>. <http://www.rfc-editor.org/info/rfc7277>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
10.2. Informative References 10.2. Informative References
[I-D.ahlberg-ccamp-microwave-radio-link] [I-D.ahlberg-ccamp-microwave-radio-link]
Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M.,
and M. Vaupotic, "Microwave Radio Link YANG Data Models", and M. Vaupotic, "Microwave Radio Link YANG Data Models",
draft-ahlberg-ccamp-microwave-radio-link-01 (work in draft-ahlberg-ccamp-microwave-radio-link-01 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-netmod-entity] [I-D.ietf-netmod-entity]
Bierman A., Bjorklund M., Dong J., Romascanu D., "A YANG Bierman A., Bjorklund M., Dong J., Romascanu D., "A YANG
Data Model for Entity Management", draft-ietf-netmod- Data Model for Entity Management", draft-ietf-netmod-
entity-05 (work in progress), October 2017. entity-05 (work in progress), October 2017.
[I-D.vallin-ccamp-alarm-module] [I-D.vallin-ccamp-alarm-module]
Vallin S. and Bjorklund M., "YANG Alarm Module", draft- Vallin S. and Bjorklund M., "YANG Alarm Module", draft-
vallin-ccamp-alarm-module-00 (work in progress), October vallin-ccamp-alarm-module-01 (work in progress), October
2017. 2017.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, DOI 10.17487/RFC8022, November 2016 Management", RFC 8022, DOI 10.17487/RFC8022, November 2016
[I.D.zhang-ccamp-l1-topo-yang] [I.D.zhang-ccamp-l1-topo-yang]
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 "Microwave Modeling - ONF Wireless Transport Group", May
2016. 2016.
[ONF CIM] [ONF CIM] "Core Information Model", ONF TR-512, ONF, September 2016
"Core Information Model", ONF TR-512, ONF, September 2016
[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. 24 change blocks. 
33 lines changed or deleted 52 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/