--- 1/draft-ietf-detnet-flow-information-model-03.txt 2019-07-08 11:13:30.487236901 -0700 +++ 2/draft-ietf-detnet-flow-information-model-04.txt 2019-07-08 11:13:30.531238022 -0700 @@ -1,1121 +1,965 @@ DetNet J. Farkas Internet-Draft B. Varga Intended status: Standards Track Ericsson -Expires: September 12, 2019 R. Cummings +Expires: January 9, 2020 R. Cummings National Instruments Y. Jiang Huawei Technologies Co., Ltd. - March 11, 2019 + July 08, 2019 DetNet Flow Information Model - draft-ietf-detnet-flow-information-model-03 + draft-ietf-detnet-flow-information-model-04 Abstract This document describes flow and service information model for - Deterministic Networking (DetNet). The DetNet service is provided - either for a Layer 3 or a Layer 2 flow. This document provides - DetNet flow and service information model both for Layer 3 and Layer - 2 flows in an integrated fashion. + Deterministic Networking (DetNet). These models are defined for IP + and MPLS DetNet data planes Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. ToDo list . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 - 4. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 - 5. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 6 - 6. Service model . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Service overview . . . . . . . . . . . . . . . . . . . . 6 - 6.2. Service parameters . . . . . . . . . . . . . . . . . . . 6 - 6.3. Reference Points . . . . . . . . . . . . . . . . . . . . 8 - 6.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 9 - 7. End System and DetNet domain . . . . . . . . . . . . . . . . 9 - 8. DetNet flows . . . . . . . . . . . . . . . . . . . . . . . . 11 - 8.1. Identification and Specification of Flows . . . . . . . . 11 - 8.1.1. IP flow Identification and Specification at UNI . . . 12 - 8.1.2. L2 Flow Identification and Specification at UNI . . . 12 - 8.1.3. DetNet Flow Identification and Specification . . . . 13 - 8.2. Traffic Specification . . . . . . . . . . . . . . . . . . 13 - 8.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 10. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 11. Common Attributes of Source and Destination . . . . . . . . . 16 - 11.1. End System Interfaces . . . . . . . . . . . . . . . . . 16 - 11.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16 - 11.3. User to Network Requirements . . . . . . . . . . . . . . 17 - 12. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 14. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18 - 14.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 19 - 15. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 15.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20 - 15.2. Interface Configuration . . . . . . . . . . . . . . . . 21 - 15.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21 - 16. Service Rank . . . . . . . . . . . . . . . . . . . . . . . . 22 - 17. Service-status . . . . . . . . . . . . . . . . . . . . . . . 22 - 18. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 20. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 21.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 21.2. Informative References . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 - -1. ToDo list - - These further actions are due on the draft: - - o Align with updated architecture and data plane documents (partly - done). + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 5 + 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 + 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 6 + 2.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 + 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 + 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 + 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7 + 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 + 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8 + 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8 + 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 + 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9 + 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 + 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10 + 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10 + 5.4. Identification and Specification of DetNet Flows . . . . 10 + 5.4.1. DetNet MPLS 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.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12 + 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12 + 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 12 + 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13 + 5.9.1. Minimum Bandwidth 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.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14 + 5.9.5. Maximum Consequtive Loss 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 + 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15 + 6.1. Management ID 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.1. Minimum Bandwidth 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.4. Maximum Loss of the DetNet Service . . . . . . . . . 16 + 6.3.5. Maximum Consequtive Loss 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.5. BiDir requirement of the DetNet Service . . . . . . . . . 17 + 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17 + 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 + 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18 + 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 - only, e.g., 802.1Qcc). We focus on DetNet flows. +1. Introduction - o Clarification on relationship between DetNet flow model and DetNet - service model. + A Deterministic Networking (DetNet) service provides a capability to + carry a unicast or a multicast data flow for an application with + constrained requirements on network performance, e.g., low packet + loss rate and/or latency. 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 - needed. + DetNet service is 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]. 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 - 1:1). + Figure 1: DetNet Service Examples as per Data Plane Framework -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 - 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. 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. + The DetNet flow and service information model provided by this + document contains both DetNet flow and App-flow specific information + in an integrated fashion. In a given network scenario three information models can distinguished: o Flow models describe characteristics of data flows. These models describe in detail all relevant aspects of a flow that are needed to support the flow properly by the network between the source and the destination(s). o Service models describe characteristics of services being provided for data flows over a network. These models can be treated as a network operator independent information model. o Configuration models describe in detail the settings required on network nodes to serve a data flow properly. Service and flow information models are used between the user and the network operator. Configuration information models are used between 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 flow/service /\ info model +---+ / \ <---------------> | X | management/control ---- +-+-+ plane entity ^ | configuration | info model +------------+ v | | +-+ | v Network +-+ v +-+ nodes +-+ +-+ +-+ - Figure 1: Usage of Information models (flow, service and + Figure 2: Usage of Information models (flow, service and configuration) DetNet flow and service information model is based on - [I-D.ietf-detnet-architecture] and on the data model specified by - [IEEE8021Qcc]. Furthermore, the DetNet flow information model relies - on the flow identification possibilities described in [IEEE8021CB], - which is used by [IEEE8021Qcc] as well. In addition to TSN data - model, [IEEE8021Qcc] also specifies configuration of TSN features - (e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the - common architecture and flow model, configuration features can be - leveraged in certain deployment scenarios, e.g., when the network - that provides 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. + [I-D.ietf-detnet-architecture] and on the concept of data model + specified by [IEEE8021Qcc]. Furthermore, the starting point of the + DetNet flow information model was the flow identification + possibilities described in [IEEE8021CB], which is used by + [IEEE8021Qcc] as well. In addition to TSN data model, [IEEE8021Qcc] + also specifies configuration of TSN features (e.g., traffic + scheduling specified by [IEEE8021Qbv]). Due to the common + architecture and flow model, configuration features can be leveraged + in certain deployment scenarios, e.g., when the network that provides + the DetNet service includes both L3 and L2 network segments. -2.1. Goals +1.1. Goals As it is expressed in the Charter [IETFDetNet], the DetNet WG collaborates with IEEE 802.1 TSN in order to define a common architecture for both Layer 2 and Layer 3, which is beneficial for various reasons, e.g., in order to simplify implementations. The - flow and service information models should be also common along those - lines. As the TSN flow information/data model specified by - [IEEE8021Qcc] is mature, the DetNet flow and service information + flow and service information models should be also aligned along + those lines. Therefore, the DetNet flow and service information models described in this document are based on [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. This document intends to specify flow and service information models only. -2.2. Non Goals +1.2. Non Goals This document (this revision) does not intend to specify either flow data model or DetNet configuration. From these aspects, the goals of this document differ from the goals of [IEEE8021Qcc], which also 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", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. +2.1. Terms Used in This Document - The lowercase forms with an initial capital "Must", "Must Not", - "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" - in this document are to be interpreted in the sense defined in - [RFC2119], but are used where the normative behavior is defined in - documents published by SDOs other than the IETF. + This document uses the terminology established in the DetNet + architecture [I-D.ietf-detnet-architecture] and the the DetNet Data + Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader + is assumed to be familiar with these documents and any terminology + 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 - 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). + App-flow The payload (data) carried over a DetNet service. -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 model components in this document. It is recommended that extensions of the model use the same conventions. o Names SHOULD be descriptive. o Names MUST start with uppercase letters. o Composed names MUST use capital letters for the first letter of each component. All other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as IPv6. Examples are 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 capability to carry a unicast or a multicast data flow for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency. - 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 DetNet service related reference points and main components. -6.2. Service parameters - - 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. +3.2. Reference Points Used in Modeling - 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 - distinguish internal reference point(s) for DetNet-aware end-systems - as well. ]] + App-flow specific reference points are the Source (where it starts) + and the Destination (where it terminates). Similarly a DetNet flow + 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- - based reference points and provide connectivity over the packet - network and between domains. A DetNet-UNI may add networking - technology specific encapsulation to the data flow in order to - transport it over the network. + 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 + networking technology specific encapsulation to/from the served App- + flow(s) (e.g., MPLS label(s), UDP and IP headers). - [[NOTE: Differences between the service over end-systems internal - 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. ]] +3.3. Information Elements -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 - can be identified: + o App-flow related paramaters: they describe the App-flow + 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 - destination nodes, so it is an e2e service between application - hosting devices (end systems). + o DetNet flow related parameters: they describe the DetNet flow + characteristics (e.g., identification, format, traffic + specification, endpoints, rank, etc.). - o DetNet-Service: the service connects networking islands, so it is - a service between the borders of network domain(s). + o DetNet service related parameters: they describe the expected + service characteristics (e.g., delivery type, connectivity delay/ + loss, status, rank, etc.). - [[NOTE: we may consider to define further scenarios based on the - result of reference point related discussions. ]] + In the information model a DetNet flow contains one or more App-flows + (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 application(s) running on an end system during communication with its peer(s). Such a data exchange has various requirements on delay and/ or loss parameters. - The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes - 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. +4.1. App-flow Characteristics - Therefore, the DetNet service information model relies on four high - level groups: + App-flow characteristics are described with the following parameters: - o Ingress: an edge system receiving a DetNet flow from a Source. - The Ingress information group includes elements that specify the - entry point for a single flow. This information group is applied - from the network to the user. + o FlowID: it is a unique (management) identifier of the App-flow. + It can be used to define the N:1 mapping of App-flows to a DetNet + flow. - o Egress: an edge system sending traffic towards a Destination of a - DetNet flow. The Egress information group includes elements that - specify the egress point for a single flow. This information - group is applied from the network to the user. + o FlowType: it is set according to the encapsulation format of the + flow. It can be Ethernet (TSN), MPLS, or IP. - o DetNet Domain: an administrative domain providing the DetNet - service. The DetNet domain information group includes elements - that specify the forwarding capabilities and methods for a single - flow. This information group is applied within the network. + o DataFlowSpecification: it is a flow descriptor, defining which + packets belongs to a flow using, e.g., FlowType specific packet + header fields like src-addr, dst-addr, label, VLAN-ID, etc. - o Service-Status: the status of a DetNet service. The status - information group includes elements that specify the status of the - service specific state of the network. This information group is - applied from the network to the user. This information group - informs the user whether or not the service is ready for use. + o TrafficSpecification: it is a flow descriptor, defining traffic + parameters like packet size, interval, and max. packets per + interval. - There are three operations for each flow with respect to a Source or - a Destination (and an Ingress or an Egress): + o FlowEndpoints: it defines the start and termination reference + 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 - 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. + App-flow requirements are described with the following parameters: - As the DetNet UNI can provide service for both L3 and L2 app-flows, - end systems may not need to implement the L3 <=> L2 Transfer Function - specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also - 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]. + o FlowRequirements: it defines the requirement of the App-flow + regarding bandwidth, latency, latency variation, loss, and + misorder tolerance. -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 - 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.) +5. DetNet Flow Related Parameters - Many flows using DetNet service are periodic with fix packet size - (i.e., Constant Bit Rate (CBR) flows), or periodic with variable - packet size. + Data model specified by [IEEE8021Qcc] describes data flows using TSN + service as periodic flows with fix packet size (i.e., Constant Bit + 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 - applications require hard limits on both parameters (delay and loss). - For example, some real-time applications allow graceful degradation - if loss happens (e.g., sample-based processing, media distribution). - Some others may require high-bandwidth connections that make the - usage of techniques like packet replication economically challenging - or even impossible. Some applications may not tolerate loss, but are - not delay sensitive (e.g., bufferless sensors). Time/loss sensitive - applications may have somewhat special requirements especially for - loss (e.g., no loss in two consecutive communication cycles; very low - outage time, etc.). - - Flows have the following attributes: + applications require hard limits on both parameters (latency and + loss). For example, some real-time applications allow graceful + degradation if loss happens (e.g., sample-based processing, media + distribution). Some others may require high-bandwidth connections + that make the usage of techniques like packet replication + economically challenging or even impossible. Some applications may + not tolerate loss, but are not latency sensitive (e.g., bufferless + sensors). Time/loss sensitive applications may have somewhat special + requirements especially for loss (e.g., no loss in two consecutive + communication cycles; very low outage time, etc.). - 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 - 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). + e. DnTrafficSpecification (Section 5.5) -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 - attributes: + g. DnFlowRank (Section 5.7) - 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 - attributes: + DnPayloadType attribute is set according to encapsulated App-flow + 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] - uses StreamID to match Talker registrations with their corresponding - Listener registrations, i.e., to identify Streams (L2 TSN flows). - The StreamID includes the following subcomponents: + Identification of DetNet MPLS flows within the DetNet domain are used + in the service information model. The attributes are specific to the + MPLS forwarding paradigm within the DetNet domain + [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 - stream to the bridged network. + a. SLabel - o A 16-bit unsigned integer value, Unique ID, used to distinguish - among multiple streams sourced by the same Talker. + b. FLabelStack -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 - the service information model. The attributes are specific to the - forwarding paradigm within the DetNet domain. DetNetwork flows can - be identified and specified by the following attributes: + DetNet IP flows can be identified and specified by the following + attributes (6-tuple) [I-D.ietf-detnet-ip]: a. SourceIpAddress b. DestinationIpAddress c. IPv6FlowLabel - d. DSCP + d. Dscp e. Protocol f. SourcePort g. DestinationPort - h. MplsLabel - -8.2. Traffic Specification +5.5. Traffic Specification of the DetNet Flow - TrafficSpecification specifies how the Source transmits packets for - the flow. This is effectively the promise/request of the Source to - the network. The network uses this traffic specification to allocate - resources and adjust queue parameters in network nodes. + DnTrafficSpecification attributes specify how the DN Ingress + transmits packets for the DetNet flow. This is effectively the + promise/request of the DN Ingress to the network. The network uses + this traffic specification to allocate resources and adjust queue + parameters in network nodes. TrafficSpecification has the following attributes: a. Interval: the period of time in which the traffic specification cannot be exceeded. b. MaxPacketsPerInterval: the maximum number of packets that the - Source will transmit in one Interval. - - c. MaxPayloadSize: the maximum payload size that the Source will - transmit. - - [[NOTE (to be removed from a future revision): These attributes can - be used to describe any type of traffic (e.g., CBR, VBR, etc.) and - can be used during resource allocation to represent worst case - 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. + Ingress will transmit in one Interval. - o AveragePayloadSize: the average payload size that the Source will + c. MaxPayloadSize: the maximum payload size that the Ingress will transmit. - ]] + These attributes can be used to describe any type of traffic (e.g., + CBR, VBR, etc.) and can be used during resource allocation to + represent worst case scenarios. - [[NOTE2: another alternative to deal better with various traffic - types can rely on [RFC6003], which describes the support of Metro - Ethernet Forum (MEF) Ethernet traffic parameters for using for - resource reservation purposes. Such a Bandwidth Profile can be also - adapted to describe the set of traffic parameters for a Detnet flow. - Committed Rate indicates the rate at which traffic commits to be sent - by the source (described in terms of the CIR (Committed Information - 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. ]] + [[Editor's note (to be removed from a future revision): 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 d elay-and-loss sensitive). + Possible options how to extend DnTrafficSpecification attributes is + for further discussion. ]] - [[NOTE3: a third alternative is to define application based traffic - 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. ]] +5.6. Endpoints of the DetNet Flow -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 - 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). +5.7. Rank of the DetNet Flow -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 - transmits). + DnFlowStatus provides the status of the DetNet flow with respect to + 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, - EndSystemInterfaces, and TrafficSpecification SHALL be included - within the Source. For the join operation, the - UserToNetworkRequirements and InterfaceCapabilities groups MAY be - included within the Source. + * PartialFailed: One or more Egress ready, and one or more + Egress failed. The DetNet flow can be used if the Ingress is + Ready. - For the leave operation, the DataFlowSpecification and - EndSystemInterfaces SHALL be included within the Source. + * Failed: All Egresses failed. - For the modify operation, the same object SHALL and MAY included as - for the join operation. + * OutOfService: Administratively blocked. -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 - EndSystemInterfaces SHALL be included within the Destination. For - the join operation, the UserToNetworkRequirements and - InterfaceCapabilities groups MAY be included within the Destination. + b. MaxLatency - For the leave operation, the DataFlowSpecification and - EndSystemInterfaces SHALL be included within the Destination. + c. MaxLatencyVariation - For the modify operation, the same object SHALL and MAY included as - for the join operation. + d. MaxLoss - [[NOTE (to be removed from a future revision): Adding a general - EndpointRank? That would define the endpoint importance (source, - 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.]] + e. MaxConsecutiveLossTolerance + f. MaxMisordering -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 - attributes in addition to DataFlowSpecification (Section 8.1). + MinBandwidth is the minimum bandwidth that has to be guaranteed for + 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 - interface (port) in the end system acting as a Source or Destination. - An interface is identified by an IP or a MAC address. + 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. - EndSystemInterfaces can refer also to logical sub-Interfaces if - supported by the end system, e.g., based on IfIndex parameter. +5.9.3. Maximum Latency Variation of the DetNet Flow -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 - 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). +5.9.4. Maximum Loss of the DetNet Flow - Note that an end system may have multiple interfaces with different - network capabilities. In this case, each interface should be - 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).";. + MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for + the DetNet flow between the Ingress and Egress(es). - 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 - attributes are to be defined. For information, [IEEE8021Qcc] - specifies the following attributes: +5.10. BiDir requirement of the DetNet Flow - 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 - Identification types supported by the interface as specified in - [IEEE8021CB].) + DetNet service have the following attributes: - o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode - types supported by the interface as specified in [IEEE8021CB].) + a. DnServiceID (Section 6.1) - ]] + b. DnServiceDeliveryType (Section 6.2) -11.3. User to Network Requirements + c. DnServiceDeliveryProfile (Section 6.3) - UserToNetworkRequirements specifies user requirements for the flow, - such as latency and reliability. + d. DNServiceConnectivity (Section 6.4) - The UserToNetworkRequirements object includes the following - attributes: + e. DnServiceBiDir (Section 6.5) - a. MaxLatency + f. DnServiceRank (Section 6.6) - MaxLatency is the maximum latency from Source to Destination(s) for a - 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. + g. DnServiceStatus (Section 6.7) - [[NOTE-1 (to be removed from a future revision): Should we add a - parameter to specify the maximum packet loss rate that can be - tolerated for the flow?]] + Service attributes are described in the following sections. - [[NOTE-2 (to be removed from a future revision): TrafficSpecification - (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?]] +6.1. Management ID of the DetNet service -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 - 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 DnServiceDeliveryProfile includes the following attributes: - 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 - 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. +6.3.4. Maximum Loss of the DetNet Service - 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 - Destination of the flow. The Status object provides the status of - the flow with respect to the establishment of the flow by the - network. The Status object is delivered via the corresponding UNI to - each Source and Destination end system of the flow. The Status is - distinct for each Source or Destination because the - AccumulatedLatency and InterfaceConfiguration objects are distinct, - see below. + 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. - The Status object SHALL include the attributes a), b), c); and MAY - include attributes d), e): +6.4. Connectivity Type of the DetNet Service - 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) - DataFlowSpecification identifies the flow for which status is - provided. DataFlowSpecification is described in (Section 8.1) If the - Status object is provided without a Source or Destination object in a - 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. + DnServiceRank attribute provides the rank of a service instance + relative to other services in the DetNet domain. DnServiceRank + (range: 0-255) is used by the network in case of network resource + limitation scenarios. - AccumulatedLatency provides the worst-case latency that a single - 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. +6.7. Status of the DetNet Service -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 - configuration in the network. + The DnServiceStatus SHALL include the following attributes: - 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 - Source: + * None: no Ingress. - * 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 - Destinations: + b. DnServiceEgressStatus is an enumeration for the status of the + 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 - Listeners failed. The flow can be used if the Source is + * PartialFailed: One or more Egress ready, and one or more + Egress failed. The DetNet flow can be used if the Ingress is Ready. - * Failed: All Destinations failed. + * Failed: All Egresses failed. - c. FailureCode: A non-zero code that specifies the problem if the - 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). + * OutOfService: Administratively blocked. - [[NOTE (to be removed from a future revision): FailureCodes to be - defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN - failure codes.]] + c. DnServiceFailureCode: A non-zero code that specifies the problem + if the DetNet service encounters a failure (e.g., packet + 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 - 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). +7. Flow Specific Operations - The InterfaceConfiguration object MAY include one or more the - following attributes: + The DetNet flow information model relies on three high level + 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 - (ports) in the failed node when a failure occurs in the network. + There are three possible operations for each DetNet flow with respect + to its DetNet service at a DN Ingress or a DN Egress (similarly to + 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. - This interface name SHALL be persistent, and unique within the node. +7.1. Join Operation -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 - 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). +7.2. Leave Operation - [[NOTE: relationship between ServiceRank and FlowRank needs further - discussions. A 1:N relationship is assumed (a service instance can - serv multiple flows). This sub-section is considered to move to the - service related sections. ]] + For the leave operation, the DnFlowSpecification and DnFlowEndpoint + SHALL be included within the DnIngress or DnEgress information group. -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 - 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. +8. Summary -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. -20. Security Considerations +10. Security Considerations N/A. -21. References -21.1. Normative References +11. References + +11.1. Normative References [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "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] - Korhonen, J. and B. Varga, "DetNet MPLS Data Plane - Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in - progress), October 2018. + [I-D.ietf-detnet-ip] + Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., + Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", + 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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010, . -21.2. Informative References - - [GPP22885] - 3GPP, "Study on LTE support for Vehicle-to-Everything - (V2X) services", - . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . - [I-D.ietf-detnet-use-cases] - Grossman, E., "Deterministic Networking Use Cases", draft- - ietf-detnet-use-cases-20 (work in progress), December - 2018. +11.2. Informative References - [IEEE8021AS] - IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local - and metropolitan area networks - Timing and - Synchronization for Time-Sensitive Applications in Bridged - Local Area Networks", 2011, - . + [I-D.ietf-detnet-data-plane-framework] + Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., + Bryant, S., and J. Korhonen, "DetNet Data Plane + Framework", draft-ietf-detnet-data-plane-framework-01 + (work in progress), July 2019. [IEEE8021CB] - IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local - and metropolitan area networks - Frame Replication and - Elimination for Reliability", 2017, - . + IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE + Standard for Local and metropolitan area networks - Frame + Replication and Elimination for Reliability", 2017, + . [IEEE8021Q] - IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and - metropolitan area networks - Bridges and Bridged - Networks", 2014, . + IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE + Standard for Local and metropolitan area networks - + Bridges and Bridged Networks", 2018, + . [IEEE8021Qbv] - IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local - and metropolitan area networks - Bridges and Bridged - Networks -- Amendment 25: Enhancements for Scheduled - Traffic", 2015, . + IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE + Standard for Local and metropolitan area networks - + Bridges and Bridged Networks - Amendment 25: Enhancements + for Scheduled Traffic", 2015, + . [IEEE8021Qcc] - IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for - Local and metropolitan area networks - Bridges and Bridged - Networks -- Amendment: Stream Reservation Protocol (SRP) - Enhancements and Performance Improvements", 2017, - . + IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE + Standard for Local and metropolitan area networks - + Bridges and Bridged Networks -- Amendment 31: Stream + Reservation Protocol (SRP) Enhancements and Performance + Improvements", 2018, + . [IEEE8021TSN] IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) Task Group", . [IETFDetNet] IETF, "IETF Deterministic Networking (DetNet) Working Group", . Authors' Addresses