We can (and IMHO should) define the Identifier independently from the locator.
An [identifier] is a "handle" that our software, at whatever layer of the stack, uses to associate the components of a particular communication with the communication as a whole. Any handle which provides this association function is an [identifier]. We want the [identifier] to have two specific properties: a. The [identifier] is unique within the scope of the function we use it for. If it isn't unique, we can't guarantee that the components will be associated with the communication to which they belong. b. The [identifier] persists unchanged for the duration of its useful function. If it fails to persist, communication will be disrupted, terminated or induced to malfunction. Here's what we can't say about the generic, abstract [identifier]: i. Scope. It could be global (dns host name). It could be just within the client and server portions of a specific application (web session cookie). It could be anywhere in between as needed to serve its particular function. ii. Lifetime. It may be quasi-permanent (http://www.cnn.com/). It may only last for two packets (the transport ID for a UDP DNS query and its response). It may be anywhere in between as needed to serve its particular function. iii. Protocol layer. It might be layer 7 (web session cookie). It might be layer 2 (the MAC address incorporated in the IPv6 address incorporated in the TCP transport ID). It might be anywhere in between as needed to serve its particular function. Where we run into problems is: 1. Some "thing" serving as part of the [identifier] also serves another function in which uniqueness adds undesirable complexity. 2. Some "thing" serving as part of the [identifier] also serves another function in which persistence adds undesirable complexity. Routing is an example of both problems. We have the extra complexity of finding the prefix in which the unique IP address belongs and we have the extra complexity of computing hundreds of thousands of new paths to the persistent IP addresses every time the system link state changes. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
