Subject: [arch-d] Major practical decision

From: [email-masked] (Noel Chiappa)
Date: Fri, 8 Dec 2006 11:54:49 -0500 (EST)

So, this high-level conversation has been interesting and educational, but
I'd like to ask a more "brass-tacks" question. In doing so, I'm basically
recognizing that while it's nice to theorize with a blank sheet of paper,
when it comes to specifying bits you have practical constraints.

I get the sense that it is now generally accepted that widespread
multi-homing has to be handled by use of multiple routing-names, and
identity/location separation.

However, it's not clear to me that a new end-end naming layer (e.g. SHIM6 or
HIP) is really a viable solution, because of the amount of legacy equipment
out there. (And a top of the hatly hat to David Conrad for first raising this
issue.) I.e. if your site is multi-homed, and you've deployed HIP/whatever,
that's not much use if many of the people trying to talk to you haven't.

David's contention was that because of this we may be forced to convert the
current IPvN addresses into end-end names, "jack up" the internetwork layer,
and insert a new layer underneath, and deploy some sort of mapping system to
map from IPvN "addresses" to some new routing-name namespace.

I think that's a really good argument - that this is the only solution that's
viable in a short time-frame. However, I'm very interested to hear what
everyone else thinks on this point.

(I note that it's always better to deploy something designed to a purpose, and
it would be better to name end-end entities out of a new namespace designed
for that purpose, but alas, we may be stuck.)

I ask this because jack-up assumes a new routing-name namespace, which has
implications for the routing: it immediately lands us with what seems to me,
after a moderate look, to be a fairly hard problem in that part of the system
- although one more soluble than routing PI addresses, before anyone says
anything!

So, what's it to be: jack-up (i.e. insertion of a new internetworking layer),
or new end-end names (i.e. insertion of a new end-end naming layer)?

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Mark Handley" <[email-masked]>
Date: Fri, 8 Dec 2006 18:02:30 +0000

> or new end-end names (i.e. insertion of a new end-end naming layer)?

I'm not sure these are the only possibilities.

We've been playing with the idea of using edge-to-edge tunnelling to
construct an infrastructure for defending against DDoS attacks.  An
unpublished paper is here if you're interested:
http://nrg.cs.ucl.ac.uk/mjh/tmp/e2etun.pdf

Anyway, this sort of edge-to-edge tunnelling doesn't require any
end-host changes, but does permit multiple routing names (in this
case, the decapsulator addresses) for each end-host IP address, and it
should be incrementally deployable.  I hadn't intended it as a
multi-homing architecture, but it might work OK.

In any event, it's an example of an architecture that isn't quite
either of the two you listed above.

 - Mark

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 8 Dec 2006 20:05:20 +0100

Hi Noel,

> that's not much use if many of the people trying to talk to you 

yes, these approaches need that the peer supports the protocol (either 
the end node itself or some form or proxy)

> everyone else thinks on this point.

i am not following

what kind of approach could provide multihoming support (preserving 
established communications) without requiring support from both peers 
of the communications? (by peers i mean either the end nodes themselves 
or devices on the edge next to each peer that perform the multihoming 
functions for them)

If we do actually manage to define a solution that _only_ requires 
modifications to the multihomed site and does not requires 
modifications to the peers that it is communicating with (nor the the 
network outside the multihomed site) this would be indeed a really nice 
feature, because only those who actually get the multihoming benefits 
have to pay the costs of supporting the multihoming support tools, 
which is very nice, but i am not sure i have ever seen a proposal that 
does this.... could you expand?

regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Fri, 8 Dec 2006 20:44:21 -0800

> or new end-end names (i.e. insertion of a new end-end naming layer)?

My $.02:

We're supposed to be architecting a fix for the Internet that should  
last for the foreseeable future.  Not just the next 10 or 20 years,  
but the next 100 or so.  The jack-up model is somewhat less clean and  
inevitably introduces suboptimalities at the interface between the  
layers.  Thus, I'm in favor of replacing the namespace.

Regards,
Tony

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Dec 2006 06:30:24 -0500

> I get the sense that it is now generally accepted that 
> widespread multi-homing has to be handled by use of multiple 
> routing-names, and identity/location separation.

We need to crisply define and obtain consensus on Routing-Names.

> HIP) is really a viable solution, because of the amount of 
> legacy equipment out there. (And a top of the hatly hat to 
> David Conrad for first raising this
> issue.) I.e. if your site is multi-homed, and you've deployed 
> HIP/whatever, that's not much use if many of the people 
> trying to talk to you haven't.

This is a deployment issue yes but not an insurmountable one the
industry is capable of adapting such as the application move today to
SOA.  But, more importantly at this point in the architecture discussion
I believe it must remain on the table as a viable option.

> 
> David's contention was that because of this we may be forced 
> to convert the current IPvN addresses into end-end names, 
> "jack up" the internetwork layer, and insert a new layer 
> underneath, and deploy some sort of mapping system to map 
> from IPvN "addresses" to some new routing-name namespace.

These are three efforts that can happen regarding our work to define an
architecture in parallel, I don't see that as a problem.

> 
> I think that's a really good argument - that this is the only 
> solution that's viable in a short time-frame. However, I'm 
> very interested to hear what everyone else thinks on this point.

I think we must define short and long term before one can answer this
question.

> 
> (I note that it's always better to deploy something designed 
> to a purpose, and it would be better to name end-end entities 
> out of a new namespace designed for that purpose, but alas, 
> we may be stuck.)

This is my view currently we should move to a new namespace for
end-to-end entities.

> 
> 
> I ask this because jack-up assumes a new routing-name 
> namespace, which has implications for the routing: it 
> immediately lands us with what seems to me, after a moderate 
> look, to be a fairly hard problem in that part of the system
> - although one more soluble than routing PI addresses, before 
> anyone says anything!
> 
> So, what's it to be: jack-up (i.e. insertion of a new 
> internetworking layer), or new end-end names (i.e. insertion 
> of a new end-end naming layer)?

I think for now we have to pursue these multiple paths.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Dec 2006 06:36:17 -0500

I don't think we can develop a solution that will last 100 years.  30
years maybe.  I beleive something else will break the system that has
nothing to do with the namespace decision or IP layer.  This is not to
say we should not replace the namespace but to attempt to provide an
architecture that can be implemented by engineers that lasts 100 years
seems a bit impossible to me.

/jim 

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]] 
> Sent: Friday, December 08, 2006 11:44 PM
> To: Noel Chiappa
> Cc: [email-masked]
> Subject: Re: [arch-d] Major practical decision
> 
> 
> internetworking 
> > layer), or new end-end names (i.e. insertion of a new 
> end-end naming 
> > layer)?
> 
> 
> My $.02:
> 
> We're supposed to be architecting a fix for the Internet that 
> should last for the foreseeable future.  Not just the next 10 
> or 20 years, but the next 100 or so.  The jack-up model is 
> somewhat less clean and inevitably introduces suboptimalities 
> at the interface between the layers.  Thus, I'm in favor of 
> replacing the namespace.
> 
> Regards,
> Tony
> 
>

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 9 Dec 2006 07:42:11 -0500

> seems a bit impossible to me.

I see extra-terrestrial routing in all seriousness as a major issue  
for the next 100 years (maybe not the
next 20 years, but certainly the next 100). Adopting the 100 year  
rule would imply that there should be a DTN component to the current  
work, and also probably that we should worry about relativistic  
synchronization effects, which seems to be a little premature.

I am sure that others can come up with likely or possible new issues  
with a 100 year time horizon. While it might
be interesting to enumerate them, I am not sure it would be fruitful  
to incorporate them in the current work.

Regards
Marshall

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 9 Dec 2006 15:57:37 +0200

Mark,

On 12/8/06, Noel Chiappa <[email-masked]> wrote:
>> internetworking layer), or new end-end names (i.e. insertion of a  
>> new end-end naming layer)?

On 8 Dec 2006, at 20:02, Mark Handley wrote:
> We've been playing with the idea of using edge-to-edge tunnelling  
> to construct an infrastructure for defending against DDoS  
> attacks.  ...
>
> case, the decapsulator addresses) for each end-host IP address, and  
> it should be incrementally deployable.  I hadn't intended it as a  

Hmm.  I'm not that sure.  What you seem to suggest looks like  
another, more implementation related dimension to me.

Basically, what I understand Noel saying is that we either must add a  
layer above the current IP layer or one below it.  This can be, of  
course, be implemented at various points in the network: at end- 
hosts, at edge routers, somewhere at the first ISP closest to the end  
site, or in the core.  Or some combination of those.  To me, that  
looks like another, basically orthogonal dimension, which is more  
implementation related than where-in-the-stack to insert the new  
layer.  For example, I could imagine a solution that would be  
initially implemented in many laptops, in big boxes used by many  
major corporations, and by some advanced ISPs, and then gradually,  
over a longer term, by all hosts.

Hence, what you seem to propose looks like an implementation strategy  
to me.

Related to your paper, I think that in the long term an architecture  
that allows keeping the routing names (locators) as relative secrets  
provides some pretty effective protection against DDoS.  Furthermore,  
if you use overlay routing instead of resolution to initially map the  
location-independent identifiers into locators, you can allow the  
responding (server) host or site to make the decision whether to  
reveal its locators to the initiator (client).  [That's the approach  
we proposed to be used in Host Identity Indirection Infrastructure  
(Hi3).]

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 9 Dec 2006 16:19:09 +0200

> that's not much use if many of the people trying to talk to you  

What I think we need is a gradual, proxy based solution approach, as  
alleged e.g. by Marcelo Bagnulo.

Let's consider briefly what's behind that proposal.  When deploying a  
new naming layer, we will have four kinds of situations: legacy- 
legacy, new-new, legacy-new and new-legacy.  Legacy-legacy and new- 
new are, in general, not very interesting from an architectural point  
of view, even though there will be numerous engineering and security  
concerns there.

This leads to the following straw man analysis:

A. Legacy (site/host) connecting to a new (site/host)

A.a New (site/host) still providing legacy connectivity by publishing  
a legacy address

This is provided by both HIP and SHIM6, with the difference that  
SHIM6 is oblivious whether the peer supports SHIM6 when the initial  
connection is made.  With HIP, the choice must be currently made  
during initial contact, but there's been discussions about delayed  
HIP state set-up.

A.b New (site/host) being reachable only with the new connectivity  
(no published legacy address)

A.b.a New identifiers being routable in the legacy system

This is the interesting case, IMHO.  If the new identifiers can be  
embedded into the legacy addressing system (e.g. as suggested in  
draft-laganier-ipv6-khi-05.txt), it may be possible to make them  
routable.  For example, the prefix could be routed to one or a few  
sites in the core network, providing a service that would encapsulate  
the legacy traffic (along a similar way Mark Handley et al suggested  
in their e2efa paper) and provide connectivity to the new "world".

