CCAMP WG J. Ahlberg Internet-Draft Ericsson AB Intended status: Informational LM. Contreras Expires: January 9, 2017 TID A. Ye Min Huawei M. Vaupotic Aviat Networks J. Tantsura Individual K. Kawada NEC Corporation X. Li NEC Laboratories Europe I. Akiyoshi NEC July 8, 2016 A framework for Management and Control of microwave and millimeter wave interface parameters - problem statement draft-mwdt-ccamp-problem-statement-00 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 for control and management of radio link interface parameters using a YANG Data Model. It focuses on the benefits of a standardized management model that is aligned with how other packet technology interfaces in a microwave/millimeter wave node are modeled, the need to support core parameters and at the same time allow for optional product/feature specific parameters supporting new, unique innovative features until they have become mature enough to be included in the standardized model. The purpose is to create a framework for identification of the necessary information elements and definition of a YANG Data Model for control and management of the radio link interfaces in a microwave/millimeter wave node. Ahlberg, et al. Expires January 9, 2017 [Page 1] Internet-Draft Problem Statement July 2016 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 January 9, 2017. Copyright Notice Copyright (c) 2016 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 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 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 4. Application . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Network Management Solutions . . . . . . . . . . . . . . 7 4.2. Software Defined Networking . . . . . . . . . . . . . . . 7 4.2.1. SDN example of radio link configuration . . . . . . . 7 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Configuration Management . . . . . . . . . . . . . . . . 9 5.1.1. Understand the capabilities and limitations . . . . . 10 5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 5.1.3. Radio link re-configuration and optimization . . . . 10 5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Retrieve logical inventory and configuration from Ahlberg, et al. Expires January 9, 2017 [Page 2] Internet-Draft Problem Statement July 2016 device . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Retrieve logical inventory and configuration from device . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Status and statistics . . . . . . . . . . . . . . . . . . 10 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.5.3. Troubleshooting and Root Cause Analysis . . . . . . . 11 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Network requirements vary between operators globally as well as within individual countries. The overall goal is however the same - to deliver the best possible network performance and quality of experience in a cost-efficient way. 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 gigabit in the millimeter wave. L2 packet features are normally an 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. 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. In 2020, more than 65% of all cell sites are expected to be connected with microwave solutions. Ahlberg, et al. Expires January 9, 2017 [Page 3] Internet-Draft Problem Statement July 2016 Open and standardized interfaces are a pre-requisite for efficient management of equipment from multiple vendors. This framework addresses management and control of the radio link interface(s) and the relationship to other packet interfaces, typically to 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 functionality. Already today there are numerous IETF data models, RFCs and drafts, with technology specific extensions that cover a large part of the packet domain. Examples are IP Management [RFC7277], Routing Management [I-D.ietf-netmod-routing-cfg] and Provider Bridge [PB- YANG]. They are based on RFC 7223 [RFC7223], which is the IETF YANG model for Interface Management, and is an evolution of the SNMP IF- MIB [RFC 2863]. Since microwave nodes will contain more and more packet functionality and the interfaces for those technologies are 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 installation, initial setup, trouble shooting, upgrade and maintenance. All interfaces in a node, irrespective of technology, would then be accessed from the same core model, i.e. RFC 7223, and could be extended with technology specific parameters in models augmenting that core model. The relationship/ connectivity between interfaces would be given by the equipment configuration and slot positions or be configured via management systems or controllers. Ahlberg, et al. Expires January 9, 2017 [Page 4] Internet-Draft Problem Statement July 2016 +------------------------------------------------------------------+ | Interface [RFC7223] | | +------------------+ | | |Ethernet Port | | | +------------------+ | | \ | | +-----------------------+ | | |Radio link terminal | | | +-----------------------+ | | \ | | +------------------------+ | | |Carrier termination | | | +------------------------+ | +------------------------------------------------------------------+ Figure 1: Relationship between interfaces in a node There will always be certain implementations that differ among products and it is therefore 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 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 parameters. For microwave radio link functionality work has been initiated (ONF: Microwave Modeling [ONF-model], IETF: Radio Link Model [I-D.ahlberg- ccamp-microwave-radio-link]). This effort is expected to take these initiatives into consideration and complement them on the gaps identified with the ambition to reach consensus within the industry around one common approach. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 3. Terminology and Definitions Software Defined Networking (SDN) is an emerging architecture that decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying Ahlberg, et al. Expires January 9, 2017 [Page 5] Internet-Draft Problem Statement July 2016 infrastructure to be abstracted for applications and network services. This results in an extremely dynamic, manageable, cost- effective, and adaptable architecture that gives administrators unprecedented programmability, automation, and control. The SDN concept is widely applied for network management, the adoption of SDN framework to manage and control the microwave and millimeter wave interface is one of the key applications of this work. Microwave is a band of spectrum with wavelengths ranging from 1 meter to 1 millimeter and with frequencies ranging between 300 MHz and 300 GHz. Microwave radio technology is widely used for point-to-point telecommunications because of their small wavelength that allows conveniently-sized antennas to direct them in narrow beams, and their comparatively higher frequencies that allows broad bandwidth and high data transmission rates. Millimeter wave is also known as extremely high frequency (EHF) or very high frequency (VHF) by the International Telecommunications Union (ITU), which can be used for high-speed wireless broadband communications. Millimeter wave is an undeveloped band of spectrum that can be used for a broad range of services on mobile and wireless networks including high-speed, point-to-point wireless local area networks (WLANs) and broadband access. This band has short wavelengths that range from 10 millimeters to 1 millimeter, namely millimeter band or millimeter wave. The 71 - 76 GHz, 81 - 86 GHz and 92-95 GHz bands are used for point-to-point high-bandwidth communication links, which allows for higher data rates up to 10 Gbit/s but requires a license. Unlicensed short-range data links can be used on 60 GHz millimeter wave. For instance, the upcoming IEEE Wi-Fi standard 802.11ad will run on the 60 GHz spectrum with data transfer rates of up to 7 Gbit/s. Carrier Termination is an interface for the capacity provided over the air by a single carrier. It is typically defined by its transmitting and receiving frequencies. Radio Link Terminal is an interface providing packet capacity and/or TDM capacity to the associated Ethernet and/or TDM interfaces in a node and used for the capacity required for setting up a transport service over a microwave/millimeter wave link. 4. Application This framework addresses the definition of an open and standardized interface for the radio link functionality in a microwave/millimeter wave node. The application of such an interface used for management and control of nodes and networks typically vary from one operator to Ahlberg, et al. Expires January 9, 2017 [Page 6] Internet-Draft Problem Statement July 2016 another, in terms of the systems used, what they are called and how they interact. 4.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 dominates the market. These solutions are expected to evolve and benefit from an increased focus on standardization by simplifying multi-vendor management, remove the need for vendor/domain specific management, and enabling use of open source systems. 4.2. Software Defined Networking SDN is another application emerging on the market. The main drivers for SDN introduction from an operator perspective is simplification and automation of network provisioning as well as E2E network services. The vision is to have a global view of the network conditions spanning across different vendors' equipment and multiple technologies. A variety of different SDN architectures and functions are being discussed and proposed within the industry, but they all have in common a very clear relationship to network management. In some proposals the SDN controller completely replaces the role of a network management system while in some cases the SDN controller is seen as an entity managed by the NMS. In any case the SDN functions shall be seen as part of an overall NMS strategy, no matter how the functionality is partitioned across units and no matter what terminology is used. If nodes from different vendors shall be managed by the same SDN functions, without the extra effort of introducing mediation layers, all nodes must align their interfaces. Hence, open and standardized node interfaces are closely associated with the introduction of SDN. 4.2.1. SDN example of radio link configuration Radio link terminals comprising 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, a logical control provides flexible management without configuring parameters on each carrier termination directly. An operator using SDN manages radio links by selecting an allowed operation mode. Alternatively, an operator can prefer the complete configuration of all the parameters of interest. Such case is not described in the document for simplicity). The operation mode is a set of logical metrics or parameters describing a Ahlberg, et al. Expires January 9, 2017 [Page 7] Internet-Draft Problem Statement July 2016 complete radio link configuration, such as capacity, availability, priority and power consumption. +------+ +-----+ +-----+ +-------+ | |-------| CT1 | ~~~~~~~~~~~ | CT1 |-------| | | | +-----+ +-----+ | | | RLT1 | | RLT2 | | | +-----+ +-----+ | | | |-------| CT2 | ~~~~~~~~~~~ | CT2 |-------| | +------+ +-----+ +-----+ +-------+ Figure 2: Radio link example Example of an operation mode table is shown Table 1. One mode (ID = 1) provides high capacity but requires high power consumption; another mode (ID = 2) provides low power consumption but low capacity. SDN controller selects one of the operation modes dynamically, according to the actual capacity need. +------+--------------+-----------+--------------+----------+-------+ | ID | Description | Capacity | Availability | Priority | Power | +------+--------------+-----------+--------------+----------+-------+ | 1 | High capacity| 400 | 99.9% | Low | High | +------+--------------+-----------+--------------+----------+-------+ | 2 | High avail- | 100 | 99.999% | High | Low | | | ability | | | | | +------+--------------+-----------+--------------+----------+-------+ Figure 3: Example of an operation mode table The procedure of logical control is as following: 1/ SDN controller gets the supported operation modes by reporting from the node NE or by other means, e.g., NMS. 2/ According to its operation policy, SDN controller selects one operation mode from the table and translates that into the required configuration of the individual parameters for the radio link terminals and the associated carrier terminations. The operation mode could be selected based on power consumption. Nowadays, more and more operators have strong requirement to decrease the node power consumption. The SDN controller can monitor the real time traffic distribution, and generated corresponding policy: to set the operation mode to high capacity on the radio links with heavy Ahlberg, et al. Expires January 9, 2017 [Page 8] Internet-Draft Problem Statement July 2016 traffic load; to set the operation mode to low power consumption on the radio links with light traffic load Radio link aggregation/bonding is widely used in microwave: multiple carriers are used to carry the traffic in cases where the needed capacity is beyond the capability of single carriers. During night time, the actual traffic load may be 1/3 of the peak day time. The operation mode of low power consumption could be set to turn off some of the radios within the group to save power consumption. The operation mode could also be configured based on traffic priority. For high priority traffic, it is necessary to assure high availability. On the other hand, low priority traffic is often high volume and requires high capacity. The SDN controller can generate corresponding policy based on the priority of traffic: to set the operation mode to high availability on the radio links with high priority traffic; to set the operation mode to high capacity on the radio links with low priority traffic. Radio protection/redundancy like a 1+1 Hot Standby is used to increase overall availability of links between nodes while radio link aggregation is used to achieve higher capacity. If traffic is predominately TDM traffic, high availability is required on radio links. In this case, SDN controller set operation mode as high availability. On the other hand, if traffic is packet traffic, e.g., LTE traffic, capacity is more of a concern. In this case, SDN controller set the operation mode as high capacity. 5. Use cases The use cases described should be the basis for identification and definition of the parameters to be supported by a YANG Data model for management of radio links, applicable for centralized, unified, multi-vendor management. Use cases addressing installation, on-site trouble shooting, fault resolution and other activities not performed from a centralized system and which in most cases are product specific are outside the scope of this framework. 5.1. Configuration Management Configuration of a radio link terminal, the constituent carrier terminations and when applicable the relationship to packet/Ethernet interfaces. Ahlberg, et al. Expires January 9, 2017 [Page 9] Internet-Draft Problem Statement July 2016 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 and enumerations that can be used. Support for the XPIC 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 to a packet/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 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.2. Inventory 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 logical inventory and configuration from device Request from manager about physical and/or equipment inventory associated with the radio link terminals and carrier terminations 5.3. Status and statistics Ahlberg, et al. Expires January 9, 2017 [Page 10] Internet-Draft Problem Statement July 2016 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 link interface and/or its constituent parts is a subset of the configuration use case to be supported. See 5.1 above. 5.4.2. 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 same cases required as a complement to the retrieval in bulk as described above. 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 and handling, and notifications and events are generic use cases for a device and not specific to a radio link interface an should be supported accordingly. 5.5.3. 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. Ahlberg, et al. Expires January 9, 2017 [Page 11] Internet-Draft Problem Statement July 2016 6. Requirements This is a placeholder for a separate chapter about requirements. 7. Security Considerations TBD. 8. IANA Considerations N/A. 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, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . 9.2. Informative References [I-D.ahlberg-ccamp-microwave-radio-link] Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., and M. Vaupotic, "Microwave Radio Link YANG Data Models", draft-ahlberg-ccamp-microwave-radio-link-01 (work in progress), May 2016. [I-D.ietf-netmod-routing-cfg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", draft-ietf-netmod-routing-cfg-22 (work in progress), July 2016. Ahlberg, et al. Expires January 9, 2017 [Page 12] Internet-Draft Problem Statement July 2016 [ONF-model] "Microwave Modeling - ONF Wireless Transport Group", May 2016. [PB-YANG] "IEEE 802.1X and 802.1Q YANG models, Marc,H.", October 2015. [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, . Authors' Addresses Jonas Ahlberg Ericsson AB Lindholmspiren 11 Goeteborg 417 56 Sweden Email: jonas.ahlberg@ericsson.com Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, S/N Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com Ye Min (Amy) Huawei Technologies CO., Ltd No.1899, Xiyuan Avenue Chengdu 611731 P.R.China Email: amy.yemin@huawei.com Marko Vaupotic Aviat Networks Motnica 9 Trzin-Ljubljana 1236 Slovenia Email: Marko.Vaupotic@aviatnet.com Ahlberg, et al. Expires January 9, 2017 [Page 13] Internet-Draft Problem Statement July 2016 Jeff Tantsura Individual 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 Xi Li NEC Laboratories Europe Kurfuersten-Anlage 36 Heidelberg 69115 Germany Email: Xi.Li@neclab.eu Ippei Akiyoshi NEC 1753, Shimonumabe Nakahara-ku Kawasaki, Kanagawa 211-8666 Japan Email: i-akiyoshi@ah.jp.nec.com Ahlberg, et al. Expires January 9, 2017 [Page 14]