idnits 2.17.00 (12 Aug 2021) /tmp/idnits21641/draft-ietf-bier-multicast-http-response-06.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 -- The document date (July 10, 2021) is 308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-00 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-05 == Outdated reference: draft-irtf-icnrg-deployment-guidelines has been published as RFC 8763 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Trossen 3 Internet-Draft Huawei 4 Intended status: Informational A. Rahman 5 Expires: January 11, 2022 C. Wang 6 InterDigital Communications, LLC 7 T. Eckert 8 Futurewei 9 July 10, 2021 11 Applicability of BIER Multicast Overlay for Adaptive Streaming Services 12 draft-ietf-bier-multicast-http-response-06 14 Abstract 16 HTTP Level Multicast, using BIER, is described as a use case in the 17 BIER Use Cases document. HTTP Level Multicast is used in today's 18 video streaming and delivery services such as HTTP Live Streaming 19 (HLS), Augmented Reality and Virtual Reality(AR/VR), generally 20 realized over IP Multicast as well as other use cases such as 21 software update delivery. A realization of "HTTP Multicast" over "IP 22 Multicast" is described for the video delivery use case. IP 23 Multicast is commonly used for IPTV services. Digital Video 24 Broadcasting (DVB) and Broadband Forum (BBF) also develope a 25 reference architecture for IP Multicast service. A few problems with 26 IP Multicast, such as waste of transmission bandwidth, increase in 27 signaling when there are few users are described. Realization over 28 BIER, through a BIER Multicast Overlay Layer, is described as an 29 alternative. How BIER Multicast Overlay operation improves over IP 30 Multicast, such as reduction in signaling, dynamic creation of 31 multicast groups to reduce signaling and bandwidth wastage is 32 described. We conclude with a few next steps. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 11, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Reference Deployment . . . . . . . . . . . . . . . . . . 3 69 2. Conventions used in this document . . . . . . . . . . . . . . 5 70 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. HTTP-based Steaming . . . . . . . . . . . . . . . . . . . 6 72 3.2. HTTP-based Software Updates . . . . . . . . . . . . . . . 7 73 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Realization over IP Multicast . . . . . . . . . . . . . . . . 8 75 5.1. Mapping to Requirements . . . . . . . . . . . . . . . . . 9 76 5.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Realization over BIER . . . . . . . . . . . . . . . . . . . . 10 78 6.1. Description of a "BIER Multicast Overlay" to support HTTP 79 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.1.1. BIER Multicast Overlay Components . . . . . . . . . . 11 81 6.1.2. BIER Multicast Overlay Operations . . . . . . . . . . 11 82 6.2. Achieving Multicast Responses . . . . . . . . . . . . . . 13 83 6.3. BIER Multicast Overlay Traffic Management . . . . . . . . 14 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 9. Informative References . . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The BIER Use Cases document [I-D.ietf-bier-use-cases] describes an 92 "HTTP Level Multicast" scenario, where HTTP Responses are carried 93 over a BIER multicast infrastructure to multiple clients. Especially 94 rate-adaptive HTTP solutions can benefit from the dynamic multicast 95 group membership changes enabled by BIER. For this, the server-side 96 Network Attachment Point (NAP), creates a list of outstanding client- 97 side NAP requesting for the same HTTP resource. When the response is 98 available, the list of NAPs with outstanding client requests are 99 converted into the BIER or BIER-TE bitstring and used to send the 100 HTTP response. 102 In this draft, we describe use cases for such HTTP response multicast 103 capability. Specifically for HTTP-based video streaming, we describe 104 how this can be realized over IP Multicast and how the operation of 105 the video delivery use case can be improved if realized over BIER. 106 The realization over BIER is achieved through what is called "BIER 107 Multicast overlay" layer, i.e., the methods by which the sending BIER 108 router knows how to send other application packets. The requirements 109 for BIER Multicast overlay layer is described in this document. It 110 also describes the necessary functions that form the BIER multicast 111 overlay and the operations that enable the desired "HTTP Level 112 Multicast" behavior. One such operation is generating the PATH ID 113 (represents the path between BFIR and BFER) based on named service 114 relationship and translating it to appropriate BIER header. We 115 describe a list of protocols needed for the realization of the 116 individual operations. 118 1.1. Reference Deployment 120 Let us formulate the architecture of the BIER multicast overlay for 121 the scenario outlined in [I-D.ietf-bier-use-cases]. This overlay is 122 shown in Figure 1 below. 124 +---------+ +------------+ 125 | | | |/ 126 +IP only +---+ SH + BFER +-----| 127 |receiver | | (CNAP) |\ | 128 |UE | +----/\------+ | 129 +---------+ || | 130 || +----------+ +---------+ 131 || | | | | 132 |-------- | BFR |---| BFR |------| 133 | | | | | | 134 | +----------+ +---------+ | 135 +---------+ +-------+ 136 | |------------------------------------>| BFIR | 137 + BIER TE + | + | 138 | PCE | +---------+ +-------+ | SH | 139 | |--|| | |----| BFR |----|(SNAP) | 140 +---------+ || | BFR | +-------+ | | 141 || | | +-------+ 142 || +---------+ /|\ 143 +---------+ +------\/----+ | | 144 | | | |/ | | 145 +IP only +---+ SH + BFER +------| +----------+ 146 |receiver | | (CNAP) |\ | IP only | 147 +---------+ +------------+ | Sender | 148 |(Server) | 149 +----------+ 151 [SH : Service Handler, CNAP : Client Network Attachment Point] 152 [SNAP : Server Network Attachment Point] 153 [PCE : Path Computation Element] 155 Figure 1: Deployment over BIER 157 The multicast overlay is formed by the BFIR and BFER of the BIER 158 layer and the additional Service Handler (SH) and Path Computation 159 Element (PCE) elements shown in the figure. When interconnecting 160 with a non-BIER enabled IP routed peering network, a special SH, such 161 as Border Gateway may be used. 163 The Service Handler and BFER can be assumed to be collocated and can 164 be viewed as Client Network Attachment Point (CNAP). Clients sends 165 and receives HTTP transactions through CNAP. 167 On the server side, the Service handling function can be part of the 168 Server Network Attachment Point (SNAP). It includes the BFIR 169 function and SH. SNAP is responsible for aggregating the relevant 170 HTTP Requests and sending one or more BIER Multicast HTTP response to 171 multiple clients who requested the same content. 173 The SH function is assumed to be collocated with BFIR / BFER. The 174 BFIR and BFER is assumed to be normal router boxes in the network. 175 If the additional function of SH cannot be added to normal routers, 176 then SH can be deployed as a separate function outside the routers. 177 In such scenario an interface between SH and BFIR or BFER needs to be 178 defined. 180 As part of the POINT/RIFE/FLAME EU Horizon 2020 projects, HTTP Level 181 Multicast use case has been executed on SDN based and ICN based 182 underlay network, as described in the 183 [I-D.irtf-icnrg-deployment-guidelines]. 185 "HTTP multicast" demonstrated benefits in HTTP-level streaming video 186 delivery, when deployed on a POINT test bed with 80+ nodes. This 187 draft [I-D.irtf-icnrg-deployment-guidelines] also describes protocol 188 requirements to enable HTTP multicast to work on ICN underlay. 190 2. Conventions used in this document 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 3. Use Cases 198 With the extensive use of "web technology", "distributed services" 199 and availability of heterogeneous network, HTTP has effectively 200 transitioned into the common transport or session layer for E2E and 201 multi-hop communication across the web that is also called Service 202 signaling. Multi-hop when using a sequence of HTTP instance such as 203 HTTP caches. The draft "On the use of HTTP as a Substrate" 204 [I-D.ietf-httpbis-bcp56bis], describes how HTTP is commonly used 205 among service instances to communicate with each other, thus 206 abstracting the lower layer details to application developers. 208 For example, HTTP provides a common transport to support application 209 layer streaming (Section 3.1) for not only conventional TV 210 broadcasting, but also emerging Virtual Reality (VR) applications 211 like VR-based tourist guide. HTTP can also be leveraged to support 212 wide-area large-scale software updates (Section 3.2) such as for 213 Vehicle-to-Everything (V2X) or Internet of vehicles use case. In the 214 following, we present how such HTTP transport capability can be 215 extended with multicast delivery for HTTP responses in certain use 216 cases. 218 3.1. HTTP-based Steaming 220 Referring to the BIER Use Cases [I-D.ietf-bier-use-cases], multicast 221 is used to scale out HTTP Live Streaming (HLS) to a large number of 222 receivers that use HTTP. This is used today in solutions like DOCSIS 223 hybrid streaming [TR_IPMC_ABR]. Multicast can speed up both live and 224 high-demand VoD streaming. Adaptive Bit Rate IPMC [TR_IPMC_ABR] 225 describes use of IP Multicast towards the CMTS or a box beside it, 226 where the content is converted to HTTP/TCP to stream to the receivers 227 (e.g., homes). A server hosting the HLS content is shown as "NAP 228 Server". The gateways acting as receivers for the multicast from the 229 server are shown as "Client-NAP" (CNAP). Each CNAP can serve 230 multiple clients. 232 Dynamic Adaptive Streaming (DASH) [ISO_DASH] over HTTP is another 233 HTTP-based streaming approach. In DASH, each media is described by a 234 Media Presentation Description (MPD) file, through which a DASH 235 client (e.g. a media player) is instructed how to download, interpret 236 and play the media. The media content is encoded into fragments or 237 chunks at different bit rates. Both the MPD and media fragments are 238 stored at a server. The DASH client first needs to retrieve the MPD 239 file from the server; then it can start to retrieve media fragments 240 encoded at different bits rates from the server. DASH players may 241 use rate adaptation, i.e., switching the retrieval from one rate 242 chunks to another rate. Usually this rate adaptation is utilizing 243 delay measurements, resulting in TCP like behavior in terms of 244 backoff in case of increasing delay. DASH has been designed to reuse 245 most of existing Internet infrastructure and protocols and can run 246 over different underlying transports including HTTP. For example, 247 two major media service providers Netflix and Youtube use DASH over 248 HTTP as their streaming technology. 250 HTTP request and response used in media streaming services like HLS 251 and DASH over HTTP, use HTTP responses for delivery of content, i.e., 252 each chunk is returned as an HTTP response to the requesting client. 253 In such scenarios, where semi-synchronous access to the same resource 254 occurs (such as watching prominent videos over Netflix or similar 255 platforms or live TV over HTTP), traffic grows linearly with the 256 number of viewers since the HTTP-based server will provide an HTTP 257 response to each individual viewer. This poses a significant burden 258 on operators in terms of costs and on users in terms of likely 259 degradation of quality. 261 The use of HTTP-based streaming of video content is not limited to 262 traditional TV broadcasting. Consider a virtual reality use case 263 where several users are joining a VR session at the same time, e.g., 264 centered around a joint event. Hence, due to the temporal 265 correlation of the VR sessions, we can assume that multiple requests 266 are sent for the same content at any point, particularly when viewing 267 angles of VR clients are similar or the same. Due to availability of 268 virtual functions and cloud technology, the actual end point from 269 where content is delivered may change. 271 3.2. HTTP-based Software Updates 273 Various new types of devices such as vehicles and robots are being 274 connected to Internet. They could be physically located at or moving 275 between different places and connect to Internet via different 276 telecom operators. Software updates for these devices become 277 important and introduce point-to-multipoint traffic from a software 278 server to devices. Using V2X as an example, the software server 279 could be a part of telecom operators or maintained by car 280 manufacturers. In either case, the software server keeps vehicle 281 software or firmware images, which will be transmitted to many 282 vehicles across the global Internet, based on a pull or push model. 283 HTTP is commonly used for those software updates to provide an E2E 284 transport between the software server and each vehicle requesting 285 software updates. As a result, the traffic from the software server 286 to vehicles increases linearly with the number of connected vehicles 287 since each vehicle will establish a HTTP connection with the software 288 server. 290 4. Requirements 292 A realization for the "HTTP multicast" use case may have the 293 following requirements: 295 o MUST support multiple FQDN-based service endpoints to exist in the 296 overlay to allow for utilizing several service endpoints for 297 delivery and would therefore enable localization of content 298 delivery. 300 o MUST send FQDN-based service requests at the network level to a 301 suitable FQDN-based service endpoint via policy-based selection of 302 appropriate path information. 304 o MUST allow for multicast delivery of HTTP response to same HTTP 305 request URI. 307 o MUST provide direct path mobility, where the path between the 308 egress and ingress Service Routers(SR) can be determined as being 309 optimal (e.g., shortest path or direct path to a selected 310 instance), is needed to avoid the use of anchor points and further 311 reduce service-level latency. 313 5. Realization over IP Multicast 315 We now discuss the realization of chunk-based delivery over IP 316 Multicast delivery methods. We focus our presentation here on the 317 video streaming use case in Section 3.1. 319 IPTV or Internet video distribution in CDNs, uses HTTP Level 320 Multicast and realized over IP Multicast (IPMC). Many features of 321 the IPTV service uses IPMC Group dependent state. Besides popular 322 features like PIM, Mldp, in a variable bit rate encoded content 323 source, content consumption also depends on group state. 325 DVB released reference architecture [DVB_REF_ARCH] for an end-to-end 326 system to deliver linear content over IP networks in a scalable and 327 standards-compliant manner. It focuses on delivering Adaptive Bit 328 Rate unicast content over a IP Multicast network. 330 A Multicast gateway is deployed in a CPE, Upstream Network Edge 331 device or Terminal and provides multicast to unicast conversion 332 facilities for several homes. All in-scope traffic on the access 333 network between the Multicast Gateway (e.g. network edge device) and 334 the Terminal or home gateway device is unicast. The individual media 335 files are encapsulated into other protocols, so that they can be 336 recovered as discrete files, when they exit the multicast pipe, which 337 is terminated at Multicast Gateway. Interface "L" between Multicast 338 server and Content playback supports fetching of all specified types 339 of Content, Conditional request, Range request, Caching etc. BBF 340 also started similar work in October 2016, called WT-399. This work 341 is now coordinated with DVB. BBF focuses on developing the device 342 management model. 344 Assume clients that are consuming the same content (such as a TV 345 program) and that this content has for each block (typically segments 346 worth 2 seconds of content) a set of outstanding requests from its 347 clients. When IP Multicast is used in the domain, such as in 348 aforementioned pre-existing solutions like in Cablelabs/DOCSIS 349 [TR_IPMC_ABR], all possible blocks of the content have to be mapped 350 to some IP Multicast group, and the CNAP will need to know the 351 mapping of block to groups. For example, a live stream may have 11 352 different bitrates available. In the most simple Block to IP 353 Multicast group mapping scheme, there could be 11 multicast groups, 354 one for all the blocks of one bitrate (note that this is not 355 necessarily done in deployments of this solution, but we consider it 356 here for the purpose of explanation). 358 If the multicast domain and especially the links into the CNAP has 359 enough bandwidth, this solution work well with IP Multicast. As soon 360 as there is at least one Client connected to a CNAP for one 361 particular content, the CNAP would join all 11 multicast groups for 362 this content. 364 5.1. Mapping to Requirements 366 To realize "HTTP Level Multicast" over "IP Multicast", some 367 additional functions needs to be supported in an intermediate 368 (overlay) layer. 370 Support of mapping between FQDN based end points, Multicast Address. 371 Creating multicast group from FQDN based end points. 373 Control mechanism related to time when to start sending response as 374 the multicast group is created. It is required that the source 375 should not send response immediately to the Multicast address. Wait 376 for some time to build the group sufficiently and then send response. 378 Support of IGMP signaling between User device, NAPs and Multicast 379 Router. 381 5.2. Problems 383 If the number of clients on a CNAP for a particular program is large, 384 the approach will work fairly well, because the likelihood that each 385 of the 11 bitrates of a content is necessary for at least one Client 386 is then fairly high. 388 When the number of receivers is not very large, IP Multicast runs 389 into two issues. If all the bitrates for the content are sent across 390 the same group, then many of the bitrates may not be required and 391 would have to be received unnecessarily and dropped by the CNAP. If 392 each bitrate was sent on a different IP Multicast group, the CNAP 393 could dynamically join/leave each multicast group based on the known 394 receivers, but that would create an extremely high and undesirable 395 amount of IP Multicast signaling protocol activity (PIM/IGMP) that is 396 easily overloading the network 398 For efficiency reasons, the CNAP would need to dynamically join to 399 only those bitrate steams where it does have outstanding requests, 400 therefore achieving the best efficiency. This would mean in the 401 worst case that a CNAP would need to send for each new block, aka.: 402 every two second for every client one IGMP/PIM leave and one IGMP/PIM 403 join towards the upstream router to get a block for an appropriate 404 bitrate (or changed content) whenever bitrate or content on a client 405 have changed. This high rate of control-plane signaling between CNAP 406 and routers, and even between routers inside the multicast Domain is 407 a major pain point and may easily prohibit deployment of these 408 solutions because in many network devices, the performance of PIM/ 409 IGMP is not scaled for continuous change in forwarding. Even worse, 410 the limit may not simply be the CPU performance of the routers 411 control plane, but a limitation in the number of changes in 412 forwarding that the forwarding plane units (NPU/ASICs) can support. 414 6. Realization over BIER 416 6.1. Description of a "BIER Multicast Overlay" to support HTTP 417 Multicast 419 The Service Handler (as in Figure 1) in BIER Multicast Overlay, 420 process the FQDN in the service request. At the service level, e.g. 421 HTTP service, the fixed relationship among consumer and providers may 422 be abstracted using "Service Names", and the changing relationship at 423 the Service execution endpoints can be managed at the "multicast 424 overlay" level, handing out the exact locations where service request 425 or response needs to be sent to BIER layer. 427 +-------------+ +-----------+ +-----------+ 428 | | | | | PATH ID | 429 | Service name| | Multicast | | translates| 430 | [producer, |------->| Overlay |------>| to BIER | 431 | consumer] | | Layer | | header | 432 | | | | | | 433 +-------------+ +-----------+ +-----------+ 435 Figure 2: Service Name to Path ID Translation 437 We illustrate this using HTTP URI as service names. It should be 438 noted, other identifiers can also be used as service name, such as an 439 IP address. In the example illustration, other layers such as TCP, 440 IP has been terminated at the egress point. Outside BIER domain we 441 terminate TCP/IP session to extract the URI. The URI is processed by 442 the "multicast overlay" layer to generate PATH IDENTIFIER , which is 443 used as BIER header. 445 Path Identifier or PATH ID, is used in path-based approach, which 446 utilizes path information provided by the source of the packet for 447 forwarding said packet in the network. This is similar to segment 448 routing albeit differing in the type of information provided for such 449 source-based forwarding. 451 Once the BIER header is determined and added at the BFIR, the rest of 452 the transport layers is assumed to be any underlay technology as 453 supported by BIER. We assume TCP friendly transport, which can 454 assure reliable delivery. 456 6.1.1. BIER Multicast Overlay Components 458 With reference to Figure 1, the following components are part of BIER 459 Multicast Overlay Layer. 461 o Service Handler (SH): The Service handler terminates transport 462 level protocols, such as TCP, and extracts the URI. It processes 463 the URI in order to determine the PATH ID by contacting the PCE 464 for a suitable path resolution, which in turn is used to send the 465 HTTP Request. 467 o Optional PCE : Path Computation Element keeps track of all service 468 execution end points through a registration process. SH interacts 469 with the PCE to obtain PATH information by resolving the FQDN from 470 the incoming URI at the ingress SH to a suitable PATH ID. 472 o Interface functions to BFIR where the PATH ID is mapped to BIER 473 header. An Interface to the BFER is likely not required because 474 the BFER will only receive the traffic that they need and should 475 be able to derive from the BIER payload which subset of its 476 receivers need to get an HTTP encapsulated version of a particular 477 reply. 479 6.1.2. BIER Multicast Overlay Operations 481 As shown in Figure 3, the "Multicast overlay function" includes a 482 function called PCE (Path Computation Element function), which is 483 responsible for selecting the correct multicast end point and 484 possibly realizing path policy enforcement. The result of the 485 selection is a BIER path identifier, which is delivered to the SH 486 upon initial path computation request (or provided to the ingress 487 router BFIR to be added as BIER header ) (i.e., when sending a 488 request to or response for a specific URL for the first time). The 489 path identifier is utilized for any future request for a given URL- 490 based request. 492 All service end points indicate availability to the PCE through a 493 registration procedure, the PCE will instruct all SHs to invalidate 494 previous path identifiers to the specific URL that might exist. This 495 may result in an a renewed path computation request at the next 496 service request forwarding. Through this, the newly registered 497 service endpoint might be utilized if the policy-governed path 498 computation selects said service instance. Otherwise, a previously 499 resolved PATH ID for the URI determined at the ingress SH is being 500 used instead, removing any resolution latency to an SH-local lookup 501 of the PATH ID. 503 +-------+ +------+----+ +--------+ +----+-----+ 504 |Apps | |Apps----> | | PCE | | | APP | 505 |layer |--->|layer | SH | +---/\---+ | SH--> | 506 |prot | |prot | | || | | LYR | 507 +-------+ +------+----+ +---------+ +---------+ +----+-----+ 508 | L2 | | L2 |-->|Forwarder|-->|Forwarder|-->| L2 | 509 +-------+ +------+----+ +---------+ +---------+ +----------+ 510 |--------BIER DOMAIN -------| 512 Figure 3: Protocol for Multicast Overlay Layer 514 In the diagram shown above, an HTTP request is sent by an IP-based 515 device towards the FQDN of the server defined in the HTTP request. 517 At the client facing SH, the HTTP request is terminated at the TCP 518 level at a local HTTP proxy. The server side SH at the egress 519 terminates any transport protocol on the outgoing (server) side. 520 These terminating functions are assumed to be part of the client/ 521 server SH. As a consequence, the SH obtains the destination "Service 522 Name" from the received HTTP request. 524 If no local BIER forwarding information exists at the client side SH, 525 the path computation entity (PCE) is consulted, which calculates a 526 unicast path from the BFIR to which the client SH is connected to the 527 BFER to which the server SH is connected. The PCE provides the 528 forwarding information (Path ID) to the client SH, which in turn 529 caches the result. The Client SH may forward the Path ID to BFIR, 530 which creates the BIER header. 532 +-------------+--------------+ 533 | | | 534 | BIER HEADER | HTTP REQUEST | 535 | | [ENCODED IN | 536 | | TEXT] | 537 | | | 538 +-------------+--------------+ 540 Figure 4: Encapsulation of Service Request 542 Ultimately, the "HTTP Request" encapsulated by BIER header, as shown 543 in above diagram, is forwarded by the client SH towards the server- 544 facing SH via the local BFIR. We assume a (TCP-friendly) transport 545 protocol being used for the transmission between client and server 546 SH. The possibility of sending one HTTP response to several CNAPs 547 makes this a reliable multicast transport protocol. The exact nature 548 of this transport protocol is left for further studies. A suitable 549 transport or Layer 2 encapsulation, as supported by BIER layer, is 550 added to the above payload. 552 +-------------+-------------+--------------+ 553 | | | | 554 | Transport L2| BIER HEADER | HTTP REQUEST | 555 | HEADER | | [ENCODED IN | 556 | | | TEXT] | 557 | | | | 558 +-------------+-------------+--------------+ 560 Figure 5: Transport Encapsulation of BIER payload 562 Upon arrival of an HTTP request at the server SH, it forwards the 563 HTTP request as a well-formed HTTP request locally to the server, 564 awaiting an HTTP response for the reverse direction. 566 If no BIER forwarding information exists for the reverse direction 567 towards the requesting client SH, this information is requested from 568 the PCE, similar to the operation in forward direction. 570 6.2. Achieving Multicast Responses 572 Upon arrival of any further client SH request at the server SH to an 573 HTTP request whose response is still outstanding, the client SR is 574 added to an internal request table. Optionally, the request is 575 suppressed from being sent to the server. 577 Upon arrival of an HTTP response at the server SH, the server SH 578 consults its internal request table for any outstanding HTTP requests 579 to the same request. The server SH retrieves the stored BIER 580 forwarding information for the reverse direction for all outstanding 581 HTTP requests and determines the path information to all client SHs 582 through a binary OR over all BIER forwarding identifiers with the 583 same SI field. This newly formed joint BIER multicast response 584 identifier is used to send the HTTP response across the network. 586 BIER makes the solution scalable. Instead of IP Multicast with IGMP/ 587 PIM, BIER is being used between Server NAP (SNAP) and CNAP, the SNAP 588 simply coalesces the forwarded HTTP requests from the CNAP, and 589 determines for every requested block the set of CNAPs requesting it. 590 A set of CNAPs corresponds to a set of bits in the BIER-bitstring, 591 one bit per CNAP. The SNAP then sends the block into BIER with the 592 appropriate bitstring set. 594 This completely eliminates any dynamic multicast signaling between 595 CNAP and SNAP. It also avoids sending of any unnecessary data block, 596 which in the IP Multicast solution is pretty much unavoidable. 598 Furthermore, using the approach with BIER, the SNAP can also easily 599 control how long to delay sending of blocks. For example, it may 600 wait for some percentage of the time of a block (e.g, 50% = 1 601 second), therefore ensuring that it is coalescing as many requests 602 into one BIER multicast answer as possible. 604 6.3. BIER Multicast Overlay Traffic Management 606 BIER-TE (BIER Traffic Engineering [I-D.ietf-bier-te-arch]) forwards 607 and replicates packets like BIER based on a BitString in the packet 608 header. Where BIER forwards and replicates its packets on shortest 609 paths towards BFER, BIER-TE allows (and requires) to also use bits in 610 the bitstring to indicate the paths in the BIER domain across which 611 the BIER-TE packets are to be sent. This is done to support Traffic 612 Engineering for BIER packets via explicit hop-by-hop and/or loose hop 613 forwarding of BIER-TE packets. A BIER-TE controller calculates 614 explicit paths for this packet forwarding. 616 The Multicast Flow Overlay operates as in BIER. Instead of 617 interacting with the BIER layer, it interacts with the BIER-TE 618 Controller. 620 In this draft, "Name-based" service forwarding over BIER, is 621 described to handle changes in service execution end points and 622 manage adhoc relationship in a multicast group. BIER-TE is another 623 way of doing this, while integrated with BIER architecture. The PCE 624 function described earlier in the BIER Multicast Overlay, may become 625 part of BIER-TE Controller. The SH function in the CNAP and SNAP 626 communicates with BIER TE controller. SH sends the service name to 627 the controller, which process the request using the PCE function and 628 returns the "bitstring" to be used as BIER header for delivery of the 629 HTTP response to multiple clients. 631 7. IANA Considerations 633 This document requests no IANA actions. 635 8. Security Considerations 637 The operations in Section 6 consider the forwarding of HTTP packets 638 between ingress and egress points based on information derived from 639 the HTTP request. The support for HTTPS is foreseen to ensure 640 suitable encryption capability of such exchanges. For this to 641 happen, we expect certificate sharing agreements to exist between the 642 content provider and the BIER overlay provider, ensuring the 643 extraction of the suitable request parameters while allowing for the 644 re-encryption of the content for an encrypted delivery over the BIER 645 network. Since we liken the relationship between content and BIER 646 overlay provider to that between content and CDN provider, the 647 existence of certificate sharing agreements is similar to the 648 practice used for CDNs. 650 9. Informative References 652 [DVB_REF_ARCH] 653 DVB, "Adaptive media streaming over IP Multicast", DVB 654 Document A176, March 2018, 655 . 659 [I-D.ietf-bier-te-arch] 660 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 661 Engineering for Bit Index Explicit Replication (BIER-TE)", 662 draft-ietf-bier-te-arch-00 (work in progress), January 663 2018. 665 [I-D.ietf-bier-use-cases] 666 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 667 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 668 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-12 669 (work in progress), September 2020. 671 [I-D.ietf-httpbis-bcp56bis] 672 Nottingham, M., "On the use of HTTP as a Substrate", 673 draft-ietf-httpbis-bcp56bis-05 (work in progress), May 674 2018. 676 [I-D.irtf-icnrg-deployment-guidelines] 677 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 678 "Deployment Considerations for Information-Centric 679 Networking (ICN)", draft-irtf-icnrg-deployment- 680 guidelines-07 (work in progress), September 2019. 682 [ISO_DASH] 683 ISO, "Information technology -- Dynamic adaptive streaming 684 over HTTP (DASH) -- Part 1: Media presentation description 685 and segment formats", ISO/IEC 23009-1:2014, May 2014, 686 . 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, 691 DOI 10.17487/RFC2119, March 1997, 692 . 694 [TR_IPMC_ABR] 695 CableLabs, "IP Multicast Adaptive Bit Rate Architecture 696 Technical Report", OC-TR-IP-MULTI-ARCH-V01-141112 C01, 697 October 2016, 698 . 702 Authors' Addresses 704 Dirk Trossen 705 Huawei Technologies Duesseldorf GmbH 706 205 Hansallee 707 Duesseldorf 40549 708 Germany 710 Email: dirk.trossen@huawei.com 711 URI: http://huawei-dialog.de/ 713 Akbar Rahman 714 InterDigital Communications, LLC 715 1000 Sherbrooke Street West 716 Montreal H3A 3G4 717 Canada 719 Email: Akbar.Rahman@InterDigital.com 721 Chonggang Wang 722 InterDigital Communications, LLC 723 1001 E Hector St 724 Conshohocken 19428 725 USA 727 Email: Chonggang.Wang@InterDigital.com 728 Toerless Eckert 729 Futurewei Technologies Inc. 730 2330 Central Expy 731 Santa Clara 95050 732 USA 734 Email: tte+ietf@cs.fau.de