-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-ccamp-yang-otn-slicing.xml
2194 lines (1942 loc) · 101 KB
/
draft-ietf-ccamp-yang-otn-slicing.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"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.19 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-ccamp-yang-otn-slicing-07" category="std">
<front>
<title abbrev="Framework and YANG of OTN Slices">Framework and Data Model for OTN Network Slicing</title>
<author initials="A." surname="Guo" fullname="Aihua Guo">
<organization>Futurewei Technologies</organization>
<address>
<email>aihuaguo.ietf@gmail.com</email>
</address>
</author>
<author initials="L.M." surname="Contreras" fullname="Luis M. Contreras">
<organization>Telefonica</organization>
<address>
<email>luismiguel.contrerasmurillo@telefonica.com</email>
</address>
</author>
<author initials="S." surname="Belotti" fullname="Sergio Belotti">
<organization>Nokia</organization>
<address>
<email>Sergio.belotti@nokia.com</email>
</address>
</author>
<author initials="R." surname="Rokui" fullname="Reza Rokui">
<organization>Ciena</organization>
<address>
<email>rrokui@ciena.com</email>
</address>
</author>
<author initials="Y." surname="Xu" fullname="Yunbin Xu">
<organization>CAICT</organization>
<address>
<email>xuyunbin@caict.ca.cn</email>
</address>
</author>
<author initials="Y." surname="Zhao" fullname="Yang Zhao">
<organization>China Mobile</organization>
<address>
<email>zhaoyangyjy@chinamobile.com</email>
</address>
</author>
<author initials="X." surname="Liu" fullname="Xufeng Liu">
<organization>Alef Edge</organization>
<address>
<email>xufeng.liu.ietf@gmail.com</email>
</address>
</author>
<date year="2024" month="June" day="26"/>
<workgroup>CCAMP Working Group</workgroup>
<abstract>
<t>The requirement of slicing network resources with desired quality of
service is emerging at every network technology, including the
Optical Transport Networks (OTN). As a part of the transport network,
OTN can provide hard pipes with guaranteed data isolation and
deterministic low latency, which are highly demanded in the Service
Level Agreement (SLA).</t>
<t>This document describes a framework for OTN network slicing and defines
YANG data models with OTN technology-specific augments deployed at both
the north and south bound of the OTN network slice controller. Additional
YANG data model augmentations will be defined in a future version of
this draft.</t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name>
<t>The requirement of slicing network resources with desired quality of
service is emerging at every network technology, including the
Optical Transport Networks (OTN). As a part of the transport network,
OTN can provide hard pipes with guaranteed data isolation and
deterministic low latency, which are highly demanded in the Service
Level Agreement (SLA).
This document describes a framework for OTN network slicing and defines
YANG data models with OTN technology-specific augments deployed at both
the north and south bound of the OTN network slice controller. Additional
YANG data model augmentations will be defined in a future version of
this draft.</t>
<section anchor="terminology"><name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
<t>The terminology for describing YANG data models is found in
<xref target="RFC7950"/>.</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-prefixes"/>.</t>
<texttable title="Prefixes and Corresponding YANG Modules" anchor="tab-prefixes">
<ttcol align='left'>Prefix</ttcol>
<ttcol align='left'>YANG Module</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>yang</c>
<c>ietf-yang-types</c>
<c><xref target="RFC6991"/></c>
<c>inet</c>
<c>ietf-inet-types</c>
<c><xref target="RFC6991"/></c>
<c>nt</c>
<c>ietf-network-topology</c>
<c><xref target="RFC8345"/></c>
<c>nw</c>
<c>ietf-network-topology</c>
<c><xref target="RFC8345"/></c>
<c>tet</c>
<c>ietf-te-topology</c>
<c><xref target="RFC8795"/></c>
<c>ietf-nss</c>
<c>ietf-network-slice-service</c>
<c>[RFCVVVV]</c>
<c>te-types</c>
<c>ietf-te-types</c>
<c>[RFCWWWW]</c>
<c>otnt</c>
<c>ietf-otn-topology</c>
<c>[RFCYYYY]</c>
<c>l1-types</c>
<c>ietf-layer1-types</c>
<c>[RFCZZZZ]</c>
<c>otns</c>
<c>ietf-otn-slice</c>
<c>[RFCXXXX]</c>
<c>otns-mpi</c>
<c>ietf-otn-slice-mpi</c>
<c>[RFCXXXX]</c>
</texttable>
<t>RFC Editor Note:
Please replace VVVV with the RFC number assigned to <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>.
Please replace WWWW with the RFC number assigned to <xref target="I-D.ietf-teas-rfc8776-update"/>.
Please replace XXXX with the RFC number assigned to this document.
Please replace YYYY with the RFC number assigned to <xref target="I-D.ietf-ccamp-otn-topo-yang"/>.
Please replace ZZZZ with the RFC number assigned to <xref target="I-D.ietf-ccamp-layer1-types"/>.
Please remove this note.</t>
</section>
<section anchor="definition-of-otn-slice"><name>Definition of OTN Slice</name>
<t>An OTN slice is an OTN virtual network topology connecting a number
of OTN endpoints using a set of shared or dedicated OTN network resources to
satisfy specific service level objectives (SLOs).</t>
<t>An OTN slice is a technology-specific realization of the RFC 9543 network slice service
<xref target="RFC9543"/> in the OTN domain, with the
capability of configuring slice resources in the term of OTN technologies.
Therefore, all the terms and definitions concerning network slicing as
defined in <xref target="RFC9543"/> apply to OTN slicing.</t>
<t>An OTN slice can span multiple OTN administrative domains, encompassing
access links, intra-domain paths, and inter-domain links.
An OTN slice may include multiple endpoints, each associated with a set of physical
or logical resources, e.g. optical port or time slots, at the termination point (TP) of
an access link or inter-domain link at an OTN provider edge (PE) equipment.</t>
<t>An end-to-end OTN slice may be composed of multiple OTN segment slices in
a hierarchical or sequential (or stitched) combination.</t>
<t><xref target="fig-otn-slice"/> illustrates the scope of OTN slices in multi-domain
environment.</t>
<figure title="OTN Slice" anchor="fig-otn-slice"><artwork><![CDATA[
<------------------End-to-end OTN Slice---------------->
<- OTN Segment Slice 1 ---> <-- OTN Segment Slice 2 -->
+-------------------------+ +-----------------------+
| +-----+ +-------+ | | +-------+ +-----+|
+----+ | | OTN | | OTN | | | | OTN | | OTN || +----+
| CE +-+-o PE +-...--+ Borde o--+--+-o Borde +-...--+ PE o+--+ CE |
+----+||/| | | Node |\ || | | Node | | || |+----+
|||+-----+ +-------+| || | +-------+ +-----+| |
||| OTN Domain 1 | || | OTN Domain 2 | |
|++----------------------+-+| +-----------------------+ |
| | | | |
| +-----+ +-----------+ | |
| | | | |
V V V V V
Access OTN Slice Inter-domain Access
Link Endpoint Link Link
]]></artwork></figure>
<t>OTN slices may be pre-configured by the management plane and presented to
the customer via the northbound interface (NBI), or be dynamically
provisioned by a higher layer slice controller, e.g., an RFC 9543 network slice
controller (NSC) through the NBI. The OTN slice is
provided by a service provider to a customer to be used as though it was part
of the customer's own networks.</t>
</section>
</section>
<section anchor="use-cases-for-otn-network-slicing"><name>Use Cases for OTN Network Slicing</name>
<section anchor="leased-line-services-with-otn"><name>Leased Line Services with OTN</name>
<t>For end business customers (like OTT or enterprises), leased lines
have the advantage of providing high-speed connections with low
costs. On the other hand, the traffic control of leased lines is very
challenging due to rapid changes in service demands. Carriers are
recommended to provide network-level slicing capabilities to meet
this demand. Based on such capabilities, private network users have
full control over the sliced resources which have been allocated to them
and which could be used to support their leased lines, when needed.
Users may formulate policies based on the demand for services and
time to schedule the resources from the entire network's perspective
flexibly. For example, the bandwidth between any two points may be
established or released based on the time or monitored traffic
characteristics. The routing and bandwidth may be adjusted at a
specific time interval to maximize network resource utilization
efficiency.</t>
</section>
<section anchor="co-construction-and-sharing"><name>Co-construction and Sharing</name>
<t>Co-construction and sharing of a network are becoming a popular means
among service providers to reduce networking building CAPEX. For Co-
construction and sharing case, there are typically multiple co-
founders for the same network. For example, one founder may provide
optical fibres and another founder may provide OTN equipment, while
each occupies a certain percentage of the usage rights of the network
resources. In this scenario, the network O&M is performed by a
certain founder in each region, where the same founder usually
deploys an independent management and control system. The other
founders of the network use each other's management and control
system to provision services remotely. In this scenario, different
founders' network resources need to be automatically (associated)
divided, isolated, and visualized. All founders may share or have
independent O&M capabilities, and should be able to perform service-
level provisioning in their respective slices.</t>
</section>
<section anchor="wholesale-of-optical-resources"><name>Wholesale of optical resources</name>
<t>In the optical resource wholesale market, smaller, local carriers and
wireless carriers may rent resources from larger carriers, or
infrastructure carriers instead of building their networks. Likewise,
international carriers may rent resources from respective local
carriers and local carriers may lease their owned networks to each
other to achieve better network utilization efficiency.
From the perspective of a resource provider, it is crucial that a
network slice is timely configured to meet traffic matrix
requirements requested by its tenants. The support for multi-tenancy
within the resource provider's network demands that the network
slices are qualitatively isolated from each other to meet the
requirements for transparency, non-interference, and security.
Typically, a resource purchaser expects to use the leased network
resources flexibly, just like they are self-constructed. Therefore,
the purchaser is not only provided with a network slice, but also the
full set of functionalities for operating and maintaining the network
slice. The purchaser also expects to, flexibly and independently,
schedule and maintain physical resources to support their own
end-to-end automation using both leased and self-constructed network
resources.</t>
</section>
<section anchor="vertical-dedicated-network-with-otn"><name>Vertical dedicated network with OTN</name>
<t>Vertical industry slicing is an emerging category of network slicing
due to the high demand for private high-speed network interconnects
for industrial applications.
In this scenario, the biggest challenge is to implement
differentiated optical network slices based on the requirements from
different industries. For example, in the financial industry, to
support high-frequency transactions, the slice must ensure to provide
the minimum latency along with the mechanism for latency management.
For the healthcare industry, online diagnosis network and software
capabilities to ensure the delivery of HD video without frame loss.
For bulk data migration in data centers, the network needs to support
on-demand, large-bandwidth allocation. In each of the aforementioned
vertical industry scenarios, the bandwidth shall be adjusted as
required to ensure flexible and efficient network resource usage.</t>
</section>
<section anchor="end-to-end-network-slicing"><name>End-to-end network slicing</name>
<t>In an end-to-end network slicing scenario such as 5G network slicing
<xref target="TS.28.530-3GPP"/>, an RFC 9543 network slice <xref target="RFC9543"/>
provides the required connectivity between other different segments
of an end-to-end network slice, such as the Radio Access Network
(RAN) and the Core Network (CN) segments, with a specific
performance commitment. An RFC 9543 network slice could be composed of
network slices from multiple technological and administrative
domains. An RFC 9543 network slice can be realized by using or combining
multiple underlying OTN slices with OTN resources, e.g., ODU time
slots or ODU containers, to achieve end-to-end slicing across the transport
domain.</t>
</section>
</section>
<section anchor="framework-for-otn-slicing"><name>Framework for OTN slicing</name>
<t>OTN slices may be abstracted differently depending on the requirement contained
in the configuration provided by the slice customer. Whereas the customer requests
an OTN slice to provide connectivity between specified endpoints, an OTN slice
can be abstracted as a set of endpoint-to-endpoint links, with each link formed
by an end-to-end tunnel across the underlying OTN networks. The resources
associated with each link of the slice is reserved and commissioned in the underlying
physical network upon the completion of configuring the OTN slice and all the
links are active.</t>
<t>An OTN slice can also be abstracted as an abstract topology when the customer requests
the slice to share resources between multiple endpoints and to use the resources on demand.
The abstract topology may consist of virtual nodes and virtual links, and their associated
resources are reserved but not commissioned across the underlying OTN networks. The
customer can later commission resources within the slice dynamically using the NBI provided
by the service provider. An OTN slice could use abstract topology to connect endpoints with
shared resources to optimize the resource utilization, and connections can be activated
within the slice as needed.</t>
<t>It is worth noting that those means to abstract an OTN slice are similar to the Virtual
Network (VN) abstraction defined for higher-level interfaces in <xref target="RFC8453"/>, in which context
a connectivity-based slice corresponds to Type 1 VN and a resource-based slice corresponds to
Type 2 VN, respectively.</t>
<t>A particular resource in an OTN network, such as a port or link, may be
sliced with one of the two granularity levels:</t>
<t><list style="symbols">
<t>Link-based slicing, in which a link and its associated link
termination points (LTPs) are dedicatedly allocated to a
particular OTN slice.</t>
<t>Tributary-slot based slicing, in which multiple OTN slices
share the same link by allocating different OTN tributary slots in
different granularities.</t>
</list></t>
<t>Furthermore, an OTN switch is typically fully non-blocking switching
at the lowest ODU container granularity, it is
desirable to specify just the total number of ODU containers in the
lowest granularity (e.g. ODU0), when configuring tributary-slot based
slicing on links and ports internal to an OTN network. In multi-domain
OTN network scenarios where separate OTN slices are created on
each of the OTN networks and are stitched at inter-domain OTN links, it
is necessary to specify matching tributary slots at the endpoints of the
inter-domain links. In some real network scenarios, OTN network resources
including tributary slots are managed explicitly by network operators for
network maintenance considerations. Therefore, an OTN slice controller
shall support configuring an OTN slice with both options.</t>
<t>An OTN slice controller (OTN-SC) is a logical function responsible for
the life-cycle management of OTN slices instantiated within the
corresponding OTN network domains. The OTN-SC provides technology-specific
interfaces at its northbound (OTN-SC NBI) to allow a higher-layer slice
controller, such as an RFC 9543 network slice controller (NSC) or an orchestrator,
to request OTN slices with OTN-specific
requirements. The OTN-SC interfaces at the southbound using the MDSC-to-PNC
interface (MPI) with a Physical Network Controller (PNC) or Multi-Domain Service Orchestrator (MDSC),
as defined in the ACTN control framework <xref target="RFC8453"/>. The logical function
within the OTN-SC is responsible for translating the OTN slice requests
into concrete slice realization which can be understood and
provisioned at the southbound by the PNC or MDSC.</t>
<t>The presence of OTN-SC provides multiple options for a high-level slice controller
or an orchestrator to configure and realize slicing in OTN networks, depending on
whether a customer's slice request is technology agnostic or technology specific:</t>
<t>Option 1[opt.1]: An IETF NSC receives a technology-agnostic slice request from the IETF NSC NBI and
realizes full or part of the slice in OTN networks directly through MPI provided by
the PNC or MDSC. The IETF NSC is responsible for mapping a technology-agnostic slicing request
into an OTN technology-specific realization. In this option, the OTN-SC is not used.</t>
<t>Option 2[opt.2]: An IETF NSC receives a technology-agnostic slice request from the IETF NSC NBI and delegates the
request to the OTN-SC through the OTN-SC NBI, which is OTN technology specific. The OTN-SC in turn realizes the slice in single or multi domain OTN networks by working with the underlying PNC or MDSC. In this option, the OTN-SC is considered as a realization of IETF NSC, i.e.,
an NS realizer as per <xref target="I-D.draft-contreras-teas-slice-controller-models"/>,
when the underlying network is OTN. The OTN-SC is also a subordinate slice controller of the RFC 9543 NSC, which
is consistent with the hierarchical control of slices specified by <xref target="RFC9543"/>.</t>
<t>Option 3[opt.3]: An OTN-aware orchestrator may request an OTN technology-specific slice with OTN-specific SLOs through the
OTN-SC NBI to the OTN-SC. The OTN-SC in turn realizes the slice in single or multi domain OTN networks by working with the underlying PNC or MDSC</t>
<t>An OTN slice may be realized by using standard MPI interfaces, control plane, network management system (NMS) or any other proprietary interfaces as needed. Examples of such interfaces include the abstract TE topology <xref target="RFC8795"/>, TE tunnel <xref target="I-D.ietf-teas-yang-te"/>,L1VPN<xref target="RFC4847"/>, or Netconf/YANG based interfaces such as OpenConfig. Some of these interfaces, such as the TE tunnel model, are suitable for creating connectivity-based OTN slices which represent a slice as a set of TE tunnels, while other interfaces such as the TE topology model are more suitable for creating resource-based OTN slices which represent a slice as a topology.</t>
<t>The OTN-SC NBI is a technology-specific interface that augments the IETF NSC NBI, which is technology-
agnostic.</t>
<t><xref target="fig-slice-interfaces"/> illustrates the OTN slicing control hierarchy
, the positioning of the OTN slicing interfaces as well as the options for OTN slice configuration.</t>
<figure title="Positioning of OTN Slicing Interfaces" anchor="fig-slice-interfaces"><artwork><![CDATA[
+--------------------+
| Provider's User |
+--------|-----------+
| CMI
+-----------------------+--------------------------------+
| Orchestrator / E2E Slice Controller |
+------------+-----------------------------+-------------+
| | NSC-NBI
| +---------------------+-------------+
| | RFC 9543 Network Slice Controller |
| +-----+---------------+-------------+
| opt.3 | opt.2 | opt.1
| OTN-SC NBI |OTN-SC NBI |
+------------+-------------+--------+ |
| OTN-SC | |
+--------------------------+--------+ |
| MPI | MPI
+--------------------------+---------------+------------+
| PNC |
+--------------------------+----------------------------+
| SBI
+-----------+----------+
|OTN Physical Network |
+----------------------+
]]></artwork></figure>
<t>OTN-SC functionalities may be recursive such that a higher-level
OTN-SC may designate the creation of OTN slices to a lower-level
OTN-SC in a recursive manner. This scenario may apply to the
creation of OTN slices in multi-domain OTN networks, where
multiple domain-wide OTN slices provisioned by lower-layer
OTN-SCs are stitched to support a multi-domain OTN slice
provisioned by the higher-level OTN-SC. Alternatively, the OTN-SC
may interface with an MDSC, which in turn interfaces with multiple
PNCs through the MPI to realize OTN slices in multi-domain OTN networks
without OTN-SC recursion.
<xref target="fig-otn-sc-recursion"/> illustrates both options for OTN slicing
in multi-domain.</t>
<figure title="OTN-SC for multi-domain" anchor="fig-otn-sc-recursion"><artwork><![CDATA[
+-------------------+ +-------------------+
| OTN-SC | | OTN-SC |
+--------|----------+ +---|----------|----+
|MPI |OTN-SC NBI|
+--------|----------+ +---|----+ +---|----+
| MDSC | | OTN-SC | | OTN-SC |
+---|----------|----+ +---|----+ +---|----+
|MPI |MPI |MPI |MPI
+---|----+ +---|----+ +---|----+ +---|----+
| PNC | | PNC | | PNC | | PNC |
+--------+ +--------+ +--------+ +--------+
Multi-domain Option 1 Multi-domain Option 2
]]></artwork></figure>
<t>OTN-SC functionalities are logically independent and may be deployed in
different combinations to cater to the realization needs. In reference to the
ACTN control framework <xref target="RFC8453"/>, an OTN-SC may be deployed</t>
<t><list style="symbols">
<t>as an independent network function;</t>
<t>together with a Physical Network Controller (PNC) for single-domain
or with a Multi-Domain Service Orchestrator (MDSC)for multi-domain;</t>
<t>together with a higher-level network slice controller to support
end-to-end network slicing;</t>
</list></t>
</section>
<section anchor="realizing-otn-slices"><name>Realizing OTN Slices</name>
<t><xref target="RFC9543"/> introduces a mechanism for an RFC 9543 network slice controller to realize network slices by constructing Network Resource Partitions (NRP). A NRP is a collection of resources identified in the underlay network to facilitate the mapping of network slices onto available network resources. An NRP is a scope view of a topology and may be considered as a topology in its own right. Thus, in traffic-engineered (TE) networks including OTN, an NRP may be simply represented as an abstract TE topology defined by <xref target="RFC8795"/>. For OTN networks, An NRP may be represented as an abstract OTN topology defined by <xref target="I-D.ietf-ccamp-otn-topo-yang"/>.</t>
<t>The NRP may be used to address the scalability issues where there may be considerable numbers of control and data plane states required to be stored and programmed if network slices are mapped directly to the underlay topology. NRP is internal to a network slice controller, and use of NRPs is optional yet could benefit a network slice realization in large-scale networks, including OTN networks.</t>
<t>For connectivity-based OTN slices, a connection within an OTN slice is typically realized by an OTN tunnel in the underlay topology and resources are reserved by the tunnel, thus use of NRP is optional in this case.</t>
<t>For resource-based OTN slices, the OTN-SC may map an OTN slice directly onto the underlay TE topology presented by the subtended network controller (MDSC or PNC) without creating NRP topologies. Due to the need for reserving resources, the OTN-SC needs to color corresponding link resources of the underlay topology with a slice identifier and maintain the coloring to keep track of the mapping of OTN slices. The OTN-SC may push the colored topology to the subtended MDSC or PNC using the MPI model defined in this draft.</t>
<t>Alternatively, an OTN slice may be mapped to a NRP as an overlay abstract OTN TE topology on top of the underlay topology. The corresponding link resources allocated to the slice is encapsulated in and tracked by the abstract topology, and a given link or port in the NRP topology represents resources that are reserved in the underlay topology. Multiple OTN slices may be mapped to the same NRP, and a single connectivity construct of the slice may be mapped to only one NRP, as per <xref target="RFC9543"/>. The resources of an NRP topology are reserved and shared by all the OTN slices mapped to this NRP, and the NRP topology may be pushed directly to the subtended MDSC or PNC, thus eliminating the need for link coloring if using the underlay topology.</t>
<t><xref target="fig-otn-sc-nrp"/> illustrates the relationship between OTN slices and NRP.</t>
<figure title="Mapping OTN Slices to NRP" anchor="fig-otn-sc-nrp"><artwork><![CDATA[
/---------------/ | /---------------/
/ -- -- / | / -- -- /
/ |N1|---|N3| /---/ | / |N2| |N3| /
/ --\ -- / / | / -- -- /
/ \-- / / | / \ --/ /
/ |N2| / / | / |N4| /
/ Slice 1 -- / / | / Slice 2 -- /
/------------<--/ / | /-----------<---/
/ Slice 3 < / | <
/--------- <-<--/ | <
+-------------<-<--------------V-----------------<------------+
| /--<-<------------/ /-----<-----------/|
| / /--\ /--\ / / /--\ / |
| / |NE1 |---|NE2 | / / |NE2 | / |
| / \--/\ . \--/ / / \--/ / |
| / ..\ ........ / /. / |
| / . /--\ / . / /--\ /--\/ ./ |
| / .|NE4 | / . / |NE3 |---|NE4 | . |
| / . \--/ / . / \--/ . \--/ /. |
| / NRP Topology 1 / . / NRP Topology 2 / . |
| /------------.----/ . /-----------.-----/ . |
| ....... . . . |
| /------.----.-----------------/ . . |
| / /--\ . . /--\ / . . |
| / |NE1 |-.----v----|NE2 | / . . |
| / ---/\ . /\--/ / . . |
| / / \v /<........................ |
| / /-/\ \ /--\ / / . |
| / |NE3 |------|NE4 |/ / . |
| / \--/ ^ \--/ / . |
| / Underlay.OTN TE Topology / . |
| /-----------.-----------------/ . |
| .............................. OTN-SC |
+-------------------------------------------------------------+
| ^
|MPI |MPI
+----------------V--------------------------------------------+
| |
| OTN MDSC/PNC |
+-------------------------------------------------------------+
]]></artwork></figure>
</section>
<section anchor="yang-data-model-for-otn-slicing-configuration"><name>YANG Data Model for OTN Slicing Configuration</name>
<section anchor="otn-slicing-yang-model-for-mpi"><name>OTN Slicing YANG Model for MPI</name>
<section anchor="mpi-yang-model-overview"><name>MPI YANG Model Overview</name>
<t>For the configuration of connectivity-based OTN slices, existing models such as
the TE tunnel interface <xref target="I-D.ietf-teas-yang-te"/> may be used and no addition is
needed. This model is addressing the case for configuring resource-based OTN slices,
where the model permits to reserve resources exploiting the common knowledge of an underlying
virtual topology between the OTN-SC and the subtended network controller (MDSC or PNC). The slice
is configured by marking corresponding link resources on the TE topology received from the
underlying MDSC or PNC with a slice identifier and OTN-specific resource requirements,
e.g. the number of ODU time slots or the type/number of ODU containers. The MDSC or PNC, based on the
marked resources by the OTN-SC, will update the underlying TE topology with new TE link for each of
the colored links to keep booked the reserved OTN resources e.g. time slots or ODU containers.</t>
</section>
<section anchor="mpi-yang-model-tree"><name>MPI YANG Model Tree</name>
<figure title="OTN slicing MPI tree diagram" anchor="fig-otn-slice-mpi-tree"><artwork><![CDATA[
module: ietf-otn-slice-mpi
augment /nw:networks/nw:network/nt:link/tet:te
/tet:te-link-attributes:
+--rw (otn-slice-granularity)?
+--:(link)
| +--rw slice-id? uint32
+--:(link-resource)
+--rw slices* [slice-id]
+--rw slice-id uint32
+--rw (technology)?
| +--:(otn)
| +--rw (slice-bandwidth)?
| +--:(containers)
| | +--rw odulist* [odu-type]
| | +--rw odu-type identityref
| | +--rw number? uint16
| +--:(time-slots)
| +--rw otn-ts-num? uint32
+--ro sliced-link-ref?
-> ../../../../../nt:link/link-id
]]></artwork></figure>
</section>
<section anchor="mpi-yang-code"><name>MPI YANG Code</name>
<figure title="OTN slicing MPI YANG model" anchor="fig-otn-slice-mpi-yang"><artwork><![CDATA[
<CODE BEGINS> file "ietf-otn-slice-mpi@2022-10-12.yang"
module ietf-otn-slice-mpi {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-otn-slice-mpi";
prefix "otns-mpi";
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
"RFC8795: YANG Data Model for Traffic Engineering
(TE) Topologies";
}
import ietf-otn-topology {
prefix "otnt";
reference
"I-D.ietf-ccamp-otn-topo-yang: A YANG Data Model
for Optical Transport Network Topology";
}
import ietf-layer1-types {
prefix "l1-types";
reference
"I-D.ietf-ccamp-layer1-types: A YANG Data Model
for Layer 1 Types";
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
Editor: Haomian Zheng
<mailto:zhenghaomian@huawei.com>
Editor: Italo Busi
<mailto:italo.busi@huawei.com>
Editor: Aihua Guo
<mailto:aihuaguo.ietf@gmail.com>
Editor: Sergio Belotti
<mailto:sergio.belotti@nokia.com>";
description
"This module defines a YANG data model for network slice
realization in Optical Transport Networks (OTN).
The model fully conforms to the Network Management Datastore
Architecture (NMDA).
Copyright (c) 2022 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 "2022-10-12" {
description
"Latest revision of MPI YANG model for OTN slicing.";
reference
"draft-ietf-ccamp-yang-otn-slicing-03: Framework and Data
Model for OTN Network Slicing";
}
/*
* Groupings
*/
grouping otn-link-slice-profile {
description
"Profile of an OTN link slice.";
choice otn-slice-granularity {
default "link";
description
"Link slice granularity.";
case link {
leaf slice-id {
type uint32;
description
"Slice identifier";
}
}
case link-resource {
list slices {
key slice-id;
description
"List of slices.";
leaf slice-id {
type uint32;
description
"Slice identifier";
}
choice technology {
description
"Data plane technology types.";
case otn {
choice slice-bandwidth {
description
"Bandwidth specification for OTN slices.";
case containers {
uses l1-types:otn-link-bandwidth;
}
case time-slots {
leaf otn-ts-num {
type uint32;
description
"Number of OTN tributary slots allocated
for the slice.";
}
}
}
}
}
leaf sliced-link-ref {
type leafref {
path "../../../../../nt:link/nt:link-id";
}
config false;
description
"Relative reference to virtual links generated from
this TE link.";
}
}
}
}
}
/*
* Augments
*/
augment "/nw:networks/nw:network/nt:link/tet:te/"
+ "tet:te-link-attributes" {
when "../../../nw:network-types/tet:te-topology/"
+ "otnt:otn-topology" {
description
"Augmentation parameters apply only for networks with
OTN topology type.";
}
description
"Augment OTN TE link attributes with slicing profile.";
uses otn-link-slice-profile;
}
}
<CODE ENDS>
]]></artwork></figure>
</section>
</section>
<section anchor="otn-slicing-yang-model-for-otn-sc-nbi"><name>OTN Slicing YANG Model for OTN-SC NBI</name>
<section anchor="nbi-yang-model-overview"><name>NBI YANG Model Overview</name>
<t>The YANG model for OTN-SC NBI is OTN-technology specific, but shares many
common constructs and attributes with the common network slicing YANG model
defined in <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>. Furthermore, the
OTN-SC NBI YANG is expected to support both connectivity-based
and resource-based slice configuration, which is likely a common requirement for
supporting slicing at other transport network layers, e.g. WDM or MPLS(-TP).</t>
<t>The OTN slicing model augments the common network slicing YANG model by extending
OTN technology-specific SLO and SLE attributes which can be requested by OTN-aware
customers and allows the customer to specify desired OTN signal quality.
These attributes include:</t>
<t><list style="symbols">
<t>The performance objective for Optical Data Unit (ODU) containers as defined in
ITU-T-G.8201-Amd.1.</t>
<t>Bandwidth specification in the type and number of ODU containers.</t>
</list></t>
</section>
<section anchor="nbi-yang-model-tree-for-otn-slice"><name>NBI YANG Model Tree for OTN slice</name>
<figure title="Tree diagram for OTN slice" anchor="fig-ietf-otn-slice"><artwork><![CDATA[
module: ietf-otn-slice
augment /ietf-nss:network-slice-services/ietf-nss:slo-sle-templates
/ietf-nss:slo-sle-template/ietf-nss:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /ietf-nss:network-slice-services/ietf-nss:slice-service
/ietf-nss:slo-sle-policy/ietf-nss:custom
/ietf-nss:service-slo-sle-policy/ietf-nss:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /nw:networks/nw:network/ns-topo:slo-sle-policy
/ns-topo:custom/ns-topo:service-slo-sle-policy
/ns-topo:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /nw:networks/nw:network/nw:node/ns-topo:slo-sle-policy
/ns-topo:custom/ns-topo:service-slo-sle-policy
/ns-topo:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /nw:networks/nw:network/nw:node/nt:termination-point
/ns-topo:slo-sle-policy/ns-topo:custom
/ns-topo:service-slo-sle-policy/ns-topo:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /nw:networks/nw:network/nt:link/ns-topo:slo-sle-policy
/ns-topo:custom/ns-topo:service-slo-sle-policy
/ns-topo:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /ietf-nss:network-slice-services/ietf-nss:slice-service
/ietf-nss:connection-groups/ietf-nss:connection-group
/ietf-nss:slo-sle-policy/ietf-nss:custom
/ietf-nss:service-slo-sle-policy/ietf-nss:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /ietf-nss:network-slice-services/ietf-nss:slice-service
/ietf-nss:connection-groups/ietf-nss:connection-group
/ietf-nss:connectivity-construct/ietf-nss:slo-sle-policy
/ietf-nss:custom/ietf-nss:service-slo-sle-policy
/ietf-nss:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
augment /ietf-nss:network-slice-services/ietf-nss:slice-service
/ietf-nss:connection-groups/ietf-nss:connection-group
/ietf-nss:connectivity-construct/ietf-nss:type
/ietf-nss:a2a/ietf-nss:a2a-sdp/ietf-nss:slo-sle-policy
/ietf-nss:custom/ietf-nss:service-slo-sle-policy
/ietf-nss:slo-policy:
+--rw otn
+--rw odu-signal-quality
| +--rw odu-pm-objective* [duration pm-type]
| +--rw duration identityref
| +--rw pm-type identityref
| +--rw pm-threshold? uint64
+--rw odulist* [odu-type]
+--rw odu-type identityref
+--rw number? uint16
]]></artwork></figure>
</section>
<section anchor="nbi-yang-code-for-otn-slice"><name>NBI YANG Code for OTN Slice</name>
<figure title="YANG model for transport network slice" anchor="fig-ietf-otn-slice-yang"><artwork><![CDATA[
<CODE BEGINS> file "ietf-otn-slice@2023-07-06.yang"
module ietf-otn-slice {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-otn-slice";
prefix "otns";
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-layer1-types {
prefix "l1-types";
reference
"draft-ietf-ccamp-layer1-types-14:
A YANG Data Model for Layer 1 Types";
}
import ietf-network-slice-service {
prefix "ietf-nss";
reference
"draft-ietf-teas-ietf-network-slice-nbi-yang-05:
IETF Network Slice Service YANG Model";
}
import ietf-ns-topo {
prefix "ns-topo";
reference
"draft-liu-teas-transport-network-slice-yang-06:
IETF Network Slice YANG Model";
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
Editor: Haomian Zheng
<mailto:zhenghaomian@huawei.com>
Editor: Italo Busi
<mailto:italo.busi@huawei.com>
Editor: Aihua Guo
<mailto:aihuaguo.ietf@gmail.com>
Editor: Sergio Belotti
<mailto:sergio.belotti@nokia.com>";
description
"This module defines a YANG data model for configuring
technology-specific network slices in optical transport
networks, e.g., Optical Transport Network (OTN).
The model fully conforms to the Network Management Datastore
Architecture (NMDA).
Copyright (c) 2022 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 "2023-07-06" {
description
"Latest revision of NBI YANG model for OTN slicing.";
reference
"draft-ietf-ccamp-yang-otn-slicing-05: Framework and Data
Model for OTN Network Slicing";
}
/*
* Identities
*/
identity bit-error-rate {
base ietf-nss:service-slo-metric-type;
description
"ODU bit error rate";
}