-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-ietf-detnet-dp-sol-ip-03.xml
2160 lines (2043 loc) · 101 KB
/
draft-ietf-detnet-dp-sol-ip-03.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="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
docName="draft-ietf-detnet-dp-sol-ip-02"
ipr="trust200902"
submissionType="IETF">
<front>
<title abbrev="DetNet IP Data Plane">
DetNet IP Data Plane Encapsulation</title>
<author role="editor" fullname="Jouni Korhonen" initials="J." surname="Korhonen">
<!--organization abbrev="Nordic">Nordic Semiconductor</organization-->
<address>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author role="editor" fullname="Balázs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization>
<address>
<postal>
<street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1117</code>
</postal>
<email>balazs.a.varga@ericsson.com</email>
</address>
</author>
<!--author fullname="Donald Fauntleroy Duck" initials="D. F." surname="Duck">
<organization abbrev="Royal Bros.">Royal Bros.</organization>
<address>
<postal>
<street>13 Paradise Road</street>
<city>Duckburg</city>
<region>Calisota</region>
<country>USA</country>
</postal>
</address>
</author-->
<date />
<workgroup>DetNet</workgroup>
<abstract>
<t>
This document specifies the Deterministic Networking data plane
when operating in an IP packet switched network.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sec_intro">
<t>
Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows.
DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end
delivery latency. General background and concepts of DetNet can
be found in the DetNet Architecture <xref target="I-D.ietf-detnet-architecture"/>.
</t>
<t>
This document specifies the DetNet data plane operation for IP
hosts and routers that provide DetNet service to IP encapsulated
data. No DetNet specific encapsulation is defined to support IP
flows, rather existing IP and higher layer protocol header information is used to support
flow identification and DetNet service delivery.
</t>
<t>
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer. The service sub-layer is used to provide DetNet service
protection and reordering. The forwarding sub-layer is used to
provides congestion protection (low loss, assured latency, and
limited reordering). As no DetNet specific headers are added to
support DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP defined by this document. Service
protection can be provided on a per sub-net
basis using technologies such as MPLS <xref
target="I-D.ietf-detnet-dp-sol-mpls"/> and IEEE802.1 TSN.
</t>
<t>
This document provides an overview of the DetNet IP data plane
in <xref target="sec_dt_dp"/>, considerations that apply to
providing DetNet services via the DetNet IP data plane in <xref
target="dn-gen-encap-solution"/> and <xref
target="m-cp-considerations"/>. <xref target="ip-procs"/>
provides the procedures for hosts and routers that support
IP-based DetNet services. Finally, <xref target="mapping-tsn"/>
provides rules for mapping IP-based DetNet flows to IEEE 802.1
TSN streams.
</t>
</section>
<section title="Terminology">
<section title="Terms Used In This Document">
<t>
This document uses the terminology and concepts established in
the DetNet architecture <xref
target="I-D.ietf-detnet-architecture"/>, and the reader is assumed
to be familiar with that document and its terminology.
</t>
</section>
<section title="Abbreviations">
<t>
The following abbreviations used in this document:
<!-- [JiK] Update later -->
<list style="hanging" hangIndent="14">
<t hangText="CE">Customer Edge equipment.</t>
<t hangText="CoS">Class of Service.</t>
<t hangText="DetNet">Deterministic Networking.</t>
<t hangText="DF">DetNet Flow.</t>
<t hangText="L2">Layer-2.</t>
<t hangText="L3">Layer-3.</t>
<t hangText="LSP">Label-switched path.</t>
<t hangText="MPLS">Multiprotocol Label Switching.</t>
<t hangText="OAM">Operations, Administration, and Maintenance.</t>
<t hangText="PE">Provider Edge.</t>
<t hangText="PREOF">Packet Replication, Ordering and Elimination Function.</t>
<t hangText="PSN">Packet Switched Network.</t>
<t hangText="PW">Pseudowire.</t>
<t hangText="QoS">Quality of Service.</t>
<t hangText="TE">Traffic Engineering.</t>
<t hangText="TSN">Time-Sensitive Networking, TSN is a Task Group of the IEEE
802.1 Working Group.</t>
</list>
</t>
</section>
<section title="Requirements Language">
<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>
</section>
</section>
<section title="DetNet IP Data Plane Overview" anchor="sec_dt_dp">
<!-- LB: this section should provide the overview related to:
<section title="Simplified IP-Related DetNet Data Plane Solution" anchor="simple-ip-solution">
<t>
This section is the placeholder for the conclusion discussed during IETF 101 and 102.
</t>
<t>
[Editor's note: describe the 6 tuple way of identifying DetNet service flows. Also stress
that PREOF is per network segment as described in <xref target="nwsegments"/>
<list style="symbols">
<t>DetNet flows are recognized based on 6 tuple.</t>
<t>No end to end DN Sequence Number present in the packet.</t>
<t>Links / sub nets may use their technology specific methods to achieve DN service.</t>
<t>TE information does not travel with the packet (e.g., nailed down path ensured via Policy-Based-Routing).</t>
<t>etc.</t>
</list>
]
</t>
<t>
<xref target="simplifiedip"/> illustrated the case for DetNet simplified IP data plane solution.
</t>
</section>
-->
<t>
This document describes how IP is used by DetNet nodes, i.e.,
hosts and routers, to identify DetNet flows and provide a DetNet
service. From a data plane perspective, an end-to-end IP model
is followed. As mentioned above, existing IP and higher layer
protocol header information is used to support flow
identification and DetNet service delivery.
</t>
<t>
DetNet uses "6-tuple" based flow identification, where "6-tuple"
refers to information carried in IP and higher layer protocol
headers. General background on the use of IP headers, and
"5-tuples", to identify flows and support Quality of Service
(QoS) can be found in <xref target="RFC3670"/>. <xref
target="RFC7657"/> also provides useful background on the
delivery differentiated services (DiffServ) and "6-tuple" based
flow identification.
</t>
<t>
DetNet flow aggregation may be enabled via the use of
wildcards, masks, prefixes and ranges. IP tunnels may also be
used to support flow aggregation. In these cases, it is
expected that DetNet aware intermediate nodes will provide
DetNet service assurance on the aggregate through resource
allocation and congestion control mechanisms.
</t>
<figure align="center" anchor="fig_ip_detnet_simple"
title="A Simple DetNet (DN) Enabled IP Network">
<artwork><![CDATA[
DetNet IP Relay Relay DetNet IP
End System Node Node End System
+----------+ +----------+
| Appl. |<------------ End to End Service ----------->| Appl. |
+----------+ ............ ........... +----------+
| Service |<-: Service :-- DetNet flow --: Service :->| Service |
+----------+ +----------+ +----------+ +----------+
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
+--------.-+ +-.------.-+ +-.---.----+ +-------.--+
: Link : \ ,-----. / \ ,-----. /
+......+ +----[ Sub ]----+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
|<--------------------- DetNet IP --------------------->|
]]></artwork>
</figure>
<t>
<xref target="fig_ip_detnet_simple"/> illustrates a DetNet enabled IP
network. The DetNet enabled end systems originate IP encapsulated
traffic that is identified as DetNet flows, relay nodes understand the
forwarding requirements of the DetNet flow and ensure that node,
interface and sub-network resources are allocated to ensure DetNet
service requirements. The dotted line around the Service component of
the Relay Nodes indicates that the transit routers are DetNet service
aware but do not perform any DetNet service sub-layer function, e.g., PREOF.
IEEE 802.1 TSN is an example sub-network type which can provide support
for DetNet flows and service. The mapping of DetNet IP flows to TSN
streams and TSN protection mechanisms is covered in <xref
target="mapping-tsn"/>.
</t>
<t>
Note: The sub-network can represent a TSN, MPLS or IP network
segment.
</t>
<figure align="center" anchor="fig_ip_detnet"
title="DetNet IP Over DetNet MPLS Network">
<artwork><![CDATA[
DetNet IP Relay Transit Relay DetNet IP
End System Node Node Node End System
+----------+ +----------+
| Appl. |<-------------- End to End Service ---------->| Appl. |
+----------+ .....-----+ +-----..... +----------+
| Service |<--: Service |-- DetNet flow ---| Service :-->| Service |
| | : |<- DN MPLS flow ->| : | |
+----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+--------.-+ +-.-+ +-.-+ +---.----.-+ +-.-+ +-.-+ +----.-----+
: Link : / ,-----. \ : Link : / ,-----. \
+.......+ +-[ Sub ]-+ +.......+ +--[ Sub ]--+
[Network] [Network]
`-----' `-----'
|<---- DetNet MPLS --->|
|<--------------------- DetNet IP ------------------->|
]]></artwork>
</figure>
<t>
<xref target="fig_ip_detnet"/> illustrates a variant of <xref
target="fig_ip_detnet_simple"/>, with an MPLS based DetNet
network as a sub-network between the relay nodes. It shows a
more complex DetNet enabled IP network where an IP flow is
mapped to one or more PWs and MPLS (TE) LSPs. The end systems
still originate IP encapsulated traffic that is identified as
DetNet flows. The relay nodes follow procedures defined in
<xref target="ip-over-mpls"/> to map each DetNet
flow to MPLS LSPs. While not shown, relay nodes can provide
service sub-layer functions such as PREOF using DetNet over MPLS,
and this is indicated by the solid line for the MPLS
facing portion of the Service component. Note that the Transit
node is MPLS (TE) LSP aware and performs switching based on MPLS
labels, and need not have any specific knowledge of the DetNet
service or the corresponding DetNet flow identification. See
<xref target="ip-over-mpls"/> for details on the mapping of IP
flows to MPLS, and <xref target="I-D.ietf-detnet-dp-sol-mpls"/>
for general support of DetNet services using MPLS.
</t>
<figure align="center" anchor="fig_non_detnet_ip"
title="Non-DetNet aware IP end systems with DetNet IP Domain">
<artwork><![CDATA[
IP Edge Edge IP
End System Node Node End System
+----------+ +.........+ +.........+ +----------+
| Appl. |<--:Svc Proxy:-- E2E Service ---:Svc Proxy:-->| Appl. |
+----------+ +.........+ +.........+ +----------+
| IP |<--:IP : :Svc:----- IP flow ----:Svc: :IP :-->| IP |
+----------+ +---+ +---+ +---+ +---+ +----------+
|Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding|
+--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+
: Link : \ ,-----. / / ,-----. \
+.......+ +-----[ Sub ]----+ +--[ Sub ]--+
[Network] [Network]
`-----' `-----'
|<--- IP --->| |<------ DetNet IP ------->| |<--- IP --->|
]]></artwork>
</figure>
<t>
<xref target="fig_non_detnet_ip"/> illustrates another variant of <xref
target="fig_ip_detnet_simple"/> where the end systems are not DetNet
aware. In this case, edge nodes sit at the boundary of the DetNet
domain and provide DetNet service proxies for the end applications by
initiating and terminating DetNet service for the application's IP
flows. The existing header information or an approach such as described
in <xref target="aggregation"/> can be used to support DetNet flow
identification.
</t>
<t>
Non-DetNet and DetNet IP packets are identical on the wire. From
data plane perspective, the only difference is that there is
flow-associated DetNet information on each DetNet node that
defines the flow related characteristics and required forwarding
behavior. As shown above, edge nodes provide a Service Proxy
function that "associates" one or more IP flows with the
appropriate DetNet flow-specific information and ensures that
the receives the proper traffic treatment within the domain.
</t>
<t>
Note: The operation of IEEE802.1 TSN end systems over DetNet
enabled IP networks is not described in this document. While
TSN flows could be encapsulated in IP packets by an IP End
System or DetNet Edge Node in order to produce DetNet IP flows,
the details of such are out of scope of this document.
</t>
</section>
<!-- ================================================================= -->
<!-- =================== General Encap considerations ================ -->
<!-- ================================================================= -->
<section title="DetNet IP Data Plane Considerations" anchor="dn-gen-encap-solution">
<t>
This section provides informative considerations related to
providing DetNet service to flows which are identified
based on their header information. At a high level, the
following are provided on a per flow basis:
<list style="hanging">
<t hangText="Congestion protection and latency control:">
<vspace blankLines="1"/>
Usage of allocated resources (queuing, policing, shaping) to ensure
that the congestion-related loss and latency/jitter requirements of
a DetNet flow are met.
</t>
<t hangText="Explicit routes:">
<vspace blankLines="1"/>
Use of a specific path for a flow. This limits
misordering and can improve delivery of deterministic latency.
</t>
<t hangText="Service protection:">
<vspace blankLines="1"/>
Which in the case of this document
translates to changing the explicit path after a failure is
detected in order to restore delivery of the required DetNet service
characteristics. Path changes, even in the case of failure
recovery, can lead to the out of order delivery of data.
</t>
<t>
Note: DetNet PREOF is not provided by the mechanisms defined in
this document.
</t>
<t hangText="Load sharing:">
<vspace blankLines="1"/>
Generally, distributing packets of the same DetNet flow over
multiple paths is not recommended. Such load sharing,
e.g., via ECMP or UCMP, impacts ordering and end-to-end jitter.
</t>
<t hangText="Troubleshooting:"> <vspace blankLines="1"/>
For example, to support identification of misbehaving flows.
</t>
<t hangText="Recognize flow(s) for analytics:"><vspace blankLines="1"/>
For example, increase counters.
</t>
<t hangText="Correlate events with flows:"><vspace blankLines="1"/>
For example, unexpected loss.
</t>
</list>
</t>
<section title="End-System Specific Considerations">
<t>
Data-flows requiring DetNet service are generated and terminated on
end systems. This document deals only with IP end systems. The
protocols used by an IP end system are specific to an application
and end systems peer with end systems using the same application
encapsulation format. This said, DetNet's use of 6-tuple IP flow
identification means that DetNet must be aware of not only the
format of the IP header, but also of the next protocol carried
within an IP packet.
</t>
<t>
When IP end systems are DetNet aware, no application-level or
service-level proxy functions are needed inside the DetNet domain.
For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain.
</t>
<t>
End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow. When
forwarding packets, this means that packets are
appropriately shaped on transmission and received appropriate traffic
treatment on the connected sub-network, see <xref target="QoS"/> and
<xref target="detrouting"/> for more details. When receiving packets,
this means that there are appropriate local node resources,
e.g., buffers, to receive and process a DetNet flow packets.
</t>
</section>
<section title="DetNet Domain-Specific Considerations">
<t>
As a general rule, DetNet IP domains need to be able to forward any
DetNet flow identified by the IP 6-tuple. Doing otherwise would limit
end system encapsulation format. From a practical standpoint this
means that all nodes along the end-to-end path of a DetNet flows need
to agree on what fields are used for flow identification, and the
transport protocols (e.g., TCP/UDP/IPsec) which can be used to
identify 6-tuple protocol ports.
</t>
<t>
From a connection type perspective two scenarios are identified:
<list style="numbers">
<t>
DN attached: end system is directly connected to an edge node or
end system is behind a sub-network. (See ES1 and ES2 in figure
below)
</t>
<t>
DN integrated: end system is part of the DetNet domain. (See ES3
in figure below)
</t>
</list>
</t>
<t>
L3 (IP) end systems may use any of these connection types. DetNet
domain allows communication between any end-systems using the
same encapsulation format, independent of their connection type and
DetNet capability. DN attached end systems have no knowledge about
the DetNet domain and its encapsulation format. See <xref
target="fig_es_con_types"/> for L3 end system connection scenarios.
</t>
<figure title="Connection types of L3 end systems" anchor="fig_es_con_types">
<artwork align="center"><![CDATA[
____+----+
+----+ _____ / | ES3|
| ES1|____ / \__/ +----+___
+----+ \ / \
+ |
____ \ _/
+----+ __/ \ +__ DetNet domain /
| ES2|____/ L2/L3 |___/ \ __ __/
+----+ \_______/ \_______/ \___/
]]>
</artwork></figure>
<section title="DetNet Routers" anchor="detrouting">
<t>
Within a DetNet domain, the DetNet enabled IP Routers
interconnect links and sub-networks to support end-to-end
delivery of DetNet flows. From a DetNet architecture
perspective, these routers are DetNet relays, as they must
be DetNet service aware. Such routers identify DetNet flows
based on the IP 6-tuple, and ensure that the DetNet service
required traffic treatment is provided both on the node and
on any attached sub-network.
</t>
<t>
This solution provides DetNet functions end to end, but does so on
a per link and sub-network basis. Congestion protection and
latency control and the resource allocation (queuing, policing,
shaping) are supported using the underlying link / sub net
specific mechanisms. However, service protections (packet
replication and packet elimination functions) are not provided at
the DetNet layer end to end. But such service protection can be
provided on a per underlying L2 link and sub-network basis.
</t>
<figure title="Encapsulation of DetNet Routing in simplified IP service L3 end-systems"
anchor="fig_simple_iprouting">
<artwork align="center"><![CDATA[
+------+ +------+
| X | | X |
+======+ +------+
End-system | IP | | IP |
-----+------+-------+======+--- --+======+--
DetNet |L2/SbN| |L2/SbN|
+------+ +------+
]]>
</artwork></figure>
<t>
The DetNet Service Flow is mapped to the link / sub-network
specific resources using an underlying system specific
means. This implies each DetNet aware node on path looks
into the forwarded DetNet Service Flow packet and utilize
e.g., a 5- (or 6-) tuple to find out the required mapping within
a node.
</t>
<t>
As noted earlier, the Service Protection is done within each
link / sub-network independently using the domain specific
mechanisms (due the lack of a unified end to end sequencing
information that would be available for intermediate nodes).
Therefore, service protection (if any) cannot be provided
end-to-end, only within sub-networks. This is shown for a three
sub-network scenario in <xref target="fig_pref_in_subnets"/>,
where each sub-network can provide service protection between
its borders.
</t>
<figure title="Replication and elimination in sub-networks for DetNet IP networks" anchor="fig_pref_in_subnets">
<artwork align="center">
<![CDATA[
______
____ / \__
____ / \__/ \___ ______
+----+ __/ +====+ +==+ \ +----+
|src |__/ SubN1 ) | | \ SubN3 \____| dst|
+----+ \_______/ \ Sub-Network2 | \______/ +----+
\_ _/
\ __ __/
\_______/ \___/
+---+ +---------E--------+ +-----+
+----+ | | | | | | | +----+
|src |----R E--------R +---+ E------R E------+ dst|
+----+ | | | | | | | +----+
+---+ +-----R------------+ +-----+
]]>
</artwork></figure>
<t>
If end to end service protection is desired that can be
implemented, for example, by the DetNet end systems using
Layer-4 (L4) transport protocols or application
protocols. However, these are out of scope of this document.
</t>
</section>
</section>
<section title="Networks With Multiple Technology Segments" anchor="nwsegments">
<!-- alternate title:
"Mapping DetNet IP Flows to Sub-Networks and Links">
-->
<t>
There are network scenarios, where the DetNet domain contains
multiple technology segments (IEEE 802.1 TSN, MPLS) and all those
segments are under the same administrative control (see <xref
target="fig_pref_xcrs_segments"/>). Furthermore, DetNet nodes may be
interconnected via TSN segments.
</t>
<t>
DetNet routers ensure that detnet service requirements are
met per hop by allocating local resources, both receive and
transmit, and by mapping the service requirements of each
flow to appropriate sub-network mechanisms. Such mapping is
sub-network technology specific. The mapping of DetNet IP
Flows to MPLS is covered <xref
target="ip-over-mpls"/>. The mapping of IP
DetNet Flows to IEEE 802.1 TSN is covered in <xref
target="mapping-tsn"/>.
</t>
<figure title="DetNet domains and multiple technology segments" anchor="fig_pref_xcrs_segments">
<artwork align="center"><![CDATA[
______
_____ / \__
____ / \__/ \___ ______
+----+ __/ +======+ +==+ \ +----+
|src |__/ Seg1 ) | | \ Seg3 \__| dst|
+----+ \_______+ \ Segment-2 | \+_____/ +----+
\======+__ _+===/
\ __ __/
\_______/ \___/
]]>
</artwork></figure>
</section>
<section title="OAM">
<t>
[Editor's note: This section is TBD. OAM may be dropped from
this document and left for future study.]
</t>
</section>
<section title="Class of Service">
<t>
Class and quality of service, i.e., CoS and QoS, are terms that are
often used interchangeably and confused. In the context of DetNet,
CoS is used to refer to mechanisms that provide traffic forwarding
treatment based on aggregate group basis and QoS is used to refer
to mechanisms that provide traffic forwarding treatment based on a
specific DetNet flow basis. Examples of existing network level CoS
mechanisms include DiffServ which is enabled by IP header
differentiated services code point (DSCP) field <xref
target="RFC2474"/> and MPLS label traffic class field <xref
target="RFC5462"/>, and at Layer-2, by IEEE 802.1p priority code
point (PCP).
</t>
<t>
CoS for DetNet flows carried in IPv6 is provided using the standard
differentiated services code point (DSCP) field <xref
target="RFC2474"/> and related mechanisms. The 2-bit explicit
congestion notification (ECN) <xref target="RFC3168"/> field MAY
also be used.
</t>
<t>
One additional consideration for DetNet nodes which support CoS
services is that they MUST ensure that the CoS service classes do
not impact the congestion protection and latency control mechanisms
used to provide DetNet QoS. This requirement is similar to
requirement for MPLS LSRs to that CoS LSPs do not impact the
resources allocated to TE LSPs via <xref target="RFC3473"/>.
</t>
</section>
<section title="Quality of Service" anchor="QoS">
<t>
Quality of Service (QoS) mechanisms for flow-specific traffic
treatment typically includes a guarantee/agreement for the service,
and allocation of resources to support the service. Example QoS
mechanisms include discrete resource allocation, admission control,
flow identification and isolation, and sometimes path control, traffic
protection, shaping, policing and remarking. Example protocols that
support QoS control include <xref target="RFC2205">Resource
ReSerVation Protocol (RSVP)</xref> (RSVP) and RSVP-TE <xref
target="RFC3209"/> and <xref target="RFC3473"/>. The existing MPLS
mechanisms defined to support CoS <xref target="RFC3270"/> can also be
used to reserve resources for specific traffic classes.
</t>
<t>
In addition to explicit routes, and packet replication and
elimination, DetNet provides zero congestion loss and bounded latency
and jitter. As described in <xref
target="I-D.ietf-detnet-architecture"/>, there are different
mechanisms that maybe used separately or in combination to deliver a
zero congestion loss service. These mechanisms are provided by the
either the MPLS or IP layers, and may be combined with the mechanisms
defined by the underlying network layer such as 802.1TSN.
</t>
<t>
A baseline set of QoS capabilities for DetNet flows carried in PWs
and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE)
<xref target="RFC3209"/> and <xref target="RFC3473"/>. TE LSPs can
also support explicit routes (path pinning). Current service
definitions for packet TE LSPs can be found in "Specification of
the Controlled Load Quality of Service", <xref target="RFC2211"/>,
"Specification of Guaranteed Quality of Service", <xref
target="RFC2212"/>, and "Ethernet Traffic Parameters", <xref
target="RFC6003"/>. Additional service definitions are expected in
future documents to support the full range of DetNet services.
In all cases, the existing label-based marking mechanisms defined
for TE-LSPs and even E-LSPs are use to support the identification
of flows requiring DetNet QoS.
</t>
<t>
QoS for DetNet service flows carried in IP MUST be provided locally by
the DetNet-aware hosts and routers supporting DetNet flows. Such
support will leverage the underlying network layer such as
802.1TSN. The traffic control mechanisms used to deliver QoS for
IP encapsulated DetNet flows are expected to be defined in a future
document. From an encapsulation perspective, the combination of the "6 tuple" i.e.,
the typical 5 tuple enhanced with the DSCP code, uniquely identifies a DetNet
service flow.
</t>
<t>
Packets that are marked with a DetNet Class of Service value,
but that have not been the subject of a completed reservation,
can disrupt the QoS offered to properly reserved DetNet flows
by using resources allocated to the reserved flows.
Therefore, the network nodes of a DetNet network must:
<list style="symbols">
<t>
Defend the DetNet QoS by discarding or remarking (to a
non-DetNet CoS) packets received that are not the subject
of a completed reservation. </t><t> Not use a DetNet
reserved resource, e.g. a queue or shaper reserved for
DetNet flows, for any packet that does not carry a DetNet
Class of Service marker.
</t>
</list>
</t>
</section>
<section title="Cross-DetNet Flow Resource Aggregation" anchor="aggregation">
<t>
The ability to aggregate individual flows, and their associated
resource control, into a larger aggregate is an important technique
for improving scaling of control in the data, management and
control planes. This document identifies the traffic identification
related aspects of aggregation of DetNet flows. The resource
control and management aspects of aggregation (including the
queuing/shaping/policing implications) will be covered in other
documents. The data plane implications of aggregation are
independent for PW/MPLS and IP encapsulated DetNet flows.
</t>
<t>
DetNet flows forwarded via IP have more limited aggregation
options, due to the available traffic flow identification fields of
the IP solution.
One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class. This
approach also requires that nodes support aggregation ensure that
traffic from aggregated LSPs are placed (shaped/policed/enqueued)
in a fashion that ensures the required DetNet service is preserved.
</t>
<t>
In both the MPLS and IP cases, additional details of the traffic control
capabilities needed at a DetNet-aware node may be covered in the
new service descriptions mentioned above or in separate future
documents. Management and control plane mechanisms will also need
to ensure that the service required on the aggregate flow (H-LSP or
DSCP) are provided, which may include the discarding or remarking
mentioned in the previous sections.
</t>
</section>
<!-- ===================================================================== -->
<section title="Time Synchronization">
<t>
While time synchronization can be important both from the perspective of
operating the DetNet network itself and from the perspective of
DetNet-based applications, time synchronization is outside the
scope of this document. This said, a DetNet node can also support
time synchronization or distribution mechanisms.
</t>
<t>
For example, <xref target="RFC8169"/> describes a method
of recording the packet queuing time in an MPLS LSR on a packet by
per packet basis and forwarding this information to the egress edge
system. This allows compensation for any variable packet queuing
delay to be applied at the packet receiver. Other mechanisms for
IP networks are
defined based on IEEE Standard 1588 <xref target="IEEE1588"/>,
such as ITU-T <xref target="G.8275.1"/> and <xref target="G.8275.2"/>.
</t>
<t>
A more detailed discussion of time synchronization is outside the
scope of this document.
</t>
</section>
</section>
<!-- ===================================================================== -->
<section title="Management and Control Considerations" anchor="m-cp-considerations">
<t>
While management plane and control planes are traditionally
considered separately, from the Data Plane perspective there is
no practical difference based on the origin of flow provisioning
information, and the DetNet architecture <xref
target="I-D.ietf-detnet-architecture"/> refers to these
collectively as the 'Controller Plane'. This document therefore
does not distinguish between information provided by distributed
control plane protocols, e.g., IGP routing protocols, or by
centralized network management mechanisms, e.g., RestConf <xref
target="RFC8040"/>, YANG <xref target="RFC7950"/>, and the Path
Computation Element Communication Protocol (PCEP) <xref
target="RFC8283"/> <xref target="I-D.ietf-teas-pce-native-ip"/>
or any combination thereof. Specific considerations and
requirements for the DetNet Controller Plane are discussed in
<xref target="control-management-requirements"/>.
</t>
<section title="Flow Identification and Aggregation">
<t>
<xref target="sec_dt_dp"/> introduces the use of the IP
"6-tuple" for flow identification, and <xref target="QoS"/>
goes on to discuss how identified flows use specific QoS
mechanisms for flow-specific traffic treatment, including path
control and resource allocation. <xref target="ip-flow-id"/>
contains detailed DetNet IP flow identification
procedures. Flow identification will play an important role
for the DetNet controller plane.
</t>
<t>
<xref target="aggregation"/> and <xref target="ip-agg"/>
discuss the use of flow aggregation in DetNet. Flow
aggregation can be accomplished using any of the 6-tuple
fields defined in <xref target="ip-flow-id"/>, using a DSCP
identified traffic class or other field. It will be the
responsibility of the DetNet controller plane to be able to
properly provision the use of these aggregation
mechanisms. These requirements are included in <xref
target="control-management-requirements"/>.
</t>
</section>
<section title="Explcit Routes">
<t>
Explicit routes are used to ensure that packets are routed
through the resources that have been reserved for them, and
hence provide the DetNet application with the required
service. A requirement for the DetNet Controller Plane will be
the ability to assign a particular identified DetNet IP flow
to a path through the DetNet domain that has been assigned the
required nodal resources to provide the appropriate traffic
treatment for the flow, and also to include particular links
as a part of the path that are able to support the DetNet
flow, for example by using IEEE 802.1 TSN links (as discussed
in <xref target="mapping-tsn"/>). Further considerations and
requirements for the DetNet Controller Plane are discussed in
<xref target="control-management-requirements"/>.
</t>
<t>
Whether configuring, calculating and instantiating these
routes is a single-stage or multi-stage process, or in a
centralized or distributed manner, is out of scope of this
document.
</t>
<t>
There are several of approaches that could be used to provide
explicit routes and resource allocation in the DetNet
layer. For example:
<list style="symbols">
<t>
The path could be explicitly set up by a controller which
calculates the path and explicitly configures each node
along that path with the appropriate forwarding and
resource allocation information.
</t>
<t>
The path could be used a distributed control plane such as
<xref target="RFC2205">RSVP</xref> or RSVP-TE <xref
target="RFC3473"/> extended to support DetNet IP flows.
</t>
<t>
The path could be implemented using IPv6-based segment
routing when extended to support resource allocation.
</t>
</list>
See <xref target="control-management-requirements"/> for
further discussion of these alternatives. In addition, <xref
target="RFC2386"/> contains useful background information on
QoS-based routing, and <xref target="RFC5575"/> discusses a
specific mechanism used by BGP for traffic flow specification
and policy-based routing.
</t>
</section>
<section title="Contention Loss and Jitter Reduction">
<t>
As discussed in <xref target="sec_intro"/>, this document does
not specify the mechanisms needed to eliminate contention loss
or reduce jitter for DetNet flows at the DetNet forwarding
sub-layer. The ability to manage node and link resources to
be able to provide these functions will be a necessary part of
the DetNet controller plane. It will also be necessary to be
able to control the required queuing mechanisms used to
provide these functions along a flow's path through the
network. See <xref target="ip-svc"/> and <xref
target="control-management-requirements"/> for further
discussion of these requirements.
</t>
</section>
<section title="Bidirectional Traffic">
<t>
Some DetNet applications generate bidirectional traffic.
Although this document discusses the DetNet IP data plane,
MPLS definitions <xref target="RFC5654"/> are useful to
illustrate terms such as associated bidirectional flows and
co-routed bidirectional flows. MPLS defines a point-to-point
associated bidirectional LSP as consisting of two
unidirectional point-to-point LSPs, one from A to B and the
other from B to A, which are regarded as providing a single
logical bidirectional forwarding path. This is analogous to
standard IP routing. MPLS defines a point-to-point co-routed
bidirectional LSP as an associated bidirectional LSP which
satisfies the additional constraint that its two
unidirectional component LSPs follow the same path (in terms
of both nodes and links) in both directions. An important
property of co-routed bidirectional LSPs is that their
unidirectional component LSPs share fate. In both types of
bidirectional LSPs, resource reservations may differ in each
direction. The concepts of associated bidirectional flows and
co-routed bidirectional flows can also be applied to DetNet IP
flows.
</t>
<t>
While the DetNet IP data plane must support bidirectional
DetNet flows, there are no special bidirectional features with
respect to the data plane other than the need for the two
directions of a co-routed bidirectional flow to take the same
path. That is to say that bidirectional DetNet flows are
solely represented at the management and control plane levels,
without specific support or knowledge within the DetNet data
plane. Fate sharing and associated vs. co-routed
bidirectional flows can be managed at the control level.
</t>
<t>
Control and management mechanisms will need to support
bidirectional flows, but the specification of such mechanisms
are out of scope of this document. An example control plane
solution for MPLS can be found in <xref target="RFC7551"/>.
</t>
<t>
This is further discussed in <xref
target="control-management-requirements"/>.
</t>
</section>
<section anchor="control-management-requirements"
title="DetNet Controller (Control and Management) Plane Requirements">
<t>
While the definition of controller plane for DetNet is out of
the scope of this document, there are particular
considerations and requirements for such that result from the
unique characteristics of the DetNet architecture <xref
target="I-D.ietf-detnet-architecture"/> and data plane as
defined herein.
</t>
<t>
The primary requirements of the DetNet controller plane are
that it must be able to:
<list style="symbols">
<t>
Instantiate DetNet flows in a DetNet domain (which may
include some or all of explicit path determination, link
bandwidth reservations, restricting flows to IEEE 802.1 TSN
links, node buffer and other resource reservations,
specification of required queuing disciplines along the
path, ability to manage bidirectional flows, etc.) as needed
for a flow.
</t>
<t>
The ability to support DetNet flow aggregation
</t>
<t>
Advertise static and dynamic node and link resources such
as capabilities and adjacencies to other network nodes (for
dynamic signaling approaches) or to network controllers (for
centralized approaches)
</t>
<t>
Scale to handle the number of DetNet flows expected in a
domain (which may require per-flow signaling or
provisioning)
</t>
<t>
Provision flow identification information at each of the
nodes along the path, and it may differ depending on the
location in the network and the DetNet functionality.
</t>
</list>
</t>
<t>
These requirements, as stated earlier, could be satisfied
using distributed control protocol signaling, centralized
network management provisioning mechanisms, or hybrid
combinations of the two, and could also make use of IPv6-based
segment routing.
</t>
<t>
In the abstract, the results of either distributed signaling
or centralized provisioning are equivalent from a DetNet data
plane perspective - flows are instantiated, explicit routes
are determined, resources are reserved, and packets are
forwarded through the domain using the IP data plane.
</t>
<t>
However, from a practical and implementation standpoint, they
are not equivalent at all. Some approaches are more scalable
than others in terms of signaling load on the network. Some
can take advantage of global tracking of resources in the
DetNet domain for better overall network resource
optimization. Some are more resilient than others if link,
node, or management equipment failures occur. While a detailed
analysis of the control plane alternatives is out of the scope
of this document, the requirements from this document can be
used as the basis of a later analysis of the alternatives.
</t>
</section>
</section>
<!-- ===================================================================== -->
<section anchor="ip-procs" title="DetNet IP Data Plane Procedures">
<t>
This section provides DetNet IP data plane procedures. These
procedures have been divided into the following areas: flow
identification, forwarding and traffic treatment. Flow
identification includes those procedures related to matching IP
and higher layer protocol header information to DetNet flow
(state) information and service requirements. Flow
identification is also sometimes called Traffic classification,
for example see <xref target="RFC5777"/>. Forwarding includes