[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: hard questions: request routing
I don't know why you think I am considering layer 3 at all. All I want
to optimize is to find the surrogate which serves the content the fastest.
This surrogate is changing constantly since the surrogate loads and
network delays are in constant flux. So determining a single tree in terms
of redirection at content distribution time does not work, since this
tree is not sensitive to changes in load and delay.
So what we need is a redirection tree (Is that what you mean with
content tree?) and everybody has to have the same view of this
tree at each point in time in the presence of updates to surrogate
and network load information.
If you can tell me how to calculate this tree without an atomic update or the
risk of transient loops in the multiple local views of the tree I would
appreciate it.
Oliver
Abbie Barbir writes:
>
> Oliver,
>
> In the proposed approach, the only update is done after the DPS system has
> negotaited the peering of content (that's all)
>
> Can you please stop thinking in terms of layer 3. The proposed solution is
> not dependent on any leyer 3.
>
> I think it is about time to start thinking of content peering as content
> routing at layer (8).
>
>
> Keep in mind the following:
> 1. we need a content tree (not related to any network)
> 2. Layer 3 are only used for decision purposed (pick the right CNAME, that's
> it)
>
>
> abbie
>
>
> > -----Original Message-----
> > From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> > Sent: Monday, April 02, 2001 11:24 AM
> > To: Barbir, Abbie [CAR:CC70:EXCH]
> > Cc: cdn@ops.ietf.org
> > Subject: RE: hard questions: request routing
> >
> >
> >
> >
> >
> > Abbie,
> >
> > if I understand your solution right you are solving the
> > problem by requiring global atomic updates of the metric used to
> > decide which CDN to use. Since this metric should be load dependent
> > and, therefore, is updated frequently you are suggesting a
> > frequent distributed atomic update. This is a very expensive
> > operation in the presence of faults (network partitioning,
> > CDN's not responding, packets being lost). This is
> > why BGP for example does not use a global atomic update and
> > rather allows for transient loops.
> >
> > I still would vote for the three level restriction outlined
> > in my other email to avoid this complexity for now.
> >
> > Oliver
> >
> >
> > Abbie Barbir writes:
> > >
> > > 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
> > >
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > > <HTML>
> > > <HEAD>
> > > <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
> > charset=iso-8859-1">
> > > <META NAME="Generator" CONTENT="MS Exchange Server version
> > 5.5.2654.19">
> > > <TITLE>RE: hard questions: request routing</TITLE>
> > > </HEAD>
> > > <BODY>
> > > <BR>
> > >
> > > <P><FONT SIZE=2>see rmarks inside,</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>> -----Original Message-----</FONT>
> > > <BR><FONT SIZE=2>> From: Oliver Spatscheck [<A
> > HREF="mailto:spatsch@research.att.com";>mailto:spatsch@research
> > .att.com</A>]</FONT>
> > > <BR><FONT SIZE=2>> Sent: Friday, March 30, 2001 4:12 PM</FONT>
> > > <BR><FONT SIZE=2>> To: Barbir, Abbie [CAR:CC70:EXCH]</FONT>
> > > <BR><FONT SIZE=2>> Cc: cdn@ops.ietf.org</FONT>
> > > <BR><FONT SIZE=2>> Subject: RE: hard questions: request
> > routing</FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> Abbie,</FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> I am
> > a littel bit confused about what exactly your are</FONT>
> > > <BR><FONT SIZE=2>> proposing. Let me try an example for
> > a DNS based RRS:</FONT>
> > > <BR><FONT SIZE=2>> </FONT>
> > > <BR><FONT SIZE=2>> - The domain is www.foobar.com</FONT>
> > > <BR><FONT SIZE=2>> - The authoritative RRS is CDN A</FONT>
> > > <BR><FONT SIZE=2>> - The content has been distributed
> > to CDN A, B and C</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2><<<<<< well, that
> > mean that the content was distributed by the DPS. The senario
> > is as follows:</FONT>
> > > <BR><FONT SIZE=2> - Content provider distribute to
> > CDN A (only one CDN for now)</FONT>
> > > <BR><FONT SIZE=2> - CDN A RRS is Authoritative on
> > that content contentA.cdna.com</FONT>
> > > <BR><FONT SIZE=2> - CDN A know resell the content to
> > CDN B</FONT>
> > > <BR><FONT SIZE=2> - the new content is
> > xxxx????.cdnB.com</FONT>
> > > <BR><FONT SIZE=2> - CDN B RRS is
> > autoratative on that new content</FONT>
> > > <BR><FONT SIZE=2> - ALL RRS in the
> > system must be informed about that.</FONT>
> > > <BR><FONT SIZE=2> - Hence, at the moment that
> > CDN A has agreed to sell to CDN B, the content </FONT>
> > > <BR><FONT SIZE=2> path has an
> > extra hop in it, let us call it content hop.</FONT>
> > > <BR><FONT SIZE=2> - hence, the
> > distribution system can inform the RRS about that</FONT>
> > > <BR><FONT SIZE=2> - a
> > content routing matrix can be updated in the RRS (based on
> > content only)</FONT>
> > > <BR><FONT
> > SIZE=2> after
> > the DPS system has finalized the tranaction. (see more about
> > at the end)</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2> - CDN B now resell the content to
> > CDN B</FONT>
> > > <BR><FONT SIZE=2> - DPS inform all RRS
> > about that</FONT>
> > > <BR><FONT SIZE=2> - new
> > content is blablabla.CDNC.com</FONT>
> > > <BR><FONT SIZE=2> - content
> > routing matrix is updated with the info.</FONT>
> > > <BR><FONT SIZE=2> - RRS in
> > CDN C is authorartive on blablabla.CDNC.com.</FONT>
> > > </P>
> > > <BR>
> > >
> > > <P><FONT SIZE=2>basically, here is the structure of the
> > proposed solution.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>Assumptions:</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>a. For a CDN to peer it must acquire a
> > number</FONT>
> > > <BR><FONT SIZE=2> (can be based on BGP,
> > or issued by an organization such as CA)</FONT>
> > > <BR><FONT SIZE=2>b. Peering of content must be done on the
> > fly. This means that when the DPS</FONT>
> > > <BR><FONT SIZE=2> finished negotating the
> > peering of content, the RRS (DNS at least) system must be </FONT>
> > > <BR><FONT SIZE=2> updated instantly to reflect
> > the authorartive CDN. Thus, no delay is allowed for the</FONT>
> > > <BR><FONT SIZE=2> regular DNS system
> > propgation etc.</FONT>
> > > <BR><FONT SIZE=2>C. From step b, there may be a need (not
> > really mandatory, optional) for the same</FONT>
> > > <BR><FONT SIZE=2> organization to assume a
> > structure for the peering DNS. For example, let us
> > assume that </FONT>
> > > <BR><FONT SIZE=2> peering.com is controlled by
> > that orgatization.</FONT>
> > > <BR><FONT SIZE=2> - all peered content will be </FONT>
> > > <BR><FONT SIZE=2>
> > blablabla!!!!!!!!!.peering.com</FONT>
> > > <BR><FONT SIZE=2> - update regarding
> > autorartive content is thus done between the RRS as opposed</FONT>
> > > <BR><FONT SIZE=2> to propgating
> > across the DNS hireachy.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>Solution:</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>1- The number of times content can be
> > resold (peered) is negotatied in the DPS system and is</FONT>
> > > <BR><FONT SIZE=2> specified by the
> > original content provider.</FONT>
> > > <BR><FONT
> > SIZE=2> &
> > nbsp; - can justify that very easily</FONT>
> > > <BR><FONT
> > SIZE=2> &
> > nbsp; - this also include the life span of the
> > retaionship for that content.</FONT>
> > > <BR><FONT
> > SIZE=2> &
> > nbsp; - mathematically speaking, this parameter
> > determines the number of content</FONT>
> > > <BR><FONT
> > SIZE=2> &
> > nbsp; hops in the content routing (no layer
> > 3 here at all)tree.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>2- Hence, from this point, we can
> > determine all the</FONT>
> > > <BR><FONT SIZE=2> possible number of CNAMEs
> > associated with that content (number not value).</FONT>
> > > <BR><FONT SIZE=2> This is done in the form of
> > a Content Routing Matrix (CRM) that each participating </FONT>
> > > <BR><FONT SIZE=2> CDN will have.The CRM matrix
> > is basically a collection of all possible CNAMEs </FONT>
> > > <BR><FONT SIZE=2> associated with that
> > content. The entries in it are mapped to the CDN numbers </FONT>
> > > <BR><FONT SIZE=2> after the successful
> > DPS negotation.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>3- Every time the DPS system peer the
> > content, the CRM matrix is updated by the RRS system</FONT>
> > > <BR><FONT SIZE=2> whereby, the CDN number is
> > inserted in the corresponding entry in the CRM matrix.</FONT>
> > > <BR><FONT SIZE=2> - these entries are used in
> > the redirection process.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>4- CRM matrix life span is determined by
> > the DPS system.</FONT>
> > > </P>
> > > <BR>
> > >
> > > <P><FONT SIZE=2>This approach basically decouples layer 3
> > from the content routing layer.</FONT>
> > > <BR><FONT SIZE=2>I will be writing a detailed description
> > (with examples) about this apprach pretty soon.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>PS: layer 3 infor and other metrics
> > including content metrics are used to decide which</FONT>
> > > <BR><FONT SIZE=2> CDN the RRS must
> > direct to. The appracoh keeps track of content hops (only)</FONT>
> > > <BR><FONT SIZE=2> - The approach can be
> > easily integrating with the accounting system for billing</FONT>
> > > <BR><FONT SIZE=2> purposed.
> > (all hops are part of the CNMAE, that are known at resolution
> > time)</FONT>
> > > <BR><FONT SIZE=2> - CNAMEs for aggrgate
> > content can be easily incorpotated.</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=2>PS: these are the concepts for know. I
> > still need more refinment. Feedback is welcomed.</FONT>
> > > </P>
> > > <BR>
> > >
> > > <P><FONT SIZE=2>abbie</FONT>
> > > </P>
> > >
> > > </BODY>
> > > </HTML>
> >
> >
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
> <TITLE>RE: hard questions: request routing</TITLE>
> </HEAD>
> <BODY>
> <BR>
>
> <P><FONT SIZE=2>Oliver,</FONT>
> </P>
>
> <P><FONT SIZE=2>In the proposed approach, the only update is done after the DPS system has</FONT>
> <BR><FONT SIZE=2>negotaited the peering of content (that's all)</FONT>
> </P>
>
> <P><FONT SIZE=2>Can you please stop thinking in terms of layer 3. The proposed solution is</FONT>
> <BR><FONT SIZE=2>not dependent on any leyer 3.</FONT>
> </P>
>
> <P><FONT SIZE=2>I think it is about time to start thinking of content peering as content routing at layer (8).</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=2>Keep in mind the following:</FONT>
> <BR><FONT SIZE=2>1. we need a content tree (not related to any network)</FONT>
> <BR><FONT SIZE=2>2. Layer 3 are only used for decision purposed (pick the right CNAME, that's it)</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=2>abbie</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=2>> -----Original Message-----</FONT>
> <BR><FONT SIZE=2>> From: Oliver Spatscheck [<A HREF="mailto:spatsch@research.att.com";>mailto:spatsch@research.att.com</A>]</FONT>
> <BR><FONT SIZE=2>> Sent: Monday, April 02, 2001 11:24 AM</FONT>
> <BR><FONT SIZE=2>> To: Barbir, Abbie [CAR:CC70:EXCH]</FONT>
> <BR><FONT SIZE=2>> Cc: cdn@ops.ietf.org</FONT>
> <BR><FONT SIZE=2>> Subject: RE: hard questions: request routing</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Abbie,</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> if I understand your solution right you are solving the</FONT>
> <BR><FONT SIZE=2>> problem by requiring global atomic updates of the metric used to</FONT>
> <BR><FONT SIZE=2>> decide which CDN to use. Since this metric should be load dependent</FONT>
> <BR><FONT SIZE=2>> and, therefore, is updated frequently you are suggesting a</FONT>
> <BR><FONT SIZE=2>> frequent distributed atomic update. This is a very expensive</FONT>
> <BR><FONT SIZE=2>> operation in the presence of faults (network partitioning,</FONT>
> <BR><FONT SIZE=2>> CDN's not responding, packets being lost). This is</FONT>
> <BR><FONT SIZE=2>> why BGP for example does not use a global atomic update and</FONT>
> <BR><FONT SIZE=2>> rather allows for transient loops.</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> I still would vote for the three level restriction outlined</FONT>
> <BR><FONT SIZE=2>> in my other email to avoid this complexity for now.</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Oliver</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Abbie Barbir writes:</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > see rmarks inside,</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > > -----Original Message-----</FONT>
> <BR><FONT SIZE=2>> > > From: Oliver Spatscheck [<A HREF="mailto:spatsch@research.att.com";>mailto:spatsch@research.att.com</A>]</FONT>
> <BR><FONT SIZE=2>> > > Sent: Friday, March 30, 2001 4:12 PM</FONT>
> <BR><FONT SIZE=2>> > > To: Barbir, Abbie [CAR:CC70:EXCH]</FONT>
> <BR><FONT SIZE=2>> > > Cc: cdn@ops.ietf.org</FONT>
> <BR><FONT SIZE=2>> > > Subject: RE: hard questions: request routing</FONT>
> <BR><FONT SIZE=2>> > > </FONT>
> <BR><FONT SIZE=2>> > > </FONT>
> <BR><FONT SIZE=2>> > > </FONT>
> <BR><FONT SIZE=2>> > > </FONT>
> <BR><FONT SIZE=2>> > > Abbie,</FONT>
> <BR><FONT SIZE=2>> > > </FONT>
> <BR><FONT SIZE=2>> > > I am a littel bit confused about what exactly your are</FONT>
> <BR><FONT SIZE=2>> > > proposing. Let me try an example for a DNS based RRS:</FONT>
> <BR><FONT SIZE=2>> > > </FONT>
> <BR><FONT SIZE=2>> > > - The domain is www.foobar.com</FONT>
> <BR><FONT SIZE=2>> > > - The authoritative RRS is CDN A</FONT>
> <BR><FONT SIZE=2>> > > - The content has been distributed to CDN A, B and C</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <<<<<< well, that mean that the content was distributed </FONT>
> <BR><FONT SIZE=2>> by the DPS. The</FONT>
> <BR><FONT SIZE=2>> > senario is as follows:</FONT>
> <BR><FONT SIZE=2>> > - Content provider distribute to CDN A (only one CDN for now)</FONT>
> <BR><FONT SIZE=2>> > - CDN A RRS is Authoritative on that content contentA.cdna.com</FONT>
> <BR><FONT SIZE=2>> > - CDN A know resell the content to CDN B</FONT>
> <BR><FONT SIZE=2>> > - the new content is xxxx????.cdnB.com</FONT>
> <BR><FONT SIZE=2>> > - CDN B RRS is autoratative on that new content</FONT>
> <BR><FONT SIZE=2>> > - ALL RRS in the system must be informed about that.</FONT>
> <BR><FONT SIZE=2>> > - Hence, at the moment that CDN A has agreed to sell to </FONT>
> <BR><FONT SIZE=2>> CDN B, the</FONT>
> <BR><FONT SIZE=2>> > content </FONT>
> <BR><FONT SIZE=2>> > path has an extra hop in it, let us call it content hop.</FONT>
> <BR><FONT SIZE=2>> > - hence, the distribution system can inform the RRS about that</FONT>
> <BR><FONT SIZE=2>> > - a content routing matrix can be updated in the </FONT>
> <BR><FONT SIZE=2>> RRS (based on</FONT>
> <BR><FONT SIZE=2>> > content only)</FONT>
> <BR><FONT SIZE=2>> > after the DPS system has finalized the </FONT>
> <BR><FONT SIZE=2>> tranaction. (see more about</FONT>
> <BR><FONT SIZE=2>> > at the end)</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > - CDN B now resell the content to CDN B</FONT>
> <BR><FONT SIZE=2>> > - DPS inform all RRS about that</FONT>
> <BR><FONT SIZE=2>> > - new content is blablabla.CDNC.com</FONT>
> <BR><FONT SIZE=2>> > - content routing matrix is updated with the info.</FONT>
> <BR><FONT SIZE=2>> > - RRS in CDN C is authorartive on blablabla.CDNC.com.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > basically, here is the structure of the proposed solution.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > Assumptions:</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > a. For a CDN to peer it must acquire a number</FONT>
> <BR><FONT SIZE=2>> > (can be based on BGP, or issued by an organization such as CA)</FONT>
> <BR><FONT SIZE=2>> > b. Peering of content must be done on the fly. This means </FONT>
> <BR><FONT SIZE=2>> that when the DPS</FONT>
> <BR><FONT SIZE=2>> > finished negotating the peering of content, the RRS </FONT>
> <BR><FONT SIZE=2>> (DNS at least) system</FONT>
> <BR><FONT SIZE=2>> > must be </FONT>
> <BR><FONT SIZE=2>> > updated instantly to reflect the authorartive CDN. </FONT>
> <BR><FONT SIZE=2>> Thus, no delay is</FONT>
> <BR><FONT SIZE=2>> > allowed for the</FONT>
> <BR><FONT SIZE=2>> > regular DNS system propgation etc.</FONT>
> <BR><FONT SIZE=2>> > C. From step b, there may be a need (not really mandatory, </FONT>
> <BR><FONT SIZE=2>> optional) for the</FONT>
> <BR><FONT SIZE=2>> > same</FONT>
> <BR><FONT SIZE=2>> > organization to assume a structure for the peering </FONT>
> <BR><FONT SIZE=2>> DNS. For example, let</FONT>
> <BR><FONT SIZE=2>> > us assume that </FONT>
> <BR><FONT SIZE=2>> > peering.com is controlled by that orgatization.</FONT>
> <BR><FONT SIZE=2>> > - all peered content will be </FONT>
> <BR><FONT SIZE=2>> > blablabla!!!!!!!!!.peering.com</FONT>
> <BR><FONT SIZE=2>> > - update regarding autorartive content is thus done </FONT>
> <BR><FONT SIZE=2>> between the RRS as</FONT>
> <BR><FONT SIZE=2>> > opposed</FONT>
> <BR><FONT SIZE=2>> > to propgating across the DNS hireachy.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > Solution:</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > 1- The number of times content can be resold (peered) is </FONT>
> <BR><FONT SIZE=2>> negotatied in the</FONT>
> <BR><FONT SIZE=2>> > DPS system and is</FONT>
> <BR><FONT SIZE=2>> > specified by the original content provider.</FONT>
> <BR><FONT SIZE=2>> > - can justify that very easily</FONT>
> <BR><FONT SIZE=2>> > - this also include the life span of the </FONT>
> <BR><FONT SIZE=2>> retaionship for that</FONT>
> <BR><FONT SIZE=2>> > content.</FONT>
> <BR><FONT SIZE=2>> > - mathematically speaking, this parameter </FONT>
> <BR><FONT SIZE=2>> determines the number</FONT>
> <BR><FONT SIZE=2>> > of content</FONT>
> <BR><FONT SIZE=2>> > hops in the content routing (no layer 3 here </FONT>
> <BR><FONT SIZE=2>> at all)tree.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > 2- Hence, from this point, we can determine all the</FONT>
> <BR><FONT SIZE=2>> > possible number of CNAMEs associated with that content </FONT>
> <BR><FONT SIZE=2>> (number not</FONT>
> <BR><FONT SIZE=2>> > value).</FONT>
> <BR><FONT SIZE=2>> > This is done in the form of a Content Routing Matrix </FONT>
> <BR><FONT SIZE=2>> (CRM) that each</FONT>
> <BR><FONT SIZE=2>> > participating </FONT>
> <BR><FONT SIZE=2>> > CDN will have.The CRM matrix is basically a collection </FONT>
> <BR><FONT SIZE=2>> of all possible</FONT>
> <BR><FONT SIZE=2>> > CNAMEs </FONT>
> <BR><FONT SIZE=2>> > associated with that content. The entries in it are </FONT>
> <BR><FONT SIZE=2>> mapped to the CDN</FONT>
> <BR><FONT SIZE=2>> > numbers </FONT>
> <BR><FONT SIZE=2>> > after the successful DPS negotation.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > 3- Every time the DPS system peer the content, the CRM </FONT>
> <BR><FONT SIZE=2>> matrix is updated by</FONT>
> <BR><FONT SIZE=2>> > the RRS system</FONT>
> <BR><FONT SIZE=2>> > whereby, the CDN number is inserted in the </FONT>
> <BR><FONT SIZE=2>> corresponding entry in the CRM</FONT>
> <BR><FONT SIZE=2>> > matrix.</FONT>
> <BR><FONT SIZE=2>> > - these entries are used in the redirection process.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > 4- CRM matrix life span is determined by the DPS system.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > This approach basically decouples layer 3 from the content </FONT>
> <BR><FONT SIZE=2>> routing layer.</FONT>
> <BR><FONT SIZE=2>> > I will be writing a detailed description (with examples) </FONT>
> <BR><FONT SIZE=2>> about this apprach</FONT>
> <BR><FONT SIZE=2>> > pretty soon.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > PS: layer 3 infor and other metrics including content </FONT>
> <BR><FONT SIZE=2>> metrics are used to</FONT>
> <BR><FONT SIZE=2>> > decide which</FONT>
> <BR><FONT SIZE=2>> > CDN the RRS must direct to. The appracoh keeps track </FONT>
> <BR><FONT SIZE=2>> of content hops</FONT>
> <BR><FONT SIZE=2>> > (only)</FONT>
> <BR><FONT SIZE=2>> > - The approach can be easily integrating with the </FONT>
> <BR><FONT SIZE=2>> accounting system for</FONT>
> <BR><FONT SIZE=2>> > billing</FONT>
> <BR><FONT SIZE=2>> > purposed. (all hops are part of the CNMAE, that are known at</FONT>
> <BR><FONT SIZE=2>> > resolution time)</FONT>
> <BR><FONT SIZE=2>> > - CNAMEs for aggrgate content can be easily incorpotated.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > PS: these are the concepts for know. I still need more </FONT>
> <BR><FONT SIZE=2>> refinment. Feedback</FONT>
> <BR><FONT SIZE=2>> > is welcomed.</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > abbie</FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"></FONT>
> <BR><FONT SIZE=2>> > <HTML></FONT>
> <BR><FONT SIZE=2>> > <HEAD></FONT>
> <BR><FONT SIZE=2>> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; </FONT>
> <BR><FONT SIZE=2>> charset=iso-8859-1"></FONT>
> <BR><FONT SIZE=2>> > <META NAME="Generator" CONTENT="MS Exchange Server version </FONT>
> <BR><FONT SIZE=2>> 5.5.2654.19"></FONT>
> <BR><FONT SIZE=2>> > <TITLE>RE: hard questions: request routing</TITLE></FONT>
> <BR><FONT SIZE=2>> > </HEAD></FONT>
> <BR><FONT SIZE=2>> > <BODY></FONT>
> <BR><FONT SIZE=2>> > <BR></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>see rmarks inside,</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>&gt; -----Original Message-----</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; From: Oliver Spatscheck [<A </FONT>
> <BR><FONT SIZE=2>> HREF="<A HREF="mailto:spatsch@research.att.com";>mailto:spatsch@research.att.com</A>"><A HREF="mailto:spatsch@research";>mailto:spatsch@research</A></FONT>
> <BR><FONT SIZE=2>> .att.com</A>]</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; Sent: Friday, March 30, 2001 4:12 PM</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; To: Barbir, Abbie [CAR:CC70:EXCH]</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; Cc: cdn@ops.ietf.org</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; Subject: RE: hard questions: request </FONT>
> <BR><FONT SIZE=2>> routing</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; Abbie,</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am </FONT>
> <BR><FONT SIZE=2>> a littel bit confused about what exactly your are</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; proposing. Let me try an example for </FONT>
> <BR><FONT SIZE=2>> a DNS based RRS:</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; - The domain is www.foobar.com</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; - The authoritative RRS is CDN A</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&gt; - The content has been distributed </FONT>
> <BR><FONT SIZE=2>> to CDN A, B and C</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>&lt;&lt;&lt;&lt;&lt;&lt;&nbsp; well, that </FONT>
> <BR><FONT SIZE=2>> mean that the content was distributed by the DPS. The senario </FONT>
> <BR><FONT SIZE=2>> is as follows:</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;- Content provider distribute to </FONT>
> <BR><FONT SIZE=2>> CDN A (only one CDN for now)</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;- CDN A RRS is Authoritative on </FONT>
> <BR><FONT SIZE=2>> that content contentA.cdna.com</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;- CDN A know resell the content to </FONT>
> <BR><FONT SIZE=2>> CDN B</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; - the new content is </FONT>
> <BR><FONT SIZE=2>> xxxx????.cdnB.com</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - CDN B RRS is </FONT>
> <BR><FONT SIZE=2>> autoratative on that new content</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - ALL RRS in the </FONT>
> <BR><FONT SIZE=2>> system must be informed about that.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; - Hence, at the moment that </FONT>
> <BR><FONT SIZE=2>> CDN A has agreed to sell to CDN B, the content </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; path has an </FONT>
> <BR><FONT SIZE=2>> extra hop in it, let us call it content hop.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - hence, the </FONT>
> <BR><FONT SIZE=2>> distribution system can inform the RRS about that</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - a </FONT>
> <BR><FONT SIZE=2>> content routing matrix can be updated in the RRS (based on </FONT>
> <BR><FONT SIZE=2>> content only)</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT </FONT>
> <BR><FONT SIZE=2>> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; after </FONT>
> <BR><FONT SIZE=2>> the DPS system has finalized the tranaction. (see more about </FONT>
> <BR><FONT SIZE=2>> at the end)</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>&nbsp; - CDN B now resell the content to </FONT>
> <BR><FONT SIZE=2>> CDN B</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - DPS inform all RRS </FONT>
> <BR><FONT SIZE=2>> about that</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - new </FONT>
> <BR><FONT SIZE=2>> content is blablabla.CDNC.com</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - content </FONT>
> <BR><FONT SIZE=2>> routing matrix is updated with the info.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - RRS in </FONT>
> <BR><FONT SIZE=2>> CDN C is authorartive on blablabla.CDNC.com.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > <BR></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>basically, here is the structure of the </FONT>
> <BR><FONT SIZE=2>> proposed solution.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>Assumptions:</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>a. For a CDN to peer it must acquire a </FONT>
> <BR><FONT SIZE=2>> number</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; (can be based on BGP, </FONT>
> <BR><FONT SIZE=2>> or issued by an organization such as CA)</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>b. Peering of content must be done on the </FONT>
> <BR><FONT SIZE=2>> fly. This means that when the DPS</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; finished negotating the </FONT>
> <BR><FONT SIZE=2>> peering of content, the RRS (DNS at least) system must be </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; updated instantly to reflect </FONT>
> <BR><FONT SIZE=2>> the authorartive CDN. Thus, no delay is allowed for the</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; regular DNS system </FONT>
> <BR><FONT SIZE=2>> propgation etc.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>C. From step b, there may be a need (not </FONT>
> <BR><FONT SIZE=2>> really mandatory, optional) for the same</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; organization to assume a </FONT>
> <BR><FONT SIZE=2>> structure for the&nbsp; peering DNS. For example, let us </FONT>
> <BR><FONT SIZE=2>> assume that </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; peering.com is controlled by </FONT>
> <BR><FONT SIZE=2>> that orgatization.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; - all peered content will be </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
> <BR><FONT SIZE=2>> blablabla!!!!!!!!!.peering.com</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; - update regarding </FONT>
> <BR><FONT SIZE=2>> autorartive content is thus done between the RRS as opposed</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; to propgating </FONT>
> <BR><FONT SIZE=2>> across the DNS hireachy.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>Solution:</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>1- The number of times content can be </FONT>
> <BR><FONT SIZE=2>> resold (peered) is negotatied in the DPS system and is</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; specified by the </FONT>
> <BR><FONT SIZE=2>> original content provider.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT </FONT>
> <BR><FONT SIZE=2>> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&</FONT>
> <BR><FONT SIZE=2>> nbsp;&nbsp; - can justify that very easily</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT </FONT>
> <BR><FONT SIZE=2>> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&</FONT>
> <BR><FONT SIZE=2>> nbsp;&nbsp; - this also include the life span of the </FONT>
> <BR><FONT SIZE=2>> retaionship for that content.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT </FONT>
> <BR><FONT SIZE=2>> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&</FONT>
> <BR><FONT SIZE=2>> nbsp;&nbsp; - mathematically speaking, this parameter </FONT>
> <BR><FONT SIZE=2>> determines the number of content</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT </FONT>
> <BR><FONT SIZE=2>> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&</FONT>
> <BR><FONT SIZE=2>> nbsp;&nbsp;&nbsp;&nbsp; hops in the content routing (no layer </FONT>
> <BR><FONT SIZE=2>> 3 here at all)tree.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>2- Hence, from this point, we can </FONT>
> <BR><FONT SIZE=2>> determine all the</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; possible number of CNAMEs </FONT>
> <BR><FONT SIZE=2>> associated with that content (number not value).</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; This is done in the form of </FONT>
> <BR><FONT SIZE=2>> a Content Routing Matrix (CRM) that each participating </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; CDN will have.The CRM matrix </FONT>
> <BR><FONT SIZE=2>> is basically a collection of all possible CNAMEs </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; associated with that </FONT>
> <BR><FONT SIZE=2>> content. The entries in it are mapped to the CDN numbers </FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; after the successful </FONT>
> <BR><FONT SIZE=2>> DPS&nbsp; negotation.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>3- Every time the DPS system peer the </FONT>
> <BR><FONT SIZE=2>> content, the CRM matrix is updated by the RRS system</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; whereby, the CDN number is </FONT>
> <BR><FONT SIZE=2>> inserted in the corresponding entry in the CRM matrix.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp; - these entries are used in </FONT>
> <BR><FONT SIZE=2>> the redirection process.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>4- CRM matrix life span is determined by </FONT>
> <BR><FONT SIZE=2>> the DPS system.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > <BR></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>This approach basically decouples layer 3 </FONT>
> <BR><FONT SIZE=2>> from the content routing layer.</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>I will be writing a detailed description </FONT>
> <BR><FONT SIZE=2>> (with examples) about this apprach pretty soon.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>PS: layer 3 infor and other metrics </FONT>
> <BR><FONT SIZE=2>> including content metrics are used to decide which</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; CDN the RRS must </FONT>
> <BR><FONT SIZE=2>> direct to. The appracoh keeps track of content hops (only)</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - The approach can be </FONT>
> <BR><FONT SIZE=2>> easily integrating with the accounting system for billing</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; purposed. </FONT>
> <BR><FONT SIZE=2>> (all hops are part of the CNMAE, that are known at resolution </FONT>
> <BR><FONT SIZE=2>> time)</FONT></FONT>
> <BR><FONT SIZE=2>> > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - CNAMEs for aggrgate </FONT>
> <BR><FONT SIZE=2>> content can be easily incorpotated.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>PS: these are the concepts for know. I </FONT>
> <BR><FONT SIZE=2>> still need more refinment. Feedback is welcomed.</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > <BR></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > <P><FONT SIZE=2>abbie</FONT></FONT>
> <BR><FONT SIZE=2>> > </P></FONT>
> <BR><FONT SIZE=2>> > </FONT>
> <BR><FONT SIZE=2>> > </BODY></FONT>
> <BR><FONT SIZE=2>> > </HTML></FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> </FONT>
> </P>
>
> </BODY>
> </HTML>