Subject: [arch-d] Primary and lesser names, or layers of indirection?

From: Pekka Nikander <[email-masked]>
Date: Sun, 19 Nov 2006 10:09:44 +0200

Maybe one difficulty in this discussion is that there are so many  
needs or "requirements"?

Disregarding mobility, multi-path, etc, to me it looks like that we  
need two classes of primary names:

1) Application-level names.  Handles that applications can refer to.

2) Routing-level names.  Handles for the routing/forwarding system to  
use for directing traffic.

The needs for these two types of names seem to be genuinely  
different, but I won't go into that here.

My point is, for various mobility/security/efficiency/administrative  
needs, it seems plausible that we would benefit from a number of  
classes of "lesser" names.  I call these tentatively "lesser" since  
they are not strictly needed; I could imagine an architecture with  
just application-level and routing-level names.  However, these  
lesser names seem to reduce the amount of signalling in various  
mobility situations, they seem to offer possibilities for making the  
system more easily secureable, and they seem to help system  
administration by allowing better application-level flexibility  
(multiple versions of apps), identification of nodes, etc.

As a starting point, I could imagine the following "lesser" names to  
be useful:

a) Application-instance names.  "Dynamic" variants of 1) above.

b) Flow or transport names.  Primarily needed for QoS/multi-path.

c) Node or stack names.  Primary units of mobility, with fate sharing.

d) Interface or link-layer names.

To give an idea how these could work, consider the following:

1. Application requests a service/whatever using an application-level  
name (1).

2. The Application-level name (1) is (optionally) resolved into an  
application-instance name (a).  The benefit of this step is that it  
makes it easier to support distributed/location dependent/time  
dependent/etc applications.  In general, any kinds of applications  
whose instance identification depends also on other attributes but  
the primary Application-level name (1).

3. If fulfilling of the application-level request involves one or  
more flows, new flow or transport names (b) are formed.  These seem  
to be needed for QoS and flow control.  Apparently, they should be  
visible to the intermediate nodes that care about QoS and flows, such  
as network-side nodes that control radio or other scarce resources.

4. A node or stack name (c) merely aggregates a number of flow names  
(b) for the primary purpose of node-level mobility.  However, the  
node or stack name also allows easier implementation of baseline  
security and privacy, can make systems administration easier, etc.

5. The node or stack name (c) is mapped onto a Routing-level name (2).

6. The Routing-level name (2) is used to deliver the packet to the  
right location.  This may involve additional names locally within the  
routing system, such as those used today in MPLS and GMPLS.  As far  
as I understand, there may be administrative needs to classify flows  
based on various attributes; using names as short-hand notification  
seems to help efficiency.

7. Apparently, the routing-level name (2) is finally mapped into an  
interface or link-layer name (d).  However, I have to admit that I  
don't quite understand why this is beneficial.  (Clearly, it is not  
necessary.)  Anyway, that's the way how the systems work today, and  
since I don't understand this level, it looks better to preserve this  
piece of the current architecture.

A useful exercise (left for the reader to keep this message  
manageable) is to consider the _exact_ benefits and drawbacks caused  
by each of the proposed layers of indirection.  The relevant  
corollary is to consider if (a)-(d) is the right choice of lesser  
names, or if there would be better ones.  One that is missing but has  
been repeatedly suggested is explicitly naming (mobile) sub- 
networks.  However, I happen to think that it can be "emulated" well  
enough with stack or node names and delegation.

Note that I didn't say anything about how the various resolutions are  
performed in detail, nor where the mapping state is stored, etc.  In  
some cases that may be implied by the nature of the names; in other  
cases I can see quite a lot of freedom and potential choices.

Another important issue here is that I don't believe we could fulfil  
all the needs for application-level names with just one name space.   
There seem to be fundamental conflicts between usability, economic  
aspects, and security, that make it impossible.  Hence, most probably  
we will need different representations for naming the application- 
level entities.  That also implies that we'll need some kind of  
infrastructures (either local or global) for maintaining mappings  
between those different representations.  But again, that's another  
issue.

