--- 1/draft-ietf-detnet-flow-information-model-08.txt 2020-05-13 23:13:05.017853574 -0700 +++ 2/draft-ietf-detnet-flow-information-model-09.txt 2020-05-13 23:13:05.061854694 -0700 @@ -1,24 +1,24 @@ -DetNet J. Farkas -Internet-Draft B. Varga +DetNet B. Varga +Internet-Draft J. Farkas Intended status: Informational Ericsson -Expires: November 7, 2020 R. Cummings +Expires: November 14, 2020 R. Cummings National Instruments Y. Jiang Huawei Technologies Co., Ltd. D. Fedyk LabN Consulting, L.L.C. - May 6, 2020 + May 13, 2020 DetNet Flow Information Model - draft-ietf-detnet-flow-information-model-08 + draft-ietf-detnet-flow-information-model-09 Abstract This document describes flow and service information model for 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 @@ -27,21 +27,21 @@ 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 November 7, 2020. + This Internet-Draft will expire on November 14, 2020. Copyright Notice Copyright (c) 2020 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 @@ -52,73 +52,72 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 - 2.4. Naming Conventions . . . . . . . . . . . . . . . . . . . 7 + 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 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 . . . . 11 - 5.4.1. DetNet MPLS Flow Identification and Specification . . 11 + 5.4. Identification and Specification of DetNet Flows . . . . 10 + 5.4.1. DetNet MPLS Flow Identification and Specification . . 10 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 . . . . . . . . 13 - 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.2. Maximum Latency of the DetNet Flow . . . . . . . . . 13 + 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 13 + 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 13 5.9.5. Maximum Consecutive 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 . . . . . . . . . . . . . . 14 - 6.1. Management ID of the DetNet service . . . . . . . . . . . 15 + 6.1. Management ID of the DetNet service . . . . . . . . . . . 14 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 . . . . . . . 15 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 15 - 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 Consecutive Loss of the DetNet Service . . . 16 + 6.3.3. Maximum Latency Variation of the DetNet Service . . . 15 + 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 15 + 6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 15 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 . . . . . . . . . 16 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 16 - 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 + 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 16 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 17 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 18 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 18 - 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 11.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.2. Informative References . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low packet loss rates and assured maximum end-to-end delivery latency. A description of the general background and concepts of DetNet can be found in [RFC8655]. This document describes the Detnet Flow Service Information Model. @@ -201,48 +200,48 @@ +-+ v +-+ nodes +-+ +-+ +-+ Figure 2: Usage of Information models (flow, service and configuration) DetNet flow and service information model is based on [RFC8655] and on the concept of data model specified by [IEEE8021Qcc]. Furthermore, the origination of the DetNet flow information model was - the flow identification possibilities described in [IEEE8021CB], - which is used by [IEEE8021Qcc] as well. In addition to the TSN data - model, [IEEE8021Qcc] also specifies configuration of TSN features - (e.g., traffic scheduling specified by [IEEE8021Qbv]). The common - architecture and flow model, allow configured features to be + the flow identification possibilities described in Section 6. of + [IEEE8021CB], which is used by [IEEE8021Qcc] as well. In addition to + the TSN data model, [IEEE8021Qcc] also specifies configuration of TSN + features (e.g., traffic scheduling specified by [IEEE8021Qbv]). The + common architecture and flow model, allow configured features to be consistent in certain deployment scenarios, e.g., when the network that provides the DetNet service includes both L3 and L2 network segments. 1.1. Goals As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates with IEEE 802.1 TSN in order to define a common architecture for both Layer 2 and Layer 3. This is beneficial for several reasons, e.g., in order to simplify implementations and maintain consistency across diverse networks. The flow and service information models are also aligned for those reasons. Therefore, the DetNet flow and service information models described in this document are based on [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. This document specifies flow and service information models only. 1.2. Non Goals - This document (this revision) does not specify flow data models or - DetNet configuration. Therefore, the goals of this document differ - from the goals of [IEEE8021Qcc], which also specifies the TSN data - model and configuration of certain TSN features. + This document does not specify flow data models or DetNet + configuration. Therefore, the goals of this document differ from the + goals of [IEEE8021Qcc], which also specifies the TSN data model and + configuration of certain TSN features. 2. Terminology 2.1. Terms Used in This Document This document uses the terminology established in the DetNet architecture [RFC8655] and 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 [RFC8655] is used to perform @@ -280,43 +279,35 @@ DetNet Deterministic Networking. DN DetNet. MPLS Multiprotocol Label Switching. PSN Packet Switched Network. TSN Time-Sensitive Networking. -2.3. Requirements Language - - 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. - -2.4. Naming Conventions +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 Descriptive names are used. - o Names MUST start with uppercase letters. + o Names 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. Example composed - names are SourceMacAddress and DestinationIPv6Address. + o Composed names 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. Example composed names are + SourceMacAddress and DestinationIPv6Address. 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. @@ -523,27 +514,26 @@ b. MaxPacketsPerInterval: the maximum number of packets that the Ingress will transmit in one Interval. 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. - [[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 delay-and-loss sensitive). - Possible options how to extend DnTrafficSpecification attributes is - for further discussion. ]] + 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 DnTrafficSpecification + attributes is for further discussion. 5.6. Endpoints of the DetNet Flow The 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 example, for App- flows with MPLS encapsulation defining an ingress node is more common @@ -575,32 +565,32 @@ * OutOfService: Administratively blocked. b. DnEgressStatus is an enumeration for the status of the flow's Egress reference points: * None: no Egress. * Ready: all Egresses are ready. * PartialFailed: One or more Egress ready, and one or more Egress failed. The DetNet flow can be used if the Ingress is Ready. + * Failed: All Egresses failed. * OutOfService: Administratively blocked. c. FailureCode: A non-zero code that specifies the error 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). - [[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.]] + Defining FailureCodes for DetNet is out-of-scope in this document. + Table 46-1 of [IEEE8021Qcc] describes TSN failure codes. 5.9. Requirements of the DetNet Flow DnFlowRequirements specifies requirements to ensure the service level desired for the DetNet flow. The DnFlowRequirements includes the following attributes: a. MinBandwidth(Section 5.9.1) b. MaxLatency(Section 5.9.2) @@ -783,23 +774,23 @@ Ready. * Failed: All Egresses failed. * OutOfService: Administratively blocked. c. DnServiceFailureCode: A non-zero code that specifies the error if the DetNet service encounters a failure (e.g., packet replication and elimination is requested but not possible, or DnServiceIngressStatus is Failed, or DnServiceEgressStatus is Failed, or DnServiceEgressStatus is PartialFailed). - [[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.]] + Defining DnServiceFailureCodes for DetNet service is out-of-scope in + this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure + codes. 7. Flow Specific Operations The DetNet flow information model relies on three high level information groups: 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. @@ -850,70 +841,73 @@ between the Join and the Leave, then while figuring out whether the new flow spec can be supported, the controller entity has to assume that the resources committed to the current flow are in use. By using Modify the controller entity knows that the resources supporting the current flow can be available for supporting the altered flow. Modify is considered to be an optional operation due to possible controller plane limitations. 8. Summary - This document describes DetNet flow information model and service - information model for DetNet IP networks and DetNet MPLS networks. + This document describes the DetNet flow information model and the + service information model for DetNet IP networks and DetNet MPLS + networks. These models are used as input for the YANG model. 9. IANA Considerations N/A. 10. Security Considerations - Security considerations for DetNet are described in detail in - [I-D.ietf-detnet-security]. General security considerations are - described in [RFC8655]. This section covers security for the Flow - Information Model and there are no additional security considerations - introduced by this document. + The external interfaces of the DetNet domain need to be subject to + appropriate confidentiality. Additionally, knowledge of which flows/ + services are provided to a customer or delivered by a network + operator may supply information that can be used in a variety of + security attacks. Security considerations for DetNet are described + in detail in [I-D.ietf-detnet-security]. General security + considerations are described in [RFC8655]. This document discusses + modeling the information, not how it is exchanged. 11. References 11.1. Normative References [I-D.ietf-detnet-ip] - Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., - and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- - ip-05 (work in progress), February 2020. + Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. + Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06 + (work in progress), April 2020. [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-05 (work in progress), February - 2020. + Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., + and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- + detnet-mpls-06 (work in progress), April 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . 11.2. Informative References [I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- - data-plane-framework-04 (work in progress), February 2020. + data-plane-framework-06 (work in progress), May 2020. [I-D.ietf-detnet-security] Mizrahi, T. and E. Grossman, "Deterministic Networking (DetNet) Security Considerations", draft-ietf-detnet- security-09 (work in progress), March 2020. [IEEE8021CB] IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE Standard for Local and metropolitan area networks - Frame Replication and Elimination for Reliability", 2017, @@ -943,36 +937,35 @@ [IETFDetNet] IETF, "IETF Deterministic Networking (DetNet) Working Group", . [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, . Authors' Addresses - - Janos Farkas + Balazs Varga Ericsson Magyar tudosok korutja 11 Budapest 1117 Hungary - Email: janos.farkas@ericsson.com + Email: balazs.a.varga@ericsson.com - Balazs Varga + Janos Farkas Ericsson Magyar tudosok korutja 11 Budapest 1117 Hungary - Email: balazs.a.varga@ericsson.com + Email: janos.farkas@ericsson.com Rodney Cummings National Instruments 11500 N. Mopac Expwy Bldg. C Austin, TX 78759-3504 USA Email: rodney.cummings@ni.com