RFC 8939

Deterministic Networking (DetNet) Data Plane: IP

📅 published November 2020, from ietf

📄 RFC 8939: Deterministic Networking (DetNet) Data Plane: IP 🌸

Okay bestie, let's get into it ✨ This one is from the Internet Engineering Task Force (IETF) and it's a Standards Track doc, so this is the real deal 💅 It was written by B. Varga (editor), J. Farkas, L. Berger, D. Fedyk, and S. Bryant. Ericsson, LabN Consulting, L.L.C., and Futurewei Technologies all got a hand in it 🫶 It came out in November 2020, and it's the official ISSN: 2070-1721 🎀

It doesn't obsolete anything, and it doesn't update anything either. It just vibes on its own 🦋

The status is Internet Standards Track, which means the IETF community reached consensus on it and the IESG approved it 💜

Abstract ✨

Okay so the big idea is this 🧚 This doc describes how Deterministic Networking (DetNet) works on the data plane for IP hosts and routers that give DetNet service to IP-encapsulated data 💖 Here's the wild part: there's no new DetNet-specific encapsulation for IP flows 🙈 Instead, the stuff already in the IP-layer and higher-layer protocol headers gets reused for flow identification and DetNet service delivery. Iconic, right? 🔥

It builds on two other docs: the DetNet architecture (RFC 8655) and the data plane framework (RFC 8938) 💅

Status of This Memo ✨

This is an Internet Standards Track document 🌈

It's a product of the IETF, and it represents the consensus of the IETF community 💜 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more info on Internet Standards, check out Section 2 of RFC 7841 🎀

For the current status, errata, and how to give feedback, head to https://www.rfc-editor.org/info/rfc8939 🦋

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please review these carefully, because they describe your rights and restrictions 📜 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💅

Table of Contents 🌈

1.  Introduction
2.  Terminology
  2.1.  Terms Used in This Document
  2.2.  Abbreviations
  2.3.  Requirements Language
3.  Overview of the DetNet IP Data Plane
4.  DetNet IP Data Plane Considerations
  4.1.  End-System-Specific Considerations
  4.2.  DetNet Domain-Specific Considerations
  4.3.  Forwarding Sub-Layer Considerations
    4.3.1.  Class of Service
    4.3.2.  Quality of Service
    4.3.3.  Path Selection
  4.4.  DetNet Flow Aggregation
  4.5.  Bidirectional Traffic
5.  DetNet IP Data Plane Procedures
  5.1.  DetNet IP Flow Identification Procedures
    5.1.1.  IP Header Information
    5.1.2.  Other Protocol Header Information
  5.2.  Forwarding Procedures
  5.3.  DetNet IP Traffic Treatment Procedures
6.  Management and Control Information Summary
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🧚

Okay so Deterministic Networking (DetNet) is a service a network can offer to DetNet flows 💖 It gives those flows extremely low packet loss rates and an assured maximum end-to-end delivery latency ✨ If you want the background and concepts, the DetNet architecture [RFC8655] has you covered 🎀

This doc specifies the DetNet data plane operation for IP hosts and routers that give DetNet service to IP-encapsulated data 🦋 Again, no DetNet-specific encapsulation is defined for IP flows. Instead, the existing IP-layer and higher-layer protocol header info does the job of flow identification and DetNet service delivery 💅 The common data plane procedures and control info for all DetNet data planes live in [RFC8938] 🫶

The DetNet architecture splits the DetNet-related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer 🌸 The service sub-layer provides DetNet service protection (for example, with the Packet Replication Function (PRF) and Packet Elimination Function (PEF)) and reordering 💜 The forwarding sub-layer provides congestion protection (low loss, assured latency, and limited out-of-order delivery) 🔥 The service sub-layer usually needs extra header fields to do its job. For example, see [DetNet-MPLS] 🙈 Since no DetNet-specific fields are added for DetNet IP flows, only the forwarding sub-layer functions are supported using the DetNet IP defined here 👑 Service protection can be provided on a per-sub-network basis using technologies such as MPLS [DetNet-MPLS] and Ethernet, as specified by the IEEE 802.1 TSN (Time-Sensitive Networking) task group (called "IEEE 802.1 TSN" in this doc) 🧚 See [IEEE802.1TSNTG] ✨

Here's the roadmap 🗺️ Section 3 gives an overview of the DetNet IP data plane, and Section 4 covers the considerations for providing DetNet services through it 💖 Section 5 has the procedures for hosts and routers that support IP-based DetNet services 🎀 Section 6 sums up the info you need to identify an individual DetNet flow 🦋

2. Terminology 🌈

2.1. Terms Used in This Document 💅

This doc uses the terminology and concepts from the DetNet architecture [RFC8655], and it assumes you're already familiar with that doc and its terms 🫶

2.2. Abbreviations 🌸

The following abbreviations are used in this document:

