[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] thoughts on the design space 1: the space
- To: rrg <firstname.lastname@example.org>
- Subject: [RRG] thoughts on the design space 1: the space
- From: Jari Arkko <email@example.com>
- Date: Thu, 24 Jul 2008 15:18:22 +0300
- User-agent: Thunderbird 18.104.22.168 (X11/20080505)
I wanted to bring up a few thoughts about the high-level design space.
This is based on something we did as a group exercise in a recent
Dagstuhl seminar, with Lixia Zhang, Dave Thaler, Bob Briscoe, Christian
Vogt, Mikko Särelä, Luise Burness, Andreas Windsam, and Wolfgang
Mandelbrat -- though I'm only speaking for myself in this e-mail. The
goal of the exercise was to look at the possible solutions and
understand what impacts they might have on upper layer protocols. This
is important so that our solutions do not end up impacting negatively on
applications and user experience. Some of the assumptions upper layers
have been built on are documented in ; I would say that document
should be on your reading list for Dublin.
Anyway, here's the the basic design space as we saw it:
Note that this reflects only two key pieces, what you do on data path
and how mappings are resolved. There are equally important other aspects
that are not covered here, such as how mapping verification is performed.
The root of the design space tree begins with the choice of whether the
intent is to do efficient routing on a flat space vs. use a small
aggregatable space and a separate identifier space. An example solution
in the former category is ROFL. Most of the things discussed in RRG
belong to the latter category.
The next choice in the aggregatable branch is whether the
identifier-locator separation goes all the way to the host or not. If it
goes all the way to the host, we can see different solutions based on
which layer the design is at. Shim6, Six/One, and HIP are IP layer
solutions, whereas multipath TCP would be a transport layer solution.
If on the other hand we do not take the separation to the hosts, there
will be some device in the network that divides the network into two
parts, the edge and core. In the core we employ aggregatable addressing,
and edge networks and hosts run on identifiers. Many of the RRG
solutions are in this design branch. We can see different solutions
based on what operation is performed when you cross the edge-core
boundary. Pure Lisp without draft-lewis is an example of a solution that
employs encapsulation. The other main solution type is translation.
However, translation come sin different variants:
(1) One sided translation where you always translate your edge addresses
to core addresses. No one needs to reverse the translation, which makes
this approach easy to deploy as it does not assume anything about other
side's deployment. Essentially, you place a NAT on your network border
and you can forever whatever addresses you are using inside without any
impact to others.
(2) Two sided translation where you always undo the translation on the
other side. This only works if the other side has upgraded to the same
system. While conceptually different from encapsulation, the end host
sees a very similar result from two sided translation and encapsulation.
Possibly the only difference is what happens to path MTU.
(3) One or two sided translation, such as Six/One Router. Here you do a
reversible translation if the other side has upgraded, and otherwise
employ one sided translation.
I only draw a very simplistic diagram for this. But basically, the host
based designs like Shim6 can operate without any extra mapping
resolution system, albeit this limits their functionality a bit. For
instance, all addresses have to be in DNS for initial connect to
succeed, if there is a failure condition.
Designs that do use a mapping resolution system come in two variants:
one that always attempts to hold the entire space, and one that runs a
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