[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Consensus? End-user networks need their own portable address space
On Jun 23, 2008, at 9:19 PM, Scott Brim wrote:
It's clear that we need a node identification mechanism that by some
means has to persist at least as long as any particular packet
exchange lasts. This could be done by any combination of functions
at multiple layers.
Indeed. Much of the discussion has been where to do the separation.
Outside of the network stack via ETR/ITR or equivalent
At the IP layer via SHIM6
At the transport layer via SCTP or equivalent
At the application layer via a "network handle" concept (i.e., present
the application an index into a kernel-maintained table with the
kernel handling address change, modeled after Unix file handles).
The farther you move down the stack, the wider the scope of an address
change (e.g., changing the address in the ETR/ITR model impacts all
devices serviced by the ETR/ITR, changing the address in a 'network
handle' affects only the process using that address).
Given that so much of Internet traffic is going to be with mobile
endpoints, I don't see how can continue using the current "address"
as an identifier good enough to support session continuity.
Hide the address change within the infrastructure of the layer. E.g.,
in the 'network handle' model, a change gets signaled to the kernel
and if the session is using TCP, the kernel shuts down the connection
to the old address and opens a new connection to the new address. In
the ETR/ITR model, no such gymnastics are necessary, of course, as the
applications or even the hosts behind the ETR/ITR never see a change.
The only way I can think of is to isolate applications from what's
really going on underneath, and present them with a token they can
use for identification and allow them to think it's a real address.
Right. Much of the ickiness we're dealing with is due to the fact
that applications and transport layers know _far_ too much about what
is beneath them. Layering violations hurt.
Regards,
-drc
--
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