/
draft-ietf-detnet-yang-20.xml
24062 lines (21923 loc) · 671 KB
/
draft-ietf-detnet-yang-20.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>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-detnet-yang-20" ipr="trust200902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.7.0 -->
<front>
<title abbrev="draft-ietf-detnet-yang-20">Deterministic Networking
(DetNet) YANG Model</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-yang-20"/>
<author fullname="Xuesong Geng" initials="X." surname="Geng">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>gengxuesong@huawei.com</email>
</address>
</author>
<author fullname="Yeoncheol Ryoo" initials="Y." surname="Ryoo">
<organization>ETRI</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email>dbduscjf@etri.re.kr</email>
<uri/>
</address>
</author>
<author fullname="Don Fedyk" initials="D." surname="Fedyk">
<organization>LabN Consulting, L.L.C.</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email>dfedyk@labn.net</email>
<uri/>
</address>
</author>
<author fullname="Reshad Rahman" initials="R." surname="Rahman">
<organization>Equinix</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email>reshad@yahoo.com</email>
<uri/>
</address>
</author>
<author fullname="Zhenqiang Li" initials="Z." surname="Li">
<organization>China Mobile</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>lizhenqiang@chinamobile.com</email>
</address>
</author>
<date/>
<abstract>
<t>This document contains the specification for the Deterministic Networking
YANG Model for configuration and operational data of DetNet Flows.
The model allows for provisioning of
end-to-end DetNet service on devices along the path without dependency on any
signaling protocol. It also specifies operational status for flows.
</t>
<t>The YANG module defined in this document conforms to the Network
Management Datastore Architecture (NMDA).</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>DetNet (Deterministic Networking) provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and concepts
of DetNet can be found in <xref target="RFC8655" format="default"/>.</t>
<t>This document defines a YANG model for DetNet based on YANG data
types and modeling language defined in <xref target="RFC6991" format="default"/> and
<xref target="RFC7950" format="default"/>. DetNet service, which is designed for
describing the characteristics of services being provided for
application flows over a network, and DetNet configuration, which is
designed for DetNet flow path establishment, flow status reporting, and
DetNet functions configuration in order to achieve end-to-end bounded
latency and zero congestion loss, are both included in this
document.</t>
<t> This Yang model is scoped to the description of the
aggregation/disaggregation and data plane capabilities of the DetNet data
planes defined in the DetNet Architecture
<xref target="RFC8655" format="default"> </xref>
and DetNet Framework <xref target="RFC8938" format="default"> </xref>.
DetNet operates at the IP layer and delivers service over lower-layer
technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN).
</t>
</section>
<section numbered="true" toc="include">
<name slugifiedName="name-abbreviations">Abbreviations</name>
<t indent="0">
The following abbreviations are used in this document:
</t>
<dl newline="false" spacing="normal" indent="14">
<dt>PEF</dt>
<dd>Packet Elimination Function</dd>
<dt>PRF</dt>
<dd>Packet Replication Function</dd>
<dt>PEOF</dt>
<dd>Packet Elimination and Ordering Functions</dd>
<dt>PERF</dt>
<dd>Packet Elimination and Replication Functions</dd>
<dt>PREOF</dt>
<dd>Packet Replication, Elimination and Ordering Functions</dd>
<dt>MPLS</dt>
<dd>Multiprotocol Label Switching</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses the terminology defined in <xref target="RFC8655" format="default"> </xref>.
The terms A-label, S-label, and F-label are used in this document
as defined in <xref target="RFC8964"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>DetNet YANG Module</name>
<t>The DetNet YANG module includes DetNet App-flow,
DetNet Service Sub-layer, and DetNet Forwarding Sub-layer
configuration and operational objects.
The corresponding attributes used in different sub-layers
are defined in <xref target="appyangatt"> </xref> ,
<xref target="serviceyangatt"> </xref> ,
<xref target="forwardingyangatt"> </xref> respectively.</t>
<t> Layers of the objects typically occur
in the different data instances forming the node types defined in
<xref target="RFC8655" format="default"> </xref>.
<xref target="table_layer_node" format="default"/>
illustrates the relationship between data instance node types and the included layers.
Node types are logical roles per DetNet service: a device along one
DetNet service can be of one node type, while another service may use
the same device with a different node type.
This model is a controller based model because a controller or operator
configures all the devices to form a service.
</t>
<figure anchor="table_layer_node" align="left" suppress-title="false">
<name slugifiedName="detnet-layer-node-types">DetNet Layers and Node Types</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------------------+
| Instance |
+-----+-----------------+-----------------+---------------+
| |Edge Node | Relay Node | Transit Node |
+-----+-----------------+-----------------+---------------+
| L |Application | | |
| a +-----------------+-----------------+---------------+
| y |Service Sub-Layer|Service Sub-Layer| |
| e +-----------------+-----------------+---------------+
| r |Forwarding S-L |Forwarding S-L | Forwarding S-L|
+-----+-----------------+-----------------+---------------+
]]></artwork>
</figure>
<t>
All of the layers have ingress/incoming and egress/outgoing operations, but any instance
may be configured as only unidirectional.
Ingress refers to any DetNet layer where a DetNet context is applied. Ingress allows functions such as
switching, aggregation and encapsulation.
Likewise, egress refers to any DetNet layer where a DetNet context is removed. Egress allows
functions such as switching, disaggregation and decapsulation.
This means that each unidirectional
flow identifier configuration is programmed starting at the ingress and flow status is
reported at ingress on each end.
In the MPLS cases once encapsulated, the IP 6-tuple, see <xref target="RFC8938"/>,
parameters may not be required to be programmed again.
In the IP case, without encapsulation, various IP flow id parameters must be configured along
the flow path.
</t>
<t>
In the YANG model the terms source and destination are
used as flow identifiers whereas ingress and egress refer to a
DetNet application direction from the application edge.
Ingress is to the DetNet application and egress is from the application.
The terms incoming and outgoing generally represent
the flow direction towards the remote application. Outgoing is viewed as
going down the stack from Application to Service sub-layer to Forwarding sub-layer
and incoming is the reverse.
Although,
in examples where there is aggregation and disaggregation
outgoing relates to the aggregating output and incoming
relates to the disaggregating flows.
</t>
<t>
At the egress point, forwarding information is determined by the
App-flow type with all DetNet-related headers removed. The forwarding
information can specify an output port, or set a next-hop-address in case
of IP, or set an MPLS label in case of MPLS.
</t>
<section anchor="appyangatt" numbered="true" toc="default">
<name>DetNet Application Flow YANG Attributes</name>
<t>DetNet application flow is responsible for mapping between
application flows and DetNet flows at the edge node (egress/ingress
node). The application flows can be either layer 2 or layer 3
flows. To map a flow at the User Network Interface (UNI), the
corresponding attributes are defined in <xref target="RFC9016" format="default"/>.</t>
</section>
<section anchor="serviceyangatt" numbered="true" toc="default">
<name>DetNet Service Sub-layer YANG Attributes</name>
<t>DetNet service functions, e.g., DetNet tunnel
initialization/termination and service protection, are provided in
the DetNet service sub-layer. To support these functions, the following
service attributes need to be configured:</t>
<ul spacing="normal">
<li>DetNet flow identification</li>
<li>Service function indication, indicates which service function
will be invoked at a DetNet edge, relay node or end station.
(DetNet tunnel initialization or termination are default functions
in the DetNet service layer, so there is no need for explicit
indication). The corresponding arguments for service functions
also need to be defined.</li>
</ul>
</section>
<section anchor="forwardingyangatt" numbered="true" toc="default">
<name>DetNet Forwarding Sub-layer YANG Attributes</name>
<t>As defined in <xref target="RFC8655" format="default"/>, DetNet forwarding sub-layer
optionally provides congestion protection for DetNet flows over paths
provided by the underlying network. Explicit route is another
mechanism that is used by DetNet to avoid temporary interruptions
caused by the convergence of routing or bridging protocols, and it is
also implemented at the DetNet forwarding sub-layer.</t>
<t>To support congestion protection and explicit route, the following
transport layer related attributes are necessary:</t>
<ul spacing="normal">
<li>Flow Specification and Traffic Requirements, as described
in the information model in <xref target="RFC9016" format="default"/>. These may be used for
resource reservation, flow shaping, filtering and policing by
a control plane or other network management and control mechanisms.
</li>
<li>Since this model programs the data plane existing explicit route
mechanisms can be reused. If a static MPLS tunnel is used as the
transport tunnel, the configuration needs to be at every transit
node along the path. For an IP-based path, the static configuration
is similar to the static MPLS case. This document provides
data-plane configuration of IP addresses or MPLS labels
but it does not provide control plane mapping or other
aspects.
</li>
</ul>
</section>
</section>
<section numbered="true" toc="default">
<name>DetNet Flow Aggregation</name>
<t>
DetNet provides the capability of flow aggregation to improve
scalability of DetNet data, management and control planes. Aggregated
flows can be viewed by some DetNet nodes as individual DetNet flows.
When aggregating DetNet flows, the flows should be compatible: if
bandwidth reservations are used, the reservation should be a reasonable
representation of the individual reservations; if maximum delay bounds
are used, the system should ensure that the aggregate does not exceed the
delay bounds of the individual flows.
</t>
<t>
The DetNet YANG model defined in this document supports DetNet flow
aggregation with the following functions:
</t>
<ul spacing="normal">
<li>
Aggregated flow encapsulation/decapsulation/identification
</li>
<li>
Mapping individual DetNet flows to an aggregated flow
</li>
<li>
Changing traffic specification parameters for aggregated flows
</li>
</ul>
<t>
The following cases of DetNet aggregation are supported:
</t>
<ul spacing="normal">
<li>
Ingress node aggregates App flows into a service sub-layer of DetNet flow
</li>
<li>
In ingress node, the service sub-layers of DetNet flows are aggregated into a forwarding sub-layer
</li>
<li>
In ingress node, the service sub-layers of DetNet flows are aggregated into a service sub-layer of an aggregated DetNet flow
</li>
<li>
Relay node aggregates the forwarding sub-layers DetNet flows into a forwarding sub-layer
</li>
<li>
Relay node aggregates the service sub-layers of DetNet flows into a forwarding sub-layer
</li>
<li>
Relay node aggregates the service sub-layers of DetNet flows into a service sub-layer of Aggregated DetNet flow
</li>
<li>
Relay node aggregates the forwarding sub-layers of DetNet flow into a service sub-layer of Aggregated DetNet flow
</li>
<li>
Transit node aggregates the forwarding sub-layers of DetNet flows into a forwarding sub-layer
</li>
</ul>
<t>
Traffic requirements and traffic specification may be tracked for
individual or aggregate flows but reserving resources and tracking the
services in the aggregated flow is out of scope.
</t>
</section>
<section numbered="true" toc="default">
<name>DetNet YANG Structure Considerations</name>
<t/>
<t>The picture shows the general structure of the DetNet YANG
Model:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------+
|ietf-detnet|
+-----+-----+
|
+--------------+----------------+------------------+
| | | |
+-----+------+ +-----+------+ +-------+------+ |
| App Flows | |service s-l | |forwarding s-l| |
+-----+------+ +-----+------+ +-------+------+ |
| | | |
+-----+------+ +-----+------+ +-------+------+ |
| Reference | | Reference | | Reference | |
| to Traffic | | to Traffic | | to Traffic | +-------+-------+
| Profile | | Profile | | Profile | |Traffic Profile|
+------------+ +------------+ +--------------+ +---------------+
]]></artwork>
<t>
There are three layer types in the DetNet YANG Model:
App-flow data layer,
service sub-layer and forwarding sub-layer.
Additionally, the Traffic parameters are captured in a Traffic profile
that can be referenced by any of the layers.
</t>
<t>
Below is a summary YANG tree showing the major items.
A complete YANG tree is in section <xref target="Tree"/>.
</t>
<t>
A traffic profile can be created for an application,
a service sub-layer or a forwarding sub-layer.
A single profile may be shared by multiple applications/sub-layer.
Each profile indicates the members currently using that profile.
</t>
<t>
Depending on which DetNet layers and functions are required,
some or all of the components may be configured.
Examples are shown in <xref target="Examples"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>DetNet Configuration YANG Structures</name>
<t> The following is a partial tree representation of the YANG as defined in
<xref target="RFC8340" format="default"/>. This corresponds to the
structure layout in the previous section.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
module: ietf-detnet
+--rw detnet
+--rw traffic-profile* [name]
| +--rw name string
| +--rw traffic-requirements
| +--rw traffic-spec
| +--ro member-app-flow* app-flow-ref
| +--ro member-svc-sublayer* service-sub-layer-ref
| +--ro member-fwd-sublayer* forwarding-sub-layer-ref
+--rw app-flows
| +--rw app-flow* [name]
| +--rw name string
| +--rw bidir-congruent? boolean
| +--ro outgoing-service? service-sub-layer-ref
| +--ro incoming-service? service-sub-layer-ref
| +--rw traffic-profile? traffic-profile-ref
| +--rw ingress
| | ...
| +--rw egress
| ...
+--rw service
| +--rw sub-layer* [name]
| +--rw name string
| +--rw service-rank? uint8
| +--rw traffic-profile? traffic-profile-ref
| +--rw service-protection
| | ...
| +--rw operation? operation
| +--rw incoming
| | ...
| +--rw outgoing
| ...
+--rw forwarding
+--rw sub-layer* [name]
+--rw name string
+--rw traffic-profile? traffic-profile-ref
+--rw operation? mpls-fwd-operation
+--rw incoming
| ...
+--rw outgoing
...
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>DetNet Configuration YANG Model</name>
<t> This YANG model imports typedefs from <xref target="RFC6991"/>,
<xref target="RFC8519"/>,
<xref target="RFC8294"/>,
<xref target="RFC8343"/>,
and <xref target="IEEE8021Q"/>.
This YANG model also has the following references to RFCs
that are not in the document text body
<xref target="RFC0791"/>,
<xref target="RFC4303"/>,
<xref target="RFC8349"/>,
<xref target="RFC8938"/>,
<xref target="RFC8960"/>,
<xref target="RFC8964"/>,
and <xref target="RFC8200"/>.
</t>
<sourcecode name="ietf-detnet@2022-02-21.yang" type="yang" markers="true"><![CDATA[
module ietf-detnet {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-detnet";
prefix dnet;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991 - Common YANG Data Types.";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991 - Common YANG Data Types.";
}
import ietf-ethertypes {
prefix ethertypes;
reference
"RFC 8519 - YANG Data Model for Network Access Control
Lists (ACLs).";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294 - Common YANG Data Types for the Routing Area.";
}
import ietf-packet-fields {
prefix packet-fields;
reference
"RFC 8519 - YANG Data Model for Network Access Control Lists
(ACLs).";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343 - A YANG Data Model for Interface Management.";
}
import ieee802-dot1q-types {
prefix dot1q-types;
reference
"IEEE 802.1Q-2022 - IEEE Standard for Local and Metropolitan
Area Networks--Bridges and Bridged Networks Clause 48: YANG
Data Models.";
}
organization
"IETF DetNet Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/detnet/>
WG List: <mailto:detnet@ietf.org>
Editor: Xuesong Geng
<mailto:gengxuesong@huawei.com>
Editor: Yeoncheol Ryoo
<mailto:dbduscjf@etri.re.kr>
Editor: Don Fedyk
<mailto:dfedyk@labn.net>;
Editor: Reshad Rahman
<mailto:reshad@yahoo.com>
Editor: Zhenqiang Li
<mailto:lizhenqiang@chinamobile.com>";
description
"This YANG module describes the parameters needed
for DetNet flow configuration and flow status
reporting. This YANG module conforms to the Network
Management Datastore Architecture (NMDA).
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.";
// RFC Ed.: replace XXXX with actual RFC number and remove
// this note
// replace '2024-02-21' with the module publication date
// the format is (year-month-day)
revision 2024-02-21 {
description
"Initial revision";
reference
"RFC XXXX: Deterministic Networking (DetNet) YANG Model";
}
identity app-status {
description
"Base identity from which all application-status
status types are derived.";
reference
"RFC 9016 Section 5.8";
}
identity none {
base app-status;
description
"This application has no status. This identity is
expected when the configuration is incomplete.";
reference
"RFC 9016 Section 5.8";
}
identity ready {
base app-status;
description
"Application ingress/egress ready.";
reference
"RFC 9016 Section 5.8";
}
identity failed {
base app-status;
description
"Application ingres/egress failed.";
reference
"RFC 9016 Section 5.8";
}
identity out-of-service {
base app-status;
description
"Application administratively blocked.";
reference
"RFC 9016 Section 5.8";
}
identity partial-failed {
base app-status;
description
"This is an application with one or more Egress ready, and one
or more Egress failed. The DetNet flow can be used if the
Ingress is Ready.";
reference
"RFC 9016 Section 5.8";
}
typedef app-flow-ref {
type leafref {
path "/dnet:detnet"
+ "/dnet:app-flows"
+ "/dnet:app-flow"
+ "/dnet:name";
}
description
"This is an application Reference.";
}
typedef service-sub-layer-ref {
type leafref {
path "/dnet:detnet"
+ "/dnet:service"
+ "/dnet:sub-layer"
+ "/dnet:name";
}
description
"This is a service sub-layer Reference.";
}
typedef forwarding-sub-layer-ref {
type leafref {
path "/dnet:detnet"
+ "/dnet:forwarding"
+ "/dnet:sub-layer"
+ "/dnet:name";
}
description
"This is a forwarding sub-layer Reference.";
}
typedef traffic-profile-ref {
type leafref {
path "/dnet:detnet"
+ "/dnet:traffic-profile"
+ "/dnet:name";
}
description
"This is a traffic Profile Reference.";
}
typedef ipsec-spi {
type uint32 {
range "1..max";
}
description
"IPsec Security Parameters Index. A 32 bit value
where some values are reserved.";
reference
"IETF RFC 4303 Encapsulating Security Payload (ESP).";
}
typedef operation {
type enumeration {
enum initiation {
description
"This is an initiating service sub-layer encapsulation.";
}
enum termination {
description
"Operation for DetNet service sub-layer decapsulation.";
}
enum relay {
description
"Operation for DetNet service sub-layer swap.";
}
enum non-detnet {
description
"No operation for DetNet service sub-layer.";
}
}
description
"Operation type identifies the behavior for this service
sub-layer. Operations are described as unidirectional
but a service sub-layer may combine operation types.";
}
typedef mpls-fwd-operation {
type enumeration {
enum impose-and-forward {
description
"This operation imposes outgoing label(s) and forwards to
next-hop.";
reference
" A YANG Data Model for MPLS Base RFC 8960.";
}
enum pop-and-forward {
description
"This operation pops the incoming label and forwards to
the next-hop.";
reference
" A YANG Data Model for MPLS Base RFC 8960.";
}
enum pop-impose-and-forward {
description
"This operation pops the incoming label, imposes one or
more outgoing label(s) and forwards to the next-hop.";
reference
" A YANG Data Model for MPLS Base RFC 8960.";
}
enum swap-and-forward {
description
"This operation swaps an incoming label, with an outgoing
label and forwards to the next-hop.";
reference
" A YANG Data Model for MPLS Base RFC 8960.";
}
enum forward {
description
"This operation forwards to next-hop.";
}
enum pop-and-lookup {
description
"This operation pops an incoming label and performs a
lookup.";
}
}
description
"MPLS operations types. This is an enum modeled after the
MPLS enum. The enums are the same as A YANG Data Model
for MPLS Base. RFC 8960.";
}
typedef service-protection {
type enumeration {
enum none {
description
"No service protection provided.";
}
enum replication {
description
"A Packet Replication Function (PRF) replicates DetNet
flow packets and forwards them to one or more next hops in
the DetNet domain. The number of packet copies sent to
each next hop is a DetNet flow-specific parameter at the
node doing the replication. PRF can be implemented by an
edge node, a relay node, or an end system.";
}
enum elimination {
description
"A Packet Elimination Function (PEF) eliminates duplicate
copies of packets to prevent excess packets flooding the
network or duplicate packets being sent out of the DetNet
domain. PEF can be implemented by an edge node, a relay
node, or an end system.";
}
enum ordering {
description
"A Packet Ordering Function (POF) re-orders packets within
a DetNet flow that are received out of order. This
function can be implemented by an edge node, a relay node,
or an end system.";
}
enum elimination-ordering {
description
"A combination of PEF and POF that can be implemented by
an edge node, a relay node, or an end system.";
}
enum elimination-replication {
description
"A combination of PEF and PRF that can be implemented by
an edge node, a relay node, or an end system.";
}
enum elimination-ordering-replication {
description
"A combination of PEF, POF and PRF that can be implemented
by an edge node, a relay node, or an end system.";
}
}
description
"This typedef describes the service protection enumeration
values.";
}
typedef sequence-number-generation {
type enumeration {
enum copy-from-app-flow {
description
"Copy-from-app-flow is used to extend and use the
sequence number used in App-flow. This function is
required when encapsulating App-flows that have been
replicated and received through multiple ingress nodes
into a member flow, and then eliminate it at the relay
node.";
}
enum generate-by-detnet-flow {
description
"Generate-by-detnet-flow is used to create a new
sequence number for a DetNet flow at the ingress node.
Care must be taken when using this option to ensure
there is only one source for generating sequence
numbers.";
}
}
description
"This typedef defines how to generate sequence numbers to
be used in DetNet encapsulation.";
}
typedef sequence-number-field {
type enumeration {
enum zero-sn {
description
"No DetNet sequence number field is used.";
}
enum short-sn {
value 16;
description
"A 16-bit DetNet sequence number field is used.";
}
enum long-sn {
value 28;
description
"A 28-bit DetNet sequence number field is used.";
}
}
description
"This enumeration configures the sequence number behavior.";
}
grouping ip-header {
description
"This grouping captures the IPv4/IPv6 packet header
information. It is modeled after existing fields.";
leaf src-ip-address {
type inet:ip-address-no-zone;
description
"The source IP address in the header.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf dest-ip-address {
type inet:ip-address-no-zone;
description
"The destination IP address in the header.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf protocol-next-header {
type uint8;
description
"In IPv4 refers to the protocol of the
payload. In IPv6, this field is known as 'next-header',
and identifies the type of header immediately following
the IPv6 header.";
reference
"RFC 791: Internet Protocol
RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification.";
}
leaf dscp {
type inet:dscp;
description
"The traffic class value in the header.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf flow-label {
type inet:ipv6-flow-label;
description
"The flow label value of the header. IPv6 only.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf source-port {
type inet:port-number;
description
"The source port number.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf destination-port {
type inet:port-number;
description
"The destination port number.";
reference
"RFC 6991 Common YANG Data Types";
}
}
grouping l2-header {
description
"The Ethernet or TSN packet header information.";
leaf source-mac-address {
type yang:mac-address;
description
"The source MAC address value of the Ethernet header.";
}
leaf destination-mac-address {
type yang:mac-address;
description
"The destination MAC address value of the Ethernet header.";
}
leaf ethertype {
type ethertypes:ethertype;
description
"The Ethernet packet type value of the Ethernet header.";
}
leaf vlan-id {
type dot1q-types:vlanid;
description
"The VLAN value of the Ethernet header.";
reference
"IEEE 802.1Q-2022.";
}
leaf pcp {
type dot1q-types:priority-type;
description
"The priority value of the Ethernet header.";
reference
"IEEE 802.1Q-2022.";
}
}
grouping destination-ip-port-id {
description
"The TCP/UDP port destination identification
information.";
container destination-port {
uses packet-fields:port-range-or-operator;
description
"This grouping captures the destination port fields.";
}
}
grouping source-ip-port-id {
description
"The TCP/UDP port source identification
information.";
container source-port {
uses packet-fields:port-range-or-operator;
description
"This grouping captures the source port fields.";
}
}
grouping ip-flow-id {
description
"The IPv4/IPv6 packet header identification information.";
leaf src-ip-prefix {
type inet:ip-prefix;
description
"The source IP prefix.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf dest-ip-prefix {
type inet:ip-prefix;
description
"The destination IP prefix.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf protocol-next-header {
type uint8;
description
"Internet Protocol number. Refers to the protocol of the
payload. In IPv6, this field is known as 'next-header', and
if extension headers are present, the protocol is present in
the 'upper-layer' header.";
reference
"RFC 791: Internet Protocol
RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification.";
}
leaf dscp {
type inet:dscp;
description
"The traffic class value in the header.";
reference
"RFC 6991 Common YANG Data Types";
}
leaf flow-label {
type inet:ipv6-flow-label;
description
"The flow label value of the header.";
reference
"RFC 6991 Common YANG Data Types";
}
uses source-ip-port-id;
uses destination-ip-port-id;
leaf ipsec-spi {
type ipsec-spi;
description
"IPsec Security Parameters Index of the Security
Association.";
reference
"IETF RFC 4303 Encapsulating Security Payload (ESP).";
}
}
grouping mpls-flow-id {
description
"The MPLS packet header identification information.";
choice label-space {
description