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
tony.li@tony.li:
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 rrg-request@psg.com with the
word 'unsubscribe' in a single line
as the message text body.
archive: <http://psg.com/lists/rrg/> &
ftp://psg.com/pub/lists/rrg
|