idnits 2.17.1 draft-ietf-ccamp-microwave-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2018) is 2302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-alarm-module-00 == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-mw-yang-02 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-02 == Outdated reference: A later version (-08) exists of draft-ietf-netmod-entity-07 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-09 -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group J. Ahlberg, Ed. 3 Internet-Draft Ericsson AB 4 Intended status: Informational M. Ye, Ed. 5 Expires: July 9, 2018 Huawei Technologies 6 X. Li 7 NEC Laboratories Europe 8 LM. Contreras 9 Telefonica I+D 10 CJ. Bernardos 11 Universidad Carlos III de Madrid 12 January 5, 2018 14 A framework for Management and Control of microwave and millimeter wave 15 interface parameters 16 draft-ietf-ccamp-microwave-framework-05 18 Abstract 20 The unification of control and management of microwave radio link 21 interfaces is a precondition for seamless multilayer networking and 22 automated network provisioning and operation. 24 This document describes the required characteristics and use cases 25 for control and management of radio link interface parameters using a 26 YANG Data Model. 28 The purpose is to create a framework for identification of the 29 necessary information elements and definition of a YANG Data Model 30 for control and management of the radio link interfaces in a 31 microwave node. Some parts of the resulting model may be generic 32 which could also be used by other technologies. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 9, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Conventions used in this document . . . . . . . . . . . . 5 69 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 70 3. Approaches to manage and control radio link interfaces . . . 7 71 3.1. Network Management Solutions . . . . . . . . . . . . . . 8 72 3.2. Software Defined Networking . . . . . . . . . . . . . . . 8 73 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Configuration Management . . . . . . . . . . . . . . . . 9 75 4.1.1. Understand the capabilities and limitations . . . . . 9 76 4.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 77 4.1.3. Radio link re-configuration and optimization . . . . 10 78 4.1.4. Radio link logical configuration . . . . . . . . . . 10 79 4.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.2.1. Retrieve logical inventory and configuration from 81 device . . . . . . . . . . . . . . . . . . . . . . . 10 82 4.2.2. Retrieve physical/equipment inventory from device . . 10 83 4.3. Status and statistics . . . . . . . . . . . . . . . . . . 11 84 4.3.1. Actual status and performance of a radio link 85 interface . . . . . . . . . . . . . . . . . . . . . . 11 86 4.4. Performance management . . . . . . . . . . . . . . . . . 11 87 4.4.1. Configuration of historical measurements to be 88 performed . . . . . . . . . . . . . . . . . . . . . . 11 89 4.4.2. Collection of historical performance data . . . . . . 11 90 4.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 91 4.5.1. Configuration of alarm reporting . . . . . . . . . . 11 92 4.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 93 4.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 94 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 95 6. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 96 6.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 97 6.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14 98 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 103 9.2. Informative References . . . . . . . . . . . . . . . . . 18 104 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 107 1. Introduction 109 Microwave radio is a technology that uses high frequency radio waves 110 to provide high speed wireless connections that can send and receive 111 voice, video, and data information. It is a general term used for 112 systems covering a very large range of traffic capacities, channel 113 separations, modulation formats and applications over a wide range of 114 frequency bands from 1 GHz up to and above 100 GHz. 116 The main application for microwave is backhaul for mobile broadband. 117 Those networks will continue to be modernized using a combination of 118 microwave and fiber technologies. The choice of technology is a 119 question about fiber presence and cost of ownership, not about 120 capacity limitations in microwave. 122 Microwave is already today able to fully support the capacity needs 123 of a backhaul in a radio access network and will evolve to support 124 multiple gigabits in traditional frequency bands and beyond 10 125 gigabits in higher frequency bands with more band width. L2 packet 126 features are normally an integrated part of microwave nodes and more 127 advanced L2 and L3 features will over time be introduced to support 128 the evolution of the transport services to be provided by a backhaul/ 129 transport network. Note that the wireless access technologies such 130 as 3/4/5G and Wi-Fi are not within the scope of this microwave model 131 work. 133 Open and standardized interfaces are a pre-requisite for efficient 134 management of equipment from multiple vendors, integrated in a single 135 system/controller. This framework addresses management and control 136 of the radio link interface(s) and the relationship to other packet 137 interfaces, typically to Ethernet interfaces, in a microwave node. A 138 radio link provides the transport over the air, using one or several 139 carriers in aggregated or protected configurations. Managing and 140 controlling a transport service over a microwave node involves both 141 radio link and packet functionality. 143 Already today there are numerous IETF data models, RFCs and drafts, 144 with technology specific extensions that cover a large part of the 145 packet domain. Examples are IP Management [RFC7277], Routing 146 Management [RFC8022] and Provider Bridge [PB-YANG]. They are based 147 on the IETF YANG model for Interface Management [RFC7223], which is 148 an evolution of the SNMP IF-MIB [RFC2863]. 150 Since microwave nodes will contain more and more packet functionality 151 which is expected to be managed using those models, there are 152 advantages if radio link interfaces can be modeled and be managed 153 using the same structure and the same approach, specifically for use 154 cases in which a microwave node is managed as one common entity 155 including both the radio link and the packet functionality, e.g. at 156 basic configuration of node and connections, centralized trouble 157 shooting, upgrade and maintenance. All interfaces in a node, 158 irrespective of technology, would then be accessed from the same core 159 model, i.e. [RFC7223], and could be extended with technology specific 160 parameters in models augmenting that core model. The relationship/ 161 connectivity between interfaces could be given by the physical 162 equipment configuration, e.g. the slot in which the Radio Link 163 Terminal (modem) is plugged in could be associated with a specific 164 Ethernet port due to the wiring in the backplane of the system, or it 165 could be flexible and therefore configured via a management system or 166 controller. 168 +------------------------------------------------------------------+ 169 | Interface [RFC7223] | 170 | +---------------+ | 171 | | Ethernet Port | | 172 | +---------------+ | 173 | \ | 174 | +---------------------+ | 175 | | Radio Link Terminal | | 176 | +---------------------+ | 177 | / \ | 178 | +---------------------+ +---------------------+ | 179 | | Carrier Termination | | Carrier Termination | | 180 | +---------------------+ +---------------------+ | 181 +------------------------------------------------------------------+ 183 Figure 1: Relationship between interfaces in a node 185 There will always be certain implementations that differ among 186 products and it is therefore practically impossible to achieve 187 industry consensus on every design detail. It is therefore important 188 to focus on the parameters that are required to support the use cases 189 applicable for centralized, unified, multi-vendor management and to 190 allow other parameters to be optional or to be covered by extensions 191 to the standardized model. Furthermore, a standard that allows for a 192 certain degree of freedom encourages innovation and competition which 193 is something that benefits the entire industry. It is therefore 194 important that a radio link management model covers all relevant 195 functions but also leaves room for product/feature-specific 196 extensions. 198 For microwave radio link functionality work has been initiated (ONF: 199 Microwave Modeling [ONF-model], IETF: Radio Link Model 200 [I-D.ahlberg-ccamp-microwave-radio-link]). The purpose of this 201 effort is to reach consensus within the industry around one common 202 approach, with respect to the use cases and requirements to be 203 supported, the type and structure of the model and the resulting 204 attributes to be included. This document describes the use cases and 205 requirements agreed to be covered, the expected characteristics of 206 the model and at the end includes an analysis of how the models in 207 the two on-going initiatives fulfill these expectations and a 208 recommendation on what can be reused and what gaps need to be filled 209 by a new and evolved radio link model. 211 1.1. Conventions used in this document 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 While [RFC2119] describes interpretations of these key words in terms 218 of protocol specifications and implementations, they are used in this 219 document to describe high level requirements to be met when defining 220 the YANG Data Model for Microwave Radio Link. 222 This document does not define any protocol extension, hence only 223 RFC2119 can be considered as a normative reference. However, the 224 list of normative references includes a number of documents that can 225 be useful for a better understanding of the context. 227 2. Terminology and Definitions 229 Microwave radio is a term commonly used for technologies that operate 230 in both microwave and millimeter wave lengths and in frequency bands 231 from 1.4 GHz up to and beyond 100 GHz. In traditional bands it 232 typically supports capacities of 1-3 Gbps and in 70/80 GHz band up to 233 10 Gbps. Using multi-carrier systems operating in frequency bands 234 with wider channels, the technology will be capable of providing 235 capacities up 100 Gbps. 237 The microwave radio technology is widely used for point-to-point 238 telecommunications because of its small wavelength that allows 239 conveniently-sized antennas to direct them in narrow beams, and the 240 comparatively higher frequencies that allow broad bandwidth and high 241 data transmission rates. It is used for a broad range of fixed and 242 mobile services including high-speed, point-to-point wireless local 243 area networks (WLANs) and broadband access. 245 ETSI EN 302 217 series defines the characteristics and requirements 246 of microwave equipment and antennas. Especially ETSI EN 302 217-2 247 [EN302217-2] specifies the essential parameters for the systems 248 operating from 1.4GHz to 86GHz. 250 Carrier Termination and Radio Link Terminal are two concepts defined 251 to support modeling of microwave radio link features and parameters 252 in a structured and yet simple manner. 254 Carrier Termination is an interface for the capacity provided over 255 the air by a single carrier. It is typically defined by its 256 transmitting and receiving frequencies. 258 Radio Link Terminal is an interface providing packet capacity and/or 259 Time Division Multiplexing (TDM) capacity to the associated Ethernet 260 and/or TDM interfaces in a node and used for setting up a transport 261 service over a microwave radio link. 263 Figure 2 provides a graphical representation of Carrier Termination 264 and Radio Link Terminal concepts. 266 /--------- Radio Link ---------\ 267 Near End Far End 269 +---------------+ +---------------+ 270 | Radio Link | | Radio Link | 271 | Terminal | | Terminal | 272 | | | | 273 | (Protected or Bonded) | 274 | | | | 275 | +-----------+ | | +-----------+ | 276 | | | | Carrier A | | | | 277 | | Carrier | |<--------->| | Carrier | | 278 | |Termination| | | |Termination| | 279 Packet--| | | | | | | |--Packet 280 | +-----------+ | | +-----------+ | 281 TDM----| | | |----TDM 282 | +-----------+ | | +-----------+ | 283 | | | | Carrier B | | | | 284 | | Carrier | |<--------->| | Carrier | | 285 | |Termination| | | |Termination| | 286 | | | | | | | | 287 | +-----------+ | | +-----------+ | 288 | | | | 289 +---------------+ +---------------+ 291 \--- Microwave Node ---/ \--- Microwave Node ---/ 293 Figure 2: Radio Link Terminal and Carrier Termination 295 Software Defined Networking (SDN) is an architecture that decouples 296 the network control and forwarding functions enabling the network 297 control to become directly programmable and the underlying 298 infrastructure to be abstracted for applications and network 299 services. SDN can be used as a term for automation of traditional 300 network management, which can be implemented using a similar 301 approach. The adoption of an SDN framework for management and 302 control the microwave interface is one of the key applications for 303 this work. 305 3. Approaches to manage and control radio link interfaces 307 This framework addresses the definition of an open and standardized 308 interface for the radio link functionality in a microwave node. The 309 application of such an interface used for management and control of 310 nodes and networks typically vary from one operator to another, in 311 terms of the systems used and how they interact. A traditional 312 solution is network management system, while an emerging one is SDN. 313 SDN solutions can be used as part of the network management system, 314 allowing for direct network programmability and automated 315 configurability by means of a centralized SDN control and 316 standardized interfaces to program the nodes. 318 3.1. Network Management Solutions 320 The classic network management solutions, with vendor specific domain 321 management combined with cross domain functionality for service 322 management and analytics, still dominates the market. These 323 solutions are expected to evolve and benefit from an increased focus 324 on standardization by simplifying multi-vendor management and remove 325 the need for vendor/domain specific management. 327 3.2. Software Defined Networking 329 One of the main drivers for applying SDN from an operator perspective 330 is simplification and automation of network provisioning as well as 331 end to end network service management. The vision is to have a 332 global view of the network conditions spanning across different 333 vendors' equipment and multiple technologies. 335 If nodes from different vendors shall be managed by the same SDN 336 controller via a node management interface (north bound interface, 337 NBI), without the extra effort of introducing intermediate systems, 338 all nodes must align their node management interfaces. Hence, an 339 open and standardized node management interface are required in a 340 multi-vendor environment. Such standardized interface enables a 341 unified management and configuration of nodes from different vendors 342 by a common set of applications. 344 On top of SDN applications to configure, manage and control the nodes 345 and their associated transport interfaces including the L2 Ethernet 346 and L3 packet interfaces as well as the radio interfaces, there are 347 also a large variety of other more advanced SDN applications that can 348 be exploited and/or developed. 350 A potential flexible approach for the operators is to use SDN in a 351 logical control way to manage the radio links by selecting a 352 predefined operation mode. The operation mode is a set of logical 353 metrics or parameters describing a complete radio link configuration, 354 such as capacity, availability, priority and power consumption. 356 An example of an operation mode table is shown in Figure 3. Based on 357 its operation policy (e.g., power consumption or traffic priority), 358 the SDN controller selects one operation mode and translates that 359 into the required configuration of the individual parameters for the 360 radio link terminals and the associated carrier terminations. 362 +----+---------------+------------+-------------+-----------+------+ 363 | ID |Description | Capacity |Availability | Priority |Power | 364 +----+---------------+------------+-------------+-----------+------+ 365 | 1 |High capacity | 400 Mbps | 99.9% | Low |High | 366 +----+---------------+------------+-------------+-----------+------+ 367 | 2 |High avail- | 100 Mbps | 99.999% | High |Low | 368 | | ability | | | | | 369 +----+---------------+------------+-------------+-----------+------+ 371 Figure 3: Example of an operation mode table 373 An operation mode bundles together the values of a set of different 374 parameters. How each operation mode maps into certain set of 375 attributes is out of scope of this document. Effort on a 376 standardizing operation mode is required to implement a smoothly 377 operator environment. 379 4. Use Cases 381 The use cases described should be the basis for identification and 382 definition of the parameters to be supported by a YANG Data model for 383 management of radio links, applicable for centralized, unified, 384 multi-vendor management. 386 Other product specific use cases, addressing e.g. installation, on- 387 site trouble shooting and fault resolution, are outside the scope of 388 this framework. If required, these use cases are expected to be 389 supported by product specific extensions to the standardized model. 391 4.1. Configuration Management 393 Configuration of a radio link terminal, the constituent carrier 394 terminations and when applicable the relationship to packet/Ethernet 395 and TDM interfaces. 397 4.1.1. Understand the capabilities and limitations 399 Exchange of information between a manager and a device about the 400 capabilities supported and specific limitations in the parameter 401 values and enumerations that can be used. 403 Support for the XPIC (Cross Polarization Interference Cancellation) 404 feature or not and the maximum modulation supported are two examples 405 on information that could be exchanged. 407 4.1.2. Initial Configuration 409 Initial configuration of a radio link terminal, enough to establish 410 L1 connectivity over the hop to an associated radio link terminal on 411 a device at far end. It MAY also include configuration of the 412 relationship between a radio link terminal and an associated traffic 413 interface, e.g. an Ethernet interface, unless that is given by the 414 equipment configuration. 416 Frequency, modulation, coding and output power are examples of 417 parameters typically configured for a carrier termination and type of 418 aggregation/bonding or protection configurations expected for a radio 419 link terminal. 421 4.1.3. Radio link re-configuration and optimization 423 Re-configuration, update or optimization of an existing radio link 424 terminal. Output power and modulation for a carrier termination and 425 protection schemas and activation/de-activation of carriers in a 426 radio link terminal are examples on parameters that can be re- 427 configured and used for optimization of the performance of a network. 429 4.1.4. Radio link logical configuration 431 Radio link terminals comprising a group of carriers are widely used 432 in microwave technology. There are several kinds of groups: 433 aggregation/bonding, 1+1 protection/redundancy, etc. To avoid 434 configuration on each carrier termination directly, a logical control 435 provides flexible management by mapping a logical configuration to a 436 set of physical attributes. This could also be applied in a 437 hierarchical SDN environment where some domain controllers are 438 located between the SDN controller and the radio link terminal. 440 4.2. Inventory 442 4.2.1. Retrieve logical inventory and configuration from device 444 Request from manager and response by device with information about 445 radio interfaces, their constitution and configuration. 447 4.2.2. Retrieve physical/equipment inventory from device 449 Request from manager about physical and/or equipment inventory 450 associated with the radio link terminals and carrier terminations. 452 4.3. Status and statistics 454 4.3.1. Actual status and performance of a radio link interface 456 Manager requests and device responds with information about actual 457 status and statistics of configured radio link interfaces and their 458 constituent parts. 460 4.4. Performance management 462 4.4.1. Configuration of historical measurements to be performed 464 Configuration of historical measurements to be performed on a radio 465 link interface and/or its constituent parts is a subset of the 466 configuration use case to be supported. See Section 4.1 above. 468 4.4.2. Collection of historical performance data 470 Collection of historical performance data in bulk by the manager is a 471 general use case for a device and not specific to a radio link 472 interface. 474 Collection of an individual counter for a specific interval is in 475 same cases required as a complement to the retrieval in bulk as 476 described above. 478 4.5. Fault Management 480 4.5.1. Configuration of alarm reporting 482 Configuration of alarm reporting associated specifically with radio 483 interfaces, e.g. configuration of alarm severity, is a subset of the 484 configuration use case to be supported. See Section 4.1 above. 486 4.5.2. Alarm management 488 Alarm synchronization, visualization, handling, notifications and 489 events are generic use cases for a device and not specific to a radio 490 link interface and should be supported accordingly. 492 4.6. Troubleshooting and Root Cause Analysis 494 Information and actions required by a manager/operator to investigate 495 and understand the underlying issue to a problem in the performance 496 and/or functionality of a radio link terminal and the associated 497 carrier terminations. 499 5. Requirements 501 For managing a microwave node including both the radio link and the 502 packet functionality, a unified data model is desired to unify the 503 modeling of the radio link interfaces and the packet interfaces using 504 the same structure and the same modelling approach. If some part of 505 model is generic for other technology usage, it should be clearly 506 stated. 508 The purpose of the YANG Data Model is for management and control of 509 the radio link interface(s) and the relationship/connectivity to 510 other packet interfaces, typically to Ethernet interfaces, in a 511 microwave node. 513 The capability of configuring and managing microwave nodes includes 514 the following requirements for the modelling: 516 1. It MUST be possible to configure, manage and control a radio link 517 terminal and the constituent carrier terminations. 519 A. Configuration of frequency, channel bandwidth, modulation, 520 coding and transmitter output power MUST be supported for a 521 carrier termination. 523 B. A radio link terminal MUST configure the associated carrier 524 terminations and the type of aggregation/bonding or 525 protection configurations expected for the radio link 526 terminal. 528 C. The capability, e.g. the maximum modulation supported, and 529 the actual status/statistics, e.g. administrative status of 530 the carriers, SHOULD also be supported by the data model. 532 D. The definition of the features and parameters SHOULD be based 533 on established microwave equipment and radio standards, such 534 as ETSI EN 302 217 [EN302217-2] which specifies the essential 535 parameters for microwave systems operating from 1.4GHz to 536 86GHz. 538 2. It MUST be possible to map different traffic types (e.g. TDM, 539 Ethernet) to the transport capacity provided by a specific radio 540 link terminal. 542 3. It MUST be possible to configure and collect historical 543 measurements (for the use case described in section 5.4) to be 544 performed on a radio link interface, e.g. minimum, maximum and 545 average transmit power and receive level in dBm. 547 4. It MUST be possible to configure and retrieve alarms reporting 548 associated with the radio interfaces, e.g. configuration of alarm 549 severity, supported alarms like configuration fault, signal lost, 550 modem fault, radio fault. 552 6. Gap Analysis on Models 554 The purpose of the gap analysis is to identify and recommend what 555 existing and established models as well as draft models under 556 definition to support the use cases and requirements specified in the 557 previous chapters. It shall also make a recommendation on how the 558 gaps not supported should be filled, including the need for 559 development of new models and evolution of existing models and 560 drafts. 562 For microwave radio link functionality work has been initiated (ONF: 563 Microwave Modeling [ONF-model], IETF: Radio Link Model 564 [I-D.ahlberg-ccamp-microwave-radio-link]. The analysis is expected 565 to take these initiatives into consideration and make a 566 recommendation on how to make use of them and how to complement them 567 in order to fill the gaps identified. 569 For generic functionality, not specific for radio link, the ambition 570 is to refer to existing or emerging models that could be applicable 571 for all functional areas in a microwave node. 573 6.1. Microwave Radio Link Functionality 575 [ONF-CIM] defines a CoreModel of the ONF Common Information Model. 576 An information model describes the things in a domain in terms of 577 objects, their properties (represented as attributes), and their 578 relationships. The ONF information model is expressed in Unified 579 Modeling Language (UML). The ONF CoreModel is independent of 580 specific data plane technology. Data plane technology specific 581 properties are acquired in a runtime solution via "filled in" cases 582 of specification (LtpSpec etc.). These can be used to augment the 583 CoreModel to provide a data plane technology specific representation. 585 IETF Data Model defines an implementation and NETCONF-specific 586 details. YANG is a data modeling language used to model the 587 configuration and state data. It is well aligned with the structure 588 of the YANG data models proposed for the different packet interfaces 589 which are all based on [RFC7223]. Furthermore, several YANG data 590 models have been proposed in the IETF for other transport 591 technologies such as optical transport; e.g. [RFC7277], 592 [I-D.ietf-ccamp-otn-topo-yang], [I-D.ietf-ospf-yang]. In light of 593 this trend, the IETF data model is becoming a popular approach for 594 modeling most packet transport technology interfaces and it is 595 thereby well positioned to become an industry standard. 597 [RFC3444] explains the difference between Information Model(IM) and 598 Data Models(DM). IM is to model managed objects at a conceptual 599 level for designers and operators, DM is defined at a lower level and 600 includes many details for implementers. In addition, the protocol- 601 specific details are usually included in DM. Since conceptual models 602 can be implemented in different ways, multiple DMs can be derived 603 from a single IM. To ensure better interoperability, it is better to 604 focus on DM directly. 606 [RFC7223] describes an interface management model, however it doesn't 607 include technology specific information, e.g., for radio interface. 608 [I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal 609 for radio interfaces, which includes support for basic configuration, 610 status and performance but lacks full support for alarm management 611 and interface layering, i.e. the connectivity of the transported 612 capacity (TDM and Ethernet) with other internal technology specific 613 interfaces in a microwave node. 615 The recommendation is to use the structure of the IETF: Radio Link 616 Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point, 617 since it is a data model providing the wanted alignment with 618 [RFC7223]. For the definition of the detailed leafs/parameters, the 619 recommendation is to use the IETF: Radio Link Model and the ONF: 620 Microwave Modeling [ONF-model] as the basis and to define new ones to 621 cover identified gaps. The parameters in those models have been 622 defined by both operators and vendors within the industry and the 623 implementations of the ONF Model have been tested in the Proof of 624 Concept events in multi-vendor environments, showing the validity of 625 the approach proposed in this framework document. 627 It is also recommended to add the required data nodes to describe the 628 interface layering for the capacity provided by a radio link terminal 629 and the associated Ethernet and TDM interfaces in a microwave node. 630 The principles and data nodes for interface layering described in 631 [RFC7223] should be used as a basis. 633 6.2. Generic Functionality 635 For generic functionality, not specific for radio link, the 636 recommendation is to refer to existing RFCs or emerging drafts 637 according to the table in Figure 4 below. New Radio Link Model is 638 used in the table for the cases where the functionality is 639 recommended to be included in the new radio link model as described 640 in Section 6.1. 642 +------------------------------------+-----------------------------+ 643 | Generic Functionality | Recommendation | 644 | | | 645 +------------------------------------+-----------------------------+ 646 |1.Fault Management | | 647 | | | 648 | Alarm Configuration | New Radio Link Model | 649 | | | 650 | Alarm notifications/ | [I-D.ietf-ccamp- | 651 | synchronization | alarm-module] | 652 +------------------------------------+-----------------------------+ 653 |2.Performance Management | | 654 | | | 655 | Performance Configuration/ | New Radio Link Model | 656 | Activation | | 657 | | | 658 | Performance Collection | New Radio Link Model and | 659 | | XML files | 660 +------------------------------------+-----------------------------+ 661 |3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] | 662 +------------------------------------+-----------------------------+ 664 Figure 4: Recommendation on how to support generic functionality 666 Microwave specific alarm configurations are recommended to be 667 included in the new radio link model and could be based on what is 668 supported in the IETF and ONF Radio Link Models. Alarm notifications 669 and synchronization are general and is recommended to be supported by 670 a generic model, such as [I-D.ietf-ccamp-alarm-module]. 672 Activation of interval counters and thresholds could be a generic 673 function but it is recommended to be supported by the new radio link 674 specific model and can be based on both the ONF and IETF Microwave 675 Radio Link models. 677 Collection of interval/historical counters is a generic function that 678 needs to be supported in a node. File based collection via SSH File 679 Transfer Protocol(SFTP) and collection via a NETCONF/YANG interfaces 680 are two possible options and the recommendation is to include support 681 for the latter in the new radio link specific model. The ONF and 682 IETF Microwave Radio Link models can be used as a basis also in this 683 area. 685 Physical and/or equipment inventory associated with the radio link 686 terminals and carrier terminations is recommended to be covered by a 687 model generic for the complete node, e.g. [I-D.ietf-netmod-entity] 688 and it is thereby outside the scope of the radio link specific model. 690 6.3. Summary 692 The conclusions and recommendations from the analysis can be 693 summarized as follows: 695 1. A Microwave Radio Link YANG Data Model should be defined with a 696 scope enough to support the use cases and requirements in 697 Sections 4 and 5 of this document. 699 2. Use the structure in the IETF: Radio Link Model 700 [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point. 701 It augments [RFC7223] and is thereby as required aligned with the 702 structure of the models for management of the packet domain. 704 3. Use established microwave equipment and radio standards, such as 705 [EN302217-2], and the IETF: Radio Link Model 706 [I-D.ahlberg-ccamp-microwave-radio-link] and the ONF: Microwave 707 Modeling [ONF-model] as the basis for the definition of the 708 detailed leafs/parameters to support the specified use cases and 709 requirements, and proposing new ones to cover identified gaps. 711 4. Add the required data nodes to describe the interface layering 712 for the capacity provided by a radio link terminal and the 713 associated Ethernet and TDM interfaces, using the principles and 714 data nodes for interface layering described in [RFC7223] as a 715 basis. 717 5. Include support for configuration of microwave specific alarms in 718 the Microwave Radio Link model and rely on a generic model such 719 as [I-D.ietf-ccamp-alarm-module] for notifications and alarm 720 synchronization. 722 6. Use a generic model such as [I-D.ietf-netmod-entity] for 723 physical/equipment inventory. 725 It is furthermore recommended that the Microwave Radio Link YANG Data 726 Model should be validated by both operators and vendors as part of 727 the process to make it stable and mature. During the Hackathon in 728 IETF 99, a project "SDN Applications for microwave radio link via 729 IETF YANG Data Model" successfully validated this framework and the 730 YANG data model[I-D.ietf-ccamp-mw-yang]. The project also received 731 the BEST OVERALL award from the Hackathon. 733 7. Security Considerations 735 Security issue concerning the access control to Management interfaces 736 can be generally addressed by authentication techniques providing 737 origin verification, integrity and confidentiality. In addition, 738 management interfaces can be physically or logically isolated, by 739 configuring them to be only accessible out-of-band, through a system 740 that is physically or logically separated from the rest of the 741 network infrastructure. In case where management interfaces are 742 accessible in-band at the client device or within the microwave 743 transport network domain, filtering or firewalling techniques can be 744 used to restrict unauthorized in-band traffic. Authentication 745 techniques may be additionally used in all cases. 747 This framework describes the requirements and characteristics of a 748 YANG Data Model for control and management of the radio link 749 interfaces in a microwave node. It is supposed to be accessed via a 750 management protocol with a secure transport layer, such as NETCONF 751 [RFC6241]. 753 8. IANA Considerations 755 This memo includes no request to IANA. 757 9. References 759 9.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, 763 DOI 10.17487/RFC2119, March 1997, 764 . 766 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 767 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 768 . 770 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 771 Information Models and Data Models", RFC 3444, 772 DOI 10.17487/RFC3444, January 2003, 773 . 775 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 776 and A. Bierman, Ed., "Network Configuration Protocol 777 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 778 . 780 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 781 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 782 . 784 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 785 RFC 7277, DOI 10.17487/RFC7277, June 2014, 786 . 788 9.2. Informative References 790 [EN302217-2] 791 "Fixed Radio Systems; Characteristics and requirements for 792 point to-point equipment and antennas; Part 2: Digital 793 systems operating in frequency bands from 1 GHz to 86 GHz; 794 Harmonised Standard covering the essential requirements of 795 article 3.2 of Directive 2014/53/EU", EN 302 217-2 796 V3.1.1 , May 2017. 798 [I-D.ahlberg-ccamp-microwave-radio-link] 799 Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., 800 and M. Vaupotic, "Microwave Radio Link YANG Data Models", 801 draft-ahlberg-ccamp-microwave-radio-link-01 (work in 802 progress), May 2016. 804 [I-D.ietf-ccamp-alarm-module] 805 Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- 806 ietf-ccamp-alarm-module-00 (work in progress), December 807 2017. 809 [I-D.ietf-ccamp-mw-yang] 810 Ahlberg, J., Ye, M., Li, X., Kawada, K., Bernardos, C., 811 Spreafico, D., and M. Vaupotic, "A YANG Data Model for 812 Microwave Radio Link", draft-ietf-ccamp-mw-yang-02 (work 813 in progress), October 2017. 815 [I-D.ietf-ccamp-otn-topo-yang] 816 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Liu, X., 817 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 818 Model for Optical Transport Network Topology", draft-ietf- 819 ccamp-otn-topo-yang-02 (work in progress), October 2017. 821 [I-D.ietf-netmod-entity] 822 Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 823 YANG Data Model for Hardware Management", draft-ietf- 824 netmod-entity-07 (work in progress), December 2017. 826 [I-D.ietf-ospf-yang] 827 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 828 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 829 yang-09 (work in progress), October 2017. 831 [ONF-CIM] "Core Information Model", version 1.2 , September 2016, 832 . 835 [ONF-model] 836 "Microwave Information Model", version 1.0 , December 837 2016, 838 . 842 [PB-YANG] "IEEE 802.1X and 802.1Q Module Specifications", version 843 0.4 , May 2015, 844 . 847 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 848 Management", RFC 8022, DOI 10.17487/RFC8022, November 849 2016, . 851 Appendix A. Contributors 853 Marko Vaupotic 854 Aviat Networks 855 Motnica 9 856 Trzin-Ljubljana 1236 857 Slovenia 859 Email: Marko.Vaupotic@aviatnet.com 861 Jeff Tantsura 862 Huawei Technologies CO., Ltd 864 Email: jefftant.ietf@gmail.com 866 Koji Kawada 867 NEC Corporation 868 1753, Shimonumabe Nakahara-ku 869 Kawasaki, Kanagawa 211-8666 870 Japan 872 Email: k-kawada@ah.jp.nec.com 873 Ippei Akiyoshi 874 NEC 875 1753, Shimonumabe Nakahara-ku 876 Kawasaki, Kanagawa 211-8666 877 Japan 879 Email: i-akiyoshi@ah.jp.nec.com 881 Daniela Spreafico 882 Nokia - IT 883 Via Energy Park, 14 884 Vimercate (MI) 20871 885 Italy 887 Email: daniela.spreafico@nokia.com 889 Authors' Addresses 891 Jonas Ahlberg (editor) 892 Ericsson AB 893 Lindholmspiren 11 894 Goteborg 417 56 895 Sweden 897 Email: jonas.ahlberg@ericsson.com 899 Ye Min (editor) 900 Huawei Technologies 901 No.1899, Xiyuan Avenue 902 Chengdu 611731 903 P.R.China 905 Email: amy.yemin@huawei.com 907 Xi Li 908 NEC Laboratories Europe 909 Kurfuersten-Anlage 36 910 Heidelberg 69115 911 Germany 913 Email: Xi.Li@neclab.eu 914 Luis M. Contreras 915 Telefonica I+D 916 Ronda de la Comunicacion, S/N 917 Madrid 28050 918 Spain 920 Email: luismiguel.contrerasmurillo@telefonica.com 922 Carlos J. Bernardos 923 Universidad Carlos III de Madrid 924 Av. Universidad, 30 925 Madrid, Leganes 28911 926 Spain 928 Email: cjbc@it.uc3m.es