CoS           Class of Service
DetNet        Deterministic Networking
DN            DetNet
Diffserv      Differentiated Services
DSCP          Differentiated Services Code Point
L2            Layer 2
L3            Layer 3
LSP           Label Switched Path
MPLS          Multiprotocol Label Switching
PEF           Packet Elimination Function
PREOF         Packet Replication, Elimination, and Ordering Functions
PRF           Packet Replication Function
QoS           Quality of Service
TSN           Time-Sensitive Networking.  TSN is a task group of the
              IEEE 802.1 Working Group.

2.3. Requirements Language 💜

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥

Only the capitalised versions count as requirement words, so lowercase "must" is just regular English. Don't mix them up, bestie 🙈

That's the end of part 1 of 6 🎀 Part 2 picks up with Section 3 (Overview of the DetNet IP Data Plane). Stay tuned, it's about to get spicy 💅✨

3. Overview of the DetNet IP Data Plane ✨

okay bestie, this section is basically the "how does IP even do DetNet" tour 🦋 and honestly it's giving main character energy. This document describes how IP gets used by DetNet nodes (that's hosts AND routers 💅) to identify DetNet flows and deliver a DetNet service over an IP data plane. From the data plane point of view, the vibe is an end-to-end IP model 🫶. Existing IP-layer and higher-layer header info does the heavy lifting for flow identification and service delivery. The common data plane stuff that applies to every DetNet data plane lives in [RFC8938], so go check that one too 🌸.

The DetNet IP data plane mostly uses 6-tuple-based flow identification 🔥. The "6-tuple" here is just info carried in the IP-layer and higher-layer headers, and it matches the definition in [RFC3290]. The six pieces are: destination address, source address, IP protocol, source port, destination port, and DSCP. Background on using IP headers and 5-tuples to identify flows and support Quality of Service (QoS) is in [RFC3670], and [RFC7657] is also super useful for Diffserv and tuple-based flow identification 🎀. Quick reminder: a 6-tuple is basically a 5-tuple with DSCP added on top ✨.

Now, some protocols don't have ports, so 5-tuples and 6-tuples just can't be used 💀. Examples are ICMP, IPsec, and Encapsulating Security Payload (ESP). Flow aggregates have the same problem. In those cases it's fine to use fewer fields, like a 3-tuple (2 IP addresses, IP protocol) or even a 2-tuple (all IP traffic between two IP addresses) 🧚.

The DetNet IP data plane also lets you optionally match on the IPv6 Flow Label field, as defined in [RFC8200] 🌈.

Non-DetNet and DetNet IP packets look exactly the same on the wire 👑. The fields used for flow identification are generally forwarded unmodified. That said, standard modification of the DSCP field [RFC2474] is not off the table 🍓.

DetNet flow aggregation can be turned on with wildcards, masks, lists, prefixes, and ranges 💜. IP tunnels can also be used for aggregation. When that happens, it's expected that DetNet-aware intermediate nodes will still provide DetNet service on the aggregate through resource allocation and congestion control mechanisms 🫶.

Want the specific procedures a DetNet node has to implement? Those are in Section 5 🎀. And the DetNet Controller Plane, defined in [RFC8655], is the one that gives each node the info it needs to identify and handle each DetNet flow 👑.

DetNet IP Relay Relay DetNet IP End System Node Node End System

+----------+ +----------+

Appl.<------------ End-to-End Service ----------->Appl.

+----------+ ............ ........... +----------+

Service<-: Service :-- DetNet flow --: Service :->Service

+----------+ +----------+ +----------+ +----------+

ForwardingForwardingForwardingForwarding

+--------.-+ +-.------.-+ +-.---.----+ +-------.--+ : Link : \ ,-----. / \ ,-----. / +......+ +----[ Sub- ]----+ +-[ Sub- ]-+ [Network] [Network] -----' -----'

<--------------------- DetNet IP --------------------->

Figure 1: A Simple DetNet-Enabled IP Network

Figure 1 shows a DetNet-enabled IP network 🦋. DetNet-enabled end systems send out IP-encapsulated traffic, and inside the DetNet domain that traffic gets identified as DetNet flows based on IP header info. Relay nodes get the forwarding requirements of each DetNet flow and make sure node, interface, and sub-network resources are allocated so the DetNet service requirements are met 💖. The dotted line around the Service component of the Relay Nodes is there to show that transit routers are DetNet service aware but don't do any DetNet service sub-layer function, e.g., PREOF 🙈.

Note: The sub-network can be a TSN, an MPLS network, or any other network technology that can carry DetNet IP traffic. 💅

IP Edge Edge IP End System Node Node End System

+----------+ +.........+ +.........+ +----------+

Appl.<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->Appl.

+----------+ +.........+ +.........+ +----------+

IP<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->IP

+----------+ +---+ +---+ +---+ +---+ +----------+

