-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-ccamp-mw-topo-yang-11.xml
2750 lines (2718 loc) · 119 KB
/
draft-ietf-ccamp-mw-topo-yang-11.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.18 (Ruby 2.7.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ccamp-mw-topo-yang-11" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<front>
<title abbrev="Microwave Topology YANG Model">A YANG Data Model for Microwave Topology</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-mw-topo-yang-11"/>
<author fullname="Scott Mansfield" role="editor">
<organization>Ericsson Inc</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Jonas Ahlberg">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Lindholmspiren 11</street>
<city>Goteborg</city>
<code>417 56</code>
<country>Sweden</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Min Ye">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No.1899, Xiyuan Avenue</street>
<city>Chengdu</city>
<code>611731</code>
<country>China</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Xi Li">
<organization>NEC Laboratories Europe</organization>
<address>
<postal>
<street>Kurfursten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Daniela Spreafico">
<organization>Nokia - IT</organization>
<address>
<postal>
<street>Via Energy Park, 14</street>
<city>Vimercate (MI)</city>
<code>20871</code>
<country>Italy</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2024" month="February" day="28"/>
<area>Routing</area>
<workgroup>CCAMP Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines a YANG data model to describe microwave/millimeter radio links in a network topology.</t>
</abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang"/>.
Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-ccamp-mw-topo-yang/"/>.
</t>
<t>
Discussion of this document takes place on the
CCAMP Working Group mailing list (<eref target="mailto:[email protected]"/>),
which is archived at <eref target="https://datatracker.ietf.org/wg/ccamp/about/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ccamp/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang"/>.</t>
</note>
</front>
<middle>
<section anchor="introduction">
<name>Introduction</name>
<t>This document defines a YANG data model to describe topologies of microwave/millimeter wave (hereafter microwave is used to simplify the text). The YANG data model describes radio links, supporting carrier(s) and the associated termination points <xref target="RFC8561"/>. A carrier is a description of a link providing transport capacity over the air by a single carrier. It is typically defined by its transmitting and receiving frequencies. A radio link is a link providing the aggregated transport capacity of the supporting carriers in aggregated and/or protected configurations, which can be used to carry traffic on higher topology layers such as Ethernet and TDM. The model augments "YANG Data Model for Traffic Engineering (TE) Topologies" defined in <xref target="RFC8795"/>, which is based on "A YANG Data Model for Network Topologies" defined in <xref target="RFC8345"/>.</t>
<t>The microwave point-to-point radio technology provides connectivity on Layer 0 / Layer 1 (L0/L1) over a radio link between two termination points, using one or several supporting carriers in aggregated or protected configurations. That application of microwave technology cannot be used to perform cross-connection or switching of the traffic to create network connectivity across multiple microwave radio links. Instead, a payload of traffic on higher topology layers, normally Layer 2 (L2) Ethernet, is carried over the microwave radio link and when the microwave radio link is terminated at the endpoints, cross-connection and switching can be performed on that higher layer creating connectivity across multiple supporting microwave radio links.</t>
<t>The microwave topology model is expected to be used between a Provisioning Network Controller (PNC) and a Multi Domain Service Coordinator (MDSC) <xref target="RFC8453"/>. Examples of use cases that can be supported are:</t>
<ol spacing="normal" type="1"><li>
<t>Correlation between microwave radio links and the supported links on higher topology layers (e.g., an L2 Ethernet topology). This information can be used to understand how changes in the performance/status of a microwave radio link affect traffic on higher layers.</t>
</li>
<li>
<t>Propagation of relevant characteristics of a microwave radio link, such as bandwidth, to higher topology layers, where it could be used as a criterion when configuring and optimizing a path for a connection/service through the network end to end.</t>
</li>
<li>
<t>Optimization of the microwave radio link configurations on a network level, with the purpose to minimize overall interference and/or maximize the overall capacity provided by the links.</t>
</li>
</ol>
<section anchor="abbreviations">
<name>Abbreviations</name>
<t>The following abbreviations are used in this document:</t>
<t>CTP Carrier Termination Point</t>
<t>RLT Radio Link Terminal</t>
<t>RLTP Radio Link Termination Point</t>
</section>
<section anchor="tree-structure">
<name>Tree Structure</name>
<t>A simplified graphical representation of the data model is used in chapter 3.1 of this document. The meaning of the symbols in these diagrams is defined in <xref target="RFC8340"/>.</t>
</section>
<section anchor="prefixes-in-data-node-names">
<name>Prefixes in Data Node Names</name>
<t>In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in <xref target="tab-prefix"/>.</t>
<table anchor="tab-prefix">
<name>Prefixes for imported YANG modules</name>
<thead>
<tr>
<th align="left">Prefix</th>
<th align="left">YANG Module</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">mwt</td>
<td align="left">ietf-microwave-topology</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">nw</td>
<td align="left">ietf-network</td>
<td align="left">
<xref target="RFC8345"/></td>
</tr>
<tr>
<td align="left">nt</td>
<td align="left">ietf-network-topology</td>
<td align="left">
<xref target="RFC8345"/></td>
</tr>
<tr>
<td align="left">mw-types</td>
<td align="left">ietf-microwave-types</td>
<td align="left">
<xref target="RFC8561"/></td>
</tr>
<tr>
<td align="left">tet</td>
<td align="left">ietf-te-topology</td>
<td align="left">
<xref target="RFC8795"/></td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="microwave-topology-yang-data-model">
<name>Microwave Topology YANG Data Model</name>
<section anchor="yang-tree">
<name>YANG Tree</name>
<figure title="Microwave Topology Tree"><artwork><![CDATA[
module: ietf-microwave-topology
augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
+--rw mw-topology!
augment /nw:networks/nw:network/nw:node/tet:te
/tet:te-node-attributes:
+--rw mw-node!
augment /nw:networks/nw:network/nw:node/nt:termination-point
/tet:te:
+--rw mw-tp!
+--rw (mw-tp-option)?
+--:(microwave-rltp)
| +--rw microwave-rltp!
+--:(microwave-ctp)
+--rw microwave-ctp!
augment /nw:networks/nw:network/nt:link/tet:te
/tet:te-link-attributes:
+--rw mw-link!
+--rw (mw-link-option)
+--:(microwave-radio-link)
| +--rw microwave-radio-link!
| +--rw rlt-mode
| +--rw num-bonded-carriers uint32
| +--rw num-protecting-carriers uint32
+--:(microwave-carrier)
+--rw microwave-carrier!
+--rw tx-frequency? uint32
+--rw rx-frequency? uint32
+--rw channel-separation? uint32
+--ro actual-tx-cm? identityref
+--ro actual-snir? decimal64
+--ro actual-transmitted-level? decimal64
augment /nw:networks/nw:network/nt:link/tet:te
/tet:te-link-attributes/tet:max-link-bandwidth
/tet:te-bandwidth:
+--ro mw-bandwidth? uint64
]]></artwork></figure>
</section>
<section anchor="relationship-between-radio-links-and-carriers">
<name>Relationship between radio links and carriers</name>
<t>A microwave radio link is always an aggregate of one or multiple carriers, in various configurations/modes. The supporting carriers are identified by their termination points and are listed in the container bundled-links as part of the te-link-config in the YANG Data Model for Traffic Engineering (TE) Topologies <xref target="RFC8795"/> for a radio-link. The exact configuration of the included carriers is further specified in the rlt-mode container (1+0, 2+0, 1+1, etc.) for the radio-link. Appendix A includes JSON examples of how such a relationship can be modelled.</t>
</section>
<section anchor="relationship-with-client-topology-model">
<name>Relationship with client topology model</name>
<t>A microwave radio link carries a payload of traffic on higher topology layers, normally L2 Ethernet. The leafs supporting-network, supporting-node, supporting-link, and supporting-termination-point in the generic YANG module for Network Topologies <xref target="RFC8345"/> are expected to be used to model a relationship/dependency from higher topology layers to a supporting microwave radio link topology layer. Appendix A includes JSON examples of an L2 Ethernet link transported over one supporting microwave link.</t>
</section>
<section anchor="applicability-of-the-data-model-for-traffic-engineering-te-topologies">
<name>Applicability of the Data Model for Traffic Engineering (TE) Topologies</name>
<t>Since microwave is a point-to-point radio technology, a majority of the leafs in the Data Model for Traffic Engineering (TE) Topologies augmented by the microwave topology model are not applicable. An example of which leafs are considered applicable can be found in appendices <xref target="examples-mw-only"/> and <xref target="examples-mw-imports"/> in this document.</t>
<t>More specifically in the context of the microwave-specific augmentations of te-topology, admin-status and oper-status leafs (from te-topology) are only applicable to microwave carriers (in the mw-link tree) and not microwave radio links. Enable and disable of a radio link is instead done in the constituent carriers. Furthermore the status leafs related to mw-tp can be used when links are inter-domain and when the status of only one side of the link is known, but since microwave is a point-to-point technology where both ends normally belong to the same domain it is not expected to be applicable in normal cases.</t>
</section>
<section anchor="microwave-topology-yang-module">
<name>Microwave Topology YANG Module</name>
<t>This module imports typedefs and modules from <xref target="RFC8345"/>, <xref target="RFC8561"/>, and <xref target="RFC8795"/>, and it references <xref target="EN301129"/> and <xref target="EN302217-1"/>.</t>
<sourcecode type="yang" markers="true" name="[email protected]"><![CDATA[
module ietf-microwave-topology {
yang-version "1.1";
namespace
"urn:ietf:params:xml:ns:yang:ietf-microwave-topology";
prefix "mwt";
import ietf-network {
prefix "nw";
reference "RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix "nt";
reference "RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-te-topology {
prefix "tet";
reference "RFC 8795: YANG Data Model for Traffic Engineering
(TE) Topologies";
}
import ietf-microwave-types {
prefix mw-types;
reference "RFC 8561";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
WG List: <mailto:[email protected]>
Editor: Jonas Ahlberg
<mailto:[email protected]>
Editor: Scott Mansfield
<mailto:[email protected]>
Editor: Min Ye
<mailto:[email protected]>
Editor: Italo Busi
<mailto:[email protected]>
Editor: Xi Li
<mailto:[email protected]>
Editor: Daniela Spreafico
<mailto:[email protected]>
";
description
"This is a module for microwave topology.
Copyright (c) 2024 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 Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2024-01-19 {
description
"AD comment resolutions.";
reference "";
}
grouping rlt-mode {
description
"This grouping provides a flexible definition of number
of bonded carriers and protecting carriers of a radio
link.";
leaf num-bonded-carriers {
type uint32;
mandatory true;
description
"Number of bonded carriers.";
}
leaf num-protecting-carriers {
type uint32;
mandatory true;
description
"Number of protecting carriers.";
}
}
grouping microwave-radio-link-attributes {
description "Grouping used for attributes describing a microwave
radio link.";
container rlt-mode {
description
"This grouping provides a flexible definition of number
of bonded carriers and protecting carriers of a radio
link.";
uses rlt-mode;
}
}
grouping microwave-carrier-attributes {
description "Grouping used for attributes describing a microwave
carrier.";
leaf tx-frequency {
type uint32;
units "kHz";
description
"Selected transmitter frequency.
Related to the data node tx-frequency in RFC 8561.";
reference
"RFC 8561: A YANG Data Model for Microwave Radio Link";
}
leaf rx-frequency {
type uint32;
units "kHz";
description
"Selected receiver frequency.
Related to the data node actual-rx-frequency in RFC 8561.";
reference
"RFC 8561: A YANG Data Model for Microwave Radio Link";
}
leaf channel-separation {
type uint32;
units "kHz";
description
"The amount of bandwidth allocated to a carrier. The
distance between adjacent channels in a radio
frequency channels arrangement.
Related to the data node channel-separation in RFC 8561.";
reference
"ETSI EN 302 217-1 and
RFC 8561: A YANG Data Model for Microwave Radio Link";
}
leaf actual-tx-cm {
type identityref {
base mw-types:coding-modulation;
}
config false;
description
"Actual coding/modulation in transmitting direction.
Related to the data node actual-tx-cm in RFC 8561.";
reference
"RFC 8561: A YANG Data Model for Microwave Radio Link";
}
leaf actual-snir {
type decimal64 {
fraction-digits 1;
}
units "dB";
config false;
description
"Actual signal to noise plus the interference ratio
(0.1 dB resolution).
Related to the data node actual-snir in RFC 8561.";
reference
"RFC 8561: A YANG Data Model for Microwave Radio Link";
}
leaf actual-transmitted-level {
type decimal64 {
fraction-digits 1;
}
units "dBm";
config false;
description
"Actual transmitted power level (0.1 dBm resolution).
Related to the data node actual-transmitted-level
in RFC 8561.";
reference
"ETSI EN 301 129 and
RFC 8561: A YANG Data Model for Microwave Radio Link";
}
}
grouping microwave-bandwidth {
description "Grouping used for microwave bandwidth.";
leaf mw-bandwidth {
type uint64;
units "bits/seconds";
config false;
description
"Nominal microwave radio link and carrier bandwidth.";
}
}
augment "/nw:networks/nw:network/nw:network-types/"
+ "tet:te-topology" {
description
"Augment network types to define a microwave network
topology type.";
container mw-topology {
presence "Indicates a topology type of microwave.";
description "Microwave topology type";
}
}
augment "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes" {
when "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology/mwt:mw-topology" {
description
"Augmentation parameters apply only for networks with a
microwave network topology type.";
}
description
"Augment network node to indicate a microwave node.";
container mw-node {
presence "Indicates a microwave node.";
description "Microwave node";
}
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point/"
+ "tet:te" {
when '../../../nw:network-types/tet:te-topology/'
+ 'mwt:mw-topology' {
description
"Augmentation parameters apply only for networks with a
microwave network topology type.";
}
description
"Augmentation to add microwave technology specific
characteristics to a termination point.";
container mw-tp {
presence
"Denotes a microwave termination point.";
description "Specification of type of termination point.";
choice mw-tp-option {
description "Selection of type of termination point.";
case microwave-rltp {
container "microwave-rltp" {
presence
"Denotes a microwave radio link termination point.
It corresponds to a microwave RLT interface as
defined in RFC 8561.";
description
"Denotes and describes a microwave radio link
termination point.";
}
}
case microwave-ctp {
container "microwave-ctp" {
presence
"Denotes a microwave carrier termination point.
It corresponds to a microwave CT interface as
defined in RFC 8561.";
description
"Denotes and describes a microwave carrier
termination point.";
}
}
}
}
}
augment "/nw:networks/nw:network/nt:link/tet:te/"
+ "tet:te-link-attributes" {
when '../../../nw:network-types/tet:te-topology/'
+ 'mwt:mw-topology' {
description
"Augmentation parameters apply only for networks with a
microwave network topology type.";
}
description
"Augmentation to add microwave technology specific
characteristics to a link.";
container mw-link {
presence "This indicates a microwave link";
description "Specification of type of link.";
choice mw-link-option {
mandatory true;
description "Selection of type of link.";
case microwave-radio-link {
container "microwave-radio-link" {
presence
"Denotes a microwave radio link";
uses microwave-radio-link-attributes;
description
"Denotes and describes a microwave radio link";
}
}
case microwave-carrier {
container "microwave-carrier" {
presence "Denotes a microwave carrier";
uses microwave-carrier-attributes;
description "Denotes and describes a microwave carrier";
}
}
}
}
}
augment "/nw:networks/nw:network/nt:link/tet:te/"
+ "tet:te-link-attributes/"
+ "tet:max-link-bandwidth/"
+ "tet:te-bandwidth" {
when '../../../../../nw:network-types/tet:te-topology/'
+ 'mwt:mw-topology' {
description
"Augmentation parameters apply only for networks with a
microwave network topology type.";
}
description
"Augmentation for TE bandwidth.";
uses microwave-bandwidth;
}
}
]]></sourcecode>
</section>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>The YANG module specified in this document defines schemas for data
that is designed to be accessed via network management protocols such
as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) <xref target="RFC6242"/>. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
<xref target="RFC8446"/>.</t>
<t>The NETCONF access control model <xref target="RFC8341"/> provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.</t>
<t>The YANG module specified in this document imports and augments the
ietf-network and ietf-network-topology models defined in <xref target="RFC8345"/>.
The security considerations from <xref target="RFC8345"/> are applicable to the
module in this document.</t>
<t>There are a several data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes can be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:</t>
<ul spacing="normal">
<li>
<t>rlt-mode: A malicious client could attempt to modify the mode in
which the radio link is configured and thereby change the
intended behavior of the link.</t>
</li>
<li>
<t>tx-frequency, rx-frequency and channel-separation: A malicious
client could attempt to modify the frequency configuration of
a carrier which could modify the intended behavior or make
the configuration invalid and thereby stop the operation of it.</t>
</li>
</ul>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>IANA is asked to assign a new URI from the "IETF XML Registry" <xref target="RFC3688"/> as follows:</t>
<artwork><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-microwave-topology
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
]]></artwork>
<t>It is proposed that IANA record the YANG module names in the "YANG
Module Names" registry <xref target="RFC6020"/> as follows:</t>
<artwork><![CDATA[
Name: ietf-microwave-topology
Maintained by IANA?: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-topology
Prefix: mwt
Reference: RFC XXXX
]]></artwork>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="RFC8561">
<front>
<title>A YANG Data Model for Microwave Radio Link</title>
<author fullname="J. Ahlberg" initials="J." surname="Ahlberg"/>
<author fullname="M. Ye" initials="M." surname="Ye"/>
<author fullname="X. Li" initials="X." surname="Li"/>
<author fullname="D. Spreafico" initials="D." surname="Spreafico"/>
<author fullname="M. Vaupotic" initials="M." surname="Vaupotic"/>
<date month="June" year="2019"/>
<abstract>
<t>This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8561"/>
<seriesInfo name="DOI" value="10.17487/RFC8561"/>
</reference>
<reference anchor="RFC8795">
<front>
<title>YANG Data Model for Traffic Engineering (TE) Topologies</title>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<author fullname="I. Bryskin" initials="I." surname="Bryskin"/>
<author fullname="V. Beeram" initials="V." surname="Beeram"/>
<author fullname="T. Saad" initials="T." surname="Saad"/>
<author fullname="H. Shah" initials="H." surname="Shah"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
<date month="August" year="2020"/>
<abstract>
<t>This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8795"/>
<seriesInfo name="DOI" value="10.17487/RFC8795"/>
</reference>
<reference anchor="RFC8345">
<front>
<title>A YANG Data Model for Network Topologies</title>
<author fullname="A. Clemm" initials="A." surname="Clemm"/>
<author fullname="J. Medved" initials="J." surname="Medved"/>
<author fullname="R. Varga" initials="R." surname="Varga"/>
<author fullname="N. Bahadur" initials="N." surname="Bahadur"/>
<author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<date month="March" year="2018"/>
<abstract>
<t>This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8345"/>
<seriesInfo name="DOI" value="10.17487/RFC8345"/>
</reference>
<reference anchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
<author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
<date month="June" year="2011"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC8040">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<date month="January" year="2017"/>
<abstract>
<t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC6242">
<front>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
<author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
<date month="June" year="2011"/>
<abstract>
<t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6242"/>
<seriesInfo name="DOI" value="10.17487/RFC6242"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8341">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="January" year="2004"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
<date month="October" year="2010"/>
<abstract>
<t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
</references>
<references>
<name>Informative References</name>
<reference anchor="EN301129">
<front>
<title>Transmission and Multiplexing (TM); Digital Radio Relay Systems (DRRS); Synchronous Digital Hierarchy (SDH); System performance monitoring parameters of SDH DRRS</title>
<author>
<organization>ETSI</organization>
</author>
<date year="1999" month="May"/>
</front>
<seriesInfo name="EN 301 129 V1.1.2" value=""/>
</reference>
<reference anchor="EN302217-1">
<front>
<title>Fixed Radio Systems; Characteristics and requirements for point-to-point equipment and antennas; Part 1: Overview, common characteristics and system- dependent requirements</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2017" month="May"/>
</front>
<seriesInfo name="EN 302 217-1 V3.1.0" value=""/>
</reference>
<reference anchor="RFC8453">
<front>
<title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
<author fullname="D. Ceccarelli" initials="D." role="editor" surname="Ceccarelli"/>
<author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
<date month="August" year="2018"/>
<abstract>
<t>Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.</t>
<t>Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.</t>
<t>This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8453"/>
<seriesInfo name="DOI" value="10.17487/RFC8453"/>
</reference>
<reference anchor="RFC8340">
<front>
<title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
<date month="March" year="2018"/>
<abstract>
<t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="I-D.draft-ietf-ccamp-if-ref-topo-yang">
<front>
<title>A YANG Data Model for Interface Reference Topology</title>
<author fullname="Jonas Ahlberg" initials="J." surname="Ahlberg">
<organization>Ericsson AB</organization>
</author>
<author fullname="Scott Mansfield" initials="S." surname="Mansfield">
<organization>Ericsson Inc</organization>
</author>
<author fullname="Min Ye" initials="M." surname="Ye">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Italo Busi" initials="I." surname="Busi">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Xi Li" initials="X." surname="Li">
<organization>NEC Laboratories Europe</organization>
</author>
<author fullname="Daniela Spreafico" initials="D." surname="Spreafico">
<organization>Nokia - IT</organization>
</author>
<date day="18" month="October" year="2023"/>
<abstract>
<t> This document defines a YANG data model to provide a reference from a
termination point in a topology model to interface management
information.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-if-ref-topo-yang-01"/>
</reference>
<reference anchor="I-D.draft-ietf-ccamp-bwa-topo-yang">
<front>
<title>A YANG Data Model for Bandwidth Availability Topology</title>
<author fullname="Jonas Ahlberg" initials="J." surname="Ahlberg">
<organization>Ericsson AB</organization>
</author>
<author fullname="Scott Mansfield" initials="S." surname="Mansfield">
<organization>Ericsson Inc</organization>
</author>
<author fullname="Min Ye" initials="M." surname="Ye">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Italo Busi" initials="I." surname="Busi">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Xi Li" initials="X." surname="Li">
<organization>NEC Laboratories Europe</organization>
</author>
<author fullname="Daniela Spreafico" initials="D." surname="Spreafico">
<organization>Nokia - IT</organization>
</author>
<date day="18" month="October" year="2023"/>
<abstract>
<t> This document defines a YANG data model to describe bandwidth
availability for a link in a network topology.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-bwa-topo-yang-01"/>
</reference>
<reference anchor="RFC8792">
<front>
<title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<date month="June" year="2020"/>
<abstract>
<t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8792"/>
<seriesInfo name="DOI" value="10.17487/RFC8792"/>
</reference>
<reference anchor="RFC8944">
<front>
<title>A YANG Data Model for Layer 2 Network Topologies</title>
<author fullname="J. Dong" initials="J." surname="Dong"/>
<author fullname="X. Wei" initials="X." surname="Wei"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
<author fullname="A. Liu" initials="A." surname="Liu"/>
<date month="November" year="2020"/>
<abstract>
<t>This document defines a YANG data model for Layer 2 network topologies. In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8944"/>
<seriesInfo name="DOI" value="10.17487/RFC8944"/>
</reference>
</references>
</references>
<section anchor="examples-mw-only">
<name>Microwave Topology Model with base topology models</name>
<t>This appendix provides some examples and illustrations of how the Microwave Topology Model can be used. The tree illustrates an example of a complete Microwave Topology Model including the relevant data nodes from network-topology and te-topology (base topology models). There are also JSON based instantiations of the Microwave Topology Model for a couple of small network examples.</t>
<t>The tree below shows an example of the relevant leafs for a complete Microwave Topology Model including the augmented Network Topology Model defined in <xref target="RFC8345"/> and the Traffic Engineering (TE) Topologies model defined in <xref target="RFC8795"/>.</t>
<figure title="Microwave Topology with Augmentations Tree"><artwork><![CDATA[
module: ietf-network
+--rw networks
+--rw network* [network-id]
| +--rw network-id network-id
| +--rw network-types
| | +--rw tet:te-topology!
| | +--rw mwt:mw-topology!
| +--rw supporting-network* [network-ref]
| | +--rw network-ref -> /networks/network/network-id
| +--rw node* [node-id]
| | +--rw node-id node-id
| | +--rw supporting-node* [network-ref node-ref]
| | | +--rw network-ref
| | | | -> ../../../supporting-network/network-ref
| | | +--rw node-ref -> /networks/network/node/node-id
| | +--rw nt:termination-point* [tp-id]
| | | +--rw nt:tp-id tp-id
| | | +--rw nt:supporting-termination-point*
| | | | [network-ref node-ref tp-ref]
| | | | +--rw nt:network-ref
| | | | | -> ../../../nw:supporting-node/network-ref
| | | | +--rw nt:node-ref
| | | | | -> ../../../nw:supporting-node/node-ref
| | | | +--rw nt:tp-ref leafref
| | | +--rw tet:te-tp-id?
| | | | te-types:te-tp-id
| | | +--rw tet:te!
| | | +--rw tet:name? string
| | | +--ro tet:geolocation
| | | | +--ro tet:altitude? int64
| | | | +--ro tet:latitude?
| | | | | geographic-coordinate-degree
| | | | +--ro tet:longitude?
| | | | geographic-coordinate-degree
| | | +--rw mwt:mw-tp!
| | | +--rw (mwt:mw-tp-option)?
| | | +--:(mwt:microwave-rltp)
| | | | +--rw mwt:microwave-rltp!
| | | +--:(mwt:microwave-ctp)
| | | +--rw mwt:microwave-ctp!
| | +--rw tet:te-node-id? te-types:te-node-id
| +--rw nt:link* [link-id]
| | +--rw nt:link-id link-id
| | +--rw nt:source
| | | +--rw nt:source-node? -> ../../../nw:node/node-id
| | | +--rw nt:source-tp? leafref
| | +--rw nt:destination
| | | +--rw nt:dest-node? -> ../../../nw:node/node-id
| | | +--rw nt:dest-tp? leafref
| | +--rw nt:supporting-link* [network-ref link-ref]
| | | +--rw nt:network-ref
| | | | -> ../../../nw:supporting-network/network-ref
| | | +--rw nt:link-ref leafref
| | +--rw tet:te!
| | +--rw (tet:bundle-stack-level)?
| | | +--:(tet:bundle)
| | | | +--rw tet:bundled-links
| | | | +--rw tet:bundled-link* [sequence]
| | | | +--rw tet:sequence uint32
| | | | +--rw tet:src-tp-ref? leafref
| | | | +--rw tet:des-tp-ref? leafref
| | +--rw tet:te-link-attributes
| | | +--rw tet:name? string
| | | +--rw tet:max-link-bandwidth
| | | | +--rw tet:te-bandwidth
| | | | +--ro mwt:mw-bandwidth? uint64
| | | +--rw mwt:mw-link!
| | | +--rw (mwt:mw-link-option)
| | | +--:(mwt:microwave-radio-link)
| | | | +--rw mwt:microwave-radio-link!
| | | | +--rw mwt:rlt-mode
| | | | +--rw mwt:num-bonded-carriers
| | | | | uint32
| | | | +--rw mwt:num-protecting-carriers
| | | | uint32
| | | +--:(mwt:microwave-carrier)
| | | +--rw mwt:microwave-carrier!
| | | +--rw mwt:tx-frequency?
| | | | uint32
| | | +--rw mwt:rx-frequency?
| | | | uint32
| | | +--rw mwt:channel-separation?
| | | | uint32
| | | +--ro mwt:actual-tx-cm?
| | | | identityref
| | | +--ro mwt:actual-snir?
| | | | decimal64
| | | +--ro mwt:actual-transmitted-level?
| | | decimal64
]]></artwork></figure>
<t>The Microwave Topology Model augments the TE Topology Model.</t>
<figure anchor="fig-mw-model">
<name>Example for L2 over microwave</name>
<artset>
<artwork type="svg">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 640 480" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,384" fill="none" stroke="black"/>
<path d="M 24,48 L 24,96" fill="none" stroke="black"/>
<path d="M 24,144 L 24,192" fill="none" stroke="black"/>
<path d="M 24,240 L 24,288" fill="none" stroke="black"/>
<path d="M 24,320 L 24,368" fill="none" stroke="black"/>
<path d="M 112,48 L 112,96" fill="none" stroke="black"/>
<path d="M 112,144 L 112,192" fill="none" stroke="black"/>
<path d="M 112,240 L 112,288" fill="none" stroke="black"/>
<path d="M 112,320 L 112,368" fill="none" stroke="black"/>
<path d="M 128,32 L 128,72" fill="none" stroke="black"/>
<path d="M 128,88 L 128,168" fill="none" stroke="black"/>