Request Routing Interface

Project Status:

(roll over for info)

Ratification Phase 1 (Comment Window)

The project output is being reviewed by the membership and is open for comments. If the members approve the document to move on, the working group will review the comments. If the document can be edited without significantly altering the content, it will move onto Phase 2. If the comments result in substantial edits, the document must go through Phase 1 again.


November 1, 2021

Estimated Completion:

December 31, 2023

Problem Statement

The said Recursive mode of delegation (per the CDNi terminology) necessitates an interface between the upstream request router and the downstream router; this has been presented and discussed by Yoav (Qwilt) and Guillaume (Broadpeak) in May 2021 (2021Q2 meeting): The IETF CDNi group has issued a specification (RFC7975) for this problem but judged necessary for DNS redirection. However for HTTP redirection the specification does not consider a simple implementation based on a HTTP proxy. Moreover the specification does not consider the possibility to perform redirection based on manifest rewriting.

Project Description

RFC 7975 offers a common request routing interface for both HTTP and DNS request routing methods. At the same time, the RFC 7975 request routing architecture has several drawbacks, especially when it comes to managing HTTP-R and manifest rewriting request routing methods. Therefore, under RFC 7975, the dCDN request router RR interface can only provide an HTTP uniform resource identifier (URI) to redirect the user to, but cannot respond to the user’s HTTP request itself. In case of manifest rewrite, this adds an extra request, thereby eliminating the latency reduction advantages of the recursive request redirection. The RFC 7975 implementation is not well-suited for adoption by some CDN implementations that are based on proxy request chaining and do not allow for ad-hoc interface queries. Full re-encoding of ingress incoming user requests into a custom JSON format to be sent to the request routing interface is cumbersome and carries a computational overhead. It is also desirable for the dCDN request router RR interface to be able to act on the uCDN response rather than only on the user request. In some open caching use cases, the dCDN only has a relationship with the uCDN and does not have separate access to the content outside of the RR interface queries it receives from the uCDN. If so, the uCDN needs to forward the response to the dCDN in the following cases:
  • Rewrite some or all of the URIs in a video manifest to point to the dCDN.
  • Rewrite a video manifest to remove and/or augment manifest playback levels or otherwise optimize the content response, based on dCDN capacity, network conditions, or other dCDN business logic.
  • Make a decision whether to redirect the user request to the dCDN-based on content type, object size, or other attribute included in the content response.
Additionally and separately, even if the dCDN has an ability to retrieve the requested object from an external source, the uCDN may wish to dynamically adjust the response, for example to provide dynamic server-side ad insertion, device-driven playback level or encoding adjustment, image or payload compression, etc. In this case, the uCDN needs to forward the dynamically adjusted response for the dCDN to act on.

Project Type


Project Leads


There are no SMEs associated with this project.

Goals and Objectives

The objective of this project is to publish the Request Routing Interface specification document.

Project Scope


The following members have contributed to this project. Click on their name to visit their profile. If they have not published their profile, the link will redirect to their LinkedIn profile.

Additional References


There are no presentations associated with this project.