ForwardingFwdFwdFwdFwdForwarding

+--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ : Link : \ ,-----. / / ,-----. \ +.......+ +----[ Sub- ]----+ +--[ Sub- ]--+ [network] [network] -----' -----'

<--- IP ---><------ DetNet IP ------><--- IP --->

Figure 2: Non-DetNet-Aware IP End Systems with DetNet IP Domain

Figure 2 is a twist on Figure 1 where the end systems are NOT DetNet aware 🥺. Edge nodes sit at the edge of the DetNet domain and act as DetNet service proxies for the apps, starting and ending DetNet service for each app's IP flows 🧚. The existing header info, or an approach like the one in Section 4.4, can be used for DetNet flow identification ✨.

Also, Figures 1 and 2 can be squished together, so DetNet-aware IP end systems can talk over a DetNet IP network with plain IP end systems 🫶.

Since non-DetNet and DetNet IP packets have the same header format on the wire, the only real difference from the data plane's perspective is the flow-associated DetNet info on each DetNet node. That info defines the flow's characteristics and the forwarding behavior it needs 👑. As the figure shows, edge nodes run a Service Proxy function that "associates" one or more IP flows with the right DetNet flow-specific info, so the flow gets the proper treatment inside the domain 💜.

Note: The operation of IEEE 802.1 TSN end systems over DetNet-enabled IP networks is not described in this document. TSN over MPLS is described in [DetNet-TSN-over-MPLS]. 🎀

4. DetNet IP Data Plane Considerations 💅

This section is all about the considerations for giving DetNet service to flows identified by their header info 🦋.

4.1. End-System-Specific Considerations 🫶

Data flows that need DetNet service get generated and terminated on end systems 🌸. This document only deals with IP end systems. The protocols an IP end system uses are specific to each application, and end systems peer with other end systems 💜. Because DetNet uses 6-tuple IP flow identification, DetNet has to be aware not just of the IP header format but also of the next protocol value carried in the IP packet (see Section 5.1.1.3) 🧚.

For DetNet-unaware IP end systems, service-level proxy functions are needed inside the DetNet domain 🥺.

When IP end systems ARE DetNet aware, no application-level or service-level proxy functions are needed inside the DetNet domain ✨. End systems need to make sure DetNet service requirements are met when they process packets belonging to a DetNet flow 👑. When sending, that means packets get shaped properly on transmission and get the right traffic treatment on the connected sub-network; see Sections 4.3.2 and 4.2 for more details 🍓. When receiving, it means the node has the local resources it needs, e.g., buffers, to receive and process that DetNet flow's packets 💖.

Another big one for DetNet-aware end systems is avoiding IP fragmentation 🚨. Full 6-tuple flow identification isn't possible on IP fragments, because fragments don't carry the transport headers or their port info 💀. So applications and/or end systems should use an IP packet size that avoids fragmentation inside the network when sending DetNet flows 🙈. The maximum size can be learned via Path MTU Discovery [RFC1191] [RFC8201] or via the Controller Plane 🌈. Heads up: Path MTU Discovery relies on ICMP, which may not take the same path as an individual DetNet flow 👀.

To get the most out of existing mechanisms, DetNet-aware applications and end systems SHOULD NOT mix DetNet and non-DetNet traffic within a single 5-tuple 💜✨

4.2. DetNet Domain-Specific Considerations ✨

Okay bestie, the golden rule 👑 is that a DetNet IP domain needs to be able to forward any DetNet flow identified by the IP 6-tuple. If it couldn't, that would limit how many 6-tuple flow ID combinations the end systems could actually use 🙈. Practically speaking, every node along the end-to-end path of a DetNet flow needs to agree on which fields are used for flow identification. If they don't agree, you can get flows interfering with other flows, and the traffic treatment a service is supposed to get just... doesn't show up 💀.

From a connection-type perspective, there are two scenarios:

  1. DN attached: the end system is directly connected to an edge node, or the end system is behind a sub-network. (See ES1 and ES2 in Figure 3.)
  2. DN integrated: the end system is part of the DetNet domain. (See ES3 in Figure 3.)

L3 (IP) end systems can use any of these connection types 🦋. A DetNet domain lets any end systems talk to each other as long as they use the same encapsulation format, no matter their connection type or DetNet capability. DN-attached end systems don't know anything about the DetNet domain or its encapsulation format, so it's giving mystery 🧚. Check out Figure 3 for L3 end system connection examples.

                                               ____+----+
                       +----+        _____    /    | ES3|
                       | ES1|____   /     \__/     +----+___
                       +----+    \ /                        \
                                  +                          |
                          ____     \                        _/
            +----+     __/    \     +__  DetNet IP domain  /
            | ES2|____/  L2/L3 |___/   \         __     __/
            +----+    \_______/         \_______/  \___/

Figure 3: Connection Types of L3 End Systems

