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