draft-ietf-detnet-ip-02.txt   draft-ietf-detnet-ip-03.txt 
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: April 18, 2020 L. Berger Expires: April 29, 2020 L. Berger
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
Independent Independent
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
October 16, 2019 October 27, 2019
DetNet Data Plane: IP DetNet Data Plane: IP
draft-ietf-detnet-ip-02 draft-ietf-detnet-ip-03
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
operating in an IP packet switched network. operating in an IP packet switched network.
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 April 18, 2020. This Internet-Draft will expire on April 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4
4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6
4.1. End-System Specific Considerations . . . . . . . . . . . 7 4.1. End-system-specific Considerations . . . . . . . . . . . 7
4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7
4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9
4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9
4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10
4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 10 4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 10
4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11
4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12
5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12
5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12
5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13
5.1.2. Other Protocol Header Information . . . . . . . . . . 14 5.1.2. Other Protocol Header Information . . . . . . . . . . 14
5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15
5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15
6. Management and Control Information Summary . . . . . . . . . 16 6. Management and Control Information Summary . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative references . . . . . . . . . . . . . . . . . . 18 10.1. Normative references . . . . . . . . . . . . . . . . . . 18
10.2. Informative references . . . . . . . . . . . . . . . . . 20 10.2. Informative references . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 the DetNet General background and concepts of DetNet can be found in the DetNet
Architecture [I-D.ietf-detnet-architecture]. Architecture [I-D.ietf-detnet-architecture].
This document specifies the DetNet data plane operation for IP hosts This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data. No and routers that provide DetNet service to IP encapsulated data. No
DetNet specific encapsulation is defined to support IP flows, instead DetNet-specific encapsulation is defined to support IP flows, instead
the existing IP and higher layer protocol header information is used the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery. Common to support flow identification and DetNet service delivery. Common
data plane procedures and control information for all DetNet data data plane procedures and control information for all DetNet data
planes can be found in the [I-D.ietf-detnet-data-plane-framework]. planes can be found in the [I-D.ietf-detnet-data-plane-framework].
The DetNet Architecture models the DetNet related data plane The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: functions into two sub- functions as two sub-layers: functions into two sub-layers: a service
layers: a service sub-layer and a forwarding sub-layer. The service sub-layer and a forwarding sub-layer. The service sub-layer is used
sub-layer is used to provide DetNet service protection and to provide DetNet service protection (e.g., by packet replication and
reordering. The forwarding sub-layer is used to provides congestion packet elimination functions) and reordering. The forwarding sub-
protection (low loss, assured latency, and limited out-of-order layer is used to provides congestion protection (low loss, assured
delivery). Since no DetNet specific headers are added to support latency, and limited out-of-order delivery). The service sub-layer
DetNet IP flows, only the forwarding sub-layer functions are generally requires additional fields to provide its service; for
supported using the DetNet IP defined by this document. Service example see [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields
protection can be provided on a per sub-net basis using technologies are added to support DetNet IP flows, only the forwarding sub-layer
such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified functions are supported using the DetNet IP defined by this document.
in the IEEE 802.1 TSN task group(referred to in this document simply Service protection can be provided on a per sub-net basis using
as IEEE802.1 TSN). technologies such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet
as specified in the IEEE 802.1 TSN task group(referred to in this
document simply as IEEE802.1 TSN).
This document provides an overview of the DetNet IP data plane in This document provides an overview of the DetNet IP data plane in
Section 3, considerations that apply to providing DetNet services via Section 3, considerations that apply to providing DetNet services via
the DetNet IP data plane in Section 4. Section 5 provides the the DetNet IP data plane in Section 4. Section 5 provides the
procedures for hosts and routers that support IP-based DetNet procedures for hosts and routers that support IP-based DetNet
services. Section 6 summarizes the set of information that is needed services. Section 6 summarizes the set of information that is needed
to identify an individual DetNet flow. to identify an individual DetNet flow.
2. Terminology 2. Terminology
skipping to change at page 3, line 50 skipping to change at page 4, line 4
The following abbreviations used in this document: The following abbreviations used in this document:
CoS Class of Service. CoS Class of Service.
DetNet Deterministic Networking. DetNet Deterministic Networking.
DN DetNet. DN DetNet.
DiffServ Differentiated Services DiffServ Differentiated Services
DSCP Differentiated Services Code Point DSCP Differentiated Services Code Point
ECN Explicit Congestion Notification.
L2 Layer-2. L2 Layer-2.
L3 Layer-3. L3 Layer-3.
LSP Label-switched path. LSP Label-switched path.
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching.
PREOF Packet Replication, Ordering and Elimination Function. PREOF Packet Replication, Elimination and Ordering Function.
QoS Quality of Service. QoS Quality of Service.
TSN Time-Sensitive Networking, TSN is a Task Group of the TSN Time-Sensitive Networking, TSN is a Task Group of the
IEEE 802.1 Working Group. IEEE 802.1 Working Group.
2.3. Requirements Language 2.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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. DetNet IP Data Plane Overview 3. DetNet IP Data Plane Overview
This document describes how IP is used by DetNet nodes, i.e., hosts This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, identify DetNet flows and provide a DetNet service using and routers, to identify DetNet flows and provide a DetNet service
an IP data plane. From a data plane perspective, an end-to-end IP using an IP data plane. From a data plane perspective, an end-to-end
model is followed. As mentioned above, existing IP and higher layer IP model is followed. As mentioned above, existing IP and higher
protocol header information is used to support flow identification layer protocol header information is used to support flow
and DetNet service delivery. Common data plane procedures and identification and DetNet service delivery. Common data plane
control information for all DetNet data planes can be found in the procedures and control information for all DetNet data planes can be
[I-D.ietf-detnet-data-plane-framework]. found in the [I-D.ietf-detnet-data-plane-framework].
The DetNet IP data plane primarily uses "6-tuple" based flow The DetNet IP data plane primarily uses "6-tuple" based flow
identification, where 6-tuple refers to information carried in IP and identification, where 6-tuple refers to information carried in IP and
higher layer protocol headers. The 6-tuple referred to in this higher layer protocol headers. The 6-tuple referred to in this
document is the same as that defined in [RFC3290]. Specifically document is the same as that defined in [RFC3290]. Specifically
6-tuple is (destination address, source address, IP protocol, source 6-tuple is (destination address, source address, IP protocol, source
port, destination port, and differentiated services (DiffServ) code port, destination port, and differentiated services (DiffServ) code
point (DSCP). General background on the use of IP headers, and point (DSCP). General background on the use of IP headers, and
5-tuples, to identify flows and support Quality of Service (QoS) can 5-tuples, to identify flows and support Quality of Service (QoS) can
be found in [RFC3670]. [RFC7657] also provides useful background on be found in [RFC3670]. [RFC7657] also provides useful background on
the delivery of DiffServ and "tuple" based flow identification. the delivery of DiffServ and "tuple" based flow identification.
The DetNet IP data plane also allows for optional matching on two The DetNet IP data plane also allows for optional matching on the
additional data fields. The optional fields are the ECN Field, as in IPv6 flow label field, as defined in [RFC8200].
[RFC3168], and the IPv6 flow label field, as defined in [RFC8200].
Generally the fields used in flow identification are forward Non-DetNet and DetNet IP packets are identical on the wire.
unmodified but modification is allowed, for example to a DSCP value, Generally the fields used in flow identification are forwarded
when required by the DetNet service. unmodified, however modification of these fields is allowed, for
example to a DSCP value, when required by the DetNet service.
DetNet flow aggregation may be enabled via the use of wildcards, DetNet flow aggregation may be enabled via the use of wildcards,
masks, lists, prefixes and ranges. IP tunnels may also be used to masks, lists, prefixes and ranges. IP tunnels may also be used to
support flow aggregation. In these cases, it is expected that DetNet support flow aggregation. In these cases, it is expected that
aware intermediate nodes will provide DetNet service assurance on the DetNet-aware intermediate nodes will provide DetNet service on the
aggregate through resource allocation and congestion control aggregate through resource allocation and congestion control
mechanisms. mechanisms.
DetNet IP Relay Relay DetNet IP DetNet IP Relay Relay DetNet IP
End System Node Node End System End System Node Node End System
+----------+ +----------+ +----------+ +----------+
| Appl. |<------------ End to End Service ----------->| Appl. | | Appl. |<------------ End to End Service ----------->| Appl. |
+----------+ ............ ........... +----------+ +----------+ ............ ........... +----------+
| Service |<-: Service :-- DetNet flow --: Service :->| Service | | Service |<-: Service :-- DetNet flow --: Service :->| Service |
skipping to change at page 5, line 40 skipping to change at page 5, line 40
: Link : \ ,-----. / \ ,-----. / : Link : \ ,-----. / \ ,-----. /
+......+ +----[ Sub ]----+ +-[ Sub ]-+ +......+ +----[ Sub ]----+ +-[ Sub ]-+
[Network] [Network] [Network] [Network]
`-----' `-----' `-----' `-----'
|<--------------------- DetNet IP --------------------->| |<--------------------- DetNet IP --------------------->|
Figure 1: A Simple DetNet (DN) Enabled IP Network Figure 1: A Simple DetNet (DN) Enabled IP Network
Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled
end systems originate IP encapsulated traffic that is identified as end systems originate IP encapsulated traffic those are identified
DetNet flows, relay nodes understand the forwarding requirements of within the DetNet domain as DetNet flows, relay nodes understand the
the DetNet flow and ensure that node, interface and sub-network forwarding requirements of the DetNet flow and ensure that node,
resources are allocated to ensure DetNet service requirements. The interface and sub-network resources are allocated to ensure DetNet
dotted line around the Service component of the Relay Nodes indicates service requirements. The dotted line around the Service component
that the transit routers are DetNet service aware but do not perform of the Relay Nodes indicates that the transit routers are DetNet
any DetNet service sub-layer function, e.g., PREOF. IEEE 802.1 TSN service aware but do not perform any DetNet service sub-layer
is an example sub-network type which can provide support for DetNet function, e.g., PREOF.
flows and service.
Note: The sub-network can represent a TSN, MPLS or IP network Note: The sub-network can represent a TSN, MPLS or IP network
segment. segment.
IP Edge Edge IP IP Edge Edge IP
End System Node Node End System End System Node Node End System
+----------+ +.........+ +.........+ +----------+ +----------+ +.........+ +.........+ +----------+
| Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. |
+----------+ +.........+ +.........+ +----------+ +----------+ +.........+ +.........+ +----------+
skipping to change at page 6, line 22 skipping to change at page 6, line 22
+----------+ +---+ +---+ +---+ +---+ +----------+ +----------+ +---+ +---+ +---+ +---+ +----------+
|Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding|
+--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+
: Link : \ ,-----. / / ,-----. \ : Link : \ ,-----. / / ,-----. \
+.......+ +----[ Sub ]----+ +--[ Sub ]--+ +.......+ +----[ Sub ]----+ +--[ Sub ]--+
[Network] [Network] [Network] [Network]
`-----' `-----' `-----' `-----'
|<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->|
Figure 2: Non-DetNet aware IP end systems with DetNet IP Domain Figure 2: Non-DetNet-aware IP end systems with DetNet IP Domain
Figure 2 illustrates a variant of Figure 1 where the end systems are Figure 2 illustrates a variant of Figure 1 where the end systems are
not DetNet aware. In this case, edge nodes sit at the boundary of not DetNet aware. In this case, edge nodes sit at the boundary of
the DetNet domain and provide DetNet service proxies for the end the DetNet domain and provide DetNet service proxies for the end
applications by initiating and terminating DetNet service for the applications by initiating and terminating DetNet service for the
application's IP flows. The existing header information or an application's IP flows. The existing header information or an
approach such as described in Section 4.4 can be used to support approach such as described in Section 4.4 can be used to support
DetNet flow identification. DetNet flow identification.
Note, that Figure 1 and Figure 2 can be combined, so IP DetNet End Note, that Figure 1 and Figure 2 can be collapsed, so IP DetNet End
Systems can communicate over DetNet IP network with IP End System. Systems can communicate over DetNet IP network with IP End System.
Non-DetNet and DetNet IP packets are identical on the wire. From As non-DetNet and DetNet IP packets are identical on the wire, from
data plane perspective, the only difference is that there is flow- data plane perspective, the only difference is that there is flow-
associated DetNet information on each DetNet node that defines the associated DetNet information on each DetNet node that defines the
flow related characteristics and required forwarding behavior. As flow related characteristics and required forwarding behavior. As
shown above, edge nodes provide a Service Proxy function that shown above, edge nodes provide a Service Proxy function that
"associates" one or more IP flows with the appropriate DetNet flow- "associates" one or more IP flows with the appropriate DetNet flow-
specific information and ensures that the receives the proper traffic specific information and ensures that the receives the proper traffic
treatment within the domain. treatment within the domain.
Note: The operation of IEEE802.1 TSN end systems over DetNet enabled Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
IP networks is not described in this document. TSN over MPLS is IP networks is not described in this document. TSN over MPLS is
discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls]. discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls].
4. DetNet IP Data Plane Considerations 4. DetNet IP Data Plane Considerations
This section provides informative considerations related to providing This section provides informative considerations related to providing
DetNet service to flows which are identified based on their header DetNet service to flows which are identified based on their header
information. information.
4.1. End-System Specific Considerations 4.1. End-system-specific Considerations
Data-flows requiring DetNet service are generated and terminated on Data-flows requiring DetNet service are generated and terminated on
end systems. This document deals only with IP end systems. The end systems. This document deals only with IP end systems. The
protocols used by an IP end system are specific to an application and protocols used by an IP end system are specific to an application,
end systems peer with end systems using the same application and end systems peer with other end systems. DetNet's use of 6-tuple
encapsulation format. This said, DetNet's use of 6-tuple IP flow IP flow identification means that DetNet must be aware of not only
identification means that DetNet must be aware of not only the format the format of the IP header, but also of the next protocol carried
of the IP header, but also of the next protocol carried within an IP within an IP packet (see Section 5.1.1.3).
packet.
When IP end systems are DetNet aware, no application-level or When IP end systems are DetNet-aware, no application-level or
service-level proxy functions are needed inside the DetNet domain. service-level proxy functions are needed inside the DetNet domain.
For DetNet unaware IP end systems service-level proxy functions are For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain. needed inside the DetNet domain.
End systems need to ensure that DetNet service requirements are met End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow. When when processing packets associated to a DetNet flow. When forwarding
forwarding packets, this means that packets are appropriately shaped packets, this means that packets are appropriately shaped on
on transmission and received appropriate traffic treatment on the transmission and receive appropriate traffic treatment on the
connected sub-network, see Section 4.3.2 and Section 4.2 for more connected sub-network, see Section 4.3.2 and Section 4.2 for more
details. When receiving packets, this means that there are details. When receiving packets, this means that there are
appropriate local node resources, e.g., buffers, to receive and appropriate local node resources, e.g., buffers, to receive and
process a DetNet flow packets. process the packets of that DetNet flow.
In order to maximize reuse of 5-tuple based mechanisms, e.g, In order to maximize reuse of 5-tuple based mechanisms, e.g,
traceroute, DetNet aware applications and end systems SHOULD NOT mix traceroute, DetNet-aware applications and end systems SHOULD NOT mix
DetNet and non-DetNet traffic within a single 5-tuple. DetNet and non-DetNet traffic within a single 5-tuple.
4.2. DetNet Domain-Specific Considerations 4.2. DetNet Domain-Specific Considerations
As a general rule, DetNet IP domains need to be able to forward any As a general rule, DetNet IP domains need to be able to forward any
DetNet flow identified by the IP 6-tuple. Doing otherwise would DetNet flow identified by the IP 6-tuple. Doing otherwise would
limit end system encapsulation format. From a practical standpoint limit the number of 6-tuple flow ID combinations that could be used
this means that all nodes along the end-to-end path of DetNet flows by the end systems. From a practical standpoint this means that all
need to agree on what fields are used for flow identification, and nodes along the end-to-end path of DetNet flows need to agree on what
the transport protocols (e.g., TCP/UDP/IPsec) which can be used to fields are used for flow identification, and the transport protocols
identify 6-tuple protocol ports. (e.g., TCP/UDP/IPsec) which can be used to identify 6-tuple protocol
ports.
From a connection type perspective two scenarios are identified: From a connection type perspective two scenarios are identified:
1. DN attached: end system is directly connected to an edge node or 1. DN attached: the end system is directly connected to an edge
end system is behind a sub-network. (See ES1 and ES2 in figure node, or the end system is behind a sub-network (See ES1 and ES2
below)
2. DN integrated: end system is part of the DetNet domain. (See ES3
in figure below) in figure below)
2. DN integrated: the end system is part of the DetNet domain. (See
ES3 in figure below)
L3 (IP) end systems may use any of these connection types. A DetNet L3 (IP) end systems may use any of these connection types. A DetNet
domain allows communication between any end-systems using the same domain allows communication between any end-systems using the same
encapsulation format, independent of their connection type and DetNet encapsulation format, independent of their connection type and DetNet
capability. DN attached end systems have no knowledge about the capability. DN attached end systems have no knowledge about the
DetNet domain and its encapsulation format. See Figure 3 for L3 end DetNet domain and its encapsulation format. See Figure 3 for L3 end
system connection examples. system connection examples.
____+----+ ____+----+
+----+ _____ / | ES3| +----+ _____ / | ES3|
| ES1|____ / \__/ +----+___ | ES1|____ / \__/ +----+___
+----+ \ / \ +----+ \ / \
+ | + |
____ \ _/ ____ \ _/
+----+ __/ \ +__ DetNet IP domain / +----+ __/ \ +__ DetNet IP domain /
| ES2|____/ L2/L3 |___/ \ __ __/ | ES2|____/ L2/L3 |___/ \ __ __/
+----+ \_______/ \_______/ \___/ +----+ \_______/ \_______/ \___/
Figure 3: Connection types of L3 end systems Figure 3: Connection types of L3 end systems
Within a DetNet domain, the DetNet enabled IP Routers are Within a DetNet domain, the DetNet-enabled IP Routers are
interconnected by links and sub-networks to support end-to-end interconnected by links and sub-networks to support end-to-end
delivery of DetNet flows. From a DetNet architecture perspective, delivery of DetNet flows. From a DetNet architecture perspective,
these routers are DetNet relays, as they must be DetNet service these routers are DetNet relays, as they must be DetNet service
aware. Such routers identify DetNet flows based on the IP 6-tuple, aware. Such routers identify DetNet flows based on the IP 6-tuple,
and ensure that the DetNet service required traffic treatment is and ensure that the DetNet service required traffic treatment is
provided both on the node and on any attached sub-network. provided both on the node and on any attached sub-network.
This solution provides DetNet functions end to end, but does so on a This solution provides DetNet functions end to end, but does so on a
per link and sub-network basis. Congestion protection and latency per link and sub-network basis. Congestion protection and latency
control and the resource allocation (queuing, policing, shaping) are control and the resource allocation (queuing, policing, shaping) are
supported using the underlying link / sub net specific mechanisms. supported using the underlying link / sub net specific mechanisms.
However, service protections (packet replication and packet However, service protection (packet replication and packet
elimination functions) are not provided at the DetNet layer end to elimination functions) is not provided at the DetNet layer end to
end. Instead service protection can be provided on a per underlying end. Instead service protection can be provided on a per underlying
L2 link and sub-network basis. L2 link and sub-network basis.
The DetNet Service Flow is mapped to the link / sub-network specific The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system specific means. This implies resources using an underlying system-specific means. This implies
each DetNet aware node on path looks into the forwarded DetNet each DetNet-aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 6-tuple to find out the Service Flow packet and utilize e.g., a 6-tuple to find out the
required mapping within a node. required mapping within a node.
As noted earlier, the Service Protection is done within each link / As noted earlier, service protection must be implemented within each
sub-network independently using the domain specific mechanisms (due link / sub-network independently, using the domain specific
the lack of a unified end to end sequencing information that would be mechanisms. This is due to the lack of unified end-to-end sequencing
available for intermediate nodes). Therefore, service protection (if information that could be used by the intermediate nodes. Therefore,
enabled) cannot be provided end-to-end, only within sub-networks. service protection (if enabled) cannot be provided end-to-end, only
This is shown for a three sub-network scenario in Figure 4, where within sub-networks. This is shown for a three sub-network scenario
each sub-network can provide service protection between its borders. in Figure 4, where each sub-network can provide service protection
"R" and "E" denotes replication and elimination points within the between its borders. "R" and "E" denotes replication and elimination
sub-network. points within the sub-network.
<-------------------- DenNet IP ------------------------> <-------------------- DenNet IP ------------------------>
______ ______
____ / \__ ____ / \__
____ / \__/ \___ ______ ____ / \__/ \___ ______
+----+ __/ +====+ +==+ \ +----+ +----+ __/ +====+ +==+ \ +----+
|src |__/ SubN1 ) | | \ SubN3 \____| dst| |src |__/ SubN1 ) | | \ SubN3 \____| dst|
+----+ \_______/ \ Sub-Network2 | \______/ +----+ +----+ \_______/ \ Sub-Network2 | \______/ +----+
\_ _/ \_ _/
\ __ __/ \ __ __/
skipping to change at page 9, line 37 skipping to change at page 9, line 37
Figure 4: Replication and elimination in sub-networks for DetNet IP Figure 4: Replication and elimination in sub-networks for DetNet IP
networks networks
If end to end service protection is desired, it can be implemented, If end to end service protection is desired, it can be implemented,
for example, by the DetNet end systems using Layer-4 (L4) transport for example, by the DetNet end systems using Layer-4 (L4) transport
protocols or application protocols. However, these protocols are out protocols or application protocols. However, these protocols are out
of scope of this document. of scope of this document.
Note that not mixing DetNet and non-DetNet traffic within a single Note that not mixing DetNet and non-DetNet traffic within a single
5-tuple, as described above, enables simpler 5-tuple filters to be 5-tuple, as described above, enables simpler 5-tuple filters to be
reused at the edges of a DetNet network to prevent non-congestion used (or re-used) at the edges of a DetNet network to prevent non-
responsive DetNet traffic from escaping the DetNet domain. congestion-responsive DetNet traffic from escaping the DetNet domain.
4.3. Forwarding Sub-Layer Considerations 4.3. Forwarding Sub-Layer Considerations
4.3.1. Class of Service 4.3.1. Class of Service
Class of Service (CoS) for DetNet flows carried in IPv6 is provided Class of Service (CoS) for DetNet flows carried in IPv6 is provided
using the standard differentiated services code point (DSCP) field using the standard differentiated services code point (DSCP) field
[RFC2474] and related mechanisms. The 2-bit explicit congestion [RFC2474] and related mechanisms.
notification (ECN) [RFC3168] field MAY also be used.
One additional consideration for DetNet nodes which support CoS One additional consideration for DetNet nodes which support CoS
services is that they MUST ensure that the CoS service classes do not services is that they MUST ensure that the CoS service classes do not
impact the congestion protection and latency control mechanisms used impact the congestion protection and latency control mechanisms used
to provide DetNet QoS. This requirement is similar to requirement to provide DetNet QoS. This requirement is similar to the
for MPLS LSRs to that CoS LSPs do not impact the resources allocated requirement for MPLS LSRs that CoS LSPs cannot impact the resources
to TE LSPs via [RFC3473]. allocated to TE LSPs [RFC3473].
4.3.2. Quality of Service 4.3.2. Quality of Service
Quality of Service (QoS) for DetNet service flows carried in IP MUST Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows. Such support leverages the underlying network layer DetNet flows. Such support leverages the underlying network layer
such as 802.1 TSN. The traffic control mechanisms used to deliver such as 802.1 TSN. The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a QoS for IP encapsulated DetNet flows are expected to be defined in a
future document. From an encapsulation perspective, the combination future document. From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
previously mentioned two optional fields, uniquely identifies a previously mentioned optional field, uniquely identifies a DetNet IP
DetNet service flow. flow.
Packets that are marked with a DetNet Class of Service value, but Packets that are identified as part of a DetNet IP flow but that have
that have not been the subject of a completed reservation, can not been the subject of a completed reservation, can disrupt the QoS
disrupt the QoS offered to properly reserved DetNet flows by using offered to properly reserved DetNet flows by using resources
resources allocated to the reserved flows. Therefore, the network allocated to the reserved flows. Therefore, the network nodes of a
nodes of a DetNet network must: DetNet network MUST ensure that no DetNet allocated resources, e.g.,
queue or shaper, is used by such flows. There are multiple methods
that MAY be used by an implementation to defend service delivery to
reserved DetNet flows, including but not limited to:
o Defend the DetNet QoS by discarding or remarking (to a non-DetNet o Treating packets associated with an incomplete reservation as non-
CoS) packets received that are not the subject of a completed DetNet traffic.
reservation.
o Not use a DetNet reserved resource, e.g. a queue or shaper o Discarding packets associated with an incomplete reservation.
reserved for DetNet flows, for any packet that does not carry a
DetNet Class of Service marker. o Remarking packets associated with an incomplete reservation.
Remarking can be accomplished by changing the value of the DSCP,
or optional, field to a value that results in the packet no longer
matching any other reserved DetNet IP flow.
4.3.3. Path Selection 4.3.3. Path Selection
While path selection algorithms and mechanisms are out of scope of While path selection algorithms and mechanisms are out of scope of
the DetNet data plane definition, it is important to highlight the the DetNet data plane definition, it is important to highlight the
implications of DetNet IP flow identification on path selection and implications of DetNet IP flow identification on path selection and
next hops. As mentioned above, the DetNet IP data plane identifies next hops. As mentioned above, the DetNet IP data plane identifies
flows using "6-tuple" header information as well as two additional flows using "6-tuple" header information as well as the additional
optional header fields. DetNet generally allows for both flow- optional header field. DetNet generally allows for both flow-
specific traffic treatment and flow-specific next-hops. specific traffic treatment and flow-specific next-hops.
In non-DetNet IP forwarding, it is generally assumed that the same In non-DetNet IP forwarding, it is generally assumed that the same
series of next hops, i.e., the same path, will be used for a series of next hops, i.e., the same path, will be used for a
particular 5-tuple or, in some cases, e.g., [RFC5120], for a particular 5-tuple or, in some cases, e.g., [RFC5120], for a
particular 6-tuple. Using different next hops for different 5-tuples particular 6-tuple. Using different next hops for different 5-tuples
does not take any special consideration for DetNet aware does not take any special consideration for DetNet-aware
applications. applications.
Care should be taken when using different next hops for the same Care should be taken when using different next hops for the same
5-tuple. As discussed in [RFC7657], unexpected behavior can occur 5-tuple. As discussed in [RFC7657], unexpected behavior can occur
when a single 5-tuple application flow experience reordering due to when a single 5-tuple application flow experience reordering due to
being split across multiple next hops. Understanding of the being split across multiple next hops. Understanding of the
application and transport protocol impact of using different next application and transport protocol impact of using different next
hops for the same 6-tuple is required. Again, this impacts path hops for the same 6-tuple is required. Again, this impacts path
selection for DetNet flows and this document only indirectly. selection for DetNet flows and this document only indirectly.
skipping to change at page 11, line 36 skipping to change at page 11, line 41
management or control function that provisions the aggregate flows management or control function that provisions the aggregate flows
must ensure that adequate resources are allocated and configured to must ensure that adequate resources are allocated and configured to
provide combined service requirements of the individual flows. As provide combined service requirements of the individual flows. As
DetNet is concerned about latency and jitter, more than just DetNet is concerned about latency and jitter, more than just
bandwidth needs to be considered. bandwidth needs to be considered.
From a single node perspective, the aggregation of IP flows impacts From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation. As DetNet IP data plane flow identification and resource allocation. As
discussed above, IP flow identification uses the IP "6-tuple" for discussed above, IP flow identification uses the IP "6-tuple" for
flow identification. DetNet IP flows can be aggregated using any of flow identification. DetNet IP flows can be aggregated using any of
the 6-tuple, or two additional optional fields defined in the 6-tuple, and an additional optional field defined in Section 5.1.
Section 5.1. The use of prefixes, wildcards, lists, and value ranges The use of prefixes, wildcards, lists, and value ranges allows a
allows a DetNet node to identify aggregate DetNet flows. From a DetNet node to identify aggregate DetNet flows. From a resource
resource allocation perspective, DetNet nodes must provide service to allocation perspective, DetNet nodes must provide service to an
a aggregate and not on a component flow basis. aggregate and not on a component flow basis.
It is the responsibility of the DetNet controller plane to properly It is the responsibility of the DetNet controller plane to properly
provision the use of these aggregation mechanisms. This includes provision the use of these aggregation mechanisms. This includes
ensuring that aggregated flows have compatible e.g., the same or very ensuring that aggregated flows have compatible e.g., the same or very
similar QoS and/or CoS characteristics, see Section 4.3.2. It also similar QoS and/or CoS characteristics, see Section 4.3.2. It also
includes ensuring that per component-flow service requirements are includes ensuring that per component-flow service requirements are
satisfied by the aggregate, see Section 5.3. satisfied by the aggregate, see Section 5.3.
4.5. Bidirectional Traffic 4.5. Bidirectional Traffic
skipping to change at page 13, line 5 skipping to change at page 13, line 5
mechanisms such as those that may be provided in YANG models mechanisms such as those that may be provided in YANG models
[I-D.ietf-detnet-yang]. [I-D.ietf-detnet-yang].
5.1. DetNet IP Flow Identification Procedures 5.1. DetNet IP Flow Identification Procedures
IP and higher layer protocol header information is used to identify IP and higher layer protocol header information is used to identify
DetNet flows. All DetNet implementations that support this document DetNet flows. All DetNet implementations that support this document
MUST identify individual DetNet flows based on the set of information MUST identify individual DetNet flows based on the set of information
identified in this section. Note, that additional flow identified in this section. Note, that additional flow
identification requirements, e.g., to support other higher layer identification requirements, e.g., to support other higher layer
protocols, may be defined in future. protocols, may be defined in the future.
The configuration and control information used to identify an The configuration and control information used to identify an
individual DetNet flow MUST be ordered by an implementation. individual DetNet flow MUST be ordered by an implementation.
Implementations MUST support a fixed order when identifying flows, Implementations MUST support a fixed order when identifying flows,
and MUST identify a DetNet flow by the first set of matching flow and MUST identify a DetNet flow by the first set of matching flow
information. information.
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
identification when the implementation is acting as a DetNet end identification when the implementation is acting as a DetNet end
systems, a relay node or as an edge node. systems, a relay node, or as an edge node.
5.1.1. IP Header Information 5.1.1. IP Header Information
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
identification based on IP header information. The IPv4 header is identification based on IP header information. The IPv4 header is
defined in [RFC0791] and the IPv6 is defined in [RFC8200]. defined in [RFC0791] and the IPv6 is defined in [RFC8200].
5.1.1.1. Source Address Field 5.1.1.1. Source Address Field
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
skipping to change at page 13, line 47 skipping to change at page 13, line 47
of zero (0) effectively means that the field is ignored. of zero (0) effectively means that the field is ignored.
Note: any IP address value is allowed, including an IP multicast Note: any IP address value is allowed, including an IP multicast
destination address. destination address.
5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
identification based on the IPv4 Protocol field when processing IPv4 identification based on the IPv4 Protocol field when processing IPv4
packets, and the IPv6 Next Header Field when processing IPv6 packets. packets, and the IPv6 Next Header Field when processing IPv6 packets.
An implementation MUST support flow identification based based the An implementation MUST support flow identification based on the next
next protocol values defined in Section 5.1.2. Other, non-zero protocol values defined in Section 5.1.2. Other, non-zero values,
values, MUST be used for flow identification. Implementations SHOULD MUST be used for flow identification. Implementations SHOULD allow
allow for these fields to be ignored for a specific DetNet flow. for these fields to be ignored for a specific DetNet flow.
5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields
These fields are used to support Differentiated Services [RFC2474] These fields are used to support Differentiated Services [RFC2474]
and Explicit Congestion Notification [RFC3168]. Implementations of [RFC2475]. Implementations of this document MUST support DetNet flow
this document MUST support DetNet flow identification based on the identification based on the DSCP field in the IPv4 Type of Service
IPv4 Type of Service field when processing IPv4 packets, and the IPv6 field when processing IPv4 packets, and the DSCP field in the IPv6
Traffic Class Field when processing IPv6 packets. Implementations Traffic Class Field when processing IPv6 packets. Implementations
MUST support list based matching of DSCP values, where the list is MUST support list based matching of DSCP values, where the list is
composed of possible field values that are to be considered when composed of possible field values that are to be considered when
identifying a specific DetNet flow. Implementations SHOULD allow for identifying a specific DetNet flow. Implementations SHOULD allow for
this field to be ignored for a specific DetNet flow. this field to be ignored for a specific DetNet flow.
Implementations of this document MUST allow the ECN field to be
ignored as part of DetNet flow identification. Additionally,
implementations SHOULD support identification of DetNet flows based
on the value carried in the ECN field. When this field is used to
identify a specific DetNet flow, implementations MUST support a list
of ECN values that match a specific slow.
5.1.1.5. IPv6 Flow Label Field 5.1.1.5. IPv6 Flow Label Field
Implementations of this document SHOULD support identification of Implementations of this document SHOULD support identification of
DetNet flows based on the IPv6 Flow Label field. Implementations DetNet flows based on the IPv6 Flow Label field. Implementations
that support matching based on this field MUST allow for this field that support matching based on this field MUST allow for this field
to be ignored for a specific DetNet flow. When this field is used to to be ignored for a specific DetNet flow. When this field is used to
identify a specific DetNet flow, implementations MAY exclude the IPv6 identify a specific DetNet flow, implementations MAY exclude the IPv6
Next Header field and next header information as part of DetNet flow Next Header field and next header information as part of DetNet flow
identification. identification.
skipping to change at page 15, line 35 skipping to change at page 15, line 31
i.e., an exact value. Implementation SHOULD also allow for the field i.e., an exact value. Implementation SHOULD also allow for the field
to be ignored for a specific DetNet flow. to be ignored for a specific DetNet flow.
5.2. Forwarding Procedures 5.2. Forwarding Procedures
General requirements for IP nodes are defined in [RFC1122], [RFC1812] General requirements for IP nodes are defined in [RFC1122], [RFC1812]
and [RFC6434], and are not modified by this document. The typical and [RFC6434], and are not modified by this document. The typical
next-hop selection process is impacted by DetNet. Specifically, next-hop selection process is impacted by DetNet. Specifically,
implementations of this document SHALL use management and control implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next information to select the one or more outgoing interfaces and next
hops to be used for a packet belonging to a DetNet flow. hops to be used for a packet associated with a DetNet flow.
The use of multiple paths or links, e.g., ECMP, to support a single The use of multiple paths or links, e.g., ECMP, to support a single
DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet
flows within a DetNet domain. flows within a DetNet domain.
The above implies that management and control functions will be The above implies that management and control functions will be
defined to support this requirement, e.g., see defined to support this requirement, e.g., see
[I-D.ietf-detnet-yang]. [I-D.ietf-detnet-yang].
5.3. DetNet IP Traffic Treatment Procedures 5.3. DetNet IP Traffic Treatment Procedures
Implementations if this document MUST ensure that a DetNet flow Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via configuration or the controller plane, e.g., via
[I-D.ietf-detnet-yang]. General information on DetNet service can be [I-D.ietf-detnet-yang]. General information on DetNet service can be
found in [I-D.ietf-detnet-flow-information-model]. Typical found in [I-D.ietf-detnet-flow-information-model]. Typical
mechanisms used to provide different treatment to different flows mechanisms used to provide different treatment to different flows
includes the allocation of system resources (such as queues and includes the allocation of system resources (such as queues and
buffers) and provisioning or related parameters (such as shaping, and buffers) and provisioning or related parameters (such as shaping, and
policing). Support can also be provided via an underlying network policing). Support can also be provided via an underlying network
technology such as MPLS [I-D.ietf-detnet-ip-over-mpls]. and technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1
IEEE802.1 TSN [I-D.ietf-detnet-ip-over-tsn]. Other than in the TSN TSN [I-D.ietf-detnet-ip-over-tsn]. Other than in the TSN case, the
case, the specific mechanisms used by a DetNet node to ensure DetNet specific mechanisms used by a DetNet node to ensure DetNet service
service delivery requirements are met for supported DetNet flows is delivery requirements are met for supported DetNet flows is outside
outside the scope of this document. the scope of this document.
6. Management and Control Information Summary 6. Management and Control Information Summary
The following summarizes the set of information that is needed to The following summarizes the set of information that is needed to
identify individual and aggregated DetNet flows: identify individual and aggregated DetNet flows:
o IPv4 and IPv6 source address field. o IPv4 and IPv6 source address field.
o IPv4 and IPv6 source address prefix length, where a zero (0) value o IPv4 and IPv6 source address prefix length, where a zero (0) value
effectively means that the address field is ignored. effectively means that the address field is ignored.
skipping to change at page 16, line 45 skipping to change at page 16, line 40
value zero (0), is desirable. value zero (0), is desirable.
o For the IPv4 Type of Service and IPv6 Traffic Class Fields: o For the IPv4 Type of Service and IPv6 Traffic Class Fields:
* If the DSCP field is to be used in flow identification. * If the DSCP field is to be used in flow identification.
Ignoring the DSCP filed is optional. Ignoring the DSCP filed is optional.
* When the DSCP field is used in flow identification, a list of * When the DSCP field is used in flow identification, a list of
field values that may be used by a specific flow. field values that may be used by a specific flow.
* If the ECN field is to be used in flow identification.
Matching based on ECN filed values is optional.
* When ECN field is used in flow identification, a list of field
values that may be used by a specific flow.
o IPv6 flow label field. This field can be optionally used for o IPv6 flow label field. This field can be optionally used for
matching. When used, can be exclusive of matching against the matching. When used, can be used instead of matching against the
next header field. Next Header field.
o TCP and UDP Source Port. Exact and wildcard matching is required. o TCP and UDP Source Port. Exact and wildcard matching is required.
Port ranges can optionally be used. Port ranges can optionally be used.
o TCP and UDP Destination Port. Exact and wildcard matching is o TCP and UDP Destination Port. Exact and wildcard matching is
required. Port ranges can optionally be used. required. Port ranges can optionally be used.
o IPsec Header SPI field. Exact matching is required. o IPsec Header SPI field. Exact matching is required.
This information MUST be provisioned per DetNet flow via This information MUST be provisioned per DetNet flow via
skipping to change at page 18, line 36 skipping to change at page 18, line 25
8. IANA Considerations 8. IANA Considerations
This document does not require an action from IANA. This document does not require an action from IANA.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
Bernardos for their various contributions to this work. Bernardos for their various contributions to this work. David Black
served as technical advisor to the DetNet working group during the
development of this document and provided many valuable comments.
10. References 10. References
10.1. Normative references 10.1. Normative references
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
skipping to change at page 19, line 20 skipping to change at page 19, line 11
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
of Explicit Congestion Notification (ECN) to IP", and W. Weiss, "An Architecture for Differentiated
RFC 3168, DOI 10.17487/RFC3168, September 2001, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>. <https://www.rfc-editor.org/info/rfc3473>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
skipping to change at page 20, line 46 skipping to change at page 20, line 39
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over
MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in
progress), July 2019. progress), July 2019.
[I-D.ietf-detnet-ip-over-tsn] [I-D.ietf-detnet-ip-over-tsn]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J. Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time
Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- Sensitive Networking (TSN)", draft-ietf-detnet-ip-over-
tsn-00 (work in progress), May 2019. tsn-00 (work in progress), May 2019.
[I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-01 (work in progress), July 2019.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf- Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-05 (work in progress), August 2019. detnet-security-05 (work in progress), August 2019.
[I-D.ietf-detnet-tsn-vpn-over-mpls] [I-D.ietf-detnet-tsn-vpn-over-mpls]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J. Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive
Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- Networking over MPLS", draft-ietf-detnet-tsn-vpn-over-
 End of changes. 54 change blocks. 
149 lines changed or deleted 146 lines changed or added

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