Inside a DetNet domain, the DetNet-enabled IP routers are connected by links and sub-networks so that DetNet flows can be delivered end to end 🌸. From a DetNet architecture point of view, these routers are DetNet relays, because they have to be DetNet service aware. These routers identify DetNet flows based on the IP 6-tuple and make sure the traffic treatment the DetNet service requires is provided on both the node and any attached sub-network. Main character energy 💅.

This solution gives you DetNet functions end to end, but it does that on a per-link and per-sub-network basis 🎀. Congestion protection, latency control, and resource allocation (queuing, policing, shaping) are supported through the underlying link- or sub-network-specific mechanisms. Service protection (PRF and PEF), though, is not provided end to end at the DetNet layer. Instead, service protection can be provided on a per-link (underlying L2 link) and per-sub-network basis.

The DetNet service flow gets mapped to the link- or sub-network-specific resources using an underlying system-specific means. That means each DetNet-aware node on the path looks into the forwarded DetNet service flow packet and uses, for example, a 6-tuple to figure out the mapping it needs inside the node 🔍.

As noted earlier, service protection has to be implemented within each link or sub-network independently, using the domain-specific mechanisms. The reason is that there isn't any unified end-to-end sequencing information the intermediate nodes could use 😭. So service protection (if enabled) can't be provided end to end, only within sub-networks. Figure 4 shows this for a scenario with three sub-networks, where each sub-network can provide service protection between its borders. "R" and "E" denote replication and elimination points within the sub-network ✨.

     <-------------------- DetNet IP ------------------------>
                                 ______
                       ____     /      \__
            ____      /     \__/          \___   ______
+----+   __/    +====+                       +==+      \     +----+
|src |__/ Sub-N1 )   |                       |  \ Sub-N3\____| dst|
+----+  \_______/    \      Sub-network 2    |   \______/    +----+
                      \_                    _/
                        \         __     __/
                         \_______/  \___/


          +---+        +---------E--------+      +-----+
+----+    |   |        |         |        |      |     |      +----+
|src |----R   E--------R     +---+        E------R     E------+ dst|
+----+    |   |        |     |            |      |     |      +----+
          +---+        +-----R------------+      +-----+

Figure 4: Replication and Elimination in Sub-networks for DetNet IP Networks

If you want end-to-end service protection, it can be implemented, for example, by the DetNet end systems using Layer 4 (L4) transport protocols or application protocols 🫶. Just know that these protocols are out of scope for this document.

Also, not mixing DetNet and non-DetNet traffic within a single 5-tuple (like we talked about above) lets you use simpler 5-tuple filters at the edges of a DetNet network. Those filters can then stop non-congestion-responsive DetNet traffic from escaping the DetNet domain 🚧.

4.3. Forwarding Sub-Layer Considerations ✨

4.3.1. Class of Service

Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is provided using the standard DSCP field [RFC2474] and related mechanisms 💖.

There's one more thing for DetNet nodes that support CoS services: they must make sure the CoS service classes don't impact the congestion protection and latency control mechanisms used to provide DetNet QoS. This is kind of like the requirement for MPLS Label Switching Routers (LSRs), where CoS LSPs can't impact the resources allocated to TE LSPs [RFC3473] 🍓.

4.3.2. Quality of Service

Quality of Service (QoS) for DetNet service flows carried in IP must be provided locally by the DetNet-aware hosts and routers that support DetNet flows 🔥. That support leans on the underlying network layer, such as 802.1 TSN. The node-internal traffic control mechanisms used to deliver QoS for IP-encapsulated DetNet flows are outside the scope of this document. From an encapsulation perspective, the 6-tuple (the typical 5-tuple enhanced with the DSCP), and optionally the flow label, uniquely identifies a DetNet IP flow 🌈.

Packets that count as part of a DetNet IP flow but never went through a completed reservation can mess up the QoS for properly reserved flows 😤. They do this by grabbing resources that were allocated to the reserved flows. So the network nodes of a DetNet network MUST ensure that no DetNet-allocated resource, e.g., queue or shaper, is used by such flows. There are several methods an implementation may use to protect service delivery to reserved DetNet flows, including but not limited to:

  • Treating packets associated with an incomplete reservation as non-DetNet traffic.
  • Discarding packets associated with an incomplete reservation.
  • Re-marking packets associated with an incomplete reservation. Re-marking can be accomplished by changing the value of the DSCP field to a value that results in the packet no longer matching any other reserved DetNet IP flow.

4.3.3. Path Selection

Path selection algorithms and mechanisms are out of scope for the DetNet data plane definition 🗺️. Still, it's important to highlight how DetNet IP flow identification affects path selection and next hops. As mentioned above, the DetNet IP data plane identifies flows using the 6-tuple header information as well as the optional (flow label) header field. DetNet generally allows both flow-specific traffic treatment and flow-specific next hops, which is so iconic ✨.

