idnits 2.17.1 draft-trossen-detnet-control-signaling-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 == Line 617 has weird spacing: '...rameter to co...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 11, 2021) is 1170 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) == Missing Reference: 'RFC 8938' is mentioned on line 128, but not defined == Missing Reference: 'RFC3290' is mentioned on line 413, but not defined == Unused Reference: 'RFC8938' is defined on line 707, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8938 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet Working Group D. Trossen 3 INTERNET-DRAFT Huawei 4 Intended Status: Standards Track F.-J. Goetz 5 Expires: August 11, 2021 J. Schmitt 6 Siemens 7 February 11, 2021 9 DetNet Control Plane Signaling 10 draft-trossen-detnet-control-signaling-01.txt 12 Abstract 14 This document provides solutions for control plane signaling, in 15 accordance with the control plane framework developed in the DetNet 16 WG. The solutions cover distributed, centralized, and hybrid 17 signaling scenarios in the TSN and SDN domain. We propose changes to 18 RSVP IntServ for a better integration with Layer 2 technologies for 19 resource reservation, outlining example API specifications for the 20 realization of the revised RSVP (called RSVP-TSN in the document). 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 INTERNET DRAFT DetNet Control Plane Signaling 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Distributed DetNet User Network Interface (ddUNI) . . . . 3 66 2.2. Fully Distributed Detnet Control Plane (still supports 67 ddUNI) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. RAP Reservation in TSN vs RSVP IntServ Model . . . . . . . 5 70 3.2. Similarities and Differences between RSVP and RAP . . . . 5 71 3.2.1. Assumptions on Network Nodes . . . . . . . . . . . . . 5 72 3.2.2. Mapping of Latency Model . . . . . . . . . . . . . . . 6 73 3.2.3. Dealing with Latency Margins . . . . . . . . . . . . . 6 74 3.2.4. Dealing with Jitter and Non-Shaping Nodes . . . . . . 6 75 3.2.5. Mapping Resource Reservation Styles . . . . . . . . . 7 76 3.3. Design Considerations for RSVP-TSN . . . . . . . . . . . . 7 77 3.3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 7 78 3.3.2. Splitting Control over Resource Style and Sender 79 Selection . . . . . . . . . . . . . . . . . . . . . . 8 80 3.3.3. Coordinated Shared Resource Style . . . . . . . . . . 8 81 3.3.4. DnFlow DestinatinIpAddress Resolution . . . . . . . . 8 82 4. RSVP-TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.1. Layer Interactions between RSVP and TSN . . . . . . . . . 9 84 4.2. API for Deterministic QoS (gQoS) . . . . . . . . . . . . . 10 85 4.3. RSVP-TSN upper API (uRSVP) . . . . . . . . . . . . . . . . 10 86 4.4. RSVP-TSN lower API (lRSVP) . . . . . . . . . . . . . . . . 12 87 4.5. RSVP-TSN Message Formats . . . . . . . . . . . . . . . . . 14 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 96 INTERNET DRAFT DetNet Control Plane Signaling 98 1. Introduction 100 The authors in [ID.malis-detnet-controller-plane-framework] provide 101 an overview of the DetNet control plane architecture along three 102 possible classes, namely (i) fully distributed control plane 103 utilizing dynamic signaling protocols, (ii) a centralized, SDN-like, 104 control plane, and (iii) a hybrid control plane. 106 When investigating the usage of RSVP [RFC2205] for the signaling of 107 deterministic IP connectivity in combination of underlying Layer 2 108 mechanisms, considerations arise for the development of the detnet- 109 specific RSVP protocol, called RSVP-TSN in the following. 111 This document will outline use cases spanning the classes of control 112 planes introduced in [ID.malis-detnet-controller-plane-framework], 113 followed by the design rationale and specification for the proposed 114 RSVP-TSN protocol. 116 1.1. Terminology 118 This document uses the terminology established in the DetNet 119 Architecture [RFC8655], and the reader is assumed to be familiar with 120 that document and its terminology. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Use Cases 128 Based on the detnet stack model [RFC 8938], "Resource allocation", 129 located in the forwarding sub-layer, is split into RSVP-TSN IP flow 130 signaling and underlying TSN subnet stream reservation. Stream 131 reservation within TSN subnetworks can be organized with a 132 decentralized, centralized or hybrid configuration model. The notion 133 of TSN in these use cases and the remainder of the document assumes a 134 Bridged-Ethernet LAN with enhancements for time-sensitive 135 networking. 137 2.1. Distributed DetNet User Network Interface (ddUNI) 139 The following figure illustrates the principle of a hybrid DetNet 140 using RSVP-TSN for DnFlow signaling in a TSN aware customer network. 141 DetNet/TSN end nodes signal their DnFlows over RSVP-TSN. In parallel, 142 the TSN control plane triggers the stream reservation within a TSN 143 aware customer network, using e.g., LRP/RAP. The control plane 144 solution of a TSN customer network is independent from RSVP-TSN 145 signaling and can cover distributed, centralized or hybrid 147 INTERNET DRAFT DetNet Control Plane Signaling 149 reservation scenarios. 151 An RSVP detnet Edge Router supports RSVP-TSN signaling of DnFlows and 152 covers DnFlow signaling supported by the associated detnet aware core 153 network. Although the DetNet control plane within the DetNet core 154 network is without support for RSVP, it still supports the DetNet 155 Flow and Service Information Model [ID-detnet-flow-information-model] 156 and can be organized in a decentralized or centralized (SDN-like) 157 manner. 159 +-------+ 160 +-------+ +-------+| +-------+ 161 +----+ | | +------+ | || +------+ | | +----+ 162 |RSVP| | TSN | | RSVP | |DetNet || | RSVP | | TSN | |RSVP| 163 |TSN |--| Cust. | |DetNet| | aware || |DetNet| | Cust. |--|TSN | 164 |End-| |Network|--| Edge |--| Core ||--| Edge |--|Network| |End-| 165 |Node| | | |Router| |Network|| |Router| | | |Node| 166 +----+ +-------+ +------+ | |+ +------+ +-------+ +----+ 167 +-------+ 168 Figure 1 : Distributed DetNet UNI 170 2.2. Fully Distributed Detnet Control Plane (still supports ddUNI) 172 The following figure illustrates a fully distributed DetNet using 173 RSVP-TSN for DnFlow signaling in TSN aware customer networks and RSVP 174 aware core networks. In difference to the previous scenario, the 175 detnet control plane within the detnet aware core network still 176 supports RSVP to establish detnet end-2-end connectivity. 178 +-------+ 179 +-------+ +-------+| +-------+ 180 +----+ | | +------+ | RSVP || +------+ | | +----+ 181 |RSVP| | TSN | | RSVP | | aware || | RSVP | | TSN | |RSVP| 182 |TSN |--| Cust. | | Edge | | Core || | Edge | | Cust. |--|TSN | 183 |End-| |Network|--|Router|--|Network||--|Router|--|Network| |End-| 184 |Node| | | +------+ | |+ +------+ | | |Node| 185 +----+ +-------+ +-------+ +-------+ +----+ 186 Figure 2 : Fully Distributed DetNet UNI 188 3. Design Rationale 190 This section will explore the design rationale behind the development 191 of RSVP-TSN. The next two sub-sections outline aspects derived from 192 the comparison of RAP, as a Layer2 mechanism, and RSVP, before 193 highlighting key design considerations for the presentation of RSVP- 194 TSN in Section 4. 196 INTERNET DRAFT DetNet Control Plane Signaling 198 3.1. RAP Reservation in TSN vs RSVP IntServ Model 200 Layer2 reservation in TSN-based networks is supported through RAP, 201 providing a maximum of 8 classes of traffic where the frame priority 202 code point (PCP) is used to select the Resource Allocation (RA) class 203 at the ingress bridge. Streams within a single RA class are queued in 204 a single traffic class where the latency of the stream is guaranteed 205 per hop and per RA class. 207 This model contrasts with the RSVP IntServ [RFC2212] model, which 208 provides a flow bandwidth driven latency model with a separate 209 transmission queue per flow, not a class-based model like in the 210 aforementioned RAP model. 212 This difference in models poses a number of challenges: 214 1. Is RSVP IntServ (as defined in [RFC2212]) the right starting 215 point? 217 2. How to efficiently map the different reservation styles of RSVP- 218 TSN onto RAP? 220 3. What is the nature of the interface between RSVP-TSN and RAP? 222 4. How is the binding between L3 signaling (RSVP IntServer) and L2 223 signaling (RAP ) realized, e.g., mapping of Stream-ID? 225 The following sub-sections elaborate on the various aspects in 226 addressing those challenges. 228 3.2. Similarities and Differences between RSVP and RAP 230 The following sub-sections will outline various aspects to be 231 considered when designing the interfaces between RSVP-TSN and RAP, 232 namely the assumptions on network nodes (Section 3.2.1), the mapping 233 of the latency model used in both models (Section 3.2.2), the dealing 234 with latency margins (Section 3.2.3), the dealing with Jitter and 235 non-shaping nodes (Section 3.2.4), and the mapping of resource 236 reservation styles (Section 3.2.5). 238 3.2.1. Assumptions on Network Nodes 240 RSVP assumes three different nodes over which a reservation can be 241 done, namely 242 - Shaping node, which implements the RSVP signaling and shaping on 243 the data plane, 245 INTERNET DRAFT DetNet Control Plane Signaling 247 - None shaping node, which implements the RSVP signaling and is 248 capable of estimating the latency caused by this node 250 - Legacy node, which does neither implement RSVP nor any shaping. 252 RAP assumes properties common to all nodes within a reservation 253 domain: 254 - All nodes take part in the signaling process 256 - Different data plane architectures are supported albeit limited to 257 those defined in IEEE 802.1Q. 259 - Bridging between different (heterogeneous) data planes is achieved 260 through a peer-to-peer model where every upstream node is a talker 261 for the next downstream node. 263 3.2.2. Mapping of Latency Model 265 RSVP assumes a weighted fair queuing (WFQ) at the data plane, where a 266 listener is able to influence therefore the latency through the 267 reserved bandwidth per flow. 269 RAP assumes one traffic class with given interference per common RA 270 class, resulting in a per hop latency for all stream within a single 271 RA class. The E2E latency is just signaled by accumulating hop 272 latency while the allowed interference determines the amount of 273 allowed flow per RA class. Here, the listener is unable to influence 274 the latency but the stream requirement is signaled upstream. 276 3.2.3. Dealing with Latency Margins 278 RSVP provides the notion of slack [RFC2212] per flow, which can be 279 consumed by the processing node in the network to enable additional 280 reservations. 282 In RAP, every listener of a stream propagates its required latency 283 upstream to the talker. Latency margins are not handled directly by 284 RAP, while the per hop latency of an RA class is preconfigured by 285 management. In each node, the per RA class upstream required latency 286 of all streams can be used to locally calculate the latency margins 287 per hop. The management system can then use this information to 288 adjust the per hop maximum latency at runtime. 290 3.2.4. Dealing with Jitter and Non-Shaping Nodes 292 RSVP has two different parameters to propagate the maximum non- 294 INTERNET DRAFT DetNet Control Plane Signaling 296 conformance to the leaky bucket model introduced through jitter and 297 non-shaping nodes. These can be accumulated by non-shaping nodes, 298 i.e., those which implement the RSVP protocol but are not performing 299 shaping at the data plane. 301 Within RAP, there is no distinction between shaping and non-shaping 302 nodes since all nodes adhere to the data plane architecture defined 303 in IEEE 802.1Q. Heterogeneous data planes are possible as long as 304 assurances to the next hop can be upheld, while RA class attributes 305 are used to propagate data plane behavior (e.g., shaper) to the next 306 neighbor. 308 3.2.5. Mapping Resource Reservation Styles 310 RSVP uses the notion of 'sessions', which are able to maintain 311 different kinds of end-to-end connectivity and resource styles, 312 namely fixed (i) filter style, (ii) shared explicit style, and (iii) 313 wildcard filter style - see [RFC2205] and Figure 3. It is important 314 to note that in RSVP, both sender selection and resource styles are 315 controlled by the receiver; we return to this issue in our next 316 section, discussing the rationale for the proposed design for RSVP- 317 TSN. 319 The current draft version of RAP supports only distinct explicit mode 320 of reservation, while in principle supporting reservation between one 321 talker and multiple listeners. Bridged Ethernet technology is also 322 able to support the shared resource modes as specified by RSVP. Also 323 a new resource style called Coordinated Shared Resource Style is 324 planned. 326 || Resource Style | 327 Sender || | 328 Selection || Distinct | Shared | Coordinated Shared | 329 -----------------||-------------|-------------|--------------------| 330 || | | | 331 Explicit || supported | supported | supported | 332 -----------------||-------------|-------------|--------------------| 333 || | | | 334 Wildcard || | supported | | 335 -----------------||------------------------------------------------| 336 Figure 3: Resource Style and Sender Selection [RFC2205] 338 3.3. Design Considerations for RSVP-TSN 340 3.3.1. Rationale 342 Continuing from Section 3.2.5, in RSVP (for IntServ), the receiver 343 initiates resource style and sender selection through the Resv 345 INTERNET DRAFT DetNet Control Plane Signaling 347 message being sent upstream, while path state being setup through the 348 Path message from the sender to the receiver upon receiving the Resv 349 message. 351 When looking into an integration with lower layer APIs, such as the 352 TSN API, we identify key differences in WHEN these lower layer APIs 353 decide if a reservation is possible: 355 1. For a new Announce downstream, each L2 node decides that if this 356 stream was reserved at this port, would there be enough resources 357 available to do so? 359 2. For a new Attachment upstream, each L2 node will lock the required 360 resources and bandwidth exclusively for this stream. For every L2 361 node local non-locked Announce, the L2 node will decide the same 362 question as in item 1 and refresh and propagate the necessary 363 states accordingly. 365 It is important to note that steps 1 and 2 only work if the 'resource 366 style' is already known by the Announce propagation. 368 3.3.2. Splitting Control over Resource Style and Sender Selection 370 In order to allow for an efficient resource reservation at the lower 371 network level by implementing the steps 1 and 2 in Section 3.3.1, we 372 propose to split the control over 'resource style' and 'sender 373 selection' in that in RSVP-TSN the sender controls the 'resource 374 style' and the listener controls the 'sender selection'. 376 3.3.3. Coordinated Shared Resource Style 378 Independent from the efficient realization of lower layer resource 379 reservation, we have also identified a requirement in industrial use 380 cases to support a large amount of deterministic connections with 381 small data usage. In those cases, separate reservation for each 382 connection could be inefficient. 384 To address this, we propose to introduce another 'resource style' 385 called 'Coordinated Shared', which would indicate the use of 386 scheduling (of those many deterministic connections) at L2-Listener 387 and L3-Receiver level. A first proposal for a solution in the TSN RAP 388 protocol was presented to the IEEE in [CHEN-IEEE] 390 3.3.4. DnFlow DestinatinIpAddress Resolution 392 To support deterministic QoS Bridged Ethernet has introduced Streams. 393 Streams differ from legacy traffic within a Bridged Ethernet sub- 394 network because streams belong to a traffic class which is uniquely 396 INTERNET DRAFT DetNet Control Plane Signaling 398 identified by a priority value in the range of 0 through 7. Streams 399 within an TSN aware Bridged Ethernet sub-network also need unique 400 destination MAC-address for identification. The priority and the 401 unique destination MAC-address indicates a Stream within a virtual 402 LAN (VLAN). The IEEE 802.1CQ draft for "Multicast and Local Address 403 Assignment" specifies protocols and procedures of locally unique 404 assignment for 48-bit and 64-bit addresses in IEEE 802 networks. 406 Streams do not use the interface Mac-Address as destination MAC- 407 Address within a Bridged Ethernet. Further enhancements for IP 408 address resolutions are required within TSN and detnet aware end- 409 systems and routers and to map one or multiple detnet IP flows to a 410 stream destination MAC-Address. DnFlows are identified by a "6-tuple" 411 that refers to information carried in IP and higher layer protocol 412 headers. The 6-tuple referred to in this document is the same as that 413 defined in [RFC3290]. Specifically, 6-tuple is DestinationIpAddress, 414 SourceIpAddress, Protocol, SourcePort, DestinationPort, and 415 differentiated services (DiffServ) code point (DSCP). 417 4. RSVP-TSN 419 In this section, we specify the APIs for RSVP-TSN, the message 420 formats, as well as outline the layer and node interactions in an 421 RSVP-TSN based system 423 4.1. Layer Interactions between RSVP and TSN 425 Figure 4 provides an overview of the interactions between L2 and L3 426 elements in a network deployment as an elaboration of the elements in 427 Figure 1, also illustrating the various interfaces described in the 428 following sections. 430 The application utilizes a generalized API for deterministic QoS 431 (dQoS) that controls and signals the establishment of deterministic 432 end-to-end DnFlow via the upper API of RSVP-TSN (uRSVP). 434 RSVP-TSN end nodes utilize RSVP-TSN to signal DnFlows to a detnet 435 aware edge router. This L3 network interface is called "Distributed 436 DetNet User Network Interface" (ddUNI). 438 The lower API of RSVP-TSN (lRSVP) interacts with the TSN control 439 plane to trigger the establishment of streams in an TSN aware (e.g. 440 customer) sub-network. The TSN control plane for the establishment of 441 streams in a TSN sub-network can be organized decentralized, 442 centralized or hybrid for stream reservation. For stream 443 establishment based on centralized scheduling, a third-party protocol 444 like RESTCONF is typically used. 446 INTERNET DRAFT DetNet Control Plane Signaling 448 +-----------+ 449 |Application| 450 +-----------+ 451 | dQoS | 452 | | 453 |C S| 454 | | 455 | uRSVP | 456 +-----------+ +-------------+ 457 | RSVP-TSN |<------------------------------------->| RSVP-TSN | 458 +-----------+ +-------------+ 459 | lRSVP | | | | | 460 | | | | | | 461 |M&A S| |M S| |M S| 462 | | | | | | 463 +-----------+ +--------------------------+ +-------------+ 464 | RSVP-TSN |<===>| TSN aware |<===>| RSVP/DetNet | 465 | End-Node | | Customer Subnetwork | | Edge Router | 466 +-----------+ +--------------------------+ +-----+ +-----+ 468 <---> RSVP-TSN DNFlow Signaling 469 <===> TSN Stream Reservation 470 dQoS API for deterministic QoS 471 uRSVP upper API of RSVP-TSN 472 lRSVP lower API of RSVP-TSN 473 C Controls S Signals M&A Maps and Aggregation 474 Figure 4: Layer Interactions between RSVP and TSN 476 4.2. API for Deterministic QoS (gQoS) 478 The description of a generalized API to support deterministic QoS is 479 not part of this document. 481 4.3. RSVP-TSN upper API (uRSVP) 483 The definition of the upper and lower APIs of RSVP-TSN is based on 484 the DetNet flow information model [ID-detnet-flow-information-model]. 486 This interface is oriented on the interface specified by RSVP-IntServ 487 (RFC 2205). Most of the changes are due to mapping resource 488 reservation styles (see Section 2.4.5). 490 Sender 492 Call: Open Session (oriented to the RSVP-IntServ interface) 494 Request parameter (make use of pieces from the 495 DnFlowSpecification) 497 INTERNET DRAFT DetNet Control Plane Signaling 499 - DestinationIpAddress, Protocol, DestinationPort 501 Response parameter: 503 - SessionID 505 Call: Add DnFlow 507 Request parameter (make use of pieces from the 508 DnFlowSpecification) 510 - SessionID, SourceIpAddress, SourcePort, DSCP 512 - DnTrafficSpecification: Interval, MaxPacketsPerInterval, 513 MaxPayloadSize, MinPayloadSize 515 - DnFLowRank 517 - Select one of the Resource Style: Distinct, Shared, 518 CoordinatedShared 520 - Data TTL, PATH MTU size, LossRate 522 Notes for new parameter: 524 The DSCP is required to map DnFlows according their service class 525 to offered service classes of the lower layer. 527 The resource style for an DnFlow is announced by the sender within 528 the path message. 530 The LossRate is accumulated per DnFlow from Sender to Receiver. 532 Upcall: DnFlow 534 - Session ID 536 - One of the Info_type: RESV_EVENT; PATH_ERROR 538 Receiver 540 Call: Open Session 542 Request parameter (make use of pieces from the 543 DnFlowSpecification) 545 - DestinationIpAddress, Protocol, DestinationPort 547 INTERNET DRAFT DetNet Control Plane Signaling 549 Response parameter 551 - SessionID 553 Call: Join DnFlow 555 Request parameter 557 - SessionID 559 - Select one of the DnFlow Source Selection: Wildcard, List of 560 explicit sources with SourcePort 562 - MaximumPacketSize 564 - Extended Traffic Specification: MaximumExpectedLatency 566 Notes for new parameter: 568 The Source Selection is split from the RSVP-IntServ Reservation 569 Style but still follows the rules defined by RSVP-IntServ. 571 The extended traffic specification MaximumExpectedLatency is 572 propagated and merged to a minimum upstream from receiver to 573 sender. 575 Upcall: DnFlow 577 - SessionID 579 - SourceIpAddress (Sender) 581 - SourcePort 583 - One of the Info_type: RESV_EVENT; PATH_ERROR 585 General 587 Call: Close Session 589 Request parameter 591 - SessionID 593 4.4. RSVP-TSN lower API (lRSVP) 595 Sender 597 INTERNET DRAFT DetNet Control Plane Signaling 599 Call: Add DnFlow 601 Request parameter 603 - SessionID, Interface, DnFlowID, DestinationIpAddress, DSCP 605 - DnTrafficSpecification: Interval, MaxPacketsPerInterval, 606 MaxPayloadSize, MinPayloadSize, MinPacketsInterval 608 - One of the Resource Styles: Distinct, Shared, Coordinated 609 Shared 611 Response parameter 613 - TransportFlowID (TSN StreamID) 615 Notes for new parameter: 617 The DnFlowID is a local parameter to correlate DnFlows to 618 transport flows (e.g., TSN Stream). 620 The TransportFlowID correlates the DnFlow to the lower layer 621 transport flow, e.g., TSN Stream ID. 623 Upcall: DnFlow 625 Response parameter 627 - SessionID 629 - TransportFlowID 631 - One of the Info_type: RESV_EVENT, RES_MODIFY_EVENT 633 Receiver 635 Call: Join DnFlow 637 Request parameter 639 - SessionID, Interface, DnFlowID, TransportFlowID 641 - MaximumPacketSize 643 - Extended Traffic Specification: MaximumExpectedLatency 645 Notes for new parameter: 647 INTERNET DRAFT DetNet Control Plane Signaling 649 (see notes above) 651 Upcall: DnFlow 653 Response parameter 655 - SessionID, TransportFlowID 657 - One of the Info_type: ANNOUNCE_EVENT, ANNOUNCE_MODIFY_EVENT 659 4.5. RSVP-TSN Message Formats 661 TBD 663 5. Security Considerations 665 Editor's note: This section needs more details. 667 6. IANA Considerations 669 N/A 671 7. Conclusion 673 This draft outlines the possible control plane signaling in 674 deterministic networking environments for distributed, centralized 675 and hybrid deployments. 677 For this, changes to the RSVP signaling have been proposed in the 678 form of RSVP-TSN for a better alignment of the Layer 3 signaling with 679 that of emerging Layer 2 solutions, together with suggested API 680 specifications for the realization of the L3 to L2 interfaces in 681 endpoints. 683 8. References 685 8.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, DOI 689 10.17487/RFC2119, March 1997, . 692 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 693 "Deterministic Networking Architecture", RFC 8655, DOI 694 10.17487/RFC8655, October 2019, . 697 INTERNET DRAFT DetNet Control Plane Signaling 699 [RFC2212] Shenker, S., Partridge, C., and Guerin, R., "Specification 700 of Guaranteed Quality of Service", RFC 2212, September 701 1997. 703 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jasmin, " 704 Resource ReSerVation Protocol (RSVP) -- Version 1 705 Functional Specification", RFC 2205, September 1997. 707 [RFC8938] B. Varga, Ed, J. Farkas, L. Berger, A. Malis, S. Bryant, 708 "Deterministic Networking (DetNet) Data Plane Framework", 709 RFC8938, November 2020. 711 8.2. Informative References 713 [ID.malis-detnet-controller-plane-framework] A. Malis, X. Geng, M. 714 Chen, F. Qin, B. Varga, "Deterministic Networking (DetNet) 715 Controller Plane Framework", draft-malis-detnet- 716 controller-plane-framework-05 (work in progress), 2020. 718 [ID-detnet-flow-information-model] Balazs Varga, Janos Farkas, Rodney 719 Cummings, Yuanlong Jiang, Don Fedyk, "DetNet Flow and 720 Service Information Model", draft-ietf-detnet-flow- 721 information-model-14 (work in progress), 2021 723 [CHEN-IEEE] F. Chen, F.J. Goetz, M. Kiessling, J. Schmitt, " Support 724 for uStream Aggregation in RAP (ver 0.3)" (work in 725 progess), Jan 2019, 726 729 [RAP_IEEE] IEEE, "P802.1Qdd - Resource Allocation Protocol", (work in 730 progress), 732 Authors' Addresses 734 Dirk Trossen 735 Huawei Technologies Duesseldorf GmbH 736 Riesstr. 25C 737 80992 Munich 738 Germany 740 Email: Dirk.Trossen@Huawei.com 742 Franz-Josef Goetz 743 Siemens AG 745 INTERNET DRAFT DetNet Control Plane Signaling 747 Gleiwitzer-Str. 555 748 90475 Nuremberg 749 Germany 751 Email: franz-josef.goetz@siemens.com 753 Juergen Schmitt 754 Siemens AG 755 Gleiwitzer Str. 555 756 90475 Nuremberg 757 Germany 759 Email: juergen.jues.schmitt@siemens.com