idnits 2.17.1 draft-ietf-detnet-flow-information-model-03.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 (March 11, 2019) is 1873 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) == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-11 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-mpls-01 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 J. Farkas 3 Internet-Draft B. Varga 4 Intended status: Standards Track Ericsson 5 Expires: September 12, 2019 R. Cummings 6 National Instruments 7 Y. Jiang 8 Huawei Technologies Co., Ltd. 9 March 11, 2019 11 DetNet Flow Information Model 12 draft-ietf-detnet-flow-information-model-03 14 Abstract 16 This document describes flow and service information model for 17 Deterministic Networking (DetNet). The DetNet service is provided 18 either for a Layer 3 or a Layer 2 flow. This document provides 19 DetNet flow and service information model both for Layer 3 and Layer 20 2 flows in an integrated fashion. 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 September 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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. ToDo list . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 61 4. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 62 5. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 6 63 6. Service model . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Service overview . . . . . . . . . . . . . . . . . . . . 6 65 6.2. Service parameters . . . . . . . . . . . . . . . . . . . 6 66 6.3. Reference Points . . . . . . . . . . . . . . . . . . . . 8 67 6.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 9 68 7. End System and DetNet domain . . . . . . . . . . . . . . . . 9 69 8. DetNet flows . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Identification and Specification of Flows . . . . . . . . 11 71 8.1.1. IP flow Identification and Specification at UNI . . . 12 72 8.1.2. L2 Flow Identification and Specification at UNI . . . 12 73 8.1.3. DetNet Flow Identification and Specification . . . . 13 74 8.2. Traffic Specification . . . . . . . . . . . . . . . . . . 13 75 8.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 15 76 9. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 11. Common Attributes of Source and Destination . . . . . . . . . 16 79 11.1. End System Interfaces . . . . . . . . . . . . . . . . . 16 80 11.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16 81 11.3. User to Network Requirements . . . . . . . . . . . . . . 17 82 12. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 13. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 14. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18 85 14.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 19 86 15. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 15.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20 88 15.2. Interface Configuration . . . . . . . . . . . . . . . . 21 89 15.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21 90 16. Service Rank . . . . . . . . . . . . . . . . . . . . . . . . 22 91 17. Service-status . . . . . . . . . . . . . . . . . . . . . . . 22 92 18. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 20. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 21.1. Normative References . . . . . . . . . . . . . . . . . . 23 97 21.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 100 1. ToDo list 102 These further actions are due on the draft: 104 o Align with updated architecture and data plane documents (partly 105 done). 107 o App-flow parameters will not be defined in detail (add references 108 only, e.g., 802.1Qcc). We focus on DetNet flows. 110 o Clarification on relationship between DetNet flow model and DetNet 111 service model. 113 o Parameter set needs finalization, some re-org of the set may be 114 needed. 116 o Sort out which parameter belongs to DetNet flow model and which to 117 DetNet service model. 119 o Clarify relationship between App-flow and DetNet flow (N:1 vs 120 1:1). 122 2. Introduction 124 A Deterministic Networking (DetNet) service provides a capability to 125 carry a unicast or a multicast data flow for an application with 126 constrained requirements on network performance, e.g., low packet 127 loss rate and/or latency. The DetNet service is provided either for 128 a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network, 129 see, e.g., [I-D.ietf-detnet-dp-sol-mpls]. Similarly, Time-Sensitive 130 Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged 131 network. DetNet and TSN have common architecture as expressed in 132 [IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can 133 be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and 134 DetNet L2 flows. Therefore, the DetNet flow and service information 135 model provided by this document covers both DetNet L3 flows and 136 DetNet L2 flows in an integrated fashion. 138 In a given network scenario three information models can 139 distinguished: 141 o Flow models describe characteristics of data flows. These models 142 describe in detail all relevant aspects of a flow that are needed 143 to support the flow properly by the network between the source and 144 the destination(s). 146 o Service models describe characteristics of services being provided 147 for data flows over a network. These models can be treated as a 148 network operator independent information model. 150 o Configuration models describe in detail the settings required on 151 network nodes to serve a data flow properly. 153 Service and flow information models are used between the user and the 154 network operator. Configuration information models are used between 155 the management/control plane entity of the network and the network 156 nodes. They are shown in Figure 1. 158 User Network Operator 159 flow/service 160 /\ info model +---+ 161 / \ <---------------> | X | management/control 162 ---- +-+-+ plane entity 163 ^ 164 | configuration 165 | info model 166 +------------+ 167 v | | 168 +-+ | v Network 169 +-+ v +-+ nodes 170 +-+ +-+ 171 +-+ 173 Figure 1: Usage of Information models (flow, service and 174 configuration) 176 DetNet flow and service information model is based on 177 [I-D.ietf-detnet-architecture] and on the data model specified by 178 [IEEE8021Qcc]. Furthermore, the DetNet flow information model relies 179 on the flow identification possibilities described in [IEEE8021CB], 180 which is used by [IEEE8021Qcc] as well. In addition to TSN data 181 model, [IEEE8021Qcc] also specifies configuration of TSN features 182 (e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the 183 common architecture and flow model, configuration features can be 184 leveraged in certain deployment scenarios, e.g., when the network 185 that provides the DetNet service includes both L3 and L2 network 186 segments. 188 Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see 189 Section 4), this document (this revision) only considers the 190 Centralized Network / Distributed User Model out of the models 191 specified by [IEEE8021Qcc]. That is, there is a User-Network 192 Interface (UNI) between an end system and a network. Furthermore, 193 there is a central entity for the control of the network. For 194 instance, the central entity implements a Path Computation Element 195 (PCE) for the calculation and establishment of paths needed for 196 packet replication and elimination, if any. 198 2.1. Goals 200 As it is expressed in the Charter [IETFDetNet], the DetNet WG 201 collaborates with IEEE 802.1 TSN in order to define a common 202 architecture for both Layer 2 and Layer 3, which is beneficial for 203 various reasons, e.g., in order to simplify implementations. The 204 flow and service information models should be also common along those 205 lines. As the TSN flow information/data model specified by 206 [IEEE8021Qcc] is mature, the DetNet flow and service information 207 models described in this document are based on [IEEE8021Qcc], which 208 is an amendment to [IEEE8021Q]. 210 This document intends to specify flow and service information models 211 only. 213 2.2. Non Goals 215 This document (this revision) does not intend to specify either flow 216 data model or DetNet configuration. From these aspects, the goals of 217 this document differ from the goals of [IEEE8021Qcc], which also 218 specifies data model and configuration of certain TSN features. 220 3. Conventions Used in This Document 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 The lowercase forms with an initial capital "Must", "Must Not", 227 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 228 in this document are to be interpreted in the sense defined in 229 [RFC2119], but are used where the normative behavior is defined in 230 documents published by SDOs other than the IETF. 232 4. Terminology and Definitions 234 This document uses the terminology established in Section 2 of the 235 DetNet architecture document [I-D.ietf-detnet-architecture]. The 236 DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used 237 to perform translation from [IEEE8021Qcc] to this document. 238 Application level flows (app-flow) can be L2 or L3 flows, what may 239 impact what header fields are use in order to identify a flow. 240 DetNet flows are created by proper DetNet encapsulation of app- 241 flow(s) (e.g., with added MPLS labels, etc.). In some scenarios App- 242 flow and DetNet flow looks similar on the wire (e.g., L3 App-flow 243 over a DetNet IP network). 245 5. Naming Conventions 247 The following naming conventions were used for naming information 248 model components in this document. It is recommended that extensions 249 of the model use the same conventions. 251 o Names SHOULD be descriptive. 253 o Names MUST start with uppercase letters. 255 o Composed names MUST use capital letters for the first letter of 256 each component. All other letters are lowercase, even for 257 acronyms. Exceptions are made for acronyms containing a mixture 258 of lowercase and capital letters, such as IPv6. Examples are 259 SourceMacAddress and DestinationIPv6Address. 261 6. Service model 263 6.1. Service overview 265 The DetNet service can be defined as a service that provides a 266 capability to carry a unicast or a multicast data flow for an 267 application with constrained requirements on network performance, 268 e.g., low packet loss rate and/or latency. 270 The simplest DetNet service is to provide bridging over the DN domain 271 (i.e., tunneling for L2), where the connected hosts are in the same 272 broadcast (BC) domain. Forwarding over the DetNet domain is based on 273 L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is 274 DetNet Routing service that provides routing, so available only for 275 L3 hosts that are in different BC domains. Forwarding over the 276 DetNet domain is based on L3 (IP) addresses (i.e. dst-IP). 278 Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] show the 279 DetNet service related reference points and main components. 281 6.2. Service parameters 283 A DetNet network receives DetNet flows via a UNI as shown in Figure 5 284 in [I-D.ietf-detnet-architecture]. The DetNet network connects the 285 UNIs via tunnels in order to provide DetNet service as shown in 286 Figure 8 in [I-D.ietf-detnet-architecture]. 288 The DetNet service attributes are the following: 290 o Service type 291 It is the flow type (L2 or L3) using the DetNet service. 293 o Bandwidth 294 It is the minimum bandwidth guaranteed for the DetNet service. 296 o Delay parameters 297 The are two delay parameters for a DetNet service: 299 * Maximum latency, which is the maximum end-to-end one-way 300 latency for the DetNet service. 302 * Packet Delay Variation (PDV), which is the difference between 303 the minimum and the maximum end-to-end one-way latency. The 304 PDV parameter describes the maximum packet delay variation for 305 the DetNet service. (Note that PDV is sometimes referred to as 306 jitter.) 308 o Loss parameters 310 * The maximum Packet Loss Ratio (PLR) parameter describes the 311 maximum packet loss ratio for the DetNet service between the 312 edges of the DetNet network. 314 * Some applications have special loss requirement. The maximum 315 consecutive loss tolerance parameter describes the maximum 316 number of consecutive packets whose loss can be tolerated. The 317 maximum consecutive loss tolerance can be measured based on 318 sequence number. 320 o Maximum allowed misordering 321 Maximum allowed misordering describes the tolerable maximum number 322 of packets that can be received out of order. The maximum allowed 323 misordering can be measured based on sequence number. The value 324 zero for the maximum allowed misordering indicates that in order 325 delivery is required, misordering cannot be tolerated. 327 o Connectivity type 328 Two connectivity types are distinguished: point-to-point (p2p) and 329 point-to-multipoint (p2mp). Connectivity type p2mp is created by 330 a transport layer function (e.g., p2mp LSP). (Note: mp2mp 331 connectivity is a superposition of p2mp connections.) 333 o Service rank 334 Service rank provides the rank of a service instance relative to 335 other services in the network. Rank is used by the network in 336 case of network resource limitation scenarios. 338 6.3. Reference Points 340 From service model design perspective a fundamental question is the 341 location of the service endpoints, i.e., where the service starts and 342 ends. 344 +--------+ 345 | | 346 | X X | 347 | ____ | 348 | / \ | 349 | | 350 |/\/\/\/\| 352 To be ADDED 353 404 Not Found 355 Figure 2: FIGURE Placeholder Reference Points 357 Note: Further discussion is needed based on data plane encapsulation 358 results what reference points should be defined. Only some possible 359 examples listed here: 361 o App-flow endpoint: End system's internal reference point for the 362 native data flow. 364 o DetNet-UNI: UNI interface ("U") on a DetNet edge node. 366 o DetNet-NNI: NNI interface ("N") between DetNet domains. 368 [[NOTE: Contributions are welcome whether we should define or 369 distinguish internal reference point(s) for DetNet-aware end-systems 370 as well. ]] 372 DetNet-UNI and DetNet-NNI are assumed in this document to be packet- 373 based reference points and provide connectivity over the packet 374 network and between domains. A DetNet-UNI may add networking 375 technology specific encapsulation to the data flow in order to 376 transport it over the network. 378 [[NOTE: Differences between the service over end-systems internal 379 reference points and DetNet-UNI is for further discussions. For 380 example, in-order delivery is expected in end system internal 381 reference points, whereas it is considered optional over the DetNet- 382 UNI. ]] 384 6.4. Service scenarios 386 Using the above defined reference points, two major service scenarios 387 can be identified: 389 o End-to-End-Service: the service reaches out to final source or 390 destination nodes, so it is an e2e service between application 391 hosting devices (end systems). 393 o DetNet-Service: the service connects networking islands, so it is 394 a service between the borders of network domain(s). 396 [[NOTE: we may consider to define further scenarios based on the 397 result of reference point related discussions. ]] 399 7. End System and DetNet domain 401 Deterministic service is required by time/loss sensitive 402 application(s) running on an end system during communication with its 403 peer(s). Such a data exchange has various requirements on delay and/ 404 or loss parameters. 406 The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes 407 two kinds of end systems: Source and Destination. The same 408 distinction is applied for the DetNet flow information model. In 409 addition to the end systems interested in a flow, the status 410 information of the flow is also important. Therefore, the DetNet 411 flow information model relies on three high level groups: 413 o Source: an end system capable of sourcing a DetNet flow. The 414 Source information group includes elements that specify the Source 415 for a single flow. This information group is applied from the 416 user to the network. 418 o Destination: an end system that is a destination of a DetNet flow. 419 The Destination information group includes elements that specify 420 the Destination for a single flow. This information group is 421 applied from the user to the network. 423 o Flow-Status: the status of a DetNet flow. The status information 424 group includes elements that specify the status of the flow in the 425 network. This information group is applied from the network to 426 the user. This information group informs the user whether or not 427 the flow is ready for use. 429 From service perspective two kinds of edge nodes can be 430 distinguished: Ingress and Egress. In addition the technology of the 431 DetNet domain and the status of the service are also important. 433 Therefore, the DetNet service information model relies on four high 434 level groups: 436 o Ingress: an edge system receiving a DetNet flow from a Source. 437 The Ingress information group includes elements that specify the 438 entry point for a single flow. This information group is applied 439 from the network to the user. 441 o Egress: an edge system sending traffic towards a Destination of a 442 DetNet flow. The Egress information group includes elements that 443 specify the egress point for a single flow. This information 444 group is applied from the network to the user. 446 o DetNet Domain: an administrative domain providing the DetNet 447 service. The DetNet domain information group includes elements 448 that specify the forwarding capabilities and methods for a single 449 flow. This information group is applied within the network. 451 o Service-Status: the status of a DetNet service. The status 452 information group includes elements that specify the status of the 453 service specific state of the network. This information group is 454 applied from the network to the user. This information group 455 informs the user whether or not the service is ready for use. 457 There are three operations for each flow with respect to a Source or 458 a Destination (and an Ingress or an Egress): 460 o Join: Source/Destination request to join the flow. 462 o Leave: Source/Destination request to leave the flow. 464 o Modify: Source/Destination request to change the flow. 466 Modify operation can be considered to address cases when a flow is 467 slightly changed, e.g., only MaxPayloadSize (Section 8.2) has been 468 changed. The advantage of having a Modify is that it allows to 469 initiate a change of flow spec while leaving the current flow is 470 operating until the change is accepted. If there is no linkage 471 between the Join and the Leave, then in figuring out whether the new 472 flow spec can be supported, the central entity has to assume that the 473 resources committed to the current flow are in use. Via Modify the 474 central entity knows that the resources supporting the current flow 475 can be available for supporting the altered flow. Modify is 476 considered to be an optional operation due to possible control-plane 477 limitations. 479 As the DetNet UNI can provide service for both L3 and L2 app-flows, 480 end systems may not need to implement the L3 <=> L2 Transfer Function 481 specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also 482 subclause 46.1 in [IEEE8021Qcc]). A DetNet edge node may implement a 483 function similar to the Transfer Function, see, e.g., the Svc Proxy 484 in Figure 3 in [I-D.ietf-detnet-architecture]. 486 8. DetNet flows 488 The app-flows leveraging DetNet service can be unicast or multicast 489 data flows of an application with constrained requirements on network 490 performance, e.g., low packet loss rate and/or latency. Flows can 491 require different connectivity types: point-to-point (p2p) or point- 492 to-multipoint (p2mp). The p2mp connectivity is created by a 493 transport layer function (e.g., p2mp LSP) 494 [I-D.ietf-detnet-dp-sol-mpls]. (Note that mp2mp connectivity is a 495 superposition of p2mp connections.) 497 Many flows using DetNet service are periodic with fix packet size 498 (i.e., Constant Bit Rate (CBR) flows), or periodic with variable 499 packet size. 501 Delay and loss parameters are correlated because the effect of late 502 delivery can result data loss for an application. However, not all 503 applications require hard limits on both parameters (delay and loss). 504 For example, some real-time applications allow graceful degradation 505 if loss happens (e.g., sample-based processing, media distribution). 506 Some others may require high-bandwidth connections that make the 507 usage of techniques like packet replication economically challenging 508 or even impossible. Some applications may not tolerate loss, but are 509 not delay sensitive (e.g., bufferless sensors). Time/loss sensitive 510 applications may have somewhat special requirements especially for 511 loss (e.g., no loss in two consecutive communication cycles; very low 512 outage time, etc.). 514 Flows have the following attributes: 516 a. DataFlowSpecification (Section 8.1) 518 b. TrafficSpecification (Section 8.2) 520 c. FlowRank (Section 8.3) 522 Flow attributes are described in the following sections. 524 8.1. Identification and Specification of Flows 526 Identification options for DetNet flows at the UNI and within the 527 DetNet domain are specified as follows; see Section 8.1.1 for DetNet 528 L3 flows (at UNI), Section 8.1.2 for DetNet L2 flows (at UNI) and 529 Section 8.1.3 for DetNetwork flows (within the network). 531 8.1.1. IP flow Identification and Specification at UNI 533 L3 data flows can be identified and specified by the following 534 attributes: 536 a. SourceIpAddress 538 b. DestinationIpAddress 540 c. IPv6FlowLabel 542 d. Dscp 544 e. Protocol 546 f. SourcePort 548 g. DestinationPort 550 8.1.2. L2 Flow Identification and Specification at UNI 552 L2 data flows can be identified and specified by the following 553 attributes: 555 a. DestinationMacAddress 557 b. SourceMacAddress 559 c. Pcp 561 d. VlanId 563 e. EtherType 565 Note: The Multiple Stream Registration Protocol (MSRP) [IEEE8021Q] 566 uses StreamID to match Talker registrations with their corresponding 567 Listener registrations, i.e., to identify Streams (L2 TSN flows). 568 The StreamID includes the following subcomponents: 570 o A 48-bit MAC Address associated with the Talker sourcing the 571 stream to the bridged network. 573 o A 16-bit unsigned integer value, Unique ID, used to distinguish 574 among multiple streams sourced by the same Talker. 576 8.1.3. DetNet Flow Identification and Specification 578 Identification of DetNet flows within the DetNet domain are used in 579 the service information model. The attributes are specific to the 580 forwarding paradigm within the DetNet domain. DetNetwork flows can 581 be identified and specified by the following attributes: 583 a. SourceIpAddress 585 b. DestinationIpAddress 587 c. IPv6FlowLabel 589 d. DSCP 591 e. Protocol 593 f. SourcePort 595 g. DestinationPort 597 h. MplsLabel 599 8.2. Traffic Specification 601 TrafficSpecification specifies how the Source transmits packets for 602 the flow. This is effectively the promise/request of the Source to 603 the network. The network uses this traffic specification to allocate 604 resources and adjust queue parameters in network nodes. 606 TrafficSpecification has the following attributes: 608 a. Interval: the period of time in which the traffic specification 609 cannot be exceeded. 611 b. MaxPacketsPerInterval: the maximum number of packets that the 612 Source will transmit in one Interval. 614 c. MaxPayloadSize: the maximum payload size that the Source will 615 transmit. 617 [[NOTE (to be removed from a future revision): These attributes can 618 be used to describe any type of traffic (e.g., CBR, VBR, etc.) and 619 can be used during resource allocation to represent worst case 620 scenarios. Further optional attributes can be considered to achieve 621 more efficient resource allocation. Such optional attributes might 622 be worth for flows with soft requirements (i.e., the flow is only 623 loss sensitive or only delay sensitive, but not both delay-and-loss 624 sensitive). Possible options how to extend TrafficSpecification 625 attributes is for further discussion. Identified options are 626 described in the following notes.]] 628 [[NOTE1: Based on the already defined attributes the most similar 629 additional attributes for VBR type flows can be defined as follows: 631 o AveragePacketsPerInterval: the average number of packets that the 632 Source will transmit in one Interval. 634 o AveragePayloadSize: the average payload size that the Source will 635 transmit. 637 ]] 639 [[NOTE2: another alternative to deal better with various traffic 640 types can rely on [RFC6003], which describes the support of Metro 641 Ethernet Forum (MEF) Ethernet traffic parameters for using for 642 resource reservation purposes. Such a Bandwidth Profile can be also 643 adapted to describe the set of traffic parameters for a Detnet flow. 644 Committed Rate indicates the rate at which traffic commits to be sent 645 by the source (described in terms of the CIR (Committed Information 646 Rate) and CBS (Committed Burst Size) attributes.) Excess Rate 647 indicates the extent by which the traffic sent by the source exceeds 648 the committed rate. The Excess Rate is described in terms of the EIR 649 (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]] 651 [[NOTE3: a third alternative is to define application based traffic 652 models such as [GPP22885] defines periodic and event-driven traffic 653 model, and 5G PPP work defines traffic model for MTC (Machine Type 654 Communication) use cases [I-D.ietf-detnet-use-cases]. Periodic 655 traffic type is usually for status update between devices or devices 656 transmit status report to a central unit in regular basis. 657 TrafficPeriod, defines the period of the status update message. 658 DataSize, defines the data size of the massage which is constant. 659 3GPP also defines approximately-periodic transmission with variations 660 on period and uncertainty in the time arrival of the packets. Event- 661 triggered traffic type corresponds traffic being triggered by an MTC 662 device event. MinIntervalBetweenEvent, defines the minimum interval 663 between two events. Event-triggered transmission will not happen all 664 the time, whenever an alert is sent, it waits until the issue being 665 solved to be able to send another alert. MaxPacketPerEvent, defines 666 the max number of packets within one message. ]] 668 8.3. Flow Rank 670 FlowRank provides the rank of this flow relative to other flows in 671 the network. This rank is used to determine success/failure of flow 672 establishment. Rank (boolean) is used by the network to decide which 673 flows can and cannot exist when network resources reach their limit. 674 Rank is used to help to determine which flows can be dropped (i.e., 675 removed from node configuration) if a port of a node becomes 676 oversubscribed (e.g., due to network reconfiguration). The true 677 value is more important than the false value (i.e., flows with false 678 are dropped first). 680 9. Source 682 The Source object specifies: 684 o The behavior of the Source for the flow (how/when the Source 685 transmits). 687 o The requirements of the Source from the network. 689 o The capabilities of the interface(s) of the Source. 691 The Source object includes the following attributes: 693 a. DataFlowSpecification (Section 8.1) 695 b. TrafficSpecification (Section 8.2) 697 c. FlowRank (Section 8.3) 699 d. EndSystemInterfaces (Section 11.1) 701 e. InterfaceCapabilities (Section 11.2) 703 f. UserToNetworkRequirements (Section 11.3) 705 For the join operation, the DataFlowSpecification, FlowRank, 706 EndSystemInterfaces, and TrafficSpecification SHALL be included 707 within the Source. For the join operation, the 708 UserToNetworkRequirements and InterfaceCapabilities groups MAY be 709 included within the Source. 711 For the leave operation, the DataFlowSpecification and 712 EndSystemInterfaces SHALL be included within the Source. 714 For the modify operation, the same object SHALL and MAY included as 715 for the join operation. 717 10. Destination 719 The Destination object includes the following attributes: 721 a. DataFlowSpecification (Section 8.1) 723 b. EndSystemInterfaces (Section 11.1) 725 c. InterfaceCapabilities (Section 11.2) 727 d. UserToNetworkRequirements (Section 11.3) 729 For the join operation, the DataFlowSpecification and 730 EndSystemInterfaces SHALL be included within the Destination. For 731 the join operation, the UserToNetworkRequirements and 732 InterfaceCapabilities groups MAY be included within the Destination. 734 For the leave operation, the DataFlowSpecification and 735 EndSystemInterfaces SHALL be included within the Destination. 737 For the modify operation, the same object SHALL and MAY included as 738 for the join operation. 740 [[NOTE (to be removed from a future revision): Adding a general 741 EndpointRank? That would define the endpoint importance (source, 742 destination). It is only partly covered by FlowRank ... For 743 example, it could distinguish the importance of Destinations if the 744 flow cannot be provided for all Destinations.]] 746 11. Common Attributes of Source and Destination 748 Source and Destination end systems have the following common 749 attributes in addition to DataFlowSpecification (Section 8.1). 751 11.1. End System Interfaces 753 EndSystemInterfaces is a list of identifiers, one for each physical 754 interface (port) in the end system acting as a Source or Destination. 755 An interface is identified by an IP or a MAC address. 757 EndSystemInterfaces can refer also to logical sub-Interfaces if 758 supported by the end system, e.g., based on IfIndex parameter. 760 11.2. Interface Capabilities 762 InterfaceCapabilities specifies the network capabilities of all 763 interfaces (ports) contained in the EndSystemInterfaces object 764 (Section 11.1). These capabilities may be configured via the 765 InterfaceConfiguration object (Section 15.2) of the Status object 766 (Section 15). 768 Note that an end system may have multiple interfaces with different 769 network capabilities. In this case, each interface should be 770 specified in a distinct top-level Source or Destination object (i.e., 771 one entry in EndSystemInterfaces (Section 11.1)). Use of multiple 772 entries in EndSystemInterfaces is intended for network capabilities 773 that span multiple interfaces (e.g., packet replication and 774 elimination).";. 776 InterfaceCapabilities attributes: 778 a. SubInterfaceCapable (sub-interface capable) 780 b. PREF-Capable (packet replication and elimination capable) 782 c. POF-Capable (packet ordering capable) 784 [[NOTE (to be removed from a future revision): InterfaceCapabilities 785 attributes are to be defined. For information, [IEEE8021Qcc] 786 specifies the following attributes: 788 o VlanTagCapable (Customer VLAN Tag capable) 790 o CB-Capable (frame replication and elimination capable) 792 o CB-StreamIdenTypeList (a list of the optional Stream 793 Identification types supported by the interface as specified in 794 [IEEE8021CB].) 796 o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode 797 types supported by the interface as specified in [IEEE8021CB].) 799 ]] 801 11.3. User to Network Requirements 803 UserToNetworkRequirements specifies user requirements for the flow, 804 such as latency and reliability. 806 The UserToNetworkRequirements object includes the following 807 attributes: 809 a. MaxLatency 811 MaxLatency is the maximum latency from Source to Destination(s) for a 812 single packet of the flow. MaxLatency is specified as an integer 813 number of nanoseconds. When this requirement is specified by the 814 Source, it must be satisfied for all Destinations. When this 815 requirement is specified by a Destination, it must be satisfied for 816 that particular Destination only. If the UserToNetworkRequirements 817 group is not provided within the Source or Destination object, then 818 value zero SHALL be used for this element. Value zero represents a 819 special use for the maximum latency requirement. Value zero locks- 820 down the initial latency that the network provides in the 821 AccumulatedLatency parameter of the Status object (Section 15) after 822 the successful configuration of the flow, such that any subsequent 823 increase in the latency beyond that initial value causes the flow to 824 fail. 826 [[NOTE-1 (to be removed from a future revision): Should we add a 827 parameter to specify the maximum packet loss rate that can be 828 tolerated for the flow?]] 830 [[NOTE-2 (to be removed from a future revision): TrafficSpecification 831 (Section 8.2) specifies the Peak Information Rate (PIR) of the flow, 832 which is a kind of user requirement to the network. Should we add 833 Committed Information Rate (CIR), i.e., the minimum rate the user 834 requests to be guaranteed for the flow by the network?]] 836 12. Ingress 838 Placeholder ... 840 13. Egress 842 Placeholder ... 844 14. DetNet Domain 846 The DetNet Domain may change the encapsulation of a DetNet L2 or L3 847 flow at the UNI. That impacts not only how a flow can be recognised 848 inside the DetNet domain but also the resource reservation 849 calculations. 851 The DetNet Domain object specifies: 853 o The behavior of the flow (how/when it is transmited). 855 o The requirements of the flow from the network. 857 o The capabilities of the DetNet domain. 859 The DetNet domain object includes the following attributes: 861 a. DataFlowSpecification (Section 8.1) 863 b. TrafficSpecification (Section 8.2) 865 c. ServiceRank (Section 16) 867 d. DetnetDomainCapabilities (Section 14.1) 869 e. UserToNetworkRequirements (Section 11.3) 871 14.1. DetNet Domain Capabilities 873 DetnetDomainCapabilities specifies the network capabilities, which 874 can be used to provide DetNet service. DetNet Edge nodes may change 875 the encapsulation of a flow according to the data plane used inside 876 the DetNet domain. 878 DetnetDomainCapabilities object includes the following attributes: 880 a. EncapsulationFormat (data plane specific encapsulation) 882 b. PREF-Capable (packet replication and elimination capable) 884 15. Flow-status 886 The FlowStatus object is provided by the network each Source and 887 Destination of the flow. The Status object provides the status of 888 the flow with respect to the establishment of the flow by the 889 network. The Status object is delivered via the corresponding UNI to 890 each Source and Destination end system of the flow. The Status is 891 distinct for each Source or Destination because the 892 AccumulatedLatency and InterfaceConfiguration objects are distinct, 893 see below. 895 The Status object SHALL include the attributes a), b), c); and MAY 896 include attributes d), e): 898 a. DataFlowSpecification (Section 8.1) 900 b. StatusInfo (Section 15.1) 902 c. AccumulatedLatency (this section below) 904 d. InterfaceConfiguration (Section 15.2) 906 e. FailedInterfaces (Section 15.3) 907 DataFlowSpecification identifies the flow for which status is 908 provided. DataFlowSpecification is described in (Section 8.1) If the 909 Status object is provided without a Source or Destination object in a 910 protocol message via a UNI, then the DataFlowSpecification object 911 SHALL be included within the Status object for both join and leave 912 operations. If the Status object immediately follows a Source or 913 Destination object in the protocol message, then the 914 DataFlowSpecification object is obtained from the Source/Destination 915 object, and therefore DataFlowSpecification is not required within 916 the Status object. 918 AccumulatedLatency provides the worst-case latency that a single 919 packet of the flow can encounter along its current path(s) in the 920 network. When provided to a Source, AccumulatedLatency is the worst- 921 case latency for all Destinations (worst path). AccumulatedLatency 922 is specified as an integer number of nanoseconds. Latency is 923 measured using the time at which the data frame's message timestamp 924 point passes the reference plane marking the boundary between the 925 network media and PHY. The message timestamp point is specified by 926 IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful 927 Status, the network returns a value less than or equal to the 928 MaxLatency of the UserToNetworkRequirements (Section 11.3). If the 929 NumReplicationTrees of the UserToNetworkRequirements (Section 11.3) 930 is one, then the AccumlatedLatency SHALL provide the worst latency 931 for the current path from the Source to each Destination. If the 932 path is changed (e.g., due to rerouting), then the AccumulatedLatency 933 changes accordingly. If the NumReplicationTrees of the 934 UserToNetworkRequirements (Section 11.3) is greater than one, 935 AccumlatedLatency SHALL provide the worst latency for all paths in 936 use from the Source to each Destination. 938 15.1. Status Info 940 StatusInfo provides information regarding the status of a flow's 941 configuration in the network. 943 The StatusInfo object MAY include the following attributes: 945 a. SourceStatus is an enumeration for the status of the flow's 946 Source: 948 * None: no Source 950 * Ready: Source is ready 952 * Failed: Source failed 954 b. DestinationStatus is an enumeration for the status of the flow's 955 Destinations: 957 * None: no Destination 959 * Ready: all Destinations are ready 961 * PartialFailed: One or more Destinations ready, and one or more 962 Listeners failed. The flow can be used if the Source is 963 Ready. 965 * Failed: All Destinations failed. 967 c. FailureCode: A non-zero code that specifies the problem if the 968 flow encounters a failure (e.g., packet replication and 969 elimination is requested but not possible, or SourceStatus is 970 Failed, or DestinationStatus is Failed, or DestinationStatus is 971 PartialFailed). 973 [[NOTE (to be removed from a future revision): FailureCodes to be 974 defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 975 failure codes.]] 977 15.2. Interface Configuration 979 InterfaceConfiguration provides information about of interfaces in 980 the Source/Destination. This configuration related information 981 assists the network in meeting the requirements of the flow. The 982 InterfaceConfiguration object is according to the capabilities of the 983 interface. InterfaceConfiguration can be distinct for each Source or 984 Destination of each flow. If the InterfaceConfiguration object is 985 not provided within the Status object, then the network SHALL assume 986 zero elements as the default (no interface configuration). 988 The InterfaceConfiguration object MAY include one or more the 989 following attributes: 991 a. MAC or IP Address to identify the interface 993 b. DataFlowSpecification (Section 8.1) 995 15.3. Failed Interfaces 997 FailedInterfaces provides a list of one or more physical interfaces 998 (ports) in the failed node when a failure occurs in the network. 1000 The FailedInterface object includes the following attributes: 1002 a. MAC or IP Address to identify the interface 1004 b. InterfaceName 1006 InterfaceName is the name of the interface (port) within the node. 1007 This interface name SHALL be persistent, and unique within the node. 1009 16. Service Rank 1011 ServiceRank provides the rank of this service instance relative to 1012 other services in the network. This rank is used to determine 1013 success/failure of service instance establishment. Rank (boolean) is 1014 used by the network to decide which services can and cannot exist 1015 when network resources reach their limit. Rank is used to help to 1016 determine which services can be dropped (i.e., removed from node 1017 configuration) if a port of a node becomes oversubscribed (e.g., due 1018 to network reconfiguration). The true value is more important than 1019 the false value (i.e., services with false are dropped first). 1021 [[NOTE: relationship between ServiceRank and FlowRank needs further 1022 discussions. A 1:N relationship is assumed (a service instance can 1023 serv multiple flows). This sub-section is considered to move to the 1024 service related sections. ]] 1026 17. Service-status 1028 Placeholder ... 1030 18. Summary 1032 This document describes DetNet flow information model both for DetNet 1033 L3 flows and DetNet L2 flows based on the TSN data model specified by 1034 [IEEE8021Qcc]. This revision is extended with DetNet specific flow 1035 information model elements. 1037 19. IANA Considerations 1039 N/A. 1041 20. Security Considerations 1043 N/A. 1045 21. References 1046 21.1. Normative References 1048 [I-D.ietf-detnet-architecture] 1049 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1050 "Deterministic Networking Architecture", draft-ietf- 1051 detnet-architecture-11 (work in progress), February 2019. 1053 [I-D.ietf-detnet-dp-sol-mpls] 1054 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 1055 Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in 1056 progress), October 2018. 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, 1060 DOI 10.17487/RFC2119, March 1997, 1061 . 1063 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 1064 RFC 6003, DOI 10.17487/RFC6003, October 2010, 1065 . 1067 21.2. Informative References 1069 [GPP22885] 1070 3GPP, "Study on LTE support for Vehicle-to-Everything 1071 (V2X) services", 1072 . 1074 [I-D.ietf-detnet-use-cases] 1075 Grossman, E., "Deterministic Networking Use Cases", draft- 1076 ietf-detnet-use-cases-20 (work in progress), December 1077 2018. 1079 [IEEE8021AS] 1080 IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local 1081 and metropolitan area networks - Timing and 1082 Synchronization for Time-Sensitive Applications in Bridged 1083 Local Area Networks", 2011, 1084 . 1087 [IEEE8021CB] 1088 IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local 1089 and metropolitan area networks - Frame Replication and 1090 Elimination for Reliability", 2017, 1091 . 1093 [IEEE8021Q] 1094 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 1095 metropolitan area networks - Bridges and Bridged 1096 Networks", 2014, . 1099 [IEEE8021Qbv] 1100 IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local 1101 and metropolitan area networks - Bridges and Bridged 1102 Networks -- Amendment 25: Enhancements for Scheduled 1103 Traffic", 2015, . 1106 [IEEE8021Qcc] 1107 IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for 1108 Local and metropolitan area networks - Bridges and Bridged 1109 Networks -- Amendment: Stream Reservation Protocol (SRP) 1110 Enhancements and Performance Improvements", 2017, 1111 . 1113 [IEEE8021TSN] 1114 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 1115 Task Group", . 1117 [IETFDetNet] 1118 IETF, "IETF Deterministic Networking (DetNet) Working 1119 Group", . 1121 Authors' Addresses 1123 Janos Farkas 1124 Ericsson 1125 Magyar tudosok korutja 11 1126 Budapest 1117 1127 Hungary 1129 Email: janos.farkas@ericsson.com 1131 Balazs Varga 1132 Ericsson 1133 Magyar tudosok korutja 11 1134 Budapest 1117 1135 Hungary 1137 Email: balazs.a.varga@ericsson.com 1138 Rodney Cummings 1139 National Instruments 1140 11500 N. Mopac Expwy 1141 Bldg. C 1142 Austin, TX 78759-3504 1143 USA 1145 Email: rodney.cummings@ni.com 1147 Yuanlong Jiang 1148 Huawei Technologies Co., Ltd. 1149 Bantian, Longgang district 1150 Shenzhen 518129 1151 China 1153 Email: jiangyuanlong@huawei.com