request-routing requirements

[Oliver Spatscheck <spatsch@research.att.com>]

The following is a minimum set of requirements we feel are necessary
in the context of CDNP. It does not address all the scenarios
discussed so far, rather it describes the requirements of the
scenarios we are most interested in. We separate the requirements into
distribution and redirection.  This separation appears to be somewhat
artificial due to the decision process within each CDN. The decision
process within a CDN as currently envisioned takes feedback
information from many CDNs, combines it with policy and drives the
redirection and distribution between CDNs. In this process it is
therefore unclear if the feedback part belongs to the redirection or
distribution part of the system.

Oliver & Kobus

----

Our requirements focus on CDNs that contain surrogates and which
peer directly with each other. (We do not consider interception proxies
at this point). 

In addition we assume the existence of out-of-band negotiated contracts 
and SLAs between the peering CDNs. 
The SLAs will specify at least the following:
    - High level footprint information (where does the CDN have proxies)
    - Capacity guarantees
    - Capabilities depending on footprint (streaming versus web)
    - Other parameters (like jitter etc... )

The following requirements are described in the context of two
CDNs (A,B). CDN A has content and CDN B has surrogates. We concentrate
on the case of distribution in one direction. This restriction
seems appropriate in that on the requirement level it is irrelevant
if the same exchanges happen in the opposite direction.

Redirection
-----------

- DNS based redirection MUST be supported using CNAME records
  + CDN B has to provide a CNAME to redirect to for each
    unique DNS name which might be redirected to CDN B
- Content MUST be named such that peering can occur
  based on DNS name alone. For example, streaming content
  versus Web content has to be identifiable using the
  DNS name alone. This can either be done by a naming convention
  (streaming.foo.com, images.foo.com) or a mapping table.
- The redirection system has to receive feedback from the CDNs:
  + readiness of a CDN to serve a particular content.
    For example, in a pull model CDN B has to receive the
    meta information described in the distribution system before
    it can serve the content CDN A wants to peer. The reception
    of this meta information has to be somehow communicated to
    the redirection system. 
  + availability of capacity in a particular region (or part of
    footprint) for a particular type of service.
    - The capacity is defined as MBit/sec outgoing capacity
      from all surrogates which is available to the
      redirection system. For example CND B only
      advertises to CDN A the capacity available to CDN A.
    - A region is defined as a list of CIDR blocks.
    - The type of service is defined as Web/SSL/Streaming
  + MUST allow for transfer of custom metrics defined
    in the SLA

Distribution
------------

- MUST prevent advertising loops
- MUST support the pull model
- MUST support selective push
  (only certain objects from a particular set
   of objects can be pushed)
- MUST support invalidation of content
- MUST allow to transfer information from CDN A to CDN B
  which is sufficient for CDN B to fetch the content:
  + origin site
  + access method
  + keys
  + certificates
- To match the requirement of DNS based redirection it MUST
  support the distribution of entire DNS sub domains
- MUST provide CDN B with DNS name used by the client
  to retrieve the document
- MUST allow content to be authenticated
- To provide the policy engine with information necessary
  to make a decision the distribution system MUST acquire
  the following information:
  + storage capacity available in the case of streaming media
  (other information like type of content is prenegotiated in SLA)