Location-to-URL Mapping Protocol (LUMP) draft-schulzrinne-ecrit-lump-00

1. Location-to-URL Mapping Protocol (LUMP)draft-schulzrinne-ecrit-lump-00 Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu IETF 63 - ECRIT

2. Overview • Support global-scale resolution of service identifiers (e.g., service URNs) + locations to other URLs • Attempts to be reliable and scalable • borrow concepts, but not protocol limitations, from DNS • Architecture: “Forest of trees with a cloud above” • avoid root as only deployment alternative • Uses standard web services building blocks IETF 63 - ECRIT

3. Overall architecture carrier X customers knows all trees; caches results R R R R R R flooding nj.us ny.us bergen.nj.us leonia.bergen.nj.us IETF 63 - ECRIT

4. Resolution • Client queries local resolver • doesn’t know which tree to query! • If not in cache, find tree root • Resolver queries tree root • recursively or iteratively IETF 63 - ECRIT

5. Cluster architecture • Each resolver or auth. server is actually a cluster of 1+ nodes • Automatically replicates changes (per record) to all other nodes • tested with mSLP nj.us node node = R node node IETF 63 - ECRIT

6. Split jurisdictions “I’m responsible for (parts of) Anytown” Anytown asks both child nodes query Elm Street Oak Street Oak Street Anytown Main Street Broad Street Main Square Anytown IETF 63 - ECRIT

7. Building trees • Trees are built from the top down • Parents add children • query for coverage region • Next level down may differ for • each service type (sos.fire vs. sos.police vs. roadside-assistance) • geo vs. civic IETF 63 - ECRIT

8. Top-level distribution • Top-levels of trees distribute their coverage region to peers • either civic pattern (C=US, A1=NJ) or polygon • Peers distribute data to other peers •  top-level scope data gets flooded to all resolvers • new resolvers query peer for current data set • periodic “do you have any new data” to avoid sync loss • volume of data modest since top-level coverage changes slowly • estimate: one map/month (few thousand bytes/month) IETF 63 - ECRIT

9. Caching • Caching at all levels • best effort update: if expired and auth. server can’t be contacted within T, use local value  no good alternative • Cache populated by verification queries • MSAG validation and/or access testing • Query returns hints: • e.g., ask for specific geo location • get back enclosing polygon with service area IETF 63 - ECRIT

10. Operations • Query record (recursive, redirection) • either from LObj or LRef • Query range (poly, civic) • return map or list of civic ranges • Provide update vector (from peer) • identified by time & hash • also used to “seed” data • Obtain updates via vector • get list of objects • Push new data object • for cluster synchronization IETF 63 - ECRIT

11. Discovery • LUMP resolver discovery via • DHCP (if offered by ISP) • likely close-by and with full cache • SIP configuration (MSP) • most likely to be operated by MSP? • “Bonjour” • subnet IETF 63 - ECRIT

12. Design assumptions • Can’t predict deployment model • May change over lifetime of protocol • from “peer” to “root” model • Want to have diverse implementations in each cluster and tree  need standardized synchronization mechanisms IETF 63 - ECRIT

13. Open issues • Clean up architecture description and terminology • Need to define WSDL • Define coverage maps for geo and civic • Estimate bandwidth usage for flooding • Security – how to trust tree scope announcements • sign (XMLDSIG) announcements • who can sign for what: some authority (e.g., regulator, NENA in US?) • mediator (trust aggregator) may do job IETF 63 - ECRIT