130 likes | 146 Views
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:
E N D
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: • Provide enough information for new comers • Specify common parameters for the old hands • In the process, identify some issues.
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
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.
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.
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
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
Unresolved Issues • Emergency Identifiers • Security Considerations • Data Distribution • Extensibility • Conflation
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?
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
Data Distribution • Most likely resolved with new ‘Re5’ requirement.
Extensibility • Resolved by new ‘Ma15’ requirement: • The mapping protocol MUST be extensible to allow for the inclusion of new location fields.
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.