Hi Scott and Tony, On Thu, Apr 23, 2009 at 2:07 PM, Scott Brim <[email protected]> wrote: > Excerpts from Tony Li on Wed, Apr 22, 2009 08:43:00AM -0700: >> >> Hi Scott, >> >>> Oh. Then I think we actually agree on procedure, but let's make it >>> explicit: >>> >>> The goal is to figure out which classes of solutions are >>> appropriate, and one input to that is to look at the implications >>> each solution class has on properties of identifiers. >> >> Agree. >> >>> Some of us have been saying that you can't do "properties of >>> identifiers" in general, you have to talk about which kinds of >>> identifiers, in which context. I guess you agree. If so, sorry, I >>> hadn't understood. >> >> No, I think it's reasonable to talk about the classes of solutions >> and the reasonable properties of the (host, interface, stack, ...) >> identifier that is bound to the locator within each class. > > This demonstrates my point: You are assuming the identifier of > interest is one that is "bound to the locator", i.e. the thing that > just the locator gets you to is what you want to describe in this > exercise. In this case one could just as easily envision having > identifiers of interest name things at a finer level of granularity, > where a locator gets you to a particular device (possibly virtual) but > initial packets must include both locator and identifier, so that when > the packet arrives at the device named by the locator, the device can > figure out which particular communication endpoint (named by the > identifier) you want to talk to. The "identifier that is bound to the > locator" could name the device but would not be interesting to us and > would not be used in normal communications, only by device management. > > I'm happy to look at properties for identifiers that are "bound to > locators" but let's not assume that each class has such things. Also > some classes do not say anything about endpoint identifiers at all. > I agree with Scott here.
For 3.3.2.2. Identifier variants B2a Each host has a single identifer to which the locators are attached. This identifier is used by the layer-4/5 and higher protocols to compose the SID. IMHO, the identifier should not be bound to the locator. The reason is that you could create an Endpoint Layer - as discussed in the paper "Breaking Up the Transport Logjam” from http://conferences.sigcomm.org/hotnets/2008/papers/HotNets2008proceedings.pdf - between the network and transport layer in the stack. Then if the identifier is used in a similar way as a HTTP cookie (RFC2965) in the Endpoint Layer you might create a generic session state machine for every application when the underlying locator(s) are changing. So when a mobile client is changing its attachment point in Internet any application session (not only HTTP) could be continued though the locator(s) has changed - if the timers are allowing it. Another place where you could use the "Endpoint cookie"=identifier is in multihoming. A site has two separate service providers that are offering two different Area Locators for the server that is using one Local Locator. In DNS the server have two records, ALOC1:LLOC and ALOC2:LLOC. The client is choosing ALOC1:LLOC for communication, session is established and the identifiers (Endpoint cookies) are exchanged but at some stage the session via ALOC1 fails. After a while the client notice that the session has stalled but in the DNS cache there is a second entry, ALOC2:LLOC. So the client stack decides to try ALOC2:LLOC instead and the connection is re-established with the help of the identifier (Endpoint cookie). Security issues arises, need to look into that and if somebody has ideas feel free to make proposals. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