Any site adopting the new system could then, independently, provide  
the same encapsulation service locally, for those hosts that don't  
implement it natively.

A.b.b New identifiers not routable in the legacy system

This seems to lead to a situation where the legacy hosts are not able  
to communicate with new systems that do not provide legacy  
connectivity.  This may be a desirable end state, providing the  
remaining legacy sites an incentive to upgrade.

B. New (site/host) connecting to a legacy (site/host)

B.a New (site/host) being able to directly connect with to legacy  
addresses

Again, this is provided by both HIP and SHIM6.

B.b New (site/host) not being able to directly connect with legacy  
systems

B.b.a "Reverse" proxy service

Under certain not-so-simple circumstances we could imagine a proxy  
service that would provide any interested legacy systems a "presence"  
in the new system.  That is, any legacy host/site could register with  
the proxy service, the proxy service would allocate it an ID in the  
new system, and allow new sites/hosts connect to the legacy one  
through it.

I'm sure there are options I'm not listing above, but I must go now.

--Pekka Nikander

---

From: Tony Li <[email-masked]>
Date: Sat, 9 Dec 2006 10:06:13 -0800

> seems a bit impossible to me.

Perhaps.  Let me make the point differently: whatever we do at this  
point should be the best possible solution that we can come up with.   
The cost of deployment of even 'short-term' solutions is incredibly  
high, and is paid by people all over the world.  A short-term kludge  
is not a responsible solution to our problems.  We have the  
opportunity now to affect a long-term architectural change and we  
should give it our best effort.  If we do well, our solution will far  
outlive us.

Tony

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Dec 2006 16:37:57 -0500

My understanding is adding a layer is jack-up and that is for RAM.  Not
this list?  This is to discuss not jack-up?  Yes or No.

Also we should adhere to what is IETF per IRTF and I agree Internet
inter-planetary type work should have some core structure that lasts 100
years but that is IRTF work IMHO, thus we need to walk that fence
between IRTF and IETF most likely.  

/jim 

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Saturday, December 09, 2006 8:58 AM
> To: Mark Handley
> Cc: Noel Chiappa; [email-masked]
> > construct an infrastructure for defending against DDoS attacks.  ...
> >
> Basically, what I understand Noel saying is that we either 
> must add a layer above the current IP layer or one below it.  
> This can be, of course, be implemented at various points in 
> the network: at end- hosts, at edge routers, somewhere at the 
> first ISP closest to the end site, or in the core.  Or some 
> combination of those.  To me, that looks like another, 
> basically orthogonal dimension, which is more implementation 
> related than where-in-the-stack to insert the new layer.  For 
> example, I could imagine a solution that would be initially 
> implemented in many laptops, in big boxes used by many major 
> corporations, and by some advanced ISPs, and then gradually, 
> Hence, what you seem to propose looks like an implementation 
> strategy to me.
> 
> Related to your paper, I think that in the long term an 
> architecture that allows keeping the routing names (locators) 
> as relative secrets provides some pretty effective protection 
> against DDoS.  Furthermore, if you use overlay routing 
> instead of resolution to initially map the 
> location-independent identifiers into locators, you can allow 
> the responding (server) host or site to make the decision 
> whether to reveal its locators to the initiator (client).  
> [That's the approach we proposed to be used in Host Identity 
> Indirection Infrastructure (Hi3).]
> 
> --Pekka Nikander
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Dec 2006 16:59:44 -0500

> The cost of deployment of even 'short-term' solutions is 
> incredibly high, and is paid by people all over the world.  A 
> short-term kludge is not a responsible solution to our 
> problems.  We have the opportunity now to affect a long-term 
> architectural change and we should give it our best effort.  
> If we do well, our solution will far outlive us.

That would be a good goal and if we adopt this then any jack-up to
assist the potential melt-down should not be part of this thread
discussion or architecture work I deduce as I think that is within the
5-7 year range, and I do not believe we can come up with something that
reaches the market of this nature in 5-7 years, given the rules of
engagement above.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 11 Dec 2006 07:00:19 -0500

I believe we must separate transport end-to-end as one problem space and
routing as another problem space completely thus I am not sure I agree
or do not agree with the below but this is clearly not baked or agreed
within this discussion so we must keep going.

/jim 

> Sent: Saturday, December 09, 2006 9:19 AM
> To: Noel Chiappa
> > However, it's not clear to me that a new end-end naming 
> layer (e.g.  
> > SHIM6 or
> > HIP) is really a viable solution, because of the amount of legacy 
> > equipment out there. (And a top of the hatly hat to David 
> Conrad for 
> > first raising this
> > issue.) I.e. if your site is multi-homed, and you've deployed HIP/ 
> > whatever, that's not much use if many of the people trying 
> to talk to 
> > you haven't.
> 
> What I think we need is a gradual, proxy based solution 
> approach, as alleged e.g. by Marcelo Bagnulo.
> 
> Let's consider briefly what's behind that proposal.  When 
> deploying a new naming layer, we will have four kinds of 
> situations: legacy- legacy, new-new, legacy-new and 
> new-legacy.  Legacy-legacy and new- new are, in general, not 
> very interesting from an architectural point of view, even 
> though there will be numerous engineering and security concerns there.
> 
> A.a New (site/host) still providing legacy connectivity by 
> publishing a legacy address
> 
> SHIM6 is oblivious whether the peer supports SHIM6 when the 
> initial connection is made.  With HIP, the choice must be 
> currently made during initial contact, but there's been 
> discussions about delayed HIP state set-up.
> 
> A.b New (site/host) being reachable only with the new 
> connectivity (no published legacy address)
> 
> This is the interesting case, IMHO.  If the new identifiers 
> can be embedded into the legacy addressing system (e.g. as 
> suggested in draft-laganier-ipv6-khi-05.txt), it may be 
> possible to make them routable.  For example, the prefix 
> could be routed to one or a few sites in the core network, 
> providing a service that would encapsulate the legacy traffic 
> (along a similar way Mark Handley et al suggested in their 
> e2efa paper) and provide connectivity to the new "world".
> 
> Any site adopting the new system could then, independently, 
> provide the same encapsulation service locally, for those 
> hosts that don't implement it natively.
> 
> This seems to lead to a situation where the legacy hosts are 
> not able to communicate with new systems that do not provide 
> legacy connectivity.  This may be a desirable end state, 
> providing the remaining legacy sites an incentive to upgrade.
> 
> 
> B.a New (site/host) being able to directly connect with to 
> legacy addresses
> 
> B.b New (site/host) not being able to directly connect with 
> legacy systems
> 
> Under certain not-so-simple circumstances we could imagine a 
> proxy service that would provide any interested legacy 
> systems a "presence"  
> in the new system.  That is, any legacy host/site could 
> register with the proxy service, the proxy service would 
> allocate it an ID in the new system, and allow new 
> sites/hosts connect to the legacy one through it.
>

---

From: John Leslie <[email-masked]>
Date: Tue, 12 Dec 2006 11:50:27 -0500

Bound, Jim <[email-masked]> wrote:
> routing as another problem space completely...

   I agree with Jim, and I'd like to try for a first pass at consensus on
architecture.

   I don't have enough time right now to break down the portion of this
that we _do_ agree on, so please feel free to work this over in search
of consensus.

   However, we need to _be_ "in search of consensus" about "architecture".
This must not deteriorate into factions arguing "positions". I will try
to outline areas of questions; but first please let me do a complete
statement: I welcome discussion of the issues I'll name, and I welcome
listing other areas of question. I'm even OK with, "you're so far out of
it that you need to go away for a week or two!"

   (This is not intended to be a complete statement: there are many other
issues we must address. I believe those can be deferred until after we
reach consensus on this much.)

Statement:

   We want to work towards an architecture with separate "layers" for
"routing" and "transport", where "routing" is responsible for
- delivering packets to destinations on the same network;
- forwarding the other packets to another network "closer" to their
  destination;
- dropping the other packets if no "closer" network is available;
- building forwarding tables believed to be loop-free;
- detecting loops in forwarding paths actually used;
- dropping packets which would cause excessive congestion;
and "transport" is responsible for
- detecting and adjusting for packet loss;
- detecting and adjusting for packet corruption;
- reducing packet injection rate when a path is congested;
- choosing among multiple paths (if available).

Question Areas:

- is there a better name than "layers" for these problem spaces?

- is there a better name than "routing" for the lower "layer"?

- is there a better name than "transport" for the upper "layer"?

- are any of the responsibilities clearly assigned to the wrong "layer"?

- are we ready to agree to define separate namespaces for these "layers"?

   (I know there are other responsibilities which _must_ be assigned
before we can have a working system: I'd _really_ prefer not to argue
where they belong yet...)

--
John Leslie <[email-masked]>

---

From: David Barak <[email-masked]>
Date: Tue, 12 Dec 2006 10:47:49 -0800 (PST)

My disagreements are in-line

> - delivering packets to destinations on the same

Define "network" in this context - normally, I think
of routing as something done by a router: that is to
say a node, not by a network.  Networks are
destinations, or logical groupings of nodes.

> - forwarding the other packets to another network
> "closer" to their destination;

Do you mean to other nodes?

> - building forwarding tables believed to be

Today, it could be argued that forwarding and routing
occupy different sub-layers: do you mean that they
should be re-merged?

> - detecting loops in forwarding paths actually used;

Do you mean that the routing layer of a given node's
stack should maintain state on every packet which
passes, and check to see if it is seen again?

The goals of rapidly determining to which interface to
forward a given packet, and maintaining historical
state information about that packet conflict.  Routing
is connectionless today - do you mean to imply that it
should become connection-oriented?

> - dropping packets which would cause excessive

Based on what, and where?  If a packet I send will
cause excessive congestion 3 hops down the path,
should I drop the packets?  Congestion is either the
result of an overburdened processor attempting to
figure out what to do with packets, or it's trying to
shove more packets through an interface than the
interface can take.  Should taking into account
interface sizing become a routing-layer function, or
is that best left to a physical or data-link layer to
determine?

> - choosing among multiple paths (if available).

I was okay until I got here :)

If you do that, you lose the benefit of in-band
signalling, and are more likely to have the routing
and transport layers disagree about what the optimum
path is.

> - is there a better name than "routing" for the

If you break up the lower layer into "routing,
forwarding, link, and physical" you'd have a cleaner
separation.

physical - what it sounds like
link - framing, hop-by-hop compression, priority, &
queueing
forwarding - sending traffic to the network on which
one resides (connected routing)
routing - sending traffic to distant networks
(recursive forwarding)

