draft-ietf-detnet-flow-information-model-14.txt   rfc9016.txt 
DetNet B. Varga Internet Engineering Task Force (IETF) B. Varga
Internet-Draft J. Farkas Request for Comments: 9016 J. Farkas
Intended status: Informational Ericsson Category: Informational Ericsson
Expires: July 28, 2021 R. Cummings ISSN: 2070-1721 R. Cummings
National Instruments National Instruments
Y. Jiang Y. Jiang
Huawei Technologies Co., Ltd. Huawei
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting
January 24, 2021 March 2021
DetNet Flow and Service Information Model Flow and Service Information Model for Deterministic Networking (DetNet)
draft-ietf-detnet-flow-information-model-14
Abstract Abstract
This document describes flow and service information model for This document describes the flow and service information model for
Deterministic Networking (DetNet). These models are defined for IP Deterministic Networking (DetNet). These models are defined for IP
and MPLS DetNet data planes and MPLS DetNet data planes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on July 28, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9016.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Goals
1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non-Goals
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6 2.1. Terms Used in This Document
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Abbreviations
2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 7 2.3. Naming Conventions
3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 3. DetNet Domain and Its Modeling
3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 3.1. DetNet Service Overview
3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7 3.2. Reference Points Used in Modeling
3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 3.3. Information Elements
4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8 4. App-Flow-Related Parameters
4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8 4.1. App-Flow Characteristics
4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 4.2. App-Flow Requirements
5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9 5. DetNet Flow-Related Parameters
5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 5.1. Management ID of the DetNet Flow
5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10 5.2. Payload Type of the DetNet Flow
5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10 5.3. Format of the DetNet Flow
5.4. Identification and Specification of DetNet Flows . . . . 10 5.4. Identification and Specification of DetNet Flows
5.4.1. DetNet MPLS Flow Identification and Specification . . 11 5.4.1. DetNet MPLS Flow Identification and Specification
5.4.2. DetNet IP Flow Identification and Specification . . . 11 5.4.2. DetNet IP Flow Identification and Specification
5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11 5.5. Traffic Specification of the DetNet Flow
5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12 5.6. Endpoints of the DetNet Flow
5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 13 5.7. Rank of the DetNet Flow
5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 13 5.8. Status of the DetNet Flow
5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 14 5.9. Requirements of the DetNet Flow
5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14 5.9.1. Minimum Bandwidth of the DetNet Flow
5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14 5.9.2. Maximum Latency of the DetNet Flow
5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14 5.9.3. Maximum Latency Variation of the DetNet Flow
5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14 5.9.4. Maximum Loss of the DetNet Flow
5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14 5.9.5. Maximum Consecutive Loss of the DetNet Flow
5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 15 5.9.6. Maximum Misordering Tolerance of the DetNet Flow
5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 15 5.10. BiDir Requirement of the DetNet Flow
6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15 6. DetNet Service-Related Parameters
6.1. Management ID of the DetNet service . . . . . . . . . . . 15 6.1. Management ID of the DetNet Service
6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15 6.2. Delivery Type of the DetNet Service
6.3. Delivery Profile of the DetNet Service . . . . . . . . . 16 6.3. Delivery Profile of the DetNet Service
6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 16 6.3.1. Minimum Bandwidth of the DetNet Service
6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16 6.3.2. Maximum Latency of the DetNet Service
6.3.3. Maximum Latency Variation of the DetNet Service . . . 16 6.3.3. Maximum Latency Variation of the DetNet Service
6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16 6.3.4. Maximum Loss of the DetNet Service
6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 16 6.3.5. Maximum Consecutive Loss of the DetNet Service
6.3.6. Maximum Misordering Tolerance of the DetNet Service . 17 6.3.6. Maximum Misordering Tolerance of the DetNet Service
6.4. Connectivity Type of the DetNet Service . . . . . . . . . 17 6.4. Connectivity Type of the DetNet Service
6.5. BiDir requirement of the DetNet Service . . . . . . . . . 17 6.5. BiDir Requirement of the DetNet Service
6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17 6.6. Rank of the DetNet Service
6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 6.7. Status of the DetNet Service
7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18 7. Flow-Specific Operations
7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 19 7.1. Join Operation
7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 19 7.2. Leave Operation
7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 19 7.3. Modify Operation
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Summary
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses
1. Introduction 1. Introduction
Deterministic Networking (DetNet) provides a capability to carry Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and delivery latency. A description of the general background and
concepts of DetNet can be found in [RFC8655]. concepts of DetNet can be found in [RFC8655].
This document describes the Detnet Flow and Service Information This document describes the DetNet flow and service information
Model. For reference [RFC3444] describes the rationale behind model. For reference, [RFC3444] describes the rationale behind
Information Models in general. This document describes the Flow and information models in general. This document describes the flow and
Service information models for operators and users to understand service information models for operators and users to understand
Detnet services, and for implementors as a guide to the functionality DetNet services and for implementors as a guide to the functionality
required by Detnet services. required by DetNet services.
The DetNet Architecture treats the DetNet related data plane The DetNet architecture treats the DetNet-related data plane
functions decomposed into two sub-layers: a service sub-layer and a functions decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide forwarding sub-layer. The service sub-layer is used to provide
DetNet service protection and reordering. The forwarding sub-layer DetNet service protection and reordering. The forwarding sub-layer
provides resource allocation (to ensure low loss, assured latency, provides resource allocation (to ensure low loss, assured latency,
and limited out-of-order delivery) and leverages Traffic Engineering and limited out-of-order delivery) and leverages traffic engineering
mechanisms. mechanisms.
DetNet service utilizes IP or MPLS and DetNet is currently defined DetNet service utilizes IP or MPLS, and DetNet is currently defined
for IP and MPLS networks as shown in Figure 1 based on Figure 2 and for IP and MPLS networks, as shown in Figure 1, which is a reprint of
Figure 3 of [RFC8938]. IEEE 802.1 Time Sensitive Networking (TSN) Figure 2 from [RFC8938]. IEEE 802.1 Time-Sensitive Networking (TSN)
utilizes Ethernet and is defined over Ethernet networks. A DetNet utilizes Ethernet and is defined over Ethernet networks. A DetNet
flow includes one or more App-flow(s) as payload. App-flows can be flow includes one or more application-level flow (App-flow) as
Ethernet, MPLS, or IP flows, which impacts which header fields are payload. App-flows can be Ethernet, MPLS, or IP flows, which impacts
utilized to identify a flow. DetNet flows are identified by the which header fields are utilized to identify a flow. DetNet flows
DetNet encapsulation of App-flow(s) (e.g., MPLS labels, IP 6-tuple are identified by the DetNet encapsulation of App-flow(s) (e.g., MPLS
etc.). In some scenarios App-flow and DetNet flow look similar on labels, IP 6-tuples, etc.). In some scenarios, App-flow and DetNet
the wire (e.g., L3 App-flow over a DetNet IP network). flow look similar on the wire (e.g., Layer 3 (L3) App-flow over a
DetNet IP network).
+-----+ +-----+
| TSN | | TSN |
+-------+ +-+-----+-+ +-------+ +-+-----+-+
| DN IP | | DN MPLS | | DN IP | | DN MPLS |
+--+--+----+----+ +-+---+-----+-+ +--+--+----+----+ +-+---+-----+-+
| TSN | DN MPLS | | TSN | DN IP | | TSN | DN MPLS | | TSN | DN IP |
+-----+---------+ +-----+-------+ +-----+---------+ +-----+-------+
Figure 1: DetNet Service Examples as per Data Plane Framework Figure 1: DetNet Service Examples as per Data Plane Framework
As shown in Figure 1 as per [RFC8938] a DetNet flow can be treated as As shown in Figure 1 and as described in [RFC8938], a DetNet flow can
an application level flow (App-flow) e.g., at DetNet flow aggregation be treated as an App-flow, e.g., at DetNet flow aggregation or in a
or in a sub-network that interconnects DetNet nodes. sub-network that interconnects DetNet nodes.
The DetNet flow and service information model provided by this The DetNet flow and service information model provided by this
document contains both DetNet flow and App-flow specific information document contains both DetNet-flow- and App-flow-specific information
in an integrated fashion. in an integrated fashion.
In a given network scenario three information models can be In a given network scenario, three information models can be
distinguished: distinguished:
o Flow models that describe characteristics of data flows. These * Flow information models that describe characteristics of data
models describe in detail all relevant aspects of a flow that are flows. These models describe, in detail, all relevant aspects of
needed to support the flow properly by the network between the a flow that are needed to support the flow properly by the network
source and the destination(s). between the source and the destination(s).
o Service models that describe characteristics of services being * Service information models that describe characteristics of
provided for data flows over a network. These models can be services being provided for data flows over a network. These
treated as a network operator independent information model. models can be treated as an information model that is network
operator independent.
o Configuration models that describe in detail the settings required * Configuration information models that describe, in detail, the
on network nodes to provide a data flow proper service. settings required on network nodes to provide proper service to a
data flow.
Service and flow information models are used between the user and the Service and flow information models are used between the user and the
network operator. Configuration information models are used between network operator. Configuration information models are used between
the management/control plane entity of the network and the network the management/control plane entity of the network and the network
nodes. They are shown in Figure 2. nodes. They are shown in Figure 2.
User Network Operator User Network Operator
flow/service flow/service
/\ info model +---+ /\ info model +---+
/ \ <---------------> | X | management/control / \ <---------------> | X | management/control
---- +-+-+ plane entity ---- +-+-+ plane entity
^ ^
| configuration | configuration
| info model | info model
+------------+ +------------+
v | | v | |
+-+ | v Network +-+ | v network
+-+ v +-+ nodes +-+ v +-+ nodes
+-+ +-+ +-+ +-+
+-+ +-+
Figure 2: Usage of Information models (flow, service and Figure 2: Usage of Information Models (Flow, Service, and
configuration) Configuration)
DetNet flow and service information model is based on [RFC8655] and The DetNet flow and service information model is based on [RFC8655]
on the concept of data model specified by [IEEE8021Qcc]. In addition and the concept of the data model specified by [IEEE8021Qcc]. In
to the TSN data model, [IEEE8021Qcc] also specifies configuration of addition to the TSN data model, [IEEE8021Qcc] also specifies
TSN features (e.g., traffic scheduling specified by [IEEE8021Qbv]). configuration of TSN features (e.g., traffic scheduling specified by
The common architecture and flow model, allow configured features to [IEEE8021Qbv]). The common architecture and flow information model
be consistent in certain deployment scenarios, e.g., when the network allow configured features to be consistent in certain deployment
that provides the DetNet service includes both L3 and L2 network scenarios, e.g., when the network that provides the DetNet service
segments. includes both L3 and L2 network segments.
1.1. Goals 1.1. Goals
As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates As expressed in the DetNet WG Charter [IETFDetNet], the DetNet WG
with IEEE 802.1 TSN in order to define a common architecture for both collaborates with IEEE 802.1 TSN in order to define a common
Layer 2 and Layer 3. This is beneficial for several reasons, e.g., architecture for both Layers 2 and 3. This is beneficial for several
in order to simplify implementations and maintain consistency across reasons, e.g., in order to simplify implementations and maintain
diverse networks. The flow and service information models are also consistency across diverse networks. The flow and service
aligned for those reasons. Therefore, the DetNet flow and service information models are also aligned for those reasons. Therefore,
information models described in this document are based on the DetNet flow and service information models described in this
[IEEE8021Qcc], which is an amendment to [IEEE8021Q]. document are based on [IEEE8021Qcc], which is an amendment to
[IEEE8021Q].
This document specifies flow and service information models only. This document specifies flow and service information models only.
1.2. Non Goals 1.2. Non-Goals
This document does not specify flow data models or DetNet This document does not specify flow data models or DetNet
configuration. Therefore, the goals of this document differ from the configuration. Therefore, the goals of this document differ from the
goals of [IEEE8021Qcc], which also specifies the TSN data model and goals of [IEEE8021Qcc], which also specifies the TSN data model and
configuration of certain TSN features. configuration of certain TSN features.
The DetNet specific YANG data model is described in The DetNet-specific YANG data model is described in [DETNET-YANG].
[I-D.ietf-detnet-yang].
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [RFC8655] and the DetNet Data Plane Framework [RFC8938]. architecture [RFC8655] and the DetNet data plane framework [RFC8938].
The reader is assumed to be familiar with these documents and any The reader is assumed to be familiar with these documents and any
terminology defined therein. The DetNet <=> TSN dictionary of terminology defined therein. The DetNet <=> TSN dictionary of
[RFC8655] is used to perform translation from [IEEE8021Qcc] to this [RFC8655] is used to perform translation from [IEEE8021Qcc] to this
document. document.
The following terminology is used in accordance with [RFC8655]: The following terminology is used in accordance with [RFC8655]:
App-flow The payload (data) carried over a DetNet service. App-flow The payload (data) carried over a DetNet service.
DetNet flow A DetNet flow is a sequence of packets which conform DetNet flow A sequence of packets that conform uniquely to a flow
uniquely to a flow identifier, and to which the DetNet identifier and to which the DetNet service is to be
service is to be provided. It includes any DetNet provided. It includes any DetNet headers added to
headers added to support the DetNet service and support the DetNet service and forwarding sub-layers.
forwarding sub-layers.
The following terminology is introduced in this document: The following terminology is introduced in this document:
Source Reference point for an App-flow, where the flow starts. Source Reference point for an App-flow, where the flow starts.
Destination Reference point for an App-flow, where the flow Destination Reference point for an App-flow, where the flow
terminates. terminates.
DN Ingress Reference point for the start of a DetNet flow. DN Ingress Reference point for the start of a DetNet flow.
Networking technology specific encapsulation may be Networking technology-specific encapsulation may be
added here to the served App-flow(s). added here to the served App-flow(s).
DN Egress Reference point for the termination of a DetNet flow. DN Egress Reference point for the end of a DetNet flow.
Networking technology specific encapsulation may be Networking technology-specific encapsulation may be
removed here from the served App-flow(s). removed here from the served App-flow(s).
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
DetNet Deterministic Networking. DetNet Deterministic Networking
DN DetNet. DN DetNet
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching
PSN Packet Switched Network. PSN Packet Switched Network
TSN Time-Sensitive Networking. TSN Time-Sensitive Networking
2.3. Naming Conventions 2.3. Naming Conventions
The following naming conventions were used for naming information The following naming conventions were used for naming information
model components in this document. It is recommended that extensions model components in this document. It is recommended that extensions
of the model use the same conventions. of the model use the same conventions.
o Descriptive names are used. * Descriptive names are used.
o Names start with uppercase letters. * Names start with uppercase letters.
o Composed names use capital letters for the first letter of each * Composed names use capital letters for the first letter of each
component. All other letters are lowercase, even for acronyms. component. All other letters are lowercase, even for
Exceptions are made for acronyms containing a mixture of lowercase abbreviations. Exceptions are made for abbreviations containing a
and capital letters, such as IPv6. Example composed names are mixture of lowercase and capital letters, such as IPv6. Example
SourceMacAddress and DestinationIPv6Address. composed names are SourceMacAddress and DestinationIPv6Address.
3. DetNet Domain and its Modeling 3. DetNet Domain and Its Modeling
3.1. DetNet Service Overview 3.1. DetNet Service Overview
The DetNet service can be defined as a service that provides a The DetNet service can be defined as a service that provides a
capability to carry a unicast or a multicast data flow for an capability to carry a unicast or a multicast data flow for an
application with constrained requirements on network performance, application with constrained requirements on network performance,
e.g., low packet loss rate and/or latency. e.g., low packet loss rate and/or latency.
Figure 5 and Figure 8 in [RFC8655] show the DetNet service related Figures 5 and 8 in [RFC8655] show the DetNet service-related
reference points and main components. reference points and main components.
3.2. Reference Points Used in Modeling 3.2. Reference Points Used in Modeling
From service design perspective a fundamental question is the From a service-design perspective, a fundamental question is the
location of the service/flow endpoints, i.e., where the service/flow location of the service/flow endpoints, i.e., where the service/flow
starts and ends. starts and ends.
App-flow specific reference points are the Source (where it starts) App-flow-specific reference points are the source (where it starts)
and the Destination (where it terminates). Similarly a DetNet flow and the destination (where it terminates). Similarly, a DetNet flow
has reference points termed DN Ingress (where a DetNet flow starts) has reference points termed "DN Ingress" (where a DetNet flow starts)
and DN Egress (where a DetNet flow ends). These reference points may and "DN Egress" (where a DetNet flow ends). These reference points
coexist in the same node (e.g., in a DetNet IP end system). DN may coexist in the same node (e.g., in a DetNet IP end system). DN
Ingress and DN Egress reference points are intermediate reference Ingress and DN Egress reference points are intermediate reference
points for a served App-flow. points for a served App-flow.
All reference points are assumed in this document to be packet-based 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 reference points. A DN Ingress may add and a DN Egress may remove
networking technology specific encapsulation to/from the served App- networking technology-specific encapsulation to/from the served App-
flow(s) (e.g., MPLS label(s), UDP and IP headers). flow(s) (e.g., MPLS label(s), UDP, and IP headers).
3.3. Information Elements 3.3. Information Elements
The DetNet flow information model and the service model relies on The DetNet flow information model and the service information model
three groups of information elements: rely on three groups of information elements:
o App-flow related parameters: these describe the App-flow App-flow-related parameters: These describe the App-flow
characteristics (e.g., identification, encapsulation, traffic characteristics (e.g., identification, encapsulation, traffic
specification, endpoints, status, etc.) and the App-flow service specification, endpoints, status, etc.) and the App-flow service
expectations (e.g., delay, loss, etc.). expectations (e.g., delay, loss, etc.).
o DetNet flow related parameters: these describe the DetNet flow DetNet flow-related parameters: These describe the DetNet flow
characteristics (e.g., identification, format, traffic characteristics (e.g., identification, format, traffic
specification, endpoints, rank, etc.). specification, endpoints, rank, etc.).
o DetNet service related parameters: these describe the expected DetNet service-related parameters: These describe the expected
service characteristics (e.g., delivery type, connectivity delay/ service characteristics (e.g., delivery type, connectivity delay/
loss, status, rank, etc.). loss, status, rank, etc.).
In the information model a DetNet flow contains one or more In the information model, a DetNet flow contains one or more
(aggregated) App-flows (N:1 mapping). During DetNet aggregation the (aggregated) App-flows (N:1 mapping). During DetNet aggregation, the
aggregated DetNet flows are treated simply as App-flows and the aggregated DetNet flows are treated simply as App-flows and the
aggregate is the DetNet flow, which provides N:1 mapping. Similarly, aggregate is the DetNet flow, which provides N:1 mapping. Similarly,
there is an aggregated many to one relationship for the DetNet there is an aggregated many-to-one relationship for the DetNet
flow(s) to the DetNet Service. flow(s) to the DetNet service.
4. App-flow Related Parameters 4. App-Flow-Related Parameters
When Deterministic service is required by time/loss sensitive When DetNet service is required by time-/loss-sensitive
application(s) running on an end system during communication with its application(s) running on an end system during communication with its
peer(s), the resulting data exchange has various requirements on peer(s), the resulting data exchange has various requirements on
delay and/or loss parameters. delay and/or loss parameters.
4.1. App-flow Characteristics 4.1. App-Flow Characteristics
App-flow characteristics are described by the following parameters: App-flow characteristics are described by the following parameters:
o FlowID: a unique (management) identifier of the App-flow. It can FlowID: a unique (management) identifier of the App-flow, which
be used to define the N:1 mapping of App-flows to a DetNet flow. can be used to define the N:1 mapping of App-flows to a
DetNet flow
o FlowType: set by the encapsulation format of the flow. It can be FlowType: set by the encapsulation format of the flow, which can
Ethernet (TSN), MPLS, or IP. be Ethernet (TSN), MPLS, or IP
o DataFlowSpecification: a flow descriptor, defining which packets DataFlowSpecification: a flow descriptor, defining which packets
belongs to a flow, using specific packet header fields such as belongs to a flow, using specific packet header fields,
src-addr, dst-addr, label, VLAN-ID, etc. such as src-addr, dst-addr, label, VLAN-ID, etc.
o TrafficSpecification: a flow descriptor, defining traffic TrafficSpecification: a flow descriptor, defining traffic
parameters such as packet size, transmission time interval, and parameters, such as packet size, transmission time
maximum packets per time interval. interval, and maximum packets per time interval
o FlowEndpoints: delineate the start and termination reference FlowEndpoints: delineates the start and end reference points of the
points of the App-flow by pointing to the source interface/node App-flow by pointing to the source interface/node and
and destination interface(s)/node(s). destination interface(s)/node(s)
o FlowStatus: indicates the status of the App-flow with respect to FlowStatus: indicates the status of the App-flow with respect to
the establishment of the flow by the connected network, e.g., the establishment of the flow by the connected network,
ready, failed, etc. e.g., ready, failed, etc.
o FlowRank: indicates the rank of this flow relative to other flows FlowRank: indicates the rank of this flow relative to other flows
in the connected network. in the connected network
Note: When defining the N:1 mapping of App-flows to a DetNet flow, | Note: When defining the N:1 mapping of App-flows to a DetNet
the App-flows must have the same FlowType and different | flow, the App-flows must have the same FlowType and different
DataFlowSpecification parameters | DataFlowSpecification parameters.
4.2. App-flow Requirements 4.2. App-Flow Requirements
App-flow requirements are described by the following parameters: App-flow requirements are described by the following parameters:
o FlowRequirements: defines the attributes of the App-flow regarding FlowRequirements: defines the attributes of the App-flow regarding
bandwidth, latency, latency variation, loss, and misordering bandwidth, latency, latency variation, loss, and
tolerance. misordering tolerance
o FlowBiDir: defines the data path requirement of the App-flow FlowBiDir: defines the data path requirement of the App-flow
whether it must share the same data path and physical path for whether it must share the same data path and physical
both directions through the network, e.g., to provide congruent path for both directions through the network, e.g., to
paths in the two directions. provide congruent paths in the two directions
5. DetNet Flow Related Parameters 5. DetNet Flow-Related Parameters
The Data model specified by [IEEE8021Qcc] describes data flows using The data model specified by [IEEE8021Qcc] describes data flows using
TSN service as periodic flows with fixed packet size (i.e., Constant TSN service as periodic flows with fixed packet size (i.e., Constant
Bit Rate (CBR) flows) or with variable packet size. The same concept Bitrate (CBR) flows) or with variable packet size. The same concept
is applied for flows using DetNet service. is applied for flows using DetNet service.
Latency and loss parameters are correlated because the effect of late Latency and loss parameters are correlated because the effect of late
delivery can result in data loss for an application. However, not delivery can result in data loss for an application. However, not
all applications require hard limits on both latency and loss. For all applications require hard limits on both latency and loss. For
example, some real-time applications allow graceful degradation if example, some real-time applications allow graceful degradation if
loss happens (e.g., sample-based data processing, media loss happens (e.g., sample-based data processing and media
distribution). Some other applications may require high-bandwidth distribution). Some other applications may require high-bandwidth
connections that make use of packet replication techniques which are connections that make use of packet replication techniques that are
economically challenging or even impossible. Some applications may economically challenging or even impossible. Some applications may
not tolerate loss, but are not delay sensitive (e.g., bufferless not tolerate loss but are not delay sensitive (e.g., bufferless
sensors). Time or loss sensitive applications may have somewhat sensors). Time- or loss-sensitive applications may have somewhat
special requirements especially for loss (e.g., no loss over two special requirements, especially for loss (e.g., no loss over two
consecutive communication cycles; very low outage time, etc.). consecutive communication cycles, very low outage time, etc.).
DetNet flows have the following attributes: DetNet flows have the following attributes:
a. DnFlowID (Section 5.1) a. DnFlowID (Section 5.1)
b. DnPayloadType (Section 5.2) b. DnPayloadType (Section 5.2)
c. DnFlowFormat (Section 5.3) c. DnFlowFormat (Section 5.3)
d. DnFlowSpecification (Section 5.4) d. DnFlowSpecification (Section 5.4)
e. DnTrafficSpecification (Section 5.5) e. DnTrafficSpecification (Section 5.5)
f. DnFlowEndpoints (Section 5.6) f. DnFlowEndpoints (Section 5.6)
g. DnFlowRank (Section 5.7) g. DnFlowRank (Section 5.7)
h. DnFlowStatus (Section 5.8) h. DnFlowStatus (Section 5.8)
DetNet flows have the following requirement attributes: DetNet flows have the following requirement attributes:
o DnFlowRequirements (Section 5.9) a. DnFlowRequirements (Section 5.9)
o DnFlowBiDir (Section 5.10) b. DnFlowBiDir (Section 5.10)
Flow attributes are described in the following sections. Flow attributes are described in the following sections.
5.1. Management ID of the DetNet Flow 5.1. Management ID of the DetNet Flow
A unique (management) identifier is needed for each DetNet flow A unique (management) identifier is needed for each DetNet flow
within the DetNet domain. It is specified by DnFlowID. It can be 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. used to define the N:1 mapping of DetNet flows to a DetNet service.
5.2. Payload type of the DetNet Flow 5.2. Payload Type of the DetNet Flow
The DnPayloadType attribute is set according to the encapsulated App- The DnPayloadType attribute is set according to the encapsulated App-
flow format. The attribute can be Ethernet, MPLS, or IP. flow format. The attribute can be Ethernet, MPLS, or IP.
5.3. Format of the DetNet Flow 5.3. Format of the DetNet Flow
The DnFlowFormat attribute is set according to the DetNet PSN The DnFlowFormat attribute is set according to the DetNet PSN
technology. The attribute can be MPLS or IP. technology. The attribute can be MPLS or IP.
5.4. Identification and Specification of DetNet Flows 5.4. Identification and Specification of DetNet Flows
Identification options for DetNet flows at the Ingress/Egress and Identification options for DetNet flows at the Ingress/Egress and
within the DetNet domain are specified as follows; see Section 5.4.1 within the DetNet domain are specified as follows; see Section 5.4.1
for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows. for DetNet MPLS flows and Section 5.4.2 for DetNet IP flows.
5.4.1. DetNet MPLS Flow Identification and Specification 5.4.1. DetNet MPLS Flow Identification and Specification
The identification of DetNet MPLS flows within the DetNet domain is The identification of DetNet MPLS flows within the DetNet domain is
based on the MPLS context in the service information model. The based on the MPLS context in the service information model. The
attributes are specific to the MPLS forwarding paradigm within the attributes are specific to the MPLS forwarding paradigm within the
DetNet domain [I-D.ietf-detnet-mpls]. DetNet MPLS flows can be DetNet domain [RFC8964]. DetNet MPLS flows can be identified and
identified and specified by the following attributes: specified by the following attributes:
a. SLabel a. SLabel
b. FLabelStack b. FLabelStack
5.4.2. DetNet IP Flow Identification and Specification 5.4.2. DetNet IP Flow Identification and Specification
DetNet IP flows can be identified and specified by the following DetNet IP flows can be identified and specified by the following
attributes [RFC8939]: attributes [RFC8939]:
a. SourceIpAddress a. SourceIpAddress
b. DestinationIpAddress b. DestinationIpAddress
c. IPv6FlowLabel c. IPv6FlowLabel
d. Dscp (attribute) d. Dscp
e. Protocol e. Protocol
f. SourcePort f. SourcePort
g. DestinationPort g. DestinationPort
h. IPSecSpi h. IPSecSpi
The IP 6-tuple that is used for DetNet IP flow identification 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 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 attributes that can be used for DetNet flow identification in
addition to the 6-tuple. 6-tuple and use of wild cards for these addition to the 6-tuple. The 6-tuple and use of wild cards for these
attributes are specified in [RFC8939]. attributes are specified in [RFC8939].
5.5. Traffic Specification of the DetNet Flow 5.5. Traffic Specification of the DetNet Flow
DnTrafficSpecification attributes specify how the DN Ingress The DnTrafficSpecification attributes specify how the DN Ingress
transmits packets for the DetNet flow. This is effectively the transmits packets for the DetNet flow. This is effectively the
promise/request of the DN Ingress to the network. The network uses promise/request of the DN Ingress to the network. The network uses
this traffic specification to allocate resources and adjust queue this traffic specification to allocate resources and adjust queue
parameters in network nodes. parameters in network nodes.
TrafficSpecification has the following attributes: TrafficSpecification has the following attributes:
a. Interval: the period of time in which the traffic specification a. Interval: the period of time in which the traffic specification
is specified. is specified
b. MaxPacketsPerInterval: the maximum number of packets that the b. MaxPacketsPerInterval: the maximum number of packets that the
Ingress will transmit in one Interval. Ingress will transmit in one Interval
c. MaxPayloadSize: the maximum payload size that the Ingress will c. MaxPayloadSize: the maximum payload size that the Ingress will
transmit. transmit
d. MinPayloadSize: the minimum payload size that the Ingress will d. MinPayloadSize: the minimum payload size that the Ingress will
transmit. transmit
e. MinPacketsPerInterval: the minimum number of packets that the e. MinPacketsPerInterval: the minimum number of packets that the
Ingress will transmit in one Interval. Ingress will transmit in one Interval
These attributes can be used to describe any type of traffic (e.g., These attributes can be used to describe any type of traffic (e.g.,
CBR, VBR, etc.) and can be used during resource allocation to CBR, Variable Bitrate (VBR), etc.) and can be used during resource
represent worst case scenarios. Intervals are specified as an allocation to represent worst-case scenarios. Intervals are
integer number of nanoseconds. PayloadSizes are specified in octets. specified as an integer number of nanoseconds. PayloadSizes are
specified in octets.
Flows exceeding the traffic specification (i.e., having more traffic Flows exceeding the traffic specification (i.e., having more traffic
than defined by the maximum attributes) may receive a different than defined by the maximum attributes) may receive a different
network behavior than the DetNet network has been engineered for. network behavior than the DetNet network has been engineered for.
Excess traffic due to malicious or malfunctioning devices can be Excess traffic due to malicious or malfunctioning devices can be
prevented or mitigated (e.g., through the use of existing mechanisms prevented or mitigated (e.g., through the use of existing mechanisms,
such as policing and shaping). such as policing and shaping).
When MinPayloadSize and MinPacketsPerInterval parameters are used, When MinPayloadSize and MinPacketsPerInterval parameters are used,
then all packets less than the MinPayloadSize will be counted as all packets less than the MinPayloadSize will be counted as being of
being of the size MinPayloadSize during packet processing when packet the size MinPayloadSize during packet processing when packet size
size matters, e.g., when policing; and all flows having less than matters, e.g., when policing; all flows having less than
MinPacketsPerInterval will be counted as having MinPacketsPerInterval MinPacketsPerInterval will be counted as having MinPacketsPerInterval
when the number of packets per interval matters, e.g., during when the number of packets per interval matters, e.g., during
resource reservation. However, flows having less than resource reservation. However, flows having less than
MinPacketsPerInterval may result in a different network behavior than MinPacketsPerInterval may result in a different network behavior than
the DetNet network has been engineered for. MinPayloadSize and the DetNet network has been engineered for. MinPayloadSize and
MinPacketsPerInterval parameters, for example, may be used when MinPacketsPerInterval parameters, for example, may be used when
engineering the latency bounds of a DetNet flow when POF is applied engineering the latency bounds of a DetNet flow when Packet Ordering
to the given DetNet flow. Function (POF) is applied to the given DetNet flow.
Further optional attributes can be considered to achieve more Further optional attributes can be considered to achieve more
efficient resource allocation. Such optional attributes might be efficient resource allocation. Such optional attributes might be
worth for flows with soft requirements (i.e., the flow is only loss worth for flows with soft requirements (i.e., the flow is only loss
sensitive or only delay sensitive, but not both delay-and-loss sensitive or only delay sensitive but not both delay and loss
sensitive). Possible options how to extend DnTrafficSpecification sensitive). Possible options about how to extend
attributes is for further discussion. DnTrafficSpecification attributes is for further discussion.
5.6. Endpoints of the DetNet Flow 5.6. Endpoints of the DetNet Flow
The DnFlowEndpoints attribute defines the starting and termination The DnFlowEndpoints attribute defines the start and end reference
reference points of the DetNet flow by pointing to the ingress points of the DetNet flow by pointing to the ingress interface/node
interface/node and egress interface(s)/node(s). Depending on the and egress interface(s)/node(s). Depending on the network scenario,
network scenario it defines an interface or a node. Interface can be it defines an interface or a node. Interface can be defined, for
defined for example if the App-flow is a TSN Stream and it is example, if the App-flow is a TSN Stream, and it is received over a
received over a well defined UNI (User-to-Network Interface). For well-defined User-to-Network Interface (UNI). For example, for App-
example, for App-flows with MPLS encapsulation defining an ingress flows with MPLS encapsulation, defining an ingress node is more
node is more common when per platform label space is used. common when a per-platform label space is used.
5.7. Rank of the DetNet Flow 5.7. Rank of the DetNet Flow
The DnFlowRank attribute provides the rank of this flow relative to The DnFlowRank attribute provides the rank of this flow relative to
other flows in the DetNet domain. Rank (range: 0-255) is used by the other flows in the DetNet domain. Rank (range: 0-255) is used by the
DetNet domain to decide which flows can and cannot exist when network DetNet domain to decide which flows can and cannot exist when network
resources reach their limit. Rank is used to help to determine which resources reach their limit. Rank is used to help to determine which
flows can be bumped (i.e., removed from node configuration thereby flows can be bumped (i.e., removed from node configuration thereby
releasing its resources) if for example a port of a node becomes releasing its resources) if, for example, a port of a node becomes
oversubscribed (e.g., due to network re-configuration). DnFlowRank oversubscribed (e.g., due to network reconfiguration). DnFlowRank
value 0 is the highest priority. value 0 is the highest priority.
5.8. Status of the DetNet Flow 5.8. Status of the DetNet Flow
DnFlowStatus provides the status of the DetNet flow with respect to The DnFlowStatus attribute provides the status of the DetNet flow
the establishment of the flow by the DetNet domain. with respect to the establishment of the flow by the DetNet domain.
The DnFlowStatus includes the following attributes: DnFlowStatus includes the following attributes:
a. DnIngressStatus is an enumeration for the status of the flow's a. DnIngressStatus is an enumeration for the status of the flow's
Ingress reference point: Ingress reference point:
* None: no Ingress. None: No Ingress.
* Ready: Ingress is ready. Ready: Ingress is ready.
* Failed: Ingress failed. Failed: Ingress failed.
* OutOfService: Administratively blocked. OutOfService: Administratively blocked.
b. DnEgressStatus is an enumeration for the status of the flow's b. DnEgressStatus is an enumeration for the status of the flow's
Egress reference points: Egress reference points:
* None: no Egress. None: No Egress.
* Ready: all Egresses are ready. Ready: All Egresses are ready.
* PartialFailed: One or more Egress ready, and one or more PartialFailed: One or more Egress is ready, and one or more
Egress failed. The DetNet flow can be used if the Ingress is Egress failed. The DetNet flow can be used if the Ingress is
Ready. Ready.
* Failed: All Egresses failed. Failed: All Egresses failed.
* OutOfService: All Egresses are administratively blocked. OutOfService: All Egresses are administratively blocked.
c. FailureCode: A non-zero code that specifies the error if the c. FailureCode is a nonzero code that specifies the error if the
DetNet flow encounters a failure (e.g., packet replication and DetNet flow encounters a failure (e.g., packet replication and
elimination is requested but not possible, or DnIngressStatus is elimination is requested but not possible or DnIngressStatus is
Failed, or DnEgressStatus is Failed, or DnEgressStatus is Failed, DnEgressStatus is Failed, or DnEgressStatus is
PartialFailed). PartialFailed).
Defining FailureCodes for DetNet is out-of-scope in this document. Defining FailureCodes for DetNet is out of scope for this document.
Table 46-1 of [IEEE8021Qcc] describes TSN failure codes. Table 46-1 of [IEEE8021Qcc] describes TSN failure codes.
5.9. Requirements of the DetNet Flow 5.9. Requirements of the DetNet Flow
DnFlowRequirements specifies requirements to ensure the service level The DnFlowRequirements attribute specifies requirements to ensure the
desired for the DetNet flow. service level desired for the DetNet flow.
The DnFlowRequirements includes the following attributes: DnFlowRequirements includes the following attributes:
a. MinBandwidth(Section 5.9.1) a. MinBandwidth (Section 5.9.1)
b. MaxLatency(Section 5.9.2) b. MaxLatency (Section 5.9.2)
c. MaxLatencyVariation(Section 5.9.3) c. MaxLatencyVariation (Section 5.9.3)
d. MaxLoss(Section 5.9.4) d. MaxLoss (Section 5.9.4)
e. MaxConsecutiveLossTolerance(Section 5.9.5) e. MaxConsecutiveLossTolerance (Section 5.9.5)
f. MaxMisordering(Section 5.9.6) f. MaxMisordering (Section 5.9.6)
5.9.1. Minimum Bandwidth of the DetNet Flow 5.9.1. Minimum Bandwidth of the DetNet Flow
MinBandwidth is the minimum bandwidth that has to be guaranteed for MinBandwidth is the minimum bandwidth that has to be guaranteed for
the DetNet flow. MinBandwidth is specified in octets per second. the DetNet flow. MinBandwidth is specified in octets per second.
5.9.2. Maximum Latency of the DetNet Flow 5.9.2. Maximum Latency of the DetNet Flow
MaxLatency is the maximum latency from Ingress to Egress(es) for a MaxLatency is the maximum latency from Ingress to Egress(es) for a
single packet of the DetNet flow. MaxLatency is specified as an single packet of the DetNet flow. MaxLatency is specified as an
integer number of nanoseconds. integer number of nanoseconds.
5.9.3. Maximum Latency Variation of the DetNet Flow 5.9.3. Maximum Latency Variation of the DetNet Flow
MaxLatencyVariation is the difference between the minimum and the MaxLatencyVariation is the difference between the minimum and the
maximum end-to-end one-way latency. MaxLatencyVariation is specified maximum end-to-end, one-way latency. MaxLatencyVariation is
as an integer number of nanoseconds. specified as an integer number of nanoseconds.
5.9.4. Maximum Loss of the DetNet Flow 5.9.4. Maximum Loss of the DetNet Flow
MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for MaxLoss defines the maximum Packet Loss Rate (PLR) requirement for
the DetNet flow between the Ingress and Egress(es) and the loss the DetNet flow between the Ingress and Egress(es) and the loss
measurement interval. measurement interval.
5.9.5. Maximum Consecutive Loss of the DetNet Flow 5.9.5. Maximum Consecutive Loss of the DetNet Flow
Some applications have special loss requirement, such as Some applications have special loss requirements, such as
MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance
parameter describes the maximum number of consecutive packets whose parameter describes the maximum number of consecutive packets whose
loss can be tolerated. The maximum consecutive loss tolerance can be loss can be tolerated. The maximum consecutive loss tolerance can be
measured for example based on sequence number. measured, for example, based on sequence number.
5.9.6. Maximum Misordering Tolerance of the DetNet Flow 5.9.6. Maximum Misordering Tolerance of the DetNet Flow
MaxMisordering describes the tolerable maximum number of packets that MaxMisordering describes the tolerable maximum number of packets that
can be received out of order. The value zero for the maximum allowed can be received out of order. The value zero for the maximum allowed
misordering indicates that in order delivery is required, misordering misordering indicates that in-order delivery is required; misordering
cannot be tolerated. cannot be tolerated.
The maximum allowed misordering can be measured for example based on The maximum allowed misordering can be measured, for example, based
sequence numbers. When a packet arrives at the egress after a packet on sequence numbers. When a packet arrives at the egress after a
with a higher sequence number, the difference between the sequence packet with a higher sequence number, the difference between the
number values cannot be bigger than "MaxMisordering + 1". sequence number values cannot be bigger than "MaxMisordering + 1".
5.10. BiDir requirement of the DetNet Flow 5.10. BiDir Requirement of the DetNet Flow
DnFlowBiDir attribute defines the requirement that the flow and the The DnFlowBiDir attribute defines the requirement that the flow and
corresponding reverse direction flow must share the same path (links the corresponding reverse direction flow must share the same path
and nodes) through the routed or switch network in the DetNet domain, (links and nodes) through the routed or switch network in the DetNet
e.g., to provide congruent paths in the two directions that share domain, e.g., to provide congruent paths in the two directions that
fate and path characteristics. share fate and path characteristics.
6. DetNet Service Related Parameters 6. DetNet Service-Related Parameters
DetNet service have the following attributes: The DetNet service has the following attributes:
a. DnServiceID (Section 6.1) a. DnServiceID (Section 6.1)
b. DnServiceDeliveryType (Section 6.2) b. DnServiceDeliveryType (Section 6.2)
c. DnServiceDeliveryProfile (Section 6.3) c. DnServiceDeliveryProfile (Section 6.3)
d. DNServiceConnectivity (Section 6.4) d. DNServiceConnectivity (Section 6.4)
e. DnServiceBiDir (Section 6.5) e. DnServiceBiDir (Section 6.5)
f. DnServiceRank (Section 6.6) f. DnServiceRank (Section 6.6)
g. DnServiceStatus (Section 6.7) g. DnServiceStatus (Section 6.7)
Service attributes are described in the following sections. Service attributes are described in the following sections.
6.1. Management ID of the DetNet service 6.1. Management ID of the DetNet Service
A unique (management) identifier for each DetNet service within the The DnServiceId attribute is a unique (management) identifier for
DetNet domain. It can be used to define the many to one mapping of each DetNet service within the DetNet domain. It can be used to
DetNet flows to a DetNet service. define the many-to-one mapping of DetNet flows to a DetNet service.
6.2. Delivery Type of the DetNet service 6.2. Delivery Type of the DetNet Service
The DnServiceDeliveryType attribute is set according to the payload The DnServiceDeliveryType attribute is set according to the payload
of the served DetNet flow (i.e., the encapsulated App-flow format). of the served DetNet flow (i.e., the encapsulated App-flow format).
The attribute can be Ethernet, MPLS, or IP. The attribute can be Ethernet, MPLS, or IP.
6.3. Delivery Profile of the DetNet Service 6.3. Delivery Profile of the DetNet Service
DnServiceDeliveryProfile specifies delivery profile to ensure proper The DnServiceDeliveryProfile attribute specifies the delivery profile
serving of the DetNet flow. to ensure proper serving of the DetNet flow.
The DnServiceDeliveryProfile includes the following attributes: DnServiceDeliveryProfile includes the following attributes:
a. MinBandwidth(Section 6.3.1) a. MinBandwidth (Section 6.3.1)
b. MaxLatency(Section 6.3.2) b. MaxLatency (Section 6.3.2)
c. MaxLatencyVariation(Section 6.3.3) c. MaxLatencyVariation (Section 6.3.3)
d. MaxLoss(Section 6.3.4) d. MaxLoss (Section 6.3.4)
e. MaxConsecutiveLossTolerance(Section 6.3.5) e. MaxConsecutiveLossTolerance (Section 6.3.5)
f. MaxMisordering(Section 6.3.6) f. MaxMisordering (Section 6.3.6)
6.3.1. Minimum Bandwidth of the DetNet Service 6.3.1. Minimum Bandwidth of the DetNet Service
MinBandwidth is the minimum bandwidth that has to be guaranteed for MinBandwidth is the minimum bandwidth that has to be guaranteed for
the DetNet service. MinBandwidth is specified in octets per second the DetNet service. MinBandwidth is specified in octets per second
and excludes additional DetNet header (if any). and excludes additional DetNet header (if any).
6.3.2. Maximum Latency of the DetNet Service 6.3.2. Maximum Latency of the DetNet Service
MaxLatency is the maximum latency from Ingress to Egress(es) for a MaxLatency is the maximum latency from Ingress to Egress(es) for a
single packet of the DetNet flow. MaxLatency is specified as an single packet of the DetNet flow. MaxLatency is specified as an
integer number of nanoseconds. integer number of nanoseconds.
6.3.3. Maximum Latency Variation of the DetNet Service 6.3.3. Maximum Latency Variation of the DetNet Service
MaxLatencyVariation is the difference between the minimum and the MaxLatencyVariation is the difference between the minimum and the
maximum end-to-end one-way latency. MaxLatencyVariation is specified maximum end-to-end, one-way latency. MaxLatencyVariation is
as an integer number of nanoseconds. specified as an integer number of nanoseconds.
6.3.4. Maximum Loss of the DetNet Service 6.3.4. Maximum Loss of the DetNet Service
MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the MaxLoss defines the maximum Packet Loss Rate (PLR) parameter for the
DetNet service between the Ingress and Egress(es) of the DetNet DetNet service between the Ingress and Egress(es) of the DetNet
domain. domain.
6.3.5. Maximum Consecutive Loss of the DetNet Service 6.3.5. Maximum Consecutive Loss of the DetNet Service
Some applications have special loss requirement, such as Some applications have a special loss requirement, such as
MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance
parameter describes the maximum number of consecutive packets whose parameter describes the maximum number of consecutive packets whose
loss can be tolerated. The maximum consecutive loss tolerance can be loss can be tolerated. The maximum consecutive loss tolerance can be
measured for example based on sequence number. measured, for example, based on sequence number.
6.3.6. Maximum Misordering Tolerance of the DetNet Service 6.3.6. Maximum Misordering Tolerance of the DetNet Service
MaxMisordering describes the tolerable maximum number of packets that MaxMisordering describes the tolerable maximum number of packets that
can be received out of order. The maximum allowed misordering can be can be received out of order. The maximum allowed misordering can be
measured for example based on sequence number. The value zero for measured, for example, based on sequence number. The value zero for
the maximum allowed misordering indicates that in order delivery is the maximum allowed misordering indicates that in-order delivery is
required, misordering cannot be tolerated. required; misordering cannot be tolerated.
6.4. Connectivity Type of the DetNet Service 6.4. Connectivity Type of the DetNet Service
Two connectivity types are distinguished: point-to-point (p2p) and Two connectivity types are distinguished: point-to-point (p2p) and
point-to-multipoint (p2mp). Connectivity type p2mp may be created by point-to-multipoint (p2mp). Connectivity type p2mp may be created by
a forwarding function (e.g., p2mp LSP). (Note: from service a forwarding function (e.g., p2mp LSP). (Note that from a service
perspective mp2mp connectivity can be treated as a superposition of perspective, mp2mp connectivity can be treated as a superposition of
p2mp connections.) p2mp connections.)
6.5. BiDir requirement of the DetNet Service 6.5. BiDir Requirement of the DetNet Service
The DnServiceBiDir attribute defines the requirement that the flow The DnServiceBiDir attribute defines the requirement that the flow
and the corresponding reverse direction flow must share the same path and the corresponding reverse direction flow must share the same path
(links and nodes) through the routed or switch network in the DetNet (links and nodes) through the routed or switch network in the DetNet
domain, e.g., to provide congruent paths in the two directions that domain, e.g., to provide congruent paths in the two directions that
share fate and path characteristics. share fate and path characteristics.
6.6. Rank of the DetNet Service 6.6. Rank of the DetNet Service
The DnServiceRank attribute provides the rank of a service instance The DnServiceRank attribute provides the rank of a service instance
relative to other services in the DetNet domain. DnServiceRank relative to other services in the DetNet domain. DnServiceRank
(range: 0-255) is used by the network in case of network resource (range: 0-255) is used by the network in case of network resource
limitation scenarios. DnServiceRank value 0 is the highest priority. limitation scenarios. DnServiceRank value 0 is the highest priority.
6.7. Status of the DetNet Service 6.7. Status of the DetNet Service
DnServiceStatus information group includes elements that specify the The DnServiceStatus information group includes elements that specify
status of the service specific state of the DetNet domain. This the status of the service-specific state of the DetNet domain. This
information group informs the user whether or not the service is information group informs the user whether or not the service is
ready for use. ready for use.
The DnServiceStatus includes the following attributes: DnServiceStatus includes the following attributes:
a. DnServiceIngressStatus is an enumeration for the status of the a. DnServiceIngressStatus is an enumeration for the status of the
service's Ingress: service's Ingress:
* None: no Ingress. None: No Ingress.
* Ready: Ingress is ready. Ready: Ingress is ready.
* Failed: Ingress failed. Failed: Ingress failed.
* OutOfService: Administratively blocked. OutOfService: Administratively blocked.
b. DnServiceEgressStatus is an enumeration for the status of the b. DnServiceEgressStatus is an enumeration for the status of the
service's Egress: service's Egress:
* None: no Egress. None: No Egress.
* Ready: all Egresses are ready. Ready: All Egresses are ready.
* PartialFailed: One or more Egress ready, and one or more PartialFailed: One or more Egress is ready, and one or more
Egress failed. The DetNet flow can be used if the Ingress is Egress failed. The DetNet flow can be used if the Ingress is
Ready. Ready.
* Failed: All Egresses failed. Failed: All Egresses failed.
* OutOfService: Administratively blocked. OutOfService: Administratively blocked.
c. DnServiceFailureCode: A non-zero code that specifies the error if c. DnServiceFailureCode is a nonzero code that specifies the error
the DetNet service encounters a failure (e.g., packet replication if the DetNet service encounters a failure (e.g., packet
and elimination is requested but not possible, or replication and elimination is requested but not possible or
DnServiceIngressStatus is Failed, or DnServiceEgressStatus is DnServiceIngressStatus is Failed, DnServiceEgressStatus is
Failed, or DnServiceEgressStatus is PartialFailed). Failed, or DnServiceEgressStatus is PartialFailed).
Defining DnServiceFailureCodes for DetNet service is out-of-scope in Defining DnServiceFailureCodes for DetNet service is out of scope for
this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure
codes. codes.
7. Flow Specific Operations 7. Flow-Specific Operations
The DetNet flow information model relies on three high level The DetNet flow information model relies on three high-level
information groups: information groups:
o DnIngress: The DnIngress information group includes elements that DnIngress: The DnIngress information group includes elements that
specify the source for a single DetNet flow. This information specify the source for a single DetNet flow. This information
group is applied from the user of the DetNet service to the group is applied from the user of the DetNet service to the
network. network.
o DnEgress: The DnEgress information group includes elements that DnEgress: The DnEgress information group includes elements that
specify the destination for a single DetNet flow. This specify the destination for a single DetNet flow. This
information group is applied from the user of the DetNet service information group is applied from the user of the DetNet service
to the network. to the network.
o DnFlowStatus: The status information group includes elements that DnFlowStatus: The DnFlowStatus information group includes elements
specify the status of the flow in the network. This information that specify the status of the flow in the network. This
group is applied from the network to the user of the DetNet information group is applied from the network to the user of the
service. This information group informs the user whether or not DetNet service. This information group informs the user whether
the DetNet flow is ready for use. or not the DetNet flow is ready for use.
There are three possible operations for each DetNet flow with respect There are three possible operations for each DetNet flow with respect
to its DetNet service at a DN Ingress or a DN Egress (similarly to to its DetNet service at a DN Ingress or a DN Egress (similar to App-
App-flows at a Source or a Destination): flows at a source or a destination):
o Join: DN Ingress/DN Egress intends to join the flow.
o Leave: DN Ingress/DN Egress intends to leave the flow.
o Modify: DN Ingress/DN Egress intends to change the flow. 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 7.1. Join Operation
For the join operation, the DnFlowSpecification, DnFlowRank, For the join operation, the DnFlowSpecification, DnFlowRank,
DnFlowEndpoint, and DnTrafficSpecification are included within the DnFlowEndpoint, and DnTrafficSpecification are included within the
DnIngress or DnEgress information group. For the join operation, the DnIngress or DnEgress information groups. For the join operation,
DnServiceRequirements groups can be included. the DnServiceRequirements groups can be included.
7.2. Leave Operation 7.2. Leave Operation
For the leave operation, the DnFlowSpecification and DnFlowEndpoint For the leave operation, the DnFlowSpecification and DnFlowEndpoint
are included within the DnIngress or DnEgress information group. are included within the DnIngress or DnEgress information groups.
7.3. Modify Operation 7.3. Modify Operation
For the modify operation, the DnFlowSpecification, DnFlowRank, For the modify operation, the DnFlowSpecification, DnFlowRank,
DnFlowEndpoint, and DnTrafficSpecification are included within the DnFlowEndpoint, and DnTrafficSpecification are included within the
DnIngress or DnEgress information group. For the join operation, the DnIngress or DnEgress information group. For the join operation, the
DnServiceRequirements groups can be included. DnServiceRequirements groups can be included.
The Modify operation can be considered to address cases when a flow The Modify operation can be considered to address cases when a flow
is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been
changed. The advantage of having a Modify is that it allows changed. The advantage of having a Modify is that it allows
initiation of a change of flow spec while leaving the current flow is initiation of a change of flow spec while leaving the current flow
operating until the change is accepted. If there is no linkage operating until the change is accepted. If there is no linkage
between the Join and the Leave, then while figuring out whether the between the Join and the Leave, then while figuring out whether the
new flow spec can be supported, the controller entity has to assume new flow spec can be supported, the controller entity has to assume
that the resources committed to the current flow are in use. By that the resources committed to the current flow are in use. By
using Modify the controller entity knows that the resources using Modify, the controller entity knows that the resources
supporting the current flow can be available for supporting the supporting the current flow can be available for supporting the
altered flow. Modify is considered to be an optional operation due altered flow. Modify is considered to be an optional operation due
to possible controller plane limitations. to possible controller plane limitations.
8. Summary 8. Summary
This document describes the DetNet flow information model and the This document describes the DetNet flow information model and the
service information model for DetNet IP networks and DetNet MPLS service information model for DetNet IP networks and DetNet MPLS
networks. These models are used as input for creating the DetNet networks. These models are used as input for creating the DetNet-
specific YANG model. specific YANG module.
9. IANA Considerations 9. IANA Considerations
N/A. This document has no IANA actions.
10. Security Considerations 10. Security Considerations
The external interfaces of the DetNet domain need to be subject to The external interfaces of the DetNet domain need to be subject to
appropriate confidentiality. Additionally, knowledge of which flows/ appropriate confidentiality. Additionally, knowledge of which flows/
services are provided to a customer or delivered by a network services are provided to a customer or delivered by a network
operator may supply information that can be used in a variety of operator may supply information that can be used in a variety of
security attacks. Security considerations for DetNet are described security attacks. Security considerations for DetNet are described
in detail in [I-D.ietf-detnet-security]. General security in detail in [DETNET-SECURITY]. General security considerations are
considerations are described in [RFC8655]. This document discusses described in [RFC8655]. This document discusses modeling the
modeling the information, not how it is exchanged. information, not how it is exchanged.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
detnet-mpls-13 (work in progress), October 2020.
[IEEE8021Qcc] [IEEE8021Qcc]
IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE IEEE, "IEEE Standard for Local and Metropolitan Area
Standard for Local and metropolitan area networks - Networks--Bridges and Bridged Networks -- Amendment 31:
Bridges and Bridged Networks -- Amendment 31: Stream Stream Reservation Protocol (SRP) Enhancements and
Reservation Protocol (SRP) Enhancements and Performance Performance Improvements",
Improvements", 2018, DOI 10.1109/IEEESTD.2018.8514112, IEEE 802.1Qcc-2018,
October 2013,
<https://ieeexplore.ieee.org/document/8514112/>. <https://ieeexplore.ieee.org/document/8514112/>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane: Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>. <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 11.2. Informative References
[I-D.ietf-detnet-security] [DETNET-SECURITY]
Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic Grossman, E., Mizrahi, T., and A. J. Hacker,
Networking (DetNet) Security Considerations", draft-ietf- "Deterministic Networking (DetNet) Security
detnet-security-13 (work in progress), December 2020. Considerations", Work in Progress, Internet-Draft, draft-
ietf-detnet-security-16, 2 March 2021,
<https://tools.ietf.org/html/draft-ietf-detnet-security-
16>.
[I-D.ietf-detnet-yang] [DETNET-YANG]
Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and
Z. Li, "Deterministic Networking (DetNet) Configuration Z. Li, "Deterministic Networking (DetNet) YANG Model",
YANG Model", draft-ietf-detnet-yang-09 (work in progress), Work in Progress, Internet-Draft, draft-ietf-detnet-yang-
November 2020. 11, 19 February 2021,
<https://tools.ietf.org/html/draft-ietf-detnet-yang-11>.
[IEEE8021Q] [IEEE8021Q]
IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE IEEE, "IEEE Standard for Local and Metropolitan Area
Standard for Local and metropolitan area networks - Networks--Bridges and Bridged Networks",
Bridges and Bridged Networks", 2018, DOI 10.1109/IEEESTD.2018.8403927, IEEE 802.1Q-2018, July
<https://ieeexplore.ieee.org/document/8403927>. 2018, <https://ieeexplore.ieee.org/document/8403927>.
[IEEE8021Qbv] [IEEE8021Qbv]
IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE IEEE, "IEEE Standard for Local and metropolitan area
Standard for Local and metropolitan area networks - networks -- Bridges and Bridged Networks - Amendment 25:
Bridges and Bridged Networks - Amendment 25: Enhancements Enhancements for Scheduled Traffic",
for Scheduled Traffic", 2015, DOI 10.1109/IEEESTD.2016.8613095, IEEE 802.1Qbv-2015,
<https://ieeexplore.ieee.org/document/7572858/>. March 2016,
<https://ieeexplore.ieee.org/document/8613095>.
[IETFDetNet] [IETFDetNet]
IETF, "IETF Deterministic Networking (DetNet) Working IETF, "Deterministic Networking (detnet)",
Group", <https://datatracker.ietf.org/wg/detnet/charter/>. <https://datatracker.ietf.org/wg/detnet/charter/>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>. <https://www.rfc-editor.org/info/rfc8938>.
Authors' Addresses Authors' Addresses
Balazs Varga Balázs Varga
Ericsson Ericsson
Magyar tudosok korutja 11 Budapest
Budapest 1117 Magyar Tudosok krt. 11.
1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Janos Farkas
János Farkas
Ericsson Ericsson
Magyar tudosok korutja 11 Budapest
Budapest 1117 Magyar Tudosok krt. 11.
1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Rodney Cummings Rodney Cummings
National Instruments National Instruments
11500 N. Mopac Expwy
Bldg. C Bldg. C
Austin, TX 78759-3504 11500 N. Mopac Expwy
USA Austin, TX 78759-3504
United States of America
Email: rodney.cummings@ni.com Email: rodney.cummings@ni.com
Yuanlong Jiang Yuanlong Jiang
Huawei Technologies Co., Ltd. Huawei
Bantian, Longgang district Bantian, Longgang district
Shenzhen
Shenzhen 518129 518129
China China
Email: jiangyuanlong@huawei.com Email: jiangyuanlong@huawei.com
Don Fedyk Don Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: dfedyk@labn.net Email: dfedyk@labn.net
 End of changes. 162 change blocks. 
417 lines changed or deleted 427 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/