idnits 2.17.1 draft-mwdt-ccamp-fmwk-00.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 (October 28, 2016) is 2734 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-00 == Outdated reference: A later version (-02) exists of draft-vallin-netmod-alarm-module-00 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-24 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: April 28, 2017 TID 6 A. Ye Min 7 Huawei 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 October 28, 2016 22 A framework for Management and Control of microwave and 23 millimeter wave interface parameters 24 draft-mwdt-ccamp-fmwk-00 26 Abstract 28 To ensure an efficient data transport, meeting the requirements 29 requested by today's transport services, the unification of control 30 and management of microwave and millimeter wave radio link interfaces 31 is a precondition for seamless multilayer networking and automated 32 network wide provisioning and operation. 34 This document describes the required characteristics and use cases 35 for control and management of radio link interface parameters using a 36 YANG Data Model. It focuses on the benefits of a standardized 37 management model that is aligned with how other packet technology 38 interfaces in a microwave/millimeter wave node are modeled, the need 39 to support core parameters and at the same time allow for optional 40 product/feature specific parameters supporting new, unique innovative 41 features until they have become mature enough to be included in the 42 standardized model. 44 The purpose is to create a framework for identification of the 45 necessary information elements and definition of a YANG Data Model 46 for control and management of the radio link interfaces in a 47 microwave/millimeter wave node. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on April 27, 2017. 66 Copyright Notice 68 Copyright (c) 2016 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 84 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 85 3. Conventions used in this document . . . . . . . . . . . . . . 7 86 4. Approaches to manage and control radio link interfaces . . . 8 87 4.1. Network Management Solutions . . . . . . . . . . . . . . 8 88 4.2. Software Defined Networking . . . . . . . . . . . . . . . 8 89 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 5.1. Configuration Management . . . . . . . . . . . . . . . . 9 91 5.1.1. Understand the capabilities & limitations . . . . . . 10 92 5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 93 5.1.3. Radio link re-configuration & optimization . . . . . 10 94 5.1.4. Radio link logical configuration . . . . . . . . . . 10 95 5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 96 5.2.1. Retrieve logical inventory & configuration from device 10 97 5.2.2. Retrieve physical/equipment inventory from device . . 11 98 5.3. Status & statistics . . . . . . . . . . . . . . . . . . . 11 99 5.3.1. Actual status & performance of a radio link interface 11 100 5.4. Performance management . . . . . . . . . . . . . . . . . 11 101 5.4.1. Configuration of historical measurements to be 102 performed . . . . . . . . . . . . . . . . . . . . . . 11 103 5.4.2. Collection of historical performance data . . . . . . 11 104 5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 105 5.5.1. Configuration of alarm reporting . . . . . . . . . . 11 106 5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 107 5.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 108 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 109 7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 110 7.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 111 7.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14 112 7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 116 10.1. Normative References . . . . . . . . . . . . . . . . . 17 117 10.2. Informative References . . . . . . . . . . . . . . . . 17 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 120 1. Terminology and Definitions 122 Microwave is a band of spectrum with wavelengths ranging from 1 123 meter to 1 millimeter and with frequencies ranging between 300 MHz 124 and 300 GHz. Microwave radio technology is widely used for point-to- 125 point telecommunications because of their small wavelength that 126 allows conveniently-sized antennas to direct them in narrow beams, 127 and their comparatively higher frequencies that allows broad 128 bandwidth and high data transmission rates. 130 Millimeter wave is also known as extremely high frequency (EHF) or 131 very high frequency (VHF) by the International Telecommunications 132 Union (ITU), which can be used for high-speed wireless broadband 133 communications. Millimeter wave can be used for a broad range of 134 fixed and mobile services including high-speed, point-to-point 135 wireless local area networks (WLANs) and broadband access. This band 136 has short wavelengths that range from 10 millimeters to 1 137 millimeter, namely millimeter band or millimeter wave. The 71 - 76 138 GHz, 81 - 86 GHz and 92-95 GHz bands are used for point-to-point 139 high-bandwidth communication links, which allows for higher data 140 rates up to 10 Gbit/s but requires a license. Unlicensed short-range 141 data links can be used on 60 GHz millimeter wave. For instance, the 142 upcoming IEEE Wi-Fi standard 802.11ad will run on the 60 GHz 143 spectrum with data transfer rates of up to 7 Gbit/s. 145 Carrier Termination is an interface for the capacity provided over 146 the air by a single carrier. It is typically defined by its 147 transmitting and receiving frequencies. 149 Radio Link Terminal is an interface providing packet capacity and/or 150 TDM capacity to the associated Ethernet and/or TDM interfaces in a 151 node and used for setting up a transport service over a 152 microwave/millimeter wave link. 154 Figure 1 provides a graphical representation of Carrier Termination 155 and Radio Link Terminal concepts. 157 /--------- Radio Link ---------\ 158 Near End Far End 160 +---------------+ +---------------+ 161 | Radio Link | | Radio Link | 162 | Terminal | | Terminal | 163 | | | | 164 | (Protected or Bonded) | 165 | | | | 166 | +-----------+ | | +-----------+ | 167 | | | | Carrier A | | | | 168 | | Carrier | |<--------->| | Carrier | | 169 | |Termination| | | |Termination| | 170 Packet--| | | | | | | |--Packet 171 | +-----------+ | | +-----------+ | 172 TDM----| | | |----TDM 173 | +-----------+ | | +-----------+ | 174 | | | | Carrier B | | | | 175 | | Carrier | |<--------->| | Carrier | | 176 | |Termination| | | |Termination| | 177 | | | | | | | | 178 | +-----------+ | | +-----------+ | 179 | | | | 180 +---------------+ +---------------+ 182 \--- Microwave Node ---/ \--- Microwave Node ---/ 184 Figure 1. Radio Link Terminal and Carrier Termination 186 Software Defined Networking (SDN) is an emerging architecture that 187 decouples the network control and forwarding functions enabling the 188 network control to become directly programmable and the underlying 189 infrastructure to be abstracted for applications and network 190 services. This results in an extremely dynamic, manageable, cost- 191 effective, and adaptable architecture that gives administrators 192 unprecedented programmability, automation, and control. The SDN 193 concept is widely applied for network management, the adoption of 194 SDN framework to manage and control the microwave and millimeter 195 wave interface is one of the key applications of this work. 197 2. Introduction 199 Network requirements vary between operators globally as well as 200 within individual countries. The overall goal is however the same - 201 to deliver the best possible network performance and quality of 202 experience in a cost-efficient way. 204 Microwave/millimeter wave (hereafter referred to as microwave, but 205 including the frequency bands represented by millimeter wave) are 206 important technologies to fulfill this goal today, but also in the 207 future when demands on capacity and packet features increases. 209 Microwave is already today able to fully support the capacity needs 210 of a backhaul in a radio access network and will evolve to support 211 multiple gigabits in traditional frequency bands and beyond 10 212 gigabits in the millimeter wave. L2 packet features are normally an 213 integrated part of microwave nodes and more advanced L2 & L3 214 features will over time be introduced to support the evolution of 215 the transport services to be provided by a backhaul/transport 216 network. Note that the wireless access technologies such as 3/4/5G & 217 WiFi are not within the scope of this microwave model work. 219 The main application for microwave is backhaul for mobile broadband. 220 Those networks will continue to be modernized using a combination of 221 microwave and fiber technologies. The choice of technology is a 222 question about fiber presence and cost of ownership, not about 223 capacity limitations in microwave. 225 Open and standardized interfaces are a pre-requisite for efficient 226 management of equipment from multiple vendors, integrated in a 227 single system/controller. This framework addresses management and 228 control of the radio link interface(s) and the relationship to other 229 packet interfaces, typically to Ethernet interfaces, in a microwave 230 node. A radio link provides the transport over the air, using one or 231 several carriers in aggregated or protected configurations. 232 Managing and controlling a transport service over a microwave node 233 involves both radio link and packet functionality. 235 Already today there are numerous IETF data models, RFCs and drafts, 236 with technology specific extensions that cover a large part of the 237 packet domain. Examples are IP Management [RFC7277], Routing 238 Management [I-D.ietf-netmod-routing-cfg] and Provider Bridge [PB- 239 YANG] They are based on RFC 7223 [RFC7223], which is the IETF YANG 240 model for Interface Management, and is an evolution of the SNMP IF- 241 MIB [RFC2863]. 243 Since microwave nodes will contain more and more packet 244 functionality which is expected to be managed using those models, 245 there are advantages if radio link interfaces can be modeled and be 246 managed using the same structure and the same approach, specifically 247 for use cases in which a microwave node are managed as one common 248 entity including both the radio link and the packet functionality, 249 e.g. at basic configuration of node & connections, centralized 250 trouble shooting, upgrade and maintenance. All interfaces in a node, 251 irrespective of technology, would then be accessed from the same 252 core model, i.e. RFC 7223, and could be extended with technology 253 specific parameters in models augmenting that core model. The 254 relationship/connectivity between interfaces could be given by the 255 physical equipment configuration, e.g the slot in which the Radio 256 Link Terminal (modem) is plugged in could be associated with a 257 specific Ethernet port due to the wiring in the backplane of the 258 system, or it could be flexible and therefore configured via a 259 management system or controller. 261 +------------------------------------------------------------------+ 262 | Interface [RFC7223] | 263 | +------------------+ | 264 | |Ethernet Port | | 265 | +------------------+ | 266 | \ | 267 | +-----------------------+ | 268 | |Radio Link Terminal | | 269 | +-----------------------+ | 270 | \ | 271 | +------------------------+ | 272 | |Carrier Termination | | 273 | +------------------------+ | 274 +------------------------------------------------------------------+ 276 Figure 2: Relationship between interfaces in a node 278 There will always be certain implementations that differ among 279 products and it is therefore practically impossible to achieve 280 industry consensus on every design detail. It is therefore important 281 to focus on the parameters that are required to support the use 282 cases applicable for centralized, unified, multi-vendor management 283 and to allow other parameters to be optional or to be covered by 284 extensions to the standardized model. Furthermore, a standard that 285 allows for a certain degree of freedom encourages innovation and 286 competition which is something that benefits the entire industry. It 287 is therefore important that a radio link management model covers all 288 relevant functions but also leaves room for product/feature-specific 289 extensions. 291 For microwave radio link functionality work has been initiated (ONF: 292 Microwave Modeling [ONF-model], IETF: Radio Link Model [I- 293 D.ahlbergccamp-microwave-radio-link]. The purpose of this effort is 294 to reach consensus within the industry around one common approach, 295 with respect to the use cases and requirements to be supported, the 296 type and structure of the model and the resulting attributes to be 297 included. This document describes the use cases and requirements 298 agreed to be covered, the expected characteristics of the model and 299 at the end includes an analysis of how the models in the two on- 300 going initiatives fulfill these expectations and a recommendation on 301 what can be reused and what gaps need to be filled by a new and 302 evolved radio link model. 304 3. Conventions used in this document 306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 307 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 308 document are to be interpreted as described in RFC 2119 [RFC2119]. 310 While [RFC2119] describes interpretations of these key words in 311 terms of protocol specifications and implementations, they are used 312 in this document to describe requirements for the YANG Data Model 313 for Microwave Radio Link. 315 4. Approaches to manage and control radio link interfaces 317 This framework addresses the definition of an open and standardized 318 interface for the radio link functionality in a microwave/millimeter 319 wave node. The application of such an interface used for management 320 and control of nodes and networks typically vary from one operator 321 to another, in terms of the systems used and how they interact. A 322 traditional solution is network management system, while an emerging 323 one is SDN. SDN solutions can be used as part of the network 324 management system, allowing for direct network programmability and 325 automated configurability by means of a centralized SDN control and 326 defining standardized interfaces to program the nodes. 328 4.1. Network Management Solutions 330 The classic network management solutions, with vendor specific 331 domain management combined with cross domain functionality for 332 service management and analytics, still dominates the market. 333 These solutions are expected to evolve and benefit from an increased 334 focus on standardization by simplifying multi-vendor management and 335 remove the need for vendor/domain specific management. 337 4.2. Software Defined Networking 339 One of the main drivers for applying SDN from an operator 340 perspective is simplification and automation of network provisioning 341 as well as E2E network service management. The vision is to have a 342 global view of the network conditions spanning across different 343 vendors? equipment and multiple technologies. 345 If nodes from different vendors shall be managed by the same SDN 346 controller via a node management interface (north bound interface, 347 NBI), without the extra effort of introducing intermediate systems, 348 all nodes must align their node management interfaces. Hence, an 349 open and standardized node management interface are required in a 350 multi-vendor environment. Such standardized interface enables a 351 unified management and configuration of nodes from different vendors 352 by a common set of applications. 354 On top of SDN applications to configure, manage and control the 355 nodes and their associated transport interfaces including the L2 and 356 L3 packet/Ethernet interfaces as well as the radio interfaces, there 357 are also a large variety of other more advanced SDN applications 358 that can be exploited and/or developed. 360 A potential flexible approach for the operators is to use SDN in a 361 logical control way to manage the radio links by selecting a 362 predefined operation mode. The operation mode is a set of logical 363 metrics or parameters describing a complete radio link 364 configuration, such as capacity, availability, priority and power 365 consumption. 367 An example of an operation mode table is shown in Figure 3. Based on 368 its operation policy (e.g., power consumption or traffic priority), 369 the SDN controller selects one operation mode and translates that 370 into the required configuration of the individual parameters for the 371 radio link terminals and the associated carrier terminations. 373 +----+---------------+------------+-------------+-----------+------+ 374 | ID |Description | Capacity |Availability | Priority |Power | 375 +----+---------------+------------+-------------+-----------+------+ 376 | 1 |High capacity | 400 Mbps | 99.9% | Low |High | 377 +----+---------------+------------+-------------+-----------+------+ 378 | 2 |High avail- | 100 Mbps | 99.999% | High |Low | 379 | | ability | | | | | 380 +----+---------------+------------+-------------+-----------+------+ 382 Figure 3. Example of an operation mode table 384 An operation mode bundles together the values of a set of different 385 parameters. How each operation mode maps into certain set of 386 attributes is out of scope of this document. Effort on a 387 standardizing operation mode is required to implement a smoothly 388 operator environment. 390 5. Use Cases 392 The use cases described should be the basis for identification and 393 definition of the parameters to be supported by a YANG Data model 394 for management of radio links, applicable for centralized, unified, 395 multi-vendor management. 397 Other product specific use cases, addressing e.g. installation, on- 398 site trouble shooting and fault resolution, are outside the scope of 399 this framework. If required, these use cases are expected to be 400 supported by product specific extensions to the standardized model. 402 5.1. Configuration Management 404 Configuration of a radio link terminal, the constituent carrier 405 terminations and when applicable the relationship to packet/Ethernet 406 and TDM interfaces. 408 5.1.1. Understand the capabilities & limitations 410 Exchange of information between a manager and a device about the 411 capabilities supported and specific limitations in the parameter 412 values & enumerations that can be used. 414 Support for the XPIC (Cross Polarization Interference Cancellation) 415 feature or not and the maximum modulation supported are two examples 416 on information that could be exchanged. 418 5.1.2. Initial Configuration 420 Initial configuration of a radio link terminal, enough to establish 421 L1 connectivity over the hop to an associated radio link terminal on 422 a device at far end. It MAY also include configuration of the 423 relationship between a radio link terminal and an associated traffic 424 interface, e.g. an Ethernet interface, unless that is given by the 425 equipment configuration. 427 Frequency, modulation, coding and output power are examples of 428 parameters typically configured for a carrier termination and type 429 of aggregation/bonding or protection configurations expected for a 430 radio link terminal. 432 5.1.3. Radio link re-configuration & optimization 434 Re-configuration, update or optimization of an existing radio link 435 terminal. Output power and modulation for a carrier termination and 436 protection schemas and activation/de-activation of carriers in a 437 radio link terminal are examples on parameters that can be re- 438 configured and used for optimization of the performance of a 439 network. 441 5.1.4. Radio link logical configuration 443 Radio link terminals comprising a group of carriers are widely used 444 in microwave technology. There are several kinds of groups: 445 aggregation/bonding, 1+1 protection/redundancy, etc. To avoid 446 configuration on each carrier termination directly, a logical 447 control provides flexible management by mapping a logical 448 configuration to a set of physical attributes. This could also be 449 applied in a hierarchical SDN environment where some domain 450 controllers are located between the SDN controller and the radio 451 link terminal. 453 5.2. Inventory 455 5.2.1. Retrieve logical inventory & configuration from device 457 Request from manager and response by device with information about 458 radio interfaces, their constitution and configuration. 460 5.2.2. Retrieve physical/equipment inventory from device 462 Request from manager about physical and/or equipment inventory 463 associated with the radio link terminals and carrier terminations. 465 5.3. Status & statistics 467 5.3.1. Actual status & performance of a radio link interface 469 Manager requests and device responds with information about actual 470 status and statistics of configured radio link interfaces and their 471 constituent parts. 473 5.4. Performance management 475 5.4.1. Configuration of historical measurements to be performed 477 Configuration of historical measurements to be performed on a radio 478 link interface and/or its constituent parts is a subset of the 479 configuration use case to be supported. See 5.1 above. 481 5.4.2. Collection of historical performance data 483 Collection of historical performance data in bulk by the manager is 484 a general use case for a device and not specific to a radio link 485 interface. 487 Collection of an individual counter for a specific interval is in 488 same cases required as a complement to the retrieval in bulk as 489 described above. 491 5.5. Fault Management 493 5.5.1. Configuration of alarm reporting 495 Configuration of alarm reporting associated specifically with radio 496 interfaces, e.g. configuration of alarm severity, is a subset of the 497 configuration use case to be supported. See 5.1 above. 499 5.5.2. Alarm management 501 Alarm synchronization, visualization & handling, and notifications & 502 events are generic use cases for a device and not specific to a 503 radio link interface and should be supported accordingly. 505 5.6. Troubleshooting and Root Cause Analysis 507 Information and actions required by a manager/operator to 508 investigate and understand the underlying issue to a problem in the 509 performance and/or functionality of a radio link terminal and the 510 associated carrier terminations. 512 6. Requirements 514 For managing a microwave node including both the radio link and the 515 packet functionality, a unified data model is desired to unify the 516 modeling of the radio link interfaces and the packet interfaces 517 using the same structure and the same modelling approach. 519 The purpose of the YANG Data Model is for management and control of 520 the radio link interface(s) and the relationship/connectivity to 521 other packet interfaces, typically to Ethernet interfaces, in a 522 microwave node. 524 The capability of configuring and managing microwave nodes includes 525 the following requirements for the modelling: 527 1) It MUST be possible to configure, manage and control a radio link 528 terminal and the constituent carrier terminations. 530 a) Frequency, channel bandwidth, modulation, coding and 531 transmitter power are examples of parameters typically 532 configured for a carrier termination. 534 b) A radio link terminal MUST configure the associated carrier 535 terminations and the type of aggregation/bonding or protection 536 configurations expected for the radio link terminal. 538 c) The capability, e.g. the maximum modulation supported, and the 539 actual status/statistics, e.g. administrative status of the 540 carriers, SHOULD also be supported by the data model. 542 2) It MUST be possible to map different traffic types (e.g. TDM, 543 Ethernet) to the transport capacity provided by a specific radio 544 link terminal. 546 3) It MUST be possible to configure and collect historical 547 measurements (for the use case described in section 5.4) to be 548 performed on a radio link interface, e.g. minimum, maximum and 549 average transmit power and receive level in dBm. 551 4) It MUST be possible to configure and retrieve alarms reporting 552 associated with the radio interfaces, e.g. configuration of alarm 553 severity, supported alarms like configuration fault, signal lost, 554 modem fault, radio fault. 556 7. Gap Analysis on Models 558 The purpose of the gap analysis is to identify and recommend what 559 existing and established models as well as draft models under 560 definition to support the use cases and requirements specified in 561 the previous chapters. It shall also make a recommendation on how 562 the gaps not supported should be filled, including the need for 563 development of new models and evolution of existing models and 564 drafts. 566 For microwave radio link functionality work has been initiated (ONF: 567 Microwave Modeling [ONF-model], IETF: Radio Link Model [I- 568 D.ahlbergccamp-microwave-radio-link]. The analysis is expected to 569 take these initiatives into consideration and make a recommendation 570 on how to make use of them and how to complement them in order to 571 fill the gaps identified. 573 For generic functionality, not specific for radio link, the ambition 574 is to refer to existing or emerging models that could be applicable 575 for all functional areas in a microwave node. 577 7.1. Microwave Radio Link Functionality 579 [ONF CIM] defines a CoreModel of the ONF Common Information Model. 580 An information model describes the things in a domain in terms of 581 objects, their properties (represented as attributes), and their 582 relationships. The ONF information model is expressed in Unified 583 Modeling Language (UML). The ONF CoreModel is independent of 584 specific data plane technology. Data plane technology specific 585 properties are acquired in a runtime solution via "filled in" cases 586 of specification (LtpSpec etc). These can be used to augment the 587 CoreModel to provide a data plane technology specific representation. 589 IETF Data Model defines an implementation and NETCONF-specific 590 details. YANG is a data modeling language used to model the 591 configuration and state data. It is well aligned with the structure 592 of the Yang data models proposed for the different packet interfaces 593 which are all based on RFC 7223. Furthermore, several YANG data 594 models have been proposed in the IETF for other transport 595 technologies such as optical transport; e.g., RFC 7277 [RFC7277], 596 [I.D.zhang-ccamp-l1-topo-yang], [I.D.ietf-ospf-yang]. In light of 597 this trend, the IETF data model is becoming a popular approach for 598 modeling most packet transport technology interfaces and it is 599 thereby well positioned to become an industry standard. 601 RFC 3444 [RFC3444] explains the difference between Information 602 Model(IM) and Data Models(DM). IM is to model managed objects at a 603 conceptual level for designers and operators, DM is defined at a 604 lower level and includes many details for implementers. In addition, 605 the protocol-specific details are usually included in DM. Since 606 conceptual models can be implemented in different ways, multiple DMs 607 can be derived from a single IM. To ensure better interoperability, 608 it is better to focus on DM directly. 610 RFC 7223 describes an interface management model, however it doesn?t 611 include technology specific information, e.g., for radio interface. 612 [I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal 613 for radio interfaces, which includes support for basic configuration, 614 status and performance but lacks full support for alarm management 615 and interface layering, i.e. the connectivity of the transported 616 capacity (TDM & Ethernet) with other internal technology specific 617 interfaces in a microwave node. 619 The recommendation is to use the structure of the IETF: Radio Link 620 Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point, 621 since it is a data model providing the wanted alignment with RFC 622 7223. For the definition of the detailed leafs/parameters, the 623 recommendation is to use the IETF: Radio Link Model and the ONF: 624 Microwave Modeling [ONF-model] as the basis and to define new ones 625 to cover identified gaps. The parameters in those models have been 626 defined by both operators and vendors within the industry and the 627 implementations of the ONF Model have been tested in the Proof of 628 Concept events in multi-vendor environments, showing the validity of 629 the approach proposed in this framework document. 631 It is also recommended to add the required data nodes to describe 632 the interface layering for the capacity provided by a radio link 633 terminal and the associated Ethernet and TDM interfaces in a 634 microwave node. The principles and data nodes for interface layering 635 described in RFC 7223 should be used as a basis. 637 7.2. Generic Functionality 639 For generic functionality, not specific for radio link, the 640 recommendation is to refer to existing RFCs or emerging drafts 641 according to the table in figure 4 below. New Radio Link Model is 642 used in the table for the cases where the functionality is 643 recommended to be included in the new radio link model as described 644 in chapter 7.1. 646 +------------------------------------+-----------------------------+ 647 | Generic Functionality | Recommendation | 648 | | | 649 +------------------------------------+-----------------------------+ 650 |1.Fault Management | | 651 | | | 652 | Alarm Configuration | New Radio Link Model | 653 | | | 654 | Alarm notifications/ | [I-D.vallin-netmod- | 655 | synchronization | alarm-module] | 656 +------------------------------------+-----------------------------+ 657 |2.Performance Management | | 658 | | | 659 | Performance Configuration/ | New Radio Link Model | 660 | Activation | | 661 | | | 662 | Performance Collection | New Radio Link Model & | 663 | | XML files | 664 +------------------------------------+-----------------------------+ 665 |3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] | 666 +------------------------------------+-----------------------------+ 668 Figure 4. Recommendation on how to support generic functionality 670 Microwave specific alarm configurations are recommended to be 671 included in the new radio link model and could be based on what is 672 supported in the IETF and ONF Radio Link Models. Alarm notifications 673 and synchronization are general and is recommended to be supported 674 by a generic model, such as [I-D.vallin-netmod-alarm-module]. 676 Activation of interval counters & thresholds could be a generic 677 function but it is recommended to be supported by the new radio link 678 specific model and can be based on both the ONF and IETF Microwave 679 Radio Link models. 681 Collection of interval/historical counters is a generic function 682 that needs to be supported in a node. File based collection via SFTP 683 and collection via a Netconf/YANG interfaces are two possible 684 options and the recommendation is to include support for the latter 685 in the new radio link specific model. The ONF and IETF Microwave 686 Radio Link models can be used as a basis also in this area. 688 Physical and/or equipment inventory associated with the radio link 689 terminals and carrier terminations is recommended to be covered by a 690 model generic for the complete node, e.g. [I-D.ietf-netmod-entity] 691 and it is thereby outside the scope of the radio link specific 692 model. 694 7.3. Summary 696 The conclusions and recommendations from the analysis can be 697 summarized as follows: 699 1) A Microwave Radio Link YANG Data Model should be defined with a 700 scope enough to support the use cases and requirements in 701 chapter 5 and 6 of this document. 703 2) Use the structure in the IETF: Radio Link Model [I-D.ahlberg- 704 ccamp-microwave-radio-link] as the starting point. It augments 705 RFC 7223 and is thereby as required aligned with the structure 706 of the models for management of the packet domain. 708 3) Use the IETF: Radio Link Model [I-D.ahlberg-ccamp-microwave- 709 radio-link] and the ONF: Microwave Modeling [ONF-model] as the 710 basis for the definition of the detailed leafs/parameters to 711 support the specified use cases and requirements, and proposing 712 new ones to cover identified gaps. 714 4) Add the required data nodes to describe the interface layering 715 for the capacity provided by a radio link terminal and the 716 associated Ethernet and TDM interfaces, using the principles 717 and data nodes for interface layering described in RFC 7223 as 718 a basis. 720 5) Include support for configuration of microwave specific alarms 721 in the Microwave Radio Link model and rely on a generic model 722 such as [I.D.vallin-netmod-alarm-module] for notifications and 723 alarm synchronization. 725 6) Use a generic model such as [I-D.ietf-netmod-entity] for 726 physical/equipment inventory. 728 It is furthermore recommended that the Microwave Radio Link YANG 729 Date Model should be validated by both operators and vendors as 730 part of the process to make it stable and mature. 732 8. Security Considerations 734 TBD 736 9. IANA Considerations 738 This memo includes no request to IANA. 740 10. References 742 10.1. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, 746 DOI 10.17487/RFC2119, March 1997, 747 . 749 [RFC2863] McCloghrie K. and Kastenholz F., "The Interfaces Group 750 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 751 . 753 [RFC3444] Pras A., Schoenwaelder J., "On the Difference between 754 Information Models and Data Models", RFC 3444, DOI 755 10.17487/RFC3444, January 2003, 756 . 758 [RFC7223] Bjorklund M., "A YANG Data Model for Interface 759 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 760 . 762 [RFC7277] Bjorklund M., "A YANG Data Model for IP Management", RFC 763 7277, DOI 10.17487/RFC7277, June 2014, 764 . 766 10.2. Informative References 768 [I-D.ahlberg-ccamp-microwave-radio-link] 769 Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., 770 and M. Vaupotic, "Microwave Radio Link YANG Data Models", 771 draft-ahlberg-ccamp-microwave-radio-link-01 (work in 772 progress), May 2016. 774 [I-D.ietf-netmod-entity] 775 Bierman A., Bjorklund M., Dong J., Romascanu D., "A YANG 776 Data Model for Entity Management", draft-ietf-netmod- 777 entity-00 (work in progress), May 2016. 779 [I-D.vallin-netmod-alarm-module] 780 Vallin S. and Bjorklund M., "YANG Alarm Module", draft- 781 vallin-netmod-alarm-module-00 (work in progress), October 782 2016. 784 [I-D.ietf-netmod-routing-cfg] 785 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 786 Management", draft-ietf-netmod-routing-cfg-24 (work in 787 progress), October 2016. 789 [I.D.zhang-ccamp-l1-topo-yang] 790 Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model 791 for Layer 1 (ODU) Network Topology", draft-zhang-ccamp-l1- 792 topo-yang-03 (work in progress), July 2016. 794 [I.D.ietf-ospf-yang] 795 Yeung D., Qu Y., Zhang J., Bogdanovic D., Sreenivasa K., 796 "Yang Data Model for OSPF Protocol", draft-ietf-ospf-yang- 797 05,(work in progress), July 2016. 799 [ONF-model] 800 "Microwave Modeling - ONF Wireless Transport Group", May 801 2016. 803 [ONF CIM] 804 "Core Information Model", ONF TR-512, ONF, September 2016 806 [PB-YANG] "IEEE 802.1X and 802.1Q YANG models, Marc,H.", October 807 2015. 809 Authors' Addresses 811 Jonas Ahlberg 812 Ericsson AB 813 Lindholmspiren 11 814 Goeteborg 417 56 815 Sweden 817 Email: jonas.ahlberg@ericsson.com 819 Luis M. Contreras 820 Telefonica I+D 821 Ronda de la Comunicacion, S/N 822 Madrid 28050 823 Spain 825 Email: luismiguel.contrerasmurillo@telefonica.com 827 Ye Min (Amy) 828 Huawei Technologies CO., Ltd 829 No.1899, Xiyuan Avenue 830 Chengdu 611731 831 P.R.China 833 Email: amy.yemin@huawei.com 834 Marko Vaupotic 835 Aviat Networks 836 Motnica 9 837 Trzin-Ljubljana 1236 838 Slovenia 840 Email: Marko.Vaupotic@aviatnet.com 842 Jeff Tantsura 843 Individual 845 Email: jefftant.ietf@gmail.com 847 Koji Kawada 848 NEC Corporation 849 1753, Shimonumabe Nakahara-ku 850 Kawasaki, Kanagawa 211-8666 851 Japan 853 Email: k-kawada@ah.jp.nec.com 855 Xi Li 856 NEC Laboratories Europe 857 Kurfuersten-Anlage 36 858 69115 Heidelberg 859 Germany 861 Email: Xi.Li@neclab.eu 863 Ippei Akiyoshi 864 NEC 865 1753, Shimonumabe Nakahara-ku 866 Kawasaki, Kanagawa 211-8666 867 Japan 869 Email: i-akiyoshi@ah.jp.nec.com 871 Carlos J. Bernardos 872 Universidad Carlos III de Madrid 873 Av. Universidad, 30 874 Leganes, Madrid 28911 875 Spain 877 Email: cjbc@it.uc3m.es