draft-ietf-detnet-dp-sol-00.txt   draft-ietf-detnet-dp-sol-01.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: May 3, 2018 Y. Jiang Expires: August 2, 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
October 30, 2017 January 29, 2018
DetNet Data Plane Encapsulation DetNet Data Plane Encapsulation
draft-ietf-detnet-dp-sol-00 draft-ietf-detnet-dp-sol-01
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.
Comment #1: SB> An overarching comment is that the early part of the
document is really fundamental architecture and perhaps belongs in
the arch draft, leaving this draft to be more specific about
solutions. Indeed if we cannot find a single solution that maps to
both IP and MPLS underlays I wonder if we should publish two
specialist RFCs?
Discussion: One document at the beginning, split into two if/when
needed. Would be post adoption in any case.
Comment #2: SB> Whilst I think we should look for a common solution
to IP and MPLS I do not think that this is where the DT ended up.
Discussion: Agree.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 3, 2018. This Internet-Draft will expire on August 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms used in this document . . . . . . . . . . . . . . . 5 2.1. Terms used in this document . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements language . . . . . . . . . . . . . . . . . . . . 8 3. Requirements language . . . . . . . . . . . . . . . . . . . . 6
4. DetNet data plane overview . . . . . . . . . . . . . . . . . 8 4. DetNet data plane overview . . . . . . . . . . . . . . . . . 6
4.1. DetNet data plane encapsulation requirements . . . . . . 10 4.1. DetNet data plane encapsulation requirements . . . . . . 8
5. DetNet data plane solution . . . . . . . . . . . . . . . . . 12 4.2. Packet replication and elimination considerations . . . . 10
5.1. DetNet specific packet fields . . . . . . . . . . . . . . 12 4.3. Packet reordering considerations . . . . . . . . . . . . 10
5.2. DetNet encapsulation . . . . . . . . . . . . . . . . . . 12 5. MPLS-based DetNet data plane solution . . . . . . . . . . . . 10
5.2.1. PseudoWire-based data plane encapsulation . . . . . . 13 5.1. DetNet specific packet fields . . . . . . . . . . . . . . 10
5.2.2. Native IPv6-based data plane encapsulation . . . . . 15 5.2. Data plane encapsulation . . . . . . . . . . . . . . . . 11
5.3. DetNet flow identification for duplicate detection . . . 17 5.3. DetNet control word . . . . . . . . . . . . . . . . . . . 12
5.3.1. PseudoWire encapsulation . . . . . . . . . . . . . . 17 5.4. Flow identification . . . . . . . . . . . . . . . . . . . 13
5.3.2. Native IPv6 encapsulation . . . . . . . . . . . . . . 18 5.5. Service layer considerations . . . . . . . . . . . . . . 13
6. PREF specific considerations . . . . . . . . . . . . . . . . 18 5.5.1. Edge node processing . . . . . . . . . . . . . . . . 13
6.1. PseudoWire-based data plane . . . . . . . . . . . . . . . 18 5.5.2. Relay node processing . . . . . . . . . . . . . . . . 15
6.1.1. Forwarder clarifications . . . . . . . . . . . . . . 18 5.5.3. End system processing . . . . . . . . . . . . . . . . 17
6.1.2. Edge node processing clarifications . . . . . . . . . 19 5.6. Transport node considerations . . . . . . . . . . . . . . 17
6.1.3. Relay node processing clarifications . . . . . . . . 21 5.6.1. Congestion protection . . . . . . . . . . . . . . . . 17
6.2. Native IPv6-based data plane . . . . . . . . . . . . . . 23 5.6.2. Explicit routes . . . . . . . . . . . . . . . . . . . 17
7. Other DetNet data plane considerations . . . . . . . . . . . 23 6. IPv6-based DetNet data plane solution . . . . . . . . . . . . 17
7.1. Class of Service . . . . . . . . . . . . . . . . . . . . 23 6.1. Data plane encapsulation . . . . . . . . . . . . . . . . 17
6.2. DetNet destination option . . . . . . . . . . . . . . . . 19
6.3. Flow identification . . . . . . . . . . . . . . . . . . . 20
6.4. Service layer considerations . . . . . . . . . . . . . . 20
6.4.1. Edge node processing . . . . . . . . . . . . . . . . 21
6.4.2. Relay node processing . . . . . . . . . . . . . . . . 23
6.4.3. End system processing . . . . . . . . . . . . . . . . 23
6.5. Transport node processing . . . . . . . . . . . . . . . . 23
6.5.1. Congestion protection . . . . . . . . . . . . . . . . 23
6.5.2. Explicit routes . . . . . . . . . . . . . . . . . . . 24
7. Other DetNet data plane considerations . . . . . . . . . . . 24
7.1. Class of Service . . . . . . . . . . . . . . . . . . . . 24
7.2. Quality of Service . . . . . . . . . . . . . . . . . . . 24 7.2. Quality of Service . . . . . . . . . . . . . . . . . . . 24
7.3. Cross-DetNet flow resource aggregation . . . . . . . . . 25 7.3. Cross-DetNet flow resource aggregation . . . . . . . . . 26
7.4. Bidirectional traffic . . . . . . . . . . . . . . . . . . 26 7.4. Bidirectional traffic . . . . . . . . . . . . . . . . . . 27
7.5. Layer 2 addressing and QoS Considerations . . . . . . . . 27 7.5. Layer 2 addressing and QoS Considerations . . . . . . . . 27
7.6. Interworking between PW- and IPv6-based encapsulations . 27 7.6. Interworking between MPLS- and IPv6-based encapsulations 28
8. Time synchronization . . . . . . . . . . . . . . . . . . . . 27 7.7. IPv4 considerations . . . . . . . . . . . . . . . . . . . 28
9. Management and control considerations . . . . . . . . . . . . 29 8. Time synchronization . . . . . . . . . . . . . . . . . . . . 28
9.1. PW Label and IPv6 Flow Label assignment and distribution 29 9. Management and control considerations . . . . . . . . . . . . 30
9.2. Packet replication and elimination . . . . . . . . . . . 30 9.1. MPLS-based data plane . . . . . . . . . . . . . . . . . . 30
9.3. Explicit paths . . . . . . . . . . . . . . . . . . . . . 30 9.1.1. S-Label assignment and distribution . . . . . . . . . 30
9.4. Congestion protection and latency control . . . . . . . . 30 9.1.2. Explicit routes . . . . . . . . . . . . . . . . . . . 30
9.5. Flow aggregation control . . . . . . . . . . . . . . . . 30 9.2. IPv6-based data plane . . . . . . . . . . . . . . . . . . 30
10. Security considerations . . . . . . . . . . . . . . . . . . . 30 9.2.1. Flow Label assignment and distribution . . . . . . . 30
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 9.2.2. Explicit routes . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 9.3. Packet replication and elimination . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Congestion protection and latency control . . . . . . . . 31
13.1. Normative references . . . . . . . . . . . . . . . . . . 31 9.5. Flow aggregation control . . . . . . . . . . . . . . . . 31
13.2. Informative references . . . . . . . . . . . . . . . . . 33 10. Security considerations . . . . . . . . . . . . . . . . . . . 31
Appendix A. Example of DetNet data plane operation . . . . . . . 34 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Example of pinned paths using IPv6 . . . . . . . . . 35 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.1. Normative references . . . . . . . . . . . . . . . . . . 32
13.2. Informative references . . . . . . . . . . . . . . . . . 34
Appendix A. Example of DetNet data plane operation . . . . . . . 35
Appendix B. Example of pinned paths using IPv6 . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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. It defines how DetNet This document specifies the DetNet data plane and the on-wire
traffic is encapsulated at the network layer, and how DetNet-aware encapsulation of DetNet flows. The specified encapsulation provides
nodes can identity DetNet flows. Two data plane definitions are the building blocks to enable the DetNet service layer functions and
given. allow flow identification as described in the DetNet Architecture.
Two data plane definitions are given.
o PW-based: One solution is based on PseudoWires (PW) [RFC3985] and
[RFC5036] and makes use of multi-segment pseudowires (MS-PW)
[RFC6073] to map DetNet Relay and Edge Nodes
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-dp-alt] to PW
architecture. The PW-based data plane can be run over an MPLS
[RFC4448] [RFC6658] Packet Switched Network (PSN).
Comment #3: SB> This is really an MPLS one. The world of IP PWs is
a bit scruffy with some work in PWE3 and some in L2TPext which
really went their own ways. There is for example no MS-PW IP
design. The MS-PW approach needs to be examined more closely by
the WG and thus at this stage be marked as provisional.
Discussion: Agree. "can be" -> "is".
Comment #3.1 LB> EVPN-based encapsulation is also a potential
candidate. In general DetNet should look more closely to the
delevopment around EVPN.
Discussion Agree. EVPN could be a potential solution and the on-
wire encapsuations are likely to be the same as PW-based
encapsulation would be. EVPN even recommends using Control Word
[RFC8214] (in the absence of entropy labels).
o Native-IP: The other solution is based on IP header fields, namely
on the IPv6 Flow Label and a new DetNet Control Word extension
header option. It is targeted for native IPv6 networks.
Comment #4: SB> The IP solution has not been properly examined by
the WG and needs to be marked as provisional.
Discussion: IP vs. MPLS is a deployment choice.
It is worth noting that while PWs are designed to work over IP PSNs
this document describes a native-IP solution that operates without
PWs. The primary reason for this is the benefit gained by enabling
the use of a normal application stack, where transport protocols such
as TCP or UDP are directly encapsulated in IP.
Comment #5: SB> We clearly need to look at the implications of 1. MPLS-based: The enacapsulation resembles PseudoWires (PW) with an
running this with a new IP header extension. Firstly we need input MPLS Packet Switched Network (PSN) [RFC3985][RFC4385].
from 6man, but we also need to understand what happens in middle
boxes, other components of the host stack etc.
Discussion: A WG can develop their own extensions and then get 2. Native-IP-based: The encapsulating protocol is IPv6 and the
approval from 6man. Sometimes that ends up redoing extensions in solution relies on IP header fields, existing and DetNet specific
6man but not always. IPv6 eaxtension header options [RFC8200].
This document specifies the encapsulation for DetNet flows, including [Editor's note: MPLS- and IPv6-based solutions are likely to be
a DetNet Control Word (CW). Furthermore, it describes how DetNet split into different documents.]
flows are identified, how DetNet Relay and Edge nodes work, and how
the Packet Replication and Elimination function (PREF) is implemented
with these two data plane solutions. This document does not define
the associated control plane functions, or Operations,
Administration, and Maintenance (OAM). It also does not specify
traffic handling capabilities required to deliver congestion
protection and latency control to DetNet flows as this is defined to
be provided by the underlying MPLS or IP network.
Comment #6: SB> OK, although I think that this may be a mistake. It is worth noting that while MPLS-based solution can transport IP
There may well be some coupling needed between the Detnet DP and packets a native-IP solution is meant for deployments where the
the substrate/transport/underlay needed to make this work. If this DetNet service layer functions are provided at the IP-layer rather
is a genuine technical layering we should talk about it. If this than the underlying transport network. The primary reason for this
is an artificial constraint imposed by the IESG we need to talk to is the benefit gained by enabling the use of a normal application
them. stack, where transport protocols such as TCP or UDP are directly
encapsulated in IP.
Discussion: The only interaction needed is that the flow The DetNet transport layer functionality that provides congestion
identification is possible. That needs to be available for lower protection for DetNet flows is assumed to be in place in a DetNet
layers. node.
Comment #6.1: LA> Even though this document does not specify any OAM Furthermore, this document also describes how DetNet flows are
functions, we will need to verify that the GACh (Generalized identified, how a DetNet Relay/Edge/Transit nodes work, and how the
Associate Channel) works correctly in a network that has Packet Replication and Elimination function (PREF) is implemented
replication and elimination. with the two data plane solutions.
Discussion: -- This document does not define the associated control plane functions,
or Operations, Administration, and Maintenance (OAM). It also does
not specify traffic handling capabilities required to deliver
congestion protection and latency control for DetNet flows at the
DetNet transport layer.
2. Terminology 2. Terminology
2.1. Terms used in this document 2.1. Terms used in this document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [I-D.ietf-detnet-architecture] and the DetNet Data Plane architecture [I-D.ietf-detnet-architecture] and the DetNet Data Plane
Solution Alternatives [I-D.ietf-detnet-dp-alt]. Solution Alternatives [I-D.ietf-detnet-dp-alt].
The following terms are also used in this document:
DA-T-PE MPLS based DetNet edge node: a DetNet-aware PseudoWire
Terminating Provider Edge (T-PE).
DA-S-PE MPLS based DetNet relay node: a DetNet-aware PseudoWire
Switching Provider Edge (S-PE).
Comment #7 SB> We need to look at whether the S-PE concept is the
best fit, or whether we should use introduce a Detnet relay to do
this. An S-PE just swaps the PW label, but Detnet needs it to do
more and a better model might be a new construct. However we
could also discard the relay concept and run 1+n end to end, in
which case the S-PEs would retain heir original function.
Discussion: Disagree of the dropping comment. However, the issues
are most likely terminology related. The relay concept is part of
the DetNet architecture A DA-S-PE was intended to be a DetNet
relay, which may do more than just swapping labels (PREF
functionality). Current text is quite biased to MS-PW, which was
the starting point for the DetNet relay in a MPLS PW network.
T-Label A label used to identify the LSP used to transport a T-Label A label used to identify the LSP used to transport a
DetNet flow across an MPLS PSN, e.g., a hop-by-hop DetNet flow across an MPLS PSN, e.g., a hop-by-hop
label used between label switching routers (LSR). label used between label switching routers (LSR).
S-Label A DetNet node to DetNet node "service" label that is S-Label A DetNet "service" label that is used between DetNet
used between DA-*-PE devices. nodes that implment also the DetNet service layer
functions. An S-Label is also used to identify a
PW Label A PseudoWire label that is used to identify DetNet flow DetNet flow at DetNet service layer.
related PW Instances within a PE node.
Flow Label IPv6 header field that is used to identify a DetNet Flow Label IPv6 header field that is used to identify a DetNet
flow (together with the source IP address field). flow (together with the source IP address field).
Comment #8 SB> If this is the IPv6 Flow label I think caution is Local-ID A DetNet Edge and Relay node internal construct that
needed as I don't think the handling of this is well defined or uniquely identifies a DetNet flow within a node and
consistently implemented in networking equipment. never appear on-wire. It may be used to select proper
forwarding and/or DetNet specific service function.
Discussion: DetNet specifies the use and discusses possible
interaction with RFC6347 in this I-D.
local-ID An edge and relay node internal construct that uniquely
identifies a DetNet flow. It may be used to select
proper forwarding and/or DetNet specific service
function.
Comment #9 SB> Is this really an internal construct, or is it an on
the wire construct? If it is needed end to end, I don't think it
is correct to describe it as an internal construct. When you say
"select" presumably you mean by potentially any DN aware node on
the path?
Discussion: It is an internal construct, so yes.
PREF A Packet Replication and Elimination Function (PREF) PREF A Packet Replication and Elimination Function (PREF)
does the replication and elimination processing of does the replication and elimination processing of
DetNet flow packets in edge or relay nodes. The DetNet flow packets in edge or relay nodes. The
replication function is essentially the existing 1+1 replication function is essentially the existing 1+1
protection mechanism. The elimination function reuses protection mechanism. The elimination function reuses
and extends the existing duplicate detection mechanism and extends the existing duplicate detection mechanism
to operate over multiple (separate) DetNet member flows to operate over multiple (separate) DetNet member flows
of a DetNet compound flow. of a DetNet compound flow.
Comment #10 SB> I wonder if 1+1 is the right way to go, or whether DetNet Control Word A control word used for sequencing and
1+n is better. A bunch of new techniques have emerged over the identifying duplaicate packets at the DetNet service
years and we really ought to look at creating paths with MRT. layer.
With 1+2 on main + the two MRT paths you have a two failure
resiliency as far as it is possible to construct such paths in the
underlying topology.
Discussion: As observed above, actually 1+n would be closer to what
is needed. 1+1 was meant to be more an example showing there is
existing work that can be leveraged.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations used in this document: The following abbreviations used in this document:
AC Attachment Circuit. AC Attachment Circuit.
CE Customer Edge equipment. CE Customer Edge equipment.
CoS Class of Service. CoS Class of Service.
skipping to change at page 8, line 17 skipping to change at page 6, line 29
TSN Time-Sensitive Network. TSN Time-Sensitive Network.
3. Requirements language 3. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
4. DetNet data plane overview 4. DetNet data plane overview
Comment #11 I am not sure whether this is a DP overview, or an
architecture overview and hence whether this needs to be here or
in the architecture draft.
Discussion: Overview is more of an editorial matter and its final
location can be discussed later on. Currently it is "no harm" to
have it here but there are no binding reasons to keep the text in
either.
This document describes how to use IP and/or MPLS to support a data This document describes how to use IP and/or MPLS to support a data
plane method of flow identification and packet formwarding over plane method of flow identification and packet formwarding over
layer-3. Two different cases are covered: (i) the inter-connect layer-3. Two different cases are covered: (i) the inter-connect
scenario, in which IEEE802.1 TSN is routed over a layer-3 network scenario, in which IEEE802.1 TSN is routed over a layer-3 network
(i.e., to enlarge the layer-2 domain), and (ii) native connectivity (i.e., to enlarge the layer-2 domain), and (ii) native connectivity
between DetNet-aware end systems. Figure 1 illustrates an exemplary between DetNet-aware end systems.
scenario.
TSN Edge Transit Relay DetNet
End System Node Node Node End System
+---------+ +.........+ +---------+
| Appl. |<---:Svc Proxy:-- End to End Service ---------->| Appl. |
+---------+ +---------+ +---------+ +---------+
| TSN | |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |
+---------+ +---+ +---+ +---------+ +---------+ +---------+
|Transport| |Trp| |Trp| |Transport| |Trp| |Trp| |Transport|
+-------.-+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.-----+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
Figure 1: A simple DetNet enabled network architecture
Figure 2 illustrates how DetNet can provide services for IEEE Figure 1 illustrates how DetNet can provide services for IEEE
802.1TSN end systems over a DetNet enabled network. The edge nodes 802.1TSN end systems over a DetNet enabled network. The edge nodes
insert and remove required DetNet data plane encapsulation. The 'X' insert and remove required DetNet data plane encapsulation. The 'X'
in the edge and relay nodes represents a potential DetNet flow packet in the edge and relay nodes represents a potential DetNet flow packet
replication and elimination point. This conceptually parallels L2VPN replication and elimination point. This conceptually parallels L2VPN
services, and could leverage existing related solutions as discussed services, and could leverage existing related solutions as discussed
below. below.
TSN |<---------- End to End DetNet Service ------>| TSN TSN |<---------- End to End DetNet Service ------>| TSN
Service | Transit Transit | Service Service | Transit Transit | Service
TSN (AC) | |<-Tunnel->| |<-Tnl->| | (AC) TSN TSN (AC) | |<-Tunnel->| |<-Tnl->| | (AC) TSN
skipping to change at page 9, line 25 skipping to change at page 7, line 20
+---+ | | E1 |==========| R1 |=======| E2 | | +---+ +---+ | | E1 |==========| R1 |=======| E2 | | +---+
| |--|----|._X_....|..DetNet..|.._ _...|..DF3..|...._X_.|---|---| | | |--|----|._X_....|..DetNet..|.._ _...|..DF3..|...._X_.|---|---| |
|CE1| | | \ | Flow 1 | X | | / | | |CE2| |CE1| | | \ | Flow 1 | X | | / | | |CE2|
| | | \_.|...DF2....|._/ \_..|..DF4..|._/ | | | | | | \_.|...DF2....|._/ \_..|..DF4..|._/ | | |
+---+ | |==========| |=======| | +---+ +---+ | |==========| |=======| | +---+
^ +--------+ +--------+ +--------+ ^ ^ +--------+ +--------+ +--------+ ^
| Edge Node Relay Node Edge Node | | Edge Node Relay Node Edge Node |
| | | |
|<----- Emulated Time Sensitive Networking (TSN) Service ---->| |<----- Emulated Time Sensitive Networking (TSN) Service ---->|
Figure 2: IEEE 802.1TSN over DetNet Figure 1: IEEE 802.1TSN over DetNet
Figure 3 illustrates how end to end PW-based DetNet service can be Figure 2 illustrates how end to end MPLS-based DetNet service can be
provided. In this case, the end systems are able to send and receive provided. In this case, the end systems are able to send and receive
DetNet flows. For example, an end system sends data encapsulated in DetNet flows. For example, an end system sends data encapsulated in
PseudoWire (PW) and in MPLS. Like earlier the 'X' in the end MPLS. Like earlier the 'X' in the end systems, edge and relay nodes
systems, edge and relay nodes represents potential DetNet flow packet represents potential DetNet flow packet replication and elimination
replication and elimination points. Here the relay nodes may change points. Here the relay nodes may change the underlying transport,
the underlying transport, for example tunneling IP over MPLS, or for example tunneling IP over MPLS, or simply interconnect network
simply interconnect network segments. segments.
DetNet DetNet DetNet DetNet
Service Transit Transit Service Service Transit Transit Service
DetNet | |<-Tnl->| |<-Tnl->| | DetNet DetNet | |<-Tnl->| |<-Tnl->| | DetNet
End | V 1 V V 2 V | End End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+ +---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X |
|CE1|========| \ | | X | | / |======|CE2| |CE1|========| \ | | X | | / |======|CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+ +---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^ ^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node | | Relay Node Relay Node Relay Node |
| | | |
|<--------------- End to End DetNet Service -------------->| |<--------------- End to End DetNet Service -------------->|
Figure 3: PW-Based Native DetNet Figure 2: MPLS-Based Native DetNet
Figure 4 illustrates how end to end IP-based DetNet service can be Figure 3 illustrates how end to end IP-based DetNet service can be
provided. In this case, the end systems are able to send and receive provided. In this case, the end systems are able to send and receive
DetNet flows. [Editor's note: TBD] DetNet flows. [Editor's note: TBD]
NOTE: This figures is TBD NOTE: This figures is TBD
DetNet DetNet DetNet DetNet
Service Transit Transit Service Service Transit Transit Service
DetNet | |<-Tnl->| |<-Tnl->| | DetNet DetNet | |<-Tnl->| |<-Tnl->| | DetNet
End | V 1 V V 2 V | End End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+ +---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...| | | | | | .|.X | | X...DFa...| | | | | | .|.X |
| H1|========| | | | | |======| H2| | H1|========| | | | | |======| H2|
skipping to change at page 10, line 43 skipping to change at page 8, line 21
+---+ | | R1 |=======| R2 |=======| R3 | | +---+ +---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...| | | | | | .|.X | | X...DFa...| | | | | | .|.X |
| H1|========| | | | | |======| H2| | H1|========| | | | | |======| H2|
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | |=======| |=======| | +---+ +---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^ ^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node | | Relay Node Relay Node Relay Node |
| | | |
|<--------------- End to End DetNet Service -------------->| |<--------------- End to End DetNet Service -------------->|
Figure 4: IP-Based Native DetNet Figure 3: IP-Based Native DetNet
4.1. DetNet data plane encapsulation requirements 4.1. DetNet data plane encapsulation requirements
Two major groups of scenarios can be distinguished which require flow Two major groups of scenarios can be distinguished which require flow
identification during transport: identification during transport:
1. DetNet function related scenarios: 1. DetNet function related scenarios:
* Congestion protection and latency control: usage of allocated * Congestion protection and latency control: usage of allocated
resources (queuing, policing, shaping). resources (queuing, policing, shaping).
skipping to change at page 11, line 42 skipping to change at page 9, line 21
* troubleshooting (e.g., identify misbehaving flows, etc.) * troubleshooting (e.g., identify misbehaving flows, etc.)
* recognize flow(s) for analytics (e.g., increase counters, * recognize flow(s) for analytics (e.g., increase counters,
etc.) etc.)
* correlate events with flows (e.g., volume above threshold, * correlate events with flows (e.g., volume above threshold,
etc.) etc.)
* etc. * etc.
Each node (edge, relay and transit) use a local-ID of the DetNet- Each DetNet node (edge, relay and transit) use an internal/
(compound)-flow in order to accomplish its role during transport. implementation specific local-ID of the DetNet-(compound)-flow in
Recognizing the DetNet flow is more relaxed for edge and relay nodes, order to accomplish its role during transport. Recognizing the
as they are fully aware of both the DetNet service and transport DetNet flow is more relaxed for edge and relay nodes, as they are
layers. The primary DetNet role of intermediate transport nodes is fully aware of both the DetNet service and transport layers. The
limited to ensuring congestion protection and latency control for the primary DetNet role of intermediate transport nodes is limited to
above listed DetNet functions. ensuring congestion protection and latency control for the above
listed DetNet functions.
The DetNet data plane allows for the aggregation of DetNet flows, The DetNet data plane allows for the aggregation of DetNet flows,
e.g., via MPLS hierarchical LSPs, to improved scaling. When DetNet e.g., via MPLS hierarchical LSPs, to improved scaling. When DetNet
flows are aggregated, transit nodes may have limited ability to flows are aggregated, transit nodes may have limited ability to
provide service on per-flow DetNet identifiers. Therefore, provide service on per-flow DetNet identifiers. Therefore,
identifying each individual DetNet flow on a transit node may not be identifying each individual DetNet flow on a transit node may not be
achieved in some network scenarios, but DetNet service can still be achieved in some network scenarios, but DetNet service can still be
assured in these scenarios through resource allocation and control. assured in these scenarios through resource allocation and control.
Comment #14 You could introduce the concept of a flow group Comment #14 You could introduce the concept of a flow group
identified into the packet. You may also include a flow id at a identified into the packet. You may also include a flow id at a
lower layer. lower layer.
Discussion: Agree on the identification properties. Adding a Discussion: Agree on the identification properties. Adding a
specific id into actual on-wire formats is not necessarily needed. specific id into actual on-wire formats is not necessarily needed.
On each node dealing with DetNet flows, a local-ID is assumed to On each DetNet node dealing with DetNet flows, an internal local-ID
determine what local operation a packet goes through. Therefore, is assumed to determine what local operation a packet goes through.
local-IDs MUST be unique on each edge and relay nodes. Local-ID MUST Therefore, local-IDs has to be unique on each edge and relay nodes.
be unambiguously bound to the DetNet flow. Local-ID is unambiguously bound to the DetNet flow.
Comment #15 I am confused as to what you mean by local ID. Is this 4.2. Packet replication and elimination considerations
an internal construct which packet parameters map to, in which
case why is it being called up? IETF practise is to specify on
the wire behaviour but not internal behaviour of equipments.
Discussion: Local-id is an internal construct, which was intended to DetNet service layer introduces packet replication and elimination
clarify the discussion in the I-D. Obviously it did not work as functionality (PREF) for use in DetNet edge and relay node and end
intended. system packet processing. PREF MAY be enabled in a DetNet node and
the required processing is only applied to packets with a positive
flow identification at the DetNet service layer. PREF utilizes a
sequence number carried within a DetNet flow packets.
5. DetNet data plane solution At a DetNet node level the output of the PREF elimination function is
always a single packet. The output of the PREF replication function
at a DetNet node level is always one or more packets (i.e., 1:M
replication). The replicated packets MUST share the same d-CW i.e.,
the sequence number is the same for each member flow of the compound
flow. The location and mechanism on the packet processing pipeline
used for replication is implementation specific.
5.1. DetNet specific packet fields The complex part of the DetNet PREF processing is tracking the
history of received packets for multiple DetNet member flows. These
ingress DetNet member flows (to a node) MUST have the same local-ID
if they belong to the same DetNet (compound) flow and share the same
sequence number counter and the history information. The location of
the packet elimination on the packet processing pipeline is
implementation specific.
The DetNet data plane encapsulation should include two DetNet 4.3. Packet reordering considerations
specific information element in each packet of a DetNet flow: (1)
flow identification and (2) sequence number.
Comment #16 should, SHOULD, must or MUST? DetNet service layer introduces also packet reordering functionality
for use in DetNet edge and relay node and end system packet
processing. The reordering functionality MAY be enabled in a DetNet
node. The reordeing functionality relies on a presence of sequence
numbers in a DetNet (compound) flows. The reordering processing is
only applied to packets with a positive flow identification at the
DetNet service layer.
Discussion: SHOULD or MUST is ok. MUST is probably more 5. MPLS-based DetNet data plane solution
appropriate.
5.1. DetNet specific packet fields
The DetNet data plane encapsulation MUST include two DetNet specific
information elements in each packet of a DetNet flow: (1) a flow
identification and (2) a sequence number.
The DetNet data plane encapsulation may consists further elements The DetNet data plane encapsulation may consists further elements
used for overlay tunneling, to distinguish between DetNet member used for overlay tunneling, to distinguish between DetNet member
flows of the same DetNet compound flow or to support OAM functions. flows of the same DetNet compound flow or to support OAM functions.
5.2. DetNet encapsulation 5.2. Data plane encapsulation
This document specifies two encapsulations for the DetNet data plane:
(1) PseudoWire (PW) for MPLS PSN and (2) native IPv6 based
encapsulation for IP PSN.
5.2.1. PseudoWire-based data plane encapsulation
Figure 5 illustrates a DetNet PW encapsulation over an MPLS PSN. The Figure 4 illustrates a DetNet data plane MPLS encapsulation. The
PW-based encapsulation of the DetNet flows fits perfectly for the MPLS-based encapsulation of the DetNet flows is a good fit for the
Layer-2 interconnect deployment cases (see Figure 2). Furthermore, Layer-2 interconnect deployment cases (see Figure 1). Furthermore,
end to end DetNet service i.e., native DetNet deployment (see end to end DetNet service i.e., native DetNet deployment (see
Figure 3) is also possible if DetNet-aware end systems are capable of Figure 2) is also possible if DetNet end systems are capable of
initiating and termination MPLS encapsulated PWs. It is also initiating and termination MPLS encapsulated packets. Transport of
possible use the same encapsulation format with a Packet PW over MPLS IP encapsulated DetNet flows, see Section 6, over MPLS-based DetNet
[RFC6658]. Transport of IP encapsulated DetNet flows, see data plane is also possible. Interworking between PW- and IPv6-based
Section 5.2.2, over DetNet PWs is also possible. Interworking encapsulations is discussed further in Section 7.6.
between PW- and IPv6-based encapsulations is discussed further in
Section 7.6.
The PW-based DetNet data plane encapsulation consists of: The MPLS-based DetNet data plane encapsulation consists of:
o DetNet control word (d-CW) containing sequencing information for o DetNet control word (d-CW) containing sequencing information for
packet replication and duplicate elimination purposes. There is a packet replication and duplicate elimination purposes. There MUST
separate sequence number space for each DetNet flow. a separate sequence number space for each DetNet flow.
o PseudoWire Label (PW Label) that is a standard PW label o DetNet Label that identifies a DetNet flow within a DetNet Edge or
identifying a DetNet flow and a PW Instance within a (DA-)T-PE or a Relay node. The DetNet label MUST be at the bottom of the label
(DA-)S-PE device. stack.
o An optional S-Label that represents DetNet Service LSP used o An optional DetNet service lable (S-Label) that represents DetNet
between (DA-)T-PE or (DA-)S-PE nodes. One possible use of an Service LSP used between DetNet Egde and/or Relay nodes. One
S-Label is to identify the different DetNet member flows used to possible use of an S-Label is to identify DetNet member flows used
provide protection to a DetNet composite flow, perhaps even when to provide protection to a DetNet compound flow, perhaps even when
both LSPs appear on the same link for some reason. both LSPs appear on the same link for some reason.
Comment #17 This needs some discussion by the WG. One or more MPLS transport LSP label(s) (T-label) which may be a hop-
by-hop label used between LSR and MUST appear higher in the label
Discussion: Agree, specifically if the I-D becomes WG document. stack than S-labels. A top of stack T-label may be PHPed before
arriving at a DetNet node. In general T-labels should be considered
o MPLS transport LSP label(s) (T-label) which may be a hop-by-hop to be part of the underlying transport network rather the actual
label used between LSRs. DetNet data plane encapsulation.
Comment #18 Ordinarily this will of course be PHPed before arrival
at an x-PE.
Discussion: In most cases yes - depends on the network
configuration. PHP is not mandatory and TP does not even have
PHP.
RFC3985 Encapsulation DetNet PW Encapsulation
+---------------------+
| Payload | +---------------------------------+
/=====================\ | |
H Payload Convergence H--. | DetNet Flow |
H---------------------H | | Payload Packet |
H Timing H +-\ | |
H---------------------H | \ /=================================\
H Sequencing H--' \-->H DetNet Control Word H
\=====================/ \=================================/
| PW Demultiplexer |--------->| PW Label |
+---------------------+ +---------------------------------+
| PSN Convergence | .--->| Optional MPLS S-Label |
+---------------------+ | +---------------------------------+
| PSN |-----+--->| MPLS T-Label(s) |
+---------------------+ +---------------------------------+
| Data-Link |
+---------------------+
| Physical |
+---------------------+
Figure 5: Encapsulation of a DetNet flow in a PW with MPLS(-TP) PSN
The DetNet control word (d-CW) is identical to the control word
defined for Ethernet over MPLS networks in [RFC4448]. The DetNet
control word is illustrated in Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| reserved - set to 0 | 16 bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DetNet Control Word
Comment #19 We need to think about whether "identical is the correct
term. The Ethernet S/N skips zero (it uses zero to mean no S/N in
use). is that the behaviour that we want?
Discussion: Good point. Identical is a wrong statement. The format
is the same the behaviour of SN is slightly different as 0 is
assumed to be a valid SN.
5.2.2. Native IPv6-based data plane encapsulation
Comment #20 SB> This part of the design needs to be marked as
provisional until it has a more thorough WG review.
Discussion: Ok, however, this is still an individual I-D.
Figure 7 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 4). 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 2).
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 the PW Label). 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 DetNet Control Word IPv6 Destination Option containing sequencing
information for packet replication and duplicate elimination
function (PREF) purposes. The DetNet Destination Option is
equivalent to the DetNet Control Word.
A DetNet-aware end station (a host) or an intermediate node
initiating an IPv6 packet is responsible for setting the Flow Label,
adding the required DetNet Destination Option, and possibly adding a
routing header such as the segment routing option (for pre-defined
paths [I-D.ietf-6man-segment-routing-header]). The payload of the
native IPv6 encapsulation is any payload protocol that can be
identified using the Next Header field either in the IPv6 packet
header or in the last IPv6 extension header.
Comment #22 SB> We will probably need to agree an option ordering,
and need to note that the 6man IPv6 solution already operates on
the edge of the ability of h/w to see that far into the packet.
Discussion: RFC8200 describes extension header ordering - there is
not much to agree there. Agree on the hardware lookup challenges.
However, the issues of SR header are not this I-D to fix.
Comment #23 SB> I am not sure the above is needed since it is by
definition correct.
Discussion: (next header) agree.
A DetNet-aware end station (a host) or an intermediate node receiving DetNet MPLS-based encapsulation
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 | | DetNet Flow |
| Payload | | Payload Packet |
| | | |
/---------------------------------\ +---------------------------------+ <--\
H DetNet Control Word DstOpt Hdr H | DetNet Control Word | |
\---------------------------------/ +---------------------------------+ +--> DetNet data plane
| IPv6 header | | S-Label | | MPLS encapsulation
| (with set Flow label) | +---------------------------------+ <--/
+---------------------------------+ | T-Label(s) |
+---------------------------------+
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 7: Encapsulation of a native IPv6 DetNet flow Figure 4: Encapsulation of a DetNet flow in an MPLS(-TP) PSN
A DetNet flow must carry sequencing information for packet 5.3. DetNet control word
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 8.
Comment #24 SB> Can an SR node look at a DO? A DetNet control word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in [RFC4385] and is illustrated in Figure 5.
The upper nibble of the d-CW MUST be set to zero (0). The effective
sequence number bit length is between 0 and 28 bits, and configured
either by a control plane or manually for each DetNet flow. The
sequence number is aligned to the right (least significant bits) and
unused bits MUST be set to zero (0). Each DetNet flow MUST have its
own sequence number counter. The sequence number is incremented by
one for each new packet.
Discussion: Yes. The d-CW MUST always be present in a packet. In a case the sequence
number is not used (e.g., for DetNet-t-flows) the control plane or
the manual configuration has to define zero (0) bit length seqeunce
number and the value of the sequence number MUST be set to zero (0).
0 1 2 3 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 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 | Reserved | |0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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]
5.3. DetNet flow identification for duplicate detection
Duplicate elimination depends on flow identification. Mapping
between packet fields and Local-ID may impact the implementation of
duplicate elimination.
Comment #25 SB> So I wonder if the right place to put the FI is in
the IPv6 FI, or in the IPv6 address itself?
Discussion: Each flow having different address is challenging if we Figure 5: DetNet Control Word
want to terminate multiple flows into the same node with one
address or originate multiple flows from a node with one address
(note, we are aware of the one /64 per node discussion but cannot
assume it here, at least not yet).
5.3.1. PseudoWire encapsulation
RFC3985 Section 5.2.1. describes PW sequencing provides a duplicate
detection service among other things. This specification clarifies
this definition as follows:
DetNet flows that need to undergo PREF processing MUST have the
same PW Label when they arrive at the DA-*-PE node.
From the label stack processing point of view receiving the same
label from multiple sources is analogous to Fast Reroute backup
tunnel behavior [RFC4090]. The PW Label for a DetNet flow can be
different on each PW segment.
Comment #26 SB> I am not sure of the utility of this reference. In
FRR you should not receive packets concurrently on two paths. It
seems fine to state the the requirement that a single label is
used for both paths.
Discussion: OK with the same label comment. OK to remove the FRR
reference here.
5.3.2. Native IPv6 encapsulation
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.
6. PREF specific considerations
This section applies equally to DetNet flows transported via IPv6 and
MPLS. While flow identification and some header related processing
will differ between the two, the considerations covered in this
section are common to both.
6.1. PseudoWire-based data plane
6.1.1. Forwarder clarifications
The DetNet specific new functionality in an edge or relay node 5.4. Flow identification
processing is the packet replication and duplication elimination
function (PREF). This function is a part of the DetNet-aware
"extended" forwarder. The PREF processing is triggered by the
received packet of a DetNet flow.
Comment #28 SB> I am not sure what you mean by triggered here. DetNet flow identification at a DetNet service layer is realized by
Hopefully we are not thinking of dataplane triggered an S-label. It maps a Detnet flow to a specific d-CW in a DetNet
configuration? node. The S-label used for flow identification MUST be bottom label
of the label stack for a DetNet-s- or DetNet-st-flow and MUST precede
the d-CW.
Discussion: "Initiated" is probably more appropriate wording. An S-label for a single DetNet flow does not need to be unique DetNet
domain wide. As long as two or more different DetNet flows do not
errorneously map to a same d-CW in a DetNet node the labels may vary.
Basically the forwarding entry has to be extended with a "PREF 5.5. Service layer considerations
enabled" boolean configuration switch that is associated with the
normal forwarding actions (e.g., in case of MPLS a swap, push, pop,
..). The output of the PREF elimination function is always a single
packet. The output of the PREF replication function is always one or
more packets (i.e., 1:M replication). The replicated packets MUST
share the same DetNet control word sequence number.
The complex part of the DetNet PREF processing is tracking the [Editor's note: quite a bit of unfinished and old text in the
history of received packets for multiple DetNet member flows. These following sections.]
ingress DetNet member flows (to a node) MUST have the same local-ID
if they belong to the same DetNet-(compound)-flow and share the same
sequence number counter and the history information.
The edge and relay node internal procedures of the PREF are The edge and relay node internal procedures of the PREF are
implementation specific. The order of a packet elimination or implementation specific. The order of a packet elimination or
replication is out of scope in this specification. However, care replication is out of scope in this specification. However, care
should be taken that the replication function does not actually should be taken that the replication function does not actually
loopback packets as "replicas". Looped back packets include loopback packets as "replicas". Looped back packets include
artificial delay when the node that originally initiated the packet artificial delay when the node that originally initiated the packet
receives it again. Also, looped back packets may make the network receives it again. Also, looped back packets may make the network
condition to look healthier than it actually is (in some cases link condition to look healthier than it actually is (in some cases link
failures are not reflected properly because looped back packets make failures are not reflected properly because looped back packets make
skipping to change at page 19, line 34 skipping to change at page 13, line 42
Comment #29: SB> There needs to be some text about preventing a node Comment #29: SB> There needs to be some text about preventing a node
ever receiving its own replicated packets. Indeed that would ever receiving its own replicated packets. Indeed that would
suggest that the flow id should be changed and replication should suggest that the flow id should be changed and replication should
only take place on configured flow IDs. I have a feeling that only take place on configured flow IDs. I have a feeling that
this would all be a lot safer if replication only happened at this would all be a lot safer if replication only happened at
ingress and we managed the diversity of the paths. ingress and we managed the diversity of the paths.
Discussion: Agree on hardening the loopback text considerations. Discussion: Agree on hardening the loopback text considerations.
6.1.2. Edge node processing clarifications 5.5.1. Edge node processing
The DetNet data plane solution overloads the edge node with DetNet
Edge Node functions. Edge nodes are also aware of DetNet flows and
may need to operate upon those. Figure 9 illustrates the overall
edge device functions. The figure shows both physical attachment
circuit (AC) (e.g., Ethernet [RFC4448]) connecting to the edge node,
and a packet service connecting to the edge node via an embedded
router function (similarly as described e.g., in [RFC6658]). Whether
traffic flow from a client AC and PSN tunnel receives DetNet specific
treatment is up to a local configuration and policy.
Comment #30: SB> Shouldn't the behaviour simply be a property of a
given PW?
Discussion: Agree in principle. TBD.
+---------------------------------------+ [Editor's note: Since we are not defining the inner workings and
| DetNet Edge Device | implementation of the DetNet Egde node - rather only what goes in and
+---------------------------------------+ Egress/ what comes out, and of course the on-wire details, then the figures
| | Forwarder | | Ingress shown in the coming section would not need to detail the inner
| | | Single | member Inst. architecture of a DetNet Node.]
Client PSN | "Packet o <-X-----> o Service o<----------> +---------------------------------------+
tunnels | NSP" | | Repl. | Instance | | DetNet Edge Node |
<---------->o | | Elim. +-------------+ Duplicate +---------------------------------------+
| | : | | Egress | | | |
| | . | Single | member Inst. | | | |
| | +-> o Service o<----------> Client AC | +---o <-------> o o<---------->
| | | | Instance | | Elim. | | | |
+-------------+ | +-------------+ Egress/ <---------->o <-------| | +-------------+
| | | | | Ingress | | | | |
Client AC | NSP | Repl. | | Single | member Inst. | +---o <-------> o |
<---------->o o <-----X-> o Service o<----------> | | | o<---------->
| | Elim. | Instance | | | +-> o |
+-------------+ +-------------+ Egress/ +-------------+ | +-------------+
| | | | Ingress | | | | |
Client AC | NSP | | Single | member Inst. Client AC | | Repl. | | |
<---------->o o <-------> o Service o<----------> <---------->o o <-----X-> o o<---------->
| | | Instance | | | Elim. | |
+---------------------------------------+ +-------------+ +-------------+
| | | |
Client AC | | | |
<---------->o o <-------> o o<---------->
| | | |
+---------------------------------------+
Figure 9: DetNet Edge Node processing Figure 6: DetNet Edge Node processing
An edge node participates to the packet replication and duplication An edge node participates to the packet replication and duplication
elimination. Required processing is done within an extended elimination. Required processing is done within an extended
forwarder function. In the case the native service processing (NSP) forwarder function. In the case the native service processing (NSP)
is IEEE 802.1CB [IEEE8021CB] capable, the packet replication and is IEEE 802.1CB [IEEE8021CB] capable, the packet replication and
duplicate elimination MAY entirely be done in the NSP and bypassing duplicate elimination MAY entirely be done in the NSP and bypassing
the DetNet flow encapsulation and logic entirely, and thus is able to the DetNet flow encapsulation and logic entirely, and thus is able to
operate over unmodified implementation and deployment. The NSP operate over unmodified implementation and deployment. The NSP
approach works only between edge nodes and cannot make use of relay approach works only between edge nodes and cannot make use of relay
nodes (see Section 6.1.3). nodes (see Section 5.5.2).
Comment #31 SB> This would be a fine way to operate the PW system - Comment #31 SB> This would be a fine way to operate the PW system -
edge to edge. edge to edge.
Discussion: When it comes to use of NSPs, agree. Also for "island Discussion: When it comes to use of NSPs, agree. Also for "island
interconnect" this is a fine. However, when there is a need to do interconnect" this is a fine. However, when there is a need to do
PREF in a middle, plain edge to edge is not enough. PREF in a middle, plain edge to edge is not enough.
The DetNet-aware extended forwarder selects the egress DetNet member The DetNet-aware extended forwarder selects the egress DetNet member
flow based on the DetNet forwarding rules. In both "normal AC" and flow based on the DetNet forwarding rules. In both "normal AC" and
"Packet AC" cases there may be no DetNet encapsulation header "Packet AC" cases there may be no DetNet encapsulation header
available yet as it is the case with relay nodes (see Section 6.1.3). available yet as it is the case with relay nodes (see Section 5.5.2).
It is the responsibility of the extended forwarder within the edge It is the responsibility of the extended forwarder within the edge
node to push the DetNet specific encapsulation (if not already node to push the DetNet specific encapsulation (if not already
present) to the packet before forwarding it to the appropriate egress present) to the packet before forwarding it to the appropriate egress
DetNet member flow instance(s). DetNet member flow instance(s).
Comment #32 SB> I am not convinced of the wisdom of having a mid- Comment #32 SB> I am not convinced of the wisdom of having a mid-
point node convert a flow into a DN flow, which is what you are point node convert a flow into a DN flow, which is what you are
implying here. This seems like an ingress function. implying here. This seems like an ingress function.
skipping to change at page 21, line 25 skipping to change at page 15, line 25
edge. edge.
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.1.3. Relay node processing clarifications 5.5.2. Relay node processing
The DetNet data plane solution overloads a relay node with DetNet
Relay node functions. Relay node is aware of DetNet flows and may
operate upon those. Figure 10 illustrates the overall DetNet relay
device functions.
Comment #33 SB> I don't think that a relay node in not a normal
construct so I am not sure "overload" is the right term here.
Discussion: Agree. There is a terminology issue here. 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
skipping to change at page 22, line 22 skipping to change at page 16, line 13
segment based on the flow identification. The mapping of ingress segment based on the flow identification. The mapping of ingress
DetNet member flow segment to egress DetNet member flow segment may DetNet member flow segment to egress DetNet member flow segment may
be statically or dynamically configured. Additionally the DetNet- be statically or dynamically configured. Additionally the DetNet-
aware forwarder does duplicate frame elimination based on the flow aware forwarder does duplicate frame elimination based on the flow
identification and the sequence number combination. The packet identification and the sequence number combination. The packet
replication is also done within the DetNet-aware forwarder. During replication is also done within the DetNet-aware forwarder. During
elimination and the replication process the sequence number of the elimination and the replication process the sequence number of the
DetNet member flow MUST be preserved and copied to the egress DetNet DetNet member flow MUST be preserved and copied to the egress DetNet
member flow. member flow.
+---------------------------------------+ +---------------------------------------+
| DetNet Relay Device | | DetNet Relay Node |
Ingress +---------------------------------------+ Ingress +---------------------------------------+
member | | Forwarder | | Egress | | | | Egress
instance | Single | | Single | member Inst. | o---------> o--+ Elim. |
----------->o Service o --X-----> o Service o-----------> ----------->o | | +--------->o----------->
| Instance | | Elim. | Instance | | | +-----> o--+ |
Ingress +-------------+ | +-------------+ Duplicate Ingress +-------------+ | +-------------+
member | | | | | Egress | | | | | Egress
instance | Single | | | Single | member Inst. | | | | |
----------->o Service o --+ +-> o Service o-----------> ----------->o o --+ +-> o o----------->
| Instance | | | Instance | | | | | |
Ingress +-------------+ | +-------------+ Ingress +-------------+ | +-------------+
member | | | | | Egress | | | | | Egress
instance | Single | Repl. | | Single | member Inst. | | Repl. | | |
----------->o Service o ------X-> o Service o-----------> ----------->o o ------+-> o o----------->
| Instance | | Instance | | | | |
Ingress +-------------+ +-------------+ Ingress +-------------+ +-------------+
member | | | | Egress | | | | Egress
instance | Single | | Single | member Inst. | | | |
----------->o Service o --------> o Service o-----------> ----------->o o --------> o o----------->
| Instance | | Instance | | | | |
+---------------------------------------+ +---------------------------------------+
Figure 10: DetNet Relay Node processing Figure 7: DetNet Relay Node processing
Comment #35 SB> Somewhere in the dp document there needs to be a Comment #35 SB> Somewhere in the dp document there needs to be a
note of the requirement for interfaces to do fast exchange of note of the requirement for interfaces to do fast exchange of
counter state, and a note to those planning the network and counter state, and a note to those planning the network and
designing the control plane that they need to provide support for designing the control plane that they need to provide support for
this. this.
Discussion: We kinf of agree but also think the above exchange or Discussion: We kinf of agree but also think the above exchange or
synchronization of counter states is not in our scope to solve. synchronization of counter states is not in our scope to solve.
6.2. Native IPv6-based data plane 5.5.3. End system processing
[Editor's note: this section is TBD.] TBD.
5.6. Transport node considerations
5.6.1. Congestion protection
TBD.
5.6.2. Explicit routes
TBD.
6. IPv6-based DetNet data plane solution
6.1. Data plane encapsulation
Figure 8 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 8: Encapsulation of a native IPv6 DetNet-s- or DetNet-st-flow
without a routing header
Figure 9 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 9: 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 6.4.1.
6.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 10.
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 10: 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.
6.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.
6.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.
6.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 11. 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 11: Encapsulation of a DetNet-flow IPv6 packet at the DetNet
Edge node
6.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) ...
6.4.1.2. Engress DetNet Edge node processing
6.4.2. Relay node processing
TBD.
6.4.3. End system processing
TBD.
6.5. Transport node processing
6.5.1. Congestion protection
6.5.2. Explicit routes
7. Other DetNet data plane considerations 7. Other DetNet data plane considerations
7.1. Class of Service 7.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 24, line 18 skipping to change at page 25, line 8
treatment typically includes a guarantee/agreement for the service, treatment typically includes a guarantee/agreement for the service,
and allocation of resources to support the service. Example QoS and allocation of resources to support the service. Example QoS
mechanisms include discrete resource allocation, admission control, mechanisms include discrete resource allocation, admission control,
flow identification and isolation, and sometimes path control, flow identification and isolation, and sometimes path control,
traffic protection, shaping, policing and remarking. Example traffic protection, shaping, policing and remarking. Example
protocols that support QoS control include Resource ReSerVation protocols that support QoS control include Resource ReSerVation
Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473].
The existing MPLS mechanisms defined to support CoS [RFC3270] can The existing MPLS mechanisms defined to support CoS [RFC3270] can
also be used to reserve resources for specific traffic classes. also be used to reserve resources for specific traffic classes.
In addition to path pinning and packet replication and elimination, In addition to explicit routes, and packet replication and
described in Section 5 above, DetNet provides zero congestion loss elimination, described in Section 5 above, DetNet provides zero
and bounded latency and jitter. congestion loss and bounded latency and jitter. As described in
[I-D.ietf-detnet-architecture], there are different mechanisms that
Comment #36 SB> I just searched from the beginning of the document maybe used separately or in combination to deliver a zero congestion
and this was the the first reference I found to pinning. loss service. These mechanisms are provided by the either the MPLS
or IP layers, and may be combined with the mechanisms defined by the
Discussion: Terminology isssue. Should use, for example, explicit underlying network layer such as 802.1TSN.
paths which is used in the architecture I-D.
As described in [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.
A baseline set of QoS capabilities for DetNet flows carried in PWs A baseline set of QoS capabilities for DetNet flows carried in PWs
and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE) and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE)
[RFC3209] and [RFC3473]. TE LSPs can also support explicit routes [RFC3209] and [RFC3473]. TE LSPs can also support explicit routes
(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 flows carried in IPv6 MUST be provided locally by the
DetNet-aware hosts and routers supporting DetNet flows. Such support DetNet-aware hosts and routers supporting DetNet flows. Such support
will leverage the underlying network layer such as 802.1TSN. The will leverage the underlying network layer such as 802.1TSN. The
traffic control mechanisms used to deliver QoS for IP encapsulated traffic control mechanisms used to deliver QoS for IP encapsulated
DetNet flows are expected to be defined in a future document. From DetNet flows are expected to be defined in a future document. From
an encapsulation perspective, and as defined in Section 5.2.2, the an encapsulation perspective, and as defined in Section 6, the
combination of the Flow Label together with the IP source address combination of the Flow Label together with the IP source address
uniquely identifies a DetNet flow. uniquely identifies a DetNet 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 SHOULD: nodes of a DetNet network MUST:
Comment #37 SB> Why not MUST?
Discussion: OK with 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.
o Not use a DetNet reserved resource, e.g. a queue or shaper o Not use a DetNet reserved resource, e.g. a queue or shaper
reserved for DetNet flows, for any packet that does not carry a reserved for DetNet flows, for any packet that does not carry a
DetNet Class of Service marker. DetNet Class of Service marker.
7.3. Cross-DetNet flow resource aggregation 7.3. Cross-DetNet flow resource aggregation
skipping to change at page 27, line 38 skipping to change at page 28, line 17
within the bridged network over which it is carried. Furthermore, within the bridged network over which it is carried. Furthermore,
IEEE 802.1CB [IEEE8021CB] describes three methods by which a packet IEEE 802.1CB [IEEE8021CB] describes three methods by which a packet
sequence number can be encoded in an Ethernet frame. sequence number can be encoded in an Ethernet frame.
Ensuring that the proper Ethernet VLAN tag priority and destination Ensuring that the proper Ethernet VLAN tag priority and destination
MAC address are used on a DetNet/TSN packet may require further MAC address are used on a DetNet/TSN packet may require further
clarification of the customary L2/L3 transformations carried out by clarification of the customary L2/L3 transformations carried out by
routers and edge label switches. Edge nodes may also have to move routers and edge label switches. Edge nodes may also have to move
sequence number fields among Layer 2, PW, and IPv6 encapsulations. sequence number fields among Layer 2, PW, and IPv6 encapsulations.
7.6. Interworking between PW- and IPv6-based encapsulations 7.6. Interworking between MPLS- and IPv6-based encapsulations
[Editor's note: add considerations for interworking between PW-based [Editor's note: add considerations for interworking between MPLS-
and native IPv6-based DetNet encapsuations.] based and native IPv6-based DetNet encapsuations.]
7.7. IPv4 considerations
[Editor's note: The fact is that there are and will be deployments
using IPv4. Neglecting it entirely is not feasible.]
8. Time synchronization 8. Time synchronization
Comment #39 SB> This section should point the reader to RFC8169 Comment #39 SB> This section should point the reader to RFC8169
(residence time in MPLS n/w. We need to consider if we need to (residence time in MPLS n/w. We need to consider if we need to
introduce the same concept in IP. introduce the same concept in IP.
Discussion: agree. Discussion: Agree. For IP we could reference to PTPv2 or v3 over
UDP/IP, since it measures residence time among other things.
[Editor's note: describe a bit of issues and deployment [Editor's note: describe a bit of issues and deployment
considerations related to time-synchronization within DetNet. Refer considerations related to time-synchronization within DetNet. Refer
to DT discussion and the slides that summarize different approaches to DT discussion and the slides that summarize different approaches
and rough synchronization performance numbers. Finally, scope time- and rough synchronization performance numbers. Finally, scope time-
synchronization solution outside data plane.] synchronization solution outside data plane.]
When DetNet is used, there is an underlying assumption that the When DetNet is used, there is an underlying assumption that the
applicaton(s) require clock synchronization such as the Precision applicaton(s) require clock synchronization such as the Precision
Time Protocol (PTP) [IEEE1588]. The relay nodes may or may not Time Protocol (PTP) [IEEE1588]. The relay nodes may or may not
skipping to change at page 29, line 20 skipping to change at page 30, line 7
Comment #40 SB> I am not sure why we sould not use PREP. We should Comment #40 SB> I am not sure why we sould not use PREP. We should
explain to the reader. explain to the reader.
Discussion: Agree that a this can be opened a bit more in detail. Discussion: Agree that a this can be opened a bit more in detail.
The issue is explained briefly in the last sentence but it could The issue is explained briefly in the last sentence but it could
be more clear. be more clear.
9. Management and control considerations 9. Management and control considerations
[Editor's note: This section needs to be different for MPLS and IPv6
solutions. Most solutions are technology dependant,]
While management plane and control planes are traditionally While management plane and control planes are traditionally
considered separately, from the Data Plane perspective there is no considered separately, from the Data Plane perspective there is no
practical difference based on the origin of flow provisioning practical difference based on the origin of flow provisioning
information. This document therefore does not distinguish between information. This document therefore does not distinguish between
information provided by a control plane protocol, e.g., RSVP-TE information provided by a control plane protocol, e.g., RSVP-TE
[RFC3209] and [RFC3473], or by a network management mechanisms, e.g., [RFC3209] and [RFC3473], or by a network management mechanisms, e.g.,
RestConf [RFC8040] and YANG [RFC7950]. RestConf [RFC8040] and YANG [RFC7950].
[Editor's note: This section is a work in progress. discuss here [Editor's note: This section is a work in progress. discuss here
what kind of enhancements are needed for DetNet and specifically for what kind of enhancements are needed for DetNet and specifically for
PREF and DetNet zero congest loss and latency control. Need to cover PREF and DetNet zero congest loss and latency control. Need to cover
both traffic control (queuing) and connection control (control both traffic control (queuing) and connection control (control
plane).] plane).]
9.1. PW Label and IPv6 Flow Label assignment and distribution 9.1. MPLS-based data plane
The PW label distribution follows the same mechanisms specified for 9.1.1. S-Label assignment and distribution
MS-PW [RFC6073]. The details of the control plane protocol solution
required for the label distribution and the management of the label [Editor's note: Outdated and MPLS specific.. and needs more work.]
number space are out of scope of this document.
The DetNet S-Label distribution follows the same mechanisms specified
for XYZ . The details of the control plane protocol solution required
for the label distribution and the management of the label number
space are out of scope of this document.
9.1.2. Explicit routes
[Editor's note: Outdated.. and needs more work.]
[TBD: based on MPLS TE and possibly IPv6 SR]
9.2. IPv6-based data plane
9.2.1. Flow Label assignment and distribution
[Editor's note: Outdated and IPv6 Specific.. and needs more work.]
The IPv6 Flow Label distribution and the label number space are out The IPv6 Flow Label distribution and the label number space are out
of scope of this document. However, it should be noted that the of scope of this document. However, it should be noted that the
combination of the IPv6 source address and the IPv6 Flow Label is combination of the IPv6 source address and the IPv6 Flow Label is
assumed to be unique within the DetNet-enabled network. Therefore, assumed to be unique within the DetNet-enabled network. Therefore,
as long as each node is able to assign unique Flow Labels for the as long as each node is able to assign unique Flow Labels for the
source address(es) it is using the DetNet-enabled network wide flow source address(es) it is using the DetNet-enabled network wide flow
identification uniqueness is guaranteed. identification uniqueness is guaranteed.
9.2. Packet replication and elimination 9.2.2. Explicit routes
The control plane protocol solution required for managing the PREF [Editor's note: Outdated.. and needs more work.]
processing is outside the scope of this document.
9.3. Explicit paths [TBD: What we have there for IPv6 and explicit routes]
[TBD: based on MPLS TE and SR.] 9.3. Packet replication and elimination
[Editor's note: Outdated and at the functional level technology
independent.. but needs more work.]
The control plane protocol solution required for managing the PREF
processing is outside the scope of this document.
9.4. Congestion protection and latency control 9.4. Congestion protection and latency control
[TBD] [TBD]
9.5. Flow aggregation control 9.5. Flow aggregation control
[TBD] [TBD]
10. Security considerations 10. Security considerations
skipping to change at page 32, line 33 skipping to change at page 33, line 38
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>.
[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>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Encapsulation Methods for Transport of Ethernet over MPLS "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
<https://www.rfc-editor.org/info/rfc4448>. February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>. 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>. 2009, <https://www.rfc-editor.org/info/rfc5462>.
[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>.
[RFC6658] Bryant, S., Ed., Martini, L., Swallow, G., and A. Malis, [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
"Packet Pseudowire Encapsulation over an MPLS PSN", (IPv6) Specification", STD 86, RFC 8200,
RFC 6658, DOI 10.17487/RFC6658, July 2012, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc6658>. <https://www.rfc-editor.org/info/rfc8200>.
13.2. Informative references 13.2. Informative references
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Field, B., daniel.voyer@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
segment-routing-header-07 (work in progress), July 2017. Header (SRH)", draft-ietf-6man-segment-routing-header-08
(work in progress), January 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-03 (work in progress), August 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
(work in progress), October 2016. (work in progress), October 2016.
[I-D.sdt-detnet-security] [I-D.sdt-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Mizrahi, T., Grossman, E., Hacker, A., Das, S.,
"Deterministic Networking (DetNet) Security "Deterministic Networking (DetNet) Security
skipping to change at page 34, line 20 skipping to change at page 35, line 27
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005, DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>. <https://www.rfc-editor.org/info/rfc3985>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>. September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>. <https://www.rfc-editor.org/info/rfc7551>.
 End of changes. 92 change blocks. 
657 lines changed or deleted 680 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/