idnits 2.17.1 draft-ietf-ccamp-microwave-framework-04.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 (December 8, 2017) is 2331 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 (-08) exists of draft-ietf-netmod-entity-05 -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP WG J. Ahlberg 3 Internet-Draft Ericsson AB 4 Intended status: Informational LM. Contreras 5 Expires: June 11, 2018 TID 6 M.Ye 7 Huawei Technologies CO., Ltd 8 M. Vaupotic 9 Aviat Networks 10 J. Tantsura 11 Individual 12 K. Kawada 13 NEC Corporation 14 X. Li 15 NEC Laboratories Europe 16 I. Akiyoshi 17 NEC 18 CJ. Bernardos 19 UC3M 20 D. Spreafico 21 Nokia - IT 22 December 8, 2017 24 A framework for Management and Control of microwave and 25 millimeter wave interface parameters 26 draft-ietf-ccamp-microwave-framework-04 28 Abstract 30 To ensure an efficient data transport, meeting the requirements 31 requested by today's transport services, the unification of control 32 and management of microwave and millimeter wave radio link interfaces 33 is a precondition for seamless multilayer networking and automated 34 network wide provisioning and operation. 36 This document describes the required characteristics and use cases 37 for control and management of radio link interface parameters using a 38 YANG Data Model. It focuses on the benefits of a standardized 39 management model that is aligned with how other packet technology 40 interfaces in a microwave/millimeter wave node are modeled, the need 41 to support core parameters and at the same time allow for optional 42 product/feature specific parameters supporting new, unique innovative 43 features until they have become mature enough to be included in the 44 standardized model. 46 The purpose is to create a framework for identification of the 47 necessary information elements and definition of a YANG Data Model 48 for control and management of the radio link interfaces in a 49 microwave/millimeter wave node. Some part of the resulting model MAY 50 be generic which COULD also be used by other technology. 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on June 11, 2018. 69 Copyright Notice 71 Copyright (c) 2017 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 87 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 88 3. Conventions used in this document . . . . . . . . . . . . . . 7 89 4. Approaches to manage and control radio link interfaces . . . 8 90 4.1. Network Management Solutions . . . . . . . . . . . . . . 8 91 4.2. Software Defined Networking . . . . . . . . . . . . . . . 8 92 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 5.1. Configuration Management . . . . . . . . . . . . . . . . 9 94 5.1.1. Understand the capabilities and limitations . . . . . 9 95 5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 96 5.1.3. Radio link re-configuration and optimization . . . . 10 97 5.1.4. Radio link logical configuration . . . . . . . . . . 10 98 5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 99 5.2.1. Retrieve logical inventory and configuration 100 from device . . . . . . . . . . . . . . . . . . . . . 10 101 5.2.2. Retrieve physical/equipment inventory from device . . 10 102 5.3. Status and statistics . . . . . . . . . . . . . . . . . . 11 103 5.3.1. Actual status and performance of 104 a radio link interface . . . . . . . . . . . . . . . 11 105 5.4. Performance management . . . . . . . . . . . . . . . . . 11 106 5.4.1. Configuration of historical measurements to be 107 performed . . . . . . . . . . . . . . . . . . . . . . 11 108 5.4.2. Collection of historical performance data . . . . . . 11 109 5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 110 5.5.1. Configuration of alarm reporting . . . . . . . . . . 11 111 5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 112 5.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 113 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 114 7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 115 7.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 116 7.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14 117 7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 120 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 121 10.1. Normative References . . . . . . . . . . . . . . . . . 17 122 10.2. Informative References . . . . . . . . . . . . . . . . 18 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 125 1. Terminology and Definitions 127 Microwave is a band of spectrum with wavelengths ranging from 1 128 meter to 1 millimeter and with frequencies ranging between 300 MHz 129 and 300 GHz. Microwave radio technology is widely used for point-to- 130 point telecommunications because of their small wavelength that 131 allows conveniently-sized antennas to direct them in narrow beams, 132 and their comparatively higher frequencies that allows broad 133 bandwidth and high data transmission rates. 135 Millimeter wave is also known as extremely high frequency (EHF) or 136 very high frequency (VHF) by the International Telecommunications 137 Union (ITU), which can be used for high-speed wireless broadband 138 communications. Millimeter wave can be used for a broad range of 139 fixed and mobile services including high-speed, point-to-point 140 wireless local area networks (WLANs) and broadband access. This band 141 has short wavelengths that range from 10 millimeters to 1 142 millimeter, namely millimeter band or millimeter wave. The 71 - 76 143 GHz, 81 - 86 GHz and 92-95 GHz bands are used for point-to-point 144 high-bandwidth communication links, which allows for higher data 145 rates up to 10 Gbit/s but requires a license. Unlicensed short-range 146 data links can be used on 60 GHz millimeter wave. For instance, the 147 upcoming IEEE Wi-Fi standard 802.11ad will run on the 60 GHz 148 spectrum with data transfer rates of up to 7 Gbit/s. 150 ETSI EN 302 217 series defines the characteristics and requirements 151 of microwave/millimeter wave equipment and antennas. Especially ETSI 152 EN 302 217-2 specifies the essential parameters for the systems 153 operating from 1.4GHz to 86GHz. 155 Carrier Termination and Radio Link Terminal are two concepts defined 156 to support modeling of microwave radio link features and parameters 157 in a structured and yet simple manner. 159 Carrier Termination is an interface for the capacity provided over 160 the air by a single carrier. It is typically defined by its 161 transmitting and receiving frequencies. 163 Radio Link Terminal is an interface providing packet capacity and/or 164 TDM capacity to the associated Ethernet and/or TDM interfaces in a 165 node and used for setting up a transport service over a 166 microwave/millimeter wave link. 168 Figure 1 provides a graphical representation of Carrier Termination 169 and Radio Link Terminal concepts. 171 /--------- Radio Link ---------\ 172 Near End Far End 174 +---------------+ +---------------+ 175 | Radio Link | | Radio Link | 176 | Terminal | | Terminal | 177 | | | | 178 | (Protected or Bonded) | 179 | | | | 180 | +-----------+ | | +-----------+ | 181 | | | | Carrier A | | | | 182 | | Carrier | |<--------->| | Carrier | | 183 | |Termination| | | |Termination| | 184 Packet--| | | | | | | |--Packet 185 | +-----------+ | | +-----------+ | 186 TDM----| | | |----TDM 187 | +-----------+ | | +-----------+ | 188 | | | | Carrier B | | | | 189 | | Carrier | |<--------->| | Carrier | | 190 | |Termination| | | |Termination| | 191 | | | | | | | | 192 | +-----------+ | | +-----------+ | 193 | | | | 194 +---------------+ +---------------+ 196 \--- Microwave Node ---/ \--- Microwave Node ---/ 198 Figure 1. Radio Link Terminal and Carrier Termination 200 Software Defined Networking (SDN) is an emerging architecture that 201 decouples the network control and forwarding functions enabling the 202 network control to become directly programmable and the underlying 203 infrastructure to be abstracted for applications and network 204 services. This results in an extremely dynamic, manageable, cost- 205 effective, and adaptable architecture that gives administrators 206 unprecedented programmability, automation, and control. The SDN 207 concept is widely applied for network management, the adoption of 208 SDN framework to manage and control the microwave and millimeter 209 wave interface is one of the key applications of this work. 211 2. Introduction 213 Network requirements vary between operators globally as well as 214 within individual countries. The overall goal is however the same - 215 to deliver the best possible network performance and quality of 216 experience in a cost-efficient way. 218 Microwave/millimeter wave (hereafter referred to as microwave, but 219 including the frequency bands represented by millimeter wave) are 220 important technologies to fulfill this goal today, but also in the 221 future when demands on capacity and packet features increases. 223 Microwave is already today able to fully support the capacity needs 224 of a backhaul in a radio access network and will evolve to support 225 multiple gigabits in traditional frequency bands and beyond 10 226 gigabits in the millimeter wave. L2 packet features are normally an 227 integrated part of microwave nodes and more advanced L2 and L3 228 features will over time be introduced to support the evolution of 229 the transport services to be provided by a backhaul/transport 230 network. Note that the wireless access technologies such as 3/4/5G 231 and WiFi are not within the scope of this microwave model work. 233 The main application for microwave is backhaul for mobile broadband. 234 Those networks will continue to be modernized using a combination of 235 microwave and fiber technologies. The choice of technology is a 236 question about fiber presence and cost of ownership, not about 237 capacity limitations in microwave. 239 Open and standardized interfaces are a pre-requisite for efficient 240 management of equipment from multiple vendors, integrated in a 241 single system/controller. This framework addresses management and 242 control of the radio link interface(s) and the relationship to other 243 packet interfaces, typically to Ethernet interfaces, in a microwave 244 node. A radio link provides the transport over the air, using one or 245 several carriers in aggregated or protected configurations. 246 Managing and controlling a transport service over a microwave node 247 involves both radio link and packet functionality. 249 Already today there are numerous IETF data models, RFCs and drafts, 250 with technology specific extensions that cover a large part of the 251 packet domain. Examples are IP Management [RFC7277], Routing 252 Management [RFC8022] and Provider Bridge [PB-YANG] They are based 253 on the IETF YANG model for Interface Management [RFC7223], which is 254 an evolution of the SNMP IF-MIB [RFC2863]. 256 Since microwave nodes will contain more and more packet 257 functionality which is expected to be managed using those models, 258 there are advantages if radio link interfaces can be modeled and be 259 managed using the same structure and the same approach, specifically 260 for use cases in which a microwave node are managed as one common 261 entity including both the radio link and the packet functionality, 262 e.g. at basic configuration of node and connections, centralized 263 trouble shooting, upgrade and maintenance. All interfaces in a node, 264 irrespective of technology, would then be accessed from the same 265 core model, i.e. [RFC7223], and could be extended with technology 266 specific parameters in models augmenting that core model. The 267 relationship/connectivity between interfaces could be given by the 268 physical equipment configuration, e.g the slot in which the Radio 269 Link Terminal (modem) is plugged in could be associated with a 270 specific Ethernet port due to the wiring in the backplane of the 271 system, or it could be flexible and therefore configured via a 272 management system or controller. 274 +------------------------------------------------------------------+ 275 | Interface [RFC7223] | 276 | +------------------+ | 277 | |Ethernet Port | | 278 | +------------------+ | 279 | \ | 280 | +-----------------------+ | 281 | |Radio Link Terminal | | 282 | +-----------------------+ | 283 | \ | 284 | +------------------------+ | 285 | |Carrier Termination | | 286 | +------------------------+ | 287 +------------------------------------------------------------------+ 289 Figure 2: Relationship between interfaces in a node 291 There will always be certain implementations that differ among 292 products and it is therefore practically impossible to achieve 293 industry consensus on every design detail. It is therefore important 294 to focus on the parameters that are required to support the use 295 cases applicable for centralized, unified, multi-vendor management 296 and to allow other parameters to be optional or to be covered by 297 extensions to the standardized model. Furthermore, a standard that 298 allows for a certain degree of freedom encourages innovation and 299 competition which is something that benefits the entire industry. It 300 is therefore important that a radio link management model covers all 301 relevant functions but also leaves room for product/feature-specific 302 extensions. 304 For microwave radio link functionality work has been initiated (ONF: 305 Microwave Modeling [ONF-model], IETF: Radio Link Model [I- 306 D.ahlbergccamp-microwave-radio-link]). The purpose of this effort is 307 to reach consensus within the industry around one common approach, 308 with respect to the use cases and requirements to be supported, the 309 type and structure of the model and the resulting attributes to be 310 included. This document describes the use cases and requirements 311 agreed to be covered, the expected characteristics of the model and 312 at the end includes an analysis of how the models in the two on- 313 going initiatives fulfill these expectations and a recommendation on 314 what can be reused and what gaps need to be filled by a new and 315 evolved radio link model. 317 3. Conventions used in this document 319 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 320 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 321 document are to be interpreted as described in [RFC2119]. 323 While [RFC2119] describes interpretations of these key words in 324 terms of protocol specifications and implementations, they are used 325 in this document to describe requirements for the YANG Data Model 326 for Microwave Radio Link. 328 4. Approaches to manage and control radio link interfaces 330 This framework addresses the definition of an open and standardized 331 interface for the radio link functionality in a microwave/millimeter 332 wave node. The application of such an interface used for management 333 and control of nodes and networks typically vary from one operator 334 to another, in terms of the systems used and how they interact. A 335 traditional solution is network management system, while an emerging 336 one is SDN. SDN solutions can be used as part of the network 337 management system, allowing for direct network programmability and 338 automated configurability by means of a centralized SDN control and 339 defining standardized interfaces to program the nodes. 341 4.1. Network Management Solutions 343 The classic network management solutions, with vendor specific 344 domain management combined with cross domain functionality for 345 service management and analytics, still dominates the market. 346 These solutions are expected to evolve and benefit from an increased 347 focus on standardization by simplifying multi-vendor management and 348 remove the need for vendor/domain specific management. 350 4.2. Software Defined Networking 352 One of the main drivers for applying SDN from an operator 353 perspective is simplification and automation of network provisioning 354 as well as E2E network service management. The vision is to have a 355 global view of the network conditions spanning across different 356 vendors' equipment and multiple technologies. 358 If nodes from different vendors shall be managed by the same SDN 359 controller via a node management interface (north bound interface, 360 NBI), without the extra effort of introducing intermediate systems, 361 all nodes must align their node management interfaces. Hence, an 362 open and standardized node management interface are required in a 363 multi-vendor environment. Such standardized interface enables a 364 unified management and configuration of nodes from different vendors 365 by a common set of applications. 367 On top of SDN applications to configure, manage and control the 368 nodes and their associated transport interfaces including the L2 369 Ethernet and L3 packet interfaces as well as the radio interfaces, 370 there are also a large variety of other more advanced SDN 371 applications that can be exploited and/or developed. 373 A potential flexible approach for the operators is to use SDN in a 374 logical control way to manage the radio links by selecting a 375 predefined operation mode. The operation mode is a set of logical 376 metrics or parameters describing a complete radio link 377 configuration, such as capacity, availability, priority and power 378 consumption. 380 An example of an operation mode table is shown in Figure 3. Based on 381 its operation policy (e.g., power consumption or traffic priority), 382 the SDN controller selects one operation mode and translates that 383 into the required configuration of the individual parameters for the 384 radio link terminals and the associated carrier terminations. 386 +----+---------------+------------+-------------+-----------+------+ 387 | ID |Description | Capacity |Availability | Priority |Power | 388 +----+---------------+------------+-------------+-----------+------+ 389 | 1 |High capacity | 400 Mbps | 99.9% | Low |High | 390 +----+---------------+------------+-------------+-----------+------+ 391 | 2 |High avail- | 100 Mbps | 99.999% | High |Low | 392 | | ability | | | | | 393 +----+---------------+------------+-------------+-----------+------+ 395 Figure 3. Example of an operation mode table 397 An operation mode bundles together the values of a set of different 398 parameters. How each operation mode maps into certain set of 399 attributes is out of scope of this document. Effort on a 400 standardizing operation mode is required to implement a smoothly 401 operator environment. 403 5. Use Cases 405 The use cases described should be the basis for identification and 406 definition of the parameters to be supported by a YANG Data model 407 for management of radio links, applicable for centralized, unified, 408 multi-vendor management. 410 Other product specific use cases, addressing e.g. installation, on- 411 site trouble shooting and fault resolution, are outside the scope of 412 this framework. If required, these use cases are expected to be 413 supported by product specific extensions to the standardized model. 415 5.1. Configuration Management 417 Configuration of a radio link terminal, the constituent carrier 418 terminations and when applicable the relationship to packet/Ethernet 419 and TDM interfaces. 421 5.1.1. Understand the capabilities and limitations 423 Exchange of information between a manager and a device about the 424 capabilities supported and specific limitations in the parameter 425 values and enumerations that can be used. 427 Support for the XPIC (Cross Polarization Interference Cancellation) 428 feature or not and the maximum modulation supported are two examples 429 on information that could be exchanged. 431 5.1.2. Initial Configuration 433 Initial configuration of a radio link terminal, enough to establish 434 L1 connectivity over the hop to an associated radio link terminal on 435 a device at far end. It MAY also include configuration of the 436 relationship between a radio link terminal and an associated traffic 437 interface, e.g. an Ethernet interface, unless that is given by the 438 equipment configuration. 440 Frequency, modulation, coding and output power are examples of 441 parameters typically configured for a carrier termination and type 442 of aggregation/bonding or protection configurations expected for a 443 radio link terminal. 445 5.1.3. Radio link re-configuration and optimization 447 Re-configuration, update or optimization of an existing radio link 448 terminal. Output power and modulation for a carrier termination and 449 protection schemas and activation/de-activation of carriers in a 450 radio link terminal are examples on parameters that can be re- 451 configured and used for optimization of the performance of a 452 network. 454 5.1.4. Radio link logical configuration 456 Radio link terminals comprising a group of carriers are widely used 457 in microwave technology. There are several kinds of groups: 458 aggregation/bonding, 1+1 protection/redundancy, etc. To avoid 459 configuration on each carrier termination directly, a logical 460 control provides flexible management by mapping a logical 461 configuration to a set of physical attributes. This could also be 462 applied in a hierarchical SDN environment where some domain 463 controllers are located between the SDN controller and the radio 464 link terminal. 466 5.2. Inventory 468 5.2.1. Retrieve logical inventory and configuration from device 470 Request from manager and response by device with information about 471 radio interfaces, their constitution and configuration. 473 5.2.2. Retrieve physical/equipment inventory from device 475 Request from manager about physical and/or equipment inventory 476 associated with the radio link terminals and carrier terminations. 478 5.3. Status and statistics 480 5.3.1. Actual status and performance of a radio link interface 482 Manager requests and device responds with information about actual 483 status and statistics of configured radio link interfaces and their 484 constituent parts. 486 5.4. Performance management 488 5.4.1. Configuration of historical measurements to be performed 490 Configuration of historical measurements to be performed on a radio 491 link interface and/or its constituent parts is a subset of the 492 configuration use case to be supported. See 5.1 above. 494 5.4.2. Collection of historical performance data 496 Collection of historical performance data in bulk by the manager is 497 a general use case for a device and not specific to a radio link 498 interface. 500 Collection of an individual counter for a specific interval is in 501 same cases required as a complement to the retrieval in bulk as 502 described above. 504 5.5. Fault Management 506 5.5.1. Configuration of alarm reporting 508 Configuration of alarm reporting associated specifically with radio 509 interfaces, e.g. configuration of alarm severity, is a subset of the 510 configuration use case to be supported. See 5.1 above. 512 5.5.2. Alarm management 514 Alarm synchronization, visualization, handling, notifications and 515 events are generic use cases for a device and not specific to a 516 radio link interface and should be supported accordingly. 518 5.6. Troubleshooting and Root Cause Analysis 520 Information and actions required by a manager/operator to 521 investigate and understand the underlying issue to a problem in the 522 performance and/or functionality of a radio link terminal and the 523 associated carrier terminations. 525 6. Requirements 527 For managing a microwave node including both the radio link and the 528 packet functionality, a unified data model is desired to unify the 529 modeling of the radio link interfaces and the packet interfaces 530 using the same structure and the same modelling approach. If some 531 part of model is generic for other technology usage, it should be 532 clearly stated. 534 The purpose of the YANG Data Model is for management and control of 535 the radio link interface(s) and the relationship/connectivity to 536 other packet interfaces, typically to Ethernet interfaces, in a 537 microwave node. 539 The capability of configuring and managing microwave nodes includes 540 the following requirements for the modelling: 542 1) It MUST be possible to configure, manage and control a radio link 543 terminal and the constituent carrier terminations. 545 a) Frequency, channel bandwidth, modulation, coding and 546 transmitter power are examples of parameters typically 547 configured for a carrier termination. 549 b) A radio link terminal MUST configure the associated carrier 550 terminations and the type of aggregation/bonding or protection 551 configurations expected for the radio link terminal. 553 c) The capability, e.g. the maximum modulation supported, and the 554 actual status/statistics, e.g. administrative status of the 555 carriers, SHOULD also be supported by the data model. 557 d) The definition of the features and parameters SHOULD be based 558 on established microwave equipment and radio standards, such 559 as ETSI EN 302 217 [EN 302 217-2] which specifies the essential 560 parameters for microwave systems operating from 1.4GHz to 561 86GHz. 563 2) It MUST be possible to map different traffic types (e.g. TDM, 564 Ethernet) to the transport capacity provided by a specific radio 565 link terminal. 567 3) It MUST be possible to configure and collect historical 568 measurements (for the use case described in section 5.4) to be 569 performed on a radio link interface, e.g. minimum, maximum and 570 average transmit power and receive level in dBm. 572 4) It MUST be possible to configure and retrieve alarms reporting 573 associated with the radio interfaces, e.g. configuration of alarm 574 severity, supported alarms like configuration fault, signal lost, 575 modem fault, radio fault. 577 7. Gap Analysis on Models 579 The purpose of the gap analysis is to identify and recommend what 580 existing and established models as well as draft models under 581 definition to support the use cases and requirements specified in 582 the previous chapters. It shall also make a recommendation on how 583 the gaps not supported should be filled, including the need for 584 development of new models and evolution of existing models and 585 drafts. 587 For microwave radio link functionality work has been initiated (ONF: 588 Microwave Modeling [ONF-model], IETF: Radio Link Model [I- 589 D.ahlbergccamp-microwave-radio-link]. The analysis is expected to 590 take these initiatives into consideration and make a recommendation 591 on how to make use of them and how to complement them in order to 592 fill the gaps identified. 594 For generic functionality, not specific for radio link, the ambition 595 is to refer to existing or emerging models that could be applicable 596 for all functional areas in a microwave node. 598 7.1. Microwave Radio Link Functionality 600 [ONF-CIM] defines a CoreModel of the ONF Common Information Model. 601 An information model describes the things in a domain in terms of 602 objects, their properties (represented as attributes), and their 603 relationships. The ONF information model is expressed in Unified 604 Modeling Language (UML). The ONF CoreModel is independent of 605 specific data plane technology. Data plane technology specific 606 properties are acquired in a runtime solution via "filled in" cases 607 of specification (LtpSpec etc). These can be used to augment the 608 CoreModel to provide a data plane technology specific representation. 610 IETF Data Model defines an implementation and NETCONF-specific 611 details. YANG is a data modeling language used to model the 612 configuration and state data. It is well aligned with the structure 613 of the Yang data models proposed for the different packet interfaces 614 which are all based on [RFC7223]. Furthermore, several YANG data 615 models have been proposed in the IETF for other transport 616 technologies such as optical transport; e.g. [RFC7277], 617 [I.D.zhang-ccamp-l1-topo-yang], [I.D.ietf-ospf-yang]. In light of 618 this trend, the IETF data model is becoming a popular approach for 619 modeling most packet transport technology interfaces and it is 620 thereby well positioned to become an industry standard. 622 [RFC3444] explains the difference between Information Model(IM) and 623 Data Models(DM). IM is to model managed objects at a conceptual level 624 for designers and operators, DM is defined at a lower level and 625 includes many details for implementers. In addition, the 626 protocol-specific details are usually included in DM. Since 627 conceptual models can be implemented in different ways, multiple DMs 628 can be derived from a single IM. To ensure better interoperability, 629 it is better to focus on DM directly. 631 [RFC7223] describes an interface management model, however it doesn't 632 include technology specific information, e.g., for radio interface. 633 [I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal 634 for radio interfaces, which includes support for basic configuration, 635 status and performance but lacks full support for alarm management 636 and interface layering, i.e. the connectivity of the transported 637 capacity (TDM and Ethernet) with other internal technology specific 638 interfaces in a microwave node. 640 The recommendation is to use the structure of the IETF: Radio Link 641 Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point, 642 since it is a data model providing the wanted alignment with 643 [RFC7223]. For the definition of the detailed leafs/parameters, the 644 recommendation is to use the IETF: Radio Link Model and the ONF: 645 Microwave Modeling [ONF-model] as the basis and to define new ones 646 to cover identified gaps. The parameters in those models have been 647 defined by both operators and vendors within the industry and the 648 implementations of the ONF Model have been tested in the Proof of 649 Concept events in multi-vendor environments, showing the validity of 650 the approach proposed in this framework document. 652 It is also recommended to add the required data nodes to describe 653 the interface layering for the capacity provided by a radio link 654 terminal and the associated Ethernet and TDM interfaces in a 655 microwave node. The principles and data nodes for interface layering 656 described in [RFC7223] should be used as a basis. 658 7.2. Generic Functionality 660 For generic functionality, not specific for radio link, the 661 recommendation is to refer to existing RFCs or emerging drafts 662 according to the table in figure 4 below. New Radio Link Model is 663 used in the table for the cases where the functionality is 664 recommended to be included in the new radio link model as described 665 in chapter 7.1. 667 +------------------------------------+-----------------------------+ 668 | Generic Functionality | Recommendation | 669 | | | 670 +------------------------------------+-----------------------------+ 671 |1.Fault Management | | 672 | | | 673 | Alarm Configuration | New Radio Link Model | 674 | | | 675 | Alarm notifications/ | [I-D.vallin-ccamp- | 676 | synchronization | alarm-module] | 677 +------------------------------------+-----------------------------+ 678 |2.Performance Management | | 679 | | | 680 | Performance Configuration/ | New Radio Link Model | 681 | Activation | | 682 | | | 683 | Performance Collection | New Radio Link Model and | 684 | | XML files | 685 +------------------------------------+-----------------------------+ 686 |3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] | 687 +------------------------------------+-----------------------------+ 689 Figure 4. Recommendation on how to support generic functionality 691 Microwave specific alarm configurations are recommended to be 692 included in the new radio link model and could be based on what is 693 supported in the IETF and ONF Radio Link Models. Alarm notifications 694 and synchronization are general and is recommended to be supported 695 by a generic model, such as [I-D.vallin-ccamp-alarm-module]. 697 Activation of interval counters and thresholds could be a generic 698 function but it is recommended to be supported by the new radio link 699 specific model and can be based on both the ONF and IETF Microwave 700 Radio Link models. 702 Collection of interval/historical counters is a generic function 703 that needs to be supported in a node. File based collection via SFTP 704 and collection via a Netconf/YANG interfaces are two possible 705 options and the recommendation is to include support for the latter 706 in the new radio link specific model. The ONF and IETF Microwave 707 Radio Link models can be used as a basis also in this area. 709 Physical and/or equipment inventory associated with the radio link 710 terminals and carrier terminations is recommended to be covered by a 711 model generic for the complete node, e.g. [I-D.ietf-netmod-entity] 712 and it is thereby outside the scope of the radio link specific 713 model. 715 7.3. Summary 717 The conclusions and recommendations from the analysis can be 718 summarized as follows: 720 1) A Microwave Radio Link YANG Data Model should be defined with a 721 scope enough to support the use cases and requirements in 722 chapter 5 and 6 of this document. 724 2) Use the structure in the IETF: Radio Link Model [I-D.ahlberg- 725 ccamp-microwave-radio-link] as the starting point. It augments 726 [RFC7223] and is thereby as required aligned with the structure 727 of the models for management of the packet domain. 729 3) Use established microwave equipment and radio standards, such 730 as [EN 302 217-2], and the IETF: Radio Link Model 731 [I-D.ahlberg-ccamp-microwave-radio-link] and the 732 ONF: Microwave Modeling [ONF-model] as the basis for the 733 definition of the detailed leafs/parameters to support the 734 specified use cases and requirements, and proposing new ones 735 to cover identified gaps. 737 4) Add the required data nodes to describe the interface layering 738 for the capacity provided by a radio link terminal and the 739 associated Ethernet and TDM interfaces, using the principles 740 and data nodes for interface layering described in [RFC7223] as 741 a basis. 743 5) Include support for configuration of microwave specific alarms 744 in the Microwave Radio Link model and rely on a generic model 745 such as [I.D.vallin-ccamp-alarm-module] for notifications and 746 alarm synchronization. 748 6) Use a generic model such as [I-D.ietf-netmod-entity] for 749 physical/equipment inventory. 751 It is furthermore recommended that the Microwave Radio Link YANG 752 Date Model should be validated by both operators and vendors as 753 part of the process to make it stable and mature. During the 754 Hackathon in IETF 99, a project "SDN Applications for microwave 755 radio link via IETF YANG Data Model" successfully validated this 756 framework and the YANG data model[I.D.ietf-ccamp-mw-yang]. The 757 project also received the BEST OVERALL award from the Hackathon. 759 8. Security Considerations 761 Security issue concerning the access control to Management interfaces 762 can be generally addressed by authentication techniques providing 763 origin verification, integrity and confidentiality. In additon, 764 management interfaces can be physically or logically isolated, 765 by configuring them to be only accessible out-of-band, through 766 a system that is physically or logically separated from the rest of 767 the network infrastructure. In case where management interfaces are 768 accessible in-band at the client device or within the microwave 769 transport netork domain, filtering or firewalling techniques 770 can be used to restrict unauthorized in-band traffic. Authentication 771 techniques may be additionally used in all cases. 773 This framework describes the requirements and charactersitics of 774 of a YANG Data Model for control and management of the radio link 775 interfaces in a microwave node. It is supposed to be accessed via a 776 management protocol with a secure transport layer, such as NETCONF 777 [RFC6241]. 779 9. IANA Considerations 781 This memo includes no request to IANA. 783 10. References 785 10.1. Normative References 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, 790 . 792 [RFC2863] McCloghrie K. and Kastenholz F., "The Interfaces Group 793 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 794 . 796 [RFC3444] Pras A., Schoenwaelder J., "On the Difference between 797 Information Models and Data Models", RFC 3444, DOI 798 10.17487/RFC3444, January 2003, 799 . 801 [RFC7223] Bjorklund M., "A YANG Data Model for Interface 802 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 803 . 805 [RFC7277] Bjorklund M., "A YANG Data Model for IP Management", RFC 806 7277, DOI 10.17487/RFC7277, June 2014, 807 . 809 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 810 Bierman, "Network Configuration Protocol (NETCONF)", 811 RFC 6241, June 2011. 813 10.2. Informative References 815 [I-D.ahlberg-ccamp-microwave-radio-link] 816 Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., 817 and M. Vaupotic, "Microwave Radio Link YANG Data Models", 818 draft-ahlberg-ccamp-microwave-radio-link-01 (work in 819 progress), May 2016. 821 [I-D.ietf-netmod-entity] 822 Bierman A., Bjorklund M., Dong J., Romascanu D., "A YANG 823 Data Model for Entity Management", draft-ietf-netmod- 824 entity-05 (work in progress), October 2017. 826 [I-D.vallin-ccamp-alarm-module] 827 Vallin S. and Bjorklund M., "YANG Alarm Module", draft- 828 vallin-ccamp-alarm-module-01 (work in progress), October 829 2017. 831 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 832 Management", RFC 8022, DOI 10.17487/RFC8022, November 2016 834 [I.D.zhang-ccamp-l1-topo-yang] 835 Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model 836 for Layer 1 (ODU) Network Topology", draft-zhang-ccamp-l1- 837 topo-yang-03 (work in progress), July 2016. 839 [I.D.ietf-ospf-yang] 840 Yeung D., Qu Y., Zhang J., Bogdanovic D., Sreenivasa K., 841 "Yang Data Model for OSPF Protocol", draft-ietf-ospf-yang- 842 05,(work in progress), July 2016. 844 [ONF-model] 845 ONF TR-532, "Microwave Information Model", version 1.0, 846 December 2016, available at 847 https://www.opennetworking.org/images/stories/downloads/ 848 sdn-resources/technical-reports/TR-532-Microwave- 849 Information-Model-V1.pdf 851 [ONF-CIM] ONF TR-512, "Core Information Model", version 1.2, 852 September 2016, available at 853 https://www.opennetworking.org/wp-content/uploads/2014/10/ 854 TR-512_CIM_(CoreModel)_1.2.zip 856 [PB-YANG] "IEEE 802.1X and 802.1Q YANG models", Marc,H., October 857 2015. 859 [EN 302 217-2] 860 ETSI, "Fixed Radio Systems; Characteristics and 861 requirements for point to-point equipment and antennas; 862 Part 2: Digital systems operating in frequency bands from 863 1 GHz to 86 GHz; Harmonised Standard covering the 864 essential requirements of article 3.2 of Directive 865 2014/53/EU", EN 302 217-2 V3.1.1, May 2017. 867 [I.D.ietf-ccamp-mw-yang] 868 Ahlberg, J., Ye, M., Li,X., Kawada K., Bernardos C., 869 Spreafico D., Vaupotic M., "A YANG Data Model for 870 Microwave Radio Link", draft-ietf-ccamp-mw-yang-01,(work 871 in progress), July 2016. 873 Authors' Addresses 875 Jonas Ahlberg 876 Ericsson AB 877 Lindholmspiren 11 878 Goeteborg 417 56 879 Sweden 881 Email: jonas.ahlberg@ericsson.com 883 Luis M. Contreras 884 Telefonica I+D 885 Ronda de la Comunicacion, S/N 886 Madrid 28050 887 Spain 889 Email: luismiguel.contrerasmurillo@telefonica.com 891 Ye Min 892 Huawei Technologies CO., Ltd 893 No.1899, Xiyuan Avenue 894 Chengdu 611731 895 P.R.China 897 Email: amy.yemin@huawei.com 899 Marko Vaupotic 900 Aviat Networks 901 Motnica 9 902 Trzin-Ljubljana 1236 903 Slovenia 905 Email: Marko.Vaupotic@aviatnet.com 906 Jeff Tantsura 907 Individual 909 Email: jefftant.ietf@gmail.com 911 Koji Kawada 912 NEC Corporation 913 1753, Shimonumabe Nakahara-ku 914 Kawasaki, Kanagawa 211-8666 915 Japan 917 Email: k-kawada@ah.jp.nec.com 919 Xi Li 920 NEC Laboratories Europe 921 Kurfuersten-Anlage 36 922 69115 Heidelberg 923 Germany 925 Email: Xi.Li@neclab.eu 927 Ippei Akiyoshi 928 NEC 929 1753, Shimonumabe Nakahara-ku 930 Kawasaki, Kanagawa 211-8666 931 Japan 933 Email: i-akiyoshi@ah.jp.nec.com 935 Carlos J. Bernardos 936 Universidad Carlos III de Madrid 937 Av. Universidad, 30 938 Leganes, Madrid 28911 939 Spain 941 Email: cjbc@it.uc3m.es 943 Daniela Spreafico 944 Nokia - IT 945 Via Energy Park, 14 946 Vimercate (MI) 20871 947 Italy 949 Email: daniela.spreafico@nokia.com