--Pekka Nikander

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

---

From: John Day <[email-masked]>
Date: Sun, 19 Nov 2006 08:36:26 -0500

At 10:09 +0200 2006/11/19, Pekka Nikander wrote:
>2) Routing-level names.  Handles for the routing/forwarding system 
>to use for directing traffic.
>

This is where John Shoch's paper gets to.

>(multiple versions of apps), identification of nodes, etc.

I will go back to my earlier characterization:  Names are needed for 
all loci of shared state with different scope.

>a) Application-instance names.  "Dynamic" variants of 1) above.

As well as other possible names or naming conventions for 
aggregations of applications.

>b) Flow or transport names.  Primarily needed for QoS/multi-path.

We have this.  It is the connection-id in TCP, i.e. the port-ids.

>1. Application requests a service/whatever using an 
>application-level name (1).
>

This was all worked out 15 years ago.

>visible to the intermediate nodes that care about QoS and flows, 
>such as network-side nodes that control radio or other scarce 
>resources.

Take a look at how IPC works in most OSs.  This should be the model.

>security and privacy, can make systems administration easier, etc.

There is a problem here.  What I would call the node address is what 
you are calling the routing level name.  What you are calling the 
node name I would see as additional structure on the application 
naming scheme.  To use your nomenclature then,

As I argued before, this is an application aggregation name.  It 
belongs in the application layer. There are cases where this kind of 
aggregation is not desirable and others are,  So this would get in 
the way.  Some may argue that a large number of instances today are 
of this sort and that may be.  But we have no idea if that will 
continue to be the case and end up being in the way later.  If we 
make it part of the application layer then we can use when and if we 
need to and not if we don't.  We don't need to force this 
inflexibility here.

>5. The node or stack name (c) is mapped onto a Routing-level name (2).

The primary purposes of the routing name or the functions behind it 
is multiplexing and relaying.

>right location.  This may involve additional names locally within 
>the routing system, such as those used today in MPLS and GMPLS.  As 
>far as I understand, there may be administrative needs to classify 
>flows based on various attributes; using names as short-hand 
>notification seems to help efficiency.
>
>since I don't understand this level, it looks better to preserve 
>this piece of the current architecture.

Once the Next Hop is chosen, this information is required to pick the 
path to the next hop.  This is only needed if there are multiple 
paths or if the media is multi-access.

>names, or if there would be better ones.  One that is missing but 
>has been repeatedly suggested is explicitly naming (mobile) 
>sub-networks.  However, I happen to think that it can be "emulated" 
>well enough with stack or node names and delegation.

This is unnecessary. No special considerations are required for 
naming and addressing to support mobility. Mobility is just dynamic 
multihoming.

>
>Note that I didn't say anything about how the various resolutions 
>are performed in detail, nor where the mapping state is stored, etc. 
>In some cases that may be implied by the nature of the names; in 
>other cases I can see quite a lot of freedom and potential choices.
>
>
>aspects, and security, that make it impossible.  Hence, most 
>probably we will need different representations for naming the 
>application-level entities.  That also implies that we'll need some 
>kind of infrastructures (either local or global) for maintaining 
>mappings between those different representations.  But again, that's 
>another issue.

I would tend to agree.  But these names should all resolve to the one 
we are positing here.  This will allow accountability.  Those are for 
our purpose for the most part outside the scope of creating and 
maintaining communication and we can exclude them for now.

Take care,
John

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 20 Nov 2006 11:47:25 +0200

John,

One question, one plea for pointers to insight, and one issue where  
our thinking seems to differ:

> This is where John Shoch's paper gets to.

This one?

Shoch, J. F.; Hupp, J. A. The "Worm" programs - early experience with  
a distributed computation (reprint of a 1980 paper). In Milojicic,  
D.; Douglis, F.; Wheeler, R., editors. Mobility: Processes, Computers  
and Agents. NY: ACM; 1999; 19-27

---

> I will go back to my earlier characterization:  Names are needed  
> for all loci of shared state with different scope.

