Re: updating GSE for the new millennium

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

On Wed, 30 Apr 2003, David Conrad wrote:

> Iljitsch,
> 
> On Wednesday, April 30, 2003, at 07:19  AM, Iljitsch van Beijnum wrote:
> > We've been talking about GSE earlier this month before we got 
> > side-tracked. I think it's time to see what a descendent of the GSE 
> > family would look like in the third millennium, so I want to write a 
> > draft. Hopefully this will give us something useful to talk about in 
> > Vienna.
> 
> Hmm.  I am doing the same thing (although I'm not planning on being in 
> Vienna).
> 
> > What I'd like to do is take input from everyone and incorporate this 
> > as much as possible in this draft. That probably means more options 
> > and more complexity that we'd like to see in an actual protocol, but 
> > for now that's fine: we can always prune later.
> 
> I would suggest starting the other direction -- the IETF already has 
> way too many drafts that try to be all things to all people.  Start 
> with a simple, easily understood base and see how far that gets you.
> 
> > The first order of business is the address rewriting. It seems to me 
> > that the different options here (GSE-like one-way rewriting upper bits 
> > with globally unique lower bits, MHAP double rewriting) can be 
> > accommodated by doing the following:
> >
> > When transmitting, for both the source and destination address: take a 
> > globally unique N bit label and map to one of several possible IPv6 
> > address suitable for routing associated with this label. When 
> > receiving, map the addresses back to labels.
> 
> 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.  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).  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.

> 
> > For the source when transmitting or the destination when receiving, 
> > the rewriter can presumably easily find the additional information 
> > needed to compelete the mapping in its configuration, but for the 
> > destination when transmitting or the source when receiving it must 
> > first discover the mapping.
> 
> Yes.  I believe it'll turn out that this discovery is where the 
> complexity (political if not technical) will lie.  I do not believe it 
> to be a difficult technical problem, however I'm sure any solution 
> proposed will be controversial.
> 

The main issues I can see behind restoring the original packet would be TCP/UDP
checksums and IPSec.  If the two end points are labelling aware, measures can
be taken to ignore the label from the checksums or replace it for IPsec,
otherwise it would be up to labelling boxen (border routers or other) to do
this on behalf of the hosts which are unaware of the labelling possibility. 

A site should also know the full permutations of labelled packets and could
check for each of them, however checking the source address would save all this
checking.

One issue I just thought of is what happens if a physical site represents
multiple logical MH sites.  Much of this discussion centres on a physical site
only having one logical MH site prefix (we are talking about prelabelled
addresses here, not live transit addresses). 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.  If one did not need to rewrite the
packets and just let the end host sort out the mess (it presumably would be
fully aware of the multiple logical sites), that would be ultimately a lot more
workable.

> > Is this workable?
> 
> I think so.
> 
> > Two additional questions:
> > - Is adding options or tunnel headers an option,
> 
> I don't think so.  Options increase complexity as they result in making 
> it impossible to do "in-place" rewrites.  You generally have to 
> synthesize a full header then append the data of the original packet 
> after the options.  Tunnel headers get you into trouble with MTUs and 
> fragmentation.  Avoiding these if possible would be a good idea I 
> believe.
> 
> > - Can packets only be rewritten once, or can this happen several times?
> 
> Address rewriting (at least as described above) would appear to me to 
> be end-to-end transparent.  As such, I'd say yes, although I'm not sure 
> I see the point.

I think if you apply the rule that a prelabelled packet can only be labelled
once (at entry to the global part of the network), the only possibility of
extra rewriting would be if the packet was restored to it's original
prelabelled state (I can't see when this would happen inside the global transit
network, but it might).

I wonder if these ideas might receive more support if the terminology of
labelling were used instead of GSE.  We'd be more likely to draw in some
support from the MPLS mob.

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