-David

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: John Leslie <[email-masked]>
Date: Tue, 12 Dec 2006 14:49:15 -0500

David Barak <[email-masked]> wrote:
>> We want to work towards an architecture with
>> separate "layers" for "routing" and "transport",
>> where "routing" is responsible for 
> Define "network" in this context -

   I don't feel able to do so. :^(

   (There may well be a better name for this "layer"...)

> normally, I think of routing as something done by a router:
> that is to say a node, not by a network.

   Agreed. Perhaps "forwarding" might be a better name?

> Do you mean to other nodes?

   I think I mean "network" (even if I can't define it!).

> occupy different sub-layers: do you mean that they

   No.

> passes, and check to see if it is seen again?

   No. This function currently depends on a Time-to-Live
field being decremented. I do not mean to imply it must
be done that way, but IMHO the function cannot be avoided.

> should become connection-oriented?

   Absolutely not!

> Based on what, and where?

   Handwaving, mostly. ;^)

> If a packet I send will cause excessive congestion 3 hops
> down the path, should I drop the packets?

   Speaking only for myself: if you actually know that, yes.
However, I did not intend to claim it's desirable to know
that, or even that it's possible.

> Congestion is either the result of an overburdened
> processor attempting to figure out what to do with packets,
> or it's trying to shove more packets through an interface
> than the interface can take.  Should taking into account

   I did not mean to express an opinion on that. That's
among the (many) things I intended to defer discussion on.

> I was okay until I got here :)

   That line was a mistake! Please accept my apology!!!

> and transport layers disagree about what the optimum

   Somehow my addled brain thought this would clarify my
intent that the "routing" "layer" is not _required_ to
find an alternate path "quickly" when a link goes down.
Again, I was wrong to include this here, and I apologize!

   (If we later agree on separate namespaces for these
"layers", I may introduce what I was actually thinking
but failed to remove: that there may be more than one
"routing-name" for a "transport-name", and that the
"transport" "layer" would be permitted to choose which
of them to pass to the "routing" "layer". Regardless,
the whole question doesn't belong in this discussion,
and I beg unanimous consent to remove it.)

> forwarding, link, and physical" you'd have a cleaner

   Anybody else have an opinion?

> link       - framing, hop-by-hop compression, priority,
>              & queueing

   I had intended no change to "physical" or "link"
-- though I'd be happy to see discussion under another
thread about how "interface sizing" could be better
split between "link" and "forwarding".

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Dec 2006 14:41:11 +0200

> ... I'd like to try for a first pass at consensus on architecture.

Here's my take.

> "routing" and "transport", where "routing" is responsible for

I'm afraid we need to be more specific about terminology here,  
unfortunately.  Apparently we need to make a distinction between the  
routing and forwarding functions, and understand how routing names  
(locators) work in terms of them.  Conversely, it may be a good idea  
to call the forwarding/routing layer as "internetworking" or the  
"network" layer, as it often has traditionally been.

I'm still trying to figure out the transport functions and transport  
names.  From a larger point of view, I'm not convinced that we need a  
"transport" layer with separate names.

That said, I agree that we need to separate the currently confounded  
"identifier" and "locator" roles of IP addresses, thereby creating  
two distinct name spaces.  The "identifier" name space will be mainly  
used by applications and the "locator" name space by routing and  
forwarding.

I'm afraid that we haven't received any kind of consensus on how to  
do that separation.

[Skipping a list of potential functions for the "internetnetworking"  
and "transport" layers.]

> - is there a better name than "layers" for these problem spaces?

I'm afraid we first need to sort out the main namespaces and the main  
functionality they are needed support.  In my not so humble opinion,  
many of our current problems are exacerbated by the IP addresses  
being a confounding of being "identifiers" and "locators" (see RFC  
4423, Section 4, but also notice that my thinking has evolved since).

> - is there a better name than "routing" for the lower "layer"?

As I stated above, I'd prefer "networking" or "internetworking".

> - is there a better name than "transport" for the upper "layer"?

I'd prefer "application", understanding that it partly subsumes what  
we have traditionally called "transport".

The reason why I'd prefer "application" is that, IMHO, the "upper"  
name space should focus on the applications' demands. From an  
architectural point of view, I'm not convinced that the "transport"  
needs any stable naming at all.  Indeed, think about how little  
independent naming TCP and UDP have today.

> - are any of the responsibilities clearly assigned to the wrong  

I see this question as two-pronged:

- starting from the current networking reality, we cannot move that  
much responsibility around without causing flag days, which clearly  
would be unacceptable

- when thinking in terms of a "new" or clean slate architecture, I'm  
afraid that so much of our current wisdom must be reconsidered that  
it is probably a little bit too early to think in terms of layered  
responsibilities.

> - are we ready to agree to define separate namespaces for these  

I think it would be a big step forward if we could agree that we need  
to separate the current IPvN namespaces into two "layered" name  
spaces, the "lower layer" names being used primarily by the routing  
and forwarding system and the "upper layer" names being geared  
primarily towards the needs of applications and the legacy socket  
APIs.  [Apparently, the NSRG couldn't agree on that, and I don't  
remember having seen any announcement that any I* body would have  
agreed on that.]

Note that when asking for consensus on this, I am not *not* asking  
for consensus on whether Noel's "jack-up" or the HIP/SHIM6 like way  
would be the way, or perhaps some other way, nor what would be the  
details of the "layered" namespaces, etc.  That is, I am not asking  
for consensus on *any* of the details.

I am merely asking if we have an early consensus on the problem in  
terms of the general solution approach.  Do we agree that we need to  
separate the naming roles of the current IPvN addresses, as is  
described above?

To further clarify: in this case, I find it very hard to produce an  
exact definition of all the architecturally inclined problems that we  
have; for example, I can easily count to up to six or seven different  
problems, all partially caused by the present role confounding.   
Hence, instead of trying to agree on a problem definition (since I  
think producing it would be very hard), I propose that perhaps we  
could agree on a general solution approach.

--Pekka Nikander

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 13 Dec 2006 09:18:58 -0500

Dear Pekka;

On Dec 13, 2006, at 7:41 AM, Pekka Nikander wrote:

> unfortunately.  Apparently we need to make a distinction between  
> the routing and forwarding functions, and understand how routing  
> names (locators) work in terms of them.  Conversely, it may be a  
> good idea to call the forwarding/routing layer as "internetworking"  
> or the "network" layer, as it often has traditionally been.
>
> I'm still trying to figure out the transport functions and  
> transport names.  From a larger point of view, I'm not convinced  
> that we need a "transport" layer with separate names.
>
> That said, I agree that we need to separate the currently  
> confounded "identifier" and "locator" roles of IP addresses,  
> thereby creating two distinct name spaces.  The "identifier" name  
> space will be mainly used by applications and the "locator" name  
> space by routing and forwarding.
>

Is it realistic to assume that that there will be only one split ?  
(For example, in the MPI case a geographically based
locator might make sense, while for static networks a locator based  
on network hierarchy is probably more appropriate, and these
very different choices will influence the type of locator, and maybe  
the type of identifier, chosen.) So wouldn't the first step
be the selection of a means to identify the split being taken ?

> [Skipping a list of potential functions for the  
> "internetnetworking" and "transport" layers.]
>
>> Question Areas:
>>
> I'm afraid we first need to sort out the main namespaces and the  
> main functionality they are needed support.  In my not so humble  
> opinion, many of our current problems are exacerbated by the IP  
> addresses being a confounding of being "identifiers" and  
> "locators" (see RFC 4423, Section 4, but also notice that my  
> thinking has evolved since).
>
> I'd prefer "application", understanding that it partly subsumes  
> what we have traditionally called "transport".
>
> - when thinking in terms of a "new" or clean slate architecture,  
> I'm afraid that so much of our current wisdom must be reconsidered  
> that it is probably a little bit too early to think in terms of  
> layered responsibilities.
>
> I think it would be a big step forward if we could agree that we  
> need to separate the current IPvN namespaces into two "layered"  
> name spaces, the "lower layer" names being used primarily by the  
> routing and forwarding system and the "upper layer" names being  
> geared primarily towards the needs of applications and the legacy  
> socket APIs.  [Apparently, the NSRG couldn't agree on that, and I  
> don't remember having seen any announcement that any I* body would  
> have agreed on that.]
>
> terms of the general solution approach.  Do we agree that we need  
> to separate the naming roles of the current IPvN addresses, as is  
> described above?
>
>
> exact definition of all the architecturally inclined problems that  
> we have; for example, I can easily count to up to six or seven  
> different problems, all partially caused by the present role  
> confounding.  Hence, instead of trying to agree on a problem  
> definition (since I think producing it would be very hard), I  
> propose that perhaps we could agree on a general solution approach.

This indicates to me that, again, "one size fits all" is probably not  
realistic.

Regards
Marshall

---

From: John Leslie <[email-masked]>
Date: Wed, 13 Dec 2006 15:49:41 -0500

Pekka Nikander <[email-masked]> wrote:
> [John Leslie <[email-masked]> wrote:]
> 
>> Statement:
>>
> unfortunately.

   I take this as discussion about "better names" for the layers.

> Apparently we need to make a distinction between the routing and
> forwarding functions, and understand how routing names (locators)
> work in terms of them.

   This is certainly a necessary work item...

> Conversely, it may be a good idea to call the forwarding/routing
> layer as "internetworking" or the "network" layer, as it often has
> traditionally been.

   Speaking only for myself, something like "internetworking" fits
rather nicely. I don't like the name "network" because it confuses
almost everybody as to what the layer is about.

> "transport" layer with separate names.

   I think the question of designing a name structure is better taken
up after agreeing on the functions we're trying to accomplish. I
quite agree that in the absence of agreed functions there's no good
reason to design a name structure.

   (Please note that I left the question of namespaces quite open,
merely appending a question _whether_ we think we're ready to talk
about it.)

> used by applications and the "locator" name space by routing and  

   That souds like support for the overall statment _iff_ we come up
with the right names.

> I'm afraid that we haven't received any kind of consensus on how to  

   Nor, IMHO, should we try to at this stage.

   We should first lay out what we want the layers to do; then discuss
what sorts of namespaces are appropriate for those functions.

   (BTW, my personal opinion is that "improved office routers" can do
whatever transition functions we might agree upon, and that ISPs could
perform those same functions for their customers who choose not to
purchase "improved office routers".)

> 4423, Section 4, but also notice that my thinking has evolved since).

   I take this to be, "Maybe, but we aren't ready to agree what it is."

> As I stated above, I'd prefer "networking" or "internetworking".

   I accept "internetworking" as a suggested replacement.