Hmm.  Is a corollary of that that names are needed at all loci where  
demultiplexing must be performed based on data received from the  
network, in order to find the right piece of shared state?

What remains somewhat obscure to me is the relationship of this to  
security and signalling efficiency.  Insight here would help  
tremendously, I think.  Any papers on this?

---

Now, let's dwell a little bit on mobility.  We seem to see the  
situation slightly differently.  Or, alternatively, I was just  
unclear in my writing.

>> 4. A node or stack name (c) merely aggregates a number of flow  
>> names (b) for the primary purpose of node-level mobility.   
>> However, the node or stack name also allows easier implementation  
>> of baseline security and privacy, can make systems administration  
>> easier, etc.
>
> There is a problem here.  What I would call the node address is  
> what you are calling the routing level name.  What you are calling  
> the node name I would see as additional structure on the  
> application naming scheme.  To use your nomenclature then,
>
> belongs in the application layer. There are cases where this kind  
> of aggregation is not desirable and others are,  So this would get  
> in the way.  Some may argue that a large number of instances today  
> are of this sort and that may be.  But we have no idea if that will  
> make it part of the application layer then we can use when and if  
> we need to and not if we don't.  We don't need to force this  
> inflexibility here.
...
>> manageable) is to consider the _exact_ benefits and drawbacks  
>> caused by each of the proposed layers of indirection.  The  
>> relevant corollary is to consider if (a)-(d) is the right choice  
>> of lesser names, or if there would be better ones.  One that is  
>> missing but has been repeatedly suggested is explicitly naming  
>> (mobile) sub-networks.  However, I happen to think that it can be  
>> "emulated" well enough with stack or node names and delegation.
>

While I completely agree with mobility being dynamic multi-homing  
from an architectural point of view, there are practical differences  
that lead, via engineering considerations, to small but apparently  
necessary differences at the architecture, once we get down one level  
of details.  That is, while at the uppermost structural level we can  
and should unify mobility and multi-homing, once we start go consider  
the network dynamics in terms of signalling efficiency, propagation  
delays, and state synchronisation, there seems to emerge some  
differences.  Now, I sincerely hope to be wrong here, since if I am  
wrong, I could further simplify my thinking.  But unfortunately I'm  
afraid that I happen to be right.  So sad :-)  But we'll see.

Let me first consider node names.  While I can agree with your point  
that node names can be considered as merely application aggregation  
names, I don't quite understand why should aggregation would not be  
desirable.  Such aggregation should be dynamic, anyway.  That is, the  
mapping from an application-level name to a node name should always  
be a dynamic one, internal to the stack, and modifiable in the case  
that the application instance needs to be moved to another node.

However, if I look at node names from the mobility point of view, I  
would imagine node mobility to be by-and-far the most common case.   
In my imagination, nearly all of the end-nodes in the future internet  
will be mobile.  While most of the mobility will most probably be  
hidden from the routing/forwarding layer, I still imagine that there  
will be huge amount of mobility / dynamic multi-homing events taking  
place, by-far the largest majority of these taking place at the level  
of "nodes", or small "subnets" (stable collections of nodes).

Now, from an architectural point of view I don't see any real  
difference between a number of applications, with active flows,  
running within a mobile node and a number of mobile nodes moving  
together within a mobile subnet.  In both cases we have aggregate  
mobility or dynamic multi-homing, basically meaning that all the apps/ 
flows within the mobility domain show the same mobility behaviour.

In order to be able to handle the large amount of signalling  
resulting from handing this dynamic behaviour, it seems beneficial of  
making these "node/stack/end-point" names explicit.  Sure, from an  
architectural point of view they are just dynamic aggregations of  
applications and associated active flows.  Explicit names just make  
it easier to inform the rest of the system about a dynamic change in  
the mapping from application names to location names.  Additionally,  
they ease system administration since the node names are something  
that matches nicely with the cognitive models of system admins.

