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 On Fri, Jun 26, 2009 at 8:24 PM, Christian Vogt<[email protected]> wrote: > Dear all - > > I am catching up on folks' previous discussion on identifier properties. > This discussion is really useful; I wish I had participated earlier. > > One thought that has been brought up is the inevitable coexistence of > multiple types of identifiers. This makes sense given the variety of > things to be identified. In fact, the multitudinousness of identifiers > is not new: Many applications have their own identifiers already today. > > But are all these identifier types essential elements of an Internet > architecture? I would argue most of them are not -- they are useful > within the scope of a particular Internet application, but they are not > essential for the Internet per se to function. In fact, I see only two > purposes for which the Internet architecture must have identifiers: > > (1) service identification, identifying a piece of communication > software that responds to incoming contact establishment attempts > > (2) session identification, identifying the protocol state corresponding > to a particular session after contact establishment > > Individual Internet architecture solutions may use combinations of more > than one identifier for either of these two purposes. For example, > service identification in the existing Internet is achieved by combining > a host identifier (DNS name, or IP address in its role as a host > identifier) and a host-local service identifier (well-known port > number). So an Internet architecture may have more than two types of > identifiers. But again, it seems that all of those identifiers would > serve only the above two purposes, after all. > > Given the distinct identifier purposes, the properties of identifiers > may naturally be specific to a particular purpose. For example, the > property of enabling session referrals clearly applies to only session > identification, but not to service identification. On the other hand, > stability is a property that is more important for service > identification than for session identification, since two hosts engaged > in a session may be able to handle changes of session identifiers. > > Thoughts? > > - Christian > > > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
