idnits 2.17.1 draft-ietf-detnet-flow-information-model-10.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 15, 2020) is 1413 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-06 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-06 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-09 Summary: 0 errors (**), 0 flaws (~~), 4 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: November 16, 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 15, 2020 13 DetNet Flow Information Model 14 draft-ietf-detnet-flow-information-model-10 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 16, 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. 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 . . 10 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 . . . . . . . . . . . . . . . . . 12 80 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 12 81 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13 82 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 13 83 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 13 84 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 13 85 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 13 86 5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14 87 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14 88 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14 89 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 14 90 6.1. Management ID of the DetNet service . . . . . . . . . . . 14 91 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15 92 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15 93 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 15 94 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 15 95 6.3.3. Maximum Latency Variation of the DetNet Service . . . 15 96 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 15 97 6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 15 98 6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16 99 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16 100 6.5. BiDir requirement of the DetNet Service . . . . . . . . . 16 101 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 16 102 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 16 103 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 17 104 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18 105 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 18 106 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 18 107 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 109 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 112 11.2. Informative References . . . . . . . . . . . . . . . . . 19 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 Service Information Model. 124 For reference [RFC3444] describes the rational behind Information 125 Models in general. This document describes the Flow and Service 126 information models for operators and users to understand Detnet 127 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 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 origination of the DetNet flow information model was 210 the flow identification possibilities described in Section 6. of 211 [IEEE8021CB], which is used by [IEEE8021Qcc] as well. In addition to 212 the TSN data model, [IEEE8021Qcc] also specifies configuration of TSN 213 features (e.g., traffic scheduling specified by [IEEE8021Qbv]). The 214 common architecture and flow model, allow configured features to be 215 consistent in certain deployment scenarios, e.g., when the network 216 that provides the DetNet service includes both L3 and L2 network 217 segments. 219 1.1. Goals 221 As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates 222 with IEEE 802.1 TSN in order to define a common architecture for both 223 Layer 2 and Layer 3. This is beneficial for several reasons, e.g., 224 in order to simplify implementations and maintain consistency across 225 diverse networks. The flow and service information models are also 226 aligned for those reasons. Therefore, the DetNet flow and service 227 information models described in this document are based on 228 [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. 230 This document specifies flow and service information models only. 232 1.2. Non Goals 234 This document does not specify flow data models or DetNet 235 configuration. Therefore, the goals of this document differ from the 236 goals of [IEEE8021Qcc], which also specifies the TSN data model and 237 configuration of certain TSN features. 239 2. Terminology 241 2.1. Terms Used in This Document 243 This document uses the terminology established in the DetNet 244 architecture [RFC8655] and the DetNet Data Plane Framework 245 [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be 246 familiar with these documents and any terminology defined therein. 247 The DetNet <=> TSN dictionary of [RFC8655] is used to perform 248 translation from [IEEE8021Qcc] to this document. 250 The following terminology is used in accordance with [RFC8655]: 252 App-flow The payload (data) carried over a DetNet service. 254 DetNet flow A DetNet flow is a sequence of packets which conform 255 uniquely to a flow identifier, and to which the DetNet 256 service is to be provided. It includes any DetNet 257 headers added to support the DetNet service and 258 forwarding sub-layers. 260 The following terminology is introduced in this document: 262 Source Reference point for an App-flow, where the flow starts. 264 Destination Reference point for an App-flow, where the flow 265 terminates. 267 DN Ingress Reference point for the start of a DetNet flow. 268 Networking technology specific encapsulation may be 269 added here to the served App-flow(s). 271 DN Egress Reference point for the termination of a DetNet flow. 272 Networking technology specific encapsulation may be 273 removed here from the served App-flow(s). 275 2.2. Abbreviations 277 The following abbreviations are used in this document: 279 DetNet Deterministic Networking. 281 DN DetNet. 283 MPLS Multiprotocol Label Switching. 285 PSN Packet Switched Network. 287 TSN Time-Sensitive Networking. 289 2.3. Naming Conventions 291 The following naming conventions were used for naming information 292 model components in this document. It is recommended that extensions 293 of the model use the same conventions. 295 o Descriptive names are used. 297 o Names start with uppercase letters. 299 o Composed names use capital letters for the first letter of each 300 component. All other letters are lowercase, even for acronyms. 301 Exceptions are made for acronyms containing a mixture of lowercase 302 and capital letters, such as IPv6. Example composed names are 303 SourceMacAddress and DestinationIPv6Address. 305 3. DetNet Domain and its Modeling 307 3.1. DetNet Service Overview 309 The DetNet service can be defined as a service that provides a 310 capability to carry a unicast or a multicast data flow for an 311 application with constrained requirements on network performance, 312 e.g., low packet loss rate and/or latency. 314 Figure 5 and Figure 8 in [RFC8655] show the DetNet service related 315 reference points and main components. 317 3.2. Reference Points Used in Modeling 319 From service design perspective a fundamental question is the 320 location of the service/flow endpoints, i.e., where the service/flow 321 starts and ends. 323 App-flow specific reference points are the Source (where it starts) 324 and the Destination (where it terminates). Similarly a DetNet flow 325 has reference points termed DN Ingress (where a DetNet flow starts) 326 and DN Egress (where a DetNet flow ends). These reference points may 327 coexist in the same node (e.g., in a DetNet IP end system). DN 328 Ingress and DN Egress reference points are intermediate reference 329 points for a served App-flow. 331 All reference points are assumed in this document to be packet-based 332 reference points. A DN Ingress may add and a DN Egress may remove 333 networking technology specific encapsulation to/from the served App- 334 flow(s) (e.g., MPLS label(s), UDP and IP headers). 336 3.3. Information Elements 338 The DetNet flow information model and the service model relies on 339 three groups of information elements: 341 o App-flow related parameters: these describe the App-flow 342 characteristics (e.g., identification, encapsulation, traffic 343 specification, endpoints, status, etc.) and the App-flow service 344 expectations (e.g., delay, loss, etc.). 346 o DetNet flow related parameters: these describe the DetNet flow 347 characteristics (e.g., identification, format, traffic 348 specification, endpoints, rank, etc.). 350 o DetNet service related parameters: these describe the expected 351 service characteristics (e.g., delivery type, connectivity delay/ 352 loss, status, rank, etc.). 354 In the information model a DetNet flow contains one or more 355 (aggregated) App-flows (N:1 mapping). During DetNet aggregation the 356 aggregated DetNet flows are treated simply as App-flows and the 357 aggregate is the DetNet flow, which provides N:1 mapping. Similarly, 358 there is an aggregated many to one relationship for the DetNet 359 flow(s) to the DetNet Service. 361 4. App-flow Related Parameters 363 When Deterministic service is required by time/loss sensitive 364 application(s) running on an end system during communication with its 365 peer(s), the resulting data exchange has various requirements on 366 delay and/or loss parameters. 368 4.1. App-flow Characteristics 370 App-flow characteristics are described by the following parameters: 372 o FlowID: a unique (management) identifier of the App-flow. It can 373 be used to define the N:1 mapping of App-flows to a DetNet flow. 375 o FlowType: set by the encapsulation format of the flow. It can be 376 Ethernet (TSN), MPLS, or IP. 378 o DataFlowSpecification: a flow descriptor, defining which packets 379 belongs to a flow using, specific packet header fields such as 380 src-addr, dst-addr, label, VLAN-ID, etc. 382 o TrafficSpecification: a flow descriptor, defining traffic 383 parameters such as packet size, transmission time interval, and 384 maximum packets per time interval. 386 o FlowEndpoints: delineate the start and termination reference 387 points of the App-flow by pointing to the source interface/node 388 and destination interface(s)/node(s). 390 o FlowStatus: indicates the status of the App-flow with respect to 391 the establishment of the flow by the connected network, e.g., 392 ready, failed, etc. 394 o FlowRank: indicates the rank of this flow relative to other flows 395 in the connected network. 397 4.2. App-flow Requirements 399 App-flow requirements are described by the following parameters: 401 o FlowRequirements: defines the attributes of the App-flow regarding 402 bandwidth, latency, latency variation, loss, and misordering 403 tolerance. 405 o FlowBiDir: defines the data path requirement of the App-flow 406 whether it must share the same data path and physical path for 407 both directions through the network, e.g., to provide congruent 408 paths in the two directions. 410 5. DetNet Flow Related Parameters 412 The Data model specified by [IEEE8021Qcc] describes data flows using 413 TSN service as periodic flows with fix packet size (i.e., Constant 414 Bit Rate (CBR) flows) or with variable packet size. The same concept 415 is applied for flows using DetNet service. 417 Latency and loss parameters are correlated because the effect of late 418 delivery can result data loss for an application. However, not all 419 applications require hard limits on both latency and loss. For 420 example, some real-time applications allow graceful degradation if 421 loss happens (e.g., sample-based data processing, media 422 distribution). Some other applications may require high-bandwidth 423 connections that make use of packet replication techniques which are 424 economically challenging or even impossible. Some applications may 425 not tolerate loss, but are not delay sensitive (e.g., bufferless 426 sensors). Time or loss sensitive applications may have somewhat 427 special requirements especially for loss (e.g., no loss over two 428 consecutive communication cycles; very low outage time, etc.). 430 DetNet flows have the following attributes: 432 a. DnFlowID (Section 5.1) 433 b. DnPayloadType (Section 5.2) 434 c. DnFlowFormat (Section 5.3) 435 d. DnFlowSpecification (Section 5.4) 436 e. DnTrafficSpecification (Section 5.5) 437 f. DnFlowEndpoints (Section 5.6) 438 g. DnFlowRank (Section 5.7) 439 h. DnFlowStatus (Section 5.8) 441 DetNet flows have the following requirement attributes: 443 o DnFlowRequirements (Section 5.9) 444 o DnFlowBiDir (Section 5.10) 446 Flow attributes are described in the following sections. 448 5.1. Management ID of the DetNet Flow 450 A unique (management) identifier is needed for each DetNet flow 451 within the DetNet domain. It is specified by DnFlowID. It can be 452 used to define the many to one mapping of DetNet flows to a DetNet 453 service. 455 5.2. Payload type of the DetNet Flow 457 The DnPayloadType attribute is set according to the encapsulated App- 458 flow format. The attribute can be Ethernet, MPLS, or IP. 460 5.3. Format of the DetNet Flow 462 The DnFlowFormat attribute is set according to the DetNet PSN 463 technology. The attribute can be MPLS or IP. 465 5.4. Identification and Specification of DetNet Flows 467 Identification options for DetNet flows at the Ingress/Egress and 468 within the DetNet domain are specified as follows; see Section 5.4.1 469 for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows. 471 5.4.1. DetNet MPLS Flow Identification and Specification 473 The identification of DetNet MPLS flows within the DetNet domain is 474 based on the MPLS context in the service information model. The 475 attributes are specific to the MPLS forwarding paradigm within the 476 DetNet domain [I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be 477 identified and specified by the following attributes: 479 a. SLabel 480 b. FLabelStack 482 5.4.2. DetNet IP Flow Identification and Specification 484 DetNet IP flows can be identified and specified by the following 485 attributes [I-D.ietf-detnet-ip]: 487 a. SourceIpAddress 488 b. DestinationIpAddress 489 c. IPv6FlowLabel 490 d. Dscp (attribute) 491 e. Protocol 492 f. SourcePort 493 g. DestinationPort 494 h. IPSecSpi 496 The IP 6-tuple that is used for DetNet IP flow identification 497 consists of items a, b, d, e, f, and g. Items c and h are additional 498 attributes that can be used for DetNet flow identification in 499 addition to the 6-tuple. 501 5.5. Traffic Specification of the DetNet Flow 503 DnTrafficSpecification attributes specify how the DN Ingress 504 transmits packets for the DetNet flow. This is effectively the 505 promise/request of the DN Ingress to the network. The network uses 506 this traffic specification to allocate resources and adjust queue 507 parameters in network nodes. 509 TrafficSpecification has the following attributes: 511 a. Interval: the period of time in which the traffic specification 512 is specified. 514 b. MaxPacketsPerInterval: the maximum number of packets that the 515 Ingress will transmit in one Interval. 517 c. MaxPayloadSize: the maximum payload size that the Ingress will 518 transmit. 520 These attributes can be used to describe any type of traffic (e.g., 521 CBR, VBR, etc.) and can be used during resource allocation to 522 represent worst case scenarios. 524 Further optional attributes can be considered to achieve more 525 efficient resource allocation. Such optional attributes might be 526 worth for flows with soft requirements (i.e., the flow is only loss 527 sensitive or only delay sensitive, but not both delay-and-loss 528 sensitive). Possible options how to extend DnTrafficSpecification 529 attributes is for further discussion. 531 5.6. Endpoints of the DetNet Flow 533 The DnFlowEndpoints attribute defines the starting and termination 534 reference points of the DetNet flow by pointing to the ingress 535 interface/node and egress interface(s)/node(s). Depending on the 536 network scenario it defines an interface or a node. Interface can be 537 defined for example if the App-flow is a TSN Stream and it is 538 received over a well defined UNI interface. For example, for App- 539 flows with MPLS encapsulation defining an ingress node is more common 540 when per platform label space is used. 542 5.7. Rank of the DetNet Flow 544 The DnFlowRank attribute provides the rank of this flow relative to 545 other flows in the DetNet domain. Rank (range: 0-255) is used by the 546 DetNet domain to decide which flows can and cannot exist when network 547 resources reach their limit. Rank is used to help to determine which 548 flows can be bumped (i.e., removed from node configuration thereby 549 releasing its resources) if for example a port of a node becomes 550 oversubscribed (e.g., due to network re-configuration). 552 5.8. Status of the DetNet Flow 554 DnFlowStatus provides the status of the DetNet flow with respect to 555 the establishment of the flow by the DetNet domain. 557 The DnFlowStatus includes the following attributes: 559 a. DnIngressStatus is an enumeration for the status of the flow's 560 Ingress reference point: 562 * None: no Ingress. 563 * Ready: Ingress is ready. 564 * Failed: Ingress failed. 565 * OutOfService: Administratively blocked. 567 b. DnEgressStatus is an enumeration for the status of the flow's 568 Egress reference points: 570 * None: no Egress. 571 * Ready: all Egresses are ready. 572 * PartialFailed: One or more Egress ready, and one or more 573 Egress failed. The DetNet flow can be used if the Ingress is 574 Ready. 576 * Failed: All Egresses failed. 577 * OutOfService: Administratively blocked. 579 c. FailureCode: A non-zero code that specifies the error if the 580 DetNet flow encounters a failure (e.g., packet replication and 581 elimination is requested but not possible, or DnIngressStatus is 582 Failed, or DnEgressStatus is Failed, or DnEgressStatus is 583 PartialFailed). 585 Defining FailureCodes for DetNet is out-of-scope in this document. 586 Table 46-1 of [IEEE8021Qcc] describes TSN failure codes. 588 5.9. Requirements of the DetNet Flow 590 DnFlowRequirements specifies requirements to ensure the service level 591 desired for the DetNet flow. 593 The DnFlowRequirements includes the following attributes: 595 a. MinBandwidth(Section 5.9.1) 596 b. MaxLatency(Section 5.9.2) 597 c. MaxLatencyVariation(Section 5.9.3) 598 d. MaxLoss(Section 5.9.4) 599 e. MaxConsecutiveLossTolerance(Section 5.9.5) 600 f. MaxMisordering(Section 5.9.6) 602 5.9.1. Minimum Bandwidth of the DetNet Flow 604 MinBandwidth is the minimum bandwidth that has to be guaranteed for 605 the DetNet flow. MinBandwidth is specified in octets per second. 607 5.9.2. Maximum Latency of the DetNet Flow 609 MaxLatency is the maximum latency from Ingress to Egress(es) for a 610 single packet of the DetNet flow. MaxLatency is specified as an 611 integer number of nanoseconds. 613 5.9.3. Maximum Latency Variation of the DetNet Flow 615 MaxLatencyVariation is the difference between the minimum and the 616 maximum end-to-end one-way latency. MaxLatencyVariation is specified 617 as an integer number of nanoseconds. 619 5.9.4. Maximum Loss of the DetNet Flow 621 MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for 622 the DetNet flow between the Ingress and Egress(es). 624 5.9.5. Maximum Consecutive Loss of the DetNet Flow 626 Some applications have special loss requirement, such as 627 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 628 parameter describes the maximum number of consecutive packets whose 629 loss can be tolerated. The maximum consecutive loss tolerance can be 630 measured for example based on sequence number. 632 5.9.6. Maximum Misordering Tolerance of the DetNet Flow 634 MaxMisordering describes the tolerable maximum number of packets that 635 can be received out of order. The maximum allowed misordering can be 636 measured for example based on sequence number. The value zero for 637 the maximum allowed misordering indicates that in order delivery is 638 required, misordering cannot be tolerated. 640 5.10. BiDir requirement of the DetNet Flow 642 DnFlowBiDir attribute defines the requirement that the flow and the 643 corresponding reverse direction flow must share the same path (links 644 and nodes) through the routed or switch network in the DetNet domain, 645 e.g., to provide congruent paths in the two directions that share 646 fate and path characteristics. 648 6. DetNet Service Related Parameters 650 DetNet service have the following attributes: 652 a. DnServiceID (Section 6.1) 653 b. DnServiceDeliveryType (Section 6.2) 654 c. DnServiceDeliveryProfile (Section 6.3) 655 d. DNServiceConnectivity (Section 6.4) 656 e. DnServiceBiDir (Section 6.5) 657 f. DnServiceRank (Section 6.6) 658 g. DnServiceStatus (Section 6.7) 660 Service attributes are described in the following sections. 662 6.1. Management ID of the DetNet service 664 A unique (management) identifier for each DetNet service within the 665 DetNet domain. It can be used to define the many to one mapping of 666 DetNet flows to a DetNet service. 668 6.2. Delivery Type of the DetNet service 670 The DnServiceDeliveryType attribute is set according to the payload 671 of the served DetNet flow (i.e., the encapsulated App-flow format). 672 The attribute can be Ethernet, MPLS, or IP. 674 6.3. Delivery Profile of the DetNet Service 676 DnServiceDeliveryProfile specifies delivery profile to ensure proper 677 serving of the DetNet flow. 679 The DnServiceDeliveryProfile includes the following attributes: 681 a. MinBandwidth(Section 6.3.1) 682 b. MaxLatency(Section 6.3.2) 683 c. MaxLatencyVariation(Section 6.3.3) 684 d. MaxLoss(Section 6.3.4) 685 e. MaxConsecutiveLossTolerance(Section 6.3.5) 686 f. MaxMisordering(Section 6.3.6) 688 6.3.1. Minimum Bandwidth of the DetNet Service 690 MinBandwidth is the minimum bandwidth that has to be guaranteed for 691 the DetNet service. MinBandwidth is specified in octets per second. 693 6.3.2. Maximum Latency of the DetNet Service 695 MaxLatency is the maximum latency from Ingress to Egress(es) for a 696 single packet of the DetNet flow. MaxLatency is specified as an 697 integer number of nanoseconds. 699 6.3.3. Maximum Latency Variation of the DetNet Service 701 MaxLatencyVariation is the difference between the minimum and the 702 maximum end-to-end one-way latency. MaxLatencyVariation is specified 703 as an integer number of nanoseconds. 705 6.3.4. Maximum Loss of the DetNet Service 707 MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the 708 DetNet service between the Ingress and Egress(es) of the DetNet 709 domain. 711 6.3.5. Maximum Consecutive Loss of the DetNet Service 713 Some applications have special loss requirement, such as 714 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 715 parameter describes the maximum number of consecutive packets whose 716 loss can be tolerated. The maximum consecutive loss tolerance can be 717 measured for example based on sequence number. 719 6.3.6. Maximum Misordering Tolerance of the DetNet Service 721 MaxMisordering describes the tolerable maximum number of packets that 722 can be received out of order. The maximum allowed misordering can be 723 measured for example based on sequence number. The value zero for 724 the maximum allowed misordering indicates that in order delivery is 725 required, misordering cannot be tolerated. 727 6.4. Connectivity Type of the DetNet Service 729 Two connectivity types are distinguished: point-to-point (p2p) and 730 point-to-multipoint (p2mp). Connectivity type p2mp is created by a 731 transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity 732 is a superposition of p2mp connections.) 734 6.5. BiDir requirement of the DetNet Service 736 The DnServiceBiDir attribute defines the requirement that the flow 737 and the corresponding reverse direction flow must share the same path 738 (links and nodes) through the routed or switch network in the DetNet 739 domain, e.g., to provide congruent paths in the two directions that 740 share fate and path characteristics. 742 6.6. Rank of the DetNet Service 744 The DnServiceRank attribute provides the rank of a service instance 745 relative to other services in the DetNet domain. DnServiceRank 746 (range: 0-255) is used by the network in case of network resource 747 limitation scenarios. 749 6.7. Status of the DetNet Service 751 DnServiceStatus information group includes elements that specify the 752 status of the service specific state of the DetNet domain. This 753 information group informs the user whether or not the service is 754 ready for use. 756 The DnServiceStatus includes the following attributes: 758 a. DnServiceIngressStatus is an enumeration for the status of the 759 service's Ingress: 761 * None: no Ingress. 762 * Ready: Ingress is ready. 763 * Failed: Ingress failed. 765 * OutOfService: Administratively blocked. 767 b. DnServiceEgressStatus is an enumeration for the status of the 768 service's Egress: 770 * None: no Egress. 771 * Ready: all Egresses are ready. 772 * PartialFailed: One or more Egress ready, and one or more 773 Egress failed. The DetNet flow can be used if the Ingress is 774 Ready. 775 * Failed: All Egresses failed. 776 * OutOfService: Administratively blocked. 778 c. DnServiceFailureCode: A non-zero code that specifies the error if 779 the DetNet service encounters a failure (e.g., packet replication 780 and elimination is requested but not possible, or 781 DnServiceIngressStatus is Failed, or DnServiceEgressStatus is 782 Failed, or DnServiceEgressStatus is PartialFailed). 784 Defining DnServiceFailureCodes for DetNet service is out-of-scope in 785 this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure 786 codes. 788 7. Flow Specific Operations 790 The DetNet flow information model relies on three high level 791 information groups: 793 o DnIngress: The DnIngress information group includes elements that 794 specify the source for a single DetNet flow. This information 795 group is applied from the user of the DetNet service to the 796 network. 798 o DnEgress: The DnEgress information group includes elements that 799 specify the destination for a single DetNet flow. This 800 information group is applied from the user of the DetNet service 801 to the network. 803 o DnFlowStatus: The status information group includes elements that 804 specify the status of the flow in the network. This information 805 group is applied from the network to the user of the DetNet 806 service. This information group informs the user whether or not 807 the DetNet flow is ready for use. 809 There are three possible operations for each DetNet flow with respect 810 to its DetNet service at a DN Ingress or a DN Egress (similarly to 811 App-flows at a Source or a Destination): 813 o Join: DN Ingress/DN Egress intends to join the flow. 814 o Leave: DN Ingress/DN Egress intends to leave the flow. 815 o Modify: DN Ingress/DN Egress intends to change the flow. 817 7.1. Join Operation 819 For the join operation, the DnFlowSpecification, DnFlowRank, 820 DnFlowEndpoint, and DnTrafficSpecification are included within the 821 DnIngress or DnEgress information group. For the join operation, the 822 DnServiceRequirements groups can be included. 824 7.2. Leave Operation 826 For the leave operation, the DnFlowSpecification and DnFlowEndpoint 827 are included within the DnIngress or DnEgress information group. 829 7.3. Modify Operation 831 For the modify operation, the DnFlowSpecification, DnFlowRank, 832 DnFlowEndpoint, and DnTrafficSpecification are included within the 833 DnIngress or DnEgress information group. For the join operation, the 834 DnServiceRequirements groups can be included. 836 The Modify operation can be considered to address cases when a flow 837 is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been 838 changed. The advantage of having a Modify is that it allows 839 initiation of a change of flow spec while leaving the current flow is 840 operating until the change is accepted. If there is no linkage 841 between the Join and the Leave, then while figuring out whether the 842 new flow spec can be supported, the controller entity has to assume 843 that the resources committed to the current flow are in use. By 844 using Modify the controller entity knows that the resources 845 supporting the current flow can be available for supporting the 846 altered flow. Modify is considered to be an optional operation due 847 to possible controller plane limitations. 849 8. Summary 851 This document describes the DetNet flow information model and the 852 service information model for DetNet IP networks and DetNet MPLS 853 networks. These models are used as input for the YANG model. 855 9. IANA Considerations 857 N/A. 859 10. Security Considerations 861 The external interfaces of the DetNet domain need to be subject to 862 appropriate confidentiality. Additionally, knowledge of which flows/ 863 services are provided to a customer or delivered by a network 864 operator may supply information that can be used in a variety of 865 security attacks. Security considerations for DetNet are described 866 in detail in [I-D.ietf-detnet-security]. General security 867 considerations are described in [RFC8655]. This document discusses 868 modeling the information, not how it is exchanged. 870 11. References 872 11.1. Normative References 874 [I-D.ietf-detnet-ip] 875 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 876 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06 877 (work in progress), April 2020. 879 [I-D.ietf-detnet-mpls] 880 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 881 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 882 detnet-mpls-06 (work in progress), April 2020. 884 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 885 "Deterministic Networking Architecture", RFC 8655, 886 DOI 10.17487/RFC8655, October 2019, 887 . 889 11.2. Informative References 891 [I-D.ietf-detnet-data-plane-framework] 892 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 893 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 894 data-plane-framework-06 (work in progress), May 2020. 896 [I-D.ietf-detnet-security] 897 Mizrahi, T. and E. Grossman, "Deterministic Networking 898 (DetNet) Security Considerations", draft-ietf-detnet- 899 security-09 (work in progress), March 2020. 901 [IEEE8021CB] 902 IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE 903 Standard for Local and metropolitan area networks - Frame 904 Replication and Elimination for Reliability", 2017, 905 . 907 [IEEE8021Q] 908 IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE 909 Standard for Local and metropolitan area networks - 910 Bridges and Bridged Networks", 2018, 911 . 913 [IEEE8021Qbv] 914 IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE 915 Standard for Local and metropolitan area networks - 916 Bridges and Bridged Networks - Amendment 25: Enhancements 917 for Scheduled Traffic", 2015, 918 . 920 [IEEE8021Qcc] 921 IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE 922 Standard for Local and metropolitan area networks - 923 Bridges and Bridged Networks -- Amendment 31: Stream 924 Reservation Protocol (SRP) Enhancements and Performance 925 Improvements", 2018, 926 . 928 [IETFDetNet] 929 IETF, "IETF Deterministic Networking (DetNet) Working 930 Group", . 932 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 933 Information Models and Data Models", RFC 3444, 934 DOI 10.17487/RFC3444, January 2003, 935 . 937 Authors' Addresses 939 Balazs Varga 940 Ericsson 941 Magyar tudosok korutja 11 942 Budapest 1117 943 Hungary 945 Email: balazs.a.varga@ericsson.com 947 Janos Farkas 948 Ericsson 949 Magyar tudosok korutja 11 950 Budapest 1117 951 Hungary 953 Email: janos.farkas@ericsson.com 954 Rodney Cummings 955 National Instruments 956 11500 N. Mopac Expwy 957 Bldg. C 958 Austin, TX 78759-3504 959 USA 961 Email: rodney.cummings@ni.com 963 Yuanlong Jiang 964 Huawei Technologies Co., Ltd. 965 Bantian, Longgang district 967 Shenzhen 518129 968 China 970 Email: jiangyuanlong@huawei.com 972 Don Fedyk 973 LabN Consulting, L.L.C. 975 Email: dfedyk@labn.net