idnits 2.17.1 draft-ietf-detnet-flow-information-model-02.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 (October 22, 2018) is 2013 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-08 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-mpls-01 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-19 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 J. Farkas 3 Internet-Draft B. Varga 4 Intended status: Standards Track Ericsson 5 Expires: April 25, 2019 R. Cummings 6 National Instruments 7 Y. Jiang 8 Y. Zha 9 Huawei Technologies Co., Ltd. 10 October 22, 2018 12 DetNet Flow Information Model 13 draft-ietf-detnet-flow-information-model-02 15 Abstract 17 This document describes flow and service information model for 18 Deterministic Networking (DetNet). The DetNet service is provided 19 either for a Layer 3 or a Layer 2 flow. This document provides 20 DetNet flow and service information model both for Layer 3 and Layer 21 2 flows in an integrated fashion. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 25, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 61 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 62 4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 5 63 5. Service model . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Service overview . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Service parameters . . . . . . . . . . . . . . . . . . . 6 66 5.3. Reference Points . . . . . . . . . . . . . . . . . . . . 7 67 5.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 8 68 6. End System and DetNet domain . . . . . . . . . . . . . . . . 8 69 7. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Identification and Specification of Flows . . . . . . . . 11 71 7.1.1. DetNet L3 Flow Identification and Specification at 72 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1.2. DetNet L2 Flow Identification and Specification at 74 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.1.3. DetNetwork Flow Identification and Specification . . 12 76 7.2. Traffic Specification . . . . . . . . . . . . . . . . . . 12 77 7.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14 79 8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. Common Attributes of Source and Destination . . . . . . . . . 16 82 10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16 83 10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16 84 10.3. User to Network Requirements . . . . . . . . . . . . . . 17 85 11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18 88 13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 19 89 14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20 91 14.2. Interface Configuration . . . . . . . . . . . . . . . . 21 92 14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21 93 15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 22 94 16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 96 18. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 19.1. Normative References . . . . . . . . . . . . . . . . . . 22 99 19.2. Informative References . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Introduction 104 A Deterministic Networking (DetNet) service provides a capability to 105 carry a unicast or a multicast data flow for an application with 106 constrained requirements on network performance, e.g., low packet 107 loss rate and/or latency. The DetNet service is provided either for 108 a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network, 109 see, e.g., [I-D.ietf-detnet-dp-sol-mpls]. Similarly, Time-Sensitive 110 Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged 111 network. DetNet and TSN have common architecture as expressed in 112 [IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can 113 be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and 114 DetNet L2 flows. Therefore, the DetNet flow and service information 115 model provided by this document covers both DetNet L3 flows and 116 DetNet L2 flows in an integrated fashion. 118 In a given network scenario three information models can 119 distinguished: 121 o Flow models describe characteristics of data flows. These models 122 describe in detail all relevant aspects of a flow that are needed 123 to support the flow properly by the network between the source and 124 the destination(s). 126 o Service models describe characteristics of services being provided 127 for data flows over a network. These models can be treated as a 128 network operator independent information model. 130 o Configuration models describe in detail the settings required on 131 network nodes to serve a data flow properly. 133 Service and flow information models are used between the user and the 134 network operator. Configuration information models are used between 135 the management/control plane entity of the network and the network 136 nodes. They are shown in Figure 1. 138 User Network Operator 139 flow/service 140 /\ info model +---+ 141 / \ <---------------> | X | management/control 142 ---- +-+-+ plane entity 143 ^ 144 | configuration 145 | info model 146 +------------+ 147 v | | 148 +-+ | v Network 149 +-+ v +-+ nodes 150 +-+ +-+ 151 +-+ 153 Figure 1: Usage of Information models (flow, service and 154 configuration) 156 DetNet flow and service information model is based on 157 [I-D.ietf-detnet-architecture] and on the data model specified by 158 [IEEE8021Qcc]. Furthermore, the DetNet flow information model relies 159 on the flow identification possibilities described in [IEEE8021CB], 160 which is used by [IEEE8021Qcc] as well. In addition to TSN data 161 model, [IEEE8021Qcc] also specifies configuration of TSN features 162 (e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the 163 common architecture and flow model, configuration features can be 164 leveraged in certain deployment scenarios, e.g., when the network 165 that provides the DetNet service includes both L3 and L2 network 166 segments. 168 Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see 169 Section 4), this document (this revision) only considers the 170 Centralized Network / Distributed User Model out of the models 171 specified by [IEEE8021Qcc]. That is, there is a User-Network 172 Interface (UNI) between an end system and a network. Furthermore, 173 there is a central entity for the control of the network. For 174 instance, the central entity implements a Path Computation Element 175 (PCE) for the calculation and establishment of paths needed for 176 packet replication and elimination, if any. 178 1.1. Goals 180 As it is expressed in the Charter [IETFDetNet], the DetNet WG 181 collaborates with IEEE 802.1 TSN in order to define a common 182 architecture for both Layer 2 and Layer 3, which is beneficial for 183 various reasons, e.g., in order to simplify implementations. The 184 flow and service information models should be also common along those 185 lines. As the TSN flow information/data model specified by 187 [IEEE8021Qcc] is mature, the DetNet flow and service information 188 models described in this document are based on [IEEE8021Qcc], which 189 is an amendment to [IEEE8021Q]. 191 This document intends to specify flow and service information models 192 only. 194 1.2. Non Goals 196 This document (this revision) does not intend to specify either flow 197 data model or DetNet configuration. From these aspects, the goals of 198 this document differ from the goals of [IEEE8021Qcc], which also 199 specifies data model and configuration of certain TSN features. 201 2. Conventions Used in This Document 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 The lowercase forms with an initial capital "Must", "Must Not", 208 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 209 in this document are to be interpreted in the sense defined in 210 [RFC2119], but are used where the normative behavior is defined in 211 documents published by SDOs other than the IETF. 213 3. Terminology and Definitions 215 This document uses the terminology established in Section 2 of the 216 DetNet architecture document [I-D.ietf-detnet-architecture]. The 217 DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used 218 to perform translation from [IEEE8021Qcc] to this document. 219 Additional terms used in this document: 221 DetNet L3 Flow: Layer 3 (L3) flow leveraging DetNet service. 223 DetNet L2 Flow: Layer 2 (L2) flow leveraging DetNet service. 225 DetNetwork Flow: DetNet data plane specific encapsulated format of a 226 DetNet L2 or L3 flow leveraging DetNet service. 228 4. Naming Conventions 230 The following naming conventions were used for naming information 231 model components in this document. It is recommended that extensions 232 of the model use the same conventions. 234 o Names SHOULD be descriptive. 236 o Names MUST start with uppercase letters. 238 o Composed names MUST use capital letters for the first letter of 239 each component. All other letters are lowercase, even for 240 acronyms. Exceptions are made for acronyms containing a mixture 241 of lowercase and capital letters, such as IPv6. Examples are 242 SourceMacAddress and DestinationIPv6Address. 244 5. Service model 246 5.1. Service overview 248 The DetNet service can be defined as a service that provides a 249 capability to carry a unicast or a multicast data flow for an 250 application with constrained requirements on network performance, 251 e.g., low packet loss rate and/or latency. 253 The simplest DetNet service is to provide bridging over the DN domain 254 (i.e., tunneling for L2), where the connected hosts are in the same 255 broadcast (BC) domain. Forwarding over the DetNet domain is based on 256 L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is 257 DetNet Routing service that provides routing, so available only for 258 L3 hosts that are in different BC domains. Forwarding over the 259 DetNet domain is based on L3 (IP) addresses (i.e. dst-IP). 261 Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] show the 262 DetNet service related reference points and main components. 264 5.2. Service parameters 266 A DetNet network receives DetNet flows via a UNI as shown in Figure 5 267 in [I-D.ietf-detnet-architecture]. The DetNet network connects the 268 UNIs via tunnels in order to provide DetNet service as shown in 269 Figure 8 in [I-D.ietf-detnet-architecture]. 271 The DetNet service attributes are the following: 273 o Bandwidth 274 It is the bandwidth guaranteed for the DetNet service. 276 o Delay parameters 277 The are two delay parameters for a DetNet service: 279 * Maximum latency, which is the maximum end-to-end one-way 280 latency for the DetNet service. 282 * Packet Delay Variation (PDV), which is the difference between 283 the minimum and the maximum end-to-end one-way latency. The 284 PDV parameter describes the maximum packet delay variation for 285 the DetNet service. (Note that PDV is sometimes referred to as 286 jitter.) 288 o Loss parameters 290 * The maximum Packet Loss Ratio (PLR) parameter describes the 291 maximum packet loss ratio for the DetNet service between the 292 edges of the DetNet network. 294 * Some applications have special loss requirement. The maximum 295 consecutive loss tolerance parameter describes the maximum 296 number of consecutive packets whose loss can be tolerated. The 297 maximum consecutive loss tolerance can be measured based on 298 sequence number. 300 o Maximum allowed misordering 301 Maximum allowed misordering describes the tolerable maximum number 302 of packets that can be received out of order. The maximum allowed 303 misordering can be measured based on sequence number. The value 304 zero for the maximum allowed misordering indicates that in order 305 delivery is required, misordering cannot be tolerated. 307 o Connectivity type 308 Two connectivity types are distinguished: point-to-point (p2p) and 309 point-to-multipoint (p2mp). Connectivity type p2mp is created by 310 a transport layer function (e.g., p2mp LSP). (Note: mp2mp 311 connectivity is a superposition of p2mp connections.) 313 o Service rank 314 Service rank provides the rank of a service instance relative to 315 other services in the network. Rank is used by the network in 316 case of network resource limitation scenarios. 318 5.3. Reference Points 320 From service model design perspective a fundamental question is the 321 location of the service endpoints, i.e., where the service starts and 322 ends. 324 Note: Further discussion is needed based on data plane encapsulation 325 results what reference points should be defined. Only some possible 326 examples listed here: 328 o App-flow endpoint: End system's internal reference point for the 329 native data flow. 331 o DetNet-UNI: UNI interface ("U") on a DetNet edge node. 333 o DetNet-NNI: NNI interface ("N") between DetNet domains. 335 [[NOTE: Contributions are welcome whether we should define or 336 distinguish internal reference point(s) for DetNet-aware end-systems 337 as well. ]] 339 DetNet-UNI and DetNet-NNI are assumed in this document to be packet- 340 based reference points and provide connectivity over the packet 341 network and between domains. A DetNet-UNI adds networking technology 342 specific encapsulation to the data flow in order to transport it over 343 the network. 345 [[NOTE: Differences between the service over end-systems internal 346 reference points and DetNet-UNI is for further discussions. For 347 example, in-order delivery is expected in end system internal 348 reference points, whereas it is considered optional over the DetNet- 349 UNI. ]] 351 5.4. Service scenarios 353 Using the above defined reference points, two major service scenarios 354 can be identified: 356 o End-to-End-Service: the service reaches out to final source or 357 destination nodes, so it is an e2e service between application 358 hosting devices (end systems). 360 o DetNet-Service: the service connects networking islands, so it is 361 a service between the borders of network domain(s). 363 [[NOTE: we may consider to define further scenarios based on the 364 result of reference point related discussions. ]] 366 6. End System and DetNet domain 368 Deterministic service is required by time/loss sensitive 369 application(s) running on an end system during communication with its 370 peer(s). Such a data exchange has various requirements on delay and/ 371 or loss parameters. 373 The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes 374 two kinds of end systems: Source and Destination. The same 375 distinction is applied for the DetNet flow information model. In 376 addition to the end systems interested in a flow, the status 377 information of the flow is also important. Therefore, the DetNet 378 flow information model relies on three high level groups: 380 o Source: an end system capable of sourcing a DetNet flow. The 381 Source information group includes elements that specify the Source 382 for a single flow. This information group is applied from the 383 user to the network. 385 o Destination: an end system that is a destination of a DetNet flow. 386 The Destination information group includes elements that specify 387 the Destination for a single flow. This information group is 388 applied from the user to the network. 390 o Flow-Status: the status of a DetNet flow. The status information 391 group includes elements that specify the status of the flow in the 392 network. This information group is applied from the network to 393 the user. This information group informs the user whether or not 394 the flow is ready for use. 396 From service perspective two kinds of edge nodes can be 397 distinguished: Ingress and Egress. In addition the technology of the 398 DetNet domain and the status of the service are also important. 399 Therefore, the DetNet service information model relies on four high 400 level groups: 402 o Ingress: an edge system receiving a DetNet flow from a Source. 403 The Ingress information group includes elements that specify the 404 entry point for a single flow. This information group is applied 405 from the network to the user. 407 o Egress: an edge system sending traffic towards a Destination of a 408 DetNet flow. The Egress information group includes elements that 409 specify the egress point for a single flow. This information 410 group is applied from the network to the user. 412 o DetNet Domain: an administrative domain providing the DetNet 413 service. The DetNet domain information group includes elements 414 that specify the forwarding capabilities and methods for a single 415 flow. This information group is applied within the network. 417 o Service-Status: the status of a DetNet service. The status 418 information group includes elements that specify the status of the 419 service specific state of the network. This information group is 420 applied from the network to the user. This information group 421 informs the user whether or not the service is ready for use. 423 There are two operations for each flow with respect to a Source or a 424 Destination (and an Ingress or an Egress): 426 o Join: Source/Destination request to join the flow. 428 o Leave: Source/Destination request to leave the flow. 430 o Modify: Source/Destination request to change the flow. 432 Modify operation can be considered to address cases when a flow is 433 slightly changed, e.g., only MaxPayloadSize (Section 7.2) has been 434 changed. The advantage of having a Modify is that it allows to 435 initiate a change of flow spec while leaving the current flow is 436 operating until the change is accepted. If there is no linkage 437 between the Join and the Leave, then in figuring out whether the new 438 flow spec can be supported, the central entity has to assume that the 439 resources committed to the current flow are in use. Via Modify the 440 central entity knows that the resources supporting the current flow 441 can be available for supporting the altered flow. Modify is 442 considered to be an optional operation due to possible control-plane 443 limitations. 445 As the DetNet UNI can provide service for both L3 and L2 flows, end 446 systems may not need to implement the L3 <=> L2 Transfer Function 447 specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also 448 subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a 449 function similar to the Transfer Function, see, e.g., the Svc Proxy 450 in Figure 3 in [I-D.ietf-detnet-architecture]. 452 7. Flow 454 The flows leveraging DetNet service can be unicast or multicast data 455 flows for an application with constrained requirements on network 456 performance, e.g., low packet loss rate and/or latency. Therefore, 457 they can require different connectivity types: point-to-point (p2p) 458 or point-to-multipoint (p2mp). The p2mp connectivity is created by a 459 transport layer function (e.g., p2mp LSP) 460 [I-D.ietf-detnet-dp-sol-mpls]. (Note that mp2mp connectivity is a 461 superposition of p2mp connections.) 463 Many flows using DetNet service are periodic with fix packet size 464 (i.e., Constant Bit Rate (CBR) flows), or periodic with variable 465 packet size. 467 Delay and loss parameters are correlated because the effect of late 468 delivery can result data loss for an application. However, not all 469 applications require hard limits on both parameters (delay and loss). 470 For example, some real-time applications allow graceful degradation 471 if loss happens (e.g., sample-based processing, media distribution). 472 Some others may require high-bandwidth connections that make the 473 usage of techniques like packet replication economically challenging 474 or even impossible. Some applications may not tolerate loss, but are 475 not delay sensitive (e.g., bufferless sensors). Time/loss sensitive 476 applications may have somewhat special requirements especially for 477 loss (e.g., no loss in two consecutive communication cycles; very low 478 outage time, etc.). 480 Flows have the following attributes: 482 a. DataFlowSpecification (Section 7.1) 484 b. TrafficSpecification (Section 7.2) 486 c. FlowRank (Section 7.3) 488 Flow attributes are described in the following sections. 490 7.1. Identification and Specification of Flows 492 Identification options for DetNet flows at the UNI and within the 493 DetNet domain are specified as follows; see Section 7.1.1 for DetNet 494 L3 flows (at UNI), Section 7.1.2 for DetNet L2 flows (at UNI) and 495 Section 7.1.3 for DetNetwork flows (within the network). 497 7.1.1. DetNet L3 Flow Identification and Specification at UNI 499 DetNet L3 flows can be identified and specified by the following 500 attributes: 502 a. SourceIpAddress 504 b. DestinationIpAddress 506 c. IPv6FlowLabel 508 d. Dscp 510 e. Protocol 512 f. SourcePort 514 g. DestinationPort 516 7.1.2. DetNet L2 Flow Identification and Specification at UNI 518 DetNet L2 flows can be identified and specified by the following 519 attributes: 521 a. DestinationMacAddress 523 b. SourceMacAddress 524 c. Pcp 526 d. VlanId 528 e. EtherType 530 Note: The Multiple Stream Registration Protocol (MSRP) [IEEE8021Q] 531 uses StreamID to match Talker registrations with their corresponding 532 Listener registrations, i.e., to identify Streams (L2 TSN flows). 533 The StreamID includes the following subcomponents: 535 o A 48-bit MAC Address associated with the Talker sourcing the 536 stream to the bridged network. 538 o A 16-bit unsigned integer value, Unique ID, used to distinguish 539 among multiple streams sourced by the same Talker. 541 7.1.3. DetNetwork Flow Identification and Specification 543 Identification of DetNet flows within the DetNet domain are used in 544 the service information model. The attributes are specific to the 545 forwarding paradigm within the DetNet domain. DetNetwork flows can 546 be identified and specified by the following attributes: 548 a. SourceIpAddress 550 b. DestinationIpAddress 552 c. IPv6FlowLabel 554 d. (Protocol) 556 e. (SourcePort) 558 f. (DestinationPort) 560 g. MplsLabel 562 [[Note: attributes in brackets are dependant on current dataplane 563 discussions. ]] 565 7.2. Traffic Specification 567 TrafficSpecification specifies how the Source transmits packets for 568 the flow. This is effectively the promise/request of the Source to 569 the network. The network uses this traffic specification to allocate 570 resources and adjust queue parameters in network nodes. 572 TrafficSpecification has the following attributes: 574 a. Interval: the period of time in which the traffic specification 575 cannot be exceeded. 577 b. MaxPacketsPerInterval: the maximum number of packets that the 578 Source will transmit in one Interval. 580 c. MaxPayloadSize: the maximum payload size that the Source will 581 transmit. 583 [[NOTE (to be removed from a future revision): These attributes can 584 be used to describe any type of traffic (e.g., CBR, VBR, etc.) and 585 can be used during resource allocation to represent worst case 586 scenarios. Further optional attributes can be considered to achieve 587 more efficient resource allocation. Such optional attributes might 588 be worth for flows with soft requirements (i.e., the flow is only 589 loss sensitive or only delay sensitive, but not both delay-and-loss 590 sensitive). Possible options how to extend TrafficSpecification 591 attributes is for further discussion. Identified options are 592 described in the following notes.]] 594 [[NOTE1: Based on the already defined attributes the most similar 595 additional attributes for VBR type flows can be defined as follows: 597 o AveragePacketsPerInterval: the average number of packets that the 598 Source will transmit in one Interval. 600 o AveragePayloadSize: the average payload size that the Source will 601 transmit. 603 ]] 605 [[NOTE2: another alternative to deal better with various traffic 606 types can rely on [RFC6003], which describes the support of Metro 607 Ethernet Forum (MEF) Ethernet traffic parameters for using for 608 resource reservation purposes. Such a Bandwidth Profile can be also 609 adapted to describe the set of traffic parameters for a Detnet flow. 610 Committed Rate indicates the rate at which traffic commits to be sent 611 by the source (described in terms of the CIR (Committed Information 612 Rate) and CBS (Committed Burst Size) attributes.) Excess Rate 613 indicates the extent by which the traffic sent by the source exceeds 614 the committed rate. The Excess Rate is described in terms of the EIR 615 (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]] 617 [[NOTE3: a third alternative is to define application based traffic 618 models such as [GPP22885] defines periodic and event-driven traffic 619 model, and 5G PPP work defines traffic model for MTC (Machine Type 620 Communication) use cases [I-D.ietf-detnet-use-cases]. Periodic 621 traffic type is usually for status update between devices or devices 622 transmit status report to a central unit in regular basis. 623 TrafficPeriod, defines the period of the status update message. 624 DataSize, defines the data size of the massage which is constant. 625 3GPP also defines approximately-periodic transmission with variations 626 on period and uncertainty in the time arrival of the packets. Event- 627 triggered traffic type corresponds traffic being triggered by an MTC 628 device event. MinIntervalBetweenEvent, defines the minimum interval 629 between two events. Event-triggered transmission will not happen all 630 the time, whenever an alert is sent, it waits until the issue being 631 solved to be able to send another alert. MaxPacketPerEvent, defines 632 the max number of packets within one message. ]] 634 7.3. Flow Rank 636 FlowRank provides the rank of this flow relative to other flows in 637 the network. This rank is used to determine success/failure of flow 638 establishment. Rank (boolean) is used by the network to decide which 639 flows can and cannot exist when network resources reach their limit. 640 Rank is used to help to determine which flows can be dropped (i.e., 641 removed from node configuration) if a port of a node becomes 642 oversubscribed (e.g., due to network reconfiguration). The true 643 value is more important than the false value (i.e., flows with false 644 are dropped first). 646 7.4. Service Rank 648 ServiceRank provides the rank of this service instance relative to 649 other services in the network. This rank is used to determine 650 success/failure of service instance establishment. Rank (boolean) is 651 used by the network to decide which services can and cannot exist 652 when network resources reach their limit. Rank is used to help to 653 determine which services can be dropped (i.e., removed from node 654 configuration) if a port of a node becomes oversubscribed (e.g., due 655 to network reconfiguration). The true value is more important than 656 the false value (i.e., services with false are dropped first). 658 [[NOTE: relationship between ServiceRank and FlowRank needs further 659 discussions. A 1:N relationship is assumed (a service instance can 660 serv multiple flows). This sub-section is considered to move to the 661 service related sections. ]] 663 8. Source 665 The Source object specifies: 667 o The behavior of the Source for the flow (how/when the Source 668 transmits). 670 o The requirements of the Source from the network. 672 o The capabilities of the interface(s) of the Source. 674 The Source object includes the following attributes: 676 a. DataFlowSpecification (Section 7.1) 678 b. TrafficSpecification (Section 7.2) 680 c. FlowRank (Section 7.3) 682 d. EndSystemInterfaces (Section 10.1) 684 e. InterfaceCapabilities (Section 10.2) 686 f. UserToNetworkRequirements (Section 10.3) 688 For the join operation, the DataFlowSpecification, FlowRank, 689 EndSystemInterfaces, and TrafficSpecification SHALL be included 690 within the Source. For the join operation, the 691 UserToNetworkRequirements and InterfaceCapabilities groups MAY be 692 included within the Source. 694 For the leave operation, the DataFlowSpecification and 695 EndSystemInterfaces SHALL be included within the Source. 697 For the modify operation, the same object SHALL and MAY included as 698 for the join operation. 700 9. Destination 702 The Destination object includes the following attributes: 704 a. DataFlowSpecification (Section 7.1) 706 b. EndSystemInterfaces (Section 10.1) 708 c. InterfaceCapabilities (Section 10.2) 710 d. UserToNetworkRequirements (Section 10.3) 712 For the join operation, the DataFlowSpecification and 713 EndSystemInterfaces SHALL be included within the Destination. For 714 the join operation, the UserToNetworkRequirements and 715 InterfaceCapabilities groups MAY be included within the Destination. 717 For the leave operation, the DataFlowSpecification and 718 EndSystemInterfaces SHALL be included within the Destination. 720 For the modify operation, the same object SHALL and MAY included as 721 for the join operation. 723 [[NOTE (to be removed from a future revision): Should we add 724 DestinationRank? It could distinguish the importance of Destinations 725 if the flow cannot be provided for all Destinations.]] 727 10. Common Attributes of Source and Destination 729 Source and Destination end systems have the following common 730 attributes in addition to DataFlowSpecification (Section 7.1). 732 10.1. End System Interfaces 734 EndSystemInterfaces is a list of identifiers, one for each physical 735 interface (port) in the end system acting as a Source or Destination. 736 An interface is identified by an IP or a MAC address. 738 EndSystemInterfaces can refer also to logical sub-Interfaces if 739 supported by the end system, e.g., based on IfIndex parameter. 741 10.2. Interface Capabilities 743 InterfaceCapabilities specifies the network capabilities of all 744 interfaces (ports) contained in the EndSystemInterfaces object 745 (Section 10.1). These capabilities may be configured via the 746 InterfaceConfiguration object (Section 14.2) of the Status object 747 (Section 14). 749 Note that an end system may have multiple interfaces with different 750 network capabilities. In this case, each interface should be 751 specified in a distinct top-level Source or Destination object (i.e., 752 one entry in EndSystemInterfaces (Section 10.1)). Use of multiple 753 entries in EndSystemInterfaces is intended for network capabilities 754 that span multiple interfaces (e.g., packet replication and 755 elimination).";. 757 InterfaceCapabilities attributes: 759 a. SubInterfaceCapable (sub-interface capable) 761 b. PREF-Capable (packet replication and elimination capable) 763 [[NOTE (to be removed from a future revision): InterfaceCapabilities 764 attributes are to be defined. For information, [IEEE8021Qcc] 765 specifies the following attributes: 767 o VlanTagCapable (Customer VLAN Tag capable) 769 o CB-Capable (frame replication and elimination capable) 771 o CB-StreamIdenTypeList (a list of the optional Stream 772 Identification types supported by the interface as specified in 773 [IEEE8021CB].) 775 o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode 776 types supported by the interface as specified in [IEEE8021CB].) 778 ]] 780 10.3. User to Network Requirements 782 UserToNetworkRequirements specifies user requirements for the flow, 783 such as latency and reliability. 785 The UserToNetworkRequirements object includes the following 786 attributes: 788 a. NumReplicationTrees 790 b. MaxLatency 792 NumReplicationTrees specifies the number of maximally disjoint trees 793 that the network should configure to provide packet replication and 794 elimination for the flow. NumReplicationTrees is provided by the 795 Source only. Destinations SHALL set this element to one. Value zero 796 and one indicate no packet replication and elimination for the flow. 797 When NumReplicationTrees is greater than one, packet replication and 798 elimination is to be used for the flow. If the Source sets this 799 element to greater than one, and packet replication and elimination 800 is not possible in the network (e.g., no disjoint paths, or the nodes 801 do not support packet replication and elimination), then the 802 FailureCode of the Status object is non-zero (Section 14.1). 804 MaxLatency is the maximum latency from Source to Destination(s) for a 805 single packet of the flow. MaxLatency is specified as an integer 806 number of nanoseconds. When this requirement is specified by the 807 Source, it must be satisfied for all Destinations. When this 808 requirement is specified by a Destination, it must be satisfied for 809 that particular Destination only. If the UserToNetworkRequirements 810 group is not provided within the Source or Destination object, then 811 value zero SHALL be used for this element. Value zero represents a 812 special use for the maximum latency requirement. Value zero locks- 813 down the initial latency that the network provides in the 814 AccumulatedLatency parameter of the Status object (Section 14) after 815 the successful configuration of the flow, such that any subsequent 816 increase in the latency beyond that initial value causes the flow to 817 fail. 819 [[NOTE-1 (to be removed from a future revision): Should we add a 820 parameter to specify the maximum packet loss rate that can be 821 tolerated for the flow?]] 823 [[NOTE-2 (to be removed from a future revision): TrafficSpecification 824 (Section 7.2) specifies the Peak Information Rate (PIR) of the flow, 825 which is a kind of user requirement to the network. Should we add 826 Committed Information Rate (CIR), i.e., the minimum rate the user 827 requests to be guaranteed for the flow by the network?]] 829 11. Ingress 831 Placeholder ... 833 12. Egress 835 Placeholder ... 837 13. DetNet Domain 839 The DetNet Domain may change the encapsulation of a DetNet L2 or L3 840 flow at the UNI. That impacts not only how a flow can be recognised 841 inside the DetNet domain but also the resource reservation 842 calculations. 844 The DetNet Domain object specifies: 846 o The behavior of the flow (how/when it is transmited). 848 o The requirements of the flow from the network. 850 o The capabilities of the DetNet domain. 852 The DetNet domain object includes the following attributes: 854 a. DataFlowSpecification (Section 7.1) 856 b. TrafficSpecification (Section 7.2) 858 c. ServiceRank (Section 7.4) 859 d. DetnetDomainCapabilities (Section 13.1) 861 e. UserToNetworkRequirements (Section 10.3) 863 13.1. DetNet Domain Capabilities 865 DetnetDomainCapabilities specifies the network capabilities, which 866 can be used to provide DetNet service. DetNet Edge nodes may change 867 the encapsulation of a flow according to the data plane used inside 868 the DetNet domain. 870 DetnetDomainCapabilities object includes the following attributes: 872 a. EncapsulationFormat (data plane specific encapsulation) 874 b. PREF-Capable (packet replication and elimination capable) 876 14. Flow-status 878 The FlowStatus object is provided by the network each Source and 879 Destination of the flow. The Status object provides the status of 880 the flow with respect to the establishment of the flow by the 881 network. The Status object is delivered via the corresponding UNI to 882 each Source and Destination end system of the flow. The Status is 883 distinct for each Source or Destination because the 884 AccumulatedLatency and InterfaceConfiguration objects are distinct, 885 see below. 887 The Status object SHALL include the attributes a), b), c); and MAY 888 include attributes d), e): 890 a. DataFlowSpecification (Section 7.1) 892 b. StatusInfo (Section 14.1) 894 c. AccumulatedLatency (this section below) 896 d. InterfaceConfiguration (Section 14.2) 898 e. FailedInterfaces (Section 14.3) 900 DataFlowSpecification identifies the flow for which status is 901 provided. DataFlowSpecification is described in (Section 7.1) If the 902 Status object is provided without a Source or Destination object in a 903 protocol message via a UNI, then the DataFlowSpecification object 904 SHALL be included within the Status object for both join and leave 905 operations. If the Status object immediately follows a Source or 906 Destination object in the protocol message, then the 907 DataFlowSpecification object is obtained from the Source/Destination 908 object, and therefore DataFlowSpecification is not required within 909 the Status object. 911 AccumulatedLatency provides the worst-case latency that a single 912 packet of the flow can encounter along its current path(s) in the 913 network. When provided to a Source, AccumulatedLatency is the worst- 914 case latency for all Destinations (worst path). AccumulatedLatency 915 is specified as an integer number of nanoseconds. Latency is 916 measured using the time at which the data frame's message timestamp 917 point passes the reference plane marking the boundary between the 918 network media and PHY. The message timestamp point is specified by 919 IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful 920 Status, the network returns a value less than or equal to the 921 MaxLatency of the UserToNetworkRequirements (Section 10.3). If the 922 NumReplicationTrees of the UserToNetworkRequirements (Section 10.3) 923 is one, then the AccumlatedLatency SHALL provide the worst latency 924 for the current path from the Source to each Destination. If the 925 path is changed (e.g., due to rerouting), then the AccumulatedLatency 926 changes accordingly. If the NumReplicationTrees of the 927 UserToNetworkRequirements (Section 10.3) is greater than one, 928 AccumlatedLatency SHALL provide the worst latency for all paths in 929 use from the Source to each Destination. 931 14.1. Status Info 933 StatusInfo provides information regarding the status of a flow's 934 configuration in the network. 936 The StatusInfo object MAY include the following attributes: 938 a. SourceStatus is an enumeration for the status of the flow's 939 Source: 941 * None: no Source 943 * Ready: Source is ready 945 * Failed: Source failed 947 b. DestinationStatus is an enumeration for the status of the flow's 948 Destinations: 950 * None: no Destination 952 * Ready: all Destinations are ready 953 * PartialFailed: One or more Destinations ready, and one or more 954 Listeners failed. The flow can be used if the Source is 955 Ready. 957 * Failed: All Destinations failed. 959 c. FailureCode: A non-zero code that specifies the problem if the 960 flow encounters a failure (e.g., packet replication and 961 elimination is requested but not possible, or SourceStatus is 962 Failed, or DestinationStatus is Failed, or DestinationStatus is 963 PartialFailed). 965 [[NOTE (to be removed from a future revision): FailureCodes to be 966 defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 967 failure codes.]] 969 14.2. Interface Configuration 971 InterfaceConfiguration provides information about of interfaces in 972 the Source/Destination. This configuration related information 973 assists the network in meeting the requirements of the flow. The 974 InterfaceConfiguration object is according to the capabilities of the 975 interface. InterfaceConfiguration can be distinct for each Source or 976 Destination of each flow. If the InterfaceConfiguration object is 977 not provided within the Status object, then the network SHALL assume 978 zero elements as the default (no interface configuration). 980 The InterfaceConfiguration object MAY include one or more the 981 following attributes: 983 a. MAC or IP Address to identify the interface 985 b. DataFlowSpecification (Section 7.1) 987 14.3. Failed Interfaces 989 FailedInterfaces provides a list of one or more physical interfaces 990 (ports) in the failed node when a failure occurs in the network. 992 The FailedInterface object includes the following attributes: 994 a. MAC or IP Address to identify the interface 996 b. InterfaceName 998 InterfaceName is the name of the interface (port) within the node. 999 This interface name SHALL be persistent, and unique within the node. 1001 15. Service-status 1003 Placeholder ... 1005 16. Summary 1007 This document describes DetNet flow information model both for DetNet 1008 L3 flows and DetNet L2 flows based on the TSN data model specified by 1009 [IEEE8021Qcc]. This revision is extended with DetNet specific flow 1010 information model elements. 1012 17. IANA Considerations 1014 N/A. 1016 18. Security Considerations 1018 N/A. 1020 19. References 1022 19.1. Normative References 1024 [I-D.ietf-detnet-architecture] 1025 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1026 "Deterministic Networking Architecture", draft-ietf- 1027 detnet-architecture-08 (work in progress), September 2018. 1029 [I-D.ietf-detnet-dp-sol-mpls] 1030 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 1031 Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in 1032 progress), October 2018. 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, 1036 DOI 10.17487/RFC2119, March 1997, 1037 . 1039 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 1040 RFC 6003, DOI 10.17487/RFC6003, October 2010, 1041 . 1043 19.2. Informative References 1045 [GPP22885] 1046 3GPP, "Study on LTE support for Vehicle-to-Everything 1047 (V2X) services", 1048 . 1050 [I-D.ietf-detnet-use-cases] 1051 Grossman, E., "Deterministic Networking Use Cases", draft- 1052 ietf-detnet-use-cases-19 (work in progress), October 2018. 1054 [IEEE8021AS] 1055 IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local 1056 and metropolitan area networks - Timing and 1057 Synchronization for Time-Sensitive Applications in Bridged 1058 Local Area Networks", 2011, 1059 . 1062 [IEEE8021CB] 1063 IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local 1064 and metropolitan area networks - Frame Replication and 1065 Elimination for Reliability", 2017, 1066 . 1068 [IEEE8021Q] 1069 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 1070 metropolitan area networks - Bridges and Bridged 1071 Networks", 2014, . 1074 [IEEE8021Qbv] 1075 IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local 1076 and metropolitan area networks - Bridges and Bridged 1077 Networks -- Amendment 25: Enhancements for Scheduled 1078 Traffic", 2015, . 1081 [IEEE8021Qcc] 1082 IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for 1083 Local and metropolitan area networks - Bridges and Bridged 1084 Networks -- Amendment: Stream Reservation Protocol (SRP) 1085 Enhancements and Performance Improvements", 2017, 1086 . 1088 [IEEE8021TSN] 1089 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 1090 Task Group", . 1092 [IETFDetNet] 1093 IETF, "IETF Deterministic Networking (DetNet) Working 1094 Group", . 1096 Authors' Addresses 1098 Janos Farkas 1099 Ericsson 1100 Magyar tudosok korutja 11 1101 Budapest 1117 1102 Hungary 1104 Email: janos.farkas@ericsson.com 1106 Balazs Varga 1107 Ericsson 1108 Magyar tudosok korutja 11 1109 Budapest 1117 1110 Hungary 1112 Email: balazs.a.varga@ericsson.com 1114 Rodney Cummings 1115 National Instruments 1116 11500 N. Mopac Expwy 1117 Bldg. C 1118 Austin, TX 78759-3504 1119 USA 1121 Email: rodney.cummings@ni.com 1123 Yuanlong Jiang 1124 Huawei Technologies Co., Ltd. 1125 Bantian, Longgang district 1126 Shenzhen 518129 1127 China 1129 Email: jiangyuanlong@huawei.com 1131 Yiyong Zha 1132 Huawei Technologies Co., Ltd. 1133 China 1135 Email: zhayiyong@huawei.com