In non-DetNet IP forwarding, it's generally assumed that the same series of next hops (the same path) will be used for a particular 5-tuple or, in some cases (e.g., [RFC5120]), for a particular 6-tuple. Using different next hops for different 5-tuples doesn't take any special consideration for DetNet-aware applications 💜.

Care should be taken when using different next hops for the same 5-tuple. As discussed in [RFC7657], unexpected behavior can happen when a single 5-tuple application flow gets reordered because it's split across multiple next hops 🙃. Understanding the application and transport protocol impact of using different next hops for the same 5-tuple is required. Again, this only indirectly impacts path selection for DetNet flows and this document.

4.4. DetNet Flow Aggregation

As described in [RFC8938], being able to aggregate individual flows and their associated resource control into a larger aggregate is an important technique for scaling, because it reduces the state per hop 📦. DetNet IP data plane aggregation can happen within a single node, when that node keeps state about both the aggregated and individual flows. It can also happen between nodes, when one node keeps state about only flow aggregates while the other node keeps state on all or a portion of the component flows. Either way, the management or control function that provisions the aggregate flows must make sure enough resources are allocated and configured to provide the combined service requirements of the individual flows. Since DetNet cares about latency and jitter, bandwidth isn't the only thing to think about 🫠.

From a single node perspective, aggregating IP flows affects DetNet IP data plane flow identification and resource allocation. As discussed above, IP flow identification uses the IP 6-tuple. DetNet IP flows can be aggregated using any of the 6-tuple fields and, optionally, the flow label too. Prefixes, wildcards, lists, and value ranges let a DetNet node identify aggregate DetNet flows 🧩. From a resource allocation perspective, DetNet nodes ought to provide service to an aggregate rather than on a component flow basis.

The DetNet Controller Plane is responsible for properly provisioning these aggregation mechanisms 🎀. That includes making sure aggregated flows have compatible (e.g., the same or very similar) QoS and/or CoS characteristics; see Section 4.3.2. It also includes making sure the aggregate satisfies the per-component-flow service requirements; see Section 5.3.

The DetNet Controller Plane MUST ensure that non-congestion-responsive DetNet traffic is not forwarded outside a DetNet domain 🚫.

4.5. Bidirectional Traffic

The DetNet IP data plane has to support bidirectional DetNet flows, but there are no special bidirectional features inside the data plane 🔄. The special case of co-routed bidirectional DetNet flows only shows up at the management and control plane levels, with no specific support or knowledge in the DetNet data plane. Fate sharing and associated or co-routed bidirectional flows can be managed at the control level 🤝.

Control and management mechanisms need to support bidirectional flows, but specifying those mechanisms is out of scope for this document. An example control plane solution for MPLS can be found in [RFC7551] 💅.

5. DetNet IP Data Plane Procedures ✨

okay so this section is the procedures part, and it's split into three vibes: flow identification (matching packets to a DetNet flow based on IP and higher-layer headers, aka "traffic classification" 🕵️‍♀️), forwarding (picking the next hop and actually delivering the packet 📬), and traffic treatment (giving an identified flow the DetNet service it needs 💅).

It also touches on the control and management side, because DetNet flows need those systems to run properly 🎀 This section lists a bunch of info elements that the management and control interfaces of a DetNet node have to support. The actual mechanism for that is out of scope here, but there's a summary of those requirements later on. The summary doesn't use conformance language because it's meant for future stuff like YANG models [DetNet-YANG] 🦋

5.1. DetNet IP Flow Identification Procedures

IP-layer and higher-layer protocol header info is what gets used to identify DetNet flows 🔍 Every DetNet implementation that supports this document MUST identify individual DetNet flows using the set of info in this section. More flow identification rules, like for other higher-layer protocols, might show up later 🌸

The config and control info used to identify one DetNet flow MUST be ordered by the implementation 📋 It MUST support a fixed order when identifying flows, and it MUST identify a DetNet flow by the first set of matching flow info it finds. Order matters, bestie!! 👑

This document's implementations MUST support DetNet flow identification whenever they're acting as a DetNet end system, a relay node, or an edge node 🧚

5.1.1. IP Header Information

Implementations of this document MUST support DetNet flow identification based on IP header info 💖 The IPv4 header is defined in [RFC0791], and the IPv6 header is defined in [RFC8200] ✨

5.1.1.1. Source Address Field

Implementations of this document MUST support DetNet flow identification based on the Source Address field of an IP packet 🫶 They SHOULD support longest prefix matching for this field (see [RFC1812] and [RFC7608]). Also, a prefix length of zero (0) basically means the field gets ignored 🙈

5.1.1.2. Destination Address Field

Implementations of this document MUST support DetNet flow identification based on the Destination Address field of an IP packet 🎯 They SHOULD support longest prefix matching for this field too (see [RFC1812] and [RFC7608]). Same deal here: a prefix length of zero (0) effectively means the field is ignored 🌈

