[RRG] thoughts on the design space 1: the space

[Jari Arkko <jari.arkko@piuha.net>]

Hi,

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 [1]; 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:

  http://www.arkko.com/ietf/rrg/designspace_dataplane.jpg
  http://www.arkko.com/ietf/rrg/designspace_mappingreso.jpg

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.

DATAPLANE
========

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.

MAPPING RESOLUTION
===============

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

Jari

[1] http://tools.ietf.org/html/draft-thaler-ip-model-evolution-01


--
to unsubscribe send a message to rrg-request@psg.com 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