Realizing Forward Requests Return Multicast Semantic with BIER

Multicast communication semantics complements unicast communication with the ability to define the delivery of packets to more than one destination. For instance, defines source-specific multicast (SSM) as A datagram sent with source IP address S and destination IP address G in the SSM range is delivered to each host socket that has specifically requested delivery of datagrams sent by S to G, and only to those sockets. The nature of the 'specific request' for delivery is reflected in an explicit group management protocol, e.g., through which a host can request that delivery, becoming a member of the group (address) G as a consequence. In this document, we introduce a different multicast semantic where the nature of the 'specifically requested delivery' is that of a forward request to the server S, which in response either adds the response to that request to an existing multicast group or forms a new one on-demand. The nature of the multicast group, equivalent to G in , is ephemeral, limited by the time it takes to send a response to the (dynamically created) group of respondents. Multicast semantics of the aforementioned nature have been exploited and realized in previous work, such as , focussing on HTTP-based forward requests with multicast-delivered HTTP responses. These works were transferred onto a BIER-based systems in a previous draft . Similarly, this draft focussed entirely on the delivery of HTTP responses under such multicast semantic, progressing to WG last call in 2021. Due to organizational reasons on the side of (some of) the authors of this draft, comments from the BIER and application area community were not be possible to address with the draft finally abandoned in 2022. This document aims to take this initial work in further by (a) formally defining the underlying communication semantic for use across a number of use cases, (b) outline use case examples beyond 'just HTTP', (c) formulate requirements for its realization and (d) outline the realization in BIER.

The following abbreviations are used throughout the remainder of this draft, with reference to and for the definition (and technical explanation) of those terms: : Bit-Forwarding Egress Routers : Bit-Forwarding Ingress Routers : Bit-Forwarding Routers : Path Computation Element : Service Handler : Network Access Point

As the name FRRM (forward requests return multicast) indicates, multicast communication under this semantic is initiated through one or more forward request communication, i.e., from one or more of the eventual receivers of the multicast response(s). More formally, we define the FRRM semantic as A datagram with source address S towards destinations D1, ..., Dn is formed as one or more responses to adequate requests from D1, ..., Dn to S, where the ephemeral group address R is defined through an identifying characteristic across all received requests from D1, ..., Dn. Where 'identifying characteristic' is an implementation-specific parameter used to distinguish among different requests (e.g., identifiers such as URIs) from any of the D1, ..., Dn to S. The nature of FRRM multicast is inherently dynamic, i.e., the multicast responses are formed in response to incoming requests. One or more responses may be created for the ephemeral group that is being formed, thereby supporting request-response patterns as much as initiated streaming patterns (i.e. a single request may lead to a stream of responses). The ephemeral groups are not unique but several may exist with different receiver groups each. This may happen when a set of forward requests arrives before time t_1, upon which the server S decides to form the ephemeral group R towards the senders of those requests, while another group R may be formed for those incoming forward requests arriving after time t_1 and before another checkpoint time t_2. The decision when to form an ephemeral group R as a result of incoming forward requests is entirely left to the implementation considerations at the server S and may depend on the specific use case (see ).

This section expands on the original HTTP-focussed use case in (still listed as an example in ) through utilizing the FRRM semantic in, e.g., CDN optimization, distributed AI and more.