|  Note: Any IP address value is allowed, including an IP
|  multicast destination address.

5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields

Implementations of this document MUST support DetNet flow identification based on the IPv4 Protocol field when processing IPv4 packets, and the IPv6 Next Header field when processing IPv6 packets 🧩 That includes the next protocol values defined in Section 5.1.2, plus any other value, zero included 💜 They SHOULD allow these fields to be ignored for a specific DetNet flow.

5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields

These fields support differentiated services [RFC2474] [RFC2475] 💅 Implementations of this document MUST support DetNet flow identification based on the DSCP field in the IPv4 Type of Service field when processing IPv4 packets, and the DSCP field in the IPv6 Traffic Class field when processing IPv6 packets. They MUST also support list-based matching of DSCP values, where the list is made up of possible field values that should be considered when identifying a specific DetNet flow 📝 They SHOULD allow this field to be ignored for a specific DetNet flow.

5.1.1.5. IPv6 Flow Label Field

Implementations of this document SHOULD support identifying DetNet flows based on the IPv6 Flow Label field 🦋 If they do support matching on this field, they MUST allow it to be ignored for a specific DetNet flow. When this field is used to identify a specific DetNet flow, implementations MAY leave out the IPv6 Next Header field and next header info as part of the identification 🌸

5.1.2. Other Protocol Header Information

Implementations of this document MUST support DetNet flow identification based on the header info in this section 🎀 Support for TCP, UDP, ICMP, and IPsec flows is defined here. Future documents are expected to define support for other protocols 🔮

5.1.2.1. TCP and UDP

DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is achieved using the Source and Destination Port fields in each protocol's header 💕 These fields share a common format and the same DetNet flow identification procedures, so they're kind of twins 👯‍♀️

The rules in this section only apply when the IPv4 Protocol or IPv6 Next Header field contains the IANA-defined value for UDP or TCP 🙌

5.1.2.1.1. Source Port Field

Implementations of this document MUST support DetNet flow identification based on the Source Port field of a TCP or UDP packet 🍓 They MUST support flow identification based on a particular value in the field, i.e., an exact value. They SHOULD support range-based port matching. Implementations MUST also allow the field to be ignored for a specific DetNet flow ✨

5.1.2.1.2. Destination Port Field

Implementations of this document MUST support DetNet flow identification based on the Destination Port field of a TCP or UDP packet 🎯 They MUST support flow identification based on a particular value in the field, i.e., an exact value. They SHOULD support range-based port matching. Implementations MUST also allow the field to be ignored for a specific DetNet flow 💜

5.1.2.2. ICMP

DetNet flow identification for ICMP [RFC0792] is achieved based on the protocol number in the IP header 🧚‍♀️ Note that the ICMP type is NOT included in the flow definition, so don't go looking for it there 🙈

5.1.2.3. IPsec AH and ESP

IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] share a common format for the Security Parameters Index (SPI) field 🔐 Implementations MUST support flow identification based on a particular value in the field, i.e., an exact value. They SHOULD also allow the field to be ignored for a specific DetNet flow.

The rules in this section only apply when the IPv4 Protocol or IPv6 Next Header field contains the IANA-defined value for AH or ESP 💖

5.2. Forwarding Procedures

General requirements for IP nodes are defined in [RFC1122], [RFC1812], and [RFC8504], and this document doesn't modify them 📚 The typical next-hop selection process is impacted by DetNet, though 👀 Specifically, implementations of this document SHALL use management and control info to select the one or more outgoing interfaces and next hops used for a packet associated with a DetNet flow. Specific management and control info will be defined in future documents, e.g., [DetNet-YANG] 🌟

Using multiple paths or links (like ECMP) to support a single DetNet flow is NOT RECOMMENDED 🚫 ECMP MAY be used for non-DetNet flows within a DetNet domain, though 🦋

All of this implies that management and control functions will be defined to support this requirement, e.g., see [DetNet-YANG] 🫶

5.3. DetNet IP Traffic Treatment Procedures

Implementations of this document must ensure that a DetNet flow gets the traffic treatment that's provisioned for it, either through configuration or the Controller Plane, e.g., via [DetNet-YANG] 👑 General info on DetNet service can be found in [DetNet-Flow-Info] 📖 Typical mechanisms for giving different flows different treatment include allocating system resources (like queues and buffers) and provisioning related parameters (like shaping and policing) 🛠️ Support can also come from an underlying network technology, such as MPLS [DetNet-IP-over-MPLS] or IEEE 802.1 TSN [DetNet-IP-over-TSN] 🌈 Mechanisms other than the ones used in the TSN case are outside the scope of this document 🙌

6. Management and Control Information Summary

