idnits 2.17.1 draft-purkayastha-bier-multicast-http-response-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2018) is 2017 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 (-12) exists of draft-ietf-bier-use-cases-07 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-05 == Outdated reference: A later version (-07) exists of draft-irtf-icnrg-deployment-guidelines-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Purkayastha 3 Internet-Draft A. Rahman 4 Intended status: Informational D. Trossen 5 Expires: April 21, 2019 InterDigital Communications, LLC 6 T. Eckert 7 Huawei 8 October 18, 2018 10 Applicability of BIER Multicast Overlay for Adaptive Streaming Services 11 draft-purkayastha-bier-multicast-http-response-01 13 Abstract 15 HTTP Level multicast, using BIER, is described as a use case in BIER 16 Use cases document. HTTP Level Multicast is used in today's video 17 streaming and delivery services such as HLS, AR/VR etc., generally 18 realized over IP Multicast. A realization of "HTTP Multicast" over 19 "IP Multicast" is described. IP multicast is commonly used for IPTV 20 services. DVB and BBF is also developing a reference architecture 21 for IP Multicast service. Few problems with IPMC, such as waste of 22 transmission bandwidth, increase in signaling when there are few 23 users are described. Realization over BIER, through a BIER Multicast 24 Overlay Layer, is described. How BIER Multicast Overlay operation 25 improves over IP Multicast, such as reduction in signaling, dynamic 26 creation of multicast groups to reduce signaling and bandwidth 27 wastage is described. We conclude with few next steps. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 21, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Reference Deployment . . . . . . . . . . . . . . . . . . 3 65 2. Conventions used in this document . . . . . . . . . . . . . . 5 66 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Realization over IP Multicast . . . . . . . . . . . . . . . . 6 69 5.1. Mapping to Requirements . . . . . . . . . . . . . . . . . 7 70 5.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Realization over BIER . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Description of a "BIER Multicast Overlay" to support HTTP 73 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.1.1. BIER Multicast Overlay Components . . . . . . . . . . 9 75 6.1.2. BIER Multicast Overlay Operations . . . . . . . . . . 10 76 6.2. Achieving Multicast Responses . . . . . . . . . . . . . . 12 77 6.3. BIER multicast Overlay Traffic Management . . . . . . . . 13 78 7. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 10. Informative References . . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 BIER Use Cases document [I-D.ietf-bier-use-cases] describes an "HTTP 87 Level Multicast" scenario, where HTTP Responses are carried over a 88 BIER multicast infrastructure to multiple clients. Especially rate- 89 adaptive HTTP solutions can benefit from the dynamic multicast group 90 membership changes enabled by BIER. For this, the "server side NAP 91 (Network Attachment Point), creates a list of outstanding client side 92 NAP (Network Attachment Point) requests for the same HTTP resource. 93 When the response is available, the list of NAPs with outstanding 94 client requests are converted into the BIER or BIER-TE bitstring and 95 used to send the HTTP response. 97 In this draft, we describe how this class of use cases can be 98 realized over IP Multicast and how the operation of the use case can 99 be improved if realized over BIER. The realization over BIER is 100 achieved through what is called "BIER Multicast overlay" layer, i.e., 101 the methods by which the sending BIER router knows how to send other 102 application packets. The requirements for BIER Multicast overlay 103 layer is described in this document. It also describes the necessary 104 functions that form the BIER multicast overlay and the operations 105 that enable the desired "HTTP Level Multicast" behavior. One such 106 operation is generating the PATH ID (represents the path between BFIR 107 and BFER) based on named service relationship and translating it to 108 appropriate BIER header. We describe a list of protocols needed for 109 the realization of the individual operations. 111 We conclude with future steps and seek input from the WG. 113 1.1. Reference Deployment 115 Let us formulate the architecture of the BIER multicast overlay for 116 the scenario outlined in [I-D.ietf-bier-use-cases]. This overlay is 117 shown in Figure 1 below. 119 +---------+ +------------+ 120 | | | |/ 121 +IP only +---+ SH + BFER +-----| 122 |receiver | | (CNAP) |\ | 123 |UE | +----/\------+ | 124 +---------+ || | 125 || +----------+ +---------+ 126 || | | | | 127 |-------- | BFR |---| BFR |------| 128 | | | | | | 129 | +----------+ +---------+ | 130 +---------+ +-------+ 131 | |------------------------------------>| BFIR | 132 + BIER TE + | + | 133 | PCE | +---------+ +-------+ | SH | 134 | |--|| | |----| BFR |----|(SNAP) | 135 +---------+ || | BFR | +-------+ | | 136 || | | +-------+ 137 || +---------+ /|\ 138 +---------+ +------\/----+ | | 139 | | | |/ | | 140 +IP only +---+ SH + BFER +------| +----------+ 141 |receiver | | (CNAP) |\ | IP only | 142 +---------+ +------------+ | Sender | 143 |(Server) | 144 +----------+ 146 [SH : Service Handler, CNAP : Client Network Attachment Point] 147 [SNAP : Server Network Attachment Point] 148 [PCE : Path Computation Element] 150 Figure 1: Deployment over BIER 152 The multicast overlay is formed by the BFIR and BFER of the BIER 153 layer and the additional SH (Service Handler) and PCE (Path 154 Computation Element) elements shown in the figure. When 155 interconnecting with a non-BIER enabled IP routed peering network, a 156 special SH, such as Border Gateway may be used. 158 The Service Handler and BFER can be assumed to be collocated and can 159 be viewed as Client Network Attachment Point (CNAP). Clients sends 160 and receives HTTP transactions through CNAP. 162 On the server side, the Service handling function can be part of the 163 Server Network Attachment Point (SNAP). It includes the BFIR 164 function and SH. SNAP is responsible for aggregating the relevant 165 HTTP Requests and sending one or more BIER Multicast HTTP response to 166 multiple clients who requested the same content. 168 The SH function is assumed to be collocated with BFIR / BFER. The 169 BFIR and BFER is assumed to be normal router boxes in the network. 170 If the additional function of SH cannot be added to normal routers, 171 then SH can be deployed as a separate function outside the routers. 172 In such scenario an interface between SH and BFIR or BFER needs to be 173 defined. 175 As part of POINT/RIFE EU Horizon 2020 project, HTTP Level Multicast 176 use case has been executed on SDN based and ICN based underlay 177 network, as described in the [I-D.irtf-icnrg-deployment-guidelines]. 179 "HTTP multicast" demonstrated benefits in HTTP-level streaming video 180 delivery, when deployed on POINT test bed with 80+ nodes. This draft 181 [I-D.irtf-icnrg-deployment-guidelines] also describes protocol 182 requirements to enable HTTP multicast to work on ICN underlay. 184 2. Conventions used in this document 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 3. Use cases 192 With the extensive use of "web technology", "distributed services" 193 and availability of heterogeneous network, HTTP has effectively 194 transitioned into the common transport or session layer for E2E and 195 multi-hop communication across the web that is also called Service 196 signaling. Multi-hop when using a sequence of HTTP instance such as 197 HTTP caches. The draft "On the use of HTTP as a Substrate" 198 [I-D.ietf-httpbis-bcp56bis], describes how HTTP is commonly used 199 among service instances to communicate with each other, thus 200 abstracting the lower layer details to application developers. 202 Referring to the BIER Use Cases [I-D.ietf-bier-use-cases], multicast 203 is used to scale out HLS (HTTP live streaming) to a large number of 204 receivers that use HTTP. This is used today in solutions like DOCSIS 205 hybrid streaming [TR_IPMC_ABR]. Multicast can speed up both live and 206 high-demand VoD streaming. Adaptive Bit Rate IPMC [TR_IPMC_ABR] 207 describes use of IP multicast towards the CMTS or a box beside it, 208 where the content is converted to HTTP/TCP to stream to the receivers 209 (e.g., homes). A server hosting the HLS content is shown as "NAP 210 Server". The gateways acting as receivers for the multicast from the 211 server are shown as "Client-NAP" (CNAP). Each CNAP can serve 212 multiple clients. 214 HTTP request and response used in media streaming services like HLS, 215 use HTTP response for delivery of content. In such scenarios, where 216 semi-synchronous access to the same resource occurs (such as watching 217 prominent videos over Netflix or similar platforms or live TV over 218 HTTP), traffic grows linearly with the number of viewers since the 219 HTTP-based server will provide an HTTP response to each individual 220 viewer. This poses a significant burden on operators in terms of 221 costs and on users in terms of likely degradation of quality. 223 This solution is not limited to traditional TV broadcasting. 224 Consider a virtual reality use case where several users are joining a 225 VR session at the same time, e.g., centered around a joint event. 226 Hence, due to the temporal correlation of the VR sessions, we can 227 assume that multiple requests are sent for the same content at any 228 point, particularly when viewing angles of VR clients are similar or 229 the same. Due to availability of virtual functions and cloud 230 technology, the actual end point from where content is delivered may 231 change. 233 4. Requirements 235 A realization for the "HTTP multicast" use case may have the 236 following requirements: 238 o MUST support multiple FQDN-based service endpoints to exist in the 239 overlay 241 o MUST send FQDN-based service requests at the network level to a 242 suitable FQDN-based service endpoint via policy-based selection of 243 appropriate path information 245 o MUST allow for multicast delivery of HTTP response to same HTTP 246 request URI 248 o MUST provide direct path mobility, where the path between the 249 egress and ingress Service Routers(SR) can be determined as being 250 optimal (e.g., shortest path or direct path to a selected 251 instance), is needed to avoid the use of anchor points and further 252 reduce service-level latency 254 5. Realization over IP Multicast 256 IPTV or Internet video distribution in CDNs, uses HTTP Level 257 Multicast and realized over IP Multicast (IPMC). Many features of 258 the IPTV service uses IPMC Group dependent state. Besides popular 259 features like PIM, Mldp, in a variable bit rate encoded content 260 source, content consumption also depends on group state. 262 DVB released reference architecture [DVB_REF_ARCH] for an end-to-end 263 system to deliver linear content over IP networks in a scalable and 264 standards-compliant manner. It focuses on delivering Adaptive Bit 265 Rate unicast content over a IP multicast network. 267 A Multicast gateway is deployed in a CPE, Upstream Network Edge 268 device or Terminal and provides multicast to unicast conversion 269 facilities for several homes. All in-scope traffic on the access 270 network between the Multicast Gateway (e.g. network edge device) and 271 the Terminal or home gateway device is unicast. The individual media 272 files are encapsulated into other protocols, so that they can be 273 recovered as discrete files, when they exit the multicast pipe, which 274 is terminated at Multicast Gateway. Interface "L" between Multicast 275 server and Content playback supports fetching of all specified types 276 of Content, Conditional request, Range request, Caching etc. BBF 277 also started similar work in October 2016, called WT-399. This work 278 is now coordinated with DVB. BBF focuses on developing the device 279 management model. 281 Assume clients that are consuming the same content (such as a TV 282 program) and that this content has for each block (typically segments 283 worth 2 seconds of content) a set of outstanding requests from its 284 clients. When IP Multicast is used in the domain, such as in 285 aforementioned pre-existing solutions like in Cablelabs/DOCSIS 286 [TR_IPMC_ABR], all possible blocks of the content have to be mapped 287 to some IP multicast group, and the CNAP will need to know the 288 mapping of block to groups. For example, a live stream may have 11 289 different bitrates available. In the most simple Block to IP 290 multicast group mapping scheme, there could be 11 multicast groups, 291 one for all the blocks of one bitrate (note that this is not 292 necessarily done in deployments of this solution, but we consider it 293 here for the purpose of explanation). 295 If the multicast domain and especially the links into the CNAP has 296 enough bandwidth, this solution work well with IP multicast. As soon 297 as there is at least one Client connected to a CNAP for one 298 particular content, the CNAP would join all 11 multicast groups for 299 this content. 301 5.1. Mapping to Requirements 303 To realize "HTTP Level Multicast" over "IP Multicast", some 304 additional functions needs to be supported in an intermediate 305 (overlay) layer. 307 Support of mapping between FQDN based end points, Multicast Address. 308 Creating multicast group from FQDN based end points. 310 Control mechanism related to time when to start sending response as 311 the multicast group is created. It is required that the source 312 should not send response immediately to the Multicast address. Wait 313 for some time to build the group sufficiently and then send response. 315 Support of IGMP signaling between User device, NAPs and Multicast 316 Router. 318 5.2. Problems 320 If the number of clients on a CNAP for a particular program is large, 321 the approach will work fairly well, because the likelihood that each 322 of the 11 bitrates of a content is necessary for at least one Client 323 is then fairly high. 325 When the number of receivers is not very large, IP multicast runs 326 into two issues. If all the bitrates for the content are sent across 327 the same group, then many of the bitrates may not be required and 328 would have to be received unnecessarily and dropped by the CNAP. If 329 each bitrate was sent on a different IP multicast group, the CNAP 330 could dynamically join/leave each multicast group based on the known 331 receivers, but that would create an extremely high and undesirable 332 amount of IP multicast signaling protocol activity (PIM/IGMP) that is 333 easily overloading the network 335 For efficiency reasons, the CNAP would need to dynamically join to 336 only those bitrate steams where it does have outstanding requests, 337 therefore achieving the best efficiency. This would mean in the 338 worst case that a CNAP would need to send for each new block, aka.: 339 every two second for every client one IGMP/PIM leave and one IGMP/PIM 340 join towards the upstream router to get a block for an appropriate 341 bitrate (or changed content) whenever bitrate or content on a client 342 have changed. This high rate of control-plane signaling between CNAP 343 and routers, and even between routers inside the multicast Domain is 344 a major pain point and may easily prohibit deployment of these 345 solutions because in many network devices, the performance of PIM/ 346 IGMP is not scaled for continuous change in forwarding. Even worse, 347 the limit may not simply be the CPU performance of the routers 348 control plane, but a limitation in the number of changes in 349 forwarding that the forwarding plane units (NPU/ASICs) can support. 351 6. Realization over BIER 352 6.1. Description of a "BIER Multicast Overlay" to support HTTP 353 Multicast 355 The Service Handler (as in Figure 1) in BIER Multicast Overlay, 356 process the FQDN in the service request. At the service level, e.g. 357 HTTP service, the fixed relationship among consumer and providers may 358 be abstracted using "Service Names", and the changing relationship at 359 the Service execution endpoints can be managed at the "multicast 360 overlay" level, handing out the exact locations where service request 361 or response needs to be sent to BIER layer. 363 +-------------+ +-----------+ +-----------+ 364 | | | | | PATH ID | 365 | Service name| | Multicast | | translates| 366 | [producer, |------->| Overlay |------>| to BIER | 367 | consumer] | | Layer | | header | 368 | | | | | | 369 +-------------+ +-----------+ +-----------+ 371 Figure 2: Service name to Path ID translation 373 We illustrate this using HTTP URI as service names. It should be 374 noted, other identifiers can also be used as service name, such as an 375 IP address. In the example illustration, other layers such as TCP, 376 IP has been terminated at the egress point. Outside BIER domain we 377 terminate TCP/IP session to extract the URI. The URI is processed by 378 the "multicast overlay" layer to generate PATH IDENTIFIER , which is 379 used as BIER header. 381 Path Identifier or PATH ID, is used in path-based approach, which 382 utilizes path information provided by the source of the packet for 383 forwarding said packet in the network. This is similar to segment 384 routing albeit differing in the type of information provided for such 385 source-based forwarding. 387 Once the BIER header is determined and added at the BFIR, the rest of 388 the transport layers is assumed to be any underlay technology as 389 supported by BIER. We assume TCP friendly transport, which can 390 assure reliable delivery. 392 6.1.1. BIER Multicast Overlay Components 394 With reference to Figure 1, the following components are part of BIER 395 Multicast Overlay Layer. 397 o Service Handler (SH): The Service handler terminates transport 398 level protocols, such as TCP, and extracts the URI. It processes 399 the URI in order to determine the PATH ID by contacting the PCE 400 for a suitable path resolution, which in turn is used to send the 401 HTTP Request. 403 o Optional PCE : Path Computation Element keeps track of all service 404 execution end points through a registration process. SH interacts 405 with the PCE to obtain PATH information by resolving the FQDN from 406 the incoming URI at the ingress SH to a suitable PATH ID. 408 o Interface functions to BFIR where the PATH ID is mapped to BIER 409 header. An Interface to the BFER is likely not required because 410 the BFER will only receive the traffic that they need and should 411 be able to derive from the BIER payload which subset of its 412 receivers need to get an HTTP encapsulated version of a particular 413 reply. 415 6.1.2. BIER Multicast Overlay Operations 417 As shown in Figure 3, the "Multicast overlay function" includes a 418 function called PCE (Path Computation Element function), which is 419 responsible for selecting the correct multicast end point and 420 possibly realizing path policy enforcement. The result of the 421 selection is a BIER path identifier, which is delivered to the SH 422 upon initial path computation request (or provided to the ingress 423 router BFIR to be added as BIER header ) (i.e., when sending a 424 request to or response for a specific URL for the first time). The 425 path identifier is utilized for any future request for a given URL- 426 based request. 428 All service end points indicate availability to the PCE through a 429 registration procedure, the PCE will instruct all SHs to invalidate 430 previous path identifiers to the specific URL that might exist. This 431 may result in an a renewed path computation request at the next 432 service request forwarding. Through this, the newly registered 433 service endpoint might be utilized if the policy-governed path 434 computation selects said service instance. Otherwise, a previously 435 resolved PATH ID for the URI determined at the ingress SH is being 436 used instead, removing any resolution latency to an SH-local lookup 437 of the PATH ID. 439 +-------+ +------+----+ +--------+ +----+-----+ 440 |Apps | |Apps----> | | PCE | | | APP | 441 |layer |--->|layer | SH | +---/\---+ | SH--> | 442 |prot | |prot | | || | | LYR | 443 +-------+ +------+----+ +---------+ +---------+ +----+-----+ 444 | L2 | | L2 |-->|Forwarder|-->|Forwarder|-->| L2 | 445 +-------+ +------+----+ +---------+ +---------+ +----------+ 446 |--------BIER DOMAIN -------| 448 Figure 3: Protocol for Multicast Overlay Layer 450 In the diagram shown above, an HTTP request is sent by an IP-based 451 device towards the FQDN of the server defined in the HTTP request. 453 At the client facing SH, the HTTP request is terminated at the TCP 454 level at a local HTTP proxy. The server side SH at the egress 455 terminates any transport protocol on the outgoing (server) side. 456 These terminating functions are assumed to be part of the client/ 457 server SH. As a consequence, the SH obtains the destination "Service 458 Name" from the received HTTP request. 460 If no local BIER forwarding information exists at the client side SH, 461 the path computation entity (PCE) is consulted, which calculates a 462 unicast path from the BFIR to which the client SH is connected to the 463 BFER to which the server SH is connected. The PCE provides the 464 forwarding information (Path ID) to the client SH, which in turn 465 caches the result. The Client SH may forward the Path ID to BFIR, 466 which creates the BIER header. 468 +-------------+--------------+ 469 | | | 470 | BIER HEADER | HTTP REQUEST | 471 | | [ENCODED IN | 472 | | TEXT] | 473 | | | 474 +-------------+--------------+ 476 Figure 4: Encapsulation of Service Request 478 Ultimately, the "HTTP Request" encapsulated by BIER header, as shown 479 in above diagram, is forwarded by the client SH towards the server- 480 facing SH via the local BFIR. We assume a (TCP-friendly) transport 481 protocol being used for the transmission between client and server 482 SH. The possibility of sending one HTTP response to several CNAPs 483 makes this a reliable multicast transport protocol. The exact nature 484 of this transport protocol is left for further studies. A suitable 485 transport or Layer 2 encapsulation, as supported by BIER layer, is 486 added to the above payload. 488 +-------------+-------------+--------------+ 489 | | | | 490 | Transport L2| BIER HEADER | HTTP REQUEST | 491 | HEADER | | [ENCODED IN | 492 | | | TEXT] | 493 | | | | 494 +-------------+-------------+--------------+ 496 Figure 5: Transport Encapsulation of BIER payload 498 Upon arrival of an HTTP request at the server SH, it forwards the 499 HTTP request as a well-formed HTTP request locally to the server, 500 awaiting an HTTP response for the reverse direction. 502 If no BIER forwarding information exists for the reverse direction 503 towards the requesting client SH, this information is requested from 504 the PCE, similar to the operation in forward direction. 506 6.2. Achieving Multicast Responses 508 Upon arrival of any further client SH request at the server SH to an 509 HTTP request whose response is still outstanding, the client SR is 510 added to an internal request table. Optionally, the request is 511 suppressed from being sent to the server. 513 Upon arrival of an HTTP response at the server SH, the server SH 514 consults its internal request table for any outstanding HTTP requests 515 to the same request. The server SH retrieves the stored BIER 516 forwarding information for the reverse direction for all outstanding 517 HTTP requests and determines the path information to all client SHs 518 through a binary OR over all BIER forwarding identifiers with the 519 same SI field. This newly formed joint BIER multicast response 520 identifier is used to send the HTTP response across the network. 522 BIER makes the solution scalable. Instead of IP multicast with IGMP/ 523 PIM, BIER is being used between Server NAP (SNAP) and CNAP, the SNAP 524 simply coalesces the forwarded HTTP requests from the CNAP, and 525 determines for every requested block the set of CNAPs requesting it. 526 A set of CNAPs corresponds to a set of bits in the BIER-bitstring, 527 one bit per CNAP. The SNAP then sends the block into BIER with the 528 appropriate bitstring set. 530 This completely eliminates any dynamic multicast signaling between 531 CNAP and SNAP. It also avoids sending of any unnecessary data block, 532 which in the IP multicast solution is pretty much unavoidable. 534 Furthermore, using the approach with BIER, the SNAP can also easily 535 control how long to delay sending of blocks. For example, it may 536 wait for some percentage of the time of a block (e.g, 50% = 1 537 second), therefore ensuring that it is coalescing as many requests 538 into one BIER multicast answer as possible. 540 6.3. BIER multicast Overlay Traffic Management 542 BIER-TE (BIER Traffic Engineering [I-D.ietf-bier-te-arch]) forwards 543 and replicates packets like BIER based on a BitString in the packet 544 header. Where BIER forwards and replicates its packets on shortest 545 paths towards BFER, BIER-TE allows (and requires) to also use bits in 546 the bitstring to indicate the paths in the BIER domain across which 547 the BIER-TE packets are to be sent. This is done to support Traffic 548 Engineering for BIER packets via explicit hop-by-hop and/or loose hop 549 forwarding of BIER-TE packets. A BIER-TE controller calculates 550 explicit paths for this packet forwarding. 552 The Multicast Flow Overlay operates as in BIER. Instead of 553 interacting with the BIER layer, it interacts with the BIER-TE 554 Controller. 556 In this draft, "Name-based" service forwarding over BIER, is 557 described to handle changes in service execution end points and 558 manage adhoc relationship in a multicast group. BIER-TE is another 559 way of doing this, while integrated with BIER architecture. The PCE 560 function described earlier in the BIER Multicast Overlay, may become 561 part of BIER-TE Controller. The SH function in the CNAP and SNAP 562 communicates with BIER TE controller. SH sends the service name to 563 the controller, which process the request using the PCE function and 564 returns the "bitstring" to be used as BIER header for delivery of the 565 HTTP response to multiple clients. 567 7. Next Steps 569 This Applicability Statement document describes how HTTP multicast 570 responses can be realized over BIER. This document describes the 571 functionalities in the multicast overlay layer to enable this 572 functionality. We would like to get feedback and support from the WG 573 to continue this work. We will elaborate further on specific 574 protocols for the overlay layer and request adoption as a WG draft. 576 8. IANA Considerations 578 This document requests no IANA actions. 580 9. Security Considerations 582 The operations in Section 6 consider the forwarding of HTTP packets 583 between ingress and egress points based on information derived from 584 the HTTP request. The support for HTTPS is foreseen to ensure 585 suitable encryption capability of such exchanges. Future updates to 586 this draft will outline the support for such HTTPS-based exchanges. 588 10. Informative References 590 [DVB_REF_ARCH] 591 DVB, "Adaptive media streaming over IP multicast", DVB 592 Document A176, March 2018, 593 . 597 [I-D.ietf-bier-te-arch] 598 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 599 Engineering for Bit Index Explicit Replication (BIER-TE)", 600 draft-ietf-bier-te-arch-00 (work in progress), January 601 2018. 603 [I-D.ietf-bier-use-cases] 604 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 605 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 606 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-07 607 (work in progress), July 2018. 609 [I-D.ietf-httpbis-bcp56bis] 610 Nottingham, M., "On the use of HTTP as a Substrate", 611 draft-ietf-httpbis-bcp56bis-05 (work in progress), May 612 2018. 614 [I-D.irtf-icnrg-deployment-guidelines] 615 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 616 "Deployment Considerations for Information-Centric 617 Networking (ICN)", draft-irtf-icnrg-deployment- 618 guidelines-04 (work in progress), September 2018. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [TR_IPMC_ABR] 626 CableLabs, "IP Multicast Adaptive Bit Rate Architecture 627 Technical Report", OC-TR-IP-MULTI-ARCH-V01-141112 C01, 628 October 2016, . 632 Authors' Addresses 634 Debashish Purkayastha 635 InterDigital Communications, LLC 636 Conshohocken 637 USA 639 Email: Debashish.Purkayastha@InterDigital.com 641 Akbar Rahman 642 InterDigital Communications, LLC 643 Montreal 644 Canada 646 Email: Akbar.Rahman@InterDigital.com 648 Dirk Trossen 649 InterDigital Communications, LLC 650 64 Great Eastern Street, 1st Floor 651 London EC2A 3QR 652 United Kingdom 654 Email: Dirk.Trossen@InterDigital.com 655 URI: http://www.InterDigital.com/ 657 Toerless Eckert 658 Huawei USA - Futurewei Technologies Inc. 659 2330 Central Expy 660 Santa Clara 95050 661 USA 663 Email: tte+ietf@cs.fau.de