Subject: updating GSE for the new millennium

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Apr 2003 16:19:31 +0200

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.

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.

If there is reasonable consensus on something, I'll use it. If there 
are several ways to do something that aren't mutually exclusive, I'll 
use all of them. If there is no feedback, I'll use my own judgement...

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.

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.

Is this workable?

Two additional questions:

- Is adding options or tunnel headers an option, or would this make 
this scheme too unattractive over IPv4-style multihoming?

- Can packets only be rewritten once, or can this happen several times?

---

From: David Conrad <[email-masked]>
Date: Wed, 30 Apr 2003 17:45:14 -0700

Iljitsch,

> draft. Hopefully this will give us something useful to talk about in 

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.

> receiving, map the addresses back to labels.

Depending on your approach, it may not be necessary to rewrite the 
source address.

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

> Is this workable?

I think so.

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

Rgds,
-drc

---

From: Peter Tattam <[email-masked]>
Date: Thu, 1 May 2003 12:27:09 +1000 (EST)

> Depending on your approach, it may not be necessary to rewrite the 

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.

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

> be end-to-end transparent.  As such, I'd say yes, although I'm not sure 

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.

> -drc

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210