idnits 2.17.1 draft-ietf-detnet-flow-information-model-08.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 (May 6, 2020) is 1451 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-05 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-05 == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-04 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-09 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: Informational Ericsson 5 Expires: November 7, 2020 R. Cummings 6 National Instruments 7 Y. Jiang 8 Huawei Technologies Co., Ltd. 9 D. Fedyk 10 LabN Consulting, L.L.C. 11 May 6, 2020 13 DetNet Flow Information Model 14 draft-ietf-detnet-flow-information-model-08 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 November 7, 2020. 39 Copyright Notice 41 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 63 2.4. Naming Conventions . . . . . . . . . . . . . . . . . . . 7 64 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 65 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 66 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7 67 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 68 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8 69 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8 70 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 71 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9 72 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 73 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10 74 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 12 82 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13 83 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 13 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 . . . . . . . . . . . . . . 14 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 . . . . . . . . 15 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 . . . . . . . . . . . . . . . 16 103 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 104 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 17 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 [RFC8655]. 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 [RFC8655] and 209 on the concept of data model specified by [IEEE8021Qcc]. 210 Furthermore, the origination of the DetNet flow information model was 211 the flow identification possibilities described in [IEEE8021CB], 212 which is used by [IEEE8021Qcc] as well. In addition to the TSN data 213 model, [IEEE8021Qcc] also specifies configuration of TSN features 214 (e.g., traffic scheduling specified by [IEEE8021Qbv]). The common 215 architecture and flow model, allow configured features to be 216 consistent in certain deployment scenarios, e.g., when the network 217 that provides the DetNet service includes both L3 and L2 network 218 segments. 220 1.1. Goals 222 As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates 223 with IEEE 802.1 TSN in order to define a common architecture for both 224 Layer 2 and Layer 3. This is beneficial for several reasons, e.g., 225 in order to simplify implementations and maintain consistency across 226 diverse networks. The flow and service information models are also 227 aligned for those reasons. Therefore, the DetNet flow and service 228 information models described in this document are based on 229 [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. 231 This document specifies flow and service information models only. 233 1.2. Non Goals 235 This document (this revision) does not specify flow data models or 236 DetNet configuration. Therefore, the goals of this document differ 237 from the goals of [IEEE8021Qcc], which also specifies the TSN data 238 model and configuration of certain TSN features. 240 2. Terminology 242 2.1. Terms Used in This Document 244 This document uses the terminology established in the DetNet 245 architecture [RFC8655] and the DetNet Data Plane Framework 246 [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be 247 familiar with these documents and any terminology defined therein. 248 The DetNet <=> TSN dictionary of [RFC8655] is used to perform 249 translation from [IEEE8021Qcc] to this document. 251 The following terminology is used in accordance with [RFC8655]: 253 App-flow The payload (data) carried over a DetNet service. 255 DetNet flow A DetNet flow is a sequence of packets which conform 256 uniquely to a flow identifier, and to which the DetNet 257 service is to be provided. It includes any DetNet 258 headers added to support the DetNet service and 259 forwarding sub-layers. 261 The following terminology is introduced in this document: 263 Source Reference point for an App-flow, where the flow starts. 265 Destination Reference point for an App-flow, where the flow 266 terminates. 268 DN Ingress Reference point for the start of a DetNet flow. 269 Networking technology specific encapsulation may be 270 added here to the served App-flow(s). 272 DN Egress Reference point for the termination of a DetNet flow. 273 Networking technology specific encapsulation may be 274 removed here from the served App-flow(s). 276 2.2. Abbreviations 278 The following abbreviations are used in this document: 280 DetNet Deterministic Networking. 282 DN DetNet. 284 MPLS Multiprotocol Label Switching. 286 PSN Packet Switched Network. 288 TSN Time-Sensitive Networking. 290 2.3. Requirements Language 292 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 293 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 294 "OPTIONAL" in this document are to be interpreted as described in BCP 295 14 [RFC2119] [RFC8174] when, and only when, they appear in all 296 capitals, as shown here. 298 2.4. Naming Conventions 300 The following naming conventions were used for naming information 301 model components in this document. It is recommended that extensions 302 of the model use the same conventions. 304 o Names SHOULD be descriptive. 306 o Names MUST start with uppercase letters. 308 o Composed names MUST use capital letters for the first letter of 309 each component. All other letters are lowercase, even for 310 acronyms. Exceptions are made for acronyms containing a mixture 311 of lowercase and capital letters, such as IPv6. Example composed 312 names are SourceMacAddress and DestinationIPv6Address. 314 3. DetNet Domain and its Modeling 316 3.1. DetNet Service Overview 318 The DetNet service can be defined as a service that provides a 319 capability to carry a unicast or a multicast data flow for an 320 application with constrained requirements on network performance, 321 e.g., low packet loss rate and/or latency. 323 Figure 5 and Figure 8 in [RFC8655] show the DetNet service related 324 reference points and main components. 326 3.2. Reference Points Used in Modeling 328 From service design perspective a fundamental question is the 329 location of the service/flow endpoints, i.e., where the service/flow 330 starts and ends. 332 App-flow specific reference points are the Source (where it starts) 333 and the Destination (where it terminates). Similarly a DetNet flow 334 has reference points termed DN Ingress (where a DetNet flow starts) 335 and DN Egress (where a DetNet flow ends). These reference points may 336 coexist in the same node (e.g., in a DetNet IP end system). DN 337 Ingress and DN Egress reference points are intermediate reference 338 points for a served App-flow. 340 All reference points are assumed in this document to be packet-based 341 reference points. A DN Ingress may add and a DN Egress may remove 342 networking technology specific encapsulation to/from the served App- 343 flow(s) (e.g., MPLS label(s), UDP and IP headers). 345 3.3. Information Elements 347 The DetNet flow information model and the service model relies on 348 three groups of information elements: 350 o App-flow related parameters: these describe the App-flow 351 characteristics (e.g., identification, encapsulation, traffic 352 specification, endpoints, status, etc.) and the App-flow service 353 expectations (e.g., delay, loss, etc.). 355 o DetNet flow related parameters: these describe the DetNet flow 356 characteristics (e.g., identification, format, traffic 357 specification, endpoints, rank, etc.). 359 o DetNet service related parameters: these describe the expected 360 service characteristics (e.g., delivery type, connectivity delay/ 361 loss, status, rank, etc.). 363 In the information model a DetNet flow contains one or more 364 (aggregated) App-flows (N:1 mapping). During DetNet aggregation the 365 aggregated DetNet flows are treated simply as App-flows and the 366 aggregate is the DetNet flow, which provides N:1 mapping. Similarly, 367 there is an aggregated many to one relationship for the DetNet 368 flow(s) to the DetNet Service. 370 4. App-flow Related Parameters 372 When Deterministic service is required by time/loss sensitive 373 application(s) running on an end system during communication with its 374 peer(s), the resulting data exchange has various requirements on 375 delay and/or loss parameters. 377 4.1. App-flow Characteristics 379 App-flow characteristics are described by the following parameters: 381 o FlowID: a unique (management) identifier of the App-flow. It can 382 be used to define the N:1 mapping of App-flows to a DetNet flow. 384 o FlowType: set by the encapsulation format of the flow. It can be 385 Ethernet (TSN), MPLS, or IP. 387 o DataFlowSpecification: a flow descriptor, defining which packets 388 belongs to a flow using, specific packet header fields such as 389 src-addr, dst-addr, label, VLAN-ID, etc. 391 o TrafficSpecification: a flow descriptor, defining traffic 392 parameters such as packet size, transmission time interval, and 393 maximum packets per time interval. 395 o FlowEndpoints: delineate the start and termination reference 396 points of the App-flow by pointing to the source interface/node 397 and destination interface(s)/node(s). 399 o FlowStatus: indicates the status of the App-flow with respect to 400 the establishment of the flow by the connected network, e.g., 401 ready, failed, etc. 403 o FlowRank: indicates the rank of this flow relative to other flows 404 in the connected network. 406 4.2. App-flow Requirements 408 App-flow requirements are described by the following parameters: 410 o FlowRequirements: defines the attributes of the App-flow regarding 411 bandwidth, latency, latency variation, loss, and misordering 412 tolerance. 414 o FlowBiDir: defines the data path requirement of the App-flow 415 whether it must share the same data path and physical path for 416 both directions through the network, e.g., to provide congruent 417 paths in the two directions. 419 5. DetNet Flow Related Parameters 421 The Data model specified by [IEEE8021Qcc] describes data flows using 422 TSN service as periodic flows with fix packet size (i.e., Constant 423 Bit Rate (CBR) flows) or with variable packet size. The same concept 424 is applied for flows using DetNet service. 426 Latency and loss parameters are correlated because the effect of late 427 delivery can result data loss for an application. However, not all 428 applications require hard limits on both latency and loss. For 429 example, some real-time applications allow graceful degradation if 430 loss happens (e.g., sample-based data processing, media 431 distribution). Some other applications may require high-bandwidth 432 connections that make use of packet replication techniques which are 433 economically challenging or even impossible. Some applications may 434 not tolerate loss, but are not delay sensitive (e.g., bufferless 435 sensors). Time or loss sensitive applications may have somewhat 436 special requirements especially for loss (e.g., no loss over two 437 consecutive communication cycles; very low outage time, etc.). 439 DetNet flows have the following attributes: 441 a. DnFlowID (Section 5.1) 442 b. DnPayloadType (Section 5.2) 443 c. DnFlowFormat (Section 5.3) 444 d. DnFlowSpecification (Section 5.4) 445 e. DnTrafficSpecification (Section 5.5) 446 f. DnFlowEndpoints (Section 5.6) 447 g. DnFlowRank (Section 5.7) 448 h. DnFlowStatus (Section 5.8) 450 DetNet flows have the following requirement attributes: 452 o DnFlowRequirements (Section 5.9) 453 o DnFlowBiDir (Section 5.10) 455 Flow attributes are described in the following sections. 457 5.1. Management ID of the DetNet Flow 459 A unique (management) identifier is needed for each DetNet flow 460 within the DetNet domain. It is specified by DnFlowID. It can be 461 used to define the many to one mapping of DetNet flows to a DetNet 462 service. 464 5.2. Payload type of the DetNet Flow 466 The DnPayloadType attribute is set according to the encapsulated App- 467 flow format. The attribute can be Ethernet, MPLS, or IP. 469 5.3. Format of the DetNet Flow 471 The DnFlowFormat attribute is set according to the DetNet PSN 472 technology. The attribute can be MPLS or IP. 474 5.4. Identification and Specification of DetNet Flows 476 Identification options for DetNet flows at the Ingress/Egress and 477 within the DetNet domain are specified as follows; see Section 5.4.1 478 for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows. 480 5.4.1. DetNet MPLS Flow Identification and Specification 482 The identification of DetNet MPLS flows within the DetNet domain is 483 based on the MPLS context in the service information model. The 484 attributes are specific to the MPLS forwarding paradigm within the 485 DetNet domain [I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be 486 identified and specified by the following attributes: 488 a. SLabel 489 b. FLabelStack 491 5.4.2. DetNet IP Flow Identification and Specification 493 DetNet IP flows can be identified and specified by the following 494 attributes [I-D.ietf-detnet-ip]: 496 a. SourceIpAddress 497 b. DestinationIpAddress 498 c. IPv6FlowLabel 499 d. Dscp (attribute) 500 e. Protocol 501 f. SourcePort 502 g. DestinationPort 503 h. IPSecSpi 505 The IP 6-tuple that is used for DetNet IP flow identification 506 consists of items a, b, d, e, f, and g. Items c and h are additional 507 attributes that can be used for DetNet flow identification in 508 addition to the 6-tuple. 510 5.5. Traffic Specification of the DetNet Flow 512 DnTrafficSpecification attributes specify how the DN Ingress 513 transmits packets for the DetNet flow. This is effectively the 514 promise/request of the DN Ingress to the network. The network uses 515 this traffic specification to allocate resources and adjust queue 516 parameters in network nodes. 518 TrafficSpecification has the following attributes: 520 a. Interval: the period of time in which the traffic specification 521 is specified. 523 b. MaxPacketsPerInterval: the maximum number of packets that the 524 Ingress will transmit in one Interval. 526 c. MaxPayloadSize: the maximum payload size that the Ingress will 527 transmit. 529 These attributes can be used to describe any type of traffic (e.g., 530 CBR, VBR, etc.) and can be used during resource allocation to 531 represent worst case scenarios. 533 [[Editor's note (to be removed from a future revision): Further 534 optional attributes can be considered to achieve more efficient 535 resource allocation. Such optional attributes might be worth for 536 flows with soft requirements (i.e., the flow is only loss sensitive 537 or only delay sensitive, but not both delay-and-loss sensitive). 538 Possible options how to extend DnTrafficSpecification attributes is 539 for further discussion. ]] 541 5.6. Endpoints of the DetNet Flow 543 The DnFlowEndpoints attribute defines the starting and termination 544 reference points of the DetNet flow by pointing to the ingress 545 interface/node and egress interface(s)/node(s). Depending on the 546 network scenario it defines an interface or a node. Interface can be 547 defined for example if the App-flow is a TSN Stream and it is 548 received over a well defined UNI interface. For example, for App- 549 flows with MPLS encapsulation defining an ingress node is more common 550 when per platform label space is used. 552 5.7. Rank of the DetNet Flow 554 The DnFlowRank attribute provides the rank of this flow relative to 555 other flows in the DetNet domain. Rank (range: 0-255) is used by the 556 DetNet domain to decide which flows can and cannot exist when network 557 resources reach their limit. Rank is used to help to determine which 558 flows can be bumped (i.e., removed from node configuration thereby 559 releasing its resources) if for example a port of a node becomes 560 oversubscribed (e.g., due to network re-configuration). 562 5.8. Status of the DetNet Flow 564 DnFlowStatus provides the status of the DetNet flow with respect to 565 the establishment of the flow by the DetNet domain. 567 The DnFlowStatus includes the following attributes: 569 a. DnIngressStatus is an enumeration for the status of the flow's 570 Ingress reference point: 572 * None: no Ingress. 573 * Ready: Ingress is ready. 574 * Failed: Ingress failed. 575 * OutOfService: Administratively blocked. 577 b. DnEgressStatus is an enumeration for the status of the flow's 578 Egress reference points: 580 * None: no Egress. 581 * Ready: all Egresses are ready. 582 * PartialFailed: One or more Egress ready, and one or more 583 Egress failed. The DetNet flow can be used if the Ingress is 584 Ready. 585 * Failed: All Egresses failed. 586 * OutOfService: Administratively blocked. 588 c. FailureCode: A non-zero code that specifies the error if the 589 DetNet flow encounters a failure (e.g., packet replication and 590 elimination is requested but not possible, or DnIngressStatus is 591 Failed, or DnEgressStatus is Failed, or DnEgressStatus is 592 PartialFailed). 594 [[Editor's note (to be removed from a future revision): FailureCodes 595 to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 596 failure codes.]] 598 5.9. Requirements of the DetNet Flow 600 DnFlowRequirements specifies requirements to ensure the service level 601 desired for the DetNet flow. 603 The DnFlowRequirements includes the following attributes: 605 a. MinBandwidth(Section 5.9.1) 606 b. MaxLatency(Section 5.9.2) 607 c. MaxLatencyVariation(Section 5.9.3) 608 d. MaxLoss(Section 5.9.4) 609 e. MaxConsecutiveLossTolerance(Section 5.9.5) 610 f. MaxMisordering(Section 5.9.6) 612 5.9.1. Minimum Bandwidth of the DetNet Flow 614 MinBandwidth is the minimum bandwidth that has to be guaranteed for 615 the DetNet flow. MinBandwidth is specified in octets per second. 617 5.9.2. Maximum Latency of the DetNet Flow 619 MaxLatency is the maximum latency from Ingress to Egress(es) for a 620 single packet of the DetNet flow. MaxLatency is specified as an 621 integer number of nanoseconds. 623 5.9.3. Maximum Latency Variation of the DetNet Flow 625 MaxLatencyVariation is the difference between the minimum and the 626 maximum end-to-end one-way latency. MaxLatencyVariation is specified 627 as an integer number of nanoseconds. 629 5.9.4. Maximum Loss of the DetNet Flow 631 MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for 632 the DetNet flow between the Ingress and Egress(es). 634 5.9.5. Maximum Consecutive Loss of the DetNet Flow 636 Some applications have special loss requirement, such as 637 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 638 parameter describes the maximum number of consecutive packets whose 639 loss can be tolerated. The maximum consecutive loss tolerance can be 640 measured for example based on sequence number. 642 5.9.6. Maximum Misordering Tolerance of the DetNet Flow 644 MaxMisordering describes the tolerable maximum number of packets that 645 can be received out of order. The maximum allowed misordering can be 646 measured for example based on sequence number. The value zero for 647 the maximum allowed misordering indicates that in order delivery is 648 required, misordering cannot be tolerated. 650 5.10. BiDir requirement of the DetNet Flow 652 DnFlowBiDir attribute defines the requirement that the flow and the 653 corresponding reverse direction flow must share the same path (links 654 and nodes) through the routed or switch network in the DetNet domain, 655 e.g., to provide congruent paths in the two directions that share 656 fate and path characteristics. 658 6. DetNet Service Related Parameters 660 DetNet service have the following attributes: 662 a. DnServiceID (Section 6.1) 663 b. DnServiceDeliveryType (Section 6.2) 664 c. DnServiceDeliveryProfile (Section 6.3) 665 d. DNServiceConnectivity (Section 6.4) 666 e. DnServiceBiDir (Section 6.5) 667 f. DnServiceRank (Section 6.6) 668 g. DnServiceStatus (Section 6.7) 670 Service attributes are described in the following sections. 672 6.1. Management ID of the DetNet service 674 A unique (management) identifier for each DetNet service within the 675 DetNet domain. It can be used to define the many to one mapping of 676 DetNet flows to a DetNet service. 678 6.2. Delivery Type of the DetNet service 680 The DnServiceDeliveryType attribute is set according to the payload 681 of the served DetNet flow (i.e., the encapsulated App-flow format). 682 The attribute can be Ethernet, MPLS, or IP. 684 6.3. Delivery Profile of the DetNet Service 686 DnServiceDeliveryProfile specifies delivery profile to ensure proper 687 serving of the DetNet flow. 689 The DnServiceDeliveryProfile includes the following attributes: 691 a. MinBandwidth(Section 6.3.1) 692 b. MaxLatency(Section 6.3.2) 693 c. MaxLatencyVariation(Section 6.3.3) 694 d. MaxLoss(Section 6.3.4) 695 e. MaxConsecutiveLossTolerance(Section 6.3.5) 696 f. MaxMisordering(Section 6.3.6) 698 6.3.1. Minimum Bandwidth of the DetNet Service 700 MinBandwidth is the minimum bandwidth that has to be guaranteed for 701 the DetNet service. MinBandwidth is specified in octets per second. 703 6.3.2. Maximum Latency of the DetNet Service 705 MaxLatency is the maximum latency from Ingress to Egress(es) for a 706 single packet of the DetNet flow. MaxLatency is specified as an 707 integer number of nanoseconds. 709 6.3.3. Maximum Latency Variation of the DetNet Service 711 MaxLatencyVariation is the difference between the minimum and the 712 maximum end-to-end one-way latency. MaxLatencyVariation is specified 713 as an integer number of nanoseconds. 715 6.3.4. Maximum Loss of the DetNet Service 717 MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the 718 DetNet service between the Ingress and Egress(es) of the DetNet 719 domain. 721 6.3.5. Maximum Consecutive Loss of the DetNet Service 723 Some applications have special loss requirement, such as 724 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 725 parameter describes the maximum number of consecutive packets whose 726 loss can be tolerated. The maximum consecutive loss tolerance can be 727 measured for example based on sequence number. 729 6.3.6. Maximum Misordering Tolerance of the DetNet Service 731 MaxMisordering describes the tolerable maximum number of packets that 732 can be received out of order. The maximum allowed misordering can be 733 measured for example based on sequence number. The value zero for 734 the maximum allowed misordering indicates that in order delivery is 735 required, misordering cannot be tolerated. 737 6.4. Connectivity Type of the DetNet Service 739 Two connectivity types are distinguished: point-to-point (p2p) and 740 point-to-multipoint (p2mp). Connectivity type p2mp is created by a 741 transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity 742 is a superposition of p2mp connections.) 744 6.5. BiDir requirement of the DetNet Service 746 The DnServiceBiDir attribute defines the requirement that the flow 747 and the corresponding reverse direction flow must share the same path 748 (links and nodes) through the routed or switch network in the DetNet 749 domain, e.g., to provide congruent paths in the two directions that 750 share fate and path characteristics. 752 6.6. Rank of the DetNet Service 754 The DnServiceRank attribute provides the rank of a service instance 755 relative to other services in the DetNet domain. DnServiceRank 756 (range: 0-255) is used by the network in case of network resource 757 limitation scenarios. 759 6.7. Status of the DetNet Service 761 DnServiceStatus information group includes elements that specify the 762 status of the service specific state of the DetNet domain. This 763 information group informs the user whether or not the service is 764 ready for use. 766 The DnServiceStatus includes the following attributes: 768 a. DnServiceIngressStatus is an enumeration for the status of the 769 service's Ingress: 771 * None: no Ingress. 772 * Ready: Ingress is ready. 773 * Failed: Ingress failed. 774 * OutOfService: Administratively blocked. 776 b. DnServiceEgressStatus is an enumeration for the status of the 777 service's Egress: 779 * None: no Egress. 780 * Ready: all Egresses are ready. 781 * PartialFailed: One or more Egress ready, and one or more 782 Egress failed. The DetNet flow can be used if the Ingress is 783 Ready. 784 * Failed: All Egresses failed. 785 * OutOfService: Administratively blocked. 787 c. DnServiceFailureCode: A non-zero code that specifies the error if 788 the DetNet service encounters a failure (e.g., packet replication 789 and elimination is requested but not possible, or 790 DnServiceIngressStatus is Failed, or DnServiceEgressStatus is 791 Failed, or DnServiceEgressStatus is PartialFailed). 793 [[Editor's note (to be removed from a future revision): 794 DnServiceFailureCodes to be defined for DetNet service. Table 46-1 795 of [IEEE8021Qcc] describes TSN failure codes.]] 797 7. Flow Specific Operations 799 The DetNet flow information model relies on three high level 800 information groups: 802 o DnIngress: The DnIngress information group includes elements that 803 specify the source for a single DetNet flow. This information 804 group is applied from the user of the DetNet service to the 805 network. 807 o DnEgress: The DnEgress information group includes elements that 808 specify the destination for a single DetNet flow. This 809 information group is applied from the user of the DetNet service 810 to the network. 812 o DnFlowStatus: The status information group includes elements that 813 specify the status of the flow in the network. This information 814 group is applied from the network to the user of the DetNet 815 service. This information group informs the user whether or not 816 the DetNet flow is ready for use. 818 There are three possible operations for each DetNet flow with respect 819 to its DetNet service at a DN Ingress or a DN Egress (similarly to 820 App-flows at a Source or a Destination): 822 o Join: DN Ingress/DN Egress intends to join the flow. 823 o Leave: DN Ingress/DN Egress intends to leave the flow. 824 o Modify: DN Ingress/DN Egress intends to change the flow. 826 7.1. Join Operation 828 For the join operation, the DnFlowSpecification, DnFlowRank, 829 DnFlowEndpoint, and DnTrafficSpecification are included within the 830 DnIngress or DnEgress information group. For the join operation, the 831 DnServiceRequirements groups can be included. 833 7.2. Leave Operation 835 For the leave operation, the DnFlowSpecification and DnFlowEndpoint 836 are included within the DnIngress or DnEgress information group. 838 7.3. Modify Operation 840 For the modify operation, the DnFlowSpecification, DnFlowRank, 841 DnFlowEndpoint, and DnTrafficSpecification are included within the 842 DnIngress or DnEgress information group. For the join operation, the 843 DnServiceRequirements groups can be included. 845 The Modify operation can be considered to address cases when a flow 846 is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been 847 changed. The advantage of having a Modify is that it allows 848 initiation of a change of flow spec while leaving the current flow is 849 operating until the change is accepted. If there is no linkage 850 between the Join and the Leave, then while figuring out whether the 851 new flow spec can be supported, the controller entity has to assume 852 that the resources committed to the current flow are in use. By 853 using Modify the controller entity knows that the resources 854 supporting the current flow can be available for supporting the 855 altered flow. Modify is considered to be an optional operation due 856 to possible controller plane limitations. 858 8. Summary 860 This document describes DetNet flow information model and service 861 information model for DetNet IP networks and DetNet MPLS networks. 863 9. IANA Considerations 865 N/A. 867 10. Security Considerations 869 Security considerations for DetNet are described in detail in 870 [I-D.ietf-detnet-security]. General security considerations are 871 described in [RFC8655]. This section covers security for the Flow 872 Information Model and there are no additional security considerations 873 introduced by this document. 875 11. References 877 11.1. Normative References 879 [I-D.ietf-detnet-ip] 880 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 881 and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- 882 ip-05 (work in progress), February 2020. 884 [I-D.ietf-detnet-mpls] 885 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 886 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 887 draft-ietf-detnet-mpls-05 (work in progress), February 888 2020. 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, 892 DOI 10.17487/RFC2119, March 1997, 893 . 895 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 896 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 897 May 2017, . 899 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 900 "Deterministic Networking Architecture", RFC 8655, 901 DOI 10.17487/RFC8655, October 2019, 902 . 904 11.2. Informative References 906 [I-D.ietf-detnet-data-plane-framework] 907 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 908 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 909 data-plane-framework-04 (work in progress), February 2020. 911 [I-D.ietf-detnet-security] 912 Mizrahi, T. and E. Grossman, "Deterministic Networking 913 (DetNet) Security Considerations", draft-ietf-detnet- 914 security-09 (work in progress), March 2020. 916 [IEEE8021CB] 917 IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE 918 Standard for Local and metropolitan area networks - Frame 919 Replication and Elimination for Reliability", 2017, 920 . 922 [IEEE8021Q] 923 IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE 924 Standard for Local and metropolitan area networks - 925 Bridges and Bridged Networks", 2018, 926 . 928 [IEEE8021Qbv] 929 IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE 930 Standard for Local and metropolitan area networks - 931 Bridges and Bridged Networks - Amendment 25: Enhancements 932 for Scheduled Traffic", 2015, 933 . 935 [IEEE8021Qcc] 936 IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE 937 Standard for Local and metropolitan area networks - 938 Bridges and Bridged Networks -- Amendment 31: Stream 939 Reservation Protocol (SRP) Enhancements and Performance 940 Improvements", 2018, 941 . 943 [IETFDetNet] 944 IETF, "IETF Deterministic Networking (DetNet) Working 945 Group", . 947 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 948 Information Models and Data Models", RFC 3444, 949 DOI 10.17487/RFC3444, January 2003, 950 . 952 Authors' Addresses 954 Janos Farkas 955 Ericsson 956 Magyar tudosok korutja 11 957 Budapest 1117 958 Hungary 960 Email: janos.farkas@ericsson.com 962 Balazs Varga 963 Ericsson 964 Magyar tudosok korutja 11 965 Budapest 1117 966 Hungary 968 Email: balazs.a.varga@ericsson.com 970 Rodney Cummings 971 National Instruments 972 11500 N. Mopac Expwy 973 Bldg. C 974 Austin, TX 78759-3504 975 USA 977 Email: rodney.cummings@ni.com 979 Yuanlong Jiang 980 Huawei Technologies Co., Ltd. 981 Bantian, Longgang district 983 Shenzhen 518129 984 China 986 Email: jiangyuanlong@huawei.com 987 Don Fedyk 988 LabN Consulting, L.L.C. 990 Email: dfedyk@labn.net