Here's the lowdown on the info you need to identify individual and aggregated DetNet flows 📋✨

  • IPv4 and IPv6 Source Address field.
  • IPv4 and IPv6 source address prefix length, where a zero (0) value effectively means that the Source Address field is ignored.
  • IPv4 and IPv6 Destination Address field.
  • IPv4 and IPv6 destination address prefix length, where a zero (0) value effectively means that the Destination Address field is ignored.
  • IPv4 Protocol field. A limited set of values is allowed, and being able to ignore this field is desirable.
  • IPv6 Next Header field. A limited set of values is allowed, and being able to ignore this field is desirable.
  • For the IPv4 Type of Service and IPv6 Traffic Class fields:
    • Whether or not the DSCP field is used in flow identification. Using the DSCP field for flow identification is optional.
    • If the DSCP field is used to identify a flow, then the flow identification info (for that flow) includes a list of DSCPs used by that flow.
  • IPv6 Flow Label field. This field can be optionally used for matching. When used, this field can be used instead of matching against the Next Header field.
  • TCP and UDP Source Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
  • TCP and UDP Destination Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
  • IPsec Header SPI field. Exact matching is required. Support for wildcard matching is recommended.
  • For end systems, an optional maximum IP packet size that should be used for that outgoing DetNet IP flow.

This info MUST be provisioned per DetNet flow via configuration, e.g., via the Controller Plane or the management plane 🎀

An implementation MUST support ordering of the set of info used to identify an individual DetNet flow 💅 For example, this can be used to give a DetNet service to one specific UDP flow (with unique Source and Destination Port values) while giving a different service to the aggregate of all the other flows with that same UDP Destination Port value 🦋

It's the DetNet Controller Plane's responsibility to properly provision both the flow identification info and the flow-specific resources needed to give each flow the traffic treatment it needs to meet its service requirements 👑 This applies to both aggregated and individual flows 🫶

7. Security Considerations 🔐✨

Okay bestie, security time, and it's serious but still iconic 💅. Detailed security considerations for DetNet are cataloged in [DetNet-Security], and the more general ones live in [RFC8655]. This section only looks at the security stuff that's specific to the DetNet IP data plane 🦋.

The security aspects that are unique to DetNet are the ones that protect the special QoS promises DetNet makes, mainly delivering flows with extremely low packet loss and bounded end-to-end latency 🍓. Honestly, those promises might not be doable against a super capable attacker, like the one in the Internet Threat Model of BCP 72 [RFC3552], who can drop or delay any or all traffic whenever they want 😭. So to make these considerations actually useful, we look at a somewhat weaker attacker. This one doesn't control the physical links in the DetNet domain, but might be able to control a network node inside the DetNet domain's boundary 🫶.

The main goal for the DetNet data plane is keeping the data intact and making sure the DetNet service actually gets delivered across the DetNet network 🔥. There are no DetNet-specific fields in the DetNet IP data plane, so whatever the underlying technology offers is what protects the integrity and confidentiality of application flows 💜. For example, encryption can be used, like the kind IPsec [RFC4301] provides for IP flows, or the kind an underlying sub-network provides with MACsec [IEEE802.1AE-2018] for IP over Ethernet (Layer 2) flows 🔒.

From a data plane point of view, this document doesn't add or change any header information 🎀.

On the management and control level, DetNet flows are identified on a per-flow basis. That can give Controller Plane attackers extra info about the data flows, compared to Controller Planes that don't do per-flow identification 👀. This is an inherent part of DetNet, and it has security implications you should think about when deciding whether DetNet fits a particular use case 🧚.

To keep the DetNet service available with no interruptions, you can plan ahead for DoS attacks and delay attacks 🛡️. To guard against DoS attacks, excess traffic from malicious or malfunctioning devices can be prevented or reduced, for example with existing mechanisms like policing and shaping applied at the input of a DetNet domain or inside an edge IEEE 802.1 TSN domain 🌈. To stop DetNet packets from getting delayed by something outside the DetNet domain, DetNet technology definitions can allow for mitigating man-in-the-middle attacks, for example through authentication and authorization of devices inside the DetNet domain 💀.

8. IANA Considerations

Good news, this one's short and sweet: this document has no IANA actions 🌸.

9. References

9.1. Normative References

9.2. Informative References ✨

