idnits 2.17.00 (12 Aug 2021) /tmp/idnits51171/draft-trossen-bier-frrm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 February 2022) is 82 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) == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-12 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER D. Trossen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track 21 February 2022 5 Expires: 25 August 2022 7 Realizing Forward Requests Return Multicast Semantic with BIER 8 draft-trossen-bier-frrm-00 10 Abstract 12 This document introduces a semantic for multicast that is based on 13 initiating forward requests, resulting in dynamic return multicast to 14 the set of initiating clients. The key dynamic nature here is 15 represented in the return multicast being possibly different for 16 every transmission. 18 We introduce this semantic more formally, present exemplifying use 19 cases and then focus on realizing this semantic using BIER 20 technology. 22 Although this document formally introduces the FRRM semantic as a new 23 communication semantic, it does not intend to show the realization of 24 it through any other means besides BIER. This is left for separate 25 documents, if desired. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 25 August 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Definition of FRRM Semantic . . . . . . . . . . . . . . . . . 4 63 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. HTTP-based Streaming . . . . . . . . . . . . . . . . . . 5 65 4.2. Intra-CDN Content Distribution . . . . . . . . . . . . . 6 66 4.3. Distributed Reasoning . . . . . . . . . . . . . . . . . . 6 67 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. BIER Architecture . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Description of a BIER Multicast Overlay . . . . . . . . . 8 70 6.2. BIER Multicast Overlay Components . . . . . . . . . . . . 9 71 7. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9 72 7.1. BIER Multicast Overlay Operations . . . . . . . . . . . . 9 73 7.2. Achieving Multicast Responses . . . . . . . . . . . . . . 11 74 7.3. BIER Multicast Overlay Traffic Management . . . . . . . . 12 75 8. Upper Layer Considerations . . . . . . . . . . . . . . . . . 13 76 8.1. Application (Protocol) Considerations . . . . . . . . . . 13 77 8.2. Transport Protocol Considerations . . . . . . . . . . . . 13 78 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 14. Informative References . . . . . . . . . . . . . . . . . . . 14 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 Multicast communication semantics complements unicast communication 89 with the ability to define the delivery of packets to more than one 90 destination. For instance, [RFC4607] defines source-specific 91 multicast (SSM) as 93 A datagram sent with source IP address S and destination IP 94 address G in the SSM range is delivered to each host socket that 95 has specifically requested delivery of datagrams sent by S to G, 96 and only to those sockets. 98 The nature of the 'specific request' for delivery is reflected in an 99 explicit group management protocol, e.g., [RFC4604] through which a 100 host can request that delivery, becoming a member of the group 101 (address) G as a consequence. 103 In this document, we introduce a different multicast semantic where 104 the nature of the 'specifically requested delivery' is that of a 105 forward request to the server S, which in response either adds the 106 response to that request to an existing multicast group or forms a 107 new one on-demand. The nature of the multicast group, equivalent to 108 G in [RFC4607], is ephemeral, limited by the time it takes to send a 109 response to the (dynamically created) group of respondents. 111 Multicast semantics of the aforementioned nature have been exploited 112 and realized in previous work, such as [ICC2016] [POINT2016], 113 focussing on HTTP-based forward requests with multicast-delivered 114 HTTP responses. 116 These works were transferred onto a BIER-based systems in a previous 117 draft [I-D.ietf-bier-multicast-http-response]. Similarly, this draft 118 focussed entirely on the delivery of HTTP responses under such 119 multicast semantic, progressing to WG last call in 2021. Due to 120 organizational reasons on the side of (some of) the authors of this 121 draft, comments from the BIER and application area community were not 122 be possible to address with the draft finally abandoned in 2022. 124 This document aims to take this initial work in 125 [I-D.ietf-bier-multicast-http-response] further by (a) formally 126 defining the underlying communication semantic for use across a 127 number of use cases, (b) outline use case examples beyond 'just 128 HTTP', (c) formulate requirements for its realization and (d) outline 129 the realization in BIER. 131 2. Abbreviations 133 The following abbreviations are used throughout the remainder of this 134 draft, with reference to [RFC8279] and [I-D.ietf-bier-te-arch] for 135 the definition (and technical explanation) of those terms: 137 BFER : Bit-Forwarding Egress Routers 139 BFIR : Bit-Forwarding Ingress Routers 141 BFR : Bit-Forwarding Routers 143 PCE : Path Computation Element 145 SH : Service Handler 146 NAP : Network Access Point 148 3. Definition of FRRM Semantic 150 As the name FRRM (forward requests return multicast) indicates, 151 multicast communication under this semantic is initiated through one 152 or more forward request communication, i.e., from one or more of the 153 eventual receivers of the multicast response(s). 155 More formally, we define the FRRM semantic as 157 A datagram with source address S towards destinations D1, ..., Dn 158 is formed as one or more responses to adequate requests from D1, 159 ..., Dn to S, where the ephemeral group address R is defined 160 through an identifying characteristic across all received requests 161 from D1, ..., Dn. 163 Where 165 'identifying characteristic' is an implementation-specific 166 parameter used to distinguish among different requests (e.g., 167 identifiers such as URIs) from any of the D1, ..., Dn to S. 169 The nature of FRRM multicast is inherently dynamic, i.e., the 170 multicast responses are formed in response to incoming requests. One 171 or more responses may be created for the ephemeral group that is 172 being formed, thereby supporting request-response patterns as much as 173 initiated streaming patterns (i.e. a single request may lead to a 174 stream of responses). 176 The ephemeral groups are not unique but several may exist with 177 different receiver groups each. This may happen when a set of 178 forward requests arrives before time t_1, upon which the server S 179 decides to form the ephemeral group R towards the senders of those 180 requests, while another group R may be formed for those incoming 181 forward requests arriving after time t_1 and before another 182 checkpoint time t_2. 184 The decision when to form an ephemeral group R as a result of 185 incoming forward requests is entirely left to the implementation 186 considerations at the server S and may depend on the specific use 187 case (see Section 4). 189 4. Use Cases 191 This section expands on the original HTTP-focussed use case in 192 [I-D.ietf-bier-multicast-http-response] (still listed as an example 193 in Section 4.1) through utilizing the FRRM semantic in, e.g., CDN 194 optimization, distributed AI and more. 196 4.1. HTTP-based Streaming 198 Referring to the BIER Use Cases [I-D.ietf-bier-use-cases], multicast 199 is used to scale HTTP Live Streaming (HLS) to a large number of 200 receivers that use HTTP. Multicast can speed up both live and high- 201 demand VoD streaming. Adaptive Bit Rate IPMC [TR_IPMC_ABR] describes 202 the use of IP Multicast towards the CMTS or a box beside it, where 203 the content is converted to HTTP/TCP to stream to the receivers 204 (e.g., homes). A server hosting the HLS content is shown as "NAP 205 Server". The gateways acting as receivers for the multicast from the 206 server are shown as "Client-NAP" (CNAP). Each CNAP can serve 207 multiple clients. 209 Dynamic Adaptive Streaming (DASH) [ISO_DASH] over HTTP is another 210 HTTP-based streaming approach. In DASH, each media is described by a 211 Media Presentation Description (MPD) file, through which a DASH 212 client (e.g. a media player) is instructed how to download, interpret 213 and play the media. The media content is encoded into fragments or 214 chunks at different bit rates. Both the MPD and media fragments are 215 stored at a server. The DASH client first needs to retrieve the MPD 216 file from the server; then it can start to retrieve media fragments 217 encoded at different bits rates from the server. DASH players may 218 use rate adaptation, i.e., switching the retrieval from one rate 219 chunks to another rate. Usually this rate adaptation is utilizing 220 delay measurements, resulting in TCP like behavior in terms of 221 backoff in case of increasing delay. DASH has been designed to reuse 222 most of existing Internet infrastructure and protocols and can run 223 over different underlying transports including HTTP. For example, 224 two major media service providers Netflix and Youtube use DASH over 225 HTTP as their streaming technology. 227 HTTP request and response used in media streaming services like HLS 228 and DASH over HTTP, use HTTP responses for delivery of content, i.e., 229 each chunk is returned as an HTTP response to the requesting client. 230 In such scenarios, where semi-synchronous access to the same resource 231 occurs (such as watching prominent videos over Netflix or similar 232 platforms or live TV over HTTP), traffic grows linearly with the 233 number of viewers since the HTTP-based server will provide an HTTP 234 response to each individual viewer. This poses a significant burden 235 on operators in terms of costs and on users in terms of likely 236 degradation of quality. 238 The use of HTTP-based streaming of video content is not limited to 239 traditional TV broadcasting. Consider a virtual reality use case 240 where several users are joining a VR session at the same time, e.g., 241 centered around a joint event. Hence, due to the temporal 242 correlation of the VR sessions, we can assume that multiple requests 243 are sent for the same content at any point, particularly when viewing 244 angles of VR clients are similar or the same. Due to availability of 245 virtual functions and cloud technology, the actual end point from 246 where content is delivered may change. 248 HTTP streaming is not limited to video content, however. Software 249 updates for, e.g., mobile devices or vehicles, become increasingly 250 important, introducing point-to-multipoint traffic from a software 251 server to devices. Using V2X as an example, the software server 252 could be a part of telecom operators or maintained by car 253 manufacturers. In either case, the software server keeps vehicle 254 software or firmware images, which will be transmitted to many 255 vehicles across the global Internet, based on a pull or push model. 256 HTTP is commonly used for those software updates to provide an E2E 257 transport between the software server and each vehicle requesting 258 software updates. As a result, the traffic from the software server 259 to vehicles increases linearly with the number of connected vehicles 260 since each vehicle will establish a HTTP connection with the software 261 server. 263 4.2. Intra-CDN Content Distribution 265 More to come here based on the work outlined in [fCDN] 267 4.3. Distributed Reasoning 269 TODO: solicit a co-author with more background to cover this 271 5. Requirements 273 TBD: capture formal requirements here 275 6. BIER Architecture 277 Figure 1 shows the architecture for FRRM over a BIER overlay. 279 +---------+ +----+ +------+ 280 | | | | | |/ 281 + IP only +---+ SH |--| BFER +----| 282 |receiver | | | | |\ | 283 | UE | +-/\-+ +------+ | 284 +---------+ || | 285 || +----------+ +---------+ 286 || | | | | 287 |----- | BFR |---| BFR |------| 288 | | | | | | 289 | +----------+ +---------+ | 290 +---------+ +-------+ 291 | | | BFIR | 292 + BIER TE + |--------| | 293 | PCE | +---------+ +---+---+ +---+---+ 294 | |-|| | BFR |----| BFR | | 295 +---------+ || +-----+---| +-------+ +---+---+ 296 ||==============|====================>| SH | 297 || | +-------+ 298 +---------+ +---\/+ +----+ | /|\ 299 | | | | | |/ | | 300 + IP only +---+ SH +-+BFER+------| +----------+ 301 |receiver | | | | |\ | IP only | 302 +---------+ +-----+ +----+ | Sender | 303 | (Server) | 304 +----------+ 306 [SH : Service Handler, PCE : Path Computation Element] 308 Figure 1: BIER Architecture for FRRM 310 The multicast overlay is formed by the BFIR and BFER of the BIER 311 layer and the additional Service Handler (SH) and Path Computation 312 Element (PCE) elements shown in the figure. When interconnecting 313 with a non-BIER enabled IP routed peering network, a special SH, such 314 as Border Gateway may be used. 316 The Service Handler and BFER could be collocated, forming therefore 317 the equivalent of a Client or Server Network Attachment Point (CNAP 318 or SNAP) [TR_IPMC_ABR]. However, the SH may also be implemented in 319 the clients and servers directly, avoiding some of the realization 320 considerations discussed later, specifically those related to 321 security associations. Lastly, the SH may be provisioned separately 322 from both client/server and BFER/BFIR components. For instance, the 323 SH may be part of a CPE deployment, where special applications access 324 the FRRM capabilities, while utilizing a separate BIER overlay 325 deployment of a network operator. 327 Clients send and receive service transactions through the SH, i.e. 328 forward requests and the responses, possibly delivered via BIER 329 multicast capabilities. 331 The SH on the server side is responsible for aggregating the relevant 332 incoming forward requests and sending one or more BIER-based 333 multicast response to multiple clients who requested the same 334 content, following the FRRM semantic in Section 3. 336 6.1. Description of a BIER Multicast Overlay 338 The Service Handler (as in Figure 1) in BIER Multicast Overlay, 339 process the service request. At the service level, e.g., for an HTTP 340 service, the fixed relationship among consumer and providers may be 341 abstracted using "Service Names", and the changing relationship at 342 the Service execution endpoints can be managed at the "multicast 343 overlay" level, handing out the exact locations where service 344 requests or responses needs to be sent to BIER layer. 346 +-------------+ +-----------+ +-----------+ 347 | | | | | PATH ID | 348 | Service name| | Multicast | | translates| 349 | [producer, |------->| Overlay |------>| to BIER | 350 | consumer] | | Layer | | header | 351 | | | | | | 352 +-------------+ +-----------+ +-----------+ 354 Figure 2: Service Name to Path ID Translation 356 It should be noted, a number of identifiers can be used as service 357 name, such as a URI or an IP address. In the example illustration, 358 other layers such as TCP, IP have been terminated at the egress 359 point. Outside BIER domain we terminate TCP/IP session to extract 360 the service name to be processed by the "multicast overlay" layer to 361 generate the PATH IDENTIFIER, which is used as BIER header. 363 Path Identifier or PATH ID, is used in path-based approach, which 364 utilizes path information provided by the source of the packet for 365 forwarding said packet in the network. This is similar to segment 366 routing albeit differing in the type of information provided for such 367 source-based forwarding. 369 Once the BIER header is determined and added at the BFIR, the rest of 370 the transport layers is assumed to be any underlay technology as 371 supported by BIER. We assume TCP friendly transport, which can 372 assure reliable delivery. 374 6.2. BIER Multicast Overlay Components 376 With reference to Figure 1, the following components are part of BIER 377 Multicast Overlay Layer. 379 1. Service Handler (SH): The Service handler terminates transport 380 level protocols, such as TCP, and extracts the service name. It 381 processes the service name in order to determine the PATH ID by 382 contacting the PCE for a suitable path resolution, which in turn 383 is used to send the service request. 385 2. Optional PCE : Path Computation Element keeps track of all 386 service execution end points through a registration process. SH 387 interacts with the PCE to obtain PATH information by resolving 388 the service name at the ingress SH to a suitable PATH ID. 390 3. Interface functions to BFIR where the PATH ID is mapped to BIER 391 header. An Interface to the BFER is likely not required because 392 the BFER will only receive the traffic that they need and should 393 be able to derive from the BIER payload which subset of its 394 receivers need to get an encapsulated version of a particular 395 reply. 397 7. Protocol Interactions 399 7.1. BIER Multicast Overlay Operations 401 As shown in Figure 3, the "Multicast overlay function" includes a 402 function called PCE (Path Computation Element function), which is 403 responsible for selecting the correct multicast end point and 404 possibly realizing path policy enforcement. The result of the 405 selection is a BIER path identifier, which is delivered to the SH 406 upon initial path computation request (or provided to the ingress 407 router BFIR to be added as BIER header ) (i.e., when sending a 408 request to or response for a specific URL for the first time). The 409 path identifier is utilized for any future request for a given URL- 410 based request. 412 All service end points indicate availability to the PCE through a 413 registration procedure, the PCE will instruct all SHs to invalidate 414 previous path identifiers to the specific URL that might exist. This 415 may result in an a renewed path computation request at the next 416 service request forwarding. Through this, the newly registered 417 service endpoint might be utilized if the policy-governed path 418 computation selects said service instance. Otherwise, a previously 419 resolved PATH ID for the URI determined at the ingress SH is being 420 used instead, removing any resolution latency to an SH-local lookup 421 of the PATH ID. 423 +-------+ +------+----+ +--------+ +----+-----+ 424 |Apps | |Apps----> | | PCE | | | APP | 425 |layer |--->|layer | SH | +---/\---+ | SH--> | 426 |prot | |prot | | || | | LYR | 427 +-------+ +------+----+ +---------+ +---------+ +----+-----+ 428 | L2 | | L2 |-->|Forwarder|-->|Forwarder|-->| L2 | 429 +-------+ +------+----+ +---------+ +---------+ +----------+ 430 |--------BIER DOMAIN -------| 432 Figure 3: Protocol Stack for Multicast Overlay Layer 434 In the diagram shown above, a service request is sent by an IP-based 435 device towards the service name of the server defined in the service 436 request. 438 At the client facing SH, the service request is terminated at the TCP 439 level. The server side SH at the egress terminates any transport 440 protocol on the outgoing (server) side. These terminating functions 441 are assumed to be part of the client/ server SH. As a consequence, 442 the SH obtains the destination "Service Name" from the received 443 service request. 445 If no local BIER forwarding information exists at the client side SH, 446 the path computation entity (PCE) is consulted, which calculates a 447 unicast path from the BFIR to which the client SH is connected to the 448 BFER to which the server SH is connected. The PCE provides the 449 forwarding information (Path ID) to the client SH, which in turn 450 caches the result. The Client SH may forward the Path ID to BFIR, 451 which creates the BIER header. 453 +-------------+--------------+ 454 | | SERVICE | 455 | BIER HEADER | REQUEST | 456 | | [ENCODED IN | 457 | | TEXT] | 458 | | | 459 +-------------+--------------+ 461 Figure 4: Encapsulation of Service Request 463 Ultimately, the "Service Request" encapsulated by BIER header, as 464 shown in above diagram, is forwarded by the client SH towards the 465 server- facing SH via the local BFIR. We assume a (TCP-friendly) 466 transport protocol being used for the transmission between client and 467 server SH. The possibility of sending one service response to 468 several SHs makes this a reliable multicast transport protocol. The 469 exact nature of this transport protocol is left for further studies. 470 A suitable transport or Layer 2 encapsulation, as supported by BIER 471 layer, is added to the above payload. 473 +-------------+-------------+--------------+ 474 | | | SERVICE | 475 | Transport L2| BIER HEADER | REQUEST | 476 | HEADER | | [ENCODED IN | 477 | | | TEXT] | 478 | | | | 479 +-------------+-------------+--------------+ 481 Figure 5: Transport Encapsulation of BIER payload 483 Upon arrival of a service request at the server SH, it forwards the 484 service request as a well-formed service request locally to the 485 server, awaiting an service response for the reverse direction. 487 If no BIER forwarding information exists for the reverse direction 488 towards the requesting client SH, this information is requested from 489 the PCE, similar to the operation in forward direction. 491 7.2. Achieving Multicast Responses 493 Upon arrival of any further client SH request at the server SH to an 494 service request whose response is still outstanding, the client SR is 495 added to an internal request table. Optionally, the request is 496 suppressed from being sent to the server. 498 Upon arrival of a service response at the server SH, the server SH 499 consults its internal request table for any outstanding service 500 requests to the same request. The server SH retrieves the stored 501 BIER forwarding information for the reverse direction for all 502 outstanding service requests and determines the path information to 503 all client SHs through a binary OR over all BIER forwarding 504 identifiers with the same SI field. This newly formed joint BIER 505 multicast response identifier is used to send the service response 506 across the network. 508 BIER makes the solution scalable. Instead of IP Multicast with IGMP/ 509 PIM, BIER is being used between Server SH and client SHs, the server- 510 facing SH simply coalesces the forwarded service requests from the 511 client-facing SH, and determines for every requested block the set of 512 SHs requesting it. A set of SHs corresponds to a set of bits in the 513 BIER-bitstring, one bit per SH. The SH then sends the block into 514 BIER with the appropriate bitstring set. 516 This completely eliminates any dynamic multicast signaling between 517 client-facing SHs and server-facing SH. It also avoids sending of 518 any unnecessary data block. 520 Furthermore, using the approach with BIER, the server-facing SH can 521 also easily control how long to delay sending of blocks. For 522 example, it may wait for some percentage of the time of a block (e.g, 523 50% = 1 second), therefore ensuring that it is coalescing as many 524 requests into one BIER multicast answer as possible. The realization 525 of such controlled sending of a single response, however, needs 526 further study as to the possible interaction with upper-layer 527 methods, particularly congestion control. 529 7.3. BIER Multicast Overlay Traffic Management 531 BIER-TE (BIER Traffic Engineering [I-D.ietf-bier-te-arch]) forwards 532 and replicates packets like BIER based on a BitString in the packet 533 header. Where BIER forwards and replicates its packets on shortest 534 paths towards BFER, BIER-TE allows (and requires) to also use bits in 535 the bitstring to indicate the paths in the BIER domain across which 536 the BIER-TE packets are to be sent. This is done to support Traffic 537 Engineering for BIER packets via explicit hop-by-hop and/or loose hop 538 forwarding of BIER-TE packets. A BIER-TE controller calculates 539 explicit paths for this packet forwarding. 541 The Multicast Flow Overlay operates as in BIER. Instead of 542 interacting with the BIER layer, it interacts with the BIER-TE 543 Controller. 545 In this draft, "Name-based" service forwarding over BIER, is 546 described to handle changes in service execution end points and 547 manage adhoc relationship in a multicast group. BIER-TE is another 548 way of doing this, while integrated with BIER architecture. The PCE 549 function described earlier in the BIER Multicast Overlay, may become 550 part of BIER-TE Controller. The server- and client-facing SH 551 function communicates with the BIER TE controller. SH sends the 552 service name to the controller, which processes the request using the 553 PCE function and returns the "bitstring" to be used as BIER header 554 for delivery of the service response to multiple clients. 556 8. Upper Layer Considerations 558 8.1. Application (Protocol) Considerations 560 TBD: add something on DASH here, app considerations for using SH 561 capabilities, ... 563 8.2. Transport Protocol Considerations 565 TBD: move transport discussions in Section 7 into this place and pose 566 the challenges that need addressing beyond the FRRM aspect at the 567 BIER level 569 9. Conclusions 571 This draft generalizes the work in 572 [I-D.ietf-bier-multicast-http-response] beyond HTTP being the 573 application protocol. Instead, this draft proposes a general 574 multicast semantic termed 'forward requests return multicast' (FRRM), 575 which can be utilized by any application layer protocol atop a BIER 576 transport network. 578 10. Security Considerations 580 The operations in Section 7 consider the forwarding of service 581 request packets between ingress and egress points based on 582 information derived from the service request. The support for 583 transport-level security, e.g., TLS, is foreseen to ensure suitable 584 encryption capability of such exchanges. For this to happen, we 585 expect certificate sharing agreements to exist between the content 586 provider and the BIER overlay provider, ensuring the extraction of 587 the suitable request parameters while allowing for the re-encryption 588 of the content for an encrypted delivery over the BIER network. 589 Since we liken the relationship between content and BIER overlay 590 provider to that between content and CDN provider, the existence of 591 certificate sharing agreements is similar to the practice used for 592 CDNs. 594 11. Privacy Considerations 596 TBD: Anything here on exposing request IDs? 598 12. IANA Considerations 600 This draft does not request any IANA action. 602 13. Acknowledgements 604 This draft originated from the narrower use case described in 605 [I-D.ietf-bier-multicast-http-response]. We acknowledge the work 606 that has gone into the development of this draft and the 607 contributions through discussions on the mailing list. We 608 specifically thank Toerless Eckert, Sebastian Robitzsch, Akbar Rahman 609 and Chonggang Wang for their contributions to the original draft, 610 some of which have been transferred to this draft, where appropriate. 612 14. Informative References 614 [DVB_REF_ARCH] 615 DVB, "Adaptive media streaming over IP Multicast", 616 Report DVB Document A176, 2018, 617 . 621 [fCDN] Al-Naday, M., Reed, M., Riihijarvi, J., Trossen, D., 622 Thomos, N., and M. Al-Khalidi, "fCDN: A Flexible and 623 Efficient CDN Infrastructure without DNS Redirection or 624 Content Reflection", Paper Arxiv, 2018, 625 . 627 [I-D.ietf-bier-multicast-http-response] 628 Trossen, D., Rahman, A., Wang, C., and T. Eckert, 629 "Applicability of BIER Multicast Overlay for Adaptive 630 Streaming Services", Work in Progress, Internet-Draft, 631 draft-ietf-bier-multicast-http-response-06, 10 July 2021, 632 . 635 [I-D.ietf-bier-te-arch] 636 Eckert, T., Menth, M., and G. Cauchie, "Tree Engineering 637 for Bit Index Explicit Replication (BIER-TE)", Work in 638 Progress, Internet-Draft, draft-ietf-bier-te-arch-12, 28 639 January 2022, . 642 [I-D.ietf-bier-use-cases] 643 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 644 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 645 Bestler, "BIER Use Cases", Work in Progress, Internet- 646 Draft, draft-ietf-bier-use-cases-12, 10 September 2020, 647 . 650 [ICC2016] Reed, M., Al-Naday, M., Thomos, N., Trossen, D., 651 Petropoulos, G., and S. Spirou, "Stateless multicast 652 switching in software defined networks", Paper IEEE ICC 653 2016, 2016. 655 [ISO_DASH] ISO, "Information technology -- Dynamic adaptive streaming 656 over HTTP (DASH) -- Part 1: Media presentation description 657 and segment formats", Report ISO/IEC 23009-1:2014, 2014, 658 . 661 [POINT2016] 662 Kim, S.-Y., Robitzsch, S., Trossen, D., Reed, M., Al- 663 Naday, M., and J. Riihijarvi, "Realizing IP-based Services 664 over an Information-Centric Networking Transport Network", 665 Paper Proceedings of the 3rd ACM Conference on 666 Information-Centric Networking, Pages 215-216, 2016. 668 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 669 Group Management Protocol Version 3 (IGMPv3) and Multicast 670 Listener Discovery Protocol Version 2 (MLDv2) for Source- 671 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 672 August 2006, . 674 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 675 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 676 . 678 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 679 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 680 Explicit Replication (BIER)", RFC 8279, 681 DOI 10.17487/RFC8279, November 2017, 682 . 684 [TR_IPMC_ABR] 685 CableLabs, "IP Multicast Adaptive Bit Rate Architecture 686 Technical Report", Report OC-TR-IP-MULTI-ARCH-V01-141112 687 C01, 2016, 688 >. 692 Author's Address 694 Dirk Trossen 695 Huawei Technologies 696 Munich 697 Germany 698 Email: dirk.trossen@huawei.com