[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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:


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


[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