draft-ietf-ecrit-mapping-arch-01.txt   draft-ietf-ecrit-mapping-arch-02.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Intended status: Informational December 17, 2006 Intended status: Informational July 8, 2007
Expires: June 20, 2007 Expires: January 9, 2008
Location-to-URL Mapping Architecture and Framework Location-to-URL Mapping Architecture and Framework
draft-ietf-ecrit-mapping-arch-01 draft-ietf-ecrit-mapping-arch-02
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 June 20, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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. The Mapping Problem . . . . . . . . . . . . . . . . . . . . . 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. Minimal System Architecture . . . . . . . . . . . . . . . 6
5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 7
7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7
7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10 7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10
7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 10 7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 10
7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11
8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 12 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 4, line 31 skipping to change at page 4, line 31
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 other 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.
forest guide: A forest guide has knowledge of the coverage region of forest guide (FG): A forest guide (FG) has knowledge of the coverage
all trees. 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 resolver. 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. 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 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. AMS, either as a subset of a civic address or a geometric object.
resolver: Resolvers contact authoritative mapping servers to answer
queries by seekers, and may cache query results.
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. Each tree exports its coverage region to the
forest mapping servers. forest mapping servers.
4. Overview of Architecture 4. Overview of Architecture
In short, end users of the LoST-based [2] mapping mechanism, called In short, end users of the LoST-based [2] mapping mechanism, called
seekers, contact resolvers that cache query results and know one or seekers, contact resolvers that cache query results and know one or
more "forest guides". Forest guides know the coverage region of more "forest guides". Forest guides know the coverage region of
trees and direct queries to the node at the top of the appropriate trees and direct queries to the node at the top of the appropriate
skipping to change at page 7, line 39 skipping to change at page 7, line 34
each cache lifetime. each cache lifetime.
6. Resolver 6. Resolver
A seeker can contact a forest guide (see below) directly, but may not A seeker can contact a forest guide (see below) directly, but may not
be able to easily locate such a guide. In addition, seekers in the be able to easily locate such a guide. In addition, seekers in the
same geographic area may already have asked the same question. Thus, same geographic area may already have asked the same question. Thus,
it makes sense to introduce another entity, known as a resolver in it makes sense to introduce another entity, known as a resolver in
the architecture, that knows how to contact one or more forest guides the architecture, that knows how to contact one or more forest guides
and caches earlier queries to accelerate the response to mapping and caches earlier queries to accelerate the response to mapping
queries and to improve the resiliency of the system. queries and to improve the resiliency of the system. Each resolver
can decide autonomously which FGs to use, with possibly different
From a protocol perspective, a resolver acts in the same way as a choices for each top-level service.
seeker, except that it knows one or more forest guides.
ISPs or VSPs would include the address of a suitable resolver in ISPs or VSPs would include the address of a suitable resolver in
their configuration information, i.e., in SIP configuration for a VSP their configuration information, e.g., in SIP configuration for a VSP
or DHCP [5] for an ISP. Resolvers are manually configured with the or DHCP [5] for an ISP. Resolvers are manually configured with the
name of one or more forest guides. 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) needing the information may entities, but clients (seekers) needing the information may
skipping to change at page 8, line 26 skipping to change at page 8, line 18
several child nodes each representing a smaller area. Each tree node several child nodes each representing a smaller area. Each tree node
can be a cluster of LoST servers that all contain the same can be a cluster of LoST servers that all contain the same
information and back up each 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 civic and geographic
coordinates for one type of service (such as 'sos.police', 'sos.fire' coordinates for one type of service (such as 'sos.police', 'sos.fire'
or 'counseling'), although nothing prevents re-using the same tree or 'counseling'), although nothing prevents re-using the same tree
for multiple different services. The collection of all trees for one for multiple different services. The collection of all trees for one
service is known as a forest. service is known as a forest.
Each tree root announces its coverage region to one or more forest
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 =
Bavaria"). These coverage regions may be aligned with political 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
skipping to change at page 11, line 38 skipping to change at page 11, line 33
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 facilitate orientation among the trees, we introduce a "forest guide"
guide". It is a server that keeps track of the coverage regions of (FG). It is a server that keeps track of the coverage regions of the
the trees. For scalability and reliability, there will need to be a trees. 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 any forest guide and will then be directed to the seeker can contact a suitable forest guide and will then be directed
right tree or, rarely, set of trees. Forest guides do not provide to the right tree or, rarely, set of trees. Forest guides do not
mapping information themselves. provide mapping information themselves, but rather redirect to
mapping servers. In some configurations, not all forest guides may
provide the same information, due to policy reasons.
Introducing forest guides avoids creating a global root, with the Introducing forest guides avoids creating a global root, with the
attendant management and control issues. Trees can also restrict attendant management and control issues. Trees can also restrict
their cooperation to parts of the information. For example, if their cooperation to parts of the information. For example, if
country C does not recognize country T, C can propagate tree regions country C does not recognize country T, C can propagate tree regions
for all but T. for all but T.
For authenticity, the records SHOULD be digitally signed. They are For authenticity, the records SHOULD be digitally signed. They are
used by resolvers and possibly seekers to find the appropriate tree used by resolvers and possibly seekers to find the appropriate tree
for a particular area. All forest guides should have consistent for a particular area. All forest guides should have consistent
skipping to change at page 15, line 12 skipping to change at page 15, line 12
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, Andrew Newton, Murugaraj Shanmugam, Richard Barnes, Jong Yul Kim, Otmar Lendl, Andrew Newton, Murugaraj
Richard Stastny, and Hannes Tschofenig provided helpful comments. 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 [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-02 (work in progress), October 2006. draft-ietf-ecrit-lost-05 (work in progress), March 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., "A Framework for Session Initiation Protocol User [4] Petrie, D. and S. Channabasappa, "A Framework for Session
Agent Profile Delivery", draft-ietf-sipping-config-framework-09 Initiation Protocol User Agent Profile Delivery",
(work in progress), October 2006. draft-ietf-sipping-config-framework-12 (work in progress),
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-00 Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-01
(work in progress), December 2006. (work in progress), March 2007.
[6] Rosen, B., "Framework for Emergency Calling in Internet [6] Rosen, B., "Framework for Emergency Calling in Internet
Multimedia", draft-ietf-ecrit-framework-00 (work in progress), Multimedia", draft-ietf-ecrit-framework-01 (work in progress),
October 2006. March 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-00 (work in progress), October 2006. draft-ietf-ecrit-phonebcp-01 (work in progress), March 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-12 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
August 2006. 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-03 Call Marking and Mapping", draft-ietf-ecrit-security-threats-04
(work in progress), July 2006. (work in progress), April 2007.
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-05 (work in progress), draft-ietf-ecrit-service-urn-06 (work in progress), March 2007.
August 2006.
[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
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 Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 25 change blocks. 
47 lines changed or deleted 49 lines changed or added

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