Some incomplete thoughts... If we wanted to build a hostname-oriented stack, how do the components divide up?
Off the top of my head, the components look like: 1. Layer-3 protocol to move packets in which the "addresses" carry -only- locator semantics. Could possibly use IPv6 here? 2. Locator assignment, reassignment and routing protocol (LARRP) to recursively assign locator prefixes (from a prefix for the entire network down to a single locator for a host), reassign them when the routing topology changes and and keep track of which prefixes map to which layer-2 destinations from which to build a FIB. 3. Core routing protocol (CRP) to handle routing between entities which are not assigning addresses to each other. Maybe rolls up into LARRP, maybe not. CRP used anywhere peering happens today. 4. Service Name Resolution Protocol (SNaRP) - so that initiators can find the LOCs for their destinations. No real value in keeping the concept of a "host" at the protocol level. Let that be handled with naming conventions instead. A the protocol level you just care about finding a service, such as "http at www.irtf.org." 5. Connection-oriented protocol (COP) - replaces TCP. Handles error correction and LOC changes. API is: listen(servicename) and connect(servicename), send, receive 6. Connection-less protocol (CLeP) - replaces UDP. API is listen(servicename), open(servicename), send and receive. Open just establishes a send/recv binding on the local machine; it doesn't generate any network traffic. Comments? Criticism? Any other big block components of a hostname-oriented protocol stack? Should any of these blocks be broken up differently? -Bill -- 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] https://www.irtf.org/mailman/listinfo/rrg