So, as far as I can see, I am not advocating any inflexibility here.   
I am just trying to identify another class of beneficial "lesser"  
names.  Nodes/stacks/hosts/end-points seem to be entities that  
benefit from being explicitly named, even though from an overall  
architectural point of view they can and probably should be  
considered merely as dynamic aggregations of applications.

--Pekka Nikander

PS.  BTW, I understood this point of view only fairly recently, maybe  
a year ago.  Until that I always considered node/stack/host/end-point  
names as primary ones, application-layer names somehow being either  
completely independent or "lesser".  Fool me.

---

From: David Conrad <[email-masked]>
Date: Mon, 20 Nov 2006 11:54:04 -0800

Hi,

On Nov 20, 2006, at 1:47 AM, Pekka Nikander wrote:
>> naming and addressing to support mobility. Mobility is just  
>> dynamic multihoming.
>
> from an architectural point of view,

Actually, I disagree.

Mobility is simply renumbering on a constrained time scale.   
Architecturally, support for multi-homing (in the sense of a network- 
attached-thingie having more than one name-thingie) is not required  
for mobility.  I would agree that multi-homing makes implementation  
easier.

Rgds,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 21 Nov 2006 08:36:30 +0100

On 20 nov 2006, at 20.54, David Conrad wrote:

> Architecturally, support for multi-homing (in the sense of a  
> network-attached-thingie having more than one name-thingie) is not  
> required for mobility.  I would agree that multi-homing makes  
> implementation easier.

I sort of agree with you David, but I do not think renumbering is  
always needed. I see "mobility" as a feature a human or service have,  
and whether renumbering is needed or not is dependent on what  
identifiers(!) are used to identify the endpoint that "moves around".  
Further, we also have different feature requirements with mobility in  
the IETF. Some people think it is important to be able to keep flows  
up during a "move". Other people say a TCP (in the classic sense) can  
restart so the "experience" on application layer is that things "just  
work".

Today the identifiers we have are URI's of some sort, and they  
include domain names as the key ingredient. Because of this, mobility  
include having a stable domain name. The rest is an implementation  
issue :-)

Oh, is that why we have this discussion? :-) :-)

    Patrik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2006 10:49:53 +0100

> Mobility is simply renumbering on a constrained time scale.

But, renumbering is simply multihoming on a relaxed time scale
(see RFC 4192).

Personally, I think *roaming* is dynamic multi-homing, which
is a slightly different statement.

     Brian

> attached-thingie having more than one name-thingie) is not required  for 
> mobility.  I would agree that multi-homing makes implementation  easier.
> 
> Rgds,
> -drc
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Nov 2006 07:34:40 -0500

>is a slightly different statement.

Clearly, renumbering and mobility are closely related.  Renumbering 
has certain advantages (like the fact that you can count on / arrange 
overlap between the old and new numbering (connectivity, locators, etc.)

One can, and some folks have built good answers were multi-homing is 
also akin to mobility.  But it does not actual seem to me that the 
ability to get a useful currently defined locator / locator set is 
the same as the ability to update that locator / locator set on the 
fly among communicating parties.  At the time scale of re-performing 
the identifier->locator mapping they ought to look the same.
And it may be advantageous to make the updating mechanism inherent in 
the mapping maintenance mechanism.
But that does not make them the same mechanism in terms of the 
architecture as we have usually discussed it.

Yours,
Joel

---

From: David Conrad <[email-masked]>
Date: Tue, 21 Nov 2006 09:45:57 -0800

Brian,

> But, renumbering is simply multihoming on a relaxed time scale

This is getting a bit far afield, however I disagree.  Multi-homing,  
particularly in the 4192 case, is a way of renumbering without  
risking the interruption of connectivity.  It permits "make before  
break", that is "make a new connection before breaking the old  
connection" as opposed to "break before make" which is necessary if  
you do not support multi-homing.  You _can_ implement mobility  
without multi-homing since the Internet is datagram based, relying on  
the remote side to retransmit any packets that might have been  
dropped while the renumbering event occurs.  Not that you'd want to,  
of course.

Rgds,
-drc

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 23 Nov 2006 12:52:16 -0600

> for mobility.  I would agree that multi-homing makes implementation

Though perhaps multi-homing can be treated as a sub-case of mobility, or
vice versa? That is, multi-homing could be a case of mobility with
multiple stable subnet connections, mobility could be a case of
multi-homing with unstable/changing subnet connections. Conceivably we
could have one solution for both views, no?

Cheers,
-Benson

---

From: David Conrad <[email-masked]>
Date: Thu, 23 Nov 2006 12:34:16 -0800

Benson,

On Nov 23, 2006, at 10:52 AM, Schliesser, Benson wrote:
> vice versa?

Yes.

The point I've been trying to make is that if you create a layer of  
indirection that allows for the mapping of one object (the id that  
applications know about) into one or more other objects (the locators  
that the routing system knows about), renumbering, mobility, and  
multi-homing all come more or less for free.

Right now, there is no indirection and you have id = locator.  Both  
the routing system and applications have deep personal knowledge of  
the same object. As a result, if you want to change locator in order  
to facilitate aggregation, you have to change the id.  Changing the  
id is painful and costly so nobody wants to do it.

However, if you introduce a layer of indirection (call it the mapping  
function "map()"), you gain a tremendous amount of flexibility (at  
the cost of a hit on performance).  That is:

a) renumbering:
	1) map(id) -> locator_A
	2) map(id) -> locator_B
