idnits 2.17.1 draft-ietf-ccamp-microwave-framework-06.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 (May 18, 2018) is 2142 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-alarm-module-01 == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-mw-yang-05 == Outdated reference: A later version (-17) exists of draft-ietf-ccamp-otn-topo-yang-02 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-11 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: November 19, 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 May 18, 2018 14 A framework for Management and Control of microwave and millimeter wave 15 interface parameters 16 draft-ietf-ccamp-microwave-framework-06 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, e.g., ETH technology. 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 November 19, 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 . . 11 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 . . . . . . . . . 12 94 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 95 6. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 96 6.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 97 6.2. Generic Functionality . . . . . . . . . . . . . . . . . . 15 98 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 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 Ethernet 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 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 transport 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 L2 145 and L3 domains. Examples are IP Management [RFC8344], Routing 146 Management [RFC8349] and Provider Bridge [PB-YANG]. They are based 147 on the IETF YANG model for Interface Management [RFC8343], which is 148 an evolution of the SNMP IF-MIB [RFC2863]. 150 Since microwave nodes will contain more and more L2 and L3(packet) 151 functionality which is expected to be managed using those models, 152 there are advantages if radio link interfaces can be modeled and be 153 managed using the same structure and the same approach, specifically 154 for use cases in which a microwave node is managed as one common 155 entity including both the radio link and the L2 and L3 functionality, 156 e.g. at basic configuration of node and connections, centralized 157 trouble 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. [RFC8343], 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 [RFC8343] | 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.ietf-ccamp-mw-yang]). The purpose of this effort is to reach 201 consensus within the industry around one common approach, with 202 respect to the use cases and requirements to be supported, the type 203 and structure of the model and the resulting attributes to be 204 included. This document describes the use cases and requirements 205 agreed to be covered, the expected characteristics of the model and 206 at the end includes an analysis of how the models in the two on-going 207 initiatives fulfill these expectations and a recommendation on what 208 can be reused and what gaps need to be filled by a new and evolved 209 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] [RFC8174] 216 when, and only when, they appear in all capitals, as shown here. 218 While [RFC2119] [RFC8174] describes interpretations of these key 219 words in terms of protocol specifications and implementations, they 220 are used in this document to describe high level requirements to be 221 met when defining the YANG Data Model for Microwave Radio Link. 223 This document does not define any protocol extension, hence only 224 [RFC2119] [RFC8174] can be considered as a normative reference. 225 However, the list of normative references includes a number of 226 documents that can be useful for a better understanding of the 227 context. 229 2. Terminology and Definitions 231 Microwave radio is a term commonly used for technologies that operate 232 in both microwave and millimeter wave lengths and in frequency bands 233 from 1.4 GHz up to and beyond 100 GHz. In traditional bands it 234 typically supports capacities of 1-3 Gbps and in 70/80 GHz band up to 235 10 Gbps. Using multi-carrier systems operating in frequency bands 236 with wider channels, the technology will be capable of providing 237 capacities up 100 Gbps. 239 The microwave radio technology is widely used for point-to-point 240 telecommunications because of its small wavelength that allows 241 conveniently-sized antennas to direct them in narrow beams, and the 242 comparatively higher frequencies that allow broad bandwidth and high 243 data transmission rates. It is used for a broad range of fixed and 244 mobile services including high-speed, point-to-point wireless local 245 area networks (WLANs) and broadband access. 247 ETSI EN 302 217 series defines the characteristics and requirements 248 of microwave equipment and antennas. Especially ETSI EN 302 217-2 249 [EN302217-2] specifies the essential parameters for the systems 250 operating from 1.4GHz to 86GHz. 252 Carrier Termination and Radio Link Terminal are two concepts defined 253 to support modeling of microwave radio link features and parameters 254 in a structured and yet simple manner. 256 Carrier Termination is an interface for the capacity provided over 257 the air by a single carrier. It is typically defined by its 258 transmitting and receiving frequencies. 260 Radio Link Terminal is an interface providing Ethernet capacity and/ 261 or Time Division Multiplexing (TDM) capacity to the associated 262 Ethernet and/or TDM interfaces in a node and used for setting up a 263 transport service over a microwave radio link. 265 Figure 2 provides a graphical representation of Carrier Termination 266 and Radio Link Terminal concepts. 268 /--------- Radio Link ---------\ 269 Near End Far End 271 +---------------+ +---------------+ 272 | Radio Link | | Radio Link | 273 | Terminal | | Terminal | 274 | | | | 275 | (Protected or Bonded) | 276 | | | | 277 | +-----------+ | | +-----------+ | 278 | | | | Carrier A | | | | 279 | | Carrier | |<--------->| | Carrier | | 280 | |Termination| | | |Termination| | 281 ETH----| | | | | | | |----ETH 282 | +-----------+ | | +-----------+ | 283 TDM----| | | |----TDM 284 | +-----------+ | | +-----------+ | 285 | | | | Carrier B | | | | 286 | | Carrier | |<--------->| | Carrier | | 287 | |Termination| | | |Termination| | 288 | | | | | | | | 289 | +-----------+ | | +-----------+ | 290 | | | | 291 +---------------+ +---------------+ 293 \--- Microwave Node ---/ \--- Microwave Node ---/ 295 Figure 2: Radio Link Terminal and Carrier Termination 297 Software Defined Networking (SDN) is an architecture that decouples 298 the network control and forwarding functions enabling the network 299 control to become directly programmable and the underlying 300 infrastructure to be abstracted for applications and network 301 services. SDN can be used as a term for automation of traditional 302 network management, which can be implemented using a similar 303 approach. The adoption of an SDN framework for management and 304 control the microwave interface is the key purpose of this work. 306 3. Approaches to manage and control radio link interfaces 308 This framework addresses the definition of an open and standardized 309 interface for the radio link functionality in a microwave node. The 310 application of such an interface used for management and control of 311 nodes and networks typically vary from one operator to another, in 312 terms of the systems used and how they interact. A traditional 313 solution is network management system(NMS), while an emerging one is 314 SDN. SDN solutions can be used as part of the network management 315 system, allowing for direct network programmability and automated 316 configurability by means of a centralized SDN control and 317 standardized interfaces to program the nodes. It's noted that 318 there's idea that the NMS and SDN are evolving towards a component, 319 and the distinction between them is quite vague. Another fact is 320 that there is still plenty of networks where NMS is still considered 321 as the implementation of the management plane, while SDN is 322 considered as the centralization of the control plane. They are 323 still kept as separate components. 325 3.1. Network Management Solutions 327 The classic network management solutions, with vendor specific domain 328 management combined with cross domain functionality for service 329 management and analytics, still dominates the market. These 330 solutions are expected to evolve and benefit from an increased focus 331 on standardization by simplifying multi-vendor management and remove 332 the need for vendor/domain specific management. 334 3.2. Software Defined Networking 336 One of the main drivers for applying SDN from an operator perspective 337 is simplification and automation of network provisioning as well as 338 end to end network service management. The vision is to have a 339 global view of the network conditions spanning across different 340 vendors' equipment and multiple technologies. 342 If nodes from different vendors shall be managed by the same SDN 343 controller via a node management interface (north bound interface, 344 NBI), without the extra effort of introducing intermediate systems, 345 all nodes must align their node management interfaces. Hence, an 346 open and standardized node management interface are required in a 347 multi-vendor environment. Such standardized interface enables a 348 unified management and configuration of nodes from different vendors 349 by a common set of applications. 351 On top of SDN applications to configure, manage and control the nodes 352 and their associated transport interfaces including the L2 Ethernet 353 and L3 IP interfaces as well as the radio interfaces, there are also 354 a large variety of other more advanced SDN applications that can be 355 exploited and/or developed. 357 A potential flexible approach for the operators is to use SDN in a 358 logical control way to manage the radio links by selecting a 359 predefined operation mode. The operation mode is a set of logical 360 metrics or parameters describing a complete radio link configuration, 361 such as capacity, availability, priority and power consumption. 363 An example of an operation mode table is shown in Figure 3. Based on 364 its operation policy (e.g., power consumption or traffic priority), 365 the SDN controller selects one operation mode and translates that 366 into the required configuration of the individual parameters for the 367 radio link terminals and the associated carrier terminations. 369 +----+---------------+------------+-------------+-----------+------+ 370 | ID |Description | Capacity |Availability | Priority |Power | 371 +----+---------------+------------+-------------+-----------+------+ 372 | 1 |High capacity | 400 Mbps | 99.9% | Low |High | 373 +----+---------------+------------+-------------+-----------+------+ 374 | 2 |High avail- | 100 Mbps | 99.999% | High |Low | 375 | | ability | | | | | 376 +----+---------------+------------+-------------+-----------+------+ 378 Figure 3: Example of an operation mode table 380 An operation mode bundles together the values of a set of different 381 parameters. How each operation mode maps into certain set of 382 attributes is out of scope of this document. Effort on a 383 standardizing operation mode is required to implement a smoothly 384 operator environment. 386 4. Use Cases 388 The use cases described should be the basis for identification and 389 definition of the parameters to be supported by a YANG Data model for 390 management of radio links, applicable for centralized, unified, 391 multi-vendor management. 393 Other product specific use cases, addressing e.g. installation, on- 394 site trouble shooting and fault resolution, are outside the scope of 395 this framework. If required, these use cases are expected to be 396 supported by product specific extensions to the standardized model. 398 4.1. Configuration Management 400 Configuration of a radio link terminal, the constituent carrier 401 terminations and when applicable the relationship to IP/Ethernet and 402 TDM interfaces. 404 4.1.1. Understand the capabilities and limitations 406 Exchange of information between a manager and a device about the 407 capabilities supported and specific limitations in the parameter 408 values and enumerations that can be used. 410 Support for the XPIC (Cross Polarization Interference Cancellation) 411 feature or not and the maximum modulation supported are two examples 412 on information that could be exchanged. 414 4.1.2. Initial Configuration 416 Initial configuration of a radio link terminal, enough to establish 417 L1 connectivity to an associated radio link terminal on a device at 418 far end over the hop. It MAY also include configuration of the 419 relationship between a radio link terminal and an associated traffic 420 interface, e.g. an Ethernet interface, unless that is given by the 421 equipment configuration. 423 Frequency, modulation, coding and output power are examples of 424 parameters typically configured for a carrier termination and type of 425 aggregation/bonding or protection configurations expected for a radio 426 link terminal. 428 4.1.3. Radio link re-configuration and optimization 430 Re-configuration, update or optimization of an existing radio link 431 terminal. Output power and modulation for a carrier termination and 432 protection schemas and activation/de-activation of carriers in a 433 radio link terminal are examples on parameters that can be re- 434 configured and used for optimization of the performance of a network. 436 4.1.4. Radio link logical configuration 438 Radio link terminals comprising a group of carriers are widely used 439 in microwave technology. There are several kinds of groups: 440 aggregation/bonding, 1+1 protection/redundancy, etc. To avoid 441 configuration on each carrier termination directly, a logical control 442 provides flexible management by mapping a logical configuration to a 443 set of physical attributes. This could also be applied in a 444 hierarchical SDN environment where some domain controllers are 445 located between the SDN controller and the radio link terminal. 447 4.2. Inventory 449 4.2.1. Retrieve logical inventory and configuration from device 451 Request from manager and response by device with information about 452 radio interfaces, their constitution and configuration. 454 4.2.2. Retrieve physical/equipment inventory from device 456 Request from manager about physical and/or equipment inventory 457 associated with the radio link terminals and carrier terminations. 459 4.3. Status and statistics 461 4.3.1. Actual status and performance of a radio link interface 463 Manager requests and device responds with information about actual 464 status and statistics of configured radio link interfaces and their 465 constituent parts. It's important to report the effective bandwidth 466 of a radio link since it can be configured to dynamically adjust the 467 modulation based on the current signal conditions. 469 4.4. Performance management 471 4.4.1. Configuration of historical measurements to be performed 473 Configuration of historical measurements to be performed on a radio 474 link interface and/or its constituent parts is a subset of the 475 configuration use case to be supported. See Section 4.1 above. 477 4.4.2. Collection of historical performance data 479 Collection of historical performance data in bulk by the manager is a 480 general use case for a device and not specific to a radio link 481 interface. 483 Collection of an individual counter for a specific interval is in 484 same cases required as a complement to the retrieval in bulk as 485 described above. 487 4.5. Fault Management 489 4.5.1. Configuration of alarm reporting 491 Configuration of alarm reporting associated specifically with radio 492 interfaces, e.g. configuration of alarm severity, is a subset of the 493 configuration use case to be supported. See Section 4.1 above. 495 4.5.2. Alarm management 497 Alarm synchronization, visualization, handling, notifications and 498 events are generic use cases for a device and not specific to a radio 499 link interface and should be supported accordingly. It's important 500 to report signal degradation of the radio link. 502 4.6. Troubleshooting and Root Cause Analysis 504 Information and actions required by a manager/operator to investigate 505 and understand the underlying issue to a problem in the performance 506 and/or functionality of a radio link terminal and the associated 507 carrier terminations. 509 5. Requirements 511 For managing a microwave node including both the radio link and the 512 packet transport functionality, a unified data model is desired to 513 unify the modeling of the radio link interfaces and the L2/L3 514 interfaces using the same structure and the same modelling approach. 515 If some part of model is generic for other technology usage, it 516 should be clearly stated. 518 The purpose of the YANG Data Model is for management and control of 519 the radio link interface(s) and the relationship/connectivity to 520 other interfaces, typically to Ethernet interfaces, in a microwave 521 node. 523 The capability of configuring and managing microwave nodes includes 524 the following requirements for the modelling: 526 1. It MUST be possible to configure, manage and control a radio link 527 terminal and the constituent carrier terminations. 529 A. Configuration of frequency, channel bandwidth, modulation, 530 coding and transmitter output power MUST be supported for a 531 carrier termination. 533 B. A radio link terminal MUST configure the associated carrier 534 terminations and the type of aggregation/bonding or 535 protection configurations expected for the radio link 536 terminal. 538 C. The capability, e.g. the maximum modulation supported, and 539 the actual status/statistics, e.g. administrative status of 540 the carriers, SHOULD also be supported by the data model. 542 D. The definition of the features and parameters SHOULD be based 543 on established microwave equipment and radio standards, such 544 as ETSI EN 302 217 [EN302217-2] which specifies the essential 545 parameters for microwave systems operating from 1.4GHz to 546 86GHz. 548 2. It MUST be possible to map different traffic types (e.g. TDM, 549 Ethernet) to the transport capacity provided by a specific radio 550 link terminal. 552 3. It MUST be possible to configure and collect historical 553 measurements (for the use case described in section 5.4) to be 554 performed on a radio link interface, e.g. minimum, maximum and 555 average transmit power and receive level in dBm. 557 4. It MUST be possible to configure and retrieve alarms reporting 558 associated with the radio interfaces, e.g. configuration of alarm 559 severity, supported alarms like configuration fault, signal lost, 560 modem fault, radio fault. 562 6. Gap Analysis on Models 564 The purpose of the gap analysis is to identify and recommend what 565 existing and established models as well as draft models under 566 definition to support the use cases and requirements specified in the 567 previous chapters. It shall also make a recommendation on how the 568 gaps not supported should be filled, including the need for 569 development of new models and evolution of existing models and 570 drafts. 572 For microwave radio link functionality work has been initiated (ONF: 573 Microwave Modeling [ONF-model], IETF: Radio Link Model 574 [I-D.ietf-ccamp-mw-yang]. The analysis is expected to take these 575 initiatives into consideration and make a recommendation on how to 576 make use of them and how to complement them in order to fill the gaps 577 identified. 579 For generic functionality, not specific for radio link, the ambition 580 is to refer to existing or emerging models that could be applicable 581 for all functional areas in a microwave node. 583 6.1. Microwave Radio Link Functionality 585 [ONF-CIM] defines a CoreModel of the ONF Common Information Model. 586 An information model describes the things in a domain in terms of 587 objects, their properties (represented as attributes), and their 588 relationships. The ONF information model is expressed in Unified 589 Modeling Language (UML). The ONF CoreModel is independent of 590 specific data plane technology. Data plane technology specific 591 properties are acquired in a runtime solution via "filled in" cases 592 of specification (LtpSpec etc.). These can be used to augment the 593 CoreModel to provide a data plane technology specific representation. 595 IETF Data Model defines an implementation and NETCONF-specific 596 details. YANG is a data modeling language used to model the 597 configuration and state data. It is well aligned with the structure 598 of the YANG data models proposed for the different interfaces which 599 are all based on [RFC8343]. Furthermore, several YANG data models 600 have been proposed in the IETF for other transport technologies such 601 as optical transport; e.g. [RFC8344], 602 [I-D.ietf-ccamp-otn-topo-yang], [I-D.ietf-ospf-yang]. In light of 603 this trend, the IETF data model is becoming a popular approach for 604 modeling most packet transport technology interfaces and it is 605 thereby well positioned to become an industry standard. 607 [RFC3444] explains the difference between Information Model(IM) and 608 Data Models(DM). IM is to model managed objects at a conceptual 609 level for designers and operators, DM is defined at a lower level and 610 includes many details for implementers. In addition, the protocol- 611 specific details are usually included in DM. Since conceptual models 612 can be implemented in different ways, multiple DMs can be derived 613 from a single IM. To ensure better interoperability, it is better to 614 focus on DM directly. 616 [RFC8343] describes an interface management model, however it doesn't 617 include technology specific information, e.g., for radio interface. 618 [I-D.ietf-ccamp-mw-yang] provides a model proposal for radio 619 interfaces, which includes support for basic configuration, status 620 and performance but lacks full support for alarm management and 621 interface layering, i.e. the connectivity of the transported capacity 622 (TDM and Ethernet) with other internal technology specific interfaces 623 in a microwave node. 625 The recommendation is to use the structure of the IETF: Radio Link 626 Model [I-D.ietf-ccamp-mw-yang] as the starting point, since it is a 627 data model providing the wanted alignment with [RFC8343]. For the 628 definition of the detailed leafs/parameters, the recommendation is to 629 use the IETF: Radio Link Model and the ONF: Microwave Modeling 630 [ONF-model] as the basis and to define new ones to cover identified 631 gaps. The parameters in those models have been defined by both 632 operators and vendors within the industry and the implementations of 633 the ONF Model have been tested in the Proof of Concept events in 634 multi-vendor environments, showing the validity of the approach 635 proposed in this framework document. 637 It is also recommended to add the required data nodes to describe the 638 interface layering for the capacity provided by a radio link terminal 639 and the associated Ethernet and TDM interfaces in a microwave node. 640 The principles and data nodes for interface layering described in 641 [RFC8343] should be used as a basis. 643 6.2. Generic Functionality 645 For generic functionality, not specific for radio link, the 646 recommendation is to refer to existing RFCs or emerging drafts 647 according to the table in Figure 4 below. New Radio Link Model is 648 used in the table for the cases where the functionality is 649 recommended to be included in the new radio link model as described 650 in Section 6.1. 652 +------------------------------------+-----------------------------+ 653 | Generic Functionality | Recommendation | 654 | | | 655 +------------------------------------+-----------------------------+ 656 |1.Fault Management | | 657 | | | 658 | Alarm Configuration | New Radio Link Model | 659 | | | 660 | Alarm notifications/ | [I-D.ietf-ccamp- | 661 | synchronization | alarm-module] | 662 +------------------------------------+-----------------------------+ 663 |2.Performance Management | | 664 | | | 665 | Performance Configuration/ | New Radio Link Model | 666 | Activation | | 667 | | | 668 | Performance Collection | New Radio Link Model and | 669 | | XML files | 670 +------------------------------------+-----------------------------+ 671 |3.Physical/Equipment Inventory | [RFC8348] | 672 +------------------------------------+-----------------------------+ 674 Figure 4: Recommendation on how to support generic functionality 676 Microwave specific alarm configurations are recommended to be 677 included in the new radio link model and could be based on what is 678 supported in the IETF and ONF Radio Link Models. Alarm notifications 679 and synchronization are general and is recommended to be supported by 680 a generic model, such as [I-D.ietf-ccamp-alarm-module]. 682 Activation of interval counters and thresholds could be a generic 683 function but it is recommended to be supported by the new radio link 684 specific model and can be based on both the ONF and IETF Microwave 685 Radio Link models. 687 Collection of interval/historical counters is a generic function that 688 needs to be supported in a node. File based collection via SSH File 689 Transfer Protocol(SFTP) and collection via a NETCONF/YANG interfaces 690 are two possible options and the recommendation is to include support 691 for the latter in the new radio link specific model. The ONF and 692 IETF Microwave Radio Link models can be used as a basis also in this 693 area. 695 Physical and/or equipment inventory associated with the radio link 696 terminals and carrier terminations is recommended to be covered by a 697 model generic for the complete node, e.g. [RFC8348] and it is 698 thereby outside the scope of the radio link specific model. 700 6.3. Summary 702 The conclusions and recommendations from the analysis can be 703 summarized as follows: 705 1. A Microwave Radio Link YANG Data Model should be defined with a 706 scope enough to support the use cases and requirements in 707 Sections 4 and 5 of this document. 709 2. Use the structure in the IETF: Radio Link Model 710 [I-D.ietf-ccamp-mw-yang] as the starting point. It augments 711 [RFC8343] and is thereby as required aligned with the structure 712 of the models for management of the L2 and L3 domains. 714 3. Use established microwave equipment and radio standards, such as 715 [EN302217-2], and the IETF: Radio Link Model 716 [I-D.ietf-ccamp-mw-yang] and the ONF: Microwave Modeling 717 [ONF-model] as the basis for the definition of the detailed 718 leafs/parameters to support the specified use cases and 719 requirements, and proposing new ones to cover identified gaps. 721 4. Add the required data nodes to describe the interface layering 722 for the capacity provided by a radio link terminal and the 723 associated Ethernet and TDM interfaces, using the principles and 724 data nodes for interface layering described in [RFC8343] as a 725 basis. 727 5. Include support for configuration of microwave specific alarms in 728 the Microwave Radio Link model and rely on a generic model such 729 as [I-D.ietf-ccamp-alarm-module] for notifications and alarm 730 synchronization. 732 6. Use a generic model such as [RFC8348] for physical/equipment 733 inventory. 735 It is furthermore recommended that the Microwave Radio Link YANG Data 736 Model should be validated by both operators and vendors as part of 737 the process to make it stable and mature. During the Hackathon in 738 IETF 99, a project "SDN Applications for microwave radio link via 739 IETF YANG Data Model" successfully validated this framework and the 740 YANG data model[I-D.ietf-ccamp-mw-yang]. The project also received 741 the BEST OVERALL award from the Hackathon. 743 7. Security Considerations 745 Security issue concerning the access control to Management interfaces 746 can be generally addressed by authentication techniques providing 747 origin verification, integrity and confidentiality. In addition, 748 management interfaces can be physically or logically isolated, by 749 configuring them to be only accessible out-of-band, through a system 750 that is physically or logically separated from the rest of the 751 network infrastructure. In case where management interfaces are 752 accessible in-band at the client device or within the microwave 753 transport network domain, filtering or firewalling techniques can be 754 used to restrict unauthorized in-band traffic. Authentication 755 techniques may be additionally used in all cases. 757 This framework describes the requirements and characteristics of a 758 YANG Data Model for control and management of the radio link 759 interfaces in a microwave node. It is supposed to be accessed via a 760 management protocol with a secure transport layer, such as NETCONF 761 [RFC6241]. 763 8. IANA Considerations 765 This memo includes no request to IANA. 767 9. References 769 9.1. Normative References 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, 773 DOI 10.17487/RFC2119, March 1997, 774 . 776 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 777 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 778 . 780 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 781 Information Models and Data Models", RFC 3444, 782 DOI 10.17487/RFC3444, January 2003, 783 . 785 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 786 and A. Bierman, Ed., "Network Configuration Protocol 787 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 788 . 790 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 791 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 792 May 2017, . 794 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 795 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 796 . 798 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 799 RFC 8344, DOI 10.17487/RFC8344, March 2018, 800 . 802 9.2. Informative References 804 [EN302217-2] 805 "Fixed Radio Systems; Characteristics and requirements for 806 point to-point equipment and antennas; Part 2: Digital 807 systems operating in frequency bands from 1 GHz to 86 GHz; 808 Harmonised Standard covering the essential requirements of 809 article 3.2 of Directive 2014/53/EU", EN 302 217-2 810 V3.1.1 , May 2017. 812 [I-D.ietf-ccamp-alarm-module] 813 Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- 814 ietf-ccamp-alarm-module-01 (work in progress), February 815 2018. 817 [I-D.ietf-ccamp-mw-yang] 818 Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. 819 Vaupotic, "A YANG Data Model for Microwave Radio Link", 820 draft-ietf-ccamp-mw-yang-05 (work in progress), March 821 2018. 823 [I-D.ietf-ccamp-otn-topo-yang] 824 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Liu, X., 825 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 826 Model for Optical Transport Network Topology", draft-ietf- 827 ccamp-otn-topo-yang-02 (work in progress), October 2017. 829 [I-D.ietf-ospf-yang] 830 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 831 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 832 yang-11 (work in progress), April 2018. 834 [ONF-CIM] "Core Information Model", version 1.2 , September 2016, 835 . 838 [ONF-model] 839 "Microwave Information Model", version 1.0 , December 840 2016, 841 . 845 [PB-YANG] "IEEE 802.1X and 802.1Q Module Specifications", version 846 0.4 , May 2015, 847 . 850 [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 851 YANG Data Model for Hardware Management", RFC 8348, 852 DOI 10.17487/RFC8348, March 2018, 853 . 855 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 856 Routing Management (NMDA Version)", RFC 8349, 857 DOI 10.17487/RFC8349, March 2018, 858 . 860 Appendix A. Contributors 861 Marko Vaupotic 862 Aviat Networks 863 Motnica 9 864 Trzin-Ljubljana 1236 865 Slovenia 867 Email: Marko.Vaupotic@aviatnet.com 869 Jeff Tantsura 871 Email: jefftant.ietf@gmail.com 873 Koji Kawada 874 NEC Corporation 875 1753, Shimonumabe Nakahara-ku 876 Kawasaki, Kanagawa 211-8666 877 Japan 879 Email: k-kawada@ah.jp.nec.com 881 Ippei Akiyoshi 882 NEC 883 1753, Shimonumabe Nakahara-ku 884 Kawasaki, Kanagawa 211-8666 885 Japan 887 Email: i-akiyoshi@ah.jp.nec.com 889 Daniela Spreafico 890 Nokia - IT 891 Via Energy Park, 14 892 Vimercate (MI) 20871 893 Italy 895 Email: daniela.spreafico@nokia.com 897 Authors' Addresses 898 Jonas Ahlberg (editor) 899 Ericsson AB 900 Lindholmspiren 11 901 Goteborg 417 56 902 Sweden 904 Email: jonas.ahlberg@ericsson.com 906 Ye Min (editor) 907 Huawei Technologies 908 No.1899, Xiyuan Avenue 909 Chengdu 611731 910 P.R.China 912 Email: amy.yemin@huawei.com 914 Xi Li 915 NEC Laboratories Europe 916 Kurfuersten-Anlage 36 917 Heidelberg 69115 918 Germany 920 Email: Xi.Li@neclab.eu 922 Luis Contreras 923 Telefonica I+D 924 Ronda de la Comunicacion, S/N 925 Madrid 28050 926 Spain 928 Email: luismiguel.contrerasmurillo@telefonica.com 930 Carlos Bernardos 931 Universidad Carlos III de Madrid 932 Av. Universidad, 30 933 Madrid, Leganes 28911 934 Spain 936 Email: cjbc@it.uc3m.es