draft-ietf-ecrit-mapping-arch-03.txt   draft-ietf-ecrit-mapping-arch-04.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Intended status: Informational September 29, 2007 Intended status: Informational March 5, 2009
Expires: April 1, 2008 Expires: September 6, 2009
Location-to-URL Mapping Architecture and Framework Location-to-URL Mapping Architecture and Framework
draft-ietf-ecrit-mapping-arch-03 draft-ietf-ecrit-mapping-arch-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2008. This Internet-Draft will expire on September 6, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes an architecture for a global, scalable, This document describes an architecture for a global, scalable,
resilient and administratively distributed system for mapping resilient and administratively distributed system for mapping
geographic location information to URLs, using the Location-to- geographic location information to URLs, using the Location-to-
Service (LoST) protocol. The architecture generalizes well-known Service (LoST) protocol. The architecture generalizes well-known
approaches found in hierarchical lookup systems such as DNS. approaches found in hierarchical lookup systems such as DNS.
Table of Contents Table of Contents
skipping to change at page 2, line 29 skipping to change at page 3, line 4
7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 12 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 12
8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
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 is actually offered by a variety of
local service providers. In many of these cases, the service 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 [8], where a geographic location pattern. This is a mapping problem [RFC5012], where a geographic
and a service identifier (URN) [10] is translated into a set of URIs, location and a service identifier (URN) [RFC5031] is translated into
the service URIs, that allow the Internet system to contact an a set of URIs, the service URIs, that allow the Internet system to
appropriate network entity that provides the service. contact 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 where the service is being provided
from, and the location of the service provider may change over time, from, and the location of the service provider may change over time,
e.g., to deal with temporary overloads, failures in the primary 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 [6]. more detail in [I-D.ietf-ecrit-framework].
The overall emergency calling architecture [6] separates mapping from The overall emergency calling architecture [I-D.ietf-ecrit-framework]
placing calls or otherwise invoking the service, so the same separates mapping from placing calls or otherwise invoking the
mechanism can be used to verify that a mapping exists ("address service, so the same mechanism can be used to verify that a mapping
validation") or to obtain test service URIs. exists ("address validation") or to obtain test service URIs.
Mapping locations to URIs describing services requires a distributed, Mapping locations to URIs describing services requires a distributed,
scalable and highly resilient infrastructure. Authoritative scalable and highly resilient infrastructure. Authoritative
knowledge about such mappings is distributed among a large number of knowledge about such mappings is distributed among a large number of
autonomous entities that may have no direct knowledge of each other. autonomous entities that may have no direct knowledge of each other.
In this document, we describe an architecture for such a global In this document, we describe an architecture for such a global
service. It allows significant freedom to combine and split service. It allows significant freedom to combine and split
functionality among actual servers and imposes few requirements as to functionality among actual servers and imposes few requirements as to
who should operate particular services. 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) [2] protocol, although much of the discussion Translation (LoST) [RFC5222] protocol, although much of the
would also apply for other mapping protocols satisfying the mapping discussion would also apply for other mapping protocols satisfying
requirements [8]. the mapping requirements [RFC5012].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1] 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 [8], 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 PIDF-LO
civic labels or a particular region described by a geometric civic labels or a particular region described by a geometric
shape. In some (rare) cases of territorial disputes, two shape. In some (rare) cases of territorial disputes, two
resolvers may be authoritative for the same region. An AMS may resolvers may be authoritative for the same region. An AMS may
redirect or forward a query to another AMS within the tree. 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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 and forest guides. End resolvers, authoritative mapping servers (AMS) and forest guides
users of the LoST-based [2] mapping mechanism, called seekers, (FGs). End users of the LoST-based [RFC5222] mapping mechanism,
contact resolvers that cache query results and know one or more called seekers, contact resolvers that cache query results and know
forest guides. Forest guides know the coverage region of trees and one or more forest guides. Forest guides form the top level of a
conceptual hierarchy, with one or more trees providing a hierarchical
resolution service for different geographic regions. Forest guides
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. Seekers, resolvers, authoritative authoritative mapping information.
mapping servers and forest guides all communicate using LoST; indeed,
it is likely that in many cases, the same software can operate as a Seekers, resolvers, authoritative mapping servers and forest guides
resolver, AMS and FG. In addition to the basic LoST query protocol all communicate using LoST; indeed, it is likely that in many cases,
[2], a synchronization protocol [11] may be used to exchange the same software can operate as a resolver, authoritative mapping
information between forest guides or to push coverage information server and forest guide. In addition to the basic LoST query
from a tree node to its parent. protocol [RFC5222], a synchronization protocol
[I-D.schulzrinne-ecrit-lost-sync] may be used to exchange information
between forest guides or to push coverage information from a tree
node to its parent.
Seekers may be part of VoIP or other end systems, or SIP proxies or Seekers may be part of VoIP or other end systems, or SIP proxies or
similar call routing functions. similar call routing functions.
Figure 1 shows the interaction of the components. Figure 1 shows the interaction of the components. The lines
indicating the connection between the forest guides are logical
connections, indicating that they are synchronizing their information
via the synchronization protocol [I-D.schulzrinne-ecrit-lost-sync].
/-\ /-\ +-----+ +-----+ /-\ /-\ +-----+ +-----+
| S +******* R ********* FG *-----------------+ FG | | S +******* R ********* FG *-----------------+ FG |
\-/ \-/ | |* | | \-/ \-/ | |* | |
+--+--+ * +--+--+ +--+--+ * +--+--+
| * | | * |
| * | | * |
| * | | * |
| * | | * |
/-\ +--+--+ * +--+--+ /-\ +--+--+ * +--+--+
skipping to change at page 6, line 30 skipping to change at page 6, line 30
|*** ^ |*** ^
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
----------- ----------- ----------- -----------
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. query and responses in recursive mode, while the lines indicate
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 added
and removed as the organization of mapping data changes. We call the and removed as the organization of mapping data changes. We call the
collection of trees a forest. There is no limit on the number of collection of trees a forest. There is no limit on the number of
trees within the forest, but the author guesses that the number of trees within the forest, but the author guesses that the number of
trees will likely be somewhere between a few hundred and a few trees will likely be somewhere between a few hundred and a few
thousand. The lower estimate would apply if each country operates thousand. The lower estimate would apply if each country operates
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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 [5]. In an enterprise can provide a pointer to a resolver via DHCP [RFC5223].
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 35 skipping to change at page 8, line 35
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 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 VSPs may include the address of a suitable resolver in their
configuration information, e.g., in SIP configuration for a VSP or configuration information, e.g., in SIP configuration for a VSP or
DHCP [5] for an ISP. Resolvers are manually configured with the name DHCP [RFC5223] for an ISP. Resolvers are manually configured with
of one or more forest guides. 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.)
skipping to change at page 9, line 21 skipping to change at page 9, line 21
types of coordinates. The collection of all trees for one service is types of coordinates. The collection of all trees for one service is
known as a forest. 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 a polygon in geospatial coordinates or a region can be described by any of the shapes in the LoST
set of civic address descriptors (e.g., "country = DE, A1 = specification expressed in geospatial coordinates, such as circles or
Bavaria"). These coverage regions may be aligned with political polygons, or a set of civic address descriptors (e.g., "country = DE,
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, or 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.
skipping to change at page 10, line 14 skipping to change at page 10, line 15
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
US NJ Bergen Fort Lee sip:emergency@fortleenj.org US NJ Bergen Fort Lee sip:emergency@fortleenj.org
US NJ Bergen Teaneck sip:police@teanecknjgov.org US NJ Bergen Teaneck sip:police@teanecknjgov.org
US NJ Bergen Englewood englewoodnj.gov US NJ Bergen Englewood englewoodnj.gov
.... ....
Coverage regions are described by sets of polygons enclosing Coverage regions are described by sets of LoST-compatible shapes
contiguous geographic areas or by descriptors enumerating groups of enclosing contiguous geographic areas or by descriptors enumerating
civic locations. For the former, the LoST server performs a point- groups of civic locations. For the former, the LoST server performs
in-polygon operation to find the polygon that contains the query the same matching operation as described in Section 12.2 of the LoST
point. (More complicated geometric matching algorithms may be added specification [RFC5222] to find the tree or AMS.
in the future.)
For example, a state-level tree node for New Jersey in the United As a civic location example, a state-level tree node for New Jersey
States may contain the following coverage region entries, indicating in the United States may contain the coverage region entries shown
that any query matching a location in Bergen County, for example, below, indicating that any query matching a location in Bergen
would be redirected or forwarded to the node located at County, for example, would be redirected or forwarded to the node
bergen.nj.example.org. There is no requirement that all child nodes located at bergen.nj.example.org.
cover the same level within the civic hierarchy. As an example, in
the table below, the city of Newark has decided to be listed directly There is no requirement that all child nodes cover the same level
within the state node, rather than through the county. Longest-match within the civic hierarchy. As an example, in the table below, the
rules allow partial coverage, so that for queries for all other towns city of Newark has decided to be listed directly within the state
within Essex county would be directed to the county node for further node, rather than through the county. Longest-match rules allow
partial coverage, so that for queries for all other towns within
Essex 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 [11] allows nodes to query other nodes for mapping data and mechanism [I-D.schulzrinne-ecrit-lost-sync] allows nodes to query
coverage regions. In the example above, the state-run node would other nodes for mapping data and coverage regions, both within a
query the county nodes and use the records returned to distribute cluster and across different hierarchy levels in a tree. In the
incoming LoST queries to the county nodes. Conversely, nodes could example above, the state-run node would query the county nodes and
also contact their parent nodes to tell them about their coverage use the records returned to distribute incoming LoST queries to the
region. There is some benefit of child nodes contacting their county nodes. Conversely, nodes could also contact their parent
parents, as this allows changes in coverage region to propagate nodes to tell them about their coverage region. There is some
quickly up the tree. benefit of child nodes contacting their parents, as this allows
changes in coverage region to 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 URL
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 turns receives an answer (recursion).
Alternatively, the node returns the URL of that child node to the Alternatively, the node returns the URL of that child node to the
querier (iteration). This process applies to each node, i.e., a node querier (iteration). This process applies to each node, i.e., a node
skipping to change at page 12, line 22 skipping to change at page 12, line 26
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 [3] administered locations. The techniques developed for meshed SLP
are applicable here. [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 not
generally be able to keep track of all the trees in the forest. To generally be able to keep track of all the trees in the forest. To
facilitate orientation among the trees, we introduce a forest guide facilitate orientation among the trees, we introduce a forest guide
(FG) which keeps track of the coverage regions of all the trees for (FG) which keeps track of the coverage regions of all the trees for
one service. For scalability and reliability, there will need to be one service. For scalability and reliability, there will need to be
a large number of forest guides, all providing the same information. a large number of forest guides, all providing the same information.
A seeker can contact a suitable forest guide and will then be A seeker can contact a suitable forest guide and will then be
directed to the right tree or, rarely, set of trees. Forest guides directed to the right tree or, rarely, set of trees. Forest guides
do not provide mapping information themselves, but rather redirect to do not provide mapping information themselves, but rather redirect to
mapping servers. In some configurations, not all forest guides may mapping servers. In some configurations, not all forest guides may
provide the same information, due to policy reasons. 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. Forest guides can with the attendant management and control issues.
also restrict their cooperation to parts of the information. For
example, if country C does not recognize country T, C can propagate However, unlike DNS root servers, forest guides may offer different
tree regions for all but T. information based on local policy. Forest guides can also restrict
their data synchronization to parts of the information. For example,
if country C does not recognize country T, C can propagate tree
regions for all but T.
For authenticity, the coverage regions SHOULD be digitally signed by For authenticity, the coverage regions SHOULD be digitally signed by
the authorities responsible for the region, as discussed in more the authorities responsible for the region, as discussed in more
detail in Section 10. They are used by resolvers and possibly detail in Section 10. They are used by resolvers and possibly
seekers to find the appropriate tree for a particular area. All seekers to find the appropriate tree for a particular area. All
forest guides should have consistent information, i.e., a collection forest guides should have consistent information, i.e., a collection
of all the coverage regions of all the trees. A tree node at the top of all the coverage regions of all the trees. A tree node at the top
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
skipping to change at page 14, line 9 skipping to change at page 14, line 16
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 [6], these automatically. In the Internet-based system proposed here
numbers are strictly used as a human user interface mechanism and are [I-D.ietf-ecrit-framework], these numbers are strictly used as a
generally not visible in call signaling messages, which carry the human user interface mechanism and are generally not visible in call
service URN [10] instead. signaling 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 country
and in the country the user is currently visiting. The user is most and in the country the user is currently visiting. The user is most
likely to remember the former, but a companion borrowing a device in likely to remember the former, but a companion borrowing a device in
an emergency, say, may only know the local emergency numbers. 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 [4] would be able to provide the numbers valid at the configuration [I-D.ietf-sipping-config-framework] would be able to
location of the SIP service provider, but even a SIP service provider provide the numbers valid at the location of the SIP service
with national footprint may serve customers that are visiting any provider, but even a SIP service provider with national footprint may
number of other countries. serve customers that 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
skipping to change at page 14, line 46 skipping to change at page 15, line 4
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 either along with the
service URL or through a separate request. The major difference service URL or through a separate request. The major difference
between the two requests is that service numbers often have much between the two requests is that service numbers often have much
larger regions of validity than the service URL itself. Also, the larger regions of validity than the service URL itself. Also, the
service number is likely to be valid longer than the service URL. service number is likely to be valid longer than the service URL.
Finally, an end system may want to look up the service number for its Finally, an end system may want to look up the service number for its
home location, not just its current (visited) 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 [9], while [10] discusses issues related to the service URN, one in [RFC5069], while [RFC5031] discusses issues related to the service
of the inputs into the mapping protocol. LoST-related security URN, one of the inputs into the mapping protocol. LoST-related
considerations are naturally discussed in the LoST [2] specification. security considerations are naturally discussed in the LoST [RFC5222]
specification.
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. security mechanism, such as TLS [RFC5246].
Query or query result corruption: To avoid that an attacker can Query or query result corruption: To avoid that an attacker can
modify the query or its result, the architecture RECOMMENDS the modify the query or its result, the architecture RECOMMENDS the
use of channel security, such as TLS. Results SHOULD also be use of channel security, such as TLS. Results SHOULD also be
digitally signed, e.g., using XML digital signatures. Note, digitally signed, e.g., using XML digital signatures
however, that simple origin assertion may not provide the end [W3C.REC-xmldsig-core-20020212]. Note, however, that simple
system with enough useful information as it has no good way of origin assertion may not provide the end system with enough useful
knowing that a particular signer is authorized to represent a information as it has no good way of knowing that a particular
particular geographic area. It might be necessary that certain signer is authorized to represent a particular geographic area.
well-known Certificate Authorities (CAs) vet sources of mapping It might be necessary that certain well-known Certificate
information and provide special certificates for that purpose. In Authorities (CAs) vet sources of mapping information and provide
many cases, a seeker will have to trust its local resolver to vet special certificates for that purpose. In many cases, a seeker
information for trustworthiness; in turn, the resolver may rely on will have to trust its local resolver to vet information for
trusted forest guides to steer it to the correct information. 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 Coverage region corruption: To avoid that a third party or an
untrustworthy member of a server population introduces claims a untrustworthy member of a server population claims a coverage
coverage region that it is not authorized for, any node region that it is not authorized for, any node introducing a new
introducing a new region map MUST sign the object by encapsulating region map MUST sign the object by protecting the data with an XML
the data into a CMS wrapper. A recipient MUST verify, through a digital signature [W3C.REC-xmldsig-core-20020212]. A recipient
local policy mechanism, that the signing entity is indeed MUST verify, through a local policy mechanism, that the signing
authorized to speak for that region. Determining who can speak entity is indeed authorized to speak for that region. Determining
for a particular region is inherently difficult unless there is a who can speak for a particular region is inherently difficult
small set of authorizing entities that participants in the mapping unless there is a small set of authorizing entities that
architecture can trust. Receiving systems should be particularly participants in the mapping architecture can trust. Receiving
suspicious if an existing coverage region is replaced with a new systems should be particularly suspicious if an existing coverage
one with a new mapping address. In many cases, trust will be region is replaced with a new one with a new mapping address. In
mediated: A seeker will have a trust relationship with a resolver. many cases, trust will be mediated: A seeker will have a trust
The resolver, in turn, will contact a trusted forest guide. relationship with a resolver. The resolver, in turn, will contact
a trusted forest guide.
Additional threats that need to be addressed by operational measures Additional threats that need to be addressed by operational measures
include denial-of-service attacks [7]. include denial-of-service attacks [I-D.ietf-ecrit-phonebcp].
11. IANA Considerations 11. IANA Considerations
Since this document describes an architecture, not a protocol, it Since this document describes an architecture, not a protocol, it
does not ask IANA to register any protocol constants. does not ask IANA to register any protocol constants.
12. Acknowledgments 12. Acknowledgments
Richard Barnes, Jong Yul Kim, Otmar Lendl, Matt Lepinski, Andrew Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar
Newton, Schida Schubert, Murugaraj Shanmugam, Richard Stastny, and Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson,
Hannes Tschofenig provided helpful comments. Schida Schubert, Murugaraj Shanmugam, Richard Stastny, and Hannes
Tschofenig provided helpful comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Hardie, T., "LoST: A Location-to-Service Translation Protocol", [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
draft-ietf-ecrit-lost-06 (work in progress), August 2007. Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008.
13.2. Informative References 13.2. Informative References
[3] 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.
[4] Petrie, D. and S. Channabasappa, "A Framework for Session [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Initiation Protocol User Agent Profile Delivery", Emergency Context Resolution with Internet Technologies",
draft-ietf-sipping-config-framework-12 (work in progress), RFC 5012, January 2008.
June 2007.
[5] Schulzrinne, H., "A Dynamic Host Configuration Protocol (DHCP) [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
based Location-to-Service Translation Protocol (LoST)
Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-02
(work in progress), July 2007.
[6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework Shanmugam, "Security Threats and Requirements for
for Emergency Calling using Internet Multimedia", Emergency Call Marking and Mapping", RFC 5069,
draft-ietf-ecrit-framework-03 (work in progress), January 2008.
September 2007.
[7] Rosen, B. and J. Polk, "Best Current Practice for [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Communications Services in support of Emergency Calling", (TLS) Protocol Version 1.2", RFC 5246, August 2008.
draft-ietf-ecrit-phonebcp-02 (work in progress),
September 2007.
[8] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [I-D.ietf-sipping-config-framework]
Context Resolution with Internet Technologies", Channabasappa, S., "A Framework for Session Initiation
draft-ietf-ecrit-requirements-13 (work in progress), Protocol User Agent Profile Delivery",
March 2007. draft-ietf-sipping-config-framework-15 (work in progress),
February 2008.
[9] Taylor, T., "Security Threats and Requirements for Emergency [I-D.ietf-ecrit-framework]
Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
(work in progress), August 2007. "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-08 (work in
progress), February 2009.
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency [I-D.ietf-ecrit-phonebcp]
and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 Rosen, B. and J. Polk, "Best Current Practice for
(work in progress), August 2007. Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-08 (work in progress),
February 2009.
[11] Schulzrinne, H., "Synchronizing Location-to-Service Translation [I-D.schulzrinne-ecrit-lost-sync]
(LoST) Servers", draft-schulzrinne-ecrit-lost-sync-00 (work in Schulzrinne, H., "Synchronizing Location-to-Service
progress), November 2006. Translation (LoST) Servers",
draft-schulzrinne-ecrit-lost-sync-01 (work in progress),
February 2008.
[W3C.REC-xmldsig-core-20020212]
Reagle, J., Solo, D., and D. Eastlake, "XML-Signature
Syntax and Processing", World Wide Web Consortium
FirstEdition REC-xmldsig-core-20020212, February 2002,
<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
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST AND
THE 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 45 change blocks. 
147 lines changed or deleted 188 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/