Referring to the BIER Use Cases , multicast is used to scale HTTP Live Streaming (HLS) to a large number of receivers that use HTTP. Multicast can speed up both live and high-demand VoD streaming. Adaptive Bit Rate IPMC describes the use of IP Multicast towards the CMTS or a box beside it, where the content is converted to HTTP/TCP to stream to the receivers (e.g., homes). A server hosting the HLS content is shown as "NAP Server". The gateways acting as receivers for the multicast from the server are shown as "Client-NAP" (CNAP). Each CNAP can serve multiple clients. Dynamic Adaptive Streaming (DASH) over HTTP is another HTTP-based streaming approach. In DASH, each media is described by a Media Presentation Description (MPD) file, through which a DASH client (e.g. a media player) is instructed how to download, interpret and play the media. The media content is encoded into fragments or chunks at different bit rates. Both the MPD and media fragments are stored at a server. The DASH client first needs to retrieve the MPD file from the server; then it can start to retrieve media fragments encoded at different bits rates from the server. DASH players may use rate adaptation, i.e., switching the retrieval from one rate chunks to another rate. Usually this rate adaptation is utilizing delay measurements, resulting in TCP like behavior in terms of backoff in case of increasing delay. DASH has been designed to reuse most of existing Internet infrastructure and protocols and can run over different underlying transports including HTTP. For example, two major media service providers Netflix and Youtube use DASH over HTTP as their streaming technology. HTTP request and response used in media streaming services like HLS and DASH over HTTP, use HTTP responses for delivery of content, i.e., each chunk is returned as an HTTP response to the requesting client. In such scenarios, where semi-synchronous access to the same resource occurs (such as watching prominent videos over Netflix or similar platforms or live TV over HTTP), traffic grows linearly with the number of viewers since the HTTP-based server will provide an HTTP response to each individual viewer. This poses a significant burden on operators in terms of costs and on users in terms of likely degradation of quality. The use of HTTP-based streaming of video content is not limited to traditional TV broadcasting. Consider a virtual reality use case where several users are joining a VR session at the same time, e.g., centered around a joint event. Hence, due to the temporal correlation of the VR sessions, we can assume that multiple requests are sent for the same content at any point, particularly when viewing angles of VR clients are similar or the same. Due to availability of virtual functions and cloud technology, the actual end point from where content is delivered may change. HTTP streaming is not limited to video content, however. Software updates for, e.g., mobile devices or vehicles, become increasingly important, introducing point-to-multipoint traffic from a software server to devices. Using V2X as an example, the software server could be a part of telecom operators or maintained by car manufacturers. In either case, the software server keeps vehicle software or firmware images, which will be transmitted to many vehicles across the global Internet, based on a pull or push model. HTTP is commonly used for those software updates to provide an E2E transport between the software server and each vehicle requesting software updates. As a result, the traffic from the software server to vehicles increases linearly with the number of connected vehicles since each vehicle will establish a HTTP connection with the software server.

More to come here based on the work outlined in

TODO: solicit a co-author with more background to cover this

TBD: capture formal requirements here

shows the architecture for FRRM over a BIER overlay.

| SH | || | +-------+ +---------+ +---\/+ +----+ | /|\ | | | | | |/ | | + IP only +---+ SH +-+BFER+------| +----------+ |receiver | | | | |\ | IP only | +---------+ +-----+ +----+ | Sender | | (Server) | +----------+ [SH : Service Handler, PCE : Path Computation Element] ]]> The multicast overlay is formed by the BFIR and BFER of the BIER layer and the additional Service Handler (SH) and Path Computation Element (PCE) elements shown in the figure. When interconnecting with a non-BIER enabled IP routed peering network, a special SH, such as Border Gateway may be used. The Service Handler and BFER could be collocated, forming therefore the equivalent of a Client or Server Network Attachment Point (CNAP or SNAP) . However, the SH may also be implemented in the clients and servers directly, avoiding some of the realization considerations discussed later, specifically those related to security associations. Lastly, the SH may be provisioned separately from both client/server and BFER/BFIR components. For instance, the SH may be part of a CPE deployment, where special applications access the FRRM capabilities, while utilizing a separate BIER overlay deployment of a network operator. Clients send and receive service transactions through the SH, i.e. forward requests and the responses, possibly delivered via BIER multicast capabilities. The SH on the server side is responsible for aggregating the relevant incoming forward requests and sending one or more BIER-based multicast response to multiple clients who requested the same content, following the FRRM semantic in .

The Service Handler (as in ) in BIER Multicast Overlay, process the service request. At the service level, e.g., for an HTTP service, the fixed relationship among consumer and providers may be abstracted using "Service Names", and the changing relationship at the Service execution endpoints can be managed at the "multicast overlay" level, handing out the exact locations where service requests or responses needs to be sent to BIER layer.