b) mobility:
	1) map(id) -> locator_A
	2a) map(id) -> locator_B
	2b) locator_A: forward(id) -> locator_B
c) multi-homing:
	1) map(id) -> locator_A
	2) map(id) -> locator_A,locator_B

Same mapping function.  Same architecture.  Different benefit  
depending on context.

Note also that since the application name does not change, you get  
connection survivability in renumbering events (both nomadicity  
(changing providers) and mobility) for free.

Architecturally, how the layer of indirection is done is irrelevant  
(engineering-wise, it matters how and where the mapping is done and  
there are a lot of ways to skin that particular cat (I use the DNS as  
an example), but that's not particularly relevant to this list).

Rgds,
-drc

---

From: John Day <[email-masked]>
Date: Thu, 23 Nov 2006 19:27:39 -0500

Hey someone read Saltzer!  ;-)

But did you notice the piece he missed?  PoAs don't map to routes. 
Nodes do.  Then you need to know the node to PoA mapping of all 
nearest neighbors to pick the path to the next hop.  Multiple paths 
to next hops didn't exist when Saltzer wrote.

At 12:34 -0800 2006/11/23, David Conrad wrote:
>applications know about) into one or more other objects (the 
>locators that the routing system knows about), renumbering, 
>mobility, and multi-homing all come more or less for free.
>
>However, if you introduce a layer of indirection (call it the 
>mapping function "map()"), you gain a tremendous amount of 
>flexibility (at the cost of a hit on performance).  That is:
>
>a) renumbering:
>	1) map(id) -> locator_A
>	2) map(id) -> locator_B
>b) mobility:
>	1) map(id) -> locator_A
>	2a) map(id) -> locator_B
>there are a lot of ways to skin that particular cat (I use the DNS 
>as an example), but that's not particularly relevant to this list).
>
>Rgds,
>-drc
>
>

---

From: Jefsey_Morfin <[email-masked]>
Date: Fri, 24 Nov 2006 03:29:29 +0100

>could have one solution for both views, no?

Yes. So easy to address all this if you do not conceive addresses as 
a solid number.
Think of network spaces as mathematical multinormed spaces.
May be some of us will remember what a vector and a vectorial addition are?

If there is a problem, that problem comes from RFC 1958 ter.
RFC 1958 Bis (RFC 3439) considered very large network complexity.
No one wrote RFC 1958 Ter yet, about the very very large global 
network extended complexity.

IMHO all this debate will go nowhere [at least at the IAB/IETF/IRTF] 
as long as we do not have the adquate thinking tools and 
architectural principles. Then we will also need a target requierement list.
jfc