[要約] RFC 7846は、Peer-to-Peer Streaming Tracker Protocol（PPSTP）に関する規格です。PPSTPは、ピアツーピアストリーミングのためのトラッカープロトコルであり、ピアの接続情報を管理することを目的としています。
Internet Engineering Task Force (IETF) R. Cruz
Request for Comments: 7846 M. Nunes
Category: Standards Track IST/INESC-ID/INOV
ISSN: 2070-1721 J. Xia
R. Huang, Ed.
Huawei
J. Taveira
IST/INOV
D. Lingli
China Mobile
May 2016
Peer-to-Peer Streaming Tracker Protocol (PPSTP)
ピアツーピアストリーミングトラッカープロトコル（PPSTP）
Abstract
概要
This document specifies the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content-streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.
このドキュメントでは、トラッカーとピア間でメタ情報を交換するための基本的なピアツーピアストリーミングトラッカープロトコル（PPSTP）バージョン1、アプリケーション層制御（シグナリング）プロトコルについて説明します。この仕様は、プロトコルのアーキテクチャとその機能の概要を示しています。また、メッセージフロー、メッセージ処理命令、メッセージフォーマット、正式な構文、およびセマンティクスについても説明します。 PPSTPは、協調するピアがコンテンツストリーミングオーバーレイネットワークを形成して、適応型マルチレート、階層化（スケーラブル）、マルチなどの構造化メディアコンテンツ（オーディオ、ビデオ、および関連するタイミングテキストとメタデータ）のほぼリアルタイムの配信をサポートできるようにします-ライブ、タイムシフト、およびオンデマンドモードで（3D）ビデオを表示します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7846.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7846で入手できます。
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. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Design Overview ............................................6
1.2.1. Typical PPSP Session ................................7
1.2.2. Example of a PPSP Session ...........................7
2. Protocol Architecture and Functional View ......................10
2.1. Messaging Model ...........................................10
2.2. Request/Response Model ....................................10
2.3. State Machines and Flows of the Protocol ..................12
2.3.1. Normal Operation ...................................14
2.3.2. Error Conditions ...................................15
3. Protocol Specification .........................................16
3.1. Presentation Language .....................................16
3.2. Resource Element Types ....................................16
3.2.1. Version ............................................16
3.2.2. Peer Number Element ................................17
3.2.3. Swarm Action Element ...............................18
3.2.4. Peer Information Elements ..........................18
3.2.5. Statistics and Status Information Element ..........20
3.3. Requests and Responses ....................................21
3.3.1. Request Types ......................................21
3.3.2. Response Types .....................................21
3.3.3. Request Element ....................................22
3.3.4. Response Element ...................................23
3.4. PPSTP Message Element .....................................24
4. Protocol Specification: Encoding and Operation .................24
4.1. Requests and Responses ....................................25
4.1.1. CONNECT Request ....................................25
4.1.1.1. Example ...................................28
4.1.2. FIND Request .......................................32
4.1.2.1. Example ...................................33
4.1.3. STAT_REPORT Request ................................34
4.1.3.1. Example ...................................35
4.2. Response Element in Response Messages .....................36
4.3. Error and Recovery Conditions .............................37
4.4. Parsing of Unknown Fields in message-body .................38
5. Operations and Manageability ...................................38
5.1. Operational Considerations ................................38
5.1.1. Installation and Initial Setup .....................38
5.1.2. Migration Path .....................................39
5.1.3. Requirements on Other Protocols and
Functional Components ..............................39
5.1.4. Impact on Network Operation ........................39
5.1.5. Verifying Correct Operation ........................40
5.2. Management Considerations .................................40
5.2.1. Interoperability ...................................40
5.2.2. Management Information .............................40
5.2.3. Fault Management ...................................41
5.2.4. Configuration Management ...........................41
5.2.5. Accounting Management ..............................41
5.2.6. Performance Management .............................41
5.2.7. Security Management ................................41
6. Security Considerations ........................................42
6.1. Authentication between Tracker and Peers ..................42
6.2. Content Integrity Protection against Polluting
Peers/Trackers ............................................43
6.3. Residual Attacks and Mitigation ...........................43
6.4. Pro-incentive Parameter Trustfulness ......................44
6.5. Privacy for Peers .........................................44
7. Guidelines for Extending PPSTP .................................45
7.1. Forms of PPSTP Extension ..................................45
7.2. Issues to Be Addressed in PPSTP Extensions ................47
8. IANA Considerations ............................................48
8.1. MIME Type Registry ........................................48
8.2. PPSTP Version Number Registry .............................49
8.3. PPSTP Request Type Registry ...............................49
8.4. PPSTP Error Code Registry .................................50
9. References .....................................................51
9.1. Normative References ......................................51
9.2. Informative References ....................................53
Acknowledgments ...................................................54
Authors' Addresses ................................................55
The Peer-to-Peer Streaming Protocol (PPSP) is composed of two protocols: the Tracker Protocol (defined in this document) and the Peer Protocol (defined in [RFC7574]). [RFC6972] specifies that the Tracker Protocol should standardize the messages between PPSP peers and PPSP trackers and also defines the requirements.
ピアツーピアストリーミングプロトコル（PPSP）は、トラッカープロトコル（このドキュメントで定義）とピアプロトコル（[RFC7574]で定義）の2つのプロトコルで構成されています。 [RFC6972]は、トラッカープロトコルがPPSPピアとPPSPトラッカー間のメッセージを標準化する必要があることを指定し、要件も定義しています。
The Peer-to-Peer Streaming Tracker Protocol (PPSTP) provides communication between trackers and peers by which peers send meta information to trackers, report streaming status, and obtain peer lists from trackers.
ピアツーピアストリーミングトラッカープロトコル（PPSTP）は、ピアがメタ情報をトラッカーに送信し、ストリーミングステータスを報告し、トラッカーからピアリストを取得することにより、トラッカーとピア間の通信を提供します。
The PPSP architecture requires PPSP peers to be able to communicate with a tracker in order to participate in a particular streaming content swarm. This centralized tracker service is used by PPSP peers for acquisition of peer lists.
PPSPアーキテクチャでは、特定のストリーミングコンテンツ群に参加するために、PPSPピアがトラッカーと通信できる必要があります。この一元化されたトラッカーサービスは、PPSPピアがピアリストの取得に使用します。
The signaling and the media data transfer between PPSP peers is not in the scope of this specification.
PPSPピア間のシグナリングとメディアデータ転送は、この仕様の範囲外です。
This document introduces a base Peer-to-Peer Streaming Tracker Protocol (PPSTP) that satisfies the requirements in [RFC6972].
このドキュメントでは、[RFC6972]の要件を満たす基本のピアツーピアストリーミングトラッカープロトコル（PPSTP）を紹介します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
absolute time: Expressed as ISO 8601 timestamps, using zero UTC offset. Fractions of a second may be indicated, for example, December 25, 2010 at 14h56 and 20.25 seconds in basic format is 20101225T145620.25Z and in extended format is 2010-12-25T14:56:20.25Z.
絶対時間：UTCオフセットがゼロのISO 8601タイムスタンプとして表されます。秒の端数は、たとえば2010年12月25日14h56および20.25秒で基本形式で20101225T145620.25Z、拡張形式で2010-12-25T14：56：20.25Zと表示される場合があります。
chunk: An uniformly atomic subset of the resource that constitutes the basic unit of data organized in P2P streaming for storage, scheduling, advertisement, and exchange among peers.
チャンク：リソースの均一にアトミックなサブセットであり、ピア間のストレージ、スケジューリング、アドバタイズメント、および交換のためにP2Pストリーミングで編成されるデータの基本単位を構成します。
chunk ID: A unique resource identifier for a chunk. The identifier type depends on the addressing scheme used, i.e., an integer, an HTTP-URL, and possibly a byte-range. The identifier type is described in the Media Presentation Description (MPD).
チャンクID：チャンクの一意のリソース識別子。識別子のタイプは、使用されるアドレス指定スキーム、つまり整数、HTTP-URL、および場合によってはバイト範囲によって異なります。識別子の種類は、メディアプレゼンテーション記述（MPD）で説明されています。
LEECH: The peers in a swarm that download content from other peers as well as contribute downloaded content with others. A LEECH should join the swarm with uncompleted media content.
リーチ：他のピアからコンテンツをダウンロードしたり、ダウンロードしたコンテンツを他のピアに提供したりする、群れの中のピア。リーチは未完成のメディアコンテンツで群れに加わるべきです。
MPD (Media Presentation Description): Formalized description for a media presentation, i.e., describes the structure of the media, namely, the representations, the codecs used, the chunks, and the corresponding addressing scheme.
MPD（Media Presentation Description）：メディアプレゼンテーションの正式な説明。つまり、メディアの構造、つまり、表現、使用されるコーデック、チャンク、および対応するアドレッシングスキームを記述します。
peer: A participant in a P2P streaming system that not only receives streaming content, but also caches and streams streaming content to other participants.
ピア：ストリーミングコンテンツを受信するだけでなく、ストリーミングコンテンツをキャッシュして他の参加者にストリーミングするP2Pストリーミングシステムの参加者。
peer ID: The identifier of a peer such that other peers, or the Tracker, can refer to the peer using its ID. The peer ID is mandatory, can take the form of a universally unique identifier (UUID), defined in [RFC4122], and can be bound to a network address of the peer, i.e., an IP address or a uniform resource identifier/locator (URI/URL) that uniquely identifies the corresponding peer in the network. The peer ID and any required security certificates are obtained from an offline enrollment server.
ピアID：他のピアまたはトラッカーがそのIDを使用してピアを参照できるようなピアの識別子。ピアIDは必須であり、[RFC4122]で定義されているUniversally Unique Identifier（UUID）の形式をとることができ、ピアのネットワークアドレス、つまりIPアドレスまたはUniform Resource Identifier / Locator（ URI / URL）。ネットワーク内の対応するピアを一意に識別します。ピアIDと必要なセキュリティ証明書は、オフライン登録サーバーから取得されます。
peer list: A list of peers that are in the same swarm maintained by the tracker. A peer can fetch the peer list of a swarm from the tracker.
ピアリスト：トラッカーによって維持されている同じスウォームにあるピアのリスト。ピアは、トラッカーからスウォームのピアリストを取得できます。
PPSP: The abbreviation of Peer-to-Peer Streaming Protocol.
PPSP：Peer-to-Peer Streaming Protocolの略。
PPSTP: The abbreviation of Peer-to-Peer Streaming Tracker Protocol.
PPSTP：Peer-to-Peer Streaming Tracker Protocolの略。
SEEDER: The peers in a swarm that only contribute the content they have to others. A SEEDER should join the swarm with complete media content.
SEEDER：他の人に持っているコンテンツのみを提供する群れの仲間。 SEEDERは、完全なメディアコンテンツで群れに参加する必要があります。
service portal: A logical entity typically used for client enrollment and for publishing, searching, and retrieving content information. It is usually located in a server of a content provider.
サービスポータル：通常、クライアントの登録や、コンテンツ情報の公開、検索、取得に使用される論理エンティティ。通常、コンテンツプロバイダーのサーバーにあります。
swarm: A group of peers that exchange data to distribute chunks of the same content (e.g., video/audio program, digital file, etc.) at a given time.
群れ：データを交換して、特定の時間に同じコンテンツ（ビデオ/オーディオプログラム、デジタルファイルなど）のチャンクを配布するピアのグループ。
swarm ID: The identifier of a swarm containing a group of peers sharing common streaming content. The swarm ID may use a universally unique identifier (UUID), e.g., a 64- or 128-bit datum to refer to the content resource being shared among peers.
群れID：共通のストリーミングコンテンツを共有するピアのグループを含む群れの識別子。スウォームIDは、ピア間で共有されているコンテンツリソースを参照するために、64ビットまたは128ビットのデータなどの汎用一意識別子（UUID）を使用できます。
tracker: A directory service that maintains a list of peers participating in a specific audio/video channel or in the distribution of a streaming file. It is a logical component that can be deployed in a centralized or distributed way.
トラッカー：特定のオーディオ/ビデオチャネルまたはストリーミングファイルの配布に参加しているピアのリストを維持するディレクトリサービス。これは、集中型または分散型の方法で展開できる論理コンポーネントです。
transaction ID: The identifier of a request from the peer to the tracker. It is used to disambiguate responses that may arrive in a different order than the corresponding requests.
トランザクションID：ピアからトラッカーへのリクエストの識別子。これは、対応する要求とは異なる順序で到着する可能性がある応答を明確にするために使用されます。
The functional entities related to peer-to-peer streaming protocols are the Client Media Player, the service portal, the tracker, and the peers. The complete description of Client Media Player and service portal is not discussed here, as they are not in the scope of the specification. The functional entities directly involved in PPSTP are trackers and peers (which may support different capabilities).
ピアツーピアストリーミングプロトコルに関連する機能エンティティは、クライアントメディアプレーヤー、サービスポータル、トラッカー、およびピアです。クライアントメディアプレーヤーとサービスポータルの完全な説明は、仕様の範囲外であるため、ここでは説明しません。 PPSTPに直接関与する機能エンティティは、トラッカーとピアです（異なる機能をサポートしている場合があります）。
The Client Media Player is a logical entity providing direct interface to the end user at the client device and includes the functions to select, request, decode, and render content. The Client Media Player may interface with the local peer application using the standard format for HTTP request and response messages [RFC7230].
クライアントメディアプレーヤーは、クライアントデバイスのエンドユーザーに直接インターフェイスを提供する論理エンティティであり、コンテンツを選択、要求、デコード、およびレンダリングする機能が含まれています。クライアントメディアプレーヤーは、HTTP要求および応答メッセージの標準形式[RFC7230]を使用して、ローカルピアアプリケーションとインターフェイスすることができます。
The service portal is a logical entity typically used for client enrollment and for publishing, searching, and retrieving content information.
サービスポータルは、通常、クライアントの登録、およびコンテンツ情報の公開、検索、取得に使用される論理エンティティです。
A peer corresponds to a logical entity (typically in a user device) that actually participates in sharing media content. Peers are organized in various swarms; each swarm corresponds to the group of peers streaming certain content at any given time.
ピアは、メディアコンテンツの共有に実際に参加する論理エンティティ（通常はユーザーデバイス内）に対応します。ピアはさまざまな群れで編成されます。各群は、特定のコンテンツをいつでもストリーミングするピアのグループに対応しています。
A tracker is a logical entity that maintains the lists of peers storing chunks for a specific live media channel or on-demand media streaming content, answers queries from peers, and collects information on the activity of peers. While a tracker may have an underlying implementation consisting of more than one physical node, logically, the tracker can most simply be thought of as a single element; in this document, it will be treated as a single logical entity. Communication between these physical nodes to present them as a single tracker to peers is not considered in PPSTP, which is a protocol between a tracker and a peer.
トラッカーは、特定のライブメディアチャネルまたはオンデマンドメディアストリーミングコンテンツのチャンクを格納するピアのリストを維持し、ピアからのクエリに応答し、ピアのアクティビティに関する情報を収集する論理エンティティです。トラッカーは、論理的には複数の物理ノードで構成される基本的な実装を持つことができますが、トラッカーは最も単純に単一の要素と考えることができます。このドキュメントでは、単一の論理エンティティとして扱われます。これらの物理ノード間の通信をピアへの単一のトラッカーとして提示することは、トラッカーとピア間のプロトコルであるPPSTPでは考慮されません。
PPSTP is not used to exchange actual content data (either on demand or live streaming) with peers, but information about which peers can provide the content. PPSTP is not designed for applications for which in-sync reception is needed.
PPSTPは、ピアとの実際のコンテンツデータ（オンデマンドまたはライブストリーミング）の交換には使用されませんが、どのピアがコンテンツを提供できるかについての情報です。 PPSTPは、同期受信が必要なアプリケーション用に設計されていません。
When a peer wants to receive streaming of selected content (LEECH mode):
ピアが選択したコンテンツのストリーミングを受信する場合（LEECHモード）：
1. Peer connects to a tracker and joins a swarm.
1. ピアはトラッカーに接続し、群れに参加します。
2. Peer acquires a list of other peers in the swarm from the tracker.
2. ピアは、トラッカーからスウォーム内の他のピアのリストを取得します。
3. Peer exchanges its content availability with the peers on the obtained peer list.
3. ピアは、取得したピアリストのピアとコンテンツの可用性を交換します。
4. Peer identifies the peers with desired content.
4. ピアは、目的のコンテンツを持つピアを識別します。
5. Peer requests content from the identified peers.
5. ピアは、識別されたピアにコンテンツを要求します。
When a peer wants to share streaming content (SEEDER mode) with other peers:
ピアがストリーミングコンテンツ（SEEDERモード）を他のピアと共有する場合：
1. Peer connects to a tracker.
1. ピアはトラッカーに接続します。
2. Peer sends information to the tracker about the swarms it belongs to (joined swarms).
2. ピアは、それが属する群れ（結合された群れ）に関する情報をトラッカーに送信します。
3. Peer waits for other peers in LEECH mode to connect with it (see steps 3-5 in the previous list).
3. ピアは、LEECHモードの他のピアが接続するのを待ちます（前のリストのステップ3〜5を参照）。
After having been disconnected due to some termination conditions or user controls, a peer can resume previous activity by connecting and re-joining the corresponding swarm(s).
いくつかの終了条件またはユーザーコントロールのために切断された後、ピアは、対応する群に接続して再参加することにより、以前のアクティビティを再開できます。
In order to be able to bootstrap in the P2P network, a peer must first obtain a peer ID and any required security certificates or authorization tokens from an enrollment service (end-user registration). The peer ID MUST be unique (see the definition of "peer ID" in Section 1.1); however, the representation of the peer ID is not considered in this document.
P2Pネットワークでブートストラップできるようにするには、ピアが最初にピアIDと必要なセキュリティ証明書または承認トークンを登録サービスから取得する必要があります（エンドユーザー登録）。ピアIDは一意でなければなりません（セクション1.1の「ピアID」の定義を参照）。ただし、このドキュメントではピアIDの表記は考慮されていません。
+--------+ +--------+ +--------+ +---------+ +--------+
| Player | | Peer_1 | | Portal | | Tracker | | Peer_2 |
+--------+ +--------+ +--------+ +---------+ +--------+
| | | | |
(a) |--Page request----------------->| | |
|<--------------Page with links--| | |
|--Select stream (MPD request)-->| | |
|<--------------------OK+MPD(x)--| | |
(b) |--Start/Resume->|--CONNECT(join x)------------>| |
|<-----------OK--|<----------------OK+Peerlist--| |
| | | |
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
| |--STAT_REPORT---------------->| |
| |<-------------------------OK--| |
: : : : :
| |--FIND----------------------->| |
| |<----------------OK+Peerlist--| |
: : : : :
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
Figure 1: A Typical PPSP Session for Streaming Content
図1：ストリーミングコンテンツの一般的なPPSPセッション
To join an existing P2P streaming service and to participate in content sharing, a peer must first locate a tracker.
既存のP2Pストリーミングサービスに参加し、コンテンツ共有に参加するには、ピアは最初にトラッカーを見つける必要があります。
As illustrated in Figure 1, a P2P streaming session may be initiated starting at point (a), with the Client Media Player browsing for the desired content in order to request it (to the local Peer_1 in the figure), or resume a previously initiated stream, but starting at point (b). For this example, the Peer_1 is in mode LEECH.
図1に示すように、ポイント（a）からP2Pストリーミングセッションを開始し、クライアントメディアプレーヤーが目的のコンテンツを参照して（図のローカルPeer_1に）要求するか、以前に開始したコンテンツを再開します。ストリーム、ただしポイント（b）から開始。この例では、Peer_1はモードLEECHです。
At point (a) in Figure 1, the Client Media Player accesses the portal and selects the content of interest. The portal returns the Media Presentation Description (MPD) file that includes information about the address of one or more trackers (which can be grouped by tiers of priority) that control the swarm x for that media content (e.g., content x).
図1のポイント（a）で、Client Media Playerはポータルにアクセスし、関心のあるコンテンツを選択します。ポータルは、そのメディアコンテンツ（コンテンツxなど）のスウォームxを制御する1つ以上のトラッカー（優先度の階層によってグループ化できる）のアドレスに関する情報を含むMedia Presentation Description（MPD）ファイルを返します。
With the information from the MPD, the Client Media Player is able to trigger the start of the streaming session, requesting to the local Peer_1 the chunks of interest.
MPDからの情報を使用して、クライアントメディアプレーヤーはストリーミングセッションの開始をトリガーし、対象のチャンクをローカルのPeer_1に要求できます。
The PPSP streaming session is then started (or resumed) at Peer_1 by sending a PPSTP CONNECT message to the tracker in order to join swarm x. The tracker will then return the OK response message containing a peer list, if the CONNECT message is successfully accepted. From that point, every chunk request is addressed by Peer_1 to its neighbors (Peer_2 in Figure 1) using a peer protocol, e.g., [RFC7574], returning the received chunks to the Client Media Player.
次に、PPSPストリーミングセッションがPeer_1で開始（または再開）され、群れxに参加するためにPPSTP CONNECTメッセージがトラッカーに送信されます。 CONNECTメッセージが正常に受け入れられると、トラッカーはピアリストを含むOK応答メッセージを返します。その時点から、ピアプロトコル（[RFC7574]など）を使用して、すべてのチャンク要求がPeer_1によってネイバー（図1のPeer_2）に送信され、受信したチャンクがクライアントメディアプレーヤーに返されます。
Once connected, Peer_1 needs to periodically report its status and statistics data to the tracker using a STAT_REPORT message.
接続されると、Peer_1は、STAT_REPORTメッセージを使用して、そのステータスと統計データを定期的にトラッカーに報告する必要があります。
If Peer_1 needs to refresh its neighborhood (for example, due to churn), it will send a PPSTP FIND message (with the desired scope) to the tracker.
Peer_1が近傍を更新する必要がある場合（たとえば、チャーンが原因で）、それはPPSTP FINDメッセージ（目的のスコープ）をトラッカーに送信します。
Peers that are only SEEDERs (i.e., serving content to other peers), as are the typical cases of service provider P2P edge caches and/or media servers, trigger their P2P streaming sessions for content x, y, z... (Figure 2), not from Media Player signals, but from some "Start" activation signal received from the service provider provisioning mechanism. In this particular case, the peer starts or resumes all its streaming sessions just by sending a PPSTP CONNECT message to the tracker (Figure 2), in order to "join" all the requested swarms.
SEEDERのみのピア（つまり、コンテンツを他のピアに提供する）は、サービスプロバイダーのP2Pエッジキャッシュやメディアサーバーの一般的なケースと同様に、コンテンツx、y、zのP2Pストリーミングセッションをトリガーします（図2 ）、Media Player信号からではなく、サービスプロバイダーのプロビジョニングメカニズムから受信した「開始」アクティベーション信号から。この特定のケースでは、要求されたすべてのスウォームに「参加」するために、PPSTP CONNECTメッセージをトラッカーに送信するだけで（図2）、ピアはすべてのストリーミングセッションを開始または再開します。
Periodically, the peer also reports its status and statistics data to the tracker using a PPSTP STAT_REPORT message.
定期的に、ピアはPPSTP STAT_REPORTメッセージを使用して、そのステータスと統計データをトラッカーに報告します。
+---------+ +---------+
| SEEDER | | Tracker |
+---------+ +---------+
| |
Start->|--CONNECT (join x,y,z)-------->|
|<--------------------------OK--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
Figure 2: A Typical PPSP Session for a Streaming SEEDER
図2：ストリーミングSEEDERの一般的なPPSPセッション
The specification of the mechanisms used by the Client Media Player (or provisioning process) and the peer to signal start/resume of streams, request media chunks, and obtain a peer ID, security certificates, or tokens is not in the scope of this document.
ストリームの開始/再開を通知し、メディアチャンクを要求し、ピアID、セキュリティ証明書、またはトークンを取得するためにクライアントメディアプレーヤー（またはプロビジョニングプロセス）およびピアが使用するメカニズムの仕様は、このドキュメントの範囲外です。
PPSTP is designed with a layered approach i.e., a PPSTP Request/Response layer, a Message layer, and a Transport layer (see Figure 3).
PPSTPは、PPSTPリクエスト/レスポンスレイヤー、メッセージレイヤー、トランスポートレイヤーなどのレイヤードアプローチで設計されています（図3を参照）。
+------------------------+
| Application |
+------------------------+
|(PPSTP) Request/Response|
|------------------------|
| (HTTP) Message |
+------------------------+
| Transport |
+------------------------+
Figure 3: Abstract Layering of PPSTP
図3：PPSTPの抽象レイヤー
The PPSTP Request/Response layer deals with the interactions between tracker and peers using request and response messages.
PPSTP要求/応答層は、要求メッセージと応答メッセージを使用して、トラッカーとピア間の対話を処理します。
The Message layer deals with the framing format for encoding and transmitting data through the underlying transport protocol, as well as the asynchronous nature of the interactions between tracker and peers.
メッセージ層は、基盤となるトランスポートプロトコルを介してデータをエンコードおよび送信するためのフレーミングフォーマット、およびトラッカーとピア間の相互作用の非同期性を扱います。
The Transport layer is responsible for the actual transmission of requests and responses over network transports, including the determination of the connection to use for a request or response message when using TCP or Transport Layer Security (TLS) [RFC5246] over it.
トランスポート層は、TCPまたはトランスポート層セキュリティ（TLS）[RFC5246]を使用するときに要求または応答メッセージに使用する接続の決定を含む、ネットワークトランスポートを介した要求と応答の実際の送信を担当します。
The messaging model of PPSTP aligns with HTTP, which is currently in version 1.1 [RFC7230], and the semantics of its messages. PPSTP is intended to also support future versions of HTTP.
PPSTPのメッセージングモデルは、現在バージョン1.1 [RFC7230]にあるHTTPとそのメッセージのセマンティクスに対応しています。 PPSTPは、HTTPの将来のバージョンもサポートすることを目的としています。
PPSTP uses a design like REST (Representational State Transfer) with the goal of leveraging current HTTP implementations and infrastructure, as well as familiarity with existing REST-like services in popular use. PPSTP messages use the UTF-8 character set [RFC3629] and are either requests from peers to a tracker service or responses from a tracker service to peers. The request and response semantics are carried as entities (header and body) in messages that correspond to either HTTP request methods or HTTP response codes, respectively.
PPSTPは、REST（Representational State Transfer）のようなデザインを使用して、現在のHTTP実装とインフラストラクチャを活用すること、および一般的に使用されている既存のRESTのようなサービスに精通していることを目標としています。 PPSTPメッセージはUTF-8文字セット[RFC3629]を使用し、ピアからトラッカーサービスへの要求、またはトラッカーサービスからピアへの応答のいずれかです。要求と応答のセマンティクスは、HTTP要求メソッドまたはHTTP応答コードにそれぞれ対応するメッセージのエンティティ（ヘッダーと本文）として伝達されます。
PPSTP uses the HTTP POST method to send parameters in requests. PPSTP messages use JavaScript Object Notation (JSON) [RFC7159] to encode message bodies.
PPSTPは、HTTP POSTメソッドを使用して、要求でパラメーターを送信します。 PPSTPメッセージは、JavaScript Object Notation（JSON）[RFC7159]を使用してメッセージ本文をエンコードします。
Peers send requests to trackers. Trackers send a single response for each request though both requests and responses can be subject to fragmentation of messages in transport.
ピアはトラッカーにリクエストを送信します。トラッカーは要求ごとに単一の応答を送信しますが、要求と応答の両方が転送中のメッセージの断片化の影響を受ける可能性があります。
The request messages of the base protocol are listed in Table 1:
基本プロトコルの要求メッセージを表1に示します。
+------------------------------+
| PPSTP Request Messages |
+------------------------------+
| CONNECT |
| FIND |
| STAT_REPORT |
+------------------------------+
Table 1: Request Messages
表1：リクエストメッセージ
CONNECT: This request message is used when a peer registers in the tracker to notify it about participation in the named swarm(s). If the peer is already registered in the tracker, this request message simply notifies the tracker about participation in the named swarm(s). The tracker records the peer ID, connect-time (referenced to the absolute time), peer IP addresses (and associated location information), link status, and peer mode for the named swarm(s). The tracker also changes the content availability of the valid named swarm(s), i.e., changes the peer's lists of the corresponding swarm(s) for the requesting peer ID. On receiving a CONNECT message, the tracker first checks the peer mode type (SEEDER/LEECH) for the specified swarm(s) and then decides the next steps (see Section 4.1 for more details).
CONNECT：この要求メッセージは、ピアがトラッカーに登録され、名前付きの群への参加について通知するときに使用されます。ピアがトラッカーにすでに登録されている場合、この要求メッセージは、指定された群に参加することをトラッカーに通知するだけです。トラッカーは、ピアID、接続時間（絶対時間を基準）、ピアIPアドレス（および関連する位置情報）、リンクステータス、および指定された群のピアモードを記録します。トラッカーは、有効な名前付きスウォームのコンテンツの可用性も変更します。つまり、要求元のピアIDに対応するスウォームのピアリストを変更します。トラッカーは、CONNECTメッセージを受信すると、まずピアモードタイプ（SEEDER / LEECH）をチェックして、指定された群れを探し、次に次のステップを決定します（詳細については、セクション4.1を参照）。
FIND: This request message is used by peers to request a list of peers active in the named swarm from the tracker whenever needed. On receiving a FIND message, the tracker finds the peers listed in the content status of the specified swarm that can satisfy the requesting peer's requirements and returns the list to the requesting peer. To create the peer list, the tracker may take peer status, capabilities, and peer priority into consideration. Peer priority may be determined by network topology preference, operator policy preference, etc.
FIND：この要求メッセージは、必要なときにいつでも、トラッカーから名前付きスウォームでアクティブなピアのリストを要求するためにピアによって使用されます。 FINDメッセージを受信すると、トラッカーは、要求側ピアの要件を満たすことができる、指定されたスウォームのコンテンツステータスにリストされているピアを見つけ、リストを要求側ピアに返します。ピアリストを作成するために、トラッカーはピアステータス、機能、およびピアプライオリティを考慮に入れることができます。ピアの優先順位は、ネットワークトポロジーの優先順位、オペレーターのポリシーの優先順位などによって決定されます。
STAT_REPORT: This request message is used to allow an active peer to send status (and optionally statistic data) to the tracker to signal continuing activity. This request message MUST be sent periodically to the tracker while the peer is active in the system.
STAT_REPORT：この要求メッセージは、アクティブなピアがステータス（およびオプションで統計データ）をトラッカーに送信して、継続的なアクティビティを通知できるようにするために使用されます。この要求メッセージは、ピアがシステムでアクティブな間、定期的にトラッカーに送信する必要があります。
The state machine for the tracker is very simple, as shown in Figure 4. Peer ID registrations represent a dynamic piece of state maintained by the network.
図4に示すように、トラッカーのステートマシンは非常に単純です。ピアIDの登録は、ネットワークによって維持される動的な状態の一部です。
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) \- (start tracker)
Figure 4: Tracker State Machine
図4：トラッカーステートマシン
When there are no peers connected in the tracker, the state machine is in INIT state.
トラッカーに接続されているピアがない場合、ステートマシンはINIT状態です。
When the first peer connects to register with its peer ID, the state machine moves from INIT to STARTED. As long as there is at least one active registration of a peer ID, the state machine remains in STARTED state. When the last peer ID is removed, the state machine transitions to TERMINATED. From there, it immediately transitions back to INIT state. Because of this, TERMINATED state is transient.
最初のピアが接続してピアIDに登録すると、ステートマシンはINITからSTARTEDに移行します。ピアIDのアクティブな登録が少なくとも1つある限り、状態マシンはSTARTED状態のままです。最後のピアIDが削除されると、状態マシンはTERMINATEDに移行します。そこから、すぐにINIT状態に戻ります。このため、TERMINATED状態は一時的なものです。
Once in STARTED state, each peer is instantiated (per peer ID) in the tracker state machine with a dedicated transaction state machine (Figure 5), which is deleted when the peer ID is removed.
STARTED状態になると、各ピアはトラッカーステートマシンで（ピアIDごとに）専用のトランザクションステートマシン（図5）でインスタンス化され、ピアIDが削除されると削除されます。
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) | (1) \- (start tracker)
V
+-----------+ +-------+ rcv CONNECT
(Transient) | TERMINATE | | START | --------------- (1)
+-----------+ +-------+ strt init timer
rcv FIND (B) ^ |
rcv STAT_REPORT (B) | |
on registration error (B)| v
on action error (A) | +------------+
---------------- +<--| PEER | (Transient)
stop init timer | | REGISTERED |
snd error | +------------+
| |
on timeout (D) | | process swarm actions
---------------- | | --------------------- (2)
stop track timer | | snd OK (PeerList)
clean peer info | / stop init timer
del registration | / strt track timer
| /
| |
| | rcv FIND
STAT_REPORT ERR(C) \ | ---- --------------- (3)
FIND ERR(C) ---- \ | / \ snd OK (PeerList)
CONNECT ERR(C) / \ | | | | rst track timer
rcv CONNECT | (4) | | | | |
----------- | v | v v | rcv STAT_REPORT
snd OK \ +==============+ / --------------- (3)
rst track timer ----| TRACKING |---- snd OK response
snd error (C) +==============+ rst track timer
Figure 5: "Per-Peer-ID" State Machine and Flow Diagram
図5：「Per-Peer-ID」ステートマシンとフロー図
Unlike the tracker state machine, which exists even when no peer IDs are registered, the "per-Peer-ID" State Machine is instantiated only when the peer ID starts registration in the tracker and is deleted when the peer ID is de-registered/removed. This allows for an implementation optimization whereby the tracker can destroy the objects associated with the "per-Peer-ID" State Machine once it enters the TERMINATE state (Figure 5).
ピアIDが登録されていない場合でも存在するトラッカーステートマシンとは異なり、「ピアIDごと」のステートマシンは、ピアIDがトラッカーへの登録を開始したときにのみインスタンス化され、ピアIDが登録解除されたときに削除されます/削除されました。これにより、実装の最適化が可能になります。これにより、トラッカーがTERMINATE状態に入ると、「ピアIDごと」の状態マシンに関連付けられたオブジェクトを破棄できます（図5）。
When a new peer ID is added, the corresponding "per-Peer-ID" State Machine is instantiated, and it moves into the PEER REGISTERED state. Because of that, the START state here is transient.
新しいピアIDが追加されると、対応する「per-Peer-ID」状態マシンがインスタンス化され、PEER REGISTERED状態に移行します。そのため、ここでのSTART状態は一時的なものです。
When the peer ID is no longer bound to a registration, the "per-Peer-ID" State Machine moves to the TERMINATE state, and the state machine is destroyed.
ピアIDが登録にバインドされなくなると、「per-Peer-ID」状態マシンはTERMINATE状態に移行し、状態マシンは破棄されます。
During the lifetime of streaming activity of a peer, the instantiated "per-Peer-ID" State Machine progresses from one state to another in response to various events. The events that may potentially advance the state include:
ピアのストリーミングアクティビティの存続期間中、インスタンス化された「ピアIDごと」のステートマシンは、さまざまなイベントに応じて、ある状態から別の状態に進みます。状態を進める可能性のあるイベントには、次のものがあります。
o Reception of CONNECT, FIND, and STAT_REPORT messages
o CONNECT、FIND、およびSTAT_REPORTメッセージの受信
o Timeout events
o タイムアウトイベント
The state diagram in Figure 5 illustrates state changes, together with the causing events and resulting actions. Specific error conditions are not shown in the state diagram.
図5の状態図は、原因となるイベントと結果のアクションと共に、状態の変化を示しています。特定のエラー状態は、状態図には示されていません。
For normal operation, the process consists of the following steps:
通常の操作では、プロセスは次のステップで構成されます。
1) When a peer wants to access the system, it needs to register with a tracker by sending a CONNECT message asking for the swarm(s) it wants to join. This request from a new peer ID triggers the instantiation in the tracker of a "per-Peer-ID" State Machine. In the START state of the new "per-Peer-ID" State Machine, the tracker registers the peer ID and associated information (IP addresses), starts the "init timer", and moves to PEER REGISTERED state.
1）ピアがシステムにアクセスする場合、参加したい群れを要求するCONNECTメッセージを送信して、トラッカーに登録する必要があります。新しいピアIDからのこの要求は、「ピアIDごと」の状態マシンのトラッカーでインスタンス化をトリガーします。新しい「ピアIDごと」の状態マシンのSTART状態では、トラッカーはピアIDと関連情報（IPアドレス）を登録し、「初期タイマー」を開始して、PEER REGISTERED状態に移行します。
2) In PEER REGISTERED state, if the peer ID is valid, the tracker either:
2）PEER REGISTERED状態で、ピアIDが有効な場合、トラッカーは次のいずれかを行います。
a) processes the requested action(s) for the valid swarm information contained in the CONNECT requests, and if successful, the tracker stops the "init timer", starts the "track timer", and sends the response to the peer (the response may contain the appropriate list of peers for the joining swarm(s), as detailed in Section 4.1), or
a) CONNECTリクエストに含まれる有効なスウォーム情報に対してリクエストされたアクションを処理し、成功した場合、トラッカーは「初期タイマー」を停止し、「トラックタイマー」を開始して、ピアに応答を送信します（応答にはセクション4.1に詳述されているように、参加する群れのピアの適切なリスト、または
b) moves the valid FIND request to TRACKING state.
b) 有効なFIND要求をTRACKING状態に移行します。
3) In TRACKING state, STAT_REPORT or FIND messages received from that peer ID will reset the "track timer", and the tracker responds to the requests with the following, respectively: a) a successful condition, or
3）TRACKING状態では、そのピアIDから受信したSTAT_REPORTまたはFINDメッセージが「追跡タイマー」をリセットし、トラッカーはそれぞれ次のように要求に応答します。a）成功した状態、または
b) a successful condition containing the appropriate list of peers for the named swarm (Section 4.2).
b) 指定されたスウォームの適切なピアのリストを含む成功した状態（セクション4.2）。
4) While in TRACKING state, a CONNECT message received from that peer ID with valid swarm action information (Section 4.1.1) resets the "track timer", and the tracker responds to the request with a successful condition.
4）TRACKING状態の間に、有効なスウォームアクション情報（セクション4.1.1）とともにそのピアIDから受信したCONNECTメッセージが「トラックタイマー」をリセットし、トラッカーは成功した状態で要求に応答します。
Peers are required not to generate protocol elements that are invalid. However, several situations may lead to abnormal conditions in the interaction with the tracker. These situations may be related to peer malfunction or communication errors. The tracker reacts to these abnormal situations depending on its current state related to a peer ID, as follows:
ピアは、無効なプロトコル要素を生成しないようにする必要があります。ただし、いくつかの状況では、トラッカーとの対話で異常な状態が発生する可能性があります。これらの状況は、ピアの誤動作または通信エラーに関連している可能性があります。トラッカーは、次のように、ピアIDに関連する現在の状態に応じて、これらの異常な状況に反応します。
A) In PEER REGISTERED state, when a CONNECT request only contains invalid swarm actions (Section 4.1.1), the tracker responds with a PPSTP error code as specified in Section 4.3, deletes the registration, and transitions to TERMINATE state for that peer ID. The state machine is destroyed.
A）PEER REGISTERED状態で、CONNECTリクエストに無効なスウォームアクションのみが含まれている場合（セクション4.1.1）、トラッカーはセクション4.3で指定されたPPSTPエラーコードで応答し、登録を削除して、そのピアIDのTERMINATE状態に移行します。ステートマシンは破壊されます。
B) In PEER REGISTERED state, if the peer ID is considered invalid (in the case of a CONNECT request or in the case of FIND or STAT_REPORT requests received from an unregistered peer ID), the tracker responds with either a 06 (Authentication Required) error_code or a 03 (Forbidden Action) error_code as described in Section 4.3 and transitions to TERMINATE state for that peer ID. The state machine is destroyed.
B）PEER REGISTERED状態で、ピアIDが無効と見なされた場合（CONNECT要求の場合、または未登録のピアIDから受信したFINDまたはSTAT_REPORT要求の場合）、トラッカーは06（認証が必要）のいずれかで応答します。セクション4.3で説明されているerror_codeまたは03（禁止アクション）error_codeと、そのピアIDのTERMINATE状態への遷移。ステートマシンは破壊されます。
C) In TRACKING state (while the "track timer" has not expired), receiving a CONNECT message from a peer ID with invalid swarm actions (Section 4.1.1) or receiving a FIND/STAT_REPORT message from a peer ID with an invalid swarm ID is considered an error condition. The tracker responds with the corresponding error code (described in Section 4.3).
C）TRACKING状態（「トラックタイマー」の期限が切れていない間）で、無効なスウォームアクションのあるピアIDからCONNECTメッセージを受信する（セクション4.1.1）、または無効なスウォームのあるピアIDからFIND / STAT_REPORTメッセージを受信するIDはエラー状態と見なされます。トラッカーは、対応するエラーコード（セクション4.3で説明）で応答します。
D) In TRACKING state, without receiving messages from the peer on timeout (the "track timer" has expired), the tracker cleans all the information associated with the peer ID in all swarms it was joined, deletes the registration, and transitions to TERMINATE state for that peer ID. The state machine is destroyed.
D）TRACKING状態では、タイムアウト時にピアからメッセージを受信せずに（「トラックタイマー」の期限が切れています）、トラッカーは、参加したすべての群れのピアIDに関連付けられたすべての情報を消去し、登録を削除して、TERMINATEに移行しますそのピアIDの状態。ステートマシンは破壊されます。
NOTE: These situations may correspond to malfunctions at the peer or to malicious conditions. As a preventive measure, the tracker proceeds to TERMINATE state for that peer ID.
注：これらの状況は、ピアの誤動作または悪意のある状態に対応している可能性があります。予防策として、トラッカーはそのピアIDのTERMINATE状態に進みます。
PPSTP uses a REST-like design, encoding the requests and responses using JSON [RFC7159]. For a generalization of the definition of protocol elements and fields, as well as their types and structures, this document uses a C-style notation, similar to the presentation language used to define TLS [RFC5246].
PPSTPはRESTのような設計を使用し、JSON [RFC7159]を使用して要求と応答をエンコードします。プロトコル要素とフィールド、およびそれらのタイプと構造の定義を一般化するために、このドキュメントではTLS [RFC5246]の定義に使用されるプレゼンテーション言語と同様に、Cスタイルの表記法を使用しています。
A JSON object consists of name/value pairs with the grammar specified in [RFC7159]. In this document, comments begin with "//", and the "ppsp_tp_string_t" and "ppsp_tp_integer_t" types are used to indicate the JSON string and number, respectively. Optional fields are enclosed in "[ ]" brackets. An array is indicated by two numbers in angle brackets, <min..max>, where "min" indicates the minimal number of values and "max" the maximum. An "*" is used to denote a no upper-bound value for "max".
JSONオブジェクトは、[RFC7159]で指定された文法を持つ名前と値のペアで構成されます。このドキュメントでは、コメントは「//」で始まり、「ppsp_tp_string_t」タイプと「ppsp_tp_integer_t」タイプは、それぞれJSON文字列と数値を示すために使用されます。オプションのフィールドは「[]」の角括弧で囲まれています。配列は山かっこで囲まれた2つの数値<min..max>で示されます。「min」は値の最小数を示し、「max」は最大値を示します。 「*」は、「max」の上限値がないことを示すために使用されます。
This section details the format of PPSTP resource element types.
このセクションでは、PPSTPリソース要素タイプの形式について詳しく説明します。
For both requests and responses, the version of PPSTP being used MUST be indicated by the attribute version, defined as follows:
要求と応答の両方で、使用されているPPSTPのバージョンは、次のように定義された属性versionで示す必要があります。
ppsp_tp_integer_t ppsp_tp_version_t = 1
ppsp_tp_integer_t ppsp_tp_version_t = 1
The defined value for ppsp_tp_version_t is listed in Table 2.
ppsp_tp_version_tの定義値を表2に示します。
+----------------------------------------------------------+
| ppsp_tp_version_t | Description |
+----------------------------------------------------------+
| 0 | Reserved |
| 1 | PPSTP version 1 |
| 2-255 | Unassigned |
+----------------------------------------------------------+
Table 2: PPSTP Version Numbers
表2：PPSTPバージョン番号
The peer number element is a scope selector optionally present in CONNECT and FIND requests.
ピア番号要素は、CONNECTおよびFIND要求にオプションで存在するスコープセレクターです。
This element contains the attribute peer_count to indicate the maximum number of peers in the returned peer list. peer_count should be less than 30 in this specification. The other 4 attributes, i.e., ability_nat, concurrent_links, online_time, and upload_bandwidth may also be contained in this element to inform the tracker the status of the peer so that the tracker could return some eligible peers based on the implementing rules set by the service providers:
この要素には、返されたピアリスト内のピアの最大数を示す属性peer_countが含まれています。この仕様では、peer_countは30未満である必要があります。他の4つの属性（つまり、ability_nat、concurrent_links、online_time、upload_bandwidth）もこの要素に含めることができ、ピアのステータスをトラッカーに通知して、サービスプロバイダーが設定した実装ルールに基づいて適格なピアをトラッカーが返すことができるようにします。 ：
o ability_nat is used to indicate the preferred NAT traversal situation of the requesting peer.
o capability_natは、要求側ピアの優先NATトラバーサル状況を示すために使用されます。
o concurrent_links means the number of P2P links the peer currently has.
o concurrent_linksは、ピアが現在持っているP2Pリンクの数を意味します。
o online_time represents online duration time of the peer. The unit is second.
o online_timeは、ピアのオンライン継続時間を表します。単位は秒です。
o upload_bandwidth is the maximum upload bandwidth capability of the peer. The unit is Kbps.
o upload_bandwidthは、ピアの最大アップロード帯域幅機能です。単位はKbpsです。
The scope selector element and its attributes are defined as follows:
スコープセレクター要素とその属性は、次のように定義されます。
Object {
ppsp_tp_integer_t peer_count;
[ppsp_tp_string_t ability_nat = "NO_NAT"
| "STUN"
| "TURN";]
[ppsp_tp_integer_t concurrent_links;]
[ppsp_tp_integer_t online_time;]
[ppsp_tp_integer_t upload_bandwidth;]
} ppsp_tp_peer_num_t;
The swarm action element identifies the action(s) to be taken in the named swarm(s) as well as the corresponding peer mode (if the peer is LEECH or SEEDER in that swarm).
swarm action要素は、指定されたswarmで実行されるアクションと、対応するピアモード（ピアがそのswarmでLEECHまたはSEEDERの場合）を識別します。
Object {
ppsp_tp_string_t swarm_id; //swarm ID
ppsp_tp_string_t action = "JOIN"
|"LEAVE"; // Action type of
// the CONNECT
// message
ppsp_tp_string_t peer_mode = "SEEDER"
| "LEECH"; // Mode of the peer
// participating
// in this swarm
} ppsp_tp_swarm_action_t;
The peer information elements provide network identification information of peers. A peer information element consists of a peer identifier and the IP-related addressing information.
ピア情報要素は、ピアのネットワーク識別情報を提供します。ピア情報要素は、ピア識別子とIP関連のアドレス情報で構成されます。
Object {
ppsp_tp_string_t peer_id;
ppsp_tp_peer_addr_t peer_addr;
} ppsp_tp_peer_info_t;
The ppsp_tp_peer_addr_t element includes the IP address and port, with a few optional attributes related to connection type and network location (in terms of ASN) as well as, optionally, the identifier of the peer protocol being used.
ppsp_tp_peer_addr_t要素には、IPアドレスとポート、接続タイプとネットワークの場所（ASNの観点から）に関連するいくつかのオプション属性、およびオプションで、使用されているピアプロトコルの識別子が含まれます。
Object {
ppsp_tp_ip_address ip_address;
ppsp_tp_integer_t port;
ppsp_tp_integer_t priority;
ppsp_tp_string_t type = "HOST"
| "REFLEXIVE"
| "PROXY";
[ppsp_tp_string_t connection = "wireless"
| "wired";]
[ppsp_tp_string_t asn;]
[ppsp_tp_string_t peer_protocol;]
} ppsp_tp_peer_addr_t;
The semantics of ppsp_tp_peer_addr_t attributes are listed in Table 3:
ppsp_tp_peer_addr_t属性のセマンティクスを表3に示します。
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| ip_address | IP address information |
| port | IP service port value |
| priority | The priority of this interface. |
| | It may be determined by network |
| | topology preference, operator |
| | policy preference, etc. How to |
| | create a priority is outside of |
| | the scope. The larger the value,|
| | the higher the priority. |
| type | Describes the address for NAT |
| | traversal, which can be HOST |
| | REFLEXIVE or PROXY |
| connection | Access type (wireless or wired) |
| asn | Autonomous System Number |
| peer_protocol | Peer-to-Peer Streaming Peer |
| | Protocol (PPSPP) supported |
+----------------------+----------------------------------+
Table 3: Semantics of ppsp_tp_peer_addr_t
表3：ppsp_tp_peer_addr_tのセマンティクス
In this document, IP address is specified as ppsp_tp_addr_value. The exact characters and format depend on address_type:
このドキュメントでは、IPアドレスはppsp_tp_addr_valueとして指定されています。正確な文字と形式は、address_typeによって異なります。
o The IPv4 address is encoded as specified by the "IPv4address" rule in Section 3.2.2 of [RFC3986].
o IPv4アドレスは、[RFC3986]のセクション3.2.2の「IPv4address」ルールで指定されているようにエンコードされます。
o The IPv6 address is encoded as specified in Section 4 of [RFC5952].
o IPv6アドレスは、[RFC5952]のセクション4で指定されているようにエンコードされます。
Object {
ppsp_tp_string_t address_type;
ppsp_tp_addr_value address;
} ppsp_tp_ip_address;
The peer information in responses is grouped in a ppsp_tp_peer_group_t element:
応答のピア情報は、ppsp_tp_peer_group_t要素にグループ化されています。
Object {
ppsp_tp_peer_info_t peer_info<1..*>;
} ppsp_tp_peer_group_t;
The statistics element (stat) is used to describe several properties relevant to the P2P network. These properties can be related to stream statistics and peer status information. Each stat element will correspond to a property type, and several stat blocks can be reported in a single STAT_REPORT message, corresponding to some or all the swarms the peer is actively involved. This specification only defines the property type "STREAM_STATS".
統計要素（stat）は、P2Pネットワークに関連するいくつかのプロパティを記述するために使用されます。これらのプロパティは、ストリーム統計およびピアステータス情報に関連付けることができます。各stat要素はプロパティタイプに対応し、ピアがアクティブに関与している一部またはすべての群に対応する単一のSTAT_REPORTメッセージでいくつかのstatブロックを報告できます。この仕様では、プロパティタイプ「STREAM_STATS」のみを定義しています。
The definition of the statistic element and attributes is as follows:
統計要素と属性の定義は次のとおりです。
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_integer_t uploaded_bytes;
ppsp_tp_integer_t downloaded_bytes;
ppsp_tp_integer_t available_bandwidth;
ppsp_tp_integer_t concurrent_links;
} stream_stats;
The semantics of stream_stats attributes are listed in Table 4:
stream_stats属性のセマンティクスを表4に示します。
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| swarm_id | Swarm ID |
| uploaded_bytes | Bytes sent to swarm |
| downloaded_bytes | Bytes received from swarm |
| available_bandwidth | Available instantaneous upload |
| | bandwidth |
| concurrent_links | Number of concurrent links |
+----------------------+----------------------------------+
Table 4: Semantics of stream_stats
表4：stream_statsのセマンティクス
The stat information is grouped in the ppsp_tp_stat_group_t element:
統計情報は、ppsp_tp_stat_group_t要素にグループ化されています。
Object {
ppsp_tp_string_t type = "STREAM_STATS"; // property type
stream_stats stat<1..*>;
} ppsp_tp_stat_group_t
Other properties may be defined, related, for example, to incentives and reputation mechanisms like "peer online time" or connectivity conditions like physical "link status", etc.
たとえば、「ピアオンライン時間」などのインセンティブや評判メカニズム、または物理的な「リンクステータス」などの接続条件に関連して、他のプロパティを定義できます。
For that purpose, the stat element may be extended to provide additional specific information for new properties, elements, or attributes (see the guidelines in Section 7).
そのために、stat要素を拡張して、新しいプロパティ、要素、または属性に関する追加の特定の情報を提供できます（セクション7のガイドラインを参照）。
This section defines the structure of PPSTP requests and responses.
このセクションでは、PPSTP要求と応答の構造を定義します。
The request type includes CONNECT, FIND, and STAT_REPORT, defined as follows:
要求タイプには、次のように定義されたCONNECT、FIND、およびSTAT_REPORTが含まれます。
ppsp_tp_string_t ppsp_tp_request_type_t = "CONNECT" | "FIND" | "STAT_REPORT";
ppsp_tp_string_t ppsp_tp_request_type_t = "接続" | 「検索」| "STAT_REPORT";
Response type corresponds to the response method type of the message, defined as follows:
応答タイプは、メッセージの応答メソッドタイプに対応し、次のように定義されます。
JSONValue ppsp_tp_response_type_t = 0x00 // SUCCESSFUL
| 0x01; // FAILED
The request element MUST be present in requests and corresponds to the request method type for the message.
リクエスト要素はリクエストに存在する必要があり、メッセージのリクエストメソッドタイプに対応します。
The generic definition of a request element is as follows:
request要素の一般的な定義は次のとおりです。
Object {
[ppsp_tp_peer_num_t peer_num;]
[ppsp_tp_peer_addr_t peer_addr<1..*>;]
ppsp_tp_swarm_action_t swarm_action<1..*>;
} ppsp_tp_request_connect;
Object {
ppsp_tp_string_t swarm_id;
[ppsp_tp_peer_num_t peer_num;]
} ppsp_tp_request_find;
Object {
ppsp_tp_version_t version;
ppsp_tp_request_type_t request_type;
ppsp_tp_string_t transaction_id;
ppsp_tp_string_t peer_id;
JSONValue request_data = ppsp_tp_req_connect connect
| ppsp_tp_req_find find
| ppsp_tp_stat_group_t stat_report;
} ppsp_tp_request;
A request element consists of the version of PPSTP, the request type, a transaction ID, the requesting peer ID, and requesting body (i.e., request_data). The request_data MUST be correctly set to the corresponding element based on the request type (see Table 5).
要求要素は、PPSTPのバージョン、要求タイプ、トランザクションID、要求元のピアID、および要求元（つまり、request_data）で構成されます。 request_dataは、リクエストタイプに基づいて対応する要素に正しく設定する必要があります（表5を参照）。
+----------------------+----------------------+
| request_type | request_data |
+----------------------+----------------------+
| "CONNECT" | "connect" |
| "FIND" | "find" |
| "STAT_REPORT" | "stat_report" |
+----------------------+----------------------+
Table 5: The Relationship between request_type and request_data
表5：request_typeとrequest_dataの関係
The generic definition of a response element is as follows:
応答要素の一般的な定義は次のとおりです。
Object {
ppsp_tp_version_t version;
ppsp_tp_response_type_t response_type;
ppsp_tp_integer_t error_code;
ppsp_tp_string_t transaction_id;
[ppsp_tp_peer_addr_t peer_addr;]
[ppsp_tp_swarm_action_result_t swarm_result<1..*>;]
} ppsp_tp_response;
A response element consists of the version of PPSTP, the response type, the error code, a transaction ID, and optionally the public address of the requesting peer and one or multiple swarm action result elements. Normally, swarm action result elements SHOULD be present and error_code MUST be set to 00 (No Error) when response_type is 0x00. Swarm action result elements SHOULD NOT be set when error_code is 01 (Bad Request). Detailed selection of error_code is introduced in Section 4.3.
応答要素は、PPSTPのバージョン、応答タイプ、エラーコード、トランザクションID、およびオプションで要求元ピアのパブリックアドレスと1つまたは複数のスウォームアクション結果要素で構成されます。通常、swarmアクションの結果要素は存在する必要があり（SHOULD）、response_typeが0x00の場合はerror_codeを00（エラーなし）に設定する必要があります。 Swarmアクションの結果要素は、error_codeが01（Bad Request）の場合は設定しないでください。 error_codeの詳細な選択は、セクション4.3で紹介されています。
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_response_type_t result;
[ppsp_tp_peer_group_t peer_group;]
} ppsp_tp_swarm_action_result_t;
A swarm action result element represents the result of an action requested by the peer. It contains a swarm identifier that globally indicates the swarm, the result for the peer of this action (which could be CONNECT ("JOIN" or "LEAVE"), FIND, or STAT_REPORT), and optionally one peer group element. The attribute result indicates the operation result of the corresponding request. When the response element corresponds to the STAT_REPORT request or the result attribute is set to 0x01, the peer group element SHOULD NOT be set.
群れアクション結果要素は、ピアによって要求されたアクションの結果を表します。これには、スウォーム、このアクションのピアの結果（CONNECT（ "JOIN"または "LEAVE"）、FIND、またはSTAT_REPORT）をグローバルに示すスウォームID、およびオプションで1つのピアグループ要素が含まれます。属性resultは、対応するリクエストの操作結果を示します。応答要素がSTAT_REPORT要求に対応するか、結果属性が0x01に設定されている場合、ピアグループ要素は設定されるべきではありません（SHOULD NOT）。
PPSTP messages (requests or responses) are designed to have a similar structure with a root field named "PPSPTrackerProtocol" containing meta information and data pertaining to a request or a response.
PPSTPメッセージ（要求または応答）は、要求または応答に関連するメタ情報とデータを含む「PPSPTrackerProtocol」という名前のルートフィールドを持つ同様の構造を持つように設計されています。
The base type of a PPSTP message is defined as follows:
PPSTPメッセージの基本タイプは次のように定義されます。
Object {
JSONValue PPSPTrackerProtocol = ppsp_tp_request Request
| ppsp_tp_response Response;
} ppsp_tp_message_root;
PPSTP is a message-oriented request/response protocol. PPSTP messages use a text type encoding in JSON [RFC7159], which MUST be indicated in the Content-Type field in HTTP/1.1 [RFC7231], specifying the "application/ppsp-tracker+json" media type for all PPSTP request parameters and responses.
PPSTPは、メッセージ指向の要求/応答プロトコルです。 PPSTPメッセージは、JSON [RFC7159]のテキストタイプエンコーディングを使用します。これは、HTTP / 1.1 [RFC7231]のContent-Typeフィールドで示される必要があり、すべてのPPSTPリクエストパラメータと反応。
Implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246].
実装は、「https」URIスキーム[RFC2818]およびトランスポート層セキュリティ（TLS）[RFC5246]をサポートする必要があります。
For deployment scenarios where peer (client) authentication is desired at the tracker, HTTP Digest Access Authentication [RFC7616] MUST be supported, with TLS Client Authentication as the preferred mechanism, if available.
トラッカーでピア（クライアント）認証が必要な展開シナリオでは、HTTPダイジェストアクセス認証[RFC7616]をサポートする必要があります（可能な場合は、優先メカニズムとしてTLSクライアント認証を使用）。
PPSTP uses the HTTP POST method to send parameters in requests to provide information resources that are the function of one or more of those input parameters. Input parameters are encoded in JSON in the HTTP entity body of the request.
PPSTPは、HTTP POSTメソッドを使用して要求にパラメーターを送信し、これらの入力パラメーターの1つ以上の機能である情報リソースを提供します。入力パラメーターは、要求のHTTPエンティティー本体のJSONでエンコードされます。
The section describes the operation of the three types of requests of PPSTP and provides some examples of usage.
このセクションでは、PPSTPの3種類の要求の操作について説明し、使用例をいくつか示します。
This method is used when a peer registers to the system and/or requests some swarm actions (join/leave). The peer MUST properly set the request type to CONNECT, generate and set the transaction_ids, set the peer_id, and include swarms the peer is interested in, followed by the corresponding action type and peer mode.
このメソッドは、ピアがシステムに登録したり、いくつかのスウォームアクション（参加/脱退）を要求したりするときに使用されます。ピアはリクエストタイプを適切にCONNECTに設定し、transaction_idsを生成して設定し、peer_idを設定し、ピアが関心を持っている群れを含め、その後に対応するアクションタイプとピアモードを含める必要があります。
o When a peer already possesses content and agrees to share it with others, it should set the action type to the value JOIN, as well as set the peer mode to SEEDER during its start (or re-start) period.
o ピアが既にコンテンツを所有しており、それを他のユーザーと共有することに同意する場合は、アクションタイプを値JOINに設定し、開始（または再起動）期間中にピアモードをSEEDERに設定する必要があります。
o When a peer makes a request to join a swarm to consume content, it should set the action type to the value JOIN, as well as set the peer mode to LEECH during its start (or re-start) period.
o ピアがコンテンツを消費するためにスウォームに参加するように要求する場合、アクションタイプを値JOINに設定し、開始（または再起動）期間中にピアモードをLEECHに設定する必要があります。
In the above cases, the peer can provide optional information on the addresses of its network interface(s), for example, the priority, type, connection, and ASN.
上記の場合、ピアは、ネットワークインターフェースのアドレスに関するオプションの情報（優先度、タイプ、接続、ASNなど）を提供できます。
When a peer plans to leave a previously joined swarm, it should set action type to LEAVE, regardless of the peer mode.
ピアが以前に参加したスウォームを離れる予定の場合、ピアモードに関係なく、アクションタイプをLEAVEに設定する必要があります。
When receiving a well-formed CONNECT request message, the tracker starts by pre-processing the peer authentication information (provided as authorization scheme and token in the HTTP message) to check whether it is valid and that it can connect to the service, then proceed to register the peer in the service and perform the swarm actions requested. If successful, a response message with a corresponding response value of SUCCESSFUL will be generated.
整形式のCONNECT要求メッセージを受信すると、トラッカーはピア認証情報（HTTPメッセージで承認スキームとトークンとして提供される）を前処理して、それが有効であり、サービスに接続できるかどうかを確認してから続行します。サービスにピアを登録し、要求されたスウォームアクションを実行します。成功すると、対応する応答値SUCCESSFULを持つ応答メッセージが生成されます。
The valid sets of the number of swarms whose action type is combined with peer mode for the CONNECT request logic are enumerated in Table 6 (referring to the "per-Peer-ID" State Machine in Section 2.3).
CONNECTリクエストロジックのアクションタイプがピアモードと組み合わされたスウォームの数の有効なセットを表6に列挙します（セクション2.3の「ピアIDごとの」ステートマシンを参照）。
+-----------+-----------+---------+----------+-----------+----------+
| Swarm | peer_mode | action | Initial | Final | Request |
| Number | Value | Value | State | State | Validity |
+-----------+-----------+---------+----------+-----------+----------|
| 1 | LEECH | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | START | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | START | TERMINATE | Invalid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | TRACKING | TRACKING | Valid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | TRACKING | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
Table 6: Validity of Action Combinations in CONNECT Requests
表6：CONNECTリクエストでのアクションの組み合わせの有効性
In the CONNECT request message, multiple swarm action elements ppsp_tp_swarm_action_t could be contained. Each of them contains the request action and the peer_mode of the peer. The peer_mode attribute MUST be set to the type of participation of the peer in the swarm (SEEDER or LEECH).
CONNECTリクエストメッセージには、複数のswarmアクション要素ppsp_tp_swarm_action_tが含まれる可能性があります。それぞれに、要求アクションとピアのpeer_modeが含まれています。 peer_mode属性は、スウォームへのピアの参加のタイプ（SEEDERまたはLEECH）に設定する必要があります。
The CONNECT message may contain multiple peer_addr elements with attributes ip_address, port, priority, and type (if Interactive Connectivity Establishment (ICE) [RFC5245] NAT traversal techniques are used), and optionally connection, asn, and peer_protocol corresponding to each of the network interfaces the peer wants to advertise.
CONNECTメッセージには、ip_address、port、priority、type（Interactive Connectivity Establishment（ICE）[RFC5245] NATトラバーサル手法が使用されている場合）の属性を持つ複数のpeer_addr要素、およびオプションで、各ネットワークに対応するconnection、asn、およびpeer_protocolが含まれる場合があります。ピアがアドバタイズするインターフェイス。
The element peer_num indicates the maximum number of peers to be returned in a list from the tracker. The returned peer list can be optionally filtered by some indicated properties, such as ability_nat for NAT traversal, and concurrent_links, online_time and upload_bandwidth for the preferred capabilities.
要素peer_numは、トラッカーからリストで返されるピアの最大数を示します。返されたピアリストは、NATトラバーサルの場合はcapability_nat、優先機能の場合はconcurrent_links、online_time、upload_bandwidthなど、指定されたプロパティによってオプションでフィルタリングできます。
The element transaction_id MUST be present in requests to uniquely identify the transaction. Responses to completed transactions use the same transaction_id as the request they correspond to.
トランザクションを一意に識別するために、要素transaction_idがリクエストに存在する必要があります。完了したトランザクションへの応答は、対応する要求と同じtransaction_idを使用します。
The response may include peer_addr data of the requesting peer public IP address. Peers can use Session Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] to gather their candidates, in which case peer_addr SHOULD NOT present in the response. If no STUN is used and the tracker is able to work as a "STUN-like" server that can inspect the public address of a peer, the tracker can return the address back with a "REFLEXIVE" attribute type. The swarm_result may also include peer_addr data corresponding to the peer IDs and public IP addresses of the selected active peers in the requested swarm. The tracker may also include the attribute asn with network location information of the transport address, corresponding to the Autonomous System Number of the access network provider of the referenced peer.
応答には、要求元のピアのパブリックIPアドレスのpeer_addrデータが含まれる場合があります。ピアは、NATのセッショントラバーサルユーティリティ（STUN）[RFC5389]およびNATを使用したリレーを使用したトラバーサル（TURN）[RFC5766]を使用して候補を収集できます。この場合、peer_addrは応答に存在しない必要があります（SHOULD NOT）。 STUNが使用されておらず、トラッカーがピアのパブリックアドレスを検査できる「STUNのような」サーバーとして機能できる場合、トラッカーは「REFLEXIVE」属性タイプでアドレスを返すことができます。 swarm_resultには、要求されたスウォーム内の選択されたアクティブピアのピアIDとパブリックIPアドレスに対応するpeer_addrデータも含まれます。トラッカーは、参照されたピアのアクセスネットワークプロバイダーの自律システム番号に対応する、トランスポートアドレスのネットワークロケーション情報とともに属性asnを含めることもできます。
If the peer_mode is SEEDER, the tracker responds with a SUCCESSFUL response and enters the peer information into the corresponding swarm activity. If the peer_mode is LEECH (or if a SEEDER includes a peer_num element in the request), the tracker will search and select an appropriate list of peers satisfying the conditions set by the requesting peer. The peer list returned MUST contain the peer IDs and the corresponding IP addresses. To create the peer list, the tracker may take peer status and network location information into consideration to express network topology preferences or operators' policy preferences with regard to the possibility of connecting with other IETF efforts such as Application-Layer Traffic Optimization (ALTO) [RFC7285].
peer_modeがSEEDERの場合、トラッカーはSUCCESSFUL応答で応答し、対応するスウォームアクティビティにピア情報を入力します。 peer_modeがLEECHの場合（またはSEEDERにリクエストにpeer_num要素が含まれている場合）、トラッカーは、リクエストしているピアによって設定された条件を満たすピアの適切なリストを検索して選択します。返されるピアリストには、ピアIDと対応するIPアドレスが含まれている必要があります。ピアリストを作成するために、トラッカーはピアステータスとネットワークロケーション情報を考慮に入れて、アプリケーションレイヤートラフィック最適化（ALTO）などの他のIETFの取り組みと接続する可能性に関して、ネットワークトポロジー設定またはオペレーターのポリシー設定を表現することができます。 RFC7285]。
IMPLEMENTATION NOTE: If no peer_num attributes are present in the request, the tracker may return a random sample from the peer population.
実装に関する注：リクエストにpeer_num属性が存在しない場合、トラッカーはピアの母集団からランダムなサンプルを返すことがあります。
The following example of a CONNECT request corresponds to a peer that wants to start (or re-start) sharing its previously streamed content (peer_mode is SEEDER).
次のCONNECT要求の例は、以前にストリーミングされたコンテンツの共有を開始（または再開）したいピアに対応します（peer_modeはSEEDER）。
POST https://tracker.example.com/video_1 HTTP/1.1
Host: tracker.example.com
Content-Length: 494
Content-Type: application/ppsp-tracker+json
Accept: application/ppsp-tracker+json
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657220",
"connect":{
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "45645"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "SEEDER"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "SEEDER"
}]
}
}
}
Another example of the message-body of a CONNECT request corresponds to a peer (peer_mode is LEECH, meaning that the peer is not in possession of the content) requesting join to a swarm, in order to start receiving the stream and providing optional information on the addresses of its network interface(s):
CONNECTリクエストのメッセージ本文の別の例は、ストリームの受信とオプションの情報の提供を開始するために、スウォームへの参加をリクエストするピア（peer_modeがLEECH、つまりピアがコンテンツを所有していないことを意味します）に対応します。ネットワークインターフェースのアドレス：
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345.0",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"peer_addr": [{
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "3256546"
},
{
"ip_address":{
"address_type": "ipv6",
"address": "2001:db8::2"
},
"port": 80,
"priority": 2,
"type": "HOST",
"connection": "wireless",
"asn": "34563456",
"peer_protocol": "PPSP-PP"
}],
"swarm_action": {
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "LEECH"
}
}
}
}
The next example of a CONNECT request corresponds to a peer leaving a previously joined swarm and requesting to join a new swarm. This is the typical example of a user watching a live channel but then deciding to switch to a different one:
CONNECTリクエストの次の例は、以前に参加したスウォームを離れ、新しいスウォームへの参加を要求するピアに対応しています。これは、ライブチャンネルを視聴しているユーザーが、別のチャンネルに切り替えることを決定する典型的な例です。
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "LEAVE",
"peer_mode": "LEECH"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "LEECH"
}]
}
}
}
The next example illustrates the response for the previous example of a CONNECT request where the peer requested two swarm actions and not more than 5 other peers, receiving from the tracker a peer list with only two other peers in the swarm "2222":
次の例は、ピアが2つのスウォームアクションを要求し、他の5つ以下のピアを要求し、スウォーム "2222"に他の2つのピアしかないピアリストをトラッカーから受信したCONNECTリクエストの前の例の応答を示しています。
HTTP/1.1 200 OK
Content-Length: 1342
Content-Type: application/ppsp-tracker+json
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"asn": "64496"
},
"swarm_result": {
"swarm_id": "2222",
"result": 0,
"peer_group": {
"peer_info": [{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
}]
}
}
}
}
This method allows peers to request a new peer list for the swarm from the tracker whenever needed.
この方法により、ピアは必要なときにいつでもトラッカーからスウォームの新しいピアリストをリクエストできます。
The FIND request may include a peer_number element to indicate to the tracker the maximum number of peers to be returned in a list corresponding to the indicated conditions set by the requesting peer, being ability_nat for NAT traversal (considering that PPSP-ICE NAT traversal techniques may be used), and optionally concurrent_links, online_time, and upload_bandwidth for the preferred capabilities.
FIND要求には、NATトラバーサル（PPSP-ICE NATトラバーサルテクニックが使用される）、およびオプションで優先機能のconcurrent_links、online_time、upload_bandwidth。
When receiving a well-formed FIND request, the tracker processes the information to check if it is valid. If successful, a response message with a response value of SUCCESSFUL will be generated, and the tracker will search out the list of peers for the swarm and select an appropriate peer list satisfying the conditions set by the requesting peer. The peer list returned MUST contain the peer IDs and the corresponding IP addresses.
整形式のFIND要求を受信すると、トラッカーは情報を処理して、それが有効かどうかを確認します。成功した場合、SUCCESSFULの応答値を持つ応答メッセージが生成され、トラッカーはスウォームのピアのリストを検索し、要求側のピアによって設定された条件を満たす適切なピアリストを選択します。返されるピアリストには、ピアIDと対応するIPアドレスが含まれている必要があります。
The tracker may take the ability of peers and popularity of the requested content into consideration. For example, the tracker could select peers with higher ability than the current peers that provide the content if the content is relatively popular (see Section 5.1.1); the tracker could also select peers with lower ability than the current peers that provide the content when the content is relatively uncommon. The tracker may take network location information into consideration as well, to express network topology preferences or operators' policy preferences. It can implement other IETF efforts like ALTO [RFC7285], which is out of the scope of this document.
トラッカーは、ピアの能力と要求されたコンテンツの人気を考慮に入れることができます。たとえば、コンテンツが比較的人気がある場合（セクション5.1.1を参照）、トラッカーは、コンテンツを提供する現在のピアよりも能力の高いピアを選択できます。トラッカーは、コンテンツが比較的一般的でない場合に、コンテンツを提供する現在のピアよりも能力の低いピアを選択することもできます。トラッカーは、ネットワークトポロジー設定またはオペレーターのポリシー設定を表すために、ネットワークロケーション情報も考慮に入れます。このドキュメントの範囲外であるALTO [RFC7285]などの他のIETFの取り組みを実装できます。
The response MUST include a peer_group element that contains the peer IDs and the corresponding IP addresses; it may also include the attribute asn with network location information of the transport address, corresponding to the Autonomous System Number of the access network provider of the referenced peer.
応答には、ピアIDと対応するIPアドレスを含むpeer_group要素を含める必要があります。また、参照されるピアのアクセスネットワークプロバイダーの自律システム番号に対応する、トランスポートアドレスのネットワークロケーション情報とともに属性asnを含めることもできます。
The response may also include a peer_addr element that includes the requesting peer public IP address. If no STUN is used and the tracker is able to work as a "STUN-like" server that can inspect the public address of a peer, the tracker can return the address back with a "REFLEXIVE" attribute type.
応答には、要求元のピアのパブリックIPアドレスを含むpeer_addr要素も含まれる場合があります。 STUNが使用されておらず、トラッカーがピアのパブリックアドレスを検査できる「STUNのような」サーバーとして機能できる場合、トラッカーは「REFLEXIVE」属性タイプでアドレスを返すことができます。
IMPLEMENTATION NOTE: If no peer_num attributes are present in the request, the tracker may return a random sample from the peer population.
実装に関する注：リクエストにpeer_num属性が存在しない場合、トラッカーはピアの母集団からランダムなサンプルを返すことがあります。
An example of the message-body of a FIND request, where the peer requests from the tracker a list of not more than 5 peers in the swarm "1111" conforming to the characteristics expressed (concurrent links, online time, and upload bandwidth level) is as follows:
FIND要求のメッセージ本文の例。ピアは、トラッカーに、表現された特性（同時リンク、オンライン時間、アップロード帯域幅レベル）に準拠したスウォーム「1111」内の5以下のピアのリストを要求します。以下のとおりであります：
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "FIND",
"transaction_id": "12345",
"peer_id": "656164657221",
"swarm_id": "1111",
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
}
}
}
An example of the message-body of a response for the above FIND request, including the requesting peer public IP address information, is as follows:
上記のFIND要求に対する応答のメッセージ本文の例（要求元のピアのパブリックIPアドレス情報を含む）は次のとおりです。
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0,
"peer_group": {
"peer_info": [{
"peer_id": "656164657221",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
}]
}
}
}
}
This method allows peers to send status and statistic data to trackers. The method is periodically initiated by the peer while it is active.
このメソッドを使用すると、ピアはステータスと統計データをトラッカーに送信できます。このメソッドは、アクティブな間、ピアによって定期的に開始されます。
The peer MUST set the request_type to "STAT_REPORT", set the peer_id with the identifier of the peer, and generate and set the transaction_id.
ピアはrequest_typeを "STAT_REPORT"に設定し、peer_idにピアの識別子を設定し、transaction_idを生成して設定する必要があります。
The report may include multiple statistics elements describing several properties relevant to a specific swarm. These properties can be related with stream statistics and peer status information, including uploaded_bytes, downloaded_bytes, available_bandwidth, concurrent_links, etc.
レポートには、特定の群に関連するいくつかのプロパティを説明する複数の統計要素が含まれる場合があります。これらのプロパティは、uploaded_bytes、downloaded_bytes、available_bandwidth、concurrent_linksなどのストリーム統計およびピアステータス情報に関連付けることができます。
Other properties may be defined (see the guidelines in Section 7.1), for example, those related to incentives and reputation mechanisms. If no Statistics Group is included, the STAT_REPORT is used as a "keep-alive" message to prevent the tracker from de-registering the peer when the "track timer" expires.
インセンティブや評判メカニズムに関連するプロパティなど、他のプロパティを定義することもできます（セクション7.1のガイドラインを参照）。統計グループが含まれていない場合、STAT_REPORTは「キープアライブ」メッセージとして使用され、「トラックタイマー」の期限が切れたときにトラッカーがピアの登録を解除しないようにします。
If the request is valid, the tracker processes the received information for future use and generates a response message with a response value of SUCCESSFUL.
要求が有効な場合、トラッカーは受信した情報を将来使用するために処理し、SUCCESSFULの応答値を含む応答メッセージを生成します。
The response MUST have the same transaction_id value as the request.
応答には、要求と同じtransaction_id値が必要です。
An example of the message-body of a STAT_REPORT request is:
STAT_REPORTリクエストのメッセージ本文の例は次のとおりです。
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "STAT_REPORT",
"transaction_id": "12345",
"peer_id": "656164657221",
"stat_report": {
"type": "STREAM_STATS",
"Stat": {
"swarm_id": "1111",
"uploaded_bytes": 512,
"downloaded_bytes": 768,
"available_bandwidth": 1024000,
"concurrent_links": 5
}
}
}
}
An example of the message-body of a response for the START_REPORT request is:
START_REPORTリクエストに対するレスポンスのメッセージ本文の例は次のとおりです。
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0
}
}
}
Table 7 indicates the response type and corresponding semantics.
表7は、応答タイプと対応するセマンティクスを示しています。
+--------------------+---------------------+
| Response Type | Semantics |
| | |
+--------------------+---------------------+
| 0 | SUCCESSFUL |
| 1 | FAILED |
+--------------------+---------------------+
Table 7: Semantics for the Value of Response Type
表7：応答タイプの値のセマンティクス
SUCCESSFUL: Indicates that the request has been processed properly and the desired operation has completed. The body of the response message includes the requested information and MUST include the same transaction_id as the corresponding request.
SUCCESSFUL：リクエストが適切に処理され、目的の操作が完了したことを示します。応答メッセージの本文には、要求された情報が含まれ、対応する要求と同じtransaction_idを含める必要があります。
CONNECT: Returns information about the successful registration of the peer and/or of each swarm action requested. May additionally return the list of peers corresponding to the action attribute requested.
CONNECT：ピアおよび/または要求された各スウォームアクションの正常な登録に関する情報を返します。さらに、要求されたアクション属性に対応するピアのリストを返す場合があります。
FIND: Returns the list of peers corresponding to the requested scope.
FIND：要求されたスコープに対応するピアのリストを返します。
STAT_REPORT: Confirms the success of the requested operation.
STAT_REPORT：要求された操作の成功を確認します。
FAILED: Indicates that the request has not been processed properly. A corresponding error_code SHOULD be set according to the conditions described in Section 4.3.
FAILED：リクエストが適切に処理されなかったことを示します。セクション4.3で説明されている条件に従って、対応するerror_codeを設定する必要があります（SHOULD）。
If the peer receives an invalid response, the same request with identical content including the same transaction_id MUST be repeated.
ピアが無効な応答を受信した場合、同じtransaction_idを含む同一のコンテンツを持つ同じリクエストを繰り返す必要があります。
The transaction_id on a request can be reused if and only if all of the content is identical, including date/time information. Details of the retry process (including time intervals to pause, number of retries to attempt, and timeouts for retrying) are implementation dependent.
リクエストのtransaction_idは、日付/時刻情報を含め、すべてのコンテンツが同一である場合にのみ再利用できます。再試行プロセスの詳細（一時停止する時間間隔、再試行回数、再試行のタイムアウトを含む）は、実装に依存します。
The tracker MUST be prepared to receive a request with a repeated transaction_id.
トラッカーは、transaction_idが繰り返されたリクエストを受信できるように準備する必要があります。
Error situations resulting from normal operation or from abnormal conditions (Section 2.3.2) MUST be responded to with response_type set to 0x01 and with the adequate error_code, as described here:
通常の操作または異常な状態（セクション2.3.2）に起因するエラー状況は、以下に説明するように、response_typeを0x01に設定し、適切なerror_codeで応答する必要があります。
o If the message is found to be incorrectly formed, the receiver MUST respond with a 01 (Bad Request) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o メッセージが正しく形成されていないことが判明した場合、受信者は、01（Bad Request）error_codeで空のメッセージ本文（peer_addrおよびswarm_result属性なし）で応答する必要があります。
o If the version number of the protocol is for a version the receiver does not support, the receiver MUST respond with a 02 (Unsupported Version Number) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o プロトコルのバージョン番号が、受信者がサポートしていないバージョンのものである場合、受信者は、02（Unsupported Version Number）error_codeで空のメッセージ本文（peer_addrおよびswarm_result属性なし）で応答する必要があります。
o In the PEER REGISTERED and TRACKING states of the tracker, certain requests are not allowed (Section 2.3.2). The tracker MUST respond with a 03 (Forbidden Action) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o トラッカーのPEER REGISTEREDおよびTRACKING状態では、特定のリクエストは許可されません（セクション2.3.2）。トラッカーは、03（Forbidden Action）error_codeで空のメッセージ本文（peer_addrおよびswarm_result属性なし）で応答する必要があります。
o If the tracker is unable to process a request message due to an unexpected condition, it SHOULD respond with a 04 (Internal Server Error) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o 予期しない状況が原因でトラッカーが要求メッセージを処理できない場合、空のメッセージ本文（peer_addrおよびswarm_result属性なし）を含む04（内部サーバーエラー）error_codeで応答する必要があります（SHOULD）。
o If the tracker is unable to process a request message because it is in an overloaded state, it SHOULD respond with a 05 (Service Unavailable) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o トラッカーが過負荷状態にあるために要求メッセージを処理できない場合は、05（Service Unavailable）error_codeで空のメッセージ本文（peer_addrおよびswarm_result属性なし）で応答する必要があります（SHOULD）。
o If authentication is required for the peer to make the request, the tracker SHOULD respond with a 06 (Authentication Required) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o ピアが要求を行うために認証が必要な場合、トラッカーは空のメッセージ本文（peer_addrおよびswarm_result属性なし）を含む06（Authentication Required）error_codeで応答する必要があります（SHOULD）。
This document only details object members used by this specification. Extensions may include additional members within JSON objects defined in this document. PPSTP implementations MUST ignore unknown members when processing PPSTP messages.
このドキュメントでは、この仕様で使用されるオブジェクトメンバーについてのみ詳しく説明します。拡張機能には、このドキュメントで定義されているJSONオブジェクト内に追加のメンバーが含まれる場合があります。 PPSTP実装は、PPSTPメッセージを処理するときに不明なメンバーを無視する必要があります。
This section provides the operational and management aspects that are required to be considered in implementations of PPSTP. These aspects follow the recommendations expressed in [RFC5706].
このセクションでは、PPSTPの実装で考慮する必要のある運用および管理の側面について説明します。これらの側面は、[RFC5706]で表現された推奨に従います。
PPSTP provides communication between trackers and peers and is conceived as a "client-server" mechanism, allowing the exchange of information about the participant peers sharing multimedia streaming content.
PPSTPは、トラッカーとピア間の通信を提供し、「クライアント/サーバー」メカニズムとして考案され、マルチメディアストリーミングコンテンツを共有する参加者のピアに関する情報の交換を可能にします。
The "server" component, i.e., the tracker, is a logical entity that can be envisioned as a centralized service (implemented in one or more physical nodes) or a fully distributed service.
「サーバー」コンポーネント、つまりトラッカーは、集中型サービス（1つ以上の物理ノードで実装）または完全に分散されたサービスとして想定できる論理エンティティです。
The "client" component can be implemented at each peer participating in the streaming of content.
「クライアント」コンポーネントは、コンテンツのストリーミングに参加している各ピアに実装できます。
Content providers wishing to use PPSP for content distribution should set up at least a PPSP tracker and a service portal (public web server) to publish links of the content descriptions, for access to their on-demand or live original content sources. Content and service providers should also create conditions to generate peer IDs and any required security certificates, as well as chunk IDs and swarm IDs for each streaming content. The configuration processes for the PPSP tracking facility, the service portal, and content sources are not standardized, enabling flexibility for implementers.
コンテンツの配信にPPSPを使用するコンテンツプロバイダーは、オンデマンドまたはライブのオリジナルのコンテンツソースにアクセスするために、少なくともPPSPトラッカーとサービスポータル（パブリックWebサーバー）を設定して、コンテンツの説明のリンクを公開する必要があります。コンテンツおよびサービスプロバイダーは、ピアIDと必要なセキュリティ証明書、および各ストリーミングコンテンツのチャンクIDと群IDを生成するための条件も作成する必要があります。 PPSP追跡機能、サービスポータル、およびコンテンツソースの構成プロセスは標準化されていないため、実装者は柔軟に対応できます。
The swarm IDs of available content, as well as the addresses of the PPSP tracking facility, can be distributed to end users in various ways, but it is common practice to include both the swarm ID and the corresponding PPSP tracker addresses (as URLs) in the MPD of the content, which is obtainable (a link) from the service portal.
利用可能なコンテンツのスウォームIDとPPSPトラッキング機能のアドレスは、さまざまな方法でエンドユーザーに配布できますが、スウォームIDと対応するPPSPトラッカーアドレス（URLとして）の両方をコンテンツのMPD。これはサービスポータルから取得できます（リンク）。
The available content could have different importance attribute values to indicate whether the content is popular or not. However, it is a totally implementation design and outside the scope of this specification. For example, the importance attribute values of the content could be set by content providers when distributing them or could be determined by the tracker based on the statistics of the requests from the peers that request the content. The tracker could set an upper threshold to decide that the content is popular enough when the importance attribute value is higher than the upper threshold. The tracker could also set a lower threshold to decide that the content is uncommon enough when the importance attribute value is lower than the lower threshold.
利用可能なコンテンツは、そのコンテンツが人気があるかどうかを示すために、さまざまな重要度属性値を持つことができます。ただし、これは完全に実装設計であり、この仕様の範囲外です。たとえば、コンテンツの重要度属性値は、配信時にコンテンツプロバイダーが設定するか、コンテンツを要求するピアからの要求の統計に基づいてトラッカーが決定できます。トラッカーは、重要度属性値が上限しきい値よりも高い場合にコンテンツが十分に人気があると判断するために上限しきい値を設定できます。トラッカーは、重要度属性値が下限しきい値よりも低い場合にコンテンツが十分に珍しいと判断するために、下限しきい値を設定することもできます。
End users browse and search for desired content in the service portal and select by clicking the links of the corresponding MPDs. This action typically requires security certificates or authorization tokens from an enrollment service (end-user registration) and then launches the Client Media Player (with PPSP awareness), which will then, using PPSTP, contact the PPSP tracker to join the corresponding swarm and obtain the transport addresses of other PPSP peers in order to start streaming the content.
エンドユーザーは、サービスポータルで目的のコンテンツを参照および検索し、対応するMPDのリンクをクリックして選択します。このアクションは通常、登録サービス（エンドユーザー登録）からのセキュリティ証明書または認証トークンを必要とし、次にクライアントメディアプレーヤー（PPSP認識付き）を起動します。PPSPTPを使用して、PPSPトラッカーに連絡し、対応するスウォームに参加して取得します。コンテンツのストリーミングを開始するための他のPPSPピアのトランスポートアドレス。
There is no previous standard protocol providing functionality similar to PPSTP. However, some popular proprietary protocols, e.g., BitTorrent, are used in existing systems. There is no way for PPSTP to migrate to proprietary protocols like the BitTorrent tracker protocol. Because PPSTP is an application-level protocol, there is no harm in PPSTP having no migration path. However, proprietary protocols migrating to standard protocols like PPSTP can solve the problems raised in [RFC6972]. It is also possible for systems to use PPSTP as the management protocol to work with exiting propriety peer protocols like the BitTorrent peer protocol.
PPSTPと同様の機能を提供する以前の標準プロトコルはありません。ただし、BitTorrentなどの一部の一般的な独自プロトコルは、既存のシステムで使用されています。 PPSTPがBitTorrentトラッカープロトコルのような独自のプロトコルに移行する方法はありません。 PPSTPはアプリケーションレベルのプロトコルであるため、PPSTPに移行パスがなくても問題はありません。ただし、PPSTPなどの標準プロトコルに移行する独自のプロトコルは、[RFC6972]で発生する問題を解決できます。システムが管理プロトコルとしてPPSTPを使用して、BitTorrentピアプロトコルのような既存の適切なピアプロトコルと連携することも可能です。
For security reasons, when using the Peer-to-Peer Streaming Peer Protocol (PPSPP) with PPSTP, the mechanisms described in Section 6.1 should be observed.
セキュリティ上の理由から、PPSTPでピアツーピアストリーミングピアプロトコル（PPSPP）を使用する場合は、セクション6.1で説明されているメカニズムを遵守する必要があります。
As the messaging model of PPSTP aligns with HTTP and the semantics of its messages, the impact on network operation is similar to using HTTP.
PPSTPのメッセージングモデルはHTTPとそのメッセージのセマンティクスに対応しているため、ネットワーク操作への影響はHTTPの使用に似ています。
The correct operation of PPSTP can be verified both at the tracker and at the peer by logging the behavior of PPSTP. Additionally, the PPSP tracker collects the status of the peers, including the peers' activity; such information can be used to monitor and obtain the global view of the operation.
PPSTPの動作をログに記録することで、トラッカーとピアの両方でPPSTPが正しく動作していることを確認できます。さらに、PPSPトラッカーは、ピアのアクティビティを含む、ピアのステータスを収集します。このような情報を使用して、操作の全体像を監視および取得できます。
The management considerations for PPSTP are similar to other solutions using HTTP for large-scale content distribution. The PPSP tracker can be realized by geographically distributed tracker nodes or multiple server nodes in a data center. As these nodes are akin to WWW nodes, their configuration procedures, detection of faults, measurement of performance, usage accounting, and security measures can be achieved by standard solutions and facilities.
PPSTPの管理に関する考慮事項は、大規模なコンテンツ配信にHTTPを使用する他のソリューションと同様です。 PPSPトラッカーは、地理的に分散したトラッカーノードまたはデータセンター内の複数のサーバーノードによって実現できます。これらのノードはWWWノードに類似しているため、その構成手順、障害の検出、パフォーマンスの測定、使用量の会計処理、およびセキュリティ対策は、標準のソリューションと設備によって実現できます。
Interoperability refers to allowing information sharing and operations between multiple devices and multiple management applications. For PPSTP, distinct types of devices host PPSTP trackers and peers. Therefore, support for multiple standard schema languages, management protocols, and information models, suited to different purposes, was considered in the PPSTP design. Specifically, management functionality for PPSTP devices can be achieved with the Simple Network Management Protocol (SNMP) [RFC3410], syslog [RFC5424], and the Network Configuration Protocol (NETCONF) [RFC6241].
相互運用性とは、複数のデバイスと複数の管理アプリケーション間での情報の共有と操作を可能にすることを指します。 PPSTPの場合、異なるタイプのデバイスがPPSTPトラッカーとピアをホストします。したがって、PPSTP設計では、さまざまな目的に適した複数の標準スキーマ言語、管理プロトコル、および情報モデルのサポートが検討されました。具体的には、PPSTPデバイスの管理機能は、簡易ネットワーク管理プロトコル（SNMP）[RFC3410]、syslog [RFC5424]、およびネットワーク構成プロトコル（NETCONF）[RFC6241]を使用して実現できます。
PPSP trackers may implement SNMP management interfaces, namely, the Application Management MIB [RFC2564], without the need to instrument the tracker application itself. The channel, connections, and transaction objects of the Application Management MIB can be used to report the basic behavior of the PPSP tracker service.
PPSPトラッカーは、トラッカーアプリケーション自体をインストルメント化する必要なく、SNMP管理インターフェイス、つまりアプリケーション管理MIB [RFC2564]を実装できます。アプリケーション管理MIBのチャネル、接続、およびトランザクションオブジェクトを使用して、PPSPトラッカーサービスの基本的な動作を報告できます。
The Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150] can be used with PPSTP to provide adequate metrics for the analysis of performance for transaction flows in the network, in direct relationship to the transport of PPSTP.
アプリケーションパフォーマンス測定MIB（APM-MIB）[RFC3729]およびトランスポートパフォーマンスメトリックMIB（TPM-MIB）[RFC4150]をPPSTPと併用して、ネットワーク内のトランザクションフローのパフォーマンス分析に適切なメトリックを直接提供できます。 PPSTPのトランスポートとの関係。
The Host Resources MIB [RFC2790] can be used to supply information on the hardware, the operating system, and the installed and running software on a PPSP tracker host.
Host Resources MIB [RFC2790]を使用して、ハードウェア、オペレーティングシステム、およびPPSPトラッカーホストにインストールされ実行されているソフトウェアに関する情報を提供できます。
The TCP-MIB [RFC4022] can additionally be considered for network monitoring.
TCP-MIB [RFC4022]は、ネットワーク監視のためにさらに検討することができます。
Logging is an important functionality for PPSTP trackers and peers; it is done via syslog [RFC5424].
ロギングは、PPSTPトラッカーおよびピアにとって重要な機能です。 syslog [RFC5424]を介して行われます。
As PPSP tracker failures can be mainly attributed to host or network conditions, the facilities previously described for verifying the correct operation of PPSTP and the management of PPSP tracker servers appear sufficient for PPSTP fault monitoring.
PPSPトラッカーの障害は主にホストまたはネットワークの状態に起因する可能性があるため、PPSTPの正しい動作を検証するための前述の機能とPPSPトラッカーサーバーの管理は、PPSTP障害の監視には十分であると思われます。
PPSP tracker deployments, when realized by geographically distributed tracker nodes or multiple server nodes in a data center, may benefit from a standard way of replicating atomic configuration updates over a set of server nodes. This functionality can be provided via NETCONF [RFC6241].
PPSPトラッカーの展開は、地理的に分散したトラッカーノードまたはデータセンター内の複数のサーバーノードによって実現される場合、一連のサーバーノード上でアトミック構成の更新をレプリケートする標準的な方法から恩恵を受ける可能性があります。この機能は、NETCONF [RFC6241]を介して提供できます。
PPSTP implementations, primarily in content provider environments, can benefit from accounting standardization efforts as described in [RFC2975], which indicates that accounting management is "concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing".
主にコンテンツプロバイダー環境でのPPSTP実装は、[RFC2975]で説明されているように、アカウンティング標準化の取り組みから利益を得ることができます。 、請求書」。
Because PPSTP is transaction oriented, its performance in terms of availability and responsiveness can be measured with the facilities of the APM-MIB [RFC3729] and the TPM-MIB [RFC4150].
PPSTPはトランザクション指向であるため、可用性と応答性に関するそのパフォーマンスは、APM-MIB [RFC3729]およびTPM-MIB [RFC4150]の機能を使用して測定できます。
Standard SNMP notifications for PPSP tracker management [RFC5590] and syslog messages [RFC5424] can be used to alert operators to the conditions identified in the security considerations (Section 6).
PPSPトラッカー管理の標準SNMP通知[RFC5590]とsyslogメッセージ[RFC5424]を使用して、セキュリティに関する考慮事項（セクション6）で特定された条件についてオペレーターに警告できます。
The statistics collected about the operation of PPSTP can be used for detecting attacks (e.g., the receipt of malformed messages, messages out of order, or messages with invalid timestamps). However, collecting such endpoint properties may also raise some security issues. For example, the statistics collected by the tracker may be disclosed to an unauthorized third party that has malicious intentions. To address such risk, the provider of the tracker should evaluate how much information is revealed and the associated risks. A confidentiality mechanism must be provided by HTTP over TLS to guarantee the confidentiality of PPSTP.
PPSTPの動作に関して収集された統計情報は、攻撃（不正なメッセージの受信、異常なメッセージの受信、タイムスタンプが無効なメッセージの受信など）の検出に使用できます。ただし、このようなエンドポイントプロパティを収集すると、セキュリティ上の問題が発生する場合もあります。たとえば、トラッカーによって収集された統計情報は、悪意のある意図を持つ無許可の第三者に開示される可能性があります。このようなリスクに対処するために、トラッカーのプロバイダーは、明らかにされた情報の量と関連するリスクを評価する必要があります。 PPSTPの機密性を保証するには、HTTP over TLSによって機密性メカニズムを提供する必要があります。
P2P streaming systems are subject to attacks by malicious or unfriendly peers/trackers that may eavesdrop on signaling, forge/deny information/knowledge about streaming content and/or its availability, impersonate a valid participant, or launch DoS attacks on a chosen victim.
P2Pストリーミングシステムは、悪意のある、または不親切なピア/トラッカーによる攻撃の対象となり、シグナリングを盗聴したり、ストリーミングコンテンツやその可用性に関する情報を偽造/拒否したり、有効な参加者を偽装したり、選択した被害者にDoS攻撃を仕掛けたりする可能性があります。
No security system can guarantee complete security in an open P2P streaming system where participants may be malicious or uncooperative. The goal of the security considerations described here is to provide sufficient protection for maintaining some security properties during tracker-peer communication even in the face of a large number of malicious peers and/or eventual distrustful trackers (under the distributed tracker deployment scenario).
セキュリティシステムは、参加者が悪意のある、または協力的でない可能性があるオープンなP2Pストリーミングシステムでの完全なセキュリティを保証できません。ここで説明するセキュリティの考慮事項の目標は、多数の悪意のあるピアや最終的に信頼できないトラッカー（分散トラッカーの展開シナリオの下）に直面した場合でも、トラッカーピア通信中に一部のセキュリティプロパティを維持するための十分な保護を提供することです。
Since the protocol uses HTTP to transfer signaling, most of the security considerations described in [RFC7230] and [RFC7231] also apply. Due to the transactional nature of the communication between peers and tracker, the method for adding authentication and data security services can be the OAuth 2.0 Authorization [RFC6749] with a bearer token, which provides the peer with the information required to successfully utilize an access token to make protected requests to the tracker.
プロトコルはHTTPを使用してシグナリングを転送するため、[RFC7230]および[RFC7231]で説明されているセキュリティに関する考慮事項のほとんどが適用されます。ピアとトラッカー間の通信のトランザクションの性質により、認証サービスとデータセキュリティサービスを追加する方法は、ベアラートークンを使用したOAuth 2.0 Authorization [RFC6749]にすることができます。保護されたリクエストをトラッカーに送信します。
To protect PPSTP signaling from attackers pretending to be valid peers (or peers other than themselves), all messages received in the tracker SHOULD be received from authorized peers. For that purpose, a peer SHOULD enroll in the system via a centralized enrollment server. The enrollment server is expected to provide a proper peer ID for the peer and information about the authentication mechanisms. The specification of the enrollment method and the provision of identifiers and authentication tokens is out of the scope of this specification.
有効なピア（または自分以外のピア）を装う攻撃者からPPSTPシグナリングを保護するために、トラッカーで受信されたすべてのメッセージは、許可されたピアから受信する必要があります（SHOULD）。そのために、ピアは集中登録サーバーを介してシステムに登録する必要があります（SHOULD）。登録サーバーは、ピアの適切なピアIDと認証メカニズムに関する情報を提供することが期待されています。登録方法の仕様と、識別子と認証トークンの提供は、この仕様の範囲外です。
Transport Layer Security (TLS) [RFC5246] MUST be used in the communication between peers and tracker to provide privacy and data integrity. Software engineers developing and service providers deploying the tracker should make themselves familiar with the Best Current Practices (BCP) on configuring HTTP over TLS [RFC7525].
トランスポート層セキュリティ（TLS）[RFC5246]は、プライバシーとデータの整合性を提供するために、ピアとトラッカー間の通信で使用する必要があります。トラッカーを開発し、サービスプロバイダーを展開しているソフトウェアエンジニアは、HTTP over TLS [RFC7525]の構成に関するベストカレントプラクティス（BCP）に慣れる必要があります。
OAuth 2.0 Authorization [RFC6749] SHOULD also be considered when digest authentication [RFC7616] and HTTPS client certificates are required.
OAuth 2.0認可[RFC6749]は、ダイジェスト認証[RFC7616]とHTTPSクライアント証明書が必要な場合にも考慮されるべきです（SHOULD）。
Malicious peers may claim ownership of popular content to the tracker and try to serve polluted (i.e., decoy content or even virus/trojan-infected content) to other peers. Since trackers do not exchange content information among peers, it is difficult to detect whether or not a peer is polluting the content. Usually, this kind of pollution can be detected by the Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574] with requiring the use of Merkle Hash Tree scheme for protecting the integrity of the content. More details can be seen in Section 5 of [RFC7574].
悪意のあるピアは、人気のあるコンテンツの所有権をトラッカーに要求し、汚染された（おとりのコンテンツ、さらにはウイルス/トロイの木馬に感染したコンテンツでさえ）他のピアにサービスを提供しようとします。トラッカーはピア間でコンテンツ情報を交換しないため、ピアがコンテンツを汚染しているかどうかを検出することは困難です。通常、この種の汚染は、ピアツーピアストリーミングピアプロトコル（PPSPP）[RFC7574]で検出できます。コンテンツの整合性を保護するには、マークルハッシュツリースキームを使用する必要があります。詳細については、[RFC7574]のセクション5をご覧ください。
Some attackers that disrupt P2P streaming on behalf of content providers may provide false or modified content or peer list information to achieve certain malicious goals. Peers connecting to those portals or trackers provided by the attackers may be redirected to some corrupted malicious content. However, there is no standard way for peers to avoid this kind of situation completely. Peers can have mechanisms to detect undesirable content or results themselves. For example, if a peer finds that the portal returned some undesired content information or the tracker returned some malicious peer lists, the peer may choose to quit the swarm or switch to other P2P streaming services provided by other content providers.
コンテンツプロバイダーに代わってP2Pストリーミングを妨害する一部の攻撃者は、特定の悪意のある目的を達成するために、偽のまたは変更されたコンテンツまたはピアリスト情報を提供する可能性があります。攻撃者によって提供されたこれらのポータルまたはトラッカーに接続しているピアは、破損した悪意のあるコンテンツにリダイレクトされる可能性があります。ただし、ピアがこのような状況を完全に回避するための標準的な方法はありません。ピアは、望ましくないコンテンツや結果を自分で検出するメカニズムを持つことができます。たとえば、ピアがポータルが望ましくないコンテンツ情報を返したり、トラッカーが悪意のあるピアリストを返したりした場合、ピアはスウォームを終了するか、他のコンテンツプロバイダーが提供する他のP2Pストリーミングサービスに切り替えることを選択できます。
To mitigate the impact of Sybil attackers impersonating a large number of valid participants by repeatedly acquiring different peer identities, the enrollment server SHOULD carefully regulate the rate of peer/tracker admission.
異なるピアIDを繰り返し取得することにより、多数の有効な参加者になりすましているSybil攻撃者の影響を緩和するために、登録サーバーは、ピア/トラッカーの許可率を注意深く調整する必要があります。
There is no guarantee that peers honestly report their status to the tracker, or serve authentic content to other peers as they claim to the tracker. It is expected that a global trust mechanism, where the credit of each peer is accumulated from evaluations for previous transactions, may be taken into account by other peers when selecting partners for future transactions, helping to mitigate the impact of such malicious behaviors. A globally trusted tracker may also take part in the trust mechanism by collecting evaluations, computing credit values, and providing them to joining peers.
ピアがトラッカーに自分のステータスを正直に報告したり、他のピアがトラッカーに要求したときに本物のコンテンツを提供したりする保証はありません。各ピアのクレジットが以前のトランザクションの評価から累積されるグローバル信頼メカニズムは、将来のトランザクションのパートナーを選択するときに他のピアによって考慮に入れられ、そのような悪意のある動作の影響を緩和するのに役立つことが期待されます。グローバルに信頼されているトラッカーは、評価を収集し、クレジット値を計算し、それらを参加ピアに提供することにより、信頼メカニズムに参加することもできます。
Property types for STAT_REPORT messages may consider additional pro-incentive parameters (see the guidelines for extension in Section 7), which can enable the tracker to improve the performance of the whole P2P streaming system. Trustworthiness of these pro-incentive parameters is critical to the effectiveness of the incentive mechanisms. Furthermore, the amount of both uploaded and downloaded data should be reported to the tracker to allow checking for inconsistencies between the upload and download report and to establish an appropriate credit/trust system.
STAT_REPORTメッセージのプロパティタイプは、インセンティブパラメーター（セクション7の拡張のガイドラインを参照）を考慮する場合があります。これにより、トラッカーがP2Pストリーミングシステム全体のパフォーマンスを向上させることができます。これらの奨励パラメーターの信頼性は、奨励メカニズムの有効性にとって重要です。さらに、アップロードされたデータとダウンロードされたデータの両方の量をトラッカーに報告して、アップロードとダウンロードのレポート間の不一致をチェックし、適切な信用/信頼システムを確立する必要があります。
One such solution could be a reputation-incentive mechanism, based on the notions of reputation, social awareness, and fairness. The mechanism would promote cooperation among participants (via each peer's reputation) based on the history of past transactions, such as, count of chunk requests (sent and received) in a swarm, contribution time of the peer, cumulative uploaded and downloaded content, JOIN and LEAVE timestamps, attainable rate, etc.
そのような解決策の1つは、評判、社会的認識、および公平性の概念に基づく評判インセンティブメカニズムである可能性があります。このメカニズムは、スウォーム内のチャンクリクエスト（送信および受信）の数、ピアの貢献時間、アップロードおよびダウンロードされたコンテンツの累積、JOINなどの過去のトランザクションの履歴に基づいて、（各ピアの評判を介して）参加者間の協力を促進しますLEAVEタイムスタンプ、達成可能なレートなど
Alternatively, exchange of cryptographic receipts signed by receiving peers can be used to attest to the upload contribution of a peer to the swarm, as suggested in [Contracts].
あるいは、[契約]で提案されているように、受信ピアによって署名された暗号化レシートの交換を使用して、スウォームへのピアのアップロード寄与を証明することができます。
PPSTP provides mechanisms in which the peers can send messages containing IP addresses, ports, and other information to the tracker. A tracker or a third party who is able to intercept such messages can store and process the obtained information in order to analyze peers' behaviors and communication patterns. Such analysis can lead to privacy risks. For example, an unauthorized party may snoop on the data transmission from the peer to a tracker in order to introduce some corrupted chunks.
PPSTPは、ピアがIPアドレス、ポート、およびその他の情報を含むメッセージをトラッカーに送信できるメカニズムを提供します。そのようなメッセージを傍受できるトラッカーまたはサードパーティは、ピアの動作と通信パターンを分析するために、取得した情報を保存および処理できます。このような分析は、プライバシーリスクにつながる可能性があります。たとえば、不正なパーティが、破損したチャンクを導入するために、ピアからトラッカーへのデータ送信を傍受する場合があります。
The Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574] has already introduced some mechanisms to protect streamed content; see Sections 12.3 and 12.4 of [RFC7574]. For PPSTP, peer implementations as well as tracker implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. In addition, a peer should be cognizant about potential trackers tracking through queries of peers, e.g., by using HTTP cookies. PPSTP as specified in this document does not rely on HTTP cookies. Thus, peers may decide not to return cookies received from the tracker, in order to make additional tracking more difficult.
ピアツーピアストリーミングピアプロトコル（PPSPP）[RFC7574]は、ストリーミングされたコンテンツを保護するためのメカニズムをすでにいくつか導入しています。 [RFC7574]のセクション12.3および12.4を参照してください。 PPSTPの場合、ピア実装およびトラッカー実装は、「https」URIスキーム[RFC2818]およびトランスポート層セキュリティ（TLS）[RFC5246]をサポートする必要があります。さらに、ピアは、ピアのクエリを介して、たとえばHTTP Cookieを使用して追跡する潜在的なトラッカーについて認識している必要があります。このドキュメントで指定されているPPSTPは、HTTP Cookieに依存していません。したがって、ピアは、追加の追跡をより困難にするために、トラッカーから受信したCookieを返さないことを決定する場合があります。
Extension mechanisms allow designers to add new features or to customize existing features of a protocol for different operating environments [RFC6709].
拡張メカニズムにより、設計者は新しい機能を追加したり、プロトコルの既存の機能をさまざまな動作環境に合わせてカスタマイズしたりできます[RFC6709]。
Extending a protocol implies either the addition of features without changing the protocol itself or the addition of new elements creating new versions of an existing schema and therefore new versions of the protocol.
プロトコルの拡張とは、プロトコル自体を変更せずに機能を追加するか、既存のスキーマの新しいバージョンを作成して、プロトコルの新しいバージョンを作成する新しい要素を追加することを意味します。
In PPSTP, this means that an extension MUST NOT alter an existing protocol schema as the changes would result in a new version of an existing schema, not an extension of an existing schema, typically non-backwards-compatible.
PPSTPでは、これは、既存のスキーマの拡張ではなく、通常は下位互換性のない既存のスキーマの新しいバージョンになるため、拡張が既存のプロトコルスキーマを変更してはならないことを意味します。
Additionally, a designer MUST remember that extensions themselves may also be extensible.
さらに、設計者は拡張自体も拡張可能であることを覚えておく必要があります。
Extensions MUST adhere to the principles described in this section in order to be considered valid.
拡張機能は、有効であると見なされるために、このセクションで説明されている原則に従う必要があります。
Extensions MUST be documented in Standards Track RFCs if there are requirements for coordination, interoperability, and broad distribution.
調整、相互運用性、および広範な配布の要件がある場合は、拡張機能を標準トラックRFCに文書化する必要があります。
In PPSTP, two extension mechanisms can be used: a Request-Response Extension or a Protocol-Level Extension.
PPSTPでは、要求と応答の拡張またはプロトコルレベルの拡張という2つの拡張メカニズムを使用できます。
o Request-Response Extension: Adding elements or attributes to an existing element mapping in the schema is the simplest form of extension. This form should be explored before any other. This task can be accomplished by extending an existing element mapping.
o 要求/応答拡張：スキーマ内の既存の要素マッピングに要素または属性を追加することは、拡張の最も単純な形式です。このフォームは、他のどのフォームよりも先に検討する必要があります。このタスクは、既存のエレメントマッピングを拡張することで実行できます。
For example, an element mapping for the Statistics Group can be extended to include additional elements needed to express status information about the activity of the peer, such as online time for the stat element.
たとえば、Statisticsグループの要素マッピングを拡張して、stat要素のオンライン時間など、ピアのアクティビティに関するステータス情報を表現するために必要な追加要素を含めることができます。
o Protocol-Level Extension: If there is no existing element mapping that can be extended to meet the requirements and the existing PPSTP request and response message structures are insufficient, then extending the protocol should be considered in order to define new operational requests and responses.
o プロトコルレベルの拡張：要件を満たすために拡張できる既存の要素マッピングがなく、既存のPPSTP要求と応答メッセージの構造が不十分な場合は、新しい運用要求と応答を定義するためにプロトコルの拡張を検討する必要があります。
For example, to enhance the level of control and the granularity of the operations, a new version of the protocol with new messages (JOIN, DISCONNECT), a retro-compatible change in semantics of an existing CONNECT request/response, and an extension in STAT_REPORT could be considered.
たとえば、制御のレベルと操作の細分性を強化するために、新しいメッセージ（JOIN、DISCONNECT）を備えた新しいバージョンのプロトコル、既存のCONNECT要求/応答のセマンティクスのレトロコンパチブルな変更、およびSTAT_REPORTを検討できます。
As illustrated in Figure 6, the peer would use an enhanced CONNECT request to perform the initial registration in the system. Then it would join a first swarm as SEEDER, later join a second swarm as LEECH, and then disconnect from the latter swarm but remain as SEEDER for the first one. When deciding to leave the system, the peer disconnects gracefully from it:
図6に示すように、ピアは拡張CONNECT要求を使用して、システムでの初期登録を実行します。次に、最初のスウォームにSEEDERとして参加し、後で2番目のスウォームにLEECHとして参加し、その後、後者のスウォームから切断しますが、最初のスウォームとしては最初のスウォームのままです。システムを離れることを決定すると、ピアはシステムから正常に切断します。
+--------+ +---------+
| Peer | | Tracker |
+--------+ +---------+
| |
|--CONNECT--------------------->|
|<--------------------------OK--|
|--JOIN(swarm_a;SEEDER)---------->|
|<--------------------------OK--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--JOIN(swarm_b;LEECH)--------->|
|<-----------------OK+PeerList--|
: :
|--STAT_REPORT(ChunkMap_b)----->|
|<--------------------------Ok--|
: :
|--DISCONNECT(swarm_b)--------->|
|<--------------------------Ok--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--DISCONNECT------------------>|
|<---------------------Ok(BYE)--|
Figure 6: Example of a Session for a PPSTP Extended Version
図6：PPSTP拡張バージョンのセッションの例
There are several issues that all extensions should take into consideration.
すべての拡張機能で考慮すべきいくつかの問題があります。
o Overview of the Extension: It is RECOMMENDED that extensions to PPSTP have a protocol overview section that discusses the basic operation of the extension. The most important processing rules for the elements in the message flows SHOULD also be mentioned.
o 拡張機能の概要：PPSTPの拡張機能には、拡張機能の基本的な操作を説明するプロトコル概要セクションがあることをお勧めします。メッセージフローの要素の最も重要な処理ルールも言及する必要があります。
o Backward Compatibility: The new extension MUST be backward compatible with the base PPSTP specified in this document.
o 下位互換性：新しい拡張機能は、このドキュメントで指定されている基本PPSTPと下位互換性がある必要があります。
o Syntactic Issues: Extensions that define new request/response methods SHOULD use all capitals for the method name, keeping with a long-standing convention in many protocols, such as HTTP. Method names are case sensitive in PPSTP. Method names SHOULD be shorter than 16 characters and SHOULD attempt to convey the general meaning of the request or response.
o 構文の問題：新しい要求/応答メソッドを定義する拡張機能は、HTTPなどの多くのプロトコルで長年の慣習に従って、メソッド名にすべて大文字を使用する必要があります（SHOULD）。メソッド名は、PPSTPでは大文字と小文字が区別されます。メソッド名は16文字未満である必要があり（SHOULD）、要求または応答の一般的な意味を伝えようとする必要があります（SHOULD）。
o Semantic Issues: PPSTP extensions MUST clearly define the semantics of the extensions. Specifically, the extension MUST specify the behaviors expected from both the peer and the tracker in processing the extension, with the processing rules in temporal order of the common messaging scenario.
o 意味上の問題：PPSTP拡張機能は、拡張機能のセマンティクスを明確に定義する必要があります。具体的には、拡張機能は、拡張機能を処理する際にピアとトラッカーの両方から期待される動作を、共通のメッセージングシナリオの時間順に処理ルールを使用して指定する必要があります。
Processing rules generally specify actions to be taken on receipt of messages and expiration of timers.
処理ルールは通常、メッセージの受信およびタイマーの満了時に実行するアクションを指定します。
The extension SHOULD specify procedures to be taken in exceptional conditions that are recoverable. Handling of unrecoverable errors does not require specification.
拡張は、回復可能な例外的な状況で実行される手順を指定する必要があります（SHOULD）。回復不可能なエラーの処理には、仕様は必要ありません。
o Security Issues: As security is an important component of any protocol, designers of PPSTP extensions need to carefully consider security requirements, e.g., authorization requirements and requirements for end-to-end integrity.
o セキュリティの問題：セキュリティはプロトコルの重要なコンポーネントであるため、PPSTP拡張機能の設計者は、承認要件やエンドツーエンドの整合性の要件など、セキュリティ要件を慎重に検討する必要があります。
o Examples of Usage: The specification of the extension SHOULD give examples of message flows and message formatting and include examples of messages containing new syntax. Examples of message flows should be given to cover common cases and at least one failure or unusual case.
o 使用例：拡張の仕様は、メッセージフローとメッセージフォーマットの例を示し、新しい構文を含むメッセージの例を含む必要があります（SHOULD）。一般的なケースと少なくとも1つの失敗または異常なケースをカバーするために、メッセージフローの例を示す必要があります。
This document registers "application/ppsp-tracker+json" media types.
このドキュメントでは、「application / ppsp-tracker + json」メディアタイプを登録しています。
Type name: application
タイプ名：アプリケーション
Subtype name: ppsp-tracker+json
サブタイプ名：ppsp-tracker + json
Required parameters: n/a
必須パラメーター：なし
Optional parameters: n/a
オプションのパラメーター：n / a
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7159].
エンコーディングの考慮事項：エンコーディングの考慮事項は、「application / json」メディアタイプに指定されたものと同じです。 [RFC7159]を参照してください。
Security considerations: See Section 6 of RFC 7846.
セキュリティに関する考慮事項：RFC 7846のセクション6をご覧ください。
Interoperability considerations: This document specifies the format of conforming messages and the interpretation thereof.
相互運用性に関する考慮事項：このドキュメントでは、適合メッセージの形式とその解釈について説明します。
Published specification: RFC 7846.
公開された仕様：RFC 7846。
Applications that use this media type: PPSP trackers and peers either stand alone or are embedded within other applications.
このメディアタイプを使用するアプリケーション：PPSPトラッカーとピアは、スタンドアロンであるか、他のアプリケーションに埋め込まれています。
Additional information:
追加情報：
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Fragment identifier considerations: n/a
フラグメント識別子の考慮事項：なし
Person & email address to contact for further information: See Authors' Addresses section.
詳細については、連絡先の人と電子メールアドレス：作成者のアドレスセクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: none
使用上の制限：なし
Author: See Authors' Addresses section of RFC 7846.
作成者：RFC 7846の「作成者のアドレス」セクションを参照してください。
Change controller: IESG (iesg@ietf.org)
変更コントローラー：IESG（iesg@ietf.org）
IANA has created the "PPSTP Version Number Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 2. New PPSTP version types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new version types and their usage has been provided.
IANAは「PPSTPバージョン番号レジストリ」を作成しました。値は0〜255の範囲の整数で、表2に初期割り当てと予約が示されています。IETFレビュー[RFC5226]の後に新しいPPSTPバージョンタイプが割り当てられ、新しいバージョンタイプとその使用法に関する適切なドキュメントが提供されていることを確認します。
IANA has created the "PPSTP Request Type Registry". Values are strings listed in Table 8. New PPSTP request types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new request types and their usage has been provided.
IANAは「PPSTP要求タイプレジストリ」を作成しました。値は表8にリストされている文字列です。IETFレビュー[RFC5226]の後に新しいPPSTP要求タイプが割り当てられ、新しい要求タイプとその使用法に関する適切なドキュメントが提供されていることを確認します。
+----------------------+-------------------------------------------+
| request_type | Description |
+----------------------+-------------------------------------------+
| "CONNECT" | Returns information about the successful |
| | registration of the peer and/or of each |
| | swarm action requested. May additionally |
| | return the list of peers corresponding to |
| | the action attribute |
| | requested. |
| | |
| "FIND" | Returns the list of peers corresponding |
| | to the requested scope. |
| | |
| "STAT_REPORT" | Confirms the success of the requested |
| | operation. |
+----------------------+-------------------------------------------+
Table 8: The PPSTP Request Type Registry
表8：PPSTP要求タイプレジストリ
IANA has created the "PPSTP Error Code Registry". Values are the strings listed in Table 9. New PPSTP error codes are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new error codes and their usage has been provided.
IANAは「PPSTPエラーコードレジストリ」を作成しました。値は表9に示す文字列です。IETFレビュー[RFC5226]の後に新しいPPSTPエラーコードが割り当てられ、新しいエラーコードとその使用法に関する適切なドキュメントが提供されていることを確認します。
+---------------+-------------------------------------------+
| error_code | Description |
+---------------+-------------------------------------------+
| 00 | No Error |
| 01 | Bad Request |
| 02 | Unsupported Version Number |
| 03 | Forbidden Action |
| 04 | Internal Server Error |
| 05 | Service Unavailable |
| 06 | Authentication Required |
+---------------+-------------------------------------------+
Table 9: The PPSTP Error Code Registry
表9：PPSTPエラーコードレジストリ
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[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>。
[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>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5590, DOI 10.17487/RFC5590, June 2009, <http://www.rfc-editor.org/info/rfc5590>.
[RFC5590] Harrington、D.、J。Schoenwaelder、「Transport Subsystem for the Simple Network Management Protocol（SNMP）」、STD 78、RFC 5590、DOI 10.17487 / RFC5590、2009年6月、<http：//www.rfc-editor .org / info / rfc5590>。
[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>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、DOI 10.17487 / RFC5952、August 2010、<http://www.rfc-editor.org/info/rfc5952> 。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<http：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content"、RFC 7231、DOI 10.17487 / RFC7231、June 2014、<http：// www.rfc-editor.org/info/rfc7231>。
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]アリミ、R。、エド、ペンノ、R。、エド、ヤン、Y。、エド、キーゼル、S。、プレビディ、S。、ルーム、W。、シャルノフ、S.、R。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<http://www.rfc-editor.org/info/rfc7285>。
[RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-Peer Streaming Peer Protocol (PPSPP)", RFC 7574, DOI 10.17487/RFC7574, July 2015, <http://www.rfc-editor.org/info/rfc7574>.
[RFC7574] Bakker、A.、Petrocco、R。、およびV. Grishchenko、「ピアツーピアストリーミングピアプロトコル（PPSPP）」、RFC 7574、DOI 10.17487 / RFC7574、2015年7月、<http：// www。 rfc-editor.org/info/rfc7574>。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D。、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<http：//www.rfc- editor.org/info/rfc7616>。
[Contracts] Piatek, M., Krishnamurthy, A., Venkataramani, A., Yang, R., Zhang, D., and A. Jaffe, "Contracts: Practical Contribution Incentives for P2P Live Streaming", NSDI: USENIX Symposium on Networked Systems Design and Implementation, April 2010.
[契約] Piatek、M.、Krishnamurthy、A.、Venkataramani、A.、Yang、R.、Zhang、D。、およびA. Jaffe、「Contracts：Practical Contribution Incentives for P2P Live Streaming」、NSDI：USENIX Symposium onネットワーク化されたシステムの設計と実装、2010年4月。
[RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. Saperia, "Application Management MIB", RFC 2564, DOI 10.17487/RFC2564, May 1999, <http://www.rfc-editor.org/info/rfc2564>.
[RFC2564] Kalbfleisch、C.、Krupczak、C.、Presuhn、R。、およびJ. Saperia、「アプリケーション管理MIB」、RFC 2564、DOI 10.17487 / RFC2564、1999年5月、<http：//www.rfc-editor .org / info / rfc2564>。
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, DOI 10.17487/RFC2790, March 2000, <http://www.rfc-editor.org/info/rfc2790>.
[RFC2790] Waldbusser、S。およびP. Grillo、「Host Resources MIB」、RFC 2790、DOI 10.17487 / RFC2790、2000年3月、<http://www.rfc-editor.org/info/rfc2790>。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, <http://www.rfc-editor.org/info/rfc2975>.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「Introduction to Accounting Management」、RFC 2975、DOI 10.17487 / RFC2975、2000年10月、<http://www.rfc-editor.org/info / rfc2975>。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, DOI 10.17487/RFC3410, December 2002, <http://www.rfc-editor.org/info/rfc3410>.
[RFC3410] Case、J.、Mundy、R.、Partain、D.、and B. Stewart、 "Introduction and Applicability Statements for Internet-Standard Management Framework"、RFC 3410、DOI 10.17487 / RFC3410、December 2002、<http： //www.rfc-editor.org/info/rfc3410>。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, DOI 10.17487/RFC3729, March 2004, <http://www.rfc-editor.org/info/rfc3729>.
[RFC3729] Waldbusser、S。、「アプリケーションパフォーマンス測定MIB」、RFC 3729、DOI 10.17487 / RFC3729、2004年3月、<http://www.rfc-editor.org/info/rfc3729>。
[RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005, <http://www.rfc-editor.org/info/rfc4022>.
[RFC4022] Raghunarayan、R。、編、「伝送制御プロトコル（TCP）の管理情報ベース」、RFC 4022、DOI 10.17487 / RFC4022、2005年3月、<http://www.rfc-editor.org/info / rfc4022>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「A Universally Unique Identifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<http：//www.rfc- editor.org/info/rfc4122>。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, DOI 10.17487/RFC4150, August 2005, <http://www.rfc-editor.org/info/rfc4150>.
[RFC4150] Dietz、R。およびR. Cole、「Transport Performance Metrics MIB」、RFC 4150、DOI 10.17487 / RFC4150、2005年8月、<http://www.rfc-editor.org/info/rfc4150>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、DOI 10.17487 / RFC5424、2009年3月、<http://www.rfc-editor.org/info/rfc5424>。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>.
[RFC5706]ハリントン、D。、「新しいプロトコルとプロトコル拡張の操作と管理を考慮するためのガイドライン」、RFC 5706、DOI 10.17487 / RFC5706、2009年11月、<http://www.rfc-editor.org/info/rfc5706 >。
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709] Carpenter、B.、Aboba、B.、Ed。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、DOI 10.17487 / RFC6709、2012年9月、<http：//www.rfc-editor .org / info / rfc6709>。
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972, DOI 10.17487/RFC6972, July 2013, <http://www.rfc-editor.org/info/rfc6972>.
[RFC6972] Zhang、Y。およびN. Zong、「問題の声明とピアツーピアストリーミングプロトコル（PPSP）の要件」、RFC 6972、DOI 10.17487 / RFC6972、2013年7月、<http：//www.rfc -editor.org/info/rfc6972>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[SARACEN] Sarecen P2P, <http://www.saracen-p2p.eu/>.
[SARACEN] Sarecen P2P、<http://www.saracen-p2p.eu/>。
Acknowledgments
謝辞
The authors appreciate the contributions made by Yingjie Gu in the early stages of the specification. Also, they thank the following people for their help and comments: Zhang Yunfei, Liao Hongluan, Roni Even, Dave Cottlehuber, Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song Haibin, Chen Wei, Zhijia Chen, Christian Schmidt, Lars Eggert, David Harrington, Henning Schulzrinne, Kangheng Wu, Martin Stiemerling, Jianyin Zhang, Johan Pouwelse, Riccardo Petrocco, and Arno Bakker.
著者は、仕様の初期段階でYingjie Guが行った貢献に感謝します。また、彼らの助けとコメントに対して次の人々に感謝します：Zhang Yunfei、Liao Hongluan、Roni Even、Dave Cottlehuber、Bhumip Khasnabish、Wu Yichuan、Peng Jin 、Chi Jing、Zong Ning、Song Haibin、Chen Wei、Zhijia Chen、Christian Schmidt、Lars Eggert、David Harrington、Henning Schulzrinne、Kangheng Wu、Martin Stiemerling、Jianyin Zhang、Johan Pouwelse、Riccardo Petrocco、Arno Bakker。
The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the SARACEN project [SARACEN], the European Commission, Huawei, or China Mobile.
ここに含まれる見解と結論は著者の見解であり、サラセンプロジェクト[SARACEN]、欧州委員会、Huawei、またはChina Mobileの公式のポリシーまたは推奨を明示または暗示するものとして必ずしも解釈してはなりません。
Authors' Addresses
著者のアドレス
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Mario Serafim Nunes IST/INESC-ID/INOV Rua Alves Redol, n.9 1000-029 Lisboa Portugal Phone: +351.213100256 Email: mario.nunes@inov.pt
マリオセラフィムヌネスIST / INESC-ID / INOV Rua Alves Redol、n.9 1000-029 Lisboa Portugal電話：+351.213100256メール：mario.nunes@inov.pt
Jinwei Xia Huawei Nanjing, Baixia District 210001 China Phone: +86-025-86622310 Email: xiajinwei@huawei.com
jin is X IA hu AはNaN北京、BA iは210001地区の下です中国電話：+ 86-025-86622310メール：Xia Jinwei@Huawei.com
Rachel Huang (editor) Huawei Email: rachel.huang@huawei.com
Rachel Huang（editor）hu A is email：Rachel。黄@ Huawei.com
Joao P. Taveira IST/INOV Email: joao.silva@inov.pt
Joao P. Taveira IST / INOVメール：joao.silva@inov.pt
Deng Lingli China Mobile Email: denglingli@chinamobile.com
中国での電子メールGL ingモバイルメール：Deng Lingli @ China Mobile.com