Offhand I don't know why it should be necessary to build a mechanism
that spans several transport lifetimes. I would much prefer that we
re-engineer our transport protocols to let them work in terms of
endpoint IDs. In particular, checkpoints would seem to make life more
complicated for applications by lowering the level of service from
transport protocols - because I think it would be hard to implement
transport-independent and application-independent checkpointing in a way
that made sense.
I do however think that there might be a place for a mini layer in
between IP and transport that accomplished a few things that we seem to
need in all transports. e.g. management of ID-LOC mapping, management
of multiple LOCs per endpoint ID, striping of traffic across multiple
paths, management of RTT and other estimators, congestion control, peer
authentication, encryption, and explicit interaction with layer 3
intermediaries.
Keith
For a long time I've suggested that we begin to look anew at the idea
of an "association" as an abstraction over "transport". Yes, I know
that this smacks if ISO/OSI, but there were a few granules of good
ideas there.
The idea is this: An "association" is an end-to-end relationship
between a pair of applications that potentially spans several
transport lifetimes.
Then, if the underlying transport goes away, perhaps due to movement
in a mobile network or renumbering, then the association is
reconstructed on a new transport that is built in accord with the
current addressing and routing conditions.
Reconstruction does not, as some have assumed, require that the
network remember anything or hold any state. Rather, taking a cue
from ISO/OSI, the trick is that the association layer is merely a
means for the applications to reliably exchange checkpoint names.
What those checkpoint names mean is up to the applications - thus what
to do if a rebinding to a new transport requires going back to a
checkpoint is something entirely within the application and its
networking library code, not some state that is stored in the net.
Basically whenever applications establish a transport they say "Ahem,
where were we when we last spoke". One answer is "We did not last
speak" Another answer is "we last agreed on the checkpoint named
'foo'". How they recover from 'foo' is entirely application dependent.
(I have not really considered the security implications - in the
absence of some form of shared secret or other authentication on
association re-establishment there would probably be a race condition
in which an intruder could jump in.)
(I'm also thinking of TCP based applications, not UDP based ones. For
them I don't see renumbering as much of a problem, but I may not be
seeing enough.)
This is not something that can readily be transparently back-ported
into existing protocols; it's not something of trivial import. But it
can be deployed for new applications and not invalidate either
existing applications or existing application protocols.
And consider, for example, how something like this might have obviated
the need for the IP layer triangulation in mobile IP.
--karl--
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf