Internet DRAFT - draft-purkayastha-bier-multicast-http
draft-purkayastha-bier-multicast-http
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
Abstract
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.
Status of This Memo
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 Notice
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
Purkayastha, et al. Expires September 2, 2018 [Page 1]
Internet-Draft HTTP Multicast March 2018
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
3.2. State Of The Art . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. HTTP Multicast Overlay Components . . . . . . . . . . . . . . 6
6. HTTP Multicast Overlay Operations . . . . . . . . . . . . . . 7
7. Required Protocol Changes . . . . . . . . . . . . . . . . . . 9
8. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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.
2. Conventions used in this document
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].
Purkayastha, et al. Expires September 2, 2018 [Page 2]
Internet-Draft HTTP Multicast March 2018
3. Background
3.1. Applicability
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
Purkayastha, et al. Expires September 2, 2018 [Page 3]
Internet-Draft HTTP Multicast March 2018
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.
3.2. State Of The Art
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.
Purkayastha, et al. Expires September 2, 2018 [Page 4]
Internet-Draft HTTP Multicast March 2018
+--------------+
| |
/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.
Purkayastha, et al. Expires September 2, 2018 [Page 5]
Internet-Draft HTTP Multicast March 2018
4. Requirements
A realization for the "HTTP multicast" use case may have the
following requirements:
o MUST support multiple FQDN-based service endpoints to exist in the
overlay
o MUST send FQDN-based service requests at the network level to a
suitable FQDN-based service endpoint via policy-based selection of
appropriate path information
o MUST allow for multicast delivery of HTTP response to same HTTP
request URI
o MUST provide direct path mobility, where the path between the
egress and ingress Service Routers(SR) can be determined as being
optimal (e.g., shortest path or direct path to a selected
instance), is needed to avoid the use of anchor points and further
reduce service-level latency
5. HTTP Multicast Overlay Components
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.
Purkayastha, et al. Expires September 2, 2018 [Page 6]
Internet-Draft HTTP Multicast March 2018
+---------+ +---------+
| | | |
+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
6. HTTP Multicast Overlay Operations
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.
Purkayastha, et al. Expires September 2, 2018 [Page 7]
Internet-Draft HTTP Multicast March 2018
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.
Purkayastha, et al. Expires September 2, 2018 [Page 8]
Internet-Draft HTTP Multicast March 2018
7. Required Protocol Changes
For the operations outlined in the previous section, we foresee the
following protocol changes may be required:
o SR-to-SR protocol for HTTP: Map HTTP to BIER message exchange
between client and server SRs
o SR-PCE protocol: Used for path computation and delivery of BIER
routing information as well as path updates
o Registration protocol: Used to register FQDN service endpoints
8. Next Steps
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.
9. IANA Considerations
This document requests no IANA actions.
10. Security Considerations
TBD.
11. Informative References
[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", draft-ietf-bier-use-cases-06
(work in progress), January 2018.
[I-D.irtf-icnrg-deployment-guidelines]
Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", draft-irtf-icnrg-deployment-
guidelines-00 (work in progress), February 2018.
Purkayastha, et al. Expires September 2, 2018 [Page 9]
Internet-Draft HTTP Multicast March 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,
<https://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Debashish Purkayastha
InterDigital Communications, LLC
Conshohocken
USA
Email: Debashish.Purkayastha@InterDigital.com
Akbar Rahman
InterDigital Communications, LLC
Montreal
Canada
Email: Akbar.Rahman@InterDigital.com
Dirk Trossen
InterDigital Communications, LLC
64 Great Eastern Street, 1st Floor
London EC2A 3QR
United Kingdom
Email: Dirk.Trossen@InterDigital.com
URI: http://www.InterDigital.com/
Purkayastha, et al. Expires September 2, 2018 [Page 10]
