idnits 2.17.1 draft-trossen-detnet-control-signaling-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 : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 550 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 (October 23, 2020) is 1279 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: 'ID.malis-detnet-controller-plane-framework-03' is mentioned on line 85, but not defined == Unused Reference: 'ID.malis-detnet-controller-plane-framework-04' is defined on line 797, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-malis-detnet-controller-plane-framework-04 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: April 25, 2021 J. Schmitt 6 Siemens 7 October 23, 2020 9 DetNet Control Plane Signaling 10 draft-trossen-detnet-control-signaling-00.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-detnet 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 INTERNET DRAFT DetNet Control Plane Signaling 45 Copyright and License Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 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 Distributed Control in Bridged TSN-based Ethernet Deployment . 3 65 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2 RAP Reservation in TSN vs RSVP IntServ Model . . . . . . . . 4 67 2.3 Interactions between L2 and L3 . . . . . . . . . . . . . . . 5 68 2.4 Similarities and Differences between RSVP and RAP . . . . . 6 69 2.5. RSVP-DetNet . . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.6. API Specifications . . . . . . . . . . . . . . . . . . . . 9 71 3. Centralized Control Signaling in SDN Domain . . . . . . . . . . 16 72 4. Hybrid Control Signaling in SDN Domain . . . . . . . . . . . . 16 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 75 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8.1 Normative References . . . . . . . . . . . . . . . . . . . 17 78 8.2 Informative References . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 INTERNET DRAFT DetNet Control Plane Signaling 83 1 Introduction 85 The authors in [ID.malis-detnet-controller-plane-framework-03] 86 provide an overview of the DetNet control plane architecture along 87 three 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. We structure the 90 following sections of this draft along those three classes in order 91 to present example solutions for each class of the DetNet control 92 plane architecture. Specifically, Section 2 will present a solution 93 for a Bridged Ethernet deployment scenario. We will introduce changes 94 to RSVP with the proposal for an RSVP-DetNet model that splits 95 resource style and sender selection between sender and receiver, 96 unlike in RSVP for IntServer, for an optimized realization of L2 97 integrations. 99 Section 3 will present a solution that realizes a centralized SDN- 100 based approach for switched Ethernet deployment scenarios. 102 Section 4 will finally outline a hybrid solution in an SDN domain 103 with path allocation through signaling and switching configuration as 104 a centralized solution. 106 At this stage, Section 3 and 4 will be detailed in future updates to 107 the draft. 109 1.1 Terminology 111 This document uses the terminology established in the DetNet 112 Architecture [RFC8655], and the reader is assumed to be familiar with 113 that document and its terminology. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2 Distributed Control in Bridged TSN-based Ethernet Deployment 121 The first solution addresses deployments of bridged TSN-based 122 customer Ethernet network, possibly interconnected through DetNet IP 123 flows for multi-site deployment. 125 2.1 Overview 127 Figure 1 provides an example deployment of TSN-based Ethernet edge 128 (customer) networks, using the RSVP/RAP combined signaling presented 129 in the following sections. The customer sites are interconnected via 130 edge routers that aggregate DetNet IP flow requirements from hosts 132 INTERNET DRAFT DetNet Control Plane Signaling 134 for reservation of aggregated flows within the core network. 136 Starting point from an DetNet perspective is the RSVP IntServ model 137 with guaranteed QoS. Resource Allocation Protocol (RAP), as defined 138 in [RAP_IEEE], is an example of a target lower layer reservation 139 mechanism. In this section, we focus on the necessary integration of 140 the RSVP and RAP concepts to enable such (and similar) deployment. 142 +-------+ 143 +-------+ 144 +-----+ +-------+ +-------+ +-------+ +-----+ 145 |RSVP/| |DetNet | +------+ | DetNet| +------+ |DetNet | |RSVP/| 146 |RAP |-|IP Flow| |Edge | |IP Flow| |Edge | |IP Flow|-|RAP | 147 |Node | | Edge |--|Router|-| Core |-|Router|--| Edge | |Node | 148 +-----+ |Network| +------+ |Network| +------+ |Network| +-----+ 149 +-------+ +-------+ +-------+ 150 Figure 1 : IP + Bridged Ethernet Within Customer Networks 152 2.2 RAP Reservation in TSN vs RSVP IntServ Model 154 Layer2 reservation in TSN-based networks is supported through RAP, 155 providing a maximum of 8 classes of traffic where the frame priority 156 code point (PCP) is used to select the Resource Allocation (RA) class 157 at the ingress bridge. Streams within a single RA class are queued in 158 a single traffic class where the latency of the stream is guaranteed 159 per hop and per RA class. 161 This model contrasts with the RSVP IntServ [RFC2212] model, which 162 provides a flow bandwidth driven latency model with a separate 163 transmission queue per flow, not a class-based model like in the 164 aforementioned RAP model. 166 This difference in models poses a number of challenges: 168 1. Is RSVP IntServ (as defined in [RFC2212]) the right starting 169 point? 171 2. How to efficiently map the different reservation styles of RSVP 172 onto RAP? 174 3. What is the nature of the RSVP-RAP interface? 176 4. How is the binding between L3 signaling (RSVP IntServer) and L2 177 signaling (RAP ) realized, e.g., mapping of Stream-ID? 179 The following sub-sections elaborate on the various aspects in 180 addressing those challenges. 182 INTERNET DRAFT DetNet Control Plane Signaling 184 2.3 Interactions between L2 and L3 186 Figure 2 provides an overview of the interactions between L2 and L3 187 elements in a network deployment as an elaboration of the elements in 188 Figure 1. 190 The application utilizes an application-specific QoS API (qAPI) that 191 controls and signals the establishment of deterministic end-to-end 192 flows via the DetNet API (dAPI) between the L3 control plane entities 193 in the L3 end systems and routers, utilizing the dUNI, based on RSVP, 194 at Layer 3. 196 The DetNet lower API (dlAPI) maps the RSVP model onto the RAP model 197 and signals the establishment of appropriate L2 segments via the TSN 198 API (tAPI) between the L2 control plane entities of the end systems, 199 routers, and L2 bridges, utilizing the tUNI, based on RAP, at Layer 200 2. 202 The L2 CP entities in turn control the establishment of appropriate 203 resources on the HW bridge (with no specification for the handling of 204 resource reservations on the end systems). 206 Within the DetNet router (on the right side of Figure 2), the second 207 L2 control plane entity bridges to the second Ethernet sub-network. 209 +-----------+ 210 |Application| 211 +-----------+ 212 | qAPI | 213 C| |S 214 | duAPI | User Network DetNet Router 215 +-----------+ +-------------+ 216 | L3 CP |<**************************************>| L3 CP | 217 +-----------+ +-------------+ 218 |dlAPI | | | | | 219 M&A| |S M| S| M| S| 220 | tAPI | Bridge Bridge | | | | 221 +-----------+ +-----------+ +-----------+ +-----+ +-----+ 222 | L2 CP |<===>| L2 CP | | L2 CP |<===>|L2 CP| |L2 CP| 223 +-----------+ +-----------+ +-----------+ +-----+ +-----+ 224 | | | | | 225 C| C| C| C| C| 226 | | | | | 227 +-----------+ +-----------+ +-----------+ +-------------+ 228 |HW Endpoint|-----| HW Bridge |----| HW Bridge |-----| HW Router + 229 +-----------+ +-----------+ +-----------+ +-------------+ 231 INTERNET DRAFT DetNet Control Plane Signaling 233 ***** L3 Signaling Control Protocol DetNet UNI (dUNI RSVP) 234 ===== L2 Reservation Control Protocol TSN UNI (tUNI IEEE P802.1Qdd) 236 HW Hardware CP Control Plane 237 qAPI QoS API duAPI DetNet upper API 238 dlAPI DetNet lower API tAPI TSN API 239 C Controls S Signals 240 M&A Maps and Aggregation 242 Figure 2 : Interaction between L2 and L3 244 Based on the above interactions, the main body of work is the 245 proposed change to RSVP, dubbed RSVP-DetNet, for an efficient mapping 246 of L3 to L2, and motivated in Section 2.5, while we will present the 247 various API specifications in Figure 2 throughout Section 2.6, 248 including an example mapping between dlAPI and RAP in Section 2.6.3. 250 Before doing so, we will outline similarities and differences in the 251 RSVP and RAP models at Layer 3 and 2, respectively. 253 2.4 Similarities and Differences between RSVP and RAP 255 The following sub-sections will outline various aspects to be 256 considered when designing the RSVP-RAP interface, namely the 257 assumptions on network nodes (Section 2.4.1), the mapping of the 258 latency model used in both models (Section 2.4.2), the dealing with 259 latency margins (Section 2.4.3), the dealing with Jitter and non- 260 shaping nodes (Section 2.4.4), and the mapping of resource 261 reservation styles (Section 2.4.5). 263 2.4.1 Assumptions on Network Nodes 265 RSVP assumes three different nodes over which a reservation can be 266 done, namely 267 - Shaping node, which implements the RSVP signaling and shaping on 268 the data plane, 270 - None shaping node, which implements the RSVP signaling and is 271 capable of estimating the latency caused by this node 273 - Legacy node, which does neither implement RSVP nor any shaping. 275 RAP assumes properties common to all nodes within a reservation 276 domain: 277 - All nodes take part in the signaling process 279 INTERNET DRAFT DetNet Control Plane Signaling 281 - Different data plane architectures are supported albeit limited to 282 those defined in IEEE 802.1Q. 284 - Bridging between different (heterogeneous) data planes is achieved 285 through a peer-to-peer model where every upstream node is a talker 286 for the next downstream node. 288 2.4.2 Mapping of Latency Model 290 RSVP assumes a weighted fair queuing (WFQ) at the data plane, where a 291 listener is able to influence therefore the latency through the 292 reserved bandwidth per flow. 294 RAP assumes one traffic class with given interference per common RA 295 class, resulting in a per hop latency for all stream within a single 296 RA class. The E2E latency is just signaled by accumulating hop 297 latency while the allowed interference determines the amount of 298 allowed flow per RA class. Here, the listener is unable to influence 299 the latency but the stream requirement is signaled upstream. 301 2.4.3 Dealing with Latency Margins 303 RSVP provides the notion of slack [RFC2212] per flow, which can be 304 consumed by the processing node in the network to enable additional 305 reservations. 307 In RAP, every listener of a stream propagates its required latency 308 upstream to the talker. Latency margins are not handled directly by 309 RAP, while the per hop latency of an RA class is preconfigured by 310 management. In each node, the per RA class upstream required latency 311 of all streams can be used to locally calculate the latency margins 312 per hop. The management system can then use this information to 313 adjust the per hop maximum latency at runtime. 315 2.4.4 Dealing with Jitter and Non-Shaping Nodes 317 RSVP has two different parameters to propagate the maximum non- 318 conformance to the leaky bucket model introduced through jitter and 319 non-shaping nodes. These can be accumulated by non-shaping nodes, 320 i.e., those which implement the RSVP protocol but are not performing 321 shaping at the data plane. 323 Within RAP, there is no distinction between shaping and non-shaping 324 nodes since all nodes adhere to the data plane architecture defined 325 in IEEE 802.1Q. Heterogeneous data planes are possible as long as 326 assurances to the next hop can be upheld, while RA class attributes 327 are used to propagate data plane behavior (e.g., shaper) to the next 329 INTERNET DRAFT DetNet Control Plane Signaling 331 neighbor. 333 2.4.5 Mapping Resource Reservation Styles 335 RSVP uses the notion of 'sessions', which are able to maintain 336 different kinds of end-to-end connectivity and resource styles, 337 namely fixed (i) filter style, (ii) shared explicit style, and (iii) 338 wildcard filter style - see [RFC2205]. It is important to note that 339 in RSVP, both sender selection and resource styles are controlled by 340 the receiver; we return to this issue in our next section. 342 RAP supports only distinct explicit mode of reservation, while in 343 principle supporting reservation between one talker and multiple 344 listeners or one listener and multiple scheduled talkers. Bridged 345 Ethernet technology is also able to support the shared resource 346 modes. 348 || Resource Style | 349 Sender || | 350 Selection || Distinct | Shared | Coordinated Shared | 351 -----------------||-------------|-------------|--------------------| 352 || | | | 353 Explicit || supported | supported | supported | 354 -----------------||-------------|-------------|--------------------| 355 || | | | 356 Wildcard || | supported | | 357 -----------------||------------------------------------------------| 358 Figure 3 : Resource Style and Sender Selection [RFC2205] 360 2.5. RSVP-DetNet 362 In this section, we motivate the introduction of a new signaling 363 model for RSVP in combination with sub-nets like TSN. We outline 364 first the rationale for its introduction before outlining the 365 proposed changes. 367 2.5.1. Rationale 369 Continuing from Section 2.4.5. , in RSVP (for IntServ), the receiver 370 initiates resource style and sender selection through the Resv 371 message being sent upstream, while path state being setup through the 372 Path message from the sender to the receiver upon receiving the Resv 373 message. 375 When looking into an integration with lower layer APIs, such as the 376 TSN API, we identify key differences in WHEN these lower layer APIs 377 decide if a reservation is possible: 379 INTERNET DRAFT DetNet Control Plane Signaling 381 1. For a new Announce downstream, each L2 node decides that if this 382 stream was reserved at this port, would there be enough resources 383 available to do so? 385 2. For a new Attachment upstream, each L2 node will lock the required 386 resources and bandwidth exclusively for this stream. For every L2 387 node local non-locked Announce, the L2 node will decide the same 388 question as in item 1 and refresh and propagate the necessary 389 states accordingly. 391 It is important to note that steps 1 and 2 only work if the 'resource 392 style' is already known by the Announce propagation. 394 2.5.2. Splitting Control over Resource Style and Sender Selection 396 In order to allow for an efficient resource reservation at the lower 397 network level by implementing the steps 1 and 2 in Section 2.5.1. , 398 we propose to split the control over 'resource style' and 'sender 399 selection' in that in RSVP-DetNet the sender controls the 'resource 400 style' and the listener controls the 'sender selection'. 402 2.5.3. Coordinated Shared Resource Style 404 Independent from the efficient realization of lower layer resource 405 reservation, we have also identified a requirement in industrial use 406 cases to support a large amount of deterministic connections with 407 small data usage. In those cases, separate reservation for each 408 connection could be inefficient. 410 To address this, we propose to introduce another 'resource style' 411 called 'Coordinated Shared', which would indicate the use of 412 scheduling (of those many deterministic connections) at L2-Listener 413 and L3-Receiver level. A first proposal for a solution in the TSN RAP 414 protocol was presented to the IEEE in [CHEN-IEEE] 416 2.6. API Specifications 418 The following sub-sections describe the upper and lower Interfaces, 419 following the proposed RSVP-DetNet changes, and provides an example 420 mapping of the RSVP lower API to RAP in a TSN setup. 422 2.6.1. RSVP-DetNet upper API (duAPI) 424 The RSVP-DetNet interface is oriented on the interface specified by 425 RSVP-IntServ (RFC 2205). Most of the changes are due to mapping 426 resource reservation styles (see chapter 2.4.5). 428 Sender 430 INTERNET DRAFT DetNet Control Plane Signaling 432 Call: Open L3 Session (oriented to the RSVP-IntServ interface) 434 Request parameter: 436 - Flow destination IP address, Protocol ID, Destination Port 438 Response parameter: 440 - L3 Session ID (local handle) 442 Call: Add IP Flow 444 Request parameter 446 - L3 Session ID, Sender source IP address, Source Port, DSCP 448 - Traffic Specification: Maximum IP packet size (per flow, <= 449 MTU), Minimum IP packet size, Burstiness, IP packet information 450 rate 452 - Select one of the Resource Style: Distinct, Shared, Coordinated 453 Shared 455 - Data TTL, PATH MTU size, Loss Rate 457 Notes for new parameter: The DSCP is required to map IP flows 458 according their service class to offered service classes of the 459 lower layer. 461 The traffic specification is enhanced by Minimum IP packet size for 462 optimization interference calculation. 464 The resource style for an IP flow is announced by the sender within 465 the path message. 467 The Loss Rate is accumulated per IP Flow. 469 Upcall: IP Flow 471 - L3 Session ID 473 - One of the Info_type: RESV_EVENT; PATH_ERROR 475 Receiver 477 Call: Open L3 Session 479 Request parameter 481 INTERNET DRAFT DetNet Control Plane Signaling 483 - Flow destination IP address, Protocol ID, Destination Port 485 Response parameter 487 - L3 Session ID 489 Call: Attach IP Flow 491 Request parameter 493 - L3 Session ID 495 - Select one of the IP flow Source Selection: Wildcard, List of 496 explicit sources with Source Port 498 - Maximum packet size 500 - Extended Traffic Specification: Maximum Expected Latency 502 Notes for new parameter: The Source Selection is split form the 503 RSVP-IntServ Reservation Style but still follows the rules defined 504 by RSVP-IntServ. The extended traffic specification Maximum 505 Expected Latency is propagated and merged to a minimum upstream 506 form receiver to sender. 508 Upcall: IP Flow 510 - L3 Session ID 512 - One of the Info_type: RESV_EVENT; PATH_ERROR 514 General 516 Call: Close L3 Session 518 Request parameter 520 - L3 Session ID 522 2.6.2. RSVP-DetNet lower API (dlAPI) 524 The RSVP-DetNet lower API shall be lower layer network technology 525 neutral. 527 Sender 529 Call: Add Flow 531 INTERNET DRAFT DetNet Control Plane Signaling 533 Request parameter 535 - L3 Session ID, Interface, L3 Flow handle, Flow destination IP 536 address, DSCP 538 - Traffic Specification: Maximum IP packet size, Minimum IP 539 packet size, Burstiness, IP packet information rate 541 - One of the Resource Styles: Distinct, Shared, Coordinated 542 Shared 544 Response parameter 546 - Transport Flow Identification 548 Notes for new parameter: 550 The L3 Flow handle is a local parameter to correlate IP Flows to 551 transport flows. 553 The Transport Flow Identifier correlates the IP flow to the lower 554 layer transport flow e.g. TSN Stream ID. 556 Upcall: Flow 558 Response parameter 560 - L3 Session ID, Transport Flow Identification 562 - One of the Info_type: RESV_EVENT, RES_MODIFY_EVENT 564 Receiver 566 Call: Attach Flow 568 Request parameter 570 - L3 Session ID, Interface, L3 Flow handle, Transport Flow 571 Identification, Maximum packet size 573 - Extended Traffic Specification: Maximum expected latency 575 - One of the Info_type: ANNOUNCE_EVENT, ANNOUNCE_MODIFY_EVENT 577 Notes for new parameter: 579 (see notes above) 581 INTERNET DRAFT DetNet Control Plane Signaling 583 Upcall: Flow 585 Response parameter 587 - L3 Session ID, Transport Flow Identification 589 - One of the Info_type: ANNOUNCE_EVENT, ANNOUNCE_MODIFY_EVENT 591 2.6.3. Example tAPI on RAP defined by IEEE 802.1Q 593 The following section defines a preliminary interface for RAP (IEEE 594 P802.1Qdd). Currently RAP draft version 0.3 is available and the 595 service interface of RAP is not yet stable. 597 Call: Open L2 Reservation Group 599 Request parameter 601 - Stream destination MAC address (unicast or multicast 603 - VLAN 605 - PCP 607 Response parameter 609 Low-Layer Group ID (local handle) 611 Notes: 613 RAP identifies its session by destination MAC address, VLAN and 614 PCP. 616 Call: Close L2 Reservation Group 618 Request parameter 620 - Low-Layer Group ID 622 Talker 624 Call: Add Stream 626 Request parameter 628 - Low-Layer Group ID 630 INTERNET DRAFT DetNet Control Plane Signaling 632 - Stream Identification 634 - Traffic Specification Template 636 - Resource Style (Distinct, Shared, Coordinated Shared) 638 - End-System/End-Station source MAC addres 640 - End-System/End-Station destination MAC address (extension for 641 Coordinated Shared) 643 - Sync Domain ID (extension for Coordinated Shared) 645 - PATH Max frame size 647 - Talker Loss Rate 649 Notes: 651 Traffic Specification Template is queue drain algorithm dependent 653 For efficient mapping it has advantages when RAP supports all 654 Resource Styles 656 The Resource Style "Coordinated Shared" allows only one destination 657 and all nodes must belong to the same sync domain 659 PATH MTU frame size is determined downstream from Talker to 660 Listener 662 The Loss Rate is accumulated per Stream. 664 Call: Modify Stream 666 Request parameter 668 - Low-Layer Group ID 670 - Stream Identification, 672 - Traffic Specification Template 674 Call: Release Stream 676 Request parameter 678 - Low-Layer Group ID 680 INTERNET DRAFT DetNet Control Plane Signaling 682 - Stream Identification 684 Upcall: Stream 686 Response parameter 688 - Low-Layer Group ID, Stream Identification 690 - One of the Info_type: RESV_EVENT, RESV_MODIFY_EVENT 692 Listener 694 Call: Attach Stream 696 Request parameter 698 - Low-Layer Group ID, 700 - Stream Identification 702 - Maximum frame size 704 - Schedule Specification (extension for Coordinated Shared) 706 - Extended Traffic Specification: Maximum expected latency 708 Notes: 710 Schedule Specification includes the schedule for the group of 711 Steams which are coordinated by synchronization 713 Maximum frame size will be delivered upstream from Listener to 714 Talker 716 Call: Attach Modify Stream 718 Request parameter 720 - Low-Layer Group ID 722 - Stream Identification 724 - Schedule Specification (extension only for Coordinated Shared) 726 INTERNET DRAFT DetNet Control Plane Signaling 728 Call: Release Stream 730 Request parameter 732 - Low-Layer Group ID 734 - Stream Identification 736 Upcall: Stream 738 Response parameter 740 - Low-Layer Group ID 742 - Stream Identification 744 - One of the Info_type: ANNOUNCE_EVENT, ANNOUNCE_MODIFY_EVENT 746 3. Centralized Control Signaling in SDN Domain 748 For future work. 750 4. Hybrid Control Signaling in SDN Domain 752 For future work. 754 5. Security Considerations 756 Editor's note: This section needs more details. 758 6. IANA Considerations 760 N/A 762 7. Conclusion 764 This draft outlines the possible control plane signaling in 765 deterministic networking environments for distributed, centralized 766 and hybrid deployments. For the first, we have proposed the 767 introduction of RSVP-detnet for a better alignment of the Layer 3 768 signaling with that of emerging Layer 2 solutions, together with 769 suggested API specifications for the realization of the L3 to L2 770 interfaces in endpoints. 772 8. References 773 INTERNET DRAFT DetNet Control Plane Signaling 775 8.1 Normative References 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, DOI 779 10.17487/RFC2119, March 1997, . 782 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 783 "Deterministic Networking Architecture", RFC 8655, DOI 784 10.17487/RFC8655, October 2019, . 787 [RFC2212] Shenker, S., Partridge, C., and Guerin, R., "Specification 788 of Guaranteed Quality of Service", RFC 2212, September 789 1997. 791 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jasmin, " 792 Resource ReSerVation Protocol (RSVP) -- Version 1 793 Functional Specification", RFC 2205, September 1997. 795 8.2 Informative References 797 [ID.malis-detnet-controller-plane-framework-04] A. Malis, X. Geng, M. 798 Chen, F. Qin, B. Varga, "Deterministic Networking (DetNet) 799 Controller Plane Framework", draft-malis-detnet- 800 controller-plane-framework-04 (work in progress), 2020. 802 [CHEN-IEEE] F. Chen, F.J. Goetz, M. Kiessling, J. Schmitt, " Support 803 for uStream Aggregation in RAP (ver 0.3)" (work in 804 progess), Jan 2019, 805 808 [RAP_IEEE] IEEE, "P802.1Qdd - Resource Allocation Protocol", (work in 809 progress), 811 Authors' Addresses 813 Dirk Trossen 814 Huawei Technologies Duesseldorf GmbH 815 Riesstr. 25C 816 80992 Munich 817 Germany 819 Email: Dirk.Trossen@Huawei.com 821 INTERNET DRAFT DetNet Control Plane Signaling 823 Franz-Josef Goetz 824 Siemens AG 825 Gleiwitzer-Str. 555 826 90475 Nuremberg 827 Germany 829 Email: franz-josef.goetz@siemens.com 831 Juergen Schmitt 832 Siemens AG 833 Gleiwitzer Str. 555 834 90475 Nuremberg 835 Germany 837 Email: juergen.jues.schmitt@siemens.com