idnits 2.17.1 draft-ietf-detnet-flow-information-model-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2019) is 1642 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-01 == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-02 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet J. Farkas 3 Internet-Draft B. Varga 4 Intended status: Standards Track Ericsson 5 Expires: April 29, 2020 R. Cummings 6 National Instruments 7 Y. Jiang 8 Huawei Technologies Co., Ltd. 9 D. Fedyk 10 LabN Consulting, L.L.C. 11 October 27, 2019 13 DetNet Flow Information Model 14 draft-ietf-detnet-flow-information-model-06 16 Abstract 18 This document describes flow and service information model for 19 Deterministic Networking (DetNet). These models are defined for IP 20 and MPLS DetNet data planes 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 29, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 7 63 2.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 64 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 65 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 66 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 8 67 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 68 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 9 69 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 9 70 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 71 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 10 72 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 73 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 11 74 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 11 75 5.4. Identification and Specification of DetNet Flows . . . . 11 76 5.4.1. DetNet MPLS Flow Identification and Specification . . 11 77 5.4.2. DetNet IP Flow Identification and Specification . . . 11 78 5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11 79 5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12 80 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12 81 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 13 82 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13 83 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14 84 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14 85 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14 86 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14 87 5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14 88 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14 89 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14 90 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15 91 6.1. Management ID of the DetNet service . . . . . . . . . . . 15 92 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15 93 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15 94 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 15 95 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16 96 6.3.3. Maximum Latency Variation of the DetNet Service . . . 16 97 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16 98 6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 16 99 6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16 100 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16 101 6.5. BiDir requirement of the DetNet Service . . . . . . . . . 16 102 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17 103 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 104 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18 105 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18 106 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 18 107 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 18 108 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 110 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 113 11.2. Informative References . . . . . . . . . . . . . . . . . 20 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 116 1. Introduction 118 Deterministic Networking (DetNet) provides a capability to carry 119 specified unicast or multicast data flows for real-time applications 120 with extremely low packet loss rates and assured maximum end-to-end 121 delivery latency. A description of the general background and 122 concepts of DetNet can be found in [I-D.ietf-detnet-architecture]. 124 This document describes the Detnet Flow Service Information Model. 125 For reference [RFC3444] describes the rational behind Information 126 Models in general. This document describes the Flow and Service 127 information models for operators and users to understand Detnet 128 services, and for implementors as a guide to the functionality 129 required by Detnet services. 131 The DetNet Architecture treats the DetNet related data plane 132 functions decomposed into two sub-layers: a service sub-layer and a 133 forwarding sub-layer. The service sub-layer is used to provide 134 DetNet service protection and reordering. The forwarding sub-layer 135 provides resource allocation (to ensure low loss, assured latency, 136 and limited out-of-order delivery) and leverages Traffic Engineering 137 mechanisms. 139 In the IETF DetNet service utilizes IP or MPLS and DetNet is 140 currently defined for IP and MPLS networks as shown in Figure 1 based 141 on Figure 2 and Figure 3 of [I-D.ietf-detnet-data-plane-framework]. 142 IEEE 802.1 Time Sensitive Networking (TSN) utilizes Ethernet and is 143 defined over Ethernet networks. A DetNet flow includes one or more 144 App-flow(s) as payload. App-flows can be Ethernet, MPLS, or IP 145 flows, which impacts which header fields are utilized to identify a 146 flow. DetNet flows are identified by the DetNet encapsulation of 147 App-flow(s) (e.g., MPLS labels, IP 6-tuple etc.). In some scenarios 148 App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow 149 over a DetNet IP network). 151 +-----+ 152 | TSN | 153 +-------+ +-+-----+-+ 154 | DN IP | | DN MPLS | 155 +--+--+----+----+ +-+---+-----+-+ 156 | TSN | DN MPLS | | TSN | DN IP | 157 +-----+---------+ +-----+-------+ 159 Figure 1: DetNet Service Examples as per Data Plane Framework 161 As shown in Figure 1 as per [I-D.ietf-detnet-data-plane-framework] a 162 DetNet flow can be treated as an application level flow (App-flow) 163 e.g., at DetNet flow aggregation or in a sub-network that 164 interconnects DetNet nodes. 166 The DetNet flow and service information model provided by this 167 document contains both DetNet flow and App-flow specific information 168 in an integrated fashion. 170 In a given network scenario three information models can 171 distinguished: 173 o Flow models that describe characteristics of data flows. These 174 models describe in detail all relevant aspects of a flow that are 175 needed to support the flow properly by the network between the 176 source and the destination(s). 178 o Service models that describe characteristics of services being 179 provided for data flows over a network. These models can be 180 treated as a network operator independent information model. 182 o Configuration models that describe in detail the settings required 183 on network nodes to provide a data flow proper service. 185 Service and flow information models are used between the user and the 186 network operator. Configuration information models are used between 187 the management/control plane entity of the network and the network 188 nodes. They are shown in Figure 2. 190 User Network Operator 191 flow/service 192 /\ info model +---+ 193 / \ <---------------> | X | management/control 194 ---- +-+-+ plane entity 195 ^ 196 | configuration 197 | info model 198 +------------+ 199 v | | 200 +-+ | v Network 201 +-+ v +-+ nodes 202 +-+ +-+ 203 +-+ 205 Figure 2: Usage of Information models (flow, service and 206 configuration) 208 DetNet flow and service information model is based on 209 [I-D.ietf-detnet-architecture] and on the concept of data model 210 specified by [IEEE8021Qcc]. Furthermore, the origination of the 211 DetNet flow information model was the flow identification 212 possibilities described in [IEEE8021CB], which is used by 213 [IEEE8021Qcc] as well. In addition to the TSN data model, 214 [IEEE8021Qcc] also specifies configuration of TSN features (e.g., 215 traffic scheduling specified by [IEEE8021Qbv]). The common 216 architecture and flow model, allow configured features to be 217 consistent in certain deployment scenarios, e.g., when the network 218 that provides the DetNet service includes both L3 and L2 network 219 segments. 221 1.1. Goals 223 As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates 224 with IEEE 802.1 TSN in order to define a common architecture for both 225 Layer 2 and Layer 3. This is beneficial for several reasons, e.g., 226 in order to simplify implementations and maintain consistency across 227 diverse networks. The flow and service information models are also 228 aligned for those reasons. Therefore, the DetNet flow and service 229 information models described in this document are based on 230 [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. 232 This document specifies flow and service information models only. 234 1.2. Non Goals 236 This document (this revision) does not specify flow data models or 237 DetNet configuration. Therefore, the goals of this document differ 238 from the goals of [IEEE8021Qcc], which also specifies the TSN data 239 model and configuration of certain TSN features. 241 2. Terminology 243 2.1. Terms Used in This Document 245 This document uses the terminology established in the DetNet 246 architecture [I-D.ietf-detnet-architecture] and the DetNet Data Plane 247 Framework [I-D.ietf-detnet-data-plane-framework]. The reader is 248 assumed to be familiar with these documents and any terminology 249 defined therein. The DetNet <=> TSN dictionary of 250 [I-D.ietf-detnet-architecture] is used to perform translation from 251 [IEEE8021Qcc] to this document. 253 The following terminology is used in accordance with 254 [I-D.ietf-detnet-architecture]: 256 App-flow The payload (data) carried over a DetNet service. 258 DetNet flow A DetNet flow is a sequence of packets which conform 259 uniquely to a flow identifier, and to which the DetNet 260 service is to be provided. It includes any DetNet 261 headers added to support the DetNet service and 262 forwarding sub-layers. 264 The following terminology is introduced in this document: 266 Source Reference point for an App-flow, where the flow starts. 268 Destination Reference point for an App-flow, where the flow 269 terminates. 271 DN Ingress Reference point for the start of a DetNet flow. 272 Networking technology specific encapsulation may be 273 added here to the served App-flow(s). 275 DN Egress Reference point for the termination of a DetNet flow. 276 Networking technology specific encapsulation may be 277 removed here from the served App-flow(s). 279 2.2. Abbreviations 281 The following abbreviations are used in this document: 283 DetNet Deterministic Networking. 285 DN DetNet. 287 MPLS Multiprotocol Label Switching. 289 PSN Packet Switched Network. 291 TSN Time-Sensitive Networking. 293 2.3. Naming Conventions 295 The following naming conventions were used for naming information 296 model components in this document. It is recommended that extensions 297 of the model use the same conventions. 299 o Names SHOULD be descriptive. 301 o Names MUST start with uppercase letters. 303 o Composed names MUST use capital letters for the first letter of 304 each component. All other letters are lowercase, even for 305 acronyms. Exceptions are made for acronyms containing a mixture 306 of lowercase and capital letters, such as IPv6. Example composed 307 names are SourceMacAddress and DestinationIPv6Address. 309 2.4. Requirements Language 311 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 312 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 313 "OPTIONAL" in this document are to be interpreted as described in BCP 314 14 [RFC2119] [RFC8174] when, and only when, they appear in all 315 capitals, as shown here. 317 3. DetNet Domain and its Modeling 319 3.1. DetNet Service Overview 321 The DetNet service can be defined as a service that provides a 322 capability to carry a unicast or a multicast data flow for an 323 application with constrained requirements on network performance, 324 e.g., low packet loss rate and/or latency. 326 Figure 5 and Figure 8 in [I-D.ietf-detnet-architecture] show the 327 DetNet service related reference points and main components. 329 3.2. Reference Points Used in Modeling 331 From service design perspective a fundamental question is the 332 location of the service/flow endpoints, i.e., where the service/flow 333 starts and ends. 335 App-flow specific reference points are the Source (where it starts) 336 and the Destination (where it terminates). Similarly a DetNet flow 337 has reference points termed DN Ingress (where a DetNet flow starts) 338 and DN Egress (where a DetNet flow ends). These reference points may 339 coexist in the same node (e.g., in a DetNet IP end system). DN 340 Ingress and DN Egress reference points are intermediate reference 341 points for a served App-flow. 343 All reference points are assumed in this document to be packet-based 344 reference points. A DN Ingress may add and a DN Egress may remove 345 networking technology specific encapsulation to/from the served App- 346 flow(s) (e.g., MPLS label(s), UDP and IP headers). 348 3.3. Information Elements 350 The DetNet flow information model and the service model relies on 351 three groups of information elements: 353 o App-flow related parameters: these describe the App-flow 354 characteristics (e.g., identification, encapsulation, traffic 355 specification, endpoints, status, etc.) and the App-flow service 356 expectations (e.g., delay, loss, etc.). 358 o DetNet flow related parameters: these describe the DetNet flow 359 characteristics (e.g., identification, format, traffic 360 specification, endpoints, rank, etc.). 362 o DetNet service related parameters: these describe the expected 363 service characteristics (e.g., delivery type, connectivity delay/ 364 loss, status, rank, etc.). 366 In the information model a DetNet flow contains one or more 367 (aggregated) App-flows (N:1 mapping). During DetNet aggregation the 368 aggregated DetNet flows are treated simply as App-flows and the 369 aggregate is the DetNet flow, which provides N:1 mapping. Similarly, 370 there is an aggregated many to one relationship for the DetNet 371 flow(s) to the DetNet Service. 373 4. App-flow Related Parameters 375 When Deterministic service is required by time/loss sensitive 376 application(s) running on an end system during communication with its 377 peer(s), the resulting data exchange has various requirements on 378 delay and/or loss parameters. 380 4.1. App-flow Characteristics 382 App-flow characteristics are described by the following parameters: 384 o FlowID: a unique (management) identifier of the App-flow. It can 385 be used to define the N:1 mapping of App-flows to a DetNet flow. 387 o FlowType: set by the encapsulation format of the flow. It can be 388 Ethernet (TSN), MPLS, or IP. 390 o DataFlowSpecification: a flow descriptor, defining which packets 391 belongs to a flow using, specific packet header fields such as 392 src-addr, dst-addr, label, VLAN-ID, etc. 394 o TrafficSpecification: a flow descriptor, defining traffic 395 parameters such as packet size, transmission time interval, and 396 maximum packets per time interval. 398 o FlowEndpoints: delineate the start and termination reference 399 points of the App-flow by pointing to the source interface/node 400 and destination interface(s)/node(s). 402 o FlowStatus: indicates the status of the App-flow with respect to 403 the establishment of the flow by the connected network, e.g., 404 ready, failed, etc. 406 o FlowRank: indicates the rank of this flow relative to other flows 407 in the connected network. 409 4.2. App-flow Requirements 411 App-flow requirements are described by the following parameters: 413 o FlowRequirements: defines the attributes of the App-flow regarding 414 bandwidth, latency, latency variation, loss, and misordering 415 tolerance. 417 o FlowBiDir: defines the data path requirement of the App-flow 418 whether it must share the same data path and physical path for 419 both directions through the network, e.g., to provide congruent 420 paths in the two directions. 422 5. DetNet Flow Related Parameters 424 The Data model specified by [IEEE8021Qcc] describes data flows using 425 TSN service as periodic flows with fix packet size (i.e., Constant 426 Bit Rate (CBR) flows) or with variable packet size. The same concept 427 is applied for flows using DetNet service. 429 Latency and loss parameters are correlated because the effect of late 430 delivery can result data loss for an application. However, not all 431 applications require hard limits on both latency and loss. For 432 example, some real-time applications allow graceful degradation if 433 loss happens (e.g., sample-based data processing, media 434 distribution). Some other applications may require high-bandwidth 435 connections that make use of packet replication techniques which are 436 economically challenging or even impossible. Some applications may 437 not tolerate loss, but are not delay sensitive (e.g., bufferless 438 sensors). Time or loss sensitive applications may have somewhat 439 special requirements especially for loss (e.g., no loss over two 440 consecutive communication cycles; very low outage time, etc.). 442 DetNet flows have the following attributes: 444 a. DnFlowID (Section 5.1) 445 b. DnPayloadType (Section 5.2) 446 c. DnFlowFormat (Section 5.3) 447 d. DnFlowSpecification (Section 5.4) 448 e. DnTrafficSpecification (Section 5.5) 449 f. DnFlowEndpoints (Section 5.6) 450 g. DnFlowRank (Section 5.7) 451 h. DnFlowStatus (Section 5.8) 453 DetNet flows have the following requirement attributes: 455 o DnFlowRequirements (Section 5.9) 456 o DnFlowBiDir (Section 5.10) 458 Flow attributes are described in the following sections. 460 5.1. Management ID of the DetNet Flow 462 A unique (management) identifier is needed for each DetNet flow 463 within the DetNet domain. It is specified by DnFlowID. It can be 464 used to define the many to one mapping of DetNet flows to a DetNet 465 service. 467 5.2. Payload type of the DetNet Flow 469 The DnPayloadType attribute is set according to the encapsulated App- 470 flow format. The attribute can be Ethernet, MPLS, or IP. 472 5.3. Format of the DetNet Flow 474 The DnFlowFormat attribute is set according to the DetNet PSN 475 technology. The attribute can be MPLS or IP. 477 5.4. Identification and Specification of DetNet Flows 479 Identification options for DetNet flows at the Ingress/Egress and 480 within the DetNet domain are specified as follows; see Section 5.4.1 481 for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows. 483 5.4.1. DetNet MPLS Flow Identification and Specification 485 The identification of DetNet MPLS flows within the DetNet domain is 486 based on the MPLS context in the service information model. The 487 attributes are specific to the MPLS forwarding paradigm within the 488 DetNet domain [I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be 489 identified and specified by the following attributes: 491 a. SLabel 492 b. FLabelStack 494 5.4.2. DetNet IP Flow Identification and Specification 496 DetNet IP flows can be identified and specified by the following 497 attributes (6-tuple) [I-D.ietf-detnet-ip]: 499 a. SourceIpAddress 500 b. DestinationIpAddress 501 c. IPv6FlowLabel 502 d. Dscp (attribute) 503 e. Protocol 504 f. SourcePort 505 g. DestinationPort 506 h. IPSecSpi 508 5.5. Traffic Specification of the DetNet Flow 510 DnTrafficSpecification attributes specify how the DN Ingress 511 transmits packets for the DetNet flow. This is effectively the 512 promise/request of the DN Ingress to the network. The network uses 513 this traffic specification to allocate resources and adjust queue 514 parameters in network nodes. 516 TrafficSpecification has the following attributes: 518 a. Interval: the period of time in which the traffic specification 519 is specified. 521 b. MaxPacketsPerInterval: the maximum number of packets that the 522 Ingress will transmit in one Interval. 524 c. MaxPayloadSize: the maximum payload size that the Ingress will 525 transmit. 527 These attributes can be used to describe any type of traffic (e.g., 528 CBR, VBR, etc.) and can be used during resource allocation to 529 represent worst case scenarios. 531 [[Editor's note (to be removed from a future revision): Further 532 optional attributes can be considered to achieve more efficient 533 resource allocation. Such optional attributes might be worth for 534 flows with soft requirements (i.e., the flow is only loss sensitive 535 or only delay sensitive, but not both delay-and-loss sensitive). 536 Possible options how to extend DnTrafficSpecification attributes is 537 for further discussion. ]] 539 5.6. Endpoints of the DetNet Flow 541 The DnFlowEndpoints attribute defines the starting and termination 542 reference points of the DetNet flow by pointing to the ingress 543 interface/node and egress interface(s)/node(s). Depending on the 544 network scenario it defines an interface or a node. Interface can be 545 defined for example if the App-flow is a TSN Stream and it is 546 received over a well defined UNI interface. For example, for App- 547 flows with MPLS encapsulation defining an ingress node is more common 548 when per platform label space is used. 550 5.7. Rank of the DetNet Flow 552 The DnFlowRank attribute provides the rank of this flow relative to 553 other flows in the DetNet domain. Rank (range: 0-255) is used by the 554 DetNet domain to decide which flows can and cannot exist when network 555 resources reach their limit. Rank is used to help to determine which 556 flows can be bumped (i.e., removed from node configuration thereby 557 releasing its resources) if for example a port of a node becomes 558 oversubscribed (e.g., due to network re-configuration). 560 5.8. Status of the DetNet Flow 562 DnFlowStatus provides the status of the DetNet flow with respect to 563 the establishment of the flow by the DetNet domain. 565 The DnFlowStatus SHALL include the following attributes: 567 a. DnIngressStatus is an enumeration for the status of the flow's 568 Ingress reference point: 570 * None: no Ingress. 571 * Ready: Ingress is ready. 572 * Failed: Ingress failed. 573 * OutOfService: Administratively blocked. 575 b. DnEgressStatus is an enumeration for the status of the flow's 576 Egress reference points: 578 * None: no Egress. 579 * Ready: all Egresses are ready. 580 * PartialFailed: One or more Egress ready, and one or more 581 Egress failed. The DetNet flow can be used if the Ingress is 582 Ready. 583 * Failed: All Egresses failed. 584 * OutOfService: Administratively blocked. 586 c. FailureCode: A non-zero code that specifies the error if the 587 DetNet flow encounters a failure (e.g., packet replication and 588 elimination is requested but not possible, or DnIngressStatus is 589 Failed, or DnEgressStatus is Failed, or DnEgressStatus is 590 PartialFailed). 592 [[Editor's note (to be removed from a future revision): FailureCodes 593 to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 594 failure codes.]] 596 5.9. Requirements of the DetNet Flow 598 DnFlowRequirements specifies requirements to ensure the service level 599 desired for the DetNet flow. 601 The DnFlowRequirements includes the following attributes: 603 a. MinBandwidth(Section 5.9.1) 604 b. MaxLatency(Section 5.9.2) 605 c. MaxLatencyVariation(Section 5.9.3) 606 d. MaxLoss(Section 5.9.4) 607 e. MaxConsecutiveLossTolerance(Section 5.9.5) 608 f. MaxMisordering(Section 5.9.6) 610 5.9.1. Minimum Bandwidth of the DetNet Flow 612 MinBandwidth is the minimum bandwidth that has to be guaranteed for 613 the DetNet flow. MinBandwidth is specified in octets per second. 615 5.9.2. Maximum Latency of the DetNet Flow 617 MaxLatency is the maximum latency from Ingress to Egress(es) for a 618 single packet of the DetNet flow. MaxLatency is specified as an 619 integer number of nanoseconds. 621 5.9.3. Maximum Latency Variation of the DetNet Flow 623 MaxLatencyVariation is the difference between the minimum and the 624 maximum end-to-end one-way latency. MaxLatencyVariation is specified 625 as an integer number of nanoseconds. 627 5.9.4. Maximum Loss of the DetNet Flow 629 MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for 630 the DetNet flow between the Ingress and Egress(es). 632 5.9.5. Maximum Consecutive Loss of the DetNet Flow 634 Some applications have special loss requirement, such as 635 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 636 parameter describes the maximum number of consecutive packets whose 637 loss can be tolerated. The maximum consecutive loss tolerance can be 638 measured for example based on sequence number. 640 5.9.6. Maximum Misordering Tolerance of the DetNet Flow 642 MaxMisordering describes the tolerable maximum number of packets that 643 can be received out of order. The maximum allowed misordering can be 644 measured for example based on sequence number. The value zero for 645 the maximum allowed misordering indicates that in order delivery is 646 required, misordering cannot be tolerated. 648 5.10. BiDir requirement of the DetNet Flow 650 DnFlowBiDir attribute defines the requirement that the flow and the 651 corresponding reverse direction flow must share the same path (links 652 and nodes) through the routed or switch network in the DetNet domain, 653 e.g., to provide congruent paths in the two directions that share 654 fate and path characteristics. 656 6. DetNet Service Related Parameters 658 DetNet service have the following attributes: 660 a. DnServiceID (Section 6.1) 661 b. DnServiceDeliveryType (Section 6.2) 662 c. DnServiceDeliveryProfile (Section 6.3) 663 d. DNServiceConnectivity (Section 6.4) 664 e. DnServiceBiDir (Section 6.5) 665 f. DnServiceRank (Section 6.6) 666 g. DnServiceStatus (Section 6.7) 668 Service attributes are described in the following sections. 670 6.1. Management ID of the DetNet service 672 A unique (management) identifier for each DetNet service within the 673 DetNet domain. It can be used to define the many to one mapping of 674 DetNet flows to a DetNet service. 676 6.2. Delivery Type of the DetNet service 678 The DnServiceDeliveryType attribute is set according to the payload 679 of the served DetNet flow (i.e., the encapsulated App-flow format). 680 The attribute can be Ethernet, MPLS, or IP. 682 6.3. Delivery Profile of the DetNet Service 684 DnServiceDeliveryProfile specifies delivery profile to ensure proper 685 serving of the DetNet flow. 687 The DnServiceDeliveryProfile includes the following attributes: 689 a. MinBandwidth(Section 6.3.1) 690 b. MaxLatency(Section 6.3.2) 691 c. MaxLatencyVariation(Section 6.3.3) 692 d. MaxLoss(Section 6.3.4) 693 e. MaxConsecutiveLossTolerance(Section 6.3.5) 694 f. MaxMisordering(Section 6.3.6) 696 6.3.1. Minimum Bandwidth of the DetNet Service 698 MinBandwidth is the minimum bandwidth that has to be guaranteed for 699 the DetNet service. MinBandwidth is specified in octets per second. 701 6.3.2. Maximum Latency of the DetNet Service 703 MaxLatency is the maximum latency from Ingress to Egress(es) for a 704 single packet of the DetNet flow. MaxLatency is specified as an 705 integer number of nanoseconds. 707 6.3.3. Maximum Latency Variation of the DetNet Service 709 MaxLatencyVariation is the difference between the minimum and the 710 maximum end-to-end one-way latency. MaxLatencyVariation is specified 711 as an integer number of nanoseconds. 713 6.3.4. Maximum Loss of the DetNet Service 715 MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the 716 DetNet service between the Ingress and Egress(es) of the DetNet 717 domain. 719 6.3.5. Maximum Consecutive Loss of the DetNet Service 721 Some applications have special loss requirement, such as 722 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 723 parameter describes the maximum number of consecutive packets whose 724 loss can be tolerated. The maximum consecutive loss tolerance can be 725 measured for example based on sequence number. 727 6.3.6. Maximum Misordering Tolerance of the DetNet Service 729 MaxMisordering describes the tolerable maximum number of packets that 730 can be received out of order. The maximum allowed misordering can be 731 measured for example based on sequence number. The value zero for 732 the maximum allowed misordering indicates that in order delivery is 733 required, misordering cannot be tolerated. 735 6.4. Connectivity Type of the DetNet Service 737 Two connectivity types are distinguished: point-to-point (p2p) and 738 point-to-multipoint (p2mp). Connectivity type p2mp is created by a 739 transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity 740 is a superposition of p2mp connections.) 742 6.5. BiDir requirement of the DetNet Service 744 The DnServiceBiDir attribute defines the requirement that the flow 745 and the corresponding reverse direction flow must share the same path 746 (links and nodes) through the routed or switch network in the DetNet 747 domain, e.g., to provide congruent paths in the two directions that 748 share fate and path characteristics. 750 6.6. Rank of the DetNet Service 752 The DnServiceRank attribute provides the rank of a service instance 753 relative to other services in the DetNet domain. DnServiceRank 754 (range: 0-255) is used by the network in case of network resource 755 limitation scenarios. 757 6.7. Status of the DetNet Service 759 DnServiceStatus information group includes elements that specify the 760 status of the service specific state of the DetNet domain. This 761 information group informs the user whether or not the service is 762 ready for use. 764 The DnServiceStatus SHALL include the following attributes: 766 a. DnServiceIngressStatus is an enumeration for the status of the 767 service's Ingress: 769 * None: no Ingress. 770 * Ready: Ingress is ready. 771 * Failed: Ingress failed. 772 * OutOfService: Administratively blocked. 774 b. DnServiceEgressStatus is an enumeration for the status of the 775 service's Egress: 777 * None: no Egress. 778 * Ready: all Egresses are ready. 779 * PartialFailed: One or more Egress ready, and one or more 780 Egress failed. The DetNet flow can be used if the Ingress is 781 Ready. 782 * Failed: All Egresses failed. 783 * OutOfService: Administratively blocked. 785 c. DnServiceFailureCode: A non-zero code that specifies the error if 786 the DetNet service encounters a failure (e.g., packet replication 787 and elimination is requested but not possible, or 788 DnServiceIngressStatus is Failed, or DnServiceEgressStatus is 789 Failed, or DnServiceEgressStatus is PartialFailed). 791 [[Editor's note (to be removed from a future revision): 792 DnServiceFailureCodes to be defined for DetNet service. Table 46-1 793 of [IEEE8021Qcc] describes TSN failure codes.]] 795 7. Flow Specific Operations 797 The DetNet flow information model relies on three high level 798 information groups: 800 o DnIngress: The DnIngress information group includes elements that 801 specify the source for a single DetNet flow. This information 802 group is applied from the user of the DetNet service to the 803 network. 805 o DnEgress: The DnEgress information group includes elements that 806 specify the destination for a single DetNet flow. This 807 information group is applied from the user of the DetNet service 808 to the network. 810 o DnFlowStatus: The status information group includes elements that 811 specify the status of the flow in the network. This information 812 group is applied from the network to the user of the DetNet 813 service. This information group informs the user whether or not 814 the DetNet flow is ready for use. 816 There are three possible operations for each DetNet flow with respect 817 to its DetNet service at a DN Ingress or a DN Egress (similarly to 818 App-flows at a Source or a Destination): 820 o Join: DN Ingress/DN Egress intends to join the flow. 821 o Leave: DN Ingress/DN Egress intends to leave the flow. 822 o Modify: DN Ingress/DN Egress intends to change the flow. 824 7.1. Join Operation 826 For the join operation, the DnFlowSpecification, DnFlowRank, 827 DnFlowEndpoint, and DnTrafficSpecification SHALL be included within 828 the DnIngress or DnEgress information group. For the join operation, 829 the DnServiceRequirements groups MAY be included. 831 7.2. Leave Operation 833 For the leave operation, the DnFlowSpecification and DnFlowEndpoint 834 SHALL be included within the DnIngress or DnEgress information group. 836 7.3. Modify Operation 838 For the modify operation, the DnFlowSpecification, DnFlowRank, 839 DnFlowEndpoint, and DnTrafficSpecification SHALL be included within 840 the DnIngress or DnEgress information group. For the join operation, 841 the DnServiceRequirements groups MAY be included. 843 The Modify operation can be considered to address cases when a flow 844 is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been 845 changed. The advantage of having a Modify is that it allows 846 initiation of a change of flow spec while leaving the current flow is 847 operating until the change is accepted. If there is no linkage 848 between the Join and the Leave, then while figuring out whether the 849 new flow spec can be supported, the controller entity has to assume 850 that the resources committed to the current flow are in use. By 851 using Modify the controller entity knows that the resources 852 supporting the current flow can be available for supporting the 853 altered flow. Modify is considered to be an optional operation due 854 to possible controller plane limitations. 856 8. Summary 858 This document describes DetNet flow information model and service 859 information model for DetNet IP networks and DetNet MPLS networks. 861 9. IANA Considerations 863 N/A. 865 10. Security Considerations 867 Security considerations for DetNet are described in detail in 868 [I-D.ietf-detnet-security]. General security considerations are 869 described in [I-D.ietf-detnet-architecture]. This section covers 870 security for the Flow Information Model and there are no additional 871 security considerations introduced by this document. 873 11. References 875 11.1. Normative References 877 [I-D.ietf-detnet-architecture] 878 Finn, N., Thubert, P., Varga, B., and J. Farkas, 879 "Deterministic Networking Architecture", draft-ietf- 880 detnet-architecture-13 (work in progress), May 2019. 882 [I-D.ietf-detnet-ip] 883 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 884 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 885 draft-ietf-detnet-ip-01 (work in progress), July 2019. 887 [I-D.ietf-detnet-mpls] 888 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 889 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 890 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, 894 DOI 10.17487/RFC2119, March 1997, 895 . 897 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 898 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 899 May 2017, . 901 11.2. Informative References 903 [I-D.ietf-detnet-data-plane-framework] 904 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 905 Bryant, S., and J. Korhonen, "DetNet Data Plane 906 Framework", draft-ietf-detnet-data-plane-framework-02 907 (work in progress), September 2019. 909 [I-D.ietf-detnet-security] 910 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 911 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 912 Networking (DetNet) Security Considerations", draft-ietf- 913 detnet-security-05 (work in progress), August 2019. 915 [IEEE8021CB] 916 IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE 917 Standard for Local and metropolitan area networks - Frame 918 Replication and Elimination for Reliability", 2017, 919 . 921 [IEEE8021Q] 922 IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE 923 Standard for Local and metropolitan area networks - 924 Bridges and Bridged Networks", 2018, 925 . 927 [IEEE8021Qbv] 928 IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE 929 Standard for Local and metropolitan area networks - 930 Bridges and Bridged Networks - Amendment 25: Enhancements 931 for Scheduled Traffic", 2015, 932 . 934 [IEEE8021Qcc] 935 IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE 936 Standard for Local and metropolitan area networks - 937 Bridges and Bridged Networks -- Amendment 31: Stream 938 Reservation Protocol (SRP) Enhancements and Performance 939 Improvements", 2018, 940 . 942 [IETFDetNet] 943 IETF, "IETF Deterministic Networking (DetNet) Working 944 Group", . 946 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 947 Information Models and Data Models", RFC 3444, 948 DOI 10.17487/RFC3444, January 2003, 949 . 951 Authors' Addresses 953 Janos Farkas 954 Ericsson 955 Magyar tudosok korutja 11 956 Budapest 1117 957 Hungary 959 Email: janos.farkas@ericsson.com 961 Balazs Varga 962 Ericsson 963 Magyar tudosok korutja 11 964 Budapest 1117 965 Hungary 967 Email: balazs.a.varga@ericsson.com 969 Rodney Cummings 970 National Instruments 971 11500 N. Mopac Expwy 972 Bldg. C 973 Austin, TX 78759-3504 974 USA 976 Email: rodney.cummings@ni.com 977 Yuanlong Jiang 978 Huawei Technologies Co., Ltd. 979 Bantian, Longgang district 980 Shenzhen 518129 981 China 983 Email: jiangyuanlong@huawei.com 985 Don Fedyk 986 LabN Consulting, L.L.C. 988 Email: dfedyk@labn.net