1 / 13

A Lo cation-to- S ervice T ranslation Protocol (LoST) & Mapping Protocol Architecture

A Lo cation-to- S ervice T ranslation Protocol (LoST) & Mapping Protocol Architecture. Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig. Overview. LoST is a simple XML-based query and response protocol running on top of HTTP either “naked” HTTP or SOAP

conway
Download Presentation

A Lo cation-to- S ervice T ranslation Protocol (LoST) & Mapping Protocol Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Location-to-Service Translation Protocol (LoST)& Mapping Protocol Architecture Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig SDO Emergency Services Coordination Workshop (ESW06) 

  2. Overview • LoST is a simple XML-based query and response protocol running on top of HTTP • either “naked” HTTP or SOAP • Main Purpose: Return URIs for given location information and service identifier • i.e., service URN + location  URIs • Status: Work in progress • Expected WGLC in Nov. 2006 SDO Emergency Services Coordination Workshop (ESW06) 

  3. Finding the correct PSAP • Which PSAP should the e-call go to? • Usually to the PSAP that serves the geographic area • Sometimes to a backup PSAP • If no location, then ‘default’ PSAP SDO Emergency Services Coordination Workshop (ESW06) 

  4. LoST Functionality • Satisfies the requirements (draft-ietf-ecrit-requirements) for mapping protocols • Civic as well as geospatial queries • civic address validation • Recursive and iterative resolution • Fully distributed and hierarchical deployment • can be split by any geographic or civic boundary • same civic region can span multiple LoST servers • Indicates errors in civic location data  debugging • but provides best-effort resolution • Supports overlapping service regions SDO Emergency Services Coordination Workshop (ESW06) 

  5. LoST Properties • Minimizes round trips: • caching individual mappings • returns coverage regions (“hinting”) • civic (“all of C=US, A1=NY”) or geo (polygon) • Facilitates reuse of Transport Layer Security (TLS) • Returns emergency service numbers for a region • Query for supported Service URN types SDO Emergency Services Coordination Workshop (ESW06) 

  6. Protocol request (mapping) <?xml version="1.0" encoding="UTF-8"?> <findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1" validate="false" operation="recursive"> <locationInfo> <civicLocation> <country>US</country> <A1>New York</A1> <A3>New York</A3> <A6>Broadway</A6> <LOC>Suite 75</LOC> <PC>10027-0401</PC> </civicLocation> </locationInfo> <service>urn:service:sos.police</service> </findServiceByLocation> details likely to change SDO Emergency Services Coordination Workshop (ESW06) 

  7. Protocol response (mapping) <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1"> <result status="200" message="OK" xml:lang="en" timeToLive="10000"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>unknown</service> <serviceBoundary> <civicLocation> <country>US</country> <A1>New York</A1> <A3>New York</A3> </civicLocation> </serviceBoundary> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <service-number>911</service-number> </result> </response> SDO Emergency Services Coordination Workshop (ESW06) 

  8. Validation • Determine if civic location is (partially) valid • Returns XML tag names of components: • validated and used for mapping • no attempt to validate (and not used) • e.g., house number • known to be invalid • Return (default) PSAP based on validated elements • May return list of guesses for correct addresses, if requested SDO Emergency Services Coordination Workshop (ESW06) 

  9. Geo support • Which geo types should be supported? • Point (3D)  • Polygon?  may yield ambiguous answers • more complicated shapes? • Current proposal • always include 3D-point • may include other shapes SDO Emergency Services Coordination Workshop (ESW06) 

  10. LoST: Location-to-URL Mapping VSP1 cluster serving VSP1 replicate root information cluster serves VSP2 123 Broad Ave Leonia Bergen County NJ US LoST root nodes NJ US NY US sip:psap@leonianj.gov search referral Bergen County NJ US Leonia NJ US SDO Emergency Services Coordination Workshop (ESW06) 

  11. LoST Architecture G tree guide G G G broadcast (gossip) T1: .us T2: .de G resolver T2 (.de) seeker 313 Westview Leonia, NJ US T3 (.dk) T1 (.us) Leonia, NJ  sip:psap@leonianj.gov SDO Emergency Services Coordination Workshop (ESW06) 

  12. Conclusion • Mapping is core component of emergency calling problem • LoST fully international and distributed • tries to avoid “who runs the root” problem • optimized for efficient use in mobile end systems SDO Emergency Services Coordination Workshop (ESW06) 

  13. References and Contact Info • IETF ECRIT Working Grouphttp://www.ietf.org/html.charters/ecrit-charter.html • LoST draft http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ • Mapping architecture draft: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch • Prototype implementation work in progress (see demo) • First interoperability tests planned for early 2006 / beginning 2007. SDO Emergency Services Coordination Workshop (ESW06) 

More Related