idnits 2.17.1 draft-ietf-detnet-flow-information-model-04.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 (July 08, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6003' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'IEEE8021TSN' is defined on line 957, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-01 == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet J. Farkas 3 Internet-Draft B. Varga 4 Intended status: Standards Track Ericsson 5 Expires: January 9, 2020 R. Cummings 6 National Instruments 7 Y. Jiang 8 Huawei Technologies Co., Ltd. 9 July 08, 2019 11 DetNet Flow Information Model 12 draft-ietf-detnet-flow-information-model-04 14 Abstract 16 This document describes flow and service information model for 17 Deterministic Networking (DetNet). These models are defined for IP 18 and MPLS DetNet data planes 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 5 59 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 6 61 2.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 62 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 63 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 64 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7 65 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 66 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8 67 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8 68 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 69 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9 70 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 71 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10 72 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10 73 5.4. Identification and Specification of DetNet Flows . . . . 10 74 5.4.1. DetNet MPLS Flow Identification and Specification . . 11 75 5.4.2. DetNet IP Flow Identification and Specification . . . 11 76 5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11 77 5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12 78 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12 79 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 12 80 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13 81 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14 82 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14 83 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14 84 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14 85 5.9.5. Maximum Consequtive Loss of the DetNet Flow . . . . . 14 86 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14 87 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14 88 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15 89 6.1. Management ID of the DetNet service . . . . . . . . . . . 15 90 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15 91 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15 92 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 16 93 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16 94 6.3.3. Maximum Latency Variation of the DetNet Service . . . 16 95 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16 96 6.3.5. Maximum Consequtive Loss of the DetNet Service . . . 16 97 6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16 98 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16 99 6.5. BiDir requirement of the DetNet Service . . . . . . . . . 17 100 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17 101 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 102 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18 103 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18 104 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 19 105 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 19 106 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 108 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 111 11.2. Informative References . . . . . . . . . . . . . . . . . 20 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 114 1. Introduction 116 A Deterministic Networking (DetNet) service provides a capability to 117 carry a unicast or a multicast data flow for an application with 118 constrained requirements on network performance, e.g., low packet 119 loss rate and/or latency. DetNet and TSN have common architecture as 120 expressed in [IETFDetNet] and [I-D.ietf-detnet-architecture]. The 121 DetNet service is provided for DetNet flows via the DetNet service 122 and forwarding sub-layers. 124 DetNet service is IP or MPLS and DetNet is currently defined for IP 125 and MPLS networks as shown in Figure 1 based on Figure 2 and Figure 3 126 of [I-D.ietf-detnet-data-plane-framework]. A DetNet flow includes 127 one or more App-flow(s) as payload. App-flows can be Ethernet, MPLS, 128 or IP flows, which impacts what header fields are use in order to 129 identify a flow. DetNet flows are created by DetNet encapsulation of 130 App-flow(s) (e.g., with added MPLS labels, etc.). In some scenarios 131 App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow 132 over a DetNet IP network). 134 +-----+ 135 | TSN | 136 +-------+ +-+-----+-+ 137 | DN IP | | DN MPLS | 138 +--+--+----+----+ +-+---+-----+-+ 139 | TSN | DN MPLS | | TSN | DN IP | 140 +-----+---------+ +-----+-------+ 142 Figure 1: DetNet Service Examples as per Data Plane Framework 144 As shown in Figure 1 as per [I-D.ietf-detnet-data-plane-framework] a 145 DetNet flow can be treated as an application level flow (App-flow) 146 e.g., at DetNet flow aggregation or in a sub-network that 147 interconnects DetNet nodes. 149 The DetNet flow and service information model provided by this 150 document contains both DetNet flow and App-flow specific information 151 in an integrated fashion. 153 In a given network scenario three information models can 154 distinguished: 156 o Flow models describe characteristics of data flows. These models 157 describe in detail all relevant aspects of a flow that are needed 158 to support the flow properly by the network between the source and 159 the destination(s). 161 o Service models describe characteristics of services being provided 162 for data flows over a network. These models can be treated as a 163 network operator independent information model. 165 o Configuration models describe in detail the settings required on 166 network nodes to serve a data flow properly. 168 Service and flow information models are used between the user and the 169 network operator. Configuration information models are used between 170 the management/control plane entity of the network and the network 171 nodes. They are shown in Figure 2. 173 User Network Operator 174 flow/service 175 /\ info model +---+ 176 / \ <---------------> | X | management/control 177 ---- +-+-+ plane entity 178 ^ 179 | configuration 180 | info model 181 +------------+ 182 v | | 183 +-+ | v Network 184 +-+ v +-+ nodes 185 +-+ +-+ 186 +-+ 188 Figure 2: Usage of Information models (flow, service and 189 configuration) 191 DetNet flow and service information model is based on 192 [I-D.ietf-detnet-architecture] and on the concept of data model 193 specified by [IEEE8021Qcc]. Furthermore, the starting point of the 194 DetNet flow information model was the flow identification 195 possibilities described in [IEEE8021CB], which is used by 196 [IEEE8021Qcc] as well. In addition to TSN data model, [IEEE8021Qcc] 197 also specifies configuration of TSN features (e.g., traffic 198 scheduling specified by [IEEE8021Qbv]). Due to the common 199 architecture and flow model, configuration features can be leveraged 200 in certain deployment scenarios, e.g., when the network that provides 201 the DetNet service includes both L3 and L2 network segments. 203 1.1. Goals 205 As it is expressed in the Charter [IETFDetNet], the DetNet WG 206 collaborates with IEEE 802.1 TSN in order to define a common 207 architecture for both Layer 2 and Layer 3, which is beneficial for 208 various reasons, e.g., in order to simplify implementations. The 209 flow and service information models should be also aligned along 210 those lines. Therefore, the DetNet flow and service information 211 models described in this document are based on [IEEE8021Qcc], which 212 is an amendment to [IEEE8021Q]. 214 This document intends to specify flow and service information models 215 only. 217 1.2. Non Goals 219 This document (this revision) does not intend to specify either flow 220 data model or DetNet configuration. From these aspects, the goals of 221 this document differ from the goals of [IEEE8021Qcc], which also 222 specifies data model and configuration of certain TSN features. 224 2. Terminology 226 2.1. Terms Used in This Document 228 This document uses the terminology established in the DetNet 229 architecture [I-D.ietf-detnet-architecture] and the the DetNet Data 230 Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader 231 is assumed to be familiar with these documents and any terminology 232 defined therein. The DetNet <=> TSN dictionary of 233 [I-D.ietf-detnet-architecture] is used to perform translation from 234 [IEEE8021Qcc] to this document. 236 The following terminology is used according to 237 [I-D.ietf-detnet-architecture]: 239 App-flow The payload (data) carried over a DetNet service. 241 DetNet flow A DetNet flow is a sequence of packets which conform 242 uniquely to a flow identifier, and to which the DetNet 243 service is to be provided. It includes any DetNet 244 headers added to support the DetNet service and 245 forwarding sub-layers. 247 The following terminology is introduced in this document: 249 Source Reference point for an App-flow, where the flow starts. 251 Destination Reference point for an App-flow, where the flow 252 terminates. 254 DN Ingress Reference point for DetNet flow, where it starts. 255 Networking technology specific encapsulation may be 256 added here to the served App-flow(s). 258 DN Egress Reference point for DetNet flow, where it terminates. 259 Networking technology specific encapsulation may be 260 removed here from the served App-flow(s). 262 2.2. Abbreviations 264 The following abbreviations are used in this document: 266 DetNet Deterministic Networking. 268 DN DetNet. 270 MPLS Multiprotocol Label Switching. 272 PSN Packet Switched Network. 274 TSN Time-Sensitive Networking. 276 2.3. Naming Conventions 278 The following naming conventions were used for naming information 279 model components in this document. It is recommended that extensions 280 of the model use the same conventions. 282 o Names SHOULD be descriptive. 284 o Names MUST start with uppercase letters. 286 o Composed names MUST use capital letters for the first letter of 287 each component. All other letters are lowercase, even for 288 acronyms. Exceptions are made for acronyms containing a mixture 289 of lowercase and capital letters, such as IPv6. Examples are 290 SourceMacAddress and DestinationIPv6Address. 292 2.4. Requirements Language 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 296 "OPTIONAL" in this document are to be interpreted as described in BCP 297 14 [RFC2119] [RFC8174] when, and only when, they appear in all 298 capitals, as shown here. 300 3. DetNet Domain and its Modeling 302 3.1. DetNet Service Overview 304 The DetNet service can be defined as a service that provides a 305 capability to carry a unicast or a multicast data flow for an 306 application with constrained requirements on network performance, 307 e.g., low packet loss rate and/or latency. 309 Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] show the 310 DetNet service related reference points and main components. 312 3.2. Reference Points Used in Modeling 314 From service design perspective a fundamental question is the 315 location of the service/flow endpoints, i.e., where the service/flow 316 starts and ends. 318 App-flow specific reference points are the Source (where it starts) 319 and the Destination (where it terminates). Similarly a DetNet flow 320 have reference points named as DN Ingress (where it starts) and DN 321 Egress (where it ends). These reference points may coexist in the 322 same node (e.g., in a DetNet IP end system). DN Ingress and DN 323 Egress reference points are intermediate reference points for a 324 served App-flow. 326 All reference points are assumed in this document to be packet-based 327 reference points. A DN Ingress may add and a DN Egress may remove 328 networking technology specific encapsulation to/from the served App- 329 flow(s) (e.g., MPLS label(s), UDP and IP headers). 331 3.3. Information Elements 333 The DetNet flow information model and the service model relies on 334 three groups of information elements: 336 o App-flow related paramaters: they describe the App-flow 337 characteristics (e.g., identification, encapsulation, traffic 338 specification, endpoints, status, etc.) and the App-flow 339 requirements (e.g., delay, loss, etc.). 341 o DetNet flow related parameters: they describe the DetNet flow 342 characteristics (e.g., identification, format, traffic 343 specification, endpoints, rank, etc.). 345 o DetNet service related parameters: they describe the expected 346 service characteristics (e.g., delivery type, connectivity delay/ 347 loss, status, rank, etc.). 349 In the information model a DetNet flow contains one or more App-flows 350 (N:1 mapping). During DetNet aggregation the aggregated DetNet flows 351 are treated as App-flows and the aggregate is the DetNet flow, which 352 provides N:1 mapping. Similarly, there is a M:1 relationship of 353 DetNet flow(s) and a DetNet Service. 355 4. App-flow Related Parameters 357 Deterministic service is required by time/loss sensitive 358 application(s) running on an end system during communication with its 359 peer(s). Such a data exchange has various requirements on delay and/ 360 or loss parameters. 362 4.1. App-flow Characteristics 364 App-flow characteristics are described with the following parameters: 366 o FlowID: it is a unique (management) identifier of the App-flow. 367 It can be used to define the N:1 mapping of App-flows to a DetNet 368 flow. 370 o FlowType: it is set according to the encapsulation format of the 371 flow. It can be Ethernet (TSN), MPLS, or IP. 373 o DataFlowSpecification: it is a flow descriptor, defining which 374 packets belongs to a flow using, e.g., FlowType specific packet 375 header fields like src-addr, dst-addr, label, VLAN-ID, etc. 377 o TrafficSpecification: it is a flow descriptor, defining traffic 378 parameters like packet size, interval, and max. packets per 379 interval. 381 o FlowEndpoints: it defines the start and termination reference 382 points of the App-flow by pointing to the source interface/node 383 and destination interface(s)/node(s). 385 o FlowStatus: it provides the status of the App-flow with respect to 386 the establishment of the flow by the network, e.g., ready, failed, 387 etc. 389 o FlowRank: it provides the rank of this flow relative to other 390 flows in the network. 392 4.2. App-flow Requirements 394 App-flow requirements are described with the following parameters: 396 o FlowRequirements: it defines the requirement of the App-flow 397 regarding bandwidth, latency, latency variation, loss, and 398 misorder tolerance. 400 o FlowBiDir: it defines the requirement of the App-flow whether it 401 has to be routed together with other App-flow(s) through the 402 network, e.g., to provide congruent paths in the two directions. 404 5. DetNet Flow Related Parameters 406 Data model specified by [IEEE8021Qcc] describes data flows using TSN 407 service as periodic flows with fix packet size (i.e., Constant Bit 408 Rate (CBR) flows) or with variable packet size. The same concept is 409 applyed for flows using DetNet service. 411 Latency and loss parameters are correlated because the effect of late 412 delivery can result data loss for an application. However, not all 413 applications require hard limits on both parameters (latency and 414 loss). For example, some real-time applications allow graceful 415 degradation if loss happens (e.g., sample-based processing, media 416 distribution). Some others may require high-bandwidth connections 417 that make the usage of techniques like packet replication 418 economically challenging or even impossible. Some applications may 419 not tolerate loss, but are not latency sensitive (e.g., bufferless 420 sensors). Time/loss sensitive applications may have somewhat special 421 requirements especially for loss (e.g., no loss in two consecutive 422 communication cycles; very low outage time, etc.). 424 DetNet flows have the following attributes: 426 a. DnFlowID (Section 5.1) 428 b. DnPayloadType (Section 5.2) 430 c. DnFlowFormat (Section 5.3) 432 d. DnFlowSpecification (Section 5.4) 434 e. DnTrafficSpecification (Section 5.5) 436 f. DnFlowEndpoints (Section 5.6) 438 g. DnFlowRank (Section 5.7) 440 h. DnFlowStatus (Section 5.8) 442 DetNet flows have the following requirement attributes: 444 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 in DnFlowID. It can be 454 used to define the M:1 mapping of DetNet flows to a DetNet service. 456 5.2. Payload type of the DetNet Flow 458 DnPayloadType attribute is set according to encapsulated App-flow 459 format. The attribute can be Ethernet, MPLS, or IP. 461 5.3. Format of the DetNet Flow 463 DnFlowFormat attribute is set according to DetNet PSN technology. 464 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 Identification of DetNet MPLS flows within the DetNet domain are used 475 in the service information model. The attributes are specific to the 476 MPLS forwarding paradigm within the DetNet domain 477 [I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be identified and 478 specified by the following attributes: 480 a. SLabel 482 b. FLabelStack 484 5.4.2. DetNet IP Flow Identification and Specification 486 DetNet IP flows can be identified and specified by the following 487 attributes (6-tuple) [I-D.ietf-detnet-ip]: 489 a. SourceIpAddress 491 b. DestinationIpAddress 493 c. IPv6FlowLabel 495 d. Dscp 497 e. Protocol 499 f. SourcePort 501 g. DestinationPort 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 cannot be exceeded. 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 These attributes can be used to describe any type of traffic (e.g., 523 CBR, VBR, etc.) and can be used during resource allocation to 524 represent worst case scenarios. 526 [[Editor's note (to be removed from a future revision): Further 527 optional attributes can be considered to achieve more efficient 528 resource allocation. Such optional attributes might be worth for 529 flows with soft requirements (i.e., the flow is only loss sensitive 530 or only delay sensitive, but not both d elay-and-loss sensitive). 531 Possible options how to extend DnTrafficSpecification attributes is 532 for further discussion. ]] 534 5.6. Endpoints of the DetNet Flow 536 DnFlowEndpoints attribute defines the starting and termination 537 reference points of the DetNet flow by pointing to the ingress 538 interface/node and egress interface(s)/node(s). Depending on the 539 network scenario it defines an interface or a node. Interface can be 540 defined for example if the App-flow is a TSN Stream and it is 541 received over a well defined UNI interface. For exampe for App-flows 542 with MPLS encapsulation defining an ingress node is more common when 543 per platform label space is used. 545 5.7. Rank of the DetNet Flow 547 DnFlowRank provides the rank of this flow relative to other flows in 548 the DetNet domain. Rank (range: 0-255) is used by the DetNet domain 549 to decide which flows can and cannot exist when network resources 550 reach their limit. Rank is used to help to determine which flows can 551 be dropped (i.e., removed from node configuration) if for example a 552 port of a node becomes oversubscribed (e.g., due to network re- 553 configuration). 555 5.8. Status of the DetNet Flow 557 DnFlowStatus provides the status of the DetNet flow with respect to 558 the establishment of the flow by the DetNet domain. 560 The DnFlowStatus SHALL include the following attributes: 562 a. DnIngressStatus is an enumeration for the status of the flow's 563 Ingress reference point: 565 * None: no Ingress. 567 * Ready: Ingress is ready. 569 * Failed: Ingress failed. 571 * OutOfService: Administratively blocked. 573 b. DnEgressStatus is an enumeration for the status of the flow's 574 Egress reference points: 576 * None: no Egress. 578 * Ready: all Egresses are ready. 580 * PartialFailed: One or more Egress ready, and one or more 581 Egress failed. The DetNet flow can be used if the Ingress is 582 Ready. 584 * Failed: All Egresses failed. 586 * OutOfService: Administratively blocked. 588 c. FailureCode: A non-zero code that specifies the problem if the 589 DetNet flow encounters a failure (e.g., packet replication and 590 elimination is requested but not possible, or DnIngressStatus is 591 Failed, or DnEgressStatus is Failed, or DnEgressStatus is 592 PartialFailed). 594 [[Editor's note (to be removed from a future revision): FailureCodes 595 to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 596 failure codes.]] 598 5.9. Requirements of the DetNet Flow 600 DnFlowRequirements specifies requirements to ensure proper serving of 601 the DetNet flow. 603 The DnFlowRequirements includes the following attributes: 605 a. MinBandwidth 607 b. MaxLatency 609 c. MaxLatencyVariation 611 d. MaxLoss 613 e. MaxConsecutiveLossTolerance 614 f. MaxMisordering 616 5.9.1. Minimum Bandwidth of the DetNet Flow 618 MinBandwidth is the minimum bandwidth that has to be guaranteed for 619 the DetNet flow. 621 5.9.2. Maximum Latency of the DetNet Flow 623 MaxLatency is the maximum latency from Ingress to Egress(es) for a 624 single packet of the DetNet flow. MaxLatency is specified as an 625 integer number of nanoseconds. 627 5.9.3. Maximum Latency Variation of the DetNet Flow 629 MaxLatencyVariation is the difference between the minimum and the 630 maximum end-to-end one-way latency. 632 5.9.4. Maximum Loss of the DetNet Flow 634 MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for 635 the DetNet flow between the Ingress and Egress(es). 637 5.9.5. Maximum Consequtive Loss of the DetNet Flow 639 Some applications have special loss requirement, like 640 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 641 parameter describes the maximum number of consecutive packets whose 642 loss can be tolerated. The maximum consecutive loss tolerance can be 643 measured for example based on sequence number. 645 5.9.6. Maximum Misordering Tolerance of the DetNet Flow 647 MaxMisordering describes the tolerable maximum number of packets that 648 can be received out of order. The maximum allowed misordering can be 649 measured for example based on sequence number. The value zero for 650 the maximum allowed misordering indicates that in order delivery is 651 required, misordering cannot be tolerated. 653 5.10. BiDir requirement of the DetNet Flow 655 DnFlowBiDir attribute defines the requirement whether the served 656 packets have to be routed together with packets of other flows 657 through the DetNet domain, e.g., to provide congruent paths in the 658 two directions. 660 6. DetNet Service Related Parameters 662 DetNet service have the following attributes: 664 a. DnServiceID (Section 6.1) 666 b. DnServiceDeliveryType (Section 6.2) 668 c. DnServiceDeliveryProfile (Section 6.3) 670 d. DNServiceConnectivity (Section 6.4) 672 e. DnServiceBiDir (Section 6.5) 674 f. DnServiceRank (Section 6.6) 676 g. DnServiceStatus (Section 6.7) 678 Service attributes are described in the following sections. 680 6.1. Management ID of the DetNet service 682 A unique (management) identifier is needed for each DetNet service 683 within the DetNet domain. It is specified in DnServiceID. It can be 684 used to define the M:1 mapping of DetNet flows to a DetNet service. 686 6.2. Delivery Type of the DetNet service 688 DnServiceDeliveryType attribute is set according to the payload of 689 the served DetNet flow (i.e., the encapsulated App-flow format). The 690 attribute can be Ethernet, MPLS, or IP. 692 6.3. Delivery Profile of the DetNet Service 694 DnServiceDeliveryProfile specifies delivery profile to ensure proper 695 serving of the DetNet flow. 697 The DnServiceDeliveryProfile includes the following attributes: 699 a. MinBandwidth 701 b. MaxLatency 703 c. MaxLatencyVariation 705 d. MaxLoss 707 e. MaxConsecutiveLossTolerance 708 f. MaxMisordering 710 6.3.1. Minimum Bandwidth of the DetNet Service 712 MinBandwidth is the minimum bandwidth that has to be guaranteed for 713 the DetNet service. 715 6.3.2. Maximum Latency of the DetNet Service 717 MaxLatency is the maximum latency from Ingress to Egress(es) for a 718 single packet of the DetNet flow. MaxLatency is specified as an 719 integer number of nanoseconds. 721 6.3.3. Maximum Latency Variation of the DetNet Service 723 MaxLatencyVariation is the difference between the minimum and the 724 maximum end-to-end one-way latency. 726 6.3.4. Maximum Loss of the DetNet Service 728 MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the 729 DetNet service between the Ingress and Egress(es) of the DetNet 730 domain. 732 6.3.5. Maximum Consequtive Loss of the DetNet Service 734 Some applications have special loss requirement, like 735 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance 736 parameter describes the maximum number of consecutive packets whose 737 loss can be tolerated. The maximum consecutive loss tolerance can be 738 measured for example based on sequence number. 740 6.3.6. Maximum Misordering Tolerance of the DetNet Service 742 MaxMisordering describes the tolerable maximum number of packets that 743 can be received out of order. The maximum allowed misordering can be 744 measured for example based on sequence number. The value zero for 745 the maximum allowed misordering indicates that in order delivery is 746 required, misordering cannot be tolerated. 748 6.4. Connectivity Type of the DetNet Service 750 Two connectivity types are distinguished: point-to-point (p2p) and 751 point-to-multipoint (p2mp). Connectivity type p2mp is created by a 752 transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity 753 is a superposition of p2mp connections.) 755 6.5. BiDir requirement of the DetNet Service 757 DnServiceBiDir attribute defines the requirement whether the served 758 packets have to be routed together with packets of other service 759 instances through the DetNet domain, e.g., to provide congruent paths 760 in the two directions. 762 6.6. Rank of the DetNet Service 764 DnServiceRank attribute provides the rank of a service instance 765 relative to other services in the DetNet domain. DnServiceRank 766 (range: 0-255) is used by the network in case of network resource 767 limitation scenarios. 769 6.7. Status of the DetNet Service 771 DnServiceStatus information group includes elements that specify the 772 status of the service specific state of the DetNet domain. This 773 information group informs the user whether or not the service is 774 ready for use. 776 The DnServiceStatus SHALL include the following attributes: 778 a. DnServiceIngressStatus is an enumeration for the status of the 779 service's Ingress: 781 * None: no Ingress. 783 * Ready: Ingress is ready. 785 * Failed: Ingress failed. 787 * OutOfService: Administratively blocked. 789 b. DnServiceEgressStatus is an enumeration for the status of the 790 service's Egress: 792 * None: no Egress. 794 * Ready: all Egresses are ready. 796 * PartialFailed: One or more Egress ready, and one or more 797 Egress failed. The DetNet flow can be used if the Ingress is 798 Ready. 800 * Failed: All Egresses failed. 802 * OutOfService: Administratively blocked. 804 c. DnServiceFailureCode: A non-zero code that specifies the problem 805 if the DetNet service encounters a failure (e.g., packet 806 replication and elimination is requested but not possible, or 807 DnServiceIngressStatus is Failed, or DnServiceEgressStatus is 808 Failed, or DnServiceEgressStatus is PartialFailed). 810 [[Editor's note (to be removed from a future revision): 811 DnServiceFailureCodes to be defined for DetNet service. Table 46-1 812 of [IEEE8021Qcc] describes TSN failure codes.]] 814 7. Flow Specific Operations 816 The DetNet flow information model relies on three high level 817 information groups: 819 o DnIngress: The DnIngress information group includes elements that 820 specify the source for a single DetNet flow. This information 821 group is applied from the user of the DetNet service to the 822 network. 824 o DnEgress: The DnEgress information group includes elements that 825 specify the destination for a single DetNet flow. This 826 information group is applied from the user of the DetNet service 827 to the network. 829 o DnFlowStatus: The status information group includes elements that 830 specify the status of the flow in the network. This information 831 group is applied from the network to the user of the DetNet 832 service. This information group informs the user whether or not 833 the DetNet flow is ready for use. 835 There are three possible operations for each DetNet flow with respect 836 to its DetNet service at a DN Ingress or a DN Egress (similarly to 837 App-flows at a Source or a Destination): 839 o Join: DN Ingress/DN Egress intends to join the flow. 841 o Leave: DN Ingress/DN Egress intends to leave the flow. 843 o Modify: DN Ingress/DN Egress intends to change the flow. 845 7.1. Join Operation 847 For the join operation, the DnFlowSpecification, DnFlowRank, 848 DnFlowEndpoint, and DnTrafficSpecification SHALL be included within 849 the DnIngress or DnEgress information group. For the join operation, 850 the DnServiceRequirements groups MAY be included. 852 7.2. Leave Operation 854 For the leave operation, the DnFlowSpecification and DnFlowEndpoint 855 SHALL be included within the DnIngress or DnEgress information group. 857 7.3. Modify Operation 859 For the modify operation, the DnFlowSpecification, DnFlowRank, 860 DnFlowEndpoint, and DnTrafficSpecification SHALL be included within 861 the DnIngress or DnEgress information group. For the join operation, 862 the DnServiceRequirements groups MAY be included. 864 Modify operation can be considered to address cases when a flow is 865 slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been 866 changed. The advantage of having a Modify is that it allows to 867 initiate a change of flow spec while leaving the current flow is 868 operating until the change is accepted. If there is no linkage 869 between the Join and the Leave, then in figuring out whether the new 870 flow spec can be supported, the controller entity has to assume that 871 the resources committed to the current flow are in use. Via Modify 872 the controller entity knows that the resources supporting the current 873 flow can be available for supporting the altered flow. Modify is 874 considered to be an optional operation due to possible controller 875 plane limitations. 877 8. Summary 879 This document describes DetNet flow information model and service 880 information model for DetNet IP networks and DetNet MPLS networks. 882 9. IANA Considerations 884 N/A. 886 10. Security Considerations 888 N/A. 890 11. References 892 11.1. Normative References 894 [I-D.ietf-detnet-architecture] 895 Finn, N., Thubert, P., Varga, B., and J. Farkas, 896 "Deterministic Networking Architecture", draft-ietf- 897 detnet-architecture-13 (work in progress), May 2019. 899 [I-D.ietf-detnet-ip] 900 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 901 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 902 draft-ietf-detnet-ip-01 (work in progress), July 2019. 904 [I-D.ietf-detnet-mpls] 905 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 906 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 907 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, 911 DOI 10.17487/RFC2119, March 1997, 912 . 914 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 915 RFC 6003, DOI 10.17487/RFC6003, October 2010, 916 . 918 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 919 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 920 May 2017, . 922 11.2. Informative References 924 [I-D.ietf-detnet-data-plane-framework] 925 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 926 Bryant, S., and J. Korhonen, "DetNet Data Plane 927 Framework", draft-ietf-detnet-data-plane-framework-01 928 (work in progress), July 2019. 930 [IEEE8021CB] 931 IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE 932 Standard for Local and metropolitan area networks - Frame 933 Replication and Elimination for Reliability", 2017, 934 . 936 [IEEE8021Q] 937 IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE 938 Standard for Local and metropolitan area networks - 939 Bridges and Bridged Networks", 2018, 940 . 942 [IEEE8021Qbv] 943 IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE 944 Standard for Local and metropolitan area networks - 945 Bridges and Bridged Networks - Amendment 25: Enhancements 946 for Scheduled Traffic", 2015, 947 . 949 [IEEE8021Qcc] 950 IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE 951 Standard for Local and metropolitan area networks - 952 Bridges and Bridged Networks -- Amendment 31: Stream 953 Reservation Protocol (SRP) Enhancements and Performance 954 Improvements", 2018, 955 . 957 [IEEE8021TSN] 958 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 959 Task Group", . 961 [IETFDetNet] 962 IETF, "IETF Deterministic Networking (DetNet) Working 963 Group", . 965 Authors' Addresses 967 Janos Farkas 968 Ericsson 969 Magyar tudosok korutja 11 970 Budapest 1117 971 Hungary 973 Email: janos.farkas@ericsson.com 975 Balazs Varga 976 Ericsson 977 Magyar tudosok korutja 11 978 Budapest 1117 979 Hungary 981 Email: balazs.a.varga@ericsson.com 982 Rodney Cummings 983 National Instruments 984 11500 N. Mopac Expwy 985 Bldg. C 986 Austin, TX 78759-3504 987 USA 989 Email: rodney.cummings@ni.com 991 Yuanlong Jiang 992 Huawei Technologies Co., Ltd. 993 Bantian, Longgang district 994 Shenzhen 518129 995 China 997 Email: jiangyuanlong@huawei.com