idnits 2.17.1 draft-ietf-detnet-flow-information-model-12.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 (December 2, 2020) is 1241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-12 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga 3 Internet-Draft J. Farkas 4 Intended status: Informational Ericsson 5 Expires: June 5, 2021 R. Cummings 6 National Instruments 7 Y. Jiang 8 Huawei Technologies Co., Ltd. 9 D. Fedyk 10 LabN Consulting, L.L.C. 11 December 2, 2020 13 DetNet Flow Information Model 14 draft-ietf-detnet-flow-information-model-12 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 June 5, 2021. 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. Naming Conventions . . . . . . . . . . . . . . . . . . . 7 63 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 64 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 65 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7 66 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 67 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8 68 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8 69 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 70 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9 71 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 72 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10 73 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10 74 5.4. Identification and Specification of DetNet Flows . . . . 10 75 5.4.1. DetNet MPLS Flow Identification and Specification . . 11 76 5.4.2. DetNet IP Flow Identification and Specification . . . 11 77 5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11 78 5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12 79 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 13 80 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 13 81 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 14 82 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14 83 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14 84 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14 85 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14 86 5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14 87 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 15 88 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 15 89 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15 90 6.1. Management ID of the DetNet service . . . . . . . . . . . 15 91 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15 92 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 16 93 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 16 94 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16 95 6.3.3. Maximum Latency Variation of the DetNet Service . . . 16 96 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16 97 6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 16 98 6.3.6. Maximum Misordering Tolerance of the DetNet Service . 17 99 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 17 100 6.5. BiDir requirement of the DetNet Service . . . . . . . . . 17 101 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17 102 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 103 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18 104 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 19 105 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 19 106 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 19 107 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 109 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 112 11.2. Informative References . . . . . . . . . . . . . . . . . 20 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 115 1. Introduction 117 Deterministic Networking (DetNet) provides a capability to carry 118 specified unicast or multicast data flows for real-time applications 119 with extremely low packet loss rates and assured maximum end-to-end 120 delivery latency. A description of the general background and 121 concepts of DetNet can be found in [RFC8655]. 123 This document describes the Detnet Flow and Service Information 124 Model. For reference [RFC3444] describes the rational behind 125 Information Models in general. This document describes the Flow and 126 Service information models for operators and users to understand 127 Detnet services, and for implementors as a guide to the functionality 128 required by Detnet services. 130 The DetNet Architecture treats the DetNet related data plane 131 functions decomposed into two sub-layers: a service sub-layer and a 132 forwarding sub-layer. The service sub-layer is used to provide 133 DetNet service protection and reordering. The forwarding sub-layer 134 provides resource allocation (to ensure low loss, assured latency, 135 and limited out-of-order delivery) and leverages Traffic Engineering 136 mechanisms. 138 In the IETF DetNet service utilizes IP or MPLS and DetNet is 139 currently defined for IP and MPLS networks as shown in Figure 1 based 140 on Figure 2 and Figure 3 of [I-D.ietf-detnet-data-plane-framework]. 141 IEEE 802.1 Time Sensitive Networking (TSN) utilizes Ethernet and is 142 defined over Ethernet networks. A DetNet flow includes one or more 143 App-flow(s) as payload. App-flows can be Ethernet, MPLS, or IP 144 flows, which impacts which header fields are utilized to identify a 145 flow. DetNet flows are identified by the DetNet encapsulation of 146 App-flow(s) (e.g., MPLS labels, IP 6-tuple etc.). In some scenarios 147 App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow 148 over a DetNet IP network). 150 +-----+ 151 | TSN | 152 +-------+ +-+-----+-+ 153 | DN IP | | DN MPLS | 154 +--+--+----+----+ +-+---+-----+-+ 155 | TSN | DN MPLS | | TSN | DN IP | 156 +-----+---------+ +-----+-------+ 158 Figure 1: DetNet Service Examples as per Data Plane Framework 160 As shown in Figure 1 as per [I-D.ietf-detnet-data-plane-framework] a 161 DetNet flow can be treated as an application level flow (App-flow) 162 e.g., at DetNet flow aggregation or in a sub-network that 163 interconnects DetNet nodes. 165 The DetNet flow and service information model provided by this 166 document contains both DetNet flow and App-flow specific information 167 in an integrated fashion. 169 In a given network scenario three information models can be 170 distinguished: 172 o Flow models that describe characteristics of data flows. These 173 models describe in detail all relevant aspects of a flow that are 174 needed to support the flow properly by the network between the 175 source and the destination(s). 177 o Service models that describe characteristics of services being 178 provided for data flows over a network. These models can be 179 treated as a network operator independent information model. 181 o Configuration models that describe in detail the settings required 182 on network nodes to provide a data flow proper service. 184 Service and flow information models are used between the user and the 185 network operator. Configuration information models are used between 186 the management/control plane entity of the network and the network 187 nodes. They are shown in Figure 2. 189 User Network Operator 190 flow/service 191 /\ info model +---+ 192 / \ <---------------> | X | management/control 193 ---- +-+-+ plane entity 194 ^ 195 | configuration 196 | info model 197 +------------+ 198 v | | 199 +-+ | v Network 200 +-+ v +-+ nodes 201 +-+ +-+ 202 +-+ 204 Figure 2: Usage of Information models (flow, service and 205 configuration) 207 DetNet flow and service information model is based on [RFC8655] and 208 on the concept of data model specified by [IEEE8021Qcc]. 209 Furthermore, the DetNet flow and service information models described 210 in this document are based on [IEEE8021Qcc]. In addition to the TSN 211 data model, [IEEE8021Qcc] also specifies configuration of TSN 212 features (e.g., traffic scheduling specified by [IEEE8021Qbv]). The 213 common architecture and flow model, allow configured features to be 214 consistent in certain deployment scenarios, e.g., when the network 215 that provides the DetNet service includes both L3 and L2 network 216 segments. 218 1.1. Goals 220 As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates 221 with IEEE 802.1 TSN in order to define a common architecture for both 222 Layer 2 and Layer 3. This is beneficial for several reasons, e.g., 223 in order to simplify implementations and maintain consistency across 224 diverse networks. The flow and service information models are also 225 aligned for those reasons. Therefore, the DetNet flow and service 226 information models described in this document are based on 227 [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. 229 This document specifies flow and service information models only. 231 1.2. Non Goals 233 This document does not specify flow data models or DetNet 234 configuration. Therefore, the goals of this document differ from the 235 goals of [IEEE8021Qcc], which also specifies the TSN data model and 236 configuration of certain TSN features. 238 2. Terminology 240 2.1. Terms Used in This Document 242 This document uses the terminology established in the DetNet 243 architecture [RFC8655] and the DetNet Data Plane Framework 244 [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be 245 familiar with these documents and any terminology defined therein. 246 The DetNet <=> TSN dictionary of [RFC8655] is used to perform 247 translation from [IEEE8021Qcc] to this document. 249 The following terminology is used in accordance with [RFC8655]: 251 App-flow The payload (data) carried over a DetNet service. 253 DetNet flow A DetNet flow is a sequence of packets which conform 254 uniquely to a flow identifier, and to which the DetNet 255 service is to be provided. It includes any DetNet 256 headers added to support the DetNet service and 257 forwarding sub-layers. 259 The following terminology is introduced in this document: 261 Source Reference point for an App-flow, where the flow starts. 263 Destination Reference point for an App-flow, where the flow 264 terminates. 266 DN Ingress Reference point for the start of a DetNet flow. 267 Networking technology specific encapsulation may be 268 added here to the served App-flow(s). 270 DN Egress Reference point for the termination of a DetNet flow. 271 Networking technology specific encapsulation may be 272 removed here from the served App-flow(s). 274 2.2. Abbreviations 276 The following abbreviations are used in this document: 278 DetNet Deterministic Networking. 280 DN DetNet. 282 MPLS Multiprotocol Label Switching. 284 PSN Packet Switched Network. 286 TSN Time-Sensitive Networking. 288 2.3. Naming Conventions 290 The following naming conventions were used for naming information 291 model components in this document. It is recommended that extensions 292 of the model use the same conventions. 294 o Descriptive names are used. 296 o Names start with uppercase letters. 298 o Composed names use capital letters for the first letter of each 299 component. All other letters are lowercase, even for acronyms. 300 Exceptions are made for acronyms containing a mixture of lowercase 301 and capital letters, such as IPv6. Example composed names are 302 SourceMacAddress and DestinationIPv6Address. 304 3. DetNet Domain and its Modeling 306 3.1. DetNet Service Overview 308 The DetNet service can be defined as a service that provides a 309 capability to carry a unicast or a multicast data flow for an 310 application with constrained requirements on network performance, 311 e.g., low packet loss rate and/or latency. 313 Figure 5 and Figure 8 in [RFC8655] show the DetNet service related 314 reference points and main components. 316 3.2. Reference Points Used in Modeling 318 From service design perspective a fundamental question is the 319 location of the service/flow endpoints, i.e., where the service/flow 320 starts and ends. 322 App-flow specific reference points are the Source (where it starts) 323 and the Destination (where it terminates). Similarly a DetNet flow 324 has reference points termed DN Ingress (where a DetNet flow starts) 325 and DN Egress (where a DetNet flow ends). These reference points may 326 coexist in the same node (e.g., in a DetNet IP end system). DN 327 Ingress and DN Egress reference points are intermediate reference 328 points for a served App-flow. 330 All reference points are assumed in this document to be packet-based 331 reference points. A DN Ingress may add and a DN Egress may remove 332 networking technology specific encapsulation to/from the served App- 333 flow(s) (e.g., MPLS label(s), UDP and IP headers). 335 3.3. Information Elements 337 The DetNet flow information model and the service model relies on 338 three groups of information elements: 340 o App-flow related parameters: these describe the App-flow 341 characteristics (e.g., identification, encapsulation, traffic 342 specification, endpoints, status, etc.) and the App-flow service 343 expectations (e.g., delay, loss, etc.). 345 o DetNet flow related parameters: these describe the DetNet flow 346 characteristics (e.g., identification, format, traffic 347 specification, endpoints, rank, etc.). 349 o DetNet service related parameters: these describe the expected 350 service characteristics (e.g., delivery type, connectivity delay/ 351 loss, status, rank, etc.). 353 In the information model a DetNet flow contains one or more 354 (aggregated) App-flows (N:1 mapping). During DetNet aggregation the 355 aggregated DetNet flows are treated simply as App-flows and the 356 aggregate is the DetNet flow, which provides N:1 mapping. Similarly, 357 there is an aggregated many to one relationship for the DetNet 358 flow(s) to the DetNet Service. 360 4. App-flow Related Parameters 362 When Deterministic service is required by time/loss sensitive 363 application(s) running on an end system during communication with its 364 peer(s), the resulting data exchange has various requirements on 365 delay and/or loss parameters. 367 4.1. App-flow Characteristics 369 App-flow characteristics are described by the following parameters: 371 o FlowID: a unique (management) identifier of the App-flow. It can 372 be used to define the N:1 mapping of App-flows to a DetNet flow. 374 o FlowType: set by the encapsulation format of the flow. It can be 375 Ethernet (TSN), MPLS, or IP. 377 o DataFlowSpecification: a flow descriptor, defining which packets 378 belongs to a flow, using specific packet header fields such as 379 src-addr, dst-addr, label, VLAN-ID, etc. 381 o TrafficSpecification: a flow descriptor, defining traffic 382 parameters such as packet size, transmission time interval, and 383 maximum packets per time interval. 385 o FlowEndpoints: delineate the start and termination reference 386 points of the App-flow by pointing to the source interface/node 387 and destination interface(s)/node(s). 389 o FlowStatus: indicates the status of the App-flow with respect to 390 the establishment of the flow by the connected network, e.g., 391 ready, failed, etc. 393 o FlowRank: indicates the rank of this flow relative to other flows 394 in the connected network. 396 Note: When defining the N:1 mapping of App-flows to a DetNet flow, 397 the App-flows must have the same FlowType and different 398 DataFlowSpecification parameters 400 4.2. App-flow Requirements 402 App-flow requirements are described by the following parameters: 404 o FlowRequirements: defines the attributes of the App-flow regarding 405 bandwidth, latency, latency variation, loss, and misordering 406 tolerance. 408 o FlowBiDir: defines the data path requirement of the App-flow 409 whether it must share the same data path and physical path for 410 both directions through the network, e.g., to provide congruent 411 paths in the two directions. 413 5. DetNet Flow Related Parameters 415 The Data model specified by [IEEE8021Qcc] describes data flows using 416 TSN service as periodic flows with fix packet size (i.e., Constant 417 Bit Rate (CBR) flows) or with variable packet size. The same concept 418 is applied for flows using DetNet service. 420 Latency and loss parameters are correlated because the effect of late 421 delivery can result in data loss for an application. However, not 422 all applications require hard limits on both latency and loss. For 423 example, some real-time applications allow graceful degradation if 424 loss happens (e.g., sample-based data processing, media 425 distribution). Some other applications may require high-bandwidth 426 connections that make use of packet replication techniques which are 427 economically challenging or even impossible. Some applications may 428 not tolerate loss, but are not delay sensitive (e.g., bufferless 429 sensors). Time or loss sensitive applications may have somewhat 430 special requirements especially for loss (e.g., no loss over two 431 consecutive communication cycles; very low outage time, etc.). 433 DetNet flows have the following attributes: 435 a. DnFlowID (Section 5.1) 436 b. DnPayloadType (Section 5.2) 437 c. DnFlowFormat (Section 5.3) 438 d. DnFlowSpecification (Section 5.4) 439 e. DnTrafficSpecification (Section 5.5) 440 f. DnFlowEndpoints (Section 5.6) 441 g. DnFlowRank (Section 5.7) 442 h. DnFlowStatus (Section 5.8) 444 DetNet flows have the following requirement attributes: 446 o DnFlowRequirements (Section 5.9) 447 o DnFlowBiDir (Section 5.10) 449 Flow attributes are described in the following sections. 451 5.1. Management ID of the DetNet Flow 453 A unique (management) identifier is needed for each DetNet flow 454 within the DetNet domain. It is specified by DnFlowID. It can be 455 used to define the many to one mapping of DetNet flows to a DetNet 456 service. 458 5.2. Payload type of the DetNet Flow 460 The DnPayloadType attribute is set according to the encapsulated App- 461 flow format. The attribute can be Ethernet, MPLS, or IP. 463 5.3. Format of the DetNet Flow 465 The DnFlowFormat attribute is set according to the DetNet PSN 466 technology. The attribute can be MPLS or IP. 468 5.4. Identification and Specification of DetNet Flows 470 Identification options for DetNet flows at the Ingress/Egress and 471 within the DetNet domain are specified as follows; see Section 5.4.1 472 for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows. 474 5.4.1. DetNet MPLS Flow Identification and Specification 476 The identification of DetNet MPLS flows within the DetNet domain is 477 based on the MPLS context in the service information model. The 478 attributes are specific to the MPLS forwarding paradigm within the 479 DetNet domain [I-D.ietf-detnet-mpls]. DetNet MPLS flows can be 480 identified and specified by the following attributes: 482 a. SLabel 483 b. FLabelStack 485 5.4.2. DetNet IP Flow Identification and Specification 487 DetNet IP flows can be identified and specified by the following 488 attributes [I-D.ietf-detnet-ip]: 490 a. SourceIpAddress 491 b. DestinationIpAddress 492 c. IPv6FlowLabel 493 d. Dscp (attribute) 494 e. Protocol 495 f. SourcePort 496 g. DestinationPort 497 h. IPSecSpi 499 The IP 6-tuple that is used for DetNet IP flow identification 500 consists of items a, b, d, e, f, and g. Items c and h are additional 501 attributes that can be used for DetNet flow identification in 502 addition to the 6-tuple. Using wild cards for these attributes are 503 specified in [I-D.ietf-detnet-ip]. 505 5.5. Traffic Specification of the DetNet Flow 507 DnTrafficSpecification attributes specify how the DN Ingress 508 transmits packets for the DetNet flow. This is effectively the 509 promise/request of the DN Ingress to the network. The network uses 510 this traffic specification to allocate resources and adjust queue 511 parameters in network nodes. 513 TrafficSpecification has the following attributes: 515 a. Interval: the period of time in which the traffic specification 516 is specified. 518 b. MaxPacketsPerInterval: the maximum number of packets that the 519 Ingress will transmit in one Interval. 521 c. MaxPayloadSize: the maximum payload size that the Ingress will 522 transmit. 524 d. MinPayloadSize: the minimum payload size that the Ingress will 525 transmit. 527 e. MinPacketsPerInterval: the minimum number of packets that the 528 Ingress will transmit in one Interval. 530 These attributes can be used to describe any type of traffic (e.g., 531 CBR, VBR, etc.) and can be used during resource allocation to 532 represent worst case scenarios. Intervals are specified as an 533 integer number of nanoseconds. PayloadSizes are specified in octets 534 per second. 536 When MinPayloadSize and MinPacketsPerInterval parameters are used, 537 then all packets less than the MinPayloadSize will be counted as 538 being of the size MinPayloadSize during packet processing when packet 539 size matters, e.g., when policing; and all flows having less than 540 MinPacketsPerInterval will be counted as having MinPacketsPerInterval 541 when the number of packets per interval matters, e.g., during 542 resource reservation. However, flows having less than 543 MinPacketsPerInterval may result in a different network behavior than 544 the DetNet network has been engineered for. MinPayloadSize and 545 MinPacketsPerInterval parameters, for example, may be used when 546 engineering the latency bounds of a DetNet flow when POF is applied 547 to the given DetNet flow. 549 Further optional attributes can be considered to achieve more 550 efficient resource allocation. Such optional attributes might be 551 worth for flows with soft requirements (i.e., the flow is only loss 552 sensitive or only delay sensitive, but not both delay-and-loss 553 sensitive). Possible options how to extend DnTrafficSpecification 554 attributes is for further discussion. 556 5.6. Endpoints of the DetNet Flow 558 The DnFlowEndpoints attribute defines the starting and termination 559 reference points of the DetNet flow by pointing to the ingress 560 interface/node and egress interface(s)/node(s). Depending on the 561 network scenario it defines an interface or a node. Interface can be 562 defined for example if the App-flow is a TSN Stream and it is 563 received over a well defined UNI interface. For example, for App- 564 flows with MPLS encapsulation defining an ingress node is more common 565 when per platform label space is used. 567 5.7. Rank of the DetNet Flow 569 The DnFlowRank attribute provides the rank of this flow relative to 570 other flows in the DetNet domain. Rank (range: 0-255) is used by the 571 DetNet domain to decide which flows can and cannot exist when network 572 resources reach their limit. Rank is used to help to determine which 573 flows can be bumped (i.e., removed from node configuration thereby 574 releasing its resources) if for example a port of a node becomes 575 oversubscribed (e.g., due to network re-configuration). DnFlowRank 576 value 0 is the highest priority. 578 5.8. Status of the DetNet Flow 580 DnFlowStatus provides the status of the DetNet flow with respect to 581 the establishment of the flow by the DetNet domain. 583 The DnFlowStatus includes the following attributes: 585 a. DnIngressStatus is an enumeration for the status of the flow's 586 Ingress reference point: 588 * None: no Ingress. 589 * Ready: Ingress is ready. 590 * Failed: Ingress failed. 591 * OutOfService: Administratively blocked. 593 b. DnEgressStatus is an enumeration for the status of the flow's 594 Egress reference points: 596 * None: no Egress. 597 * Ready: all Egresses are ready. 598 * PartialFailed: One or more Egress ready, and one or more 599 Egress failed. The DetNet flow can be used if the Ingress is 600 Ready. 601 * Failed: All Egresses failed. 602 * OutOfService: All Egresses are administratively blocked. 604 c. FailureCode: A non-zero code that specifies the error if the 605 DetNet flow encounters a failure (e.g., packet replication and 606 elimination is requested but not possible, or DnIngressStatus is 607 Failed, or DnEgressStatus is Failed, or DnEgressStatus is 608 PartialFailed). 610 Defining FailureCodes for DetNet is out-of-scope in this document. 611 Table 46-1 of [IEEE8021Qcc] describes TSN failure codes. 613 5.9. Requirements of the DetNet Flow 615 DnFlowRequirements specifies requirements to ensure the service level 616 desired for the DetNet flow. 618 The DnFlowRequirements includes the following attributes: 620 a. MinBandwidth(Section 5.9.1) 621 b. MaxLatency(Section 5.9.2) 622 c. MaxLatencyVariation(Section 5.9.3) 623 d. MaxLoss(Section 5.9.4) 624 e. MaxConsecutiveLossTolerance(Section 5.9.5) 625 f. MaxMisordering(Section 5.9.6) 627 5.9.1. Minimum Bandwidth of the DetNet Flow 629 MinBandwidth is the minimum bandwidth that has to be guaranteed for 630 the DetNet flow. MinBandwidth is specified in octets per second. 632 5.9.2. Maximum Latency of the DetNet Flow 634 MaxLatency is the maximum latency from Ingress to Egress(es) for a 635 single packet of the DetNet flow. MaxLatency is specified as an 636 integer number of nanoseconds. 638 5.9.3. Maximum Latency Variation of the DetNet Flow 640 MaxLatencyVariation is the difference between the minimum and the 641 maximum end-to-end one-way latency. MaxLatencyVariation is specified 642 as an integer number of nanoseconds. 644 5.9.4. Maximum Loss of the DetNet Flow 646 MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for 647 the DetNet flow between the Ingress and Egress(es) and the loss 648 measurement interval. 650 5.9.5. Maximum Consecutive Loss of the DetNet Flow 652 Some applications have special loss requirement, such as 653 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 654 parameter describes the maximum number of consecutive packets whose 655 loss can be tolerated. The maximum consecutive loss tolerance can be 656 measured for example based on sequence number. 658 5.9.6. Maximum Misordering Tolerance of the DetNet Flow 660 MaxMisordering describes the tolerable maximum number of packets that 661 can be received out of order. The value zero for the maximum allowed 662 misordering indicates that in order delivery is required, misordering 663 cannot be tolerated. 665 The maximum allowed misordering can be measured for example based on 666 sequence number. The difference of sequence number values in 667 consecutive packets at the Egress cannot be bigger than 668 "MaxMisordering + 1". 670 5.10. BiDir requirement of the DetNet Flow 672 DnFlowBiDir attribute defines the requirement that the flow and the 673 corresponding reverse direction flow must share the same path (links 674 and nodes) through the routed or switch network in the DetNet domain, 675 e.g., to provide congruent paths in the two directions that share 676 fate and path characteristics. 678 6. DetNet Service Related Parameters 680 DetNet service have the following attributes: 682 a. DnServiceID (Section 6.1) 683 b. DnServiceDeliveryType (Section 6.2) 684 c. DnServiceDeliveryProfile (Section 6.3) 685 d. DNServiceConnectivity (Section 6.4) 686 e. DnServiceBiDir (Section 6.5) 687 f. DnServiceRank (Section 6.6) 688 g. DnServiceStatus (Section 6.7) 690 Service attributes are described in the following sections. 692 6.1. Management ID of the DetNet service 694 A unique (management) identifier for each DetNet service within the 695 DetNet domain. It can be used to define the many to one mapping of 696 DetNet flows to a DetNet service. 698 6.2. Delivery Type of the DetNet service 700 The DnServiceDeliveryType attribute is set according to the payload 701 of the served DetNet flow (i.e., the encapsulated App-flow format). 702 The attribute can be Ethernet, MPLS, or IP. 704 6.3. Delivery Profile of the DetNet Service 706 DnServiceDeliveryProfile specifies delivery profile to ensure proper 707 serving of the DetNet flow. 709 The DnServiceDeliveryProfile includes the following attributes: 711 a. MinBandwidth(Section 6.3.1) 712 b. MaxLatency(Section 6.3.2) 713 c. MaxLatencyVariation(Section 6.3.3) 714 d. MaxLoss(Section 6.3.4) 715 e. MaxConsecutiveLossTolerance(Section 6.3.5) 716 f. MaxMisordering(Section 6.3.6) 718 6.3.1. Minimum Bandwidth of the DetNet Service 720 MinBandwidth is the minimum bandwidth that has to be guaranteed for 721 the DetNet service. MinBandwidth is specified in octets per second 722 and excludes additional DetNet header (if any). 724 6.3.2. Maximum Latency of the DetNet Service 726 MaxLatency is the maximum latency from Ingress to Egress(es) for a 727 single packet of the DetNet flow. MaxLatency is specified as an 728 integer number of nanoseconds. 730 6.3.3. Maximum Latency Variation of the DetNet Service 732 MaxLatencyVariation is the difference between the minimum and the 733 maximum end-to-end one-way latency. MaxLatencyVariation is specified 734 as an integer number of nanoseconds. 736 6.3.4. Maximum Loss of the DetNet Service 738 MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the 739 DetNet service between the Ingress and Egress(es) of the DetNet 740 domain. 742 6.3.5. Maximum Consecutive Loss of the DetNet Service 744 Some applications have special loss requirement, such as 745 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 746 parameter describes the maximum number of consecutive packets whose 747 loss can be tolerated. The maximum consecutive loss tolerance can be 748 measured for example based on sequence number. 750 6.3.6. Maximum Misordering Tolerance of the DetNet Service 752 MaxMisordering describes the tolerable maximum number of packets that 753 can be received out of order. The maximum allowed misordering can be 754 measured for example based on sequence number. The value zero for 755 the maximum allowed misordering indicates that in order delivery is 756 required, misordering cannot be tolerated. 758 6.4. Connectivity Type of the DetNet Service 760 Two connectivity types are distinguished: point-to-point (p2p) and 761 point-to-multipoint (p2mp). Connectivity type p2mp may be created by 762 a forwarding function (e.g., p2mp LSP). (Note: from service 763 perspective mp2mp connectivity can be treated as a superposition of 764 p2mp connections.) 766 6.5. BiDir requirement of the DetNet Service 768 The DnServiceBiDir attribute defines the requirement that the flow 769 and the corresponding reverse direction flow must share the same path 770 (links and nodes) through the routed or switch network in the DetNet 771 domain, e.g., to provide congruent paths in the two directions that 772 share fate and path characteristics. 774 6.6. Rank of the DetNet Service 776 The DnServiceRank attribute provides the rank of a service instance 777 relative to other services in the DetNet domain. DnServiceRank 778 (range: 0-255) is used by the network in case of network resource 779 limitation scenarios. DnServiceRank value 0 is the highest priority. 781 6.7. Status of the DetNet Service 783 DnServiceStatus information group includes elements that specify the 784 status of the service specific state of the DetNet domain. This 785 information group informs the user whether or not the service is 786 ready for use. 788 The DnServiceStatus includes the following attributes: 790 a. DnServiceIngressStatus is an enumeration for the status of the 791 service's Ingress: 793 * None: no Ingress. 794 * Ready: Ingress is ready. 795 * Failed: Ingress failed. 796 * OutOfService: Administratively blocked. 798 b. DnServiceEgressStatus is an enumeration for the status of the 799 service's Egress: 801 * None: no Egress. 802 * Ready: all Egresses are ready. 803 * PartialFailed: One or more Egress ready, and one or more 804 Egress failed. The DetNet flow can be used if the Ingress is 805 Ready. 806 * Failed: All Egresses failed. 807 * OutOfService: Administratively blocked. 809 c. DnServiceFailureCode: A non-zero code that specifies the error if 810 the DetNet service encounters a failure (e.g., packet replication 811 and elimination is requested but not possible, or 812 DnServiceIngressStatus is Failed, or DnServiceEgressStatus is 813 Failed, or DnServiceEgressStatus is PartialFailed). 815 Defining DnServiceFailureCodes for DetNet service is out-of-scope in 816 this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure 817 codes. 819 7. Flow Specific Operations 821 The DetNet flow information model relies on three high level 822 information groups: 824 o DnIngress: The DnIngress information group includes elements that 825 specify the source for a single DetNet flow. This information 826 group is applied from the user of the DetNet service to the 827 network. 829 o DnEgress: The DnEgress information group includes elements that 830 specify the destination for a single DetNet flow. This 831 information group is applied from the user of the DetNet service 832 to the network. 834 o DnFlowStatus: The status information group includes elements that 835 specify the status of the flow in the network. This information 836 group is applied from the network to the user of the DetNet 837 service. This information group informs the user whether or not 838 the DetNet flow is ready for use. 840 There are three possible operations for each DetNet flow with respect 841 to its DetNet service at a DN Ingress or a DN Egress (similarly to 842 App-flows at a Source or a Destination): 844 o Join: DN Ingress/DN Egress intends to join the flow. 845 o Leave: DN Ingress/DN Egress intends to leave the flow. 847 o Modify: DN Ingress/DN Egress intends to change the flow. 849 7.1. Join Operation 851 For the join operation, the DnFlowSpecification, DnFlowRank, 852 DnFlowEndpoint, and DnTrafficSpecification are included within the 853 DnIngress or DnEgress information group. For the join operation, the 854 DnServiceRequirements groups can be included. 856 7.2. Leave Operation 858 For the leave operation, the DnFlowSpecification and DnFlowEndpoint 859 are included within the DnIngress or DnEgress information group. 861 7.3. Modify Operation 863 For the modify operation, the DnFlowSpecification, DnFlowRank, 864 DnFlowEndpoint, and DnTrafficSpecification are included within the 865 DnIngress or DnEgress information group. For the join operation, the 866 DnServiceRequirements groups can be included. 868 The Modify operation can be considered to address cases when a flow 869 is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been 870 changed. The advantage of having a Modify is that it allows 871 initiation of a change of flow spec while leaving the current flow is 872 operating until the change is accepted. If there is no linkage 873 between the Join and the Leave, then while figuring out whether the 874 new flow spec can be supported, the controller entity has to assume 875 that the resources committed to the current flow are in use. By 876 using Modify the controller entity knows that the resources 877 supporting the current flow can be available for supporting the 878 altered flow. Modify is considered to be an optional operation due 879 to possible controller plane limitations. 881 8. Summary 883 This document describes the DetNet flow information model and the 884 service information model for DetNet IP networks and DetNet MPLS 885 networks. These models are used as input for creating the DetNet 886 specific YANG model. 888 9. IANA Considerations 890 N/A. 892 10. Security Considerations 894 The external interfaces of the DetNet domain need to be subject to 895 appropriate confidentiality. Additionally, knowledge of which flows/ 896 services are provided to a customer or delivered by a network 897 operator may supply information that can be used in a variety of 898 security attacks. Security considerations for DetNet are described 899 in detail in [I-D.ietf-detnet-security]. General security 900 considerations are described in [RFC8655]. This document discusses 901 modeling the information, not how it is exchanged. 903 11. References 905 11.1. Normative References 907 [I-D.ietf-detnet-ip] 908 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 909 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 910 (work in progress), July 2020. 912 [I-D.ietf-detnet-mpls] 913 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 914 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 915 detnet-mpls-13 (work in progress), October 2020. 917 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 918 "Deterministic Networking Architecture", RFC 8655, 919 DOI 10.17487/RFC8655, October 2019, 920 . 922 11.2. Informative References 924 [I-D.ietf-detnet-data-plane-framework] 925 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 926 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 927 data-plane-framework-06 (work in progress), May 2020. 929 [I-D.ietf-detnet-security] 930 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 931 Networking (DetNet) Security Considerations", draft-ietf- 932 detnet-security-12 (work in progress), October 2020. 934 [IEEE8021Q] 935 IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE 936 Standard for Local and metropolitan area networks - 937 Bridges and Bridged Networks", 2018, 938 . 940 [IEEE8021Qbv] 941 IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE 942 Standard for Local and metropolitan area networks - 943 Bridges and Bridged Networks - Amendment 25: Enhancements 944 for Scheduled Traffic", 2015, 945 . 947 [IEEE8021Qcc] 948 IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE 949 Standard for Local and metropolitan area networks - 950 Bridges and Bridged Networks -- Amendment 31: Stream 951 Reservation Protocol (SRP) Enhancements and Performance 952 Improvements", 2018, 953 . 955 [IETFDetNet] 956 IETF, "IETF Deterministic Networking (DetNet) Working 957 Group", . 959 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 960 Information Models and Data Models", RFC 3444, 961 DOI 10.17487/RFC3444, January 2003, 962 . 964 Authors' Addresses 966 Balazs Varga 967 Ericsson 968 Magyar tudosok korutja 11 969 Budapest 1117 970 Hungary 972 Email: balazs.a.varga@ericsson.com 974 Janos Farkas 975 Ericsson 976 Magyar tudosok korutja 11 977 Budapest 1117 978 Hungary 980 Email: janos.farkas@ericsson.com 981 Rodney Cummings 982 National Instruments 983 11500 N. Mopac Expwy 984 Bldg. C 985 Austin, TX 78759-3504 986 USA 988 Email: rodney.cummings@ni.com 990 Yuanlong Jiang 991 Huawei Technologies Co., Ltd. 992 Bantian, Longgang district 994 Shenzhen 518129 995 China 997 Email: jiangyuanlong@huawei.com 999 Don Fedyk 1000 LabN Consulting, L.L.C. 1002 Email: dfedyk@labn.net