ECRIT Working Group James Polk
Internet-Draft Cisco Systems
Expires: Sept 6th, 2006 Andrew Newton
VeriSign
March 6th, 2006
Emergency Context Routing of Internet Technologies
Architecture Considerations
draft-polk-newton-ecrit-arch-considerations-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses architectural considerations for emergency
context routing of Internet technologies. The purpose of this
document is to provide a systemic view of emergency context routing,
discuss unresolved issues, and explain the relationship of some of
the proposals to these issues, while discussing potential directions
that might be still be necessary for the working group to
investigate.
Polk & Newton Expires Sept 6th, 2006 [Page 1]
Internet-Draft ECRIT Arch Considerations Mar 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Division of Labor . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology, Acronyms and Definitions . . . . . . . . . . 4
2. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. LCMS Mapping . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Conveyance . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Location Conveyance . . . . . . . . . . . . . . . . . . . 8
5.2 Identity Conveyance . . . . . . . . . . . . . . . . . . . 8
6. Universal Emergency Identifiers . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1 Security of the LCMS . . . . . . . . . . . . . . . . . . 10
7.2 Security of Location Conveyance . . . . . . . . . . . . . 11
7.3 Security of Bootstrapping . . . . . . . . . . . . . . . . 11
7.4 Security of Conversion . . . . . . . . . . . . . . . . . 11
8. Data distribution . . . . . . . . . . . . . . . . . . . . . . 12
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Conflation . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Rerouting/Transfer . . . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1 Normative References . . . . . . . . . . . . . . . . . . 14
13.2 Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
A. Appendix A. Additional stuff . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 15
1. Introduction
The solution to proper emergency call identification, management and
routing over the Internet involves many components and coordination
between them. This document describes the necessary interaction
between these components. The information given in this document
may not be complete, and some of the issues presented in this
document may not be resolved by the community. The intent of this
document is to describe a "big picture" view of the process,
describe prevailing thoughts on this subject and describe unresolved
issues in hopes of bringing about consensus within the community on
these topics.
The current architecture of Emergency Context Routing of Internet
Technologies is composed of the following:
Bootstrapping: delivery of configuration and location information to
the client at or near power-up time.
Conversion: conversion of location information into forms usable in
mapping and conveyance, if necessary.
Polk & Newton Expires Sept 6th, 2006 [Page 2]
Internet-Draft ECRIT Arch Considerations Mar 2006
LCMS Mapping: conversion of endsystem location information into
addresses usable to initiate or progress communication towards an
emergency call center (a PSAP).
Conveyance: delivery of endsystem location information to an
emergency call center during the emergency call (used for
first responder dispatch).
There are many unresolved issues regarding these steps and related
matters. The following list is not exhaustive, but includes most of
the issues brought grouping discussions to date (and a few new
ones).
Universal emergency identifier: there needs to be a universal
emergency identifier to prevent highly localized usage and
confusion by users and systems of what applies to a certain
region, and what does not.
Security: the security properties necessary for the proper
protection of LCMS data are not well understood.
Data distribution: the distribution of LCMS data closer to the
points of queries within the Internet.
Extensibility: the methods for extensibility in all components of
the system must be well understood.
Conflation: many of the components proposed for use in the routing
of emergency calls have other uses and most have not been
primarily designed for the emergency call routing case.
1.1 Division of Labor
As stated above, not all of the components used in the process of
routing an emergency call to the correct emergency call center over
the Internet have been defined for the exclusive use of this case,
and therefore not all of the specification work is being conducted
within the scope of the charter of the ECRIT working group.
Bootstrapping of location information, both geospatial and civic,
via DHCP is work in progress in the GEOPRIV working group.
Bootstrapping of URI references via DHCP is work in progress in the
DHC working group.
The definition of location objects and the use of schemas to
describe location is work in progress in the GEOPRIV working group.
The specification of conveyance of location objects via SIP is work
in progress in the SIP working group.
The mapping of location information to URIs is the primary function
of the ECRIT working group. The set of mechanisms and services
Polk & Newton Expires Sept 6th, 2006 [Page 3]
Internet-Draft ECRIT Arch Considerations Mar 2006
working in conjunction with each other to conduct this mapping is
referred to as the Location Context Mapping System, or LCMS by this
document for the purposes of clarity.
1.2 Terminology, Acronyms and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
The following terms and definitions will be used throughout this
document:
Application (Layer) Provider (ALP) - provider of application level
services such as a voice over IP service that is completely
divorced from the Link provider, and may be divorced from the
Internet Attachment Provider of an endsystem that is merely
providing a layer 3 connectivity service.
ALP - Application (Layer) Provider
Emergency Services Gateway (ESGW) - The special IP to circuit-
switched gateway that front-ends an emergency services Selective
Router (SR) (which directs all TDM based 911/112 type calls to
the appropriate PSAP within a given physical region)
Emergency Services Routing Proxy (ESRP) - a special instance of a
SIP Proxy that understands emergency routing of messages
identified as emergency messages to a PSAP based on
the location of the caller that is included in the message
ESGW - Emergency Services Gateway
ESRP - Emergency Services Routing Proxy
IAP - Internet Attachment Provider
Internet Attachment Provider (IAP) - typically the organization that
provides Internet or IP access to the client (i.e. assigns the
client an IP address and/or provides the client with IP transit.
Location Context Mapping System A set of coordinated mechanisms
and services that map a physical location (geospatial or civic)
to a network address.
LCMS Location Context Mapping System
LIS - Location Information Server
PSAP - Public Safety Answering Point
Polk & Newton Expires Sept 6th, 2006 [Page 4]
Internet-Draft ECRIT Arch Considerations Mar 2006
Location Information Server (LIS) Provides a mapping function to
relate unique identifiers for IP devices at physical network
access points and the geographic descriptions of their location
(e.g., civic location/street addresses or geographic
coordinates). Responds to queries for location information.
Public Safety Answering Point (PSAP) - the emergency response call
center talking the local emergency calls from people in distress.
This facility can be logical, and can transfer (reroute) any
request sent to it to another facility deemed more appropriate to
receive the request.
2. Bootstrapping
Bootstrapping delivers configuration information to the
client. The most obvious use of bootstrapping is for an endsystem
to ask for and receive its IP address, Subnet Mask and Default
Gateway addresses. This could also be used to deliver the
geospatial or civic address of the client to it for future use.
This is typically done at device or individual application
boot times. Unlike other parts of the architecture, bootstrapping
is the only phase of the emergency call routing process that does
not have a single solution. This is due to the many network
configuration techniques used by access networks.
There are three well-known methods of bootstrapping:
1. Using the DHCP protocol
2. Using the PPP protocol
3. Using IEEE 802.1 LLDP-MED
For location information, there are two types: location information
regarding a civic address (e.g. 123 Main St ) and geospatial
information (e.g. x, y, z coordinates).
The set of configuration data types has not been discussed or
resolved. But the following types of configuration information have
been noted: 1) references to LCMS servers, 2) references to PSAPs,
and 3) references to location information servers.
References to LCMS servers obviate the need for global hierarchies
of LCMS data directories (which have proven politically difficult in
other voice over IP matters) and reduce the coordination to only the
necessary jurisdictional boundaries.
References to PSAPs obviate the need for the mapping steps in cases
where location is not likely to be a determining factor in emergency
call routing (e.g. location is fixed and the emergency call center
is known).
References to location information servers enable better separation
Polk & Newton Expires Sept 6th, 2006 [Page 5]
Internet-Draft ECRIT Arch Considerations Mar 2006
for knowledge of location from the access network.
3. Conversion
Conversion of location information from one format to the other
format is conducted for the benefit of the LCMS servers and
conveyance of the location information. There are two aspects to
this conversion: syntactic conversion of the location information
from the binary formats used in bootstrapping to the XML format used
in PIDF-LO, and conversion of the civic location information to
geospatial location information or vice versa.
Syntactic conversion is a necessary function, and it can take two
different forms: conversion from the binary DHCP format to the
PIDF-LO conveyance format and conversion to a LCMS format if the
LCMS interface does not use PIDF-LO.
Conversion of location information from a civic address to
geospatial coordinates or from geospatial coordinates to a civic
address is much more controversial. There is no doubt that civic
addresses are much easier to consume by humans than geospatial
coordinates, however conversion from geospatial coordinates to a
civic address can be error prone and in cases involving large areas
(e.g. a farm, an outdoor park, etc
) the resulting civic address can
be of limited utility. Further, civic coordinates only address
a fraction of the land of this planet, as civic addresses are to a
great degree tied to the existence of a nearby street, which are
prevalent in cities, but are scarce to non-existent in rural areas.
Therefore, a combination of the two formats will be required
regardless of mankind's consumption preference.
4. LCMS Mapping
The creation of an LCMS, which will convert location information
into references (i.e. URIs) to emergency call centers, is the
primary area of work for the ECRIT working group. There are two
times in which this LCMS function can occur successfully:
1. before the device attempts contact with a PSAP, and
2. after the device initiates contact with the PSAP, but before the
correct PSAP is determined by the ESRP making the LCMS query.
Accomplishing mapping of a device's location with the proper PSAP
can be done statically or dynamically, or in a layered - combination
- approach.
Statically - If a site is small enough, for example residential or
Small or single building business scale, all devices in either of
these types of locations can be configured to download, or have
Polk & Newton Expires Sept 6th, 2006 [Page 6]
Internet-Draft ECRIT Arch Considerations Mar 2006
downloaded to them, their location information and the SIP or
SIPS URI for contacting the appropriate PSAP for that location.
Dynamically - for the above types of locations, or for larger
locations, the client's location can be used to "look up" the
appropriate PSAP SIP or SIPS URI, and have this configuration
information downloaded to each client requesting it. This can
also be pushed to all clients regardless of whether they asked
for the information or not. This pushing of the PSAP URI(s) can
be at some interval to maintain freshness of the URI(s), as stale
URI(s) are a concern to some.
For the static configuration, for each given endpoint or section of
a network, a known PSAP SIP or SIPS URI is downloaded to the
client(s) without the clients providing their individual location to
perform the LCMS function. In the case of dynamic configuration of
a URI, the client provides their location to an LCMS server to do
this look-up, with the answer sent to the client for future use by
any application on that client, including for emergency services.
In a layered approach, there does not need to be a one-size-fits-all
solution, but a combination of ways in which the mapping resolution
is accomplished towards the goal of having the emergency call set-up
reach the appropriate PSAP. For example, a solution with the most
risk can be used last, but in a way it does not rely on any other
steps to have occurred to function properly. In this scenario, the
simplest means of mapping with the least risk can be performed
initially, before the device ever knows it will generate an
emergency call set-up message. In this way, this first mechanism is
done at boot-time, and the mapping during the actual emergency call
can still happen whether or not the bootstrapping took place or not.
This layered approach would be with a goal of solving the function
of mapping one of the independent steps towards entering the
appropriate PSAP SIP or SIPS URI into the INVITE message. When this
URI is learned should not matter, as long as it is the appropriate
URI.
Another combined approach can be attained in the following scenario:
if the endsystem knows of an authoritative LCMS server regardless of
which network or domain the client is connected to, the endsystem
can contact this server to get its PSAP SIP/SIPS URI based on its
location provided by the local access network. In this scenario, an
endsystem can have a trust association established with a particular
server (or server service) that it contacts as soon as it either
learns its location from a local network/domain or somehow
determines it has moved while remaining "connected" to that
network/domain.
For the device configuration of a PSAP SIP or SIPS URI, currently
only DHCP is being proposed as a solution [ID-DHCP-URI]. This
proposal is not an LCMS function because it does not send location
to a server and receive the mapping answer containing a URI. DHCP
Polk & Newton Expires Sept 6th, 2006 [Page 7]
Internet-Draft ECRIT Arch Considerations Mar 2006
is used here to only deliver the URI to be used as the Request-URI
of the emergency SIP INVITE.
To date there are three protocol proposals for LCMS: LUMP, ECON, and
DNS SOS. LUMP is an XML-based, SOAP solution with emphasis on data
distribution. ECON is an XML-based, IRIS solution with emphasis on
lightweight data exchange, and DNS SOS is a DNS-based solution with
emphasis on re-using DNS semantics.
Finally, some jurisdictions may find it necessary to withdraw the
LCMS protocol from public view and place its function within an
ESRP. At the option of the jurisdiction, more than one ESRP function
may be implemented in series, to provide increasingly precise
routing to the appropriate PSAP.
5. Conveyance
5.1 Location Conveyance
Once the address of the PSAP is known, either through bootstrapping
or through LCMS mapping, a call can be initiated with the PSAP.
Location information is sent to the PSAP as meta-data of the call
using PIDF-LO. This facet is not part of the ECRIT WG, but cannot
be overlooked. Even if the caller contacts the appropriate PSAP,
that PSAP will still require knowledge of where the caller is in
order to dispatch emergency responders (i.e. help). Issues
regarding the acquisition of this knowledge are discussed in Section
7.2.
Passing location information within the voice application protocol
is commonly referred to as "location-by-value". There exists
another concept where a reference to a location server is passed
within the voice application protocol instead of the actual location
information. This is known a "location-by-reference". Location-by-
reference is not without controversy, and its plusses and minuses
will be discussed in a future version of this document.
5.2 Identity Conveyance
There is a general desire on behalf of PSAP operators to have the
identity of a caller conveyed within a call. This identity has two
parts: an identity asserted to be authentic and a call-back
reference for re-establishment of communications.
Of the two parts of this identity conveyance, the authentication of
the identity is the most contentious and burdensome to solve. For
example, if a traveler with a phone purchased in London were to make
an emergency phone call in New York, what trust relationship exists
between the authorities of New York and a phone retailer in London?
Making matters more complicated, conveyance of identity for
Polk & Newton Expires Sept 6th, 2006 [Page 8]
Internet-Draft ECRIT Arch Considerations Mar 2006
emergency calling is not a work item for any IETF working group.
6. Universal Emergency Identifiers
Throughout the world, there are many different numbers in use to
signal emergency phone calls. Some counts have this number as high
as 60 unique number sequences worldwide. This lack of uniformity
also leads to collision. For example, in some areas of the world,
dialing the number 0 is used for calling for help, whereas in other
parts of the world, this would not accomplish its intended emergency
meaning, resulting in the caller being told to hang up and dial
another number.
Therefore, one of the ECRIT requirements is for a universal
emergency identifier to signal an emergency. The need for it to be
universal (or well-known) is threefold: so that all the components
in the emergency call routing process may properly operate based on
its presence in a message, to avoid collisions with other purposes
(as stated above), and so that clients may localize its meaning to
end users. The issue is that there is not just one single
identifier related to emergency calls, but that there are many
identifiers related to emergency calls for various specific types of
emergencies.
Multiple identifiers lead to confusion and many have overlapping
meaning. For example, the separate identifiers "mountain" and
"rescue" could mean the same thing to a user needing to be rescued
from a mountainous area. Additionally, some jurisdictions have
custom identifiers that are either unused globally or have a limited
applicability.
Each LCMS proposal takes a different approach to solving this
problem. ECON takes the simplest approach, specifying a simple list
of 3 identifiers. DNS SOS specifies a list of six identifiers. LUMP
specifies a hierarchy of identifiers.
What is not clear, or has not been well defined, is the need for
even the simplest of these approaches. It is not even well
understood if end users, in an emergency situation, will be able to
rationalize the difference between "emergency" and a simple list of
"police", "fire", and "medical". While some have suggested this is
in practice in some parts of the world today, that does not
necessarily mean this will become universal in usage. It appears
that if there is a single master identifier with more than one sub-
identifier, that this arrangement should be used where it is
understood, and perhaps adopted elsewhere as jurisdictions decide to
segment this capability based on education within that area.
What appears obvious to avoid is to have different identifiers for
help in different parts of the world moving forward. If only
'sos.police@...' reaches the police in a country where Alice does
Polk & Newton Expires Sept 6th, 2006 [Page 9]
Internet-Draft ECRIT Arch Considerations Mar 2006
not live when she sends a SIP INVITE to 'sos@...', ECRIT as a WG has
not likely accomplished its goal.
Locales that choose to have sub-identifiers for granularity must
have an architected solution for the higher level identifier as
well.
7. Security Considerations
7.1 Security of the LCMS
It is the goal of the working group to develop a dynamic LCMS
protocol that is both secure and responsive, two features that tend
to conflict with each other. Security for this mapping solution has
fallen into two broad categories: object signing and channel
security.
Object signing has three benefits: integrity of data during
distribution, the potential for utilization in UDP packets, and pre-
calculation of cryptographic data. However, in cases where partial
matching of the query are to be allowed (i.e. parts of a civic
address are to be ignored in the query) or the query cannot be known
ahead of time (i.e. the whole set of geospatial coordinates is
known but not in practical terms), object signing will require "on-
line" signing which negates advantages in data distribution and
cryptographic pre-calculations.
In addition, the use case regarding the invalidity of a signed
object may be no different from that of a validly signed object.
Users confronted with an emergency may not be able to appreciate the
difference in validity, and even if they did, may not alter their
course of action (i.e. they continue with the emergency call
anyway).
Channel security requires expensive cryptographic calculations that
cannot be computed ahead of time and requires multiple packet
exchanges (i.e. roundtrips) to establish. However, this approach
has the benefit of securing all parts of the transaction, and unlike
object signing, is well used and well understood on the Internet.
The security properties of each of the three LCMS proposals is as
follows:
LUMP uses both channel security (TLS connections to the query
server) and object signing (signed entries in the database).
DNS SOS uses both channel security (TLS in connections to fetching
polygons and other information) and object signing (in DNSSEC
for the protection of NAPTR records).
ECON uses channel security (TLS connections to the query server) as
Polk & Newton Expires Sept 6th, 2006 [Page 10]
Internet-Draft ECRIT Arch Considerations Mar 2006
an option setup by the operator of the service and a lightweight
UDP transfer protocol for scenarios where security is not
needed.
7.2 Security of Location Conveyance
There is a general desire to protect PSAPs from malicious calls.
Yet, how this is to be accomplished is not clear or well defined.
Complicating this issue is the simple fact that many PSAPs will
accept a call without location information related to the caller.
Additionally, many PSAPs give priority or parity to location
information collected by a human operator from a human caller. Due
to this fact, it has been observed that any security mechanism put
into place by ECRIT can simply be routed around by directly
contacting a PSAP.
In cases where a PSAP would wish to disregard calls of unknown
provenance, no guidelines have clearly been stated as to how such
trust relationships would be erected.
7.3 Security of Bootstrapping
Where critical decisions might be based on the value(s) of the
bootstrapping process, such as a URI option from [ID-DHC-URI], DHCP
authentication in [RFC3118] SHOULD be used to protect the integrity
of the DHCP options.
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the client and
destination DHCP server to capture any URIs in transit.
When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.
All that said, if DNS is not secure, and bootstrapping is difficult
to secure based on what it takes to accomplish [RFC3118], is
securing the mapping service worth the effort and pain to achieve?
7.4 Security of Conversion
Location is a vital part of emergency messaging. As discussed
earlier, an endsystem will not likely be in control of which format
of location it receives from a roamed to network. For more fixed
endsystems, this should not be the case. If an endsystem does
receive location in a format it knows an application on that
endsystem does not prefer, the endsystem can contact a server or
service, if one is known, to convert this format to the other
format.
Polk & Newton Expires Sept 6th, 2006 [Page 11]
Internet-Draft ECRIT Arch Considerations Mar 2006
As a non-emergency example, most humans understand street addresses
much better than GPS coordinates. If a roaming device, say using
802.11 at a hotspot, acquires its location via DHCP Option 123 [RFC
3825], it can determine if an application used by that device
prefers the civic format when using an instant messaging application
on that device. Before the IM application is launched, or as the
app is launched, the device can seek a conversion server to perform
this format conversion operation. How does a client learn of a
server that can do this? [ID-DHC-URI] provides one means for a
device to learn the URL of a server that can do this function, or
this can be preconfigured in the device as a trusted source for this
conversion, wherever it is - as long as there is connectivity to
that trusted source.
In the emergency case, perhaps the device knows it needs to convert
to the civic format to have an ESRP perform an LCMS query, but the
local network gave it a geospatial location only. If the conversion
server is preconfigured, this provides the ability to have the two
devices, say the phone and the conversion server, establish a trust
relationship, perhaps with pre-shared keys. This reduces the round
trip times, making it more efficient. This also provides a more
secure means of communication since both entities 'know' each other.
8. Data distribution
There is a desire to locate LCMS data in the LCMS close to the
points of query in the Internet for performance reasons. In
addition, some jurisdictions distribute authority for this data upon
hierarchical lines. However, the needs for data distribution beyond
these high-level requirements are not well known. For instance, the
known life expectancy of data distributed to caches is not well
known, nor are update procedures in the distribution of this data.
Each of the three LCMS proposals addresses this problem in a
different way:
DNS SOS relies upon the cache machinery of DNS. The population of
DNS caches with location information is accomplished through
validation of caller locations (a process during provisioning of
a callers location and before any emergency call). This proposal
does not address early cache expiration due to limited cache
memory, by accepted practices of DNS operations, or by routine
maintenance of DNS servers.
LUMP defines a caching mechanism that identifies objects by hash
value in order to accomplish a mesh of caches between nodes. The
population of the caches with location information is
accomplished through validation of caller locations (a process
conducted during provisioning of a callers location and before
any emergency call).
Polk & Newton Expires Sept 6th, 2006 [Page 12]
Internet-Draft ECRIT Arch Considerations Mar 2006
ECON defines no preference for data distribution due to the limited
requirements available. However, it does describe two methods
that could be employed: the serialization of data to files for
distribution via standard transfer protocols and an on-line,
incremental approach capable of distributing entries before their
activation date.
9. Extensibility
Within the ECRIT working group, there appears to be rough consensus
on the need for extensible mechanisms, and hence an extensible LCMS
protocol capable of extensions in its query interface and resulting
output. This desire for extensibility is born from a general sense
that not all the problems of emergency call routing over the
Internet will be fully exposed until deployment of a first
generation solution and from a more specific sense of the
incompleteness of the civic address schema in PIDF-LO.
As an example of the more general case, the document [ID-ECRIT-
JAPAN] describes a numeric address code equivalent to the civic
elements <A1> through <A5> in PIDF-LO used in conjunction with
geospatial coordinates to conduct emergency call handling in Japan.
As an example of the more specific case, PIDF-LO does not contain an
element to describe street section numbers as used in Taiwan.
10. Conflation
As mentioned in the introduction, many of the components used in the
process of routing emergency calls were not designed primarily for
this task and are being developed in working groups that do not have
emergency call routing explicitly defined in their chartered scope.
As a general example, conveyance of location information within a
call also has applicability to delivery businesses, such as pizza
restaurants that need to know the location of the caller for
delivery purposes. In a more technical sense, much of what is known
about civic addresses worldwide is a result of the study of postal
delivery, and therefore schemas used as location input for emergency
call routing may not be tuned properly.
Within the ECRIT working group, there are no requirements regarding
the resilience of the emergency call routing process as it relates
to inputs that have not been designed for this specific purpose.
11. Rerouting/Transfer
Another facet of the ECRIT WG that has not been addressed is what to
do if a PSAP receives an emergency call and the call should not have
been routed to that PSAP. What does the PSAP do next, and can this
Polk & Newton Expires Sept 6th, 2006 [Page 13]
Internet-Draft ECRIT Arch Considerations Mar 2006
action be automated? Does the PSAP have an additional screening
capability in some ESRP at the PSAP interior edge to do a final
check that the call set-up is to the appropriate PSAP, taking steps
not yet defined if this PSAP is not the appropriate one for this
particular call set-up?
This is more a rerouting function of the call set-up, or of a call
transfer function if the call is answered before determining this is
an inappropriate PSAP. For example, VPNs will likely cause some
emergency calls to go erroneously to the city that the caller's
corporate offices are located in rather than to where the caller is.
This has not been considered to date, yet likely should be - as
message reroute should be possible anytime an ESRP misdirects a
message towards a PSAP, just not he appropriate PSAP.
12. Acknowledgements
Nadine Abbott provided text regarding ESRP usage and comments
regarding the inclusion of discussion of location-by-value vs.
location-by-reference. Richard Statsny suggested this document
would be a more complete introduction to the problem space if it
included information regarding identity conveyance.
13. References
13.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
13.2 Informative References
[ID-DHC-URI] J. Polk, "A Dynamic Host Configuration Protocol Option
for Requesting and Receiving Uniform Resource Identifiers",
draft-polk-dhc-uri-03.txt, "work in progress", March 2006
[ID-ECRIT-JAPAN] H. Arai, M. Kawanishi, draft-arai-ecrit-japan-req-
01.txt, "work-in-progress", May 2005
Author's Address
James M. Polk
Polk & Newton Expires Sept 6th, 2006 [Page 14]
Internet-Draft ECRIT Arch Considerations Mar 2006
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Fax: none
Email: jmpolk@cisco.com
Andrew Newton
21345 Ridgetop Circle
Dulles, VA 20166
Phone: +17039483382
Email: andy@hxr.us
Appendix A. Additional stuff
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
Polk & Newton Expires Sept 6th, 2006 [Page 15]
Internet-Draft ECRIT Arch Considerations Mar 2006
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk & Newton Expires Sept 6th, 2006 [Page 16]