see rmarks inside,
> -----Original Message-----
> From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> Sent: Friday, March 30, 2001 4:12 PM
> To: Barbir, Abbie [CAR:CC70:EXCH]
> Cc: cdn@ops.ietf.org
> Subject: RE: hard questions: request routing
>
>
>
>
> Abbie,
>
> I am a littel bit confused about what exactly your are
> proposing. Let me try an example for a DNS based RRS:
>
> - The domain is www.foobar.com
> - The authoritative RRS is CDN A
> - The content has been distributed to CDN A, B and C
<<<<<< well, that mean that the content was distributed by the DPS. The senario is as follows:
- Content provider distribute to CDN A (only one CDN for now)
- CDN A RRS is Authoritative on that content contentA.cdna.com
- CDN A know resell the content to CDN B
- the new content is xxxx????.cdnB.com
- CDN B RRS is autoratative on that new content
- ALL RRS in the system must be informed about that.
- Hence, at the moment that CDN A has agreed to sell to CDN B, the content
path has an extra hop in it, let us call it content hop.
- hence, the distribution system can inform the RRS about that
- a content routing matrix can be updated in the RRS (based on content only)
after the DPS system has finalized the tranaction. (see more about at the end)
- CDN B now resell the content to CDN B
- DPS inform all RRS about that
- new content is blablabla.CDNC.com
- content routing matrix is updated with the info.
- RRS in CDN C is authorartive on blablabla.CDNC.com.
basically, here is the structure of the proposed solution.
Assumptions:
a. For a CDN to peer it must acquire a number
(can be based on BGP, or issued by an organization such as CA)
b. Peering of content must be done on the fly. This means that when the DPS
finished negotating the peering of content, the RRS (DNS at least) system must be
updated instantly to reflect the authorartive CDN. Thus, no delay is allowed for the
regular DNS system propgation etc.
C. From step b, there may be a need (not really mandatory, optional) for the same
organization to assume a structure for the peering DNS. For example, let us assume that
peering.com is controlled by that orgatization.
- all peered content will be
blablabla!!!!!!!!!.peering.com
- update regarding autorartive content is thus done between the RRS as opposed
to propgating across the DNS hireachy.
Solution:
1- The number of times content can be resold (peered) is negotatied in the DPS system and is
specified by the original content provider.
- can justify that very easily
- this also include the life span of the retaionship for that content.
- mathematically speaking, this parameter determines the number of content
hops in the content routing (no layer 3 here at all)tree.
2- Hence, from this point, we can determine all the
possible number of CNAMEs associated with that content (number not value).
This is done in the form of a Content Routing Matrix (CRM) that each participating
CDN will have.The CRM matrix is basically a collection of all possible CNAMEs
associated with that content. The entries in it are mapped to the CDN numbers
after the successful DPS negotation.
3- Every time the DPS system peer the content, the CRM matrix is updated by the RRS system
whereby, the CDN number is inserted in the corresponding entry in the CRM matrix.
- these entries are used in the redirection process.
4- CRM matrix life span is determined by the DPS system.
This approach basically decouples layer 3 from the content routing layer.
I will be writing a detailed description (with examples) about this apprach pretty soon.
PS: layer 3 infor and other metrics including content metrics are used to decide which
CDN the RRS must direct to. The appracoh keeps track of content hops (only)
- The approach can be easily integrating with the accounting system for billing
purposed. (all hops are part of the CNMAE, that are known at resolution time)
- CNAMEs for aggrgate content can be easily incorpotated.
PS: these are the concepts for know. I still need more refinment. Feedback is welcomed.
abbie