[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Routing Research Group <email@example.com>
- Subject: [RRG] GSE?
- From: Robin Whittle <firstname.lastname@example.org>
- Date: Wed, 11 Jun 2008 23:55:57 +1000
- Cc: email@example.com
- Organization: First Principles
- User-agent: Thunderbird 22.214.171.124 (Windows/20080421)
You wrote in:
> Please, please, please go read GSE. You may not like it, you may
> not agree with it, but until you grok it, you haven't seen a big
> chunk of the solution space.
(See quickie summary below my signature.)
In the context of the RRG potentially forming a consensus that we
don't need to recommend a solution for IPv4, but can rely on some
IPv6-based solution and mass migration to IPv6, I think it is vital
that all significant parts of the IPv6 solution space be considered.
GSE seems to have been developed briefly around 1997. I understand
that applying it to IPv6 as used today would involve major changes
in routers, host stacks and some or all applications.
There may well be some major attractions in doing this, if it could
be done, but it sounds like a radical thing on which to bet the
future of the Net.
Could you or someone else put together a proposal and link to it
from the RRG wiki? An 8 page summary and analysis document would be
A crucial part of this would be the time-frame for transitioning the
current IPv6 system to whatever it is you are planning, and then
having a transition plan for most end-users from IPv4 to the new system.
I think it would also be good to explain why you would prefer to do
this in a hurry for IPv6 - due to whatever urgency you or other
people might think about the IPv4 scaling problem - rather than
fixing the IPv4 problem with a map-encap scheme and then being able
to take more time on whatever it is you propose for IPv6.
If there was a plan to keep IPv4 going nicely for another decade or
two with map-encap while cooking up something more elegant and
lasting - including perhaps GSE for IPv6 without the need for
map-encap - then I might be able to get enthusiastic about it.
Still, I think map-encap + TTRs is the way forward for scalable,
generally optimal path mobility. If the GSE system could do
multihoming and portability without the need for map-encap, then
this reduces the scale and cost of the map encap system to that
required for genuinely mobile hosts and networks.
I understand that a GSE-based solution would not involve
encapsulation at all, and encapsulating IPv6 packets is a more
costly process than IPv4 packets, due to the very long addresses.
I think this is a significant problem for map-encap for IPv6 VoIP
GSE stands for "Global, Site, and End-system address elements". It
is only applicable to IPv6, or to an addressing system with 128 bits.
The 16 byte IPv6 address is split into 3 pieces:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| Routing Goop | STP| End System Designator |
6+ bytes ~2 bytes 8 bytes
Routing Goop signifies where the Site attaches to the Global
Internet. The Site Topology Partition (STP) is Site-private "LAN
segment" information. The End System Designator (ESD) specifies
an interface on an end-system.
The ESD for each host is globally unique. Routing Goop is used by
the global routing system and is rewritten in the destination field
when it arrives at a site.
I haven't read enough to know how it provides multihoming and
portability (of the ESD part of the address) when changing ISPs.
One immediate result is that upper-layer protocols must use only
the ESD for purposes such as pseudo-header checksums and the like.
The ESD is the invariant token, the RG is possibly transient
topology information subject to change.
So how does the Routing Goop and STP get set when the packet leaves
the site for another? Does a router change them or does the sending
host have to get it right. Does there need to be a mapping function
and consequently a mapping database to determine what to set these
to, since the ESD is what uniquely identifies the destination host?
What lead to the demise of GSE ten years ago?
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg