Hi Iljitsch,
Since MPLS encapsulation is quite light may be usefull to explore
this direction.
Yet, I have few questions:
Would not the path set up mechanism be a big issue in inter-domain
context?
Do we really need path set up?
Can you explain how this will help make the Internet scale larger?
(i.e. what is the gain on the BGP tables?)
One comment:
- requires new code and new ways of doing things
We cannont re-architecture the Internet with old code ;-)
(Even using MPLS, you can partly re-use the code. )
Luigi
- incremental deployment looks hard
- ITR only gets to choose destination ETR, not alternative ways to
get there
- packet overhead is relatively large
What I propose is use MPLS instead. The MPLS equivalent of the ITR/
ETR functions are widely available in implementations today. MPLS
has the potential to have relatively little packet overhead, and it
allows for the possibility to specify paths rather than just exit
points. Because MPLS uses a label rather than a tunnel endpoint
address, it's much easier to decapsulate packets at arbitrary
locations rather than at one exactly specified point.
It's fairly easy to deploy MPLS today and put labels on packets
when they enter an ISP network, tunnel them through the core and
pop the label at a border router and egress the packet from the AS.
Next step would be something along the lines of distributing labels
in eBGP between consenting neighboring ASes, so that AS A can tell
AS B to put label L on packets towards prefix X, so that B's
ingress router doesn't have to do a full table lookup, either.
Fairly boring stuff.
But it gets more interesting if we give sources (could be site exit
routers or middleboxes, but ideally source hosts) the ability to
put a label stack on packets. That would work like this: at some
point, a source decides that it's sending so many packets to a
destination that it's useful to make these packets go through the
core faster, so it sends out a bubble packet. This is an IP packet
with as its destination address the destination in question,
preceded by an MPLS header with a special "bubble" label value. If
the ISP doesn't support this mechanism, the packet is simply
dropped and nothing happens. (Remember, this packet is not part of
the ongoing communication with the destination.) If the ISP
supports the mechanism, it returns to the source a set of label
stacks with priorities. The source now encapsulates packets to the
destination in one of the label stacks. It monitors return traffic
to see if the path works, and switches to a different one if it
doesn't. (So this requires state, want this to happen close to the
source.) The source can then send a packet that has one of the
thusly discovered label stacks followed by a bubble to discover
label stacks for paths through the next AS. And so on until it
knows a full path or possibly a number of full paths.
This mechanism allows for multihoming and network (even host?)
mobility by having a destination declare that it's currently
residing at an alternative address. The source then sends a bubble
for that address, but when it has a full path, it encapslates
packets with the original destination address using the MPLS stack
for the path towards the care of address.
The thing that I really like about this is that it allows for a
source to find different paths towards the same destination, which
gives the host ways to optimize its communication that don't exist
today.
--
to unsubscribe send a message to [EMAIL PROTECTED] 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
Luigi Iannone
[EMAIL PROTECTED]
