draft-ietf-detnet-ip-06.txt   draft-ietf-detnet-ip-07.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: October 25, 2020 L. Berger Expires: January 4, 2021 L. Berger
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
April 23, 2020 July 3, 2020
DetNet Data Plane: IP DetNet Data Plane: IP
draft-ietf-detnet-ip-06 draft-ietf-detnet-ip-07
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the DetNet data plane operation for IP hosts
operating in an IP packet switched network. and routers that provide DetNet service to IP encapsulated data. No
DetNet-specific encapsulation is defined to support IP flows; instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery. This
document builds on the DetNet Architecture and Data Plane Framework.
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 October 25, 2020. This Internet-Draft will expire on January 4, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 16 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . 7 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 7
4.1. End-system-specific Considerations . . . . . . . . . . . 7 4.1. End System Specific Considerations . . . . . . . . . . . 8
4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 8
4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 10 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 11
4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 10 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 11
4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 11
4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 11 4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 12
4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 12
4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 13
5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 13
5.1. DetNet IP Flow Identification Procedures . . . . . . . . 13 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 14
5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 14
5.1.2. Other Protocol Header Information . . . . . . . . . . 14 5.1.2. Other Protocol Header Information . . . . . . . . . . 15
5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 17
5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 16 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 17
6. Management and Control Information Summary . . . . . . . . . 16 6. Management and Control Information Summary . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative references . . . . . . . . . . . . . . . . . . 19 11.1. Normative references . . . . . . . . . . . . . . . . . . 20
11.2. Informative references . . . . . . . . . . . . . . . . . 20 11.2. Informative references . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 with a network to DetNet flows. DetNet provides these flows with
extremely low packet loss rates and assured maximum end-to-end extremely low packet loss rates and assured maximum end-to-end
delivery latency. General background and concepts of DetNet can be delivery latency. General background and concepts of DetNet can be
found in the DetNet Architecture [RFC8655]. found in the DetNet Architecture [RFC8655].
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 [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 as two sub-layers: a service sub-layer and a forwarding functions as two sub-layers: a service sub-layer and a forwarding
sub-layer. The service sub-layer is used to provide DetNet service sub-layer. The service sub-layer is used to provide DetNet service
protection (e.g., by packet replication and packet elimination protection (e.g., by packet replication and packet elimination
functions) and reordering. The forwarding sub-layer is used to functions) and reordering. The forwarding sub-layer is used to
provide congestion protection (low loss, assured latency, and limited provide congestion protection (low loss, assured latency, and limited
out-of-order delivery). The service sub-layer generally requires out-of-order delivery). The service sub-layer generally requires
additional header fields to provide its service; for example see additional header fields to provide its service; for example see
[I-D.ietf-detnet-mpls]. Since no DetNet-specific fields are added to [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields are added to
support DetNet IP flows, only the forwarding sub-layer functions are support DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP defined by this document. Service supported using the DetNet IP defined by this document. Service
protection can be provided on a per sub-net basis using technologies protection can be provided on a per sub-net basis using technologies
such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified
in the IEEE 802.1 TSN (Time-Sensitive Networking) task group in the IEEE 802.1 TSN (Time-Sensitive Networking) task group
(referred to in this document simply as IEEE802.1 TSN). (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, and considerations that apply to providing DetNet services
the DetNet IP data plane in Section 4. Section 5 provides the via 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
2.1. Terms Used In This Document 2.1. Terms Used In This Document
This document uses the terminology and concepts established in the This document uses the terminology and concepts established in the
DetNet architecture [RFC8655], and the reader is assumed to be DetNet architecture [RFC8655], and the reader is assumed to be
skipping to change at page 4, line 36 skipping to change at page 4, line 40
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, to identify DetNet flows and provide a DetNet service and routers, to identify DetNet flows and provide a DetNet service
using an IP data plane. From a data plane perspective, an end-to-end using an IP data plane. From a data plane perspective, an end-to-end
IP model is followed. As mentioned above, existing IP and higher IP model is followed. As mentioned above, existing IP and higher
layer protocol header information is used to support flow layer protocol header information is used to support flow
identification and DetNet service delivery. Common data plane identification and DetNet service delivery. Common data plane
procedures and control information for all DetNet data planes can be procedures and control information for all DetNet data planes can be
found in the [I-D.ietf-detnet-data-plane-framework]. found in [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
higher layer protocol headers. The 6-tuple referred to in this and 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. Note the delivery of DiffServ and "tuple" based flow identification. Note
that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP
component. component.
For some of the protocols 5-tuples and 6-tuples cannot be used For some of the protocols 5-tuples and 6-tuples cannot be used
because the port information is not available (e.g., ICMP, IPSec because the port information is not available (e.g., ICMP, IPSec
ESP). Same can be valid for flow aggregates. In such cases using ESP). This is also the case for flow aggregates. In such cases,
smaller tuples are appropriate, e.g., a 3-tuple (2 IP addresses, IP using fewer fields is appropriate, e.g., a 3-tuple (2 IP addresses,
protocol) or even a 2-tuple (all IP traffic between two IP IP protocol) or even a 2-tuple (all IP traffic between two IP
addresses). addresses).
The DetNet IP data plane also allows for optional matching on the The DetNet IP data plane also allows for optional matching on the
IPv6 flow label field, as defined in [RFC8200]. IPv6 flow label field, as defined in [RFC8200].
Non-DetNet and DetNet IP packets are identical on the wire. Non-DetNet and DetNet IP packets have the same protocol header format
Generally the fields used in flow identification are forwarded on the wire. Generally the fields used in flow identification are
unmodified, however modification of these fields is allowed, for forwarded unmodified. However, standard modification of the DSCP
example changing the DSCP value, when required by the DetNet service. field [RFC2474] is not precluded.
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 support flow aggregation. In these cases, it is expected that
DetNet-aware intermediate nodes will provide DetNet service 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.
The specific procedures that are required to be implemented by a
DetNet node supporting this document can be found in Section 5. The
DetNet controller plane, as defined in [RFC8655], is responsible for
providing each node with the information needed to identify and
handle each DetNet flow.
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 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
|Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding|
+--------.-+ +-.------.-+ +-.---.----+ +-------.--+ +--------.-+ +-.------.-+ +-.---.----+ +-------.--+
skipping to change at page 5, line 48 skipping to change at page 6, line 26
+......+ +----[ 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 end systems originate IP encapsulated traffic that is identified
within the DetNet domain as DetNet flows. Relay nodes understand the within the DetNet domain as DetNet flows based on IP header
forwarding requirements of the DetNet flow and ensure that node, information. Relay nodes understand the forwarding requirements of
interface and sub-network resources are allocated to ensure DetNet the DetNet flow and ensure that node, interface and sub-network
service requirements. The dotted line around the Service component resources are allocated to ensure DetNet service requirements. The
of the Relay Nodes indicates that the transit routers are DetNet dotted line around the Service component of the Relay Nodes indicates
service aware but do not perform any DetNet service sub-layer that the transit routers are DetNet service aware but do not perform
function, e.g., PREOF (Packet Replication, Elimination and Ordering any DetNet service sub-layer function, e.g., PREOF (Packet
Function). Replication, Elimination and Ordering Function).
Note: The sub-network can represent a TSN, MPLS network or other Note: The sub-network can represent a TSN, MPLS network or other
network technology that can carry DetNet IP traffic. network technology that can carry DetNet IP traffic.
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 38 skipping to change at page 7, line 32
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 collapsed, 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 a DetNet IP network with IP End Systems.
As non-DetNet and DetNet IP packets are identical on the wire, from As non-DetNet and DetNet IP packets have the same protocol header
data plane perspective, the only difference is that there is flow- format on the wire, from a data plane perspective, the only
associated DetNet information on each DetNet node that defines the difference is that there is flow-associated DetNet information on
flow related characteristics and required forwarding behavior. As each DetNet node that defines the flow related characteristics and
shown above, edge nodes provide a Service Proxy function that required forwarding behavior. As shown above, edge nodes provide a
"associates" one or more IP flows with the appropriate DetNet flow- Service Proxy function that "associates" one or more IP flows with
specific information and ensures that the flow receives the proper the appropriate DetNet flow-specific information and ensures that the
traffic treatment within the domain. flow receives the proper traffic 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]. described 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 considerations related to providing DetNet
DetNet service to flows which are identified based on their header 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, protocols used by an IP end system are specific to an application,
and end systems peer with other end systems. DetNet's use of 6-tuple and end systems peer with other end systems. DetNet's use of 6-tuple
IP flow identification means that DetNet must be aware of not only IP flow identification means that DetNet must be aware of not only
the format of the IP header, but also of the next protocol carried the format of the IP header, but also of the next protocol value
within an IP packet (see Section 5.1.1.3). carried within an IP packet (see Section 5.1.1.3).
When IP end systems are DetNet-aware, no application-level or
service-level proxy functions are needed inside the DetNet domain.
For DetNet unaware IP end systems service-level proxy functions are For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain. needed inside the DetNet domain.
When IP end systems are DetNet-aware, no application-level or
service-level proxy functions are 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 to a DetNet flow. When forwarding when processing packets associated to a DetNet flow. When sending
packets, this means that packets are appropriately shaped on packets, this means that packets are appropriately shaped on
transmission and receive 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 the packets of that DetNet flow. process the packets of that DetNet flow.
An important additional consideration for DetNet-aware end systems is
avoiding IP fragmentation. Full 6-tuple flow identification is not
possible on IP fragments as fragments don't include the transport
headers or their port information. As such, it is important that
applications and/or end-systems use an IP packet size that will avoid
fragmentation within the network when sending DetNet flows. The
maximum size can be learned via path MTU discovery, [RFC1192] and
[RFC8201], or via the controller plane. Note that path MTU discovery
relies on ICMP, which may not follow the same path as an individual
DetNet flow.
In order to maximize reuse of existing mechanisms, DetNet-aware In order to maximize reuse of existing mechanisms, DetNet-aware
applications and end systems SHOULD NOT mix DetNet and non-DetNet applications and end systems SHOULD NOT mix DetNet and non-DetNet
traffic within a single 5-tuple. 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 the number of 6-tuple flow ID combinations that could be used limit the number of 6-tuple flow ID combinations that could be used
by the end systems. From a practical standpoint this means that all by the end systems. From a practical standpoint this means that all
nodes along the end-to-end path of DetNet flows need to agree on what nodes along the end-to-end path of DetNet flows need to agree on what
fields are used for flow identification. fields are used for flow identification. Possible consequences of
not having such an agreement include some flows interfering with
other flows, and the traffic treatment expected for a service not
being provided.
From a connection type perspective two scenarios are identified: From a connection type perspective two scenarios are identified:
1. DN attached: the end system is directly connected to an edge 1. DN attached: the end system is directly connected to an edge
node, or the end system is behind a sub-network (See ES1 and ES2 node, or the end system is behind a sub-network (See ES1 and ES2
in figure below) in figure below)
2. DN integrated: the end system is part of the DetNet domain. (See 2. DN integrated: the end system is part of the DetNet domain. (See
ES3 in figure below) 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|____ / \__/ +----+___
+----+ \ / \ +----+ \ / \
+ | + |
skipping to change at page 8, line 39 skipping to change at page 9, line 43
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-network specific mechanisms.
However, service protection (packet replication and packet However, service protection (packet replication and packet
elimination functions) is 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, service protection must be implemented within each As noted earlier, service protection must be implemented within each
link / sub-network independently, using the domain specific link/sub-network independently, using the domain specific mechanisms.
mechanisms. This is due to the lack of unified end-to-end sequencing This is due to the lack of unified end-to-end sequencing information
information that could be used by the intermediate nodes. Therefore, that could be used by the intermediate nodes. Therefore, service
service protection (if enabled) cannot be provided end-to-end, only protection (if enabled) cannot be provided end-to-end, only within
within sub-networks. This is shown for a three sub-network scenario sub-networks. This is shown for a three sub-network scenario in
in Figure 4, where each sub-network can provide service protection Figure 4, where each sub-network can provide service protection
between its borders. "R" and "E" denotes replication and elimination between its borders. "R" and "E" denote replication and elimination
points within the sub-network. points within the sub-network.
<-------------------- DenNet IP ------------------------> <-------------------- DenNet IP ------------------------>
______ ______
____ / \__ ____ / \__
____ / \__/ \___ ______ ____ / \__/ \___ ______
+----+ __/ +====+ +==+ \ +----+ +----+ __/ +====+ +==+ \ +----+
|src |__/ SubN1 ) | | \ SubN3 \____| dst| |src |__/ SubN1 ) | | \ SubN3 \____| dst|
+----+ \_______/ \ Sub-Network2 | \______/ +----+ +----+ \_______/ \ Sub-Network2 | \______/ +----+
\_ _/ \_ _/
\ __ __/ \ __ __/
\_______/ \___/ \_______/ \___/
+---+ +---------E--------+ +-----+ +---+ +---------E--------+ +-----+
+----+ | | | | | | | +----+ +----+ | | | | | | | +----+
|src |----R E--------R +---+ E------R E------+ dst| |src |----R E--------R +---+ E------R E------+ dst|
+----+ | | | | | | | +----+ +----+ | | | | | | | +----+
+---+ +-----R------------+ +-----+ +---+ +-----R------------+ +-----+
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
used (or re-used) at the edges of a DetNet network to prevent non- used (or re-used) at the edges of a DetNet network to prevent non-
congestion-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 IPv4 and IPv6 is Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is
provided using the standard differentiated services (DSCP) field provided using the standard differentiated services (DSCP) field
[RFC2474] and related mechanisms. [RFC2474] and related mechanisms.
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 the to provide DetNet QoS. This requirement is similar to the
requirement for MPLS LSRs that CoS LSPs cannot impact the resources requirement for MPLS LSRs that CoS LSPs cannot impact the resources
allocated to TE LSPs [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 node-internal traffic control mechanisms used
QoS for IP encapsulated DetNet flows are expected to be defined in a to deliver QoS for IP encapsulated DetNet flows are outside the scope
future document. From an encapsulation perspective, the combination of this 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 (the typical 5-tuple enhanced with the DSCP) and
previously mentioned optional field (i.e., flow label), uniquely optionally the flow label uniquely identifies a DetNet IP flow.
identifies a DetNet IP flow.
Packets that are identified as part of a DetNet IP flow but that have Packets that are identified as part of a DetNet IP flow but that have
not been the subject of a completed reservation, can disrupt the QoS not been the subject of a completed reservation can disrupt the QoS
offered to properly reserved DetNet flows by using resources offered to properly reserved DetNet flows by using resources
allocated to the reserved flows. Therefore, the network nodes of a allocated to the reserved flows. Therefore, the network nodes of a
DetNet network MUST ensure that no DetNet allocated resources, e.g., DetNet network MUST ensure that no DetNet allocated resources, e.g.,
queue or shaper, is used by such flows. There are multiple methods queue or shaper, is used by such flows. There are multiple methods
that MAY be used by an implementation to defend service delivery to that may be used by an implementation to defend service delivery to
reserved DetNet flows, including but not limited to: reserved DetNet flows, including but not limited to:
o Treating packets associated with an incomplete reservation as non- o Treating packets associated with an incomplete reservation as non-
DetNet traffic. DetNet traffic.
o Discarding packets associated with an incomplete reservation. o Discarding packets associated with an incomplete reservation.
o Remarking packets associated with an incomplete reservation. o Re-marking packets associated with an incomplete reservation. Re-
Remarking can be accomplished by changing the value of the DSCP marking can be accomplished by changing the value of the DSCP
field to a value that results in the packet no longer matching any field to a value that results in the packet no longer matching any
other reserved DetNet IP flow. 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 the additional flows using "6-tuple" header information as well as the optional
optional header field. DetNet generally allows for both flow- (flow label) 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 experiences 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 5-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.
4.4. DetNet Flow Aggregation 4.4. DetNet Flow Aggregation
As described in [I-D.ietf-detnet-data-plane-framework], the ability As described in [I-D.ietf-detnet-data-plane-framework], the ability
to aggregate individual flows, and their associated resource control, to aggregate individual flows, and their associated resource control,
into a larger aggregate is an important technique for improving into a larger aggregate is an important technique for improving
scaling by reducing the state per hop. DetNet IP data plane scaling by reducing the state per hop. DetNet IP data plane
aggregation can take place within a single node, when that node aggregation can take place within a single node, when that node
maintains state about both the aggregated and individual flows. It maintains state about both the aggregated and individual flows. It
skipping to change at page 11, line 51 skipping to change at page 13, line 5
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, and an additional optional field (i.e., flow label). the 6-tuple fields and optionally also by the flow label. The use of
The use of prefixes, wildcards, lists, and value ranges allows a prefixes, wildcards, lists, and value ranges allows a DetNet node to
DetNet node to identify aggregate DetNet flows. From a resource identify aggregate DetNet flows. From a resource allocation
allocation perspective, DetNet nodes ought to provide service to an perspective, DetNet nodes ought to provide service to an aggregate
aggregate rather than on a component flow basis. rather than 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
similar QoS and/or CoS characteristics, see Section 4.3.2. It also very similar) QoS and/or CoS characteristics, see Section 4.3.2. It
includes ensuring that per component-flow service requirements are also includes ensuring that per component-flow service requirements
satisfied by the aggregate, see Section 5.3. are satisfied by the aggregate, see Section 5.3.
The DetNet controller plane MUST ensure that non-congestion-
responsive DetNet traffic is not forwarded outside a DetNet domain.
4.5. Bidirectional Traffic 4.5. Bidirectional Traffic
While the DetNet IP data plane must support bidirectional DetNet While the DetNet IP data plane must support bidirectional DetNet
flows, there are no special bidirectional features with respect to flows, there are no special bidirectional features within the data
the data plane other than the need for the two directions of a co- plane. The special case of co-routed bidirectional DetNet flows are
routed bidirectional flow to take the same path. That is to say that solely represented at the management and control plane levels,
bidirectional DetNet flows are solely represented at the management without specific support or knowledge within the DetNet data plane.
and control plane levels, without specific support or knowledge Fate sharing and associated or co-routed bidirectional flows can be
within the DetNet data plane. Fate sharing and associated or co- managed at the control level.
routed bidirectional flows can be managed at the control level.
Control and management mechanisms need to support bidirectional Control and management mechanisms need to support bidirectional
flows, but the specification of such mechanisms are out of scope of flows, but the specification of such mechanisms are out of scope of
this document. An example control plane solution for MPLS can be this document. An example control plane solution for MPLS can be
found in [RFC7551]. found in [RFC7551].
5. DetNet IP Data Plane Procedures 5. DetNet IP Data Plane Procedures
This section provides DetNet IP data plane procedures. These This section provides DetNet IP data plane procedures. These
procedures have been divided into the following areas: flow procedures have been divided into the following areas: flow
identification, forwarding and traffic treatment. Flow identification, forwarding and traffic treatment. Flow
identification includes those procedures related to matching IP and identification includes those procedures related to matching IP and
higher layer protocol header information to DetNet flow (state) higher layer protocol header information to DetNet flow (state)
information and service requirements. Flow identification is also information and service requirements. Flow identification is also
sometimes called Traffic classification, for example see [RFC5777]. sometimes called Traffic classification; for example see [RFC5777].
Forwarding includes those procedures related to next hop selection Forwarding includes those procedures related to next hop selection
and delivery. Traffic treatment includes those procedures related to and delivery. Traffic treatment includes those procedures related to
providing an identified flow with the required DetNet service. providing an identified flow with the required DetNet service.
DetNet IP data plane establishment and operational procedures also DetNet IP data plane establishment and operational procedures also
have requirements on the control and management systems for DetNet have requirements on the control and management systems for DetNet
flows and these are referred to in this section. Specifically this flows and these are referred to in this section. Specifically this
section identifies a number of information elements that require section identifies a number of information elements that require
support via the management and control interfaces supported by a support via the management and control interfaces supported by a
DetNet node. The specific mechanism used for such support is out of DetNet node. The specific mechanism used for such support is out of
skipping to change at page 13, line 13 skipping to change at page 14, line 18
management and control related information is included. Conformance management and control related information is included. Conformance
language is not used in the summary since it applies to future language is not used in the summary since it applies to future
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
identification requirements, e.g., to support other higher layer requirements, e.g., to support other higher layer protocols, may be
protocols, may be defined in the future. 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.
skipping to change at page 13, line 37 skipping to change at page 14, line 42
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
identification based on the Source Address field of an IP packet. identification based on the Source Address field of an IP packet.
Implementations SHOULD support longest prefix matching for this Implementations SHOULD support longest prefix matching for this field
field, see [RFC1812] and [RFC7608]. Note that a prefix length of (see [RFC1812] and [RFC7608].) Note that a prefix length of zero (0)
zero (0) effectively means that the field is ignored. effectively means that the field is ignored.
5.1.1.2. Destination Address Field 5.1.1.2. Destination Address Field
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
identification based on the Destination Address field of an IP identification based on the Destination Address field of an IP
packet. Implementations SHOULD support longest prefix matching for packet. Implementations SHOULD support longest prefix matching for
this field, see [RFC1812] and [RFC7608]. Note that a prefix length this field (see [RFC1812] and [RFC7608].) Note that a prefix length
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 on the next This includes the next protocol values defined in Section 5.1.2 and
protocol values defined in Section 5.1.2. Other, non-zero values, any other value, including zero. Implementations SHOULD allow for
MUST be used for flow identification. Implementations SHOULD allow 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]
[RFC2475]. Implementations of this document MUST support DetNet flow [RFC2475]. Implementations of this document MUST support DetNet flow
identification based on the DSCP field in the IPv4 Type of Service identification based on the DSCP field in the IPv4 Type of Service
field when processing IPv4 packets, and the DSCP field in 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.
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 it to be
to be ignored for a specific DetNet flow. When this field is used to 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.
5.1.2. Other Protocol Header Information 5.1.2. Other Protocol Header Information
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
identification based on header information identified in this identification based on header information identified in this
section. Support for TCP, UDP, ICMP and IPsec flows is defined. section. Support for TCP, UDP, ICMP and IPsec flows is defined.
Future documents are expected to define support for other protocols. Future documents are expected to define support for other protocols.
skipping to change at page 15, line 31 skipping to change at page 16, line 38
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
identification based on the Destination Port field of a TCP or UDP identification based on the Destination Port field of a TCP or UDP
packet. Implementations MUST support flow identification based on a packet. Implementations MUST support flow identification based on a
particular value carried in the field, i.e., an exact value. particular value carried in the field, i.e., an exact value.
Implementations SHOULD support range-based port matching. Implementations SHOULD support range-based port matching.
Implementation MUST also allow for the field to be ignored for a Implementation MUST also allow for the field to be ignored for a
specific DetNet flow. specific DetNet flow.
5.1.2.2. ICMP 5.1.2.2. ICMP
DetNet flow identification for ICMP is achieved based on the DetNet flow identification for ICMP [RFC0792] is achieved based on
protocol's header. Note that ICMP type is not included in the flow the protocol number in the IP header. Note that ICMP type is not
definition. included in the flow definition.
5.1.2.3. IPsec AH and ESP 5.1.2.3. IPsec AH and ESP
IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security
Payload (ESP) [RFC4303] share a common format for the Security Payload (ESP) [RFC4303] share a common format for the Security
Parameters Index (SPI) field. Implementations MUST support flow Parameters Index (SPI) field. Implementations MUST support flow
identification based on a particular value carried in the field, identification based on a particular value carried in the field,
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.
skipping to change at page 16, line 6 skipping to change at page 17, line 16
or IPv6 Next Header Field contains the IANA defined value for AH or or IPv6 Next Header Field contains the IANA defined value for AH or
ESP. ESP.
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 [RFC8504], and are not modified by this document. The typical and [RFC8504], 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 associated with a DetNet flow. hops to be used for a packet associated with a DetNet flow. Specific
management and control information will be defined in future
documents, e.g., [I-D.ietf-detnet-yang].
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 of this document MUST ensure that a DetNet flow Implementations of 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 of 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] or IEEE802.1 technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1
TSN [I-D.ietf-detnet-ip-over-tsn]. Other mechanisms than the ones TSN [I-D.ietf-detnet-ip-over-tsn]. Other mechanisms than the ones
used in the TSN case are outside the scope of this document. used in the TSN case are outside 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:
skipping to change at page 16, line 47 skipping to change at page 18, line 11
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.
o IPv4 and IPv6 destination address field. o IPv4 and IPv6 destination address field.
o IPv4 and IPv6 destination address prefix length, where a zero (0) o IPv4 and IPv6 destination address prefix length, where a zero (0)
effectively means that the address field is ignored. effectively means that the address field is ignored.
o IPv4 protocol field. A limited set of values is allowed, and the o IPv4 protocol field. A limited set of values is allowed, and the
ability to ignore this field, e.g., via configuration of the value ability to ignore this field is desirable.
zero (0), is desirable.
o IPv6 next header field. A limited set of values is allowed, and o IPv6 next header field. A limited set of values is allowed, and
the ability to ignore this field, e.g., via configuration of the the ability to ignore this field 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:
* Whether or not the DSCP field is used in flow identification. * Whether or not the DSCP field is used in flow identification.
Use of the DSCP field for flow identification is optional. Use of the DSCP field for flow identification is optional.
* If the DSCP field is used to identify a flow, then the flow * If the DSCP field is used to identify a flow, then the flow
identification information (for that flow) includes a list of identification information (for that flow) includes a list of
DSCPs used by that flow. DSCPs used by that 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 used instead of matching against the matching. When used, this field can be used instead of matching
Next Header field. against the Next Header field.
o TCP and UDP Source Port. Exact and wildcard matching is required. o TCP and UDP Source Port. Support for both exact and wildcard
Port ranges can optionally be used. matching is required. Port ranges can optionally be used.
o TCP and UDP Destination Port. Exact and wildcard matching is o TCP and UDP Destination Port. Support for both exact and wildcard
required. Port ranges can optionally be used. matching is required. Port ranges can optionally be used.
o IPsec Header SPI field. Exact matching is required. Support for o IPsec Header SPI field. Exact matching is required. Support for
wildcard matching is recommended. wildcard matching is recommended.
o For end systems, an optional maximum IP packet size that should be
used for that outgoing DetNet IP flow.
This information MUST be provisioned per DetNet flow via This information MUST be provisioned per DetNet flow via
configuration, e.g., via the controller or management plane. configuration, e.g., via the controller or management plane.
Information identifying a DetNet flow is ordered and implementations An implementation MUST support ordering of the set of information
use the first match. This can, for example, be used to provide a information used to identify an individual DetNet flow. This can,
DetNet service for a specific UDP flow, with unique Source and for example, be used to provide a DetNet service for a specific UDP
Destination Port field values, while providing a different service flow, with unique Source and Destination Port field values, while
for the aggregate of all other flows with that same UDP Destination providing a different service for the aggregate of all other flows
Port value. with that same UDP Destination Port value.
It is the responsibility of the DetNet controller plane to properly It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific provision both flow identification information and the flow specific
resources needed to provided the traffic treatment needed to meet resources needed to provided the traffic treatment needed to meet
each flow's service requirements. This applies for aggregated and each flow's service requirements. This applies for aggregated and
individual flows. individual flows.
7. Security Considerations 7. Security Considerations
Security considerations for DetNet are described in detail in Detailed security considerations for DetNet are cataloged in
[I-D.ietf-detnet-security]. General security considerations are [I-D.ietf-detnet-security], and more general security considerations
described in [RFC8655]. This section considers exclusively security are described in [RFC8655]. This section considers exclusively
considerations which are specific to the DetNet IP data plane. security considerations which are specific to the DetNet IP data
plane.
Security aspects which are unique to DetNet are those whose aim is to Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency. and bounded end-to-end delivery latency. Achieving such loss rates
and bounded latency may not be possible in the face of a highly
capable adversary, such as the one envisioned by the Internet Threat
Model of BCP 72 that can arbitrarily drop or delay any or all
traffic. In order to present meaningful security considerations, we
consider a somewhat weaker attacker who does not control the physical
links of the DetNet domain, but may have the ability to control a
network node within the boundary of the DetNet domain.
The primary considerations for the data plane is to maintain The primary consideration for the DetNet data plane is to maintain
integrity of data and delivery of the associated DetNet service integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected traversing the DetNet network. Since no DetNet-specific fields are
through whatever means is provided by the underlying technology. For available in the DetNet IP data plane, the integrity and
confidentiality of application flows can be protected through
whatever means are provided by the underlying technology. For
example, encryption may be used, such as that provided by IPSec example, encryption may be used, such as that provided by IPSec
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec [RFC4301] for IP flows and/or by an underlying sub-net using MACSec
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
From a data plane perspective this document does not add or modify From a data plane perspective this document does not add or modify
any header information. any header information.
At the management and control level DetNet flows are identified on a At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with per-flow basis, which may provide controller plane attackers with
additional information about the data flows (when compared to additional information about the data flows (when compared to
controller planes that do not include per-flow identification). This controller planes that do not include per-flow identification). This
is an inherent property of DetNet which has security implications is an inherent property of DetNet which has security implications
that should be considered when determining if DetNet is a suitable that should be considered when determining if DetNet is a suitable
technology for any given use case. technology for any given use case.
To provide uninterrupted availability of the DetNet service, To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks. To provisions can be made against DOS attacks and delay attacks. To
protect against DOS attacks, excess traffic due to malicious or protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example malfunctioning devices can be prevented or mitigated, for example
through the use of existing mechanism such as policing and shaping through the use of existing mechanism such as policing and shaping
applied at the input of a DetNet domain. To prevent DetNet packets applied at the input of a DetNet domain or within an edge IEEE802.1
from being delayed by an entity external to a DetNet domain, DetNet TSN domain. To prevent DetNet packets from being delayed by an
technology definition can allow for the mitigation of Man-In-The- entity external to a DetNet domain, DetNet technology definition can
Middle attacks, for example through use of authentication and allow for the mitigation of Man-In-The-Middle attacks, for example
authorization of devices within the DetNet domain. through use of authentication and authorization of devices within the
DetNet domain.
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. David Black Bernardos for their various contributions to this work. David Black
served as technical advisor to the DetNet working group during the served as technical advisor to the DetNet working group during the
development of this document and provided many valuable comments. development of this document and provided many valuable comments.
IESG comments were provided by Murray Kucherawy, Roman Danyliw,
Alvaro Retana, Benjamin Kaduk, Rob Wilton, and Erik Vyncke.
10. Contributors 10. Contributors
RFC7322 limits the number of authors listed on the front page of a RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5. The editor wishes to thank and acknowledge draft to a maximum of 5. The editor wishes to thank and acknowledge
the follow authors for contributing text to this draft. the follow authors for contributing text to this draft.
Jouni Korhonen Jouni Korhonen
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
Andrew G. Malis Andrew G. Malis
Malis Consulting Malis Consulting
Email: agmalis@gmail.com Email: agmalis@gmail.com
11. References 11. References
11.1. Normative references 11.1. Normative references
[I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-06 (work in progress), May 2020.
[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,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<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>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
skipping to change at page 20, line 37 skipping to change at page 22, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative references [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[I-D.ietf-detnet-data-plane-framework] 11.2. Informative references
Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-04 (work in progress), February 2020.
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-dp-sol-mpls]
Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-
flow-information-model-07 (work in progress), March 2020. flow-information-model-10 (work in progress), May 2020.
[I-D.ietf-detnet-ip-over-mpls] [I-D.ietf-detnet-ip-over-mpls]
Varga, B., Berger, L., Fedyk, D., Malis, A., Bryant, S., Varga, B., Berger, L., Fedyk, D., Bryant, S., and J.
and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft- Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf-
ietf-detnet-ip-over-mpls-05 (work in progress), February detnet-ip-over-mpls-06 (work in progress), May 2020.
2020.
[I-D.ietf-detnet-ip-over-tsn] [I-D.ietf-detnet-ip-over-tsn]
Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
Data Plane: IP over IEEE 802.1 Time Sensitive Networking Data Plane: IP over IEEE 802.1 Time Sensitive Networking
(TSN)", draft-ietf-detnet-ip-over-tsn-02 (work in (TSN)", draft-ietf-detnet-ip-over-tsn-03 (work in
progress), March 2020. progress), June 2020.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
draft-ietf-detnet-mpls-05 (work in progress), February detnet-mpls-07 (work in progress), June 2020.
2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T. and E. Grossman, "Deterministic Networking Mizrahi, T. and E. Grossman, "Deterministic Networking
(DetNet) Security Considerations", draft-ietf-detnet- (DetNet) Security Considerations", draft-ietf-detnet-
security-09 (work in progress), March 2020. security-10 (work in progress), May 2020.
[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 D. Varga, B., Farkas, J., Malis, A., Bryant, S., and D.
Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive Fedyk, "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-
mpls-02 (work in progress), March 2020. mpls-03 (work in progress), June 2020.
[I-D.ietf-detnet-yang] [I-D.ietf-detnet-yang]
Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D. Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D.
Fedyk, "Deterministic Networking (DetNet) Configuration Fedyk, "Deterministic Networking (DetNet) Configuration
YANG Model", draft-ietf-detnet-yang-05 (work in progress), YANG Model", draft-ietf-detnet-yang-06 (work in progress),
March 2020. June 2020.
[IEEE802.1AE-2018] [IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018, Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>. <https://ieeexplore.ieee.org/document/8585421>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1192] Kahin, B., "Commercialization of the Internet summary
report", RFC 1192, DOI 10.17487/RFC1192, November 1990,
<https://www.rfc-editor.org/info/rfc1192>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
DOI 10.17487/RFC3290, May 2002, DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>. <https://www.rfc-editor.org/info/rfc3290>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and
W. Weiss, "Information Model for Describing Network Device W. Weiss, "Information Model for Describing Network Device
QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670,
January 2004, <https://www.rfc-editor.org/info/rfc3670>. January 2004, <https://www.rfc-editor.org/info/rfc3670>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008, DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>. <https://www.rfc-editor.org/info/rfc5120>.
skipping to change at page 22, line 42 skipping to change at page 24, line 27
[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>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/info/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
Authors' Addresses Authors' Addresses
Balazs Varga (editor) Balazs Varga (editor)
Ericsson Ericsson
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 Budapest 1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Janos Farkas Janos Farkas
Ericsson Ericsson
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 Budapest 1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
 End of changes. 91 change blocks. 
204 lines changed or deleted 254 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/