idnits 2.17.1 draft-trossen-detnet-rsvp-tsn-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 586 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 (January 11, 2022) is 835 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 226, but not defined == Unused Reference: 'RFC8938' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'CHEN-IEEE' is defined on line 686, 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: July 11, 2022 J. Schmitt 6 Siemens 7 January 11, 2022 9 RSVP for TSN Networks 10 draft-trossen-detnet-rsvp-tsn-01.txt 12 Abstract 14 This document provides a solution for control plane signaling by 15 virtue of proposing changes to RSVP signaling with deterministic 16 services at the underlying TSN enabled layer. The solution covers 17 distributed, centralized, and hybrid signaling scenarios in the TSN 18 and SDN domain. The proposed changes to RSVP IntServ, called RSVP TSN 19 in the remainder of this document, provide a better integration with 20 Layer 2 technologies for resource reservation, for which we outline 21 example API specifications for the realization of RSVP TSN. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. RSVP IntServ vs RSVP TSN Data Plane Model . . . . . . . . 6 66 3.2. RSVP IntServ vs RSVP TSN Resource Reservation Styles . . . 6 67 3.3. RSVP IntServ vs RSVP TSN Object Definitions . . . . . . . 7 68 3.4 RSVP IntServ vs RSVP TSN Flow Specification . . . . . . . . 7 69 4. RSVP TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. Layer Interactions between RSVP TSN and Lower Layer 71 Resource Allocation . . . . . . . . . . . . . . . . . . . 9 72 4.2. API for Deterministic QoS (dQoS) . . . . . . . . . . . . . 10 73 4.3. DnFlow Signaling Interface (DnFSI) . . . . . . . . . . . . 10 74 4.4. DnFlow Transport Interface (DnFTI) . . . . . . . . . . . . 13 75 4.5. RSVP TSN Message Formats . . . . . . . . . . . . . . . . . 14 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The authors in [ID.malis-detnet-controller-plane-framework] provide 86 an overview of the DetNet control plane architecture along three 87 possible classes, namely (i) fully distributed control plane 88 utilizing dynamic signaling protocols, (ii) a centralized, SDN-like, 89 control plane, and (iii) a hybrid control plane. 91 The Time-Sensitive Networking (TSN) Task Group (TG) is a part of the 92 IEEE 802.1 Working Group (WG) (https://1.ieee802.org/tsn/). The 93 charter of the TSN TSG is to provide deterministic services for time 94 sensitive applications through IEEE 802 networks, i.e., guaranteed 95 packet transport with bounded latency, low packet delay variation, 96 and low packet loss. 98 The TSN TG has developed basic data plane techniques for providing 99 deterministic services within an IEEE 802.1Q network. Key aspects are 100 to provide resource reservation for deterministic services by making 101 use of a separate queue, access control, and determining the upper-, 102 lower- and in-class interference on the egress side for bounded 103 latency. This model for traffic from time sensitive applications, 104 called TSN model, and the associated data plane techniques for time 105 sensitive traffic can be applied to different lower layer network 106 technologies and is not limited to IEEE 802.1Q bridges. DetNet uses 107 for its DnFlows deterministic services provided by the lower layer 108 network technologies. 110 While many deterministic IP deployments make use of pre-planned flow 111 allocations, using an often centrally managed approach, this draft 112 investigates the use of RSVP [RFC2205] for allowing endpoints to 113 dynamically signal deterministic IP connectivity in combination with 114 underlying Layer 2 mechanisms, specifically those used for TSN 115 networks. When doing so, considerations arise for the development of 116 a Layer2-specific RSVP protocol, called RSVP TSN in the following. 118 This document will outline use cases for RSVP TSN, followed by the 119 design rationale and specification for the proposed RSVP TSN 120 protocol. 122 Note that the document does NOT cover aspects of traffic engineering, 123 specifically for a more detnet-focused revision of RSVP-TE. However, 124 the work in this draft is meant to provide more insights into the 125 possible working of RSVP for detnet (here focused over a specific L2 126 technology, namely TSN), which may in turn be used for a more general 127 work on detnet-specific extensions needed for RSVP overall. As such, 128 this document has been narrowed in scope from its previous version in 129 [ID-trossen-detnet-control-signaling]. 131 While this document has originally targeted the DetNet working group 132 by providing a suitable control plane signaling method for 133 deployments with TSN underlays, discussions are ongoing as to where 134 to ultimately place the work in this draft. Possible candidates here 135 are the TEAS (Traffic Engineering Architecture and Signaling) or 136 CCAMP (Common Control and Measurement Plane) WG. 138 1.1. Terminology 140 This document uses the terminology established in the DetNet 141 Architecture [RFC8655], and the reader is assumed to be familiar with 142 that document and its terminology. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 2. Use Cases 150 A deterministic network [RFC8655] is composed of DetNet-enabled end 151 systems and DetNet relay nodes which deliver deterministic services. 152 As shown in Figure 1, TSN-enabled end systems can still make use of 153 deterministic networking when they are connected to an DetNet edge 154 node supporting service proxy function to establish a deterministic 155 end-to-end service. 157 TSN Edge Transit Relay DetNet 158 End System Node Node Node End System 159 +----------+ +---------+ +----------+ 160 | Appl. |<--:Svc Proxy:-------End-to-End Service----->| Appl. | 161 +----------+ +---------+ +---------+ +----------+ 162 | TSN | |TSN| |Svc|<--DetNet flow---: Service :-->| Service | 163 +----------+ +-.-+ +-.-+ +---------+ +---------+ +----------+ 164 |Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding| 165 +-------.--+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.------+ 166 : : / ,-----. : : / ,-----. 167 +........+ +-[ Sub- ]--+ +.......+ +-[ Sub- ]--+ 168 [network] [network] 169 '-----' '-----' 170 Figure 1 : Deterministic Network with TSN-enabled End 171 Systems 173 In principle, three use cases are of interest for the establishment 174 of deterministic end-to-end service over deterministic networks: 175 (a) DetNet-enabled edge nodes with service proxy on both side because 176 the connected source and destination are TSN-enabled end systems 178 (b) Detnet enabled edge nodes with service proxy on one side because 179 the connected source or destination are TSN-enabled end systems 180 and on the other side the connected source or destination are 181 Detnet-enabled end-systems 183 (c) DetNet-enabled end systems are connected to a network supporting 184 end-to-end deterministic services 186 For the establishment of deterministic end-to-end connectivity based 187 on DnFlows, an end-2-end signaling protocol called RSVP TSN for 188 DnFlows is proposed. To achieve deterministic QoS, access control for 189 a DnFlow is required because each DnFlow must be known by the network 190 supporting DetNet. 192 The establishment of deterministic end-to-end connectivity is in 193 principle comparable with the establishment of TCP connectivity. The 194 main difference is that all network elements must take active part in 195 the establishment of a deterministic end-to-end connectivity. 197 RSVP TSN is an option which can be used to signal DnFLow information 198 between 200 a) DetNet-enabled edge nodes, 202 b) DetNet-enabled edge nodes and DetNet-enabled end system, 204 c) DetNet-enabled end systems, 206 d) DetNet-enabled end system and first DetNet-enabled relay node, 208 e) and DetNet-enabled relay node 210 NOTE: the next revision of the draft will include a more elaborate 211 reasoning as to why a dynamic signaling may be desirable, possibly 212 alongside managed approaches. 214 Several years ago, the IETF has introduced RSVP Intserv to exchange 215 flow information for integrated services. Because deterministic 216 service based on TSN differs from integrated services, additional 217 RSVP object definitions are required for RSVP TSN. 219 Goal of this contribution is to use RSVP TSN for signaling DnFlow 220 information to dynamically establish deterministic end-to-end 221 connectivity. DetNet-enabled end systems support RSVP TSN. There is 222 no need for edge nodes with proxy services. DetNet-unware or TSN- 223 aware end-systems presume edge nodes supporting proxy services when 224 they want have benefit from DetNet. 226 In the detnet stack model [RFC 8938], "Resource allocation" is 227 located in the forwarding sub-layer. In this document, the term 228 "Signaling" is used instead of the term "Resource allocation". One 229 reason for using the term "Signaling" is because the lower layer 230 network technologies like IEEE 802.1Q with TSN enhancements are 231 responsible to allocate queuing, bandwidth and latency resources to 232 provide deterministic services. 234 3. Design Rationale 236 IntServ and TSN have defined different models providing deterministic 237 QoS. This section will explore the design rationale behind the 238 development of RSVP TSN. It also outlines aspects derived from the 239 underlaying TSN capable lower layer network technology before 240 highlighting key design considerations for the presentation of RSVP 241 TSN in Section 4. 243 3.1. RSVP IntServ vs RSVP TSN Data Plane Model 245 The RSVP IntServ [RFC2212] model provides a flow bandwidth driven 246 latency model with a separate transmission queue per flow. RSVP 247 IntServ assumes a weighted fair queuing (WFQ) at the data plane, 248 where a listener is able to influence therefore the latency through 249 the reserved bandwidth per flow. 251 RSVP TSN assumes deterministic services are provided by lower layer 252 network technologies supporting the TSN model. The TSN model itself 253 is in contrasts with the RSVP IntServ [RFC2212] model. Lower layer 254 network technologies providing deterministic services for traffic 255 from time sensitive applications make use of separate queues, access 256 control, resource reservation and determine the upper-, lower- and 257 in-class interference on the egress side for bounded latency 259 3.2. RSVP IntServ vs RSVP TSN Resource Reservation Styles 261 RSVP IntServ has introduced the notion of 'sessions' to maintain 262 different kinds of deterministic end-to-end connectivity and resource 263 styles, namely fixed (i) filter style, (ii) shared explicit style, 264 and (iii) wildcard filter style - see [RFC2205]. The receiver 265 controls sender selection and resource styles selection. The receiver 266 is also able to influence latency for a flow by requesting certain 267 amount of bandwidth. 269 RSVP TSN splits the control over sender selection and resource 270 styles, due to the given TSN data plane model. The resource style is 271 controlled by the sender and the sender selection is controlled by 272 the receiver. The Receiver cannot influence bandwidth for a DnFlow. 274 The resource style 'coordinated share' is introduced in RSVP TSN to 275 support a large amount of small DnFlows with small data usage. 276 Multiple separate resource reservations on lower layer for small 277 DnFlows could become very inefficient. 279 || Resource Style | 280 Sender || | | NEW: | 281 Selection || Distinct | Shared | Coordinated Shared | 282 -----------------||-------------|-------------|--------------------| 283 || | | | 284 Explicit || supported | supported | supported | 285 -----------------||-------------|-------------|--------------------| 286 || | | | 287 Wildcard || | supported | | 288 -----------------||------------------------------------------------| 289 Figure 2: Resource Style and Sender Selection [RFC2205] 291 3.3. RSVP IntServ vs RSVP TSN Object Definitions 293 Due to the differences described above, not all object definitions 294 from RSVP IntServ can be applied to RSVP TSN. Also, not all features 295 are supported in the same way as is done by RSVP IntServ since RSVP 296 TSN assumes a deterministic service to be provided by the lower 297 network layer. 299 For instance, IEEE 802.1Q networks with TSN enhancements provides 300 deterministic services by a layer 2 protocol for resource allocation 301 for Sstreams [IEEE P802.1Qdd - Resource Allocation Protocol]. Such an 302 allocated Sstream can transport one or multiple DnFlows. A StreamID 303 is used for the identification at the layer 2 control plane. 305 To correlate DnFlow with their lower layer transport steams a stream 306 identifier information must be distributed by RSVP TSN. This is only 307 one of the reasons for introducing additional RSVP object 308 definitions. 310 3.4 RSVP IntServ vs RSVP TSN Flow Specification 312 In RSVP IntServ, the flow specification describes both the 313 characteristics of the traffic sent by the source and the service 314 requirements of the application. The flow specification of RSVP 315 IntServ is token bucket based. The sender TSpec is a description of 316 the allowed traffic characteristics for which service is being 317 requested. Each receiver describes by RSpec the service it desires to 318 receive. The RSpec is carried form the receiver to the intermediate 319 network elements and flows upstream towards the sender. It may be 320 used or updated at the intermediate network elements before arriving 321 the sender. The ADSpec object carries information which is generated 322 at either data sources or intermediate network elements, is flowing 323 downstream towards receivers. 325 In RSVP TSN, the sender TSpec information is also a description of 326 the allowed traffic characteristics for which service is being 327 requested. The receiver cannot describe the service it desires to 328 receive. The traffic specification itself can be token bucket based 329 but also variants based on intervals are supported. RSVP TSN does not 330 support RSpec. It is not able to support heterogeneous receivers 331 where each makes reservation requests with different QoS requirements 332 on per DnFlow session. 334 These differences pose a number of questions: 336 1. Is RSVP IntServ (as defined in [RFC2212]) the right starting point 337 to deliver DnFlow information and trigger resource allocation on 338 lower layer network technologies supporting the TSN model? 340 2. How to efficiently map the different reservation styles of RSVP 341 TSN (originally introduced by RSVP IntServ) onto the TSN data 342 plane model? 344 3. What is the nature of the interface between RSVP TSN and lower 345 layer resource reservation? 347 4. How does the binding between DnFlow signaling of RSVP TSN and 348 lower layer resource reservation look like? 350 5. Which of the different RSVP TSN traffic specifications shall be 351 supported? 353 Note: Different traffic specifications exist for an efficient 354 mapping of traffic specification to scheduling model. 356 | Time based | Token Bucket | Priority based | 357 | Scheduling | based | (none shaping | 358 | | Scheduling | network nodes) | 359 ---------+-----------------+-----------------+----------------+ 360 Stream/ | Proposal: | Asynchronous | Highest | 361 Flow | Dampers with | Traffic Shaping | (static) | 362 Based | Forward Traffic | (ATS) | priority | 363 | isolation | (IEEE 802.1Qcr) | | 364 ---------+-----------------+-----------------+----------------+ 365 Class |Cyclic Queuing & | Credit-Based | | 366 Based |Forwarding (CQF) | Shaper (CBSA) | | 367 | (IEEE 802.1Qch) | (IEEE 802.1Qav) | | 368 --------------------------------------------------------------- 369 Figure 3: Comparison of TSN and RSVP-IntServ Models 371 The proposal for dumper is discussed within the IEEE 802.1 TSN WG 372 (see https://www.ieee802.org/1/files/public/docs2020/new-specht- 373 dampers-fti-0620-v02.pdf). 375 For instance, the Resource-Allocation-Protocol (RAP) [RAP_IEEE] 376 introduces templates to describe traffic class for streams with its 377 scheduling model and the associated traffic specification for 378 streams. 380 4. RSVP TSN 382 This section specifies the APIs for RSVP TSN, the message formats, 383 and outlines the layer and node interactions in an RSVP TSN based 384 system. 386 4.1. Layer Interactions between RSVP TSN and Lower Layer Resource 387 Allocation 389 Figure 4 provides an overview of the interactions between lower layer 390 resource allocation and DnFlow signaling in a network deployment as 391 an elaboration of the elements in Figure 1, also illustrating the 392 various interfaces described in the following sections. 394 The application utilizes a generalized API for deterministic QoS 395 (dQoS), which controls and signals the establishment DnFlow via the 396 upper API of RSVP TSN. The latter is called DnFlow-Signaling- 397 Interface(uRSVPDnFSI) in this contribution. 399 DetNet end nodes utilize RSVP TSN to distribute DnFlow information by 400 end-to end signaling over DetNet Route. 402 The lower API of RSVP TSN is called DnFlow-Transport-Interface 403 (DnFTI) in this contribution. The DnFTI has connectivity with the 404 lower network layer, which in turn provides deterministic services 405 within a subnetwork based on the TSN model. 407 For instance, IEEE 802.1Q with extensions for TSN establish streams 408 to transport DnFlows. For stream reservation the Resource- 409 Allocation-Protocol (RAP) [RAP_IEEE] has defined the Reservation- 410 Service-Interface (RSI). 412 The following figure illustrates the information flow within a DetNet 413 end system and a DetNet relay node for the establishment of 414 deterministic end-2-end services. 416 DetNet DetNet 417 End System Relay Node 418 +------------+ 419 |Time | 420 |Sensitive | 421 |Application | 422 +------------+ 423 | dQoS | 424 | | 425 |C S| 426 | | 427 | DnFSI | 428 +------------+ +-------------+ 429 | RSVP TSN |<---------------------------------->| RSVP TSN | 430 +------------+ +-------------+ 431 | DnFTI | | | | | 432 | | | | | | 433 |M&A S| |M S| |M S| 434 | | | | | | 435 +-------------+ +-----------------------+ +-------------+ 436 | Lower Layer |<===>| Lower Layer |<===>| Lower Layer | 437 | TSN aware | | TSN aware Subnetwork | | TSN aware | 438 +-------------+ +-----------------------+ +-----+ +-----+ 440 <---> DnFlow Signaling Service 441 <===> Lower layer transport stream/flow reservation service 442 <===> TSN Stream Reservation 443 dQoS Deterministic QoS time sensitive application interface 444 DnFSI DnFlow-Service-Interface (upper API of RSVP TSN) 445 DnFTI DnFlow-Transport-Interface(lower API of RSVP TSN) 446 C Control 447 S Signaling 448 M&A Maps and Aggregation 450 Figure 4: Layer Interactions between RSVP TSN and lower 451 layer network supporting TSN 453 4.2. API for Deterministic QoS (dQoS) 455 The description of a generalized API to support deterministic QoS is 456 not part of this document. 458 4.3. DnFlow Signaling Interface (DnFSI) 460 The definition of the DnFSI and the DnFTI is based on the DnFlow 461 information model [ID-detnet-flow-information-model]. 463 This interface is oriented on the interface specified by RSVP-IntServ 464 (RFC 2205). Most of the changes are due to mapping resource 465 reservation styles (see Section 3.2). 467 Sender 469 Call: Open Session (oriented to the RSVP-IntServ interface) 471 Request parameter (make use of pieces from the 472 DnFlowSpecification) 474 - DestinationIpAddress, Protocol, DestinationPort 476 Response parameter: 478 - SessionID 480 Call: Add DnFlow 482 Request parameter (make use of pieces from the 483 DnFlowSpecification) 485 - SessionID, SourceIpAddress, SourcePort, DSCP 487 - DnTrafficSpecification: Interval, MaxPacketsPerInterval, 488 MaxPayloadSize, MinPayloadSize 490 - DnFLowRank 492 - Select one of the Resource Style: Distinct, Shared, 493 CoordinatedShared 495 - Data TTL, PATH MTU size, LossRate 497 Notes for new parameter: 499 The DSCP is required to map DnFlows according their service class 500 to offered service classes of the lower layer. 502 The resource style for an DnFlow is announced by the sender within 503 the path message. 505 The LossRate is accumulated per DnFlow from Sender to Receiver. 507 Upcall: DnFlow 509 - Session ID 511 - One of the Info_type: RESV_EVENT; PATH_ERROR 513 Receiver 514 Call: Open Session 516 Request parameter (make use of pieces from the 517 DnFlowSpecification) 519 - DestinationIpAddress, Protocol, DestinationPort 521 Response parameter 523 - SessionID 525 Call: Join DnFlow 527 Request parameter 529 - SessionID 531 - Select one of the DnFlow Source Selection: Wildcard, List of 532 explicit sources with SourcePort 534 - MaximumPacketSize 536 - Extended Traffic Specification: MaximumExpectedLatency 538 Notes for new parameter: 540 The Source Selection is split from the RSVP-IntServ Reservation 541 Style but still follows the rules defined by RSVP-IntServ. 543 The extended traffic specification MaximumExpectedLatency is 544 propagated and merged to a minimum upstream from receiver to 545 sender. 547 Upcall: DnFlow 549 - SessionID 551 - SourceIpAddress (Sender) 553 - SourcePort 555 - One of the Info_type: RESV_EVENT; PATH_ERROR 557 General 559 Call: Close Session 561 Request parameter 562 - SessionID 564 4.4. DnFlow Transport Interface (DnFTI) 566 Sender 568 Call: Add DnFlow 570 Request parameter 572 - SessionID, Interface, DnFlowID, DestinationIpAddress, DSCP 574 - DnTrafficSpecification: Interval, MaxPacketsPerInterval, 575 MaxPayloadSize, MinPayloadSize, MinPacketsInterval 577 - One of the Resource Styles: Distinct, Shared, Coordinated 578 Shared 580 Response parameter 582 - TransportFlowID (TSN StreamID) 584 Notes for new parameter: 586 The DnFlowID is a local parameter to correlate DnFlows to 587 transport flows (e.g., TSN Stream). 589 The TransportFlowID correlates the DnFlow to the lower layer 590 transport flow, e.g., TSN Stream ID. 592 Upcall: DnFlow 594 Response parameter 596 - SessionID 598 - TransportFlowID 600 - One of the Info_type: RESV_EVENT, RES_MODIFY_EVENT 602 Receiver 604 Call: Join DnFlow 606 Request parameter 608 - SessionID, Interface, DnFlowID, TransportFlowID 609 - MaximumPacketSize 611 - Extended Traffic Specification: MaximumExpectedLatency 613 Notes for new parameter: 615 (see notes above) 617 Upcall: DnFlow 619 Response parameter 621 - SessionID, TransportFlowID 623 - One of the Info_type: ANNOUNCE_EVENT, ANNOUNCE_MODIFY_EVENT 625 4.5. RSVP TSN Message Formats 627 TBD 629 5. Security Considerations 631 Editor's note: This section needs more details. 633 6. IANA Considerations 635 N/A 637 7. Conclusion 639 This draft outlines recommended changes to RSVP signaling in the form 640 of RSVP TSN for a better alignment of the Layer 3 signaling with that 641 of emerging Layer 2 solutions, together with suggested API 642 specifications for the realization of the L3 to L2 interfaces in 643 endpoints. 645 8. References 647 8.1. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, DOI 651 10.17487/RFC2119, March 1997, . 654 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 655 "Deterministic Networking Architecture", RFC 8655, DOI 656 10.17487/RFC8655, October 2019, . 659 [RFC2212] Shenker, S., Partridge, C., and Guerin, R., "Specification 660 of Guaranteed Quality of Service", RFC 2212, September 661 1997. 663 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jasmin, " 664 Resource ReSerVation Protocol (RSVP) -- Version 1 665 Functional Specification", RFC 2205, September 1997. 667 [RFC8655] N. Finn, B. Thubert, B. Vargas, J. Farkas, "Deterministic 668 Networking Architecture", RFC8655, October 2019 670 [RFC8938] B. Varga, Ed, J. Farkas, L. Berger, A. Malis, S. Bryant, 671 "Deterministic Networking (DetNet) Data Plane Framework", 672 RFC8938, November 2020. 674 8.2. Informative References 676 [ID.malis-detnet-controller-plane-framework] A. Malis, X. Geng, M. 677 Chen, F. Qin, B. Varga, "Deterministic Networking (DetNet) 678 Controller Plane Framework", draft-malis-detnet- 679 controller-plane-framework-05 (work in progress), 2020 681 [ID-detnet-flow-information-model] Balazs Varga, Janos Farkas, Rodney 682 Cummings, Yuanlong Jiang, Don Fedyk, "DetNet Flow and 683 Service Information Model", draft-ietf-detnet-flow- 684 information-model-14 (work in progress), 2021 686 [CHEN-IEEE] F. Chen, F.J. Goetz, M. Kiessling, J. Schmitt, " Support 687 for uStream Aggregation in RAP (ver 0.3)" (work in 688 progess), Jan 2019, 689 692 [RAP_IEEE] IEEE, "P802.1Qdd - Resource Allocation Protocol", (work in 693 progress), 695 [ID-trossen-detnet-control-signaling] D. Trossen, F.-J. Goetz, J. 696 Schmitt, "DetNet Control Plane Signaling", draft-trossen- 697 detnet-control-signaling-01 (work in progress), 2021 699 Authors' Addresses 701 Dirk Trossen 702 Huawei Technologies Duesseldorf GmbH 703 Riesstr. 25C 704 80992 Munich 705 Germany 707 Email: Dirk.Trossen@Huawei.com 709 Franz-Josef Goetz 710 Siemens AG 711 Gleiwitzer-Str. 555 712 90475 Nuremberg 713 Germany 715 Email: franz-josef.goetz@siemens.com 717 Juergen Schmitt 718 Siemens AG 719 Gleiwitzer Str. 555 720 90475 Nuremberg 721 Germany 723 Email: juergen.jues.schmitt@siemens.com