< draft-ietf-detnet-flow-information-model-03.txt   draft-ietf-detnet-flow-information-model-04.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: September 12, 2019 R. Cummings Expires: January 9, 2020 R. Cummings
National Instruments National Instruments
Y. Jiang Y. Jiang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
March 11, 2019 July 08, 2019
DetNet Flow Information Model DetNet Flow Information Model
draft-ietf-detnet-flow-information-model-03 draft-ietf-detnet-flow-information-model-04
Abstract Abstract
This document describes flow and service information model for This document describes flow and service information model for
Deterministic Networking (DetNet). The DetNet service is provided Deterministic Networking (DetNet). These models are defined for IP
either for a Layer 3 or a Layer 2 flow. This document provides and MPLS DetNet data planes
DetNet flow and service information model both for Layer 3 and Layer
2 flows in an integrated fashion.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 12, 2019. This Internet-Draft will expire on January 9, 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. ToDo list . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions Used in This Document . . . . . . . . . . . . . . 5 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 5
4. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
5. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 6 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 6
6. Service model . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Requirements Language . . . . . . . . . . . . . . . . . . 7
6.1. Service overview . . . . . . . . . . . . . . . . . . . . 6 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7
6.2. Service parameters . . . . . . . . . . . . . . . . . . . 6 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7
6.3. Reference Points . . . . . . . . . . . . . . . . . . . . 8 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7
6.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 9 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8
7. End System and DetNet domain . . . . . . . . . . . . . . . . 9 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8
8. DetNet flows . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8
8.1. Identification and Specification of Flows . . . . . . . . 11 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9
8.1.1. IP flow Identification and Specification at UNI . . . 12 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9
8.1.2. L2 Flow Identification and Specification at UNI . . . 12 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10
8.1.3. DetNet Flow Identification and Specification . . . . 13 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10
8.2. Traffic Specification . . . . . . . . . . . . . . . . . . 13 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10
8.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Identification and Specification of DetNet Flows . . . . 10
9. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. DetNet MPLS Flow Identification and Specification . . 11
10. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4.2. DetNet IP Flow Identification and Specification . . . 11
11. Common Attributes of Source and Destination . . . . . . . . . 16 5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11
11.1. End System Interfaces . . . . . . . . . . . . . . . . . 16 5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12
11.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12
11.3. User to Network Requirements . . . . . . . . . . . . . . 17 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 12
12. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13
13. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14
14. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14
14.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 19 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14
15. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14
15.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20 5.9.5. Maximum Consequtive Loss of the DetNet Flow . . . . . 14
15.2. Interface Configuration . . . . . . . . . . . . . . . . 21 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14
15.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14
16. Service Rank . . . . . . . . . . . . . . . . . . . . . . . . 22 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15
17. Service-status . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Management ID of the DetNet service . . . . . . . . . . . 15
18. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15
20. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 16
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16
21.1. Normative References . . . . . . . . . . . . . . . . . . 23 6.3.3. Maximum Latency Variation of the DetNet Service . . . 16
21.2. Informative References . . . . . . . . . . . . . . . . . 23 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.5. Maximum Consequtive Loss of the DetNet Service . . . 16
6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16
1. ToDo list 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16
6.5. BiDir requirement of the DetNet Service . . . . . . . . . 17
These further actions are due on the draft: 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17
6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17
o Align with updated architecture and data plane documents (partly 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18
done). 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18
7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 19
7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 19
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
o App-flow parameters will not be defined in detail (add references 1. Introduction
only, e.g., 802.1Qcc). We focus on DetNet flows.
o Clarification on relationship between DetNet flow model and DetNet A Deterministic Networking (DetNet) service provides a capability to
service model. carry a unicast or a multicast data flow for an application with
constrained requirements on network performance, e.g., low packet
loss rate and/or latency. DetNet and TSN have common architecture as
expressed in [IETFDetNet] and [I-D.ietf-detnet-architecture]. The
DetNet service is provided for DetNet flows via the DetNet service
and forwarding sub-layers.
o Parameter set needs finalization, some re-org of the set may be DetNet service is IP or MPLS and DetNet is currently defined for IP
needed. and MPLS networks as shown in Figure 1 based on Figure 2 and Figure 3
of [I-D.ietf-detnet-data-plane-framework]. A DetNet flow includes
one or more App-flow(s) as payload. App-flows can be Ethernet, MPLS,
or IP flows, which impacts what header fields are use in order to
identify a flow. DetNet flows are created by DetNet encapsulation of
App-flow(s) (e.g., with added MPLS labels, etc.). In some scenarios
App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow
over a DetNet IP network).
o Sort out which parameter belongs to DetNet flow model and which to +-----+
DetNet service model. | TSN |
+-------+ +-+-----+-+
| DN IP | | DN MPLS |
+--+--+----+----+ +-+---+-----+-+
| TSN | DN MPLS | | TSN | DN IP |
+-----+---------+ +-----+-------+
o Clarify relationship between App-flow and DetNet flow (N:1 vs Figure 1: DetNet Service Examples as per Data Plane Framework
1:1).
2. Introduction As shown in Figure 1 as per [I-D.ietf-detnet-data-plane-framework] a
DetNet flow can be treated as an application level flow (App-flow)
e.g., at DetNet flow aggregation or in a sub-network that
interconnects DetNet nodes.
A Deterministic Networking (DetNet) service provides a capability to The DetNet flow and service information model provided by this
carry a unicast or a multicast data flow for an application with document contains both DetNet flow and App-flow specific information
constrained requirements on network performance, e.g., low packet in an integrated fashion.
loss rate and/or latency. The DetNet service is provided either for
a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network,
see, e.g., [I-D.ietf-detnet-dp-sol-mpls]. Similarly, Time-Sensitive
Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged
network. DetNet and TSN have common architecture as expressed in
[IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can
be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and
DetNet L2 flows. Therefore, the DetNet flow and service information
model provided by this document covers both DetNet L3 flows and
DetNet L2 flows 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 describe characteristics of data flows. These models
describe in detail all relevant aspects of a flow that are needed describe in detail all relevant aspects of a flow that are needed
to support the flow properly by the network between the source and to support the flow properly by the network between the source and
the destination(s). the destination(s).
o Service models describe characteristics of services being provided o Service models describe characteristics of services being provided
for data flows over a network. These models can be treated as a for data flows over a network. These models can be treated as a
network operator independent information model. network operator independent information model.
o Configuration models describe in detail the settings required on o Configuration models describe in detail the settings required on
network nodes to serve a data flow properly. network nodes to serve a data flow properly.
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 1. 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 1: 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 data model specified by [I-D.ietf-detnet-architecture] and on the concept of data model
[IEEE8021Qcc]. Furthermore, the DetNet flow information model relies specified by [IEEE8021Qcc]. Furthermore, the starting point of the
on the flow identification possibilities described in [IEEE8021CB], DetNet flow information model was the flow identification
which is used by [IEEE8021Qcc] as well. In addition to TSN data possibilities described in [IEEE8021CB], which is used by
model, [IEEE8021Qcc] also specifies configuration of TSN features [IEEE8021Qcc] as well. In addition to TSN data model, [IEEE8021Qcc]
(e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the also specifies configuration of TSN features (e.g., traffic
common architecture and flow model, configuration features can be scheduling specified by [IEEE8021Qbv]). Due to the common
leveraged in certain deployment scenarios, e.g., when the network architecture and flow model, configuration features can be leveraged
that provides the DetNet service includes both L3 and L2 network in certain deployment scenarios, e.g., when the network that provides
segments. the DetNet service includes both L3 and L2 network segments.
Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see
Section 4), this document (this revision) only considers the
Centralized Network / Distributed User Model out of the models
specified by [IEEE8021Qcc]. That is, there is a User-Network
Interface (UNI) between an end system and a network. Furthermore,
there is a central entity for the control of the network. For
instance, the central entity implements a Path Computation Element
(PCE) for the calculation and establishment of paths needed for
packet replication and elimination, if any.
2.1. Goals 1.1. Goals
As it is expressed in the Charter [IETFDetNet], the DetNet WG As it is expressed in the Charter [IETFDetNet], the DetNet WG
collaborates with IEEE 802.1 TSN in order to define a common collaborates with IEEE 802.1 TSN in order to define a common
architecture for both Layer 2 and Layer 3, which is beneficial for architecture for both Layer 2 and Layer 3, which is beneficial for
various reasons, e.g., in order to simplify implementations. The various reasons, e.g., in order to simplify implementations. The
flow and service information models should be also common along those flow and service information models should be also aligned along
lines. As the TSN flow information/data model specified by those lines. Therefore, the DetNet flow and service information
[IEEE8021Qcc] is mature, the DetNet flow and service information
models described in this document are based on [IEEE8021Qcc], which models described in this document are based on [IEEE8021Qcc], which
is an amendment to [IEEE8021Q]. is an amendment to [IEEE8021Q].
This document intends to specify flow and service information models This document intends to specify flow and service information models
only. only.
2.2. Non Goals 1.2. Non Goals
This document (this revision) does not intend to specify either flow This document (this revision) does not intend to specify either flow
data model or DetNet configuration. From these aspects, the goals of data model or DetNet configuration. From these aspects, the goals of
this document differ from the goals of [IEEE8021Qcc], which also this document differ from the goals of [IEEE8021Qcc], which also
specifies data model and configuration of certain TSN features. specifies data model and configuration of certain TSN features.
3. Conventions Used in This Document 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2.1. Terms Used in This Document
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The lowercase forms with an initial capital "Must", "Must Not", This document uses the terminology established in the DetNet
"Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" architecture [I-D.ietf-detnet-architecture] and the the DetNet Data
in this document are to be interpreted in the sense defined in Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader
[RFC2119], but are used where the normative behavior is defined in is assumed to be familiar with these documents and any terminology
documents published by SDOs other than the IETF. defined therein. The DetNet <=> TSN dictionary of
[I-D.ietf-detnet-architecture] is used to perform translation from
[IEEE8021Qcc] to this document.
4. Terminology and Definitions The following terminology is used according to
[I-D.ietf-detnet-architecture]:
This document uses the terminology established in Section 2 of the App-flow The payload (data) carried over a DetNet service.
DetNet architecture document [I-D.ietf-detnet-architecture]. The
DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used
to perform translation from [IEEE8021Qcc] to this document.
Application level flows (app-flow) can be L2 or L3 flows, what may
impact what header fields are use in order to identify a flow.
DetNet flows are created by proper DetNet encapsulation of app-
flow(s) (e.g., with added MPLS labels, etc.). In some scenarios App-
flow and DetNet flow looks similar on the wire (e.g., L3 App-flow
over a DetNet IP network).
5. Naming Conventions DetNet flow A DetNet flow is a sequence of packets which conform
uniquely to a flow identifier, and to which the DetNet
service is to be provided. It includes any DetNet
headers added to support the DetNet service and
forwarding sub-layers.
The following terminology is introduced in this document:
Source Reference point for an App-flow, where the flow starts.
Destination Reference point for an App-flow, where the flow
terminates.
DN Ingress Reference point for DetNet flow, where it starts.
Networking technology specific encapsulation may be
added here to the served App-flow(s).
DN Egress Reference point for DetNet flow, where it terminates.
Networking technology specific encapsulation may be
removed here from the served App-flow(s).
2.2. Abbreviations
The following abbreviations are used in this document:
DetNet Deterministic Networking.
DN DetNet.
MPLS Multiprotocol Label Switching.
PSN Packet Switched Network.
TSN Time-Sensitive Networking.
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 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. Examples are
SourceMacAddress and DestinationIPv6Address. SourceMacAddress and DestinationIPv6Address.
6. Service model 2.4. Requirements Language
6.1. Service overview The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. DetNet Domain and its Modeling
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.
The simplest DetNet service is to provide bridging over the DN domain
(i.e., tunneling for L2), where the connected hosts are in the same
broadcast (BC) domain. Forwarding over the DetNet domain is based on
L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is
DetNet Routing service that provides routing, so available only for
L3 hosts that are in different BC domains. Forwarding over the
DetNet domain is based on L3 (IP) addresses (i.e. dst-IP).
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.
6.2. Service parameters 3.2. Reference Points Used in Modeling
A DetNet network receives DetNet flows via a UNI as shown in Figure 5
in [I-D.ietf-detnet-architecture]. The DetNet network connects the
UNIs via tunnels in order to provide DetNet service as shown in
Figure 8 in [I-D.ietf-detnet-architecture].
The DetNet service attributes are the following:
o Service type
It is the flow type (L2 or L3) using the DetNet service.
o Bandwidth
It is the minimum bandwidth guaranteed for the DetNet service.
o Delay parameters
The are two delay parameters for a DetNet service:
* Maximum latency, which is the maximum end-to-end one-way
latency for the DetNet service.
* Packet Delay Variation (PDV), which is the difference between
the minimum and the maximum end-to-end one-way latency. The
PDV parameter describes the maximum packet delay variation for
the DetNet service. (Note that PDV is sometimes referred to as
jitter.)
o Loss parameters
* The maximum Packet Loss Ratio (PLR) parameter describes the
maximum packet loss ratio for the DetNet service between the
edges of the DetNet network.
* Some applications have special loss requirement. The maximum
consecutive loss tolerance parameter describes the maximum
number of consecutive packets whose loss can be tolerated. The
maximum consecutive loss tolerance can be measured based on
sequence number.
o Maximum allowed misordering
Maximum allowed misordering describes the tolerable maximum number
of packets that can be received out of order. The maximum allowed
misordering can be measured based on sequence number. The value
zero for the maximum allowed misordering indicates that in order
delivery is required, misordering cannot be tolerated.
o Connectivity type
Two connectivity types are distinguished: point-to-point (p2p) and
point-to-multipoint (p2mp). Connectivity type p2mp is created by
a transport layer function (e.g., p2mp LSP). (Note: mp2mp
connectivity is a superposition of p2mp connections.)
o Service rank
Service rank provides the rank of a service instance relative to
other services in the network. Rank is used by the network in
case of network resource limitation scenarios.
6.3. Reference Points
From service model design perspective a fundamental question is the
location of the service endpoints, i.e., where the service starts and
ends.
+--------+
| |
| X X |
| ____ |
| / \ |
| |
|/\/\/\/\|
To be ADDED
404 Not Found
Figure 2: FIGURE Placeholder Reference Points
Note: Further discussion is needed based on data plane encapsulation
results what reference points should be defined. Only some possible
examples listed here:
o App-flow endpoint: End system's internal reference point for the
native data flow.
o DetNet-UNI: UNI interface ("U") on a DetNet edge node.
o DetNet-NNI: NNI interface ("N") between DetNet domains. From service design perspective a fundamental question is the
location of the service/flow endpoints, i.e., where the service/flow
starts and ends.
[[NOTE: Contributions are welcome whether we should define or App-flow specific reference points are the Source (where it starts)
distinguish internal reference point(s) for DetNet-aware end-systems and the Destination (where it terminates). Similarly a DetNet flow
as well. ]] have reference points named as DN Ingress (where it starts) and DN
Egress (where it ends). These reference points may coexist in the
same node (e.g., in a DetNet IP end system). DN Ingress and DN
Egress reference points are intermediate reference points for a
served App-flow.
DetNet-UNI and DetNet-NNI are assumed in this document to be packet- All reference points are assumed in this document to be packet-based
based reference points and provide connectivity over the packet reference points. A DN Ingress may add and a DN Egress may remove
network and between domains. A DetNet-UNI may add networking networking technology specific encapsulation to/from the served App-
technology specific encapsulation to the data flow in order to flow(s) (e.g., MPLS label(s), UDP and IP headers).
transport it over the network.
[[NOTE: Differences between the service over end-systems internal 3.3. Information Elements
reference points and DetNet-UNI is for further discussions. For
example, in-order delivery is expected in end system internal
reference points, whereas it is considered optional over the DetNet-
UNI. ]]
6.4. Service scenarios The DetNet flow information model and the service model relies on
three groups of information elements:
Using the above defined reference points, two major service scenarios o App-flow related paramaters: they describe the App-flow
can be identified: characteristics (e.g., identification, encapsulation, traffic
specification, endpoints, status, etc.) and the App-flow
requirements (e.g., delay, loss, etc.).
o End-to-End-Service: the service reaches out to final source or o DetNet flow related parameters: they describe the DetNet flow
destination nodes, so it is an e2e service between application characteristics (e.g., identification, format, traffic
hosting devices (end systems). specification, endpoints, rank, etc.).
o DetNet-Service: the service connects networking islands, so it is o DetNet service related parameters: they describe the expected
a service between the borders of network domain(s). service characteristics (e.g., delivery type, connectivity delay/
loss, status, rank, etc.).
[[NOTE: we may consider to define further scenarios based on the In the information model a DetNet flow contains one or more App-flows
result of reference point related discussions. ]] (N:1 mapping). During DetNet aggregation the aggregated DetNet flows
are treated as App-flows and the aggregate is the DetNet flow, which
provides N:1 mapping. Similarly, there is a M:1 relationship of
DetNet flow(s) and a DetNet Service.
7. End System and DetNet domain 4. App-flow Related Parameters
Deterministic service is required by time/loss sensitive 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). Such a data exchange has various requirements on delay and/
or loss parameters. or loss parameters.
The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes 4.1. App-flow Characteristics
two kinds of end systems: Source and Destination. The same
distinction is applied for the DetNet flow information model. In
addition to the end systems interested in a flow, the status
information of the flow is also important. Therefore, the DetNet
flow information model relies on three high level groups:
o Source: an end system capable of sourcing a DetNet flow. The
Source information group includes elements that specify the Source
for a single flow. This information group is applied from the
user to the network.
o Destination: an end system that is a destination of a DetNet flow.
The Destination information group includes elements that specify
the Destination for a single flow. This information group is
applied from the user to the network.
o Flow-Status: the status of a DetNet flow. The status information
group includes elements that specify the status of the flow in the
network. This information group is applied from the network to
the user. This information group informs the user whether or not
the flow is ready for use.
From service perspective two kinds of edge nodes can be
distinguished: Ingress and Egress. In addition the technology of the
DetNet domain and the status of the service are also important.
Therefore, the DetNet service information model relies on four high App-flow characteristics are described with the following parameters:
level groups:
o Ingress: an edge system receiving a DetNet flow from a Source. o FlowID: it is a unique (management) identifier of the App-flow.
The Ingress information group includes elements that specify the It can be used to define the N:1 mapping of App-flows to a DetNet
entry point for a single flow. This information group is applied flow.
from the network to the user.
o Egress: an edge system sending traffic towards a Destination of a o FlowType: it is set according to the encapsulation format of the
DetNet flow. The Egress information group includes elements that flow. It can be Ethernet (TSN), MPLS, or IP.
specify the egress point for a single flow. This information
group is applied from the network to the user.
o DetNet Domain: an administrative domain providing the DetNet o DataFlowSpecification: it is a flow descriptor, defining which
service. The DetNet domain information group includes elements packets belongs to a flow using, e.g., FlowType specific packet
that specify the forwarding capabilities and methods for a single header fields like src-addr, dst-addr, label, VLAN-ID, etc.
flow. This information group is applied within the network.
o Service-Status: the status of a DetNet service. The status o TrafficSpecification: it is a flow descriptor, defining traffic
information group includes elements that specify the status of the parameters like packet size, interval, and max. packets per
service specific state of the network. This information group is interval.
applied from the network to the user. This information group
informs the user whether or not the service is ready for use.
There are three operations for each flow with respect to a Source or o FlowEndpoints: it defines the start and termination reference
a Destination (and an Ingress or an Egress): points of the App-flow by pointing to the source interface/node
and destination interface(s)/node(s).
o Join: Source/Destination request to join the flow. o FlowStatus: it provides the status of the App-flow with respect to
the establishment of the flow by the network, e.g., ready, failed,
etc.
o Leave: Source/Destination request to leave the flow. o FlowRank: it provides the rank of this flow relative to other
flows in the network.
o Modify: Source/Destination request to change the flow. 4.2. App-flow Requirements
Modify operation can be considered to address cases when a flow is App-flow requirements are described with the following parameters:
slightly changed, e.g., only MaxPayloadSize (Section 8.2) has been
changed. The advantage of having a Modify is that it allows to
initiate a change of flow spec while leaving the current flow is
operating until the change is accepted. If there is no linkage
between the Join and the Leave, then in figuring out whether the new
flow spec can be supported, the central entity has to assume that the
resources committed to the current flow are in use. Via Modify the
central entity knows that the resources supporting the current flow
can be available for supporting the altered flow. Modify is
considered to be an optional operation due to possible control-plane
limitations.
As the DetNet UNI can provide service for both L3 and L2 app-flows, o FlowRequirements: it defines the requirement of the App-flow
end systems may not need to implement the L3 <=> L2 Transfer Function regarding bandwidth, latency, latency variation, loss, and
specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also misorder tolerance.
subclause 46.1 in [IEEE8021Qcc]). A DetNet edge node may implement a
function similar to the Transfer Function, see, e.g., the Svc Proxy
in Figure 3 in [I-D.ietf-detnet-architecture].
8. DetNet flows o FlowBiDir: it defines the requirement of the App-flow whether it
has to be routed together with other App-flow(s) through the
network, e.g., to provide congruent paths in the two directions.
The app-flows leveraging DetNet service can be unicast or multicast 5. DetNet Flow Related Parameters
data flows of an application with constrained requirements on network
performance, e.g., low packet loss rate and/or latency. Flows can
require different connectivity types: point-to-point (p2p) or point-
to-multipoint (p2mp). The p2mp connectivity is created by a
transport layer function (e.g., p2mp LSP)
[I-D.ietf-detnet-dp-sol-mpls]. (Note that mp2mp connectivity is a
superposition of p2mp connections.)
Many flows using DetNet service are periodic with fix packet size Data model specified by [IEEE8021Qcc] describes data flows using TSN
(i.e., Constant Bit Rate (CBR) flows), or periodic with variable service as periodic flows with fix packet size (i.e., Constant Bit
packet size. Rate (CBR) flows) or with variable packet size. The same concept is
applyed for flows using DetNet service.
Delay 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 (delay and loss). applications require hard limits on both parameters (latency and
For example, some real-time applications allow graceful degradation loss). For example, some real-time applications allow graceful
if loss happens (e.g., sample-based processing, media distribution). degradation if loss happens (e.g., sample-based processing, media
Some others may require high-bandwidth connections that make the distribution). Some others may require high-bandwidth connections
usage of techniques like packet replication economically challenging that make the usage of techniques like packet replication
or even impossible. Some applications may not tolerate loss, but are economically challenging or even impossible. Some applications may
not delay sensitive (e.g., bufferless sensors). Time/loss sensitive not tolerate loss, but are not latency sensitive (e.g., bufferless
applications may have somewhat special requirements especially for sensors). Time/loss sensitive applications may have somewhat special
loss (e.g., no loss in two consecutive communication cycles; very low requirements especially for loss (e.g., no loss in two consecutive
outage time, etc.). communication cycles; very low outage time, etc.).
Flows have the following attributes:
a. DataFlowSpecification (Section 8.1) DetNet flows have the following attributes:
b. TrafficSpecification (Section 8.2) a. DnFlowID (Section 5.1)
c. FlowRank (Section 8.3) b. DnPayloadType (Section 5.2)
Flow attributes are described in the following sections. c. DnFlowFormat (Section 5.3)
8.1. Identification and Specification of Flows d. DnFlowSpecification (Section 5.4)
Identification options for DetNet flows at the UNI and within the e. DnTrafficSpecification (Section 5.5)
DetNet domain are specified as follows; see Section 8.1.1 for DetNet
L3 flows (at UNI), Section 8.1.2 for DetNet L2 flows (at UNI) and
Section 8.1.3 for DetNetwork flows (within the network).
8.1.1. IP flow Identification and Specification at UNI f. DnFlowEndpoints (Section 5.6)
L3 data flows can be identified and specified by the following g. DnFlowRank (Section 5.7)
attributes:
a. SourceIpAddress h. DnFlowStatus (Section 5.8)
b. DestinationIpAddress DetNet flows have the following requirement attributes:
c. IPv6FlowLabel o DnFlowRequirements (Section 5.9)
d. Dscp o DnFlowBiDir (Section 5.10)
e. Protocol Flow attributes are described in the following sections.
f. SourcePort 5.1. Management ID of the DetNet Flow
g. DestinationPort A unique (management) identifier is needed for each DetNet flow
within the DetNet domain. It is specified in DnFlowID. It can be
used to define the M:1 mapping of DetNet flows to a DetNet service.
8.1.2. L2 Flow Identification and Specification at UNI 5.2. Payload type of the DetNet Flow
L2 data flows can be identified and specified by the following DnPayloadType attribute is set according to encapsulated App-flow
attributes: format. The attribute can be Ethernet, MPLS, or IP.
a. DestinationMacAddress 5.3. Format of the DetNet Flow
b. SourceMacAddress DnFlowFormat attribute is set according to DetNet PSN technology.
The attribute can be MPLS or IP.
c. Pcp 5.4. Identification and Specification of DetNet Flows
d. VlanId Identification options for DetNet flows at the Ingress/Egress and
within the DetNet domain are specified as follows; see Section 5.4.1
for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows.
e. EtherType 5.4.1. DetNet MPLS Flow Identification and Specification
Note: The Multiple Stream Registration Protocol (MSRP) [IEEE8021Q] Identification of DetNet MPLS flows within the DetNet domain are used
uses StreamID to match Talker registrations with their corresponding in the service information model. The attributes are specific to the
Listener registrations, i.e., to identify Streams (L2 TSN flows). MPLS forwarding paradigm within the DetNet domain
The StreamID includes the following subcomponents: [I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be identified and
specified by the following attributes:
o A 48-bit MAC Address associated with the Talker sourcing the a. SLabel
stream to the bridged network.
o A 16-bit unsigned integer value, Unique ID, used to distinguish b. FLabelStack
among multiple streams sourced by the same Talker.
8.1.3. DetNet Flow Identification and Specification 5.4.2. DetNet IP Flow Identification and Specification
Identification of DetNet flows within the DetNet domain are used in DetNet IP flows can be identified and specified by the following
the service information model. The attributes are specific to the attributes (6-tuple) [I-D.ietf-detnet-ip]:
forwarding paradigm within the DetNet domain. DetNetwork flows can
be identified and specified by the following attributes:
a. SourceIpAddress a. SourceIpAddress
b. DestinationIpAddress b. DestinationIpAddress
c. IPv6FlowLabel c. IPv6FlowLabel
d. DSCP d. Dscp
e. Protocol e. Protocol
f. SourcePort f. SourcePort
g. DestinationPort g. DestinationPort
h. MplsLabel 5.5. Traffic Specification of the DetNet Flow
8.2. Traffic Specification
TrafficSpecification specifies how the Source transmits packets for DnTrafficSpecification attributes specify how the DN Ingress
the flow. This is effectively the promise/request of the Source to transmits packets for the DetNet flow. This is effectively the
the network. The network uses this traffic specification to allocate promise/request of the DN Ingress to the network. The network uses
resources and adjust queue parameters in network nodes. this traffic specification to allocate resources and adjust queue
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. cannot be exceeded.
b. MaxPacketsPerInterval: the maximum number of packets that the b. MaxPacketsPerInterval: the maximum number of packets that the
Source will transmit in one Interval. Ingress will transmit in one Interval.
c. MaxPayloadSize: the maximum payload size that the Source will c. MaxPayloadSize: the maximum payload size that the Ingress will
transmit. transmit.
[[NOTE (to be removed from a future revision): These attributes can These attributes can be used to describe any type of traffic (e.g.,
be used to describe any type of traffic (e.g., CBR, VBR, etc.) and CBR, VBR, etc.) and can be used during resource allocation to
can be used during resource allocation to represent worst case represent worst case scenarios.
scenarios. Further optional attributes can be considered to achieve
more efficient resource allocation. Such optional attributes might
be 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). Possible options how to extend TrafficSpecification
attributes is for further discussion. Identified options are
described in the following notes.]]
[[NOTE1: Based on the already defined attributes the most similar
additional attributes for VBR type flows can be defined as follows:
o AveragePacketsPerInterval: the average number of packets that the
Source will transmit in one Interval.
o AveragePayloadSize: the average payload size that the Source will
transmit.
]]
[[NOTE2: another alternative to deal better with various traffic [[Editor's note (to be removed from a future revision): Further
types can rely on [RFC6003], which describes the support of Metro optional attributes can be considered to achieve more efficient
Ethernet Forum (MEF) Ethernet traffic parameters for using for resource allocation. Such optional attributes might be worth for
resource reservation purposes. Such a Bandwidth Profile can be also flows with soft requirements (i.e., the flow is only loss sensitive
adapted to describe the set of traffic parameters for a Detnet flow. or only delay sensitive, but not both d elay-and-loss sensitive).
Committed Rate indicates the rate at which traffic commits to be sent Possible options how to extend DnTrafficSpecification attributes is
by the source (described in terms of the CIR (Committed Information for further discussion. ]]
Rate) and CBS (Committed Burst Size) attributes.) Excess Rate
indicates the extent by which the traffic sent by the source exceeds
the committed rate. The Excess Rate is described in terms of the EIR
(Excess Information Rate) and EBS (Excess Burst Size) attributes. ]]
[[NOTE3: a third alternative is to define application based traffic 5.6. Endpoints of the DetNet Flow
models such as [GPP22885] defines periodic and event-driven traffic
model, and 5G PPP work defines traffic model for MTC (Machine Type
Communication) use cases [I-D.ietf-detnet-use-cases]. Periodic
traffic type is usually for status update between devices or devices
transmit status report to a central unit in regular basis.
TrafficPeriod, defines the period of the status update message.
DataSize, defines the data size of the massage which is constant.
3GPP also defines approximately-periodic transmission with variations
on period and uncertainty in the time arrival of the packets. Event-
triggered traffic type corresponds traffic being triggered by an MTC
device event. MinIntervalBetweenEvent, defines the minimum interval
between two events. Event-triggered transmission will not happen all
the time, whenever an alert is sent, it waits until the issue being
solved to be able to send another alert. MaxPacketPerEvent, defines
the max number of packets within one message. ]]
8.3. Flow Rank DnFlowEndpoints attribute defines the starting and termination
reference points of the DetNet flow by pointing to the ingress
interface/node and egress interface(s)/node(s). Depending on the
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
received over a well defined UNI interface. For exampe for App-flows
with MPLS encapsulation defining an ingress node is more common when
per platform label space is used.
FlowRank provides the rank of this flow relative to other flows in 5.7. Rank of the DetNet Flow
the network. This rank is used to determine success/failure of flow
establishment. Rank (boolean) is used by the network to decide which
flows can and cannot exist when network resources reach their limit.
Rank is used to help to determine which flows can be dropped (i.e.,
removed from node configuration) if a port of a node becomes
oversubscribed (e.g., due to network reconfiguration). The true
value is more important than the false value (i.e., flows with false
are dropped first).
9. Source DnFlowRank provides the rank of this flow relative to 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 resources
reach their limit. Rank is used to help to determine which flows can
be dropped (i.e., removed from node configuration) if for example a
port of a node becomes oversubscribed (e.g., due to network re-
configuration).
The Source object specifies: 5.8. Status of the DetNet Flow
o The behavior of the Source for the flow (how/when the Source DnFlowStatus provides the status of the DetNet flow with respect to
transmits). the establishment of the flow by the DetNet domain.
o The requirements of the Source from the network. The DnFlowStatus SHALL include the following attributes:
o The capabilities of the interface(s) of the Source. a. DnIngressStatus is an enumeration for the status of the flow's
Ingress reference point:
The Source object includes the following attributes: * None: no Ingress.
a. DataFlowSpecification (Section 8.1) * Ready: Ingress is ready.
b. TrafficSpecification (Section 8.2) * Failed: Ingress failed.
c. FlowRank (Section 8.3) * OutOfService: Administratively blocked.
d. EndSystemInterfaces (Section 11.1) b. DnEgressStatus is an enumeration for the status of the flow's
Egress reference points:
e. InterfaceCapabilities (Section 11.2) * None: no Egress.
f. UserToNetworkRequirements (Section 11.3) * Ready: all Egresses are ready.
For the join operation, the DataFlowSpecification, FlowRank, * PartialFailed: One or more Egress ready, and one or more
EndSystemInterfaces, and TrafficSpecification SHALL be included Egress failed. The DetNet flow can be used if the Ingress is
within the Source. For the join operation, the Ready.
UserToNetworkRequirements and InterfaceCapabilities groups MAY be
included within the Source.
For the leave operation, the DataFlowSpecification and * Failed: All Egresses failed.
EndSystemInterfaces SHALL be included within the Source.
For the modify operation, the same object SHALL and MAY included as * OutOfService: Administratively blocked.
for the join operation.
10. Destination c. FailureCode: A non-zero code that specifies the problem if the
DetNet flow encounters a failure (e.g., packet replication and
elimination is requested but not possible, or DnIngressStatus is
Failed, or DnEgressStatus is Failed, or DnEgressStatus is
PartialFailed).
The Destination object includes the following attributes: [[Editor's note (to be removed from a future revision): FailureCodes
to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN
failure codes.]]
a. DataFlowSpecification (Section 8.1) 5.9. Requirements of the DetNet Flow
b. EndSystemInterfaces (Section 11.1) DnFlowRequirements specifies requirements to ensure proper serving of
the DetNet flow.
c. InterfaceCapabilities (Section 11.2) The DnFlowRequirements includes the following attributes:
d. UserToNetworkRequirements (Section 11.3) a. MinBandwidth
For the join operation, the DataFlowSpecification and b. MaxLatency
EndSystemInterfaces SHALL be included within the Destination. For
the join operation, the UserToNetworkRequirements and
InterfaceCapabilities groups MAY be included within the Destination.
For the leave operation, the DataFlowSpecification and c. MaxLatencyVariation
EndSystemInterfaces SHALL be included within the Destination.
For the modify operation, the same object SHALL and MAY included as d. MaxLoss
for the join operation.
[[NOTE (to be removed from a future revision): Adding a general e. MaxConsecutiveLossTolerance
EndpointRank? That would define the endpoint importance (source, f. MaxMisordering
destination). It is only partly covered by FlowRank ... For
example, it could distinguish the importance of Destinations if the
flow cannot be provided for all Destinations.]]
11. Common Attributes of Source and Destination 5.9.1. Minimum Bandwidth of the DetNet Flow
Source and Destination end systems have the following common MinBandwidth is the minimum bandwidth that has to be guaranteed for
attributes in addition to DataFlowSpecification (Section 8.1). the DetNet flow.
11.1. End System Interfaces 5.9.2. Maximum Latency of the DetNet Flow
EndSystemInterfaces is a list of identifiers, one for each physical MaxLatency is the maximum latency from Ingress to Egress(es) for a
interface (port) in the end system acting as a Source or Destination. single packet of the DetNet flow. MaxLatency is specified as an
An interface is identified by an IP or a MAC address. integer number of nanoseconds.
EndSystemInterfaces can refer also to logical sub-Interfaces if 5.9.3. Maximum Latency Variation of the DetNet Flow
supported by the end system, e.g., based on IfIndex parameter.
11.2. Interface Capabilities MaxLatencyVariation is the difference between the minimum and the
maximum end-to-end one-way latency.
InterfaceCapabilities specifies the network capabilities of all 5.9.4. Maximum Loss of the DetNet Flow
interfaces (ports) contained in the EndSystemInterfaces object
(Section 11.1). These capabilities may be configured via the
InterfaceConfiguration object (Section 15.2) of the Status object
(Section 15).
Note that an end system may have multiple interfaces with different MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
network capabilities. In this case, each interface should be the DetNet flow between the Ingress and Egress(es).
specified in a distinct top-level Source or Destination object (i.e.,
one entry in EndSystemInterfaces (Section 11.1)). Use of multiple
entries in EndSystemInterfaces is intended for network capabilities
that span multiple interfaces (e.g., packet replication and
elimination).";.
InterfaceCapabilities attributes: 5.9.5. Maximum Consequtive Loss of the DetNet Flow
a. SubInterfaceCapable (sub-interface capable) Some applications have special loss requirement, like
MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance
parameter describes the maximum number of consecutive packets whose
loss can be tolerated. The maximum consecutive loss tolerance can be
measured for example based on sequence number.
b. PREF-Capable (packet replication and elimination capable) 5.9.6. Maximum Misordering Tolerance of the DetNet Flow
c. POF-Capable (packet ordering capable) MaxMisordering describes the tolerable maximum number of packets that
can be received out of order. The maximum allowed misordering can be
measured for example based on sequence number. The value zero for
the maximum allowed misordering indicates that in order delivery is
required, misordering cannot be tolerated.
[[NOTE (to be removed from a future revision): InterfaceCapabilities 5.10. BiDir requirement of the DetNet Flow
attributes are to be defined. For information, [IEEE8021Qcc]
specifies the following attributes:
o VlanTagCapable (Customer VLAN Tag capable) DnFlowBiDir attribute defines the requirement whether the served
packets have to be routed together with packets of other flows
through the DetNet domain, e.g., to provide congruent paths in the
two directions.
o CB-Capable (frame replication and elimination capable) 6. DetNet Service Related Parameters
o CB-StreamIdenTypeList (a list of the optional Stream DetNet service have the following attributes:
Identification types supported by the interface as specified in
[IEEE8021CB].)
o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode a. DnServiceID (Section 6.1)
types supported by the interface as specified in [IEEE8021CB].)
]] b. DnServiceDeliveryType (Section 6.2)
11.3. User to Network Requirements c. DnServiceDeliveryProfile (Section 6.3)
UserToNetworkRequirements specifies user requirements for the flow, d. DNServiceConnectivity (Section 6.4)
such as latency and reliability.
The UserToNetworkRequirements object includes the following e. DnServiceBiDir (Section 6.5)
attributes:
a. MaxLatency f. DnServiceRank (Section 6.6)
MaxLatency is the maximum latency from Source to Destination(s) for a g. DnServiceStatus (Section 6.7)
single packet of the flow. MaxLatency is specified as an integer
number of nanoseconds. When this requirement is specified by the
Source, it must be satisfied for all Destinations. When this
requirement is specified by a Destination, it must be satisfied for
that particular Destination only. If the UserToNetworkRequirements
group is not provided within the Source or Destination object, then
value zero SHALL be used for this element. Value zero represents a
special use for the maximum latency requirement. Value zero locks-
down the initial latency that the network provides in the
AccumulatedLatency parameter of the Status object (Section 15) after
the successful configuration of the flow, such that any subsequent
increase in the latency beyond that initial value causes the flow to
fail.
[[NOTE-1 (to be removed from a future revision): Should we add a Service attributes are described in the following sections.
parameter to specify the maximum packet loss rate that can be
tolerated for the flow?]]
[[NOTE-2 (to be removed from a future revision): TrafficSpecification 6.1. Management ID of the DetNet service
(Section 8.2) specifies the Peak Information Rate (PIR) of the flow,
which is a kind of user requirement to the network. Should we add
Committed Information Rate (CIR), i.e., the minimum rate the user
requests to be guaranteed for the flow by the network?]]
12. Ingress A unique (management) identifier is needed for each DetNet service
within the DetNet domain. It is specified in DnServiceID. It can be
used to define the M:1 mapping of DetNet flows to a DetNet service.
Placeholder ... 6.2. Delivery Type of the DetNet service
13. Egress DnServiceDeliveryType attribute is set according to the payload of
the served DetNet flow (i.e., the encapsulated App-flow format). The
attribute can be Ethernet, MPLS, or IP.
Placeholder ... 6.3. Delivery Profile of the DetNet Service
14. DetNet Domain DnServiceDeliveryProfile specifies delivery profile to ensure proper
serving of the DetNet flow.
The DetNet Domain may change the encapsulation of a DetNet L2 or L3 The DnServiceDeliveryProfile includes the following attributes:
flow at the UNI. That impacts not only how a flow can be recognised
inside the DetNet domain but also the resource reservation
calculations.
The DetNet Domain object specifies: a. MinBandwidth
o The behavior of the flow (how/when it is transmited). b. MaxLatency
o The requirements of the flow from the network. c. MaxLatencyVariation
o The capabilities of the DetNet domain. d. MaxLoss
The DetNet domain object includes the following attributes: e. MaxConsecutiveLossTolerance
f. MaxMisordering
a. DataFlowSpecification (Section 8.1) 6.3.1. Minimum Bandwidth of the DetNet Service
b. TrafficSpecification (Section 8.2) MinBandwidth is the minimum bandwidth that has to be guaranteed for
the DetNet service.
c. ServiceRank (Section 16) 6.3.2. Maximum Latency of the DetNet Service
d. DetnetDomainCapabilities (Section 14.1) MaxLatency is the maximum latency from Ingress to Egress(es) for a
single packet of the DetNet flow. MaxLatency is specified as an
integer number of nanoseconds.
e. UserToNetworkRequirements (Section 11.3) 6.3.3. Maximum Latency Variation of the DetNet Service
14.1. DetNet Domain Capabilities MaxLatencyVariation is the difference between the minimum and the
maximum end-to-end one-way latency.
DetnetDomainCapabilities specifies the network capabilities, which 6.3.4. Maximum Loss of the DetNet Service
can be used to provide DetNet service. DetNet Edge nodes may change
the encapsulation of a flow according to the data plane used inside
the DetNet domain.
DetnetDomainCapabilities object includes the following attributes: MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the
DetNet service between the Ingress and Egress(es) of the DetNet
domain.
a. EncapsulationFormat (data plane specific encapsulation) 6.3.5. Maximum Consequtive Loss of the DetNet Service
b. PREF-Capable (packet replication and elimination capable) Some applications have special loss requirement, like
MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance
parameter describes the maximum number of consecutive packets whose
loss can be tolerated. The maximum consecutive loss tolerance can be
measured for example based on sequence number.
15. Flow-status 6.3.6. Maximum Misordering Tolerance of the DetNet Service
The FlowStatus object is provided by the network each Source and MaxMisordering describes the tolerable maximum number of packets that
Destination of the flow. The Status object provides the status of can be received out of order. The maximum allowed misordering can be
the flow with respect to the establishment of the flow by the measured for example based on sequence number. The value zero for
network. The Status object is delivered via the corresponding UNI to the maximum allowed misordering indicates that in order delivery is
each Source and Destination end system of the flow. The Status is required, misordering cannot be tolerated.
distinct for each Source or Destination because the
AccumulatedLatency and InterfaceConfiguration objects are distinct,
see below.
The Status object SHALL include the attributes a), b), c); and MAY 6.4. Connectivity Type of the DetNet Service
include attributes d), e):
a. DataFlowSpecification (Section 8.1) Two connectivity types are distinguished: point-to-point (p2p) and
point-to-multipoint (p2mp). Connectivity type p2mp is created by a
transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity
is a superposition of p2mp connections.)
b. StatusInfo (Section 15.1) 6.5. BiDir requirement of the DetNet Service
c. AccumulatedLatency (this section below) DnServiceBiDir attribute defines the requirement whether the served
packets have to be routed together with packets of other service
instances through the DetNet domain, e.g., to provide congruent paths
in the two directions.
d. InterfaceConfiguration (Section 15.2) 6.6. Rank of the DetNet Service
e. FailedInterfaces (Section 15.3) DnServiceRank attribute provides the rank of a service instance
DataFlowSpecification identifies the flow for which status is relative to other services in the DetNet domain. DnServiceRank
provided. DataFlowSpecification is described in (Section 8.1) If the (range: 0-255) is used by the network in case of network resource
Status object is provided without a Source or Destination object in a limitation scenarios.
protocol message via a UNI, then the DataFlowSpecification object
SHALL be included within the Status object for both join and leave
operations. If the Status object immediately follows a Source or
Destination object in the protocol message, then the
DataFlowSpecification object is obtained from the Source/Destination
object, and therefore DataFlowSpecification is not required within
the Status object.
AccumulatedLatency provides the worst-case latency that a single 6.7. Status of the DetNet Service
packet of the flow can encounter along its current path(s) in the
network. When provided to a Source, AccumulatedLatency is the worst-
case latency for all Destinations (worst path). AccumulatedLatency
is specified as an integer number of nanoseconds. Latency is
measured using the time at which the data frame's message timestamp
point passes the reference plane marking the boundary between the
network media and PHY. The message timestamp point is specified by
IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful
Status, the network returns a value less than or equal to the
MaxLatency of the UserToNetworkRequirements (Section 11.3). If the
NumReplicationTrees of the UserToNetworkRequirements (Section 11.3)
is one, then the AccumlatedLatency SHALL provide the worst latency
for the current path from the Source to each Destination. If the
path is changed (e.g., due to rerouting), then the AccumulatedLatency
changes accordingly. If the NumReplicationTrees of the
UserToNetworkRequirements (Section 11.3) is greater than one,
AccumlatedLatency SHALL provide the worst latency for all paths in
use from the Source to each Destination.
15.1. Status Info DnServiceStatus information group includes elements that specify the
status of the service specific state of the DetNet domain. This
information group informs the user whether or not the service is
ready for use.
StatusInfo provides information regarding the status of a flow's The DnServiceStatus SHALL include the following attributes:
configuration in the network.
The StatusInfo object MAY include the following attributes: a. DnServiceIngressStatus is an enumeration for the status of the
service's Ingress:
a. SourceStatus is an enumeration for the status of the flow's * None: no Ingress.
Source:
* None: no Source * Ready: Ingress is ready.
* Ready: Source is ready * Failed: Ingress failed.
* Failed: Source failed * OutOfService: Administratively blocked.
b. DestinationStatus is an enumeration for the status of the flow's b. DnServiceEgressStatus is an enumeration for the status of the
Destinations: service's Egress:
* None: no Destination * None: no Egress.
* Ready: all Destinations are ready * Ready: all Egresses are ready.
* PartialFailed: One or more Destinations ready, and one or more * PartialFailed: One or more Egress ready, and one or more
Listeners failed. The flow can be used if the Source is Egress failed. The DetNet flow can be used if the Ingress is
Ready. Ready.
* Failed: All Destinations failed. * Failed: All Egresses failed.
c. FailureCode: A non-zero code that specifies the problem if the * OutOfService: Administratively blocked.
flow encounters a failure (e.g., packet replication and
elimination is requested but not possible, or SourceStatus is
Failed, or DestinationStatus is Failed, or DestinationStatus is
PartialFailed).
[[NOTE (to be removed from a future revision): FailureCodes to be c. DnServiceFailureCode: A non-zero code that specifies the problem
defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN if the DetNet service encounters a failure (e.g., packet
failure codes.]] replication and elimination is requested but not possible, or
DnServiceIngressStatus is Failed, or DnServiceEgressStatus is
Failed, or DnServiceEgressStatus is PartialFailed).
15.2. Interface Configuration [[Editor's note (to be removed from a future revision):
DnServiceFailureCodes to be defined for DetNet service. Table 46-1
of [IEEE8021Qcc] describes TSN failure codes.]]
InterfaceConfiguration provides information about of interfaces in 7. Flow Specific Operations
the Source/Destination. This configuration related information
assists the network in meeting the requirements of the flow. The
InterfaceConfiguration object is according to the capabilities of the
interface. InterfaceConfiguration can be distinct for each Source or
Destination of each flow. If the InterfaceConfiguration object is
not provided within the Status object, then the network SHALL assume
zero elements as the default (no interface configuration).
The InterfaceConfiguration object MAY include one or more the The DetNet flow information model relies on three high level
following attributes: information groups:
a. MAC or IP Address to identify the interface o DnIngress: The DnIngress information group includes elements that
specify the source for a single DetNet flow. This information
group is applied from the user of the DetNet service to the
network.
b. DataFlowSpecification (Section 8.1) o DnEgress: The DnEgress information group includes elements that
specify the destination for a single DetNet flow. This
information group is applied from the user of the DetNet service
to the network.
15.3. Failed Interfaces o DnFlowStatus: The status information group includes elements that
specify the status of the flow in the network. This information
group is applied from the network to the user of the DetNet
service. This information group informs the user whether or not
the DetNet flow is ready for use.
FailedInterfaces provides a list of one or more physical interfaces There are three possible operations for each DetNet flow with respect
(ports) in the failed node when a failure occurs in the network. to its DetNet service at a DN Ingress or a DN Egress (similarly to
App-flows at a Source or a Destination):
The FailedInterface object includes the following attributes: o Join: DN Ingress/DN Egress intends to join the flow.
a. MAC or IP Address to identify the interface o Leave: DN Ingress/DN Egress intends to leave the flow.
b. InterfaceName o Modify: DN Ingress/DN Egress intends to change the flow.
InterfaceName is the name of the interface (port) within the node. 7.1. Join Operation
This interface name SHALL be persistent, and unique within the node.
16. Service Rank For the join operation, the DnFlowSpecification, DnFlowRank,
DnFlowEndpoint, and DnTrafficSpecification SHALL be included within
the DnIngress or DnEgress information group. For the join operation,
the DnServiceRequirements groups MAY be included.
ServiceRank provides the rank of this service instance relative to 7.2. Leave Operation
other services in the network. This rank is used to determine
success/failure of service instance establishment. Rank (boolean) is
used by the network to decide which services can and cannot exist
when network resources reach their limit. Rank is used to help to
determine which services can be dropped (i.e., removed from node
configuration) if a port of a node becomes oversubscribed (e.g., due
to network reconfiguration). The true value is more important than
the false value (i.e., services with false are dropped first).
[[NOTE: relationship between ServiceRank and FlowRank needs further For the leave operation, the DnFlowSpecification and DnFlowEndpoint
discussions. A 1:N relationship is assumed (a service instance can SHALL be included within the DnIngress or DnEgress information group.
serv multiple flows). This sub-section is considered to move to the
service related sections. ]]
17. Service-status 7.3. Modify Operation
Placeholder ... For the modify operation, the DnFlowSpecification, DnFlowRank,
DnFlowEndpoint, and DnTrafficSpecification SHALL be included within
the DnIngress or DnEgress information group. For the join operation,
the DnServiceRequirements groups MAY be included.
18. Summary Modify operation can be considered to address cases when a flow is
slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been
changed. The advantage of having a Modify is that it allows to
initiate a change of flow spec while leaving the current flow is
operating until the change is accepted. If there is no linkage
between the Join and the Leave, then in figuring out whether the new
flow spec can be supported, the controller entity has to assume that
the resources committed to the current flow are in use. Via Modify
the controller entity knows that the resources supporting the current
flow can be available for supporting the altered flow. Modify is
considered to be an optional operation due to possible controller
plane limitations.
This document describes DetNet flow information model both for DetNet 8. Summary
L3 flows and DetNet L2 flows based on the TSN data model specified by
[IEEE8021Qcc]. This revision is extended with DetNet specific flow
information model elements.
19. IANA Considerations This document describes DetNet flow information model and service
information model for DetNet IP networks and DetNet MPLS networks.
9. IANA Considerations
N/A. N/A.
20. Security Considerations 10. Security Considerations
N/A. N/A.
21. References 11. References
21.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-11 (work in progress), February 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-ip]
Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
progress), October 2018. draft-ietf-detnet-ip-01 (work in progress), July 2019.
[I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
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", [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
RFC 6003, DOI 10.17487/RFC6003, October 2010, RFC 6003, DOI 10.17487/RFC6003, October 2010,
<https://www.rfc-editor.org/info/rfc6003>. <https://www.rfc-editor.org/info/rfc6003>.
21.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
[GPP22885] May 2017, <https://www.rfc-editor.org/info/rfc8174>.
3GPP, "Study on LTE support for Vehicle-to-Everything
(V2X) services",
<http://www.3gpp.org/DynaReport/22885.html>.
[I-D.ietf-detnet-use-cases] 11.2. Informative References
Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-20 (work in progress), December
2018.
[IEEE8021AS] [I-D.ietf-detnet-data-plane-framework]
IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
and metropolitan area networks - Timing and Bryant, S., and J. Korhonen, "DetNet Data Plane
Synchronization for Time-Sensitive Applications in Bridged Framework", draft-ietf-detnet-data-plane-framework-01
Local Area Networks", 2011, (work in progress), July 2019.
<http://standards.ieee.org/getieee802/
download/802.1AS-2011.pdf>.
[IEEE8021CB] [IEEE8021CB]
IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE
and metropolitan area networks - Frame Replication and Standard for Local and metropolitan area networks - Frame
Elimination for Reliability", 2017, Replication and Elimination for Reliability", 2017,
<http://www.ieee802.org/1/pages/802.1cb.html>. <https://ieeexplore.ieee.org/document/8091139/>.
[IEEE8021Q] [IEEE8021Q]
IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE
metropolitan area networks - Bridges and Bridged Standard for Local and metropolitan area networks -
Networks", 2014, <http://standards.ieee.org/getieee802/ Bridges and Bridged Networks", 2018,
download/802-1Q-2014.pdf>. <https://ieeexplore.ieee.org/document/8403927>.
[IEEE8021Qbv] [IEEE8021Qbv]
IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE
and metropolitan area networks - Bridges and Bridged Standard for Local and metropolitan area networks -
Networks -- Amendment 25: Enhancements for Scheduled Bridges and Bridged Networks - Amendment 25: Enhancements
Traffic", 2015, <https://standards.ieee.org/findstds/ for Scheduled Traffic", 2015,
standard/802.1Qbv-2015.html>. <https://ieeexplore.ieee.org/document/7572858/>.
[IEEE8021Qcc] [IEEE8021Qcc]
IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE
Local and metropolitan area networks - Bridges and Bridged Standard for Local and metropolitan area networks -
Networks -- Amendment: Stream Reservation Protocol (SRP) Bridges and Bridged Networks -- Amendment 31: Stream
Enhancements and Performance Improvements", 2017, Reservation Protocol (SRP) Enhancements and Performance
<http://www.ieee802.org/1/pages/802.1cc.html>. Improvements", 2018,
<https://ieeexplore.ieee.org/document/8514112/>.
[IEEE8021TSN] [IEEE8021TSN]
IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN)
Task Group", <http://www.ieee802.org/1/pages/tsn.html>. 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/>.
Authors' Addresses Authors' Addresses
 End of changes. 217 change blocks. 
738 lines changed or deleted 582 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/