idnits 2.17.1 draft-ietf-detnet-flow-information-model-14.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 (January 24, 2021) is 1185 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-13 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-09 Summary: 0 errors (**), 0 flaws (~~), 3 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: July 28, 2021 R. Cummings 6 National Instruments 7 Y. Jiang 8 Huawei Technologies Co., Ltd. 9 D. Fedyk 10 LabN Consulting, L.L.C. 11 January 24, 2021 13 DetNet Flow and Service Information Model 14 draft-ietf-detnet-flow-information-model-14 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 July 28, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 rationale 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 DetNet service utilizes IP or MPLS and DetNet is currently defined 139 for IP and MPLS networks as shown in Figure 1 based on Figure 2 and 140 Figure 3 of [RFC8938]. IEEE 802.1 Time Sensitive Networking (TSN) 141 utilizes Ethernet and is defined over Ethernet networks. A DetNet 142 flow includes one or more App-flow(s) as payload. App-flows can be 143 Ethernet, MPLS, or IP flows, which impacts which header fields are 144 utilized to identify a flow. DetNet flows are identified by the 145 DetNet encapsulation of App-flow(s) (e.g., MPLS labels, IP 6-tuple 146 etc.). In some scenarios App-flow and DetNet flow look similar on 147 the wire (e.g., L3 App-flow over a DetNet IP network). 149 +-----+ 150 | TSN | 151 +-------+ +-+-----+-+ 152 | DN IP | | DN MPLS | 153 +--+--+----+----+ +-+---+-----+-+ 154 | TSN | DN MPLS | | TSN | DN IP | 155 +-----+---------+ +-----+-------+ 157 Figure 1: DetNet Service Examples as per Data Plane Framework 159 As shown in Figure 1 as per [RFC8938] a DetNet flow can be treated as 160 an application level flow (App-flow) e.g., at DetNet flow aggregation 161 or in a sub-network that interconnects DetNet nodes. 163 The DetNet flow and service information model provided by this 164 document contains both DetNet flow and App-flow specific information 165 in an integrated fashion. 167 In a given network scenario three information models can be 168 distinguished: 170 o Flow models that describe characteristics of data flows. These 171 models describe in detail all relevant aspects of a flow that are 172 needed to support the flow properly by the network between the 173 source and the destination(s). 175 o Service models that describe characteristics of services being 176 provided for data flows over a network. These models can be 177 treated as a network operator independent information model. 179 o Configuration models that describe in detail the settings required 180 on network nodes to provide a data flow proper service. 182 Service and flow information models are used between the user and the 183 network operator. Configuration information models are used between 184 the management/control plane entity of the network and the network 185 nodes. They are shown in Figure 2. 187 User Network Operator 188 flow/service 189 /\ info model +---+ 190 / \ <---------------> | X | management/control 191 ---- +-+-+ plane entity 192 ^ 193 | configuration 194 | info model 195 +------------+ 196 v | | 197 +-+ | v Network 198 +-+ v +-+ nodes 199 +-+ +-+ 200 +-+ 202 Figure 2: Usage of Information models (flow, service and 203 configuration) 205 DetNet flow and service information model is based on [RFC8655] and 206 on the concept of data model specified by [IEEE8021Qcc]. In addition 207 to the TSN data model, [IEEE8021Qcc] also specifies configuration of 208 TSN features (e.g., traffic scheduling specified by [IEEE8021Qbv]). 209 The common architecture and flow model, allow configured features to 210 be consistent in certain deployment scenarios, e.g., when the network 211 that provides the DetNet service includes both L3 and L2 network 212 segments. 214 1.1. Goals 216 As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates 217 with IEEE 802.1 TSN in order to define a common architecture for both 218 Layer 2 and Layer 3. This is beneficial for several reasons, e.g., 219 in order to simplify implementations and maintain consistency across 220 diverse networks. The flow and service information models are also 221 aligned for those reasons. Therefore, the DetNet flow and service 222 information models described in this document are based on 223 [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. 225 This document specifies flow and service information models only. 227 1.2. Non Goals 229 This document does not specify flow data models or DetNet 230 configuration. Therefore, the goals of this document differ from the 231 goals of [IEEE8021Qcc], which also specifies the TSN data model and 232 configuration of certain TSN features. 234 The DetNet specific YANG data model is described in 235 [I-D.ietf-detnet-yang]. 237 2. Terminology 239 2.1. Terms Used in This Document 241 This document uses the terminology established in the DetNet 242 architecture [RFC8655] and the DetNet Data Plane Framework [RFC8938]. 243 The reader is assumed to be familiar with these documents and any 244 terminology defined therein. The DetNet <=> TSN dictionary of 245 [RFC8655] is used to perform translation from [IEEE8021Qcc] to this 246 document. 248 The following terminology is used in accordance with [RFC8655]: 250 App-flow The payload (data) carried over a DetNet service. 252 DetNet flow A DetNet flow is a sequence of packets which conform 253 uniquely to a flow identifier, and to which the DetNet 254 service is to be provided. It includes any DetNet 255 headers added to support the DetNet service and 256 forwarding sub-layers. 258 The following terminology is introduced in this document: 260 Source Reference point for an App-flow, where the flow starts. 262 Destination Reference point for an App-flow, where the flow 263 terminates. 265 DN Ingress Reference point for the start of a DetNet flow. 266 Networking technology specific encapsulation may be 267 added here to the served App-flow(s). 269 DN Egress Reference point for the termination of a DetNet flow. 270 Networking technology specific encapsulation may be 271 removed here from the served App-flow(s). 273 2.2. Abbreviations 275 The following abbreviations are used in this document: 277 DetNet Deterministic Networking. 279 DN DetNet. 281 MPLS Multiprotocol Label Switching. 283 PSN Packet Switched Network. 285 TSN Time-Sensitive Networking. 287 2.3. Naming Conventions 289 The following naming conventions were used for naming information 290 model components in this document. It is recommended that extensions 291 of the model use the same conventions. 293 o Descriptive names are used. 295 o Names start with uppercase letters. 297 o Composed names use capital letters for the first letter of each 298 component. All other letters are lowercase, even for acronyms. 299 Exceptions are made for acronyms containing a mixture of lowercase 300 and capital letters, such as IPv6. Example composed names are 301 SourceMacAddress and DestinationIPv6Address. 303 3. DetNet Domain and its Modeling 305 3.1. DetNet Service Overview 307 The DetNet service can be defined as a service that provides a 308 capability to carry a unicast or a multicast data flow for an 309 application with constrained requirements on network performance, 310 e.g., low packet loss rate and/or latency. 312 Figure 5 and Figure 8 in [RFC8655] show the DetNet service related 313 reference points and main components. 315 3.2. Reference Points Used in Modeling 317 From service design perspective a fundamental question is the 318 location of the service/flow endpoints, i.e., where the service/flow 319 starts and ends. 321 App-flow specific reference points are the Source (where it starts) 322 and the Destination (where it terminates). Similarly a DetNet flow 323 has reference points termed DN Ingress (where a DetNet flow starts) 324 and DN Egress (where a DetNet flow ends). These reference points may 325 coexist in the same node (e.g., in a DetNet IP end system). DN 326 Ingress and DN Egress reference points are intermediate reference 327 points for a served App-flow. 329 All reference points are assumed in this document to be packet-based 330 reference points. A DN Ingress may add and a DN Egress may remove 331 networking technology specific encapsulation to/from the served App- 332 flow(s) (e.g., MPLS label(s), UDP and IP headers). 334 3.3. Information Elements 336 The DetNet flow information model and the service model relies on 337 three groups of information elements: 339 o App-flow related parameters: these describe the App-flow 340 characteristics (e.g., identification, encapsulation, traffic 341 specification, endpoints, status, etc.) and the App-flow service 342 expectations (e.g., delay, loss, etc.). 344 o DetNet flow related parameters: these describe the DetNet flow 345 characteristics (e.g., identification, format, traffic 346 specification, endpoints, rank, etc.). 348 o DetNet service related parameters: these describe the expected 349 service characteristics (e.g., delivery type, connectivity delay/ 350 loss, status, rank, etc.). 352 In the information model a DetNet flow contains one or more 353 (aggregated) App-flows (N:1 mapping). During DetNet aggregation the 354 aggregated DetNet flows are treated simply as App-flows and the 355 aggregate is the DetNet flow, which provides N:1 mapping. Similarly, 356 there is an aggregated many to one relationship for the DetNet 357 flow(s) to the DetNet Service. 359 4. App-flow Related Parameters 361 When Deterministic service is required by time/loss sensitive 362 application(s) running on an end system during communication with its 363 peer(s), the resulting data exchange has various requirements on 364 delay and/or loss parameters. 366 4.1. App-flow Characteristics 368 App-flow characteristics are described by the following parameters: 370 o FlowID: a unique (management) identifier of the App-flow. It can 371 be used to define the N:1 mapping of App-flows to a DetNet flow. 373 o FlowType: set by the encapsulation format of the flow. It can be 374 Ethernet (TSN), MPLS, or IP. 376 o DataFlowSpecification: a flow descriptor, defining which packets 377 belongs to a flow, using specific packet header fields such as 378 src-addr, dst-addr, label, VLAN-ID, etc. 380 o TrafficSpecification: a flow descriptor, defining traffic 381 parameters such as packet size, transmission time interval, and 382 maximum packets per time interval. 384 o FlowEndpoints: delineate the start and termination reference 385 points of the App-flow by pointing to the source interface/node 386 and destination interface(s)/node(s). 388 o FlowStatus: indicates the status of the App-flow with respect to 389 the establishment of the flow by the connected network, e.g., 390 ready, failed, etc. 392 o FlowRank: indicates the rank of this flow relative to other flows 393 in the connected network. 395 Note: When defining the N:1 mapping of App-flows to a DetNet flow, 396 the App-flows must have the same FlowType and different 397 DataFlowSpecification parameters 399 4.2. App-flow Requirements 401 App-flow requirements are described by the following parameters: 403 o FlowRequirements: defines the attributes of the App-flow regarding 404 bandwidth, latency, latency variation, loss, and misordering 405 tolerance. 407 o FlowBiDir: defines the data path requirement of the App-flow 408 whether it must share the same data path and physical path for 409 both directions through the network, e.g., to provide congruent 410 paths in the two directions. 412 5. DetNet Flow Related Parameters 414 The Data model specified by [IEEE8021Qcc] describes data flows using 415 TSN service as periodic flows with fixed packet size (i.e., Constant 416 Bit Rate (CBR) flows) or with variable packet size. The same concept 417 is applied for flows using DetNet service. 419 Latency and loss parameters are correlated because the effect of late 420 delivery can result in data loss for an application. However, not 421 all applications require hard limits on both latency and loss. For 422 example, some real-time applications allow graceful degradation if 423 loss happens (e.g., sample-based data processing, media 424 distribution). Some other applications may require high-bandwidth 425 connections that make use of packet replication techniques which are 426 economically challenging or even impossible. Some applications may 427 not tolerate loss, but are not delay sensitive (e.g., bufferless 428 sensors). Time or loss sensitive applications may have somewhat 429 special requirements especially for loss (e.g., no loss over two 430 consecutive communication cycles; very low outage time, etc.). 432 DetNet flows have the following attributes: 434 a. DnFlowID (Section 5.1) 435 b. DnPayloadType (Section 5.2) 436 c. DnFlowFormat (Section 5.3) 437 d. DnFlowSpecification (Section 5.4) 438 e. DnTrafficSpecification (Section 5.5) 439 f. DnFlowEndpoints (Section 5.6) 440 g. DnFlowRank (Section 5.7) 441 h. DnFlowStatus (Section 5.8) 443 DetNet flows have the following requirement attributes: 445 o DnFlowRequirements (Section 5.9) 446 o DnFlowBiDir (Section 5.10) 448 Flow attributes are described in the following sections. 450 5.1. Management ID of the DetNet Flow 452 A unique (management) identifier is needed for each DetNet flow 453 within the DetNet domain. It is specified by DnFlowID. It can be 454 used to define the N:1 mapping of DetNet flows to a DetNet service. 456 5.2. Payload type of the DetNet Flow 458 The DnPayloadType attribute is set according to the encapsulated App- 459 flow format. The attribute can be Ethernet, MPLS, or IP. 461 5.3. Format of the DetNet Flow 463 The DnFlowFormat attribute is set according to the DetNet PSN 464 technology. The attribute can be MPLS or IP. 466 5.4. Identification and Specification of DetNet Flows 468 Identification options for DetNet flows at the Ingress/Egress and 469 within the DetNet domain are specified as follows; see Section 5.4.1 470 for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows. 472 5.4.1. DetNet MPLS Flow Identification and Specification 474 The identification of DetNet MPLS flows within the DetNet domain is 475 based on the MPLS context in the service information model. The 476 attributes are specific to the MPLS forwarding paradigm within the 477 DetNet domain [I-D.ietf-detnet-mpls]. DetNet MPLS flows can be 478 identified and specified by the following attributes: 480 a. SLabel 481 b. FLabelStack 483 5.4.2. DetNet IP Flow Identification and Specification 485 DetNet IP flows can be identified and specified by the following 486 attributes [RFC8939]: 488 a. SourceIpAddress 489 b. DestinationIpAddress 490 c. IPv6FlowLabel 491 d. Dscp (attribute) 492 e. Protocol 493 f. SourcePort 494 g. DestinationPort 495 h. IPSecSpi 497 The IP 6-tuple that is used for DetNet IP flow identification 498 consists of items a, b, d, e, f, and g. Items c and h are additional 499 attributes that can be used for DetNet flow identification in 500 addition to the 6-tuple. 6-tuple and use of wild cards for these 501 attributes are specified in [RFC8939]. 503 5.5. Traffic Specification of the DetNet Flow 505 DnTrafficSpecification attributes specify how the DN Ingress 506 transmits packets for the DetNet flow. This is effectively the 507 promise/request of the DN Ingress to the network. The network uses 508 this traffic specification to allocate resources and adjust queue 509 parameters in network nodes. 511 TrafficSpecification has the following attributes: 513 a. Interval: the period of time in which the traffic specification 514 is specified. 516 b. MaxPacketsPerInterval: the maximum number of packets that the 517 Ingress will transmit in one Interval. 519 c. MaxPayloadSize: the maximum payload size that the Ingress will 520 transmit. 522 d. MinPayloadSize: the minimum payload size that the Ingress will 523 transmit. 525 e. MinPacketsPerInterval: the minimum number of packets that the 526 Ingress will transmit in one Interval. 528 These attributes can be used to describe any type of traffic (e.g., 529 CBR, VBR, etc.) and can be used during resource allocation to 530 represent worst case scenarios. Intervals are specified as an 531 integer number of nanoseconds. PayloadSizes are specified in octets. 533 Flows exceeding the traffic specification (i.e., having more traffic 534 than defined by the maximum attributes) may receive a different 535 network behavior than the DetNet network has been engineered for. 536 Excess traffic due to malicious or malfunctioning devices can be 537 prevented or mitigated (e.g., through the use of existing mechanisms 538 such as policing and shaping). 540 When MinPayloadSize and MinPacketsPerInterval parameters are used, 541 then all packets less than the MinPayloadSize will be counted as 542 being of the size MinPayloadSize during packet processing when packet 543 size matters, e.g., when policing; and all flows having less than 544 MinPacketsPerInterval will be counted as having MinPacketsPerInterval 545 when the number of packets per interval matters, e.g., during 546 resource reservation. However, flows having less than 547 MinPacketsPerInterval may result in a different network behavior than 548 the DetNet network has been engineered for. MinPayloadSize and 549 MinPacketsPerInterval parameters, for example, may be used when 550 engineering the latency bounds of a DetNet flow when POF is applied 551 to the given DetNet flow. 553 Further optional attributes can be considered to achieve more 554 efficient resource allocation. Such optional attributes might be 555 worth for flows with soft requirements (i.e., the flow is only loss 556 sensitive or only delay sensitive, but not both delay-and-loss 557 sensitive). Possible options how to extend DnTrafficSpecification 558 attributes is for further discussion. 560 5.6. Endpoints of the DetNet Flow 562 The DnFlowEndpoints attribute defines the starting and termination 563 reference points of the DetNet flow by pointing to the ingress 564 interface/node and egress interface(s)/node(s). Depending on the 565 network scenario it defines an interface or a node. Interface can be 566 defined for example if the App-flow is a TSN Stream and it is 567 received over a well defined UNI (User-to-Network Interface). For 568 example, for App-flows with MPLS encapsulation defining an ingress 569 node is more common when per platform label space is used. 571 5.7. Rank of the DetNet Flow 573 The DnFlowRank attribute provides the rank of this flow relative to 574 other flows in the DetNet domain. Rank (range: 0-255) is used by the 575 DetNet domain to decide which flows can and cannot exist when network 576 resources reach their limit. Rank is used to help to determine which 577 flows can be bumped (i.e., removed from node configuration thereby 578 releasing its resources) if for example a port of a node becomes 579 oversubscribed (e.g., due to network re-configuration). DnFlowRank 580 value 0 is the highest priority. 582 5.8. Status of the DetNet Flow 584 DnFlowStatus provides the status of the DetNet flow with respect to 585 the establishment of the flow by the DetNet domain. 587 The DnFlowStatus includes the following attributes: 589 a. DnIngressStatus is an enumeration for the status of the flow's 590 Ingress reference point: 592 * None: no Ingress. 593 * Ready: Ingress is ready. 594 * Failed: Ingress failed. 595 * OutOfService: Administratively blocked. 597 b. DnEgressStatus is an enumeration for the status of the flow's 598 Egress reference points: 600 * None: no Egress. 601 * Ready: all Egresses are ready. 602 * PartialFailed: One or more Egress ready, and one or more 603 Egress failed. The DetNet flow can be used if the Ingress is 604 Ready. 605 * Failed: All Egresses failed. 606 * OutOfService: All Egresses are administratively blocked. 608 c. FailureCode: A non-zero code that specifies the error if the 609 DetNet flow encounters a failure (e.g., packet replication and 610 elimination is requested but not possible, or DnIngressStatus is 611 Failed, or DnEgressStatus is Failed, or DnEgressStatus is 612 PartialFailed). 614 Defining FailureCodes for DetNet is out-of-scope in this document. 615 Table 46-1 of [IEEE8021Qcc] describes TSN failure codes. 617 5.9. Requirements of the DetNet Flow 619 DnFlowRequirements specifies requirements to ensure the service level 620 desired for the DetNet flow. 622 The DnFlowRequirements includes the following attributes: 624 a. MinBandwidth(Section 5.9.1) 625 b. MaxLatency(Section 5.9.2) 626 c. MaxLatencyVariation(Section 5.9.3) 627 d. MaxLoss(Section 5.9.4) 628 e. MaxConsecutiveLossTolerance(Section 5.9.5) 629 f. MaxMisordering(Section 5.9.6) 631 5.9.1. Minimum Bandwidth of the DetNet Flow 633 MinBandwidth is the minimum bandwidth that has to be guaranteed for 634 the DetNet flow. MinBandwidth is specified in octets per second. 636 5.9.2. Maximum Latency of the DetNet Flow 638 MaxLatency is the maximum latency from Ingress to Egress(es) for a 639 single packet of the DetNet flow. MaxLatency is specified as an 640 integer number of nanoseconds. 642 5.9.3. Maximum Latency Variation of the DetNet Flow 644 MaxLatencyVariation is the difference between the minimum and the 645 maximum end-to-end one-way latency. MaxLatencyVariation is specified 646 as an integer number of nanoseconds. 648 5.9.4. Maximum Loss of the DetNet Flow 650 MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for 651 the DetNet flow between the Ingress and Egress(es) and the loss 652 measurement interval. 654 5.9.5. Maximum Consecutive Loss of the DetNet Flow 656 Some applications have special loss requirement, such as 657 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 658 parameter describes the maximum number of consecutive packets whose 659 loss can be tolerated. The maximum consecutive loss tolerance can be 660 measured for example based on sequence number. 662 5.9.6. Maximum Misordering Tolerance of the DetNet Flow 664 MaxMisordering describes the tolerable maximum number of packets that 665 can be received out of order. The value zero for the maximum allowed 666 misordering indicates that in order delivery is required, misordering 667 cannot be tolerated. 669 The maximum allowed misordering can be measured for example based on 670 sequence numbers. When a packet arrives at the egress after a packet 671 with a higher sequence number, the difference between the sequence 672 number values cannot be bigger than "MaxMisordering + 1". 674 5.10. BiDir requirement of the DetNet Flow 676 DnFlowBiDir attribute defines the requirement that the flow and the 677 corresponding reverse direction flow must share the same path (links 678 and nodes) through the routed or switch network in the DetNet domain, 679 e.g., to provide congruent paths in the two directions that share 680 fate and path characteristics. 682 6. DetNet Service Related Parameters 684 DetNet service have the following attributes: 686 a. DnServiceID (Section 6.1) 687 b. DnServiceDeliveryType (Section 6.2) 688 c. DnServiceDeliveryProfile (Section 6.3) 689 d. DNServiceConnectivity (Section 6.4) 690 e. DnServiceBiDir (Section 6.5) 691 f. DnServiceRank (Section 6.6) 692 g. DnServiceStatus (Section 6.7) 694 Service attributes are described in the following sections. 696 6.1. Management ID of the DetNet service 698 A unique (management) identifier for each DetNet service within the 699 DetNet domain. It can be used to define the many to one mapping of 700 DetNet flows to a DetNet service. 702 6.2. Delivery Type of the DetNet service 704 The DnServiceDeliveryType attribute is set according to the payload 705 of the served DetNet flow (i.e., the encapsulated App-flow format). 706 The attribute can be Ethernet, MPLS, or IP. 708 6.3. Delivery Profile of the DetNet Service 710 DnServiceDeliveryProfile specifies delivery profile to ensure proper 711 serving of the DetNet flow. 713 The DnServiceDeliveryProfile includes the following attributes: 715 a. MinBandwidth(Section 6.3.1) 716 b. MaxLatency(Section 6.3.2) 717 c. MaxLatencyVariation(Section 6.3.3) 718 d. MaxLoss(Section 6.3.4) 719 e. MaxConsecutiveLossTolerance(Section 6.3.5) 720 f. MaxMisordering(Section 6.3.6) 722 6.3.1. Minimum Bandwidth of the DetNet Service 724 MinBandwidth is the minimum bandwidth that has to be guaranteed for 725 the DetNet service. MinBandwidth is specified in octets per second 726 and excludes additional DetNet header (if any). 728 6.3.2. Maximum Latency of the DetNet Service 730 MaxLatency is the maximum latency from Ingress to Egress(es) for a 731 single packet of the DetNet flow. MaxLatency is specified as an 732 integer number of nanoseconds. 734 6.3.3. Maximum Latency Variation of the DetNet Service 736 MaxLatencyVariation is the difference between the minimum and the 737 maximum end-to-end one-way latency. MaxLatencyVariation is specified 738 as an integer number of nanoseconds. 740 6.3.4. Maximum Loss of the DetNet Service 742 MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the 743 DetNet service between the Ingress and Egress(es) of the DetNet 744 domain. 746 6.3.5. Maximum Consecutive Loss of the DetNet Service 748 Some applications have special loss requirement, such as 749 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 750 parameter describes the maximum number of consecutive packets whose 751 loss can be tolerated. The maximum consecutive loss tolerance can be 752 measured for example based on sequence number. 754 6.3.6. Maximum Misordering Tolerance of the DetNet Service 756 MaxMisordering describes the tolerable maximum number of packets that 757 can be received out of order. The maximum allowed misordering can be 758 measured for example based on sequence number. The value zero for 759 the maximum allowed misordering indicates that in order delivery is 760 required, misordering cannot be tolerated. 762 6.4. Connectivity Type of the DetNet Service 764 Two connectivity types are distinguished: point-to-point (p2p) and 765 point-to-multipoint (p2mp). Connectivity type p2mp may be created by 766 a forwarding function (e.g., p2mp LSP). (Note: from service 767 perspective mp2mp connectivity can be treated as a superposition of 768 p2mp connections.) 770 6.5. BiDir requirement of the DetNet Service 772 The DnServiceBiDir attribute defines the requirement that the flow 773 and the corresponding reverse direction flow must share the same path 774 (links and nodes) through the routed or switch network in the DetNet 775 domain, e.g., to provide congruent paths in the two directions that 776 share fate and path characteristics. 778 6.6. Rank of the DetNet Service 780 The DnServiceRank attribute provides the rank of a service instance 781 relative to other services in the DetNet domain. DnServiceRank 782 (range: 0-255) is used by the network in case of network resource 783 limitation scenarios. DnServiceRank value 0 is the highest priority. 785 6.7. Status of the DetNet Service 787 DnServiceStatus information group includes elements that specify the 788 status of the service specific state of the DetNet domain. This 789 information group informs the user whether or not the service is 790 ready for use. 792 The DnServiceStatus includes the following attributes: 794 a. DnServiceIngressStatus is an enumeration for the status of the 795 service's Ingress: 797 * None: no Ingress. 798 * Ready: Ingress is ready. 799 * Failed: Ingress failed. 800 * OutOfService: Administratively blocked. 802 b. DnServiceEgressStatus is an enumeration for the status of the 803 service's Egress: 805 * None: no Egress. 806 * Ready: all Egresses are ready. 807 * PartialFailed: One or more Egress ready, and one or more 808 Egress failed. The DetNet flow can be used if the Ingress is 809 Ready. 810 * Failed: All Egresses failed. 811 * OutOfService: Administratively blocked. 813 c. DnServiceFailureCode: A non-zero code that specifies the error if 814 the DetNet service encounters a failure (e.g., packet replication 815 and elimination is requested but not possible, or 816 DnServiceIngressStatus is Failed, or DnServiceEgressStatus is 817 Failed, or DnServiceEgressStatus is PartialFailed). 819 Defining DnServiceFailureCodes for DetNet service is out-of-scope in 820 this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure 821 codes. 823 7. Flow Specific Operations 825 The DetNet flow information model relies on three high level 826 information groups: 828 o DnIngress: The DnIngress information group includes elements that 829 specify the source for a single DetNet flow. This information 830 group is applied from the user of the DetNet service to the 831 network. 833 o DnEgress: The DnEgress information group includes elements that 834 specify the destination for a single DetNet flow. This 835 information group is applied from the user of the DetNet service 836 to the network. 838 o DnFlowStatus: The status information group includes elements that 839 specify the status of the flow in the network. This information 840 group is applied from the network to the user of the DetNet 841 service. This information group informs the user whether or not 842 the DetNet flow is ready for use. 844 There are three possible operations for each DetNet flow with respect 845 to its DetNet service at a DN Ingress or a DN Egress (similarly to 846 App-flows at a Source or a Destination): 848 o Join: DN Ingress/DN Egress intends to join the flow. 849 o Leave: DN Ingress/DN Egress intends to leave the flow. 851 o Modify: DN Ingress/DN Egress intends to change the flow. 853 7.1. Join Operation 855 For the join operation, the DnFlowSpecification, DnFlowRank, 856 DnFlowEndpoint, and DnTrafficSpecification are included within the 857 DnIngress or DnEgress information group. For the join operation, the 858 DnServiceRequirements groups can be included. 860 7.2. Leave Operation 862 For the leave operation, the DnFlowSpecification and DnFlowEndpoint 863 are included within the DnIngress or DnEgress information group. 865 7.3. Modify Operation 867 For the modify operation, the DnFlowSpecification, DnFlowRank, 868 DnFlowEndpoint, and DnTrafficSpecification are included within the 869 DnIngress or DnEgress information group. For the join operation, the 870 DnServiceRequirements groups can be included. 872 The Modify operation can be considered to address cases when a flow 873 is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been 874 changed. The advantage of having a Modify is that it allows 875 initiation of a change of flow spec while leaving the current flow is 876 operating until the change is accepted. If there is no linkage 877 between the Join and the Leave, then while figuring out whether the 878 new flow spec can be supported, the controller entity has to assume 879 that the resources committed to the current flow are in use. By 880 using Modify the controller entity knows that the resources 881 supporting the current flow can be available for supporting the 882 altered flow. Modify is considered to be an optional operation due 883 to possible controller plane limitations. 885 8. Summary 887 This document describes the DetNet flow information model and the 888 service information model for DetNet IP networks and DetNet MPLS 889 networks. These models are used as input for creating the DetNet 890 specific YANG model. 892 9. IANA Considerations 894 N/A. 896 10. Security Considerations 898 The external interfaces of the DetNet domain need to be subject to 899 appropriate confidentiality. Additionally, knowledge of which flows/ 900 services are provided to a customer or delivered by a network 901 operator may supply information that can be used in a variety of 902 security attacks. Security considerations for DetNet are described 903 in detail in [I-D.ietf-detnet-security]. General security 904 considerations are described in [RFC8655]. This document discusses 905 modeling the information, not how it is exchanged. 907 11. References 909 11.1. Normative References 911 [I-D.ietf-detnet-mpls] 912 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 913 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 914 detnet-mpls-13 (work in progress), October 2020. 916 [IEEE8021Qcc] 917 IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE 918 Standard for Local and metropolitan area networks - 919 Bridges and Bridged Networks -- Amendment 31: Stream 920 Reservation Protocol (SRP) Enhancements and Performance 921 Improvements", 2018, 922 . 924 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 925 "Deterministic Networking Architecture", RFC 8655, 926 DOI 10.17487/RFC8655, October 2019, 927 . 929 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 930 Bryant, "Deterministic Networking (DetNet) Data Plane: 931 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 932 . 934 11.2. Informative References 936 [I-D.ietf-detnet-security] 937 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 938 Networking (DetNet) Security Considerations", draft-ietf- 939 detnet-security-13 (work in progress), December 2020. 941 [I-D.ietf-detnet-yang] 942 Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and 943 Z. Li, "Deterministic Networking (DetNet) Configuration 944 YANG Model", draft-ietf-detnet-yang-09 (work in progress), 945 November 2020. 947 [IEEE8021Q] 948 IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE 949 Standard for Local and metropolitan area networks - 950 Bridges and Bridged Networks", 2018, 951 . 953 [IEEE8021Qbv] 954 IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE 955 Standard for Local and metropolitan area networks - 956 Bridges and Bridged Networks - Amendment 25: Enhancements 957 for Scheduled Traffic", 2015, 958 . 960 [IETFDetNet] 961 IETF, "IETF Deterministic Networking (DetNet) Working 962 Group", . 964 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 965 Information Models and Data Models", RFC 3444, 966 DOI 10.17487/RFC3444, January 2003, 967 . 969 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 970 Bryant, "Deterministic Networking (DetNet) Data Plane 971 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 972 . 974 Authors' Addresses 976 Balazs Varga 977 Ericsson 978 Magyar tudosok korutja 11 979 Budapest 1117 980 Hungary 982 Email: balazs.a.varga@ericsson.com 983 Janos Farkas 984 Ericsson 985 Magyar tudosok korutja 11 986 Budapest 1117 987 Hungary 989 Email: janos.farkas@ericsson.com 991 Rodney Cummings 992 National Instruments 993 11500 N. Mopac Expwy 994 Bldg. C 995 Austin, TX 78759-3504 996 USA 998 Email: rodney.cummings@ni.com 1000 Yuanlong Jiang 1001 Huawei Technologies Co., Ltd. 1002 Bantian, Longgang district 1004 Shenzhen 518129 1005 China 1007 Email: jiangyuanlong@huawei.com 1009 Don Fedyk 1010 LabN Consulting, L.L.C. 1012 Email: dfedyk@labn.net