idnits 2.17.1 draft-farkas-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 (June 30, 2017) is 2492 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-00 ** 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-01 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-use-cases (ref. 'I-D.ietf-detnet-use-cases') Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet J. Farkas 3 Internet-Draft B. Varga 4 Intended status: Standards Track Ericsson 5 Expires: January 1, 2018 R. Cummings 6 National Instruments 7 J. Yuanlong 8 Z. Yiyong 9 Huawei 10 June 30, 2017 12 DetNet Flow Information Model 13 draft-farkas-detnet-flow-information-model-01 15 Abstract 17 This document describes flow information model for Deterministic 18 Networking (DetNet). The DetNet service is provided either for a 19 Layer 3 or a Layer 2 flow. This document provides DetNet flow 20 information model both for Layer 3 and Layer 2 flows in an integrated 21 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 http://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 January 1, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 62 4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 5 63 5. End System and DetNet domain . . . . . . . . . . . . . . . . 5 64 6. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Identification and Specification of Flows . . . . . . . . 7 66 6.1.1. DetNet L3 Flow Identification and Specification at 67 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1.2. DetNet L2 Flow Identification and Specification at 69 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.1.3. DetNetwork Flow Identification and Specification . . 8 71 6.2. Traffic Specification . . . . . . . . . . . . . . . . . . 9 72 6.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. Common Attributes of Source and Destination . . . . . . . . . 12 76 9.1. End System Interfaces . . . . . . . . . . . . . . . . . . 12 77 9.2. Interface Capabilities . . . . . . . . . . . . . . . . . 12 78 9.3. User to Network Requirements . . . . . . . . . . . . . . 13 79 10. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 14 80 10.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 14 81 11. Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 11.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 16 83 11.2. Interface Configuration . . . . . . . . . . . . . . . . 17 84 11.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 17 85 12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 15.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 A Deterministic Networking (DetNet) service provides a capability to 96 carry a unicast or a multicast data flow for an application with 97 constrained requirements on network performance, e.g., low packet 98 loss rate and/or latency. The DetNet service is provided either for 99 a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network, 100 see, e.g., [I-D.ietf-detnet-dp-alt]. Similarly, Time-Sensitive 101 Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged 102 network. DetNet and TSN have common architecture as expressed in 103 [IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can 104 be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and 105 DetNet L2 flows. Therefore, the DetNet flow information model 106 provided by this document covers both DetNet L3 flows and DetNet L2 107 flows in an integrated fashion. Thus, the DetNet flow information 108 model is based on [I-D.ietf-detnet-architecture] and on the data 109 model specified by [IEEE8021Qcc]. Furthermore, the DetNet flow 110 information model relies on the flow identification possibilities 111 described in [IEEE8021CB], which is used by [IEEE8021Qcc] as well. 112 In addition to TSN data model, [IEEE8021Qcc] also specifies 113 configuration of TSN features (e.g., traffic scheduling specified by 114 [IEEE8021Qbv]). Due to the common architecture and flow model, 115 configuration features can be leveraged in certain deployment 116 scenarios, e.g., when the network that provides the DetNet service 117 includes both L3 and L2 network segments. 119 Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see 120 Section 4), this document (this revision) only considers the 121 Centralized Network / Distributed User Model out of the models 122 specified by [IEEE8021Qcc]. That is, there is a User-Network 123 Interface (UNI) between an end system and a network. Furthermore, 124 there is a central entity for the control of the network. For 125 instance, the central entity implements a Path Computation Element 126 (PCE) for the calculation and establishment of paths needed for 127 packet replication and elimination, if any. 129 [[NOTE (to be removed from a future revision): The Goals and Non 130 goals subsections are only for initial revisions, they are to be 131 removed from future revisions of this draft.]] 133 1.1. Goals 135 As it is expressed in the Charter [IETFDetNet], the DetNet WG 136 collaborates with IEEE 802.1 TSN in order to define a common 137 architecture for both Layer 2 and Layer 3, which is beneficial for 138 various reasons, e.g., in order to simplify implementations. The 139 flow information model should be also common along those lines. As 140 the TSN flow information/data model specified by [IEEE8021Qcc] is 141 mature, the DetNet flow information model described in this document 142 is based on [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. 144 The Centralized Network / Distributed User Model of [IEEE8021Qcc] is 145 used in this revision as a start of the work. Further models can be 146 also useful for DetNet, e.g., the Fully Centralized Model for the 147 Industrial M2M use case [I-D.ietf-detnet-use-cases]. 149 This document intends to specify flow information model only. 151 1.2. Non Goals 153 This document (this revision) does not intend to specify either flow 154 data model or DetNet configuration. From these aspects, the goals of 155 this document differ from the goals of [IEEE8021Qcc], which also 156 specifies data model and configuration of certain TSN features. 158 2. Conventions Used in This Document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 The lowercase forms with an initial capital "Must", "Must Not", 165 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 166 in this document are to be interpreted in the sense defined in 167 [RFC2119], but are used where the normative behavior is defined in 168 documents published by SDOs other than the IETF. 170 3. Terminology and Definitions 172 This document uses the terminology established in Section 2 of the 173 DetNet architecture document [I-D.ietf-detnet-architecture]. The 174 DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used 175 to perform translation from [IEEE8021Qcc] to this document. 176 Additional terms used in this document: 178 DetNet L3 Flow: Layer 3 (L3) flow leveraging DetNet service. 180 DetNet L2 Flow: Layer 2 (L2) flow leveraging DetNet service. 182 DetNetwork Flow: DetNet data plane specific encapsulated format of a 183 DetNet L2 or L3 flow leveraging DetNet service. 185 4. Naming Conventions 187 The following naming conventions were used for naming information 188 model components in this document. It is recommended that extensions 189 of the model use the same conventions. 191 o Names SHOULD be descriptive. 193 o Names MUST start with uppercase letters. 195 o Composed names MUST use capital letters for the first letter of 196 each component. All other letters are lowercase, even for 197 acronyms. Exceptions are made for acronyms containing a mixture 198 of lowercase and capital letters, such as IPv6. Examples are 199 SourceMacAddress and DestinationIPv6Address. 201 5. End System and DetNet domain 203 Deterministic service is required by time/loss sensitive 204 application(s) running on an end system during communication with its 205 peer(s). Such a data exchange has various requirements on delay and/ 206 or loss parameters. 208 The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes 209 two kinds of end systems: Source and Destination. The same 210 distinction is applied for the DetNet flow information model. In 211 addition to the end systems interested in a flow, the status 212 information of the flow is also important. Therefore, the DetNet 213 flow information model relies on four high level groups: 215 o Source: an end system capable of sourcing a DetNet flow. The 216 Source information group includes elements that specify the Source 217 for a single flow. This information group is applied from the 218 user to the network. 220 o Destination: an end system that is a destination of a DetNet flow. 221 The Destination information group includes elements that specify 222 the Destination for a single flow. This information group is 223 applied from the user to the network. 225 o DetNet Domain: a network providing the DetNet service. The DetNet 226 domain information group includes elements that specify the 227 forwarding method for a single flow. This information group is 228 applied within the network. 230 o Status: the status of a DetNet flow. The status information group 231 includes elements that specify the status of the flow in the 232 network. This information group is applied from the network to 233 the user. This information group informs the user whether or not 234 the flow is ready for use. 236 There are two operations for each flow with respect to a Source or a 237 Destination: 239 o Join: Source/Destination request to join the flow. 241 o Leave: Source/Destination request to leave the flow. 243 [[NOTE (to be removed from a future revision): Adding Modify 244 operation can be considered to address cases when a flow is slightly 245 changed, e.g., only MaxPayloadSize (Section 6.2) has been changed. 246 The advantage of having a Modify is that it allows to initiate a 247 change of flow spec while leaving the current flow is operating until 248 the change is accepted. If there is no linkage between the Join and 249 the Leave, then in figuring out whether the new flow spec can be 250 supported, the central entity has to assume that the resources 251 committed to the current flow are in use. If it is a Modify the 252 central entity knows that the resources supporting the current flow 253 can be available for supporting the altered flow. Modify is 254 considered to be an optional operation due to possible control-plane 255 limitations. ]] 257 As the DetNet UNI can provide service for both L3 and L2 flows, end 258 systems may not need to implement the L3 <=> L2 Transfer Function 259 specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also 260 subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a 261 function similar to the Transfer Function, see, e.g., the Svc Proxy 262 in Figure 1 in [I-D.ietf-detnet-dp-alt]. 264 6. Flow 266 The flows leveraging DetNet service can be unicast or multicast data 267 flows for an application with constrained requirements on network 268 performance, e.g., low packet loss rate and/or latency. Therefore, 269 they can require different connectivity types: point-to-point (p2p) 270 or point-to-multipoint (p2mp). The p2mp connectivity is created by a 271 transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt]. 272 (Note that mp2mp connectivity is a superposition of p2mp 273 connections.) 275 Many flows using DetNet service are periodic with fix packet size 276 (i.e., Constant Bit Rate (CBR) flows), or periodic with variable 277 packet size. 279 Delay and loss parameters are correlated because the effect of late 280 delivery can result data loss for an application. However, not all 281 applications require hard limits on both parameters (delay and loss). 282 For example, some real-time applications allow graceful degradation 283 if loss happens (e.g., sample-based processing, media distribution). 284 Some others may require high-bandwidth connections that make the 285 usage of techniques like packet replication economically challenging 286 or even impossible. Some applications may not tolerate loss, but are 287 not delay sensitive (e.g., bufferless sensors). Time/loss sensitive 288 applications may have somewhat special requirements especially for 289 loss (e.g., no loss in two consecutive communication cycles; very low 290 outage time, etc.). 292 Flows have the following attributes: 294 a. DataFlowSpecification (Section 6.1) 296 b. TrafficSpecification (Section 6.2) 298 c. FlowRank (Section 6.3) 300 Flow attributes are described in the following sections. 302 6.1. Identification and Specification of Flows 304 Identification options for DetNet flows at the UNI and within the 305 DetNet domain are specified as follows; see Section 6.1.1 for DetNet 306 L3 flows (at UNI), Section 6.1.2 for DetNet L2 flows (at UNI) and 307 Section 6.1.3 for DetNetwork flows (within the network). 309 6.1.1. DetNet L3 Flow Identification and Specification at UNI 311 DetNet L3 flows can be identified and specified by the following 312 attributes: 314 a. SourceIpAddress 316 b. DestinationIpAddress 318 c. IPv6FlowLabel 320 d. Dscp 322 e. Protocol 324 f. SourcePort 326 g. DestinationPort 328 6.1.2. DetNet L2 Flow Identification and Specification at UNI 330 DetNet L2 flows can be identified and specified by the following 331 attributes: 333 a. DestinationMacAddress 335 b. SourceMacAddress 337 c. Pcp 339 d. VlanId 341 e. EtherType 343 [[NOTE (to be removed from a future revision): The Multiple Stream 344 Registration Protocol (MSRP) [IEEE8021Q] uses StreamID to match 345 Talker registrations with their corresponding Listener registrations, 346 i.e., to identify Streams (L2 TSN flows). The StreamID includes the 347 following subcomponents: 349 o A 48-bit MAC Address associated with the Talker sourcing the 350 stream to the bridged network. 352 o A 16-bit unsigned integer value, Unique ID, used to distinguish 353 among multiple streams sourced by the same Talker. 355 ]] 357 6.1.3. DetNetwork Flow Identification and Specification 359 DetNetwork flows can be identified and specified by the following 360 attributes: 362 a. SourceIpAddress 364 b. DestinationIpAddress 366 c. IPv6FlowLabel 368 d. MplsLabel 370 [[NOTE (to be removed from a future revision): Attributes are based 371 on latest data plane solution.]] 373 6.2. Traffic Specification 375 TrafficSpecification specifies how the Source transmits packets for 376 the flow. This is effectively the promise/request of the Source to 377 the network. The network uses this traffic specification to allocate 378 resources and adjust queue parameters in network nodes. 380 TrafficSpecification has the following attributes: 382 a. Interval: the period of time in which the traffic specification 383 cannot be exceeded. 385 b. MaxPacketsPerInterval: the maximum number of packets that the 386 Source will transmit in one Interval. 388 c. MaxPayloadSize: the maximum payload size that the Source will 389 transmit. 391 [[NOTE (to be removed from a future revision): These attributes can 392 be used to describe any type of traffic (e.g., CBR, VBR, etc.) and 393 can be used during resource allocation to represent worst case 394 scenarios. Further optional attributes can be considered to achieve 395 more efficient resource allocation. Such optional attributes might 396 be worth for flows with soft requirements (i.e., the flow is only 397 loss sensitive or only delay sensitive, but not both delay-and-loss 398 sensitive). Possible options how to extend TrafficSpecification 399 attributes is for further discussion. Identified options are 400 described in the following notes.]] 402 [[NOTE1: Based on the already defined attributes the most similar 403 additional attributes for VBR type flows can be defined as follows: 405 o AveragePacketsPerInterval: the average number of packets that the 406 Source will transmit in one Interval. 408 o AveragePayloadSize: the average payload size that the Source will 409 transmit. 411 ]] 413 [[NOTE2: another alternative to deal better with various traffic 414 types can rely on [RFC6003], which describes the support of Metro 415 Ethernet Forum (MEF) Ethernet traffic parameters for using for 416 resource reservation purposes. Such a Bandwidth Profile can be also 417 adapted to describe the set of traffic parameters for a Detnet flow. 418 Committed Rate indicates the rate at which traffic commits to be sent 419 by the source (described in terms of the CIR (Committed Information 420 Rate) and CBS (Committed Burst Size) attributes.) Excess Rate 421 indicates the extent by which the traffic sent by the source exceeds 422 the committed rate. The Excess Rate is described in terms of the EIR 423 (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]] 425 [[NOTE3: a third alternative is to define application based traffic 426 models such as [GPP22885] defines periodic and event-driven traffic 427 model, and 5G PPP work defines traffic model for MTC (Machine Type 428 Communication) use cases. Periodic traffic type is usually for 429 status update between devices or devices transmit status report to a 430 central unit in regular basis. TrafficPeriod, defines the period of 431 the status update message. DataSize, defines the data size of the 432 massage which is constant. 3GPP also defines approximately-periodic 433 transmission with variations on period and uncertainty in the time 434 arrival of the packets. Event-triggered traffic type corresponds 435 traffic being triggered by an MTC device event. 436 MinIntervalBetweenEvent, defines the minimum interval between two 437 events. Event-triggered transmission will not happen all the time, 438 whenever an alert is sent, it waits until the issue being solved to 439 be able to send another alert. MaxPacketPerEvent, defines the max 440 number of packets within one message. ]] 442 6.3. Flow Rank 444 FlowRank provides the rank of this flow relative to others flows in 445 the network. This rank is used to determine success/failure of flow 446 establishment. Rank (boolean) is used by the network to decide which 447 flows can and cannot exist when network resources reach their limit. 448 Rank is used to help to determine which flows can be dropped (i.e., 449 removed from node configuration) if a port of a node becomes 450 oversubscribed (e.g., due to network reconfiguration). The true 451 value is more important than the false value (i.e., flows with false 452 are dropped first). 454 [[NOTE (to be removed from a future revision): FlowRank specified by 455 [IEEE8021Qcc] is according to L2 logic, where lower values are 456 preferred.]] 458 7. Source 460 The Source object specifies: 462 o The behavior of the Source for the flow (how/when the Source 463 transmits). 465 o The requirements of the Source from the network. 467 o The capabilities of the interface(s) of the Source. 469 The Source object includes the following attributes: 471 a. DataFlowSpecification (Section 6.1) 473 b. TrafficSpecification (Section 6.2) 475 c. FlowRank (Section 6.3) 477 d. EndSystemInterfaces (Section 9.1) 479 e. InterfaceCapabilities (Section 9.2) 481 f. UserToNetworkRequirements (Section 9.3) 483 For the join operation, the DataFlowSpecification, FlowRank, 484 EndSystemInterfaces, and TrafficSpecification SHALL be included 485 within the Source. For the join operation, the 486 UserToNetworkRequirements and InterfaceCapabilities groups MAY be 487 included within the Source. 489 For the leave operation, the DataFlowSpecification and 490 EndSystemInterfaces SHALL be included within the Source. 492 8. Destination 494 The Destination object includes the following attributes: 496 a. DataFlowSpecification (Section 6.1) 498 b. EndSystemInterfaces (Section 9.1) 500 c. InterfaceCapabilities (Section 9.2) 502 d. UserToNetworkRequirements (Section 9.3) 504 For the join operation, the DataFlowSpecification and 505 EndSystemInterfaces SHALL be included within the Destination. For 506 the join operation, the UserToNetworkRequirements and 507 InterfaceCapabilities groups MAY be included within the Destination. 509 For the leave operation, the DataFlowSpecification and 510 EndSystemInterfaces SHALL be included within the Destination. 512 [[NOTE (to be removed from a future revision): Should we add 513 DestinationRank? It could distinguish the importance of Destinations 514 if the flow cannot be provided for all Destinations.]] 516 9. Common Attributes of Source and Destination 518 Source and Destination end systems have the following common 519 attributes in addition to DataFlowSpecification (Section 6.1). 521 9.1. End System Interfaces 523 EndSystemInterfaces is a list of identifiers, one for each physical 524 interface (port) in the end system acting as a Source or Destination. 525 An interface is identified by an IP or a MAC address. 527 EndSystemInterfaces can refer also to logical sub-Interfaces if 528 supported by the end system, e.g., based on IfIndex parameter. 530 9.2. Interface Capabilities 532 InterfaceCapabilities specifies the network capabilities of all 533 interfaces (ports) contained in the EndSystemInterfaces object 534 (Section 9.1). These capabilities may be configured via the 535 InterfaceConfiguration object (Section 11.2) of the Status object 536 (Section 11). 538 Note that an end system may have multiple interfaces with different 539 network capabilities. In this case, each interface should be 540 specified in a distinct top-level Source or Destination object (i.e., 541 one entry in EndSystemInterfaces (Section 9.1)). Use of multiple 542 entries in EndSystemInterfaces is intended for network capabilities 543 that span multiple interfaces (e.g., packet replication and 544 elimination).";. 546 InterfaceCapabilities attributes: 548 a. SubInterfaceCapable (sub-interface capable) 550 b. PREF-Capable (packet replication and elimination capable) 552 [[NOTE (to be removed from a future revision): InterfaceCapabilities 553 attributes are to be defined. For information, [IEEE8021Qcc] 554 specifies the following attributes: 556 o VlanTagCapable (Customer VLAN Tag capable) 558 o CB-Capable (frame replication and elimination capable) 560 o CB-StreamIdenTypeList (a list of the optional Stream 561 Identification types supported by the interface as specified in 562 [IEEE8021CB].) 564 o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode 565 types supported by the interface as specified in [IEEE8021CB].) 567 ]] 569 9.3. User to Network Requirements 571 UserToNetworkRequirements specifies user requirements for the flow, 572 such as latency and reliability. 574 The UserToNetworkRequirements object includes the following 575 attributes: 577 a. NumReplicationTrees 579 b. MaxLatency 581 NumReplicationTrees specifies the number of maximally disjoint trees 582 that the network should configure to provide packet replication and 583 elimination for the flow. NumReplicationTrees is provided by the 584 Source only. Destinations SHALL set this element to one. Value zero 585 and one indicate no packet replication and elimination for the flow. 586 When NumReplicationTrees is greater than one, packet replication and 587 elimination is to be used for the flow. If the Source sets this 588 element to greater than one, and packet replication and elimination 589 is not possible in the network (e.g., no disjoint paths, or the nodes 590 do not support packet replication and elimination), then the 591 FailureCode of the Status object is non-zero (Section 11.1). 593 MaxLatency is the maximum latency from Source to Destination(s) for a 594 single packet of the flow. MaxLatency is specified as an integer 595 number of nanoseconds. When this requirement is specified by the 596 Source, it must be satisfied for all Destinations. When this 597 requirement is specified by a Destination, it must be satisfied for 598 that particular Destination only. If the UserToNetworkRequirements 599 group is not provided within the Source or Destination object, then 600 value zero SHALL be used for this element. Value zero represents a 601 special use for the maximum latency requirement. Value zero locks- 602 down the initial latency that the network provides in the 603 AccumulatedLatency parameter of the Status object (Section 11) after 604 the successful configuration of the flow, such that any subsequent 605 increase in the latency beyond that initial value causes the flow to 606 fail. 608 [[NOTE-1 (to be removed from a future revision): Should we add a 609 parameter to specify the maximum packet loss rate that can be 610 tolerated for the flow?]] 612 [[NOTE-2 (to be removed from a future revision): TrafficSpecification 613 (Section 6.2) specifies the Peak Information Rate (PIR) of the flow, 614 which is a kind of user requirement to the network. Should we add 615 Committed Information Rate (CIR), i.e., the minimum rate the user 616 requests to be guaranteed for the flow by the network?]] 618 10. DetNet Domain 620 The DetNet Domain may change the encapsulation of a DetNet L2 or L3 621 flow at the UNI. That impacts not only how a flow can be recognised 622 inside the DetNet domain but also the resource reservation 623 calculations. 625 The DetNet Domain object specifies: 627 o The behavior of the flow (how/when it is transmited). 629 o The requirements of the flow from the network. 631 o The capabilities of the DetNet domain. 633 The DetNet domain object includes the following attributes: 635 a. DataFlowSpecification (Section 6.1) 637 b. TrafficSpecification (Section 6.2) 639 c. FlowRank (Section 6.3) 641 d. DetnetDomainCapabilities (Section 10.1) 643 e. UserToNetworkRequirements (Section 9.3) 645 10.1. DetNet Domain Capabilities 647 DetnetDomainCapabilities specifies the network capabilities, which 648 can be used to provide DetNet service. DetNet Edge nodes may change 649 the encapsulation of a flow according to the data plane used inside 650 the DetNet domain. 652 DetnetDomainCapabilities object includes the following attributes: 654 a. EncapsulationFormat (data plane specific encapsulation) 656 b. PREF-Capable (packet replication and elimination capable) 658 11. Status 660 The Status object is provided by the network each Source and 661 Destination of the flow. The Status object provides the status of 662 the flow with respect to the establishment of the flow by the 663 network. The Status object is delivered via the corresponding UNI to 664 each Source and Destination end system of the flow. The Status is 665 distinct for each Source or Destination because the 666 AccumulatedLatency and InterfaceConfiguration objects are distinct, 667 see below. 669 The Status object SHALL include the attributes a), b), c); and MAY 670 include attributes d), e): 672 a. DataFlowSpecification (Section 6.1) 674 b. StatusInfo (Section 11.1) 676 c. AccumulatedLatency (this section below) 678 d. InterfaceConfiguration (Section 11.2) 680 e. FailedInterfaces (Section 11.3) 682 DataFlowSpecification identifies the flow for which status is 683 provided. DataFlowSpecification is described in (Section 6.1) If the 684 Status object is provided without a Source or Destination object in a 685 protocol message via a UNI, then the DataFlowSpecification object 686 SHALL be included within the Status object for both join and leave 687 operations. If the Status object immediately follows a Source or 688 Destination object in the protocol message, then the 689 DataFlowSpecification object is obtained from the Source/Destination 690 object, and therefore DataFlowSpecification is not required within 691 the Status object. 693 AccumulatedLatency provides the worst-case latency that a single 694 packet of the flow can encounter along its current path(s) in the 695 network. When provided to a Source, AccumulatedLatency is the worst- 696 case latency for all Destinations (worst path). AccumulatedLatency 697 is specified as an integer number of nanoseconds. Latency is 698 measured using the time at which the data frame's message timestamp 699 point passes the reference plane marking the boundary between the 700 network media and PHY. The message timestamp point is specified by 701 IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful 702 Status, the network returns a value less than or equal to the 703 MaxLatency of the UserToNetworkRequirements (Section 9.3). If the 704 NumReplicationTrees of the UserToNetworkRequirements (Section 9.3) is 705 one, then the AccumlatedLatency SHALL provide the worst latency for 706 the current path from the Source to each Destination. If the path is 707 changed (e.g., due to rerouting), then the AccumulatedLatency changes 708 accordingly. If the NumReplicationTrees of the 709 UserToNetworkRequirements (Section 9.3) is greater than one, 710 AccumlatedLatency SHALL provide the worst latency for all paths in 711 use from the Source to each Destination. 713 11.1. Status Info 715 StatusInfo provides information regarding the status of a flow's 716 configuration in the network. 718 The StatusInfo object MAY include the following attributes: 720 a. SourceStatus is an enumeration for the status of the flow's 721 Source: 723 * None: no Source 725 * Ready: Source is ready 727 * Failed: Source failed 729 b. DestinationStatus is an enumeration for the status of the flow's 730 Destinations: 732 * None: no Destination 734 * Ready: all Destinations are ready 736 * PartialFailed: One or more Destinations ready, and one or more 737 Listeners failed. The flow can be used tf the Source is 738 Ready. 740 * Failed: All Destinations failed. 742 c. FailureCode: A non-zero code that specifies the problem if the 743 flow encounters a failure (e.g., packet replication and 744 elimination is requested but not possible, or SourceStatus is 745 Failed, or DestinationStatus is Failed, or DestinationStatus is 746 PartialFailed). 748 [[NOTE (to be removed from a future revision): FailureCodes to be 749 defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 750 failure codes.]] 752 11.2. Interface Configuration 754 InterfaceConfiguration provides configuration of interfaces in the 755 Source/Destination. This configuration assists the network in 756 meeting the requirements of the flow. The InterfaceConfiguration 757 object is according to the capabilities of the interface. 758 InterfaceConfiguration can be distinct for each Source or Destination 759 of each flow. If the InterfaceConfiguration object is not provided 760 within the Status object, then the network SHALL assume zero elements 761 as the default (no interface configuration). 763 The InterfaceConfiguration object MAY include one or more the 764 following attributes: 766 a. MAC or IP Address to identify the interface 768 b. DataFlowSpecification (Section 6.1) 770 11.3. Failed Interfaces 772 FailedInterfaces provides a list of one or more physical interfaces 773 (ports) in the failed node when a failure occurs in network 774 configuration. 776 The InterfaceConfiguration object includes the following attributes: 778 a. MAC or IP Address to identify the interface 780 b. InterfaceName 782 InterfaceName is the name of the interface (port) within the node. 783 This interface name SHALL be persistent, and unique within the node. 785 12. Summary 787 This document describes DetNet flow information model both for DetNet 788 L3 flows and DetNet L2 flows based on the TSN data model specified by 789 [IEEE8021Qcc]. This revision is extended with DetNet specific flow 790 information model elements. 792 13. IANA Considerations 794 N/A. 796 14. Security Considerations 798 N/A. 800 15. References 802 15.1. Normative References 804 [I-D.ietf-detnet-architecture] 805 Finn, N. and P. Thubert, "Deterministic Networking 806 Architecture", draft-ietf-detnet-architecture-00 (work in 807 progress), September 2016. 809 [I-D.ietf-detnet-dp-alt] 810 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 811 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 812 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 813 (work in progress), October 2016. 815 [I-D.ietf-detnet-use-cases] 816 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 817 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 818 Varga, B., Farkas, J., Goetz, F., and J. Schmitt, 819 "Deterministic Networking Use Cases", draft-ietf-detnet- 820 use-cases-01 (work in progress), February 2016. 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, 824 DOI 10.17487/RFC2119, March 1997, 825 . 827 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 828 RFC 6003, DOI 10.17487/RFC6003, October 2010, 829 . 831 15.2. Informative References 833 [GPP22885] 834 3GPP, "Study on LTE support for Vehicle-to-Everything 835 (V2X) services", 836 . 838 [IEEE8021AS] 839 IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local 840 and metropolitan area networks - Timing and 841 Synchronization for Time-Sensitive Applications in Bridged 842 Local Area Networks", 2011, 843 . 846 [IEEE8021CB] 847 IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local 848 and metropolitan area networks - Frame Replication and 849 Elimination for Reliability", 2017, 850 . 852 [IEEE8021Q] 853 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 854 metropolitan area networks - Bridges and Bridged 855 Networks", 2014, . 858 [IEEE8021Qbv] 859 IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local 860 and metropolitan area networks - Bridges and Bridged 861 Networks -- Amendment 25: Enhancements for Scheduled 862 Traffic", 2015, . 865 [IEEE8021Qcc] 866 IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for 867 Local and metropolitan area networks - Bridges and Bridged 868 Networks -- Amendment: Stream Reservation Protocol (SRP) 869 Enhancements and Performance Improvements", 2017, 870 . 872 [IEEE8021TSN] 873 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 874 Task Group", . 876 [IETFDetNet] 877 IETF, "IETF Deterministic Networking (DetNet) Working 878 Group", . 880 Authors' Addresses 881 Janos Farkas 882 Ericsson 883 Konyves Kalman krt. 11/B 884 Budapest 1097 885 Hungary 887 Email: janos.farkas@ericsson.com 889 Balazs Varga 890 Ericsson 891 Konyves Kalman krt. 11/B 892 Budapest 1097 893 Hungary 895 Email: balazs.a.varga@ericsson.com 897 Rodney Cummings 898 National Instruments 899 11500 N. Mopac Expwy 900 Bldg. C 901 Austin, TX 78759-3504 902 USA 904 Email: rodney.cummings@ni.com 906 Jiang Yuanlong 907 Huawei 909 Email: jiangyuanlong@huawei.com 911 Zha Yiyong 912 Huawei 914 Email: zhayiyong@huawei.com