CDN Interconnect
Last updated
Last updated
CDN controllers in the Blockcast network interface with upstream content providers using , which is based on IETF CDN interconnection. It addresses one of the biggest challenges for CDN operators in attracting content providers to use their networks. Providing standard interfaces for deploying, configuring, and monitoring services across CDNs reduces the cost of maintaining multi-CDN deployments and onboarding into new networks.
It comprises 7 interfaces between an upstream content provider or uCDN and a downstream capacity provider or dCDN:
Footprint and Capabilities:
Configuration:
Request Routing:
Capacity Insights:
Content Management:
Logging:
\
\
After an initial bootstrap (out of scope of original specifications, herein provided by the OCM Delivery Bootstrap Layer) and probing the Footprint & Capabilities interface on the dCDN controller for available resources where they want to reach their audience, upstream content providers and uCDNs use the Configuration Interface to deploy their services into parts of the dCDN.
Content providers can leverage multiple CDNs to cover the same audience footprint, a common practice today for path diversity in case one dCDN becomes overloaded. The content provider uses a multi-CDN selector service like NS1 Pulsar or Cedexis, to receive incoming user requests and delegate traffic to the dCDN with the shortest route, best performance, or lowest price. They can also implement their own CDN selector and use the Capacity Insights interface to probe how much bandwidth is available in a dCDN footprint and their delegation criteria.\
The dCDN manager listens on the Routing interface for incoming delegation requests and responds with the address of an available cache node best suited to deliver the response to the user. The dCDN then sends the usage event details over the Logging interface. Content can be prepositioned or flushed from cache with the Content Management interface.
\