RFC 8561
A YANG Data Model for Microwave Radio Link
RFC 8561: A YANG Data Model for Microwave Radio Link π‘β¨
Okay bestie, let's get the basics down first π. This is RFC 8561, published by the IETF in June 2019 as a Standards Track document, which means it's an official Internet standard π. Its ISSN is 2070-1721. The authors are J. Ahlberg (Ericsson AB), M. Ye (Huawei Technologies), X. Li (NEC Laboratories Europe), D. Spreafico (Nokia - IT), and M. Vaupotic (Aviat Networks) π«Ά. The title block doesn't list anything this RFC obsoletes or updates, so it's standing on its own π¦.
Abstract
This doc defines a YANG data model for controlling and managing radio link interfaces and how they connect to packet interfaces (usually Ethernet) on a microwave or millimeter wave node π‘. The data nodes for managing interface protection get pulled out into their own separate, generic YANG data model π§©. Why? So other interface types can use it too π. Efficient, iconic, no notes π .
Status of This Memo
This is an Internet Standards Track document π.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community π«Ά. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) β¨. If you want more on Internet Standards, check out Section 2 of RFC 7841 π.
Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8561 π.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved π.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document π§Ύ. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License π.
Table of Contents πΊοΈ
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3
1.2. Tree Structure . . . . . . . . . . . . . . . . . . . . . 5
2. Microwave Radio Link YANG Data Model . . . . . . . . . . . . 5
2.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Explanation of the Microwave Data Model . . . . . . . . . 7
3. Microwave Radio Link YANG Data Model . . . . . . . . . . . . 7
4. Interface Protection YANG Data Model . . . . . . . . . . . . 27
5. Microwave Types YANG Data Model . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Normative References . . . . . . . . . . . . . . . . . . 43
8.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Example: 1+0 and 2+0 Configuration Instances . . . . 47
A.1. 1+0 Instance . . . . . . . . . . . . . . . . . . . . . . 47
A.2. 2+0 Instance . . . . . . . . . . . . . . . . . . . . . . 49
A.3. 2+0 XPIC Instance . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction β¨
This doc defines a YANG data model for managing and controlling radio link interfaces, plus how they relate to packet interfaces (usually Ethernet) and/or Time-Division Multiplexing (TDM) interfaces on a microwave or millimeter wave node π‘. The ETSI EN 302 217 series is where the characteristics and requirements of microwave and millimeter wave equipment and antennas are defined π°οΈ. Specifically, ETSI EN 302 217-2 [EN302217-2] lays out the essential parameters for systems running from 1.4 GHz to 86 GHz π. The data model includes configuration and state data, following the new Network Management Datastore Architecture [RFC8342] π§ .
The design follows the framework for managing and controlling microwave and millimeter wave interface parameters defined in [RFC8432] π . That framework figures out why the YANG data model is needed, its scope, the use cases, and the requirements it has to support π. It also does a detailed gap analysis to find the missing parameters and functionality in existing, established models, then recommends how to fill those gaps with a new model π. Based on the gap analysis, the data model's structure is based on the one defined in [MICROWAVE-RADIO-LINK], and it augments [RFC8343] so the packet interfaces line up with the same structure π«Ά. To be specific, the model includes interface layering to manage the capacity a radio link terminal provides to the associated Ethernet and TDM interfaces, using the interface layering principles from [RFC8343] as a basis π.
The data nodes for managing interface protection are split into a separate, generic YANG data module, so they can be used for other interface types too π¦.
The designed YANG data model is built on established microwave equipment and radio standards. Those include ETSI EN 302 217-2, the IETF Radio Link Model [MICROWAVE-RADIO-LINK], and the ONF Microwave Model [ONF-model] π§©. They're the foundation for the detailed leafs and parameters. The model also proposes new ones to cover the gaps identified in [RFC8432] π₯.
1.1. Terminology and Definitions π
The following terms are used in this document:
Carrier Termination (CT) is an interface for the capacity provided over the air by a single carrier π». It's typically defined by its transmitting and receiving frequencies π.
Radio Link Terminal (RLT) is an interface that provides packet capacity and/or TDM capacity to the associated Ethernet and/or TDM interfaces in a node πΈ. It's used to set up a transport service over a microwave or millimeter wave link β¨.
The following acronyms are used in this document:
ACM: Adaptive Coding Modulation
ATPC: Automatic Transmitter Power Control
BBE: Background Block Error
BER: Bit Error Ratio
BPSK: Binary Phase-Shift Keying
CM: Coding Modulation
CT: Carrier Termination
ES: Errored Seconds
IF: Intermediate Frequency
MIMO: Multiple Input Multiple Output
RF: Radio Frequency
RLT: Radio Link Terminal
QAM: Quadrature Amplitude Modulation
QPSK: Quadrature Phase-Shift Keying
RTPC: Remote Transmit Power Control
SES: Severely Errored Seconds
TDM: Time-Division Multiplexing
UAS: Unavailable Seconds
XPIC: Cross Polarization Interference Cancellation
1.2. Tree Structure π³
A simplified graphical view of the data model shows up in Section 2.1 of this document πΌοΈ. The meaning of the symbols in those diagrams is defined in [RFC8340] π.
2. Microwave Radio Link YANG Data Model π‘π
2.1. YANG Tree π³
module: ietf-microwave-radio-link
+--rw radio-link-protection-groups
| +--rw protection-group* [name]
| +--rw name string
| +--rw protection-architecture-type? identityref
| +--rw members* if:interface-ref
| +--rw operation-type? enumeration
| +--rw working-entity* if:interface-ref
| +--rw revertive-wait-to-restore? uint16
| +--rw hold-off-timer? uint16
| +--ro status? identityref
| +---x manual-switch-working
| +---x manual-switch-protection
| +---x forced-switch
| +---x lockout-of-protection
| +---x freeze
| +---x exercise
| +---x clear
+--rw xpic-pairs {xpic}?
| +--rw xpic-pair* [name]
| +--rw name string
| +--rw enabled? boolean
| +--rw members* if:interface-ref
+--rw mimo-groups {mimo}?
+--rw mimo-group* [name]
+--rw name string
+--rw enabled? boolean
+--rw members* if:interface-ref
augment /if:interfaces/if:interface:
+--rw id? string
+--rw mode identityref
+--rw carrier-terminations* if:interface-ref
+--rw rlp-groups*
| -> /radio-link-protection-groups/protection-group/name
+--rw xpic-pairs* -> /xpic-pairs/xpic-pair/name
| {xpic}?
+--rw mimo-groups* -> /mimo-groups/mimo-group/name
| {mimo}?
+--rw tdm-connections* [tdm-type] {tdm}?
+--rw tdm-type identityref
+--rw tdm-connections uint16
augment /if:interfaces/if:interface:
+--rw carrier-id? string
+--rw tx-enabled? boolean
+--ro tx-oper-status? enumeration
+--rw tx-frequency uint32
+--rw (freq-or-distance)
| +--:(rx-frequency)
| | +--rw rx-frequency? uint32
| +--:(duplex-distance)
| +--rw duplex-distance? int32
+--ro actual-rx-frequency? uint32
+--ro actual-duplex-distance? uint32
+--rw channel-separation uint32
+--rw polarization? enumeration
+--rw (power-mode)
| +--:(rtpc)
| | +--rw rtpc
| | +--rw maximum-nominal-power power
| +--:(atpc)
| +--rw atpc
| +--rw maximum-nominal-power power
| +--rw atpc-lower-threshold power
| +--rw atpc-upper-threshold power
+--ro actual-transmitted-level? power
+--ro actual-received-level? power
+--rw (coding-modulation-mode)
| +--:(single)
| | +--rw single
| | +--rw selected-cm identityref
| +--:(adaptive)
| +--rw adaptive
| +--rw selected-min-acm identityref
| +--rw selected-max-acm identityref
+--ro actual-tx-cm? identityref
+--ro actual-snir? decimal64
+--ro actual-xpi? decimal64 {xpic}?
+--rw ct-performance-thresholds
| +--rw received-level-alarm-threshold? power
| +--rw transmitted-level-alarm-threshold? power
| +--rw ber-alarm-threshold? enumeration
+--rw if-loop? enumeration
+--rw rf-loop? enumeration
+--ro capabilities
| +--ro min-tx-frequency? uint32
| +--ro max-tx-frequency? uint32
| +--ro min-rx-frequency? uint32
| +--ro max-rx-frequency? uint32
| +--ro minimum-power? power
| +--ro maximum-available-power? power
| +--ro available-min-acm? identityref
| +--ro available-max-acm? identityref
+--ro error-performance-statistics
| +--ro bbe? yang:counter32
| +--ro es? yang:counter32
| +--ro ses? yang:counter32
| +--ro uas? yang:counter32
+--ro radio-performance-statistics
+--ro min-rltm? power
+--ro max-rltm? power
+--ro min-tltm? power
+--ro max-tltm? power
2.2. Explanation of the Microwave Data Model π¦
okay so the leafs in the Interface Management Module that get augmented by RLT and CT are not always applicable π it's giving "pick and choose" energy.
"/interfaces/interface/enabled" is not applicable for RLT. ngl this one is a little plot twist: enabling and disabling an interface is done in the constituent CTs instead π
The packet-related measurements are also not in the scope of the microwave radio link domain, so they're not applicable for RLT and CT either. The full list is: "in-octets", "in-unicast-pkts", "in-broadcast-pkts", "in-multicast-pkts", "in-discards", "in-errors", "in-unknown-protos", "out-octets", "out-unicast-pkts", "out-broadcast-pkts", "out-multicast-pkts", "out-discards", and "out-errors" π bestie, that's a lot of counters to not care about π
3. Microwave Radio Link YANG Data Model β¨
okay so this module imports typedefs and modules from [RFC6991], [RFC8343] and [RFC7224], and it references [TR102311], [EN302217-1], [EN301129], and [G.826]. the whole thing is giving organized and iconic π
<CODE BEGINS> file "ietf-microwave-radio-link@2019-06-19.yang"
module ietf-microwave-radio-link {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link";
prefix mrl;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991";
}
import iana-if-type {
prefix ianaift;
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343";
}
import ietf-interface-protection {
prefix ifprot;
reference
"RFC 8561";
}
import ietf-microwave-types {
prefix mw-types;
reference
"RFC 8561";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"WG List: <mailto:ccamp@ietf.org>
Editors:
Jonas Ahlberg (jonas.ahlberg@ericsson.com)
Min Ye (amy.yemin@huawei.com)
Xi Li (Xi.Li@neclab.eu)
Daniela Spreafico (daniela.spreafico@nokia.com)
Marko Vaupotic (Marko.Vaupotic@aviatnet.com)";
description
"This is a module for the entities in
a generic microwave system.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8561; see
the RFC itself for full legal notices.";
revision 2019-06-19 {
description
"Initial revision.";
reference
"RFC 8561: A YANG Data Model for Microwave Radio Link";
}
/*
* Features
*/
feature xpic {
description
"Indicates that the device supports XPIC.";
reference
"ETSI TR 102 311";
}
feature mimo {
description
"Indicates that the device supports MIMO.";
reference
"ETSI TR 102 311";
}
feature tdm {
description
"Indicates that the device supports TDM.";
}
/*
* Typedefs
*/
typedef power {
type decimal64 {
fraction-digits 1;
}
description
"Type used for the power values in the data nodes
for configuration or status.";
}
/*
* Radio Link Terminal (RLT)
*/
augment "/if:interfaces/if:interface" {
when "derived-from-or-self(if:type,"
+ "'ianaift:microwaveRadioLinkTerminal')";
description
"Addition of data nodes for the radio link terminal to
the standard Interface data model, for interfaces of
the type 'microwaveRadioLinkTerminal'.";
leaf id {
type string;
description
"Descriptive identity of the radio link terminal used by
far-end RLT to check that it's connected to the correct
near-end RLT. Does not need to be configured if this
check is not used.";
}
leaf mode {
type identityref {
base mw-types:rlt-mode;
}
mandatory true;
description
"A description of the mode in which the radio link
terminal is configured. The format is X plus Y.
X represents the number of bonded carrier terminations.
Y represents the number of protecting carrier
terminations.";
}
leaf-list carrier-terminations {
type if:interface-ref;
must "derived-from-or-self(/if:interfaces/if:interface"
+ "[if:name = current()]"
+ "/if:type, 'ianaift:microwaveCarrierTermination')" {
description
"The type of interface must be
'microwaveCarrierTermination'.";
}
min-elements 1;
description
"A list of references to carrier terminations
included in the radio link terminal.";
}
leaf-list rlp-groups {
type leafref {
path "/mrl:radio-link-protection-groups/"
+ "mrl:protection-group/mrl:name";
}
description
"A list of references to the carrier termination
groups configured for radio link protection in this
radio link terminal.";
}
leaf-list xpic-pairs {
if-feature "xpic";
type leafref {
path "/mrl:xpic-pairs/mrl:xpic-pair/mrl:name";
}
description
"A list of references to the XPIC pairs used in this
radio link terminal. One pair can be used by two
terminals.";
reference
"ETSI TR 102 311";
}
leaf-list mimo-groups {
if-feature "mimo";
type leafref {
path "/mrl:mimo-groups/mrl:mimo-group/mrl:name";
}
description
"A reference to the MIMO group used in this
radio link terminal. One group can be used by more
than one terminal.";
reference
"ETSI TR 102 311";
}
list tdm-connections {
if-feature "tdm";
key "tdm-type";
description
"A list stating the number of active TDM connections
of a specified tdm-type that is configured to be
supported by the RLT.";
leaf tdm-type {
type identityref {
base mw-types:tdm-type;
}
description
"The type of TDM connection, which also indicates
the supported capacity.";
}
leaf tdm-connections {
type uint16;
mandatory true;
description
"Number of connections of the specified type.";
}
}
}
/*
* Carrier Termination
*/
okay bestie, this chunk is all YANG, so we're dropping the code in exactly as written π π
augment "/if:interfaces/if:interface" {
when "derived-from-or-self(if:type,"
+ "'ianaift:microwaveCarrierTermination')";
description
"Addition of data nodes for carrier termination to
the standard Interface data model, for interfaces
of the type 'microwaveCarrierTermination'.";
leaf carrier-id {
type string;
default "A";
description
"ID of the carrier (e.g., A, B, C, or D).
Used in XPIC and MIMO configurations to check that
the carrier termination is connected to the correct
far-end carrier termination. Should be the same
carrier ID on both sides of the hop. Left as
default value when MIMO and XPIC are not in use.";
}
leaf tx-enabled {
type boolean;
default "false";
description
"Disables (false) or enables (true) the transmitter.
Only applicable when the interface is enabled
(interface:enabled = true); otherwise, it's always
disabled.";
}
leaf tx-oper-status {
type enumeration {
enum off {
description
"Transmitter is off.";
}
enum on {
description
"Transmitter is on.";
}
enum standby {
description
"Transmitter is in standby.";
}
}
config false;
description
"Shows the operative status of the transmitter.";
}
leaf tx-frequency {
type uint32;
units "kHz";
mandatory true;
description
"Selected transmitter frequency.";
}
choice freq-or-distance {
leaf rx-frequency {
type uint32;
units "kHz";
description
"Selected receiver frequency.";
}
leaf duplex-distance {
type int32;
units "kHz";
description
"Distance between transmitter and receiver frequencies.";
}
mandatory true;
description
"A choice to configure rx-frequency directly or compute
it as duplex-distance subtracted from tx-frequency.";
}
leaf actual-rx-frequency {
type uint32;
units "kHz";
config false;
description
"Computed receiver frequency.";
}
leaf actual-duplex-distance {
type uint32;
units "kHz";
config false;
description
"Computed distance between Tx and Rx frequencies.";
}
leaf channel-separation {
type uint32;
units "kHz";
mandatory true;
description
"The amount of bandwidth allocated to a carrier. The
distance between adjacent channels in a radio
frequency channels arrangement";
reference
"ETSI EN 302 217-1";
}
leaf polarization {
type enumeration {
enum horizontal {
description
"Horizontal polarization.";
}
enum vertical {
description
"Vertical polarization.";
}
enum not-specified {
description
"Polarization not specified.";
}
}
default "not-specified";
description
"Polarization - a textual description for info only.";
}
choice power-mode {
container rtpc {
description
"Remote Transmit Power Control (RTPC).";
reference
"ETSI EN 302 217-1";
leaf maximum-nominal-power {
type power {
range "-99..99";
}
units "dBm";
mandatory true;
description
"Selected output power.";
reference
"ETSI EN 302 217-1";
}
}
container atpc {
description
"Automatic Transmitter Power Control (ATPC).";
reference
"ETSI EN 302 217-1";
leaf maximum-nominal-power {
type power {
range "-99..99";
}
units "dBm";
mandatory true;
description
"Selected maximum output power. Minimum output
power is the same as the system capability,
minimum-power.";
reference
"ETSI EN 302 217-1";
}
leaf atpc-lower-threshold {
type power {
range "-99..-20";
}
units "dBm";
must 'current() <= ../atpc-upper-threshold';
mandatory true;
description
"The lower threshold for the input power at the
far end, which is used in the ATPC mode.";
reference
"ETSI EN 302 217-1";
}
leaf atpc-upper-threshold {
type power {
range "-99..-20";
}
units "dBm";
mandatory true;
description
"The upper threshold for the input power at the
far end, which is used in the ATPC mode.";
reference
"ETSI EN 302 217-1";
}
}
mandatory true;
description
"A choice of RTPC or ATPC.";
}
leaf actual-transmitted-level {
type power {
range "-99..99";
}
units "dBm";
config false;
description
"Actual transmitted power level (0.1 dBm resolution).";
reference
"ETSI EN 301 129";
}
leaf actual-received-level {
type power {
range "-99..-20";
}
units "dBm";
config false;
description
"Actual received power level (0.1 dBm resolution).";
reference
"ETSI EN 301 129";
}
choice coding-modulation-mode {
container single {
description
"A single modulation order only.";
reference
"ETSI EN 302 217-1";
leaf selected-cm {
type identityref {
base mw-types:coding-modulation;
}
mandatory true;
description
"Selected the single coding/modulation.";
}
}
container adaptive {
description
"Adaptive coding/modulation.";
reference
"ETSI EN 302 217-1";
leaf selected-min-acm {
type identityref {
base mw-types:coding-modulation;
}
mandatory true;
description
"Selected minimum coding/modulation.
Adaptive coding/modulation shall not go
below this value.";
}
leaf selected-max-acm {
type identityref {
base mw-types:coding-modulation;
}
mandatory true;
description
"Selected maximum coding/modulation.
Adaptive coding/modulation shall not go
above this value.";
}
}
mandatory true;
description
"A selection of single or
adaptive coding/modulation mode.";
}
leaf actual-tx-cm {
type identityref {
base mw-types:coding-modulation;
}
config false;
description
"Actual coding/modulation in transmitting direction.";
}
leaf actual-snir {
type decimal64 {
fraction-digits 1;
range "0..99";
}
units "dB";
config false;
description
"Actual signal to noise plus the interference ratio
(0.1 dB resolution).";
}
leaf actual-xpi {
if-feature "xpic";
type decimal64 {
fraction-digits 1;
range "0..99";
}
units "dB";
config false;
description
"The actual carrier to cross-polar interference.
Only valid if XPIC is enabled (0.1 dB resolution).";
reference
"ETSI TR 102 311";
}
container ct-performance-thresholds {
description
"Specification of thresholds for when alarms should
be sent and cleared for various performance counters.";
leaf received-level-alarm-threshold {
type power {
range "-99..-20";
}
units "dBm";
default "-99";
description
"An alarm is sent when the received power level is
below the specified threshold.";
reference
"ETSI EN 301 129";
}
leaf transmitted-level-alarm-threshold {
type power {
range "-99..99";
}
units "dBm";
default "-99";
description
"An alarm is sent when the transmitted power level
is below the specified threshold.";
reference
"ETSI EN 301 129";
}
leaf ber-alarm-threshold {
type enumeration {
enum 1e-9 {
description
"Threshold at 1e-9 (10^-9).";
}
enum 1e-8 {
description
"Threshold at 1e-8 (10^-8).";
Okay so we're mid-enum, right in the middle of the BER thresholds π Let's go π«Ά
}
enum 1e-7 {
description
"Threshold at 1e-7 (10^-7).";
}
enum 1e-6 {
description
"Threshold at 1e-6 (10^-6).";
}
enum 1e-5 {
description
"Threshold at 1e-5 (10^-5).";
}
enum 1e-4 {
description
"Threshold at 1e-4 (10^-4).";
}
enum 1e-3 {
description
"Threshold at 1e-3 (10^-3).";
}
enum 1e-2 {
description
"Threshold at 1e-2 (10^-2).";
}
enum 1e-1 {
description
"Threshold at 1e-1 (10^-1).";
}
}
default "1e-6";
description
"Specification of at which BER an alarm should
be raised.";
reference
"ETSI EN 302 217-1";
}
}
leaf if-loop {
type enumeration {
enum disabled {
description
"Disables the IF Loop.";
}
enum client {
description
"Loops the signal back to the client side.";
}
enum radio {
description
"Loops the signal back to the radio side.";
}
}
default "disabled";
description
"Enable (client/radio) or disable (disabled)
the IF Loop, which loops the signal back to
the client side or the radio side.";
}
leaf rf-loop {
type enumeration {
enum disabled {
description
"Disables the RF Loop.";
}
enum client {
description
"Loops the signal back to the client side.";
}
enum radio {
description
"Loops the signal back to the radio side.";
}
}
default "disabled";
description
"Enable (client/radio) or disable (disabled)
the RF loop, which loops the signal back to
the client side or the radio side.";
}
Next up is the capabilities container π It's the read-only info about what the installed gear can actually do, plus a few picked settings. Frequencies are in kHz and power is in dBm, and yes, the maximum-available-power and minimum-power leaves both point at ETSI EN 302 217-1 β¨
container capabilities {
config false;
description
"Capabilities of the installed equipment and
some selected configurations.";
leaf min-tx-frequency {
type uint32;
units "kHz";
description
"Minimum Tx frequency possible to use.";
}
leaf max-tx-frequency {
type uint32;
units "kHz";
description
"Maximum Tx frequency possible to use.";
}
leaf min-rx-frequency {
type uint32;
units "kHz";
description
"Minimum Rx frequency possible to use.";
}
leaf max-rx-frequency {
type uint32;
units "kHz";
description
"Maximum Tx frequency possible to use.";
}
leaf minimum-power {
type power;
units "dBm";
description
"The minimum output power supported.";
reference
"ETSI EN 302 217-1";
}
leaf maximum-available-power {
type power;
units "dBm";
description
"The maximum output power supported.";
reference
"ETSI EN 302 217-1";
}
leaf available-min-acm {
type identityref {
base mw-types:coding-modulation;
}
description
"Minimum coding-modulation possible to use.";
}
leaf available-max-acm {
type identityref {
base mw-types:coding-modulation;
}
description
"Maximum coding-modulation possible to use.";
}
}
container error-performance-statistics {
config false;
description
"ITU-T G.826 error performance statistics relevant for
a microwave/millimeter wave carrier.";
leaf bbe {
type yang:counter32;
units "number of block errors";
description
"Number of Background Block Errors (BBEs). A BBE is an
errored block not occurring as part of Severely Errored
Seconds (SES). Discontinuities in the value of this
counter can occur at re-initialization of the management
system and at other times as indicated by the value of
'discontinuity-time' in ietf-interfaces.";
reference
"ITU-T G.826";
}
leaf es {
type yang:counter32;
units "seconds";
description
"Number of Errored Seconds (ES). An ES is a one-second
period with one or more errored blocks or at least one
defect. Discontinuities in the value of this counter
can occur at re-initialization of the management system
and at other times as indicated by the value of
'discontinuity-time' in ietf-interfaces.";
reference
"ITU-T G.826";
}
leaf ses {
type yang:counter32;
units "seconds";
description
"Number of SES. SES is a one-second period that contains
equal or more than 30% errored blocks or at least
one defect. SES is a subset of ES. Discontinuities in
the value of this counter can occur at re-initialization
of the management system and at other times as indicated
by the value of 'discontinuity-time' in ietf-interfaces.";
reference
"ITU-T G.826";
}
leaf uas {
type yang:counter32;
units "seconds";
description
"Number of Unavailable Seconds (UAS); that is, the
total time that the node has been unavailable.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time' in ietf-interfaces.";
reference
"ITU-T G.826";
}
}
Now the radio performance stats π¦ These are the ETSI EN 301 129 numbers for received and transmitted power levels, and the ranges are different for the rx pair (-99..-20) versus the tx pair (-99..99). Then we get the radio link protection groups, which are a whole vibe π Lowkey, the must lines are the bit that checks each member is a microwaveCarrierTermination π
container radio-performance-statistics {
config false;
description
"ETSI EN 301 129 radio physical interface statistics relevant
for a carrier termination.";
leaf min-rltm {
type power {
range "-99..-20";
}
units "dBm";
description
"Minimum received power level. Discontinuities in the
value of this counter can occur at re-initialization
of the management system and at other times as
indicated by the value of 'discontinuity-time' in
ietf-interfaces.";
reference
"ETSI EN 301 129";
}
leaf max-rltm {
type power {
range "-99..-20";
}
units "dBm";
description
"Maximum received power level. Discontinuities in the
value of this counter can occur at re-initialization
of the management system and at other times as
indicated by the value of 'discontinuity-time' in
ietf-interfaces.";
reference
"ETSI EN 301 129";
}
leaf min-tltm {
type power {
range "-99..99";
}
units "dBm";
description
"Minimum transmitted power level. Discontinuities
in the value of this counter can occur at
re-initialization of the management system and
at other times as indicated by the value of
'discontinuity-time' in ietf-interfaces.";
reference
"ETSI EN 301 129";
}
leaf max-tltm {
type power {
range "-99..99";
}
units "dBm";
description
"Maximum transmitted power level. Discontinuities
in the value of this counter can occur at
re-initialization of the management system and
at other times as indicated by the value of
'discontinuity-time' in ietf-interfaces.";
reference
"ETSI EN 301 129";
}
}
}
/*
* Radio Link Protection Groups
*/
container radio-link-protection-groups {
description
"Configuration of radio link protected groups of
carrier terminations in a radio link. More than one
protected group per radio link terminal is allowed.";
uses ifprot:protection-groups {
refine "protection-group/members" {
must "derived-from-or-self(/if:interfaces/if:interface"
+ "[if:name = current()]"
+ "/if:type, 'ianaift:microwaveCarrierTermination')" {
description
"The type of a protection member must be
'microwaveCarrierTermination'.";
}
}
refine "protection-group/working-entity" {
must "derived-from-or-self(/if:interfaces/if:interface"
+ "[if:name = current()]"
+ "/if:type, 'ianaift:microwaveCarrierTermination')" {
description
"The type of a working-entity must be
'microwaveCarrierTermination'.";
}
}
}
}
/*
* XPIC & MIMO groups - Configuration data nodes
*/
container xpic-pairs {
if-feature "xpic";
description
"Configuration of carrier termination pairs
for operation in XPIC mode.";
reference
"ETSI TR 102 311";
list xpic-pair {
key "name";
description
"List of carrier termination pairs in XPIC mode.";
leaf name {
type string;
description
"Name used for identification of the XPIC pair.";
}
leaf enabled {
type boolean;
default "false";
description
"Enable(true)/disable(false) XPIC";
}
leaf-list members {
type if:interface-ref;
must "derived-from-or-self(/if:interfaces/if:interface"
+ "[if:name = current()]"
+ "/if:type, 'ianaift:microwaveCarrierTermination')" {
description
"The type of a member must be
'microwaveCarrierTermination'.";
}
min-elements 2;
max-elements 2;
description
"Association to XPIC pairs used in the radio link
terminal.";
}
}
}
container mimo-groups {
if-feature "mimo";
description
"Configuration of carrier terminations
for operation in MIMO mode.";
reference
"ETSI TR 102 311";
list mimo-group {
key "name";
description
"List of carrier terminations in MIMO mode.";
leaf name {
type string;
description
"Name used for identification of the MIMO group.";
}
leaf enabled {
type boolean;
default "false";
description
"Enable(true)/disable(false) MIMO.";
}
leaf-list members {
type if:interface-ref;
must "derived-from-or-self(/if:interfaces/if:interface"
+ "[if:name = current()]"
+ "/if:type, 'ianaift:microwaveCarrierTermination')" {
description
"The type of a member must be
'microwaveCarrierTermination'.";
}
min-elements 2;
description
"Association to a MIMO group if used in the radio
link terminal.";
}
}
}
}
<CODE ENDS>
4. Interface Protection YANG Data Model β¨
Okay so the interface protection bits got their very own module π π‘οΈ Instead of living inside the Microwave Radio Link Module, they were pulled out into a separate, generic YANG data model. That means other interface types can use it too, which is honestly so iconic π π
This module imports [RFC8343] π¦ and references [G.808.1] π.
<CODE BEGINS> file "ietf-interface-protection@2019-06-19.yang"
module ietf-interface-protection {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-interface-protection";
prefix ifprot;
import ietf-interfaces {
prefix if;
reference
"RFC 8343";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"WG List: <mailto:ccamp@ietf.org>
Editors:
Jonas Ahlberg (jonas.ahlberg@ericsson.com)
Min Ye (amy.yemin@huawei.com)
Xi Li (Xi.Li@neclab.eu)
Daniela Spreafico (daniela.spreafico@nokia.com)
Marko Vaupotic (Marko.Vaupotic@aviatnet.com)";
description
"This is a module for the entities in
a generic interface protection mechanism.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8561; see
the RFC itself for full legal notices.";
revision 2019-06-19 {
description
"Initial revision.";
reference
"RFC 8561: A YANG Data Model for Microwave Radio Link";
}
/*
* Protection architecture type identities
*/
identity protection-architecture-type {
description
"protection architecture type";
reference
"ITU-T G.808.1";
}
identity one-plus-one-type {
base protection-architecture-type;
description
"1+1; one interface protects
another one interface.";
reference
"ITU-T G.808.1";
}
identity one-to-n-type {
base protection-architecture-type;
description
"1:N; one interface protects
n other interfaces.";
reference
"ITU-T G.808.1";
}
/*
* Protection states identities
*/
identity protection-states {
description
"Identities describing the status of the protection
in a group of interfaces configured in
a protection mode.";
}
identity unprotected {
base protection-states;
description
"Not protected.";
}
identity protected {
base protection-states;
description
"Protected.";
}
identity unable-to-protect {
base protection-states;
description
"Unable to protect.";
}
/*
* Protection Groups
*/
grouping protection-groups {
description
"Configuration of protected groups of interfaces
providing protection for each other. More than one
protected group per higher-layer interface is allowed.";
list protection-group {
key "name";
description
"List of protected groups of interfaces
in a higher-layer interface.";
leaf name {
type string;
description
"Name used for identification of the protection group.";
}
leaf protection-architecture-type {
type identityref {
base protection-architecture-type;
}
default "ifprot:one-plus-one-type";
description
"The type of protection architecture used, e.g., one
interface protecting one or several other interfaces.";
reference
"ITU-T G.808.1";
}
leaf-list members {
type if:interface-ref;
min-elements 2;
description
"Association to a group of interfaces configured for
protection and used by a higher-layer interface.";
}
leaf operation-type {
type enumeration {
enum non-revertive {
description
"In non-revertive operation, the traffic does not
return to the working interface if the switch requests
are terminated.";
reference
"ITU-T G.808.1";
}
enum revertive {
description
"In revertive operation, the traffic always
returns to (or remains on) the working interface
if the switch requests are terminated.";
reference
"ITU-T G.808.1";
}
}
default "non-revertive";
description
"The type of protection operation, i.e., revertive
or non-revertive operation.";
}
leaf-list working-entity {
when "../operation-type = 'revertive'";
type if:interface-ref;
min-elements 1;
description
"The interfaces that the traffic normally should
be transported over when there is no need to use the
protecting interface.";
}
leaf revertive-wait-to-restore {
when "../operation-type = 'revertive'";
type uint16;
units "seconds";
default "0";
description
"The time to wait before switching back to the working
interface if operation-type is revertive.";
reference
"ITU-T G.808.1";
}
leaf hold-off-timer {
type uint16;
units "milliseconds";
default "0";
description
"Time interval after the detection of a fault and its
confirmation as a condition requiring the protection-
switching procedure.";
reference
"ITU-T G.808.1";
}
leaf status {
type identityref {
base protection-states;
}
config false;
description
"Status of the protection in a group of interfaces
configured in a protection mode.";
reference
"ITU-T G.808.1";
}
action manual-switch-working {
description
"A switch action initiated by an operator command.
It switches a normal traffic signal to the working
transport entity.";
reference
"ITU-T G.808.1";
}
action manual-switch-protection {
description
"A switch action initiated by an operator command.
It switches a normal traffic signal to the protection
transport entity.";
reference
"ITU-T G.808.1";
}
action forced-switch {
description
"A switch action initiated by an operator command.
It switches a normal traffic signal to the protection
transport entity and forces it to remain on that
entity even when criteria for switching back to
the original entity are fulfilled.";
reference
"ITU-T G.808.1";
}
action lockout-of-protection {
description
"A switch action temporarily disables access to the
protection transport entity for all signals.";
reference
"ITU-T G.808.1";
}
action freeze {
description
"A switch action temporarily prevents any switch action
to be taken and, as such, freezes the current state.
Until the freeze is cleared, additional near-end external
commands are rejected, and fault condition changes and
received Automatic Protection-Switching (APS) messages
are ignored.";
reference
"ITU-T G.808.1";
}
action exercise {
description
"A switch action to test if the APS communication is
operating correctly. It is lower priority than any 'real'
switch request.";
reference
"ITU-T G.808.1";
}
action clear {
description
"An action clears all switch commands.";
reference
"ITU-T G.808.1";
}
}
}
}
<CODE ENDS>
5. Microwave Types YANG Data Model π
okay so this section is the types module, and it's giving "shared toolbox" energy π§°β¨ it defines a bunch of common data types that other modules in the microwave area are supposed to import, so nobody has to reinvent the wheel. bestie, slay. π
Here's the vibe: it's a YANG module called ietf-microwave-types, and it's pinned to revision 2019-06-19. π
<CODE BEGINS> file "ietf-microwave-types@2019-06-19.yang"
module ietf-microwave-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-types";
prefix mw-types;
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"WG List: <mailto:ccamp@ietf.org>
Editors:
Jonas Ahlberg (jonas.ahlberg@ericsson.com)
Min Ye (amy.yemin@huawei.com)
Xi Li (Xi.Li@neclab.eu)
Daniela Spreafico (daniela.spreafico@nokia.com)
Marko Vaupotic (Marko.Vaupotic@aviatnet.com)";
description
"This module contains a collection of YANG data types
considered generally useful for microwave interfaces.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8561; see
the RFC itself for full legal notices.";
revision 2019-06-19 {
description
"Initial revision.";
reference
"RFC 8561: A YANG Data Model for Microwave Radio Link";
}
/*
* Radio-link-terminal mode identities
*/
identity rlt-mode {
description
"A description of the mode in which the radio link
terminal is configured. The format is X plus Y.
X represents the number of bonded carrier terminations.
Y represents the number of protecting carrier
terminations.";
}
identity one-plus-zero {
base rlt-mode;
description
"1 carrier termination only.";
}
identity one-plus-one {
base rlt-mode;
description
"1 carrier termination
and 1 protecting carrier termination.";
}
identity two-plus-zero {
base rlt-mode;
description
"2 bonded carrier terminations.";
}
/*
* Coding and modulation identities
*/
identity coding-modulation {
description
"The coding and modulation schemes.";
}
identity half-bpsk {
base coding-modulation;
description
"Half BPSK coding and modulation scheme.";
}
identity half-bpsk-strong {
base half-bpsk;
description
"Half BPSK strong coding and modulation scheme.";
}
identity half-bpsk-light {
base half-bpsk;
description
"Half BPSK light coding and modulation scheme.";
}
identity bpsk {
base coding-modulation;
description
"BPSK coding and modulation scheme.";
}
identity bpsk-strong {
base bpsk;
description
"BPSK strong coding and modulation scheme.";
}
identity bpsk-light {
base bpsk;
description
"BPSK light coding and modulation scheme.";
}
identity qpsk {
base coding-modulation;
description
"QPSK coding and modulation scheme.";
}
identity qam-4 {
base coding-modulation;
description
"4 QAM coding and modulation scheme.";
}
identity qam-4-strong {
base qam-4;
description
"4 QAM strong coding and modulation scheme.";
}
identity qam-4-light {
base qam-4;
description
"4 QAM light coding and modulation scheme.";
}
identity qam-16 {
base coding-modulation;
description
"16 QAM coding and modulation scheme.";
}
identity qam-16-strong {
base qam-16;
description
"16 QAM strong coding and modulation scheme.";
}
identity qam-16-light {
base qam-16;
description
"16 QAM light coding and modulation scheme.";
}
identity qam-32 {
base coding-modulation;
description
"32 QAM coding and modulation scheme.";
}
identity qam-32-strong {
base qam-32;
description
"32 QAM strong coding and modulation scheme.";
}
identity qam-32-light {
base qam-32;
description
"32 QAM light coding and modulation scheme.";
}
identity qam-64 {
base coding-modulation;
description
"64 QAM coding and modulation scheme.";
}
identity qam-64-strong {
base qam-64;
description
"64 QAM strong coding and modulation scheme.";
}
identity qam-64-light {
base qam-64;
description
"64 QAM light coding and modulation scheme.";
}
identity qam-128 {
base coding-modulation;
description
"128 QAM coding and modulation scheme.";
}
identity qam-128-strong {
base qam-128;
description
"128 QAM strong coding and modulation scheme.";
}
identity qam-128-light {
base qam-128;
description
"128 QAM light coding and modulation scheme.";
}
identity qam-256 {
base coding-modulation;
description
"256 QAM coding and modulation scheme.";
}
identity qam-256-strong {
base qam-256;
description
"256 QAM strong coding and modulation scheme.";
}
identity qam-256-light {
base qam-256;
description
"256 QAM light coding and modulation scheme.";
}
identity qam-512 {
base coding-modulation;
description
"512 QAM coding and modulation scheme.";
}
identity qam-512-strong {
base qam-512;
description
"512 QAM strong coding and modulation scheme.";
}
identity qam-512-light {
base qam-512;
description
"512 QAM light coding and modulation scheme.";
}
identity qam-1024 {
base coding-modulation;
description
"1024 QAM coding and modulation scheme.";
}
identity qam-1024-strong {
base qam-1024;
description
"1024 QAM strong coding and modulation scheme.";
}
identity qam-1024-light {
base qam-1024;
description
"1024 QAM light coding and modulation scheme.";
}
identity qam-2048 {
base coding-modulation;
description
"2048 QAM coding and modulation scheme.";
}
identity qam-2048-strong {
base qam-2048;
description
"2048 QAM strong coding and modulation scheme.";
}
identity qam-2048-light {
base qam-2048;
description
"2048 QAM light coding and modulation scheme.";
}
identity qam-4096 {
base coding-modulation;
description
"4096 QAM coding and modulation scheme.";
}
identity qam-4096-strong {
base qam-4096;
description
"4096 QAM strong coding and modulation scheme.";
}
identity qam-4096-light {
base qam-4096;
description
"4096 QAM light coding and modulation scheme.";
}
/*
* TDM-type identities
*/
identity tdm-type {
description
"A description of the type of TDM connection,
also indicating the supported capacity of the
connection.";
}
identity E1 {
base tdm-type;
description
"E1 connection, 2.048 Mbit/s.";
}
identity STM-1 {
base tdm-type;
description
"STM-1 connection, 155.52 Mbit/s.";
}
}
<CODE ENDS>
okay that's the whole types module, and honestly the structure is so clean πΈ every modulation family gets a base identity with strong and light variants hanging off it, so the whole thing is like a neat little family tree π³ and the TDM bit at the bottom is literally just two identities, E1 and STM-1, with their capacities written right in the descriptions π
next up is the good stuff, bestie π¦
6. Security Considerations π
okay bestie, security is where things get SERIOUS ππ₯. these YANG data models are built to be reached through network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040]. the bottom layer of NETCONF is the secure transport layer, and the one every implementation has to support is Secure Shell (SSH) [RFC6242]. the bottom layer of RESTCONF is HTTPS, and the mandatory-to-implement secure transport there is TLS [RFC8446]. π
the Network Configuration Access Control Model (NACM) [RFC8341] is how you lock things down π. it lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of the protocol operations and content available to them. main character gatekeeping energy π
a bunch of data nodes in these models are writable, creatable, and deletable (that's config true, which is the default) π. they might be sensitive or vulnerable depending on the network. writing to them without proper protection (think edit-config) can seriously mess with network operations π. here are the subtrees and data nodes, and why they're sensitive:
Interfaces of type microwaveRadioLinkTerminal:
/if:interfaces/if:interface/mode/if:interfaces/if:interface/carrier-terminations/if:interfaces/if:interface/rlp-groups/if:interfaces/if:interface/xpic-pairs/if:interfaces/if:interface/mimo-groups/if:interfaces/if:interface/tdm-connections
these nodes hold the configuration of the radio link terminal, and they have to match the configuration of the radio link terminal on the other side of the radio link π€. if someone gets unauthorized access, they could interrupt the ability to forward traffic. not it π
Interfaces of type microwaveCarrierTermination:
/if:interfaces/if:interface/carrier-id/if:interfaces/if:interface/tx-enabled/if:interfaces/if:interface/tx-frequency/if:interfaces/if:interface/rx-frequency/if:interfaces/if:interface/duplex-distance/if:interfaces/if:interface/channel-separation/if:interfaces/if:interface/rtpc/maximum-nominal-power/if:interfaces/if:interface/atpc/maximum-nominal-power/if:interfaces/if:interface/atpc/atpc-lower-threshold/if:interfaces/if:interface/atpc/atpc-upper-threshold/if:interfaces/if:interface/single/selected-cm/if:interfaces/if:interface/adaptive/selected-min-acm/if:interfaces/if:interface/adaptive/selected-max-acm/if:interfaces/if:interface/if-loop/if:interfaces/if:interface/rf-loop
these ones represent the configuration of the carrier termination, and they have to match the carrier termination on the other side of the carrier π. same deal: unauthorized access could interrupt the ability to forward traffic π«
Radio link protection:
/radio-link-protection-groups/protection-group
this node is the configuration of the protection of carrier terminations π‘οΈ. unauthorized access could interrupt traffic forwarding or take away the ability to perform a necessary protection switch. yikes π¬
XPIC:
/xpic-pairs
this node is the XPIC configuration of a pair of carriers. unauthorized access could interrupt the ability to forward traffic β¨
MIMO:
/mimo-groups
this node is the MIMO configuration of multiple carriers. unauthorized access could interrupt the ability to forward traffic π
some of the RPC operations in this model can also be sensitive or vulnerable depending on the network, so controlling access to them is super important π. here are the operations and why they're sensitive:
Radio link protection:
/radio-link-protection-groups/protection-group/manual-switch-working,
/radio-link-protection-groups/protection-group/
manual-switch-protection,
/radio-link-protection-groups/protection-group/forced-switch,
/radio-link-protection-groups/protection-group/lockout-of-protection,
/radio-link-protection-groups/protection-group/freeze,
/radio-link-protection-groups/protection-group/exercise, and
/radio-link-protection-groups/protection-group/clear
these represent actions that could affect the configuration of the protection of carrier terminations. unauthorized access could interrupt traffic forwarding or remove the ability to perform a necessary protection switch π¨
the security considerations of [RFC8343] also apply to this document. read those too, no skipping ππ«Ά
7. IANA Considerations π¦
IANA has assigned new URIs from the "IETF XML Registry" [RFC3688] as follows:
URI: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-interface-protection
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-microwave-types
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
IANA has also recorded YANG module names in the "YANG Module Names" registry [RFC6020] like this π:
Name: ietf-microwave-radio-link
Maintained by IANA?: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
Prefix: mrl
Reference: RFC 8561
Name: ietf-interface-protection
Maintained by IANA?: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-interface-protection
Prefix: ifprot
Reference: RFC 8561
Name: ietf-microwave-types
Maintained by IANA?: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-types
Prefix: mw-types
Reference: RFC 8561
and finally, IANA registered these ifTypes in "ifType definitions" under [IANA-SMI] π:
Decimal Name Description
------- ------------ -------------------------------
295 microwaveCarrierTermination air interface of a single
microwave carrier
296 microwaveRadioLinkTerminal radio link interface for one
or several aggregated microwave
carriers
8. References β¨
8.1. Normative References
Here are the normative references, all in one place for your reading list ππ:
[IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers
(MIB Module Registrations)",
<https://www.iana.org/assignments/smi-numbers>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014,
<https://www.rfc-editor.org/info/rfc7224>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References π
Okay bestie, these are the informative refs. They're the extra reading that backs up the whole spec, so no skipping π«Ά
[EN301129] ETSI, "Transmission and Multiplexing (TM); Digital Radio Relay Systems (DRRS); Synchronous Digital Hierarchy (SDH); System performance monitoring parameters of SDH DRRS", EN 301 129 V1.1.2, May 1999.
[EN302217-1] ETSI, "Fixed Radio Systems; Characteristics and requirements for point-to-point equipment and antennas; Part 1: Overview, common characteristics and system-dependent requirements", EN 302 217-1 V3.1.0, May 2017.
[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", EN 302 217-2 V3.1.1, May 2017.
[G.808.1] ITU-T, "SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS; Digital networks ; General aspects Generic protection switching ; Linear trail and subnetwork protection", ITU-T Recommendation G.808.1, May 2014.
[G.826] ITU-T, "SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS; Digital networks - Quality and availability targets; End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections", ITU-T Recommendation G.826, December 2002.
[MICROWAVE-RADIO-LINK] Ahlberg, J., Carlson, J., Lund, H., 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.
[ONF-model] ONF, "Microwave Information Model", 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.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, https://www.rfc-editor.org/info/rfc8340.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, https://www.rfc-editor.org/info/rfc8342.
[RFC8432] Ahlberg, J., Ed., Ye, M., Ed., Li, X., Contreras, LM., and CJ. Bernardos, "A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters", RFC 8432, DOI 10.17487/RFC8432, October 2018, https://www.rfc-editor.org/info/rfc8432.
[TR102311] ETSI, "Fixed Radio Systems; Point-to-point equipment; Specific aspects of the spatial frequency reuse method", ETSI TR 102 311 V1.2.1, November 2015.
Appendix A. Example: 1+0 and 2+0 Configuration Instances π§
Okay so this appendix is full of cute little examples π They use the YANG data model from this document to show 1+0 and 2+0 instances. Just a heads up: these examples are not meant to be a complete module for 1+0 and 2+0 configuration, so don't copy-paste them and expect the whole thing to work π
A.1. 1+0 Instance
/--------- Radio Link ---------\
Near End Far End
+---------------+ +---------------+
| Radio Link | | Radio Link |
| Terminal A | | Terminal B |
| | | |
| | | |
| +-----------+ | | +-----------+ |
| | | | Carrier A | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
| | 1 | | | | 1 | |
| +-----------+ | | +-----------+ |
| | | |
| | | |
+---------------+ +---------------+
\--- Microwave Node ---/ \--- Microwave Node ---/
Figure 1: 1+0 Example
Figure 1 shows a 1+0 example. The following instance shows the 1+0 configuration of the Near End node. π¦
"interface": [
{
"name": "RLT-A",
"description": "Radio Link Terminal A",
"type": "microwaveRadioLinkTerminal",
"id": "RLT-A",
"mode": "one-plus-zero",
"carrier-terminations": [
"RLT-A:CT-1"
],
"tdm-connections": [
"tdm-type": "E1",
"tdm-connections": "4"
]
},
{
"name": "RLT-A:CT-1",
"description": "Carrier Termination 1",
"type": "microwaveCarrierTermination",
"carrier-id": "A",
"tx-enabled": true,
"tx-frequency": 10728000,
"duplex-distance": 644000,
"channel-separation": 28000,
"polarization": not-specified,
"rtpc": {
"maximum-nominal-power": 20
},
"single": {
"selected-cm": "qam-512"
}
}
]
A.2. 2+0 Instance
Figure 2 shows a 2+0 example. πΈ
/--------- Radio Link ---------\
Near End Far End
+---------------+ +---------------+
| Radio Link | | Radio Link |
| Terminal A | | Terminal B |
| | | |
| | | |
| +-----------+ | | +-----------+ |
| | | | Carrier A | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
| | 1 | | | | 1 | |
| +-----------+ | | +-----------+ |
| | | |
| +-----------+ | | +-----------+ |
| | | | Carrier B | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
| | 2 | | | | 2 | |
| +-----------+ | | +-----------+ |
| | | |
+---------------+ +---------------+
\--- Microwave Node ---/ \--- Microwave Node ---/
Figure 2: 2+0 Example
The following instance shows the 2+0 configuration of the Near End node. β¨
"interface": [
{
"name": "RLT-A",
"description": "Radio Link Terminal A",
"type": "microwaveRadioLinkTerminal",
"id": "RLT-A",
"mode": "two-plus-zero",
"carrier-terminations": [
"RLT-A:CT-1",
"RLT-A:CT-2"
],
"tdm-connections": [
"tdm-type": "E1",
"tdm-connections": "4"
]
},
{
"name": "RLT-A:CT-1",
"description": "Carrier Termination 1",
"type": "microwaveCarrierTermination",
"carrier-id": "A",
"tx-enabled": true,
"tx-frequency": 10728000,
"duplex-distance": 644000,
"channel-separation": 28000,
"polarization": not-specified,
"rtpc": {
"maximum-nominal-power": 20
},
"single": {
"selected-cm": "qam-512"
}
},
{
"name": "RLT-A:CT-2",
"description": "Carrier Termination 2",
"type": "microwaveCarrierTermination",
"carrier-id": "B",
"tx-enabled": true,
"tx-oper-status": on,
"tx-frequency": 10618000,
"duplex-distance": 644000,
"channel-separation": 28000,
"polarization": not-specified,
"rtpc": {
"maximum-nominal-power": 20
},
"single": {
"selected-cm": "qam-512"
}
}
]
A.3. 2+0 XPIC Instance
The following instance shows the XPIC configuration of the Near End node. π
"interface": [
{
"name": "RLT-A",
"description": "Radio Link Terminal A",
"type": "microwaveRadioLinkTerminal",
"id": "RLT-A",
"mode": "two-plus-zero",
"carrier-terminations": [
"RLT-A:CT-1",
"RLT-A:CT-2"
],
"xpic-pairs": [
"RLT-A:CT-1",
"RLT-A:CT-2"
],
"tdm-connections": [
"tdm-type": "E1",
"tdm-connections": "4"
]
},
{
"name": "RLT-A:CT-1",
"description": "Carrier Termination 1",
"type": "microwaveCarrierTermination",
"carrier-id": "A",
"tx-enabled": true,
"tx-frequency": 10728000,
"duplex-distance": 644000,
"channel-separation": 28000,
"polarization": not-specified,
"rtpc": {
"maximum-nominal-power": 20
},
"single": {
"selected-cm": "qam-512"
}
},
{
"name": "RLT-A:CT-2",
"description": "Carrier Termination 2",
"type": "microwaveCarrierTermination",
"carrier-id": "B",
"tx-enabled": true,
"tx-oper-status": on,
"tx-frequency": 10618000,
"duplex-distance": 644000,
"channel-separation": 28000,
"polarization": not-specified,
"rtpc": {
"maximum-nominal-power": 20
},
"single": {
"selected-cm": "qam-512"
}
}
]
Contributors π«Ά
Big shoutout to these contributors, they really carried π
Koji Kawada
NEC Corporation
1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan
Email: k-kawada@ah.jp.nec.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Authors' Addresses π
And last but definitely not least, the authors π
Jonas Ahlberg
Ericsson AB
Lindholmspiren 11
Goteborg 417 56
Sweden
Email: jonas.ahlberg@ericsson.com
Min Ye
Huawei Technologies
No.1899, Xiyuan Avenue
Chengdu 611731
China
Email: amy.yemin@huawei.com
Xi Li
NEC Laboratories Europe
Kurfursten-Anlage 36
Heidelberg 69115
Germany
Email: Xi.Li@neclab.eu
Daniela Spreafico
Nokia - IT
Via Energy Park, 14
Vimercate (MI) 20871
Italy
Email: daniela.spreafico@nokia.com
Marko Vaupotic
Aviat Networks
Motnica 9
Trzin-Ljubljana 1236
Slovenia
Email: Marko.Vaupotic@Aviatnet.com
π¦ where this page comes from
- ietf: rfc8561 2019-06
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms