[要約] RFC 5582は、位置情報とURLのマッピングのアーキテクチャとフレームワークに関するものであり、位置情報をURLに関連付けるための方法を提供しています。その目的は、位置情報を使用して特定のリソースにアクセスするための一貫した方法を提供することです。
Network Working Group H. Schulzrinne
Request for Comments: 5582 Columbia U.
Category: Informational September 2009
Location-to-URL Mapping Architecture and Framework
場所からURLへのマッピングアーキテクチャとフレームワーク
Abstract
概要
This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS.
このドキュメントでは、場所からサービスへの位置情報をURLにマッピングするためのグローバル、スケーラブル、回復力があり、管理的に分散されたシステムのアーキテクチャについて説明します。アーキテクチャは、DNSなどの階層検索システムに見られる有名なアプローチを一般化します。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 4
4.1. The Principal Components . . . . . . . . . . . . . . . . . 4
4.2. Minimal System Architecture . . . . . . . . . . . . . . . 6
5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8
7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10
7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11
7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11
8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
It is often desirable to allow users to access a service that provides a common function but that is actually offered by a variety of local service providers. In many of these cases, the service provider chosen depends on the location of the person wishing to access that service. Among the best-known public services of this kind is emergency calling, where emergency calls are routed to the most appropriate public safety answering point (PSAP) based on the caller's physical location. Other services, from food delivery to directory services and roadside assistance, also follow this general pattern. This is a mapping problem [RFC5012], where a geographic location and a service identifier [RFC5031] is translated into a set of URIs, the service URIs, that allow the Internet system to contact an appropriate network entity that provides the service.
多くの場合、ユーザーが共通の機能を提供するサービスにアクセスできるようにすることが望ましいことがありますが、実際にはさまざまなローカルサービスプロバイダーが提供しています。これらのケースの多くでは、選択されたサービスプロバイダーは、そのサービスにアクセスしたい人の場所に依存します。この種の最も有名な公共サービスの中には、緊急通話があり、そこでは、発信者の物理的な場所に基づいて、緊急電話が最も適切な公共安全留守ポイント（PSAP）にルーティングされます。食品配達からディレクトリサービスや道端の支援まで、他のサービスもこの一般的なパターンに従います。これはマッピングの問題[RFC5012]であり、地理的位置とサービス識別子[RFC5031]が、インターネットシステムがサービスを提供する適切なネットワークエンティティに連絡できるようにするURISのURISのセットに翻訳されます。
The caller does not need to know from where the service is being provided, and the location of the service provider may change over time, e.g., to deal with temporary overloads, failures in the primary service provider location, or long-term changes in system architecture. For emergency services, this problem is described in more detail in [ECRIT-FRAME].
発信者は、サービスがどこから提供されているかを知る必要はなく、サービスプロバイダーの場所は時間とともに変化する可能性があります。建築。緊急サービスの場合、この問題については[ECRITフレーム]で詳細に説明します。
The overall emergency calling architecture [ECRIT-FRAME] separates mapping from placing calls or otherwise invoking the service, so the same mechanism can be used to verify that a mapping exists ("address validation") or to obtain test service URIs.
全体的な緊急通話アーキテクチャ[ECRITフレーム]は、マッピングが通話の配置またはその他のサービスの呼び出しから分離されているため、同じメカニズムを使用して、マッピングが存在すること（「アドレス検証」）を確認するか、テストサービスURIを取得することができます。
Mapping locations to URIs that describe services requires a distributed, scalable, and highly resilient infrastructure. Authoritative knowledge about such mappings is distributed among a large number of autonomous entities that may have no direct knowledge of each other. In this document, we describe an architecture for such a global service. It allows significant freedom to combine and split functionality among actual servers and imposes few requirements as to who should operate particular services.
サービスを説明するURIへの場所のマッピングには、分散、スケーラブル、および非常に回復力のあるインフラストラクチャが必要です。このようなマッピングに関する権威ある知識は、お互いの直接的な知識を持たない可能性のある多数の自律団体に分配されています。このドキュメントでは、このようなグローバルサービスのアーキテクチャについて説明します。これにより、実際のサーバー間で機能を組み合わせて分割するという大幅な自由が可能になり、誰が特定のサービスを運営する必要があるかについての要件がほとんどありません。
Besides determining the service URI, end systems also need to determine the local service numbers. As discussed in Section 9, the architecture described here can also address that problem.
サービスURIを決定することに加えて、END Systemsはローカルサービス番号も決定する必要があります。セクション9で説明したように、ここで説明するアーキテクチャは、その問題にも対処できます。
The architecture described here uses the Location-to-Service Translation (LoST) [RFC5222] protocol, although much of the discussion would also apply for other mapping protocols satisfying the mapping requirements [RFC5012].
ここで説明するアーキテクチャは、場所からサービスへの翻訳（Lost）[RFC5222]プロトコルを使用していますが、議論の多くは、マッピング要件を満たす他のマッピングプロトコルにも適用されます[RFC5012]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [RFC2119]で説明されているように解釈され、準拠の実装の要件レベルを示します。
In addition to the terms defined in [RFC5012], this document uses the following terms to describe LoST clients and servers:
[RFC5012]で定義されている用語に加えて、このドキュメントでは、次の用語を使用して、失われたクライアントとサーバーを説明します。
authoritative mapping server (AMS): An authoritative mapping server (AMS) is a LoST server that can provide the authoritative answer to a particular set of queries, e.g., covering a set of Presence Information Data Information Location Object (PIDF-LO) civic labels or a particular region described by a geometric shape. In some (rare) cases of territorial disputes, two resolvers may be authoritative for the same region. An AMS may redirect or forward a query to another AMS within the tree.
権威あるマッピングサーバー（AMS）：権威あるマッピングサーバー（AMS）は、特定の一連のクエリに権威ある回答を提供できる失われたサーバーです。または、幾何学的な形状で記述された特定の領域。領土紛争の一部の（まれな）ケースでは、同じ地域で2つのリゾルバーが権威ある場合があります。AMSは、ツリー内の別のAMSにクエリをリダイレクトまたは転送する場合があります。
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.
子供：子供は、別のAMSのサブリージョンに対して権威あるAMSです。子供は順番に別のAMSの親になることができます。
(tree node) cluster: A node cluster is a group of LoST servers that all share the same mapping information and return the same results for queries. Clusters provide redundancy and share query load. Clusters are fully-meshed, i.e., they all exchange updates with 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, contiguous and may be represented as either a subset of a civic address or a geometric object.
カバレッジ領域：AMSのカバレッジ領域は、AMSがマッピングクエリに信頼できるように回答できる地理的地域です。カバレッジ領域は一般に、必ずしも隣接するものではありませんが、市民住所のサブセットまたは幾何学的オブジェクトのいずれかとして表される場合があります。
forest guide (FG): A forest guide (FG) has knowledge of the coverage region of trees for a particular top-level service.
Forest Guide（FG）：Forest Guide（FG）は、特定のトップレベルサービスのための木のカバレッジ領域に関する知識を持っています。
mapping: A mapping is a short-hand for 'mapping from a location object to either another mapping server or the desired service URLs'.
マッピング：マッピングは、「ロケーションオブジェクトから別のマッピングサーバーまたは目的のサービスURLへのマッピング」の短い手です。
parent: A mapping server that covers the region of all of its children. A mapping server without a parent is a root AMS.
親：すべての子供の地域をカバーするマッピングサーバー。親のないマッピングサーバーはルートAMSです。
resolver: A resolver is contacted by a seeker, consults a forest mapping server, and then resolves the query using an appropriate tree. Resolvers may cache query results.
リゾルバー：リゾルバーはシーカーから連絡し、フォレストマッピングサーバーに相談し、適切なツリーを使用してクエリを解決します。リゾルバーはクエリの結果をキャッシュする場合があります。
seeker: A seeker is a LoST client requesting a mapping. A seeker does not provide mapping services to others but may cache results for its own use.
シーカー：シーカーは、マッピングを要求する失われたクライアントです。シーカーは他の人にマッピングサービスを提供しませんが、それ自体で使用するために結果をキャッシュする場合があります。
tree: A tree consists of a self-contained hierarchy of authoritative mapping servers for a particular service. Each tree exports its coverage region to the forest mapping servers.
ツリー：ツリーは、特定のサービス用の権威あるマッピングサーバーの自己完結型の階層で構成されています。各ツリーは、カバレッジ領域をフォレストマッピングサーバーにエクスポートします。
The mapping architecture distinguishes four logical roles: seekers, resolvers, authoritative mapping servers (AMS), and forest guides (FGs). End users of the LoST-based [RFC5222] mapping mechanism, called seekers, contact resolvers that cache query results and know 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 consist of authoritative mapping servers and maintain the authoritative mapping information.
マッピングアーキテクチャは、シーカー、リゾルバー、信頼できるマッピングサーバー（AMS）、およびフォレストガイド（FG）の4つの論理的役割を区別します。失われたベースの[RFC5222]マッピングメカニズム（シーカーと呼ばれるマッピングメカニズム）のエンドユーザーは、キャッシュが結果をクエリし、1つ以上の森林ガイドを知っているリゾルバーに連絡します。フォレストガイドは、概念的な階層の最上位レベルを形成し、1つ以上の木がさまざまな地理的地域の階層解像度サービスを提供します。フォレストガイドは、すべてまたはほぼすべての木の地理的カバレッジ領域を知っており、適切なツリーの上部にあるノードへの直接クエリを示しています。ツリーは、信頼できるマッピングサーバーで構成され、権威あるマッピング情報を維持しています。
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, authoritative mapping server, and forest guide. In addition to the basic LoST query protocol [RFC5222], a synchronization protocol [LOST-SYNC] may be used to exchange information between forest guides or to push coverage information from a tree node to its parent.
探求者、リゾルバー、権威あるマッピングサーバー、およびフォレストガイドはすべて、失われたものを使用して通信します。実際、多くの場合、同じソフトウェアがリゾルバー、信頼できるマッピングサーバー、およびForest Guideとして動作できる可能性があります。Basic Lost Queryプロトコル[RFC5222]に加えて、同期プロトコル[Lost-Sync]を使用して、森林ガイド間の情報を交換したり、ツリーノードからその親にカバレッジ情報を押したりすることもできます。
Seekers may be part of Voice over IP (VoIP) or other end systems, or of SIP proxies or similar call routing functions.
シーカーは、Voice over IP（VoIP）またはその他のエンドシステム、またはSIPプロキシまたは同様のコールルーティング関数の一部である場合があります。
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 [LOST-SYNC].
図1は、コンポーネントの相互作用を示しています。森林ガイド間の接続を示す線は論理的な接続であり、同期プロトコル[Lost-Sync]を介して情報を同期していることを示しています。
/-\ /-\ +-----+ +-----+
| S +******* R ********* FG *-----------------+ FG |
\-/ \-/ | |* | |
+--+--+ * +--+--+
| * |
| * |
| * |
| * |
/-\ +--+--+ * +--+--+
| R +------>+ FG +-----*-----------+ FG |
\-/ | | * | |
+--+--+ * +--+--+
| * |
| * |
| * |
|*** ^
/ \ / \
/ \ / \
/ \ / \
/ \ / \
----------- -----------
tree tree
Architecture diagram, showing seekers (S), resolvers (R), forest guides (FG), and trees. The star (*) line indicates the flow of the query and responses in recursive mode, while the lines indicate synchronization relationships.
アーキテクチャ図、探求者、リソースバー（R）、フォレストガイド（FG）、および木を示す。星（*）線は、再帰モードでのクエリのフローと応答を示し、線は同期関係を示します。
Figure 1
図1
The mapping function for the world is divided among trees. The 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 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 will likely be somewhere between a few hundred and a few thousand. The lower estimate would apply if each country operates one tree, the higher if different governmental or private organizations within a country operate independent trees. We assume that tree coverage information changes relatively slowly, on the order of less than one change per year per tree, although the system imposes no specific threshold. Tree coverage would change, for example, if a country is split or merged or if two trees for different regions become part of a larger tree. (On the other hand, information within a tree is likely to change much more frequently.)
世界のマッピング関数は木々に分かれています。木のコレクションは全世界を覆わない可能性があり、データのマッピングの組織化として木が追加され、削除されます。木のコレクションを森と呼びます。森林内の木の数に制限はありませんが、著者は、木の数はおそらく数百から数千の間にあると推測しています。各国が1つの木を運営している場合、より低い見積もりは適用されます。システムには特定のしきい値を課さないが、ツリーカバレッジ情報は、ツリーごとに1年に1回未満の順序で比較的ゆっくりと変化すると想定しています。たとえば、国が分割されているかマージされている場合、または異なる領域の2本の木がより大きな木の一部になった場合、ツリーカバレッジは変化します。（一方、ツリー内の情報は、はるかに頻繁に変化する可能性があります。）
It is possible to build a functioning system consisting only of seekers and resolvers if these resolvers have other means of obtaining mapping data. For example, a company acting as a mapping service provider could collect mapping records manually and make them available to their customers through the resolver. While feasible as a starting point, such an architecture is unlikely to scale globally. Among other problems, it becomes very hard for providers of authoritative data to ensure that all such providers have up-to-date information. If new trees are set up, they would somehow make themselves known to these providers. Such a mechanism would be similar to the old "hosts.txt" mechanism for distributing host information in the early Internet before DNS was developed.
これらのリゾルバーにマッピングデータを取得する他の手段がある場合、シーカーとリゾルバーのみで構成される機能システムを構築することが可能です。たとえば、マッピングサービスプロバイダーとして行動する会社は、マッピングレコードを手動で収集し、リゾルバーを介して顧客が利用できるようにすることができます。出発点として実行可能ですが、このようなアーキテクチャはグローバルに拡大する可能性は低いです。他の問題の中でも、権威あるデータのプロバイダーがそのようなすべてのプロバイダーに最新の情報を確保することが非常に困難になります。新しい木が設置されている場合、彼らはどういうわけかこれらのプロバイダーに自分自身を知らせます。このようなメカニズムは、DNSが開発される前に初期のインターネットでホスト情報を配布するための古い「hosts.txt」メカニズムに似ています。
Below, we describe the operation of each component in more detail.
以下に、各コンポーネントの操作についてさらに詳しく説明します。
Clients desiring location-to-service mappings are known as seekers. Seekers are consumers of mapping data and originate LoST queries as LoST protocol clients. Seekers do not answer LoST queries. They contact either forest guides or resolvers to find the appropriate tree that can authoritatively answer their questions. Seekers can be end systems such as SIP user agents, or call routing entities such as SIP proxy servers.
場所からサービスへのマッピングを希望するクライアントは、探求者として知られています。探求者はデータのマッピングの消費者であり、失われたプロトコルクライアントとして失われたクエリを発信します。探求者は失われたクエリに答えません。彼らは、フォレストガイドまたはリゾルバーのいずれかに連絡して、彼らの質問に権威ある質問に答えることができる適切なツリーを見つけます。シーカーは、SIPユーザーエージェントなどのエンドシステムになるか、SIPプロキシサーバーなどのルーティングエンティティを呼び出すことができます。
Seekers may need to obtain mapping information in several steps, i.e., they may obtain pointers to intermediate servers that lead them closer to the final mapping. Seekers MAY cache query results for later use but otherwise have no obligations to other entities in the system.
探求者は、いくつかのステップでマッピング情報を取得する必要がある場合があります。つまり、最終的なマッピングに近づく中間サーバーへのポインターを取得する場合があります。探求者は、後で使用するためにクエリの結果をキャッシュする場合がありますが、それ以外の場合はシステム内の他のエンティティに義務がありません。
Seekers need to be able to identify appropriate resolvers. The mechanism for providing seekers with that information is likely to differ depending on who operates the resolvers. For example, if the voice service provider operates the resolver, it might include the location of the resolver in the SIP configuration information it distributes to its user agents. An Internet access provider or enterprise can provide a pointer to a resolver via DHCP [RFC5223]. In an ad hoc or zero-configuration environment, appropriate service directories may advertise resolvers.
探求者は、適切なリゾルバーを特定できる必要があります。求職者にその情報を提供するメカニズムは、リソースバーを操作する人によって異なる可能性があります。たとえば、音声サービスプロバイダーがリゾルバーを操作する場合、ユーザーエージェントに配布するSIP構成情報にリゾルバーの場所が含まれる場合があります。インターネットアクセスプロバイダーまたはエンタープライズは、DHCP [RFC5223]を介してリゾルバーへのポインターを提供できます。アドホックまたはゼロ構成環境では、適切なサービスディレクトリがリゾルバーを宣伝する場合があります。
Like other entities in the system, seekers can cache responses. This is particularly useful if the response describes the result for a civic or geospatial region, rather than just a point. For example, for mobile nodes, seekers would only have to update their resolution results when they leave the coverage area of a service provider, such as a PSAP for emergency services, and can avoid repeatedly polling for this information whenever the location information changes slightly. (Mobile nodes would also need a location update mechanism that is either local or triggered when they leave the current service area.) This will likely be of particular benefit for seekers representing a large user population, such as the outbound proxy in a corporate network. For example, rather than having to query separately for each cubicle, information provided by the authoritative node may indicate that the whole campus is covered by the same service provider.
システム内の他のエンティティと同様に、シーカーは応答をキャッシュできます。これは、応答が単なるポイントではなく、市民または地理空間地域の結果を説明する場合に特に役立ちます。たとえば、モバイルノードの場合、探求者は、緊急サービスのPSAPなど、サービスプロバイダーのカバレッジエリアを離れるときにのみ解決結果を更新する必要があり、位置情報がわずかに変化するたびにこの情報の繰り返しの投票を避けることができます。（モバイルノードには、現在のサービスエリアを離れるときにローカルまたはトリガーされるロケーション更新メカニズムも必要です。）これは、企業ネットワークのアウトバウンドプロキシなど、大規模なユーザー母集団を表す探求者にとって特に利点があるでしょう。たとえば、各キュービクルを個別にクエリする必要があるのではなく、権威あるノードが提供する情報は、キャンパス全体が同じサービスプロバイダーでカバーされていることを示している場合があります。
Given this caching mechanism and cache lifetimes of several days, most mobile users traveling to and from work would only need to obtain service area information along their commute route once during each cache lifetime.
このキャッシングメカニズムと数日間のキャッシュ寿命を考えると、職場と出入りするほとんどのモバイルユーザーは、各キャッシュの寿命に一度通勤ルートに沿ってサービスエリア情報を取得するだけです。
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 same geographic area may already have asked the same question. Thus, it makes sense to introduce another entity, known as a resolver in the architecture, that knows how to contact one or more forest guides and that caches earlier queries to accelerate the response to mapping queries and to improve the resiliency of the system. Each resolver can decide autonomously which FGs to use, with possibly different choices for each top-level service.
シーカーは、森林ガイド（以下を参照）に直接連絡できますが、そのようなガイドを簡単に見つけることができない場合があります。さらに、同じ地理的地域の探求者は、すでに同じ質問をしているかもしれません。したがって、アーキテクチャのリゾルバーとして知られる別のエンティティを導入することは理にかなっています。これは、1つ以上の森林ガイドに連絡する方法を知っており、以前のクエリをキャッシュして、マッピングクエリへの応答を加速し、システムの復元力を改善することです。各リゾルバーは、どのFGを使用するかを自律的に決定でき、各トップレベルサービスに対しておそらく異なる選択肢があります。
ISPs or Voice Service Providers (VSPs) may include the address of a suitable resolver in their configuration information, e.g., in SIP configuration for a VSP or DHCP [RFC5223] for an ISP. Resolvers are manually configured with the name of one or more forest guides.
ISPまたは音声サービスプロバイダー（VSP）には、構成情報に適切なリゾルバーのアドレスを含めることができます。たとえば、ISPのVSPまたはDHCP [RFC5223]のSIP構成などです。リゾルバーは、1つ以上のフォレストガイドの名前で手動で構成されています。
The architecture assumes that authoritative knowledge about the mapping data is distributed among many independent administrative entities, but clients (seekers) may potentially need to find out mapping information for any spot on earth. (Extensions to extra-terrestrial applications are left for future exploration.) Information is organized hierarchically, in a tree, with tree nodes representing larger geographic areas pointing to several child nodes, each representing a smaller area. Each tree node can be a cluster of LoST servers that all contain the same information and back up each other.
アーキテクチャは、マッピングデータに関する権威ある知識は多くの独立した管理エンティティに分散されていると想定していますが、クライアント（探求者）は、地球上のあらゆる場所のマッピング情報を見つける必要がある可能性があります。（地球外アプリケーションへの拡張は、将来の探索のために残されます。）情報は、ツリー内で階層的に編成され、ツリーノードはいくつかの子ノードを指す大きな地理的領域を表し、それぞれがより小さな領域を表しています。各ツリーノードは、すべて同じ情報を含んで互いにバックアップする失われたサーバーのクラスターにすることができます。
Each tree can map a location described by either civic or geographic coordinates, but not both, for one type of service (such as 'sos.police', 'sos.fire' or 'counseling') and one location profile, although nothing prevents re-using the same servers for multiple, different services or both types of coordinates. The collection of all trees for one service and location profile is known as a forest.
各ツリーは、1つのタイプのサービス（「sos.police」、「sos.fire」、「councounsing」など、市民または地理的座標のいずれかで記述された場所をマッピングできますが、両方ではありません。複数の異なるサービス、または両方のタイプの座標に対して同じサーバーを再利用します。1つのサービスとロケーションプロファイルのすべての木のコレクションは、森林として知られています。
Each tree root announces its coverage region to one or more forest guides.
各ツリールートは、そのカバレッジ地域を1つ以上の森林ガイドに発表します。
Each tree node cluster knows the coverage region of its children and sends queries to the appropriate server "down" the tree. Each such tree node knows authoritatively about the service mappings for a particular region, typically, but not necessarily, contiguous. The region can be described by any of the shapes in the LoST specification expressed in geospatial coordinates, such as circles or 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 confusion, only one cluster is responsible for a particular geographic or civic location, but the system can also deal with cases where coverage regions overlap.
各ツリーノードクラスターは、子供のカバレッジ領域を把握し、適切なサーバーにツリーを「下」に送信します。そのような各ツリーノードは、特定の地域のサービスマッピングについて、通常は隣接するものではありません。この領域は、円やポリゴンなどの地理空間座標で表される失われた仕様の形状、または市民住所記述子のセットによって説明できます（例：「国= de、a1 = bavaria」）。これらのカバレッジ領域は政治的境界に沿っている場合がありますが、それは必要ありません。ほとんどの場合、混乱を避けるために、特定の地理的または市民の場所に責任があるクラスターは1つだけですが、システムはカバレッジ領域が重複する場合にも対処できます。
There are no assumptions about the coverage region of a tree as a whole. For example, a tree could cover a single city, a state/ province, or a whole country. Nodes within a tree need to loosely coordinate their operation, but they do not need to be operated by the same administrator.
木全体のカバレッジ領域についての仮定はありません。たとえば、木は単一の都市、州/州、または全国を覆うことができます。ツリー内のノードは、操作を大まかに調整する必要がありますが、同じ管理者が操作する必要はありません。
The tree architecture is roughly similar to the domain name system (DNS), except that delegation is not by label but rather by region. (Naturally, DNS does not have the notion of forest guides.) One can also draw analogies to the Lightweight Directory Access Protocol (LDAP) when deployed in a distributed fashion.
ツリーアーキテクチャは、ドメイン名システム（DNS）とほぼ類似しています。ただし、委任はラベルごとではなく、地域ごとです。（当然、DNSには森林ガイドの概念がありません。）分散ファッションで展開された場合、Lightweight Directory Access Protocol（LDAP）に類似を描くこともできます。
Tree nodes maintain two types of information -- namely, coverage regions and mappings. Coverage regions describe the region served by a child node in the tree and point to a child node for further resolution. Mappings contain an actual service URI leading to a service provider or another signaling server representing a group of service providers, which in turn might further route signaling requests to more servers covering smaller regions.
ツリーノードは、カバレッジ領域とマッピングの2種類の情報を維持します。カバレッジ領域は、ツリー内の子ノードが提供する領域を説明し、さらに解決するために子ノードを指しています。マッピングには、サービスプロバイダーまたはサービスプロバイダーのグループを表す別のシグナリングサーバーにつながる実際のサービスURIが含まれています。
Leaf nodes, i.e., nodes without children, only maintain mappings, while tree nodes above the leaf nodes only maintain coverage regions. An example for emergency services of a leaf node entry is shown below, indicating how queries for three towns are directed to different PSAPs. Queries for Englewood are directed to another LoST server instead.
葉のノード、つまり子供のないノードはマッピングのみを維持しますが、葉のノードの上のツリーノードはカバレッジ領域のみを維持します。葉のノードエントリの緊急サービスの例を以下に示します。3つの町のクエリが異なるPSAPにどのように向けられているかを示します。Englewoodのクエリは、代わりに別のLost Serverに送られます。
country A1 A2 A3 resource or LoST server
US NJ Bergen Leonia sip:psap@leonianj.gov
US NJ Bergen Fort Lee sip:emergency@fortleenj.org
US NJ Bergen Teaneck sip:police@teanecknjgov.org
US NJ Bergen Englewood englewoodnj.gov
....
Coverage regions are described by sets of LoST-compatible shapes enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs the same matching operation as described in Section 12.2 of the LoST specification [RFC5222] to find the tree or AMS.
カバレッジ領域は、隣接する地理的領域を囲む失われた互換性のある形状のセットまたは市民の場所のグループを列挙する記述子によって説明されています。前者の場合、Lost Serverは、Lost Specification [RFC5222]のセクション12.2で説明されているのと同じマッチング操作を実行して、ツリーまたはAMSを見つけます。
As a civic location example, a state-level tree node for New Jersey in the United States may contain the coverage region entries shown below, indicating that any query matching a location in Bergen County, for example, would be redirected or forwarded to the node located at bergen.nj.example.org.
市民の場所の例として、米国のニュージャージー州の州レベルのツリーノードには、以下に示すカバレッジ地域のエントリが含まれている場合があります。たとえば、ベルゲン郡の場所に一致するクエリがノードにリダイレクトまたは転送されることを示しています。bergen.nj.example.orgにあります。
There is no requirement that all child nodes 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 within the state node, rather than through the county. Longest-match rules allow partial coverage so that queries for all other towns within Essex county would be directed to the county node for further resolution.
すべての子供ノードが市民階層内で同じレベルをカバーするという要件はありません。例として、以下の表では、ニューアーク市は郡を介してではなく、州のノード内に直接リストされることを決定しました。最も長い試合規則では、エセックス郡内の他のすべての町の質問が郡ノードに向けてさらに解決するために、部分的なカバレッジを許可します。
C A1 A2 A3 LoST server name
US NJ Atlantic * atlantic.nj.example.org/sos
US NJ Bergen * bergen.nj.example.org/sos
US NJ Monmouth * monmouth.nj.example.org/sos
US NJ Essex * essex.nj.example.org/sos
US NJ Essex Newark newark.example.com/sos
....
Thus, there is no substantial difference between coverage region and mapping data. The only difference is that coverage regions return names of LoST servers, while mapping entries contain service URLs. Mapping entries may be specific down to the house- or floor-level or may only contain street-level information. For example, in the United States, civic mapping data for emergency services is generally limited to address ranges ("MSAG data"), so initial mapping databases may only contain street-level information.
したがって、カバレッジ領域とマッピングデータの間に大きな違いはありません。唯一の違いは、カバレッジ領域が失われたサーバーの名前を返すことですが、マッピングエントリにはサービスURLが含まれていることです。マッピングエントリは、家または床レベルに固有のものであるか、ストリートレベルの情報のみを含む場合があります。たとえば、米国では、緊急サービスの市民マッピングデータは一般に範囲の対処（「MSAGデータ」）に限定されているため、初期マッピングデータベースにはストリートレベルの情報のみが含まれている場合があります。
To automate the maintenance of trees, the LoST synchronization mechanism [LOST-SYNC] allows nodes to query other nodes for mapping data and coverage regions, both within a cluster and across different hierarchy levels in a tree. In the example above, the state-run node would query the county nodes and use the records returned to distribute incoming LoST queries to the county nodes. Conversely, nodes could also contact their parent nodes to tell them about their coverage region. There is some benefit of child nodes contacting their parents, as this allows changes in coverage regions to propagate quickly up the tree.
ツリーのメンテナンスを自動化するために、失われた同期メカニズム[Lost-Sync]により、ノードは、クラスター内およびツリー内の異なる階層レベルの両方で、データとカバレッジ領域のマッピングのために他のノードを照会できます。上記の例では、国営ノードは郡ノードを照会し、返されたレコードを使用して、郡ノードに着信された失われたクエリを配布します。逆に、ノードは親ノードに連絡して、カバレッジ領域について伝えることもできます。これにより、カバレッジ領域の変更がツリーをすばやく伝播できるようにするため、両親に連絡する子ノードの利点があります。
Within a tree, the basic operation is straightforward. A query reaches the root of the tree. That node determines which coverage region matches that request and forwards the request to the server indicated in the coverage region record, returning a response to the querier when it in turn receives an answer (recursion). Alternatively, the node returns the application unique string (server name) of that child node to the querier (iteration). This process applies to each node, i.e., a node does not need to know whether the original query came from a parent node, a seeker, a forest guide, or a resolver.
ツリー内では、基本操作は簡単です。クエリがツリーのルートに到達します。そのノードは、どのカバレッジ領域がその要求を一致させ、リクエストをカバレッジ領域記録に示すサーバーに転送するかを決定し、回答を受け取ったときにクエリエへの応答を返します（再帰）。あるいは、ノードは、その子ノードのアプリケーションの一意の文字列（サーバー名）をクエリエ（反復）に返します。このプロセスは各ノードに適用されます。つまり、ノードは、元のクエリが親ノード、シーカー、フォレストガイド、またはリゾルバーから来たかどうかを知る必要はありません。
For efficiency, a node MAY return region information instead of a point answer. Thus, instead of returning that a particular geospatial coordinate maps to a service URL or server name, it MAY return a polygon indicating the region for which this answer would be returned, along with expiration time (time-to-live) information. The querying node can then cache this information for future use.
効率のために、ノードはポイントアンサーの代わりに地域情報を返す場合があります。したがって、特定の地理空間座標がサービスURLまたはサーバー名にマップすることを返す代わりに、この回答が返される領域を示すポリゴンを返す可能性があり、有効期限（寿命までの時間）情報があります。クエリノードは、将来の使用のためにこの情報をキャッシュできます。
For civic coordinates, trees may not include individual mapping records for each floor, house number, or street. To avoid giving the wrong indication that a particular location has been found valid, LoST can indicate which parts of the location information have actually been used to look up a mapping.
市民座標の場合、木は各フロア、家番号、または通りの個々のマッピングレコードを含めることはできません。特定の場所が有効であることが判明したという誤った兆候を与えることを避けるために、失われた場所は、マッピングの検索に実際に使用されている位置情報を示すことができます。
In some cases, coverage regions may overlap, either because there is a dispute as to who handles a particular geographic region or, more likely, because the resolution of the coverage map may not be sufficiently high. For example, a node may "shave some corners" off its polygon so that its coverage region appears to overlap with its geographic neighbor. For civic coordinates, houses on the same street may be served by different PSAPs. The mapping mechanism needs to work even if a coverage map is imprecise or if there are disputes about coverage.
場合によっては、特定の地理的領域を誰が処理するかについての論争があるため、またはカバレッジマップの解決が十分に高くない可能性が高いため、カバレッジ領域が重複する場合があります。たとえば、ノードはポリゴンから「角を剃る」ため、そのカバレッジ領域は地理的な隣接と重複しているように見えます。市民座標の場合、同じ通りの家には異なるPSAPが提供される場合があります。カバレッジマップが不正確である場合、またはカバレッジに関する紛争がある場合でも、マッピングメカニズムは機能する必要があります。
The solution for overlapping coverage regions is relatively simple. If a query matches multiple coverage regions, the node returns all URLs or server names, in redirection mode, or queries both children, if in recursive mode. If the overlapping coverage is caused by imprecise coverage maps, only one will return a result and the others will return an error indication. If the particular location is disputed territory, the response will contain all answers, leaving it to the querier to choose the preferred solution or try to contact all services in turn.
重複するカバレッジ領域のソリューションは比較的簡単です。クエリが複数のカバレッジ領域と一致する場合、ノードはリダイレクトモードですべてのURLまたはサーバー名を返し、再帰モードの場合、両方の子供をクエリします。重複するカバレッジが不正確なカバレッジマップによって引き起こされる場合、結果を返すのは1つだけで、他のカバレッジはエラー表示を返します。特定の場所が争われている領土である場合、応答にはすべての回答が含まれ、それをクエリエに任せて優先ソリューションを選択するか、すべてのサービスに順番に連絡しようとします。
Since they provide authoritative information, tree nodes need to be highly reliable. Thus, while this document refers to tree nodes as logical entities within the tree, an actual implementation would likely replicate node information across several servers, forming a cluster. Each such node would have the same information. Standard techniques such as DNS SRV records can be used to select one of the servers. Replication within the cluster can use any suitable protocol mechanism, but a standardized, incremental update mechanism makes it easier to spread those nodes across multiple independently administered locations. The techniques developed for the meshed Service Location Protocol (SLP) [RFC3528] are applicable here.
彼らは権威ある情報を提供するので、ツリーノードは非常に信頼性が高い必要があります。したがって、このドキュメントはツリーノードをツリー内の論理エンティティと呼びますが、実際の実装は、いくつかのサーバー全体でノード情報を再現してクラスターを形成する可能性があります。そのようなノードにはそれぞれ同じ情報があります。DNS SRVレコードなどの標準的な手法を使用して、サーバーの1つを選択できます。クラスター内のレプリケーションは、適切なプロトコルメカニズムを使用できますが、標準化された増分更新メカニズムにより、複数の独立して管理された位置にこれらのノードを簡単に拡散できます。Meshed Service Location Protocol（SLP）[RFC3528]のために開発された手法は、ここで適用されます。
Unfortunately, just having trees covering various regions of the 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 facilitate orientation among the trees, we introduce a forest guide (FG), which keeps track of the coverage regions of all the trees for one service and location profile. For scalability and reliability, there will need to be a large number of forest guides, all providing the same information. A seeker can contact a suitable forest guide and will then be directed to the right tree or, rarely, set of trees. Forest guides do not 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.
残念ながら、マッピングプロトコルのクライアントは一般に森のすべての木を追跡することはできないため、世界のさまざまな地域をカバーする木を持っているだけでは十分ではありません。木の間の方向を容易にするために、1つのサービスと場所のプロファイルのために、すべての木のカバレッジ領域を追跡する森林ガイド（FG）を紹介します。スケーラビリティと信頼性のために、多くの森林ガイドが必要であり、すべて同じ情報を提供します。シーカーは適切な森林ガイドに連絡し、その後、正しい木またはめったに木のセットに向けられます。フォレストガイドは、マッピング情報自体を提供するのではなく、マッピングサーバーにリダイレクトします。一部の構成では、政策上の理由により、すべての森林ガイドが同じ情報を提供するわけではありません。
Forest guides fulfill a similar role to root servers in DNS. They distribute information, signed for authenticity, offered by trees. However, introducing forest guides avoids creating a global root, with the attendant management and control issues.
フォレストガイドは、DNSのルートサーバーと同様の役割を果たします。彼らは、木々によって提供される真正性のために署名された情報を配布します。ただし、フォレストガイドを導入することで、アテンダントの管理と制御の問題があるグローバルルートの作成を回避できます。
However, unlike DNS root servers, forest guides may offer different 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.
ただし、DNSルートサーバーとは異なり、Forestガイドはローカルポリシーに基づいて異なる情報を提供する場合があります。フォレストガイドは、データの同期を情報の一部に制限することもできます。たとえば、国Cが国Tを認識していない場合、CはTを除くすべてのものに対してツリー領域を伝播できます。
For authenticity, the coverage regions SHOULD be digitally signed by the authorities responsible for the region, as discussed in more detail in Section 10. They are 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 other guides. Due to policy and maybe political reasons, not all forest guides may share the same coverage region data.
信頼性のために、セクション10で詳細に説明するように、カバレッジ地域は、地域の責任者当局によってデジタル的に署名する必要があります。これらは、特定のエリアに適したツリーを見つけるためにリソースバーとおそらく求められている人によって使用されます。すべての森林ガイドには、一貫した情報、つまりすべての木のすべてのカバレッジ領域のコレクションが必要です。ツリーの上部にあるツリーノードは、任意の森林ガイドに連絡し、新しいカバレッジ領域情報をシステムに注入できます。各ツリーが複数の森林ガイドへのカバレッジを発表することを期待するでしょう。各フォレストガイドの仲間は、他の1つ以上のガイドと一緒に仲間をガイドし、他のガイドに新しいカバレッジ地域の発表を配布します。政策と政治的理由により、すべての森林ガイドが同じカバレッジ地域データを共有するわけではありません。
Forest guides can, in principle, be operated by anybody, including voice service providers, Internet access providers, dedicated services providers, and enterprises.
フォレストガイドは、原則として、音声サービスプロバイダー、インターネットアクセスプロバイダー、専用サービスプロバイダー、企業など、誰でも運営できます。
As in routing, peering with other forest guides implies a certain amount of trust in the peer. Thus, peering is likely to require some negotiation between the administering parties concerned, rather than automatic configuration. The mechanism itself does not imply a particular policy as to who gets to advertise a particular coverage region.
ルーティングと同様に、他の森林ガイドとの覗き見は、ピアに対するある程度の信頼を意味します。したがって、ピアリングは、自動構成ではなく、関係者の間の交渉を必要とする可能性があります。メカニズム自体は、特定のカバレッジ領域を宣伝できる人に関する特定のポリシーを意味するものではありません。
The section below is not directly related to the problem of determining service location but is an instance of the more generic problem solved by this architecture -- namely, mapping location information to service-related parameters, such as service numbers.
以下のセクションは、サービスの場所を決定する問題に直接関係していませんが、このアーキテクチャによって解決されるより一般的な問題のインスタンス、つまり、サービス番号などのサービス関連パラメーターに位置情報をマッピングするインスタンスです。
For the foreseeable future, some user devices and software will emulate the user interface of a telephone, i.e., the only way to enter call address information is via a 12-button keypad with digits and the asterisk and hash symbols. These devices use service numbers to identify services. The best-known examples of service numbers are emergency numbers, such as 9-1-1 in North America and 1-1-2 in Europe. However, many other public and private service numbers have been defined, ranging in the United States from 3-1-1 for non-emergency local government services to 4-1-1 for directory assistance, to various "800" numbers for anything from roadside assistance to legal services to home-delivery food.
近い将来、一部のユーザーデバイスとソフトウェアは電話のユーザーインターフェイスをエミュレートします。つまり、コールアドレス情報を入力する唯一の方法は、数字とアスタリスクとハッシュシンボルを備えた12ボタンキーパッドを介してです。これらのデバイスは、サービス番号を使用してサービスを特定します。サービス番号の最もよく知られている例は、北米で9-1-1やヨーロッパでは1-1-2などの緊急番号です。ただし、他の多くの公的および民間サービス番号が定義されており、米国では3-1-1から非緊急地方自治体サービスの場合は、ディレクトリ支援のために4-1-1まで、からのさまざまな「800」の数値までの範囲で定義されています。家庭用食品への法的サービスへの道端の支援。
Such service numbers are likely to be used until essentially all communication devices feature IP connectivity and an alphanumeric keyboard. Unfortunately, for emergency services, more than 60 emergency numbers are in use throughout the world, with many of those numbers serving non-emergency purposes elsewhere, e.g., identifying repair or directory services. Countries also occasionally change their emergency numbers to conform to regional agreements. An example is the introduction of "1-1-2" for countries in Europe.
このようなサービス番号は、基本的にすべての通信デバイスがIP接続と英数字キーボードを備えるまで使用される可能性があります。残念ながら、緊急サービスの場合、世界中で60を超える緊急番号が使用されており、これらの数字の多くは他の場所で非緊急目的で役立っています。たとえば、修理またはディレクトリサービスを特定しています。また、国々は時折、緊急数を変更して地域協定に準拠します。例は、ヨーロッパの国の「1-1-2」の導入です。
Thus, a system that allows devices to be used internationally to place calls needs to allow devices to discover service numbers automatically. In the Internet-based system proposed in [ECRIT-FRAME], these numbers are strictly used as a human-user interface mechanism and are generally not visible in call signaling messages, which carry the service URN [RFC5031] instead.
したがって、デバイスを国際的に使用できるようにするシステムは、コールを配置する必要があります。デバイスが自動的にサービス番号を発見できるようにする必要があります。[ecrit-frame]で提案されているインターネットベースのシステムでは、これらの数値は人間ユーザーインターフェイスメカニズムとして厳密に使用されており、代わりにサービスurn [RFC5031]を運ぶコールシグナリングメッセージでは見えません。
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 and those used in the country the user is currently visiting. The user is most likely to remember the former, but a companion borrowing a device in an emergency, say, may only know the local emergency numbers.
最高のユーザーエクスペリエンスのために、システムは2つのサービス番号を発見できるはずです。つまり、ユーザーの母国で使用されているものと、ユーザーが現在訪問している国で使用されているものです。ユーザーは前者を覚えている可能性が最も高くなりますが、緊急時にデバイスを借りる仲間は、現地の緊急人数のみを知っている場合があります。
Determining home and local service numbers is a configuration problem, but unfortunately, existing configuration mechanisms are ill-suited for this purpose. For example, a DHCP server might be able to provide the local service numbers but not the home numbers. When virtual private networks (VPNs) are used, even DHCP may provide numbers of uncertain origin, as a user may contact the home network or some local branch office of the corporate network. Similarly, SIP configuration [CONFIG-FRAME] would be able to provide the numbers valid at the location of the SIP service provider, but even a SIP service provider with a national footprint may serve customers that are visiting any number of other countries.
ホームおよびローカルのサービス番号を決定することは構成の問題ですが、残念ながら、既存の構成メカニズムはこの目的に適していません。たとえば、DHCPサーバーは、ホーム番号ではなく、ローカルサービス番号を提供できる場合があります。仮想プライベートネットワーク（VPN）を使用すると、DHCPでさえ、ユーザーがホームネットワークまたはコーポレートネットワークの地元の支店に連絡する可能性があるため、不確実な起源の数を提供する場合があります。同様に、SIP Configuration [config-frame]は、SIPサービスプロバイダーの場所で有効な数字を提供することができますが、全国のフットプリントを持つSIPサービスプロバイダーでさえ、他の多くの国を訪問している顧客にサービスを提供する場合があります。
Also, while initially there are likely to be only a few service numbers, e.g., for emergency services, the LoST architecture can be used to support other services, as noted. Configuring every local DHCP or SIP configuration server with that information is likely to be error-prone and tedious.
また、当初は少数のサービス番号しか存在しない可能性がありますが、たとえば、緊急サービスの場合は、失われたアーキテクチャを使用して他のサービスをサポートできます。すべてのローカルDHCPまたはSIP構成サーバーをその情報で構成することは、エラーが発生し、退屈な可能性があります。
For these reasons, the LoST-based mapping architecture supports providing service numbers to end systems based on caller location. The mapping operation is almost exactly the same as for determining the service URL. The mapping can be obtained along with the service URL. The major difference between the two requests is that service numbers often have much larger regions of validity than the service URL itself. Also, the 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 home location, not just its current (visited) location.
これらの理由により、失われたベースのマッピングアーキテクチャは、発信者の場所に基づいてシステムを終了するためのサービス番号を提供することをサポートしています。マッピング操作は、サービスURLを決定するのとほぼ同じです。マッピングは、サービスURLとともに取得できます。2つの要求の主な違いは、サービス番号がサービスURL自体よりもはるかに大きな妥当性の領域を持っていることが多いことです。また、サービス番号は、サービスURLよりも長く有効になる可能性があります。最後に、エンドシステムは、現在の（訪問された）場所だけでなく、その家の場所のサービス番号を調べたい場合があります。
Security considerations for emergency services mapping are discussed in [RFC5069], while [RFC5031] discusses issues related to the service URN, one of the inputs into the mapping protocol. LoST-related security considerations are naturally discussed in the LoST specification [RFC5222].
緊急サービスマッピングに関するセキュリティ上の考慮事項は[RFC5069]で説明されていますが、[RFC5031]は、マッピングプロトコルへの入力の1つであるService URNに関連する問題について説明しています。失われたセキュリティの考慮事項は、失われた仕様[RFC5222]で自然に議論されています。
The architecture addresses the following security issues, usually through the underlying transport security associations:
アーキテクチャは、通常、基礎となる輸送セキュリティ協会を通じて、次のセキュリティ問題に対処します。
server impersonation: Seekers, resolvers, fellow tree guides, and cluster members can assure themselves of the identity of the remote party by using the facilities in the underlying channel security mechanism, such as Transport Layer Security (TLS) [RFC5246].
サーバーのなりすまし：シーカー、リソースバー、仲間のツリーガイド、およびクラスターメンバーは、輸送層のセキュリティ（TLS）[RFC5246]など、基礎となるチャネルセキュリティメカニズムの施設を使用することにより、リモートパーティの身元を確保できます。
query or query result corruption: To avoid the possibility of an attacker modifying the query or its result, the architecture RECOMMENDS the use of channel security, such as TLS. Results SHOULD also be digitally signed, e.g., using XML digital signatures [W3C.REC-xmldsig-core-20020212]. Note, however, that simple origin assertion may not provide the end system with enough useful information as it has no good way of knowing that a particular signer is authorized to represent a particular geographic area. It might be necessary that certain well-known Certificate Authorities (CAs) vet sources of mapping information and provide special certificates for that purpose. In many cases, a seeker will have to trust its local resolver to vet information for trustworthiness; in turn, the resolver may rely on trusted forest guides to steer it to the correct information.
クエリまたはクエリの結果の破損：攻撃者がクエリまたはその結果を変更する可能性を回避するために、アーキテクチャはTLSなどのチャネルセキュリティの使用を推奨します。XMLデジタル署名[W3C.REC-XMLDSIG-CORE-20020212]を使用して、結果もデジタル署名する必要があります。ただし、特定の署名者が特定の地理的領域を代表することを許可されていることを知る良い方法がないため、単純な起源のアサーションはエンドシステムに十分な有用な情報を提供しない場合があることに注意してください。特定の有名な証明書当局（CAS）獣医情報源のマッピング情報源が必要になる場合があり、その目的のために特別な証明書を提供することが必要かもしれません。多くの場合、シーカーは、信頼性のために情報を審査するために地元のリゾルバーを信頼する必要があります。次に、リゾルバーは信頼できる森林ガイドに依存して、それを正しい情報に導くことができます。
coverage region corruption: To avoid the possibility of a third party or an untrustworthy member of a server population claiming a coverage region that it is not authorized for, any node introducing a new service boundary MUST sign the object by protecting the data with an XML digital signature [W3C.REC-xmldsig-core-20020212]. A recipient MUST verify, through a local policy mechanism, that the signing entity is indeed authorized to speak for that region. Determining who can speak for a particular region is inherently difficult unless there is a small set of authorizing entities that participants in the mapping architecture can trust. Receiving systems should be particularly suspicious if an existing coverage region is replaced with a new one with a new mapping address. In many cases, trust will be mediated: a seeker will have a trust relationship with a resolver, and the resolver, in turn, will contact a trusted forest guide.
カバレッジ地域の破損：サードパーティまたはサーバー母集団の信頼できないメンバーの可能性を回避するには、承認されていないカバレッジ領域を主張するサーバー母集団の信頼できないメンバー、新しいサービス境界を導入するノードは、XMLデジタルでデータを保護してオブジェクトに署名する必要があります署名[W3C.REC-XMLDSIG-CORE-20020212]。受信者は、ローカルポリシーメカニズムを通じて、署名エンティティが実際にその地域について話すことを許可されていることを確認する必要があります。マッピングアーキテクチャの参加者が信頼できる小さな承認エンティティの小さなセットがない限り、特定の地域で誰が話すことができるかを決定することは、本質的に困難です。既存のカバレッジ領域が新しいマッピングアドレスを持つ新しい領域に置き換えられている場合、受信システムは特に疑わしいはずです。多くの場合、信頼は媒介されます。シーカーはリゾルバーと信頼関係を持ち、リゾルバーは信頼できる森林ガイドに連絡します。
Additional threats that need to be addressed by operational measures include denial-of-service attacks [PHONE-BCP].
運用措置によって対処する必要がある追加の脅威には、サービス拒否攻撃[電話BCP]が含まれます。
Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson, Schida Schubert, Murugaraj Shanmugam, Richard Stastny, Hannes Tschofenig, and Karl Heinz Wolf provided helpful comments.
Jari Arkko、Richard Barnes、Cullen Jennings、Jong Yul Kim、Otmar Lendl、Matt Lepinski、Chris Newman、Andrew Newton、Jon Peterson、Schida Schubert、Murugaraj Shanmugam、Richard Stastny、Hannes Tschofenig、Karl Heinz Wolfはin Hopfulコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031] Schulzrinne、H。、「緊急およびその他の有名なサービスのためのユニフォームリソース名（URN）」、RFC 5031、2008年1月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「Lost：A Location-s-Service Translation Protocol」、RFC 5222、2008年8月。
[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.
[RFC5223] Schulzrinne、H.、Polk、J。、およびH. Tschofenig、「ダイナミックホスト構成プロトコル（DHCP）を使用して、位置からサービスへの翻訳（Lost）サーバーの発見」、RFC 5223、2008年8月。
[CONFIG-FRAME] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, February 2008.
[Config-Frame] Channabasappa、S。、「セッション開始プロトコルユーザーエージェントプロファイル配信のフレームワーク」、2008年2月の作業。
[ECRIT-FRAME] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", Work in Progress, March 2009.
[Ecrit-frame] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「インターネットマルチメディアを使用した緊急通話のフレームワーク」、2009年3月、進行中。
[LOST-SYNC] Schulzrinne, H. and H. Tschofenig, "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Work in Progress, March 2009.
[Lost-Sync] Schulzrinne、H。およびH. Tschofenig、「位置からサービスへの翻訳（失われた）プロトコルベースのサービス境界とマッピング要素の同期」、2009年3月の進行中。
[PHONE-BCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, March 2009.
[Phone-BCP] Rosen、B。and J. Polk、「緊急通話を支援するコミュニケーションサービスの最良の現在の練習」、2009年3月、Work in Progress。
[RFC3528] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced Service Location Protocol (mSLP)", RFC 3528, April 2003.
[RFC3528] Zhao、W.、Schulzrinne、H.、およびE. Guttman、「Mesh-Enhanced Service Location Protocol（MSLP）」、RFC 3528、2003年4月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne、H。およびR. Marshall、「インターネット技術による緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069] Taylor、T.、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「緊急コールマーキングとマッピングのセキュリティの脅威と要件」、RFC 5069、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[W3C.REC-xmldsig-core-20020212] Solo, D., Eastlake, D., and J. Reagle, "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>.
[W3C.REC-XMLDSIG-CORE-20020212] SOLO、D.、EastLake、D.、およびJ. Reagle、「XML-Signature Syntax and Processing」、World Wide Web Consortium Firstedition Rec-Xmldsig-Core-20020212、2002年2月、<http://www.w3.org/tr/2002/rec-xmldsig-core-20020212>。
Author's Address
著者の連絡先
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu