ESW06 LoST

A Location-to-Service Translation Protocol (LoST)& Mapping Protocol Architecture : 

A Location-to-Service Translation Protocol (LoST) & Mapping Protocol Architecture Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig

Overview: 

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

Finding the correct PSAP: 

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

LoST Functionality: 

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

LoST Properties: 

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

Protocol request (mapping): 

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

Protocol response (mapping): 

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>

Validation: 

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

Geo support: 

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

LoST: Location-to-URL Mapping: 

LoST: Location-to-URL Mapping cluster serves VSP2 NY US NJ US Bergen County NJ US 123 Broad Ave Leonia Bergen County NJ US cluster serving VSP1 replicate root information search referral root nodes Leonia NJ US sip:psap@leonianj.gov VSP1 LoST

LoST Architecture: 

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

Conclusion: 

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

References and Contact Info: 

References and Contact Info IETF ECRIT Working Group http://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.