Emergency Context Resolution with Internet Technologies (ecrit) Internet Drafts
| LoST: A Location-to-Service Translation Protocol | |||||||||||||||||
|
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. | ||||||||||||||||
| Location-to-URL Mapping Architecture and Framework | |||||||||||||||||
|
This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. | ||||||||||||||||
| Best Current Practice for Communications Services in support of Emergency Calling | |||||||||||||||||
|
The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. | ||||||||||||||||
| Framework for Emergency Calling using Internet Multimedia | |||||||||||||||||
|
The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. | ||||||||||||||||
| A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure | |||||||||||||||||
|
The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). | ||||||||||||||||
| Location Hiding: Problem Statement and Requirements | |||||||||||||||||
|
The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to-Service Translation (LoST) Protocol is envisioned. This document explores the architectural impact for the IETF emergency services architecture for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document provides a problem statement and lists requirements. | ||||||||||||||||
| Specifying Holes in LoST Service Boundaries | |||||||||||||||||
|
This document describes how holes can be specified in service boundaries. One means of implementing a solution is described. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
Emergency Context Resolution with Internet Technologies (ecrit)
Last Modified: 2008-04-23
Additional information is available at tools.ietf.org/wg/ecrit
Chair(s):
Real-time Applications and Infrastructure Area Director(s):
Real-time Applications and Infrastructure Area Advisor:
Secretary(ies):
Mailing Lists:
General Discussion: ecrit@ietf.orgTo Subscribe: https://www1.ietf.org/mailman//listinfo/ecrit
Archive: http://www.ietf.org/mail-archive/web/ecrit/index.html
Description of Working Group:
In a number of areas, the public switched telephone network (PSTN) hasbeen configured to recognize an explicitly specified number (commonly
one that is short and easily memorized) as a call for emergency
services. These numbers (e.g. 911, 112) relate to an emergency
service context and depend on a broad, regional configuration of
service contact methods and a geographically-constrained context of
service delivery. These calls are intended to be delivered to special
call centers equipped to manage emergency response. Successful
delivery of an emergency service call within those systems requires
both an association of the physical location of the originator with an
appropriate emergency service center and call routing to deliver the
call to the center.
Calls placed using Internet technologies do not use the same systems
to achieve those goals, and the common use of overlay networks and
tunnels (either as VPNs or for mobility) makes meeting them more
challenging. There are, however, Internet technologies available to
describe location and to manage call routing. This working group will
describe when these may be appropriate and how they may be used.
Explicitly outside the scope of this group is the question of
pre-emption or prioritization of emergency services traffic. This
group is considering emergency services calls which might be made by
any user of the Internet, as opposed to government or military
services that may impose very different authentication and routing
requirements.
The group will show how the availability of location data and call
routing information at different steps in session setup would enable
communication between a user and a relevant emergency response
center. Though the term "call routing" is used in this document, it
should be understood that some of the mechanisms which will be
described might be used to enable other types of media streams. Video
and text messaging, for example, might be used to request emergency
services.
While this group anticipates a close working relationship with groups
such as NENA and ETSI EMTEL, any solution presented must be useful
regardless of jurisdiction, and it must be possible to use without a
single, central authority. Further, it must be possible for multiple
delegations within a jurisdiction to be handled independently, as call
routing for specific emergency types may be independent.
This working group cares about privacy and security concerns, and will
address them within its documents.
Goals and Milestones:
| Done | Informational RFC containing terminology definitions and the requirements | |
| Done | An Informational document describing the threats and security considerations | |
| Done | A Standards Track RFC describing how to identify a session set-up request is to an emergency response center | |
| Done | A Standards Track RFC describing how to route an emergency call based on location information | |
| Done | An Informational document describing the Mapping Protocol Architecture | |
| Feb 2008 | An Informational document describing the ECRIT Framework | |
| Feb 2008 | A BCP document describing the emergency call support for devices |
Internet-Drafts:
LoST: A Location-to-Service Translation Protocol (126418 bytes)Location-to-URL Mapping Architecture and Framework (43321 bytes)
Best Current Practice for Communications Services in support of Emergency Calling (103065 bytes)
Framework for Emergency Calling using Internet Multimedia (95476 bytes)
A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure (16684 bytes)
Location Hiding: Problem Statement and Requirements (18243 bytes)
Specifying Holes in LoST Service Boundaries (25238 bytes)
Request For Comments:
Requirements for Emergency Context Resolution with Internet Technologies (RFC 5012) (54599 bytes)A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (RFC 5031) (32960 bytes)
Security Threats and Requirements for Emergency Call Marking and Mapping (RFC 5069) (26230 bytes)
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
