[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