| Overlay |------>| to BIER | | consumer] | | Layer | | header | | | | | | | +-------------+ +-----------+ +-----------+ ]]> It should be noted, a number of identifiers can be used as service name, such as a URI or an IP address. In the example illustration, other layers such as TCP, IP have been terminated at the egress point. Outside BIER domain we terminate TCP/IP session to extract the service name to be processed by the "multicast overlay" layer to generate the PATH IDENTIFIER, which is used as BIER header. Path Identifier or PATH ID, is used in path-based approach, which utilizes path information provided by the source of the packet for forwarding said packet in the network. This is similar to segment routing albeit differing in the type of information provided for such source-based forwarding. Once the BIER header is determined and added at the BFIR, the rest of the transport layers is assumed to be any underlay technology as supported by BIER. We assume TCP friendly transport, which can assure reliable delivery.

With reference to , the following components are part of BIER Multicast Overlay Layer. Service Handler (SH): The Service handler terminates transport level protocols, such as TCP, and extracts the service name. It processes the service name in order to determine the PATH ID by contacting the PCE for a suitable path resolution, which in turn is used to send the service request. Optional PCE : Path Computation Element keeps track of all service execution end points through a registration process. SH interacts with the PCE to obtain PATH information by resolving the service name at the ingress SH to a suitable PATH ID. Interface functions to BFIR where the PATH ID is mapped to BIER header. An Interface to the BFER is likely not required because the BFER will only receive the traffic that they need and should be able to derive from the BIER payload which subset of its receivers need to get an encapsulated version of a particular reply.

As shown in , the "Multicast overlay function" includes a function called PCE (Path Computation Element function), which is responsible for selecting the correct multicast end point and possibly realizing path policy enforcement. The result of the selection is a BIER path identifier, which is delivered to the SH upon initial path computation request (or provided to the ingress router BFIR to be added as BIER header ) (i.e., when sending a request to or response for a specific URL for the first time). The path identifier is utilized for any future request for a given URL- based request. All service end points indicate availability to the PCE through a registration procedure, the PCE will instruct all SHs to invalidate previous path identifiers to the specific URL that might exist. This may result in an a renewed path computation request at the next service request forwarding. Through this, the newly registered service endpoint might be utilized if the policy-governed path computation selects said service instance. Otherwise, a previously resolved PATH ID for the URI determined at the ingress SH is being used instead, removing any resolution latency to an SH-local lookup of the PATH ID.

| | PCE | | | APP | |layer |--->|layer | SH | +---/\---+ | SH--> | |prot | |prot | | || | | LYR | +-------+ +------+----+ +---------+ +---------+ +----+-----+ | L2 | | L2 |-->|Forwarder|-->|Forwarder|-->| L2 | +-------+ +------+----+ +---------+ +---------+ +----------+ |--------BIER DOMAIN -------| ]]> In the diagram shown above, a service request is sent by an IP-based device towards the service name of the server defined in the service request. At the client facing SH, the service request is terminated at the TCP level. The server side SH at the egress terminates any transport protocol on the outgoing (server) side. These terminating functions are assumed to be part of the client/ server SH. As a consequence, the SH obtains the destination "Service Name" from the received service request. If no local BIER forwarding information exists at the client side SH, the path computation entity (PCE) is consulted, which calculates a unicast path from the BFIR to which the client SH is connected to the BFER to which the server SH is connected. The PCE provides the forwarding information (Path ID) to the client SH, which in turn caches the result. The Client SH may forward the Path ID to BFIR, which creates the BIER header.

Ultimately, the "Service Request" encapsulated by BIER header, as shown in above diagram, is forwarded by the client SH towards the server- facing SH via the local BFIR. We assume a (TCP-friendly) transport protocol being used for the transmission between client and server SH. The possibility of sending one service response to several SHs makes this a reliable multicast transport protocol. The exact nature of this transport protocol is left for further studies. A suitable transport or Layer 2 encapsulation, as supported by BIER layer, is added to the above payload.

