Re: updating GSE for the new millennium

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

On Wed, 30 Apr 2003, David Conrad wrote:

> On Wednesday, April 30, 2003, at 07:27  PM, Peter Tattam wrote:
> >> Depending on your approach, it may not be necessary to rewrite the
> >> source address.
> >
> > I don't think it's necessary.  The less changes to the packet, the 
> > better in my
> > opinion.  Just map the N bit label at whatever point a decision has to 
> > be made
> > to forward the packet outside the site.  I think only one relabelling 
> > should be
> > allowed and the decision to relabel be based on on the pre-labelled 
> > address.
> 
> Agreed.

Additionally, I think it is a bad idea to relabel the source as the label
supplied is unlikely to be the best path.  The other end needs to determine
this. 

> 
> > I would presume that a MH address be identifiable by just looking at 
> > the address
> > (i.e. the top M (where M < N) bits represent a particular class of MH
> > addresses).
> 
> Why would you not want all addresses to be multi-homable?  Why add the 
> complexity of figuring out whether an address is multi-homable or not?

it probably doesn't matter - I was suggesting it as a method of determining if
the packet was clean or dirty.  It would be important if dirty packets end up
at the destination host.

> 
> > Once the labelling is done, it can be sent all the way to the end
> > host.  If one retains the prelabelled source address, this is an 
> > additional tag
> > to the end point that the packet can have it's label removed.
> 
> Right.  To put one approach I've been toying with in more concrete 
> terms:
> 
> Inside the site, call the first 48 bits of the address the 'site 
> identifier'.  These are globally unique, permanently assigned 
> identifiers which are used as the prefix for all devices within the 
> site.  Outside the site, call the first 48 bits the 'aggregation 
> locator'.  These are globally unique, transitory (for the duration of 
> the connectivity contract between the site and the ISP) routing 
> locators assigned by ISPs out of blocks they announce to their peers as 
> aggregates.  At the border, the 'site identifier' is used as a key into 
> a table of site identifier/aggregation locator mappings.  In the DNS, 
> AAAA rdata is a site identifier and all hosts within a site use the 
> site identifier as the prefix for their source address(es).
> 
> Packet sent and arrives at a border device.  First 48 bits of the 
> destination address are stripped off, used as a key into a table of 
> site identifier/aggregation locator key/value pairs to get back one or 
> more aggregation locators, one of the aggregation locators is chosen 
> and written into the first 48 bits of the destination address.  
> Packeted is forwarded on to the next hop according to the value of the 
> aggregation locator.
> 
> On reception at the destination site, the first 48 bits of the 
> destination address are stripped off.  The aggregation locator value is 
> then looked up in the manually configured set of aggregation locators 
> on the border device that handles the inverse mapping to get the site 
> identifier.  The site identifier is then written into the destination 
> addresses and the packet is forwarded onto the destination within the 
> site.
> 
> Advantages that I can see:
> - multi-homing is 'easy', simply add new provider's aggregation locator 
> to your site identifier
> 	- no need to inform ISPs of each other's existence
> 	- no negative impact on global routing tables
> - re-homing is a special case of multi-homing (only one aggregation 
> locator associated with the site identifier)
> 	- renumbering becomes trivial
> - no modification necessary to existing v6 stacks or applications
> - no modification necessary to the DNS
> - all v6 stateless/statefull auto-config stuff continues to work
> 	- privacy is no more of a concern than it is in existing v6 addressing 
> arch
> - mapping of site identifier/aggregation locator is done at the edges 
> where performance is less of a concern
> 	- mapping is managed by site administrator so no need for new trust 
> relationships
> - end-to-end transparent
> - traceroute still works
> 
> Disadvantages that I can see:
> - Assumes the boundary of a site is distinct enough to install a (set 
> of) device(s) at it
> - Implies a site is internally connected
> - Needs a globally distributed key/value lookup table
> 	- Data integrity of the table must be assurable
> - Requires mucking about with the packet in flight.  Twice.
> - Needs a border device (or process) at both source and destination
> - Need at least two globally unique prefixes per site (one site 
> identifier, one or more aggregation locators)
> - Doesn't provide host multi-homing unless a host is also a site
> - traceroute still works
> 
> I'm sure I'm missing some.  I'm equally sure people will tell me why 
> this won't work... :-)
> 
> > The main issues I can see behind restoring the original packet would 
> > be TCP/UDP
> > checksums and IPSec.
> 
> Perhaps I misunderstand.  If the original values are restored before 
> delivery at the final destination, the TCP/UDP checksums would compute 
> correctly and IPSec would not be affected.

For a TCP connection, the srce/dest part of checksum can be cached.  One just
has to agree on knowing when to include the srce/dest pair in the checksum.
Another reason for determining if the packet is clean or dirty.  Minor
optimization that's all.  Don't forget that in Ipv6 we don't do IP header
checksumming any more.

We need to search for protocols that depend on the addresses in the header
being intact and work out whether the packet needs to be reconstructed or
cached values can be used instead.  If we are considering very high speeds,
this could be important.  Messing with the packet in transit could be a
performance hit and if we can get away without doing it, all the better.

> 
> > One issue I just thought of is what happens if a physical site 
> > represents
> > multiple logical MH sites.
> 
> Not an issue (given oodles of address space) -- use multiple site 
> identifiers and aggregation locators.
> 
> > When there are several possible MH
> > site addresses, one would have to match the post labelled transit 
> > addresses to
> > the MH site prefix that they pertain to.
> 
> The key would be to maintain a mapping between each and every site 
> identifier and the aggregation locators providing service to that site 
> identifier.

This is the really tough bit.  Maintaining an accurate and secure database of
mappings is non-trivial.  Each site has their own specific view of the network
topology which makes this quite different to the DNS system.

The only other issue I wonder about is using single box to do translations at
the site boundary.  Because such a box is an insertion, it could be a single
point of failure, and could well have scalability issues.  I would see it as an
interim step towards a later solution where end hosts are able to mange the
translations themselves.  At least it should be a stateless translation which
makes it relatively scalable.

> 
> Just some thoughts...

Some good ones.  Glad to see others recognizing the benefits of the GSE style
of doing stuff.

> 
> Rgds,
> -drc
> 
> 
> 

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