RFC 8432

A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters

📅 published October 2018, from ietf

RFC 8432 ✨ A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters 🦋

okay bestie, title block first!! 🎀 This is RFC 8432, an Informational doc (so it's published for info, NOT a standard 💅), dated October 2018. The authors are J. Ahlberg (Ed.) from Ericsson AB, M. Ye (Ed.) from Huawei Technologies, X. Li from NEC Laboratories Europe, LM. Contreras from Telefonica I+D, and CJ. Bernardos from Universidad Carlos III de Madrid. 👑 It lives in ISSN 2070-1721, and it doesn't obsolete or update anything. Iconic, clean slate 🌈

Abstract

the vibe: unifying how we control and manage microwave radio link interfaces is basically a must for seamless multi-layer networking and automated provisioning 🔥 Like, you can't automate chaos, periodt.

This doc lays out the required characteristics and use cases for managing radio link interface parameters with a YANG data model 🧚. The goal is a framework that figures out which info elements are needed and then defines the YANG model for controlling and managing radio link interfaces in a microwave node. Some bits of the model could be generic and reused by other techs too, like Ethernet 💖

Status of This Memo

okay this part is the legal-ish stuff but it's still important 🙈 This document is not an Internet Standards Track spec. It's published for informational purposes, full stop 💅

It IS a product of the IETF, meaning it reflects consensus from the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 🌸

Want the current status, errata, or a way to give feedback? Head to https://www.rfc-editor.org/info/rfc8432 🫶

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date. Read those carefully, because they spell out your rights and restrictions 🎀 If you extract Code Components from this document, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 😭

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................5
   2. Terminology and Definitions .....................................5
   3. Approaches to Manage and Control Radio Link Interfaces ..........7
      3.1. Network Management Solutions ...............................7
      3.2. Software-Defined Networking ................................7
   4. Use Cases .......................................................8
      4.1. Configuration Management ...................................9
      4.2. Inventory .................................................10
      4.3. Status and Statistics .....................................10
      4.4. Performance Management ....................................10
      4.5. Fault Management ..........................................11
      4.6. Troubleshooting and Root Cause Analysis ...................11
   5. Requirements ...................................................11
   6. Gap Analysis on Models .........................................12
      6.1. Microwave Radio Link Functionality ........................13
      6.2. Generic Functionality .....................................14
      6.3. Summary ...................................................15
   7. Security Considerations ........................................16
   8. IANA Considerations ............................................16
   9. References .....................................................16
      9.1. Normative References ......................................16
      9.2. Informative References ....................................17
   Contributors ......................................................19
   Authors' Addresses ................................................20

1. Introduction 🌸

Okay so microwave radio is basically tech that uses high-frequency radio waves to give you high-speed wireless connections that can carry voice, video, and data 🦋 It's a catch-all term for systems with a huge range of capacities, channel separations, modulation formats, and apps, spanning frequency bands from 1.4 GHz all the way up to and above 100 GHz 💅

The main gig for microwave is backhaul for mobile broadband 📡 Those networks are gonna keep getting modernized with a mix of microwave and fiber. Whether you pick fiber or microwave comes down to whether fiber is around and the cost of owning it, not because microwave can't keep up on capacity ✨

Microwave can already fully handle the capacity a radio access network backhaul needs, and it's evolving to hit multiple gigabits in traditional bands and more than 10 gigabits in higher bands with more bandwidth 🔥 Layer 2 (L2) Ethernet features are usually built right into microwave nodes, and more advanced L2 and Layer 3 (L3) features are coming over time to support transport services on a backhaul/transport network 💖 Heads up: wireless access techs like 3/4/5G and Wi-Fi are not in scope here 🙈

Open, standardized interfaces are a must for managing gear from multiple vendors inside a single system or controller 👑 This framework handles management and control of the radio link interface(s) and how they relate to other interfaces (usually Ethernet ones) on a microwave node 🧚 A radio link carries traffic over the air using one or several carriers, in aggregated or protected setups. Running a transport service over a microwave node means dealing with both radio link and packet transport stuff 🫶

There are already loads of IETF data models, RFCs, and Internet-Drafts with tech-specific extensions covering a big chunk of the L2 and L3 world 🌈 Examples are IP Management [RFC8344], Routing Management [RFC8349], and Provider Bridge [IEEE802.1Qcp]. They're built on the IETF YANG data model for Interface Management [RFC8343], which evolved from the SNMP IF-MIB [RFC2863] 💜

Here's the thing: microwave nodes are getting more and more L2 and L3 (packet) functionality that these models can manage, so it's a big win if radio link interfaces can be modeled and managed with the same structure and approach ✨ This matters most when a microwave node is managed as one entity covering both the radio link and L2/L3 stuff, like basic node and connection config, centralized troubleshooting, upgrades, and maintenance 🎀 Every interface in a node, no matter the tech, would then be accessed from the same core model, [RFC8343], and could be extended with tech-specific params in models that augment it 🦋 The relationships between interfaces could come from the physical equipment config. For example, the slot where the Radio Link Terminal (modem) plugs in could be tied to a specific Ethernet port because of the backplane wiring, or it could be flexible and set through a management system or controller 💅

   +------------------------------------------------------------------+
   | Interface [RFC8343]                                              |
   |                +---------------+                                 |
   |                | Ethernet Port |                                 |
   |                +---------------+                                 |
   |                      \                                           |
   |                    +---------------------+                       |
   |                    | Radio Link Terminal |                       |
   |                    +---------------------+                       |
   |                       /              \                           |
   |     +---------------------+       +---------------------+        |
   |     | Carrier Termination |       | Carrier Termination |        |
   |     +---------------------+       +---------------------+        |
   +------------------------------------------------------------------+

            Figure 1: Relationship between Interfaces in a Node

There will always be implementations that differ between products, so getting industry consensus on every design detail is basically impossible 😭 That's why it matters to focus on the params needed for the use cases of centralized, unified, multi-vendor management, and let other params be optional or covered by extensions to the standard model 🌸 Also, a standard with some freedom encourages innovation and competition, which helps the whole industry 💖 So a radio link management model should cover all the relevant functions while still leaving room for product- and feature-specific extensions ✨

Models already exist for microwave radio link functionality: the "Microwave Information Model" by the ONF [ONF-MW] and the "Microwave Radio Link YANG Data Models" submitted to and discussed by the CCAMP Working Group [CCAMP-MW] 🦋 This doc aims to get the industry to agree on one common approach for the use cases and requirements, the model's type and structure, and the attributes to include 🔥 It describes the use cases, requirements, and expected characteristics of the model, and analyzes how the models in those two ongoing efforts measure up. It also recommends what can be reused and what gaps a new, evolved model needs to fill ("A YANG Data Model for Microwave Radio Link" by the IETF [IETF-MW]) 👑

1.1. Conventions Used in This Document 🎀

Okay, the key words here are the BCP 14 ones. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, just like shown here 💅

Part 1 of 4 done bestie, more coming! 🧚💖 Section 2 (Terminology and Definitions) is next 🌈

2. Terminology and Definitions ✨

okay so before we get into the good stuff, we need to agree on what these words mean 🤓🎀

Microwave radio 🌸: this is the umbrella term for tech that operates in both microwave and millimeter wavelengths, in frequency bands from 1.4 GHz up to and beyond 100 GHz. In the traditional bands it usually gives you 1-3 Gbps, and in the 70/80 GHz band it supports up to 10 Gbps. Using multi-carrier systems in frequency bands with wider channels, the tech will be capable of providing capacities of up to 100 Gbps. literally insane 🔥

Microwave radio technology 🦋: this is widely used for point-to-point telecom because the small wavelength lets you fit conveniently sized antennas that aim radio waves in narrow beams, and the higher frequencies allow broad bandwidth and high data-transmission rates. It's used for a broad range of fixed and mobile services, including high-speed, point-to-point wireless local area networks (WLANs) and broadband access. it's giving main character energy 💅

The ETSI EN 302 217 series is the one that defines the characteristics and requirements of microwave equipment and antennas. In particular, ETSI EN 302 217-2 [EN302217-2] specifies the essential parameters for systems operating from 1.4 GHz to 86 GHz. so if you're ever wondering where the specs live, that's the place 🧚

Carrier Termination and Radio Link Terminal 🎀: two concepts that were defined to support modeling of microwave radio link features and parameters in a structured yet simple manner. They're the building blocks, bestie, so pay attention 🫶

  • Carrier Termination 🍓: an interface for the capacity provided over the air by a single carrier. It is typically defined by its transmitting and receiving frequencies.
  • Radio Link Terminal 💜: an interface providing Ethernet capacity and/or Time Division Multiplexing (TDM) capacity to the associated Ethernet and/or TDM interfaces in a node. It is used for setting up a transport service over a microwave radio link.

Figure 2 gives you a visual of how the Carrier Termination and Radio Link Terminal concepts fit together. Look at this diagram, it's so clean 😭

                 /--------- Radio Link ---------\
                  Near End              Far End

           +---------------+           +---------------+
           |    Radio Link |           | Radio Link    |
           |      Terminal |           | Terminal      |
           |               |           |               |
           |           (Protected or Bonded)           |
           |               |           |               |
           | +-----------+ |           | +-----------+ |
           | |           | | Carrier A | |           | |
           | |  Carrier  | |<--------->| |  Carrier  | |
           | |Termination| |           | |Termination| |
    ETH----| |           | |           | |           | |----ETH
           | +-----------+ |           | +-----------+ |
    TDM----|               |           |               |----TDM
           | +-----------+ |           | +-----------+ |
           | |           | | Carrier B | |           | |
           | |  Carrier  | |<--------->| |  Carrier  | |
           | |Termination| |           | |Termination| |
           | |           | |           | |           | |
           | +-----------+ |           | +-----------+ |
           |               |           |               |
           +---------------+           +---------------+

     \--- Microwave Node ---/          \--- Microwave Node ---/

           Figure 2: Radio Link Terminal and Carrier Termination

Software-Defined Networking (SDN) 👑: an architecture that decouples the network control and forwarding functions. This lets the network control become directly programmable, and the underlying infrastructure gets abstracted for applications and network services. SDN can be used to automate traditional network management functionality, using an SDN approach of standardized programmable interfaces for control and management [RFC7426]. this is the glow-up of networking, no cap ✨

okay so this section is about the big question: how do you actually manage and control these radio links? 🧐

This framework is all about defining an open and standardized interface for radio link functionality in a microwave node. The way that interface gets used for managing and controlling nodes and networks typically varies from one operator to another, depending on the systems they use and how those systems interact. Possible approaches include using a Network Management System (NMS), Software-Defined Networking (SDN), or some combination of the two. Lots of networks still have the NMS as one component/interface, with the SDN controller scoped to control-plane functionality as a separate component/interface, so this document does not preclude either model. The aim here is to provide a framework for development of a common YANG data model for both management and control of microwave interfaces. periodt 💅

3.1. Network Management Solutions

The classic network management solutions are still the dominant ones, honestly. They combine vendor-specific domain management with cross-domain functionality for service management and analytics. These solutions are expected to evolve and benefit from an increased focus on standardization, by simplifying multi-vendor management and removing the need for vendor- or domain-specific management. ✨🫶

3.2. Software-Defined Networking

One of the main drivers for applying SDN from an operator perspective is simplification and automation of network provisioning, plus end-to-end network service management. The vision is to have a global view of the network conditions spanning different vendors' equipment and multiple technologies. it's so ambitious and I'm obsessed 😭

If nodes from different vendors are managed by the same SDN controller via a node management interface, without the extra effort of introducing intermediate systems, then all nodes must align their node management interfaces. Hence, an open and standardized node management interface is required in a multi-vendor environment. Such a standardized interface enables unified management and configuration of nodes from different vendors by a common set of applications. no more chaos bestie 🌈

In addition to SDN applications for configuring, managing, and controlling the nodes and their associated transport interfaces (including the L2 Ethernet, L3 IP, and radio interfaces), there are also a large variety of more advanced SDN applications that can be utilized and/or developed. the possibilities are literally endless 🧚

A potentially flexible approach for operators is to use SDN in a logically controlled way, managing the radio links by selecting a predefined operation mode. The operation mode is a set of logical metrics or parameters describing a complete radio link configuration, such as capacity, availability, priority, and power consumption. 🎀

An example of an operation mode table is shown in Figure 3. Based on its operation policy (e.g., power consumption or traffic priority), the SDN controller selects one operation mode and translates that into the required configuration of the individual parameters for the Radio Link Terminals and the associated Carrier Terminations. so the controller does the thinking and the parameters get set, iykyk 🫶

   +----+---------------+------------+-------------+-----------+------+
   | ID |Description    | Capacity   |Availability | Priority  |Power |
   +----+---------------+------------+-------------+-----------+------+
   | 1  |High capacity  |  400 Mbps  |  99.9%      | Low       |High  |
   +----+---------------+------------+-------------+-----------+------+
   | 2  |High avail-    |  100 Mbps  |  99.999%    | High      |Low   |
   |    | ability       |            |             |           |      |
   +----+---------------+------------+-------------+-----------+------+

               Figure 3: Example of an Operation Mode Table

An operation mode bundles together the values of a set of different parameters. How each operation mode maps a certain set of attributes is out of the scope of this document. (not me scoping things out, but okay 🙈)

4. Use Cases 🍓

The use cases described should be the basis for identifying and defining the parameters that a YANG data model needs to support, for managing radio links in a way that applies to centralized, unified, multi-vendor management. The use cases involve configuration management, inventory, status and statistics, performance management, fault management, and troubleshooting and root cause analysis. the full list, bestie 📋

Other product-specific use cases, e.g., addressing installation or on-site troubleshooting and fault resolution, are outside the scope of this framework. If required, these use cases are expected to be supported by product-specific extensions to the standardized model. 🌸

4.1. Configuration Management

Configuration management involves configuring a Radio Link Terminal, the constituent Carrier Terminations, and, when applicable, the relationship to IP/Ethernet and TDM interfaces. this is where the magic starts ✨

  • Understand the capabilities and limitations 💖

Exchange of information between a manager and a device about the capabilities supported and specific limitations in the parameter values and enumerations that can be used.

Examples of information that could be exchanged include the maximum modulation supported and support (or lack of support) for the Cross Polarization Interference Cancellation (XPIC) feature.

  • Initial Configuration 🦋

Initial configuration of a Radio Link Terminal, enough to establish Layer 1 (L1) connectivity to an associated Radio Link Terminal on a device at the far end over the hop. It may also include configuration of the relationship between a Radio Link Terminal and an associated traffic interface, e.g., an Ethernet interface, unless that is given by the equipment configuration.

Frequency, modulation, coding, and output power are examples of parameters typically configured for a Carrier Termination, and type of aggregation/bonding or protection configurations expected for a Radio Link Terminal. 🔥

  • Radio link reconfiguration and optimization 🧚

Reconfiguration, update, or optimization of an existing Radio Link Terminal. Output power and modulation for a Carrier Termination, as well as protection schemas and activation/deactivation of carriers in a Radio Link Terminal, are examples of parameters that can be reconfigured and used for optimization of the performance of a network. glow-up era 💅

  • Radio link logical configuration 👑

Radio Link Terminals configured to include a group of carriers are widely used in microwave technology. There are several kinds of groups: aggregation/bonding, 1+1 protection/redundancy, etc. To avoid configuring each Carrier Termination directly, a logical control provides flexible management by mapping a logical configuration to a set of physical attributes. This could also be applied in a hierarchical SDN environment where some domain controllers are located between the SDN controller and the Radio Link Terminal. the layers 🫶💜

4.2. Inventory

  • Retrieve logical inventory and configuration from device 🎀

Request from manager and response by device with information about radio interfaces, e.g., their constitution and configuration.

  • Retrieve physical/equipment inventory from device 🌈

Request from manager about physical and/or equipment inventory associated with the Radio Link Terminals and Carrier Terminations.

4.3. Status and Statistics ✨

  • Actual status and performance of a radio link interface 📡

The manager asks, and the device answers, with what's actually happening: the status and statistics of the configured radio link interfaces and their parts 🔍. Reporting the effective bandwidth of a radio link is a big deal, bestie, because the link can dynamically adjust its modulation based on the current signal conditions 🌈.

4.4. Performance Management 📊

  • Configuration of historical performance measurements 🗂️

Setting up historical performance measurements for a radio link interface and/or its parts 💅. See Section 4.1.

  • Collection of historical performance data 📥

Pulling historical performance data in bulk is a general use case for a device, not something specific to radio link interfaces 🫶.

Grabbing an individual counter for one specific interval is sometimes needed too, as a complement to the bulk retrieval I just mentioned 🧚.

4.5. Fault Management 🚨

  • Configuration of alarm reporting ⚙️

Setting up alarm reporting that's specific to radio interfaces, like configuring the alarm severity, is a subset of the configuration use case we're supporting 💖. See Section 4.1.

  • Alarm management 🔔

Alarm synchronization, visualization, handling, notifications, and events are generic use cases for a device, and they SHOULD be supported on a radio link interface ✨. There are also radio-specific alarms that are important to report 🙈. Signal degradation of the radio link is one example 📉.

4.6. Troubleshooting and Root Cause Analysis 🕵️‍♀️

Here we give the manager or operator the information they need, plus suggested actions, to dig into and understand the root of a problem with the performance and/or functionality of a Radio Link Terminal and its associated Carrier Terminations 🔎💜.

5. Requirements 📝

For managing a microwave node that covers both the radio link and the packet transport functionality, we want a unified data model 💫. It should model the radio link interfaces and the L2/L3 interfaces with the same structure and the same modeling approach 🎀. If some part of the model is generic enough for other technology usage, that SHOULD be clearly stated 👑.

The point of the YANG data model is to manage and control the radio link interface(s) and how they relate to and connect with other interfaces, typically Ethernet interfaces, in a microwave node 🦋.

The ability to configure and manage microwave nodes comes with these requirements for the model 💅:

  1. It MUST be possible to configure, manage, and control a Radio Link Terminal and its constituent Carrier Terminations 🔥.
    • A. Configuration of frequency, channel bandwidth, modulation, coding, and transmitter output power MUST be supported for a Carrier Termination ⚡.
    • B. A Radio Link Terminal MUST configure the associated Carrier Terminations and the type of aggregation/bonding or protection configurations expected for the Radio Link Terminal 🫶.
    • C. The capability (e.g., the maximum modulation supported) and the actual status/statistics (e.g., administrative status of the carriers) SHOULD also be supported by the data model 🌸.
    • D. The definition of the features and parameters SHOULD be based on established microwave equipment and radio standards, such as ETSI EN 302 217 [EN302217-2], which specifies the essential parameters for microwave systems operating from 1.4 GHz to 86 GHz 🧚.
  2. It MUST be possible to map different traffic types (e.g., TDM and Ethernet) to the transport capacity provided by a specific Radio Link Terminal 🍓.
  3. It MUST be possible to configure and collect historical measurements (for the use case described in Section 4.4) to be performed on a radio link interface (e.g., minimum, maximum, average transmit power, and received level in dBm) 📈.
  4. It MUST be possible to configure and retrieve alarms reporting associated with the radio interfaces (e.g., configuration fault, signal lost, modem fault, and radio fault) 🚨.

6. Gap Analysis on Models 🧩

The gap analysis is all about figuring out and recommending which models to use in a microwave device so the use cases and requirements from the previous sections actually work 💖. It also recommends how the unsupported gaps should get filled, including whether we need brand-new models or updates to existing models and documents 🛠️.

Two models already exist for microwave radio link functionality: the "Microwave Information Model" from the ONF [ONF-MW], and the "Microwave Radio Link YANG Data Models" that were submitted to and discussed in the CCAMP Working Group [CCAMP-MW] 🌈. This analysis takes both of these initiatives into account and recommends how to use and complement them to fill the gaps we found ✨.

For generic functionality (stuff that isn't specific to radio links), the goal is to point to existing or emerging models that could work across all the functional areas in a microwave node 🎀.

[ONF-CIM] defines a CoreModel of the ONF Common Information Model 💅. An information model describes the things in a domain in terms of objects, their properties (represented as attributes), and their relationships 🧠. The ONF information model is written in Unified Modeling Language (UML) 🦋. The ONF CoreModel doesn't depend on any specific data-plane technology 🫶. The technology-specific content, added in a runtime solution via "filled in" cases of specification, augments the CoreModel by giving it a forwarding technology-specific representation 🔥.

IETF data models define implementations and protocol-specific details 🌸. YANG is a data modeling language used to model configuration and state data 💜. [RFC8343] defines a generic YANG data model for interface management that doesn't include technology-specific information 🍓. To describe the technology-specific information, several YANG data models have been proposed in the IETF to augment [RFC8343], such as the data model defined in [RFC8344] 🧚. The YANG data model is a popular approach for modeling interfaces for many packet transport technologies, which makes it well positioned to become an industry standard 👑. Given that trend, [CCAMP-MW] offers a YANG data model proposal for radio interfaces that lines up nicely with the structure of other technology-specific YANG data models augmenting [RFC8343] ✨.

[RFC3444] explains the difference between Information Models (IMs) and Data Models (DMs) 📚. An IM models managed objects at a conceptual level for designers and operators, while a DM is defined at a lower level and includes lots of details for implementers 🤓. On top of that, the protocol-specific details usually go into a DM 💅. Since conceptual models can be implemented in different ways, multiple DMs can come from a single IM 🌈.

We recommend using the structure of the model in [CCAMP-MW] as the starting point, since it's a data model that gives the alignment with [RFC8343] we want 🎀. To cover the gaps we've identified, we recommend defining new leafs/parameters and including them in the new model [IETF-MW], while taking reference from [ONF-CIM] 🛠️. We also recommend adding the required data nodes to describe the interface layering for the capacity a Radio Link Terminal provides, plus the associated Ethernet and TDM interfaces in a microwave node 🦋. The principles and data nodes for interface layering described in [RFC8343] SHOULD be used as a basis 💖.

6.2. Generic Functionality 🌸

For generic functionality (not specific to radio links), the recommendation is to refer to existing RFCs or emerging Internet-Drafts, as shown in Figure 4 🧚. "[IETF-MW]" appears in Figure 4 wherever the functionality is recommended for inclusion in the new model [IETF-MW], as described in Section 6.1 💜.

+------------------------------------+-----------------------------+
| Generic Functionality              | Recommendation              |
|                                    |                             |
+------------------------------------+-----------------------------+
|1. Fault Management                 |                             |
|                                    |                             |
|   Alarm Configuration              | [IETF-MW]                   |
|                                    |                             |
|   Alarm Notifications/             | [YANG-ALARM]                |
|   Synchronization                  |                             |
+------------------------------------+-----------------------------+
|2. Performance Management           |                             |
|                                    |                             |
|   Performance Configuration/       | [IETF-MW]                   |
|   Activation                       |                             |
|                                    |                             |
|   Performance Collection           | [IETF-MW] and XML files     |
+------------------------------------+-----------------------------+
|3.  Physical/Equipment Inventory    | [RFC8348]                   |
+------------------------------------+-----------------------------+

Figure 4: Recommendation for How to Support Generic Functionality 🎀

Microwave-specific alarm configurations are recommended for the new model [IETF-MW], and they could be based on what the models in [ONF-MW] and [CCAMP-MW] already support 🔔. Alarm notifications and synchronization are general, so we recommend supporting them with a generic model, such as [YANG-ALARM] ✨.

Activating interval counters and thresholds could be a generic function, but it's recommended to be supported by the new model [IETF-MW] 💅. It can be based on the models in [ONF-MW] and [CCAMP-MW] 🌈.

Collecting interval/historical counters is a generic function that a node needs to support 📊. File-based collection via the SSH File Transfer Protocol (SFTP) and collection via NETCONF/YANG interfaces are two possible options, and the recommendation is to include support for the latter in the new model [IETF-MW] 🦋. The models in [ONF-MW] and [CCAMP-MW] can also be used as a basis in this area 🫶.

Physical and/or equipment inventory for the Radio Link Terminals and Carrier Terminations is recommended to be covered by a generic model for the complete node, such as the model defined in [RFC8348] 🧚. That makes it outside the scope of the new model [IETF-MW] 💜.

6.3. Summary ✨

okay so here's the big conclusion from all that analysis 💅 there are six recommendations, and they're honestly so satisfying:

  1. A new YANG data model for radio link [IETF-MW] should be defined with enough scope to support the use cases and requirements in Sections 4 and 5 of this document. 🦋
  2. Use the structure of the model described in [CCAMP-MW] as the starting point. It augments [RFC8343] and is thereby as required aligned with the structure of the models for management of the L2 and L3 domains. 🌸
  3. Use established microwave equipment and radio standards (such as [EN302217-2], the model described in [CCAMP-MW], and the model described in [ONF-MW]) as the basis for the definition of the detailed leafs/ parameters to support the specified use cases and requirements, proposing new ones to cover identified gaps. 🧚
  4. Add the required data nodes to describe the interface layering for the capacity provided by a Radio Link Terminal and the associated Ethernet and TDM interfaces, using the principles and data nodes for interface layering described in [RFC8343] as a basis. 💖
  5. Include support for configuration of microwave-specific alarms in the new YANG data model [IETF-MW] and rely on a generic model such as [YANG-ALARM] for notifications and alarm synchronization. 🔥
  6. Use a generic model such as [RFC8348] for physical/equipment inventory. ✨

7. Security Considerations 🔒

okay bestie, this part is serious, so let's be real 😭 the configuration info can be sensitive and vulnerable on networks. if somebody gets unauthorized access to configuration data nodes, it can mess with network operations. think interrupting the ability to forward traffic, or boosting the interference level of the network. 💀

the status and inventory also reveal network info that could be super helpful to an attacker, and an attack on that info may end up causing a loss of customer data. not okay at all.

the good news is access control on management interfaces can generally be handled with authentication techniques that provide origin verification, integrity, and confidentiality 🫶 management interfaces can also be physically or logically isolated by setting them up to be accessible only out-of-band, through a system that is physically or logically separated from the rest of the network infrastructure. 🧱

when management interfaces are accessible in-band, either at the client device or within the microwave transport network domain, filtering or firewalling techniques can be used to restrict unauthorized in-band traffic. and authentication techniques may be used in all cases too 🛡️

this framework describes the requirements and characteristics of a YANG data model for control and management of the radio link interfaces in a microwave node. it is supposed to be accessed via a management protocol with a secure transport layer, such as NETCONF [RFC6241]. 🎀

8. IANA Considerations 🌈

okay, quick and easy one: this document has no IANA actions. 💅

9. References 📚

9.1. Normative References 🌟

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References 🦋

[CCAMP-MW] Ahlberg, J., Carlson, J-O., Lund, H-A., Olausson, T.,
           Ye, M., and M. Vaupotic, "Microwave Radio Link YANG Data
           Models", Work in Progress, draft-ahlberg-ccamp-microwave-
           radio-link-01, May 2016.

[EN302217-2]
           ETSI, "Fixed Radio Systems; Characteristics and
           requirements for point-to-point equipment and antennas;
           Part 2: Digital systems operating in frequency bands from
           1 GHz to 86 GHz; Harmonised Standard covering the
           essential requirements of article 3.2 of Directive
           2014/53/EU", ETSI EN 302 217-2, V3.1.1, May 2017.

[IEEE802.1Qcp]
           IEEE, "Bridges and Bridged Networks Ammendment: YANG Data
           Model", Work in Progress, Draft 2.2, March 2018,
           <https://1.ieee802.org/tsn/802-1qcp/>.

[IETF-MW]  Ahlberg, J., Ye, M., Li, X., Spreafico, D., and
           M. Vaupotic, "A YANG Data Model for Microwave Radio Link",
           Work in Progress, draft-ietf-ccamp-mw-yang-10, October
           2018.

[ONF-CIM]  ONF, "Core Information Model (CoreModel)", ONF
           TR-512, version 1.2, September 2016,
           <https://www.opennetworking.org/images/stories/downloads/
           sdn-resources/technical-reports/
           TR-512_CIM_(CoreModel)_1.2.zip>.

[ONF-MW]   ONF, "Microwave Information Model", ONF TR-532, version
           1.0, December 2016,
           <https://www.opennetworking.org/images/stories/downloads/
           sdn-resources/technical-reports/
           TR-532-Microwave-Information-Model-V1.pdf>.

[RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
           MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
           <https://www.rfc-editor.org/info/rfc2863>.

[RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
           Information Models and Data Models", RFC 3444,
           DOI 10.17487/RFC3444, January 2003,
           <https://www.rfc-editor.org/info/rfc3444>.

[RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
           and A. Bierman, Ed., "Network Configuration Protocol
           (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
           <https://www.rfc-editor.org/info/rfc6241>.

[RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
           Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
           Defined Networking (SDN): Layers and Architecture
           Terminology", RFC 7426, DOI 10.17487/RFC7426, January
           2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
           Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
           <https://www.rfc-editor.org/info/rfc8343>.

[RFC8344]  Bjorklund, M., "A YANG Data Model for IP Management",
           RFC 8344, DOI 10.17487/RFC8344, March 2018,
           <https://www.rfc-editor.org/info/rfc8344>.

[RFC8348]  Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
           YANG Data Model for Hardware Management", RFC 8348,
           DOI 10.17487/RFC8348, March 2018,
           <https://www.rfc-editor.org/info/rfc8348>.

[RFC8349]  Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
           Routing Management (NMDA Version)", RFC 8349,
           DOI 10.17487/RFC8349, March 2018,
           <https://www.rfc-editor.org/info/rfc8349>.

[YANG-ALARM]
           Vallin, S. and M. Bjorklund, "YANG Alarm Module", Work in
           Progress, draft-ietf-ccamp-alarm-module-04, October 2018.

Contributors 🫶

these are the lovely people who helped make this happen 🌸

Marko Vaupotic
Aviat Networks
Motnica 9
Trzin-Ljubljana  1236
Slovenia

Email: Marko.Vaupotic@aviatnet.com


Jeff Tantsura

Email: jefftant.ietf@gmail.com


Koji Kawada
NEC Corporation
1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan

Email: k-kawada@ah.jp.nec.com


Ippei Akiyoshi
NEC
1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan

Email: i-akiyoshi@ah.jp.nec.com


Daniela Spreafico
Nokia - IT
Via Energy Park, 14
Vimercate (MI)  20871
Italy

Email: daniela.spreafico@nokia.com

Authors' Addresses 💜

and last but not least, the authors, who are literally the reason we have any of this 😭✨

Jonas Ahlberg (editor)
Ericsson AB
Lindholmspiren 11
Goteborg  417 56
Sweden

Email: jonas.ahlberg@ericsson.com


Min Ye (editor)
Huawei Technologies
No.1899, Xiyuan Avenue
Chengdu  611731
China

Email: amy.yemin@huawei.com


Xi Li
NEC Laboratories Europe
Kurfuersten-Anlage 36
Heidelberg  69115
Germany

Email: Xi.Li@neclab.eu


Luis Contreras
Telefonica I+D
Ronda de la Comunicacion, S/N
Madrid  28050
Spain

Email: luismiguel.contrerasmurillo@telefonica.com


Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Madrid, Leganes  28911
Spain

Email: cjbc@it.uc3m.es

that's the whole RFC, bestie! 🌈👑 you're officially done 🎀

📦 where this page comes from