diff options
Diffstat (limited to 'doc/rfc/rfc8432.txt')
| -rw-r--r-- | doc/rfc/rfc8432.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc8432.txt b/doc/rfc/rfc8432.txt new file mode 100644 index 0000000..c474123 --- /dev/null +++ b/doc/rfc/rfc8432.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Ahlberg, Ed. +Request for Comments: 8432 Ericsson AB +Category: Informational M. Ye, Ed. +ISSN: 2070-1721 Huawei Technologies + X. Li + NEC Laboratories Europe + LM. Contreras + Telefonica I+D + CJ. Bernardos + Universidad Carlos III de Madrid + October 2018 + + + A Framework for Management and Control of + Microwave and Millimeter Wave Interface Parameters + +Abstract + + The unification of control and management of microwave radio link + interfaces is a precondition for seamless multi-layer networking and + automated network provisioning and operation. + + This document describes the required characteristics and use cases + for control and management of radio link interface parameters using a + YANG data model. + + The purpose is to create a framework to identify the necessary + information elements and define a YANG data model for control and + management of the radio link interfaces in a microwave node. Some + parts of the resulting model may be generic and could also be used by + other technologies, e.g., Ethernet technology. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8432. + + + + +Ahlberg, et al. Informational [Page 1] + +RFC 8432 Microwave Framework October 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................5 + 2. Terminology and Definitions .....................................5 + 3. Approaches to Manage and Control Radio Link Interfaces ..........7 + 3.1. Network Management Solutions ...............................7 + 3.2. Software-Defined Networking ................................7 + 4. Use Cases .......................................................8 + 4.1. Configuration Management ...................................9 + 4.2. Inventory .................................................10 + 4.3. Status and Statistics .....................................10 + 4.4. Performance Management ....................................10 + 4.5. Fault Management ..........................................11 + 4.6. Troubleshooting and Root Cause Analysis ...................11 + 5. Requirements ...................................................11 + 6. Gap Analysis on Models .........................................12 + 6.1. Microwave Radio Link Functionality ........................13 + 6.2. Generic Functionality .....................................14 + 6.3. Summary ...................................................15 + 7. Security Considerations ........................................16 + 8. IANA Considerations ............................................16 + 9. References .....................................................16 + 9.1. Normative References ......................................16 + 9.2. Informative References ....................................17 + Contributors ......................................................19 + Authors' Addresses ................................................20 + + + + + + + + + +Ahlberg, et al. Informational [Page 2] + +RFC 8432 Microwave Framework October 2018 + + +1. Introduction + + Microwave radio is a technology that uses high-frequency radio waves + to provide high-speed wireless connections that can send and receive + voice, video, and data information. It is a general term used for + systems covering a very large range of traffic capacities, channel + separations, modulation formats, and applications over a wide range + of frequency bands from 1.4 GHz up to and above 100 GHz. + + The main application for microwave is backhaul for mobile broadband. + Those networks will continue to be modernized using a combination of + microwave and fiber technologies. The choice of technology depends + on fiber presence and cost of ownership, not capacity limitations in + microwave. + + Today, microwave is already able to fully support the capacity needs + of a backhaul in a radio access network and will evolve to support + multiple gigabits in traditional frequency bands and more than 10 + gigabits in higher-frequency bands with more bandwidth. Layer 2 (L2) + Ethernet features are normally an integrated part of microwave nodes, + and more advanced L2 and Layer 3 (L3) features will be introduced + over time to support the evolution of the transport services that + will be provided by a backhaul/transport network. Note that wireless + access technologies such as 3/4/5G and Wi-Fi are not within the scope + of this document. + + Open and standardized interfaces are a prerequisite for efficient + management of equipment from multiple vendors, integrated in a single + system/controller. This framework addresses management and control + of the radio link interface(s) and their relationship to other + interfaces (typically, Ethernet interfaces) in a microwave node. A + radio link provides the transport over the air, using one or several + carriers in aggregated or protected configurations. Managing and + controlling a transport service over a microwave node involves both + radio link and packet transport functionality. + + Today, there are already numerous IETF data models, RFCs, and + Internet-Drafts with technology-specific extensions that cover a + large part of the L2 and L3 domains. Examples include IP Management + [RFC8344], Routing Management [RFC8349], and Provider Bridge + [IEEE802.1Qcp]. These are based on the IETF YANG data model for + Interface Management [RFC8343], which is an evolution of the SNMP + IF-MIB [RFC2863]. + + Since microwave nodes will contain more and more L2 and L3 (packet) + functionality that is expected to be managed using those models, + there are advantages if radio link interfaces can be modeled and + managed using the same structure and the same approach. This is + + + +Ahlberg, et al. Informational [Page 3] + +RFC 8432 Microwave Framework October 2018 + + + especially true for use cases in which a microwave node is managed as + one common entity that includes both the radio link and the L2 and L3 + functionality, e.g., basic configuration of the node and connections, + centralized troubleshooting, upgrade, and maintenance. All + interfaces in a node, irrespective of technology, would then be + accessed from the same core model, i.e., [RFC8343], and could be + extended with technology-specific parameters in models augmenting + that core model. The relationship/connectivity between interfaces + could be given by the physical equipment configuration. For example, + the slot where the Radio Link Terminal (modem) is plugged in could be + associated with a specific Ethernet port due to the wiring in the + backplane of the system, or it could be flexible and therefore + configured via a management system or controller. + + +------------------------------------------------------------------+ + | Interface [RFC8343] | + | +---------------+ | + | | Ethernet Port | | + | +---------------+ | + | \ | + | +---------------------+ | + | | Radio Link Terminal | | + | +---------------------+ | + | / \ | + | +---------------------+ +---------------------+ | + | | Carrier Termination | | Carrier Termination | | + | +---------------------+ +---------------------+ | + +------------------------------------------------------------------+ + + Figure 1: Relationship between Interfaces in a Node + + There will always be certain implementations that differ among + products, so it is practically impossible to achieve industry + consensus on every design detail. It is therefore important to focus + on the parameters that are required to support the use cases + applicable for centralized, unified, multi-vendor management and to + allow other parameters to either be optional or be covered by + extensions to the standardized model. Furthermore, a standard that + allows for a certain degree of freedom encourages innovation and + competition, which benefits the entire industry. Thus, it is + important that a radio link management model covers all relevant + functions but also leaves room for product- and feature-specific + extensions. + + Models are available for microwave radio link functionality: + "Microwave Information Model" by the ONF [ONF-MW] and "Microwave + Radio Link YANG Data Models" submitted to and discussed by the CCAMP + Working Group [CCAMP-MW]. The purpose of this document is to reach + + + +Ahlberg, et al. Informational [Page 4] + +RFC 8432 Microwave Framework October 2018 + + + consensus within the industry around one common approach with respect + to the use cases and requirements to be supported, the type and + structure of the model, and the resulting attributes to be included. + This document describes the use cases, requirements, and expected + characteristics of the model. It also includes an analysis of how + the models in the two ongoing initiatives fulfill these expectations + and recommendations for what can be reused and what gaps need to be + filled by a new and evolved model ("A YANG Data Model for Microwave + Radio Link" by the IETF [IETF-MW]). + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Terminology and Definitions + + Microwave radio: a term commonly used for technologies that operate + in both microwave and millimeter wavelengths and in frequency + bands from 1.4 GHz up to and beyond 100 GHz. In traditional + bands, it typically supports capacities of 1-3 Gbps; in the 70/80 + GHz band, it supports up to 10 Gbps. Using multi-carrier systems + operating in frequency bands with wider channels, the technology + will be capable of providing capacities of up to 100 Gbps. + + Microwave radio technology: widely used for point-to-point + telecommunications because its small wavelength allows + conveniently sized antennas to direct radio waves in narrow beams + and its comparatively higher frequencies allow broad bandwidth and + high data-transmission rates. It is used for a broad range of + fixed and mobile services, including high-speed, point-to-point + wireless local area networks (WLANs) and broadband access. + + The ETSI EN 302 217 series defines the characteristics and + requirements of microwave equipment and antennas. In particular, + ETSI EN 302 217-2 [EN302217-2] specifies the essential parameters + for the systems operating from 1.4 GHz to 86 GHz. + + Carrier Termination and Radio Link Terminal: two concepts defined to + support modeling of microwave radio link features and parameters + in a structured yet simple manner. + + * Carrier Termination: an interface for the capacity provided + over the air by a single carrier. It is typically defined by + its transmitting and receiving frequencies. + + + +Ahlberg, et al. Informational [Page 5] + +RFC 8432 Microwave Framework October 2018 + + + * Radio Link Terminal: an interface providing Ethernet capacity + and/or Time Division Multiplexing (TDM) capacity to the + associated Ethernet and/or TDM interfaces in a node. It is + used for setting up a transport service over a microwave radio + link. + + Figure 2 provides a graphical representation of the Carrier + Termination and Radio Link Terminal concepts. + + /--------- Radio Link ---------\ + Near End Far End + + +---------------+ +---------------+ + | Radio Link | | Radio Link | + | Terminal | | Terminal | + | | | | + | (Protected or Bonded) | + | | | | + | +-----------+ | | +-----------+ | + | | | | Carrier A | | | | + | | Carrier | |<--------->| | Carrier | | + | |Termination| | | |Termination| | + ETH----| | | | | | | |----ETH + | +-----------+ | | +-----------+ | + TDM----| | | |----TDM + | +-----------+ | | +-----------+ | + | | | | Carrier B | | | | + | | Carrier | |<--------->| | Carrier | | + | |Termination| | | |Termination| | + | | | | | | | | + | +-----------+ | | +-----------+ | + | | | | + +---------------+ +---------------+ + + \--- Microwave Node ---/ \--- Microwave Node ---/ + + Figure 2: Radio Link Terminal and Carrier Termination + + Software-Defined Networking (SDN): an architecture that decouples + the network control and forwarding functions, enabling the network + control to become directly programmable and the underlying + infrastructure to be abstracted for applications and network + services. SDN can be used for automation of traditional network + management functionality using an SDN approach of standardized + programmable interfaces for control and management [RFC7426]. + + + + + + +Ahlberg, et al. Informational [Page 6] + +RFC 8432 Microwave Framework October 2018 + + +3. Approaches to Manage and Control Radio Link Interfaces + + This framework addresses the definition of an open and standardized + interface for radio link functionality in a microwave node. The + application of such an interface used for management and control of + nodes and networks typically varies from one operator to another in + terms of the systems used and how they interact. Possible approaches + include using a Network Management System (NMS), Software-Defined + Networking (SDN), or some combination of the two. As there are still + many networks where the NMS is implemented as one component/interface + and the SDN controller is scoped to control-plane functionality as a + separate component/interface, this document does not preclude either + model. The aim of this document is to provide a framework for + development of a common YANG data model for both management and + control of microwave interfaces. + +3.1. Network Management Solutions + + The classic network management solutions, with vendor-specific domain + management combined with cross-domain functionality for service + management and analytics, still dominate the market. These solutions + are expected to evolve and benefit from an increased focus on + standardization by simplifying multi-vendor management and removing + the need for vendor- or domain-specific management. + +3.2. Software-Defined Networking + + One of the main drivers for applying SDN from an operator perspective + is simplification and automation of network provisioning as well as + end-to-end network service management. The vision is to have a + global view of the network conditions spanning different vendors' + equipment and multiple technologies. + + If nodes from different vendors are managed by the same SDN + controller via a node management interface without the extra effort + of introducing intermediate systems, all nodes must align their node + management interfaces. Hence, an open and standardized node + management interface is required in a multi-vendor environment. Such + a standardized interface enables unified management and configuration + of nodes from different vendors by a common set of applications. + + In addition to SDN applications for configuring, managing, and + controlling the nodes and their associated transport interfaces + (including the L2 Ethernet, L3 IP, and radio interfaces), there are + also a large variety of more advanced SDN applications that can be + utilized and/or developed. + + + + + +Ahlberg, et al. Informational [Page 7] + +RFC 8432 Microwave Framework October 2018 + + + A potentially flexible approach for operators is to use SDN in a + logically controlled way, managing the radio links by selecting a + predefined operation mode. The operation mode is a set of logical + metrics or parameters describing a complete radio link configuration, + such as capacity, availability, priority, and power consumption. + + An example of an operation mode table is shown in Figure 3. Based on + its operation policy (e.g., power consumption or traffic priority), + the SDN controller selects one operation mode and translates that + into the required configuration of the individual parameters for the + Radio Link Terminals and the associated Carrier Terminations. + + +----+---------------+------------+-------------+-----------+------+ + | ID |Description | Capacity |Availability | Priority |Power | + +----+---------------+------------+-------------+-----------+------+ + | 1 |High capacity | 400 Mbps | 99.9% | Low |High | + +----+---------------+------------+-------------+-----------+------+ + | 2 |High avail- | 100 Mbps | 99.999% | High |Low | + | | ability | | | | | + +----+---------------+------------+-------------+-----------+------+ + + Figure 3: Example of an Operation Mode Table + + An operation mode bundles together the values of a set of different + parameters. How each operation mode maps a certain set of attributes + is out of the scope of this document. + +4. Use Cases + + The use cases described should be the basis for identifying and + defining the parameters to be supported by a YANG data model for + management of radio links that will be applicable to centralized, + unified, multi-vendor management. The use cases involve + configuration management, inventory, status and statistics, + performance management, fault management, and troubleshooting and + root cause analysis. + + Other product-specific use cases, e.g., addressing installation or + on-site troubleshooting and fault resolution, are outside the scope + of this framework. If required, these use cases are expected to be + supported by product-specific extensions to the standardized model. + + + + + + + + + + +Ahlberg, et al. Informational [Page 8] + +RFC 8432 Microwave Framework October 2018 + + +4.1. Configuration Management + + Configuration management involves configuring a Radio Link Terminal, + the constituent Carrier Terminations, and, when applicable, the + relationship to IP/Ethernet and TDM interfaces. + + o Understand the capabilities and limitations + + Exchange of information between a manager and a device about the + capabilities supported and specific limitations in the parameter + values and enumerations that can be used. + + Examples of information that could be exchanged include the + maximum modulation supported and support (or lack of support) for + the Cross Polarization Interference Cancellation (XPIC) feature. + + o Initial Configuration + + Initial configuration of a Radio Link Terminal, enough to + establish Layer 1 (L1) connectivity to an associated Radio Link + Terminal on a device at the far end over the hop. It may also + include configuration of the relationship between a Radio Link + Terminal and an associated traffic interface, e.g., an Ethernet + interface, unless that is given by the equipment configuration. + + Frequency, modulation, coding, and output power are examples of + parameters typically configured for a Carrier Termination and type + of aggregation/bonding or protection configurations expected for a + Radio Link Terminal. + + o Radio link reconfiguration and optimization + + Reconfiguration, update, or optimization of an existing Radio Link + Terminal. Output power and modulation for a Carrier Termination + as well as protection schemas and activation/deactivation of + carriers in a Radio Link Terminal are examples on parameters that + can be reconfigured and used for optimization of the performance + of a network. + + o Radio link logical configuration + + Radio Link Terminals configured to include a group of carriers are + widely used in microwave technology. There are several kinds of + groups: aggregation/bonding, 1+1 protection/redundancy, etc. To + avoid configuration on each Carrier Termination directly, a + logical control provides flexible management by mapping a logical + configuration to a set of physical attributes. This could also be + + + + +Ahlberg, et al. Informational [Page 9] + +RFC 8432 Microwave Framework October 2018 + + + applied in a hierarchical SDN environment where some domain + controllers are located between the SDN controller and the Radio + Link Terminal. + +4.2. Inventory + + o Retrieve logical inventory and configuration from device + + Request from manager and response by device with information about + radio interfaces, e.g., their constitution and configuration. + + o Retrieve physical/equipment inventory from device + + Request from manager about physical and/or equipment inventory + associated with the Radio Link Terminals and Carrier Terminations. + +4.3. Status and Statistics + + o Actual status and performance of a radio link interface + + Manager requests and device responds with information about actual + status and statistics of configured radio link interfaces and + their constituent parts. 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 + + o Configuration of historical performance measurements + + Configuration of historical performance measurements for a radio + link interface and/or its constituent parts. See Section 4.1. + + o Collection of historical performance data + + Collection of historical performance data in bulk by the manager + is a general use case for a device and not specific to a radio + link interface. + + Collection of an individual counter for a specific interval is in + some cases required as a complement to the retrieval in bulk as + described above. + + + + + + + + +Ahlberg, et al. Informational [Page 10] + +RFC 8432 Microwave Framework October 2018 + + +4.5. Fault Management + + o Configuration of alarm reporting + + Configuration of alarm reporting associated specifically with + radio interfaces, e.g., configuration of alarm severity, is a + subset of the configuration use case to be supported. See + Section 4.1. + + o Alarm management + + Alarm synchronization, visualization, handling, notifications, and + events are generic use cases for a device and should be supported + on a radio link interface. There are, however, radio-specific + alarms that are important to report. Signal degradation of the + radio link is one example. + +4.6. Troubleshooting and Root Cause Analysis + + Provide information and suggest actions required by a manager/ + operator to investigate and understand the underlying issue to a + problem in the performance and/or functionality of a Radio Link + Terminal and the associated Carrier Terminations. + +5. Requirements + + For managing a microwave node including both the radio link and the + packet transport functionality, a unified data model is desired to + unify the modeling of the radio link interfaces and the L2/L3 + interfaces using the same structure and the same modeling approach. + If some part of the model is generic for other technology usage, it + should be clearly stated. + + The purpose of the YANG data model is for management and control of + the radio link interface(s) and the relationship/connectivity to + other interfaces, typically to Ethernet interfaces, in a microwave + node. + + The capability of configuring and managing microwave nodes includes + the following requirements for the model: + + 1. It MUST be possible to configure, manage, and control a Radio + Link Terminal and the constituent Carrier Terminations. + + A. Configuration of frequency, channel bandwidth, modulation, + coding, and transmitter output power MUST be supported for a + Carrier Termination. + + + + +Ahlberg, et al. Informational [Page 11] + +RFC 8432 Microwave Framework October 2018 + + + B. A Radio Link Terminal MUST configure the associated Carrier + Terminations and the type of aggregation/bonding or + protection configurations expected for the Radio Link + Terminal. + + C. The capability (e.g., the maximum modulation supported) and + the actual status/statistics (e.g., administrative status of + the carriers) SHOULD also be supported by the data model. + + D. The definition of the features and parameters SHOULD be based + on established microwave equipment and radio standards, such + as ETSI EN 302 217 [EN302217-2], which specifies the + essential parameters for microwave systems operating from 1.4 + GHz to 86 GHz. + + 2. It MUST be possible to map different traffic types (e.g., TDM and + Ethernet) to the transport capacity provided by a specific Radio + Link Terminal. + + 3. It MUST be possible to configure and collect historical + measurements (for the use case described in Section 4.4) to be + performed on a radio link interface (e.g., minimum, maximum, + average transmit power, and received level in dBm). + + 4. It MUST be possible to configure and retrieve alarms reporting + associated with the radio interfaces (e.g., configuration fault, + signal lost, modem fault, and radio fault). + +6. Gap Analysis on Models + + The purpose of the gap analysis is to identify and recommend what + models to use in a microwave device to support the use cases and + requirements specified in the previous sections. This document also + makes a recommendation for how the gaps not supported should be + filled, including the need for development of new models and + evolution of existing models and documents. + + Models are available for microwave radio link functionality: + "Microwave Information Model" by the ONF [ONF-MW] and "Microwave + Radio Link YANG Data Models" submitted to and discussed by the CCAMP + Working Group [CCAMP-MW]. The analysis in this document takes these + initiatives into consideration and makes a recommendation on how to + use and complement them in order to fill the gaps identified. + + For generic functionality, not functionality specific to radio link, + the ambition is to refer to existing or emerging models that could be + applicable for all functional areas in a microwave node. + + + + +Ahlberg, et al. Informational [Page 12] + +RFC 8432 Microwave Framework October 2018 + + +6.1. Microwave Radio Link Functionality + + [ONF-CIM] defines a CoreModel of the ONF Common Information Model. + An information model describes the things in a domain in terms of + objects, their properties (represented as attributes), and their + relationships. The ONF information model is expressed in Unified + Modeling Language (UML). The ONF CoreModel is independent of + specific data-plane technology. The technology-specific content, + acquired in a runtime solution via "filled in" cases of + specification, augments the CoreModel by providing a forwarding + technology-specific representation. + + IETF data models define implementations and protocol-specific + details. YANG is a data modeling language used to model the + configuration and state data. [RFC8343] defines a generic YANG data + model for interface management that doesn't include technology- + specific information. To describe the technology-specific + information, several YANG data models have been proposed in the IETF + to augment [RFC8343], e.g., the data model defined in [RFC8344]. The + YANG data model is a popular approach for modeling interfaces for + many packet transport technologies and is thereby well positioned to + become an industry standard. In light of this trend, [CCAMP-MW] + provides a YANG data model proposal for radio interfaces that is well + aligned with the structure of other technology-specific YANG data + models augmenting [RFC8343]. + + [RFC3444] explains the difference between Information Models (IMs) + and Data Models (DMs). An IM models managed objects at a conceptual + level for designers and operators, while a DM is defined at a lower + level and includes many details for implementers. In addition, the + protocol-specific details are usually included in a DM. Since + conceptual models can be implemented in different ways, multiple DMs + can be derived from a single IM. + + It is recommended to use the structure of the model described in + [CCAMP-MW] as the starting point, since it is a data model providing + the wanted alignment with [RFC8343]. To cover the identified gaps, + it is recommended to define new leafs/parameters and include those in + the new model [IETF-MW] while taking reference from [ONF-CIM]. It is + also recommended to add the required data nodes to describe the + interface layering for the capacity provided by a Radio Link Terminal + and the associated Ethernet and TDM interfaces in a microwave node. + The principles and data nodes for interface layering described in + [RFC8343] should be used as a basis. + + + + + + + +Ahlberg, et al. Informational [Page 13] + +RFC 8432 Microwave Framework October 2018 + + +6.2. Generic Functionality + + For generic functionality, not functionality specific to radio links, + the recommendation is to refer to existing RFCs or emerging Internet- + Drafts according to Figure 4. "[IETF-MW]" is used in Figure 4 for + the cases where the functionality is recommended to be included in + the new model [IETF-MW] as described in Section 6.1. + + +------------------------------------+-----------------------------+ + | Generic Functionality | Recommendation | + | | | + +------------------------------------+-----------------------------+ + |1. Fault Management | | + | | | + | Alarm Configuration | [IETF-MW] | + | | | + | Alarm Notifications/ | [YANG-ALARM] | + | Synchronization | | + +------------------------------------+-----------------------------+ + |2. Performance Management | | + | | | + | Performance Configuration/ | [IETF-MW] | + | Activation | | + | | | + | Performance Collection | [IETF-MW] and XML files | + +------------------------------------+-----------------------------+ + |3. Physical/Equipment Inventory | [RFC8348] | + +------------------------------------+-----------------------------+ + + Figure 4: Recommendation for How to Support Generic Functionality + + Microwave-specific alarm configurations are recommended to be + included in the new model [IETF-MW] and could be based on what is + supported in the models described in [ONF-MW] and [CCAMP-MW]. Alarm + notifications and synchronization are general and are recommended to + be supported by a generic model, such as [YANG-ALARM]. + + Activation of interval counters and thresholds could be a generic + function, but it is recommended to be supported by the new model + [IETF-MW]. It can be based on the models described in [ONF-MW] and + [CCAMP-MW]. + + Collection of interval/historical counters is a generic function that + needs to be supported in a node. File-based collection via the SSH + File Transfer Protocol (SFTP) and collection via NETCONF/YANG + interfaces are two possible options; the recommendation is to include + + + + + +Ahlberg, et al. Informational [Page 14] + +RFC 8432 Microwave Framework October 2018 + + + support for the latter in the new model [IETF-MW]. The models + described in [ONF-MW] and [CCAMP-MW] can also be used as a basis in + this area. + + Physical and/or equipment inventory associated with the Radio Link + Terminals and Carrier Terminations is recommended to be covered by a + generic model for the complete node, e.g., the model defined in + [RFC8348]. It is thereby outside the scope of the new model + [IETF-MW]. + +6.3. Summary + + The conclusions and recommendations from the analysis can be + summarized as follows: + + 1. A new YANG data model for radio link [IETF-MW] should be defined + with enough scope to support the use cases and requirements in + Sections 4 and 5 of this document. + + 2. Use the structure of the model described in [CCAMP-MW] as the + starting point. It augments [RFC8343] and is thereby as required + aligned with the structure of the models for management of the L2 + and L3 domains. + + 3. Use established microwave equipment and radio standards (such as + [EN302217-2], the model described in [CCAMP-MW], and the model + described in [ONF-MW]) as the basis for the definition of the + detailed leafs/ parameters to support the specified use cases and + requirements, proposing new ones to cover identified gaps. + + 4. Add the required data nodes to describe the interface layering + for the capacity provided by a Radio Link Terminal and the + associated Ethernet and TDM interfaces, using the principles and + data nodes for interface layering described in [RFC8343] as a + basis. + + 5. Include support for configuration of microwave-specific alarms in + the new YANG data model [IETF-MW] and rely on a generic model + such as [YANG-ALARM] for notifications and alarm synchronization. + + 6. Use a generic model such as [RFC8348] for physical/equipment + inventory. + + + + + + + + + +Ahlberg, et al. Informational [Page 15] + +RFC 8432 Microwave Framework October 2018 + + +7. Security Considerations + + The configuration information may be considered sensitive or + vulnerable in network environments. Unauthorized access to + configuration data nodes can have a negative effect on network + operations, e.g., interrupting the ability to forward traffic or + increasing the interference level of the network. The status and + inventory reveal some network information that could be very helpful + to an attacker. A malicious attack to that information may result in + a loss of customer data. Security issues concerning the access + control to management interfaces can be generally addressed by + authentication techniques providing origin verification, integrity, + and confidentiality. In addition, 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 + cases where management interfaces are accessible in-band at the + client device or within the microwave transport network domain, + filtering or firewalling techniques can be used to restrict + unauthorized in-band traffic. Additionally, authentication + techniques may be used in all cases. + + This framework describes the requirements and characteristics 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]. + +8. IANA Considerations + + This document has no IANA actions. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + + + + + + +Ahlberg, et al. Informational [Page 16] + +RFC 8432 Microwave Framework October 2018 + + +9.2. Informative References + + [CCAMP-MW] Ahlberg, J., Carlson, J-O., Lund, H-A., Olausson, T., + Ye, M., and M. Vaupotic, "Microwave Radio Link YANG Data + Models", Work in Progress, draft-ahlberg-ccamp-microwave- + radio-link-01, May 2016. + + [EN302217-2] + ETSI, "Fixed Radio Systems; Characteristics and + requirements for point-to-point equipment and antennas; + Part 2: Digital systems operating in frequency bands from + 1 GHz to 86 GHz; Harmonised Standard covering the + essential requirements of article 3.2 of Directive + 2014/53/EU", ETSI EN 302 217-2, V3.1.1, May 2017. + + [IEEE802.1Qcp] + IEEE, "Bridges and Bridged Networks Ammendment: YANG Data + Model", Work in Progress, Draft 2.2, March 2018, + <https://1.ieee802.org/tsn/802-1qcp/>. + + [IETF-MW] Ahlberg, J., Ye, M., Li, X., Spreafico, D., and + M. Vaupotic, "A YANG Data Model for Microwave Radio Link", + Work in Progress, draft-ietf-ccamp-mw-yang-10, October + 2018. + + [ONF-CIM] ONF, "Core Information Model (CoreModel)", ONF + TR-512, version 1.2, September 2016, + <https://www.opennetworking.org/images/stories/downloads/ + sdn-resources/technical-reports/ + TR-512_CIM_(CoreModel)_1.2.zip>. + + [ONF-MW] ONF, "Microwave Information Model", ONF TR-532, version + 1.0, December 2016, + <https://www.opennetworking.org/images/stories/downloads/ + sdn-resources/technical-reports/ + TR-532-Microwave-Information-Model-V1.pdf>. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + <https://www.rfc-editor.org/info/rfc2863>. + + [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between + Information Models and Data Models", RFC 3444, + DOI 10.17487/RFC3444, January 2003, + <https://www.rfc-editor.org/info/rfc3444>. + + + + + + +Ahlberg, et al. Informational [Page 17] + +RFC 8432 Microwave Framework October 2018 + + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., + Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- + Defined Networking (SDN): Layers and Architecture + Terminology", RFC 7426, DOI 10.17487/RFC7426, January + 2015, <https://www.rfc-editor.org/info/rfc7426>. + + [RFC8343] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, + <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>. + + [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A + YANG Data Model for Hardware Management", RFC 8348, + DOI 10.17487/RFC8348, March 2018, + <https://www.rfc-editor.org/info/rfc8348>. + + [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>. + + [YANG-ALARM] + Vallin, S. and M. Bjorklund, "YANG Alarm Module", Work in + Progress, draft-ietf-ccamp-alarm-module-04, October 2018. + + + + + + + + + + + + + + + + + + + +Ahlberg, et al. Informational [Page 18] + +RFC 8432 Microwave Framework October 2018 + + +Contributors + + Marko Vaupotic + Aviat Networks + Motnica 9 + Trzin-Ljubljana 1236 + Slovenia + + Email: Marko.Vaupotic@aviatnet.com + + + Jeff Tantsura + + Email: jefftant.ietf@gmail.com + + + Koji Kawada + NEC Corporation + 1753, Shimonumabe Nakahara-ku + Kawasaki, Kanagawa 211-8666 + Japan + + Email: k-kawada@ah.jp.nec.com + + + Ippei Akiyoshi + NEC + 1753, Shimonumabe Nakahara-ku + Kawasaki, Kanagawa 211-8666 + Japan + + Email: i-akiyoshi@ah.jp.nec.com + + + Daniela Spreafico + Nokia - IT + Via Energy Park, 14 + Vimercate (MI) 20871 + Italy + + Email: daniela.spreafico@nokia.com + + + + + + + + + + +Ahlberg, et al. Informational [Page 19] + +RFC 8432 Microwave Framework October 2018 + + +Authors' Addresses + + Jonas Ahlberg (editor) + Ericsson AB + Lindholmspiren 11 + Goteborg 417 56 + Sweden + + Email: jonas.ahlberg@ericsson.com + + + Min Ye (editor) + Huawei Technologies + No.1899, Xiyuan Avenue + Chengdu 611731 + China + + Email: amy.yemin@huawei.com + + + Xi Li + NEC Laboratories Europe + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + Email: Xi.Li@neclab.eu + + + Luis Contreras + Telefonica I+D + Ronda de la Comunicacion, S/N + Madrid 28050 + Spain + + Email: luismiguel.contrerasmurillo@telefonica.com + + + Carlos J. Bernardos + Universidad Carlos III de Madrid + Av. Universidad, 30 + Madrid, Leganes 28911 + Spain + + Email: cjbc@it.uc3m.es + + + + + + +Ahlberg, et al. Informational [Page 20] + |