RFC 9016

Flow and Service Information Model for Deterministic Networking (DetNet)

📅 published March 2021, from ietf

RFC 9016 📚💖 Flow and Service Information Model for Deterministic Networking (DetNet) ✨

Okay bestie, let's get into it 🫶 This is RFC 9016, and it's an Informational doc (so it's not a Standards Track spec, just published for info 🌸). It came out in March 2021 and it's from the IETF, with the ISSN 2070-1721 🎀.

The authors are B. Varga and J. Farkas from Ericsson, R. Cummings from National Instruments, Y. Jiang from Huawei, and D. Fedyk from LabN Consulting 💅. This RFC doesn't obsolete anything and doesn't update anything, so it's standing on its own 🦋.

The whole point is the flow and service information model for DetNet 🧚. It's defined for both the IP and MPLS data planes, and that's the abstract in a nutshell ✨.

Status of This Memo 📝

Not a Standards Track spec, it's just published for info 💅. It's a product of the IETF, reflects the consensus of the IETF community, got public review, and was approved for publication by the IESG 🌈. Not every IESG-approved doc is a candidate for an Internet Standard, see Section 2 of RFC 7841 💀.

You can check the current status, errata, and where to send feedback at https://www.rfc-editor.org/info/rfc9016 🔥.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date. Please read those carefully because they spell out your rights and restrictions 🙈. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 🫶.

Table of Contents 🗺️

1.  Introduction
  1.1.  Goals
  1.2.  Non-Goals
2.  Terminology
  2.1.  Terms Used in This Document
  2.2.  Abbreviations
  2.3.  Naming Conventions
3.  DetNet Domain and Its Modeling
  3.1.  DetNet Service Overview
  3.2.  Reference Points Used in Modeling
  3.3.  Information Elements
4.  App-Flow-Related Parameters
  4.1.  App-Flow Characteristics
  4.2.  App-Flow Requirements
5.  DetNet Flow-Related Parameters
  5.1.  Management ID of the DetNet Flow
  5.2.  Payload Type of the DetNet Flow
  5.3.  Format of the DetNet Flow
  5.4.  Identification and Specification of DetNet Flows
    5.4.1.  DetNet MPLS Flow Identification and Specification
    5.4.2.  DetNet IP Flow Identification and Specification
  5.5.  Traffic Specification of the DetNet Flow
  5.6.  Endpoints of the DetNet Flow
  5.7.  Rank of the DetNet Flow
  5.8.  Status of the DetNet Flow
  5.9.  Requirements of the DetNet Flow
    5.9.1.  Minimum Bandwidth of the DetNet Flow
    5.9.2.  Maximum Latency of the DetNet Flow
    5.9.3.  Maximum Latency Variation of the DetNet Flow
    5.9.4.  Maximum Loss of the DetNet Flow
    5.9.5.  Maximum Consecutive Loss of the DetNet Flow
    5.9.6.  Maximum Misordering Tolerance of the DetNet Flow
  5.10. BiDir Requirement of the DetNet Flow
6.  DetNet Service-Related Parameters
  6.1.  Management ID of the DetNet Service
  6.2.  Delivery Type of the DetNet Service
  6.3.  Delivery Profile of the DetNet Service
    6.3.1.  Minimum Bandwidth of the DetNet Service
    6.3.2.  Maximum Latency of the DetNet Service
    6.3.3.  Maximum Latency Variation of the DetNet Service
    6.3.4.  Maximum Loss of the DetNet Service
    6.3.5.  Maximum Consecutive Loss of the DetNet Service
    6.3.6.  Maximum Misordering Tolerance of the DetNet Service
  6.4.  Connectivity Type of the DetNet Service
  6.5.  BiDir Requirement of the DetNet Service
  6.6.  Rank of the DetNet Service
  6.7.  Status of the DetNet Service
7.  Flow-Specific Operations
  7.1.  Join Operation
  7.2.  Leave Operation
  7.3.  Modify Operation
8.  Summary
9.  IANA Considerations
10. Security Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Authors' Addresses

1. Introduction 🌟

1.1. Goals 🎯

1.2. Non-Goals 🙅‍♀️

Here's what's up with part 1 💕. DetNet is all about carrying specified unicast or multicast flows for real-time apps with extremely low packet loss and assured max end-to-end latency 😭🔥. Background lives in [RFC8655] ✨.

This doc describes the DetNet flow and service information model 🧚. [RFC3444] explains the rationale behind information models in general 📚. Operators and users use these models to understand DetNet services, and implementors use them as a guide to the functionality DetNet services need 💅.

The DetNet architecture splits the data plane functions into two sub-layers 🦋. The service sub-layer handles DetNet service protection and reordering. The forwarding sub-layer does resource allocation (to keep loss low, latency assured, and out-of-order delivery limited) and leans on traffic engineering mechanisms 🌸.

DetNet service runs over IP or MPLS, and DetNet is currently defined for IP and MPLS networks, see Figure 1, a reprint of Figure 2 from [RFC8938] 🫶. IEEE 802.1 Time-Sensitive Networking (TSN) runs over Ethernet and is defined over Ethernet networks 🌈. A DetNet flow carries one or more application-level flows (App-flows) as payload 💜. App-flows can be Ethernet, MPLS, or IP flows, and which one it is changes which header fields you use to identify a flow 🙈. DetNet flows are identified by the DetNet encapsulation of the App-flow(s), like MPLS labels or IP 6-tuples 🎀. Sometimes an App-flow and a DetNet flow look the same on the wire, like a Layer 3 (L3) App-flow over a DetNet IP network 👑.

                                             +-----+
                                             | TSN |
                        +-------+          +-+-----+-+
                        | DN IP |          | DN MPLS |
                     +--+--+----+----+   +-+---+-----+-+
                     | TSN | DN MPLS |   | TSN | DN IP |
                     +-----+---------+   +-----+-------+

       Figure 1: DetNet Service Examples as per Data Plane Framework

As Figure 1 shows, and as [RFC8938] describes, a DetNet flow can be treated as an App-flow, for example at DetNet flow aggregation or in a sub-network that interconnects DetNet nodes 🦋✨.

The flow and service info model in this doc packs both DetNet-flow and App-flow-specific info together in one integrated place 💖.

In any given network scenario, you can tell apart three info models 🧁:

  • Flow information models describe the characteristics of data flows 🌷. They detail every relevant aspect of a flow the network needs to support it properly between the source and the destination(s) 💅.
  • Service information models describe the characteristics of services provided for data flows over a network 💎. They can be treated as info models that are independent of the network operator 🫶.
  • Configuration information models describe, in detail, the settings needed on network nodes to give a data flow proper service 🔧.

Service and flow info models are used between the user and the network operator 🤝. Configuration info models are used between the management/control plane entity of the network and the network nodes 🛰️. Check out Figure 2 for the picture 📸.

          User                  Network Operator
                  flow/service
           /\      info model    +---+
          /  \ <---------------> | X |    management/control
          ----                   +-+-+       plane entity
                                   ^
                                   |   configuration
                                   |     info model
                            +------------+
                            v      |     |
                           +-+     |     v  network
                           +-+     v    +-+  nodes
                                  +-+   +-+
                                  +-+

     Figure 2: Usage of Information Models (Flow, Service, and
                           Configuration)

The DetNet flow and service info model is based on [RFC8655] and on the data model concept specified by [IEEE8021Qcc] 🌸. Besides the TSN data model, [IEEE8021Qcc] also specifies configuration of TSN features, like traffic scheduling specified by [IEEE8021Qbv] 🎀. The common architecture and flow info model keep configured features consistent in certain deployments, like when the network serving the DetNet service has both L3 and L2 segments 🧚.

1.1. Goals 🎯

Per the DetNet WG Charter [IETFDetNet], the DetNet WG works with IEEE 802.1 TSN to define one common architecture for both Layers 2 and 3 💜. That's super beneficial for a bunch of reasons, like simplifying implementations and keeping things consistent across diverse networks 🌈. The flow and service info models are aligned for those same reasons ✨. So the DetNet flow and service info models in this doc are based on [IEEE8021Qcc], which is an amendment to [IEEE8021Q] 💖.

This doc specifies flow and service info models only 🫶.

1.2. Non-Goals 🙅‍♀️

This doc does not specify flow data models or DetNet configuration 🙈. That's why its goals differ from [IEEE8021Qcc], which also specifies the TSN data model and configuration of certain TSN features 💅.

The DetNet-specific YANG data model is described in [DETNET-YANG] 🦋.

2. Terminology 📖

Part 1 ends here, bestie. Part 2 picks up at Section 2 with the terminology, so keep an eye out for it 💕🌸

2.1. Terms Used in This Document ✨

Okay so this doc borrows its vocab from the DetNet architecture [RFC8655] and the DetNet data plane framework [RFC8938] 📚 bestie, you're expected to already know those docs and every term in them 🫶 The DetNet <=> TSN dictionary from [RFC8655] is what translates [IEEE8021Qcc] stuff into this doc's language 💅

Terminology used in accordance with [RFC8655]:

  • App-flow: the payload (data) carried over a DetNet service 🎀
  • DetNet flow: a sequence of packets that conform uniquely to a flow identifier and to which the DetNet service is to be provided. It includes any DetNet headers added to support the DetNet service and forwarding sub-layers 🦋

New terms introduced in this document:

  • Source: reference point for an App-flow, where the flow starts 🌸
  • Destination: reference point for an App-flow, where the flow terminates 🌸
  • DN Ingress: reference point for the start of a DetNet flow. Networking technology-specific encapsulation may be added here to the served App-flow(s) ✨
  • DN Egress: reference point for the end of a DetNet flow. Networking technology-specific encapsulation may be removed here from the served App-flow(s) ✨

2.2. Abbreviations

The abbreviations we use in here, no cap 💖

DetNet        Deterministic Networking
DN            DetNet
MPLS          Multiprotocol Label Switching
PSN           Packet Switched Network
TSN           Time-Sensitive Networking

2.3. Naming Conventions

These are the naming conventions used for the information model components in this doc. It's recommended that extensions of the model use the same conventions, periodt 💅

  • Descriptive names are used 🧚
  • Names start with uppercase letters 🔠
  • Composed names use capital letters for the first letter of each component. All other letters are lowercase, even for abbreviations. Exceptions are made for abbreviations containing a mixture of lowercase and capital letters, such as IPv6. Example composed names are SourceMacAddress and DestinationIPv6Address 🌈

3. DetNet Domain and Its Modeling 🦋

3.1. DetNet Service Overview

The DetNet service is a service that provides a capability to carry a unicast or a multicast data flow for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency. It's giving reliability for the apps that need it 👑

Figures 5 and 8 in [RFC8655] show the DetNet service-related reference points and main components 📸

3.2. Reference Points Used in Modeling

Okay so from a service-design perspective, a big question is where the service/flow endpoints live, meaning where the service/flow starts and where it ends 🤔

App-flow-specific reference points are the source (where it starts) and the destination (where it terminates). A DetNet flow has its own reference points called "DN Ingress" (where a DetNet flow starts) and "DN Egress" (where a DetNet flow ends). These reference points may coexist in the same node (e.g., in a DetNet IP end system) 🫶 DN Ingress and DN Egress are intermediate reference points for a served App-flow 💜

In this document, all reference points are assumed to be packet-based reference points. A DN Ingress may add and a DN Egress may remove networking technology-specific encapsulation to/from the served App-flow(s) (e.g., MPLS label(s), UDP, and IP headers) 🎀

3.3. Information Elements

The DetNet flow information model and the service information model rely on three groups of information elements. Bestie, this is the lineup 📋

  • App-flow-related parameters: these describe the App-flow characteristics (e.g., identification, encapsulation, traffic specification, endpoints, status, etc.) and the App-flow service expectations (e.g., delay, loss, etc.) ✨
  • DetNet flow-related parameters: these describe the DetNet flow characteristics (e.g., identification, format, traffic specification, endpoints, rank, etc.) 🌸
  • DetNet service-related parameters: these describe the expected service characteristics (e.g., delivery type, connectivity delay/loss, status, rank, etc.) 👑

In the information model, a DetNet flow contains one or more (aggregated) App-flows, which is an N:1 mapping. During DetNet aggregation, the aggregated DetNet flows are treated simply as App-flows, and the aggregate is the DetNet flow, which provides that N:1 mapping. Similarly, there's an aggregated many-to-one relationship for the DetNet flow(s) to the DetNet service 🦋

When DetNet service is required by time-/loss-sensitive application(s) running on an end system during communication with its peer(s), the resulting data exchange has various requirements on delay and/or loss parameters. Main character energy for sure 🎬

4.1. App-Flow Characteristics

App-flow characteristics are described by the following parameters 📝

  • FlowID: a unique (management) identifier of the App-flow, which can be used to define the N:1 mapping of App-flows to a DetNet flow 🆔
  • FlowType: set by the encapsulation format of the flow, which can be Ethernet (TSN), MPLS, or IP 🎀
  • DataFlowSpecification: a flow descriptor, defining which packets belong to a flow, using specific packet header fields, such as src-addr, dst-addr, label, VLAN-ID, etc. 🔍
  • TrafficSpecification: a flow descriptor, defining traffic parameters, such as packet size, transmission time interval, and maximum packets per time interval 📦
  • FlowEndpoints: delineates the start and end reference points of the App-flow by pointing to the source interface/node and destination interface(s)/node(s) 📍
  • FlowStatus: indicates the status of the App-flow with respect to the establishment of the flow by the connected network, e.g., ready, failed, etc. 🚦
  • FlowRank: indicates the rank of this flow relative to other flows in the connected network 👑
Note: When defining the N:1 mapping of App-flows to a DetNet flow, the App-flows must have the same FlowType and different DataFlowSpecification parameters. 🙈

4.2. App-Flow Requirements

App-flow requirements are described by the following parameters 🌈

  • FlowRequirements: defines the attributes of the App-flow regarding bandwidth, latency, latency variation, loss, and misordering tolerance 💖
  • FlowBiDir: defines the data path requirement of the App-flow, whether it must share the same data path and physical path for both directions through the network, e.g., to provide congruent paths in the two directions 🦋

The data model specified by [IEEE8021Qcc] describes data flows using TSN service as periodic flows with fixed packet size (i.e., Constant Bitrate (CBR) flows) or with variable packet size. The same concept is applied for flows using DetNet service 🧚

Latency and loss parameters are correlated, because the effect of late delivery can result in data loss for an application. However, not all applications require hard limits on both latency and loss 🫶 For example, some real-time applications allow graceful degradation if loss happens (e.g., sample-based data processing and media distribution). Some other applications may require high-bandwidth connections that make use of packet replication techniques that are economically challenging or even impossible. Some applications may not tolerate loss but are not delay sensitive (e.g., bufferless sensors). Time- or loss-sensitive applications may have somewhat special requirements, especially for loss (e.g., no loss over two consecutive communication cycles, very low outage time, etc.) 💀

DetNet flows have the following attributes 📋

  • a. DnFlowID (Section 5.1)
  • b. DnPayloadType (Section 5.2)
  • c. DnFlowFormat (Section 5.3)
  • d. DnFlowSpecification (Section 5.4)
  • e. DnTrafficSpecification (Section 5.5)
  • f. DnFlowEndpoints (Section 5.6)
  • g. DnFlowRank (Section 5.7)
  • h. DnFlowStatus (Section 5.8)

DetNet flows have the following requirement attributes 🔥

  • a. DnFlowRequirements (Section 5.9)
  • b. DnFlowBiDir (Section 5.10)

Flow attributes are described in the following sections 🌸

5.1. Management ID of the DetNet Flow

A unique (management) identifier is needed for each DetNet flow within the DetNet domain. It is specified by DnFlowID. It can be used to define the N:1 mapping of DetNet flows to a DetNet service 🆔

5.2. Payload Type of the DetNet Flow

The DnPayloadType attribute is set according to the encapsulated App-flow format. The attribute can be Ethernet, MPLS, or IP 🎀

5.3. Format of the DetNet Flow

The DnFlowFormat attribute is set according to the DetNet PSN technology. The attribute can be MPLS or IP 🌈

5.4. Identification and Specification of DetNet Flows

Identification options for DetNet flows at the Ingress/Egress and within the DetNet domain are specified as follows. See Section 5.4.1 for DetNet MPLS flows and Section 5.4.2 for DetNet IP flows 🔍

5.4.1. DetNet MPLS Flow Identification and Specification

The identification of DetNet MPLS flows within the DetNet domain is based on the MPLS context in the service information model. The attributes are specific to the MPLS forwarding paradigm within the DetNet domain [RFC8964]. DetNet MPLS flows can be identified and specified by the following attributes 🦋

  • a. SLabel
  • b. FLabelStack

5.4.2. DetNet IP Flow Identification and Specification

DetNet IP flows can be identified and specified by the following attributes [RFC8939] 🌐

  • a. SourceIpAddress
  • b. DestinationIpAddress
  • c. IPv6FlowLabel
  • d. Dscp
  • e. Protocol
  • f. SourcePort
  • g. DestinationPort
  • h. IPSecSpi

The IP 6-tuple that is used for DetNet IP flow identification consists of items a, b, d, e, f, and g. Items c and h are additional attributes that can be used for DetNet flow identification in addition to the 6-tuple. The 6-tuple and use of wild cards for these attributes are specified in [RFC8939] 💜

5.5. Traffic Specification of the DetNet Flow

okay so the DnTrafficSpecification attributes describe how the DN Ingress sends packets for the DetNet flow 💅 It's basically the Ingress making a promise to the network, like "this is what I'm gonna send, please plan for it." The network then uses that promise to reserve resources and tune queue parameters in its nodes 🎀

The TrafficSpecification has these attributes:

  • a. Interval: the period of time over which the traffic specification is defined
  • b. MaxPacketsPerInterval: the maximum number of packets the Ingress will transmit in one Interval
  • c. MaxPayloadSize: the maximum payload size the Ingress will transmit
  • d. MinPayloadSize: the minimum payload size the Ingress will transmit
  • e. MinPacketsPerInterval: the minimum number of packets the Ingress will transmit in one Interval

These attributes can describe basically any kind of traffic (CBR, VBR, and so on 🦋) and they can be used during resource allocation to plan for worst-case scenarios. Interval values are an integer number of nanoseconds, and payload sizes are in octets 🌸

Now the spicy part 🌶️ If a flow goes over its traffic specification (so more traffic than the maximum attributes say), it can get a different network behavior than the one the DetNet network was engineered for 😭 Excess traffic from malicious or malfunctioning devices can be prevented or mitigated, for example with existing mechanisms like policing and shaping 🛡️

Here's how the minimum attributes work. When MinPayloadSize and MinPacketsPerInterval are used, every packet smaller than MinPayloadSize gets counted as being exactly MinPayloadSize during packet processing where size matters (like policing). Every flow with fewer than MinPacketsPerInterval gets counted as having MinPacketsPerInterval when the packet count matters (like resource reservation) 🧮 BUT, flows with fewer than MinPacketsPerInterval might still see a different network behavior than the DetNet network was engineered for, so keep that in mind 👀 These two minimums can be used, for example, when engineering the latency bounds of a DetNet flow where the Packet Ordering Function (POF) is applied 💜

There can also be extra optional attributes for more efficient resource allocation. They could be useful for flows with soft requirements, meaning flows that are only loss sensitive or only delay sensitive, but not both 🍓 How to extend the DnTrafficSpecification attributes is still open for further discussion ✨

5.6. Endpoints of the DetNet Flow

The DnFlowEndpoints attribute defines the start and end reference points of the DetNet flow. It does this by pointing at the ingress interface or node, and the egress interface(s) or node(s) 🧚 Whether you get an interface or a node depends on the network scenario. Defining an interface makes sense when the App-flow is a TSN Stream received over a well-defined User-to-Network Interface (UNI) 🌈 For App-flows with MPLS encapsulation, defining an ingress node is more common when a per-platform label space is used 💅

5.7. Rank of the DetNet Flow

The DnFlowRank attribute gives the rank of this flow compared to other flows in the DetNet domain. The rank (range: 0-255) is what the DetNet domain uses to decide which flows can and cannot exist when network resources hit their limit 😤 Rank helps decide which flows can get bumped, meaning removed from node configuration so their resources are released. This could happen if, for example, a node port becomes oversubscribed (say, after a network reconfiguration) 🔥

DnFlowRank value 0 is the highest priority. Zero is the queen 👑

5.8. Status of the DetNet Flow

The DnFlowStatus attribute shows the status of the DetNet flow with respect to how the DetNet domain has been establishing it 🫶

DnFlowStatus includes these attributes:

  • a. DnIngressStatus is an enumeration for the status of the flow's Ingress reference point:
    • None: No Ingress.
    • Ready: Ingress is ready.
    • Failed: Ingress failed.
    • OutOfService: Administratively blocked.
  • b. DnEgressStatus is an enumeration for the status of the flow's Egress reference points:
    • None: No Egress.
    • Ready: All Egresses are ready.
    • PartialFailed: One or more Egress is ready, and one or more Egress failed. The DetNet flow can be used if the Ingress is Ready. 🥺
    • Failed: All Egresses failed.
    • OutOfService: All Egresses are administratively blocked.
  • c. FailureCode is a nonzero code that specifies the error if the DetNet flow runs into a failure. Examples include packet replication and elimination being requested but not possible, DnIngressStatus being Failed, DnEgressStatus being Failed, or DnEgressStatus being PartialFailed 💀

Defining FailureCodes for DetNet is out of scope for this document 🙈 If you want the TSN failure codes, check Table 46-1 of [IEEE8021Qcc] 📚

5.9. Requirements of the DetNet Flow

The DnFlowRequirements attribute specifies the requirements that make sure the DetNet flow gets the service level it wants ✨

DnFlowRequirements includes these attributes:

  • a. MinBandwidth (Section 5.9.1)
  • b. MaxLatency (Section 5.9.2)
  • c. MaxLatencyVariation (Section 5.9.3)
  • d. MaxLoss (Section 5.9.4)
  • e. MaxConsecutiveLossTolerance (Section 5.9.5)
  • f. MaxMisordering (Section 5.9.6)

5.9.1. Minimum Bandwidth of the DetNet Flow

MinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet flow. It's specified in octets per second 🍃

5.9.2. Maximum Latency of the DetNet Flow

MaxLatency is the maximum latency from Ingress to Egress(es) for a single packet of the DetNet flow ⏱️ It's specified as an integer number of nanoseconds ⭐

5.9.3. Maximum Latency Variation of the DetNet Flow

MaxLatencyVariation is the difference between the minimum and the maximum end-to-end, one-way latency 🎢 It's specified as an integer number of nanoseconds 💖

5.9.4. Maximum Loss of the DetNet Flow

MaxLoss defines the maximum Packet Loss Rate (PLR) requirement for the DetNet flow between the Ingress and Egress(es), along with the loss measurement interval 📉

5.9.5. Maximum Consecutive Loss of the DetNet Flow

Some applications have special loss requirements, like MaxConsecutiveLossTolerance 🥹 This parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured, for example, based on sequence number 🔢

5.9.6. Maximum Misordering Tolerance of the DetNet Flow

MaxMisordering describes the tolerable maximum number of packets that can be received out of order 🌀 A value of zero for the maximum allowed misordering means in-order delivery is required, and misordering cannot be tolerated at all 🙅‍♀️

The maximum allowed misordering can be measured, for example, based on sequence numbers. When a packet shows up at the egress after a packet with a higher sequence number, the difference between the sequence number values cannot be bigger than "MaxMisordering + 1" 🧠

5.10. BiDir Requirement of the DetNet Flow

The DnFlowBiDir attribute defines the requirement that the flow and its corresponding reverse direction flow must share the same path (links and nodes) through the routed or switched network in the DetNet domain 🔁 Basically, the goal is congruent paths in both directions, so they share fate and path characteristics 🦋

The DetNet service has these attributes:

  • a. DnServiceID (Section 6.1)
  • b. DnServiceDeliveryType (Section 6.2)
  • c. DnServiceDeliveryProfile (Section 6.3)
  • d. DNServiceConnectivity (Section 6.4)
  • e. DnServiceBiDir (Section 6.5)
  • f. DnServiceRank (Section 6.6)
  • g. DnServiceStatus (Section 6.7)

Each one gets its own section below 🎀

6.1. Management ID of the DetNet Service

The DnServiceId attribute is a unique (management) identifier for each DetNet service within the DetNet domain 🪪 It can be used to define the many-to-one mapping of DetNet flows to a DetNet service 🌸

6.2. Delivery Type of the DetNet Service

The DnServiceDeliveryType attribute is set according to the payload of the served DetNet flow, which is the encapsulated App-flow format 📦 The attribute can be Ethernet, MPLS, or IP 🌐

6.3. Delivery Profile of the DetNet Service

The DnServiceDeliveryProfile attribute specifies the delivery profile that makes sure the DetNet flow gets served properly 💅

DnServiceDeliveryProfile includes these attributes:

  • a. MinBandwidth (Section 6.3.1)
  • b. MaxLatency (Section 6.3.2)
  • c. MaxLatencyVariation (Section 6.3.3)
  • d. MaxLoss (Section 6.3.4)
  • e. MaxConsecutiveLossTolerance (Section 6.3.5)
  • f. MaxMisordering (Section 6.3.6)

6.3.1. Minimum Bandwidth of the DetNet Service

MinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet service. It's specified in octets per second and excludes any additional DetNet header (if there is one) 🍓

6.3.2. Maximum Latency of the DetNet Service

MaxLatency is the maximum latency from Ingress to Egress(es) for a single packet of the DetNet flow ⏱️ It's specified as an integer number of nanoseconds ✨

6.3.3. Maximum Latency Variation of the DetNet Service

MaxLatencyVariation is the difference between the minimum and the maximum end-to-end, one-way latency 🎢 It's specified as an integer number of nanoseconds 💜

6.3.4. Maximum Loss of the DetNet Service

MaxLoss defines the maximum Packet Loss Rate (PLR) parameter for the DetNet service between the Ingress and Egress(es) of the DetNet domain 📉

6.3.5. Maximum Consecutive Loss of the DetNet Service

Some applications have a special loss requirement, like MaxConsecutiveLossTolerance 🥹 This parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured, for example, based on sequence number 🔢

6.3.6. Maximum Misordering Tolerance of the DetNet Service

MaxMisordering describes the tolerable maximum number of packets that can be received out of order 🌀 The maximum allowed misordering can be measured, for example, based on sequence number. A value of zero means in-order delivery is required, and misordering cannot be tolerated 🙅‍♀️

6.4. Connectivity Type of the DetNet Service

There are two connectivity types: point-to-point (p2p) and point-to-multipoint (p2mp) 🦋 Connectivity type p2mp can be created by a forwarding function, for example a p2mp LSP 🧚 (Quick side note from a service perspective: mp2mp connectivity can be treated as a superposition of p2mp connections 💅)

6.5. BiDir Requirement of the DetNet Service

The DnServiceBiDir attribute defines the requirement that the flow and its corresponding reverse direction flow must share the same path (links and nodes) through the routed or switched network in the DetNet domain 🔁 The goal is the same as before: congruent paths in both directions that share fate and path characteristics 🫶

6.6. Rank of the DetNet Service

The DnServiceRank attribute gives the rank of a service instance compared to other services in the DetNet domain 👑 The rank (range: 0-255) is used by the network when resources are limited 😤 A DnServiceRank value of 0 is the highest priority 💖

6.7. Status of the DetNet Service 💖

okay so this is the status part 🧚 The DnServiceStatus information group holds the elements that show the status of the service-specific state of the DetNet domain. It basically tells the user whether the service is ready for use or not ✨

DnServiceStatus has these attributes:

a. DnServiceIngressStatus is an enumeration for the status of the service's Ingress:

  • None: No Ingress.
  • Ready: Ingress is ready.
  • Failed: Ingress failed.
  • OutOfService: Administratively blocked.

b. DnServiceEgressStatus is an enumeration for the status of the service's Egress:

  • None: No Egress.
  • Ready: All Egresses are ready.
  • PartialFailed: One or more Egress is ready, and one or more Egress failed. The DetNet flow can be used if the Ingress is Ready.
  • Failed: All Egresses failed.
  • OutOfService: Administratively blocked.

c. DnServiceFailureCode is a nonzero code that specifies the error if the DetNet service encounters a failure (e.g., packet replication and elimination is requested but not possible or DnServiceIngressStatus is Failed, DnServiceEgressStatus is Failed, or DnServiceEgressStatus is PartialFailed).

Defining DnServiceFailureCodes for DetNet service is out of scope for this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure codes 🌸

7. Flow-Specific Operations 🎀

The DetNet flow information model relies on three high-level information groups, and they're giving main character energy 👑

  • DnIngress: The DnIngress information group includes elements that specify the source for a single DetNet flow. This information group is applied from the user of the DetNet service to the network.
  • DnEgress: The DnEgress information group includes elements that specify the destination for a single DetNet flow. This information group is applied from the user of the DetNet service to the network.
  • DnFlowStatus: The DnFlowStatus information group includes elements that specify the status of the flow in the network. This information group is applied from the network to the user of the DetNet service. It informs the user whether or not the DetNet flow is ready for use.

There are three possible operations for each DetNet flow with respect to its DetNet service at a DN Ingress or a DN Egress (similar to App-flows at a source or a destination) 🦋

  • Join: DN Ingress/DN Egress intends to join the flow.
  • Leave: DN Ingress/DN Egress intends to leave the flow.
  • Modify: DN Ingress/DN Egress intends to change the flow.

7.1. Join Operation 🧚

For the join operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint, and DnTrafficSpecification are included within the DnIngress or DnEgress information groups. For the join operation, the DnServiceRequirements groups can be included.

7.2. Leave Operation 🙈

For the leave operation, the DnFlowSpecification and DnFlowEndpoint are included within the DnIngress or DnEgress information groups.

7.3. Modify Operation 💅

For the modify operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint, and DnTrafficSpecification are included within the DnIngress or DnEgress information group. For the join operation, the DnServiceRequirements groups can be included.

The Modify operation can be considered to address cases when a flow is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been changed. The advantage of having a Modify is that it allows initiation of a change of flow spec while leaving the current flow operating until the change is accepted. If there is no linkage between the Join and the Leave, then while figuring out whether the new flow spec can be supported, the controller entity has to assume that the resources committed to the current flow are in use. By using Modify, the controller entity knows that the resources supporting the current flow can be available for supporting the altered flow. Modify is considered to be an optional operation due to possible controller plane limitations 🫶

8. Summary 🌈

This document describes the DetNet flow information model and the service information model for DetNet IP networks and DetNet MPLS networks. These models are used as input for creating the DetNet-specific YANG module ✨

9. IANA Considerations 🍓

This document has no IANA actions.

10. Security Considerations 💀

The external interfaces of the DetNet domain need to be subject to appropriate confidentiality. Additionally, knowledge of which flows/services are provided to a customer or delivered by a network operator may supply information that can be used in a variety of security attacks. Security considerations for DetNet are described in detail in [DETNET-SECURITY]. General security considerations are described in [RFC8655]. This document discusses modeling the information, not how it is exchanged.

11. References 📚

11.1. Normative References 💜

[IEEE8021Qcc]
           IEEE, "IEEE Standard for Local and Metropolitan Area
           Networks--Bridges and Bridged Networks -- Amendment 31:
           Stream Reservation Protocol (SRP) Enhancements and
           Performance Improvements",
           DOI 10.1109/IEEESTD.2018.8514112, IEEE 802.1Qcc-2018,
           October 2013,
           <https://ieeexplore.ieee.org/document/8514112/>.

[RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
           "Deterministic Networking Architecture", RFC 8655,
           DOI 10.17487/RFC8655, October 2019,
           <https://www.rfc-editor.org/info/rfc8655>.

[RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
           Bryant, "Deterministic Networking (DetNet) Data Plane:
           IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
           <https://www.rfc-editor.org/info/rfc8939>.

[RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
           S., and J. Korhonen, "Deterministic Networking (DetNet)
           Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
           2021, <https://www.rfc-editor.org/info/rfc8964>.

11.2. Informative References 🦋

[DETNET-SECURITY]
           Grossman, E., Mizrahi, T., and A. J. Hacker,
           "Deterministic Networking (DetNet) Security
           Considerations", Work in Progress, Internet-Draft, draft-
           ietf-detnet-security-16, 2 March 2021,
           <https://tools.ietf.org/html/draft-ietf-detnet-security-
           16>.

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

[IEEE8021Q]
           IEEE, "IEEE Standard for Local and Metropolitan Area
           Networks--Bridges and Bridged Networks",
           DOI 10.1109/IEEESTD.2018.8403927, IEEE 802.1Q-2018, July
           2018, <https://ieeexplore.ieee.org/document/8403927>.

[IEEE8021Qbv]
           IEEE, "IEEE Standard for Local and metropolitan area
           networks -- Bridges and Bridged Networks - Amendment 25:
           Enhancements for Scheduled Traffic",
           DOI 10.1109/IEEESTD.2016.8613095, IEEE 802.1Qbv-2015,
           March 2016,
           <https://ieeexplore.ieee.org/document/8613095>.

[IETFDetNet]
           IETF, "Deterministic Networking (detnet)",
           <https://datatracker.ietf.org/wg/detnet/charter/>.

[RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
           Information Models and Data Models", RFC 3444,
           DOI 10.17487/RFC3444, January 2003,
           <https://www.rfc-editor.org/info/rfc3444>.

[RFC8938]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
           Bryant, "Deterministic Networking (DetNet) Data Plane
           Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
           <https://www.rfc-editor.org/info/rfc8938>.

Authors' Addresses 🎀

Balázs Varga
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


Rodney Cummings
National Instruments
Bldg. C
11500 N. Mopac Expwy
Austin, TX 78759-3504
United States of America

Email: rodney.cummings@ni.com


Yuanlong Jiang
Huawei
Bantian, Longgang district
Shenzhen
518129
China

Email: jiangyuanlong@huawei.com


Don Fedyk
LabN Consulting, L.L.C.

Email: dfedyk@labn.net
📦 where this page comes from