idnits 2.17.1 draft-ietf-ccamp-microwave-framework-02.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 20, 2017) is 2352 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 == Outdated reference: A later version (-01) exists of draft-vallin-ccamp-alarm-module-00 -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 2 errors (**), 0 flaws (~~), 3 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: April 23, 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 October 20, 2017 24 A framework for Management and Control of microwave and 25 millimeter wave interface parameters 26 draft-ietf-ccamp-microwave-framework-02 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 April 23, 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 & limitations . . . . . . 10 95 5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 96 5.1.3. Radio link re-configuration & optimization . . . . . 10 97 5.1.4. Radio link logical configuration . . . . . . . . . . 10 98 5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 99 5.2.1. Retrieve logical inventory & configuration from device 10 100 5.2.2. Retrieve physical/equipment inventory from device . . 11 101 5.3. Status & statistics . . . . . . . . . . . . . . . . . . . 11 102 5.3.1. Actual status & performance of a radio link interface 11 103 5.4. Performance management . . . . . . . . . . . . . . . . . 11 104 5.4.1. Configuration of historical measurements to be 105 performed . . . . . . . . . . . . . . . . . . . . . . 11 106 5.4.2. Collection of historical performance data . . . . . . 11 107 5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 108 5.5.1. Configuration of alarm reporting . . . . . . . . . . 11 109 5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 110 5.6. Troubleshooting and Root Cause Analysis . . . . . . . . . 11 111 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 112 7. Gap Analysis on Models . . . . . . . . . . . . . . . . . . . 13 113 7.1. Microwave Radio Link Functionality . . . . . . . . . . . 13 114 7.2. Generic Functionality . . . . . . . . . . . . . . . . . . 14 115 7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 119 10.1. Normative References . . . . . . . . . . . . . . . . . 17 120 10.2. Informative References . . . . . . . . . . . . . . . . 17 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 123 1. Terminology and Definitions 125 Microwave is a band of spectrum with wavelengths ranging from 1 126 meter to 1 millimeter and with frequencies ranging between 300 MHz 127 and 300 GHz. Microwave radio technology is widely used for point-to- 128 point telecommunications because of their small wavelength that 129 allows conveniently-sized antennas to direct them in narrow beams, 130 and their comparatively higher frequencies that allows broad 131 bandwidth and high data transmission rates. 133 Millimeter wave is also known as extremely high frequency (EHF) or 134 very high frequency (VHF) by the International Telecommunications 135 Union (ITU), which can be used for high-speed wireless broadband 136 communications. Millimeter wave can be used for a broad range of 137 fixed and mobile services including high-speed, point-to-point 138 wireless local area networks (WLANs) and broadband access. This band 139 has short wavelengths that range from 10 millimeters to 1 140 millimeter, namely millimeter band or millimeter wave. The 71 - 76 141 GHz, 81 - 86 GHz and 92-95 GHz bands are used for point-to-point 142 high-bandwidth communication links, which allows for higher data 143 rates up to 10 Gbit/s but requires a license. Unlicensed short-range 144 data links can be used on 60 GHz millimeter wave. For instance, the 145 upcoming IEEE Wi-Fi standard 802.11ad will run on the 60 GHz 146 spectrum with data transfer rates of up to 7 Gbit/s. 148 ETSI EN 302 217 series defines the characteristics and requirements 149 of microwave/millimeter wave equipment and antennas. Especially ETSI 150 EN 302 217-2 specifies the essential parameters for the systems 151 operating from 1.4GHz to 86GHz. 153 Carrier Termination and Radio Link Terminal are two concepts defined 154 to support modeling of microwave radio link features and parameters 155 in a structured and yet simple manner. 157 Carrier Termination is an interface for the capacity provided over 158 the air by a single carrier. It is typically defined by its 159 transmitting and receiving frequencies. 161 Radio Link Terminal is an interface providing packet capacity and/or 162 TDM capacity to the associated Ethernet and/or TDM interfaces in a 163 node and used for setting up a transport service over a 164 microwave/millimeter wave link. 166 Figure 1 provides a graphical representation of Carrier Termination 167 and Radio Link Terminal concepts. 169 /--------- Radio Link ---------\ 170 Near End Far End 172 +---------------+ +---------------+ 173 | Radio Link | | Radio Link | 174 | Terminal | | Terminal | 175 | | | | 176 | (Protected or Bonded) | 177 | | | | 178 | +-----------+ | | +-----------+ | 179 | | | | Carrier A | | | | 180 | | Carrier | |<--------->| | Carrier | | 181 | |Termination| | | |Termination| | 182 Packet--| | | | | | | |--Packet 183 | +-----------+ | | +-----------+ | 184 TDM----| | | |----TDM 185 | +-----------+ | | +-----------+ | 186 | | | | Carrier B | | | | 187 | | Carrier | |<--------->| | Carrier | | 188 | |Termination| | | |Termination| | 189 | | | | | | | | 190 | +-----------+ | | +-----------+ | 191 | | | | 192 +---------------+ +---------------+ 194 \--- Microwave Node ---/ \--- Microwave Node ---/ 196 Figure 1. Radio Link Terminal and Carrier Termination 198 Software Defined Networking (SDN) is an emerging architecture that 199 decouples the network control and forwarding functions enabling the 200 network control to become directly programmable and the underlying 201 infrastructure to be abstracted for applications and network 202 services. This results in an extremely dynamic, manageable, cost- 203 effective, and adaptable architecture that gives administrators 204 unprecedented programmability, automation, and control. The SDN 205 concept is widely applied for network management, the adoption of 206 SDN framework to manage and control the microwave and millimeter 207 wave interface is one of the key applications of this work. 209 2. Introduction 211 Network requirements vary between operators globally as well as 212 within individual countries. The overall goal is however the same - 213 to deliver the best possible network performance and quality of 214 experience in a cost-efficient way. 216 Microwave/millimeter wave (hereafter referred to as microwave, but 217 including the frequency bands represented by millimeter wave) are 218 important technologies to fulfill this goal today, but also in the 219 future when demands on capacity and packet features increases. 221 Microwave is already today able to fully support the capacity needs 222 of a backhaul in a radio access network and will evolve to support 223 multiple gigabits in traditional frequency bands and beyond 10 224 gigabits in the millimeter wave. L2 packet features are normally an 225 integrated part of microwave nodes and more advanced L2 & L3 226 features will over time be introduced to support the evolution of 227 the transport services to be provided by a backhaul/transport 228 network. Note that the wireless access technologies such as 3/4/5G & 229 WiFi are not within the scope of this microwave model work. 231 The main application for microwave is backhaul for mobile broadband. 232 Those networks will continue to be modernized using a combination of 233 microwave and fiber technologies. The choice of technology is a 234 question about fiber presence and cost of ownership, not about 235 capacity limitations in microwave. 237 Open and standardized interfaces are a pre-requisite for efficient 238 management of equipment from multiple vendors, integrated in a 239 single system/controller. This framework addresses management and 240 control of the radio link interface(s) and the relationship to other 241 packet interfaces, typically to Ethernet interfaces, in a microwave 242 node. A radio link provides the transport over the air, using one or 243 several carriers in aggregated or protected configurations. 244 Managing and controlling a transport service over a microwave node 245 involves both radio link and packet functionality. 247 Already today there are numerous IETF data models, RFCs and drafts, 248 with technology specific extensions that cover a large part of the 249 packet domain. Examples are IP Management [RFC7277], Routing 250 Management [RFC8022] and Provider Bridge [PB-YANG] They are based 251 on RFC 7223 [RFC7223], which is the IETF YANG model for Interface 252 Management, and is an evolution of the SNMP IF-MIB [RFC2863]. 254 Since microwave nodes will contain more and more packet 255 functionality which is expected to be managed using those models, 256 there are advantages if radio link interfaces can be modeled and be 257 managed using the same structure and the same approach, specifically 258 for use cases in which a microwave node are managed as one common 259 entity including both the radio link and the packet functionality, 260 e.g. at basic configuration of node & connections, centralized 261 trouble shooting, upgrade and maintenance. All interfaces in a node, 262 irrespective of technology, would then be accessed from the same 263 core model, i.e. RFC 7223, and could be extended with technology 264 specific parameters in models augmenting that core model. The 265 relationship/connectivity between interfaces could be given by the 266 physical equipment configuration, e.g the slot in which the Radio 267 Link Terminal (modem) is plugged in could be associated with a 268 specific Ethernet port due to the wiring in the backplane of the 269 system, or it could be flexible and therefore configured via a 270 management system or controller. 272 +------------------------------------------------------------------+ 273 | Interface [RFC7223] | 274 | +------------------+ | 275 | |Ethernet Port | | 276 | +------------------+ | 277 | \ | 278 | +-----------------------+ | 279 | |Radio Link Terminal | | 280 | +-----------------------+ | 281 | \ | 282 | +------------------------+ | 283 | |Carrier Termination | | 284 | +------------------------+ | 285 +------------------------------------------------------------------+ 287 Figure 2: Relationship between interfaces in a node 289 There will always be certain implementations that differ among 290 products and it is therefore practically impossible to achieve 291 industry consensus on every design detail. It is therefore important 292 to focus on the parameters that are required to support the use 293 cases applicable for centralized, unified, multi-vendor management 294 and to allow other parameters to be optional or to be covered by 295 extensions to the standardized model. Furthermore, a standard that 296 allows for a certain degree of freedom encourages innovation and 297 competition which is something that benefits the entire industry. It 298 is therefore important that a radio link management model covers all 299 relevant functions but also leaves room for product/feature-specific 300 extensions. 302 For microwave radio link functionality work has been initiated (ONF: 303 Microwave Modeling [ONF-model], IETF: Radio Link Model [I- 304 D.ahlbergccamp-microwave-radio-link]. The purpose of this effort is 305 to reach consensus within the industry around one common approach, 306 with respect to the use cases and requirements to be supported, the 307 type and structure of the model and the resulting attributes to be 308 included. This document describes the use cases and requirements 309 agreed to be covered, the expected characteristics of the model and 310 at the end includes an analysis of how the models in the two on- 311 going initiatives fulfill these expectations and a recommendation on 312 what can be reused and what gaps need to be filled by a new and 313 evolved radio link model. 315 3. Conventions used in this document 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 319 document are to be interpreted as described in RFC 2119 [RFC2119]. 321 While [RFC2119] describes interpretations of these key words in 322 terms of protocol specifications and implementations, they are used 323 in this document to describe requirements for the YANG Data Model 324 for Microwave Radio Link. 326 4. Approaches to manage and control radio link interfaces 328 This framework addresses the definition of an open and standardized 329 interface for the radio link functionality in a microwave/millimeter 330 wave node. The application of such an interface used for management 331 and control of nodes and networks typically vary from one operator 332 to another, in terms of the systems used and how they interact. A 333 traditional solution is network management system, while an emerging 334 one is SDN. SDN solutions can be used as part of the network 335 management system, allowing for direct network programmability and 336 automated configurability by means of a centralized SDN control and 337 defining standardized interfaces to program the nodes. 339 4.1. Network Management Solutions 341 The classic network management solutions, with vendor specific 342 domain management combined with cross domain functionality for 343 service management and analytics, still dominates the market. 344 These solutions are expected to evolve and benefit from an increased 345 focus on standardization by simplifying multi-vendor management and 346 remove the need for vendor/domain specific management. 348 4.2. Software Defined Networking 350 One of the main drivers for applying SDN from an operator 351 perspective is simplification and automation of network provisioning 352 as well as E2E network service management. The vision is to have a 353 global view of the network conditions spanning across different 354 vendors' equipment and multiple technologies. 356 If nodes from different vendors shall be managed by the same SDN 357 controller via a node management interface (north bound interface, 358 NBI), without the extra effort of introducing intermediate systems, 359 all nodes must align their node management interfaces. Hence, an 360 open and standardized node management interface are required in a 361 multi-vendor environment. Such standardized interface enables a 362 unified management and configuration of nodes from different vendors 363 by a common set of applications. 365 On top of SDN applications to configure, manage and control the 366 nodes and their associated transport interfaces including the L2 and 367 L3 packet/Ethernet interfaces as well as the radio interfaces, there 368 are also a large variety of other more advanced SDN applications 369 that can be exploited and/or developed. 371 A potential flexible approach for the operators is to use SDN in a 372 logical control way to manage the radio links by selecting a 373 predefined operation mode. The operation mode is a set of logical 374 metrics or parameters describing a complete radio link 375 configuration, such as capacity, availability, priority and power 376 consumption. 378 An example of an operation mode table is shown in Figure 3. Based on 379 its operation policy (e.g., power consumption or traffic priority), 380 the SDN controller selects one operation mode and translates that 381 into the required configuration of the individual parameters for the 382 radio link terminals and the associated carrier terminations. 384 +----+---------------+------------+-------------+-----------+------+ 385 | ID |Description | Capacity |Availability | Priority |Power | 386 +----+---------------+------------+-------------+-----------+------+ 387 | 1 |High capacity | 400 Mbps | 99.9% | Low |High | 388 +----+---------------+------------+-------------+-----------+------+ 389 | 2 |High avail- | 100 Mbps | 99.999% | High |Low | 390 | | ability | | | | | 391 +----+---------------+------------+-------------+-----------+------+ 393 Figure 3. Example of an operation mode table 395 An operation mode bundles together the values of a set of different 396 parameters. How each operation mode maps into certain set of 397 attributes is out of scope of this document. Effort on a 398 standardizing operation mode is required to implement a smoothly 399 operator environment. 401 5. Use Cases 403 The use cases described should be the basis for identification and 404 definition of the parameters to be supported by a YANG Data model 405 for management of radio links, applicable for centralized, unified, 406 multi-vendor management. 408 Other product specific use cases, addressing e.g. installation, on- 409 site trouble shooting and fault resolution, are outside the scope of 410 this framework. If required, these use cases are expected to be 411 supported by product specific extensions to the standardized model. 413 5.1. Configuration Management 415 Configuration of a radio link terminal, the constituent carrier 416 terminations and when applicable the relationship to packet/Ethernet 417 and TDM interfaces. 419 5.1.1. Understand the capabilities & limitations 421 Exchange of information between a manager and a device about the 422 capabilities supported and specific limitations in the parameter 423 values & enumerations that can be used. 425 Support for the XPIC (Cross Polarization Interference Cancellation) 426 feature or not and the maximum modulation supported are two examples 427 on information that could be exchanged. 429 5.1.2. Initial Configuration 431 Initial configuration of a radio link terminal, enough to establish 432 L1 connectivity over the hop to an associated radio link terminal on 433 a device at far end. It MAY also include configuration of the 434 relationship between a radio link terminal and an associated traffic 435 interface, e.g. an Ethernet interface, unless that is given by the 436 equipment configuration. 438 Frequency, modulation, coding and output power are examples of 439 parameters typically configured for a carrier termination and type 440 of aggregation/bonding or protection configurations expected for a 441 radio link terminal. 443 5.1.3. Radio link re-configuration & optimization 445 Re-configuration, update or optimization of an existing radio link 446 terminal. Output power and modulation for a carrier termination and 447 protection schemas and activation/de-activation of carriers in a 448 radio link terminal are examples on parameters that can be re- 449 configured and used for optimization of the performance of a 450 network. 452 5.1.4. Radio link logical configuration 454 Radio link terminals comprising a group of carriers are widely used 455 in microwave technology. There are several kinds of groups: 456 aggregation/bonding, 1+1 protection/redundancy, etc. To avoid 457 configuration on each carrier termination directly, a logical 458 control provides flexible management by mapping a logical 459 configuration to a set of physical attributes. This could also be 460 applied in a hierarchical SDN environment where some domain 461 controllers are located between the SDN controller and the radio 462 link terminal. 464 5.2. Inventory 466 5.2.1. Retrieve logical inventory & configuration from device 468 Request from manager and response by device with information about 469 radio interfaces, their constitution and configuration. 471 5.2.2. Retrieve physical/equipment inventory from device 473 Request from manager about physical and/or equipment inventory 474 associated with the radio link terminals and carrier terminations. 476 5.3. Status & statistics 478 5.3.1. Actual status & performance of a radio link interface 480 Manager requests and device responds with information about actual 481 status and statistics of configured radio link interfaces and their 482 constituent parts. 484 5.4. Performance management 486 5.4.1. Configuration of historical measurements to be performed 488 Configuration of historical measurements to be performed on a radio 489 link interface and/or its constituent parts is a subset of the 490 configuration use case to be supported. See 5.1 above. 492 5.4.2. Collection of historical performance data 494 Collection of historical performance data in bulk by the manager is 495 a general use case for a device and not specific to a radio link 496 interface. 498 Collection of an individual counter for a specific interval is in 499 same cases required as a complement to the retrieval in bulk as 500 described above. 502 5.5. Fault Management 504 5.5.1. Configuration of alarm reporting 506 Configuration of alarm reporting associated specifically with radio 507 interfaces, e.g. configuration of alarm severity, is a subset of the 508 configuration use case to be supported. See 5.1 above. 510 5.5.2. Alarm management 512 Alarm synchronization, visualization & handling, and notifications & 513 events are generic use cases for a device and not specific to a 514 radio link interface and should be supported accordingly. 516 5.6. Troubleshooting and Root Cause Analysis 518 Information and actions required by a manager/operator to 519 investigate and understand the underlying issue to a problem in the 520 performance and/or functionality of a radio link terminal and the 521 associated carrier terminations. 523 6. Requirements 525 For managing a microwave node including both the radio link and the 526 packet functionality, a unified data model is desired to unify the 527 modeling of the radio link interfaces and the packet interfaces 528 using the same structure and the same modelling approach. If some 529 part of model is generic for other technology usage, it should be 530 clearly stated. 532 The purpose of the YANG Data Model is for management and control of 533 the radio link interface(s) and the relationship/connectivity to 534 other packet interfaces, typically to Ethernet interfaces, in a 535 microwave node. 537 The capability of configuring and managing microwave nodes includes 538 the following requirements for the modelling: 540 1) It MUST be possible to configure, manage and control a radio link 541 terminal and the constituent carrier terminations. 543 a) Frequency, channel bandwidth, modulation, coding and 544 transmitter power are examples of parameters typically 545 configured for a carrier termination. 547 b) A radio link terminal MUST configure the associated carrier 548 terminations and the type of aggregation/bonding or protection 549 configurations expected for the radio link terminal. 551 c) The capability, e.g. the maximum modulation supported, and the 552 actual status/statistics, e.g. administrative status of the 553 carriers, SHOULD also be supported by the data model. 555 d) The definition of the features and parameters SHOULD be based 556 on established microwave equipment and radio standards, such 557 as ETSI EN 302 217 [EN 302 217-2] which specifies the essential 558 parameters for microwave systems operating from 1.4GHz to 559 86GHz. 561 2) It MUST be possible to map different traffic types (e.g. TDM, 562 Ethernet) to the transport capacity provided by a specific radio 563 link terminal. 565 3) It MUST be possible to configure and collect historical 566 measurements (for the use case described in section 5.4) to be 567 performed on a radio link interface, e.g. minimum, maximum and 568 average transmit power and receive level in dBm. 570 4) It MUST be possible to configure and retrieve alarms reporting 571 associated with the radio interfaces, e.g. configuration of alarm 572 severity, supported alarms like configuration fault, signal lost, 573 modem fault, radio fault. 575 7. Gap Analysis on Models 577 The purpose of the gap analysis is to identify and recommend what 578 existing and established models as well as draft models under 579 definition to support the use cases and requirements specified in 580 the previous chapters. It shall also make a recommendation on how 581 the gaps not supported should be filled, including the need for 582 development of new models and evolution of existing models and 583 drafts. 585 For microwave radio link functionality work has been initiated (ONF: 586 Microwave Modeling [ONF-model], IETF: Radio Link Model [I- 587 D.ahlbergccamp-microwave-radio-link]. The analysis is expected to 588 take these initiatives into consideration and make a recommendation 589 on how to make use of them and how to complement them in order to 590 fill the gaps identified. 592 For generic functionality, not specific for radio link, the ambition 593 is to refer to existing or emerging models that could be applicable 594 for all functional areas in a microwave node. 596 7.1. Microwave Radio Link Functionality 598 [ONF CIM] defines a CoreModel of the ONF Common Information Model. 599 An information model describes the things in a domain in terms of 600 objects, their properties (represented as attributes), and their 601 relationships. The ONF information model is expressed in Unified 602 Modeling Language (UML). The ONF CoreModel is independent of 603 specific data plane technology. Data plane technology specific 604 properties are acquired in a runtime solution via "filled in" cases 605 of specification (LtpSpec etc). These can be used to augment the 606 CoreModel to provide a data plane technology specific representation. 608 IETF Data Model defines an implementation and NETCONF-specific 609 details. YANG is a data modeling language used to model the 610 configuration and state data. It is well aligned with the structure 611 of the Yang data models proposed for the different packet interfaces 612 which are all based on RFC 7223. Furthermore, several YANG data 613 models have been proposed in the IETF for other transport 614 technologies such as optical transport; e.g., RFC 7277 [RFC7277], 615 [I.D.zhang-ccamp-l1-topo-yang], [I.D.ietf-ospf-yang]. In light of 616 this trend, the IETF data model is becoming a popular approach for 617 modeling most packet transport technology interfaces and it is 618 thereby well positioned to become an industry standard. 620 RFC 3444 [RFC3444] explains the difference between Information 621 Model(IM) and Data Models(DM). IM is to model managed objects at a 622 conceptual level for designers and operators, DM is defined at a 623 lower level and includes many details for implementers. In addition, 624 the protocol-specific details are usually included in DM. Since 625 conceptual models can be implemented in different ways, multiple DMs 626 can be derived from a single IM. To ensure better interoperability, 627 it is better to focus on DM directly. 629 RFC 7223 describes an interface management model, however it doesn't 630 include technology specific information, e.g., for radio interface. 631 [I-D.ahlberg-ccamp-microwave-radio-link] provides a model proposal 632 for radio interfaces, which includes support for basic configuration, 633 status and performance but lacks full support for alarm management 634 and interface layering, i.e. the connectivity of the transported 635 capacity (TDM & Ethernet) with other internal technology specific 636 interfaces in a microwave node. 638 The recommendation is to use the structure of the IETF: Radio Link 639 Model [I-D.ahlberg-ccamp-microwave-radio-link] as the starting point, 640 since it is a data model providing the wanted alignment with RFC 641 7223. For the definition of the detailed leafs/parameters, the 642 recommendation is to use the IETF: Radio Link Model and the ONF: 643 Microwave Modeling [ONF-model] as the basis and to define new ones 644 to cover identified gaps. The parameters in those models have been 645 defined by both operators and vendors within the industry and the 646 implementations of the ONF Model have been tested in the Proof of 647 Concept events in multi-vendor environments, showing the validity of 648 the approach proposed in this framework document. 650 It is also recommended to add the required data nodes to describe 651 the interface layering for the capacity provided by a radio link 652 terminal and the associated Ethernet and TDM interfaces in a 653 microwave node. The principles and data nodes for interface layering 654 described in RFC 7223 should be used as a basis. 656 7.2. Generic Functionality 658 For generic functionality, not specific for radio link, the 659 recommendation is to refer to existing RFCs or emerging drafts 660 according to the table in figure 4 below. New Radio Link Model is 661 used in the table for the cases where the functionality is 662 recommended to be included in the new radio link model as described 663 in chapter 7.1. 665 +------------------------------------+-----------------------------+ 666 | Generic Functionality | Recommendation | 667 | | | 668 +------------------------------------+-----------------------------+ 669 |1.Fault Management | | 670 | | | 671 | Alarm Configuration | New Radio Link Model | 672 | | | 673 | Alarm notifications/ | [I-D.vallin-ccamp- | 674 | synchronization | alarm-module] | 675 +------------------------------------+-----------------------------+ 676 |2.Performance Management | | 677 | | | 678 | Performance Configuration/ | New Radio Link Model | 679 | Activation | | 680 | | | 681 | Performance Collection | New Radio Link Model & | 682 | | XML files | 683 +------------------------------------+-----------------------------+ 684 |3.Physical/Equipment Inventory | [I-D.ietf-netmod-entity] | 685 +------------------------------------+-----------------------------+ 687 Figure 4. Recommendation on how to support generic functionality 689 Microwave specific alarm configurations are recommended to be 690 included in the new radio link model and could be based on what is 691 supported in the IETF and ONF Radio Link Models. Alarm notifications 692 and synchronization are general and is recommended to be supported 693 by a generic model, such as [I-D.vallin-ccamp-alarm-module]. 695 Activation of interval counters & thresholds could be a generic 696 function but it is recommended to be supported by the new radio link 697 specific model and can be based on both the ONF and IETF Microwave 698 Radio Link models. 700 Collection of interval/historical counters is a generic function 701 that needs to be supported in a node. File based collection via SFTP 702 and collection via a Netconf/YANG interfaces are two possible 703 options and the recommendation is to include support for the latter 704 in the new radio link specific model. The ONF and IETF Microwave 705 Radio Link models can be used as a basis also in this area. 707 Physical and/or equipment inventory associated with the radio link 708 terminals and carrier terminations is recommended to be covered by a 709 model generic for the complete node, e.g. [I-D.ietf-netmod-entity] 710 and it is thereby outside the scope of the radio link specific 711 model. 713 7.3. Summary 715 The conclusions and recommendations from the analysis can be 716 summarized as follows: 718 1) A Microwave Radio Link YANG Data Model should be defined with a 719 scope enough to support the use cases and requirements in 720 chapter 5 and 6 of this document. 722 2) Use the structure in the IETF: Radio Link Model [I-D.ahlberg- 723 ccamp-microwave-radio-link] as the starting point. It augments 724 RFC 7223 and is thereby as required aligned with the structure 725 of the models for management of the packet domain. 727 3) Use established microwave equipment and radio standards, such 728 as ETSI EN 302 217 [EN 302 217-2], and the IETF: Radio Link 729 Model [I-D.ahlberg-ccamp-microwave-radio-link] and the 730 ONF: Microwave Modeling [ONF-model] as the basis for the 731 definition of the detailed leafs/parameters to support the 732 specified use cases and requirements, and proposing new ones 733 to cover identified gaps. 735 4) Add the required data nodes to describe the interface layering 736 for the capacity provided by a radio link terminal and the 737 associated Ethernet and TDM interfaces, using the principles 738 and data nodes for interface layering described in RFC 7223 as 739 a basis. 741 5) Include support for configuration of microwave specific alarms 742 in the Microwave Radio Link model and rely on a generic model 743 such as [I.D.vallin-ccamp-alarm-module] for notifications and 744 alarm synchronization. 746 6) Use a generic model such as [I-D.ietf-netmod-entity] for 747 physical/equipment inventory. 749 It is furthermore recommended that the Microwave Radio Link YANG 750 Date Model should be validated by both operators and vendors as 751 part of the process to make it stable and mature. During the 752 Hackathon in IETF 99, a project "SDN Applications for microwave 753 radio link via IETF YANG Data Model" successfully validated this 754 framework and the YANG data model[I.D.ietf-ccamp-mw-yang]. The 755 project also received the BEST OVERALL award from the Hackathon. 757 8. Security Considerations 759 TBD 761 9. IANA Considerations 763 This memo includes no request to IANA. 765 10. References 767 10.1. Normative References 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, 771 DOI 10.17487/RFC2119, March 1997, 772 . 774 [RFC2863] McCloghrie K. and Kastenholz F., "The Interfaces Group 775 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 776 . 778 [RFC3444] Pras A., Schoenwaelder J., "On the Difference between 779 Information Models and Data Models", RFC 3444, DOI 780 10.17487/RFC3444, January 2003, 781 . 783 [RFC7223] Bjorklund M., "A YANG Data Model for Interface 784 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 785 . 787 [RFC7277] Bjorklund M., "A YANG Data Model for IP Management", RFC 788 7277, DOI 10.17487/RFC7277, June 2014, 789 . 791 10.2. Informative References 793 [I-D.ahlberg-ccamp-microwave-radio-link] 794 Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., 795 and M. Vaupotic, "Microwave Radio Link YANG Data Models", 796 draft-ahlberg-ccamp-microwave-radio-link-01 (work in 797 progress), May 2016. 799 [I-D.ietf-netmod-entity] 800 Bierman A., Bjorklund M., Dong J., Romascanu D., "A YANG 801 Data Model for Entity Management", draft-ietf-netmod- 802 entity-05 (work in progress), October 2017. 804 [I-D.vallin-ccamp-alarm-module] 805 Vallin S. and Bjorklund M., "YANG Alarm Module", draft- 806 vallin-ccamp-alarm-module-00 (work in progress), October 807 2017. 809 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 810 Management", RFC 8022, DOI 10.17487/RFC8022, November 2016 812 [I.D.zhang-ccamp-l1-topo-yang] 813 Zhang X., Rao B., Sharma A., Liu X., "A YANG Data Model 814 for Layer 1 (ODU) Network Topology", draft-zhang-ccamp-l1- 815 topo-yang-03 (work in progress), July 2016. 817 [I.D.ietf-ospf-yang] 818 Yeung D., Qu Y., Zhang J., Bogdanovic D., Sreenivasa K., 819 "Yang Data Model for OSPF Protocol", draft-ietf-ospf-yang- 820 05,(work in progress), July 2016. 822 [ONF-model] 823 "Microwave Modeling - ONF Wireless Transport Group", May 824 2016. 826 [ONF CIM] 827 "Core Information Model", ONF TR-512, ONF, September 2016 829 [PB-YANG] "IEEE 802.1X and 802.1Q YANG models", Marc,H., October 830 2015. 832 [EN 302 217-2] 833 ETSI, "Fixed Radio Systems; Characteristics and 834 requirements for point to-point equipment and antennas; 835 Part 2: Digital systems operating in frequency bands from 836 1 GHz to 86 GHz; Harmonised Standard covering the 837 essential requirements of article 3.2 of Directive 838 2014/53/EU", EN 302 217-2 V3.1.1, May 2017. 840 [I.D.ietf-ccamp-mw-yang] 841 Ahlberg, J., Ye, M., Li,X., Kawada K., Bernardos C., 842 Spreafico D., Vaupotic M., "A YANG Data Model for 843 Microwave Radio Link", draft-ietf-ccamp-mw-yang-01,(work 844 in progress), July 2016. 846 Authors' Addresses 848 Jonas Ahlberg 849 Ericsson AB 850 Lindholmspiren 11 851 Goeteborg 417 56 852 Sweden 854 Email: jonas.ahlberg@ericsson.com 856 Luis M. Contreras 857 Telefonica I+D 858 Ronda de la Comunicacion, S/N 859 Madrid 28050 860 Spain 862 Email: luismiguel.contrerasmurillo@telefonica.com 864 Ye Min 865 Huawei Technologies CO., Ltd 866 No.1899, Xiyuan Avenue 867 Chengdu 611731 868 P.R.China 870 Email: amy.yemin@huawei.com 872 Marko Vaupotic 873 Aviat Networks 874 Motnica 9 875 Trzin-Ljubljana 1236 876 Slovenia 878 Email: Marko.Vaupotic@aviatnet.com 880 Jeff Tantsura 881 Individual 883 Email: jefftant.ietf@gmail.com 884 Koji Kawada 885 NEC Corporation 886 1753, Shimonumabe Nakahara-ku 887 Kawasaki, Kanagawa 211-8666 888 Japan 890 Email: k-kawada@ah.jp.nec.com 892 Xi Li 893 NEC Laboratories Europe 894 Kurfuersten-Anlage 36 895 69115 Heidelberg 896 Germany 898 Email: Xi.Li@neclab.eu 900 Ippei Akiyoshi 901 NEC 902 1753, Shimonumabe Nakahara-ku 903 Kawasaki, Kanagawa 211-8666 904 Japan 906 Email: i-akiyoshi@ah.jp.nec.com 908 Carlos J. Bernardos 909 Universidad Carlos III de Madrid 910 Av. Universidad, 30 911 Leganes, Madrid 28911 912 Spain 914 Email: cjbc@it.uc3m.es 916 Daniela Spreafico 917 Nokia - IT 918 Via Energy Park, 14 919 Vimercate (MI) 20871 920 Italy 922 Email: daniela.spreafico@nokia.com