idnits 2.17.1 draft-farkas-detnet-flow-information-model-00.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 12, 2017) is 2601 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: September 13, 2017 R. Cummings 6 National Instruments 7 March 12, 2017 9 DetNet Flow Information Model Based on TSN 10 draft-farkas-detnet-flow-information-model-00 12 Abstract 14 This document describes flow information model for Deterministic 15 Networking (DetNet). The DetNet service is provided either for a 16 Layer 3 or a Layer 2 flow. This document provides DetNet flow 17 information model both for Layer 3 and Layer 2 flows in an integrated 18 fashion. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 13, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 59 4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 4 60 5. End System . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Identification and Specification of Flows . . . . . . . . 6 63 6.1.1. DetNet L3 Flow Identification and Specification . . . 7 64 6.1.2. DetNet L2 Flow Identification and Specification . . . 7 65 6.2. Traffic Specification . . . . . . . . . . . . . . . . . . 8 66 6.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. Common Attributes of Source and Destination . . . . . . . . . 10 70 9.1. End System Interfaces . . . . . . . . . . . . . . . . . . 10 71 9.2. Interface Capabilities . . . . . . . . . . . . . . . . . 10 72 9.3. User to Network Requirements . . . . . . . . . . . . . . 11 73 10. Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 10.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 13 75 10.2. Interface Configuration . . . . . . . . . . . . . . . . 14 76 10.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 14 77 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 14.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 A Deterministic Networking (DetNet) service provides a capability to 88 carry a unicast or a multicast data flow for an application with 89 constrained requirements on network performance, e.g., low packet 90 loss rate and/or latency. The DetNet service is provided either for 91 a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network, 92 see, e.g., [I-D.ietf-detnet-dp-alt]. Similarly, Time-Sensitive 93 Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged 94 network. DetNet and TSN have common architecture as expressed in 95 [IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can 96 be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and 97 DetNet L2 flows. Therefore, the DetNet flow information model 98 provided by this document covers both DetNet L3 flows and DetNet L2 99 flows in an integrated fashion. Thus, the DetNet flow information 100 model is based on [I-D.ietf-detnet-architecture] and on the data 101 model specified by [IEEE8021Qcc]. Furthermore, the DetNet flow 102 information model relies on the flow identification possibilities 103 described in [IEEE8021CB], which is used by [IEEE8021Qcc] as well. 104 In addition to TSN data model, [IEEE8021Qcc] also specifies 105 configuration of TSN features (e.g., traffic scheduling specified by 106 [IEEE8021Qbv]). Due to the common architecture and flow model, 107 configuration features can be leveraged in certain deployment 108 scenarios, e.g., when the network that provides the DetNet service 109 includes both L3 and L2 network segments. 111 Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see 112 Section 4), this document (this revision) only considers the 113 Centralized Network / Distributed User Model out of the models 114 specified by [IEEE8021Qcc]. That is, there is a User-Network 115 Interface (UNI) between an end system and a network. Furthermore, 116 there is a central entity for the control of the network. For 117 instance, the central entity implements a Path Computation Element 118 (PCE) for the calculation and establishment of paths needed for 119 packet replication and elimination, if any. 121 [[NOTE (to be removed from a future revision): The Goals and Non 122 goals subsections are only for revision 00, they are to be removed 123 from future revisions of this draft.]] 125 1.1. Goals 127 As it is expressed in the Charter [IETFDetNet], the DetNet WG 128 collaborates with IEEE 802.1 TSN in order to define a common 129 architecture for both Layer 2 and Layer 3, which is beneficial for 130 various reasons, e.g., in order to simplify implementations. The 131 flow information model should be also common along those lines. As 132 the TSN flow information/data model specified by [IEEE8021Qcc] is 133 mature, the DetNet flow information model described in this document 134 is based on [IEEE8021Qcc], which is an amendment to [IEEE8021Q]. 136 The Centralized Network / Distributed User Model of [IEEE8021Qcc] is 137 used in this revision as a start of the work. Further models can be 138 also useful for DetNet, e.g., the Fully Centralized Model for the 139 Industrial M2M use case [I-D.ietf-detnet-use-cases]. 141 This document intends to specify flow information model only. 143 Revision 00 is just a start; it is not complete. As this revision 144 heavily relies on [IEEE8021Qcc], the need for further DetNet specific 145 aspects is to be reviewed and missing pieces are to be added. 147 1.2. Non Goals 149 This document (this revision) does not intend to specify either flow 150 data model or DetNet configuration. From these aspects, the goals of 151 this document differ from the goals of [IEEE8021Qcc], which also 152 specifies data model and configuration of certain TSN features. 154 2. Conventions Used in This Document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 The lowercase forms with an initial capital "Must", "Must Not", 161 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 162 in this document are to be interpreted in the sense defined in 163 [RFC2119], but are used where the normative behavior is defined in 164 documents published by SDOs other than the IETF. 166 3. Terminology and Definitions 168 This document uses the terminology established in Section 2 of the 169 DetNet architecture document [I-D.ietf-detnet-architecture]. The 170 DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used 171 to perform translation from [IEEE8021Qcc] to this document. 172 Additional terms used in this document: 174 DetNet L3 Flow: Layer 3 (L3) flow leveraging DetNet service. 176 DetNet L2 Flow: Layer 2 (L2) flow leveraging DetNet service. 178 4. Naming Conventions 180 The following naming conventions were used for naming information 181 model components in this document. It is recommended that extensions 182 of the model use the same conventions. 184 o Names SHOULD be descriptive. 186 o Names MUST start with uppercase letters. 188 o Composed names MUST use capital letters for the first letter of 189 each component. All other letters are lowercase, even for 190 acronyms. Exceptions are made for acronyms containing a mixture 191 of lowercase and capital letters, such as IPv6. Examples are 192 SourceMacAddress and DestinationIPv6Address. 194 5. End System 196 Deterministic service is required by time/loss sensitive 197 application(s) running on an end system during communication with its 198 peer(s). Such a data exchange has various requirements on delay and/ 199 or loss parameters. 201 The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes 202 two kinds of end systems: Source and Destination. The same 203 distinction is applied for the DetNet flow information model. In 204 addition to the end systems interested in a flow, the status 205 information of the flow is also important. Therefore, the DetNet 206 flow information model relies on three high level groups: 208 o Source: an end system capable of sourcing a DetNet flow. The 209 Source information group includes elements that specify the Source 210 for a single flow. This information group is applied from the 211 user to the network. 213 o Destination: an end system that is a destination of a DetNet flow. 214 The Destination information group includes elements that specify 215 the Destination for a single flow. This information group is 216 applied from the user to the network. 218 o Status: the status of a DetNet flow. The status information group 219 includes elements that specify the status of the flow in the 220 network. This information group is applied from the network to 221 the user. This information group informs the user whether or not 222 the flow is ready for use. 224 There are two operations for each flow with respect to a Source or a 225 Destination: 227 o Join: Source/Destination request to join the flow. 229 o Leave: Source/Destination request to leave the flow. 231 [[NOTE (to be removed from a future revision): Adding Modify 232 operation can be considered to address cases when a flow is slightly 233 changed, e.g., only MaxPacketSize (Section 6.2) has been changed.]] 235 As the DetNet UNI can provide both L3 and L2 services, end systems 236 may not need to implement the L3 <=> L2 Transfer Function specified 237 by [IEEE8021CB] (see, e.g., subclause 6.3; see also subclause 46.1 in 238 [IEEE8021Qcc]). An edge node may implement a function similar to the 239 Transfer Function, see, e.g., the Svc Proxy in Figure 1 in 240 [I-D.ietf-detnet-dp-alt]. 242 6. Flow 244 The flows leveraging DetNet service can be unicast or multicast data 245 flows for an application with constrained requirements on network 246 performance, e.g., low packet loss rate and/or latency. Therefore, 247 they can require different connectivity types: point-to-point (p2p) 248 or point-to-multipoint (p2mp). The p2mp connectivity is created by a 249 transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt]. 250 (Note that mp2mp connectivity is a superposition of p2mp 251 connections.) 253 Many flows using DetNet service are periodic with fix packet size 254 (i.e., Constant Bit Rate (CBR) flows), or periodic with variable 255 packet size. 257 Delay and loss parameters are correlated because the effect of late 258 delivery can result data loss for an application. However, not all 259 applications require hard limits on both parameters (delay and loss). 260 For example, some real-time applications allow graceful degradation 261 if loss happens (e.g., sample-based processing, media distribution). 262 Some others may require high-bandwidth connections that make the 263 usage of techniques like packet replication economically challenging 264 or even impossible. Some applications may not tolerate loss, but are 265 not delay sensitive (e.g., bufferless sensors). Time/loss sensitive 266 applications may have somewhat special requirements especially for 267 loss (e.g., no loss in two consecutive communication cycles; very low 268 outage time, etc.). 270 Flows have the following attributes: 272 a. DataFlowSpecification (Section 6.1) 274 b. TrafficSpecification (Section 6.2) 276 c. FlowRank (Section 6.3) 278 Flow attributes are described in the following sections. 280 6.1. Identification and Specification of Flows 282 Identification options for TSN flows are specified by [IEEE8021CB], 283 which also includes IP flow identification, see, e.g., Table 6-1 in 284 Clause 6. Therefore, the flow identification specified by 285 [IEEE8021CB] is also applicable to DetNet flows. 287 [[NOTE (to be removed from a future revision): Extensions to the 288 options specified by [IEEE8021CB] can be discussed.]] 290 DataFlowSpecification specifies DetNet flows as follows; see 291 Section 6.1.1 for DetNet L3 flows and Section 6.1.2 for DetNet L2 292 flows. 294 6.1.1. DetNet L3 Flow Identification and Specification 296 DetNet L3 flows can be identified and specified by the following 297 attributes: 299 a. SourceIpAddress 301 b. DestinationIpAddress 303 c. Dscp 305 d. Protocol 307 e. SourcePort 309 f. DestinationPort 311 g. MplsLabel 313 6.1.2. DetNet L2 Flow Identification and Specification 315 DetNet L2 flows can be identified and specified by the following 316 attributes: 318 a. DestinationMacAddress 320 b. SourceMacAddress 322 c. Pcp 324 d. VlanId 326 [[NOTE (to be removed from a future revision): The Multiple Stream 327 Registration Protocol (MSRP) [IEEE8021Q] uses StreamID to match 328 Talker registrations with their corresponding Listener registrations, 329 i.e., to identify Streams (L2 TSN flows). The StreamID includes the 330 following subcomponents: 332 o A 48-bit MAC Address associated with the Talker sourcing the 333 stream to the bridged network. 335 o A 16-bit unsigned integer value, Unique ID, used to distinguish 336 among multiple streams sourced by the same Talker. 338 ]] 340 6.2. Traffic Specification 342 TrafficSpecification specifies how the Source transmits packets for 343 the flow. This is effectively the promise/request of the Source to 344 the network. The network uses this traffic specification to allocate 345 resources and adjust queue parameters in network nodes. 347 TrafficSpecification has the following attributes: 349 a. Interval: the period of time in which the traffic specification 350 cannot be exceeded. 352 b. MaxPacketsPerInterval: the maximum number of packets that the 353 Source will transmit in one Interval. 355 c. MaxPayloadSize: the maximum payload size that the Source will 356 transmit. 358 6.3. Flow Rank 360 FlowRank provides the rank of this flow relative to others flows in 361 the network. This rank is used to determine success/failure of flow 362 establishment. Rank (boolean) is used by the network to decide which 363 flows can and cannot exist when network resources reach their limit. 364 Rank is used to help to determine which flows can be dropped (i.e., 365 removed from node configuration) if a port of a node becomes 366 oversubscribed (e.g., due to network reconfiguration). The false 367 value is more important than the true value (i.e., flows with true 368 are dropped first). 370 7. Source 372 The Source object specifies: 374 o The behavior of the Source for the flow (how/when the Source 375 transmits). 377 o The requirements of the Source from the network. 379 o The capabilities of the interface(s) of the Source. 381 The Source object includes the following attributes: 383 a. DataFlowSpecification (Section 6.1) 385 b. TrafficSpecification (Section 6.2) 387 c. FlowRank (Section 6.3) 389 d. EndSystemInterfaces (Section 9.1) 391 e. InterfaceCapabilities (Section 9.2) 393 f. UserToNetworkRequirements (Section 9.3) 395 For the join operation, the DataFlowSpecification, FlowRank, 396 EndSystemInterfaces, and TrafficSpecification SHALL be included 397 within the Source. For the join operation, the 398 UserToNetworkRequirements and InterfaceCapabilities groups MAY be 399 included within the Source. 401 For the leave operation, the DataFlowSpecification and 402 EndSystemInterfaces SHALL be included within the Source. 404 8. Destination 406 The Destination object includes the following attributes: 408 a. DataFlowSpecification (Section 6.1) 410 b. EndSystemInterfaces (Section 9.1) 412 c. InterfaceCapabilities (Section 9.2) 414 d. UserToNetworkRequirements (Section 9.3) 416 For the join operation, the DataFlowSpecification and 417 EndSystemInterfaces SHALL be included within the Destination. For 418 the join operation, the UserToNetworkRequirements and 419 InterfaceCapabilities groups MAY be included within the Destination. 421 For the leave operation, the DataFlowSpecification and 422 EndSystemInterfaces SHALL be included within the Destination. 424 [[NOTE (to be removed from a future revision): Should we add 425 DestinationRank? It could distinguish the importance of Destinations 426 if the flow cannot be provided for all Destinations.]] 428 9. Common Attributes of Source and Destination 430 Source and Destination end systems have the following common 431 attributes in addition to DataFlowSpecification (Section 6.1). 433 9.1. End System Interfaces 435 EndSystemInterfaces is a list of identifiers, one for each physical 436 interface (port) in the end system acting as a Source or Destination. 437 An interface is identified by an IP or a MAC address. 439 [[NOTE (to be removed from a future revision): Sub-Interfaces to be 440 added, e.g., based on IfIndex.]] 442 9.2. Interface Capabilities 444 InterfaceCapabilities specifies the network capabilities of all 445 interfaces (ports) contained in the EndSystemInterfaces object 446 (Section 9.1). These capabilities may be configured via the 447 InterfaceConfiguration object (Section 10.2) of the Status object 448 (Section 10). 450 Note that an end system may have multiple interfaces with different 451 network capabilities. In this case, each interface should be 452 specified in a distinct top-level Source or Destination object (i.e., 453 one entry in EndSystemInterfaces (Section 9.1)). Use of multiple 454 entries in EndSystemInterfaces is intended for network capabilities 455 that span multiple interfaces (e.g., packet replication and 456 elimination).";. 458 [[NOTE (to be removed from a future revision): InterfaceCapabilities 459 attributes are to be defined. For information, [IEEE8021Qcc] 460 specifies the following attributes: 462 a. VlanTagCapable (Customer VLAN Tag capable) 464 b. CB-Capable (frame replication and elimination capable) 466 c. CB-StreamIdenTypeList (a list of the optional Stream 467 Identification types supported by the interface as specified in 468 [IEEE8021CB].) 470 d. CB-SequenceTypeList (a list of the optional Sequence Encode/ 471 Decode types supported by the interface as specified in 472 [IEEE8021CB].) 474 ]] 476 9.3. User to Network Requirements 478 UserToNetworkRequirements specifies user requirements for the flow, 479 such as latency and reliability. 481 The UserToNetworkRequirements object includes the following 482 attributes: 484 a. NumReplicationTrees 486 b. MaxLatency 488 NumReplicationTrees specifies the number of maximally disjoint trees 489 that the network should configure to provide packet replication and 490 elimination for the flow. NumReplicationTrees is provided by the 491 Source only. Destinations SHALL set this element to one. Value zero 492 and one indicate no packet replication and elimination for the flow. 493 When NumReplicationTrees is greater than one, packet replication and 494 elimination is to be used for the flow. If the Source sets this 495 element to greater than one, and packet replication and elimination 496 is not possible in the network (e.g., no disjoint paths, or the nodes 497 do not support packet replication and elimination), then the 498 FailureCode of the Status object is non-zero (Section 10.1). 500 MaxLatency is the maximum latency from Source to Destination(s) for a 501 single packet of the flow. MaxLatency is specified as an integer 502 number of nanoseconds. When this requirement is specified by the 503 Source, it must be satisfied for all Destinations. When this 504 requirement is specified by a Destination, it must be satisfied for 505 that particular Destination only. If the UserToNetworkRequirements 506 group is not provided within the Source or Destination object, then 507 value zero SHALL be used for this element. Value zero represents a 508 special use for the maximum latency requirement. Value zero locks- 509 down the initial latency that the network provides in the 510 AccumulatedLatency parameter of the Status object (Section 10) after 511 the successful configuration of the flow, such that any subsequent 512 increase in the latency beyond that initial value causes the flow to 513 fail. 515 [[NOTE-1 (to be removed from a future revision): Should we add a 516 parameter to specify the maximum packet loss rate that can be 517 tolerated for the flow?]] 519 [[NOTE-2 (to be removed from a future revision): TrafficSpecification 520 (Section 6.2) specifies the Peak Information Rate (PIR) of the flow, 521 which is a kind of user requirement to the network. Should we add 522 Committed Information Rate (CIR), i.e., the minimum rate the user 523 requests to be guaranteed for the flow by the network?]] 525 10. Status 527 The Status object is provided by the network each Source and 528 Destination of the flow. The Status object provides the status of 529 the flow with respect to the establishment of the flow by the 530 network. The Status object is delivered via the corresponding UNI to 531 each Source and Destination end system of the flow. The Status is 532 distinct for each Source or Destination because the 533 AccumulatedLatency and InterfaceConfiguration objects are distinct, 534 see below. 536 The Status object SHALL include the attributes a), b), c); and MAY 537 include attributes d), e): 539 a. DataFlowSpecification (Section 6.1) 541 b. StatusInfo (Section 10.1) 543 c. AccumulatedLatency (this section below) 545 d. InterfaceConfiguration (Section 10.2) 547 e. FailedInterfaces (Section 10.3) 549 DataFlowSpecification identifies the flow for which status is 550 provided. DataFlowSpecification is described in (Section 6.1) If the 551 Status object is provided without a Source or Destination object in a 552 protocol message via a UNI, then the DataFlowSpecification object 553 SHALL be included within the Status object for both join and leave 554 operations. If the Status object immediately follows a Source or 555 Destination object in the protocol message, then the 556 DataFlowSpecification object is obtained from the Source/Destination 557 object, and therefore DataFlowSpecification is not required within 558 the Status object. 560 AccumulatedLatency provides the worst-case latency that a single 561 packet of the flow can encounter along its current path(s) in the 562 network. When provided to a Source, AccumulatedLatency is the worst- 563 case latency for all Destinations (worst path). AccumulatedLatency 564 is specified as an integer number of nanoseconds. Latency is 565 measured using the time at which the data frame's message timestamp 566 point passes the reference plane marking the boundary between the 567 network media and PHY. The message timestamp point is specified by 568 IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful 569 Status, the network returns a value less than or equal to the 570 MaxLatency of the UserToNetworkRequirements (Section 9.3). If the 571 NumReplicationTrees of the UserToNetworkRequirements (Section 9.3) is 572 one, then the AccumlatedLatency SHALL provide the worst latency for 573 the current path from the Source to each Destination. If the path is 574 changed (e.g., due to rerouting), then the AccumulatedLatency changes 575 accordingly. If the NumReplicationTrees of the 576 UserToNetworkRequirements (Section 9.3) is greater than one, 577 AccumlatedLatency SHALL provide the worst latency for all paths in 578 use from the Source to each Destination. 580 10.1. Status Info 582 StatusInfo provides information regarding the status of a flow's 583 configuration in the network. 585 The StatusInfo object MAY include the following attributes: 587 a. SourceStatus is an enumeration for the status of the flow's 588 Source: 590 * None: no Source 592 * Ready: Source is ready 594 * Failed: Source failed 596 b. DestinationStatus is an enumeration for the status of the flow's 597 Destinations: 599 * None: no Destination 601 * Ready: all Destinations are ready 603 * PartialFailed: One or more Destinations ready, and one or more 604 Listeners failed. The flow can be used tf the Source is 605 Ready. 607 * Failed: All Destinations failed. 609 c. FailureCode: A non-zero code that specifies the problem if the 610 flow encounters a failure (e.g., packet replication and 611 elimination is requested but not possible, or SourceStatus is 612 Failed, or DestinationStatus is Failed, or DestinationStatus is 613 PartialFailed). 615 [[NOTE (to be removed from a future revision): FailureCodes to be 616 defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 617 failure codes.]] 619 10.2. Interface Configuration 621 InterfaceConfiguration provides configuration of interfaces in the 622 Source/Destination. This configuration assists the network in 623 meeting the requirements of the flow. The InterfaceConfiguration 624 object is according to the capabilities of the interface. 625 InterfaceConfiguration can be distinct for each Source or Destination 626 of each flow. If the InterfaceConfiguration object is not provided 627 within the Status object, then the network SHALL assume zero elements 628 as the default (no interface configuration). 630 The InterfaceConfiguration object MAY include one or more the 631 following attributes: 633 a. MAC or IP Address to identify the interface 635 b. DataFlowSpecification (Section 6.1) 637 10.3. Failed Interfaces 639 FailedInterfaces provides a list of one or more physical interfaces 640 (ports) in the failed node when a failure occurs in network 641 configuration (i.e., non-zero FailureCode in StatusInfo object 642 (Section 10.1)). 644 The InterfaceConfiguration object includes the following attributes: 646 a. MAC or IP Address to identify the interface 648 b. InterfaceName 650 InterfaceName is the name of the interface (port) within the node. 651 This interface name SHALL be persistent, and unique within the node. 653 11. Summary 655 This document describes DetNet flow information model both for DetNet 656 L3 flows and DetNet L2 flows based on the TSN data model specified by 657 [IEEE8021Qcc]. This revision of the document is just to start the 658 discussions; further work is needed. 660 12. IANA Considerations 662 N/A. 664 13. Security Considerations 666 N/A. 668 14. References 670 14.1. Normative References 672 [I-D.ietf-detnet-architecture] 673 Finn, N. and P. Thubert, "Deterministic Networking 674 Architecture", draft-ietf-detnet-architecture-00 (work in 675 progress), September 2016. 677 [I-D.ietf-detnet-dp-alt] 678 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 679 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 680 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 681 (work in progress), October 2016. 683 [I-D.ietf-detnet-use-cases] 684 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 685 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 686 Varga, B., Farkas, J., Goetz, F., and J. Schmitt, 687 "Deterministic Networking Use Cases", draft-ietf-detnet- 688 use-cases-01 (work in progress), February 2016. 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, 692 DOI 10.17487/RFC2119, March 1997, 693 . 695 14.2. Informative References 697 [IEEE8021AS] 698 IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local 699 and metropolitan area networks - Timing and 700 Synchronization for Time-Sensitive Applications in Bridged 701 Local Area Networks", 2011, 702 . 705 [IEEE8021CB] 706 IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local 707 and metropolitan area networks - Frame Replication and 708 Elimination for Reliability", 2017, 709 . 711 [IEEE8021Q] 712 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 713 metropolitan area networks - Bridges and Bridged 714 Networks", 2014, . 717 [IEEE8021Qbv] 718 IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local 719 and metropolitan area networks - Bridges and Bridged 720 Networks -- Amendment 25: Enhancements for Scheduled 721 Traffic", 2015, . 724 [IEEE8021Qcc] 725 IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for 726 Local and metropolitan area networks - Bridges and Bridged 727 Networks -- Amendment: Stream Reservation Protocol (SRP) 728 Enhancements and Performance Improvements", 2017, 729 . 731 [IEEE8021TSN] 732 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 733 Task Group", . 735 [IETFDetNet] 736 IETF, "IETF Deterministic Networking (DetNet) Working 737 Group", . 739 Authors' Addresses 741 Janos Farkas 742 Ericsson 743 Konyves Kalman krt. 11/B 744 Budapest 1097 745 Hungary 747 Email: janos.farkas@ericsson.com 749 Balazs Varga 750 Ericsson 751 Konyves Kalman krt. 11/B 752 Budapest 1097 753 Hungary 755 Email: balazs.a.varga@ericsson.com 756 Rodney Cummings 757 National Instruments 758 11500 N. Mopac Expwy 759 Bldg. C 760 Austin, TX 78759-3504 761 USA 763 Email: rodney.cummings@ni.com