[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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


   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

   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",
   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

   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

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

   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

   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

   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


11.  Informative References

              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.

              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

              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,

Authors' Addresses

   Debashish Purkayastha
   InterDigital Communications, LLC

   Email: Debashish.Purkayastha@InterDigital.com

   Akbar Rahman
   InterDigital Communications, LLC

   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]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/