Upon arrival of a service request at the server SH, it forwards the service request as a well-formed service request locally to the server, awaiting an service response for the reverse direction. If no BIER forwarding information exists for the reverse direction towards the requesting client SH, this information is requested from the PCE, similar to the operation in forward direction.

Upon arrival of any further client SH request at the server SH to an service request whose response is still outstanding, the client SR is added to an internal request table. Optionally, the request is suppressed from being sent to the server. Upon arrival of a service response at the server SH, the server SH consults its internal request table for any outstanding service requests to the same request. The server SH retrieves the stored BIER forwarding information for the reverse direction for all outstanding service requests and determines the path information to all client SHs through a binary OR over all BIER forwarding identifiers with the same SI field. This newly formed joint BIER multicast response identifier is used to send the service response across the network. BIER makes the solution scalable. Instead of IP Multicast with IGMP/ PIM, BIER is being used between Server SH and client SHs, the server-facing SH simply coalesces the forwarded service requests from the client-facing SH, and determines for every requested block the set of SHs requesting it. A set of SHs corresponds to a set of bits in the BIER-bitstring, one bit per SH. The SH then sends the block into BIER with the appropriate bitstring set. This completely eliminates any dynamic multicast signaling between client-facing SHs and server-facing SH. It also avoids sending of any unnecessary data block. Furthermore, using the approach with BIER, the server-facing SH can also easily control how long to delay sending of blocks. For example, it may wait for some percentage of the time of a block (e.g, 50% = 1 second), therefore ensuring that it is coalescing as many requests into one BIER multicast answer as possible. The realization of such controlled sending of a single response, however, needs further study as to the possible interaction with upper-layer methods, particularly congestion control.

BIER-TE (BIER Traffic Engineering ) forwards and replicates packets like BIER based on a BitString in the packet header. Where BIER forwards and replicates its packets on shortest paths towards BFER, BIER-TE allows (and requires) to also use bits in the bitstring to indicate the paths in the BIER domain across which the BIER-TE packets are to be sent. This is done to support Traffic Engineering for BIER packets via explicit hop-by-hop and/or loose hop forwarding of BIER-TE packets. A BIER-TE controller calculates explicit paths for this packet forwarding. The Multicast Flow Overlay operates as in BIER. Instead of interacting with the BIER layer, it interacts with the BIER-TE Controller. In this draft, "Name-based" service forwarding over BIER, is described to handle changes in service execution end points and manage adhoc relationship in a multicast group. BIER-TE is another way of doing this, while integrated with BIER architecture. The PCE function described earlier in the BIER Multicast Overlay, may become part of BIER-TE Controller. The server- and client-facing SH function communicates with the BIER TE controller. SH sends the service name to the controller, which processes the request using the PCE function and returns the "bitstring" to be used as BIER header for delivery of the service response to multiple clients.

TBD: add something on DASH here, app considerations for using SH capabilities, ...

TBD: move transport discussions in into this place and pose the challenges that need addressing beyond the FRRM aspect at the BIER level

This draft generalizes the work in beyond HTTP being the application protocol. Instead, this draft proposes a general multicast semantic termed 'forward requests return multicast' (FRRM), which can be utilized by any application layer protocol atop a BIER transport network.

The operations in consider the forwarding of service request packets between ingress and egress points based on information derived from the service request. The support for transport-level security, e.g., TLS, is foreseen to ensure suitable encryption capability of such exchanges. For this to happen, we expect certificate sharing agreements to exist between the content provider and the BIER overlay provider, ensuring the extraction of the suitable request parameters while allowing for the re-encryption of the content for an encrypted delivery over the BIER network. Since we liken the relationship between content and BIER overlay provider to that between content and CDN provider, the existence of certificate sharing agreements is similar to the practice used for CDNs.

TBD: Anything here on exposing request IDs?

This draft does not request any IANA action.

This draft originated from the narrower use case described in . We acknowledge the work that has gone into the development of this draft and the contributions through discussions on the mailing list. We specifically thank Toerless Eckert, Sebastian Robitzsch, Akbar Rahman and Chonggang Wang for their contributions to the original draft, some of which have been transferred to this draft, where appropriate.