--- 1/draft-ietf-detnet-flow-information-model-12.txt 2020-12-14 00:14:02.826703068 -0800 +++ 2/draft-ietf-detnet-flow-information-model-13.txt 2020-12-14 00:14:02.874704294 -0800 @@ -1,24 +1,24 @@ DetNet B. Varga Internet-Draft J. Farkas Intended status: Informational Ericsson -Expires: June 5, 2021 R. Cummings +Expires: June 16, 2021 R. Cummings National Instruments Y. Jiang Huawei Technologies Co., Ltd. D. Fedyk LabN Consulting, L.L.C. - December 2, 2020 + December 13, 2020 DetNet Flow Information Model - draft-ietf-detnet-flow-information-model-12 + draft-ietf-detnet-flow-information-model-13 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 June 5, 2021. + This Internet-Draft will expire on June 16, 2021. 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 @@ -114,60 +114,59 @@ 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 and Service Information - Model. For reference [RFC3444] describes the rational behind + Model. For reference [RFC3444] describes the rationale behind Information Models in general. This document describes the Flow and Service information models for operators and users to understand Detnet services, and for implementors as a guide to the functionality required by Detnet services. The DetNet Architecture treats the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer. The service sub-layer is used to provide DetNet service protection and reordering. The forwarding sub-layer provides resource allocation (to ensure low loss, assured latency, and limited out-of-order delivery) and leverages Traffic Engineering mechanisms. In the IETF DetNet service utilizes IP or MPLS and DetNet is currently defined for IP and MPLS networks as shown in Figure 1 based - on Figure 2 and Figure 3 of [I-D.ietf-detnet-data-plane-framework]. - IEEE 802.1 Time Sensitive Networking (TSN) utilizes Ethernet and is - defined over Ethernet networks. A DetNet flow includes one or more - App-flow(s) as payload. App-flows can be Ethernet, MPLS, or IP - flows, which impacts which header fields are utilized to identify a - flow. DetNet flows are identified by the DetNet encapsulation of - App-flow(s) (e.g., MPLS labels, IP 6-tuple etc.). In some scenarios - App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow - over a DetNet IP network). + on Figure 2 and Figure 3 of [RFC8938]. IEEE 802.1 Time Sensitive + Networking (TSN) utilizes Ethernet and is defined over Ethernet + networks. A DetNet flow includes one or more App-flow(s) as payload. + App-flows can be Ethernet, MPLS, or IP flows, which impacts which + header fields are utilized to identify a flow. DetNet flows are + identified by the DetNet encapsulation of App-flow(s) (e.g., MPLS + labels, IP 6-tuple etc.). In some scenarios App-flow and DetNet flow + look similar on the wire (e.g., L3 App-flow over a DetNet IP + network). +-----+ | TSN | +-------+ +-+-----+-+ | DN IP | | DN MPLS | +--+--+----+----+ +-+---+-----+-+ | TSN | DN MPLS | | TSN | DN IP | +-----+---------+ +-----+-------+ Figure 1: DetNet Service Examples as per Data Plane Framework - 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. + As shown in Figure 1 as per [RFC8938] 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. 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 be distinguished: o Flow models that describe characteristics of data flows. These models describe in detail all relevant aspects of a flow that are @@ -226,32 +225,33 @@ 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 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. + configuration of certain TSN features. The DetNet specific YANG data + model is described in [I-D.ietf-detnet-yang]. 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 - translation from [IEEE8021Qcc] to this document. + architecture [RFC8655] and the DetNet Data Plane Framework [RFC8938]. + 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 translation from [IEEE8021Qcc] to this + document. The following terminology is used in accordance with [RFC8655]: App-flow The payload (data) carried over a DetNet service. 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. @@ -478,36 +478,36 @@ attributes are specific to the MPLS forwarding paradigm within the DetNet domain [I-D.ietf-detnet-mpls]. DetNet MPLS flows can be identified and specified by the following attributes: a. SLabel b. FLabelStack 5.4.2. DetNet IP Flow Identification and Specification DetNet IP flows can be identified and specified by the following - attributes [I-D.ietf-detnet-ip]: + attributes [RFC8939]: a. SourceIpAddress b. DestinationIpAddress c. IPv6FlowLabel d. Dscp (attribute) e. Protocol f. SourcePort g. DestinationPort h. IPSecSpi The IP 6-tuple that is used for DetNet IP flow identification consists of items a, b, d, e, f, and g. Items c and h are additional attributes that can be used for DetNet flow identification in addition to the 6-tuple. Using wild cards for these attributes are - specified in [I-D.ietf-detnet-ip]. + specified in [RFC8939]. 5.5. Traffic Specification of the DetNet Flow 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: @@ -523,22 +523,28 @@ d. MinPayloadSize: the minimum payload size that the Ingress will transmit. e. MinPacketsPerInterval: the minimum number of packets that the Ingress will transmit in one Interval. 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. Intervals are specified as an - integer number of nanoseconds. PayloadSizes are specified in octets - per second. + integer number of nanoseconds. PayloadSizes are specified in octets. + + Flows exceeding the traffic specification (i.e., having more traffic + than defined by the maximum attributes) may receive a different + network behavior than the DetNet network has been engineered for. + Excess traffic due to malicious or malfunctioning devices can be + prevented or mitigated (e.g., through the use of existing mechanisms + such as policing and shaping). When MinPayloadSize and MinPacketsPerInterval parameters are used, then all packets less than the MinPayloadSize will be counted as being of the size MinPayloadSize during packet processing when packet size matters, e.g., when policing; and all flows having less than MinPacketsPerInterval will be counted as having MinPacketsPerInterval when the number of packets per interval matters, e.g., during resource reservation. However, flows having less than MinPacketsPerInterval may result in a different network behavior than the DetNet network has been engineered for. MinPayloadSize and @@ -656,23 +662,23 @@ measured for example based on sequence number. 5.9.6. Maximum Misordering Tolerance of the DetNet Flow MaxMisordering describes the tolerable maximum number of packets that can be received out of order. The value zero for the maximum allowed misordering indicates that in order delivery is required, misordering cannot be tolerated. The maximum allowed misordering can be measured for example based on - sequence number. The difference of sequence number values in - consecutive packets at the Egress cannot be bigger than - "MaxMisordering + 1". + sequence numbers. When a packet arrives at the egress after a packet + with a higher sequence number, the difference between the sequence + number values cannot be bigger than "MaxMisordering + 1". 5.10. BiDir requirement of the DetNet Flow DnFlowBiDir attribute defines the requirement that the flow and the corresponding reverse direction flow must share the same path (links and nodes) through the routed or switch network in the DetNet domain, e.g., to provide congruent paths in the two directions that share fate and path characteristics. 6. DetNet Service Related Parameters @@ -897,47 +903,48 @@ 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., and S. - Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 - (work in progress), July 2020. - [I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- detnet-mpls-13 (work in progress), October 2020. [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 + [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. + Bryant, "Deterministic Networking (DetNet) Data Plane: + IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, + . - [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-06 (work in progress), May 2020. +11.2. Informative References [I-D.ietf-detnet-security] Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", draft-ietf- detnet-security-12 (work in progress), October 2020. + [I-D.ietf-detnet-yang] + Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and + Z. Li, "Deterministic Networking (DetNet) Configuration + YANG Model", draft-ietf-detnet-yang-09 (work in progress), + November 2020. + [IEEE8021Q] IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks", 2018, . [IEEE8021Qbv] IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Amendment 25: Enhancements @@ -954,20 +961,25 @@ [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, . + [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. + Bryant, "Deterministic Networking (DetNet) Data Plane + Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, + . + Authors' Addresses Balazs Varga Ericsson Magyar tudosok korutja 11 Budapest 1117 Hungary Email: balazs.a.varga@ericsson.com