okay bestie, here are the informative refs 📚 these aren't strictly required to implement the spec, but they're the docs the DetNet crew was building on, so they're good to know about 🧚

   [DetNet-Flow-Info]
              Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
              Fedyk, "DetNet Flow Information Model", Work in Progress,
              Internet-Draft, draft-ietf-detnet-flow-information-model-
              11, 21 October 2020, <https://tools.ietf.org/html/draft-
              ietf-detnet-flow-information-model-11>.

   [DetNet-IP-over-MPLS]
              Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J.
              Korhonen, "DetNet Data Plane: IP over MPLS", Work in
              Progress, Internet-Draft, draft-ietf-detnet-ip-over-mpls-
              09, 11 October 2020, <https://tools.ietf.org/html/draft-
              ietf-detnet-ip-over-mpls-09>.

   [DetNet-IP-over-TSN]
              Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
              "DetNet Data Plane: IP over IEEE 802.1 Time Sensitive
              Networking (TSN)", Work in Progress, Internet-Draft,
              draft-ietf-detnet-ip-over-tsn-04, 2 November 2020,
              <https://tools.ietf.org/html/draft-ietf-detnet-ip-over-
              tsn-04>.

   [DetNet-MPLS]
              Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
              S., and J. Korhonen, "DetNet Data Plane: MPLS", Work in
              Progress, Internet-Draft, draft-ietf-detnet-mpls-13, 11
              October 2020,
              <https://tools.ietf.org/html/draft-ietf-detnet-mpls-13>.

   [DetNet-Security]
              Grossman, E., Ed., Mizrahi, T., and A. Hacker,
              "Deterministic Networking (DetNet) Security
              Considerations", Work in Progress, Internet-Draft, draft-
              ietf-detnet-security-12, 2 October 2020,
              <https://tools.ietf.org/html/draft-ietf-detnet-security-
              12>.

   [DetNet-TSN-over-MPLS]
              Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D.
              Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive
              Networking over MPLS", Work in Progress, Internet-Draft,
              draft-ietf-detnet-tsn-vpn-over-mpls-04, 2 November 2020,
              <https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-
              over-mpls-04>.

   [DetNet-YANG]
              Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and
              Z. Li, "Deterministic Networking (DetNet) Configuration
              YANG Model", Work in Progress, Internet-Draft, draft-ietf-
              detnet-yang-09, 16 November 2020,
              <https://tools.ietf.org/html/draft-ietf-detnet-yang-09>.

   [IEEE802.1AE-2018]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks-Media Access Control (MAC) Security", IEEE
              802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
              2018, <https://ieeexplore.ieee.org/document/8585421>.

   [IEEE802.1TSNTG]
              IEEE, "Time-Sensitive Networking (TSN) Task Group",
              <https://1.ieee802.org/tsn/>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990,
              <https://www.rfc-editor.org/info/rfc1191>.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

   [RFC3290]  Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
              Informal Management Model for Diffserv Routers", RFC 3290,
              DOI 10.17487/RFC3290, May 2002,
              <https://www.rfc-editor.org/info/rfc3290>.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
              DOI 10.17487/RFC3473, January 2003,
              <https://www.rfc-editor.org/info/rfc3473>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC3670]  Moore, B., Durham, D., Strassner, J., Westerinen, A., and
              W. Weiss, "Information Model for Describing Network Device
              QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670,
              January 2004, <https://www.rfc-editor.org/info/rfc3670>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC5777]  Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
              Ed., and A. Lior, "Traffic Classification and Quality of
              Service (QoS) Attributes for Diameter", RFC 5777,
              DOI 10.17487/RFC5777, February 2010,
              <https://www.rfc-editor.org/info/rfc5777>.

   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
              Extensions for Associated Bidirectional Label Switched
              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
              <https://www.rfc-editor.org/info/rfc7551>.

   [RFC7657]  Black, D., Ed. and P. Jones, "Differentiated Services
              (Diffserv) and Real-Time Communication", RFC 7657,
              DOI 10.17487/RFC7657, November 2015,
              <https://www.rfc-editor.org/info/rfc7657>.

   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
              DOI 10.17487/RFC8201, July 2017,
              <https://www.rfc-editor.org/info/rfc8201>.

   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
              January 2019, <https://www.rfc-editor.org/info/rfc8504>.

Acknowledgements ✨

big thank-yous 🫶 to Pat Thaler, Norman Finn, Loa Andersson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, and Carlos J. Bernardos for all their different contributions to this work 💖

David Black was the technical advisor to the DetNet working group while this document was being developed, and he gave us lots of really valuable feedback 🙌

IESG comments came from Murray Kucherawy, Roman Danyliw, Alvaro Retana, Benjamin Kaduk, Rob Wilton, and Érik Vyncke 👑

Contributors ✨

the editor wants to shout out the people who contributed a ton to the content of this document and should be treated as coauthors 💅

  • Jouni Korhonen Email: jouni.nospam@gmail.com
  • Andrew G. Malis Malis Consulting Email: agmalis@gmail.com

Authors' Addresses ✨

and here are the authors, with where to find them 🦋

   Balázs Varga (editor)
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary

   Email: balazs.a.varga@ericsson.com


   János Farkas
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary

   Email: janos.farkas@ericsson.com


   Lou Berger
   LabN Consulting, L.L.C.

   Email: lberger@labn.net


   Don Fedyk
   LabN Consulting, L.L.C.

   Email: dfedyk@labn.net


   Stewart Bryant
   Futurewei Technologies

   Email: sb@stewartbryant.com
📦 where this page comes from