rfc8939xml2.original.xml   rfc8939.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
docName="draft-ietf-detnet-ip-07"
ipr="trust200902"
submissionType="IETF">
<front>
<title abbrev="DetNet IP">
DetNet Data Plane: IP</title>
<author role="editor" fullname="Bal&aacute;zs Varga" initials="B." surname=" <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
Varga">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
category="std" consensus="true" docName="draft-ietf-detnet-ip-07"
number="8939" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.46.0 -->
<front>
<title abbrev="DetNet Data Plane: IP">Deterministic Networking (DetNet) Data
Plane: IP</title>
<seriesInfo name="RFC" value="8939"/>
<author role="editor" fullname="Balázs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>balazs.a.varga@ericsson.com</email> <email>balazs.a.varga@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="János Farkas" initials="J." surname="Farkas">
<author fullname="J&aacute;nos Farkas" initials="J." surname="Farkas">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
</address> </address>
skipping to change at line 45 skipping to change at line 39
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Lou Berger" initials="L." surname="Berger"> <author fullname="Lou Berger" initials="L." surname="Berger">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>lberger@labn.net</email> <email>lberger@labn.net</email>
</address> </address>
</author> </author>
<author fullname="Don Fedyk" initials="D." surname="Fedyk"> <author fullname="Don Fedyk" initials="D." surname="Fedyk">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>dfedyk@labn.net</email> <email>dfedyk@labn.net</email>
</address> </address>
</author> </author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant"> <author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Futurewei Technologies</organization> <organization>Futurewei Technologies</organization>
<address> <address>
<email>stewart.bryant@gmail.com</email> <email>sb@stewartbryant.com</email>
</address> </address>
</author> </author>
<!--author fullname="Donald Fauntleroy Duck" initials="D. F." surname="Duck" <date year="2020" month="November" />
>
<organization abbrev="Royal Bros.">Royal Bros.</organization>
<address>
<postal>
<street>13 Paradise Road</street>
<city>Duckburg</city>
<region>Calisota</region>
<country>USA</country>
</postal>
</address>
</author-->
<date />
<workgroup>DetNet</workgroup> <workgroup>DetNet</workgroup>
<keyword>Application</keyword>
<keyword>Endpoint</keyword>
<keyword>Service Sub-layer</keyword>
<keyword>Forwarding Sub-layer</keyword>
<abstract> <abstract>
<t> <t>
This document specifies the DetNet data plane operation for IP hosts This document specifies the Deterministic Networking (DetNet)
and routers that provide DetNet service to IP encapsulated data. No data plane operation for IP hosts and routers that provide DetNet
DetNet-specific encapsulation is defined to support IP flows; instead service to IP-encapsulated data. No DetNet-specific encapsulation is
the existing IP and higher layer protocol header information is used to defined to support IP flows; instead, the existing IP-layer and
support flow identification and DetNet service delivery. This higher-layer protocol header information is used to support flow
document builds on the DetNet Architecture and Data Plane Framework. identification and DetNet service delivery. This document builds on
the DetNet architecture (RFC 8655) and data plane framework
(RFC 8938).
</t> </t>
</abstract> </abstract>
</front> </front>
<!--
***********************************************
IESG review comment resolutions in this version:
DONE
- Roni Even, (Gen-ART), (03-09), Ready with Nits
- Sabrina Tanamal, IANA, (03-12), OK
- David Black (03-12), Include ICMP
- Tero Kivinen 03-12, Nits
- Bob Briscoe, (03-15), Comments and Many nits
To be discussed:
- Security section
- Deborah, (04-09), decrease authors to 5 !!!
***********************************************
<middle> <middle>
<section title="Introduction" anchor="sec_intro"> <section anchor="sec_intro" numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
Deterministic Networking (DetNet) is a service that can be offered by a Deterministic Networking (DetNet) is a service that can be offered by
network to DetNet flows. a network to DetNet flows.
DetNet provides these flows with extremely low packet loss rates and ass DetNet provides these flows with extremely low packet loss rates and
ured maximum end-to-end assured maximum end-to-end
delivery latency. General background and concepts of DetNet can delivery latency. General background and concepts of DetNet can
be found in the DetNet Architecture <xref target="RFC8655"/>. be found in the DetNet architecture <xref target="RFC8655" format="defau lt"/>.
</t> </t>
<t> <t>
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 to the existing IP-layer and higher-layer protocol header information is us
ed to
support flow identification and DetNet service delivery. Common data pla ne support flow identification and DetNet service delivery. Common data pla ne
procedures and control information for all DetNet data planes procedures and control information for all DetNet data planes
can be found in <xref target="I-D.ietf-detnet-data-plane-framework"/>. can be found in <xref target="RFC8938" format="default"/>.
</t> </t>
<t> <t>
The DetNet Architecture models the DetNet related data plane functions The DetNet architecture models the DetNet-related data plane functions
as two sub-layers: a as two sub-layers: a service sub-layer and a forwarding sub-layer.
service sub-layer and a forwarding sub-layer. The service sub-layer is The service sub-layer is used to provide DetNet service protection
used to provide DetNet service protection (e.g., by packet replication (e.g., by the Packet Replication Function (PRF) and Packet Elimination
and packet elimination functions) and reordering. The Function (PEF)) and reordering. The forwarding sub-layer is used to
forwarding sub-layer is used to provide congestion protection (low provide congestion protection (low loss, assured latency, and limited
loss, assured latency, and limited out-of-order delivery). out-of-order delivery). The service sub-layer generally requires
The service sub-layer generally requires additional header fields additional header fields to provide its service; for example, see
to provide <xref target="DetNet-MPLS" format="default"/>. Since no
its service; for example see <xref target="I-D.ietf-detnet-mpls"/ DetNet-specific fields are added to support DetNet IP flows, only the
>. forwarding sub-layer functions are supported using the DetNet IP
Since no DetNet-specific fields are added to support DetNet defined by this document. Service protection can be provided on a
IP flows, only per-sub-network basis using technologies such as MPLS <xref
the forwarding sub-layer functions are supported using the DetNet target="DetNet-MPLS"/> and Ethernet,
IP as specified by the IEEE 802.1 TSN (Time-Sensitive Networking) task
defined by this document. group (referred to in this document simply as "IEEE 802.1 TSN").
Service protection can be provided on a per See <xref target="IEEE802.1TSNTG"/>.
sub-net basis using technologies such as MPLS <xref
target="I-D.ietf-detnet-dp-sol-mpls"/> and Ethernet as
specified in the IEEE 802.1 TSN (Time-Sensitive Networking) task group (
referred to in this document
simply as IEEE802.1 TSN).
</t> </t>
<t> <t>
This document provides an overview of the DetNet IP data plane in <xref This document provides an overview of the DetNet IP data plane in
target="sec_dt_dp"/>, and considerations that apply to providing <xref target="sec_dt_dp" format="default"/> and considerations that
DetNet services via the DetNet IP data plane in <xref apply to providing
target="dn-gen-encap-solution"/>. <xref target="ip-procs"/> DetNet services via the DetNet IP data plane in <xref target="dn-gen-enc
ap-solution" format="default"/>. <xref target="ip-procs" format="default"/>
provides the procedures for hosts and routers that support IP-based provides the procedures for hosts and routers that support IP-based
DetNet services. <xref target="ip-flow-id-info"/> summarizes the set of DetNet services. <xref target="ip-flow-id-info" format="default"/> summa rizes the set of
information that is needed to identify an individual DetNet flow . information that is needed to identify an individual DetNet flow .
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<section title="Terms Used In This Document"> <section numbered="true" toc="default">
<name>Terms Used in This Document</name>
<t> <t>
This document uses the terminology and concepts established in This document uses the terminology and concepts established in
the DetNet architecture <xref the DetNet architecture <xref target="RFC8655" format="default"/>,
target="RFC8655"/>, and the reader is assumed and it is assumed that the reader is
to be familiar with that document and its terminology. familiar with that document and its terminology.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Abbreviations"> <name>Abbreviations</name>
<t> <t>
The following abbreviations used in this document: The following abbreviations are used in this document:
<!-- [JiK] Update later -->
<list style="hanging" hangIndent="14"> </t>
<t hangText="CoS">Class of Service</t> <dl newline="false" spacing="normal" indent="14">
<t hangText="DetNet">Deterministic Networking</t> <dt>CoS</dt>
<t hangText="DN">DetNet</t> <dd>Class of Service</dd>
<t hangText="DiffServ">Differentiated Services</t> <dt>DetNet</dt>
<t hangText="DSCP">Differentiated Services Code Point</t> <dd>Deterministic Networking</dd>
<t hangText="L2">Layer-2</t> <dt>DN</dt>
<t hangText="L3">Layer-3</t> <dd>DetNet</dd>
<t hangText="LSP">Label-switched path</t> <dt>Diffserv</dt>
<t hangText="MPLS">Multiprotocol Label Switching</t> <dd>Differentiated Services</dd>
<t hangText="PREOF">Packet Replication, Elimination and Ordering Fun <dt>DSCP</dt>
ction</t> <dd>Differentiated Services Code Point</dd>
<t hangText="QoS">Quality of Service</t> <dt>L2</dt>
<t hangText="TSN">Time-Sensitive Networking, TSN is a Task Group of <dd>Layer 2</dd>
the IEEE <dt>L3</dt>
802.1 Working Group.</t> <dd>Layer 3</dd>
</list> <dt>LSP</dt>
<dd>Label Switched Path</dd>
<dt>MPLS</dt>
<dd>Multiprotocol Label Switching</dd>
<dt>PEF</dt>
<dd>Packet Elimination Function</dd>
<dt>PREOF</dt>
<dd>Packet Replication, Elimination, and Ordering Functions</dd>
<dt>PRF</dt>
<dd>Packet Replication Function</dd>
<dt>QoS</dt>
<dd>Quality of Service</dd>
<dt>TSN</dt>
<dd>Time-Sensitive Networking. TSN is a task group of the IEEE
802.1 Working Group.</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
</section> </section>
</section> <section anchor="sec_dt_dp" numbered="true" toc="default">
<name>Overview of the DetNet IP Data Plane</name>
<section title="DetNet IP Data Plane Overview" anchor="sec_dt_dp">
<!-- LB: this section should provide the overview related to:
<section title="Simplified IP-Related DetNet Data Plane Solution" anchor="si
mple-ip-solution">
<t>
This section is the placeholder for the conclusion discussed during IETF 101 an
d 102.
</t>
<t>
[Editor's note: describe the 6 tuple way of identifying DetNet service f
lows. Also stress
that PREOF is per network segment as described in <xref target="nwsegmen
ts"/>
<list style="symbols">
<t>DetNet flows are recognized based on 6 tuple.</t>
<t>No end-to-end DN Sequence Number present in the packet.</t>
<t>Links/sub-networks may use their technology specific methods to ach
ieve DN service.</t>
<t>TE information does not travel with the packet (e.g., nailed down p
ath ensured via Policy-Based-Routing).</t>
<t>etc.</t>
</list>
]
</t>
<t> <t>
<xref target="simplifiedip"/> illustrated the case for DetNet simplified
IP data plane solution.
</t>
</section>
-->
<t>
This document describes how IP is used by DetNet nodes, i.e., hosts and This document describes how IP is used by DetNet nodes, i.e., hosts and
routers, to identify DetNet flows and provide a DetNet service using an IP routers, to identify DetNet flows and provide a DetNet service using an IP
data plane. From a data plane perspective, an end-to-end IP model is data plane. From a data plane perspective, an end-to-end IP model is
followed. As mentioned above, existing IP and higher layer protocol followed. As mentioned above, existing IP-layer and higher-layer
header information is used to support flow identification and DetNet protocol header information is used to support flow identification and
DetNet
service delivery. Common data plane procedures and control information service delivery. Common data plane procedures and control information
for all DetNet data planes can be found in <xref for all DetNet data planes can be found in <xref target="RFC8938" format
target="I-D.ietf-detnet-data-plane-framework"/>. ="default"/>.
</t> </t>
<t> <t>
The DetNet IP data plane primarily uses 6-tuple based flow identificatio The DetNet IP data plane primarily uses 6-tuple-based flow identificatio
n, where n, where
"6-tuple" refers to information carried in IP and higher layer protocol "6-tuple" refers to information carried in IP-layer and higher-layer pro
tocol
headers. The 6-tuple referred to in this document is the same as headers. The 6-tuple referred to in this document is the same as
that defined in <xref target="RFC3290"/>. Specifically 6-tuple is that defined in <xref target="RFC3290"
format="default"/>. Specifically, the 6-tuple is
destination address, source address, IP protocol, source port, destination address, source address, IP protocol, source port,
destination port, and differentiated services (DiffServ) code point destination port, and
(DSCP). General background on the use of IP headers, and 5-tuples, DSCP. General background on the use of IP headers and 5-tuples
to identify flows and support Quality of Service (QoS) can be found in to identify flows and support Quality of Service (QoS) can be found in
<xref target="RFC3670"/>. <xref target="RFC7657"/> also provides <xref target="RFC3670" format="default"/>. <xref target="RFC7657" forma
useful background on the delivery of DiffServ and "tuple" based flow t="default"/> also provides
useful background on the delivery of Diffserv and tuple-based flow
identification. Note that a 6-tuple is composed of a 5-tuple identification. Note that a 6-tuple is composed of a 5-tuple
plus the addition of a DSCP component. plus the addition of a DSCP component.
</t> </t>
<t> <t>
For some of the protocols 5-tuples and 6-tuples cannot be used becaus For some of the protocols, 5-tuples and 6-tuples cannot be used, bec
e ause
the port information is not available (e.g., ICMP, IPSec ESP). Th the port information is not available (e.g., ICMP, IPsec, and
is is Encapsulating Security Payload (ESP)). This is
also the case for flow aggregates. In such cases, using also the case for flow aggregates. In such cases, using
fewer fields is appropriate, e.g., a 3-tuple (2 IP addresses, IP fewer fields is appropriate, such as a 3-tuple (2 IP
protocol) or even a addresses, IP protocol) or even a
2-tuple (all IP traffic between two IP addresses). 2-tuple (all IP traffic between two IP addresses).
</t> </t>
<t> <t>
The DetNet IP data plane also allows for optional matching on The DetNet IP data plane also allows for optional matching on
the IPv6 flow label field, the IPv6 Flow Label field,
as defined in <xref target="RFC8200"/>. as defined in <xref target="RFC8200" format="default"/>.
</t> </t>
<t> <t>
Non-DetNet and DetNet IP packets have the same protocol Non-DetNet and DetNet IP packets have the same protocol
header format on the wire. header format on the wire.
Generally the fields used in flow identification are forwarded Generally, the fields used in flow identification are forwarded
unmodified. However, standard modification of the unmodified. However, standard modification of the
DSCP field <xref target="RFC2474"/> is not precluded. DSCP field <xref target="RFC2474" format="default"/> is not preclude
d.
</t> </t>
<t> <t>
DetNet flow aggregation may be enabled via the use of DetNet flow aggregation may be enabled via the use of
wildcards, masks, lists, prefixes and ranges. IP tunnels may also be wildcards, masks, lists, prefixes, and ranges. IP tunnels may also be
used to support flow aggregation. In these cases, it is used to support flow aggregation. In these cases, it is
expected that DetNet-aware intermediate nodes will provide expected that DetNet-aware intermediate nodes will provide
DetNet service on the aggregate through resource DetNet service on the aggregate through resource
allocation and congestion control mechanisms. allocation and congestion control mechanisms.
</t> </t>
<t> <t>
The specific procedures that are required to be implemented by a The specific procedures that are required to be implemented by a
DetNet node supporting this document can be found in <xref DetNet node supporting this document can be found in <xref target="ip-pr
target="ip-procs"/>. The DetNet controller plane, as defined in ocs" format="default"/>. The DetNet Controller Plane, as defined in
<xref target="RFC8655"/>, is responsible for providing each node <xref target="RFC8655" format="default"/>, is responsible for providing
each node
with the information needed to identify and handle each DetNet flow. with the information needed to identify and handle each DetNet flow.
</t> </t>
<figure align="center" anchor="fig_ip_detnet_simple" <figure anchor="fig_ip_detnet_simple">
title="A Simple DetNet (DN) Enabled IP Network"> <name>A Simple DetNet-Enabled IP Network</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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|
+--------.-+ +-.------.-+ +-.---.----+ +-------.--+ +--------.-+ +-.------.-+ +-.---.----+ +-------.--+
: Link : \ ,-----. / \ ,-----. / : Link : \ ,-----. / \ ,-----. /
+......+ +----[ Sub ]----+ +-[ Sub ]-+ +......+ +----[ Sub- ]----+ +-[ Sub- ]-+
[Network] [Network] [Network] [Network]
`-----' `-----' `-----' `-----'
|<--------------------- DetNet IP --------------------->| |<--------------------- DetNet IP --------------------->|
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<xref target="fig_ip_detnet_simple"/> illustrates a DetNet enabled IP <xref target="fig_ip_detnet_simple" format="default"/> illustrates a
network. The DetNet enabled end systems originate IP encapsulated DetNet-enabled IP
network. The DetNet-enabled end systems originate IP-encapsulated
traffic that is identified within the DetNet domain as DetNet traffic that is identified within the DetNet domain as DetNet
flows based on IP header information. flows based on IP header information.
Relay nodes understand the 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 of service requirements. The dotted line around the Service component of
the Relay Nodes indicates that the transit routers are DetNet service the Relay Nodes indicates that the transit routers are
aware but do not perform any DetNet service sub-layer function, e.g., PR DetNet service aware but do not perform any DetNet service sub-layer
EOF function, e.g., PREOF.
(Packet Replication, Elimination and Ordering Function).
</t> </t>
<aside>
<t> <t>
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.
</t> </t>
</aside>
<figure align="center" anchor="fig_non_detnet_ip" <figure anchor="fig_non_detnet_ip">
title="Non-DetNet-aware IP end systems with DetNet IP Domain"> <name>Non-DetNet-Aware IP End Systems with DetNet IP Domain</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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. |
+----------+ +.........+ +.........+ +----------+ +----------+ +.........+ +.........+ +----------+
| IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP |
+----------+ +---+ +---+ +---+ +---+ +----------+ +----------+ +---+ +---+ +---+ +---+ +----------+
|Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding|
+--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+
: Link : \ ,-----. / / ,-----. \ : Link : \ ,-----. / / ,-----. \
+.......+ +----[ Sub ]----+ +--[ Sub ]--+ +.......+ +----[ Sub- ]----+ +--[ Sub- ]--+
[Network] [Network] [network] [network]
`-----' `-----' `-----' `-----'
|<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->|
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<xref target="fig_non_detnet_ip"/> illustrates a variant of <xref <xref target="fig_non_detnet_ip" format="default"/> illustrates a varian
target="fig_ip_detnet_simple"/> where the end systems are not DetNet t of <xref target="fig_ip_detnet_simple" format="default"/> where the end system
s are not DetNet
aware. In this case, edge nodes sit at the boundary of the DetNet aware. In this case, edge nodes sit at the boundary of the DetNet
domain and provide DetNet service proxies for the end applications by domain and provide DetNet service proxies for the end applications by
initiating and terminating DetNet service for the application's IP initiating and terminating DetNet service for the application's IP
flows. The existing header information or an approach such as described flows. The existing header information or an approach such as described
in <xref target="aggregation"/> can be used to support DetNet flow in <xref target="aggregation" format="default"/> can be used to support DetNet flow
identification. identification.
</t> </t>
<t> <t>
Note that <xref target="fig_ip_detnet_simple"/> and Note that Figures <xref target="fig_ip_detnet_simple"
<xref target="fig_non_detnet_ip"/> can be collapsed, so IP DetNet format="counter"/> and <xref target="fig_non_detnet_ip"
End Systems can communicate over a DetNet IP network with IP End Systems format="counter"/> can be collapsed,
. so IP DetNet
end systems can communicate over a DetNet IP network with IP end systems
.
</t> </t>
<t> <t>
As non-DetNet and DetNet IP packets have the same protocol As non-DetNet and DetNet IP packets have the same protocol header
header format on the wire, from format on the wire, from
a data plane perspective, the only difference is that there is a data plane perspective, the only difference is that there is
flow-associated DetNet information on each DetNet node that flow-associated DetNet information on each DetNet node that
defines the flow related characteristics and required forwarding defines the flow-related characteristics and required forwarding
behavior. As shown above, edge nodes provide a Service Proxy behavior. As shown above, edge nodes provide a Service Proxy
function that "associates" one or more IP flows with the function that "associates" one or more IP flows with the
appropriate DetNet flow-specific information and ensures that appropriate DetNet flow-specific information and ensures that
the flow receives the proper traffic treatment within the domain. the flow receives the proper traffic treatment within the domain.
</t> </t>
<t> <aside>
Note: The operation of IEEE802.1 TSN end systems over DetNet <t>
enabled IP networks is not described in this document. TSN Note: The operation of IEEE 802.1 TSN end systems over DetNet-enabled
over MPLS is described in <xref target="I-D.ietf-detnet-tsn-vpn-over-mpl IP networks is not described in this document. TSN
s"/>. over MPLS is described in <xref
</t> target="I-D.ietf-detnet-tsn-vpn-over-mpls" format="default"/>.
</t>
</aside>
</section> </section>
<!-- ================================================================= --> <section anchor="dn-gen-encap-solution" numbered="true" toc="default">
<!-- =================== General Encap considerations ================ --> <name>DetNet IP Data Plane Considerations</name>
<!-- ================================================================= -->
<section title="DetNet IP Data Plane Considerations" anchor="dn-gen-encap-so
lution">
<t> <t>
This section provides considerations related to This section provides considerations related to
providing DetNet service to flows which are identified providing DetNet service to flows that are identified
based on their header information. based on their header information.
</t> </t>
<section numbered="true" toc="default">
<section title="End System Specific Considerations"> <name>End-System-Specific Considerations</name>
<t> <t>
Data-flows requiring DetNet service are generated and terminate Data flows requiring DetNet service are generated and terminated on
d on end systems. This document deals only with IP end systems.
end systems. This document deals only with IP end systems. The protocols used by an IP end system are specific to an application,
The protocols used by an IP end system are specific to an appli and end systems peer with other end systems.
cation, DetNet's use of 6-tuple IP flow
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 the identification means that DetNet must be aware of not only the
format of the IP header, but also of the next protocol value carried format of the IP header, but also of the next protocol value carried
within an IP packet (see <xref target="nxt-proto-field"/>). within an IP packet (see <xref target="nxt-proto-field" format="defaul t"/>).
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
When IP end systems are DetNet-aware, no application-level or When IP end systems are DetNet aware, no application-level or
service-level proxy functions are needed inside the DetNet domain. service-level proxy functions are needed inside the DetNet domain.
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 when processing packets associated to a DetNet flow. When
sending packets, this means that packets are sending packets, this means that packets are
appropriately shaped on transmission and receive appropriate traffic appropriately shaped on transmission and receive appropriate traffic
treatment on the connected sub-network; see <xref target="QoS"/> and treatment on the connected sub-network; see Sections <xref target="QoS
<xref target="dn_dom_spec_cons"/> for more details. When receiving pa "
ckets, format="counter"/> and <xref target="dn_dom_spec_cons"
format="counter"/> for more details. When receiving packets,
this means that there are appropriate local node resources, this means that there are appropriate local node resources,
e.g., buffers, to receive and process the packets of that DetNet flow. e.g., buffers, to receive and process the packets of that DetNet flow.
</t> </t>
<t> <t>
An important additional consideration for DetNet-aware end An important additional consideration for DetNet-aware end
systems is avoiding IP fragmentation. Full 6-tuple flow systems is avoiding IP fragmentation. Full 6-tuple flow
identification is not possible on IP fragments as fragments identification is not possible on IP fragments, as fragments
don't include the transport headers or their port don't include the transport headers or their port
information. As such, it is important that applications and/or information. As such, it is important that applications and/or
end-systems use an IP packet size that will avoid end systems use an IP packet size that will avoid
fragmentation within the network when sending DetNet flows. fragmentation within the network when sending DetNet flows.
The maximum size can be learned via path MTU discovery, <xref The maximum size can be learned via Path MTU Discovery <xref
target="RFC1192"/> and <xref target="RFC8201"/>, or via target="RFC1191" /> <xref target="RFC8201"
the controller plane. Note that path MTU discovery relies on format="default"/> or via the Controller Plane. Note that Path MTU
Discovery relies on
ICMP, which may not follow the same path as an individual ICMP, which may not follow the same path as an individual
DetNet flow. DetNet flow.
</t> </t>
<t> <t>
In order to maximize reuse of existing mechanisms, In order to maximize reuse of existing mechanisms,
DetNet-aware applications and end systems SHOULD NOT mix DetNet-aware applications and end systems <bcp14>SHOULD NOT</bcp14> mi x
DetNet and non-DetNet traffic within a single 5-tuple. DetNet and non-DetNet traffic within a single 5-tuple.
</t> </t>
</section> </section>
<section anchor="dn_dom_spec_cons" numbered="true" toc="default">
<section title="DetNet Domain-Specific Considerations" anchor="dn_dom_spec <name>DetNet Domain-Specific Considerations</name>
_cons">
<t> <t>
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 limit DetNet flow identified by the IP 6-tuple. Doing otherwise would limit
the number of 6-tuple flow ID combinations that could be used b the number of 6-tuple flow ID combinations that could be
y the used by the end systems. From a practical standpoint, this
end systems. From a practical standpoint this
means that all nodes along the end-to-end path of DetNet flows need means that all nodes along the end-to-end path of DetNet flows need
to agree on what fields are used for flow identification. to agree on what fields are used for flow identification.
Possible consequences of not having such an agreement include Possible consequences of not having such an agreement include
some flows interfering with other flows, and some flows interfering with other flows, and
the traffic treatment expected for a service not being the traffic treatment expected for a service not being
provided. provided.
</t> </t>
<t> <t>
From a connection type perspective two scenarios are identified: From a connection-type perspective, two scenarios are identified:
<list style="numbers">
<t>
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 in figure below)
</t>
<t>
DN integrated: the end system is part of the DetNet domain. (See E
S3
in figure below)
</t>
</list>
</t> </t>
<ol spacing="normal" type="1">
<li>
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 in <xref target="fig_es_con_types"/>.)
</li>
<li>
DN integrated: the end system is part of the DetNet domain. (See E
S3
in <xref target="fig_es_con_types"/>.)
</li>
</ol>
<t> <t>
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 domain allows communication between any end systems using the
same encapsulation format, independent of their connection type and same encapsulation format, independent of their connection type and
DetNet capability. DN attached end systems have no knowledge about DetNet capability. DN-attached end systems have no knowledge about
the DetNet domain and its encapsulation format. See <xref the DetNet domain and its encapsulation format. See <xref target="fig
target="fig_es_con_types"/> for L3 end system connection examples. _es_con_types" format="default"/> for L3 end system connection examples.
</t> </t>
<figure anchor="fig_es_con_types">
<figure title="Connection types of L3 end systems" anchor="fig_es_con_ty <name>Connection Types of L3 End Systems</name>
pes"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
____+----+ ____+----+
+----+ _____ / | ES3| +----+ _____ / | ES3|
| ES1|____ / \__/ +----+___ | ES1|____ / \__/ +----+___
+----+ \ / \ +----+ \ / \
+ | + |
____ \ _/ ____ \ _/
+----+ __/ \ +__ DetNet IP domain / +----+ __/ \ +__ DetNet IP domain /
| ES2|____/ L2/L3 |___/ \ __ __/ | ES2|____/ L2/L3 |___/ \ __ __/
+----+ \_______/ \_______/ \___/ +----+ \_______/ \_______/ \___/
]]></artwork>
</figure>
]]> <t>
</artwork></figure> Within a DetNet domain, the DetNet-enabled IP routers are
interconnected by links and sub-networks to support end-to-end
<t> delivery of DetNet flows. From a DetNet architecture perspective,
Within a DetNet domain, the DetNet-enabled IP Routers are interconne these routers are DetNet relays, as they must be DetNet service
cted by aware. Such routers identify DetNet flows based on the IP 6-tuple
links and sub-networks to support end-to-end delivery of DetNet and ensure that the traffic treatment required by the DetNet service
flows. From a DetNet architecture perspective, these routers are is
DetNet relays, as they must be DetNet service aware. Such routers provided on both the node and any attached sub-network.
identify DetNet flows based on the IP 6-tuple, and ensure that the </t>
DetNet service required traffic treatment is provided both on the <t>
node and on any attached sub-network. This solution provides DetNet functions end to end, but it does so
</t> on a per-link and per-sub-network basis. Congestion protection, lat
<t> ency
This solution provides DetNet functions end-to-end, but does so on control,
a per link and sub-network basis. Congestion protection and and resource allocation (queuing, policing,
latency control and the resource allocation (queuing, policing, shaping) are supported using the underlying
shaping) are supported using the underlying link/sub-network link/sub-network-specific mechanisms. However, service protection
specific mechanisms. However, service protection (packet (PRF and PEF) is not
replication and packet elimination functions) is not provided at provided end to end at the DetNet layer.
the DetNet layer end-to-end. Instead service protection can be Instead, service protection can be
provided on a per underlying L2 link and sub-network basis. provided on a per-link (underlying
</t> L2 link) and per-sub-network basis.
</t>
<!-- =================================================================
<figure title="Encapsulation of DetNet Routing in simplified
IP service L3 end systems"
anchor="fig_simple_iprouting">
<artwork align="center"><![CDATA[
+- - - - - -+ +- - - - - -+
| X | | X |
+======+ +- - - - - -+
End system | IP | | IP |
- - - - -+- - - - - -+- - - - - - -+======+- - - - -+======+- -
DetNet |L2/SbN| |L2/SbN|
+- - - - - -+ +- - - - - -+
]]>
</artwork></figure>
<t> <t>
The DetNet Service Flow is mapped to the link/sub-network The DetNet service flow is mapped to the
specific resources using an underlying system-specific link/sub-network-specific resources using an underlying
means. This implies each DetNet-aware node on path looks system-specific
into the forwarded DetNet Service Flow packet and utilize means. This implies that each DetNet-aware node on the path looks
e.g., a 6-tuple to find out the required mapping within into the forwarded DetNet service flow packet and utilizes,
for example, a 6-tuple to find out the required mapping within
a node. a node.
</t> </t>
<t> <t>
As noted earlier, service protection must be implemente As noted earlier, service protection must be implemented within
d within each link/sub-network independently, using the domain-specific
each link/sub-network independently, using the domain s mechanisms. This is due to the lack of unified end-to-end
pecific sequencing information that could be used by the intermediate
mechanisms. This is due to the lack of unified end-to-e nodes.
nd Therefore, service protection (if enabled) cannot be provided
sequencing information that could be used by the interm end to end, only within sub-networks. This is shown for a scenario
ediate with three sub-networks in <xref target="fig_pref_in_subnets"
nodes. format="default"/>,
Therefore, service protection (if enabled) cannot be provided where each sub-network can provide service protection between
end-to-end, only within sub-networks. This is shown for a three
sub-network scenario in <xref target="fig_pref_in_subnets"/>,
where each sub-network can provide service protection between
its borders. "R" and "E" denote replication and elimination its borders. "R" and "E" denote replication and elimination
points within the sub-network. points within the sub-network.
</t> </t>
<figure anchor="fig_pref_in_subnets">
<figure title="Replication and elimination in sub-networks for DetNe <name>Replication and Elimination in Sub-networks for DetNet IP
t IP networks" anchor="fig_pref_in_subnets"> Networks</name>
<artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[ <-------------------- DetNet IP ------------------------>
<-------------------- DenNet IP ------------------------>
______ ______
____ / \__ ____ / \__
____ / \__/ \___ ______ ____ / \__/ \___ ______
+----+ __/ +====+ +==+ \ +----+ +----+ __/ +====+ +==+ \ +----+
|src |__/ SubN1 ) | | \ SubN3 \____| dst| |src |__/ Sub-N1 ) | | \ Sub-N3\____| dst|
+----+ \_______/ \ Sub-Network2 | \______/ +----+ +----+ \_______/ \ Sub-network 2 | \______/ +----+
\_ _/ \_ _/
----+ \_______/ \ <span class="insert">Sub-network 2</span> | \___ ___/ +----+
\ __ __/ \ __ __/
\_______/ \___/ \_______/ \___/
+---+ +---------E--------+ +-----+ +---+ +---------E--------+ +-----+
+----+ | | | | | | | +----+ +----+ | | | | | | | +----+
|src |----R E--------R +---+ E------R E------+ dst| |src |----R E--------R +---+ E------R E------+ dst|
+----+ | | | | | | | +----+ +----+ | | | | | | | +----+
+---+ +-----R------------+ +-----+ +---+ +-----R------------+ +-----+
]]> ]]></artwork>
</artwork></figure> </figure>
<t> <t>
If end-to-end service protection is desired, it can be If end-to-end service protection is desired, it can be
implemented, for example, by the DetNet end systems using Layer-4 implemented -- for example, by the DetNet end systems using
Layer 4
(L4) transport protocols or application protocols. However, these (L4) transport protocols or application protocols. However, these
protocols are out of scope of this document. protocols are out of the scope of this document.
</t>
<t>
Note that not mixing DetNet and non-DetNet traffic within
a single 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-congestion-responsive DetNet
traffic from escaping the DetNet domain.
</t>
</section>
<section title="Forwarding Sub-Layer Considerations">
<section title="Class of Service">
<t>
Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is pr
ovided using the standard
differentiated services (DSCP) field <xref
target="RFC2474"/> and related mechanisms.
</t> </t>
<t> <t>
One additional consideration for DetNet nodes which support CoS Note that not mixing DetNet and non-DetNet traffic within
services is that they must ensure that the CoS service classes do a single 5-tuple, as described above, enables simpler
not impact the congestion protection and latency control mechanisms 5-tuple filters to be used (or reused) at the edges of a DetNet
used to provide DetNet QoS. This requirement is similar to the network to prevent non-congestion-responsive DetNet
requirement for MPLS LSRs that CoS LSPs cannot impact the resou traffic from escaping the DetNet
rces domain.
allocated to TE LSPs <xref target="RFC3473"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Forwarding Sub-Layer Considerations</name>
<section numbered="true" toc="default">
<name>Class of Service</name>
<section title="Quality of Service" anchor="QoS"> <t>
<t> Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6
is provided using the standard
DSCP field <xref target="RFC2474"
format="default"/> and related mechanisms.
</t>
<t>
One additional consideration for DetNet nodes that support CoS
services is that they must ensure that the CoS service classes do
not impact the congestion protection and latency control mechanisms
used to provide DetNet QoS. This requirement is similar to the
requirement for MPLS Label Switching Routers (LSRs) that CoS LSPs
cannot impact the resources allocated to TE
LSPs <xref target="RFC3473" format="default"/>.
</t>
</section>
<section anchor="QoS" numbered="true" toc="default">
<name>Quality of Service</name>
<t>
Quality of Service (QoS) for DetNet service flows carried in IP must b e provided locally by Quality of Service (QoS) for DetNet service flows carried in IP must b e provided locally by
the DetNet-aware hosts and routers supporting DetNet flows. Such the DetNet-aware hosts and routers supporting DetNet flows. Such
support leverages the underlying network layer such as support leverages the underlying network layer such as
802.1 TSN. The node-internal traffic control mechanisms used to deliv 802.1 TSN. The node-internal traffic control mechanisms used to
er QoS for deliver QoS for
IP encapsulated DetNet flows are outside the scope of this IP-encapsulated DetNet flows are outside the scope of this
document. From an encapsulation perspective, the combination of the 6- tuple document. From an encapsulation perspective, the combination of the 6- tuple
(the typical 5-tuple enhanced with the DSCP) and optionally (the typical 5-tuple enhanced with the DSCP) and optionally
the flow label uniquely identifies a DetNet IP flow. the flow label uniquely identifies a DetNet IP flow.
</t> </t>
<t> <t>
Packets that are identified as part of a DetNet IP flow Packets that are identified as part of a DetNet IP flow
but that have not been the subject of a completed reservation but that have not been the subject of a completed reservation
can disrupt the QoS offered to properly reserved DetNet flows can disrupt the QoS offered to properly reserved DetNet flows
by using resources allocated to the reserved flows. by using resources allocated to the reserved flows.
Therefore, the network nodes of a DetNet network MUST ensure Therefore, the network nodes of a DetNet network <bcp14>MUST</bcp14> e
that no DetNet allocated resources, e.g., queue or shaper, is nsure
that no DetNet-allocated resource, e.g., queue or shaper, is
used by such flows. used by such flows.
There are multiple methods that may be There are multiple methods that may be
used by an implementation to defend service delivery to 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:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
Treating packets associated with an incomplete reservation Treating packets associated with an incomplete reservation
as non-DetNet traffic. as non-DetNet traffic.
</t> </li>
<t> <li>
Discarding packets associated with an incomplete Discarding packets associated with an incomplete
reservation. reservation.
</t> </li>
<t> <li>
Re-marking packets associated with an incomplete Re-marking packets associated with an incomplete
reservation. Re-marking can be accomplished by changing reservation. Re-marking can be accomplished by changing
the value of the DSCP field to a value that the value of the DSCP field to a value that
results in the packet no longer matching any other results in the packet no longer matching any other
reserved DetNet IP flow. reserved DetNet IP flow.
</t> </li>
</list> </ul>
</t> </section>
</section> <section anchor="path" numbered="true" toc="default">
<section title="Path Selection" anchor="path"> <name>Path Selection</name>
<t> <t>
While path selection algorithms and mechanisms are out of While path selection algorithms and mechanisms are out of the
scope of the DetNet data plane definition, it is important to scope of the DetNet data plane definition, it is important to
highlight the implications of DetNet IP flow identification on highlight the implications of DetNet IP flow identification on
path selection and next hops. As mentioned above, the DetNet path selection and next hops. As mentioned above, the DetNet
IP data plane identifies flows using "6-tuple" header IP data plane identifies flows using 6-tuple header
information as well as the optional (flow label) header information as well as the optional (flow label) header
field. DetNet generally allows for both flow-specific traffic field. DetNet generally allows for both flow-specific traffic
treatment and flow-specific next-hops. treatment and flow-specific next hops.
</t> </t>
<t> <t>
In non-DetNet IP forwarding, it is generally assumed that the In non-DetNet IP forwarding, it is generally assumed that the
same series of next hops, i.e., the same path, will be used same series of next hops, i.e., the same path, will be used
for a particular 5-tuple or, in some cases, e.g., <xref for a particular 5-tuple or, in some cases (e.g., <xref
target="RFC5120"/>, for a particular 6-tuple. Using different target="RFC5120" format="default"/>), for a particular 6-tuple.
Using different
next hops for different 5-tuples does not take any special next hops for different 5-tuples does not take any special
consideration for DetNet-aware applications. consideration for DetNet-aware applications.
</t> </t>
<t> <t>
Care should be taken when using different next hops for the Care should be taken when using different next hops for the
same 5-tuple. As discussed in <xref target="RFC7657"/>, same 5-tuple. As discussed in <xref target="RFC7657" format="default" />,
unexpected behavior can occur when a single 5-tuple unexpected behavior can occur when a single 5-tuple
application flow experiences reordering due to being split application flow experiences reordering due to being split
across multiple next hops. Understanding of the application across multiple next hops. Understanding of the application
and transport protocol impact of using different next hops for and transport protocol impact of using different next hops for
the same 5-tuple is required. Again, this impacts path the same 5-tuple is required. Again, this only indirectly impacts pat
selection for DetNet flows and this document only indirectly. h
</t> selection for DetNet flows and this document.
</section> </t>
</section>
</section> </section>
<section anchor="aggregation" numbered="true" toc="default">
<section title="DetNet Flow Aggregation" anchor="aggregation"> <name>DetNet Flow Aggregation</name>
<t> <t>
As described in <xref As described in <xref target="RFC8938" format="default"/>, the ability
target="I-D.ietf-detnet-data-plane-framework"/>, the ability to to
aggregate individual flows, and their associated resource aggregate individual flows and their associated resource
control, into a larger aggregate is an important technique for control into a larger aggregate is an important technique for
improving scaling by reducing the state per hop. DetNet IP improving scaling by reducing the state per hop. DetNet IP
data plane aggregation can take place within a single node, data plane aggregation can take place within a single node,
when that node maintains state about both the aggregated and when that node maintains state about both the aggregated and
individual flows. It can also take place between nodes, where individual flows. It can also take place between nodes, when
one node maintains state about only flow aggregates while the one node maintains state about only flow aggregates while the
other node maintains state on all or a portion of the component other node maintains state on all or a portion of the component
flows. In either case, the management or control function that flows. In either case, the management or control function that
provisions the aggregate flows must ensure that adequate provisions the aggregate flows must ensure that adequate
resources are allocated and configured to provide combined resources are allocated and configured to provide the combined
service requirements of the individual flows. As DetNet is service requirements of the individual flows. As DetNet is
concerned about latency and jitter, more than just bandwidth concerned about latency and jitter, more than just bandwidth
needs to be considered. needs to be considered.
</t> </t>
<t> <t>
From a single node perspective, the aggregation of IP flows From a single node perspective, the aggregation of IP flows
impacts DetNet IP data plane flow identification and resource impacts DetNet IP data plane flow identification and resource
allocation. As discussed above, IP flow identification uses allocation. As discussed above, IP flow identification uses
the IP "6-tuple" for flow identification. DetNet IP flows can the IP 6-tuple for flow identification. DetNet IP flows can
be aggregated using any of the 6-tuple fields and optionally also by be aggregated using any of the 6-tuple fields and optionally also by
the flow label. The use of prefixes, wildcards, the flow label. The use of prefixes, wildcards,
lists, and value ranges allows a DetNet node to identify lists, and value ranges allows a DetNet node to identify
aggregate DetNet flows. From a resource allocation aggregate DetNet flows. From a resource allocation
perspective, DetNet nodes ought to provide service to an perspective, DetNet nodes ought to provide service to an
aggregate rather than on a component flow basis. aggregate rather than on a component flow basis.
</t> </t>
<t> <t>
It is the responsibility of the DetNet controller plane to It is the responsibility of the DetNet Controller Plane to
properly provision the use of these aggregation mechanisms. properly provision the use of these aggregation mechanisms.
This includes ensuring that aggregated flows have compatible This includes ensuring that aggregated flows have compatible
(e.g., the same or very similar) QoS and/or CoS characteristics, (e.g., the same or very similar) QoS and/or CoS characteristics;
see <xref target="QoS"/>. It also includes ensuring that per see <xref target="QoS" format="default"/>. It also includes
component-flow service requirements are satisfied by the ensuring that per-component-flow service requirements are satisfied
aggregate, see <xref target="ip-svc"/>. by the aggregate; see <xref target="ip-svc" format="default"/>.
</t> </t>
<t> <t>
The DetNet controller plane MUST ensure that The DetNet Controller Plane <bcp14>MUST</bcp14> ensure that
non-congestion-responsive DetNet traffic is not forwarded non-congestion-responsive DetNet traffic is not forwarded
outside a DetNet domain. outside a DetNet domain.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Bidirectional Traffic"> <name>Bidirectional Traffic</name>
<t> <t>
While the DetNet IP data plane must support bidirectional While the DetNet IP data plane must support bidirectional
DetNet flows, there are no special bidirectional features within DetNet flows, there are no special bidirectional features within
the data plane. The special case of co-routed bidirectional the data plane. The special case of co-routed bidirectional
DetNet flows are DetNet flows is
solely represented at the management and control plane levels, solely represented at the management and control plane levels,
without specific support or knowledge within the DetNet data without specific support or knowledge within the DetNet data
plane. Fate sharing and associated or co-routed plane. Fate sharing and associated or co-routed
bidirectional flows can be managed at the control level. bidirectional flows can be managed at the control level.
</t> </t>
<t> <t>
Control and management mechanisms need to support Control and management mechanisms need to support
bidirectional flows, but the specification of such mechanisms bidirectional flows, but the specification of such mechanisms
are out of scope of this document. An example control plane is out of the scope of this document. An example control plane
solution for MPLS can be found in <xref target="RFC7551"/>. solution for MPLS can be found in <xref target="RFC7551" format="defau
lt"/>.
</t> </t>
</section> </section>
</section> </section>
<!-- ===================================================================== -
->
<!-- ===================================================================== -
->
<section anchor="ip-procs" title="DetNet IP Data Plane Procedures"> <section anchor="ip-procs" numbered="true" toc="default">
<name>DetNet IP Data Plane Procedures</name>
<t> <t>
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 identification includes those procedures related to matching
and higher layer protocol header information to DetNet flow IP-layer
and higher-layer protocol header information to DetNet flow
(state) information and service requirements. Flow (state) information and service requirements. Flow
identification is also sometimes called Traffic classification; identification is also sometimes called "traffic classification";
for example see <xref target="RFC5777"/>. Forwarding includes for example, see <xref target="RFC5777" format="default"/>. Forwarding
those procedures related to next hop selection and includes
those procedures related to next-hop selection and
delivery. Traffic treatment includes those procedures related to 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.
</t> </t>
<t> <t>
DetNet IP data plane establishment and operational procedures DetNet IP data plane establishment and operational procedures
also have requirements on the control and management systems also have requirements on the control and management systems
for DetNet flows and these are referred to in this section. for DetNet flows, and these are referred to in this section.
Specifically this section identifies a Specifically, this section identifies a
number of information elements that require support via the number of information elements that require support via the
management and control interfaces supported by a DetNet node. management and control interfaces supported by a DetNet node.
The specific mechanism used for such support is out of the scope The specific mechanism used for such support is out of the scope
of this document. A summary of the requirements for management and cont of this document. A summary of the requirements for management- and
rol control-related information is included. Conformance
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
<xref target="I-D.ietf-detnet-yang"/>. <xref target="I-D.ietf-detnet-yang" format="default"/>.
</t> </t>
<section anchor="ip-flow-id" <section anchor="ip-flow-id" numbered="true" toc="default">
title="DetNet IP Flow Identification Procedures"> <name>DetNet IP Flow Identification Procedures</name>
<t> <t>
IP and higher layer protocol header information is used to IP-layer and higher-layer protocol header information is used to ident
identify DetNet flows. All DetNet implementations that support ify
this document MUST identify individual DetNet flows based on DetNet flows. All DetNet implementations that support this document
the set of information identified in this section. Note that <bcp14>MUST</bcp14> identify individual DetNet flows based on the
additional flow identification requirements, e.g., to support set of information identified in this section. Note that additional
other higher layer protocols, may be defined in the future. requirements for flow identification, e.g., to support
other higher-layer protocols, may be defined in the future.
</t> </t>
<t> <t>
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 <bcp14>MUST</bcp14> be ordered by an implementa
Implementations MUST support a fixed order when identifying tion.
flows, and MUST identify a DetNet flow by the first set of Implementations <bcp14>MUST</bcp14> support a fixed order when identif
ying
flows and <bcp14>MUST</bcp14> identify a DetNet flow by the first set
of
matching flow information. matching flow information.
</t> </t>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> support DetNet fl ow
identification when the implementation is acting as a identification when the implementation is acting as a
DetNet end systems, a relay node, or as an edge node. DetNet end system, a relay node, or an edge node.
</t> </t>
<section anchor="ip-hdr" numbered="true" toc="default">
<section anchor="ip-hdr" title="IP Header Information"> <name>IP Header Information</name>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> support DetNet flow
identification based on IP header information. The IPv4 identification based on IP header information. The IPv4
header is defined in <xref target="RFC0791"/> and the IPv6 header is defined in <xref target="RFC0791" format="default"/>, and
is defined in <xref target="RFC8200"/>. the IPv6
is defined in <xref target="RFC8200" format="default"/>.
</t> </t>
<section title="Source Address Field"> <section numbered="true" toc="default">
<name>Source Address Field</name>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> support DetNe t flow
identification based on the Source Address field of an IP identification based on the Source Address field of an IP
packet. Implementations SHOULD support longest prefix packet. Implementations <bcp14>SHOULD</bcp14> support longest pref
matching for this field (see <xref target="RFC1812"/> and ix
<xref target="RFC7608"/>.) Note that a prefix length of matching for this field (see <xref target="RFC1812" format="defaul
t"/> and
<xref target="RFC7608" format="default"/>). Note that a prefix len
gth of
zero (0) effectively means that the field is ignored. zero (0) effectively means that the field is ignored.
</t> </t>
</section> </section>
<section title="Destination Address Field"> <section numbered="true" toc="default">
<name>Destination Address Field</name>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> support DetNe t 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 packet. Implementations <bcp14>SHOULD</bcp14> support longest pref
matching for this field (see <xref target="RFC1812"/> and ix
<xref target="RFC7608"/>.) Note that a prefix length of matching for this field (see <xref target="RFC1812" format="defaul
t"/> and
<xref target="RFC7608" format="default"/>). Note that a prefix len
gth of
zero (0) effectively means that the field is ignored. zero (0) effectively means that the field is ignored.
</t> </t>
<aside>
<t> <t>
Note: Any IP address value is allowed, including an IP Note: Any IP address value is allowed, including an IP
multicast destination address. multicast destination address.
</t> </t>
</aside>
</section> </section>
<section anchor="nxt-proto-field" <section anchor="nxt-proto-field" numbered="true" toc="default">
title="IPv4 Protocol and IPv6 Next Header Fields"> <name>IPv4 Protocol and IPv6 Next Header Fields</name>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> support DetNe t flow
identification based on the IPv4 Protocol field when identification based on the IPv4 Protocol field when
processing IPv4 packets, and the IPv6 Next Header Field processing IPv4 packets and the IPv6 Next Header field
when processing IPv6 packets. This includes when processing IPv6 packets. This includes
the next protocol the next protocol
values defined in <xref target="nxt-proto"/> and any other values defined in <xref target="nxt-proto" format="default"/> and any other
value, including zero. value, including zero.
Implementations SHOULD allow for these fields to be Implementations <bcp14>SHOULD</bcp14> allow for these fields to be
ignored for a specific DetNet flow. ignored for a specific DetNet flow.
</t> </t>
</section> </section>
<section title="IPv4 Type of Service and IPv6 Traffic Class Fields"> <section numbered="true" toc="default">
<name>IPv4 Type of Service and IPv6 Traffic Class Fields</name>
<t> <t>
These fields are used to support Differentiated Services These fields are used to support differentiated services
<xref target="RFC2474"/> <xref target="RFC2475"/>. <xref target="RFC2474" format="default"/> <xref target="RFC2475" f
Implementations of this document MUST support DetNet flow ormat="default"/>.
Implementations of this document <bcp14>MUST</bcp14> support DetNe
t flow
identification based on the DSCP field in the IPv4 Type of identification based on the DSCP field in the IPv4 Type of
Service field when processing IPv4 packets, and the DSCP Service field when processing IPv4 packets and the DSCP
field in the IPv6 Traffic Class Field when processing IPv6 field in the IPv6 Traffic Class field when processing IPv6
packets. Implementations MUST support list-based matching packets. Implementations <bcp14>MUST</bcp14> support list-based m
atching
of DSCP values, where the list is composed of possible of DSCP values, where the list is composed of possible
field values that are to be considered when identifying a field values that are to be considered when identifying a
specific DetNet flow. Implementations SHOULD allow for specific DetNet flow. Implementations <bcp14>SHOULD</bcp14> allow for
this field to be ignored for a specific DetNet flow. this field to be ignored for a specific DetNet flow.
</t> </t>
</section> </section>
<section title="IPv6 Flow Label Field"> <section numbered="true" toc="default">
<name>IPv6 Flow Label Field</name>
<t> <t>
Implementations of this document SHOULD support identification of Implementations of this document <bcp14>SHOULD</bcp14> support ide ntification 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 it that support matching based on this field <bcp14>MUST</bcp14> allo w for it
to be ignored for a specific DetNet flow. When this field to be ignored for a specific DetNet flow. When this field
is used to identify a specific DetNet flow, implementations MAY is used to identify a specific DetNet flow, implementations <bcp14 >MAY</bcp14>
exclude the IPv6 Next Header field and next header information as exclude the IPv6 Next Header field and next header information as
part of DetNet flow identification. part of DetNet flow identification.
</t> </t>
</section> </section>
</section> </section>
<section anchor="nxt-proto" numbered="true" toc="default">
<section anchor="nxt-proto" title="Other Protocol Header Information"> <name>Other Protocol Header Information</name>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> 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 Future documents are expected to define support for other
protocols. protocols.
</t> </t>
<section title="TCP and UDP"> <section numbered="true" toc="default">
<name>TCP and UDP</name>
<t> <t>
DetNet flow identification for TCP <xref DetNet flow identification for TCP <xref target="RFC0793" format="
target="RFC0793"/> and UDP <xref target="RFC0768"/> is default"/> and UDP <xref target="RFC0768" format="default"/> is
achieved based on the Source and Destination achieved based on the Source and Destination
Port fields carried in each protocol's header. These Port fields carried in each protocol's header. These
fields share a common format and common DetNet flow fields share a common format and common DetNet
identification procedures. flow identification procedures.
</t> </t>
<t> <t>
The rules defined in this section only apply when the The rules defined in this section only apply when the
IPv4 Protocol or IPv6 Next Header Field contains the IANA IPv4 Protocol or IPv6 Next Header field contains the
defined value for UDP or TCP. IANA-defined value for UDP or TCP.
</t> </t>
<section title="Source Port Field"> <section numbered="true" toc="default">
<name>Source Port Field</name>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> support Det Net flow
identification based on the Source Port field of a TCP or identification based on the Source Port field of a TCP or
UDP packet. Implementations MUST support flow UDP packet. Implementations <bcp14>MUST</bcp14> support flow
identification based on a particular value carried in the identification based on a particular value carried in the
field, i.e., an exact value. Implementations SHOULD support field, i.e., an exact value. Implementations <bcp14>SHOULD</bcp
range-based port matching. Implementation MUST also allow 14> support
range-based port matching. Implementation <bcp14>MUST</bcp14> al
so allow
for the field to be ignored for a specific DetNet flow. for the field to be ignored for a specific DetNet flow.
</t> </t>
</section> </section>
<section title="Destination Port Field"> <section numbered="true" toc="default">
<name>Destination Port Field</name>
<t> <t>
Implementations of this document MUST support DetNet flow Implementations of this document <bcp14>MUST</bcp14> support Det Net flow
identification based on the Destination Port field of a TCP or identification based on the Destination Port field of a TCP or
UDP packet. Implementations MUST support flow UDP packet. Implementations <bcp14>MUST</bcp14> support flow
identification based on a particular value carried in the identification based on a particular value carried in the
field, i.e., an exact value. Implementations SHOULD support field, i.e., an exact value. Implementations <bcp14>SHOULD</bcp
range-based port matching. Implementation MUST also allow 14> support
range-based port matching. Implementation <bcp14>MUST</bcp14> al
so allow
for the field to be ignored for a specific DetNet flow. for the field to be ignored for a specific DetNet flow.
</t> </t>
</section> </section>
</section> </section>
<section title="ICMP"> <section numbered="true" toc="default">
<name>ICMP</name>
<t> <t>
DetNet flow identification for ICMP <xref target="RFC0792"/> is a DetNet flow identification for ICMP <xref target="RFC0792"
chieved based on the format="default"/> is achieved based on the
protocol number in the IP header. Note that ICMP type i protocol number in the IP header. Note that ICMP type is not inclu
s not included in the ded in the
flow definition. flow definition.
</t> </t>
</section> </section>
<section title="IPsec AH and ESP"> <section numbered="true" toc="default">
<name>IPsec AH and ESP</name>
<t> <t>
IPsec Authentication Header (AH) <xref target="RFC4302"/> IPsec Authentication Header (AH) <xref target="RFC4302" format="de
and Encapsulating Security Payload (ESP) <xref fault"/>
target="RFC4303"/> share a common format for the Security and Encapsulating Security Payload (ESP) <xref target="RFC4303" fo
Parameters Index (SPI) field. Implementations MUST rmat="default"/> share a common format for the Security
Parameters Index (SPI) field. Implementations <bcp14>MUST</bcp14>
support flow identification based on a particular value support flow identification based on a particular value
carried in the field, i.e., an exact value. Implementation SHOULD carried in the field, i.e., an exact value. Implementations
<bcp14>SHOULD</bcp14>
also allow for the field to be ignored for a specific also allow for the field to be ignored for a specific
DetNet flow. DetNet flow.
</t> </t>
<t> <t>
The rules defined in this section only apply when the The rules defined in this section only apply when the
IPv4 Protocol or IPv6 Next Header Field contains the IANA IPv4 Protocol or IPv6 Next Header field contains the
defined value for AH or ESP. IANA-defined value for AH or ESP.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="ip-fwd" numbered="true" toc="default">
<section anchor="ip-fwd" title="Forwarding Procedures"> <name>Forwarding Procedures</name>
<t> <t>
General requirements for IP nodes are defined in <xref General requirements for IP nodes are defined in <xref
target="RFC1122"/>, <xref target="RFC1812"/> and <xref target="RFC1122" format="default"/>, <xref target="RFC1812"
target="RFC8504"/>, and are not modified by this document. The format="default"/>, and <xref target="RFC8504" format="default"/>
and are not modified by this document. The
typical next-hop selection process is impacted by DetNet. typical next-hop selection process is impacted by DetNet.
Specifically, implementations of this document SHALL use Specifically, implementations of this document <bcp14>SHALL</bcp14> us e
management and control information to select the one or more management and control information to select the one or more
outgoing interfaces and next hops to be used for a packet outgoing interfaces and next hops to be used for a packet
associated with a DetNet flow. Specific management and control associated with a DetNet flow. Specific management and control
information will be defined in future documents, e.g., <xref information will be defined in future documents, e.g., <xref target="I
target="I-D.ietf-detnet-yang"/>. -D.ietf-detnet-yang" format="default"/>.
</t> </t>
<t> <t>
The use of multiple paths or links, e.g., ECMP, to support a The use of multiple paths or links, e.g., ECMP, to support a
single DetNet flow is NOT RECOMMENDED. ECMP MAY be used for single DetNet flow is <bcp14>NOT RECOMMENDED</bcp14>. ECMP <bcp14>MAY< /bcp14> be used for
non-DetNet flows within a DetNet domain. non-DetNet flows within a DetNet domain.
</t> </t>
<t> <t>
The above implies that management and control functions will The above implies that management and control functions will
be defined to support this requirement, e.g., see <xref target="I-D.ie be defined to support this requirement, e.g., see <xref
tf-detnet-yang"/>. target="I-D.ietf-detnet-yang" format="default"/>.
</t> </t>
</section> </section>
<section anchor="ip-svc" numbered="true" toc="default">
<section anchor="ip-svc" title="DetNet IP Traffic Treatment Procedures"> <name>DetNet IP Traffic Treatment Procedures</name>
<t> <t>
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 <xref target="I-D.iet configuration or the Controller Plane, e.g., via <xref target="I-D.iet
f-detnet-yang"/>. f-detnet-yang" format="default"/>.
General information on DetNet service can be found in <xref General information on DetNet service can be found in <xref target="I-
target="I-D.ietf-detnet-flow-information-model"/>. Typical D.ietf-detnet-flow-information-model" format="default"/>. 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 include the allocation of system resources (such as queues and
buffers) and provisioning of 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 <xref target="I-D.ietf-detnet-ip-over-mpls"/> technology such as MPLS <xref target="I-D.ietf-detnet-ip-over-mpls" fo
or rmat="default"/> or
IEEE802.1 TSN <xref target="I-D.ietf-detnet-ip-over-tsn"/>. IEEE 802.1 TSN <xref target="I-D.ietf-detnet-ip-over-tsn" format="defa
Other mechanisms than the ones used in the TSN case are outside ult"/>.
the Other mechanisms than the ones used in the TSN case are outsid
scope of this document. e the
scope of this document.
</t> </t>
</section> </section>
</section> </section>
<section anchor="ip-flow-id-info" <section anchor="ip-flow-id-info" numbered="true" toc="default">
title="Management and Control Information Summary"> <name>Management and Control Information Summary</name>
<t> <t>
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:
<list style="symbols"> </t>
<t>IPv4 and IPv6 source address field.</t> <ul spacing="normal">
<t>IPv4 and IPv6 source address prefix length, where a zero <li>IPv4 and IPv6 Source Address field.</li>
(0) value effectively means that the address field is <li>IPv4 and IPv6 source address prefix length, where a zero
ignored.</t> (0) value effectively means that the Source Address field is
<t>IPv4 and IPv6 destination address field.</t> ignored.</li>
<t>IPv4 and IPv6 destination address prefix length, where a <li>IPv4 and IPv6 Destination Address field.</li>
zero (0) effectively means that the address field is <li>IPv4 and IPv6 destination address prefix length, where a
ignored.</t> zero (0) value effectively means that the Destination Address fiel
<t>IPv4 protocol field. A limited set of values is allowed, d is
and the ability to ignore this field is desirable.</t> ignored.</li>
<t>IPv6 next header field. A limited set of values is allowed, <li>IPv4 Protocol field. A limited set of values is allowed,
and the ability to ignore this field is desirable.</t> and the ability to ignore this field is desirable.</li>
<t>For the IPv4 Type of Service and IPv6 Traffic Class <li>IPv6 Next Header field. A limited set of values is allowed,
Fields: and the ability to ignore this field is desirable.</li>
<list style="symbols"> <li>
<t>Whether or not the DSCP field is used in flow identification. <t>For the IPv4 Type of Service and IPv6 Traffic Class fields:
Use of the DSCP field for flow identification is </t>
optional.</t> <ul spacing="normal">
<t>If the DSCP field is used to identify a flow, then the flow <li>Whether or not the DSCP field is used in flow identification.
identification information (for that flow) includ Use of the DSCP field for flow identification is
es a list of optional.</li>
DSCPs used by that flow.</t> <li>If the DSCP field is used to identify a flow, then the flow
</list></t> identification information (for that flow) inclu
<t>IPv6 flow label field. This field can be optionally used des a list of
DSCPs used by that flow.</li>
</ul>
</li>
<li>IPv6 Flow Label field. This field can be optionally used
for matching. When used, this field can be used instead of matchi ng against for matching. When used, this field can be used instead of matchi ng against
the Next Header field.</t> the Next Header field.</li>
<t>TCP and UDP Source Port. Support for both exact and wildcard ma <li>TCP and UDP Source Port. Support for both exact and wildcard matchin
tching is g is
required. Port ranges can optionally be used.</t> required. Port ranges can optionally be used.</li>
<t>TCP and UDP Destination Port. Support for both exact and wildca <li>TCP and UDP Destination Port. Support for both exact and wildcard ma
rd matching is tching is
required. Port ranges can optionally be used.</t> required. Port ranges can optionally be used.</li>
<t>IPsec Header SPI field. Exact matching is <li>IPsec Header SPI field. Exact matching is
required. Support for wildcard matching is required. Support for wildcard matching is
recommended.</t> recommended.</li>
<t>For end systems, an optional maximum IP packet size <li>For end systems, an optional maximum IP packet size
that should be used for that outgoing DetNet IP flow.</t> that should be used for that outgoing DetNet IP flow.</li>
</list> </ul>
This information MUST be provisioned per DetNet flow via <t>
configuration, e.g., via the controller or management plane. This information <bcp14>MUST</bcp14> be provisioned per DetNet flow
</t> via
<t> configuration, e.g., via the Controller Plane or the management plan
An implementation MUST support ordering of the e.
set of information information used to identify an </t>
<t>
An implementation <bcp14>MUST</bcp14> support ordering of the
set of information used to identify an
individual DetNet flow. This can, for example, be individual DetNet flow. This can, for example, be
used to provide a DetNet service for a specific UDP flow, with used to provide a DetNet service for a specific UDP flow, with
unique Source and Destination Port field values, while unique Source and Destination Port field values, while
providing a different service for the aggregate of all other providing a different service for the aggregate of all other
flows with that same UDP Destination Port value. flows with that same UDP Destination Port value.
</t> </t>
<t> <t>
It is the responsibility of the DetNet controller plane to It is the responsibility of the DetNet Controller Plane to
properly provision both flow identification information and properly provision both flow identification information and
the flow specific resources needed to provided the traffic the flow-specific resources needed to provide the traffic
treatment needed to meet each flow's service requirements. treatment needed to meet each flow's service requirements.
This applies for aggregated and individual flows. This applies for aggregated and individual flows.
</t> </t>
</section> </section>
<!-- ===================================================================== - <section numbered="true" toc="default">
-> <name>Security Considerations</name>
<section title="Security Considerations">
<t> <t>
Detailed security considerations for DetNet are cataloged in Detailed security considerations for DetNet are cataloged in
<xref target="I-D.ietf-detnet-security"/>, and more general security cons <xref target="DetNet-Security" format="default"/>, and more general secur
iderations ity considerations
are described in <xref target="RFC8655"/>. This section are described in <xref target="RFC8655" format="default"/>. This section
considers exclusively security considerations which are specific to the D exclusively considers security considerations that are specific to the De
etNet tNet
IP data plane. IP data plane.
</t> </t>
<t> <t>
Security aspects which are unique to DetNet are those whose aim is to Security aspects that are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are provide the specific QoS 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 Achieving such loss rates and bounded latency may not be possible
in the face of a highly capable adversary, such as the one in the face of a highly capable adversary, such as the one
envisioned by the Internet Threat Model of BCP 72 that can envisioned by the Internet Threat Model of BCP 72 <xref
target="RFC3552"/> that can
arbitrarily drop or delay any or all traffic. In order to arbitrarily drop or delay any or all traffic. In order to
present meaningful security considerations, we consider a present meaningful security considerations, we consider a
somewhat weaker attacker who does not control the physical links somewhat weaker attacker who does not control the physical links
of the DetNet domain, but may have the ability to control a of the DetNet domain but may have the ability to control a
network node within the boundary of the DetNet domain. network node within the boundary of the DetNet domain.
</t> </t>
<t> <t>
The primary consideration for the DetNet 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 traversi ng integrity of data and delivery of the associated DetNet service traversi ng
the DetNet network. the DetNet network.
Since no DetNet-specific fields are available in the DetNet IP Since no DetNet-specific fields are available in the DetNet IP
data plane, data plane,
the integrity and confidentiality of application flows can be protected through whatever means are the integrity and confidentiality of application flows can be protected through whatever means are
provided by the underlying technology. For example, encryption may be provided by the underlying technology. For example, encryption may be
used, such as that provided by IPSec <xref target="RFC4301"/> for IP used, such as that provided by IPsec <xref target="RFC4301" format="defa
flows and/or by an underlying sub-net using MACSec ult"/> for IP
<xref target="IEEE802.1AE-2018"/> for IP over Ethernet (Layer-2) flows. flows and/or by an underlying sub-network using
</t> MACsec
<t> <xref target="IEEE802.1AE-2018" format="default"/> for IP over
From a data plane perspective this document does not add or modify any Ethernet (Layer 2) flows.
</t>
<t>
From a data plane perspective, this document does not add or modify any
header information. header information.
</t> </t>
<t> <t>
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 per-flow basis, which may provide Controller Plane
attackers with additional information about the data flows (when attackers with additional information about the data flows (when
compared to controller planes that do not include per-flow identificatio compared to Controller Planes that do not include per-flow identificatio
n). n).
This is an inherent property of DetNet which has security This is an inherent property of DetNet that has security
implications that should be considered when determining if DetNet is implications that should be considered when determining if DetNet is
a suitable technology for any given use case. a suitable technology for any given use case.
</t> </t>
<t> <t>
To provide uninterrupted availability of the DetNet To provide uninterrupted availability of the DetNet service,
service, provisions can be made against DOS attacks and delay provisions can be made against DoS attacks and delay attacks. To
attacks. To protect against DOS attacks, excess traffic due to protect against DoS attacks, excess traffic due to malicious or
malicious or malfunctioning devices can be prevented or mitigated, malfunctioning devices can be prevented or mitigated -- for example,
for example through the use of existing mechanism such as policing and s through the use of existing mechanisms such as policing and shaping
haping applied at applied at the input of a DetNet domain or within an edge IEEE 802.1
the input of a DetNet domain or within an edge IEEE802.1 TSN domain. To TSN domain. To prevent DetNet packets from being delayed by an entity
prevent DetNet packets from external to a DetNet domain, DetNet technology definitions can allow
being delayed by an entity external to a DetNet domain, DetNet for the mitigation of man-in-the-middle attacks -- for example,
technology definition can allow for the mitigation of through the use of authentication and authorization of devices within th
Man-In-The-Middle attacks, for example through use of e
authentication and authorization of devices within the DetNet domain. DetNet domain.
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
This document does not require an action from IANA. This document has no IANA actions.
</t> </t>
</section> </section>
</middle>
<back>
<section anchor="acks" title="Acknowledgements"> <displayreference target="I-D.ietf-detnet-flow-information-model" to="DetNet-Flo
w-Info"/>
<displayreference target="I-D.ietf-detnet-yang" to="DetNet-YANG"/>
<displayreference target="I-D.ietf-detnet-ip-over-tsn" to="DetNet-IP-over-TSN"/>
<displayreference target="I-D.ietf-detnet-ip-over-mpls" to="DetNet-IP-over-MPLS"
/>
<displayreference target="I-D.ietf-detnet-tsn-vpn-over-mpls" to="DetNet-TSN-over
-MPLS"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0768.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0792.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0793.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1812.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2474.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4302.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4303.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7608.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8655.xml"/>
<!-- draft-ietf-detnet-data-plane-framework (RFC 8938) -->
<reference anchor='RFC8938'>
<front>
<title>Deterministic Networking (DetNet) Data Plane Framework</title>
<author initials='B' surname='Varga' fullname='Balazs Varga' role="editor">
<organization />
</author>
<author initials='J' surname='Farkas' fullname='Janos Farkas'>
<organization />
</author>
<author initials='L' surname='Berger' fullname='Lou Berger'>
<organization />
</author>
<author initials='A' surname='Malis' fullname='Andrew Malis'>
<organization />
</author>
<author initials='S' surname='Bryant' fullname='Stewart Bryant'>
<organization />
</author>
<date month='November' year='2020' />
</front>
<seriesInfo name="RFC" value="8938"/>
<seriesInfo name="DOI" value="10.17487/RFC8938"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1191.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2475.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3290.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3473.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3552.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3670.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5120.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5777.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8504.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7657.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8201.xml"/>
<!-- draft-ietf-detnet-mpls (RFC-EDITOR) -->
<!-- Have to do long way; Balazs Varga is an editor -->
<reference anchor="DetNet-MPLS" target="https://tools.ietf.org/html/draf
t-ietf-detnet-mpls-13">
<front>
<title>DetNet Data Plane: MPLS</title>
<author initials="B" surname="Varga" fullname="Balazs Varga"
role="editor">
<organization/>
</author>
<author initials="J" surname="Farkas" fullname="Janos Farkas">
<organization/>
</author>
<author initials="L" surname="Berger" fullname="Lou Berger">
<organization/>
</author>
<author initials="A" surname="Malis" fullname="Andrew Malis">
<organization/>
</author>
<author initials="S" surname="Bryant" fullname="Stewart Bryant">
<organization/>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization/>
</author>
<date day="11" month="October" year="2020"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-detnet-mpls-13"/>
</reference>
<!-- draft-ietf-detnet-flow-information-model (Waiting for Writeup) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-detnet-flow-information-model.xml"/>
<!-- draft-ietf-detnet-security (Waiting for Writeup) -->
<!-- Have to do long way; Ethan Grossman is an editor -->
<reference anchor="DetNet-Security"
target="https://tools.ietf.org/html/draft-ietf-detnet-security-12">
<front>
<title>Deterministic Networking (DetNet) Security
Considerations</title>
<author initials="E" surname="Grossman" fullname="Ethan Grossman" r
ole="editor">
<organization/>
</author>
<author initials="T" surname="Mizrahi" fullname="Tal Mizrahi">
<organization/>
</author>
<author initials="A" surname="Hacker" fullname="Andrew Hacker">
<organization/>
</author>
<date month="October" day="2" year="2020"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-detnet-security-12"/>
</reference>
<!-- draft-ietf-detnet-yang (I-D Exists) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-detnet-yang.xml"/>
<!-- draft-ietf-detnet-ip-over-tsn (I-D Exists) -->
<!-- Have to do long way; B Varga is an editor -->
<reference anchor='I-D.ietf-detnet-ip-over-tsn'>
<front>
<title>DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)</ti
tle>
<author initials='B' surname='Varga' fullname='Balazs Varga' role="editor">
<organization />
</author>
<author initials='J' surname='Farkas' fullname='Janos Farkas'>
<organization />
</author>
<author initials='A' surname='Malis' fullname='Andrew Malis'>
<organization />
</author>
<author initials='S' surname='Bryant' fullname='Stewart Bryant'>
<organization />
</author>
<date month='November' day='2' year='2020' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-detnet-ip-over-tsn-04' />
</reference>
<!-- draft-ietf-detnet-ip-over-mpls (MISSREF) -->
<!-- Have to do long way; B Varga is an editor -->
<reference anchor='I-D.ietf-detnet-ip-over-mpls'>
<front>
<title>DetNet Data Plane: IP over MPLS</title>
<author initials='B' surname='Varga' fullname='Balazs Varga' role="editor">
<organization />
</author>
<author initials='L' surname='Berger' fullname='Lou Berger'>
<organization />
</author>
<author initials='D' surname='Fedyk' fullname='Don Fedyk'>
<organization />
</author>
<author initials='S' surname='Bryant' fullname='Stewart Bryant'>
<organization />
</author>
<author initials='J' surname='Korhonen' fullname='Jouni Korhonen'>
<organization />
</author>
<date month='October' day='11' year='2020' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-detnet-ip-over-mpls-09' />
</reference>
<!-- draft-ietf-detnet-tsn-vpn-over-mpls (I-D Exists) -->
<!-- Had to do long way; B Varga is an editor -->
<reference anchor='I-D.ietf-detnet-tsn-vpn-over-mpls'>
<front>
<title>DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS</title>
<author initials='B' surname='Varga' fullname='Balazs Varga' role="editor">
<organization />
</author>
<author initials='J' surname='Farkas' fullname='Janos Farkas'>
<organization />
</author>
<author initials='A' surname='Malis' fullname='Andrew Malis'>
<organization />
</author>
<author initials='S' surname='Bryant' fullname='Stewart Bryant'>
<organization />
</author>
<author initials='D' surname='Fedyk' fullname='Don Fedyk'>
<organization />
</author>
<date month='November' day='2' year='2020' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-detnet-tsn-vpn-over-mpls-04'
/>
</reference>
<reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org
/document/8585421">
<front>
<title>IEEE Standard for Local and metropolitan area networks-Media
Access Control (MAC) Security</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2018" month="December"/>
</front>
<seriesInfo name="IEEE" value="802.1AE-2018" />
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421" />
</reference>
<reference anchor="IEEE802.1TSNTG" target="https://1.ieee802.org/tsn/">
<front>
<title>Time-Sensitive Networking (TSN) Task Group</title>
<author>
<organization>IEEE</organization>
</author>
<date/>
</front>
</reference>
</references>
</references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgements</name>
<t> <t>
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David B The authors wish to thank <contact fullname="Pat Thaler"/>, <contact
lack, fullname="Norman Finn"/>, <contact fullname="Loa Andersson"/>, <contact
Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther fullname="David Black"/>,
, <contact fullname="Rodney Cummings"/>, <contact fullname="Ethan
George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their Grossman"/>, <contact fullname="Tal Mizrahi"/>, <contact
various contributions to this work. David Black served as fullname="David Mozes"/>, <contact fullname="Craig Gunther"/>,
<contact fullname="George Swallow"/>, <contact fullname="Yuanlong
Jiang"/>, and <contact fullname="Carlos J. Bernardos"/> for their
various contributions to this work. <contact fullname="David Black"/> se
rved as
technical advisor to the DetNet working group during the technical advisor to the DetNet working group during the
development of this document and provided many valuable development of this document and provided many valuable
comments. IESG comments were provided by Murray Kucherawy, comments. IESG comments were provided by <contact fullname="Murray Kuche
Roman Danyliw, Alvaro Retana, Benjamin Kaduk, Rob Wilton, and rawy"/>,
Erik Vyncke. <contact fullname="Roman Danyliw"/>, <contact fullname="Alvaro
Retana"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Rob
Wilton"/>, and
<contact fullname="&#201;rik Vyncke"/>.
</t> </t>
</section> </section>
<section anchor="contrib" numbered="false" toc="default">
<name>Contributors</name>
<section anchor="contrib" title="Contributors">
<t> <t>
RFC7322 limits the number of authors listed on the front page of The editor of this document wishes to thank and acknowledge the following
a draft to a maximum of 5. The editor wishes to thank and people who contributed substantially to the content of this document and
acknowledge the follow authors for contributing text to this should be considered coauthors:
draft.
</t> </t>
<figure> <artwork><![CDATA[ <contact fullname="Jouni Korhonen">
Jouni Korhonen <address>
Email: jouni.nospam@gmail.com <postal>
<street></street>
Andrew G. Malis <city></city>
Malis Consulting <region></region><code></code>
Email: agmalis@gmail.com <country></country>
]]></artwork> </postal>
</figure> <email>jouni.nospam@gmail.com</email>
</section> </address>
</contact>
</middle>
<back> <contact fullname="Andrew G. Malis">
<references title="Normative references"> <organization>Malis Consulting</organization>
<?rfc include="reference.RFC.0768"?> <address>
<?rfc include="reference.RFC.0791"?> <postal>
<?rfc include="reference.RFC.0792"?> <street></street>
<?rfc include="reference.RFC.0793"?> <city></city>
<?rfc include="reference.RFC.1812"?> <region></region><code></code>
<?rfc include="reference.RFC.2119"?> <country></country>
<?rfc include="reference.RFC.2474"?> </postal>
<?rfc include="reference.RFC.4301"?> <email>agmalis@gmail.com</email>
<?rfc include="reference.RFC.4302"?> </address>
<?rfc include="reference.RFC.4303"?> </contact>
<?rfc include="reference.RFC.7608"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8200"?>
<?rfc include="reference.RFC.8655"?>
<?rfc include="reference.I-D.ietf-detnet-data-plane-framework'?>
</references>
<references title="Informative references">
<?rfc include="reference.RFC.1122"?>
<?rfc include="reference.RFC.1192"?>
<?rfc include="reference.RFC.2475"?>
<?rfc include="reference.RFC.3290"?>
<?rfc include="reference.RFC.3473"?>
<?rfc include="reference.RFC.3670"?>
<?rfc include="reference.RFC.5120"?>
<?rfc include="reference.RFC.5777"?>
<?rfc include="reference.RFC.8504"?>
<?rfc include="reference.RFC.7551"?>
<?rfc include="reference.RFC.7657"?>
<?rfc include="reference.RFC.8201"?>
<?rfc include="reference.I-D.ietf-detnet-mpls"?>
<?rfc include="reference.I-D.ietf-detnet-dp-sol-mpls"?>
<?rfc include="reference.I-D.ietf-detnet-flow-information-model"?>
<?rfc include="reference.I-D.ietf-detnet-security"?>
<?rfc include="reference.I-D.ietf-detnet-yang"?>
<?rfc include="reference.I-D.ietf-detnet-ip-over-tsn'?>
<?rfc include="reference.I-D.ietf-detnet-ip-over-mpls'?>
<?rfc include="reference.I-D.ietf-detnet-tsn-vpn-over-mpls'?>
<reference anchor="IEEE802.1AE-2018"
target="https://ieeexplore.ieee.org/document/8585421">
<front>
<title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2018" />
</front>
</reference>
</references> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 209 change blocks. 
752 lines changed or deleted 975 lines changed or added

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