Hi Patte - You are absolutely right that decoupling services and sessions from their location would be highly useful. The current conflation of identification and location certainly has serious disadvantages. For example, decoupling would mitigate the routing scalability problem.
But are you saying that using a host identity as part of service or session identification is necessary to achieve this decoupling? - Christian On Jun 30, 2009, at Patrick Frejborg wrote:
Hi Christian, I think service identification and session identification is belonging to the transport layer in the IP reference model - in the OS model they are on separate layers. So in the IP model I would collapse them under one identifier, I think that is what we have today. E.g a TCP connection is identified by the five tuples; source and destination addresses, source and destination ports and protocol. But here the problems starts, a connection/session/association is identified by elements from the network layer (source and destination addresses) - thus the border between the network and transport layer gets very blurred. I believe that this is the reason why we today need to have global unique IP addresses, with global addresses we can identify connections on hosts, security and NAT nodes - it is the only method at the moment, right? Adding a host identifier to the IP reference model wouldn't add much value - unless it can decouple the dependency between network and transport layer. If the host identifier could give an identity for a connection without deep dependency to the network layer an new world opens. I.e. a connection could be identified by some other mechanisms than the network tuples. Then we could migrate from a single-level address scheme to a multilevel address scheme and create a better routing architecture without the need to have global unique addresses. And mobility would be much easier to achieve, i.e. if connections are identified by something else it doesn't matter when the underlying network changes - the application will not be aware and doesn't care about the network parameters. SCTP goes in this direction but the current mainstream transport protocol is TCP. Guess people will not move their applications to use SCTP instead of TCP in order to improve the routing architecture of Internet, right? I think the only way is to fool TCP that underlying network is still the same though it isn't - something is needed between the network and transport layer that the applications aren't aware of. By having a new layer we could change the underlying addressing scheme with backwards compatibly to the current addressing scheme - not all stacks needs to be upgraded since it is backwards compatible. This will not improve mobility but mobility will be improved once people are starting to move their applications to use the host identifier to identify connections on the transport layer. Would people move their applications to support mobility? I think it is matter of time, there are so much mobile devices connected to Internet that enterprises will see business opportunities to move applications to an infrastructure that better supports mobility, this is long term vision but guess it will happen. So I think the identifier(s) should be designed to decouple the transport layer from the network layer. Opponents will say that all hosts must be upgraded, this is not true if the the new stack is made backwards compatible with fallback mechanisms to the current architecture. -- patte
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
