[要約] RFC 7890は、P2PSIP（ピアツーピアSIP）の概念と用語に関する情報を提供するものです。その目的は、P2PSIPの基本的な概念と用語を明確に定義し、P2PSIPの実装や研究における共通の理解を促進することです。
Internet Engineering Task Force (IETF) D. Bryan
Request for Comments: 7890 Cogent Force, LLC
Category: Informational P. Matthews
ISSN: 2070-1721 Nokia
E. Shim
Samsung Electronics Co., Ltd.
D. Willis
Softarmor Systems
S. Dawkins
Huawei (USA)
June 2016
Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)
ピアツーピアSIP（P2PSIP）の概念と用語
Abstract
概要
This document defines concepts and terminology for using the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and the SIP usage document defined by the working group.
このドキュメントでは、従来のプロキシレジストラ機能とメッセージルーティング機能が分散メカニズムに置き換えられたピアツーピア環境でセッション開始プロトコルを使用するための概念と用語を定義します。これらのメカニズムは、分散ハッシュテーブルまたは同様の外部プロパティを持つ他の分散データメカニズムを使用して実装できます。このドキュメントには、ここで定義されたネットワーク要素間の機能的な関係の概要、運用の概念モデル、P2PSIPワーキンググループ、リソースの再配置と検出（RELOAD）プロトコルによって対処される関連問題の概要、およびワーキンググループによって定義されたSIP使用法ドキュメント。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7890.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7890で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. High-Level Description . . . . . . . . . . . . . . . . . . . 4
2.1. Services . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Relationship between P2PSIP and RELOAD . . . . . . . . . 5
2.4. Relationship between P2PSIP and SIP . . . . . . . . . . . 5
2.5. Relationship between P2PSIP and Other AoR-Dereferencing
Approaches . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . 6
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 6
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. The Distributed Database Function . . . . . . . . . . . . 12
5.2. Using the Distributed Database Function . . . . . . . . . 13
5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 14
5.5. Clients and Connecting Unmodified SIP Devices . . . . . . 15
5.6. Architecture . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
One of the fundamental problems in multimedia communication between Internet nodes is the rendezvous problem, or discovering the host at which a given user can be reached. In the Session Initiation Protocol (SIP) [RFC3261], this problem is expressed as the problem of mapping an Address of Record (AoR) for a user into one or more Contact URIs [RFC3986]. The AoR is a name for the user that is independent of the host or hosts where the user can be contacted, while a Contact URI indicates the host where the user can be contacted.
インターネットノード間のマルチメディア通信における基本的な問題の1つは、ランデブー問題、または特定のユーザーに到達できるホストの発見です。セッション開始プロトコル（SIP）[RFC3261]では、この問題は、ユーザーのレコードのアドレス（AoR）を1つ以上の連絡先URI [RFC3986]にマッピングする問題として表されます。 AoRは、ユーザーに連絡できるホストに依存しないユーザーの名前です。一方、Contact URIは、ユーザーに連絡できるホストを示します。
In the common SIP-using architectures that we refer to as "Conventional SIP" or "Client/Server SIP", there is a relatively fixed hierarchy of SIP routing proxies and SIP user agents. To deliver a SIP INVITE to the host or hosts at which the user can be contacted, a SIP UA follows the procedures specified in [RFC3263] to determine the IP address of a SIP proxy, and then sends the INVITE to that proxy. The proxy will then, in turn, deliver the SIP INVITE to the hosts where the user can be contacted.
「従来のSIP」または「クライアント/サーバーSIP」と呼ばれる一般的なSIP使用アーキテクチャでは、SIPルーティングプロキシとSIPユーザーエージェントの階層が比較的固定されています。ユーザーに連絡できるホストにSIP INVITEを配信するために、SIP UAは[RFC3263]で指定された手順に従ってSIPプロキシのIPアドレスを決定し、INVITEをそのプロキシに送信します。次に、プロキシは、SIP INVITEをユーザーに連絡できるホストに配信します。
This document gives a high-level description of an alternative solution to this problem. In this alternative solution, the relatively fixed hierarchy of Client/Server SIP is replaced by a peer-to-peer overlay network. In this peer-to-peer overlay network, the various mappings of AoRs to Contact URIs are not centralized at proxy/registrar nodes but are instead distributed amongst the peers in the overlay.
このドキュメントでは、この問題の代替ソリューションの概要を説明します。この代替ソリューションでは、クライアント/サーバーSIPの比較的固定された階層が、ピアツーピアオーバーレイネットワークに置き換えられています。このピアツーピアオーバーレイネットワークでは、AoRから連絡先URIへのさまざまなマッピングがプロキシ/レジストラノードで集中管理されず、オーバーレイ内のピア間で分散されます。
The details of this alternative solution are specified by the RELOAD protocol [RFC6940], which defines a mechanism for distribution using a Distributed Hash Table (DHT) and specifies the wire protocol, security, and authentication mechanisms needed to convey this information. This DHT protocol was designed specifically with the purpose of enabling a distributed SIP registrar in mind. While designing the protocol, other applications were considered, and then design decisions were made that allow RELOAD to be used in other instances where a DHT is desirable, but only when such decisions did not add undue complexity to the RELOAD protocol. The RELOAD SIP document [P2PSIP] specifies how RELOAD is used with the SIP protocol to enable a distributed, server-less SIP solution.
この代替ソリューションの詳細は、RELOADプロトコル[RFC6940]で指定されています。これは、分散ハッシュテーブル（DHT）を使用した配信メカニズムを定義し、この情報を伝達するために必要なワイヤプロトコル、セキュリティ、および認証メカニズムを指定します。このDHTプロトコルは、分散型SIPレジストラを有効にすることを目的として特別に設計されました。プロトコルの設計中に他のアプリケーションが検討され、DHTが望ましい他のインスタンスでRELOADを使用できるようにする設計上の決定が行われましたが、そのような決定によってRELOADプロトコルが過度に複雑にならない場合に限られます。 RELOAD SIPドキュメント[P2PSIP]は、SIPプロトコルでRELOADを使用して、分散型のサーバーレスSIPソリューションを実現する方法を指定しています。
A Peer-to-Peer SIP (P2PSIP) Overlay is a collection of nodes organized in a peer-to-peer fashion for the purpose of enabling real-time communication using the Session Initiation Protocol (SIP). Collectively, the nodes in the Overlay provide a distributed mechanism for mapping names to Overlay locations. This provides for the mapping of Addresses of Record (AoRs) to Contact URIs, thereby providing the "location server" function of [RFC3261]. An Overlay also provides a transport function by which SIP messages can be transported between any two nodes in the Overlay.
ピアツーピアSIP（P2PSIP）オーバーレイは、セッション開始プロトコル（SIP）を使用したリアルタイム通信を可能にするために、ピアツーピア方式で編成されたノードのコレクションです。まとめると、オーバーレイのノードは、名前をオーバーレイの場所にマッピングする分散メカニズムを提供します。これにより、Addresses of Record（AoR）からContact URIへのマッピングが提供され、[RFC3261]の「ロケーションサーバー」機能が提供されます。オーバーレイは、SIPメッセージをオーバーレイ内の任意の2つのノード間で転送できる転送機能も提供します。
A P2PSIP Overlay consists of one or more nodes called "Peers". The nodes in the Overlay collectively run a distributed database algorithm. This distributed database algorithm allows data to be stored on nodes and retrieved in an efficient manner. It may also ensure that a copy of a data item is stored on more than one node, so that the loss of a node does not result in the loss of the data item to the Overlay.
P2PSIPオーバーレイは、「ピア」と呼ばれる1つ以上のノードで構成されます。オーバーレイのノードは、分散データベースアルゴリズムを集合的に実行します。この分散データベースアルゴリズムにより、データをノードに格納し、効率的な方法で取得できます。また、データ項目のコピーが複数のノードに確実に格納されるため、ノードが失われてもオーバーレイのデータ項目が失われることはありません。
One use of this distributed database is to store the information required to provide the mapping between AoRs and Contact URIs for the distributed location function. This provides a location function within each Overlay that is an alternative to the location functions described in [RFC3263]. However, the model of [RFC3263] is used between Overlays.
この分散データベースの用途の1つは、分散ロケーション機能のAoRと連絡先URI間のマッピングを提供するために必要な情報を格納することです。これは、[RFC3263]で説明されているロケーション関数の代替となる、各オーバーレイ内のロケーション関数を提供します。ただし、[RFC3263]のモデルはオーバーレイ間で使用されます。
The nature of peer-to-peer computing is that each peer offers services to other peers to allow the overlay to collectively provide larger functions. In P2PSIP, Peers offer both distributed storage and distributed message-routing services, allowing these functions to be implemented across the Overlay. Additionally, the RELOAD protocol offers a simplistic discovery mechanism specific to the Traversal Using Relays around NAT (TURN) [RFC5766] protocol used for NAT traversal. Individual Peers may also offer other services as an enhancement to P2PSIP functionality (for example, to support voicemail) or to support other applications beyond SIP. To support these additional services, Peers may need to store additional information in the Overlay. [RFC7374] describes the mechanism used in P2PSIP for resource discovery.
ピアツーピアコンピューティングの性質は、各ピアが他のピアにサービスを提供して、オーバーレイがより大きな機能をまとめて提供できるようにすることです。 P2PSIPでは、ピアは分散ストレージと分散メッセージルーティングサービスの両方を提供し、これらの機能をオーバーレイ全体に実装できます。さらに、RELOADプロトコルは、NATトラバーサルに使用されるNAT（TURN）[RFC5766]プロトコルを使用したトラバーサル固有の単純化された検出メカニズムを提供します。個々のピアは、P2PSIP機能の拡張（ボイスメールをサポートするためなど）として、またはSIP以外の他のアプリケーションをサポートするために、他のサービスを提供することもできます。これらの追加サービスをサポートするために、ピアはオーバーレイに追加情報を保存する必要がある場合があります。 [RFC7374]は、リソース検出のためにP2PSIPで使用されるメカニズムについて説明しています。
An Overlay may or may not also include one or more nodes called "Clients". Clients are supported in the RELOAD protocol as peers that have not joined the Overlay, and therefore do not route messages or store information. Clients access the services of the RELOAD protocol by connecting to a Peer that performs operations on the behalf of the Client. Note that in RELOAD, there is no distinct client protocol. Instead, a Client connects using the same protocol, but never joins the Overlay as a Peer. For more information, see [RFC6940].
オーバーレイには、「クライアント」と呼ばれる1つ以上のノードが含まれる場合と含まれない場合があります。クライアントは、RELOADプロトコルで、オーバーレイに参加していないピアとしてサポートされているため、メッセージのルーティングや情報の保存を行いません。クライアントは、クライアントに代わって操作を実行するピアに接続することにより、RELOADプロトコルのサービスにアクセスします。 RELOADには、明確なクライアントプロトコルがないことに注意してください。代わりに、クライアントは同じプロトコルを使用して接続しますが、ピアとしてオーバーレイに参加することはありません。詳細については、[RFC6940]を参照してください。
A special Peer may also be a member of the P2PSIP Overlay and may present the functionality of one or all of a SIP registrar, proxy, or redirect server to conventional SIP devices (i.e., unmodified SIP user agent (UA) or client). In this way, existing, unmodified SIP clients may connect to the P2PSIP network. Note that in the context of P2PSIP, the unmodified SIP client is also sometimes referred to as a "client". These unmodified SIP devices do not speak the RELOAD protocol, and this is a distinct concept from the notion of "Client" discussed in the previous paragraph.
特別なピアもP2PSIPオーバーレイのメンバーである場合があり、SIPレジストラー、プロキシ、またはリダイレクトサーバーの1つまたはすべての機能を従来のSIPデバイス（つまり、変更されていないSIPユーザーエージェント（UA）またはクライアント）に提示する場合があります。このようにして、既存の変更されていないSIPクライアントがP2PSIPネットワークに接続できます。 P2PSIPのコンテキストでは、変更されていないSIPクライアントは「クライアント」と呼ばれることもあります。これらの変更されていないSIPデバイスはRELOADプロトコルを話しません。これは、前の段落で説明した「クライアント」の概念とは異なる概念です。
The RELOAD protocol defined by the P2PSIP working group implements a DHT primarily for use by server-less, peer-to-peer SIP deployments. However, the RELOAD protocol could be used for other applications as well. As such, a "P2PSIP" deployment is generally assumed to be a use of RELOAD to implement distributed SIP, but it is possible that RELOAD is used as a mechanism to distribute other applications, completely unrelated to SIP.
P2PSIPワーキンググループによって定義されたRELOADプロトコルは、主にサーバーレスのピアツーピアSIP展開で使用するためのDHTを実装します。ただし、RELOADプロトコルは他のアプリケーションにも使用できます。そのため、「P2PSIP」展開は一般にRELOADを使用して分散SIPを実装すると想定されていますが、SIPとはまったく関係のない他のアプリケーションを分散するメカニズムとしてRELOADが使用される可能性があります。
Since P2PSIP is about peer-to-peer networks for real-time communication, it is expected that most Peers and Clients will be coupled with SIP entities (although RELOAD may be used for other applications than P2PSIP). For example, one Peer might be coupled with a SIP UA, another might be coupled with a SIP proxy, while a third might be coupled with a SIP-to-PSTN gateway. For such nodes, the Peer or Client portion of the node is logically distinct from the SIP entity portion. However, there is no hard requirement that every P2PSIP node (Peer or Client) be coupled to a SIP entity. As an example, additional Peers could be placed in the Overlay to provide additional storage or redundancy for the RELOAD Overlay, but might not have any direct SIP capabilities.
P2PSIPはリアルタイム通信用のピアツーピアネットワークに関するものであるため、ほとんどのピアおよびクライアントはSIPエンティティと結合されることが予想されます（ただし、P2PSIP以外のアプリケーションにはRELOADを使用できます）。たとえば、1つのピアがSIP UAに結合され、別のピアがSIPプロキシに結合され、3番目のピアがSIP-to-PSTNゲートウェイに結合される場合があります。このようなノードの場合、ノードのピアまたはクライアント部分は、SIPエンティティ部分とは論理的に異なります。ただし、すべてのP2PSIPノード（ピアまたはクライアント）がSIPエンティティに結合されているという厳密な要件はありません。例として、追加のピアをオーバーレイに配置して、RELOADオーバーレイに追加のストレージまたは冗長性を提供できますが、直接のSIP機能がない場合があります。
As noted above, the fundamental task of P2PSIP is to turn an AoR into a Contact. This task might be approached using zero configuration techniques such as multicast DNS (mDNS) and DNS Service Discovery (DNS-SD) [RFC6762] [RFC6763], Link-Local Multicast Name Resolution [RFC4795], and dynamic DNS [RFC2136].
上記のように、P2PSIPの基本的なタスクは、AoRを連絡先に変えることです。このタスクは、マルチキャストDNS（mDNS）やDNSサービス検出（DNS-SD）[RFC6762] [RFC6763]、リンクローカルマルチキャスト名前解決[RFC4795]、動的DNS [RFC2136]などのゼロ構成手法を使用してアプローチできます。
These alternatives were discussed in the P2PSIP working group, and not pursued as a general solution for a number of reasons related to scalability, the ability to work in a disconnected state, partition recovery, and so on. However, there does seem to be some continuing interest in the possibility of using mDNS and DNS-SD for the bootstrapping of P2PSIP overlays.
これらの代替案はP2PSIPワーキンググループで議論され、スケーラビリティ、切断状態で動作する機能、パーティションの回復などに関連するいくつかの理由により、一般的なソリューションとしては追求されませんでした。ただし、P2PSIPオーバーレイのブートストラップにmDNSとDNS-SDを使用する可能性には、引き続き関心があるようです。
Network Address Translators (NATs) are impediments to establishing and maintaining peer-to-peer networks, since NATs hinder direct communication between nodes. Some peer-to-peer network architectures avoid this problem by insisting that all nodes exist in the same address space. However, RELOAD provides capabilities that allow nodes to be located in multiple address spaces interconnected by NATs, to allow RELOAD messages to traverse NATs, and to assist in transmitting application-level messages (for example, SIP messages) across NATs.
NATはノード間の直接通信を妨げるため、ネットワークアドレストランスレータ（NAT）はピアツーピアネットワークの確立と維持の障害となります。一部のピアツーピアネットワークアーキテクチャでは、すべてのノードが同じアドレス空間に存在するように主張することで、この問題を回避しています。ただし、RELOADは、NATによって相互接続された複数のアドレススペースにノードを配置できるようにする機能を提供し、RELOADメッセージがNATを通過できるようにし、NATを介してアプリケーションレベルのメッセージ（SIPメッセージなど）の送信を支援します。
The following diagram shows a P2PSIP Overlay consisting of a number of Peers, one Client, and an ordinary SIP UA. It illustrates a typical P2PSIP Overlay but does not limit other compositions or variations; for example, Proxy Peer P might also talk to an ordinary SIP proxy as well. The figure is not intended to cover all possible architecture variations, but simply to show a deployment with many common P2PSIP elements.
次の図は、複数のピア、1つのクライアント、および通常のSIP UAで構成されるP2PSIPオーバーレイを示しています。これは典型的なP2PSIPオーバーレイを示していますが、他の構成やバリエーションを制限するものではありません。たとえば、Proxy Peer Pは通常のSIPプロキシとも通信します。この図は、考えられるすべてのアーキテクチャのバリエーションを網羅することを意図したものではなく、単に多くの一般的なP2PSIP要素を使用した展開を示しています。
--->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # RELOAD
| E | A | F | +---------+ # P2PSIP
| | T | | # Protocol
+------+ N +------+ # |
# A # |
NATNATNATNAT # |
# # | \__/
NATNATNATNAT +-------+ v / \
# N | |#####/ UA \
+------+ A P2PSIP Overlay | Peer | /Client\
| | T | Q | |___C__|
| UA | N | |
| Peer | A +-------+
| D | T #
| | N #
+------+ A # RELOAD
# T # P2PSIP
# N +-------+ +-------+ # Protocol
# A | | | | #
#########T####| Proxy |########| Redir |#######
N | Peer | | Peer |
A | P | | R |
T +-------+ +-------+
| /
| SIP /
\__/ / /
/\ / ______________/ SIP
/ \/ /
/ UA \/
/______\
SIP UA A
Figure 1: P2PSIP Overlay Reference Model
図1：P2PSIPオーバーレイ参照モデル
Here, the large perimeter depicted by "#" represents a stylized view of the Overlay (the actual connections could be a mesh, a ring, or some other structure). Around the periphery of the Overlay rectangle, we have a number of Peers. Each Peer is labeled with its coupled SIP entity -- for example, "Proxy Peer P" means that Peer P is coupled with a SIP proxy. In some cases, a Peer or Client might be coupled with two or more SIP entities. In this diagram, we have a Public Switched Telephone Network (PSTN) gateway coupled with Peer "G", three Peers ("D", "E", and "F") that are each coupled with a UA, a Peer "P" that is coupled with a SIP proxy, an ordinary Peer "Q" with no SIP capabilities, and one Peer "R" that is coupled with a SIP redirector. Note that because these are all Peers, each is responsible for storing Resource Records and transporting messages around the Overlay.
ここで、「＃」で示される大きな周囲は、オーバーレイの様式化されたビューを表します（実際の接続は、メッシュ、リング、またはその他の構造である可能性があります）。オーバーレイ長方形の周囲には、いくつかのピアがあります。各ピアは、結合されたSIPエンティティでラベル付けされます。たとえば、「プロキシピアP」は、ピアPがSIPプロキシに結合されていることを意味します。場合によっては、ピアまたはクライアントが2つ以上のSIPエンティティと結合されることがあります。この図では、ピア "G"、3つのピア（ "D"、 "E"、および "F"）に結合された公衆交換電話網（PSTN）ゲートウェイがあり、それぞれUA、ピア "P"に結合されています。 "これは、SIPプロキシ、SIP機能のない通常のピア" Q "、およびSIPリダイレクタと結合された1つのピア" R "と結合されています。これらはすべてピアであるため、それぞれがリソースレコードを保存し、メッセージをオーバーレイ内で転送することに注意してください。
To the left, two of the Peers ("D" and "E") are behind network address translators (NATs). These Peers are included in the P2PSIP Overlay, and thus participate in storing resource records and routing messages, despite being behind the NATs.
左側では、2つのピア（「D」と「E」）がネットワークアドレス変換（NAT）の背後にあります。これらのピアはP2PSIPオーバーレイに含まれているため、NATの背後にあるにもかかわらず、リソースレコードとルーティングメッセージの格納に参加します。
On the right side, we have a Client "C", which uses the RELOAD Protocol to communicate with Proxy Peer "Q". The Client "C" uses RELOAD to obtain information from the Overlay, but has not inserted itself into the Overlay, and therefore does not participate in routing messages or storing information.
右側には、クライアント "C"があり、RELOADプロトコルを使用してプロキシピア "Q"と通信します。クライアント "C"はRELOADを使用してオーバーレイから情報を取得しますが、それ自体をオーバーレイに挿入していないため、メッセージのルーティングや情報の格納には関与しません。
Below the Overlay, we have a conventional SIP UA "A" that is not part of the Overlay, either directly as a Peer or indirectly as a Client. It does not speak the RELOAD P2PSIP protocol and is not participating in the Overlay as a Peer or a Client. Instead, it uses SIP to interact with the Overlay via an adapter Peer or Peers that communicate with the Overlay using RELOAD.
オーバーレイの下に、直接またはピアとして間接的に、オーバーレイの一部ではない従来のSIP UA "A"があります。 RELOAD P2PSIPプロトコルを使用せず、ピアまたはクライアントとしてオーバーレイに参加していません。代わりに、SIPを使用して、RELOADを使用してオーバーレイと通信する1つまたは複数のアダプターピアを介してオーバーレイと対話します。
Both the SIP proxy coupled with Peer "P" and the SIP redirector coupled with Peer "R" can serve as adapters between ordinary SIP devices and the Overlay. Each accepts standard SIP requests and resolves the next hop by using the P2PSIP protocol to interact with the routing knowledge of the Overlay, and then processes the SIP requests as appropriate (proxying or redirecting towards the next hop). Note that proxy operation is bidirectional -- the proxy may be forwarding a request from an ordinary SIP device to the Overlay, or from the P2PSIP Overlay to an ordinary SIP device.
ピア「P」と結合されたSIPプロキシとピア「R」と結合されたSIPリダイレクタは、通常のSIPデバイスとオーバーレイの間のアダプタとして機能できます。それぞれが標準のSIP要求を受け入れ、P2PSIPプロトコルを使用してオーバーレイのルーティング情報と対話することによりネクストホップを解決し、SIP要求を適切に処理します（ネクストホップへのプロキシまたはリダイレクト）。プロキシ操作は双方向であることに注意してください。プロキシは、通常のSIPデバイスからオーバーレイに、またはP2PSIPオーバーレイから通常のSIPデバイスに要求を転送している可能性があります。
The PSTN Gateway at Peer "G" provides a similar sort of adaptation to and from the PSTN.
ピア「G」のPSTNゲートウェイは、PSTNとの間で同様の適応を提供します。
This section defines a number of concepts that are key to understanding the P2PSIP work.
このセクションでは、P2PSIPの動作を理解するための鍵となるいくつかの概念を定義します。
Overlay Network: An overlay network is a computer network that is built on top of another network. Nodes in the overlay can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network. For example, many peer-to-peer networks are overlay networks because they run on top of the Internet. Dial-up Internet is an overlay upon the telephone network.
オーバーレイネットワーク：オーバーレイネットワークは、別のネットワークの上に構築されたコンピューターネットワークです。オーバーレイのノードは、仮想リンクまたは論理リンクによって接続されていると考えることができます。各リンクは、基盤となるネットワーク内の、おそらく多くの物理リンクを経由するパスに対応しています。たとえば、多くのピアツーピアネットワークはインターネット上で実行されるため、オーバーレイネットワークです。ダイヤルアップインターネットは、電話ネットワークのオーバーレイです。
P2P Network: A peer-to-peer (or P2P) computer network is a network that relies primarily on the computing power and bandwidth of the participants in the network rather than concentrating it in a relatively low number of servers. P2P networks are typically used for connecting nodes via largely ad hoc connections. Such networks are useful for many purposes. Sharing content files containing audio, video, data, or anything in digital format is very common, and real-time data, such as telephony traffic, is also exchanged using P2P technology. A P2P Network may also be called a "P2P Overlay", a "P2P Overlay Network", or a "P2P Network Overlay", since its organization is not at the physical layer, but is instead "on top of" an existing Internet Protocol network.
P2Pネットワーク：ピアツーピア（またはP2P）コンピューターネットワークは、比較的少数のサーバーに集中するのではなく、主にネットワークの参加者のコンピューティング能力と帯域幅に依存するネットワークです。 P2Pネットワークは通常、主にアドホック接続を介してノードを接続するために使用されます。このようなネットワークは、多くの目的に役立ちます。オーディオ、ビデオ、データ、またはデジタル形式の何かを含むコンテンツファイルを共有することは非常に一般的であり、テレフォニートラフィックなどのリアルタイムデータもP2Pテクノロジを使用して交換されます。 P2Pネットワークは「P2Pオーバーレイ」、「P2Pオーバーレイネットワーク」、または「P2Pネットワークオーバーレイ」とも呼ばれます。これは、その組織が物理層ではなく、既存のインターネットプロトコルの「上」にあるためです。通信網。
P2PSIP: A suite of communications protocols related to the Session Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer-to-peer techniques for resolving the targets of SIP requests, providing SIP message transport, and providing other SIP-related functions. At present, these protocols include [RFC6940], [RFC7363], [RFC7374], [RFC7851] and [P2PSIP].
P2PSIP：SIPがピアツーピア技術を使用してSIPリクエストのターゲットを解決し、SIPメッセージトランスポートを提供し、その他のSIP関連機能を提供できるようにする、セッション開始プロトコル（SIP）[RFC3261]に関連する一連の通信プロトコル。現在、これらのプロトコルには、[RFC6940]、[RFC7363]、[RFC7374]、[RFC7851]、および[P2PSIP]が含まれます。
User: A human that interacts with the Overlay through SIP UAs located on Peers and Clients (and perhaps in other ways).
ユーザー：ピアとクライアントにあるSIP UAを介して（おそらく他の方法で）オーバーレイと対話する人間。
The following terms are defined here only within the scope of P2PSIP. These terms may have conflicting definitions in other bodies of literature. Some draft versions of this document prefixed each term with "P2PSIP" to clarify the term's scope. This prefixing has been eliminated from the text; however, the scoping still applies.
以下の用語は、ここではP2PSIPの範囲内でのみ定義されています。これらの用語は、他の文献で矛盾する定義を持っている可能性があります。このドキュメントのいくつかのドラフトバージョンでは、用語の範囲を明確にするために、各用語の前に「P2PSIP」を付けています。この接頭辞はテキストから削除されました。ただし、スコープは引き続き適用されます。
Overlay Name: A human-friendly name that identifies a specific P2PSIP Overlay. This is in the format of (a portion of) a URI, but may or may not have a related record in the DNS.
オーバーレイ名：特定のP2PSIPオーバーレイを識別するわかりやすい名前。これはURI（の一部）の形式ですが、DNSに関連レコードがある場合とない場合があります。
Peer: A node participating in a P2PSIP Overlay that provides storage and transport services to other nodes in that P2PSIP Overlay. Each Peer has a unique identifier, known as a Peer-ID, within the Overlay. Each Peer may be coupled to one or more SIP entities. Within the Overlay, the Peer is capable of performing several different operations, including: joining and leaving the Overlay, transporting SIP messages within the Overlay, storing information on behalf of the Overlay, putting information into the Overlay, and getting information from the Overlay.
ピア：P2PSIPオーバーレイ内の他のノードにストレージおよびトランスポートサービスを提供するP2PSIPオーバーレイに参加しているノード。各ピアには、オーバーレイ内にピアIDと呼ばれる一意の識別子があります。各ピアは、1つ以上のSIPエンティティに結合できます。ピアは、オーバーレイ内で、オーバーレイへの参加と離脱、オーバーレイ内でのSIPメッセージの転送、オーバーレイに代わって情報を保存する、オーバーレイに情報を入力する、オーバーレイから情報を取得するなど、いくつかの異なる操作を実行できます。
Node-ID: Information that uniquely identifies each Node within a given Overlay. This value is not human-friendly -- in a DHT approach, this is a numeric value in the hash space. These Node-IDs are completely independent of the identifier of any user of a user agent associated with a Peer.
ノードID：特定のオーバーレイ内の各ノードを一意に識別する情報。この値は人間に優しいものではありません。DHTアプローチでは、これはハッシュ空間の数値です。これらのノードIDは、ピアに関連付けられたユーザーエージェントのユーザーの識別子から完全に独立しています。
Client: A node that participates in a P2PSIP Overlay but does not store information or forward messages. A Client can also be thought of as a peer that has not joined the Overlay. Clients can store and retrieve information from the Overlay.
クライアント：P2PSIPオーバーレイに参加するが、情報の保存やメッセージの転送を行わないノード。クライアントは、オーバーレイに参加していないピアと考えることもできます。クライアントはオーバーレイから情報を保存および取得できます。
User Name: A human-friendly name for a user. This name must be unique within the Overlay, but may be unique in a wider scope. User Names are formatted so that they can be used within a URI (likely a SIP URI), perhaps in combination with the Overlay Name.
ユーザー名：ユーザーにとってわかりやすい名前。この名前はオーバーレイ内で一意である必要がありますが、より広い範囲で一意にすることもできます。ユーザー名は、おそらくオーバーレイ名と組み合わせて、URI（SIP URIなど）内で使用できるようにフォーマットされています。
Service: A capability contributed by a Peer to an Overlay or to the members of an Overlay. Not all Peers and Clients will offer the same set of services, and P2PSIP provides service discovery mechanisms to locate services.
サービス：ピアがオーバーレイまたはオーバーレイのメンバーに提供する機能。すべてのピアとクライアントが同じサービスのセットを提供するわけではなく、P2PSIPはサービスを見つけるためのサービス検出メカニズムを提供します。
Service Name: A unique, human-friendly name for a service.
サービス名：サービスに固有の、人にわかりやすい名前。
Resource: Anything about which information can be stored in the Overlay. Both Users and Services are examples of Resources.
リソース：オーバーレイに保存できる情報。ユーザーとサービスの両方がリソースの例です。
Resource-ID: A non-human-friendly value that uniquely identifies a resource and that is used as a key for storing and retrieving data about the resource. One way to generate a Resource-ID is by applying a mapping function to some other unique name (e.g., User Name or Service Name) for the resource. The Resource-ID is used by the distributed database algorithm to determine the Peer or Peers that are responsible for storing data for the Overlay.
Resource-ID：リソースを一意に識別し、リソースに関するデータを格納および取得するためのキーとして使用される、人にやさしい値。 Resource-IDを生成する1つの方法は、リソースのその他の一意の名前（ユーザー名やサービス名など）にマッピング関数を適用することです。 Resource-IDは、分散データベースアルゴリズムによって使用され、オーバーレイのデータの格納を担当するピアを決定します。
Resource Record: A block of data, stored using the distributed database mechanism of the Overlay, that includes information relevant to a specific resource. We presume that there may be multiple types of resource records. Some may hold data about Users, and others may hold data about Services, and the working group may define other types. The types, usages, and formats of the records are a question for future study.
リソースレコード：オーバーレイの分散データベースメカニズムを使用して保存されたデータのブロック。特定のリソースに関連する情報が含まれます。複数のタイプのリソースレコードが存在する可能性があると想定しています。ユーザーに関するデータを保持するものもあれば、サービスに関するデータを保持するものもあり、ワーキンググループは他のタイプを定義することもあります。レコードのタイプ、使用法、および形式は、今後の検討課題です。
Responsible Peer The Peer that is responsible for storing the Resource Record for a Resource. In the literature, the term "Root Peer" is also used for this concept.
Responsible Peerリソースのリソースレコードの保存を担当するピア。文献では、「ルートピア」という用語もこの概念に使用されています。
Peer Protocol: The protocol spoken between P2PSIP Overlay Peers to share information and organize the P2PSIP Overlay Network. In P2PSIP, this is implemented using the RELOAD protocol [RFC6940].
ピアプロトコル：情報を共有し、P2PSIPオーバーレイネットワークを編成するためにP2PSIPオーバーレイピア間で話されるプロトコル。 P2PSIPでは、これはRELOADプロトコル[RFC6940]を使用して実装されます。
Client Protocol: The protocol spoken between Clients and Peers. In P2PSIP and RELOAD, this is syntactically the same protocol as the Peer Protocol. The only difference is that Clients are not routing messages or routing information, and have not (or cannot) insert themselves into the Overlay.
クライアントプロトコル：クライアントとピアの間で話されるプロトコル。 P2PSIPおよびRELOADでは、これは構文的にはピアプロトコルと同じプロトコルです。唯一の違いは、クライアントはメッセージやルーティング情報をルーティングしておらず、オーバーレイに自分自身を挿入していない（または挿入できない）ことです。
Peer Protocol Connection / P2PSIP Client Protocol Connection: The Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), TCP, UDP, or other transport-layer protocol connection over which the RELOAD Peer Protocol messages are transported.
ピアプロトコル接続/ P2PSIPクライアントプロトコル接続：トランスポート層セキュリティ（TLS）、データグラムトランスポート層セキュリティ（DTLS）、TCP、UDP、またはRELOADピアプロトコルメッセージがトランスポートされる他のトランスポート層プロトコル接続。
Neighbors: The set of P2PSIP Peers that a Peer or Client know of directly and can reach without further lookups.
ネイバー：ピアまたはクライアントが直接知っているP2PSIPピアのセットで、これ以上ルックアップすることなく到達できます。
Joining Peer: A node that is attempting to become a Peer in a particular Overlay.
ピアに参加：特定のオーバーレイでピアになろうとしているノード。
Bootstrap Peer: A Peer in the Overlay that is the first point of contact for a Joining Peer. It selects the Peer that will serve as the Admitting Peer and helps the Joining Peer contact the Admitting Peer.
ブートストラップピア：参加ピアの最初の連絡先となるオーバーレイ内のピア。承認ピアとして機能するピアを選択し、参加ピアが承認ピアに連絡できるようにします。
Admitting Peer: A Peer in the Overlay that helps the Joining Peer join the Overlay. The choice of the Admitting Peer may depend on the Joining Peer (e.g., depend on the Joining Peer's Peer-ID). For example, the Admitting Peer might be chosen as the Peer which is "closest" in the logical structure of the Overlay to the future position of the Joining Peer. The selection of the Admitting Peer is typically done by the Bootstrap Peer. It is allowable for the Bootstrap Peer to select itself as the Admitting Peer.
Admitting Peer：Joining PeerがOverlayに参加するのに役立つ、オーバーレイ内のピア。許可ピアの選択は、参加ピアに依存する可能性があります（たとえば、参加ピアのピアIDに依存）。たとえば、許可ピアは、参加ピアの将来の位置へのオーバーレイの論理構造で「最も近い」ピアとして選択される場合があります。 Admitting Peerの選択は、通常、Bootstrap Peerによって行われます。ブートストラップピアは、それ自体を許可ピアとして選択することができます。
Bootstrap Server: A network node used by Joining Peers to locate a Bootstrap Peer. A Bootstrap Server may act as a proxy for messages between the Joining Peer and the Bootstrap Peer. The Bootstrap Server itself is typically a stable host with a DNS name that is somehow communicated (for example, through configuration, specification on a web page, or using DHCP) to Peers that want to join the Overlay. A Bootstrap Server is NOT required to be a Peer or Client, though it may be if desired.
ブートストラップサーバー：参加ピアがブートストラップピアを見つけるために使用するネットワークノード。 Bootstrap Serverは、Joining PeerとBootstrap Peer間のメッセージのプロキシとして機能します。ブートストラップサーバー自体は、通常、DNS名を持つ安定したホストであり、オーバーレイに参加するピアに何らかの方法で（たとえば、構成、Webページでの指定、またはDHCPを使用して）通信されます。必要に応じて、ブートストラップサーバーをピアまたはクライアントにする必要はありません。
Peer Admission: The act of admitting a node (the "Joining Peer") into an Overlay as a Peer. After the admission process is over, the Joining Peer is a fully functional Peer of the Overlay. During the admission process, the Joining Peer may need to present credentials to prove that it has sufficient authority to join the Overlay.
ピアアドミッション：ノード（「Joining Peer」）をピアとしてオーバーレイに許可する行為。アドミッションプロセスが終了すると、Joining Peerは完全に機能するオーバーレイのピアになります。承認プロセス中に、Joining Peerは、オーバーレイに参加するための十分な権限があることを証明するために、資格情報を提示する必要がある場合があります。
Resource Record Insertion: The act of inserting a P2PSIP Resource Record into the distributed database. Following insertion, the data will be stored at one or more Peers. The data can be retrieved or updated using the Resource-ID as a key.
リソースレコードの挿入：P2PSIPリソースレコードを分散データベースに挿入する行為。挿入後、データは1つ以上のピアに保存されます。 Resource-IDをキーとして使用して、データを取得または更新できます。
A P2PSIP Overlay functions as a distributed database. The database serves as a way to store information about Resources. A piece of information, called a "Resource Record", can be stored by and retrieved from the database using a key associated with the Resource Record called its "Resource-ID". Each Resource must have a unique Resource-ID. In addition to uniquely identifying the Resource, the Resource-ID is also used by the distributed database algorithm to determine the Peer or Peers that store the Resource Record in the Overlay.
P2PSIPオーバーレイは分散データベースとして機能します。データベースは、リソースに関する情報を格納する方法として機能します。 「リソースレコード」と呼ばれる情報は、「リソースID」と呼ばれるリソースレコードに関連付けられたキーを使用して、データベースに格納したり、データベースから取得したりできます。各リソースには一意のリソースIDが必要です。リソースを一意に識別することに加えて、Resource-IDは分散データベースアルゴリズムでも使用され、オーバーレイにリソースレコードを保存するピアを決定します。
Users are humans that can use the Overlay to do things like making and receiving calls. Information stored in the resource record associated with a user can include things like the full name of the user and the location of the UAs that the user is using (the user's SIP AoR). Full details of how this is implemented using RELOAD are provided in [P2PSIP].
ユーザーは、オーバーレイを使用して通話の発信や受信などを実行できる人間です。ユーザーに関連付けられたリソースレコードに格納される情報には、ユーザーのフルネームや、ユーザーが使用しているUA（ユーザーのSIP AoR）の場所などが含まれます。 RELOADを使用してこれを実装する方法の詳細は、[P2PSIP]で提供されています。
Before information about a user can be stored in the Overlay, a user needs a User Name. The User Name is a human-friendly identifier that uniquely identifies the user within the Overlay. In RELOAD, users are issued certificates, which in the case of centrally signed certificates, identify the User Name as well as a certain number of Resource-IDs where the user may store their information. For more information, see [RFC6940].
ユーザーに関する情報をオーバーレイに保存する前に、ユーザーにはユーザー名が必要です。ユーザー名は、オーバーレイ内でユーザーを一意に識別する、人にわかりやすい識別子です。 RELOADでは、ユーザーに証明書が発行されます。中央署名付き証明書の場合は、ユーザー名と、ユーザーが情報を保存できる特定の数のリソースIDを識別します。詳細については、[RFC6940]を参照してください。
The P2PSIP suite of protocols also standardizes information about how to locate services. Services represent actions that a Peer (and perhaps a Client) can do to benefit other Peers and Clients in the Overlay. Information that might be stored in the resource record associated with a service might include the Peers (and perhaps Clients) offering the service. Service discovery for P2PSIP is defined in [RFC7374].
P2PSIPプロトコルスイートは、サービスの検索方法に関する情報も標準化しています。サービスは、ピア（およびクライアント）がオーバーレイ内の他のピアおよびクライアントに利益をもたらすために実行できるアクションを表します。サービスに関連付けられたリソースレコードに格納される可能性のある情報には、サービスを提供するピア（およびおそらくクライアント）が含まれる場合があります。 P2PSIPのサービス発見は[RFC7374]で定義されています。
Each service has a human-friendly Service Name that uniquely identifies the service. Like User Names, the Service Name is not a Resource-ID, rather the Resource-ID is derived from the service name using some function defined by the distributed database algorithm used by the Overlay.
各サービスには、サービスを一意に識別する、わかりやすいサービス名があります。ユーザー名と同様に、サービス名はリソースIDではなく、オーバーレイで使用される分散データベースアルゴリズムで定義された関数を使用して、サービス名から派生します。
A class of algorithms known as Distributed Hash Tables (DHTs) are one way to implement the distributed database. The RELOAD protocol is extensible and allows many different DHTs to be implemented, but specifies a mandatory-to-implement DHT in the form of a modified Chord DHT. For more information, see [Chord].
分散ハッシュテーブル（DHT）と呼ばれるアルゴリズムのクラスは、分散データベースを実装する1つの方法です。 RELOADプロトコルは拡張可能であり、多くの異なるDHTを実装できますが、実装するために必須のDHTを変更されたコードDHTの形式で指定します。詳細については、[コード]を参照してください。
While there are a number of ways the distributed database described in the previous section can be used to establish multimedia sessions using SIP, the basic mechanism defined in the RELOAD protocol and SIP usage is summarized below. This is a very simplistic overview. For more detailed information, please see the RELOAD protocol [RFC6940].
前のセクションで説明した分散データベースを使用してSIPを使用したマルチメディアセッションを確立する方法はいくつかありますが、RELOADプロトコルで定義された基本的なメカニズムとSIPの使用法を以下にまとめます。これは非常に単純化した概要です。詳細については、RELOADプロトコル[RFC6940]を参照してください。
Contact information for a user is stored in the resource record for that user. Assume that a user is using a device, here called "Peer A", that serves as the contact point for this user. The user adds contact information to this resource record, as authorized by the RELOAD certificate mechanism. The resource record itself is stored with Peer Z in the network, where Peer Z is chosen by the particular distributed database algorithm in use by the Overlay.
ユーザーの連絡先情報は、そのユーザーのリソースレコードに格納されます。ユーザーが、ここでは「ピアA」と呼ばれる、このユーザーの連絡先として機能するデバイスを使用しているとします。ユーザーは、RELOAD証明書メカニズムによって承認されたように、このリソースレコードに連絡先情報を追加します。リソースレコード自体はピアZと共にネットワークに格納されます。ピアZは、オーバーレイで使用されている特定の分散データベースアルゴリズムによって選択されます。
When the SIP entity coupled with Peer B has an INVITE message addressed to this user, it retrieves the resource record from Peer Z. It then extracts the contact information for the various Peers that are a contact point for the user, including Peer A, and uses the Overlay to establish a connection to Peer A, including any appropriate NAT traversal (the details of which are not shown).
ピアBと結合したSIPエンティティがこのユーザー宛のINVITEメッセージを持っている場合、ピアZからリソースレコードを取得します。次に、ピアAを含む、ユーザーの連絡先であるさまざまなピアの連絡先情報を抽出します。オーバーレイを使用して、ピアAへの接続を確立します。これには、適切なNATトラバーサルが含まれます（詳細は示していません）。
Note that RELOAD is used only to establish the connection. Once the connection is established, messages between the Peers are sent using ordinary SIP.
RELOADは接続を確立するためにのみ使用されることに注意してください。接続が確立されると、ピア間のメッセージは通常のSIPを使用して送信されます。
This exchange is illustrated in the following figure. The notation "Store(U@A)" is used to show the distributed database operation of updating the resource record for user U with the contract A, and "Fetch(U)" illustrates the distributed database operation of retrieving the resource record for user U. Note that the messages between the Peers A, B, and Z may actually travel via intermediate Peers (not shown) as part of the distributed lookup process or so as to traverse intervening NATs.
この交換を次の図に示します。表記「Store（U @ A）」は、契約AでユーザーUのリソースレコードを更新する分散データベース操作を示すために使用され、「Fetch（U）」は、ユーザーのリソースレコードを取得する分散データベース操作を示していますU.ピアA、B、Z間のメッセージは、分散ルックアッププロセスの一部として、または介在するNATを通過するために、中間ピア（図示せず）を介して実際に送信される場合があることに注意してください。
Peer B Peer Z Peer A
| | |
| | Store(U@A)|
| |<------------------|
| |Store-Resp(OK) |
| |------------------>|
| | |
|Fetch(U) | |
|------------------->| |
| Fetch-Resp(U@A)| |
|<-------------------| |
| | |
(RELOAD IS USED TO ESTABLISH CONNECTION)
| | |
| SIP INVITE(To:U) | |
|--------------------------------------->|
| | |
Figure 2: SIP Exchange Using Distributed Database Function
図2：分散データベース機能を使用したSIP交換
NAT traversal in P2PSIP using RELOAD treats all Peers as equal and establishes a partial mesh of connections between them. Messages from one Peer to another are routed along the edges in the mesh of connections until they reach their destination. To make the routing efficient and to avoid the use of standard Internet routing protocols, the partial mesh is organized in a structured manner. If the structure is based on any one of a number of common DHT algorithms, then the maximum number of hops between any two Peers is log N, where N is the number of peers in the overlay. Existing connections, along with the Interactive Connectivity Establishment (ICE) NAT traversal techniques [RFC5245], are used to establish new connections between Peers, and also to allow the applications running on Peers to establish a connection to communicate with one another.
RELOADを使用したP2PSIPのNATトラバーサルは、すべてのピアを同等として扱い、それらの間の接続の部分的なメッシュを確立します。あるピアから別のピアへのメッセージは、宛先に到達するまで接続メッシュのエッジに沿ってルーティングされます。ルーティングを効率化し、標準のインターネットルーティングプロトコルの使用を回避するために、部分メッシュは構造化された方法で編成されます。構造がいくつかの一般的なDHTアルゴリズムのいずれかに基づいている場合、2つのピア間のホップの最大数はlog Nです。ここで、Nはオーバーレイ内のピアの数です。 Interactive Connectivity Establishment（ICE）NATトラバーサル手法[RFC5245]とともに既存の接続を使用して、ピア間の新しい接続を確立し、ピアで実行されているアプリケーションが相互に通信するための接続を確立できるようにします。
Before a Peer can attempt to join a P2PSIP Overlay, it must first obtain a Node-ID, configuration information, and optionally a set of credentials. The Node-ID is an identifier that uniquely identifies the Peer within the Overlay, while the credentials show that the Peer is allowed to join the Overlay.
ピアがP2PSIPオーバーレイへの参加を試みる前に、ピアはまずノードID、構成情報、およびオプションで資格情報のセットを取得する必要があります。ノードIDは、オーバーレイ内でピアを一意に識別する識別子ですが、資格情報は、ピアがオーバーレイに参加することを許可されていることを示しています。
The P2PSIP WG does not impose a particular mechanism for how the Peer-ID and the credentials are obtained, but the RELOAD protocol does specify the format for the configuration information and how this information may be obtained, along with credentials and a Node-ID, from an offline enrollment server.
P2PSIP WGは、Peer-IDと資格情報の取得方法に特定のメカニズムを課していませんが、RELOADプロトコルは、構成情報の形式と資格情報とノードIDとともにこの情報を取得する方法を指定しています。オフライン登録サーバーから。
Once the configuration information is obtained, RELOAD specifies a mechanism whereby a Peer may obtain a multicast-bootstrap address in the configuration file and broadcast to this address to attempt locating a Bootstrap Peer. Additionally, the Peer may store previous Peers it has seen and attempt using these as Bootstrap Peers, or it may obtain an address for a Bootstrap Peer by some other mechanism. For more information, see the RELOAD protocol.
構成情報が取得されると、RELOADは、ピアが構成ファイル内のマルチキャストブートストラップアドレスを取得し、このアドレスにブロードキャストしてブートストラップピアの検索を試みるメカニズムを指定します。さらに、ピアは、以前に確認したピアを保存して、これらをブートストラップピアとして使用するか、他のメカニズムによってブートストラップピアのアドレスを取得する場合があります。詳細については、RELOADプロトコルを参照してください。
The job of the Bootstrap Peer is simple: refer the Joining Peer to a Peer (called the "Admitting Peer") that will help the Joining Peer join the network. The choice of the Admitting Peer will often depend on the Joining Peer -- for example, the Admitting Peer may be a Peer that will become a neighbor of the Joining Peer in the Overlay. It is possible that the Bootstrap Peer might also serve as the Admitting Peer.
ブートストラップピアの仕事は簡単です。参加ピアをネットワークに参加させるのに役立つピア（「許可ピア」と呼ばれます）に参加ピアを紹介します。 Admitting Peerの選択は、Joining Peerに依存することがよくあります。たとえば、Admitting Peerは、オーバーレイのJoining Peerのネイバーになるピアになる場合があります。ブートストラップピアがアドミッティングピアとしても機能する可能性があります。
The Admitting Peer will help the Joining Peer learn about other Peers in the Overlay and establish connections to them as appropriate. The Admitting Peer and/or the other Peers in the Overlay will also do whatever else is required to help the Joining Peer become a fully functional Peer. The details of how this is done will depend on the distributed database algorithm used by the Overlay.
Admitting Peerは、Joining Peerがオーバーレイ内の他のピアについて学習し、必要に応じてそれらへの接続を確立するのに役立ちます。許可ピアおよび/またはオーバーレイ内の他のピアは、参加ピアが完全に機能するピアになるために必要な他のこともすべて行います。これがどのように行われるかの詳細は、オーバーレイで使用される分散データベースアルゴリズムによって異なります。
At various stages in this process, the Joining Peer may be asked to present its credentials to show that it is authorized to join the Overlay. Similarly, the various Peers contacted may be asked to present their credentials so the Joining Peer can verify that it is really joining the Overlay it wants to.
このプロセスのさまざまな段階で、Joining Peerはクレデンシャルを提示して、オーバーレイへの参加が許可されていることを示すよう求められる場合があります。同様に、接続されたさまざまなピアは、自分の資格情報を提示するよう求められる場合があります。これにより、参加ピアは、自分が希望するオーバーレイに本当に参加していることを確認できます。
As mentioned above, in RELOAD, from the perspective of the protocol, Clients are simply peers that do not store information, do not route messages, and have not inserted themselves into the Overlay. The same protocol is used for the actual message exchanged. Note that while the protocol is the same, the Client need not implement all the capabilities of a Peer. If, for example, it never routes messages, it will not need to be capable of processing such messages or understanding a DHT.
上記のように、RELOADでは、プロトコルの観点から、クライアントは単に情報を格納せず、メッセージをルーティングせず、オーバーレイに挿入されていないピアです。交換される実際のメッセージには同じプロトコルが使用されます。プロトコルは同じですが、クライアントはピアのすべての機能を実装する必要はありません。たとえば、メッセージをルーティングしない場合、そのようなメッセージを処理したり、DHTを理解したりする必要はありません。
For SIP devices, another way to realize this functionality is for a Peer to behave as a proxy/registrar as specified in [RFC3261]. SIP devices then use standard SIP mechanisms to add, update, and remove registrations and to send SIP messages to Peers and other Clients. The authors here refer to these devices simply as a "SIP UA", not a "P2PSIP Client", to distinguish it from the concept described above.
SIPデバイスの場合、この機能を実現するもう1つの方法は、ピアが[RFC3261]で指定されているプロキシ/レジストラとして動作することです。次に、SIPデバイスは標準のSIPメカニズムを使用して、登録を追加、更新、および削除し、SIPメッセージをピアおよび他のクライアントに送信します。ここでは、これらのデバイスを「P2PSIPクライアント」ではなく単に「SIP UA」と呼び、上記の概念と区別しています。
The architecture adopted by RELOAD to implement P2PSIP is shown below. An application (for example, SIP or another application using RELOAD) uses RELOAD to locate other Peers and (optionally) to establish connections to those Peers, potentially across NATs. Messages may still be exchanged directly between the Peers. The overall block diagram for the architecture is as follows:
P2PSIPを実装するためにRELOADが採用したアーキテクチャを以下に示します。アプリケーション（たとえば、SIPまたはRELOADを使用する別のアプリケーション）は、RELOADを使用して他のピアを検索し、（オプションで）NAT全体でそれらのピアへの接続を確立します。メッセージはピア間で直接交換される場合があります。アーキテクチャの全体的なブロック図は次のとおりです。
__________________________
| |
| SIP, other apps... |
| ___________________|
| | RELOAD Layer |
|______|___________________|
| Transport Layer |
|__________________________|
Figure 3: Architecture for Implementing P2PSIP
図3：P2PSIPを実装するためのアーキテクチャ
This specification is an overview of existing specifications and does not introduce any security considerations on its own. Please refer to the security considerations of the respective specifications, particularly the RELOAD protocol specification ([RFC6940]) for further details.
この仕様は既存の仕様の概要であり、それ自体でセキュリティに関する考慮事項を紹介するものではありません。詳細については、それぞれの仕様、特にRELOADプロトコル仕様（[RFC6940]）のセキュリティに関する考慮事項を参照してください。
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A scalable peer-to-peer lookup protocol for internet applications", IEEE/ACM Transactions on Networking, Volume 11, Issue 1, pp. 17-32, DOI 10.1109/TNET.2002.808407, February 2003.
[コード] Stoica、I.、Morris、R.、Liben-Nowell、D.、Karger、D.、Kaashoek、M.、Dabek、F。、およびH. Balakrishnan、「コード：スケーラブルなピアツーピアインターネットアプリケーションのルックアッププロトコル」、IEEE / ACM Transactions on Networking、Volume 11、Issue 1、17-32ページ、DOI 10.1109 / TNET.2002.808407、2003年2月。
[P2PSIP] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD", Work in Progress, draft-ietf-p2psip-sip-21, April 2016.
[P2PSIP] Jennings、C.、Lowekamp、B.、Rescorla、E.、Baset、S.、Schulzrinne、H。、およびT. Schmidt、「A SIP Usage for RELOAD」、Work in Progress、draft-ietf-p2psip -sip-21、2016年4月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、and J. Bound、 "Dynamic Updates in the Domain Name System（DNS UPDATE）"、RFC 2136、DOI 10.17487 / RFC2136、April 1997 、<http://www.rfc-editor.org/info/rfc2136>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <http://www.rfc-editor.org/info/rfc3263>.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、DOI 10.17487 / RFC3263、2002年6月、<http://www.rfc-editor.org/info / rfc3263>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, DOI 10.17487/RFC4795, January 2007, <http://www.rfc-editor.org/info/rfc4795>.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-local Multicast Name Resolution（LLMNR）」、RFC 4795、DOI 10.17487 / RFC4795、2007年1月、<http：//www.rfc- editor.org/info/rfc4795>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<http://www.rfc-editor.org/info/rfc5766>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<http://www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<http://www.rfc-editor.org/info/rfc6763>。
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, <http://www.rfc-editor.org/info/rfc6940>.
[RFC6940] Jennings、C.、Lowekamp、B.、Ed。、Rescorla、E.、Baset、S。、およびH. Schulzrinne、「REsource LOcation And Discovery（RELOAD）Base Protocol」、RFC 6940、DOI 10.17487 / RFC6940 、2014年1月、<http://www.rfc-editor.org/info/rfc6940>。
[RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014, <http://www.rfc-editor.org/info/rfc7363>.
[RFC7363] Maenpaa、J。、およびG. Camarillo、「REsource LOcation And Discovery（RELOAD）の自己調整分散ハッシュテーブル（DHT）」、RFC 7363、DOI 10.17487 / RFC7363、2014年9月、<http：// www。 rfc-editor.org/info/rfc7363>。
[RFC7374] Maenpaa, J. and G. Camarillo, "Service Discovery Usage for REsource LOcation And Discovery (RELOAD)", RFC 7374, DOI 10.17487/RFC7374, October 2014, <http://www.rfc-editor.org/info/rfc7374>.
[RFC7374] Maenpaa、J.、G。Camarillo、「Service Discovery Usage for REsource LOcation And Discovery（RELOAD）」、RFC 7374、DOI 10.17487 / RFC7374、2014年10月、<http://www.rfc-editor.org/ info / rfc7374>。
[RFC7851] Song, H., Jiang, X., Even, R., Bryan, D., and Y. Sun, "Peer-to-Peer (P2P) Overlay Diagnostics", RFC 7851, DOI 10.17487/RFC7851, May 2016, <http://www.rfc-editor.org/info/rfc7851>.
[RFC7851] Song、H.、Jiang、X.、Even、R.、Bryan、D。、およびY. Sun、「ピアツーピア（P2P）オーバーレイ診断」、RFC 7851、DOI 10.17487 / RFC7851、5月2016、<http://www.rfc-editor.org/info/rfc7851>。
Authors' Addresses
著者のアドレス
David A. Bryan Cogent Force, LLC Cedar Park, Texas United States
David A. Bryan Cogent Force、LLCシーダーパーク、テキサス州アメリカ合衆国
Email: dbryan@ethernot.org
Philip Matthews Nokia 600 March Road Ottawa, Ontario K2K 2E6 Canada
Philip Matthews Nokia 600 March Roadオタワオンタリオ州K2K 2E6カナダ
Phone: +1 613 784 3139
Email: philip_matthews@magma.ca
Eunsoo Shim Samsung Electronics Co., Ltd. San 14, Nongseo-dong, Giheung-gu Yongin-si, Gyeonggi-do 446-712 South Korea
Eunsoo Shim Samsung Electronics Co.、Ltd. San 14、京畿道龍仁市技興区農草洞韓国446446-712韓国
Email: eunsooshim@gmail.com
Dean Willis Softarmor Systems 3100 Independence Pkwy #311-164 Plano, Texas 75075 United States
Dean Willis Softarmor Systems 3100 Independence Pkwy＃311-164 Plano、Texas 75075 United States
Phone: +1 214 504 1987
Email: dean.willis@softarmor.com
Spencer Dawkins Huawei Technologies (USA)
Spencer Dawkins Huawei Technologies（USA）
Phone: +1 214 755 3870
Email: spencerdawkins.ietf@gmail.com