idnits 2.17.1 draft-ietf-detnet-flow-information-model-01.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 05, 2018) is 2238 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-detnet-use-cases' is defined on line 1025, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-03 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-dp-alt (ref. 'I-D.ietf-detnet-dp-alt') == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-13 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-use-cases (ref. 'I-D.ietf-detnet-use-cases') Summary: 2 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: September 6, 2018 R. Cummings 6 National Instruments 7 Y. Jiang 8 Huawei 9 Y. Zha 10 Tencent 11 March 05, 2018 13 DetNet Flow Information Model 14 draft-ietf-detnet-flow-information-model-01 16 Abstract 18 This document describes flow and service information model for 19 Deterministic Networking (DetNet). The DetNet service is provided 20 either for a Layer 3 or a Layer 2 flow. This document provides 21 DetNet flow and service information model both for Layer 3 and Layer 22 2 flows in an integrated fashion. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 62 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 63 4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 5 64 5. Service model . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Service overview . . . . . . . . . . . . . . . . . . . . 6 66 5.2. Service parameters . . . . . . . . . . . . . . . . . . . 6 67 5.3. Reference Points . . . . . . . . . . . . . . . . . . . . 7 68 5.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 8 69 6. End System and DetNet domain . . . . . . . . . . . . . . . . 8 70 7. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.1. Identification and Specification of Flows . . . . . . . . 11 72 7.1.1. DetNet L3 Flow Identification and Specification at 73 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1.2. DetNet L2 Flow Identification and Specification at 75 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1.3. DetNetwork Flow Identification and Specification . . 12 77 7.2. Traffic Specification . . . . . . . . . . . . . . . . . . 12 78 7.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14 80 8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. Common Attributes of Source and Destination . . . . . . . . . 16 83 10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16 84 10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16 85 10.3. User to Network Requirements . . . . . . . . . . . . . . 17 86 11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18 89 13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 18 90 14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20 92 14.2. Interface Configuration . . . . . . . . . . . . . . . . 21 93 14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21 94 15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 21 95 16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 18. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 19.1. Normative References . . . . . . . . . . . . . . . . . . 22 100 19.2. Informative References . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Introduction 105 A Deterministic Networking (DetNet) service provides a capability to 106 carry a unicast or a multicast data flow for an application with 107 constrained requirements on network performance, e.g., low packet 108 loss rate and/or latency. The DetNet service is provided either for 109 a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network, 110 see, e.g., [I-D.ietf-detnet-dp-alt]. Similarly, Time-Sensitive 111 Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged 112 network. DetNet and TSN have common architecture as expressed in 113 [IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can 114 be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and 115 DetNet L2 flows. Therefore, the DetNet flow and service information 116 model provided by this document covers both DetNet L3 flows and 117 DetNet L2 flows in an integrated fashion. 119 In a given network scenario three information models can 120 distinguished: 122 o Flow models describe characteristics of data flows. These models 123 describe in detail all relevant aspects of a flow that are needed 124 to support the flow properly by the network between the source and 125 the destination(s). 127 o Service models describe characteristics of services being provided 128 for data flows over a network. These models can be treated as a 129 network operator independent information model. 131 o Configuration models describe in detail the settings required on 132 network nodes to serve a data flow properly. 134 Service and flow information models are used between the user and the 135 network operator. Configuration information models are used between 136 the management/control plane entity of the network and the network 137 nodes. They are shown in Figure 1. 139 User Network Operator 140 flow/service 141 /\ info model +---+ 142 / \ <---------------> | X | management/control 143 ---- +-+-+ plane entity 144 ^ 145 | configuration 146 | info model 147 +------------+ 148 v | | 149 +-+ | v Network 150 +-+ v +-+ nodes 151 +-+ +-+ 152 +-+ 154 Figure 1: Usage of Information models (flow, service and 155 configuration) 157 DetNet flow and service information model is based on 158 [I-D.ietf-detnet-architecture] and on the data model specified by 159 [IEEE8021Qcc]. Furthermore, the DetNet flow information model relies 160 on the flow identification possibilities described in [IEEE8021CB], 161 which is used by [IEEE8021Qcc] as well. In addition to TSN data 162 model, [IEEE8021Qcc] also specifies configuration of TSN features 163 (e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the 164 common architecture and flow model, configuration features can be 165 leveraged in certain deployment scenarios, e.g., when the network 166 that provides the DetNet service includes both L3 and L2 network 167 segments. 169 Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see 170 Section 4), this document (this revision) only considers the 171 Centralized Network / Distributed User Model out of the models 172 specified by [IEEE8021Qcc]. That is, there is a User-Network 173 Interface (UNI) between an end system and a network. Furthermore, 174 there is a central entity for the control of the network. For 175 instance, the central entity implements a Path Computation Element 176 (PCE) for the calculation and establishment of paths needed for 177 packet replication and elimination, if any. 179 1.1. Goals 181 As it is expressed in the Charter [IETFDetNet], the DetNet WG 182 collaborates with IEEE 802.1 TSN in order to define a common 183 architecture for both Layer 2 and Layer 3, which is beneficial for 184 various reasons, e.g., in order to simplify implementations. The 185 flow and service information models should be also common along those 186 lines. As the TSN flow information/data model specified by 188 [IEEE8021Qcc] is mature, the DetNet flow and service information 189 models described in this document are based on [IEEE8021Qcc], which 190 is an amendment to [IEEE8021Q]. 192 This document intends to specify flow and service information models 193 only. 195 1.2. Non Goals 197 This document (this revision) does not intend to specify either flow 198 data model or DetNet configuration. From these aspects, the goals of 199 this document differ from the goals of [IEEE8021Qcc], which also 200 specifies data model and configuration of certain TSN features. 202 2. Conventions Used in This Document 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 The lowercase forms with an initial capital "Must", "Must Not", 209 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 210 in this document are to be interpreted in the sense defined in 211 [RFC2119], but are used where the normative behavior is defined in 212 documents published by SDOs other than the IETF. 214 3. Terminology and Definitions 216 This document uses the terminology established in Section 2 of the 217 DetNet architecture document [I-D.ietf-detnet-architecture]. The 218 DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used 219 to perform translation from [IEEE8021Qcc] to this document. 220 Additional terms used in this document: 222 DetNet L3 Flow: Layer 3 (L3) flow leveraging DetNet service. 224 DetNet L2 Flow: Layer 2 (L2) flow leveraging DetNet service. 226 DetNetwork Flow: DetNet data plane specific encapsulated format of a 227 DetNet L2 or L3 flow leveraging DetNet service. 229 4. Naming Conventions 231 The following naming conventions were used for naming information 232 model components in this document. It is recommended that extensions 233 of the model use the same conventions. 235 o Names SHOULD be descriptive. 237 o Names MUST start with uppercase letters. 239 o Composed names MUST use capital letters for the first letter of 240 each component. All other letters are lowercase, even for 241 acronyms. Exceptions are made for acronyms containing a mixture 242 of lowercase and capital letters, such as IPv6. Examples are 243 SourceMacAddress and DestinationIPv6Address. 245 5. Service model 247 5.1. Service overview 249 The DetNet service can be defined as a service that provides a 250 capability to carry a unicast or a multicast data flow for an 251 application with constrained requirements on network performance, 252 e.g., low packet loss rate and/or latency. 254 The simplest DetNet service is to provide bridging over the DN domain 255 (i.e., tunneling for L2), where the connected hosts are in the same 256 broadcast (BC) domain. Forwarding over the DetNet domain is based on 257 L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is 258 DetNet Routing service that provides routing, so available only for 259 L3 hosts that are in different BC domains. Forwarding over the 260 DetNet domain is based on L3 (IP) addresses (i.e. dst-IP). 262 Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] shows the 263 DetNet service related reference points and main components. 265 5.2. Service parameters 267 Two forwarding methods are distinguished: (1) Bridging and (2) 268 Routing. The DN service is represented by a DN-PSeudoWire (DN-PW). 270 Data-flows are received over the UNI. Usually there is a DN service 271 related legacy VPN service. The DN service and the legacy VPN 272 service use a common AC (attachment circuit). Legacy VPN is used by 273 regular traffic of the DetNet end-systems. DN flows are "directed" 274 by a selector to DN-PW(s). (See Figure 8. in 275 [I-D.ietf-detnet-architecture]) 277 Service attributes for DetNet connectivity are: 279 o Bandwidth parameter(s), 281 o Delay parameter(s), 283 o Loss parameter(s), 284 o Connectivity type, 286 o In order delivery, 288 o Service rank. 290 Time/loss sensitive applications may have somewhat special 291 requirements especially for loss (e.g., no loss in two consecutive 292 communication cycles; very low outage time, etc.). 294 Two connectivity types are distinguished: point-to-point (p2p) and 295 point-to-multipoint (p2mp). Connectivity type p2mp is created by a 296 transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity 297 is a superposition of p2mp connections.) 299 Depending on the application and the end-system capabilities DetNet 300 service may be requested to provide in order delivery. 302 Service rank provides the rank of a service instance relative to 303 other services in the network. Rank is used by the network in case 304 of network resource limitation scenarios. 306 5.3. Reference Points 308 From service model design perspective a fundamental question is the 309 location of the service endpoints, i.e., where the service starts and 310 ends. 312 Note: Further discussion is needed based on data plane encapsulation 313 results what reference points should be defined. Only some possible 314 examples listed here: 316 o App-flow endpoint: End system's internal reference point for the 317 native data flow. 319 o DetNet-UNI: UNI interface ("U") on a DetNet edge node. 321 o DetNet-NNI: NNI interface ("N") between DetNet domains. 323 [[NOTE: Contributions are welcome whether we should define or 324 distinguish internal reference point(s) for DetNet-aware end-systems 325 as well. ]] 327 DetNet-UNI and DetNet-NNI are assumed in this document to be packet- 328 based reference points and provide connectivity over the packet 329 network and between domains. A DetNet-UNI adds networking technology 330 specific encapsulation to the data flow in order to transport it over 331 the network. 333 [[NOTE: Differences between the service over end-systems internal 334 reference points and DetNet-UNI is for further discussions. For 335 example, in-order delivery is expected in end system internal 336 reference points, whereas it is considered optional over the DetNet- 337 UNI. ]] 339 5.4. Service scenarios 341 Using the above defined reference points, two major service scenarios 342 can be identified: 344 o End-to-End-Service: the service reaches out to final source or 345 destination nodes, so it is an e2e service between application 346 hosting devices (end systems). 348 o DetNet-Service: the service connects networking islands, so it is 349 a service between the borders of network domain(s). 351 [[NOTE: we may consider to define further scenarios based on the 352 result of reference point related discussions. ]] 354 6. End System and DetNet domain 356 Deterministic service is required by time/loss sensitive 357 application(s) running on an end system during communication with its 358 peer(s). Such a data exchange has various requirements on delay and/ 359 or loss parameters. 361 The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes 362 two kinds of end systems: Source and Destination. The same 363 distinction is applied for the DetNet flow information model. In 364 addition to the end systems interested in a flow, the status 365 information of the flow is also important. Therefore, the DetNet 366 flow information model relies on three high level groups: 368 o Source: an end system capable of sourcing a DetNet flow. The 369 Source information group includes elements that specify the Source 370 for a single flow. This information group is applied from the 371 user to the network. 373 o Destination: an end system that is a destination of a DetNet flow. 374 The Destination information group includes elements that specify 375 the Destination for a single flow. This information group is 376 applied from the user to the network. 378 o Flow-Status: the status of a DetNet flow. The status information 379 group includes elements that specify the status of the flow in the 380 network. This information group is applied from the network to 381 the user. This information group informs the user whether or not 382 the flow is ready for use. 384 From service perspective two kinds of edge nodes can be 385 distinguished: Ingress and Egress. In addition the technology of the 386 DetNet domain and the status of the service are also important. 387 Therefore, the DetNet service information model relies on four high 388 level groups: 390 o Ingress: an edge system receiving a DetNet flow from a Source. 391 The Ingress information group includes elements that specify the 392 entry point for a single flow. This information group is applied 393 from the network to the user. 395 o Egress: an edge system sending traffic towards a Destination of a 396 DetNet flow. The Egress information group includes elements that 397 specify the egress point for a single flow. This information 398 group is applied from the network to the user. 400 o DetNet Domain: an administrative domain providing the DetNet 401 service. The DetNet domain information group includes elements 402 that specify the forwarding capabilities and methods for a single 403 flow. This information group is applied within the network. 405 o Service-Status: the status of a DetNet service. The status 406 information group includes elements that specify the status of the 407 service specific state of the network. This information group is 408 applied from the network to the user. This information group 409 informs the user whether or not the service is ready for use. 411 There are two operations for each flow with respect to a Source or a 412 Destination (and an Ingress or an Egress): 414 o Join: Source/Destination request to join the flow. 416 o Leave: Source/Destination request to leave the flow. 418 o Modify: Source/Destination request to change the flow. 420 Modify operation can be considered to address cases when a flow is 421 slightly changed, e.g., only MaxPayloadSize (Section 7.2) has been 422 changed. The advantage of having a Modify is that it allows to 423 initiate a change of flow spec while leaving the current flow is 424 operating until the change is accepted. If there is no linkage 425 between the Join and the Leave, then in figuring out whether the new 426 flow spec can be supported, the central entity has to assume that the 427 resources committed to the current flow are in use. Via Modify the 428 central entity knows that the resources supporting the current flow 429 can be available for supporting the altered flow. Modify is 430 considered to be an optional operation due to possible control-plane 431 limitations. 433 As the DetNet UNI can provide service for both L3 and L2 flows, end 434 systems may not need to implement the L3 <=> L2 Transfer Function 435 specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also 436 subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a 437 function similar to the Transfer Function, see, e.g., the Svc Proxy 438 in Figure 1 in [I-D.ietf-detnet-dp-alt]. 440 7. Flow 442 The flows leveraging DetNet service can be unicast or multicast data 443 flows for an application with constrained requirements on network 444 performance, e.g., low packet loss rate and/or latency. Therefore, 445 they can require different connectivity types: point-to-point (p2p) 446 or point-to-multipoint (p2mp). The p2mp connectivity is created by a 447 transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt]. 448 (Note that mp2mp connectivity is a superposition of p2mp 449 connections.) 451 Many flows using DetNet service are periodic with fix packet size 452 (i.e., Constant Bit Rate (CBR) flows), or periodic with variable 453 packet size. 455 Delay and loss parameters are correlated because the effect of late 456 delivery can result data loss for an application. However, not all 457 applications require hard limits on both parameters (delay and loss). 458 For example, some real-time applications allow graceful degradation 459 if loss happens (e.g., sample-based processing, media distribution). 460 Some others may require high-bandwidth connections that make the 461 usage of techniques like packet replication economically challenging 462 or even impossible. Some applications may not tolerate loss, but are 463 not delay sensitive (e.g., bufferless sensors). Time/loss sensitive 464 applications may have somewhat special requirements especially for 465 loss (e.g., no loss in two consecutive communication cycles; very low 466 outage time, etc.). 468 Flows have the following attributes: 470 a. DataFlowSpecification (Section 7.1) 472 b. TrafficSpecification (Section 7.2) 474 c. FlowRank (Section 7.3) 476 Flow attributes are described in the following sections. 478 7.1. Identification and Specification of Flows 480 Identification options for DetNet flows at the UNI and within the 481 DetNet domain are specified as follows; see Section 7.1.1 for DetNet 482 L3 flows (at UNI), Section 7.1.2 for DetNet L2 flows (at UNI) and 483 Section 7.1.3 for DetNetwork flows (within the network). 485 7.1.1. DetNet L3 Flow Identification and Specification at UNI 487 DetNet L3 flows can be identified and specified by the following 488 attributes: 490 a. SourceIpAddress 492 b. DestinationIpAddress 494 c. IPv6FlowLabel 496 d. Dscp 498 e. Protocol 500 f. SourcePort 502 g. DestinationPort 504 7.1.2. DetNet L2 Flow Identification and Specification at UNI 506 DetNet L2 flows can be identified and specified by the following 507 attributes: 509 a. DestinationMacAddress 511 b. SourceMacAddress 513 c. Pcp 515 d. VlanId 517 e. EtherType 519 Note: The Multiple Stream Registration Protocol (MSRP) [IEEE8021Q] 520 uses StreamID to match Talker registrations with their corresponding 521 Listener registrations, i.e., to identify Streams (L2 TSN flows). 522 The StreamID includes the following subcomponents: 524 o A 48-bit MAC Address associated with the Talker sourcing the 525 stream to the bridged network. 527 o A 16-bit unsigned integer value, Unique ID, used to distinguish 528 among multiple streams sourced by the same Talker. 530 7.1.3. DetNetwork Flow Identification and Specification 532 Identification of DetNet flows within the DetNet domain are used in 533 the service information model. The attributes are specific to the 534 forwarding paradigm within the DetNet domain. DetNetwork flows can 535 be identified and specified by the following attributes: 537 a. SourceIpAddress 539 b. DestinationIpAddress 541 c. IPv6FlowLabel 543 d. (Protocol) 545 e. (SourcePort) 547 f. (DestinationPort) 549 g. MplsLabel 551 [[Note: attributes in brackets are dependant on current dataplane 552 discussions. ]] 554 7.2. Traffic Specification 556 TrafficSpecification specifies how the Source transmits packets for 557 the flow. This is effectively the promise/request of the Source to 558 the network. The network uses this traffic specification to allocate 559 resources and adjust queue parameters in network nodes. 561 TrafficSpecification has the following attributes: 563 a. Interval: the period of time in which the traffic specification 564 cannot be exceeded. 566 b. MaxPacketsPerInterval: the maximum number of packets that the 567 Source will transmit in one Interval. 569 c. MaxPayloadSize: the maximum payload size that the Source will 570 transmit. 572 [[NOTE (to be removed from a future revision): These attributes can 573 be used to describe any type of traffic (e.g., CBR, VBR, etc.) and 574 can be used during resource allocation to represent worst case 575 scenarios. Further optional attributes can be considered to achieve 576 more efficient resource allocation. Such optional attributes might 577 be worth for flows with soft requirements (i.e., the flow is only 578 loss sensitive or only delay sensitive, but not both delay-and-loss 579 sensitive). Possible options how to extend TrafficSpecification 580 attributes is for further discussion. Identified options are 581 described in the following notes.]] 583 [[NOTE1: Based on the already defined attributes the most similar 584 additional attributes for VBR type flows can be defined as follows: 586 o AveragePacketsPerInterval: the average number of packets that the 587 Source will transmit in one Interval. 589 o AveragePayloadSize: the average payload size that the Source will 590 transmit. 592 ]] 594 [[NOTE2: another alternative to deal better with various traffic 595 types can rely on [RFC6003], which describes the support of Metro 596 Ethernet Forum (MEF) Ethernet traffic parameters for using for 597 resource reservation purposes. Such a Bandwidth Profile can be also 598 adapted to describe the set of traffic parameters for a Detnet flow. 599 Committed Rate indicates the rate at which traffic commits to be sent 600 by the source (described in terms of the CIR (Committed Information 601 Rate) and CBS (Committed Burst Size) attributes.) Excess Rate 602 indicates the extent by which the traffic sent by the source exceeds 603 the committed rate. The Excess Rate is described in terms of the EIR 604 (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]] 606 [[NOTE3: a third alternative is to define application based traffic 607 models such as [GPP22885] defines periodic and event-driven traffic 608 model, and 5G PPP work defines traffic model for MTC (Machine Type 609 Communication) use cases. Periodic traffic type is usually for 610 status update between devices or devices transmit status report to a 611 central unit in regular basis. TrafficPeriod, defines the period of 612 the status update message. DataSize, defines the data size of the 613 massage which is constant. 3GPP also defines approximately-periodic 614 transmission with variations on period and uncertainty in the time 615 arrival of the packets. Event-triggered traffic type corresponds 616 traffic being triggered by an MTC device event. 617 MinIntervalBetweenEvent, defines the minimum interval between two 618 events. Event-triggered transmission will not happen all the time, 619 whenever an alert is sent, it waits until the issue being solved to 620 be able to send another alert. MaxPacketPerEvent, defines the max 621 number of packets within one message. ]] 623 7.3. Flow Rank 625 FlowRank provides the rank of this flow relative to other flows in 626 the network. This rank is used to determine success/failure of flow 627 establishment. Rank (boolean) is used by the network to decide which 628 flows can and cannot exist when network resources reach their limit. 629 Rank is used to help to determine which flows can be dropped (i.e., 630 removed from node configuration) if a port of a node becomes 631 oversubscribed (e.g., due to network reconfiguration). The true 632 value is more important than the false value (i.e., flows with false 633 are dropped first). 635 7.4. Service Rank 637 ServiceRank provides the rank of this service instance relative to 638 other services in the network. This rank is used to determine 639 success/failure of service instance establishment. Rank (boolean) is 640 used by the network to decide which services can and cannot exist 641 when network resources reach their limit. Rank is used to help to 642 determine which services can be dropped (i.e., removed from node 643 configuration) if a port of a node becomes oversubscribed (e.g., due 644 to network reconfiguration). The true value is more important than 645 the false value (i.e., services with false are dropped first). 647 [[NOTE: relationship between ServiceRank and FlowRank needs further 648 discussions. A 1:N relationship is assumed (a service instance can 649 serv multiple flows). This sub-section is considered to move to the 650 service related sections. ]] 652 8. Source 654 The Source object specifies: 656 o The behavior of the Source for the flow (how/when the Source 657 transmits). 659 o The requirements of the Source from the network. 661 o The capabilities of the interface(s) of the Source. 663 The Source object includes the following attributes: 665 a. DataFlowSpecification (Section 7.1) 667 b. TrafficSpecification (Section 7.2) 669 c. FlowRank (Section 7.3) 670 d. EndSystemInterfaces (Section 10.1) 672 e. InterfaceCapabilities (Section 10.2) 674 f. UserToNetworkRequirements (Section 10.3) 676 For the join operation, the DataFlowSpecification, FlowRank, 677 EndSystemInterfaces, and TrafficSpecification SHALL be included 678 within the Source. For the join operation, the 679 UserToNetworkRequirements and InterfaceCapabilities groups MAY be 680 included within the Source. 682 For the leave operation, the DataFlowSpecification and 683 EndSystemInterfaces SHALL be included within the Source. 685 For the modify operation, the same object SHALL and MAY included as 686 for the join operation. 688 9. Destination 690 The Destination object includes the following attributes: 692 a. DataFlowSpecification (Section 7.1) 694 b. EndSystemInterfaces (Section 10.1) 696 c. InterfaceCapabilities (Section 10.2) 698 d. UserToNetworkRequirements (Section 10.3) 700 For the join operation, the DataFlowSpecification and 701 EndSystemInterfaces SHALL be included within the Destination. For 702 the join operation, the UserToNetworkRequirements and 703 InterfaceCapabilities groups MAY be included within the Destination. 705 For the leave operation, the DataFlowSpecification and 706 EndSystemInterfaces SHALL be included within the Destination. 708 For the modify operation, the same object SHALL and MAY included as 709 for the join operation. 711 [[NOTE (to be removed from a future revision): Should we add 712 DestinationRank? It could distinguish the importance of Destinations 713 if the flow cannot be provided for all Destinations.]] 715 10. Common Attributes of Source and Destination 717 Source and Destination end systems have the following common 718 attributes in addition to DataFlowSpecification (Section 7.1). 720 10.1. End System Interfaces 722 EndSystemInterfaces is a list of identifiers, one for each physical 723 interface (port) in the end system acting as a Source or Destination. 724 An interface is identified by an IP or a MAC address. 726 EndSystemInterfaces can refer also to logical sub-Interfaces if 727 supported by the end system, e.g., based on IfIndex parameter. 729 10.2. Interface Capabilities 731 InterfaceCapabilities specifies the network capabilities of all 732 interfaces (ports) contained in the EndSystemInterfaces object 733 (Section 10.1). These capabilities may be configured via the 734 InterfaceConfiguration object (Section 14.2) of the Status object 735 (Section 14). 737 Note that an end system may have multiple interfaces with different 738 network capabilities. In this case, each interface should be 739 specified in a distinct top-level Source or Destination object (i.e., 740 one entry in EndSystemInterfaces (Section 10.1)). Use of multiple 741 entries in EndSystemInterfaces is intended for network capabilities 742 that span multiple interfaces (e.g., packet replication and 743 elimination).";. 745 InterfaceCapabilities attributes: 747 a. SubInterfaceCapable (sub-interface capable) 749 b. PREF-Capable (packet replication and elimination capable) 751 [[NOTE (to be removed from a future revision): InterfaceCapabilities 752 attributes are to be defined. For information, [IEEE8021Qcc] 753 specifies the following attributes: 755 o VlanTagCapable (Customer VLAN Tag capable) 757 o CB-Capable (frame replication and elimination capable) 759 o CB-StreamIdenTypeList (a list of the optional Stream 760 Identification types supported by the interface as specified in 761 [IEEE8021CB].) 763 o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode 764 types supported by the interface as specified in [IEEE8021CB].) 766 ]] 768 10.3. User to Network Requirements 770 UserToNetworkRequirements specifies user requirements for the flow, 771 such as latency and reliability. 773 The UserToNetworkRequirements object includes the following 774 attributes: 776 a. NumReplicationTrees 778 b. MaxLatency 780 NumReplicationTrees specifies the number of maximally disjoint trees 781 that the network should configure to provide packet replication and 782 elimination for the flow. NumReplicationTrees is provided by the 783 Source only. Destinations SHALL set this element to one. Value zero 784 and one indicate no packet replication and elimination for the flow. 785 When NumReplicationTrees is greater than one, packet replication and 786 elimination is to be used for the flow. If the Source sets this 787 element to greater than one, and packet replication and elimination 788 is not possible in the network (e.g., no disjoint paths, or the nodes 789 do not support packet replication and elimination), then the 790 FailureCode of the Status object is non-zero (Section 14.1). 792 MaxLatency is the maximum latency from Source to Destination(s) for a 793 single packet of the flow. MaxLatency is specified as an integer 794 number of nanoseconds. When this requirement is specified by the 795 Source, it must be satisfied for all Destinations. When this 796 requirement is specified by a Destination, it must be satisfied for 797 that particular Destination only. If the UserToNetworkRequirements 798 group is not provided within the Source or Destination object, then 799 value zero SHALL be used for this element. Value zero represents a 800 special use for the maximum latency requirement. Value zero locks- 801 down the initial latency that the network provides in the 802 AccumulatedLatency parameter of the Status object (Section 14) after 803 the successful configuration of the flow, such that any subsequent 804 increase in the latency beyond that initial value causes the flow to 805 fail. 807 [[NOTE-1 (to be removed from a future revision): Should we add a 808 parameter to specify the maximum packet loss rate that can be 809 tolerated for the flow?]] 811 [[NOTE-2 (to be removed from a future revision): TrafficSpecification 812 (Section 7.2) specifies the Peak Information Rate (PIR) of the flow, 813 which is a kind of user requirement to the network. Should we add 814 Committed Information Rate (CIR), i.e., the minimum rate the user 815 requests to be guaranteed for the flow by the network?]] 817 11. Ingress 819 Placeholder ... 821 12. Egress 823 Placeholder ... 825 13. DetNet Domain 827 The DetNet Domain may change the encapsulation of a DetNet L2 or L3 828 flow at the UNI. That impacts not only how a flow can be recognised 829 inside the DetNet domain but also the resource reservation 830 calculations. 832 The DetNet Domain object specifies: 834 o The behavior of the flow (how/when it is transmited). 836 o The requirements of the flow from the network. 838 o The capabilities of the DetNet domain. 840 The DetNet domain object includes the following attributes: 842 a. DataFlowSpecification (Section 7.1) 844 b. TrafficSpecification (Section 7.2) 846 c. ServiceRank (Section 7.4) 848 d. DetnetDomainCapabilities (Section 13.1) 850 e. UserToNetworkRequirements (Section 10.3) 852 13.1. DetNet Domain Capabilities 854 DetnetDomainCapabilities specifies the network capabilities, which 855 can be used to provide DetNet service. DetNet Edge nodes may change 856 the encapsulation of a flow according to the data plane used inside 857 the DetNet domain. 859 DetnetDomainCapabilities object includes the following attributes: 861 a. EncapsulationFormat (data plane specific encapsulation) 863 b. PREF-Capable (packet replication and elimination capable) 865 14. Flow-status 867 The FlowStatus object is provided by the network each Source and 868 Destination of the flow. The Status object provides the status of 869 the flow with respect to the establishment of the flow by the 870 network. The Status object is delivered via the corresponding UNI to 871 each Source and Destination end system of the flow. The Status is 872 distinct for each Source or Destination because the 873 AccumulatedLatency and InterfaceConfiguration objects are distinct, 874 see below. 876 The Status object SHALL include the attributes a), b), c); and MAY 877 include attributes d), e): 879 a. DataFlowSpecification (Section 7.1) 881 b. StatusInfo (Section 14.1) 883 c. AccumulatedLatency (this section below) 885 d. InterfaceConfiguration (Section 14.2) 887 e. FailedInterfaces (Section 14.3) 889 DataFlowSpecification identifies the flow for which status is 890 provided. DataFlowSpecification is described in (Section 7.1) If the 891 Status object is provided without a Source or Destination object in a 892 protocol message via a UNI, then the DataFlowSpecification object 893 SHALL be included within the Status object for both join and leave 894 operations. If the Status object immediately follows a Source or 895 Destination object in the protocol message, then the 896 DataFlowSpecification object is obtained from the Source/Destination 897 object, and therefore DataFlowSpecification is not required within 898 the Status object. 900 AccumulatedLatency provides the worst-case latency that a single 901 packet of the flow can encounter along its current path(s) in the 902 network. When provided to a Source, AccumulatedLatency is the worst- 903 case latency for all Destinations (worst path). AccumulatedLatency 904 is specified as an integer number of nanoseconds. Latency is 905 measured using the time at which the data frame's message timestamp 906 point passes the reference plane marking the boundary between the 907 network media and PHY. The message timestamp point is specified by 908 IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful 909 Status, the network returns a value less than or equal to the 910 MaxLatency of the UserToNetworkRequirements (Section 10.3). If the 911 NumReplicationTrees of the UserToNetworkRequirements (Section 10.3) 912 is one, then the AccumlatedLatency SHALL provide the worst latency 913 for the current path from the Source to each Destination. If the 914 path is changed (e.g., due to rerouting), then the AccumulatedLatency 915 changes accordingly. If the NumReplicationTrees of the 916 UserToNetworkRequirements (Section 10.3) is greater than one, 917 AccumlatedLatency SHALL provide the worst latency for all paths in 918 use from the Source to each Destination. 920 14.1. Status Info 922 StatusInfo provides information regarding the status of a flow's 923 configuration in the network. 925 The StatusInfo object MAY include the following attributes: 927 a. SourceStatus is an enumeration for the status of the flow's 928 Source: 930 * None: no Source 932 * Ready: Source is ready 934 * Failed: Source failed 936 b. DestinationStatus is an enumeration for the status of the flow's 937 Destinations: 939 * None: no Destination 941 * Ready: all Destinations are ready 943 * PartialFailed: One or more Destinations ready, and one or more 944 Listeners failed. The flow can be used if the Source is 945 Ready. 947 * Failed: All Destinations failed. 949 c. FailureCode: A non-zero code that specifies the problem if the 950 flow encounters a failure (e.g., packet replication and 951 elimination is requested but not possible, or SourceStatus is 952 Failed, or DestinationStatus is Failed, or DestinationStatus is 953 PartialFailed). 955 [[NOTE (to be removed from a future revision): FailureCodes to be 956 defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 957 failure codes.]] 959 14.2. Interface Configuration 961 InterfaceConfiguration provides information about of interfaces in 962 the Source/Destination. This configuration related information 963 assists the network in meeting the requirements of the flow. The 964 InterfaceConfiguration object is according to the capabilities of the 965 interface. InterfaceConfiguration can be distinct for each Source or 966 Destination of each flow. If the InterfaceConfiguration object is 967 not provided within the Status object, then the network SHALL assume 968 zero elements as the default (no interface configuration). 970 The InterfaceConfiguration object MAY include one or more the 971 following attributes: 973 a. MAC or IP Address to identify the interface 975 b. DataFlowSpecification (Section 7.1) 977 14.3. Failed Interfaces 979 FailedInterfaces provides a list of one or more physical interfaces 980 (ports) in the failed node when a failure occurs in the network. 982 The FailedInterface object includes the following attributes: 984 a. MAC or IP Address to identify the interface 986 b. InterfaceName 988 InterfaceName is the name of the interface (port) within the node. 989 This interface name SHALL be persistent, and unique within the node. 991 15. Service-status 993 Placeholder ... 995 16. Summary 997 This document describes DetNet flow information model both for DetNet 998 L3 flows and DetNet L2 flows based on the TSN data model specified by 999 [IEEE8021Qcc]. This revision is extended with DetNet specific flow 1000 information model elements. 1002 17. IANA Considerations 1004 N/A. 1006 18. Security Considerations 1008 N/A. 1010 19. References 1012 19.1. Normative References 1014 [I-D.ietf-detnet-architecture] 1015 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1016 "Deterministic Networking Architecture", draft-ietf- 1017 detnet-architecture-03 (work in progress), August 2017. 1019 [I-D.ietf-detnet-dp-alt] 1020 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 1021 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 1022 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 1023 (work in progress), October 2016. 1025 [I-D.ietf-detnet-use-cases] 1026 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 1027 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 1028 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 1029 X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D., 1030 Geng, X., Dujovne, D., and M. Seewald, "Deterministic 1031 Networking Use Cases", draft-ietf-detnet-use-cases-13 1032 (work in progress), September 2017. 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 [IEEE8021AS] 1051 IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local 1052 and metropolitan area networks - Timing and 1053 Synchronization for Time-Sensitive Applications in Bridged 1054 Local Area Networks", 2011, 1055 . 1058 [IEEE8021CB] 1059 IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local 1060 and metropolitan area networks - Frame Replication and 1061 Elimination for Reliability", 2017, 1062 . 1064 [IEEE8021Q] 1065 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 1066 metropolitan area networks - Bridges and Bridged 1067 Networks", 2014, . 1070 [IEEE8021Qbv] 1071 IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local 1072 and metropolitan area networks - Bridges and Bridged 1073 Networks -- Amendment 25: Enhancements for Scheduled 1074 Traffic", 2015, . 1077 [IEEE8021Qcc] 1078 IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for 1079 Local and metropolitan area networks - Bridges and Bridged 1080 Networks -- Amendment: Stream Reservation Protocol (SRP) 1081 Enhancements and Performance Improvements", 2017, 1082 . 1084 [IEEE8021TSN] 1085 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 1086 Task Group", . 1088 [IETFDetNet] 1089 IETF, "IETF Deterministic Networking (DetNet) Working 1090 Group", . 1092 Authors' Addresses 1093 Janos Farkas 1094 Ericsson 1095 Konyves Kalman krt. 11/B 1096 Budapest 1097 1097 Hungary 1099 Email: janos.farkas@ericsson.com 1101 Balazs Varga 1102 Ericsson 1103 Konyves Kalman krt. 11/B 1104 Budapest 1097 1105 Hungary 1107 Email: balazs.a.varga@ericsson.com 1109 Rodney Cummings 1110 National Instruments 1111 11500 N. Mopac Expwy 1112 Bldg. C 1113 Austin, TX 78759-3504 1114 USA 1116 Email: rodney.cummings@ni.com 1118 Yuanlong Jiang 1119 Huawei 1121 Email: jiangyuanlong@huawei.com 1123 Yiyong Zha 1124 Tencent