Primary and lesser names, or layers of indirection?
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Primary and lesser names, or layers of indirection?
by Pekka Nikander
::
Rate this Message:
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 Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
|
|
|
Re: Primary and lesser names, or layers of indirection?
by John Day-2
::
Rate this Message:
At 10:09 +0200 2006/11/19, Pekka Nikander wrote:
>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. This is where John Shoch's paper gets to. >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. I will go back to my earlier characterization: Names are needed for all loci of shared state with different scope. >As a starting point, I could imagine the following "lesser" names to >be useful: > >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. > >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). This was all worked out 15 years ago. >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. Take a look at how IPC works in most OSs. This should be the model. >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, 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. > >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. 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. > >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. 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. > > >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. 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Primary and lesser names, or layers of indirection?
by Pekka Nikander
::
Rate this Message:
John,
One question, one plea for pointers to insight, and one issue where our thinking seems to differ: On Nov 19, 2006, at 15:36, John Day wrote: > 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, > > 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. >> 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. > > This is unnecessary. No special considerations are required for > naming and addressing to support mobility. Mobility is just dynamic > multihoming. 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. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
|
|
|
Re: Primary and lesser names, or layers of indirection?
by Wesley Eddy
::
Rate this Message:
On Mon, Nov 20, 2006 at 09:46:23AM -0500, Noel Chiappa wrote:
> > From: Pekka Nikander <pekka.nikander@...> > > > On Nov 19, 2006, at 15:36, John Day wrote: > > >> 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 > > No, he almost certainly meant IEN-19, "Inter-Network Naming, Addressing, and > Routing". I believe the IEN repository at ISI has this one now. > There is a citation in RFC 1498 for: 1. Shoch, John F., "Inter-Network Naming, Addressing, and Routing," IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K. (ed.), Tutorial: Distributed Processor Communication Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287. I wasn't able to find this in IEEE Xplore, though. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
|
|
|
Re: Primary and lesser names, or layers of indirection?
by David Conrad
::
Rate this Message:
Hi,
On Nov 20, 2006, at 1:47 AM, Pekka Nikander wrote: >> This is unnecessary. No special considerations are required for >> naming and addressing to support mobility. Mobility is just >> dynamic multihoming. > > While I completely agree with mobility being dynamic multi-homing > 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Primary and lesser names, or layers of indirection?
by Patrik Fältström
::
Rate this Message:
On 20 nov 2006, at 20.54, David Conrad wrote:
> On Nov 20, 2006, at 1:47 AM, Pekka Nikander wrote: >>> This is unnecessary. No special considerations are required for >>> naming and addressing to support mobility. Mobility is just >>> dynamic multihoming. >> >> While I completely agree with mobility being dynamic multi-homing >> 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. 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Primary and lesser names, or layers of indirection?
by Brian E Carpenter
::
Rate this Message:
David Conrad wrote: > Hi, > > On Nov 20, 2006, at 1:47 AM, Pekka Nikander wrote: > >>> This is unnecessary. No special considerations are required for >>> naming and addressing to support mobility. Mobility is just dynamic >>> multihoming. >> >> >> While I completely agree with mobility being dynamic multi-homing >> from an architectural point of view, > > > Actually, I disagree. > > 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 > 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 > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@... > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Primary and lesser names, or layers of indirection?
by Joel M. Halpern
::
Rate this Message:
At 04:49 AM 11/21/2006, Brian E Carpenter wrote:
>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 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Primary and lesser names, or layers of indirection?
by David Conrad
::
Rate this Message:
Brian,
On Nov 21, 2006, at 1:49 AM, Brian E Carpenter wrote: >> Mobility is simply renumbering on a constrained time scale. > But, renumbering is simply multihoming on a relaxed time scale > (see RFC 4192). 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
RE: Primary and lesser names, or layers of indirection?
by Schliesser, Benson
::
Rate this Message:
David Conrad [mailto:drc@...] wrote:
> 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. 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Primary and lesser names, or layers of indirection?
by David Conrad
::
Rate this Message:
Benson,
On Nov 23, 2006, at 10:52 AM, Schliesser, Benson wrote: > Though perhaps multi-homing can be treated as a sub-case of > mobility, or > 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
|
|
|
Re: Primary and lesser names, or layers of indirection?
by John Day-2
::
Rate this Message:
|
