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