> we have traditionally called "transport".

   Speaking only for myself, I consider that a poor choice. Inevitably,
it seems to infer that "transport", "session", and "presentation"
couldn't benefit from their own namespace -- a question I think best
avoided.

   IMHO, we'll be better equipped to name this layer if we can agree
upon some functions for it. Recall, I suggested
" 
" - detecting and adjusting for packet loss;
" - detecting and adjusting for packet corruption;
" - reducing packet injection rate when a path is congested;

   It was my intention to list needed functions without laying too
much responsibility on this layer -- in the interests of scalability.
These three are current responsibilities of TCP.

> independent naming TCP and UDP have today.

   Bingo!

   The three functions I listed clearly _can_ be accomplished without
a new namespace. If we design a new namespace at this point, it is
only based on a belief that we'll find some other function(s) --
possibly relating to multi-homing and mobility.

   IMHO, "applccations" are mostly agnostic about multi-homing and
mobility.

> much responsibility around without causing flag days, which clearly  

   I disagree.

   But let's first try to agree what we'd _like_ to move...

> it is probably a little bit too early to think in terms of layered  

1. I doubt we really can think entirely "clean-slate".

2. It doesn't feel too early to me.
   
> remember having seen any announcement that any I* body would have  

   This statement is too vague, IMHO.

   "Routing/Forwarding" _could_ expand to fill any space allotted. I
think it's important -- in the name of scalability -- to make sure it
doesn't.

   I can't attach any distinct meaning to "needs of applications and
the legacy socket APIs".

   When searching for consensus, it helps _a_lot_ to make the statements
crisp. It's human nature to "reach agreement" by writing words which
mean one thing to one faction and something else to another. This can
only postpone the problem. Eventually you'll be saddled with so many
points of failed understanding that "consensus by exhaustion" is the
only kind of consensus possible. That can never produce a good design.

> separate the naming roles of the current IPvN addresses, as is  

   I will not answer that, even for myself.

   It sounds like an easy question, but it isn't. As Pekka himself
noted, TCP doesn't need its own namespace to accomplish its current
functions: thus we're asked to agree to create a new namespace which
doesn't yet have any reason to exist. While I believe we will find
reasons, I'm quite nervous about starting the design without them.

> have;

   I do not believe we need to list "all" yet. I'm not sure it would
even help if we could. Architecture is about designing for _unknown_
problems.

> for example, I can easily count to up to six or seven different  

   I don't think we need to list even that many to decide it's worth
our while to sort out the proper roles.

> could agree on a general solution approach.

   Architecture doesn't start from a "problem definition" -- it starts
from a list of desires.

   The consensus I'm seeking is on a small part of a list of desires.
Do we want these things? We'll have plenty of opportunity to add to the
list later.

   Trying to "solve" how to satisfy the list every time we want to
add a new item will only serve to exhaust us all.

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 14 Dec 2006 13:29:16 +1300

I agree with all of this; instead of characterising the confusion,  
agree on the source of it and go from there.  We do, I think, agree  
that the confusion is there, and that naming conflation is the root  
cause of problem.

Andrew

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 14 Dec 2006 09:29:33 +0200

John,

In general I feel we had mostly terminology disagreements, partly  
reflecting that we apparently look at the problem from slightly  
different angles.  We also seem to be mostly over with the  
terminology issues.  I'd be happy with what Noel stated about the terms.

Disregarding the terminology, I think we are in pretty good overall  
agreement sans how to handle the "transport".  Hence, I'm focusing on  
that, but before I get to that, I need to do a small detour.

To start with, and as I have stated at least three times so far, if  
we think about our current global communications system as sets of  
components, we can see there three independently changing sets of  
components: "routers", "host os stacks", and "applications".  [Note  
that the structure is *economic*, not technical.  The sets of  
components have different purchasing cycles and lifetimes.]  Between  
the components, we have two relatively well defined and understood  
interfaces:

1. One between routers and stacks, i.e., sending IP packets over  
Ethernet, PPP, etc.

2. One between stacks and applications, i.e., the socket API and its  
equivalents.

These two interfaces are the ones that are hardest to change as  
changing them requires that more than one of the involved component  
sets are changed at the same time.  Changing the syntax of the  
interfaces is almost out of the question.  Changing semantics -- that  
we need to do, but we need to be pretty careful when doing so.

Now, architecturally, to implement the identifier / locator  
separation we seem to have two fundamentally different paths:

1. In what Noel calls the "jack up" approaches, we change the  
"routers".  Conversely, we change the semantics of what now are IP  
addresses to "identifiers" at *both* interfaces.  In this approach,  
what now are IP addresses will become "identifiers", both within the  
"stacks" and "applications".  In this model, "locators" are internal  
to the network, and only seen by (some) "routers".

2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change the  
"stacks"; perhaps not immediately but eventually.  Conversely, we  
change the semantics of what now are IP addresses so that they become  
"locators" at the "router/stack" interface and "identifiers" at the  
"stack/application" interface.  As a consequence, applications will  
deal with "identifiers" and routers will deal with "locators"; the  
"stack" will do the translation.

While writing this, I noticed that, at least in theory, we also have  
a third approach.  [But I am not aware of any viable solution  
proposals here.]

3. In the "apps" approaches we change the "apps"; not necessarily the  
apps themselves but e.g. resolution, libraries, etc.  Conversely, we  
change the semantics of what now are "IP addresses" so that they  
become "locators" at *both* of the interfaces.  The "apps layer" will  
do the translation, and "identifiers" are internal to the apps.   
[This approach also has problems related to e.g. TCP state during  
mobility events, so it may be impossible to do a clean-cut  
implementation based on this architectural approach.]

Four more notes before we get to the point:

1a.  It is also possible to implement the "jack up" mechanisms in the  
hosts, but that changes the underlying trust model and therefore  
security properties.  The consequences and implications -- think  
about them.

2a.  It is possible to implement the "shim" mechanisms in a separate  
box (proxy) in a way that structurally resembles the "jack up"  
mechanisms.  But, the trust model is slightly different than in a  
plain, "stack" based "shim" approach.

3a.  I have hard time imagining how to implement the "apps" approach  
in a proxy box, but intuitively I have the feeling that it should be  
doable.

4. Implication: From an implementation point of view, the difference  
between the "jack up" and "shim" approaches need not be that big.   
Both can be implemented either in some new "router" boxes or in the  
host os stacks, or in some combination thereof.  Perhaps even the  
"apps" approach can be implemented in that way.

Ergo: The differences are architectural, reflecting different  
architectural semantics and fundamentally different trust models!

Now we are finally done with our detour and I get to my point:

If you read carefully what I stated above, I did not need the word  
"transport", not even once.  And I did not try to avoid it -- it just  
wasn't needed.

t is pretty clear that somewhere within the "router layer" we will  
need "locators", aka routing names.  It is pretty clear that in the  
"application layer" we will need "identifiers", identifying entities  
that the apps are interested in.  [Whether the ids identify "hosts",  
"stacks", or other entities will need to be discussed, but that can  
be deferred.]  It is pretty clear that somewhere we will need to make  
a translation between them.

However, that translation can take place in at least four different  
locations:

1. In the routing system, resulting in "jack up".

2. In the stack as a "shim", with at least two potential choices for  
the location:

2a.  In the "internetworking" layer, somewhere near IPsec, similar to  
SHIM6 and HIP.

2b.  In the "transport" layer, similar to SCTP add IP.

3. In the "apps layer", e.g., in a library.

If we talk about the "transport" layer and "transport" names, that  
gives the implication that the "transport" needs stable, location- 
independent names.  I don't think that's the case.  Its the  
applications that have the need for such entity-referring location- 
independent stable names.  Hence, I prefer to consider the "upper  
names" aka "identifiers" as something that the applications, not the  
transport, are interested in.  From a theoretical point of view, it  
is an open question whether the "transport" should see them or not.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 14 Dec 2006 12:58:01 +0200

>> I'm afraid that we haven't received any kind of consensus on how  
>> to do that separation.
>
> (For example, in the MPI case a geographically based locator might  
> make sense, while for static networks a locator based on network  
> hierarchy is probably more appropriate, and these very different  
> choices will influence the type of locator, and maybe the type of  
> identifier, chosen.) So wouldn't the first step be the selection of  
> a means to identify the split being taken ?

I am not sure if I understand you correctly (e.g. I don't know what  
you refer to with "MPI"), but if I understand you correctly, to me  
your statement feels like that you would like to have multiple  
different locator spaces.  If so, as I have written before, I don't  
see any architectural reason why an id/loc split implementation  
couldn't include mechanisms for architected NATs and NATPs, thereby  
allowing different locators and routing mechanisms at different areas  
in the net.

On the other hand, I would see there tremendous social utility value  
if we managed to move back to a single, global identifier space.

>> To further clarify: in this case, I find it very hard to produce  
>> an exact definition of all the architecturally inclined problems  
>> that we have; for example, I can easily count to up to six or  
>> seven different problems, all partially caused by the present role  
>> confounding.
>
> This indicates to me that, again, "one size fits all" is probably  
> not realistic.

You are right that it may be unrealistic to solve all of the related  
problems, or even my "six or seven" problems, at a single shot.   
OTOH, I have practical reasons to believe that all of my "six or  
seven" problems could be solved with a public-keys-based identity- 
layer clearly more elegantly (and with less complexity) than we are  
able to do today.

[For reference, the problems I've considered are the following:   
scalability of the routing system; combined host mobility and multi- 
homing; fast and vertical handovers with re-authentication;  
architected NAT, IPv4/v6 interop, etc.; some forms of bad traffic  
(DDoS); sub-network naming and mobility; and flexible and secure  
application naming.]

--Pekka Nikander

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 14 Dec 2006 09:34:36 -0500

Dear Pekka;

On Dec 14, 2006, at 5:58 AM, Pekka Nikander wrote:

>> identifier, chosen.) So wouldn't the first step be the selection  
>> of a means to identify the split being taken ?
>
> allowing different locators and routing mechanisms at different  
> areas in the net.
>
> On the other hand, I would see there tremendous social utility  
> value if we managed to move back to a single, global identifier space.
>

Mobile Platform Internet - Autonomous Systems on wings (or wheels  
or...). Some documentation is at
http://www.multicasttech.com/mpi/

(Think of a 787 with hundreds of internal computers, 3 or more  
internal address blocks, and (potentially) dozens of IP
interfaces, such as 802.16 to the ground, 802.11 to the tower, and  
several satellite links, and a strong need to multihome to all of  
these.)

