Request Routing Interface

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.