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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf