[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updating GSE for the new millennium

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.
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?

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.

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.

Just some thoughts...

Rgds,
-drc