draft-ietf-ecrit-mapping-arch-02.txt   draft-ietf-ecrit-mapping-arch-03.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Intended status: Informational July 8, 2007 Intended status: Informational September 29, 2007
Expires: January 9, 2008 Expires: April 1, 2008
Location-to-URL Mapping Architecture and Framework Location-to-URL Mapping Architecture and Framework
draft-ietf-ecrit-mapping-arch-02 draft-ietf-ecrit-mapping-arch-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 9, 2008. This Internet-Draft will expire on April 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
1. The Mapping Problem . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 5 4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 5
4.1. Minimal System Architecture . . . . . . . . . . . . . . . 6 4.1. The Principal Components . . . . . . . . . . . . . . . . . 5
5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Minimal System Architecture . . . . . . . . . . . . . . . 7
6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 7 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8
7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10 7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 10 7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 11
7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11 7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11
8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 12
9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 12 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. The Mapping Problem 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
skipping to change at page 4, line 7 skipping to change at page 4, line 7
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) [2] protocol, although much of the discussion
would also apply for other mapping protocols satisfying the mapping would also apply for other mapping protocols satisfying the mapping
requirements [8]. requirements [8].
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUSTNOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" are to be interpreted as described in RFC 2119 [1] and document are to be interpreted as described in RFC 2119 [1] 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 [8], 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 other 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
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
region within which the AMS is able to authoritatively answer
mapping queries. Coverage regions are generally, but not
necessarily, contigous and may be represented as either a subset
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 one or more URLs describing either another mapping
server or the desired service URLs'. server or the desired service 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.
region map: A data object describing a contiguous area covered by an
AMS, either as a subset of a civic address or a geometric object.
tree: A tree consists of a self-contained hierarchy of authoritative tree: A tree consists of a self-contained hierarchy of authoritative
mapping servers. Each tree exports its coverage region to the mapping servers for a particular service. Each tree exports its
forest mapping servers. coverage region to the forest mapping servers.
4. Overview of Architecture 4. Overview of Architecture
In short, end users of the LoST-based [2] mapping mechanism, called 4.1. The Principal Components
seekers, contact resolvers that cache query results and know one or
more "forest guides". Forest guides know the coverage region of The mapping architecture distinguishes four logical roles: seekers,
trees and direct queries to the node at the top of the appropriate resolvers, authoritative mapping servers and forest guides. End
tree. Trees consist of authoritative mapping servers and maintain users of the LoST-based [2] mapping mechanism, called seekers,
the authoritative mapping information. Figure 1 shows the contact resolvers that cache query results and know one or more
interaction of the components. forest guides. Forest guides know the coverage region of trees and
direct queries to the node at the top of the appropriate tree. Trees
consist of authoritative mapping servers and maintain the
authoritative mapping information. Seekers, resolvers, authoritative
mapping servers and forest guides all communicate using LoST; indeed,
it is likely that in many cases, the same software can operate as a
resolver, AMS and FG. In addition to the basic LoST query protocol
[2], a synchronization protocol [11] 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
similar call routing functions.
Figure 1 shows the interaction of the components.
/-\ /-\ +-----+ +-----+ /-\ /-\ +-----+ +-----+
| S +******* R ********* FG *-----------------+ FG | | S +******* R ********* FG *-----------------+ FG |
\-/ \-/ | |* | | \-/ \-/ | |* | |
+--+--+ * +--+--+ +--+--+ * +--+--+
| * | | * |
| * | | * |
| * | | * |
| * | | * |
/-\ +--+--+ * +--+--+ /-\ +--+--+ * +--+--+
skipping to change at page 5, line 51 skipping to change at page 6, line 41
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
one tree. We assume that tree coverage information changes one tree, the higher if different governmental or private
relatively slowly, on the order of less than one change per year per organizations within a country operate independent trees. We assume
tree, although the system imposes no specific threshold. Tree that tree coverage information changes relatively slowly, on the
coverage would change, for example, if a country is split or merged order of less than one change per year per tree, although the system
or if two trees for different regions become part of a larger tree. imposes no specific threshold. Tree coverage would change, for
(On the other hand, information within a tree is likely to change example, if a country is split or merged or if two trees for
much more frequently.) different regions become part of a larger tree. (On the other hand,
information within a tree is likely to change much more frequently.)
4.1. Minimal System Architecture 4.2. Minimal System Architecture
It is possible to build a functioning system consisting only of It is possible to build a functioning system consisting only of
seekers and resolvers if these resolvers have other means of seekers and resolvers if these resolvers have other means of
obtaining mapping data. For example, a company acting as a mapping obtaining mapping data. For example, a company acting as a mapping
service provider could collect mapping records manually and make them service provider could collect mapping records manually and make them
available to their customers through the resolver. While feasible as available to their customers through the resolver. While feasible as
a starting point, such an architecture is unlikely to scale globally. a starting point, such an architecture is unlikely to scale globally.
Among other problems, it becomes very hard for providers of Among other problems, it becomes very hard for providers of
authoritative data to ensure that all such providers have up-to-date authoritative data to ensure that all such providers have up-to-date
information. If new trees are set up, they would somehow make information. If new trees are set up, they would somehow make
skipping to change at page 6, line 34 skipping to change at page 7, line 29
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 or call routing entities such as SIP proxy servers. end systems such as SIP user agents or call routing entities such as
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
skipping to change at page 7, line 38 skipping to change at page 8, line 33
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 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 would include the address of a suitable resolver in ISPs or VSPs may include the address of a suitable resolver in their
their configuration information, e.g., in SIP configuration for a VSP configuration information, e.g., in SIP configuration for a VSP or
or DHCP [5] for an ISP. Resolvers are manually configured with the DHCP [5] for an ISP. Resolvers are manually configured with the name
name of one or more forest guides. 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) needing the information may entities, but clients (seekers) may potentially need to find out
potentially need to find out mapping about any spot on earth. mapping information for any spot on earth. (Extensions to extra-
terrestrial applications are left for future exploration.)
(Extensions to extra-terrestrial applications are left for future Information is organized hierarchically, in a tree, with tree nodes
exploration.) Information is organized hierarchically, in a tree, representing larger geographic areas pointing to several child nodes
with tree nodes representing larger geographic areas pointing to each representing a smaller area. Each tree node can be a cluster of
several child nodes each representing a smaller area. Each tree node LoST servers that all contain the same information and back up each
can be a cluster of LoST servers that all contain the same other.
information and back up each other.
Each tree can map a location described by civic and geographic Each tree can map a location described by either civic or geographic
coordinates for one type of service (such as 'sos.police', 'sos.fire' coordinates, but not both, for one type of service (such as
or 'counseling'), although nothing prevents re-using the same tree 'sos.police', 'sos.fire' or 'counseling'), although nothing prevents
for multiple different services. The collection of all trees for one re-using the same servers for multiple different services or both
service is known as a forest. types of coordinates. The collection of all trees for one service 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 a polygon in geospatial coordinates or a region can be described by a polygon in geospatial coordinates or a
set of civic address descriptors (e.g., "country = DE, A1 = set of civic address descriptors (e.g., "country = DE, A1 =
skipping to change at page 9, line 10 skipping to change at page 10, line 7
providers, which in turn might further route signaling requests to providers, which in turn might further route signaling requests to
more servers covering smaller regions. 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 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 lost:englewoodnj.gov US NJ Bergen Englewood englewoodnj.gov
.... ....
Coverage regions are described by sets of polygons enclosing Coverage regions are described by sets of polygons enclosing
contiguous geographic areas or by descriptors enumerating groups of contiguous geographic areas or by descriptors enumerating groups of
civic locations. For the former, the LoST server performs a point- civic locations. For the former, the LoST server performs a point-
in-polygon operation to find the polygon that contains the query in-polygon operation to find the polygon that contains the query
point. (More complicated geometric matching algorithms may be added point. (More complicated geometric matching algorithms may be added
in the future.) in the future.)
For example, a state-level tree node for New Jersey in the United For example, a state-level tree node for New Jersey in the United
skipping to change at page 9, line 36 skipping to change at page 10, line 33
that any query matching a location in Bergen County, for example, that any query matching a location in Bergen County, for example,
would be redirected or forwarded to the node located at would be redirected or forwarded to the node located at
bergen.nj.example.org. There is no requirement that all child nodes bergen.nj.example.org. There is no requirement that all child nodes
cover the same level within the civic hierarchy. As an example, in 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 the table below, the city of Newark has decided to be listed directly
within the state node, rather than through the county. Longest-match within the state node, rather than through the county. Longest-match
rules allow partial coverage, so that for queries for all other towns rules allow partial coverage, so that for queries for all other towns
within Essex county would be directed to the county node for further within Essex county would be directed to the county node for further
resolution. resolution.
C A1 A2 A3 resource C A1 A2 A3 LoST server name
US NJ Atlantic * lost:atlantic.nj.example.org/sos US NJ Atlantic * atlantic.nj.example.org/sos
US NJ Bergen * lost:bergen.nj.example.org/sos US NJ Bergen * bergen.nj.example.org/sos
US NJ Monmouth * lost:monmouth.nj.example.org/sos US NJ Monmouth * monmouth.nj.example.org/sos
US NJ Essex * lost:essex.nj.example.org/sos US NJ Essex * essex.nj.example.org/sos
US NJ Essex Newark lost: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
LoST URLs, while mapping entries contain service URLs. Mapping names of LoST servers, while mapping entries contain service URLs.
entries may be specific down to the house or floor level or may only Mapping entries may be specific down to the house or floor level or
contain street-level information. For example, in the United States, may only contain street-level information. For example, in the
civic mapping data for emergency services is generally limited to United States, civic mapping data for emergency services is generally
address ranges ("MSAG data"), so initial mapping databases may only limited to address ranges ("MSAG data"), so initial mapping databases
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 [11] allows nodes to query other nodes for mapping data and
coverage regions. In the example above, the state-run node would coverage regions. In the example above, the state-run node would
query the county nodes and use the records returned to distribute query the county nodes and use the records returned to distribute
incoming LoST queries to the county nodes. Conversely, nodes could incoming LoST queries to the county nodes. Conversely, nodes could
also contact their parent nodes to tell them about their coverage also contact their parent nodes to tell them about their coverage
region. There is some benefit of child nodes contacting their region. There is some benefit of child nodes contacting their
parents, as this allows changes in coverage region to propagate parents, as this allows changes in coverage region to propagate
quickly up the tree. quickly up the tree.
skipping to change at page 11, line 33 skipping to change at page 12, line 30
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 [3]
are applicable here. 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). It is a server that keeps track of the coverage regions of the (FG) which keeps track of the coverage regions of all the trees for
trees. For scalability and reliability, there will need to be a one service. For scalability and reliability, there will need to be
large number of forest guides, all providing the same information. A a large number of forest guides, all providing the same information.
seeker can contact a suitable forest guide and will then be directed A seeker can contact a suitable forest guide and will then be
to the right tree or, rarely, set of trees. Forest guides do not directed to the right tree or, rarely, set of trees. Forest guides
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.
Introducing forest guides avoids creating a global root, with the Forest guides fulfill a similar role to root servers in DNS. They
attendant management and control issues. Trees can also restrict distribute information, signed for authenticity, offered by trees.
their cooperation to parts of the information. For example, if However, introducing forest guides avoids creating a global root,
country C does not recognize country T, C can propagate tree regions with the attendant management and control issues. Forest guides can
for all but T. also restrict their cooperation to parts of the information. For
example, if country C does not recognize country T, C can propagate
For authenticity, the records SHOULD be digitally signed. They are tree regions for all but T.
used by resolvers and possibly seekers to find the appropriate tree
for a particular area. All 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 a tree can contact any forest
guide and inject new coverage region information into the system.
One would expect that each tree announces its coverage to more than
one forest guide. Each forest guide peers with one or more other
guides and distributes new coverage region announcements to all other
guides.
Forest guides fulfill a similar role to root servers in DNS. For authenticity, the coverage regions SHOULD be digitally signed by
However, their number is likely to be larger, possibly counted in the authorities responsible for the region, as discussed in more
hundreds. They distribute information, signed for authenticity, detail in Section 10. They are used by resolvers and possibly
offered by trees. seekers to find the appropriate tree for a particular area. All
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 a tree can contact any forest guide and inject new coverage region
information into the system. One would expect that each tree
announces its coverage to more than one forest guide. Each forest
guide peers with one or more other guides and distributes new
coverage region announcements to other guides. Due to policy and
maybe political reasons, not all forest guides may share the same
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
skipping to change at page 13, line 27 skipping to change at page 14, line 25
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 to the home numbers of uncertain origin, as a user may contact the home network
network or some local branch office of the corporate network. or some local branch office of the corporate network. Similarly, SIP
Similarly, SIP configuration [4] would be able to provide the numbers configuration [4] would be able to provide the numbers valid at the
valid at the location of the SIP service provider, but even a SIP location of the SIP service provider, but even a SIP service provider
service provider with national footprint may serve customers that are with national footprint may serve customers that are visiting any
visiting any number of other countries. 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 service URL. The mapping can be obtained either along with the
determining the service URL or separately. 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 the 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 [9], while [10] discusses issues related to the service URN, one
of the inputs into the mapping protocol. LoST-related security of the inputs into the mapping protocol. LoST-related security
considerations are naturally discussed in the LoST [2] specification. considerations are naturally discussed in the LoST [2] 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:
skipping to change at page 14, line 32 skipping to change at page 15, line 32
digitally signed, e.g., using XML digital signatures. Note, digitally signed, e.g., using XML digital signatures. Note,
however, that simple origin assertion may not provide the end however, that simple origin assertion may not provide the end
system with enough useful information as it has no good way of system with enough useful information as it has no good way of
knowing that a particular signer is authorized to represent a knowing that a particular signer is authorized to represent a
particular geographic area. It might be necessary that certain particular geographic area. It might be necessary that certain
well-known Certificate Authorities (CAs) vet sources of mapping well-known Certificate Authorities (CAs) vet sources of mapping
information and provide special certificates for that purpose. In information and provide special certificates for that purpose. In
many cases, a seeker will have to trust its local resolver to vet many cases, a seeker will have to trust its local resolver to vet
information for trustworthiness; in turn, the resolver may rely on information for trustworthiness; in turn, the resolver may rely on
trusted forest guides to steer it to the correct information. trusted forest guides to steer it to the correct information.
Region corruption: To avoid that a third party or an untrustworthy Coverage region corruption: To avoid that a third party or an
member of a server population introduces a region map that it is untrustworthy member of a server population introduces claims a
not authorized for, any node introducing a new region map MUST coverage region that it is not authorized for, any node
sign the object by encapsulating the data into a CMS wrapper. A introducing a new region map MUST sign the object by encapsulating
recipient MUST verify, through a local policy mechanism, that the the data into a CMS wrapper. A recipient MUST verify, through a
signing entity is indeed authorized to speak for that region. local policy mechanism, that the signing entity is indeed
Determining who can speak for a particular region is inherently authorized to speak for that region. Determining who can speak
difficult unless there is a small set of authorizing entities that for a particular region is inherently difficult unless there is a
participants in the mapping architecture can trust. Receiving small set of authorizing entities that participants in the mapping
systems should be particularly suspicious if an existing region architecture can trust. Receiving systems should be particularly
map is replaced with a new one with a new mapping address. In suspicious if an existing coverage region is replaced with a new
many cases, trust will be mediated: A seeker will have a trust one with a new mapping address. In many cases, trust will be
relationship with a resolver. The resolver, in turn, will contact mediated: A seeker will have a trust relationship with a resolver.
a trusted forest guide. 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 [7].
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, Andrew Newton, Murugaraj Richard Barnes, Jong Yul Kim, Otmar Lendl, Matt Lepinski, Andrew
Shanmugam, Richard Stastny, and Hannes Tschofenig provided helpful Newton, Schida Schubert, Murugaraj Shanmugam, Richard Stastny, and
comments. 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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Hardie, T., "LoST: A Location-to-Service Translation Protocol", [2] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-ietf-ecrit-lost-05 (work in progress), March 2007. draft-ietf-ecrit-lost-06 (work in progress), August 2007.
13.2. Informative References 13.2. Informative References
[3] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced [3] 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 [4] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress), draft-ietf-sipping-config-framework-12 (work in progress),
June 2007. June 2007.
[5] Schulzrinne, H., "A Dynamic Host Configuration Protocol (DHCP) [5] Schulzrinne, H., "A Dynamic Host Configuration Protocol (DHCP)
based Location-to-Service Translation Protocol (LoST) based Location-to-Service Translation Protocol (LoST)
Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-01 Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-02
(work in progress), March 2007. (work in progress), July 2007.
[6] Rosen, B., "Framework for Emergency Calling in Internet [6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
Multimedia", draft-ietf-ecrit-framework-01 (work in progress), for Emergency Calling using Internet Multimedia",
March 2007. draft-ietf-ecrit-framework-03 (work in progress),
September 2007.
[7] Rosen, B. and J. Polk, "Best Current Practice for [7] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-01 (work in progress), March 2007. draft-ietf-ecrit-phonebcp-02 (work in progress),
September 2007.
[8] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [8] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. March 2007.
[9] Taylor, T., "Security Threats and Requirements for Emergency [9] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 Call Marking and Mapping", draft-ietf-ecrit-security-threats-05
(work in progress), April 2007. (work in progress), August 2007.
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
draft-ietf-ecrit-service-urn-06 (work in progress), March 2007. and Other Well-Known Services", draft-ietf-ecrit-service-urn-07
(work in progress), August 2007.
[11] Schulzrinne, H., "Synchronizing Location-to-Service Translation [11] Schulzrinne, H., "Synchronizing Location-to-Service Translation
(LoST) Servers", draft-schulzrinne-ecrit-lost-sync-00 (work in (LoST) Servers", draft-schulzrinne-ecrit-lost-sync-00 (work in
progress), November 2006. progress), November 2006.
Author's Address Author's Address
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
 End of changes. 36 change blocks. 
144 lines changed or deleted 168 lines changed or added

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