| Network Working Group | D. Purkayastha |
| Internet-Draft | A. Rahman |
| Intended status: Informational | D. Trossen |
| Expires: September 2, 2018 | InterDigital Communications, LLC |
| March 1, 2018 |
Multicast HTTP using BIER
draft-purkayastha-bier-multicast-http-00
HTTP Level multicast, using BIER, is described in the working group use case document. Specifically, it describes how individual HTTP responses can utilize a single BIER multicast response, utilizing an edge-based service routing components on top of the BIER transport. In order to enable the use case, the document describes additional functions in the ingress and egress nodes to the BIER network. These functions are assumed to be part of the BIER multicast overlay.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
BIER Use Cases document [I-D.ietf-bier-use-cases] describes an “HTTP Level Multicast” scenario, where HTTP Responses are carried over a BIER multicast infrastructure to multiple clients. HTTP-level clients benefit from the dynamic multicast group formation enabled by BIER. For this, the server side Service Router (SR), creates a list of outstanding client side Service Router (SR) requests for the same HTTP resource. When a response is available, BIER forwarding information is retrieved and used to send the HTTP response.
In this draft, we introduce the requirements for a BIER multicast overlay realizing this use case. It also describes the necessary functions that form the BIER multicast overlay and the operations that enable the desired “HTTP Level Multicast” behavior. We describe a list of protocols needed for the realization of the individual operations.
We conclude with future steps and seek input from the WG.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
With the extensive use of “web technology”, “distributed services” and availability of heterogeneous network, HTTP has effectively transitioned into the common transport for E2E communication across the web. HTTP request and response is used in media streaming and delivery applications. In such scenarios, where semi-synchronous access to the same resource occurs (such as watching prominent videos over Netflix or similar platforms or liveTV 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. BIER can greatly reduce this burden, as described in the use case [I-D.ietf-bier-use-cases], by utilizing the BIER routing overlay to transport a single HTTP response to several edge nodes. Edge nodes may have additional logic to ‘route’ the HTTP-based service from and to the individual clients. The path-based routing applied in BIER is particularly appealing since it will allow for building those multicast relations per HTTP request/response relation in an ad-hoc manner, thereby improving flexibility and utilization even further.
Applicability of “HTTP Level Multicast” is not only restricted for Video streaming and delivery. It may be applied in other use cases such as Virtual Reality, V2X where users may access, in semi-synchronous way, the same resource.
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. The “HTTP Level Multicast” use case allows reducing the load on the network and faster delivery of content.
In a V2X scenario, at a particular location, as many vehicles enters, they may request geo-location, safety related information from the same content server. The requests may be semi-synchronous or close in chronological order. “HTTP Level Multicast” will reduce the flood of HTTP response and latency in delivering the information to the vehicles.
As part of POINT/RIFE EU Horizon 2020 project, HTTP Level Multicast use case has been executed on SDN based and ICN based underlay network, as described in the [I-D.irtf-icnrg-deployment-guidelines]. “HTTP multicast” demonstrated benefits in HTTP-level streaming video delivery, when deployed on POINT test bed with 80+ nodes. This draft [I-D.irtf-icnrg-deployment-guidelines] also describes protocol requirements to enable HTTP multicast to work on ICN underlay.
This use case completely works as an overlay on BIER. The multicast here is ad-hoc, i.e., the multicast relations are built at the level of each HTTP response and can therefore vary from one request/response transaction to others. Returning to our VR scenario above, the multicast relations are being formed for each request for a VR video chunk. If more than one VR client has requested said chunk at the time defined by the response delay for delivering the chunk from the video server, BIER multicast relations are formed in an ad-hoc manner and the response is sent to the clients with outstanding requests to the same chunk via a BIER-level multicast. Note that these multicast relations are highly dynamic. For instance, in the case of the VR scenario, changes in viewing angles by VR clients will result in completely access patterns to chunks at the next retrieval. This differs from edge multicast flow aggregators which assume stable multicast relations that can be mapped onto, e.g., IP multicast.
This use case describes how a single HTTP Response, which represents N number of responses for the same resource, can be directed towards correct ingress point in a fast and dynamic way. The routing decision is abstracted at HTTP level, instead of the traditional approach where routing decision for a service request is made at Layer 3 after resolution of the service name onto a locator such as an IP address. This means HTTP requests and responses are routed based on the URI associated with the request. URI is simply put, name of a resource. Using URI to identify Source and Destination, HTTP requests are routed using a path-based forwarding. To summarize, routing of HTTP request/response can be done based on named services and HTTP is used as a special named (application layer) service. The routing of those request in done via a service router (as shown in Fig. 1), which utilizes a path-based approach to forwarding.
+--------------+
| |
/images/* /| Image server |
/ | pool |
+---------+ +----------+ / | |
| | xyz.com | | / +--------------+
| Users |----------\| Service |/
| |----------/| Router |\
+---------+ | | \
+----------+ \ +-------------+
\ | |
/video/* \| Video server|
| pool |
| |
+-------------+
Figure 1: Path Based Routing
This service router is configured with rules to forward requests based on the URL path. E.g in case of multiple micro-services being run, traffic can be routed to multiple back-end services using path-based routing. For example, general requests are routed to one target group and requests to render images to another target group.
“HTTP Level multicast” may work on existing transport technology using SDN based forwarding [Reed2016]. This option utilizes path-based forwarding through SDN-based wildcard matching fields, supported with OF1.2+ [Reed2016]. It can be embedded into slicing approach of underlying transport infrastructure by leaving typical slicing fields available (e.g., VLAN tags). The forwarding utilizes the Ethernet frame format at Layer 2, representing the topological links of a specific forwarding path in the transport network as unique bits in a fixed size bit array. For the latter, the approach utilizes the IPv6 source and destination fields for storing the bit array information (in a simple version for this forwarding, this limits the topology to 256 links but extensions schemes are possible, which are left out of this document at this stage). AS mentioned, the SDN forwarding action is a simple wildcard matching, supported with OF1.2+, with the wildcard representing the unique bit of a switch-specific output port. With that, the switch needs to consider as many forwarding rules as switch local output ports, see [Reed2016] for more information.
A realization for the “HTTP multicast” use case may have the following requirements:
Let us formulate the architecture of the BIER multicast overlay for the scenario outlined in [I-D.ietf-bier-use-cases]. This overlay is shown in Figure 2 below.
The multicast overlay is formed by the BFIR and BFER of the BIER layer and the additional SR and PCE elements shown in the figure. When connecting to a standard IP routed peering network, a special SR is utilized, shown as the border GW in the figure.
+---------+ +---------+
| | | |
+IP only +---+ SR +--------|
|receiver | | | |
|UE | +---------+ |
+---------+ |
+----------+ +---------+
| | | |
| BFER |---| BFR |------|
| | | | |
+----------+ +---------+ |
+-------+
|-------| BFER |
+---------+ +----|--+ +---|---+
| |----| BFR | |
| BFIR | +-------+ +--------+
| | | SR |
+---------+ +--------+
+---------+ +---------+ | |
| | | | | |
+IP only +---+ SR +---------| +----------------+
|sender UE| | | | IP only sender |
+---------+ +---------+ | and receiver |
| UE |
+----------------+
Figure 2: BIER Multicast Overlay for HTTP Multicast Use case
As shown in Figure 2, the multicast overlay 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 SR upon initial path computation request (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 SRs to invalidate previous path identifiers to the specific URL. This may result in an initial 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.
In the architecture of Figure 2, an HTTP request is sent by an IP-based device towards the FQDN of the server defined in the HTTP request.
At the client facing SR, the HTTP request is terminated at the HTTP level at a local HTTP proxy. We assume termination on the client side at Layer 3 and above protocols, such as TCP. Server side SR at the egress, terminates any transport protocol on the outgoing (server) side. These terminating functions are assumed to be part of the client/server SR.
If no local BIER forwarding information exists to the server SR, a path computation entity (PCE) is consulted, which calculates a unicast path from the BFIR to which the client SR is connected to the BFER to which the server SR is connected. The PCE provides the forwarding information to the client SR, which in turn caches the result.
Ultimately, the HTTP request is forwarded by the client SR towards the server-facing SR via the local BFIR. We assume a (TCP-friendly) transport protocol being used for the transmission between client and server SR while not mandating the use of TCP for this transmission.
Upon arrival of an HTTP request at the server SR, the server SR proxy forwards the HTTP request as a well-formed HTTP request locally to the server.
If no BIER forwarding information exists for the reverse direction towards the requesting client SR, this information is requested from the PCE, similar to the operation in forward direction.
Upon arrival of any further client SR request at the server SR to an HTTP 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 an HTTP response at the server SR, the server SR consults its internal request table for any outstanding HTTP requests to the same request. The server SR retrieves the stored BIER forwarding information for the reverse direction for all outstanding HTTP requests and determines the path information to all client SRs 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 HTTP response across the network.
For the operations outlined in the previous section, we foresee the following protocol changes may be required:
Given the importance of HTTP-based services, we therefore suggest to include an additional Applicability Statement documenting how BIER can be applied to aggregate HTTP responses over a BIER infrastructure (which we term as “HTTP Multicast”). This new proposed Applicability Statement document will describe how BIER can be applied to implement efficient, dynamic multicast support for the delivery of HTTP responses to individual HTTP requests for the same resource.
This document requests no IANA actions.
TBD.
| [I-D.ietf-bier-use-cases] | Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., Przygienda, T., Gulko, A., Robinson, D., Arya, V. and C. Bestler, "BIER Use Cases", Internet-Draft draft-ietf-bier-use-cases-06, January 2018. |
| [I-D.irtf-icnrg-deployment-guidelines] | Rahman, A., Trossen, D., Kutscher, D. and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", Internet-Draft draft-irtf-icnrg-deployment-guidelines-00, February 2018. |
| [Reed2016] | Reed, M., Al-Naday, M., Thomas, N., Trossen, D., Petropoulos, G. and S. Spirou, "Stateless multicast switching in software defined networks", ICC 2016, 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |