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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Jari,

Some time ago we discussed whether a hierarchical view of
the options is sufficient, and I know some of us (including me)
concluded that it isn't, and that we really need a facet-based
view. I think that hierarchies such as you have drawn tend to
conceal similarities. But if you stick to hierarchies, I think
you need at least one more, taking the view from the upper layer
protocols. So I think we need a view like this too:

          Application
       _______|_______
       |             |
     Path-aware    Path-unaware
       |             |
                   Transport
             ________|________
             |               |
           Path-aware     Path-unaware

etc.

     Brian





On 2008-07-25 00:18, Jari Arkko wrote:
> 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
> 



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