draft-ietf-ecrit-mapping-arch-04.txt   rfc5582.txt 
ECRIT H. Schulzrinne Network Working Group H. Schulzrinne
Internet-Draft Columbia U. Request for Comments: 5582 Columbia U.
Intended status: Informational March 5, 2009 Category: Informational September 2009
Expires: September 6, 2009
Location-to-URL Mapping Architecture and Framework Location-to-URL Mapping Architecture and Framework
draft-ietf-ecrit-mapping-arch-04.txt
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 This document describes an architecture for a global, scalable,
http://www.ietf.org/ietf/1id-abstracts.txt. resilient, and administratively distributed system for mapping
geographic location information to URLs, using the Location-to-Service
Translation (LoST) protocol. The architecture generalizes well-known
approaches found in hierarchical lookup systems such as DNS.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2009. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 5 4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 4
4.1. The Principal Components . . . . . . . . . . . . . . . . . 5 4.1. The Principal Components . . . . . . . . . . . . . . . . . 4
4.2. Minimal System Architecture . . . . . . . . . . . . . . . 7 4.2. Minimal System Architecture . . . . . . . . . . . . . . . 6
5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8
7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 11 7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10
7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11 7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11
7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 12 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11
8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
It is often desirable to allow users to access a service that It is often desirable to allow users to access a service that
provides a common function, but is actually offered by a variety of provides a common function but that is actually offered by a variety
local service providers. In many of these cases, the service of local service providers. In many of these cases, the service
provider chosen depends on the location of the person wishing to provider chosen depends on the location of the person wishing to
access that service. Among the best-known public services of this access that service. Among the best-known public services of this
kind is emergency calling, where emergency calls are routed to the kind is emergency calling, where emergency calls are routed to the
most appropriate public safety answering point (PSAP), based on the most appropriate public safety answering point (PSAP) based on the
caller's physical location. Other services, from food delivery to caller's physical location. Other services, from food delivery to
directory services and roadside assistance, also follow this general directory services and roadside assistance, also follow this general
pattern. This is a mapping problem [RFC5012], where a geographic pattern. This is a mapping problem [RFC5012], where a geographic
location and a service identifier (URN) [RFC5031] is translated into location and a service identifier [RFC5031] is translated into a set
a set of URIs, the service URIs, that allow the Internet system to of URIs, the service URIs, that allow the Internet system to contact
contact an appropriate network entity that provides the service. an appropriate network entity that provides the service.
The caller does not need to know where the service is being provided The caller does not need to know from where the service is being
from, and the location of the service provider may change over time, provided, and the location of the service provider may change over
e.g., to deal with temporary overloads, failures in the primary time, e.g., to deal with temporary overloads, failures in the primary
service provider location or long-term changes in system service provider location, or long-term changes in system
architecture. For emergency services, this problem is described in architecture. For emergency services, this problem is described in
more detail in [I-D.ietf-ecrit-framework]. more detail in [ECRIT-FRAME].
The overall emergency calling architecture [I-D.ietf-ecrit-framework] The overall emergency calling architecture [ECRIT-FRAME] separates
separates mapping from placing calls or otherwise invoking the mapping from placing calls or otherwise invoking the service, so the
service, so the same mechanism can be used to verify that a mapping same mechanism can be used to verify that a mapping exists ("address
exists ("address validation") or to obtain test service URIs. validation") or to obtain test service URIs.
Mapping locations to URIs describing services requires a distributed, Mapping locations to URIs that describe services requires a
scalable and highly resilient infrastructure. Authoritative distributed, scalable, and highly resilient infrastructure.
knowledge about such mappings is distributed among a large number of Authoritative knowledge about such mappings is distributed among a
autonomous entities that may have no direct knowledge of each other. large number of autonomous entities that may have no direct knowledge
In this document, we describe an architecture for such a global of each other. In this document, we describe an architecture for
service. It allows significant freedom to combine and split such a global service. It allows significant freedom to combine and
functionality among actual servers and imposes few requirements as to split functionality among actual servers and imposes few requirements
who should operate particular services. as to who should operate particular services.
Besides determining the service URI, end systems also need to Besides determining the service URI, end systems also need to
determine the local service numbers. As discussed in Section 9, the determine the local service numbers. As discussed in Section 9, the
architecture described here can also address that problem. architecture described here can also address that problem.
The architecture described here uses the Location-to-Service The architecture described here uses the Location-to-Service
Translation (LoST) [RFC5222] protocol, although much of the Translation (LoST) [RFC5222] protocol, although much of the
discussion would also apply for other mapping protocols satisfying discussion would also apply for other mapping protocols satisfying
the mapping requirements [RFC5012]. the mapping requirements [RFC5012].
skipping to change at page 4, line 19 skipping to change at page 3, line 42
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Definitions 3. Definitions
In addition to the terms defined in [RFC5012], this document uses the In addition to the terms defined in [RFC5012], this document uses the
following terms to describe LoST clients and servers: following terms to describe LoST clients and servers:
authoritative mapping server (AMS): An authoritative mapping server authoritative mapping server (AMS): An authoritative mapping server
(AMS) is a LoST server that can provide the authoritative answer (AMS) is a LoST server that can provide the authoritative answer
to a particular set of queries, e.g., covering a set of PIDF-LO to a particular set of queries, e.g., covering a set of Presence
civic labels or a particular region described by a geometric Information Data Information Location Object (PIDF-LO) civic
shape. In some (rare) cases of territorial disputes, two labels or a particular region described by a geometric shape. In
resolvers may be authoritative for the same region. An AMS may some (rare) cases of territorial disputes, two resolvers may be
redirect or forward a query to another AMS within the tree. authoritative for the same region. An AMS may redirect or forward
a query to another AMS within the tree.
child: A child is an AMS that is authoritative for a subregion of child: A child is an AMS that is authoritative for a subregion of
another AMS. A child can in turn be parent for another AMS. another AMS. A child can in turn be parent for another AMS.
(tree node) cluster: A node cluster is a group of LoST servers that (tree node) cluster: A node cluster is a group of LoST servers that
all share the same mapping information and return the same results all share the same mapping information and return the same results
for queries. Clusters provide redundancy and share query load. for queries. Clusters provide redundancy and share query load.
Clusters are fully-meshed, i.e., they all exchange updates with Clusters are fully-meshed, i.e., they all exchange updates with
each other. each other.
coverage region: The coverage region of an AMS is the geographic coverage region: The coverage region of an AMS is the geographic
region within which the AMS is able to authoritatively answer region within which the AMS is able to authoritatively answer
mapping queries. Coverage regions are generally, but not mapping queries. Coverage regions are generally, but not
necessarily, contigous and may be represented as either a subset necessarily, contiguous and may be represented as either a subset
of a civic address or a geometric object. of a civic address or a geometric object.
forest guide (FG): A forest guide (FG) has knowledge of the coverage forest guide (FG): A forest guide (FG) has knowledge of the coverage
region of trees for a particular top-level service. region of trees for a particular top-level service.
mapping: A mapping is a short-hand for 'mapping from a location mapping: A mapping is a short-hand for 'mapping from a location
object to one or more URLs describing either another mapping object to either another mapping server or the desired service
server or the desired service URLs'. URLs'.
parent: A mapping server that covers the region of all of its parent: A mapping server that covers the region of all of its
children. A mapping server without a parent is a root AMS. children. A mapping server without a parent is a root AMS.
resolver: A resolver is contacted by a seeker, consults a forest resolver: A resolver is contacted by a seeker, consults a forest
mapping server and then resolves the query using an appropriate mapping server, and then resolves the query using an appropriate
tree. Resolvers may cache query results. tree. Resolvers may cache query results.
seeker: A seeker is a LoST client requesting a mapping. A seeker seeker: A seeker is a LoST client requesting a mapping. A seeker
does not provide mapping services to others, but may cache results does not provide mapping services to others but may cache results
for its own use. for its own use.
tree: A tree consists of a self-contained hierarchy of authoritative tree: A tree consists of a self-contained hierarchy of authoritative
mapping servers for a particular service. Each tree exports its mapping servers for a particular service. Each tree exports its
coverage region to the forest mapping servers. coverage region to the forest mapping servers.
4. Overview of Architecture 4. Overview of Architecture
4.1. The Principal Components 4.1. The Principal Components
The mapping architecture distinguishes four logical roles: seekers, The mapping architecture distinguishes four logical roles: seekers,
resolvers, authoritative mapping servers (AMS) and forest guides resolvers, authoritative mapping servers (AMS), and forest guides
(FGs). End users of the LoST-based [RFC5222] mapping mechanism, (FGs). End users of the LoST-based [RFC5222] mapping mechanism,
called seekers, contact resolvers that cache query results and know called seekers, contact resolvers that cache query results and know
one or more forest guides. Forest guides form the top level of a one or more forest guides. Forest guides form the top level of a
conceptual hierarchy, with one or more trees providing a hierarchical conceptual hierarchy, with one or more trees providing a hierarchical
resolution service for different geographic regions. Forest guides resolution service for different geographic regions. Forest guides
know the geographic coverage region of all or almost all trees and know the geographic coverage region of all or almost all trees and
direct queries to the node at the top of the appropriate tree. Trees direct queries to the node at the top of the appropriate tree. Trees
consist of authoritative mapping servers and maintain the consist of authoritative mapping servers and maintain the
authoritative mapping information. authoritative mapping information.
Seekers, resolvers, authoritative mapping servers and forest guides Seekers, resolvers, authoritative mapping servers, and forest guides
all communicate using LoST; indeed, it is likely that in many cases, all communicate using LoST; indeed, it is likely that, in many cases,
the same software can operate as a resolver, authoritative mapping the same software can operate as a resolver, authoritative mapping
server and forest guide. In addition to the basic LoST query server, and forest guide. In addition to the basic LoST query
protocol [RFC5222], a synchronization protocol protocol [RFC5222], a synchronization protocol [LOST-SYNC] may be
[I-D.schulzrinne-ecrit-lost-sync] may be used to exchange information used to exchange information between forest guides or to push
between forest guides or to push coverage information from a tree coverage information from a tree node to its parent.
node to its parent.
Seekers may be part of VoIP or other end systems, or SIP proxies or Seekers may be part of Voice over IP (VoIP) or other end systems, or
similar call routing functions. of SIP proxies or similar call routing functions.
Figure 1 shows the interaction of the components. The lines Figure 1 shows the interaction of the components. The lines
indicating the connection between the forest guides are logical indicating the connection between the forest guides are logical
connections, indicating that they are synchronizing their information connections, indicating that they are synchronizing their information
via the synchronization protocol [I-D.schulzrinne-ecrit-lost-sync]. via the synchronization protocol [LOST-SYNC].
/-\ /-\ +-----+ +-----+ /-\ /-\ +-----+ +-----+
| S +******* R ********* FG *-----------------+ FG | | S +******* R ********* FG *-----------------+ FG |
\-/ \-/ | |* | | \-/ \-/ | |* | |
+--+--+ * +--+--+ +--+--+ * +--+--+
| * | | * |
| * | | * |
| * | | * |
| * | | * |
/-\ +--+--+ * +--+--+ /-\ +--+--+ * +--+--+
skipping to change at page 6, line 29 skipping to change at page 5, line 47
| * | | * |
|*** ^ |*** ^
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
----------- ----------- ----------- -----------
tree tree tree tree
Architecture diagram, showing seekers (S), resolvers (R), forest Architecture diagram, showing seekers (S), resolvers (R), forest
guides (FG) and trees. The star (*) line indicates the flow of the guides (FG), and trees. The star (*) line indicates the flow of the
query and responses in recursive mode, while the lines indicate query and responses in recursive mode, while the lines indicate
synchronization relationships. synchronization relationships.
Figure 1 Figure 1
The mapping function for the world is divided among trees. The The mapping function for the world is divided among trees. The
collection of trees may not cover the whole world and trees are added collection of trees may not cover the whole world, and trees are
and removed as the organization of mapping data changes. We call the added and removed as the organization of mapping data changes. We
collection of trees a forest. There is no limit on the number of call the collection of trees a forest. There is no limit on the
trees within the forest, but the author guesses that the number of number of trees within the forest, but the author guesses that the
trees will likely be somewhere between a few hundred and a few number of trees will likely be somewhere between a few hundred and a
thousand. The lower estimate would apply if each country operates few thousand. The lower estimate would apply if each country
one tree, the higher if different governmental or private operates one tree, the higher if different governmental or private
organizations within a country operate independent trees. We assume organizations within a country operate independent trees. We assume
that tree coverage information changes relatively slowly, on the that tree coverage information changes relatively slowly, on the
order of less than one change per year per tree, although the system order of less than one change per year per tree, although the system
imposes no specific threshold. Tree coverage would change, for imposes no specific threshold. Tree coverage would change, for
example, if a country is split or merged or if two trees for example, if a country is split or merged or if two trees for
different regions become part of a larger tree. (On the other hand, different regions become part of a larger tree. (On the other hand,
information within a tree is likely to change much more frequently.) information within a tree is likely to change much more frequently.)
4.2. Minimal System Architecture 4.2. Minimal System Architecture
skipping to change at page 7, line 29 skipping to change at page 6, line 44
Below, we describe the operation of each component in more detail. Below, we describe the operation of each component in more detail.
5. Seeker 5. Seeker
Clients desiring location-to-service mappings are known as seekers. Clients desiring location-to-service mappings are known as seekers.
Seekers are consumers of mapping data and originate LoST queries as Seekers are consumers of mapping data and originate LoST queries as
LoST protocol clients. Seekers do not answer LoST queries. They LoST protocol clients. Seekers do not answer LoST queries. They
contact either forest guides or resolvers to find the appropriate contact either forest guides or resolvers to find the appropriate
tree that can authoritatively answer their questions. Seekers can be tree that can authoritatively answer their questions. Seekers can be
end systems such as SIP user agents or call routing entities such as end systems such as SIP user agents, or call routing entities such as
SIP proxy servers. SIP proxy servers.
Seekers may need to obtain mapping information in several steps, Seekers may need to obtain mapping information in several steps,
i.e., they may obtain pointers to intermediate servers that lead them i.e., they may obtain pointers to intermediate servers that lead them
closer to the final mapping. Seekers MAY cache query results for closer to the final mapping. Seekers MAY cache query results for
later use, but otherwise have no obligations to other entities in the later use but otherwise have no obligations to other entities in the
system. system.
Seekers need to be able to identify appropriate resolvers. The Seekers need to be able to identify appropriate resolvers. The
mechanism for providing seekers with that information is likely to mechanism for providing seekers with that information is likely to
differ depending on who operates the resolvers. For example, if the differ depending on who operates the resolvers. For example, if the
voice service provider operates the resolver, it might include the voice service provider operates the resolver, it might include the
location of the resolver in the SIP configuration information it location of the resolver in the SIP configuration information it
distributes to its user agents. An Internet access provider or distributes to its user agents. An Internet access provider or
enterprise can provide a pointer to a resolver via DHCP [RFC5223]. enterprise can provide a pointer to a resolver via DHCP [RFC5223].
In an ad-hoc or zero-configuration environment, appropriate service In an ad hoc or zero-configuration environment, appropriate service
directories may advertise resolvers. directories may advertise resolvers.
Like other entities in the system, seekers can cache responses. This Like other entities in the system, seekers can cache responses. This
is particularly useful if the response describes the result for a is particularly useful if the response describes the result for a
civic or geospatial region, rather than just a point. For example, civic or geospatial region, rather than just a point. For example,
for mobile nodes, seekers would only have to update their resolution for mobile nodes, seekers would only have to update their resolution
results when they leave the coverage area of a service provider, such results when they leave the coverage area of a service provider, such
as a PSAP for emergency services, and can avoid repeatedly polling as a PSAP for emergency services, and can avoid repeatedly polling
for this information whenever the location information changes for this information whenever the location information changes
slightly. (Mobile nodes would also need a location update mechanism slightly. (Mobile nodes would also need a location update mechanism
skipping to change at page 8, line 28 skipping to change at page 7, line 43
obtain service area information along their commute route once during obtain service area information along their commute route once during
each cache lifetime. each cache lifetime.
6. Resolver 6. Resolver
A seeker can contact a forest guide (see below) directly, but may not A seeker can contact a forest guide (see below) directly, but may not
be able to easily locate such a guide. In addition, seekers in the be able to easily locate such a guide. In addition, seekers in the
same geographic area may already have asked the same question. Thus, same geographic area may already have asked the same question. Thus,
it makes sense to introduce another entity, known as a resolver in it makes sense to introduce another entity, known as a resolver in
the architecture, that knows how to contact one or more forest guides the architecture, that knows how to contact one or more forest guides
and caches earlier queries to accelerate the response to mapping and that caches earlier queries to accelerate the response to mapping
queries and to improve the resiliency of the system. Each resolver queries and to improve the resiliency of the system. Each resolver
can decide autonomously which FGs to use, with possibly different can decide autonomously which FGs to use, with possibly different
choices for each top-level service. choices for each top-level service.
ISPs or VSPs may include the address of a suitable resolver in their ISPs or Voice Service Providers (VSPs) may include the address of a
configuration information, e.g., in SIP configuration for a VSP or suitable resolver in their configuration information, e.g., in SIP
DHCP [RFC5223] for an ISP. Resolvers are manually configured with configuration for a VSP or DHCP [RFC5223] for an ISP. Resolvers are
the name of one or more forest guides. manually configured with the name of one or more forest guides.
7. Trees: Maintaining Authoritative Knowledge 7. Trees: Maintaining Authoritative Knowledge
7.1. Basic Operation 7.1. Basic Operation
The architecture assumes that authoritative knowledge about the The architecture assumes that authoritative knowledge about the
mapping data is distributed among many independent administrative mapping data is distributed among many independent administrative
entities, but clients (seekers) may potentially need to find out entities, but clients (seekers) may potentially need to find out
mapping information for any spot on earth. (Extensions to extra- mapping information for any spot on earth. (Extensions to extra-
terrestrial applications are left for future exploration.) terrestrial applications are left for future exploration.)
Information is organized hierarchically, in a tree, with tree nodes Information is organized hierarchically, in a tree, with tree nodes
representing larger geographic areas pointing to several child nodes representing larger geographic areas pointing to several child nodes,
each representing a smaller area. Each tree node can be a cluster of each representing a smaller area. Each tree node can be a cluster of
LoST servers that all contain the same information and back up each LoST servers that all contain the same information and back up each
other. other.
Each tree can map a location described by either civic or geographic Each tree can map a location described by either civic or geographic
coordinates, but not both, for one type of service (such as coordinates, but not both, for one type of service (such as
'sos.police', 'sos.fire' or 'counseling'), although nothing prevents 'sos.police', 'sos.fire' or 'counseling') and one location profile,
re-using the same servers for multiple different services or both although nothing prevents re-using the same servers for multiple,
types of coordinates. The collection of all trees for one service is different services or both types of coordinates. The collection of
known as a forest. all trees for one service and location profile is known as a forest.
Each tree root announces its coverage region to one or more forest Each tree root announces its coverage region to one or more forest
guides. guides.
Each tree node cluster knows the coverage region of its children and Each tree node cluster knows the coverage region of its children and
sends queries to the appropriate server "down" the tree. Each such sends queries to the appropriate server "down" the tree. Each such
tree node knows authoritatively about the service mappings for a tree node knows authoritatively about the service mappings for a
particular region, typically, but not necessarily, contiguous. The particular region, typically, but not necessarily, contiguous. The
region can be described by any of the shapes in the LoST region can be described by any of the shapes in the LoST
specification expressed in geospatial coordinates, such as circles or specification expressed in geospatial coordinates, such as circles or
polygons, or a set of civic address descriptors (e.g., "country = DE, polygons, or a set of civic address descriptors (e.g., "country = DE,
A1 = Bavaria"). These coverage regions may be aligned with political A1 = Bavaria"). These coverage regions may be aligned with political
boundaries, but that is not required. In most cases, to avoid boundaries, but that is not required. In most cases, to avoid
confusion, only one cluster is responsible for a particular confusion, only one cluster is responsible for a particular
geographic or civic location, but the system can also deal with cases geographic or civic location, but the system can also deal with cases
where coverage regions overlap. where coverage regions overlap.
There are no assumptions about the coverage region of a tree as a There are no assumptions about the coverage region of a tree as a
whole. For example, a tree could cover a single city, or a state/ whole. For example, a tree could cover a single city, a state/
province or a whole country. Nodes within a tree need to loosely province, or a whole country. Nodes within a tree need to loosely
coordinate their operation, but they do not need to be operated by coordinate their operation, but they do not need to be operated by
the same administrator. the same administrator.
The tree architecture is roughly similar to the domain name system The tree architecture is roughly similar to the domain name system
(DNS), except that delegation is not by label, but rather by region. (DNS), except that delegation is not by label but rather by region.
(Naturally, DNS does not have the notion of forest guides.) One can (Naturally, DNS does not have the notion of forest guides.) One can
also draw analogies to LDAP, when deployed in a distributed fashion. also draw analogies to the Lightweight Directory Access Protocol
(LDAP) when deployed in a distributed fashion.
Tree nodes maintain two types of information, namely coverage regions Tree nodes maintain two types of information -- namely, coverage
and mappings. Coverage regions describe the region served by a child regions and mappings. Coverage regions describe the region served by
node in the tree and point to a child node for further resolution. a child node in the tree and point to a child node for further
Mappings contain an actual service URI leading to a service provider resolution. Mappings contain an actual service URI leading to a
or another signaling server representing a group of service service provider or another signaling server representing a group of
providers, which in turn might further route signaling requests to service providers, which in turn might further route signaling
more servers covering smaller regions. requests to more servers covering smaller regions.
Leaf nodes, i.e., nodes without children, only maintain mappings, Leaf nodes, i.e., nodes without children, only maintain mappings,
while tree nodes above the leaf nodes only maintain coverage regions. while tree nodes above the leaf nodes only maintain coverage regions.
An example for emergency services of a leaf node entry is shown An example for emergency services of a leaf node entry is shown
below, indicating how queries for three towns are directed to below, indicating how queries for three towns are directed to
different PSAPs. Queries for Englewood are directed to another LoST different PSAPs. Queries for Englewood are directed to another LoST
server instead. server instead.
country A1 A2 A3 resource or LoST server country A1 A2 A3 resource or LoST server
US NJ Bergen Leonia sip:psap@leonianj.gov US NJ Bergen Leonia sip:psap@leonianj.gov
skipping to change at page 10, line 31 skipping to change at page 9, line 45
As a civic location example, a state-level tree node for New Jersey As a civic location example, a state-level tree node for New Jersey
in the United States may contain the coverage region entries shown in the United States may contain the coverage region entries shown
below, indicating that any query matching a location in Bergen below, indicating that any query matching a location in Bergen
County, for example, would be redirected or forwarded to the node County, for example, would be redirected or forwarded to the node
located at bergen.nj.example.org. located at bergen.nj.example.org.
There is no requirement that all child nodes cover the same level There is no requirement that all child nodes cover the same level
within the civic hierarchy. As an example, in the table below, the within the civic hierarchy. As an example, in the table below, the
city of Newark has decided to be listed directly within the state city of Newark has decided to be listed directly within the state
node, rather than through the county. Longest-match rules allow node, rather than through the county. Longest-match rules allow
partial coverage, so that for queries for all other towns within partial coverage so that queries for all other towns within Essex
Essex county would be directed to the county node for further county would be directed to the county node for further resolution.
resolution.
C A1 A2 A3 LoST server name C A1 A2 A3 LoST server name
US NJ Atlantic * atlantic.nj.example.org/sos US NJ Atlantic * atlantic.nj.example.org/sos
US NJ Bergen * bergen.nj.example.org/sos US NJ Bergen * bergen.nj.example.org/sos
US NJ Monmouth * monmouth.nj.example.org/sos US NJ Monmouth * monmouth.nj.example.org/sos
US NJ Essex * essex.nj.example.org/sos US NJ Essex * essex.nj.example.org/sos
US NJ Essex Newark newark.example.com/sos US NJ Essex Newark newark.example.com/sos
.... ....
Thus, there is no substantial difference between coverage region and Thus, there is no substantial difference between coverage region and
mapping data. The only difference is that coverage regions return mapping data. The only difference is that coverage regions return
names of LoST servers, while mapping entries contain service URLs. names of LoST servers, while mapping entries contain service URLs.
Mapping entries may be specific down to the house or floor level or Mapping entries may be specific down to the house- or floor-level or
may only contain street-level information. For example, in the may only contain street-level information. For example, in the
United States, civic mapping data for emergency services is generally United States, civic mapping data for emergency services is generally
limited to address ranges ("MSAG data"), so initial mapping databases limited to address ranges ("MSAG data"), so initial mapping databases
may only contain street-level information. may only contain street-level information.
To automate the maintenance of trees, the LoST synchronization To automate the maintenance of trees, the LoST synchronization
mechanism [I-D.schulzrinne-ecrit-lost-sync] allows nodes to query mechanism [LOST-SYNC] allows nodes to query other nodes for mapping
other nodes for mapping data and coverage regions, both within a data and coverage regions, both within a cluster and across different
cluster and across different hierarchy levels in a tree. In the hierarchy levels in a tree. In the example above, the state-run node
example above, the state-run node would query the county nodes and would query the county nodes and use the records returned to
use the records returned to distribute incoming LoST queries to the distribute incoming LoST queries to the county nodes. Conversely,
county nodes. Conversely, nodes could also contact their parent nodes could also contact their parent nodes to tell them about their
nodes to tell them about their coverage region. There is some coverage region. There is some benefit of child nodes contacting
benefit of child nodes contacting their parents, as this allows their parents, as this allows changes in coverage regions to
changes in coverage region to propagate quickly up the tree. propagate quickly up the tree.
7.2. Answering Queries 7.2. Answering Queries
Within a tree, the basic operation is straightforward: A query Within a tree, the basic operation is straightforward. A query
reaches the root of the tree. That node determines which coverage reaches the root of the tree. That node determines which coverage
region matches that request and forwards the request to the URL region matches that request and forwards the request to the server
indicated in the coverage region record, returning a response to the indicated in the coverage region record, returning a response to the
querier when it in turns receives an answer (recursion). querier when it in turn receives an answer (recursion).
Alternatively, the node returns the URL of that child node to the Alternatively, the node returns the application unique string (server
querier (iteration). This process applies to each node, i.e., a node name) of that child node to the querier (iteration). This process
does not need to know whether the original query came from a parent applies to each node, i.e., a node does not need to know whether the
node, a seeker, a forest guide or a resolver. original query came from a parent node, a seeker, a forest guide, or
a resolver.
For efficiency, a node MAY return region information instead of a For efficiency, a node MAY return region information instead of a
point answer. Thus, instead of returning that a particular point answer. Thus, instead of returning that a particular
geospatial coordinate maps to a service or mapping URL, it MAY return geospatial coordinate maps to a service URL or server name, it MAY
a polygon indicating the region for which this answer would be return a polygon indicating the region for which this answer would be
returned, along with expiration time (time-to-live) information. The returned, along with expiration time (time-to-live) information. The
querying node can then cache this information for future use. querying node can then cache this information for future use.
For civic coordinates, trees may not include individual mapping For civic coordinates, trees may not include individual mapping
records for each floor, house number or street. To avoid giving the records for each floor, house number, or street. To avoid giving the
wrong indication that a particular location has been found valid, wrong indication that a particular location has been found valid,
LoST can indicate which parts of the location information have LoST can indicate which parts of the location information have
actually been used to look up a mapping. actually been used to look up a mapping.
7.3. Overlapping Coverage Regions 7.3. Overlapping Coverage Regions
In some cases, coverage regions may overlap, either because there is In some cases, coverage regions may overlap, either because there is
a dispute as to who handles a particular geographic region or, more a dispute as to who handles a particular geographic region or, more
likely, since the resolution of the coverage map may not be likely, because the resolution of the coverage map may not be
sufficiently high. For example, a node may "shave some corners" off sufficiently high. For example, a node may "shave some corners" off
its polygon, so that its coverage region appears to overlap with its its polygon so that its coverage region appears to overlap with its
geographic neighbor. For civic coordinates, houses on the same geographic neighbor. For civic coordinates, houses on the same
street may be served by different PSAPs. The mapping mechanism needs street may be served by different PSAPs. The mapping mechanism needs
to work even if a coverage map is imprecise or if there are disputes to work even if a coverage map is imprecise or if there are disputes
about coverage. about coverage.
The solution for overlapping coverage regions is relatively simple. The solution for overlapping coverage regions is relatively simple.
If a query matches multiple coverage regions, the node returns all If a query matches multiple coverage regions, the node returns all
URLs, in redirection mode, or queries both children, if in recursive URLs or server names, in redirection mode, or queries both children,
mode. If the overlapping coverage is caused by imprecise coverage if in recursive mode. If the overlapping coverage is caused by
maps, only one will return a result and the others will return an imprecise coverage maps, only one will return a result and the others
error indication. If the particular location is disputed territory, will return an error indication. If the particular location is
the response will contain all answers, leaving it to the querier to disputed territory, the response will contain all answers, leaving it
choose the preferred solution or trying to contact all services in to the querier to choose the preferred solution or try to contact all
turn. services in turn.
7.4. Scaling and Reliability 7.4. Scaling and Reliability
Since they provide authoritative information, tree nodes need to be Since they provide authoritative information, tree nodes need to be
highly reliable. Thus, while this document refers to tree nodes as highly reliable. Thus, while this document refers to tree nodes as
logical entities within the tree, an actual implementation would logical entities within the tree, an actual implementation would
likely replicate node information across several servers, forming a likely replicate node information across several servers, forming a
cluster. Each such node would have the same information. Standard cluster. Each such node would have the same information. Standard
techniques such as DNS SRV records can be used to select one of the techniques such as DNS SRV records can be used to select one of the
servers. Replication within the cluster can use any suitable servers. Replication within the cluster can use any suitable
protocol mechanism, but a standardized incremental update mechanism protocol mechanism, but a standardized, incremental update mechanism
makes it easier to spread those nodes across multiple independently- makes it easier to spread those nodes across multiple independently
administered locations. The techniques developed for meshed SLP administered locations. The techniques developed for the meshed
[RFC3528] are applicable here. Service Location Protocol (SLP) [RFC3528] are applicable here.
8. Forest Guides 8. Forest Guides
Unfortunately, just having trees covering various regions of the Unfortunately, just having trees covering various regions of the
world is not sufficient as a client of the mapping protocol would not world is not sufficient, as a client of the mapping protocol would
generally be able to keep track of all the trees in the forest. To not generally be able to keep track of all the trees in the forest.
facilitate orientation among the trees, we introduce a forest guide To facilitate orientation among the trees, we introduce a forest
(FG) which keeps track of the coverage regions of all the trees for guide (FG), which keeps track of the coverage regions of all the
one service. For scalability and reliability, there will need to be trees for one service and location profile. For scalability and
a large number of forest guides, all providing the same information. reliability, there will need to be a large number of forest guides,
A seeker can contact a suitable forest guide and will then be all providing the same information. A seeker can contact a suitable
directed to the right tree or, rarely, set of trees. Forest guides forest guide and will then be directed to the right tree or, rarely,
do not provide mapping information themselves, but rather redirect to set of trees. Forest guides do not provide mapping information
mapping servers. In some configurations, not all forest guides may themselves, but rather redirect to mapping servers. In some
provide the same information, due to policy reasons. configurations, not all forest guides may provide the same
information, due to policy reasons.
Forest guides fulfill a similar role to root servers in DNS. They Forest guides fulfill a similar role to root servers in DNS. They
distribute information, signed for authenticity, offered by trees. distribute information, signed for authenticity, offered by trees.
However, introducing forest guides avoids creating a global root, However, introducing forest guides avoids creating a global root,
with the attendant management and control issues. with the attendant management and control issues.
However, unlike DNS root servers, forest guides may offer different However, unlike DNS root servers, forest guides may offer different
information based on local policy. Forest guides can also restrict information based on local policy. Forest guides can also restrict
their data synchronization to parts of the information. For example, their data synchronization to parts of the information. For example,
if country C does not recognize country T, C can propagate tree if country C does not recognize country T, C can propagate tree
skipping to change at page 13, line 23 skipping to change at page 12, line 41
of a tree can contact any forest guide and inject new coverage region of a tree can contact any forest guide and inject new coverage region
information into the system. One would expect that each tree information into the system. One would expect that each tree
announces its coverage to more than one forest guide. Each forest announces its coverage to more than one forest guide. Each forest
guide peers with one or more other guides and distributes new guide peers with one or more other guides and distributes new
coverage region announcements to other guides. Due to policy and coverage region announcements to other guides. Due to policy and
maybe political reasons, not all forest guides may share the same maybe political reasons, not all forest guides may share the same
coverage region data. coverage region data.
Forest guides can, in principle, be operated by anybody, including Forest guides can, in principle, be operated by anybody, including
voice service providers, Internet access providers, dedicated voice service providers, Internet access providers, dedicated
services providers and enterprises. services providers, and enterprises.
As in routing, peering with other forest guides implies a certain As in routing, peering with other forest guides implies a certain
amount of trust in the peer. Thus, peering is likely to require some amount of trust in the peer. Thus, peering is likely to require some
negotiation between the administering parties concerned, rather than negotiation between the administering parties concerned, rather than
automatic configuration. The mechanism itself does not imply a automatic configuration. The mechanism itself does not imply a
particular policy as to who gets to advertise a particular coverage particular policy as to who gets to advertise a particular coverage
region. region.
9. Configuring Service Numbers 9. Configuring Service Numbers
The section below is not directly related to the problem of The section below is not directly related to the problem of
determining service location, but is an instance of the more generic determining service location but is an instance of the more generic
problem solved by this architecture, namely mapping location problem solved by this architecture -- namely, mapping location
information to service-related parameters, such as service numbers. information to service-related parameters, such as service numbers.
For the foreseeable future, some user devices and software will For the foreseeable future, some user devices and software will
emulate the user interface of a telephone, i.e., the only way to emulate the user interface of a telephone, i.e., the only way to
enter call address information is via a 12-button keypad with digits enter call address information is via a 12-button keypad with digits
and the asterisk and hash symbol. These devices use service numbers and the asterisk and hash symbols. These devices use service numbers
to identify services. The best-known examples of service numbers are to identify services. The best-known examples of service numbers are
emergency numbers, such as 9-1-1 in North America and 1-1-2 in emergency numbers, such as 9-1-1 in North America and 1-1-2 in
Europe. However, many other public and private service numbers have Europe. However, many other public and private service numbers have
been defined, ranging in the United States from 3-1-1 for non- been defined, ranging in the United States from 3-1-1 for non-
emergency local government services to 4-1-1 for directory assistance emergency local government services to 4-1-1 for directory
to various "800" numbers for anything from roadside assistance to assistance, to various "800" numbers for anything from roadside
legal services to home-delivery food. assistance to legal services to home-delivery food.
Such service numbers are likely to be used until essentially all Such service numbers are likely to be used until essentially all
communication devices feature IP connectivity and an alphanumeric communication devices feature IP connectivity and an alphanumeric
keyboard. Unfortunately, for emergency services, more than 60 keyboard. Unfortunately, for emergency services, more than 60
emergency numbers are in use throughout the world, with many of those emergency numbers are in use throughout the world, with many of those
numbers serving non-emergency purposes elsewhere, e.g., identifying numbers serving non-emergency purposes elsewhere, e.g., identifying
repair or directory services. Countries also occasionally change repair or directory services. Countries also occasionally change
their emergency numbers to conform to regional agreements. An their emergency numbers to conform to regional agreements. An
example is the introduction of "1-1-2" for countries in Europe. example is the introduction of "1-1-2" for countries in Europe.
Thus, a system that allows devices to be used internationally to Thus, a system that allows devices to be used internationally to
place calls needs to allow devices to discover service numbers place calls needs to allow devices to discover service numbers
automatically. In the Internet-based system proposed here automatically. In the Internet-based system proposed in
[I-D.ietf-ecrit-framework], these numbers are strictly used as a [ECRIT-FRAME], these numbers are strictly used as a human-user
human user interface mechanism and are generally not visible in call interface mechanism and are generally not visible in call signaling
signaling messages, which carry the service URN [RFC5031] instead. messages, which carry the service URN [RFC5031] instead.
For the best user experience, systems should be able to discover two For the best user experience, systems should be able to discover two
sets of service numbers, namely those used in the user's home country sets of service numbers -- namely, those used in the user's home
and in the country the user is currently visiting. The user is most country and those used in the country the user is currently visiting.
likely to remember the former, but a companion borrowing a device in The user is most likely to remember the former, but a companion
an emergency, say, may only know the local emergency numbers. borrowing a device in an emergency, say, may only know the local
emergency numbers.
Determining home and local service numbers is a configuration Determining home and local service numbers is a configuration
problem, but unfortunately, existing configuration mechanisms are problem, but unfortunately, existing configuration mechanisms are
ill-suited for this purpose. For example, a DHCP server might be ill-suited for this purpose. For example, a DHCP server might be
able to provide the local service numbers, but not the home numbers. able to provide the local service numbers but not the home numbers.
When virtual private networks (VPNs) are used, even DHCP may provide When virtual private networks (VPNs) are used, even DHCP may provide
numbers of uncertain origin, as a user may contact the home network numbers of uncertain origin, as a user may contact the home network
or some local branch office of the corporate network. Similarly, SIP or some local branch office of the corporate network. Similarly, SIP
configuration [I-D.ietf-sipping-config-framework] would be able to configuration [CONFIG-FRAME] would be able to provide the numbers
provide the numbers valid at the location of the SIP service valid at the location of the SIP service provider, but even a SIP
provider, but even a SIP service provider with national footprint may service provider with a national footprint may serve customers that
serve customers that are visiting any number of other countries. are visiting any number of other countries.
Also, while initially there are likely to be only a few service Also, while initially there are likely to be only a few service
numbers, e.g., for emergency services, the LoST architecture can be numbers, e.g., for emergency services, the LoST architecture can be
used to support other services, as noted. Configuring every local used to support other services, as noted. Configuring every local
DHCP or SIP configuration server with that information is likely to DHCP or SIP configuration server with that information is likely to
be error-prone and tedious. be error-prone and tedious.
For these reasons, the LoST-based mapping architecture supports For these reasons, the LoST-based mapping architecture supports
providing service numbers to end systems based on caller location. providing service numbers to end systems based on caller location.
The mapping operation is almost exactly the same as for determining The mapping operation is almost exactly the same as for determining
the service URL. The mapping can be obtained either along with the the service URL. The mapping can be obtained along with the service
service URL or through a separate request. The major difference URL. The major difference between the two requests is that service
between the two requests is that service numbers often have much numbers often have much larger regions of validity than the service
larger regions of validity than the service URL itself. Also, the URL itself. Also, the service number is likely to be valid longer
service number is likely to be valid longer than the service URL. than the service URL. Finally, an end system may want to look up the
service number for its home location, not just its current (visited)
Finally, an end system may want to look up the service number for its location.
home location, not just its current (visited) location.
10. Security Considerations 10. Security Considerations
Security considerations for emergency services mapping are discussed Security considerations for emergency services mapping are discussed
in [RFC5069], while [RFC5031] discusses issues related to the service in [RFC5069], while [RFC5031] discusses issues related to the service
URN, one of the inputs into the mapping protocol. LoST-related URN, one of the inputs into the mapping protocol. LoST-related
security considerations are naturally discussed in the LoST [RFC5222] security considerations are naturally discussed in the LoST
specification. specification [RFC5222].
The architecture addresses the following security issues, usually The architecture addresses the following security issues, usually
through the underlying transport security associations: through the underlying transport security associations:
Server impersonation: Seekers, resolvers, fellow tree guides and server impersonation: Seekers, resolvers, fellow tree guides, and
cluster members can assure themselves of the identity of the cluster members can assure themselves of the identity of the
remote party by using the facilities in the underlying channel remote party by using the facilities in the underlying channel
security mechanism, such as TLS [RFC5246]. security mechanism, such as Transport Layer Security (TLS)
Query or query result corruption: To avoid that an attacker can [RFC5246].
modify the query or its result, the architecture RECOMMENDS the
use of channel security, such as TLS. Results SHOULD also be
digitally signed, e.g., using XML digital signatures
[W3C.REC-xmldsig-core-20020212]. Note, however, that simple
origin assertion may not provide the end system with enough useful
information as it has no good way of knowing that a particular
signer is authorized to represent a particular geographic area.
It might be necessary that certain well-known Certificate
Authorities (CAs) vet sources of mapping information and provide
special certificates for that purpose. In many cases, a seeker
will have to trust its local resolver to vet information for
trustworthiness; in turn, the resolver may rely on trusted forest
guides to steer it to the correct information.
Coverage region corruption: To avoid that a third party or an
untrustworthy member of a server population claims a coverage
region that it is not authorized for, any node introducing a new
region map MUST sign the object by protecting the data with an XML
digital signature [W3C.REC-xmldsig-core-20020212]. A recipient
MUST verify, through a local policy mechanism, that the signing
entity is indeed authorized to speak for that region. Determining
who can speak for a particular region is inherently difficult
unless there is a small set of authorizing entities that
participants in the mapping architecture can trust. Receiving
systems should be particularly suspicious if an existing coverage
region is replaced with a new one with a new mapping address. In
many cases, trust will be mediated: A seeker will have a trust
relationship with a resolver. The resolver, in turn, will contact
a trusted forest guide.
Additional threats that need to be addressed by operational measures query or query result corruption: To avoid the possibility of an
include denial-of-service attacks [I-D.ietf-ecrit-phonebcp]. attacker modifying the query or its result, the architecture
RECOMMENDS the use of channel security, such as TLS. Results
SHOULD also be digitally signed, e.g., using XML digital
signatures [W3C.REC-xmldsig-core-20020212]. Note, however, that
simple origin assertion may not provide the end system with enough
useful information as it has no good way of knowing that a
particular signer is authorized to represent a particular
geographic area. It might be necessary that certain well-known
Certificate Authorities (CAs) vet sources of mapping information
and provide special certificates for that purpose. In many cases,
a seeker will have to trust its local resolver to vet information
for trustworthiness; in turn, the resolver may rely on trusted
forest guides to steer it to the correct information.
11. IANA Considerations coverage region corruption: To avoid the possibility of a third
party or an untrustworthy member of a server population claiming a
coverage region that it is not authorized for, any node
introducing a new service boundary MUST sign the object by
protecting the data with an XML digital signature
[W3C.REC-xmldsig-core-20020212]. A recipient MUST verify, through
a local policy mechanism, that the signing entity is indeed
authorized to speak for that region. Determining who can speak
for a particular region is inherently difficult unless there is a
small set of authorizing entities that participants in the mapping
architecture can trust. Receiving systems should be particularly
suspicious if an existing coverage region is replaced with a new
one with a new mapping address. In many cases, trust will be
mediated: a seeker will have a trust relationship with a resolver,
and the resolver, in turn, will contact a trusted forest guide.
Since this document describes an architecture, not a protocol, it Additional threats that need to be addressed by operational measures
does not ask IANA to register any protocol constants. include denial-of-service attacks [PHONE-BCP].
12. Acknowledgments 11. Acknowledgments
Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar
Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson, Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson,
Schida Schubert, Murugaraj Shanmugam, Richard Stastny, and Hannes Schida Schubert, Murugaraj Shanmugam, Richard Stastny, Hannes
Tschofenig provided helpful comments. Tschofenig, and Karl Heinz Wolf provided helpful comments.
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223, Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008. August 2008.
13.2. Informative References 12.2. Informative References
[CONFIG-FRAME]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery", Work in Progress,
February 2008.
[ECRIT-FRAME]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet
Multimedia", Work in Progress, March 2009.
[LOST-SYNC]
Schulzrinne, H. and H. Tschofenig, "Synchronizing
Location-to-Service Translation (LoST) Protocol based
Service Boundaries and Mapping Elements", Work
in Progress, March 2009.
[PHONE-BCP]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
Work in Progress, March 2009.
[RFC3528] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced [RFC3528] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced
Service Location Protocol (mSLP)", RFC 3528, April 2003. Service Location Protocol (mSLP)", RFC 3528, April 2003.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069, Emergency Call Marking and Mapping", RFC 5069,
January 2008. January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress),
February 2008.
[I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-08 (work in
progress), February 2009.
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-08 (work in progress),
February 2009.
[I-D.schulzrinne-ecrit-lost-sync]
Schulzrinne, H., "Synchronizing Location-to-Service
Translation (LoST) Servers",
draft-schulzrinne-ecrit-lost-sync-01 (work in progress),
February 2008.
[W3C.REC-xmldsig-core-20020212] [W3C.REC-xmldsig-core-20020212]
Reagle, J., Solo, D., and D. Eastlake, "XML-Signature Solo, D., Eastlake, D., and J. Reagle, "XML-Signature
Syntax and Processing", World Wide Web Consortium Syntax and Processing", World Wide Web Consortium
FirstEdition REC-xmldsig-core-20020212, February 2002, FirstEdition REC-xmldsig-core-20020212, February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>. <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
Author's Address Author's Address
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
 End of changes. 85 change blocks. 
273 lines changed or deleted 255 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/