idnits 2.17.1 draft-ietf-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 (January 08, 2018) is 2298 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 896, 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: July 12, 2018 R. Cummings 6 National Instruments 7 J. Yuanlong 8 Z. Yiyong 9 Huawei 10 January 08, 2018 12 DetNet Flow Information Model 13 draft-ietf-detnet-flow-information-model-00 15 Abstract 17 This document describes flow and service information model for 18 Deterministic Networking (DetNet). The DetNet service is provided 19 either for a Layer 3 or a Layer 2 flow. This document provides 20 DetNet flow and service information model both for Layer 3 and Layer 21 2 flows in an integrated fashion. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 12, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 61 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 62 4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 5 63 5. End System and DetNet domain . . . . . . . . . . . . . . . . 6 64 6. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Identification and Specification of Flows . . . . . . . . 8 66 6.1.1. DetNet L3 Flow Identification and Specification at 67 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1.2. DetNet L2 Flow Identification and Specification at 69 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1.3. DetNetwork Flow Identification and Specification . . 10 71 6.2. Traffic Specification . . . . . . . . . . . . . . . . . . 10 72 6.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9. Common Attributes of Source and Destination . . . . . . . . . 13 77 9.1. End System Interfaces . . . . . . . . . . . . . . . . . . 13 78 9.2. Interface Capabilities . . . . . . . . . . . . . . . . . 13 79 9.3. User to Network Requirements . . . . . . . . . . . . . . 14 80 10. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 11. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 12. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 15 83 12.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 16 84 13. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 13.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 17 86 13.2. Interface Configuration . . . . . . . . . . . . . . . . 18 87 13.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 19 88 14. Service-status . . . . . . . . . . . . . . . . . . . . . . . 19 89 15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 17. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 18.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 18.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 A Deterministic Networking (DetNet) service provides a capability to 100 carry a unicast or a multicast data flow for an application with 101 constrained requirements on network performance, e.g., low packet 102 loss rate and/or latency. The DetNet service is provided either for 103 a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network, 104 see, e.g., [I-D.ietf-detnet-dp-alt]. Similarly, Time-Sensitive 105 Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged 106 network. DetNet and TSN have common architecture as expressed in 107 [IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can 108 be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and 109 DetNet L2 flows. Therefore, the DetNet flow and service information 110 model provided by this document covers both DetNet L3 flows and 111 DetNet L2 flows in an integrated fashion. 113 In a given network scenario three information models can 114 distinguished: 116 o Flow models describe characteristics of data flows. These models 117 describe in detail all relevant aspects of a flow that are needed 118 to support the flow properly by the network between the source and 119 the destination(s). 121 o Service models describe characteristics of services being provided 122 for data flows over a network. These models can be treated as a 123 network operator independent information model. 125 o Configuration models describe in detail the settings required on 126 network nodes to serve a data flow properly. 128 Service and flow information models are used between the user and the 129 network operator. Configuration information models are used between 130 the management/control plane entity of the network and the network 131 nodes. They are shown in Figure 1. 133 User Network Operator 134 flow/service 135 /\ info model +---+ 136 / \ <---------------> | X | management/control 137 ---- +-+-+ plane entity 138 ^ 139 | configuration 140 | info model 141 +------------+ 142 v | | 143 +-+ | v Network 144 +-+ v +-+ nodes 145 +-+ +-+ 146 +-+ 148 Figure 1: Usage of Information models (flow, service and 149 configuration) 151 DetNet flow and service information model is based on 152 [I-D.ietf-detnet-architecture] and on the data model specified by 153 [IEEE8021Qcc]. Furthermore, the DetNet flow information model relies 154 on the flow identification possibilities described in [IEEE8021CB], 155 which is used by [IEEE8021Qcc] as well. In addition to TSN data 156 model, [IEEE8021Qcc] also specifies configuration of TSN features 157 (e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the 158 common architecture and flow model, configuration features can be 159 leveraged in certain deployment scenarios, e.g., when the network 160 that provides the DetNet service includes both L3 and L2 network 161 segments. 163 Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see 164 Section 4), this document (this revision) only considers the 165 Centralized Network / Distributed User Model out of the models 166 specified by [IEEE8021Qcc]. That is, there is a User-Network 167 Interface (UNI) between an end system and a network. Furthermore, 168 there is a central entity for the control of the network. For 169 instance, the central entity implements a Path Computation Element 170 (PCE) for the calculation and establishment of paths needed for 171 packet replication and elimination, if any. 173 1.1. Goals 175 As it is expressed in the Charter [IETFDetNet], the DetNet WG 176 collaborates with IEEE 802.1 TSN in order to define a common 177 architecture for both Layer 2 and Layer 3, which is beneficial for 178 various reasons, e.g., in order to simplify implementations. The 179 flow and service information models should be also common along those 180 lines. As the TSN flow information/data model specified by 182 [IEEE8021Qcc] is mature, the DetNet flow and service information 183 models described in this document are based on [IEEE8021Qcc], which 184 is an amendment to [IEEE8021Q]. 186 This document intends to specify flow and service information models 187 only. 189 1.2. Non Goals 191 This document (this revision) does not intend to specify either flow 192 data model or DetNet configuration. From these aspects, the goals of 193 this document differ from the goals of [IEEE8021Qcc], which also 194 specifies data model and configuration of certain TSN features. 196 2. Conventions Used in This Document 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [RFC2119]. 202 The lowercase forms with an initial capital "Must", "Must Not", 203 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 204 in this document are to be interpreted in the sense defined in 205 [RFC2119], but are used where the normative behavior is defined in 206 documents published by SDOs other than the IETF. 208 3. Terminology and Definitions 210 This document uses the terminology established in Section 2 of the 211 DetNet architecture document [I-D.ietf-detnet-architecture]. The 212 DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used 213 to perform translation from [IEEE8021Qcc] to this document. 214 Additional terms used in this document: 216 DetNet L3 Flow: Layer 3 (L3) flow leveraging DetNet service. 218 DetNet L2 Flow: Layer 2 (L2) flow leveraging DetNet service. 220 DetNetwork Flow: DetNet data plane specific encapsulated format of a 221 DetNet L2 or L3 flow leveraging DetNet service. 223 4. Naming Conventions 225 The following naming conventions were used for naming information 226 model components in this document. It is recommended that extensions 227 of the model use the same conventions. 229 o Names SHOULD be descriptive. 231 o Names MUST start with uppercase letters. 233 o Composed names MUST use capital letters for the first letter of 234 each component. All other letters are lowercase, even for 235 acronyms. Exceptions are made for acronyms containing a mixture 236 of lowercase and capital letters, such as IPv6. Examples are 237 SourceMacAddress and DestinationIPv6Address. 239 5. End System and DetNet domain 241 Deterministic service is required by time/loss sensitive 242 application(s) running on an end system during communication with its 243 peer(s). Such a data exchange has various requirements on delay and/ 244 or loss parameters. 246 The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes 247 two kinds of end systems: Source and Destination. The same 248 distinction is applied for the DetNet flow information model. In 249 addition to the end systems interested in a flow, the status 250 information of the flow is also important. Therefore, the DetNet 251 flow information model relies on three high level groups: 253 o Source: an end system capable of sourcing a DetNet flow. The 254 Source information group includes elements that specify the Source 255 for a single flow. This information group is applied from the 256 user to the network. 258 o Destination: an end system that is a destination of a DetNet flow. 259 The Destination information group includes elements that specify 260 the Destination for a single flow. This information group is 261 applied from the user to the network. 263 o Flow-Status: the status of a DetNet flow. The status information 264 group includes elements that specify the status of the flow in the 265 network. This information group is applied from the network to 266 the user. This information group informs the user whether or not 267 the flow is ready for use. 269 From service perspective two kinds of edge nodes can be 270 distinguished: Ingress and Egress. In addition the technology of the 271 DetNet domain and the status of the service are also important. 272 Therefore, the DetNet service information model relies on four high 273 level groups: 275 o Ingress: an edge system receiving a DetNet flow from a Source. 276 The Ingress information group includes elements that specify the 277 entry point for a single flow. This information group is applied 278 from the network to the user. 280 o Egress: an edge system sending traffic towards a Destination of a 281 DetNet flow. The Egress information group includes elements that 282 specify the egress point for a single flow. This information 283 group is applied from the network to the user. 285 o DetNet Domain: an administrative domain providing the DetNet 286 service. The DetNet domain information group includes elements 287 that specify the forwarding capabilities and methods for a single 288 flow. This information group is applied within the network. 290 o Service-Status: the status of a DetNet service. The status 291 information group includes elements that specify the status of the 292 service specific state of the network. This information group is 293 applied from the network to the user. This information group 294 informs the user whether or not the service is ready for use. 296 There are two operations for each flow with respect to a Source or a 297 Destination (and an Ingress or an Egress): 299 o Join: Source/Destination request to join the flow. 301 o Leave: Source/Destination request to leave the flow. 303 o Modify: Source/Destination request to change the flow. 305 Modify operation can be considered to address cases when a flow is 306 slightly changed, e.g., only MaxPayloadSize (Section 6.2) has been 307 changed. The advantage of having a Modify is that it allows to 308 initiate a change of flow spec while leaving the current flow is 309 operating until the change is accepted. If there is no linkage 310 between the Join and the Leave, then in figuring out whether the new 311 flow spec can be supported, the central entity has to assume that the 312 resources committed to the current flow are in use. Via Modify the 313 central entity knows that the resources supporting the current flow 314 can be available for supporting the altered flow. Modify is 315 considered to be an optional operation due to possible control-plane 316 limitations. 318 As the DetNet UNI can provide service for both L3 and L2 flows, end 319 systems may not need to implement the L3 <=> L2 Transfer Function 320 specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also 321 subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a 322 function similar to the Transfer Function, see, e.g., the Svc Proxy 323 in Figure 1 in [I-D.ietf-detnet-dp-alt]. 325 6. Flow 327 The flows leveraging DetNet service can be unicast or multicast data 328 flows for an application with constrained requirements on network 329 performance, e.g., low packet loss rate and/or latency. Therefore, 330 they can require different connectivity types: point-to-point (p2p) 331 or point-to-multipoint (p2mp). The p2mp connectivity is created by a 332 transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt]. 333 (Note that mp2mp connectivity is a superposition of p2mp 334 connections.) 336 Many flows using DetNet service are periodic with fix packet size 337 (i.e., Constant Bit Rate (CBR) flows), or periodic with variable 338 packet size. 340 Delay and loss parameters are correlated because the effect of late 341 delivery can result data loss for an application. However, not all 342 applications require hard limits on both parameters (delay and loss). 343 For example, some real-time applications allow graceful degradation 344 if loss happens (e.g., sample-based processing, media distribution). 345 Some others may require high-bandwidth connections that make the 346 usage of techniques like packet replication economically challenging 347 or even impossible. Some applications may not tolerate loss, but are 348 not delay sensitive (e.g., bufferless sensors). Time/loss sensitive 349 applications may have somewhat special requirements especially for 350 loss (e.g., no loss in two consecutive communication cycles; very low 351 outage time, etc.). 353 Flows have the following attributes: 355 a. DataFlowSpecification (Section 6.1) 357 b. TrafficSpecification (Section 6.2) 359 c. FlowRank (Section 6.3) 361 Flow attributes are described in the following sections. 363 6.1. Identification and Specification of Flows 365 Identification options for DetNet flows at the UNI and within the 366 DetNet domain are specified as follows; see Section 6.1.1 for DetNet 367 L3 flows (at UNI), Section 6.1.2 for DetNet L2 flows (at UNI) and 368 Section 6.1.3 for DetNetwork flows (within the network). 370 6.1.1. DetNet L3 Flow Identification and Specification at UNI 372 DetNet L3 flows can be identified and specified by the following 373 attributes: 375 a. SourceIpAddress 377 b. DestinationIpAddress 379 c. IPv6FlowLabel 381 d. Dscp 383 e. Protocol 385 f. SourcePort 387 g. DestinationPort 389 6.1.2. DetNet L2 Flow Identification and Specification at UNI 391 DetNet L2 flows can be identified and specified by the following 392 attributes: 394 a. DestinationMacAddress 396 b. SourceMacAddress 398 c. Pcp 400 d. VlanId 402 e. EtherType 404 Note: The Multiple Stream Registration Protocol (MSRP) [IEEE8021Q] 405 uses StreamID to match Talker registrations with their corresponding 406 Listener registrations, i.e., to identify Streams (L2 TSN flows). 407 The StreamID includes the following subcomponents: 409 o A 48-bit MAC Address associated with the Talker sourcing the 410 stream to the bridged network. 412 o A 16-bit unsigned integer value, Unique ID, used to distinguish 413 among multiple streams sourced by the same Talker. 415 6.1.3. DetNetwork Flow Identification and Specification 417 Identification of DetNet flows within the DetNet domain are used in 418 the service information model. The attributes are specific to the 419 forwarding paradigm within the DetNet domain. DetNetwork flows can 420 be identified and specified by the following attributes: 422 a. SourceIpAddress 424 b. DestinationIpAddress 426 c. IPv6FlowLabel 428 d. MplsLabel 430 6.2. Traffic Specification 432 TrafficSpecification specifies how the Source transmits packets for 433 the flow. This is effectively the promise/request of the Source to 434 the network. The network uses this traffic specification to allocate 435 resources and adjust queue parameters in network nodes. 437 TrafficSpecification has the following attributes: 439 a. Interval: the period of time in which the traffic specification 440 cannot be exceeded. 442 b. MaxPacketsPerInterval: the maximum number of packets that the 443 Source will transmit in one Interval. 445 c. MaxPayloadSize: the maximum payload size that the Source will 446 transmit. 448 [[NOTE (to be removed from a future revision): These attributes can 449 be used to describe any type of traffic (e.g., CBR, VBR, etc.) and 450 can be used during resource allocation to represent worst case 451 scenarios. Further optional attributes can be considered to achieve 452 more efficient resource allocation. Such optional attributes might 453 be worth for flows with soft requirements (i.e., the flow is only 454 loss sensitive or only delay sensitive, but not both delay-and-loss 455 sensitive). Possible options how to extend TrafficSpecification 456 attributes is for further discussion. Identified options are 457 described in the following notes.]] 459 [[NOTE1: Based on the already defined attributes the most similar 460 additional attributes for VBR type flows can be defined as follows: 462 o AveragePacketsPerInterval: the average number of packets that the 463 Source will transmit in one Interval. 465 o AveragePayloadSize: the average payload size that the Source will 466 transmit. 468 ]] 470 [[NOTE2: another alternative to deal better with various traffic 471 types can rely on [RFC6003], which describes the support of Metro 472 Ethernet Forum (MEF) Ethernet traffic parameters for using for 473 resource reservation purposes. Such a Bandwidth Profile can be also 474 adapted to describe the set of traffic parameters for a Detnet flow. 475 Committed Rate indicates the rate at which traffic commits to be sent 476 by the source (described in terms of the CIR (Committed Information 477 Rate) and CBS (Committed Burst Size) attributes.) Excess Rate 478 indicates the extent by which the traffic sent by the source exceeds 479 the committed rate. The Excess Rate is described in terms of the EIR 480 (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]] 482 [[NOTE3: a third alternative is to define application based traffic 483 models such as [GPP22885] defines periodic and event-driven traffic 484 model, and 5G PPP work defines traffic model for MTC (Machine Type 485 Communication) use cases. Periodic traffic type is usually for 486 status update between devices or devices transmit status report to a 487 central unit in regular basis. TrafficPeriod, defines the period of 488 the status update message. DataSize, defines the data size of the 489 massage which is constant. 3GPP also defines approximately-periodic 490 transmission with variations on period and uncertainty in the time 491 arrival of the packets. Event-triggered traffic type corresponds 492 traffic being triggered by an MTC device event. 493 MinIntervalBetweenEvent, defines the minimum interval between two 494 events. Event-triggered transmission will not happen all the time, 495 whenever an alert is sent, it waits until the issue being solved to 496 be able to send another alert. MaxPacketPerEvent, defines the max 497 number of packets within one message. ]] 499 6.3. Flow Rank 501 FlowRank provides the rank of this flow relative to other flows in 502 the network. This rank is used to determine success/failure of flow 503 establishment. Rank (boolean) is used by the network to decide which 504 flows can and cannot exist when network resources reach their limit. 505 Rank is used to help to determine which flows can be dropped (i.e., 506 removed from node configuration) if a port of a node becomes 507 oversubscribed (e.g., due to network reconfiguration). The true 508 value is more important than the false value (i.e., flows with false 509 are dropped first). 511 6.4. Service Rank 513 ServiceRank provides the rank of this service instance relative to 514 other services in the network. This rank is used to determine 515 success/failure of service instance establishment. Rank (boolean) is 516 used by the network to decide which services can and cannot exist 517 when network resources reach their limit. Rank is used to help to 518 determine which services can be dropped (i.e., removed from node 519 configuration) if a port of a node becomes oversubscribed (e.g., due 520 to network reconfiguration). The true value is more important than 521 the false value (i.e., services with false are dropped first). 523 7. Source 525 The Source object specifies: 527 o The behavior of the Source for the flow (how/when the Source 528 transmits). 530 o The requirements of the Source from the network. 532 o The capabilities of the interface(s) of the Source. 534 The Source object includes the following attributes: 536 a. DataFlowSpecification (Section 6.1) 538 b. TrafficSpecification (Section 6.2) 540 c. FlowRank (Section 6.3) 542 d. EndSystemInterfaces (Section 9.1) 544 e. InterfaceCapabilities (Section 9.2) 546 f. UserToNetworkRequirements (Section 9.3) 548 For the join operation, the DataFlowSpecification, FlowRank, 549 EndSystemInterfaces, and TrafficSpecification SHALL be included 550 within the Source. For the join operation, the 551 UserToNetworkRequirements and InterfaceCapabilities groups MAY be 552 included within the Source. 554 For the leave operation, the DataFlowSpecification and 555 EndSystemInterfaces SHALL be included within the Source. 557 For the modify operation, the same object SHALL and MAY included as 558 for the join operation. 560 8. Destination 562 The Destination object includes the following attributes: 564 a. DataFlowSpecification (Section 6.1) 566 b. EndSystemInterfaces (Section 9.1) 568 c. InterfaceCapabilities (Section 9.2) 570 d. UserToNetworkRequirements (Section 9.3) 572 For the join operation, the DataFlowSpecification and 573 EndSystemInterfaces SHALL be included within the Destination. For 574 the join operation, the UserToNetworkRequirements and 575 InterfaceCapabilities groups MAY be included within the Destination. 577 For the leave operation, the DataFlowSpecification and 578 EndSystemInterfaces SHALL be included within the Destination. 580 For the modify operation, the same object SHALL and MAY included as 581 for the join operation. 583 [[NOTE (to be removed from a future revision): Should we add 584 DestinationRank? It could distinguish the importance of Destinations 585 if the flow cannot be provided for all Destinations.]] 587 9. Common Attributes of Source and Destination 589 Source and Destination end systems have the following common 590 attributes in addition to DataFlowSpecification (Section 6.1). 592 9.1. End System Interfaces 594 EndSystemInterfaces is a list of identifiers, one for each physical 595 interface (port) in the end system acting as a Source or Destination. 596 An interface is identified by an IP or a MAC address. 598 EndSystemInterfaces can refer also to logical sub-Interfaces if 599 supported by the end system, e.g., based on IfIndex parameter. 601 9.2. Interface Capabilities 603 InterfaceCapabilities specifies the network capabilities of all 604 interfaces (ports) contained in the EndSystemInterfaces object 605 (Section 9.1). These capabilities may be configured via the 606 InterfaceConfiguration object (Section 13.2) of the Status object 607 (Section 13). 609 Note that an end system may have multiple interfaces with different 610 network capabilities. In this case, each interface should be 611 specified in a distinct top-level Source or Destination object (i.e., 612 one entry in EndSystemInterfaces (Section 9.1)). Use of multiple 613 entries in EndSystemInterfaces is intended for network capabilities 614 that span multiple interfaces (e.g., packet replication and 615 elimination).";. 617 InterfaceCapabilities attributes: 619 a. SubInterfaceCapable (sub-interface capable) 621 b. PREF-Capable (packet replication and elimination capable) 623 [[NOTE (to be removed from a future revision): InterfaceCapabilities 624 attributes are to be defined. For information, [IEEE8021Qcc] 625 specifies the following attributes: 627 o VlanTagCapable (Customer VLAN Tag capable) 629 o CB-Capable (frame replication and elimination capable) 631 o CB-StreamIdenTypeList (a list of the optional Stream 632 Identification types supported by the interface as specified in 633 [IEEE8021CB].) 635 o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode 636 types supported by the interface as specified in [IEEE8021CB].) 638 ]] 640 9.3. User to Network Requirements 642 UserToNetworkRequirements specifies user requirements for the flow, 643 such as latency and reliability. 645 The UserToNetworkRequirements object includes the following 646 attributes: 648 a. NumReplicationTrees 650 b. MaxLatency 652 NumReplicationTrees specifies the number of maximally disjoint trees 653 that the network should configure to provide packet replication and 654 elimination for the flow. NumReplicationTrees is provided by the 655 Source only. Destinations SHALL set this element to one. Value zero 656 and one indicate no packet replication and elimination for the flow. 658 When NumReplicationTrees is greater than one, packet replication and 659 elimination is to be used for the flow. If the Source sets this 660 element to greater than one, and packet replication and elimination 661 is not possible in the network (e.g., no disjoint paths, or the nodes 662 do not support packet replication and elimination), then the 663 FailureCode of the Status object is non-zero (Section 13.1). 665 MaxLatency is the maximum latency from Source to Destination(s) for a 666 single packet of the flow. MaxLatency is specified as an integer 667 number of nanoseconds. When this requirement is specified by the 668 Source, it must be satisfied for all Destinations. When this 669 requirement is specified by a Destination, it must be satisfied for 670 that particular Destination only. If the UserToNetworkRequirements 671 group is not provided within the Source or Destination object, then 672 value zero SHALL be used for this element. Value zero represents a 673 special use for the maximum latency requirement. Value zero locks- 674 down the initial latency that the network provides in the 675 AccumulatedLatency parameter of the Status object (Section 13) after 676 the successful configuration of the flow, such that any subsequent 677 increase in the latency beyond that initial value causes the flow to 678 fail. 680 [[NOTE-1 (to be removed from a future revision): Should we add a 681 parameter to specify the maximum packet loss rate that can be 682 tolerated for the flow?]] 684 [[NOTE-2 (to be removed from a future revision): TrafficSpecification 685 (Section 6.2) specifies the Peak Information Rate (PIR) of the flow, 686 which is a kind of user requirement to the network. Should we add 687 Committed Information Rate (CIR), i.e., the minimum rate the user 688 requests to be guaranteed for the flow by the network?]] 690 10. Ingress 692 Placeholder ... 694 11. Egress 696 Placeholder ... 698 12. DetNet Domain 700 The DetNet Domain may change the encapsulation of a DetNet L2 or L3 701 flow at the UNI. That impacts not only how a flow can be recognised 702 inside the DetNet domain but also the resource reservation 703 calculations. 705 The DetNet Domain object specifies: 707 o The behavior of the flow (how/when it is transmited). 709 o The requirements of the flow from the network. 711 o The capabilities of the DetNet domain. 713 The DetNet domain object includes the following attributes: 715 a. DataFlowSpecification (Section 6.1) 717 b. TrafficSpecification (Section 6.2) 719 c. ServiceRank (Section 6.4) 721 d. DetnetDomainCapabilities (Section 12.1) 723 e. UserToNetworkRequirements (Section 9.3) 725 12.1. DetNet Domain Capabilities 727 DetnetDomainCapabilities specifies the network capabilities, which 728 can be used to provide DetNet service. DetNet Edge nodes may change 729 the encapsulation of a flow according to the data plane used inside 730 the DetNet domain. 732 DetnetDomainCapabilities object includes the following attributes: 734 a. EncapsulationFormat (data plane specific encapsulation) 736 b. PREF-Capable (packet replication and elimination capable) 738 13. Flow-status 740 The FlowStatus object is provided by the network each Source and 741 Destination of the flow. The Status object provides the status of 742 the flow with respect to the establishment of the flow by the 743 network. The Status object is delivered via the corresponding UNI to 744 each Source and Destination end system of the flow. The Status is 745 distinct for each Source or Destination because the 746 AccumulatedLatency and InterfaceConfiguration objects are distinct, 747 see below. 749 The Status object SHALL include the attributes a), b), c); and MAY 750 include attributes d), e): 752 a. DataFlowSpecification (Section 6.1) 754 b. StatusInfo (Section 13.1) 755 c. AccumulatedLatency (this section below) 757 d. InterfaceConfiguration (Section 13.2) 759 e. FailedInterfaces (Section 13.3) 761 DataFlowSpecification identifies the flow for which status is 762 provided. DataFlowSpecification is described in (Section 6.1) If the 763 Status object is provided without a Source or Destination object in a 764 protocol message via a UNI, then the DataFlowSpecification object 765 SHALL be included within the Status object for both join and leave 766 operations. If the Status object immediately follows a Source or 767 Destination object in the protocol message, then the 768 DataFlowSpecification object is obtained from the Source/Destination 769 object, and therefore DataFlowSpecification is not required within 770 the Status object. 772 AccumulatedLatency provides the worst-case latency that a single 773 packet of the flow can encounter along its current path(s) in the 774 network. When provided to a Source, AccumulatedLatency is the worst- 775 case latency for all Destinations (worst path). AccumulatedLatency 776 is specified as an integer number of nanoseconds. Latency is 777 measured using the time at which the data frame's message timestamp 778 point passes the reference plane marking the boundary between the 779 network media and PHY. The message timestamp point is specified by 780 IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful 781 Status, the network returns a value less than or equal to the 782 MaxLatency of the UserToNetworkRequirements (Section 9.3). If the 783 NumReplicationTrees of the UserToNetworkRequirements (Section 9.3) is 784 one, then the AccumlatedLatency SHALL provide the worst latency for 785 the current path from the Source to each Destination. If the path is 786 changed (e.g., due to rerouting), then the AccumulatedLatency changes 787 accordingly. If the NumReplicationTrees of the 788 UserToNetworkRequirements (Section 9.3) is greater than one, 789 AccumlatedLatency SHALL provide the worst latency for all paths in 790 use from the Source to each Destination. 792 13.1. Status Info 794 StatusInfo provides information regarding the status of a flow's 795 configuration in the network. 797 The StatusInfo object MAY include the following attributes: 799 a. SourceStatus is an enumeration for the status of the flow's 800 Source: 802 * None: no Source 803 * Ready: Source is ready 805 * Failed: Source failed 807 b. DestinationStatus is an enumeration for the status of the flow's 808 Destinations: 810 * None: no Destination 812 * Ready: all Destinations are ready 814 * PartialFailed: One or more Destinations ready, and one or more 815 Listeners failed. The flow can be used if the Source is 816 Ready. 818 * Failed: All Destinations failed. 820 c. FailureCode: A non-zero code that specifies the problem if the 821 flow encounters a failure (e.g., packet replication and 822 elimination is requested but not possible, or SourceStatus is 823 Failed, or DestinationStatus is Failed, or DestinationStatus is 824 PartialFailed). 826 [[NOTE (to be removed from a future revision): FailureCodes to be 827 defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN 828 failure codes.]] 830 13.2. Interface Configuration 832 InterfaceConfiguration provides information about of interfaces in 833 the Source/Destination. This configuration related information 834 assists the network in meeting the requirements of the flow. The 835 InterfaceConfiguration object is according to the capabilities of the 836 interface. InterfaceConfiguration can be distinct for each Source or 837 Destination of each flow. If the InterfaceConfiguration object is 838 not provided within the Status object, then the network SHALL assume 839 zero elements as the default (no interface configuration). 841 The InterfaceConfiguration object MAY include one or more the 842 following attributes: 844 a. MAC or IP Address to identify the interface 846 b. DataFlowSpecification (Section 6.1) 848 13.3. Failed Interfaces 850 FailedInterfaces provides a list of one or more physical interfaces 851 (ports) in the failed node when a failure occurs in the network. 853 The FailedInterface object includes the following attributes: 855 a. MAC or IP Address to identify the interface 857 b. InterfaceName 859 InterfaceName is the name of the interface (port) within the node. 860 This interface name SHALL be persistent, and unique within the node. 862 14. Service-status 864 Placeholder ... 866 15. Summary 868 This document describes DetNet flow information model both for DetNet 869 L3 flows and DetNet L2 flows based on the TSN data model specified by 870 [IEEE8021Qcc]. This revision is extended with DetNet specific flow 871 information model elements. 873 16. IANA Considerations 875 N/A. 877 17. Security Considerations 879 N/A. 881 18. References 883 18.1. Normative References 885 [I-D.ietf-detnet-architecture] 886 Finn, N., Thubert, P., Varga, B., and J. Farkas, 887 "Deterministic Networking Architecture", draft-ietf- 888 detnet-architecture-03 (work in progress), August 2017. 890 [I-D.ietf-detnet-dp-alt] 891 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 892 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 893 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 894 (work in progress), October 2016. 896 [I-D.ietf-detnet-use-cases] 897 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 898 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 899 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 900 X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D., 901 Geng, X., Dujovne, D., and M. Seewald, "Deterministic 902 Networking Use Cases", draft-ietf-detnet-use-cases-13 903 (work in progress), September 2017. 905 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 906 Requirement Levels", BCP 14, RFC 2119, 907 DOI 10.17487/RFC2119, March 1997, 908 . 910 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 911 RFC 6003, DOI 10.17487/RFC6003, October 2010, 912 . 914 18.2. Informative References 916 [GPP22885] 917 3GPP, "Study on LTE support for Vehicle-to-Everything 918 (V2X) services", 919 . 921 [IEEE8021AS] 922 IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local 923 and metropolitan area networks - Timing and 924 Synchronization for Time-Sensitive Applications in Bridged 925 Local Area Networks", 2011, 926 . 929 [IEEE8021CB] 930 IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local 931 and metropolitan area networks - Frame Replication and 932 Elimination for Reliability", 2017, 933 . 935 [IEEE8021Q] 936 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 937 metropolitan area networks - Bridges and Bridged 938 Networks", 2014, . 941 [IEEE8021Qbv] 942 IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local 943 and metropolitan area networks - Bridges and Bridged 944 Networks -- Amendment 25: Enhancements for Scheduled 945 Traffic", 2015, . 948 [IEEE8021Qcc] 949 IEEE 802.1, "IEEE P802.1Qcc-2015: IEEE Draft Standard for 950 Local and metropolitan area networks - Bridges and Bridged 951 Networks -- Amendment: Stream Reservation Protocol (SRP) 952 Enhancements and Performance Improvements", 2017, 953 . 955 [IEEE8021TSN] 956 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 957 Task Group", . 959 [IETFDetNet] 960 IETF, "IETF Deterministic Networking (DetNet) Working 961 Group", . 963 Authors' Addresses 965 Janos Farkas 966 Ericsson 967 Konyves Kalman krt. 11/B 968 Budapest 1097 969 Hungary 971 Email: janos.farkas@ericsson.com 973 Balazs Varga 974 Ericsson 975 Konyves Kalman krt. 11/B 976 Budapest 1097 977 Hungary 979 Email: balazs.a.varga@ericsson.com 980 Rodney Cummings 981 National Instruments 982 11500 N. Mopac Expwy 983 Bldg. C 984 Austin, TX 78759-3504 985 USA 987 Email: rodney.cummings@ni.com 989 Jiang Yuanlong 990 Huawei 992 Email: jiangyuanlong@huawei.com 994 Zha Yiyong 995 Huawei 997 Email: zhayiyong@huawei.com