draft-ietf-detnet-dp-sol-03.txt   draft-ietf-detnet-dp-sol-04.txt 
DetNet J. Korhonen, Ed. DetNet J. Korhonen, Ed.
Internet-Draft Nordic Internet-Draft Nordic
Intended status: Standards Track L. Andersson Intended status: Standards Track L. Andersson
Expires: September 6, 2018 Y. Jiang Expires: September 23, 2018 Y. Jiang
N. Finn N. Finn
Huawei Huawei
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
CJ. Bernardos CJ. Bernardos
UC3M UC3M
T. Mizrahi T. Mizrahi
Marvell Marvell
L. Berger L. Berger
LabN LabN
March 5, 2018 March 22, 2018
DetNet Data Plane Encapsulation DetNet Data Plane Encapsulation
draft-ietf-detnet-dp-sol-03 draft-ietf-detnet-dp-sol-04
Abstract Abstract
This document specifies Deterministic Networking data plane This document specifies Deterministic Networking data plane
encapsulation solutions. The described data plane solutions can be encapsulation solutions. The described data plane solutions can be
applied over either IP or MPLS Packet Switched Networks. applied over either IP or MPLS Packet Switched Networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on September 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
6.2. Data plane encapsulation . . . . . . . . . . . . . . . . 19 6.2. Data plane encapsulation . . . . . . . . . . . . . . . . 19
6.3. DetNet control word . . . . . . . . . . . . . . . . . . . 20 6.3. DetNet control word . . . . . . . . . . . . . . . . . . . 20
6.4. Flow identification . . . . . . . . . . . . . . . . . . . 21 6.4. Flow identification . . . . . . . . . . . . . . . . . . . 21
6.5. Service layer considerations . . . . . . . . . . . . . . 21 6.5. Service layer considerations . . . . . . . . . . . . . . 21
6.5.1. Edge node processing . . . . . . . . . . . . . . . . 22 6.5.1. Edge node processing . . . . . . . . . . . . . . . . 22
6.5.2. Relay node processing . . . . . . . . . . . . . . . . 23 6.5.2. Relay node processing . . . . . . . . . . . . . . . . 23
6.5.3. End system processing . . . . . . . . . . . . . . . . 25 6.5.3. End system processing . . . . . . . . . . . . . . . . 25
6.6. Transport node considerations . . . . . . . . . . . . . . 25 6.6. Transport node considerations . . . . . . . . . . . . . . 25
6.6.1. Congestion protection . . . . . . . . . . . . . . . . 25 6.6.1. Congestion protection . . . . . . . . . . . . . . . . 25
6.6.2. Explicit routes . . . . . . . . . . . . . . . . . . . 25 6.6.2. Explicit routes . . . . . . . . . . . . . . . . . . . 25
7. IPv6-based DetNet data plane solution . . . . . . . . . . . . 25 7. Simplified IP based DetNet data plane solution . . . . . . . 25
7.1. Data plane encapsulation . . . . . . . . . . . . . . . . 25 8. Other DetNet data plane considerations . . . . . . . . . . . 25
7.2. DetNet destination option . . . . . . . . . . . . . . . . 27 8.1. Class of Service . . . . . . . . . . . . . . . . . . . . 25
7.3. Flow identification . . . . . . . . . . . . . . . . . . . 28 8.2. Quality of Service . . . . . . . . . . . . . . . . . . . 26
7.4. Service layer considerations . . . . . . . . . . . . . . 28 8.3. Cross-DetNet flow resource aggregation . . . . . . . . . 27
7.4.1. Edge node processing . . . . . . . . . . . . . . . . 29 8.4. Bidirectional traffic . . . . . . . . . . . . . . . . . . 28
7.4.2. Relay node processing . . . . . . . . . . . . . . . . 31 8.5. Layer 2 addressing and QoS Considerations . . . . . . . . 29
7.4.3. End system processing . . . . . . . . . . . . . . . . 31 8.6. Interworking between MPLS- and IPv6-based encapsulations 29
7.5. Transport node processing . . . . . . . . . . . . . . . . 31 8.7. IPv4 considerations . . . . . . . . . . . . . . . . . . . 30
7.5.1. Congestion protection . . . . . . . . . . . . . . . . 31 9. Time synchronization . . . . . . . . . . . . . . . . . . . . 30
7.5.2. Explicit routes . . . . . . . . . . . . . . . . . . . 32 10. Management and control considerations . . . . . . . . . . . . 31
8. Other DetNet data plane considerations . . . . . . . . . . . 32 10.1. MPLS-based data plane . . . . . . . . . . . . . . . . . 32
8.1. Class of Service . . . . . . . . . . . . . . . . . . . . 32 10.1.1. S-Label assignment and distribution . . . . . . . . 32
8.2. Quality of Service . . . . . . . . . . . . . . . . . . . 32 10.1.2. Explicit routes . . . . . . . . . . . . . . . . . . 32
8.3. Cross-DetNet flow resource aggregation . . . . . . . . . 34 10.2. IPv6-based data plane . . . . . . . . . . . . . . . . . 32
8.4. Bidirectional traffic . . . . . . . . . . . . . . . . . . 35 10.2.1. Flow Label assignment and distribution . . . . . . . 32
8.5. Layer 2 addressing and QoS Considerations . . . . . . . . 35 10.2.2. Explicit routes . . . . . . . . . . . . . . . . . . 32
8.6. Interworking between MPLS- and IPv6-based encapsulations 36 10.3. Packet replication and elimination . . . . . . . . . . . 32
8.7. IPv4 considerations . . . . . . . . . . . . . . . . . . . 36 10.4. Congestion protection and latency control . . . . . . . 33
9. Time synchronization . . . . . . . . . . . . . . . . . . . . 36 10.5. Flow aggregation control . . . . . . . . . . . . . . . . 33
10. Management and control considerations . . . . . . . . . . . . 38 11. Security considerations . . . . . . . . . . . . . . . . . . . 33
10.1. MPLS-based data plane . . . . . . . . . . . . . . . . . 38 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33
10.1.1. S-Label assignment and distribution . . . . . . . . 38 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
10.1.2. Explicit routes . . . . . . . . . . . . . . . . . . 38 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.2. IPv6-based data plane . . . . . . . . . . . . . . . . . 38 14.1. Normative references . . . . . . . . . . . . . . . . . . 34
10.2.1. Flow Label assignment and distribution . . . . . . . 38 14.2. Informative references . . . . . . . . . . . . . . . . . 36
10.2.2. Explicit routes . . . . . . . . . . . . . . . . . . 39 Appendix A. Example of DetNet data plane operation . . . . . . . 37
10.3. Packet replication and elimination . . . . . . . . . . . 39 Appendix B. Example of pinned paths using IPv6 . . . . . . . . . 38
10.4. Congestion protection and latency control . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
10.5. Flow aggregation control . . . . . . . . . . . . . . . . 39
11. Security considerations . . . . . . . . . . . . . . . . . . . 39
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 39
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Normative references . . . . . . . . . . . . . . . . . . 40
14.2. Informative references . . . . . . . . . . . . . . . . . 42
Appendix A. Example of DetNet data plane operation . . . . . . . 43
Appendix B. Example of pinned paths using IPv6 . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides these flows extremely low a network to DetNet flows. DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency. packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in General background and concepts of DetNet can be found in
[I-D.ietf-detnet-architecture]. [I-D.ietf-detnet-architecture].
This document specifies the DetNet data plane and the on-wire This document specifies the DetNet data plane and the on-wire
skipping to change at page 16, line 12 skipping to change at page 16, line 12
further fields (e.g., explicit path information) to an existing IP further fields (e.g., explicit path information) to an existing IP
header may be impossible (e.g., due to security/encryption). header may be impossible (e.g., due to security/encryption).
Furthermore, DetNet domain IP-header format may collide with IP- Furthermore, DetNet domain IP-header format may collide with IP-
header format used by the source of a flow. Implementing such an header format used by the source of a flow. Implementing such an
approach requires that source encapsulation is in-line with DetNet approach requires that source encapsulation is in-line with DetNet
domain encapsulation format, however we do not intend to mandate end- domain encapsulation format, however we do not intend to mandate end-
systems' encapsulation format (see former text: As a general rule, systems' encapsulation format (see former text: As a general rule,
DetNet domains MUST be capable to forward any Data-flows and the DetNet domains MUST be capable to forward any Data-flows and the
DetNet domain MUST NOT intend to mandate end-system encapsulation DetNet domain MUST NOT intend to mandate end-system encapsulation
format.). format).
Another approach with IP PSN can be based on MPLS over IP [RFC4023]
and/or MPLS over UDP/IP [RFC7510]. In this case the encapsulations
over the PSNs were the same i.e., basically the DetNet MPLS-based
data plane encapsulation as described in Section 6.2 for both IP and
MPLS PSNs.
[Editor's node: this approach was actually proposed earlier in
draft-dt-detnet-dp-sol-00 in a PseudoWire context for IP PSN]
5.2.2.3. Simplified IP Service 5.2.2.3. Simplified IP Service
In this case there is no "tunneling" below the DetNet Service, but In this case there is no "tunneling" below the DetNet Service, but
the DetNet Service flows are mapped to each link / sub net using its the DetNet Service flows are mapped to each link / sub net using its
technology specific methods. The DetNet IP header containes the IP technology specific methods. The DetNet IP header containes the IP
address destination DetNet end system. The data-flow IP header MUST address destination DetNet end system. The data-flow IP header MUST
be preserved as-is. be preserved as-is.
This solution provides end to end DetNet service consisting of This solution provides end to end DetNet service consisting of
skipping to change at page 17, line 15 skipping to change at page 17, line 23
of scope of this document. of scope of this document.
[Editor's note: the service protection to be clarified further.] [Editor's note: the service protection to be clarified further.]
5.3. DetNet Inter-Working Function (DN-IWF) 5.3. DetNet Inter-Working Function (DN-IWF)
5.3.1. Networks with multiple technology segments 5.3.1. Networks with multiple technology segments
There are network scenarios, where the DetNet domain contains There are network scenarios, where the DetNet domain contains
multiple technology segments (IP, MPLS) and all those segments are multiple technology segments (IP, MPLS) and all those segments are
under the same administrative control. Furthermore, DetNet nodes may under the same administrative control (see Figure 10). Furthermore,
be interconnected via TSN segments. DetNet nodes may be interconnected via TSN segments.
An important aspect of DetNet network design is placement of DetNet An important aspect of DetNet network design is placement of DetNet
functions across the domain. Designs based on segment-by-segment functions across the domain. Designs based on segment-by-segment
optimization can provide only suboptimal solutions. In order to optimization can provide only suboptimal solutions. In order to
achieve global optimum Inter-Working Functions (DN-IWF) can be placed achieve global optimum Inter-Working Functions (DN-IWF) can be placed
at segment border nodes, which stich together DetNet flows across at segment border nodes, which stich together DetNet flows across
connected segments. connected segments.
DN-IWF may ensure that flow attributes are correlated across segment DN-IWF may ensure that flow attributes are correlated across segment
borders. For example, there are two DetNet functions which require borders. For example, there are two DetNet functions which require
skipping to change at page 23, line 38 skipping to change at page 23, line 38
The extended forwarder MAY copy the sequencing information from the The extended forwarder MAY copy the sequencing information from the
native DetNet packet into the DetNet sequence number field and vice native DetNet packet into the DetNet sequence number field and vice
versa. If there is no existing sequencing information available in versa. If there is no existing sequencing information available in
the native packet or the forwarder chose not to copy it from the the native packet or the forwarder chose not to copy it from the
native packet, then the extended forwarder MUST maintain a sequence native packet, then the extended forwarder MUST maintain a sequence
number counter for each DetNet flow (indexed by the DetNet flow number counter for each DetNet flow (indexed by the DetNet flow
identification). identification).
6.5.2. Relay node processing 6.5.2. Relay node processing
TBD.
A DetNet Relay node participates to the packet replication and A DetNet Relay node participates to the packet replication and
duplication elimination. This processing is done within an extended duplication elimination. This processing is done within an extended
forwarder function. Whether an ingress DetNet member flow receives forwarder function. Whether an ingress DetNet member flow receives
DetNet specific processing depends on how the forwarding is DetNet specific processing depends on how the forwarding is
programmed. For some DetNet member flows the relay node can act as a programmed. For some DetNet member flows the relay node can act as a
normal relay node and for some apply the DetNet specific processing normal relay node and for some apply the DetNet specific processing
(i.e., PREF). (i.e., PREF).
Comment #34 SB> Again relay node is not a normal term, so am not Comment #34 SB> Again relay node is not a normal term, so am not
sure what it does in the absence of a PREF function. sure what it does in the absence of a PREF function.
skipping to change at page 25, line 28 skipping to change at page 25, line 24
6.6. Transport node considerations 6.6. Transport node considerations
6.6.1. Congestion protection 6.6.1. Congestion protection
TBD. TBD.
6.6.2. Explicit routes 6.6.2. Explicit routes
TBD. TBD.
7. IPv6-based DetNet data plane solution 7. Simplified IP based DetNet data plane solution
7.1. Data plane encapsulation
Figure 16 illustrates a DetNet native IPv6 encapsulation. The native
IPv6 encapsulation is meant for end to end Detnet service use cases,
where the end stations are DetNet-aware (see Figure 3). Technically
it is possible to use the IPv6 encapsulation to tunnel any traffic
over a DetNet enabled network, which would make native IPv6
encapsulation also a valid data plane choice for an interconnect use
case (see Figure 1).
The native IPv6-based DetNet data plane encapsulation consists of:
o IPv6 header as the transport protocol.
o IPv6 header Flow Label that is used to help to identify a DetNet
flow (i.e., roughly an equivalent to an S-Label for the MPLS
encapsulation). A Flow Label together with the IPv6 source
address uniquely identifies a DetNet flow.
Comment #21 SB> Have we validated that it is unconditionally safe to
make this assumption about the use of the FL?
Discussion: RFC6437 does not restrict such use and DetNet DP
solution can always define their own use of flow label. It should
be noted that a DetNet aware node will always contain new code and
is not a load balancer.
o Zero, one or two DetNet Destination Options containing sequencing
information for packet replication and duplicate elimination
function (PREF), and/or packet reordering purposes. The DetNet
Destination Option is equivalent to the DetNet Control Word. If
PREF or packet reordering is not needed for the DetNet flow then
no DetNet Destination Option is inserted into the IPv6 header.
A DetNet-aware end station (a host) or an intermediate Detnet node
initiating an (or adding a tunnelling) IPv6 packet is responsible for
setting the Flow Label, adding the optional DetNet Destination
Option(s) for DetNet-s- or DetNet-st-flows, and possibly adding a
routing header such as the segment routing option (e.g., for pre-
defined paths [I-D.ietf-6man-segment-routing-header]). If a routing
header is inserted into the IPv6 packet for DetNet-s- or DetNet-st-
flows then a second instance of the DetNet Destination Option MUST be
added before the routing header (see Section 4.1 of [RFC8200]).
A DetNet-aware end station (a host) or an intermediate node receiving
an IPv6 packet destined to it and containing a DetNet Destination
Option does the appropriate processing of the packet. This may
involve packet duplication and elimination (PREF processing),
terminating a tunnel or delivering the packet to the upper layers/
Applications.
+---------------------------------+
| |
| DetNet Flow |
| Payload |
| |
/---------------------------------\
H Optional DetNet DstOpt Hdr H
\---------------------------------/
| IPv6 header |
| (with set Flow label) |
+---------------------------------+
Figure 16: Encapsulation of a native IPv6 DetNet-s- or DetNet-st-flow
without a routing header
Figure 17 illustrates an IPv6 packet for the case where a routing
header has been added into the packet by a DetNet-aware end system
(again assuming DetNet-s- or DetNet-st-flows). Note that the use of
routing header such as the one with the segment routing option is not
mandatory for explicit routes. Similar functionality can be arranged
using other means as well (e.g., using policy routing or layer-2
means).
+---------------------------------+
| |
| DetNet Flow |
| Payload |
| |
/---------------------------------\
H DetNet DstOpt Hdr H
\---------------------------------/
| Routing header |
/---------------------------------\
H DetNet DstOpt Hdr H
\---------------------------------/
| IPv6 header |
| (with set Flow label) |
+---------------------------------+
Figure 17: Encapsulation of a native IPv6 DetNet-s- or DetNet-st-
flows with routing header
IPv6 extension headers can only be inserted by a node that initiated
the IPv6 packet. IPv6 extension headers, except for the Hop-by-Hop
Option headers, can only be processed by an IPv6 node that is
identified by the Destination Address field of the IPv6 header (see
Section 0 of [RFC8200]. Therefore, if a DetNet-aware end system only
inserted the DetNet Destination Option into the IPv6 but e.g., a
DetNet Edge node is configured to enforce an explicit route for the
IPv6 packet using a source routing header, then it has no other
possibility than add an outer tunneling IPv6 header with required
extension headers in it. The processing of IPv6 packets in a DetNet
Edge node is discussed further in Section 7.4.1.
7.2. DetNet destination option
A DetNet flow must carry sequencing information for packet
replication and elimination function (PREF) purposes. This document
specifies a new IPv6 Destination Option: the DetNet Destination
Option for that purpose. The format of the option is illustrated in
Figure 18.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD1 | 4 | 0 | 28 bit sequence
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: DetNet Destination Option
The Option Type for the DetNet Destination Option is set to TBD1.
[To be removed from the final version of the document: The Option
Type MUST have the two most significant bits set to 10b]
If an IPv6 packet gets dropped due the DetNet Service layer
processing based on the DetNet Destination Option an ICMPv6 packet of
any type MUST NOT be sent back to the source of the packet.
7.3. Flow identification
The DetNet flow identification is based on the IPv6 Flow Label and
the source address combination. The two fields uniquelly identify
the end to end native IPv6 encapsulated DetNet flow. Obviously, the
identification fails if any intermediate node modifies either the
source address or the Flow Label.
Comment #27 SB> See earlier. If there are enough IPv6 addresses to
address video fragments, why not DN flows? Then this problem goes
away.
Discussion: See the earlier comment #25 discussion. If nodes get
their addressies via DHCPv6 basically ruins this mechanism. Also
the assumption for this to work is that the node has a full /64 to
use, which is not always the case. Otherwise the idea is just
fine.
7.4. Service layer considerations
[Editor's note: this section is TBD. It will detail the PREF
functionality.]
o PREF - requires both flow identification and sequence numbering.
o Packet reordeing - requires both flow identification and sequence
numbering.
A DetNet service layer processing can be done at each DetNet node
that matches the IPv6 header's Destination Address. Then, if the
DetNet flow identification provides a positive match for the DetNet
flow that the node has a service layer state installed e.g., for PREF
or packet reordering purposes, further service layer processing takes
place. In a case of PREF or packet reordering that means processing
the DetNet Destination Option for the identified DetNet flow.
7.4.1. Edge node processing
[Editor's note: This is the start of the IPv6 handling text - there
are errors and bad language. The founding assumption is the use of
source routing when intermediate nodes (relays/edges) need to modify
packets. This is due the text in RFC8200 and the fact that without
hph options only routing+dsthdr is usable with intermediates under
strict RFC8200.. ]
[Editor's note: Regrading the source routing and the "example" SRv6
approach. Current text is based on the assumption that intermediates
cannot add/delete extension headers such as the SRv6. That said
adding adding a header implies adding a tunneling outer IPv6 header
and deleting a header implies a tunnel decapsulation. This is not
probably desired due to the involved overhead and to be discussed
whether it is possible/acceptable to just "process" the Application
flow packets.]
For a DetNet Edge node there are several scenarios that involve
modifications to the DetNet flow IPv6 packets. The assumption is
that a DetNet-aware end system has always set the IPv6 header flow
label properly for the flow identification purposes. A DetNet- or
DetNet-t-flow does not include the DetNet Destination Option.
Following cases have been identified:
1. A DetNet App-flow or a DetNet-t-flow packet arrives at an ingress
DetNet Edge node and DetNet service layer functions are done only
at DetNet Edge nodes. Possible explicit routes between edge
nodes are arranged by other than IPv6 specific means.
2. A DetNet App-flow or a DetNet-t-flow packet arrives at an ingress
DetNet Edge node and multiple DetNet Relay nodes may process
DetNet flow packets before reaching an egress DetNet Edge node.
Explicit routes between edge nodes has to be arranged by IPv6
specific means.
3. A DetNet-s- or a DetNet-st-flow packet arrives at an ingress
DetNet Edge node and DetNet service layer functions are done only
at DetNet Edge nodes. Possible explicit routes between edge
nodes are arranged by other than IPv6 specific means.
4. A DetNet-s- or a DetNet-st-flow packet arrives at an ingress
DetNet Edge node and multiple DetNet Relay nodes may process
DetNet flow packets before reaching an egress DetNet Edge node.
Explicit routes between edge nodes has to be arranged by IPv6
specific means.
A generic DetNet IPv6 encapsulation for a DetNet flow packet between
DetNet Edge nodes is shown in Figure 19. Essentially every time an
igress DetNet Edge node has to insert something into the DetNet flow
packet it has to add an outer tunneling IPv6 header, which then
contain possible additional extension headers.
+---------------------------------+
| |
| DetNet Flow |
| Payload |
| |
+---------------------------------+
| Optional DetNet DstOpt Hdr (1) |
+---------------------------------+
| Inner IPv6 header |
| (with set Flow label) (1) |
+---------------------------------+ <--+
| Optional Routing header | |
+---------------------------------+ |
| Optional DetNet DstOpt Hdr (2) | +-- Added/removed by
+---------------------------------+ | DetNet Edge node
| Outer IPv6 header | |
| (with set Flow label) (2) | |
+---------------------------------+ <--+
Figure 19: Encapsulation of a DetNet-flow IPv6 packet at the DetNet
Edge node
7.4.1.1. Ingress DetNet Edge node processing
Case 1) MAY require an addition of the DetNet Destination Option if
packet reordering is requested at the egress DetNet Edge node.
Otherwise, no modifications except rewriting the IPv6 header flow
label to the packet is done. If modifications are required then:
o The outer IPv6 header is added with the Source Address set to the
ingress DetNet Edge node address and the Destination Address set
to the egress DetNet Edge node address.
o The flow label of the outer IPv6 header SHOULD be set to a value
maintained by the edge node.
o The DetNet Destination Option with the edge node managed per
DetNet flow sequence number value is inserted into the outer IPv6
header.
Case 2) requires an addition of the DetNet Destination Option unless
neither packet reordeing or PREF is enable at any DetNet Edge/Relay
node. A source routing header has to be added for the explicit route
purposes. An example of the source routing header is the Segment
Routing header. The following modifications to DetNet flow IPv6
packets are required:
o An outer IPv6 header is added with the Source Address set to the
ingress DetNet Edge node address and the Destination Address set
to the egress DetNet Edge node address.
o The flow label of the outer IPv6 header SHOULD be set to a value
maintained by the edge node.
o The DetNet Destination Option with the edge node managed per
DetNet flow sequence number value MAY be inserted into the outer
IPv6 header.
o A source routing header with addresses of those DetNet Relay nodes
that must be traversed is inserted into the outer IPv6 header.
Case 3) ...[Editor's note: is it OK if the sequece number added here
by the edge node has only local significance between the edge nodes
and not end to end between end systems? ]
Case 4) ...
7.4.1.2. Engress DetNet Edge node processing
7.4.2. Relay node processing
TBD.
7.4.3. End system processing
TBD.
7.5. Transport node processing [Editor's note: describe the 6 tuple way of doing DetNet service
flows. Also stress that PREF is per network segment as described in
Section 5.3.1]
7.5.1. Congestion protection Section 5.2.2.3 illustrated the case for DetNet simplified IP data
7.5.2. Explicit routes plane solution.
8. Other DetNet data plane considerations 8. Other DetNet data plane considerations
8.1. Class of Service 8.1. Class of Service
Class and quality of service, i.e., CoS and QoS, are terms that are Class and quality of service, i.e., CoS and QoS, are terms that are
often used interchangeably and confused. In the context of DetNet, often used interchangeably and confused. In the context of DetNet,
CoS is used to refer to mechanisms that provide traffic forwarding CoS is used to refer to mechanisms that provide traffic forwarding
treatment based on aggregate group basis and QoS is used to refer to treatment based on aggregate group basis and QoS is used to refer to
mechanisms that provide traffic forwarding treatment based on a mechanisms that provide traffic forwarding treatment based on a
skipping to change at page 33, line 30 skipping to change at page 27, line 9
(path pinning). Current service definitions for packet TE LSPs can (path pinning). Current service definitions for packet TE LSPs can
be found in "Specification of the Controlled Load Quality of be found in "Specification of the Controlled Load Quality of
Service", [RFC2211], "Specification of Guaranteed Quality of Service", [RFC2211], "Specification of Guaranteed Quality of
Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003].
Additional service definitions are expected in future documents to Additional service definitions are expected in future documents to
support the full range of DetNet services. In all cases, the support the full range of DetNet services. In all cases, the
existing label-based marking mechanisms defined for TE-LSPs and even existing label-based marking mechanisms defined for TE-LSPs and even
E-LSPs are use to support the identification of flows requiring E-LSPs are use to support the identification of flows requiring
DetNet QoS. DetNet QoS.
QoS for DetNet flows carried in IPv6 MUST be provided locally by the QoS for DetNet service flows carried in IP MUST be provided locally
DetNet-aware hosts and routers supporting DetNet flows. Such support by the DetNet-aware hosts and routers supporting DetNet flows. Such
will leverage the underlying network layer such as 802.1TSN. The support will leverage the underlying network layer such as 802.1TSN.
traffic control mechanisms used to deliver QoS for IP encapsulated The traffic control mechanisms used to deliver QoS for IP
DetNet flows are expected to be defined in a future document. From encapsulated DetNet flows are expected to be defined in a future
an encapsulation perspective, and as defined in Section 7, the document. From an encapsulation perspective, and as defined in
combination of the Flow Label together with the IP source address Section 7, the combination of the "6 tuple" i.e., the typical 5 tuple
uniquely identifies a DetNet flow. enhanced with the DSCP code, uniquely identifies a DetNet service
flow.
Packets that are marked with a DetNet Class of Service value, but Packets that are marked with a DetNet Class of Service value, but
that have not been the subject of a completed reservation, can that have not been the subject of a completed reservation, can
disrupt the QoS offered to properly reserved DetNet flows by using disrupt the QoS offered to properly reserved DetNet flows by using
resources allocated to the reserved flows. Therefore, the network resources allocated to the reserved flows. Therefore, the network
nodes of a DetNet network MUST: nodes of a DetNet network MUST:
o Defend the DetNet QoS by discarding or remarking (to a non-DetNet o Defend the DetNet QoS by discarding or remarking (to a non-DetNet
CoS) packets received that are not the subject of a completed CoS) packets received that are not the subject of a completed
reservation. reservation.
skipping to change at page 41, line 32 skipping to change at page 35, line 16
in Multi-Protocol Label Switching (MPLS) Networks", in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003, RFC 3443, DOI 10.17487/RFC3443, January 2003,
<https://www.rfc-editor.org/info/rfc3443>. <https://www.rfc-editor.org/info/rfc3443>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>. <https://www.rfc-editor.org/info/rfc3473>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, (GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005, DOI 10.17487/RFC4206, October 2005,
<https://www.rfc-editor.org/info/rfc4206>. <https://www.rfc-editor.org/info/rfc4206>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>. February 2006, <https://www.rfc-editor.org/info/rfc4385>.
skipping to change at page 42, line 14 skipping to change at page 36, line 5
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
RFC 6003, DOI 10.17487/RFC6003, October 2010, RFC 6003, DOI 10.17487/RFC6003, October 2010,
<https://www.rfc-editor.org/info/rfc6003>. <https://www.rfc-editor.org/info/rfc6003>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, Aissaoui, "Segmented Pseudowire", RFC 6073,
DOI 10.17487/RFC6073, January 2011, DOI 10.17487/RFC6073, January 2011,
<https://www.rfc-editor.org/info/rfc6073>. <https://www.rfc-editor.org/info/rfc6073>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
14.2. Informative references 14.2. Informative references
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
Field, B., daniel.voyer@bell.ca, d., Field, B., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
Header (SRH)", draft-ietf-6man-segment-routing-header-08 Header (SRH)", draft-ietf-6man-segment-routing-header-09
(work in progress), January 2018. (work in progress), March 2018.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-04 (work in progress), October 2017. detnet-architecture-04 (work in progress), October 2017.
[I-D.ietf-detnet-dp-alt] [I-D.ietf-detnet-dp-alt]
Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., Korhonen, J., Farkas, J., Mirsky, G., Thubert, P.,
Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol
and Solution Alternatives", draft-ietf-detnet-dp-alt-00 and Solution Alternatives", draft-ietf-detnet-dp-alt-00
 End of changes. 15 change blocks. 
359 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/