Re: host based MH with a connectivity cache

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On 15 Dec 2002, marcelo bagnulo wrote:

> Hi Peter,
> 
> I am trying to understand your idea but I fail to understand some
> points.

> 
> If i understand correctly the CSS (or CSX) stores information about
> mapping between identifiers (FORMAL addresses/prefixes) and CURRENLTY
> working locators (ACTUAL addresses/prefixes). Moreover, if you have a
> CSS within the site A, it will store: 
> - mapping information between identifiers and locators about hosts that
> belong to the site A, so it can provide this information to other CSS
> that can need it (this would be the server part)
> - mapping information between identifiers and locators about other
> sites, so it can provide it to hosts belonging to the site A (this would
> be the cache part)
> 
> Then, let's say you have two sites: site A which is multi-homed and site
> B which is not multi-homed.
> 
> If a host (hostB) that belongs to the site B wants to communicate with
> hostA belonging to site A, (we suppose that HostB already has HostA
> identifier, for instance it obtained it from the DNS) then
> - hostB request mapping information about hostA from the CSS of its site
> (site B) (CSSB)
> - CSSB asks CSSA about the mapping info
> - CSSB answer to hostB
> - hostB starts the communication using one of the locators returned
> 
> Would this be correct?
> 
> If this is so,
> 
> - I do not see how does the BGP interaction works. I mean, CSSB should
> return to hostB, information about locators that are currently
> reachable. This means that if you send a packet from site B addressed to
> that locator, an available path exits. Doesn't aggregation would
> preclude you to see that?

Yes, you are right about that & I mentioned this in the preface.  It up to the
CSSB to restore the missing BGP information via the interaction with its peer
CSS(n)s not via the BGP visible at that point in the network, possibly in a
recursive manner like the DNS operates. 

As the BGP view information traverses the net via the CSSes, the accessiblity
information should probably be modified based on the CSS's derivation of the
BGP information that it can see from that point.   This an important point as
it the best view of the other end of a connection should be the best
approximation of the BGP as given by the CSS closest to the the site being
referenced.

Now this is perhaps the hand waving and I am open to assistance here.

As far as I can envisage there would be two sets of information to be
transferred between CSSes.

There would be the initial set of mappings between formal and actual addresses
along with the weights for each path based as reconstructed by the CSS system.
This would be cached by the CSS system, and would be pulled by the local CSS in
much the same way as DNS.

Then there would be path update information which would be pushed by
neighbouring CSSes to the local one.  One would not want to have every CSS
broadcasting to the whole CSS system, so I guess one would have to have a
selective broadcasting system between CSSes.  There are techniques from other
disciplines we could borrow - perhaps something like the multicast system.  A
CSS requests from its peers that it wants to receive updates for paths which it
knows are in use, and the neighbouring peers in turn receive the same
information.

In the worst case of a fully meshed CSS, the amount of information traversing
would degenerate into the equivalent to a totally unaggregated BGP system with
the DFZ being much the same as we have in IPv4.  Only empirical data will tell
us what the true picture will be.  There is one advantage though, and that is
the CSS system load can be removed from the core routing system and could be
managed with cheaper hardware even if it ultimately resembles something like
the BGP system we currently are used to.

> - How do you propose to find out which is the CSS for a given address In
> the example how does CSSB find out CSSA? Something like the reverse
> lookup in DNS perhaps?

It is not necessary to find any given CSS, only information about prefixes. 
Each CSS has an approximation of the full DFZ which would have resulted from an
non aggregated internet but only for prefixes it is interested in.  The
appoximation is built up from the paths that the originating site needs to see
(cached information) + the definitive MH information advertised by the site(s)
that the CSS handles.  There need not be a 1-1 mapping between sites and CSS, a
CSS can serve many sites, but a site must have at least one CSS (and can
possibly have more than one).  However you have made a good point.  It is not
sufficient to just get the cached view from a neigbouring CSS.  The information
should be modified in such a way as to provide an accurate view which would be
equivalent to that seen by a BGP system which had full unaggregated information
in the DFZ.  As long as CSSes are arranged in the right way topologically, it
should be possible to determine the weights of the various MH paths between the
source and destination paths. 

> - The CSS seems like a critical part of the system, so i guess it should
> benefit from multi-homing fault tolerance capabilities, so i guess that
> an alternative method to provide its multi-homing capabilities is
> required, right?

A CSS only needs to have hard wired into it all the MH paths to its peers and
an independent mechanism to determine which of these paths is accessible
(keepalives like BGP?)   The quality of traffic between CSSes should not in any
way affect the information that traverses the CSS system.  I personally believe
this is a fault in the current BGP system and the reason for the BGP storms
we have grown accustomed to dealing with.

> - the solutions requires at least one CSS per site (multi-homed or not)?

Yes..  See above.

> 
> Thanks, marcelo
> 


I am sorry for the hand waving - I am trying my best to understand the full
implications of how such an idea could work.  I am happy to throw the ideas
open to debate and input/enhancement from others.

Peter

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210