idnits 2.17.1 draft-trossen-detnet-rsvp-tsn-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 574 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 (July 8, 2021) is 1023 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 213, but not defined == Unused Reference: 'RFC8938' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'CHEN-IEEE' is defined on line 674, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8938 Summary: 2 errors (**), 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: January 8, 2022 J. Schmitt 6 Siemens 7 July 8, 2021 9 RSVP for TSN Networks 10 draft-trossen-detnet-rsvp-tsn-00.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 . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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) . . . . . . . . . . . . 12 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 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 The authors in [ID.malis-detnet-controller-plane-framework] provide 87 an overview of the DetNet control plane architecture along three 88 possible classes, namely (i) fully distributed control plane 89 utilizing dynamic signaling protocols, (ii) a centralized, SDN-like, 90 control plane, and (iii) a hybrid control plane. 92 The Time-Sensitive Networking (TSN) Task Group (TG) is a part of the 93 IEEE 802.1 Working Group (WG) (https://1.ieee802.org/tsn/). The 94 charter of the TSN TSG is to provide deterministic services for time 95 sensitive applications through IEEE 802 networks, i.e., guaranteed 96 packet transport with bounded latency, low packet delay variation, 97 and low packet loss. 99 The TSN TG has developed basic data plane techniques for providing 100 deterministic services within an IEEE 802.1Q network. Key aspects are 101 to provide resource reservation for deterministic services by making 102 use of a separate queue, access control, and determining the upper-, 103 lower- and in-class interference on the egress side for bounded 104 latency. This model for traffic from time sensitive applications, 105 called TSN model, and the associated data plane techniques for time 106 sensitive traffic can be applied to different lower layer network 107 technologies and is not limited to IEEE 802.1Q bridges. DetNet uses 108 for its DnFlows deterministic services provided by the lower layer 109 network technologies. 111 When investigating the usage of RSVP [RFC2205] for the signaling of 112 deterministic IP connectivity in combination with underlying Layer 2 113 mechanisms, specifically those developed for TSN, considerations 114 arise for the development of a Layer2-specific RSVP protocol, called 115 RSVP TSN in the following. 117 This document will outline use cases for RSVP TSN, followed by the 118 design rationale and specification for the proposed RSVP TSN 119 protocol. 121 Note that the document does NOT cover aspects of traffic engineering, 122 specifically for a more detnet-focused revision of RSVP-TE. However, 123 the work in this draft is meant to provide more insights into the 124 possible working of RSVP for detnet (here focused over a specific L2 125 technology, namely TSN), which may in turn be used for a more general 126 work on detnet-specific extensions needed for RSVP overall. As such, 127 this document has been narrowed in scope from its previous version in 128 [ID-trossen-detnet-control-signaling]. 130 1.1. Terminology 131 This document uses the terminology established in the DetNet 132 Architecture [RFC8655], and the reader is assumed to be familiar with 133 that document and its terminology. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. Use Cases 141 A deterministic network [RFC8655] is composed of DetNet-enabled end 142 systems and DetNet relay nodes which deliver deterministic services. 143 As shown in Figure 1, TSN-enabled end systems can still make use of 144 deterministic networking when they are connected to an DetNet edge 145 node supporting service proxy function to establish a deterministic 146 end-to-end service. 148 TSN Edge Transit Relay DetNet 149 End System Node Node Node End System 150 +----------+ +---------+ +----------+ 151 | Appl. |<--:Svc Proxy:-------End-to-End Service----->| Appl. | 152 +----------+ +---------+ +---------+ +----------+ 153 | TSN | |TSN| |Svc|<--DetNet flow---: Service :-->| Service | 154 +----------+ +-.-+ +-.-+ +---------+ +---------+ +----------+ 155 |Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding| 156 +-------.--+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.------+ 157 : : / ,-----. : : / ,-----. 158 +........+ +-[ Sub- ]--+ +.......+ +-[ Sub- ]--+ 159 [network] [network] 160 '-----' '-----' 161 Figure 1 : Deterministic Network with TSN-enabled End 162 Systems 164 In principle, three use cases are of interest for the establishment 165 of deterministic end-to-end service over deterministic networks: 166 (a) DetNet-enabled edge nodes with service proxy on both side because 167 the connected source and destination are TSN-enabled end systems 169 (b) Detnet enabled edge nodes with service proxy on one side because 170 the connected source or destination are TSN-enabled end systems 171 and on the other side the connected source or destination are 172 Detnet-enabled end-systems 174 (c) DetNet-enabled end systems are connected to a network supporting 175 end-to-end deterministic services 177 For the establishment of deterministic end-to-end connectivity based 178 on DnFlows, an end-2-end signaling protocol called RSVP TSN for 179 DnFlows is proposed. To achieve deterministic QoS, access control for 180 a DnFlow is required because each DnFlow must be known by the network 181 supporting DetNet. 183 The establishment of deterministic end-to-end connectivity is in 184 principle comparable with the establishment of TCP connectivity. The 185 main difference is that all network elements must take active part in 186 the establishment of a deterministic end-to-end connectivity. 188 RSVP TSN is an option which can be used to signal DnFLow information 189 between 191 a) DetNet-enabled edge nodes, 193 b) DetNet-enabled edge nodes and DetNet-enabled end system, 195 c) DetNet-enabled end systems, 197 d) DetNet-enabled end system and first DetNet-enabled relay node, 199 e) and DetNet-enabled relay node 201 Several years ago, the IETF has introduced RSVP Intserv to exchange 202 flow information for integrated services. Because deterministic 203 service based on TSN differs from integrated services, additional 204 RSVP object definitions are required for RSVP TSN. 206 Goal of this contribution is to use RSVP TSN for signaling DnFlow 207 information to establish deterministic end-to-end connectivity. 208 DetNet-enabled end systems support RSVP TSN. There is no need for 209 edge nodes with proxy services. DetNet-unware or TSN-aware end- 210 systems presume edge nodes supporting proxy services when they want 211 have benefit from DetNet. 213 In the detnet stack model [RFC 8938], "Resource allocation" is 214 located in the forwarding sub-layer. In this document, the term 215 "Signaling" is used instead of the term "Resource allocation". One 216 reason for using the term "Signaling" is because the lower layer 217 network technologies like IEEE 802.1Q with TSN enhancements are 218 responsible to allocate queuing, bandwidth and latency resources to 219 provide deterministic services. 221 3. Design Rationale 223 IntServ and TSN have defined different models providing deterministic 224 QoS. This section will explore the design rationale behind the 225 development of RSVP TSN. It also outlines aspects derived from the 226 underlaying TSN capable lower layer network technology before 227 highlighting key design considerations for the presentation of RSVP 228 TSN in Section 4. 230 3.1. RSVP IntServ vs RSVP TSN Data Plane Model 232 The RSVP IntServ [RFC2212] model provides a flow bandwidth driven 233 latency model with a separate transmission queue per flow. RSVP 234 IntServ assumes a weighted fair queuing (WFQ) at the data plane, 235 where a listener is able to influence therefore the latency through 236 the reserved bandwidth per flow. 238 RSVP TSN assumes deterministic services are provided by lower layer 239 network technologies supporting the TSN model. The TSN model itself 240 is in contrasts with the RSVP IntServ [RFC2212] model. Lower layer 241 network technologies providing deterministic services for traffic 242 from time sensitive applications make use of separate queues, access 243 control, resource reservation and determine the upper-, lower- and 244 in-class interference on the egress side for bounded latency 246 3.2. RSVP IntServ vs RSVP TSN Resource Reservation Styles 248 RSVP IntServ has introduced the notion of 'sessions' to maintain 249 different kinds of deterministic end-to-end connectivity and resource 250 styles, namely fixed (i) filter style, (ii) shared explicit style, 251 and (iii) wildcard filter style - see [RFC2205]. The receiver 252 controls sender selection and resource styles selection. The receiver 253 is also able to influence latency for a flow by requesting certain 254 amount of bandwidth. 256 RSVP TSN splits the control over sender selection and resource 257 styles, due to the given TSN data plane model. The resource style is 258 controlled by the sender and the sender selection is controlled by 259 the receiver. The Receiver cannot influence bandwidth for a DnFlow. 261 The resource style 'coordinated share' is introduced in RSVP TSN to 262 support a large amount of small DnFlows with small data usage. 263 Multiple separate resource reservations on lower layer for small 264 DnFlows could become very inefficient. 266 || Resource Style | 267 Sender || | | NEW: | 268 Selection || Distinct | Shared | Coordinated Shared | 269 -----------------||-------------|-------------|--------------------| 270 || | | | 271 Explicit || supported | supported | supported | 273 -----------------||-------------|-------------|--------------------| 274 || | | | 275 Wildcard || | supported | | 276 -----------------||------------------------------------------------| 277 Figure 2: Resource Style and Sender Selection [RFC2205] 279 3.3. RSVP IntServ vs RSVP TSN Object Definitions 281 Due to the differences described above, not all object definitions 282 from RSVP IntServ can be applied to RSVP TSN. Also, not all features 283 are supported in the same way as is done by RSVP IntServ since RSVP 284 TSN assumes a deterministic service to be provided by the lower 285 network layer. 287 For instance, IEEE 802.1Q networks with TSN enhancements provides 288 deterministic services by a layer 2 protocol for resource allocation 289 for Sstreams [IEEE P802.1Qdd - Resource Allocation Protocol]. Such an 290 allocated Sstream can transport one or multiple DnFlows. A StreamID 291 is used for the identification at the layer 2 control plane. 293 To correlate DnFlow with their lower layer transport steams a stream 294 identifier information must be distributed by RSVP TSN. This is only 295 one of the reasons for introducing additional RSVP object 296 definitions. 298 3.4 RSVP IntServ vs RSVP TSN Flow Specification 300 In RSVP IntServ, the flow specification describes both the 301 characteristics of the traffic sent by the source and the service 302 requirements of the application. The flow specification of RSVP 303 IntServ is token bucket based. The sender TSpec is a description of 304 the allowed traffic characteristics for which service is being 305 requested. Each receiver describes by RSpec the service it desires to 306 receive. The RSpec is carried form the receiver to the intermediate 307 network elements and flows upstream towards the sender. It may be 308 used or updated at the intermediate network elements before arriving 309 the sender. The ADSpec object carries information which is generated 310 at either data sources or intermediate network elements, is flowing 311 downstream towards receivers. 313 In RSVP TSN, the sender TSpec information is also a description of 314 the allowed traffic characteristics for which service is being 315 requested. The receiver cannot describe the service it desires to 316 receive. The traffic specification itself can be token bucket based 317 but also variants based on intervals are supported. RSVP TSN does not 318 support RSpec. It is not able to support heterogeneous receivers 319 where each makes reservation requests with different QoS requirements 320 on per DnFlow session. 322 These differences pose a number of questions: 324 1. Is RSVP IntServ (as defined in [RFC2212]) the right starting point 325 to deliver DnFlow information and trigger resource allocation on 326 lower layer network technologies supporting the TSN model? 328 2. How to efficiently map the different reservation styles of RSVP 329 TSN (originally introduced by RSVP IntServ) onto the TSN data 330 plane model? 332 3. What is the nature of the interface between RSVP TSN and lower 333 layer resource reservation? 335 4. How does the binding between DnFlow signaling of RSVP TSN and 336 lower layer resource reservation look like? 338 5. Which of the different RSVP TSN traffic specifications shall be 339 supported? 341 Note: Different traffic specifications exist for an efficient 342 mapping of traffic specification to scheduling model. 344 | Time based | Token Bucket | Priority based | 345 | Scheduling | based | (none shaping | 346 | | Scheduling | network nodes) | 347 ---------+-----------------+-----------------+----------------+ 348 Stream/ | Proposal: | Asynchronous | Highest | 349 Flow | Dampers with | Traffic Shaping | (static) | 350 Based | Forward Traffic | (ATS) | priority | 351 | isolation | (IEEE 802.1Qcr) | | 352 ---------+-----------------+-----------------+----------------+ 353 Class |Cyclic Queuing & | Credit-Based | | 354 Based |Forwarding (CQF) | Shaper (CBSA) | | 355 | (IEEE 802.1Qch) | (IEEE 802.1Qav) | | 356 --------------------------------------------------------------- 357 Figure 3: Comparison of TSN and RSVP-IntServ Models 359 The proposal for dumper is discussed within the IEEE 802.1 TSN WG 360 (see https://www.ieee802.org/1/files/public/docs2020/new-specht- 361 dampers-fti-0620-v02.pdf). 363 For instance, the Resource-Allocation-Protocol (RAP) [RAP_IEEE] 364 introduces templates to describe traffic class for streams with its 365 scheduling model and the associated traffic specification for 366 streams. 368 4. RSVP TSN 369 This section specifies the APIs for RSVP TSN, the message formats, 370 and outlines the layer and node interactions in an RSVP TSN based 371 system. 373 4.1. Layer Interactions between RSVP TSN and Lower Layer Resource 374 Allocation 376 Figure 4 provides an overview of the interactions between lower layer 377 resource allocation and DnFlow signaling in a network deployment as 378 an elaboration of the elements in Figure 1, also illustrating the 379 various interfaces described in the following sections. 381 The application utilizes a generalized API for deterministic QoS 382 (dQoS), which controls and signals the establishment DnFlow via the 383 upper API of RSVP TSN. The latter is called DnFlow-Signaling- 384 Interface(uRSVPDnFSI) in this contribution. 386 DetNet end nodes utilize RSVP TSN to distribute DnFlow information by 387 end-to end signaling over DetNet Route. 389 The lower API of RSVP TSN is called DnFlow-Transport-Interface 390 (DnFTI) in this contribution. The DnFTI has connectivity with the 391 lower network layer, which in turn provides deterministic services 392 within a subnetwork based on the TSN model. 394 For instance, IEEE 802.1Q with extensions for TSN establish streams 395 to transport DnFlows. For stream reservation the Resource- 396 Allocation-Protocol (RAP) [RAP_IEEE] has defined the Reservation- 397 Service-Interface (RSI). 399 The following figure illustrates the information flow within a DetNet 400 end system and a DetNet relay node for the establishment of 401 deterministic end-2-end services. 403 DetNet DetNet 404 End System Relay Node 405 +------------+ 406 |Time | 407 |Sensitive | 408 |Application | 409 +------------+ 410 | dQoS | 411 | | 412 |C S| 413 | | 414 | DnFSI | 415 +------------+ +-------------+ 416 | RSVP TSN |<---------------------------------->| RSVP TSN | 417 +------------+ +-------------+ 418 | DnFTI | | | | | 419 | | | | | | 420 |M&A S| |M S| |M S| 421 | | | | | | 422 +-------------+ +-----------------------+ +-------------+ 423 | Lower Layer |<===>| Lower Layer |<===>| Lower Layer | 424 | TSN aware | | TSN aware Subnetwork | | TSN aware | 425 +-------------+ +-----------------------+ +-----+ +-----+ 427 <---> DnFlow Signaling Service 428 <===> Lower layer transport stream/flow reservation service 429 <===> TSN Stream Reservation 430 dQoS Deterministic QoS time sensitive application interface 431 DnFSI DnFlow-Service-Interface (upper API of RSVP TSN) 432 DnFTI DnFlow-Transport-Interface(lower API of RSVP TSN) 433 C Control 434 S Signaling 435 M&A Maps and Aggregation 437 Figure 4: Layer Interactions between RSVP TSN and lower 438 layer network supporting TSN 440 4.2. API for Deterministic QoS (dQoS) 442 The description of a generalized API to support deterministic QoS is 443 not part of this document. 445 4.3. DnFlow Signaling Interface (DnFSI) 447 The definition of the DnFSI and the DnFTI is based on the DnFlow 448 information model [ID-detnet-flow-information-model]. 450 This interface is oriented on the interface specified by RSVP-IntServ 451 (RFC 2205). Most of the changes are due to mapping resource 452 reservation styles (see Section 3.2). 454 Sender 456 Call: Open Session (oriented to the RSVP-IntServ interface) 458 Request parameter (make use of pieces from the 459 DnFlowSpecification) 461 - DestinationIpAddress, Protocol, DestinationPort 463 Response parameter: 465 - SessionID 467 Call: Add DnFlow 469 Request parameter (make use of pieces from the 470 DnFlowSpecification) 472 - SessionID, SourceIpAddress, SourcePort, DSCP 474 - DnTrafficSpecification: Interval, MaxPacketsPerInterval, 475 MaxPayloadSize, MinPayloadSize 477 - DnFLowRank 479 - Select one of the Resource Style: Distinct, Shared, 480 CoordinatedShared 482 - Data TTL, PATH MTU size, LossRate 484 Notes for new parameter: 486 The DSCP is required to map DnFlows according their service class 487 to offered service classes of the lower layer. 489 The resource style for an DnFlow is announced by the sender within 490 the path message. 492 The LossRate is accumulated per DnFlow from Sender to Receiver. 494 Upcall: DnFlow 496 - Session ID 498 - One of the Info_type: RESV_EVENT; PATH_ERROR 500 Receiver 502 Call: Open Session 504 Request parameter (make use of pieces from the 505 DnFlowSpecification) 507 - DestinationIpAddress, Protocol, DestinationPort 509 Response parameter 511 - SessionID 513 Call: Join DnFlow 515 Request parameter 517 - SessionID 519 - Select one of the DnFlow Source Selection: Wildcard, List of 520 explicit sources with SourcePort 522 - MaximumPacketSize 524 - Extended Traffic Specification: MaximumExpectedLatency 526 Notes for new parameter: 528 The Source Selection is split from the RSVP-IntServ Reservation 529 Style but still follows the rules defined by RSVP-IntServ. 531 The extended traffic specification MaximumExpectedLatency is 532 propagated and merged to a minimum upstream from receiver to 533 sender. 535 Upcall: DnFlow 537 - SessionID 539 - SourceIpAddress (Sender) 541 - SourcePort 543 - One of the Info_type: RESV_EVENT; PATH_ERROR 545 General 547 Call: Close Session 549 Request parameter 551 - SessionID 553 4.4. DnFlow Transport Interface (DnFTI) 555 Sender 557 Call: Add DnFlow 559 Request parameter 560 - SessionID, Interface, DnFlowID, DestinationIpAddress, DSCP 562 - DnTrafficSpecification: Interval, MaxPacketsPerInterval, 563 MaxPayloadSize, MinPayloadSize, MinPacketsInterval 565 - One of the Resource Styles: Distinct, Shared, Coordinated 566 Shared 568 Response parameter 570 - TransportFlowID (TSN StreamID) 572 Notes for new parameter: 574 The DnFlowID is a local parameter to correlate DnFlows to 575 transport flows (e.g., TSN Stream). 577 The TransportFlowID correlates the DnFlow to the lower layer 578 transport flow, e.g., TSN Stream ID. 580 Upcall: DnFlow 582 Response parameter 584 - SessionID 586 - TransportFlowID 588 - One of the Info_type: RESV_EVENT, RES_MODIFY_EVENT 590 Receiver 592 Call: Join DnFlow 594 Request parameter 596 - SessionID, Interface, DnFlowID, TransportFlowID 598 - MaximumPacketSize 600 - Extended Traffic Specification: MaximumExpectedLatency 602 Notes for new parameter: 604 (see notes above) 606 Upcall: DnFlow 607 Response parameter 609 - SessionID, TransportFlowID 611 - One of the Info_type: ANNOUNCE_EVENT, ANNOUNCE_MODIFY_EVENT 613 4.5. RSVP TSN Message Formats 615 TBD 617 5. Security Considerations 619 Editor's note: This section needs more details. 621 6. IANA Considerations 623 N/A 625 7. Conclusion 627 This draft outlines recommended changes to RSVP signaling in the form 628 of RSVP TSN for a better alignment of the Layer 3 signaling with that 629 of emerging Layer 2 solutions, together with suggested API 630 specifications for the realization of the L3 to L2 interfaces in 631 endpoints. 633 8. References 635 8.1. Normative References 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, DOI 639 10.17487/RFC2119, March 1997, . 642 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 643 "Deterministic Networking Architecture", RFC 8655, DOI 644 10.17487/RFC8655, October 2019, . 647 [RFC2212] Shenker, S., Partridge, C., and Guerin, R., "Specification 648 of Guaranteed Quality of Service", RFC 2212, September 649 1997. 651 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jasmin, " 652 Resource ReSerVation Protocol (RSVP) -- Version 1 653 Functional Specification", RFC 2205, September 1997. 655 [RFC8655] N. Finn, B. Thubert, B. Vargas, J. Farkas, "Deterministic 656 Networking Architecture", RFC8655, October 2019 658 [RFC8938] B. Varga, Ed, J. Farkas, L. Berger, A. Malis, S. Bryant, 659 "Deterministic Networking (DetNet) Data Plane Framework", 660 RFC8938, November 2020. 662 8.2. Informative References 664 [ID.malis-detnet-controller-plane-framework] A. Malis, X. Geng, M. 665 Chen, F. Qin, B. Varga, "Deterministic Networking (DetNet) 666 Controller Plane Framework", draft-malis-detnet- 667 controller-plane-framework-05 (work in progress), 2020 669 [ID-detnet-flow-information-model] Balazs Varga, Janos Farkas, Rodney 670 Cummings, Yuanlong Jiang, Don Fedyk, "DetNet Flow and 671 Service Information Model", draft-ietf-detnet-flow- 672 information-model-14 (work in progress), 2021 674 [CHEN-IEEE] F. Chen, F.J. Goetz, M. Kiessling, J. Schmitt, " Support 675 for uStream Aggregation in RAP (ver 0.3)" (work in 676 progess), Jan 2019, 677 680 [RAP_IEEE] IEEE, "P802.1Qdd - Resource Allocation Protocol", (work in 681 progress), 683 [ID-trossen-detnet-control-signaling] D. Trossen, F.-J. Goetz, J. 684 Schmitt, "DetNet Control Plane Signaling", draft-trossen- 685 detnet-control-signaling-01 (work in progress), 2021 686 Authors' Addresses 688 Dirk Trossen 689 Huawei Technologies Duesseldorf GmbH 690 Riesstr. 25C 691 80992 Munich 692 Germany 694 Email: Dirk.Trossen@Huawei.com 696 Franz-Josef Goetz 697 Siemens AG 698 Gleiwitzer-Str. 555 699 90475 Nuremberg 700 Germany 702 Email: franz-josef.goetz@siemens.com 704 Juergen Schmitt 705 Siemens AG 706 Gleiwitzer Str. 555 707 90475 Nuremberg 708 Germany 710 Email: juergen.jues.schmitt@siemens.com