1 / 13

ECRIT Architectural Considerations

ECRIT Architectural Considerations. draft-polk-newton-ecrit-arch-considerations-01 James Polk Andrew Newton. Genesis. An observation about the ECRIT meeting in Paris: New comers were confused Old hands speak about differing universes The intent of this document:

alexanderjennifer
Download Presentation

ECRIT Architectural Considerations

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. ECRIT Architectural Considerations draft-polk-newton-ecrit-arch-considerations-01 James Polk Andrew Newton

  2. Genesis • An observation about the ECRIT meeting in Paris: • New comers were confused • Old hands speak about differing universes • The intent of this document: • Provide enough information for new comers • Specify common parameters for the old hands • In the process, identify some issues.

  3. Architecture • There is no one, single type of network in which ECRIT will be deployed. • There are many. • However, we can identify processes that occur within each type of network on which ECRIT must rely: • Bootstrapping • Conversion • Mapping • Conveyance

  4. Bootstrapping • Delivery ofconfiguration and location information to “seekers”. • DHCP • PPP • LLDP • Manual • There are multiple configuration protocols. • The ECRIT requirements upon bootstrapping are not clear.

  5. Conversion • Syntactic • If no PIDF-LO compatible mapping protocol, from the binary bootstrapping scheme to mapping scheme. • From the binary bootstrapping scheme to PIDF-LO XML for conveyance. • Geocoding & Reverse Geocoding • x,y,z <--> 123 Main St. • Civic addresses are user friendly • But geospatial coordinates can be more precise • No requirements for the delivery of both.

  6. Mapping • Location Context Mapping System (LCMS) • Static: • “fixed location” devices can have the mapping done beforehand and handed to them. • Dynamic • When location is known to be fluid, mapping can be done “on-the-fly”. • Combination • Endsystem always asks (same) trusted server where it is (before or during call), even when it moves within the local network

  7. Conveyance • Information sent to the PSAP during the emergency call • Location Conveyance • PIDF-LO • A URI to PIDF-LO? • Identity Conveyance • An authenticated identity • A call-back reference

  8. Unresolved Issues • Emergency Identifiers • Security Considerations • Data Distribution • Extensibility • Conflation

  9. Emergency Call Identifier(s) • Is there just: One? Three? Seven? • What about adhoc identifiers specific to certain regions? • Must these identifiers take any certain form to fit into protocol elements?

  10. Security Considerations • LCMS volume is likely to be orders of magnitude higher than PSTN emergency call volume. • If bootstrapping protocols are insecure, what is the point anyway? • What is the real problem? • Mapping forgery • Mapping denial of service

  11. Data Distribution • Most likely resolved with new ‘Re5’ requirement.

  12. Extensibility • Resolved by new ‘Ma15’ requirement: • The mapping protocol MUST be extensible to allow for the inclusion of new location fields.

  13. Conflation • No requirements regarding the resilience of the emergency call resolution process as it relates to inputs that have not been designed for this specific purpose. • E.g. • ECRIT may require streets to be abbreviated or postal names to be absent, but other location based applications require “typical” addresses.

More Related