📡
Blockcast Network - Light Paper (It's a WIP)
  • Welcome to Blockcast Network
  • Intro
    • The Internet Capacity Crunch
  • Overview
    • What is Blockcast?
    • Mission And Values
    • How Blockcast Works
    • Ecosystem Roles
  • Building Blocks
    • Control Plane
      • dCDN Controller
      • CDN Interconnect
      • Challenge Coordination
      • Service Contracts
    • Data Plane
      • Multicast HTTP Adaption
      • Multicast Backbone
      • Traffic Router
    • Consensus Layer
  • Getting Started
    • How Do I Participate in The Network
      • BEACON
        • Start Running your BEACON Today
        • BEACON Common Questions
      • RELAY
      • CAST
Powered by GitBook
On this page
  1. Building Blocks
  2. Control Plane

CDN Interconnect

PreviousdCDN ControllerNextChallenge Coordination

Last updated 6 months ago

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.

\

SVTA OpenCaching
RFC6707