draft-ietf-detnet-flow-information-model-04.txt   draft-ietf-detnet-flow-information-model-05.txt 
DetNet J. Farkas DetNet J. Farkas
Internet-Draft B. Varga Internet-Draft B. Varga
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 9, 2020 R. Cummings Expires: March 14, 2020 R. Cummings
National Instruments National Instruments
Y. Jiang Y. Jiang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
July 08, 2019 D. Fedyk
LabN Consulting, L.L.C.
September 11, 2019
DetNet Flow Information Model DetNet Flow Information Model
draft-ietf-detnet-flow-information-model-04 draft-ietf-detnet-flow-information-model-05
Abstract Abstract
This document describes flow and service information model for This document describes 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 Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on March 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 5 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 6 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 7
2.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.4. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7
3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7
3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 8
3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8
4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 9
4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 9
4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9
5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 10
5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10
5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 11
5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 11
5.4. Identification and Specification of DetNet Flows . . . . 10 5.4. Identification and Specification of DetNet Flows . . . . 11
5.4.1. DetNet MPLS Flow Identification and Specification . . 11 5.4.1. DetNet MPLS Flow Identification and Specification . . 11
5.4.2. DetNet IP Flow Identification and Specification . . . 11 5.4.2. DetNet IP Flow Identification and Specification . . . 11
5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11 5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11
5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12 5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12
5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12
5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 12 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 13
5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13
5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14
5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14
5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14
5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14
5.9.5. Maximum Consequtive Loss of the DetNet Flow . . . . . 14 5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14
5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14
5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14
6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15
6.1. Management ID of the DetNet service . . . . . . . . . . . 15 6.1. Management ID of the DetNet service . . . . . . . . . . . 15
6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15
6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15
6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 16 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 15
6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16
6.3.3. Maximum Latency Variation of the DetNet Service . . . 16 6.3.3. Maximum Latency Variation of the DetNet Service . . . 16
6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16
6.3.5. Maximum Consequtive Loss of the DetNet Service . . . 16 6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 16
6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16 6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16
6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16
6.5. BiDir requirement of the DetNet Service . . . . . . . . . 17 6.5. BiDir requirement of the DetNet Service . . . . . . . . . 16
6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17
6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17
7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18
7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18
7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 19 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 18
7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 19 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 18
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
A Deterministic Networking (DetNet) service provides a capability to Deterministic Networking (DetNet) provides a capability to carry
carry a unicast or a multicast data flow for an application with specified unicast or multicast data flows for real-time applications
constrained requirements on network performance, e.g., low packet with extremely low packet loss rates and assured maximum end-to-end
loss rate and/or latency. DetNet and TSN have common architecture as delivery latency. A description of the general background and
expressed in [IETFDetNet] and [I-D.ietf-detnet-architecture]. The concepts of DetNet can be found in [I-D.ietf-detnet-architecture].
DetNet service is provided for DetNet flows via the DetNet service
and forwarding sub-layers.
DetNet service is IP or MPLS and DetNet is currently defined for IP This document describes the Detnet Flow Service Information Model.
and MPLS networks as shown in Figure 1 based on Figure 2 and Figure 3 For reference [RFC3444] describes the rational behind Information
of [I-D.ietf-detnet-data-plane-framework]. A DetNet flow includes Models in general. This document describes the Flow and Service
one or more App-flow(s) as payload. App-flows can be Ethernet, MPLS, information models for operators and users to understand Detnet
or IP flows, which impacts what header fields are use in order to services, and for implementors as a guide to the functionality
identify a flow. DetNet flows are created by DetNet encapsulation of required by Detnet services.
App-flow(s) (e.g., with added MPLS labels, etc.). In some scenarios
The DetNet Architecture treats the DetNet related data plane
functions decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide
DetNet service protection and reordering. The forwarding sub-layer
provides resource allocation (to ensure low loss, assured latency,
and limited out-of-order delivery) and leverages Traffic Engineering
mechanisms.
In the IETF 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 Figure 3 of [I-D.ietf-detnet-data-plane-framework].
IEEE 802.1 Time Sensitive Networking (TSN) utilizes Ethernet and is
defined over Ethernet networks. A DetNet flow includes one or more
App-flow(s) as payload. App-flows can be Ethernet, MPLS, or IP
flows, which impacts which header fields are utilized to identify a
flow. DetNet flows are identified by the DetNet encapsulation of
App-flow(s) (e.g., MPLS labels, IP 6-tuple etc.). In some scenarios
App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow
over a DetNet IP network). 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 |
+-----+---------+ +-----+-------+ +-----+---------+ +-----+-------+
skipping to change at page 4, line 17 skipping to change at page 4, line 32
e.g., at DetNet flow aggregation or in a sub-network that e.g., at DetNet flow aggregation or in a sub-network that
interconnects DetNet nodes. 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 In a given network scenario three information models can
distinguished: distinguished:
o Flow models describe characteristics of data flows. These models o Flow models that describe characteristics of data flows. These
describe in detail all relevant aspects of a flow that are needed models describe in detail all relevant aspects of a flow that are
to support the flow properly by the network between the source and needed to support the flow properly by the network between the
the destination(s). source and the destination(s).
o Service models describe characteristics of services being provided o Service models that describe characteristics of services being
for data flows over a network. These models can be treated as a provided for data flows over a network. These models can be
network operator independent information model. treated as a network operator independent information model.
o Configuration models describe in detail the settings required on o Configuration models that describe in detail the settings required
network nodes to serve a data flow properly. on network nodes to provide a data flow proper service.
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
skipping to change at page 5, line 7 skipping to change at page 5, line 25
+-+ | 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 DetNet flow and service information model is based on
[I-D.ietf-detnet-architecture] and on the concept of data model [I-D.ietf-detnet-architecture] and on the concept of data model
specified by [IEEE8021Qcc]. Furthermore, the starting point of the specified by [IEEE8021Qcc]. Furthermore, the origination of the
DetNet flow information model was the flow identification DetNet flow information model was the flow identification
possibilities described in [IEEE8021CB], which is used by possibilities described in [IEEE8021CB], which is used by
[IEEE8021Qcc] as well. In addition to TSN data model, [IEEE8021Qcc] [IEEE8021Qcc] as well. In addition to the TSN data model,
also specifies configuration of TSN features (e.g., traffic [IEEE8021Qcc] also specifies configuration of TSN features (e.g.,
scheduling specified by [IEEE8021Qbv]). Due to the common traffic scheduling specified by [IEEE8021Qbv]). The common
architecture and flow model, configuration features can be leveraged architecture and flow model, allow configured features to be
in certain deployment scenarios, e.g., when the network that provides consistent in certain deployment scenarios, e.g., when the network
the DetNet service includes both L3 and L2 network segments. that provides the DetNet service includes both L3 and L2 network
segments.
1.1. Goals 1.1. Goals
As it is expressed in the Charter [IETFDetNet], the DetNet WG As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates
collaborates with IEEE 802.1 TSN in order to define a common with IEEE 802.1 TSN in order to define a common architecture for both
architecture for both Layer 2 and Layer 3, which is beneficial for Layer 2 and Layer 3. This is beneficial for several reasons, e.g.,
various reasons, e.g., in order to simplify implementations. The in order to simplify implementations and maintain consistency across
flow and service information models should be also aligned along diverse networks. The flow and service information models are also
those lines. Therefore, the DetNet flow and service information aligned for those reasons. Therefore, the DetNet flow and service
models described in this document are based on [IEEE8021Qcc], which information models described in this document are based on
is an amendment to [IEEE8021Q]. [IEEE8021Qcc], which is an amendment to [IEEE8021Q].
This document intends to specify flow and service information models This document specifies flow and service information models only.
only.
1.2. Non Goals 1.2. Non Goals
This document (this revision) does not intend to specify either flow This document (this revision) does not specify flow data models or
data model or DetNet configuration. From these aspects, the goals of DetNet configuration. Therefore, the goals of this document differ
this document differ from the goals of [IEEE8021Qcc], which also from the goals of [IEEE8021Qcc], which also specifies the TSN data
specifies data model and configuration of certain TSN features. model and configuration of certain TSN features.
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 [I-D.ietf-detnet-architecture] and the the DetNet Data architecture [I-D.ietf-detnet-architecture] and the DetNet Data Plane
Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader Framework [I-D.ietf-detnet-data-plane-framework]. The reader is
is assumed to be familiar with these documents and any terminology assumed to be familiar with these documents and any terminology
defined therein. The DetNet <=> TSN dictionary of defined therein. The DetNet <=> TSN dictionary of
[I-D.ietf-detnet-architecture] is used to perform translation from [I-D.ietf-detnet-architecture] is used to perform translation from
[IEEE8021Qcc] to this document. [IEEE8021Qcc] to this document.
The following terminology is used according to The following terminology is used in accordance with
[I-D.ietf-detnet-architecture]: [I-D.ietf-detnet-architecture]:
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 DetNet flow is a sequence of packets which conform
uniquely to a flow identifier, and to which the DetNet uniquely to a flow identifier, and to which the DetNet
service is to be provided. It includes any DetNet service is to be provided. It includes any DetNet
headers added to support the DetNet service and headers added to 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 DetNet flow, where it starts. 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 DetNet flow, where it terminates. DN Egress Reference point for the termination 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.
skipping to change at page 7, line 8 skipping to change at page 7, line 32
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 Names SHOULD be descriptive. o Names SHOULD be descriptive.
o Names MUST start with uppercase letters. o Names MUST start with uppercase letters.
o Composed names MUST use capital letters for the first letter of o Composed names MUST use capital letters for the first letter of
each component. All other letters are lowercase, even for each component. All other letters are lowercase, even for
acronyms. Exceptions are made for acronyms containing a mixture acronyms. Exceptions are made for acronyms containing a mixture
of lowercase and capital letters, such as IPv6. Examples are of lowercase and capital letters, such as IPv6. Example composed
SourceMacAddress and DestinationIPv6Address. names are SourceMacAddress and DestinationIPv6Address.
2.4. Requirements Language 2.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 [I-D.ietf-detnet-architecture] show the Figure 5 and Figure 8 in [I-D.ietf-detnet-architecture] show the
DetNet service related reference points and main components. DetNet service related 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 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
have reference points named as DN Ingress (where it starts) and DN has reference points termed DN Ingress (where a DetNet flow starts)
Egress (where it ends). These reference points may coexist in the and DN Egress (where a DetNet flow ends). These reference points may
same node (e.g., in a DetNet IP end system). DN Ingress and DN coexist in the same node (e.g., in a DetNet IP end system). DN
Egress reference points are intermediate reference points for a Ingress and DN Egress reference points are intermediate reference
served App-flow. points for a served App-flow.
All reference points are assumed in this document to be packet-based All reference points are assumed in this document 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 model relies on
three groups of information elements: three groups of information elements:
o App-flow related paramaters: they describe the App-flow o 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 specification, endpoints, status, etc.) and the App-flow service
requirements (e.g., delay, loss, etc.). expectations (e.g., delay, loss, etc.).
o DetNet flow related parameters: they describe the DetNet flow o 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: they describe the expected o 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 App-flows In the information model a DetNet flow contains one or more
(N:1 mapping). During DetNet aggregation the aggregated DetNet flows (aggregated) App-flows (N:1 mapping). During DetNet aggregation the
are treated as App-flows and the aggregate is the DetNet flow, which aggregated DetNet flows are treated simply as App-flows and the
provides N:1 mapping. Similarly, there is a M:1 relationship of aggregate is the DetNet flow, which provides N:1 mapping. Similarly,
DetNet flow(s) and a DetNet Service. there is an aggregated many to one relationship for the DetNet
flow(s) to the DetNet Service.
4. App-flow Related Parameters 4. App-flow Related Parameters
Deterministic service is required by time/loss sensitive When Deterministic 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). Such a data exchange has various requirements on delay and/ peer(s), the resulting data exchange has various requirements on
or loss parameters. delay and/or loss parameters.
4.1. App-flow Characteristics 4.1. App-flow Characteristics
App-flow characteristics are described with the following parameters: App-flow characteristics are described by the following parameters:
o FlowID: it is a unique (management) identifier of the App-flow. o FlowID: a unique (management) identifier of the App-flow. It can
It can be used to define the N:1 mapping of App-flows to a DetNet be used to define the N:1 mapping of App-flows to a DetNet flow.
flow.
o FlowType: it is set according to the encapsulation format of the o FlowType: set by the encapsulation format of the flow. It can be
flow. It can be Ethernet (TSN), MPLS, or IP. Ethernet (TSN), MPLS, or IP.
o DataFlowSpecification: it is a flow descriptor, defining which o DataFlowSpecification: a flow descriptor, defining which packets
packets belongs to a flow using, e.g., FlowType specific packet belongs to a flow using, specific packet header fields such as
header fields like src-addr, dst-addr, label, VLAN-ID, etc. src-addr, dst-addr, label, VLAN-ID, etc.
o TrafficSpecification: it is a flow descriptor, defining traffic o TrafficSpecification: a flow descriptor, defining traffic
parameters like packet size, interval, and max. packets per parameters such as packet size, transmission time interval, and
interval. maximum packets per time interval.
o FlowEndpoints: it defines the start and termination reference o FlowEndpoints: delineate the start and termination reference
points of the App-flow by pointing to the source interface/node points of the App-flow by pointing to the source interface/node
and destination interface(s)/node(s). and destination interface(s)/node(s).
o FlowStatus: it provides the status of the App-flow with respect to o FlowStatus: indicates the status of the App-flow with respect to
the establishment of the flow by the network, e.g., ready, failed, the establishment of the flow by the connected network, e.g.,
etc. ready, failed, etc.
o FlowRank: it provides the rank of this flow relative to other o FlowRank: indicates the rank of this flow relative to other flows
flows in the network. in the connected network.
4.2. App-flow Requirements 4.2. App-flow Requirements
App-flow requirements are described with the following parameters: App-flow requirements are described by the following parameters:
o FlowRequirements: it defines the requirement of the App-flow o FlowRequirements: defines the attributes of the App-flow regarding
regarding bandwidth, latency, latency variation, loss, and bandwidth, latency, latency variation, loss, and misordering
misorder tolerance. tolerance.
o FlowBiDir: it defines the requirement of the App-flow whether it o FlowBiDir: defines the data path requirement of the App-flow
has to be routed together with other App-flow(s) through the whether it must share the same data path and physical path for
network, e.g., to provide congruent paths in the two directions. both directions through the network, e.g., to provide congruent
paths in the two directions.
5. DetNet Flow Related Parameters 5. DetNet Flow Related Parameters
Data model specified by [IEEE8021Qcc] describes data flows using TSN The Data model specified by [IEEE8021Qcc] describes data flows using
service as periodic flows with fix packet size (i.e., Constant Bit TSN service as periodic flows with fix packet size (i.e., Constant
Rate (CBR) flows) or with variable packet size. The same concept is Bit Rate (CBR) flows) or with variable packet size. The same concept
applyed 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 data loss for an application. However, not all delivery can result data loss for an application. However, not all
applications require hard limits on both parameters (latency and applications require hard limits on both latency and loss. For
loss). For example, some real-time applications allow graceful example, some real-time applications allow graceful degradation if
degradation if loss happens (e.g., sample-based processing, media loss happens (e.g., sample-based data processing, media
distribution). Some others may require high-bandwidth connections distribution). Some other applications may require high-bandwidth
that make the usage of techniques like packet replication connections that make use of packet replication techniques which are
economically challenging or even impossible. Some applications may economically challenging or even impossible. Some applications may
not tolerate loss, but are not latency sensitive (e.g., bufferless not tolerate loss, but are not delay sensitive (e.g., bufferless
sensors). Time/loss sensitive applications may have somewhat special sensors). Time or loss sensitive applications may have somewhat
requirements especially for loss (e.g., no loss in two consecutive special requirements especially for loss (e.g., no loss over two
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) o DnFlowRequirements (Section 5.9)
o DnFlowBiDir (Section 5.10) o 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 in DnFlowID. It can be within the DetNet domain. It is specified by DnFlowID. It can be
used to define the M:1 mapping of DetNet flows to a DetNet service. used to define the many to one mapping of DetNet flows to a DetNet
service.
5.2. Payload type of the DetNet Flow 5.2. Payload type of the DetNet Flow
DnPayloadType attribute is set according to encapsulated App-flow The DnPayloadType attribute is set according to the encapsulated App-
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
DnFlowFormat attribute is set according to DetNet PSN technology. The DnFlowFormat attribute is set according to the DetNet PSN
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 DetNetw IP flows.
5.4.1. DetNet MPLS Flow Identification and Specification 5.4.1. DetNet MPLS Flow Identification and Specification
Identification of DetNet MPLS flows within the DetNet domain are used The identification of DetNet MPLS flows within the DetNet domain is
in the service information model. The attributes are specific to the based on the MPLS context in the service information model. The
MPLS forwarding paradigm within the DetNet domain attributes are specific to the MPLS forwarding paradigm within the
[I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be identified and DetNet domain [I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be
specified by the following attributes: identified and 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 (6-tuple) [I-D.ietf-detnet-ip]: attributes (6-tuple) [I-D.ietf-detnet-ip]:
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
5.5. Traffic Specification of the DetNet Flow 5.5. Traffic Specification of the DetNet Flow
DnTrafficSpecification attributes specify how the DN Ingress 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.
skipping to change at page 11, line 47 skipping to change at page 12, line 8
DnTrafficSpecification attributes specify how the DN Ingress 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
cannot be exceeded. 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.
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, VBR, etc.) and can be used during resource allocation to
represent worst case scenarios. represent worst case scenarios.
[[Editor's note (to be removed from a future revision): Further [[Editor's note (to be removed from a future revision): Further
optional attributes can be considered to achieve more efficient optional attributes can be considered to achieve more efficient
resource allocation. Such optional attributes might be worth for resource allocation. Such optional attributes might be worth for
flows with soft requirements (i.e., the flow is only loss sensitive flows with soft requirements (i.e., the flow is only loss sensitive
or only delay sensitive, but not both d elay-and-loss sensitive). or only delay sensitive, but not both delay-and-loss sensitive).
Possible options how to extend DnTrafficSpecification attributes is Possible options how to extend DnTrafficSpecification attributes is
for further discussion. ]] for further discussion. ]]
5.6. Endpoints of the DetNet Flow 5.6. Endpoints of the DetNet Flow
DnFlowEndpoints attribute defines the starting and termination The DnFlowEndpoints attribute defines the starting and termination
reference points of the DetNet flow by pointing to the ingress reference points of the DetNet flow by pointing to the ingress
interface/node and egress interface(s)/node(s). Depending on the interface/node and egress interface(s)/node(s). Depending on the
network scenario it defines an interface or a node. Interface can be network scenario it defines an interface or a node. Interface can be
defined for example if the App-flow is a TSN Stream and it is defined for example if the App-flow is a TSN Stream and it is
received over a well defined UNI interface. For exampe for App-flows received over a well defined UNI interface. For example, for App-
with MPLS encapsulation defining an ingress node is more common when flows with MPLS encapsulation defining an ingress node is more common
per platform label space is used. when per platform label space is used.
5.7. Rank of the DetNet Flow 5.7. Rank of the DetNet Flow
DnFlowRank provides the rank of this flow relative to other flows in The DnFlowRank attribute provides the rank of this flow relative to
the DetNet domain. Rank (range: 0-255) is used by the DetNet domain other flows in the DetNet domain. Rank (range: 0-255) is used by the
to decide which flows can and cannot exist when network resources DetNet domain to decide which flows can and cannot exist when network
reach their limit. Rank is used to help to determine which flows can resources reach their limit. Rank is used to help to determine which
be dropped (i.e., removed from node configuration) if for example a flows can be bumped (i.e., removed from node configuration thereby
port of a node becomes oversubscribed (e.g., due to network re- releasing its resources) if for example a port of a node becomes
configuration). oversubscribed (e.g., due to network re-configuration).
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 DnFlowStatus provides the status of the DetNet flow with respect to
the establishment of the flow by the DetNet domain. the establishment of the flow by the DetNet domain.
The DnFlowStatus SHALL include the following attributes: The DnFlowStatus SHALL include 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:
skipping to change at page 13, line 4 skipping to change at page 13, line 16
DnFlowStatus provides the status of the DetNet flow with respect to DnFlowStatus provides the status of the DetNet flow with respect to
the establishment of the flow by the DetNet domain. the establishment of the flow by the DetNet domain.
The DnFlowStatus SHALL include the following attributes: The DnFlowStatus SHALL include 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 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. FailureCode: A non-zero code that specifies the problem if the c. FailureCode: A non-zero 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, or DnEgressStatus is Failed, or DnEgressStatus is
PartialFailed). PartialFailed).
[[Editor's note (to be removed from a future revision): FailureCodes [[Editor's note (to be removed from a future revision): FailureCodes
to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN
failure codes.]] failure codes.]]
5.9. Requirements of the DetNet Flow 5.9. Requirements of the DetNet Flow
DnFlowRequirements specifies requirements to ensure proper serving of DnFlowRequirements specifies requirements to ensure the service level
the DetNet flow. desired for the DetNet flow.
The DnFlowRequirements includes the following attributes: The DnFlowRequirements includes the following attributes:
a. MinBandwidth a. MinBandwidth(Section 5.9.1)
b. MaxLatency(Section 5.9.2)
b. MaxLatency c. MaxLatencyVariation(Section 5.9.3)
d. MaxLoss(Section 5.9.4)
c. MaxLatencyVariation e. MaxConsecutiveLossTolerance(Section 5.9.5)
f. MaxMisordering(Section 5.9.6)
d. MaxLoss
e. MaxConsecutiveLossTolerance
f. MaxMisordering
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. 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. maximum end-to-end one-way latency. MaxLatencyVariation is 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 Ratio (PLR) requirement for
the DetNet flow between the Ingress and Egress(es). the DetNet flow between the Ingress and Egress(es).
5.9.5. Maximum Consequtive Loss of the DetNet Flow 5.9.5. Maximum Consecutive Loss of the DetNet Flow
Some applications have special loss requirement, like Some applications have 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.
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 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.
5.10. BiDir requirement of the DetNet Flow 5.10. BiDir requirement of the DetNet Flow
DnFlowBiDir attribute defines the requirement whether the served DnFlowBiDir attribute defines the requirement that the flow and the
packets have to be routed together with packets of other flows corresponding reverse direction flow must share the same path (links
through the DetNet domain, e.g., to provide congruent paths in the and nodes) through the routed or switch network in the DetNet domain,
two directions. e.g., to provide congruent paths in the two directions that share
fate and path characteristics.
6. DetNet Service Related Parameters 6. DetNet Service Related Parameters
DetNet service have the following attributes: DetNet service have 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 is needed for each DetNet service A unique (management) identifier for each DetNet service within the
within the DetNet domain. It is specified in DnServiceID. It can be DetNet domain. It can be used to define the many to one mapping of
used to define the M:1 mapping of DetNet flows to a DetNet service. DetNet flows to a DetNet service.
6.2. Delivery Type of the DetNet service 6.2. Delivery Type of the DetNet service
DnServiceDeliveryType attribute is set according to the payload of The DnServiceDeliveryType attribute is set according to the payload
the served DetNet flow (i.e., the encapsulated App-flow format). The of the served DetNet flow (i.e., the encapsulated App-flow format).
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 DnServiceDeliveryProfile specifies delivery profile to ensure proper
serving of the DetNet flow. serving of the DetNet flow.
The DnServiceDeliveryProfile includes the following attributes: The DnServiceDeliveryProfile includes the following attributes:
a. MinBandwidth a. MinBandwidth(Section 6.3.1)
b. MaxLatency(Section 6.3.2)
b. MaxLatency c. MaxLatencyVariation(Section 6.3.3)
d. MaxLoss(Section 6.3.4)
c. MaxLatencyVariation e. MaxConsecutiveLossTolerance(Section 6.3.5)
f. MaxMisordering(Section 6.3.6)
d. MaxLoss
e. MaxConsecutiveLossTolerance
f. MaxMisordering
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. the DetNet service. MinBandwidth is specified in octets per second.
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. maximum end-to-end one-way latency. MaxLatencyVariation is 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 Ratio (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 Consequtive Loss of the DetNet Service 6.3.5. Maximum Consecutive Loss of the DetNet Service
Some applications have special loss requirement, like Some applications have 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
skipping to change at page 17, line 7 skipping to change at page 16, line 48
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 is created by a point-to-multipoint (p2mp). Connectivity type p2mp is created by a
transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity
is a superposition of p2mp connections.) is a superposition of p2mp connections.)
6.5. BiDir requirement of the DetNet Service 6.5. BiDir requirement of the DetNet Service
DnServiceBiDir attribute defines the requirement whether the served The DnServiceBiDir attribute defines the requirement that the flow
packets have to be routed together with packets of other service and the corresponding reverse direction flow must share the same path
instances through the DetNet domain, e.g., to provide congruent paths (links and nodes) through the routed or switch network in the DetNet
in the two directions. domain, e.g., to provide congruent paths in the two directions that
share fate and path characteristics.
6.6. Rank of the DetNet Service 6.6. Rank of the DetNet Service
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. limitation scenarios.
6.7. Status of the DetNet Service 6.7. Status of the DetNet Service
DnServiceStatus information group includes elements that specify the DnServiceStatus information group includes elements that specify the
status of the service specific state of the DetNet domain. This 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.
skipping to change at page 17, line 32 skipping to change at page 17, line 25
status of the service specific state of the DetNet domain. This 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 SHALL include the following attributes: The DnServiceStatus SHALL include 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 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 problem c. DnServiceFailureCode: A non-zero code that specifies the error if
if the DetNet service encounters a failure (e.g., packet the DetNet service encounters a failure (e.g., packet replication
replication and elimination is requested but not possible, or and elimination is requested but not possible, or
DnServiceIngressStatus is Failed, or DnServiceEgressStatus is DnServiceIngressStatus is Failed, or DnServiceEgressStatus is
Failed, or DnServiceEgressStatus is PartialFailed). Failed, or DnServiceEgressStatus is PartialFailed).
[[Editor's note (to be removed from a future revision): [[Editor's note (to be removed from a future revision):
DnServiceFailureCodes to be defined for DetNet service. Table 46-1 DnServiceFailureCodes to be defined for DetNet service. Table 46-1
of [IEEE8021Qcc] describes TSN failure codes.]] of [IEEE8021Qcc] describes TSN failure 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
skipping to change at page 19, line 17 skipping to change at page 19, line 5
For the leave operation, the DnFlowSpecification and DnFlowEndpoint For the leave operation, the DnFlowSpecification and DnFlowEndpoint
SHALL be included within the DnIngress or DnEgress information group. SHALL be included within the DnIngress or DnEgress information group.
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 SHALL be included within DnFlowEndpoint, and DnTrafficSpecification SHALL be 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 MAY be included. the DnServiceRequirements groups MAY be included.
Modify operation can be considered to address cases when a flow is The Modify operation can be considered to address cases when a flow
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 to changed. The advantage of having a Modify is that it allows
initiate a change of flow spec while leaving the current flow is initiation of a change of flow spec while leaving the current flow is
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 in figuring out whether the new between the Join and the Leave, then while figuring out whether the
flow spec can be supported, the controller entity has to assume that new flow spec can be supported, the controller entity has to assume
the resources committed to the current flow are in use. Via Modify that the resources committed to the current flow are in use. By
the controller entity knows that the resources supporting the current using Modify the controller entity knows that the resources
flow can be available for supporting the altered flow. Modify is supporting the current flow can be available for supporting the
considered to be an optional operation due to possible controller altered flow. Modify is considered to be an optional operation due
plane limitations. to possible controller plane limitations.
8. Summary 8. Summary
This document describes DetNet flow information model and service This document describes DetNet flow information model and service
information model for DetNet IP networks and DetNet MPLS networks. information model for DetNet IP networks and DetNet MPLS networks.
9. IANA Considerations 9. IANA Considerations
N/A. N/A.
10. Security Considerations 10. Security Considerations
N/A. Security considerations for DetNet are described in detail in
[I-D.ietf-detnet-security]. General security considerations are
described in [I-D.ietf-detnet-architecture]. This section covers
security for the Flow Information Model and there are no additional
security considerations introduced by this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019. detnet-architecture-13 (work in progress), May 2019.
skipping to change at page 20, line 20 skipping to change at page 20, line 10
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-01 (work in progress), July 2019. draft-ietf-detnet-mpls-01 (work in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
RFC 6003, DOI 10.17487/RFC6003, October 2010,
<https://www.rfc-editor.org/info/rfc6003>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-01 Framework", draft-ietf-detnet-data-plane-framework-01
(work in progress), July 2019. (work in progress), July 2019.
[I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-05 (work in progress), August 2019.
[IEEE8021CB] [IEEE8021CB]
IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE
Standard for Local and metropolitan area networks - Frame Standard for Local and metropolitan area networks - Frame
Replication and Elimination for Reliability", 2017, Replication and Elimination for Reliability", 2017,
<https://ieeexplore.ieee.org/document/8091139/>. <https://ieeexplore.ieee.org/document/8091139/>.
[IEEE8021Q] [IEEE8021Q]
IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE
Standard for Local and metropolitan area networks - Standard for Local and metropolitan area networks -
Bridges and Bridged Networks", 2018, Bridges and Bridged Networks", 2018,
skipping to change at page 21, line 20 skipping to change at page 21, line 13
<https://ieeexplore.ieee.org/document/7572858/>. <https://ieeexplore.ieee.org/document/7572858/>.
[IEEE8021Qcc] [IEEE8021Qcc]
IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE
Standard for Local and metropolitan area networks - Standard for Local and metropolitan area networks -
Bridges and Bridged Networks -- Amendment 31: Stream Bridges and Bridged Networks -- Amendment 31: Stream
Reservation Protocol (SRP) Enhancements and Performance Reservation Protocol (SRP) Enhancements and Performance
Improvements", 2018, Improvements", 2018,
<https://ieeexplore.ieee.org/document/8514112/>. <https://ieeexplore.ieee.org/document/8514112/>.
[IEEE8021TSN]
IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN)
Task Group", <http://www.ieee802.org/1/pages/tsn.html>.
[IETFDetNet] [IETFDetNet]
IETF, "IETF Deterministic Networking (DetNet) Working IETF, "IETF Deterministic Networking (DetNet) Working
Group", <https://datatracker.ietf.org/wg/detnet/charter/>. Group", <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>.
Authors' Addresses Authors' Addresses
Janos Farkas Janos Farkas
Ericsson Ericsson
Magyar tudosok korutja 11 Magyar tudosok korutja 11
Budapest 1117 Budapest 1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
skipping to change at page 22, line 4 skipping to change at page 21, line 39
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Balazs Varga Balazs Varga
Ericsson Ericsson
Magyar tudosok korutja 11 Magyar tudosok korutja 11
Budapest 1117 Budapest 1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Rodney Cummings Rodney Cummings
National Instruments National Instruments
11500 N. Mopac Expwy 11500 N. Mopac Expwy
Bldg. C Bldg. C
Austin, TX 78759-3504 Austin, TX 78759-3504
USA USA
Email: rodney.cummings@ni.com Email: rodney.cummings@ni.com
Yuanlong Jiang Yuanlong Jiang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Bantian, Longgang district Bantian, Longgang district
Shenzhen 518129 Shenzhen 518129
China China
Email: jiangyuanlong@huawei.com Email: jiangyuanlong@huawei.com
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
 End of changes. 124 change blocks. 
262 lines changed or deleted 249 lines changed or added

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