draft-ietf-detnet-ip-05.txt   draft-ietf-detnet-ip-06.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: August 6, 2020 L. Berger Expires: October 25, 2020 L. Berger
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis
Independent
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
February 3, 2020 April 23, 2020
DetNet Data Plane: IP DetNet Data Plane: IP
draft-ietf-detnet-ip-05 draft-ietf-detnet-ip-06
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 38 skipping to change at page 1, line 36
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 August 6, 2020. This Internet-Draft will expire on October 25, 2020.
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 17 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . 7
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 . . . . . . . . . . . 10
4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . 13
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 . . . . . . . . . 16
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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative references . . . . . . . . . . . . . . . . . . 18 11.1. Normative references . . . . . . . . . . . . . . . . . . 19
11.2. Informative references . . . . . . . . . . . . . . . . . 20 11.2. Informative references . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 with
packet loss rates and assured maximum end-to-end delivery latency. extremely low packet loss rates and assured maximum end-to-end
General background and concepts of DetNet can be found in the DetNet delivery latency. General background and concepts of DetNet can be
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 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 as two sub-layers: functions into two sub-layers: a service functions as two sub-layers: a service sub-layer and a forwarding
sub-layer and a forwarding sub-layer. The service sub-layer is used sub-layer. The service sub-layer is used to provide DetNet service
to provide DetNet service protection (e.g., by packet replication and protection (e.g., by packet replication and packet elimination
packet elimination functions) and reordering. The forwarding sub- functions) and reordering. The forwarding sub-layer is used to
layer is used to provide congestion protection (low loss, assured provide congestion protection (low loss, assured latency, and limited
latency, and limited out-of-order delivery). The service sub-layer out-of-order delivery). The service sub-layer generally requires
generally requires additional fields to provide its service; for additional header fields to provide its service; for example see
example see [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields are added to
are added to support DetNet IP flows, only the forwarding sub-layer support DetNet IP flows, only the forwarding sub-layer functions are
functions are supported using the DetNet IP defined by this document. supported using the DetNet IP defined by this document. Service
Service protection can be provided on a per sub-net basis using protection can be provided on a per sub-net basis using technologies
technologies such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified
as specified in the IEEE 802.1 TSN task group(referred to in this in the IEEE 802.1 TSN (Time-Sensitive Networking) task group
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, 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 4, line 4 skipping to change at page 3, line 50
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
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, Elimination and Ordering Function PREOF Packet Replication, Elimination and Ordering Function
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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
because the port information is not available (e.g., ICMP, IPSec
ESP). Same can be valid for flow aggregates. In such cases using
smaller tuples are appropriate, e.g., a 3-tuple (2 IP addresses, IP
protocol) or even a 2-tuple (all IP traffic between two IP
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 are identical on the wire.
Generally the fields used in flow identification are forwarded Generally the fields used in flow identification are forwarded
unmodified, however modification of these fields is allowed, for unmodified, however modification of these fields is allowed, for
example to a DSCP value, when required by the DetNet service. example changing the 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 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.
DetNet IP Relay Relay DetNet IP DetNet IP Relay Relay DetNet IP
End System Node Node End System End System Node Node End System
skipping to change at page 5, line 40 skipping to change at page 5, line 47
: 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 those are 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. Relay nodes understand the
forwarding requirements of the DetNet flow and ensure that node, forwarding requirements of the DetNet flow and ensure that node,
interface and sub-network resources are allocated to ensure DetNet interface and sub-network resources are allocated to ensure DetNet
service requirements. The dotted line around the Service component service requirements. The dotted line around the Service component
of the Relay Nodes indicates that the transit routers are DetNet of the Relay Nodes indicates that the transit routers are DetNet
service aware but do not perform any DetNet service sub-layer service aware but do not perform any DetNet service sub-layer
function, e.g., PREOF. function, e.g., PREOF (Packet 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 41 skipping to change at page 6, line 47
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 DetNet IP network with IP End System.
As 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 flow receives the proper
treatment within the domain. 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]. 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.
skipping to change at page 9, line 42 skipping to change at page 10, line 9
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 IPv6 is provided Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is
using the standard differentiated services code point (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 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 optional field, uniquely identifies a DetNet IP previously mentioned optional field (i.e., flow label), uniquely
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 Remarking packets associated with an incomplete reservation.
Remarking can be accomplished by changing the value of the DSCP, Remarking can be accomplished by changing the value of the DSCP
or optional, field to a value that results in the packet no longer field to a value that results in the packet no longer matching any
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 additional
optional header field. 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.
skipping to change at page 11, line 38 skipping to change at page 11, line 51
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 defined in Section 5.1. the 6-tuple, and an additional optional field (i.e., flow label).
The use of prefixes, wildcards, lists, and value ranges allows a The use of prefixes, wildcards, lists, and value ranges allows a
DetNet node to identify aggregate DetNet flows. From a resource DetNet node to identify aggregate DetNet flows. From a resource
allocation perspective, DetNet nodes must provide service to an allocation perspective, DetNet nodes ought to provide service to an
aggregate and not on a component flow basis. aggregate 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 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 12, line 36 skipping to change at page 12, line 46
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 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
the scope of this document. A summary of the requirements for the scope of this document. A summary of the requirements for
management and control related information is included. Conformance management and control related information is included. Conformance
language is not used in the summary since 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 requirements, e.g., to support other higher layer identification requirements, e.g., to support other higher layer
skipping to change at page 14, line 31 skipping to change at page 14, line 41
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.
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 and IPsec flows is defined. Future section. Support for TCP, UDP, ICMP and IPsec flows is defined.
documents are expected to define support for other protocols. Future documents are expected to define support for other protocols.
5.1.2.1. TCP and UDP 5.1.2.1. TCP and UDP
DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is
achieved based on the Source and Destination Port fields carried in achieved based on the Source and Destination Port fields carried in
each protocol's header. These fields share a common format and each protocol's header. These fields share a common format and
common DetNet flow identification procedures. common DetNet flow identification procedures.
The rules defined in this section only apply when the IPv4 Protocol
or IPv6 Next Header Field contains the IANA defined value for UDP or
TCP.
5.1.2.1.1. Source Port Field 5.1.2.1.1. Source Port Field
Implementations of this document MUST support DetNet flow Implementations of this document MUST support DetNet flow
identification based on the Source Port field of a TCP or UDP packet. identification based on the Source Port field of a TCP or UDP packet.
Implementations MUST support flow identification based on a 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.1.2. Destination Port Field 5.1.2.1.2. Destination Port Field
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. IPsec AH and ESP 5.1.2.2. ICMP
DetNet flow identification for ICMP is achieved based on the
protocol's header. Note that ICMP type is not included in the flow
definition.
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.
The rules defined in this section only apply when the IPv4 Protocol
or IPv6 Next Header Field contains the IANA defined value for AH or
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.
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
skipping to change at page 16, line 4 skipping to change at page 16, line 28
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 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] 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 than in the TSN case, the TSN [I-D.ietf-detnet-ip-over-tsn]. Other mechanisms than the ones
specific mechanisms used by a DetNet node to ensure DetNet service used in the TSN case are outside the scope of this document.
delivery requirements are met for supported DetNet flows is 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:
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 34 skipping to change at page 17, line 11
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, e.g., via configuration of the value
zero (0), 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, e.g., via configuration of the
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. * Whether or not the DSCP field is used in flow identification.
Ignoring the DSCP filed is optional. Use of the DSCP field for flow identification is optional.
* When the DSCP field is used in flow identification, a list of * If the DSCP field is used to identify a flow, then the flow
field values that may be used by a specific flow. identification information (for that flow) includes a list of
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, 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. Support for
wildcard matching is recommended.
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 Information identifying a DetNet flow is ordered and implementations
use the first match. This can, for example, be used to provide a use the first match. This can, for example, be used to provide a
DetNet service for a specific UDP flow, with unique Source and DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service Destination Port field values, while providing a different service
for the aggregate of all other flows with that same UDP Destination for the aggregate of all other flows with that same UDP Destination
Port value. Port value.
skipping to change at page 18, line 31 skipping to change at page 19, line 7
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.
10. Contributors 10. Contributors
This document is derived from an earlier draft that was edited by RFC7322 limits the number of authors listed on the front page of a
Jouni Korhonen (jouni.nospam@gmail.com) and as such, he contributed draft to a maximum of 5. The editor wishes to thank and acknowledge
to and authored text in this document. the follow authors for contributing text to this draft.
Jouni Korhonen
Email: jouni.nospam@gmail.com
Andrew G. Malis
Malis Consulting
Email: agmalis@gmail.com
11. References 11. References
11.1. Normative references 11.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 20, line 8 skipping to change at page 20, line 40
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 11.2. Informative references
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, S., and J. Korhonen, "DetNet Data Plane Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
Framework", draft-ietf-detnet-data-plane-framework-03 data-plane-framework-04 (work in progress), February 2020.
(work in progress), October 2019.
[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. Farkas, J., Varga, B., 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-06 (work in progress), October flow-information-model-07 (work in progress), March 2020.
2019.
[I-D.ietf-detnet-ip-over-mpls] [I-D.ietf-detnet-ip-over-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Berger, L., Fedyk, D., Malis, A., Bryant, S.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft-
MPLS", draft-ietf-detnet-ip-over-mpls-04 (work in ietf-detnet-ip-over-mpls-05 (work in progress), February
progress), November 2019. 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-01 (work in (TSN)", draft-ietf-detnet-ip-over-tsn-02 (work in
progress), October 2019. progress), March 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., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-04 (work in progress), November draft-ietf-detnet-mpls-05 (work in progress), February
2019. 2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, Mizrahi, T. and E. Grossman, "Deterministic Networking
J., Austad, H., and N. Finn, "Deterministic Networking
(DetNet) Security Considerations", draft-ietf-detnet- (DetNet) Security Considerations", draft-ietf-detnet-
security-07 (work in progress), January 2020. security-09 (work in progress), March 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-01 (work in progress), October 2019. mpls-02 (work in progress), March 2020.
[I-D.ietf-detnet-yang] [I-D.ietf-detnet-yang]
Geng, X., Chen, M., Ryoo, Y., Li, Z., and R. Rahman, Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D.
"Deterministic Networking (DetNet) Configuration YANG Fedyk, "Deterministic Networking (DetNet) Configuration
Model", draft-ietf-detnet-yang-04 (work in progress), YANG Model", draft-ietf-detnet-yang-05 (work in progress),
November 2019. March 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>.
skipping to change at page 23, line 4 skipping to change at page 23, line 32
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Don Fedyk Don Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: dfedyk@labn.net Email: dfedyk@labn.net
Andrew G. Malis
Independent
Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Futurewei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
 End of changes. 47 change blocks. 
94 lines changed or deleted 114 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/