Further thoughts related to the separation between identfier information and routing/location information: As far as I know, by the enum-solution for VoIP the telefone number is treated like a DNS-name and mapped to an IP address. By means of a thorough loc-id split, i.e. by providing 2 destination info parts, the identifer part may be extended to cater multiple address families, e.g. E.164 immediately. Also VPN numbering may be done in a more elegant way, enabling better (?) VPN models. Or AFI's for new sorts of entities ? like traffic lights? etc etc etc. Loc-id separation makes a lot of sense for the benefit of both the identifiers and their categories as well as the routing. Heiner In einer eMail vom 16.03.2008 10:18:54 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
Hi all, Here's a few thoughts on segmenting the solution space a bit more. As part of our original charter, we accepted as axiomatic that the overloading between the locator and identifier namespaces was harmful. We ended up in this difficulty because the address was used by the transport protocols as part of a host's identification, as well as the topological locator that was used by the routing subsystem to forward packets. We've also accepted as axiomatic that we would like to separate this functionality into two independent namespaces. I want to stress here that for the architectural result to be in any way clean, independence is mandatory. Any linkage whatsoever would be a clearly suboptimal result. In what Noel has characterized as the "jack-up" model, we would lift up the operating Internet today, let what we think of as addresses continue to be used, but demote them to the role of pure identifiers. We would then install a new namespace of locators underneath it, provide a mapping between identifiers and locators, and work out a forwarding plane adaptation so that we only dealt with locators in the core. The logical alternative to this is to continue to use addresses, but instead of as identifiers, to retain them as locators. This would imply that we would introduce a new namespace to function as identifiers. In effect, this is part of what Handley's proposal does: by shifting the transport to stop using addresses as part of the identification of a transport connection, it creates the need for another level of identification. Handley posits the use of multiple parallel connections between hosts, striping data across these connections to instantiate a single, address-agile transport layer. Implicit in this structure is a mechanism for the host to recognize that these individual connections are part of a greater aggregated connection. This has obvious security implications which will, in effect, require a security association between hosts. That security association effectively requires some security token (e.g., a public-private key pair used to compute a session key) so that the correspondent host can be assured that the component connections are indeed related. This security token is, for all intents and purposes, a host identifier. Accordingly, it seems appropriate to christen this the "jack-down" model, as it jacks the network layer down a notch and inserts a layer of host identification above the network layer, leaving it firmly embedded in the transport layer. Assuming that we retain our axioms from the start of this discussion, this pretty clearly divides the solution space in two, and would seem to present a full cover of the space, which I, for one, find somewhat satisfying. Comments? Thoughts? Regards, Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
