--- 1/draft-ietf-ccamp-microwave-framework-03.txt 2017-12-08 00:13:50.591902357 -0800 +++ 2/draft-ietf-ccamp-microwave-framework-04.txt 2017-12-08 00:13:50.639903487 -0800 @@ -1,36 +1,36 @@ CCAMP WG J. Ahlberg Internet-Draft Ericsson AB Intended status: Informational LM. Contreras -Expires: May 6, 2018 TID +Expires: June 11, 2018 TID M.Ye Huawei Technologies CO., Ltd M. Vaupotic Aviat Networks J. Tantsura Individual K. Kawada NEC Corporation X. Li NEC Laboratories Europe I. Akiyoshi NEC CJ. Bernardos UC3M D. Spreafico Nokia - IT - November 12, 2017 + December 8, 2017 A framework for Management and Control of microwave and millimeter wave interface parameters - draft-ietf-ccamp-microwave-framework-03 + draft-ietf-ccamp-microwave-framework-04 Abstract To ensure an efficient data transport, meeting the requirements requested by today's transport services, the unification of control and management of microwave and millimeter wave radio link interfaces is a precondition for seamless multilayer networking and automated network wide provisioning and operation. This document describes the required characteristics and use cases @@ -57,21 +57,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -84,29 +84,31 @@ Table of Contents 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Conventions used in this document . . . . . . . . . . . . . . 7 4. Approaches to manage and control radio link interfaces . . . 8 4.1. Network Management Solutions . . . . . . . . . . . . . . 8 4.2. Software Defined Networking . . . . . . . . . . . . . . . 8 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 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.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.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.3. Status & statistics . . . . . . . . . . . . . . . . . . . 11 - 5.3.1. Actual status & performance of a radio link interface 11 + 5.3. Status and statistics . . . . . . . . . . . . . . . . . . 11 + 5.3.1. Actual status and performance of + a radio link interface . . . . . . . . . . . . . . . 11 5.4. Performance management . . . . . . . . . . . . . . . . . 11 5.4.1. Configuration of historical measurements to be performed . . . . . . . . . . . . . . . . . . . . . . 11 5.4.2. Collection of historical performance data . . . . . . 11 5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 5.5.1. Configuration of alarm reporting . . . . . . . . . . 11 5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 5.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 @@ -215,25 +217,25 @@ Microwave/millimeter wave (hereafter referred to as microwave, but including the frequency bands represented by millimeter wave) are important technologies to fulfill this goal today, but also in the future when demands on capacity and packet features increases. Microwave is already today able to fully support the capacity needs of a backhaul in a radio access network and will evolve to support multiple gigabits in traditional frequency bands and beyond 10 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 the transport services to be provided by a backhaul/transport - network. Note that the wireless access technologies such as 3/4/5G & - WiFi are not within the scope of this microwave model work. + network. Note that the wireless access technologies such as 3/4/5G + and WiFi are not within the scope of this microwave model work. The main application for microwave is backhaul for mobile broadband. Those networks will continue to be modernized using a combination of microwave and fiber technologies. The choice of technology is a question about fiber presence and cost of ownership, not about capacity limitations in microwave. Open and standardized interfaces are a pre-requisite for efficient management of equipment from multiple vendors, integrated in a single system/controller. This framework addresses management and @@ -250,21 +252,21 @@ Management [RFC8022] and Provider Bridge [PB-YANG] They are based on the IETF YANG model for Interface Management [RFC7223], which is an evolution of the SNMP IF-MIB [RFC2863]. Since microwave nodes will contain more and more packet functionality which is expected to be managed using those models, there are advantages if radio link interfaces can be modeled and be managed using the same structure and the same approach, specifically for use cases in which a microwave node are managed as one common 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, irrespective of technology, would then be accessed from the same core model, i.e. [RFC7223], 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, e.g the slot in which 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. @@ -294,21 +296,21 @@ and to allow other parameters to be optional or to be covered by extensions to the standardized model. Furthermore, a standard that allows for a certain degree of freedom encourages innovation and competition which is something that benefits the entire industry. It is therefore important that a radio link management model covers all relevant functions but also leaves room for product/feature-specific extensions. For microwave radio link functionality work has been initiated (ONF: 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, 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 and requirements 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- going initiatives fulfill these expectations and a recommendation on what can be reused and what gaps need to be filled by a new and evolved radio link model. @@ -356,24 +358,24 @@ If nodes from different vendors shall be managed by the same SDN controller via a node management interface (north bound interface, NBI), without the extra effort of introducing intermediate systems, all nodes must align their node management interfaces. Hence, an open and standardized node management interface are required in a multi-vendor environment. Such standardized interface enables a unified management and configuration of nodes from different vendors by a common set of applications. On top of SDN applications to configure, manage and control the - nodes and their associated transport interfaces including the L2 and - L3 packet/Ethernet interfaces as well as the radio interfaces, there - are also a large variety of other more advanced SDN applications - that can be exploited and/or developed. + nodes and their associated transport interfaces including the L2 + Ethernet and L3 packet interfaces as well as the radio interfaces, + there are also a large variety of other more advanced SDN + applications that can be exploited and/or developed. A potential flexible approach for the operators is to use SDN in a logical control way to manage 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), @@ -409,45 +411,45 @@ site trouble shooting 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. 5.1. Configuration Management Configuration of a radio link terminal, the constituent carrier terminations and when applicable the relationship to packet/Ethernet 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 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) feature or not and the maximum modulation supported are two examples on information that could be exchanged. 5.1.2. Initial Configuration Initial configuration of a radio link terminal, enough to establish L1 connectivity over the hop to an associated radio link terminal on a device at far end. 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. -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 terminal. Output power and modulation for a carrier termination and protection schemas and activation/de-activation of carriers in a radio link terminal are examples on parameters that can be re- configured and used for optimization of the performance of a network. 5.1.4. Radio link logical configuration @@ -456,33 +458,33 @@ 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 applied in a hierarchical SDN environment where some domain controllers are located between the SDN controller and the radio link terminal. 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 radio interfaces, their constitution and configuration. 5.2.2. Retrieve physical/equipment inventory from device Request from manager about physical and/or equipment inventory 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 status and statistics of configured radio link interfaces and their constituent parts. 5.4. Performance management 5.4.1. Configuration of historical measurements to be performed Configuration of historical measurements to be performed on a radio @@ -502,21 +504,21 @@ 5.5. Fault Management 5.5.1. 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 5.1 above. 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 radio link interface and should be supported accordingly. 5.6. Troubleshooting and Root Cause Analysis Information and 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. @@ -588,21 +590,21 @@ take these initiatives into consideration and make a recommendation on how to make use of them and how to complement them in order to fill the gaps identified. For generic functionality, not specific for radio link, the ambition is to refer to existing or emerging models that could be applicable for all functional areas in a microwave node. 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 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. Data plane technology specific properties are acquired in a runtime solution via "filled in" cases of specification (LtpSpec etc). These can be used to augment the CoreModel to provide a data plane technology specific representation. IETF Data Model defines an implementation and NETCONF-specific @@ -625,21 +627,21 @@ conceptual models can be implemented in different ways, multiple DMs can be derived from a single IM. To ensure better interoperability, it is better to focus on DM directly. [RFC7223] describes an interface management model, however it doesn't include technology specific information, e.g., for radio interface. [I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal for radio interfaces, which includes support for basic configuration, status and performance but lacks full support for alarm management 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. The recommendation is to use the structure of the IETF: Radio Link Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point, since it is a data model providing the wanted alignment with [RFC7223]. For the definition of the detailed leafs/parameters, the recommendation is to use the IETF: Radio Link Model and the ONF: Microwave Modeling [ONF-model] as the basis and to define new ones to cover identified gaps. The parameters in those models have been defined by both operators and vendors within the industry and the @@ -671,35 +673,35 @@ | Alarm Configuration | New Radio Link Model | | | | | Alarm notifications/ | [I-D.vallin-ccamp- | | synchronization | alarm-module] | +------------------------------------+-----------------------------+ |2.Performance Management | | | | | | Performance Configuration/ | New Radio Link Model | | Activation | | | | | - | Performance Collection | New Radio Link Model & | + | Performance Collection | New Radio Link Model and | | | XML files | +------------------------------------+-----------------------------+ |3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] | +------------------------------------+-----------------------------+ Figure 4. Recommendation on how to support generic functionality Microwave specific alarm configurations are recommended to be 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 and synchronization are general and is recommended to be supported 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 specific model and can be based on both the ONF and IETF Microwave Radio Link models. Collection of interval/historical counters is a generic function that needs to be supported in a node. File based collection via SFTP and collection via a Netconf/YANG interfaces are two possible options and the recommendation is to include support for the latter in the new radio link specific model. The ONF and IETF Microwave Radio Link models can be used as a basis also in this area. @@ -833,24 +835,30 @@ Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model for Layer 1 (ODU) Network Topology", draft-zhang-ccamp-l1- topo-yang-03 (work in progress), July 2016. [I.D.ietf-ospf-yang] Yeung D., Qu Y., Zhang J., Bogdanovic D., Sreenivasa K., "Yang Data Model for OSPF Protocol", draft-ietf-ospf-yang- 05,(work in progress), July 2016. [ONF-model] - "Microwave Modeling - ONF Wireless Transport Group", May - 2016. + ONF TR-532, "Microwave Information Model", version 1.0, + December 2016, available at + https://www.opennetworking.org/images/stories/downloads/ + sdn-resources/technical-reports/TR-532-Microwave- + Information-Model-V1.pdf - [ONF CIM] "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 2015. [EN 302 217-2] ETSI, "Fixed Radio Systems; Characteristics and requirements for point to-point equipment and antennas; Part 2: Digital systems operating in frequency bands from 1 GHz to 86 GHz; Harmonised Standard covering the essential requirements of article 3.2 of Directive