In the MPI case, I think that a geographically based locater may make  
sense. Suppose that you know that I was at this location, at
this time. That would in principal allow you to determine which  
Satellite footprints, 802.16 nets, and 802.11 ATC links I could be  
part of at that time. If, say, there was a set of gateways for  
satellite uplinks, you would know which gateway to forward to. If you  
were sending ATC information, you would (in principal) know whether  
to send to the satellite or to the local tower.

(In a sense, this discussion is more about aggregation and  
scalability than routing. We know how to route to aircraft; BGP can  
do it. I think that the real question is, how do we do it in a way  
that doesn't require global visibility of the platform.)

Also note that in this mobile case, you need to include a time tag,  
as the locators will change with time and old locators will require  
different routing. (Locators might change significantly during a long  
tcp session, for example.)

Of course, in the static case, my rack in an exchange or co-lo may be  
less than one meter from your rack but in a totally different place  
in network topology, and I doubt that pure geography is worth much.

>>> seven different problems, all partially caused by the present  
>>> role confounding.
>>
> You are right that it may be unrealistic to solve all of the  
> related problems, or even my "six or seven" problems, at a single  
> shot.  OTOH, I have practical reasons to believe that all of my  
> "six or seven" problems could be solved with a public-keys-based  
> identity-layer clearly more elegantly (and with less complexity)  
> than we are able to do today.
>

Is there a write-up of this ?

Regards
Marshall

---

From: Peter Sherbin <[email-masked]>
Date: Thu, 14 Dec 2006 08:08:58 -0800 (PST)

>applications will deal with "identifiers" and routers will deal with "locators"

Whout it be more clear to use "names" for "identifiers" and "addresses" for
"locators"?

Thanks,

Peter

____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Dec 2006 14:55:22 +0100

Interesting thread you started there... just one point I think
needs clarifying for the record:

Noel Chiappa wrote:
...

> that's not much use if many of the people trying to talk to you haven't.

SHIM6 is specifically designed so that a shimmed host can talk to an unshimmed
host (i.e., the shim becomes a no-op) and no upper layer protocol needs to be
touched (i.e., the socket API continues to work). No router needs to be touched,
except possibly for the exit router selection problem.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Dec 2006 15:14:24 +0100

> http://www.multicasttech.com/mpi/

Oh boy. MPI means something very different to many networking people:
Message Passing Interface. This is very widely used in high performance
cluster computing, with multiple implementations.
See http://www.mpi-forum.org or http://www.open-mpi.org/ .

This is a very confusing acronym clash.

    Brian

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 15 Dec 2006 10:29:51 -0500

Dear Brian;

> This is a very confusing acronym clash.

I suspect that every 3 letter acronym has clashes - I found the  
Meeting Professionals International and the Master
Painters Institute, but not this one.

Even with 4 letters, there are overlaps. For example, there is

IETF (International Engineering & Technology Fair), a bi-annual  
exhibition organized by Confederation of Indian Industry (CII) since  
1975

and (my favorite, for some reason) the

International Essential Tremor Foundation (IETF).

At any rate, I don't think that the people thinking about Internet  
connections to these mobile platforms are
wedded to the name, and I would welcome alternative suggestions.

Regards
Marshall

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 16 Dec 2006 11:06:23 +0200

Dear Marshall,

> different routing. (Locators might change significantly during a  
> long tcp session, for example.)

An interesting observation!  But I have never thought that we'd try  
to address fast mobility at IP layer.  Future location prediction is  
nothing new in mobile radio networks, of course.  For example,  
complex MIMO (multiple in, multiple out) antenna systems do it all  
the time to get the interference patterns right.

>> scalability of the routing system; combined host mobility and  
>> multi-homing; fast and vertical handovers with re-authentication;  

Not a single one, but see below.

As you may know, most of our practical work in this are was done with  
HIP, but mostly be applied to many other architectural options, too.   
Considering the issues, I am not aware of any papers that would  
directly address routing and forwarding with HIP -- we've generally  
assumed that since it allows the locators to be rewritten in the fly  
it would do as well as any id/loc split mechanism.

For some considerations and comparison to legacy NAT, see [1].   
Combined mobility and multi-homing is described in [2], [3] and [4].   
For fast handovers, see e.g. [5], for vertical handovers, e.g. [6]; I  
haven't been that much involved in that work and don't know all the  
details.  Architected NAT and IPv4/IPv6 interoperability is discussed  
in [1], [3], [7], and [8].  DoS is addressed in RFC 4423, DDoS in [9]  
and [10].  Sub-network mobility is still work in progress and I am  
not aware of publications, but there are submitted papers and we have  
a working prototype.  Application naming is discussed in [11].

--Pekka Nikander

[1] Jukka Ylitalo, Patrik Salmela, and Hannes Tschofenig, "SPINAT:  
Integrating IPsec into Overlay Routing", in Proc. of the First  
International Conference on Security and Privacy for Emerging Areas  
in Communication Networks (SecureComm'05), Athens, Greece, September  
5-9, 2005. http://users.tkk.fi/~jylitalo/publications/SecureComm05- 
Ylitalo-et-al.pdf

[2] Pekka Nikander, Jukka Ylitalo, and Jorma Wall, "Integrating  
Security, Mobility, and Multi-Homing in a HIP Way", in Proc. of  
Network and Distributed Systems Security Symposium (NDSS'03), pp.  
87-99, ISBN 1-891562-16-9, Internet Society, San Diego, CA, US,  
February 6-7, 2003.
http://www.tml.tkk.fi/~pnr/publications/NDSS03-Nikander-et-al.pdf

[3] Jukka Ylitalo, Pekka Nikander, "A new Name Space for End-Points:  
Implementing secure Mobility and Multi-homing across the two versions  
of IP," in Proceedings of the Fifth European Wireless Conference,  
Mobile and Wireless Systems beyond 3G (EW2004), pp. 435-441,  
Barcelona, Spain, February 24-27, 2004.
http://www.tml.tkk.fi/~pnr/publications/ew2004.pdf

[4] T. Henderson (ed), "End-Host Mobility and Multihoming with the  
Host Identity Protocol", ID, IETF.
http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-04.txt

[5] Jari Arkko and Pekka Nikander, "Fast network attachment",  
WO2006018045, EPO.

[6] Jokela P., Wall J., Melen J., Rinta-aho T., Kauppinen T.,  
Mahkonen H., Jokikyyny T.,
Kuparinen M., Korhonen J., "Handover Performance with HIP and MIPv6",  
International
Symposium on Wireless Communication Systems, in Proceedings of ISWCS'04.

[7] Hannes Tschofenig, Andrei Gurtov, Jukka Ylitalo, Aarthi  
Nagarajan, and Murugaraj Shanmugam, "Traversing Middleboxes with the  
Host Identity Protocol", in Proc. of the Tenth Australasian  
Conference on Information Security and Privacy (ACISP'05), Brisbane,  
Australia, July 4-6, 2005.
http://users.tkk.fi/~jylitalo/publications/ACISP2005-Tschofenig-et- 
al.pdf

[8] Petri Jokela, Pekka Nikander, Jan Melen, Jukka Ylitalo and Jorma  
Wall, "Host Identity Protocol: Achieving IPv4 - IPv6 handovers  
without tunneling", in Proceedings of Evolute workshop 2003: "Beyond  
3G Evolution of Systems and Services", University of Surrey,  
Guildford, UK, November 10, 2003.
http://www.tml.tkk.fi/~pnr/publications/evolute2003.pdf

[9] Pekka Nikander, Jari Arkko, and Börje Ohlman, Host Identity  
Indirection Infrastructure (Hi3)," in Proceedings of The Second  
Swedish National Computer Networking Workshop 2004 (SNCNW2004),  
Karlstad University, Karlstad, Sweden, Nov 23-24, 2004.
http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf

[10] Andrei Gurtov, Dmitry Korzun, Pekka Nikander, "Hi3: An Efficient  
and Secure Networking Architecture for Mobile Hosts," Technical  
report 2005-2, Helsinki Institute for Information Technology, June 2005.
http://www.tml.tkk.fi/~pnr/publications/HIIT_gurtov_hi3_report_2005.pdf

[11] Teemu Koponen, Andrei Gurtov, Pekka Nikander, "Application  
mobility with Host Identity Protocol," Extended Abstract in Proc. of  
NDSS Wireless and Mobile Security Workshop, San Diego, CA, USA,  
February 2005.

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 09:42:52 -0500

> If you do that, you lose the benefit of in-band signalling, 
> and are more likely to have the routing and transport layers 
> disagree about what the optimum path is.

On the contrary is my view.  The capability to use in-band-signaling to
identify best multiple paths is something that should be made easier
with the new model.  I also believe one of the inputs to the forwarding
path is information from end nodes using in-band-signaling  but lets not
go down the QoS path for now.  But QoS is a part of what needs some
thought for a new model.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 09:50:48 -0500

We need a transport layer Pekka or call it what you want but it must
exist and its  between the internet-networking layer and the apps layer.
Unless I misundertand your input?  Also we are not done we have no way
to gage consensus and until we have that saying we are done is not fair.
Someone needs to write all this down in a draft at minimum.

/jim 

> Sent: Thursday, December 14, 2006 2:30 AM
> To: John Leslie
> Subject: [arch-d] On the role of "transport" (was Re: Do we 
> have "partialconsensus"?)
> 
> John,
> 
> In general I feel we had mostly terminology disagreements, 
> partly reflecting that we apparently look at the problem from 
> slightly different angles.  We also seem to be mostly over 
> with the terminology issues.  I'd be happy with what Noel 
> stated about the terms.
> 
> Disregarding the terminology, I think we are in pretty good 
> overall agreement sans how to handle the "transport".  Hence, 
> I'm focusing on that, but before I get to that, I need to do 
> a small detour.
> 
> 
> To start with, and as I have stated at least three times so 
> far, if we think about our current global communications 
> system as sets of components, we can see there three 
> independently changing sets of
> components: "routers", "host os stacks", and "applications".  
> [Note that the structure is *economic*, not technical.  The 
> sets of components have different purchasing cycles and 
> lifetimes.]  Between the components, we have two relatively 
> well defined and understood
> interfaces:
> 
> 1. One between routers and stacks, i.e., sending IP packets 
> over Ethernet, PPP, etc.
> 
> 2. One between stacks and applications, i.e., the socket API 
> and its equivalents.
> 
> These two interfaces are the ones that are hardest to change 
> as changing them requires that more than one of the involved 
> component sets are changed at the same time.  Changing the 
> syntax of the interfaces is almost out of the question.  
> Changing semantics -- that we need to do, but we need to be 
> pretty careful when doing so.
> 
> 
> "routers".  Conversely, we change the semantics of what now 
> are IP addresses to "identifiers" at *both* interfaces.  In 
> this approach, what now are IP addresses will become 
> "identifiers", both within the "stacks" and "applications".  
> In this model, "locators" are internal to the network, and 
> only seen by (some) "routers".
> 
> 2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change 
> the "stacks"; perhaps not immediately but eventually.  
> Conversely, we change the semantics of what now are IP 
> addresses so that they become "locators" at the 
> "router/stack" interface and "identifiers" at the 
> "stack/application" interface.  As a consequence, 
> applications will deal with "identifiers" and routers will 
> deal with "locators"; the "stack" will do the translation.
> 
> While writing this, I noticed that, at least in theory, we 
> also have a third approach.  [But I am not aware of any 
> viable solution proposals here.]
> 
> 3. In the "apps" approaches we change the "apps"; not 
> necessarily the apps themselves but e.g. resolution, 
> libraries, etc.  Conversely, we change the semantics of what 
> now are "IP addresses" so that they become "locators" at 
> *both* of the interfaces.  The "apps layer" will  
> [This approach also has problems related to e.g. TCP state 
> during mobility events, so it may be impossible to do a 
> clean-cut implementation based on this architectural approach.]
> 
> 1a.  It is also possible to implement the "jack up" 
> mechanisms in the hosts, but that changes the underlying 
> trust model and therefore security properties.  The 
> consequences and implications -- think about them.
> 
> 2a.  It is possible to implement the "shim" mechanisms in a 
> separate box (proxy) in a way that structurally resembles the 
> "jack up"  
> mechanisms.  But, the trust model is slightly different than 
> in a plain, "stack" based "shim" approach.
> 
> 3a.  I have hard time imagining how to implement the "apps" 
> approach in a proxy box, but intuitively I have the feeling 
> that it should be doable.
> 
> Both can be implemented either in some new "router" boxes or 
> in the host os stacks, or in some combination thereof.  
> Perhaps even the "apps" approach can be implemented in that way.
> 
> If you read carefully what I stated above, I did not need the 
> word "transport", not even once.  And I did not try to avoid 
> it -- it just wasn't needed.
> 
> t is pretty clear that somewhere within the "router layer" we 
> will need "locators", aka routing names.  It is pretty clear 
> that in the "application layer" we will need "identifiers", 
> identifying entities that the apps are interested in.  
> [Whether the ids identify "hosts", "stacks", or other 
> entities will need to be discussed, but that can be 
> deferred.]  It is pretty clear that somewhere we will need to 
> make a translation between them.
> 
> 2. In the stack as a "shim", with at least two potential 
> choices for the location:
> 
> If we talk about the "transport" layer and "transport" names, 
> that gives the implication that the "transport" needs stable, 
> location- independent names.  I don't think that's the case.  
> Its the applications that have the need for such 
> entity-referring location- independent stable names.  Hence, 
> I prefer to consider the "upper names" aka "identifiers" as 
> something that the applications, not the transport, are 
> interested in.  From a theoretical point of view, it is an 
> open question whether the "transport" should see them or not.
> 
> --Pekka Nikander
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 09:54:08 -0500

MPI is a message passing interface and used widely.
/jim 

> Sent: Thursday, December 14, 2006 5:58 AM
> To: Marshall Eubanks
> Subject: Re: [arch-d] Do we have "partial consensus"?
> 
> confounded 
> > identifier, chosen.) So wouldn't the first step be the 
> selection of a 
> > means to identify the split being taken ?
> 
> I am not sure if I understand you correctly (e.g. I don't 
> know what you refer to with "MPI"), but if I understand you 
> correctly, to me your statement feels like that you would 
> like to have multiple different locator spaces.  If so, as I 
> have written before, I don't see any architectural reason why 
> an id/loc split implementation couldn't include mechanisms 
> for architected NATs and NATPs, thereby allowing different 
> locators and routing mechanisms at different areas in the net.
> 
> On the other hand, I would see there tremendous social 
> utility value if we managed to move back to a single, global 
> identifier space.
> 
> OTOH, I have practical reasons to believe that all of my "six 
> or seven" problems could be solved with a public-keys-based 
> identity- layer clearly more elegantly (and with less 
> complexity) than we are able to do today.
> 
> multi- homing; fast and vertical handovers with 
> re-authentication; architected NAT, IPv4/v6 interop, etc.; 
> some forms of bad traffic (DDoS); sub-network naming and 
> mobility; and flexible and secure application naming.]
> 
> --Pekka Nikander
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 09:55:06 -0500

Nevermind that is the MPI below.  I thought reference was to accessing
the name space for a new model.

/jim 

> From: Marshall Eubanks [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 9:35 AM
> To: Pekka Nikander
> >>> two distinct name spaces.  The "identifier" name space will be 
> >>> mainly used by applications and the "locator" name space 
> by routing 
> >>> and forwarding.
> >>>
> utility value

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 09:57:22 -0500

Yes and it confused me.  We are going to need a doc soon so we all have
common understanding of terminology e.g. MIP, Jack-Up, Name-Space,
Identifier et al.
/jim 

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Friday, December 15, 2006 9:14 AM
> To: Marshall Eubanks
> > or...). Some documentation is at http://www.multicasttech.com/mpi/
> 
> Message Passing Interface. This is very widely used in high 
> performance cluster computing, with multiple implementations.

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 17 Dec 2006 20:34:49 +0200

Jim,

I agree that we need a transport layer.

What I don't know is whether we need explicit transport names, and if  
we do, whether they should be locators or identifiers.  (Remember  
that right now we do not have explicit transport names but they are  
created by combining IP addresses and port numbers.)

What I outlined below were three architectural choices of *where* to  
do an identifier locator separation.  One of those (#3) is ABOVE  
transport.  In that case the names that transport sees will be  
locators, not identifiers.

Based on that, I objected to John's use of "transport names" as a  
generic name for upper layer identifiers.  For example, in the SHIM6  
case transport sees identifiers, yes.   But in some other choices it  
is only above transport that locators get mapped to identifiers and  
vice versa.

Based on that, I'd consider "application names" a better choice for  
ULIDs than "transport names".  However, perhaps the best choice would  
be "identifier"; or "ULID", as used in SHIM6.

--Pekka

---

From: David Barak <[email-masked]>
Date: Sun, 17 Dec 2006 13:09:41 -0800 (PST)

--- "Bound, Jim" <[email-masked]> wrote:

> signalling, 
> with the new model. 

Only a transport-layer-aware device can perform
transport-layer functions.  Currently, selection of
the best path is done below the transport layer, at
the same layer which actually forwards packets.  

If the layers above the routing layer can perform path
selection, then there either needs to be a layering
violation (i.e. multiple layers required to be in
synch at all times), or every hop must be a
transport-layer-device, which means that there is no
concept of end-to-end forwarding (see X.25), or there
needs to be a huge amount of state held on all end
hosts which are the transport-aware devices.

None of those are improvements on the existing in-band
signalling (i.e. routing happens over data plane) from
a scalability or simplicity approach.

-David

David Barak

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 22:02:56 -0500

Pekka, 

> What I don't know is whether we need explicit transport 
> names, and if we do, whether they should be locators or 
> identifiers.  (Remember that right now we do not have 
> explicit transport names but they are created by combining IP 
> addresses and port numbers.)

Yes I know I am taking a purist *new* approach and assuming transport
has nothing to do with the internetworking layer at all other than the
transport dst identifier is a hint or vector to what locators or
routing-namespace-identifiers are used to deliver the packet.  Talking
with a few offline on this to see if I have gone to far to remove all
notion of routing, path, and all the other words we use today as
nomenclature.  So will come back to this later.  The transport layer to
me in a **new** model participates in notification of problems to
support applications and to be the front end across a network for those
applications.  I am being very abstract at this point.

> 
> What I outlined below were three architectural choices of 
> *where* to do an identifier locator separation.  One of those 
> (#3) is ABOVE transport.  In that case the names that 
> transport sees will be locators, not identifiers.

But in my abstraction above there is no reason for locators is where I
am headed that is the layer below.

> 
> Based on that, I objected to John's use of "transport names" 
> as a generic name for upper layer identifiers.  For example, 
> in the SHIM6  
> is only above transport that locators get mapped to 
> identifiers and vice versa.

I am in agreement with John I believe on this principle.  Whether
locators or routing-namespace-identifiers below and different than the
transport are needed is my question at least for me right now.  

> 
> Based on that, I'd consider "application names" a better 
> choice for ULIDs than "transport names".  However, perhaps 
> the best choice would be "identifier"; or "ULID", as used in SHIM6.

I think your right above and I do like the SHIM6 model of ULID.  But the
selection of locators in SHIM6 with a **new** model (Noel, John L, you,
Tony L, Peter S. and others) may not be necessary???????  I could be off
the deep end here totally removing that from transport but I just want
to think about it and run a bit :--).

/jim

> >> Subject: [arch-d] On the role of "transport" (was Re: Do we have 
> >> "partialconsensus"?)
> >>
> >> John,
> >>
> >> [Note that the structure is *economic*, not technical.  
> The sets of 
> >> interfaces is almost out of the question.
> >> Changing semantics -- that we need to do, but we need to be pretty 
> >> careful when doing so.
> >>
> >>
> >> "stacks" and "applications".
> >> "stacks"; perhaps not immediately but eventually.
> addresses so 
> >> that they become "locators" at the "router/stack" interface and 
> >> "identifiers" at the "stack/application" interface.  As a 
> >> consequence, applications will deal with "identifiers" and routers 
> >> will deal with "locators"; the "stack" will do the translation.
> >>
> also have 
> necessarily the 
> >> become "locators" at
> >> *both* of the interfaces.  The "apps layer" will do the 
> translation, 
> >> and "identifiers" are internal to the apps.
> trust model 
> >> and therefore security properties.  The consequences and 
> implications 
> >> -- think about them.
> >>
> >> approach in a proxy box, but intuitively I have the 
> feeling that it 
> >> should be doable.
> >>
> >> host os stacks, or in some combination thereof.
> >> that the apps are interested in.
> entities will 
> >> need to be discussed, but that can be deferred.]  It is 
> pretty clear 
> >> that somewhere we will need to make a translation between them.
> >>
> choices for 
> >> gives the implication that the "transport" needs stable,
> >> Its the applications that have the need for such entity-referring 
> >> location- independent stable names.  Hence, I prefer to 
> consider the 
> >> "upper names" aka "identifiers" as something that the 
> applications, 
> >> not the transport, are interested in.  From a theoretical point of 
> >> view, it is an open question whether the "transport" 
> should see them 
> >> or not.
> >>
> >> --Pekka Nikander
> >>
> >>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 22:05:44 -0500

I think you have captured an important point but the reality is today
the layers are really virtual and the "violation" you speak of is in
most code I know of on the street and indirectly in specs.  

How do we want the stack to look?  Like an hour glass, wine glass, or
bulge in the center?  I think this is important to think about if any
core architecture princples are to survive for 100 years.

/jim 

> From: David Barak [mailto:[email-masked]] 
> Sent: Sunday, December 17, 2006 4:10 PM
> To: Bound, Jim; [email-masked]
> Subject: RE: [arch-d] Do we have "partial consensus"?
> 
> 
> > On the contrary is my view.  The capability to use 
> in-band-signaling 
> > to identify best multiple paths is something that should be made 
> > easier with the new model.
> 
> transport-layer functions.  Currently, selection of the best 
> path is done below the transport layer, at the same layer 
> which actually forwards packets.  
> 
> selection, then there either needs to be a layering violation 
> (i.e. multiple layers required to be in synch at all times), 
> or every hop must be a transport-layer-device, which means 
> that there is no concept of end-to-end forwarding (see X.25), 
> or there needs to be a huge amount of state held on all end 
> signalling (i.e. routing happens over data plane) from a 
> scalability or simplicity approach.
> 
> -David
> 
> David Barak
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
>

---

From: Joe Touch <[email-masked]>
Date: Sun, 17 Dec 2006 21:38:42 -0800

Pekka Nikander wrote:
> What I don't know is whether we need explicit transport names, and if we
> do, whether they should be locators or identifiers.  (Remember that
> right now we do not have explicit transport names but they are created
> by combining IP addresses and port numbers.)

That combination is used for two things:

	transport names _after_ a connection is established

	service names _before_ a connection is established

(the two overlap, e.g., in UDP).

The point is there's another level of naming here that's orthogonal and
could/should be split out. See draft-touch-tcp-portnames (soon to be
reissued with updates).

Joe

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 18 Dec 2006 08:39:58 +0200

Jim,

[Cutting and rearranging the old content a little bit, in order to  
help readability.]

On 18 Dec 2006, at 05:02, Bound, Jim wrote:
> ... I am taking a purist *new* approach and assuming transport has  
> nothing to do with the internetworking layer at all other than the  
> routing-namespace-identifiers are used to deliver the packet. ...

To me, this sounds like my "architectural approach #2":

>>>> "stacks"; perhaps not immediately but eventually.  Conversely,  
>>>> we change the semantics of what now are IP addresses so that  
>>>> they become "locators" at the "router/stack" interface and   
>>>> consequence, applications will deal with "identifiers" and  
>>>> routers will deal with "locators"; the "stack" will do the  
>>>> translation.

What I was trying to say with this approach (#2) was the following:

- change the host stack implementations (but during transition the  
same functionality may happen elsewhere)

- in the internetworking layer, use locators aka routing-namespace- 
identifiers

- in the transport layer, use identifiers aka ULIDs

Now, this happen also to be my favourite approach; i.e, we seem to  
agree.  BUT, I am simultaneously trying to understand the pros and  
cons of the other two approaches (#1 and #3).

> Talking with a few offline on this to see if I have gone to far to  
> remove all notion of routing, path, and all the other words we use  
> today as nomenclature.   So will come back to this later.

Personally, I don't believe you've gone too far, at least when  
speaking architecturally.  However, once we'll get back to  
engineering, we'll probably need some terms for those or similar  
functions again.

> But in my abstraction above there is no reason for locators is  
> where I am headed that is the layer below.

I think I understand: no locators at transport but only in a layer  
below.  BUT, there are some applications people that would like to do  
the id/loc split above transport.  I think it would be good to  
understand the merits and drawbacks of that approach, too.

>> Based on that, I'd consider "application names" a better choice  
>> for ULIDs than "transport names".  However, perhaps the best  
>> choice would be "identifier"; or "ULID", as used in SHIM6.
>
> I think your right above and I do like the SHIM6 model of ULID.

So, at least you and I seem to be converging to using the term "ULID"  
for the names that John used the term "transport name" for, in his  
original consensus call.

> But the selection of locators in SHIM6 with a **new** model (Noel,  
> John L, you, Tony L, Peter S. and others) may not be necessary???????

I am not sure what you are saying, but if we do the identifier  
locator separation, some function somewhere must select what locator  
to use for an outgoing packet.  [Traditionally, the choice was made  
in the application code, either in the application proper or in some  
library.]  What I think we have mostly worked out so far are the  
architectural options of where to do that choice in the new world.   
In some new models, the selection function is located elsewhere than  
where it is in SHIM6 and HIP.

Once we understand better the options or approaches of *where* to do  
the locator selection in an architectural sense, we'll still have  
lots to do:  how to select a good locator, what kind of  
infrastructure (if any) is needed to support that selection, what are  
the new packet structures and headers (if any), how the locator  
selection interacts with transports, etc.

Considering the details, we've so far worked out how to do the  
identifier locator separation with HIP and SHIM6.  Of HIP we have had  
working experimental implementations for some 3-5 years now, but  
still too little practical experience on e.g. how it works with  
existing congestion control.  AFAIK, the first SHIM6 implementations  
should be ready very soon.  Unfortunately, I am ignorant of the  
implementation and experimentation situation of Noel's "jack  
up" (approach #1) or the recently recognised "above  
transport" (approach #3) approaches.

> I could be off the deep end here totally removing that from  
> transport but I just want to think about it and run a bit :--).

One of the areas where I notice myself being somewhat weak is  
understanding all the implications of id/loc split to the traditional  
transport functions, i.e. e2e error control and congestion control.   
I once thought I understood the case, and recorded my view in a  
position paper [1].  But now I'm puzzled, again.

[1] Pekka Nikander, "ACCCoRD: Architectural Considerations on the  
placement of Congestion Control Routines and Data -- Extended  
Abstract," in Proceedings of High Speed Networking Workshop,  
Budabest, Hungary, May 17-18, 2004, Budabest University of Technology  
and Economics.
http://www.tml.tkk.fi/~pnr/publications/hsn2004.pdf

--Pekka Nikander

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 18 Dec 2006 06:10:45 -0800 (PST)

> We are going to need a doc soon so we all have common understanding of terminology
e.g. MIP, Jack-Up, Name-Space, Identifier et al.

Would it help to have basic terms defined: application, port, system, transport,
network, datalink, node, interface, name, identifier, address, locator,
topology,..., a sort of RFC 2119 for architecture? 

Thanks,

Peter

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 18 Dec 2006 10:01:22 -0500

> > We are going to need a doc soon so we all have common 
> understanding of 
> > terminology
> Would it help to have basic terms defined: application, port, 
> system, transport, network, datalink, node, interface, name, 
> identifier, address, locator, topology,..., a sort of RFC 
> 2119 for architecture? 

Yes but some of these I hope remain the same from the many specs in the
IETF now. Its the new ones that are most important.  And identifier is
IMHO brand new for this work though HIP is good reference to develop
that nomenclature both semantics and syntax.

I like the idea of the new needing a 2119.

NB: One suggestion - please for the new no ASN1 or XML encodings for now
:--)  Just simple plain normal text description.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 18 Dec 2006 09:57:46 -0500

Pekka, 

> [Cutting and rearranging the old content a little bit, in 
> order to help readability.]
> 

OK will double check but will take your word for it in my response.  I
have already had bugs in my readings on this list and other work need to
slow down.

> Conversely, we 
> >>>> change the semantics of what now are IP addresses so that
> - change the host stack implementations (but during 
> transition the same functionality may happen elsewhere)

Yes.

> 
> - in the internetworking layer, use locators aka 
> routing-namespace- identifiers

Yes.

> - in the transport layer, use identifiers aka ULIDs

Yes.

> 
> Now, this happen also to be my favourite approach; i.e, we 
> seem to agree.  BUT, I am simultaneously trying to understand 
> the pros and cons of the other two approaches (#1 and #3).

Absolutely and due dilligence for sure.

> Personally, I don't believe you've gone too far, at least 
> when speaking architecturally.  However, once we'll get back 
> to engineering, we'll probably need some terms for those or 
> similar functions again.

ACK.

> I think I understand: no locators at transport but only in a 
> layer below.  BUT, there are some applications people that 
> would like to do the id/loc split above transport.  I think 
> it would be good to understand the merits and drawbacks of 
> that approach, too.

Agreed that there will be exceptions.  What I think we will need in this
case and must permit is a fast path like raw sockets API to the
internetworking-layer.  The nasty part of this for deployment as you
know the bindings, PRUs, et al in most stack implementatons integrate
quite tightly-coupled the transport with API bindings and that gets to
you point about engineering above for this issue too.  But my view is
many product vendors will need direct access to the
internetworking-layer.  For true uses of locators in transport layer I
think there should be justified use cases and I would wager a small
amount most of that can be done via raw sockets (note just using sockets
because it is widely well understood there are many APIs and DLLs etc.
that do this I realize).

> choice for 

> > I think your right above and I do like the SHIM6 model of ULID.

I will follow yours and others lead on how we determine namespace not my
forte but I do understand the pain if we implement them wrong in the
network subsystem for an internetworking-layer esp. for forwarding.

> for the names that John used the term "transport name" for, 
> in his original consensus call.

I am ok either way as long as we all agree what it means.  ULID is used
by SHIM6 and that is pretty good.  But ULID might be to generic.  What I
mean by that is suppose we need identifiers above the *new* transport we
might want to attach specific layer syntax to the identifiers now so we
can expand them tomorrow.  ULID is pretty generic?  Just a thought.  In
that case John's approach could be the right one?

> I am not sure what you are saying, but if we do the 
> identifier locator separation, some function somewhere must 
> select what locator to use for an outgoing packet.  
> [Traditionally, the choice was made in the application code, 
> either in the application proper or in some library.]  What I 
> think we have mostly worked out so far are the  
> In some new models, the selection function is located 
> elsewhere than where it is in SHIM6 and HIP.

The selection of path is based on the apps dst identifier which does not
have to be a locator or better yet a routing-namespace-identifier.  For
transition we could easily have a branch condition in the library of the
app until the new model is implemented cleanly (note this is how I would
move apps to SHIM6 and more importantly today to SCTP :--)).  I am
speaking from the blank page here and as you know I am the last one to
ever support anything that breaks stuff in the market but if we are to
have this blank page discussion for "transport" lets have it totally.

> 
> Once we understand better the options or approaches of 
> *where* to do the locator selection in an architectural 
> sense, we'll still have lots to do:  how to select a good 
> locator, what kind of infrastructure (if any) is needed to 
> support that selection, what are the new packet structures 
> and headers (if any), how the locator selection interacts 
> with transports, etc.

Absolutely.

> 
> Considering the details, we've so far worked out how to do 
> the identifier locator separation with HIP and SHIM6.  Of HIP 
> we have had working experimental implementations for some 3-5 
> years now, but still too little practical experience on e.g. 
> how it works with existing congestion control.  AFAIK, the 
> first SHIM6 implementations should be ready very soon.  
> Unfortunately, I am ignorant of the implementation and 
> experimentation situation of Noel's "jack up" (approach #1) 
> or the recently recognised "above transport" (approach #3) approaches.

Understood and the jack-up though I agree is still fuzzy but we need to
go there. This work on this list and if we get enough momentum can be
the catalyst for more implementations three we have seen happen like
this (and there are more) are SCTP, IPv6 Parts, and RDMA.  So a good
list, friendly debate, smart people and understanding the ground rules
in this community bringing all to same mission is very powerful aspect
of the IETF.

> transport 
> > but I just want to think about it and run a bit :--).
> 
> I once thought I understood the case, and recorded my view in 
> a position paper [1].  But now I'm puzzled, again.

I believe most algorithms will remain the same (but we need more than we
have today e.g. Satcom lossy links, nodes seamless mobile where QoS
changes, etc), but the key is the routing-namespace-identifiers also
have to work with functions like heartbeat packets, PTMU, et al.

> 
> [1] Pekka Nikander, "ACCCoRD: Architectural Considerations on 
> the placement of Congestion Control Routines and Data -- 
> Extended Abstract," in Proceedings of High Speed Networking 
> Workshop, Budabest, Hungary, May 17-18, 2004, Budabest 
> University of Technology and Economics.

I pulled it and will read as I can.  The only reason I am keeping up now
is because things are slowing down for the holiday season and cheer
:--).

/jim

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 18 Dec 2006 12:09:27 -0500

Dear Pekka;

On Dec 16, 2006, at 4:06 AM, Pekka Nikander wrote:

> Dear Marshall,
>
>> Also note that in this mobile case, you need to include a time  
>> tag, as the locators will change with time and old locators will  
>> require different routing. (Locators might change significantly  
>> during a long tcp session, for example.)
>
> to address fast mobility at IP layer.  Future location

I would define "fast mobility" as something that is comparable to or  
shorter than the routing convergence time, i.e., order seconds
or less.

> prediction is nothing new in mobile radio networks, of course.  For  
> example, complex MIMO (multiple in, multiple out) antenna systems  
> do it all the time to get the interference patterns right.

Yes, and that is truly fast mobility. One of the characteristics of  
large platform mobility is that, on the time scale of
routing convergence, they don't move fast (i.e., convergence times  
are typically < mobility time scale). I would agree that
in the case of truly fast mobility, things should be addressed at a  
lower level or by more specialized solutions.

> Not a single one, but see below.

Thank you for this thorough response.

Regards
Marshall

> As you may know, most of our practical work in this are was done  
> with HIP, but mostly be applied to many other architectural  
> options, too.  Considering the issues, I am not aware of any papers  
> that would directly address routing and forwarding with HIP --  
> we've generally assumed that since it allows the locators to be  
> rewritten in the fly it would do as well as any id/loc split  
> mechanism.
>
> Combined mobility and multi-homing is described in [2], [3] and  
> [4].  For fast handovers, see e.g. [5], for vertical handovers,  
> e.g. [6]; I haven't been that much involved in that work and don't  
> know all the details.  Architected NAT and IPv4/IPv6  
> interoperability is discussed in [1], [3], [7], and [8].  DoS is  
> addressed in RFC 4423, DDoS in [9] and [10].  Sub-network mobility  
> is still work in progress and I am not aware of publications, but  
> there are submitted papers and we have a working prototype.   
> Application naming is discussed in [11].
>
> --Pekka Nikander
>
> in Communication Networks (SecureComm'05), Athens, Greece,  
> September 5-9, 2005. http://users.tkk.fi/~jylitalo/publications/ 
> SecureComm05-Ylitalo-et-al.pdf
>
> [3] Jukka Ylitalo, Pekka Nikander, "A new Name Space for End- 
> Points: Implementing secure Mobility and Multi-homing across the  
> two versions of IP," in Proceedings of the Fifth European Wireless  
> Conference, Mobile and Wireless Systems beyond 3G (EW2004), pp.  
> 435-441, Barcelona, Spain, February 24-27, 2004.
> Kuparinen M., Korhonen J., "Handover Performance with HIP and  
> MIPv6", International
> Nagarajan, and Murugaraj Shanmugam, "Traversing Middleboxes with  
> the Host Identity Protocol", in Proc. of the Tenth Australasian  
> Conference on Information Security and Privacy (ACISP'05),  
> Brisbane, Australia, July 4-6, 2005.
> [8] Petri Jokela, Pekka Nikander, Jan Melen, Jukka Ylitalo and  
> Jorma Wall, "Host Identity Protocol: Achieving IPv4 - IPv6  
> handovers without tunneling", in Proceedings of Evolute workshop  
> 2003: "Beyond 3G Evolution of Systems and Services", University of  
> Surrey, Guildford, UK, November 10, 2003.
> [10] Andrei Gurtov, Dmitry Korzun, Pekka Nikander, "Hi3: An  
> Efficient and Secure Networking Architecture for Mobile Hosts,"  
> Technical report 2005-2, Helsinki Institute for Information  
> Technology, June 2005.
> mobility with Host Identity Protocol," Extended Abstract in Proc.  
> of NDSS Wireless and Mobile Security Workshop, San Diego, CA, USA,  
> February 2005.
>
>

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 18 Dec 2006 17:39:13 +0000

An observation on this discussion: the word 'mobility' is overused and overloaded in the IETF world.

'Fast mobility', as discussed below, is pretty much what everyone else has always called mobility; truly fast mobility needs to take advantage of physical channel diversity (i.e. make before break for a seamless handover).

'Slow mobility' or 'mobility' is pretty much what everyone else calls 'roaming' - 'Mobile IP' is imo misnamed, since it's really about preserving your static address in a home network while roaming on a different network, and that roaming may or may not have a mobility aspect with regular handovers involved.

[US: read 'handover' as 'handoff']

L.

"Partial consensus"? Is that like "partly pregnant"?

At Monday 18/12/2006 12:09 -0500, Marshall Eubanks wrote:
>>September 5-9, 2005. http://users.tkk.fi/~jylitalo/publications/ SecureComm05-Ylitalo-et-al.pdf
>>
>>[3] Jukka Ylitalo, Pekka Nikander, "A new Name Space for End- Points: Implementing secure Mobility and Multi-homing across the  
>>http://users.tkk.fi/~jylitalo/publications/ACISP2005-Tschofenig-et- al.pdf
>>
>>http://www.tml.tkk.fi/~pnr/publications/ HIIT_gurtov_hi3_report_2005.pdf
>>

---

From: John Leslie <[email-masked]>
Date: Tue, 19 Dec 2006 12:47:42 -0500

A week has passed: I'll try for an update:

John Leslie <[email-masked]> wrote:
> 
> ... I will try to outline areas of questions; but first please let me
> do a complete statement: I welcome discussion of the issues I'll name,
> and I welcome listing other areas of question...
> 
> Statement:

   (See below for a discussion of the layer names.)

> - dropping packets which would cause excessive congestion;

   There has been discussion whether some of these responsibilities
belong to an even lower layer: I don't think there's consensus on that;
and I think we can proceed without settling that question.

> - reducing packet injection rate when a path is congested;

   (The erroneous fourth bullet under "transport" has been removed.)

> - is there a better name than "layers" for these problem spaces?

   None has been proposed: let's stick with "layers".

> - is there a better name than "routing" for the lower "layer"?

   It has been suggested we call the lower layer "internetworking".
I endorse such a change.

> - is there a better name than "transport" for the upper "layer"?

   I think we have rough consensus to talk of a "transport" layer;
but there is still confusion about whether we're trying to assign
too much to it. IMHO, we're close enough to consensus to agree to
discuss a "transport" layer with the three named functions, and
possibly others.
   
> - are any of the responsibilities clearly assigned to the wrong

   None have been proposed (not counting the questions about a
layer below "internetworking")..

> - are we ready to agree to define separate namespaces for these

   We're not ready for that yet, as I read the posts. :^(

   However, I think we're close to consensus that the "namespace" for
the "internetworking" layer should be locators; and that some higher
layer (not necessarily "transport") should have a namespace containing
identifiers not tied to "internetworking" topology.

   That may be close enough...

   (Important though this task surely is, I remain convinced that
we've got to assign responsibilities before we can logically design
a new namespace.)

> before we can have a working system: I'd _really_ prefer not to
> argue where they belong yet...)

   If I've correctly stated the partial consensus above, I think we're
ready to discuss where other responsibilities belong. In any case,
I'd like to ask:

- what other responsibilities should be assigned to these layers?

- are there responsibilities which should be assigned a layer higher
  than "transport"?

---

From: John Leslie <[email-masked]>
Date: Wed, 27 Dec 2006 10:46:47 -0500

A week has passed...

> - are there responsibilities which should be assigned a layer higher

   The list has been (completely) quiet: I take this to indicate the
time of year.

   Regardless, I'd be really surprised if _nobody_ has a wishlist
concerning mobility, security, and/or privacy. It would be really
helpful if we gathered these wishlists within the next week...

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Dec 2006 08:35:46 +0200

> helpful if we gathered these wishlists within the next week...

I still don't understand what you are aiming or what you are trying  
to accomplish with this "partial consensus", but very briefly w.r.t  
the three functions above:

A. Mobility functionality we may need on almost all "layers":

1. physical layer looks like the best layer for handling local, fast,  
radio based mobility (MIMO etc)

2. link layer looks like the best layer for handling local, cross  
link or cross base station mobility

3-4. internetworking and/or transport looks like the natural layer  
for global host mobility; there are weak indications (signalling  
efficiency, aggregation etc) indicating that internetworking is  
probably better

5. personally, I still don't understand all the subtleties related to  
session mobility, especially inter-node session handovers, and e2e  
error correction and congestion control state

7. if we had proper application naming aggregation structures, we  
could most probably handle subnet mobility and application-level  
delegation much better than today

B. Different security functions we will need on almost all "layers":

1. physical layer is a great place to implement geographic location  
security and over-the-air opportunistic encryption, etc.

2. link layer is a good place to include network access control

3-4. there are indications that the location of IPsec, i.e., between  
traditional internetworking and traditional transport, is a good  
choice for placing e2e encryption and integrity

7. it is cumbersome to place user and service authentication and  
access control outside of the application layer, as they have their  
application specific aspects

C. It is impossible to properly implement privacy without considering  
all "layers" simultaneously

1-7. just consider session tracking and mobility

--Pekka Nikander