Internet DRAFT - draft-purkayastha-multicast-http-using-bier
draft-purkayastha-multicast-http-using-bier
Network Working Group D. Purkayastha
Internet-Draft A. Rahman
Intended status: Informational D. Trossen
Expires: April 30, 2018 InterDigital Communications, LLC
October 27, 2017
Multicast HTTP using BIER
draft-purkayastha-multicast-http-using-bier-00
Abstract
HTTP Level multicast, using BIER, is described as a use case in
[I-D.ietf-bier-use-cases]. 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 April 30, 2018.
Copyright Notice
Copyright (c) 2017 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
Purkayastha, et al. Expires April 30, 2018 [Page 1]
Internet-Draft HTTP Multicast October 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. HTTP Multicast Overlay Components . . . . . . . . . . . . . . 3
4. HTTP Multicast Overlay Operations . . . . . . . . . . . . . . 4
5. Required Protocol Changes . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
BIER Use Cases document [I-D.ietf-bier-use-cases] describes an "HTTP
Level Multicast" scenario, where HTTP-level clients benefit from the
dynamic multicast group formation enabled by BIER. HTTP multicast
means aggregating individual HTTP Responses (e.g. for the same
segment of a viral video) and mapping it onto the BIER multicast
overlay. For this, the server NAP (network attachment point),
creates a list of outstanding client NAP requests to the same HTTP
request URI. 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 protocol changes needed for the realization of the
individual operations.
2. 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
Purkayastha, et al. Expires April 30, 2018 [Page 2]
Internet-Draft HTTP Multicast October 2017
o MUST provide direct path mobility, where the path between the
egress and ingress NAPs 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
3. 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 1 below.
The multicast overlay is formed by the BFIR and BFER of the BIER
layer and the additional NAP and PCE elements shown in the figure.
When connecting to a standard IP routed peering network, a special
NAP is utilized, shown as the border GW in the figure.
+---------+ +---------+
| | | |
+IP only +---+ NAP +--------|
|reciever | | | |
|UE | +---------+ |
+---------+ |
+----------+ +---------+
| | | |
| BFER |---| BFR |------|
| | | | |
+----------+ +---------+ |
+-------+
|-------| BFER |
+---------+ +----|--+ +---|---+
| |----| BFR | |
| BFIR | +-------+ +--------+
| | | NAP |
+---------+ +--------+
+---------+ +---------+ | |
| | | | | |
+IP only +---+ NAP +---------| +----------------+
|sender UE| | | | IP only sender |
+---------+ +---------+ | and reciever |
| UE |
+----------------+
Figure 1: BIER Multicast Overlay for HTTP Multicast Use case
Purkayastha, et al. Expires April 30, 2018 [Page 3]
Internet-Draft HTTP Multicast October 2017
4. HTTP Multicast Overlay Operations
As shown in Figure 1, 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 NAP 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 NAPs 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 1, 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 NAP, 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 NAP at the
egress, terminates any transport protocol on the outgoing (server)
side. These terminating functions are assumed to be part of the
client/server NAP.
If no local BIER forwarding information exists to the server (NAP), a
path computation entity (PCE) is consulted, which calculates a
unicast path from the BFIR to which the client NAP is connect to the
BFER to which the server NAP is connected. The PCE provides the
forwarding information to the client NAP, which in turn caches the
result.
Ultimately, the HTTP request is forwarded by the client NAP towards
the server-facing NAP via the local BFIR. We assume a (TCP-friendly)
transport protocol being used for the transmission between client and
server NAP while not mandating the use of TCP for this transmission.
Upon arrival of an HTTP request at the server NAP, the server NAP
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 NAP, this information is requested from
the PCE, similar to the operation in forward direction.
Purkayastha, et al. Expires April 30, 2018 [Page 4]
Internet-Draft HTTP Multicast October 2017
Upon arrival of any further client NAP request at the server NAP to
an HTTP request whose response is still outstanding, the client NAP
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 NAP, the server NAP
consults its internal request table for any outstanding HTTP requests
to the same request. The server NAP retrieves the stored BIER
forwarding information for the reverse direction for all outstanding
HTTP requests and determines the path information to all client NAPs
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.
5. Required Protocol Changes
For the operations outlined in the previous section, we foresee the
following protocol changes may be required:
o NAP-to-NAP protocol for HTTP: Map HTTP to BIER message exchange
between client and server NAPs
o NAP-PCE protocol: Used for path computation and delivery of BIER
routing information as well as path updates
o Overlay transport protocol: Used for transport-level exchange over
BIER layer
o Registration protocol: Used to register FQDN service endpoints
o Content certificate distribution protocol: Used for HTTPS support
There is a similar ongoing work in SFC WG, which handles HTTP
redirection [I-D.purkayastha-sfc-service-indirection]. The lower
layers for the NAPs and PCE infrastructure is similar between the two
approaches. Does the WG see value in supporting the requirements for
BIER to enable HTTP Multicast Use case as defined in
[I-D.ietf-bier-use-cases]? It also raises a relevant question, where
shall the protocol work be done?
6. IANA Considerations
This document requests no IANA actions.
Purkayastha, et al. Expires April 30, 2018 [Page 5]
Internet-Draft HTTP Multicast October 2017
7. Security Considerations
TBD.
8. Informative References
[I-D.ietf-bier-use-cases]
Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
Przygienda, T., arkadiy.gulko@thomsonreuters.com, a.,
Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases",
draft-ietf-bier-use-cases-05 (work in progress), July
2017.
[I-D.purkayastha-sfc-service-indirection]
Purkayastha, D., Rahman, A., and D. Trossen, "USE CASE FOR
HANDLING DYNAMIC CHAINING AND SERVICE INDIRECTION", draft-
purkayastha-sfc-service-indirection-00 (work in progress),
July 2017.
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 April 30, 2018 [Page 6]
