[要約] RFC 7019は、RELOADプロトコルにおけるアプリケーション層マルチキャスト拡張に関するものであり、その目的はRELOADを使用してアプリケーション層でマルチキャスト通信をサポートすることです。
Internet Research Task Force (IRTF) J. Buford
Request for Comments: 7019 Avaya Labs Research
Category: Experimental M. Kolberg, Ed.
ISSN: 2070-1721 University of Stirling
September 2013
Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)
LOcation And Discovery（RELOAD）を再ソースするためのアプリケーション層マルチキャスト拡張機能
Abstract
概要
We define a REsource LOcation And Discovery (RELOAD) Usage for Application-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast.
ALMをサポートするために、アプリケーションレイヤーマルチキャスト（ALM）のREsource LOcation And Discovery（RELOAD）の使用法と、RELOAD試験的メッセージタイプへのマッピングを定義します。 ALM Usageは、オーバーレイに依存しない方法でさまざまなALM制御アルゴリズムをサポートすることを目的としています。 ScribeとP2PCastに基づいて、2つのサンプルアルゴリズムが定義されています。
This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).
このドキュメントは、Scalable Adaptive Multicast Research Group（SAM RG）の製品です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Scalable Adaptive Multicast Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、Internet Research Task Force（IRTF）のScalable Adaptive Multicast Research Groupのコンセンサスを表しています。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション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/rfc7019.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7019で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Definitions .....................................................5
2.1. Overlay Network ............................................5
2.2. Overlay Multicast ..........................................5
2.3. Source-Specific Multicast (SSM) ............................6
2.4. Any-Source Multicast (ASM) .................................6
2.5. Peer .......................................................6
3. Assumptions .....................................................6
3.1. Overlay ....................................................6
3.2. Overlay Multicast ..........................................7
3.3. RELOAD .....................................................7
3.4. NAT ........................................................7
3.5. Tree Topology ..............................................7
4. Architecture Extensions to RELOAD ...............................7
5. RELOAD ALM Usage ................................................9
6. ALM Tree Control Signaling ......................................9
7. ALM Messages Mapped to RELOAD ..................................11
7.1. Introduction ..............................................11
7.2. Tree Lifecycle Messages ...................................12
7.2.1. CreateALMTree ......................................12
7.2.2. CreateALMTreeResponse ..............................13
7.2.3. Join ...............................................13
7.2.4. JoinAccept (Join Response) .........................14
7.2.5. JoinReject (Join Response) .........................15
7.2.6. JoinConfirm ........................................15
7.2.7. JoinConfirmResponse ................................16
7.2.8. JoinDecline ........................................16
7.2.9. JoinDeclineResponse ................................16
7.2.10. Leave .............................................17
7.2.11. LeaveResponse .....................................17
7.2.12. Reform or Optimize Tree ...........................17
7.2.13. ReformResponse ....................................18
7.2.14. Heartbeat .........................................18
7.2.15. Heartbeat Response ................................18
7.2.16. NodeQuery .........................................19
7.2.17. NodeQueryResponse .................................19
7.2.18. Push ..............................................21
7.2.19. PushResponse ......................................22
8. Scribe Algorithm ...............................................22
8.1. Overview ..................................................22
8.2. Create ....................................................23
8.3. Join ......................................................24
8.4. Leave .....................................................24
8.5. JoinConfirm ...............................................24
8.6. JoinDecline ...............................................24
8.7. Multicast .................................................24
9. P2PCast Algorithm ..............................................25
9.1. Overview ..................................................25
9.2. Message Mapping ...........................................25
9.3. Create ....................................................26
9.4. Join ......................................................26
9.5. Leave .....................................................28
9.6. JoinConfirm ...............................................28
9.7. Multicast .................................................28
10. Message Format ................................................28
10.1. ALMHeader Definition .....................................30
10.2. ALMMessageContents Definition ............................31
10.3. Response Codes ...........................................31
11. Examples ......................................................32
11.1. Create Tree ..............................................32
11.2. Join Tree ................................................33
11.3. Leave Tree ...............................................35
11.4. Push Data ................................................35
12. Kind Definitions ..............................................36
12.1. ALMTree Kind Definition ..................................36
13. RELOAD Configuration File Extensions ..........................37
14. IANA Considerations ...........................................37
14.1. ALM Algorithm Types ......................................37
14.2. Message Code Registration ................................38
14.3. Error Code Registration ..................................38
15. Security Considerations .......................................39
16. Acknowledgements ..............................................40
17. References ....................................................40
17.1. Normative Reference ......................................40
17.2. Informative References ...................................40
The concept of scalable adaptive multicast includes both scaling properties and adaptability properties. Scalability is intended to cover:
スケーラブルなアダプティブマルチキャストの概念には、スケーリングプロパティと適応性プロパティの両方が含まれます。スケーラビリティの対象は次のとおりです。
o large group size
o 大人数
o large numbers of small groups
o 多数の小グループ
o rate of group membership change
o グループメンバーシップの変更率
o admission control for QoS
o QoSのアドミッションコントロール
o use with network-layer QoS mechanisms
o ネットワーク層のQoSメカニズムで使用
o varying degrees of reliability
o さまざまな程度の信頼性
o trees connecting nodes over the global Internet
o グローバルインターネットを介してノードを接続するツリー
Adaptability includes
適応性には
o use of different control mechanisms for different multicast trees depending on initial application parameters or application classes
o 初期アプリケーションパラメータまたはアプリケーションクラスに応じて、異なるマルチキャストツリーに異なる制御メカニズムを使用する
o changing multicast tree structure depending on changes in application requirements, network conditions, and membership
o アプリケーション要件、ネットワーク条件、およびメンバーシップの変更に応じてマルチキャストツリー構造を変更する
Application-Layer Multicast (ALM) has been demonstrated to be a viable multicast technology where native multicast isn't available. Many ALM designs have been proposed. This ALM Usage focuses on:
Application-Layer Multicast（ALM）は、ネイティブマルチキャストが利用できない実行可能なマルチキャストテクノロジーであることが実証されています。多くのALM設計が提案されています。このALMの使用法は、以下に焦点を当てています。
o ALM implemented in RELOAD-based overlays
o RELOADベースのオーバーレイに実装されたALM
o Support for a variety of ALM control algorithms
o さまざまなALM制御アルゴリズムのサポート
o Providing a basis for defining a separate hybrid ALM RELOAD Usage
o 個別のハイブリッドALM RELOAD使用法を定義するための基礎を提供する
RELOAD [RELOAD] has an application extension mechanism in which a new type of application defines a Usage. A RELOAD Usage defines a set of data types and rules for their use. In addition, this document describes additional message types and a new ALM algorithm plugin architectural component.
RELOAD [RELOAD]には、新しいタイプのアプリケーションがUsageを定義するアプリケーション拡張メカニズムがあります。 RELOAD Usageは、使用のための一連のデータ型とルールを定義します。さらに、このドキュメントでは、追加のメッセージタイプと新しいALMアルゴリズムプラグインのアーキテクチャコンポーネントについて説明します。
This document represents the consensus of the SAM RG. It was repeatedly discussed within the research group, as well as with other Application-Layer Multicast experts.
このドキュメントは、SAM RGのコンセンサスを表しています。研究グループ内や他のアプリケーションレイヤーマルチキャストの専門家と繰り返し議論されました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
We adopt the terminology defined in Section 3 of [RELOAD], specifically the distinction between "node", "peer", and "client".
[RELOAD]のセクション3で定義された用語、特に「ノード」、「ピア」、「クライアント」の区別を採用します。
Overlay network: An application-layer virtual or logical network with addressable end points that provides connectivity, routing, and messaging between end points. Overlay networks are frequently used as a substrate for deploying new network services or for providing a routing topology not available from the underlying physical network. Many peer-to-peer systems are overlay networks that run on top of the Internet. In Figure 1, "P" indicates overlay peers, and peers are connected in a logical address space. The links shown in the figure represent predecessor/successor links. Depending on the overlay routing model, additional or different links may be present.
オーバーレイネットワーク：エンドポイント間の接続、ルーティング、およびメッセージングを提供するアドレス可能なエンドポイントを備えたアプリケーション層の仮想または論理ネットワーク。オーバーレイネットワークは、新しいネットワークサービスを展開したり、基盤となる物理ネットワークでは利用できないルーティングトポロジを提供したりするための基盤としてよく使用されます。多くのピアツーピアシステムは、インターネット上で実行されるオーバーレイネットワークです。図1で、「P」はオーバーレイピアを示し、ピアは論理アドレス空間で接続されています。図に示されているリンクは、先行リンク/後続リンクを表しています。オーバーレイルーティングモデルによっては、追加のリンクまたは異なるリンクが存在する場合があります。
P P P P P
..+....+....+...+.....+...
. +P
P+ .
. +P
..+....+....+...+.....+...
P P P P P
Figure 1: Overlay Network Example
図1：オーバーレイネットワークの例
Overlay Multicast (OM): Hosts participating in a multicast session form an overlay network and utilize unicast connections among pairs of hosts for data dissemination [BUFORD2009] [KOLBERG2010] [BUFORD2008]. The hosts in overlay multicast exclusively handle group management, routing, and tree construction, without any support from Internet routers. This is also commonly known as Application-Layer Multicast (ALM) or End-System Multicast (ESM). We call systems that use proxies connected in an overlay multicast backbone "proxied overlay multicast" or POM.
オーバーレイマルチキャスト（OM）：マルチキャストセッションに参加しているホストはオーバーレイネットワークを形成し、ホストのペア間のユニキャスト接続を利用してデータを配信します[BUFORD2009] [KOLBERG2010] [BUFORD2008]。オーバーレイマルチキャストのホストは、グループ管理、ルーティング、およびツリー構築のみを処理し、インターネットルーターからのサポートはありません。これは一般に、アプリケーション層マルチキャスト（ALM）またはエンドシステムマルチキャスト（ESM）とも呼ばれます。オーバーレイマルチキャストバックボーンに接続されたプロキシを使用するシステムを「プロキシオーバーレイマルチキャスト」またはPOMと呼びます。
SSM tree: The creator of the tree is the source. It sends data messages to the tree root that are forwarded down the tree.
SSMツリー：ツリーの作成者がソースです。ツリーの下に転送されるデータメッセージをツリールートに送信します。
ASM tree: A node sending a data message sends the message to its parent and its children. Each node receiving a data message from one edge forwards it to the remaining tree edges to which it is connected.
ASMツリー：データメッセージを送信するノードは、その親と子にメッセージを送信します。 1つのエッジからデータメッセージを受信する各ノードは、それが接続されている残りのツリーエッジに転送します。
Peer: An autonomous end system that is connected to the physical network and participates in and contributes resources to overlay construction, routing, and maintenance. Some peers may also perform additional roles such as connection relays, super nodes, NAT traversal assistance, and data storage.
ピア：物理ネットワークに接続され、オーバーレイの構築、ルーティング、メンテナンスに参加し、リソースを提供する自律的なエンドシステム。一部のピアは、接続リレー、スーパーノード、NATトラバーサルアシスタンス、データストレージなどの追加の役割を実行する場合もあります。
Peers connect in a large-scale overlay, which may be used for a variety of peer-to-peer applications in addition to multicast sessions. Peers may assume additional roles in the overlay beyond participation in the overlay and in multicast trees. We assume a single-structured overlay routing algorithm is used. Any of a variety of multi-hop, one-hop, or variable-hop overlay algorithms could be used.
ピアは大規模なオーバーレイで接続します。これは、マルチキャストセッションに加えて、さまざまなピアツーピアアプリケーションに使用できます。ピアは、オーバーレイおよびマルチキャストツリーへの参加以外に、オーバーレイで追加の役割を担う場合があります。単一構造のオーバーレイルーティングアルゴリズムが使用されることを想定しています。さまざまなマルチホップ、ワンホップ、または可変ホップのオーバーレイアルゴリズムを使用できます。
Castro, et al. [CASTRO2003] compared multi-hop overlays and found that tree-based construction in a single overlay outperformed using separate overlays for each multicast session. We use a single overlay rather than separate overlays per multicast session.
カストロ他[CASTRO2003]はマルチホップオーバーレイを比較し、単一のオーバーレイでのツリーベースの構築が、マルチキャストセッションごとに個別のオーバーレイを使用してパフォーマンスが向上することを発見しました。マルチキャストセッションごとに個別のオーバーレイではなく、単一のオーバーレイを使用します。
An overlay multicast algorithm may leverage the overlay's mechanism for maintaining overlay state in the face of churn. For example, a peer may store a number of DHT (Distributed Hash Table) entries. When the peer gracefully leaves the overlay, it transfers those entries to the nearest peer. When another peer joins that is closer to some of the entries than the current peer that holds those entries, than those entries are migrated. Overlay churn affects multicast trees as well; remedies include automatic migration of the tree state and automatic rejoin operations for dislocated child nodes.
オーバーレイマルチキャストアルゴリズムは、チャーンに直面してもオーバーレイの状態を維持するためのオーバーレイのメカニズムを活用できます。たとえば、ピアはいくつかのDHT（分散ハッシュテーブル）エントリを格納できます。ピアがオーバーレイを適切に離れると、それらのエントリが最も近いピアに転送されます。それらのエントリを保持している現在のピアよりもいくつかのエントリに近い別のピアが参加すると、それらのエントリは移行されます。オーバーレイチャーンは、マルチキャストツリーにも影響します。救済策には、ツリー状態の自動移行と、位置がずれた子ノードの自動再結合操作が含まれます。
The overlay supports concurrent multiple multicast trees. The limit on the number of concurrent trees depends on peer and network resources and is not an intrinsic property of the overlay.
オーバーレイは、複数のマルチキャストツリーを同時にサポートします。同時ツリー数の制限は、ピアとネットワークのリソースに依存し、オーバーレイの固有のプロパティではありません。
We use RELOAD [RELOAD] as the peer-to-peer (P2P) overlay for data storage and the mechanism by which the peers interconnect and route messages. RELOAD is a generic P2P overlay, and application support is defined by profiles called Usages.
RELOAD [RELOAD]は、データストレージのピアツーピア（P2P）オーバーレイと、ピアが相互接続してメッセージをルーティングするメカニズムのオーバーレイとして使用します。 RELOADは一般的なP2Pオーバーレイであり、アプリケーションサポートはUsagesと呼ばれるプロファイルによって定義されます。
Some nodes in the overlay may be in a private address space and behind firewalls. We use the RELOAD mechanisms for NAT traversal. We permit clients to be leaf nodes in an ALM tree.
オーバーレイの一部のノードは、プライベートアドレス空間にあり、ファイアウォールの背後にある場合があります。 NATトラバーサルにはRELOADメカニズムを使用します。クライアントがALMツリーのリーフノードになることを許可します。
All tree control messages are routed in the overlay. Two types of data or media topologies are envisioned: 1) tree edges are paths in the overlay, and 2) tree edges are direct connections between a parent and child peer in the tree, formed using the RELOAD AppAttach method.
すべてのツリー制御メッセージはオーバーレイでルーティングされます。 2つのタイプのデータまたはメディアトポロジが想定されています。1）ツリーエッジはオーバーレイ内のパスであり、2）ツリーエッジはRELOAD AppAttachメソッドを使用して形成されたツリー内の親ピアと子ピア間の直接接続です。
There are two changes as depicted in Figure 2. New ALM messages are mapped to RELOAD Message Transport using the RELOAD experimental message type. A plugin for ALM algorithms handles the ALM state and control. The ALM algorithm is under control of the application via the Group API [COMMON-API].
図2に示すように2つの変更があります。新しいALMメッセージは、RELOAD試験的メッセージタイプを使用してRELOADメッセージトランスポートにマップされます。 ALMアルゴリズムのプラグインは、ALMの状態と制御を処理します。 ALMアルゴリズムは、Group API [COMMON-API]を介してアプリケーションの制御下にあります。
+---------+
|Group API|
+---------+
|
------------------- Application ------------------------
+-------+ |
| ALM | |
| Usage | |
+-------+ |
-------------- Messaging Service Boundary --------------
|
+--------+ +-----------+---------+ +---------+
| Storage|<---> | RELOAD | ALM |<-->| ALM Alg |
+--------+ | Message | Messages| +---------+
^ | Transport | |
| +-----------+---------+
v | |
+-------------+ |
| Topology | |
| Plugin | |
+-------------+ |
^ |
v v
+-------------------+
| Forwarding & |
| Link Management |
+-------------------+
---------- Overlay Link Service Boundary --------------
Figure 2: RELOAD Architecture Extensions
図2：RELOADアーキテクチャ拡張
The ALM components interact with RELOAD as follows:
ALMコンポーネントは、RELOADと次のように相互作用します。
o ALM uses the RELOAD data storage functionality to store an ALMTree instance when a new ALM tree is created in the overlay and to retrieve ALMTree instance(s) for existing ALM trees.
o ALMはRELOADデータストレージ機能を使用して、オーバーレイに新しいALMツリーが作成されたときにALMTreeインスタンスを格納し、既存のALMツリーのALMTreeインスタンスを取得します。
o ALM applications and management tools may use the RELOAD data storage functionality to store diagnostic information about the operation of trees, including average number of trees, delay from source to leaf nodes, bandwidth use, and packet loss rate. In addition, diagnostic information may include statistics specific to the tree root or to any node in the tree.
o ALMアプリケーションと管理ツールは、RELOADデータストレージ機能を使用して、ツリーの平均数、送信元からリーフノードへの遅延、帯域幅の使用、パケット損失率など、ツリーの動作に関する診断情報を保存できます。さらに、診断情報には、ツリールートまたはツリー内の任意のノードに固有の統計が含まれる場合があります。
Applications of RELOAD are restricted in the data types that can be stored in the DHT. The profile of accepted data types for an application is referred to as a Usage. RELOAD is designed so that new applications can easily define new Usages. New RELOAD Usages are needed for multicast applications since the data types in base RELOAD and existing Usages are not sufficient.
RELOADのアプリケーションは、DHTに格納できるデータ型に制限されています。アプリケーションで受け入れられるデータ型のプロファイルは、使用法と呼ばれます。 RELOADは、新しいアプリケーションが新しい使用法を簡単に定義できるように設計されています。ベースRELOADのデータ型と既存の使用法では不十分なため、マルチキャストアプリケーションには新しいRELOAD使用法が必要です。
We define an ALM Usage in RELOAD. This ALM Usage is sufficient for applications that require ALM functionality in the overlay. Figure 2 shows the internal structure of the ALM Usage. This contains the Group API ([COMMON-API]), an ALM algorithm plugin (e.g., Scribe), and the ALM messages that are then sent out to the RELOAD network.
RELOADでALMの使用法を定義します。このALMの使用法は、オーバーレイでALM機能を必要とするアプリケーションに十分です。図2に、ALMの使用法の内部構造を示します。これには、グループAPI（[COMMON-API]）、ALMアルゴリズムプラグイン（Scribeなど）、およびRELMネットワークに送信されるALMメッセージが含まれます。
A RELOAD Usage is required [RELOAD] to define the following:
以下を定義するには、RELOADの使用法が必要です[RELOAD]。
o Kind-ID and code points
o 種類IDとコードポイント
o data structures for each Kind
o 各種類のデータ構造
o access control rules for each Kind
o 各種類のアクセス制御ルール
o the Resource Name used to hash to the Resource ID that determines where the Kind is stored
o 種類が格納される場所を決定するリソースIDへのハッシュに使用されるリソース名
o address restoration after recovery from a network partition (to form a single coherent network)
o ネットワークパーティションからの復旧後のアドレス復元（単一のコヒーレントネットワークを形成するため）
o the types of connections that can be initiated using AppConnect
o AppConnectを使用して開始できる接続のタイプ
An ALM group_id is a RELOAD node_id. The owner of an ALM group creates a RELOAD node_id as specified in [RELOAD]. This means that a group_id is used as a RELOAD Destination for overlay routing purposes.
ALM group_idはRELOAD node_idです。 ALMグループの所有者は、[RELOAD]で指定されたRELOAD node_idを作成します。これは、group_idがオーバーレイルーティングの目的でRELOAD宛先として使用されることを意味します。
Peers use the overlay to support ALM operations such as:
ピアはオーバーレイを使用して、次のようなALM操作をサポートします。
o CreateALMTree
o CreateALMTree
o Join
o 参加する
o Leave
o 去る
o Reform or optimize tree There are a variety of algorithms for peers to form multicast trees in the overlay. The approach presented here permits multiple such algorithms to be supported in the overlay since different algorithms may be more suitable for certain application requirements; the approach also supports experimentation. Therefore, overlay messaging corresponding to the set of overlay multicast operations MUST carry algorithm identification information.
oツリーの再構成または最適化ピアがオーバーレイにマルチキャストツリーを形成するためのさまざまなアルゴリズムがあります。ここに示すアプローチでは、さまざまなアルゴリズムが特定のアプリケーション要件に適している場合があるため、オーバーレイで複数のそのようなアルゴリズムをサポートできます。このアプローチは実験もサポートします。したがって、オーバーレイマルチキャスト操作のセットに対応するオーバーレイメッセージングは、アルゴリズム識別情報を運ぶ必要があります。
For example, for small groups, the join point might be directly assigned by the rendezvous point, while for large trees the Join request might be propagated down the tree with candidate parents forwarding their position directly to the new node.
たとえば、小さなグループの場合、参加ポイントはランデブーポイントによって直接割り当てられる可能性がありますが、大きなツリーの場合、Join要求は、親候補が新しいノードに直接その位置を転送することでツリーの下に伝播される可能性があります。
Here is a simplistic notation for forming a multicast tree in the overlay. Its main advantage is the use of the overlay for routing both control and data messages. The group creator does not have to be the root of the tree or even in the tree. It does not consider per-node load, admission control, or alternative paths. After the creation of a tree, the group_id is expected to be advertised or distributed out of band, perhaps by publishing in the DHT. Similarly, joining peers will discover the group_id out of band, perhaps by a lookup in the tree.
以下は、オーバーレイでマルチキャストツリーを形成するための単純な表記です。その主な利点は、制御メッセージとデータメッセージの両方をルーティングするためのオーバーレイの使用です。グループの作成者は、ツリーのルートである必要はありません。ノードごとの負荷、アドミッションコントロール、または代替パスは考慮されません。ツリーの作成後、group_idは、おそらくDHTで公開することにより、帯域外でアドバタイズまたは配布されることが予想されます。同様に、参加しているピアは、おそらくツリー内のルックアップによって、帯域外でgroup_idを検出します。
As stated earlier, multiple algorithms will coexist in the overlay.
前述したように、オーバーレイには複数のアルゴリズムが共存します。
1. Peer that initiates multicast group:
1. マルチキャストグループを開始するピア：
group_id = create(); // Allocate a unique group_id. // The root is the nearest // peer in the overlay.
group_id = create(); //一意のgroup_idを割り当てます。 //ルートはオーバーレイ内の最も近い//ピアです。
2. Any joining peer:
2. 参加ピア：
joinTree(group_id); // sends "join group_id" message
The overlay routes the Join request using the overlay routing mechanism toward the peer with the nearest ID to the group_id. This peer is the root. Peers on the path to the root join the tree as forwarding points.
オーバーレイは、オーバーレイルーティングメカニズムを使用して、Joinリクエストをgroup_idに最も近いIDを持つピアにルーティングします。このピアがルートです。ルートへのパス上のピアは、転送ポイントとしてツリーに参加します。
3. Leave Tree:
3. ツリーを離れる：
leaveTree(group_id); // removes this node from the tree Propagates a Leave request to each child node and to the parent node. If the parent node is a forwarding node and this is its last child, then it propagates a Leave request to its parent. A child node receiving a Leave request from a parent sends a Join request to the group_id.
leaveTree（group_id）; //このノードをツリーから削除します。Leaveリクエストを各子ノードと親ノードに伝播します。親ノードが転送ノードであり、これがその最後の子である場合、その親にLeave要求を伝播します。親からの脱退要求を受信した子ノードは、結合要求をgroup_idに送信します。
4. Message forwarding:
4. メッセージ転送：
multicastMsg(group_id, msg);
multicastMsg（group_id、msg）;
For message forwarding, both Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) approaches may be used.
メッセージ転送では、Any-Source Multicast（ASM）とSource-Specific Multicast（SSM）の両方のアプローチを使用できます。
In this document, we define messages for overlay multicast tree creation, using an existing protocol (RELOAD) in the P2P-SIP WG [RELOAD] for a universal structured peer-to-peer overlay protocol. RELOAD provides the mechanism to support a number of overlay topologies. Hence, the overlay multicast framework defined in this document can be used with P2P-SIP and makes the Scalable Adaptive Multicast (SAM) framework overlay agnostic.
このドキュメントでは、ユニバーサル構造化ピアツーピアオーバーレイプロトコルのP2P-SIP WG [RELOAD]で既存のプロトコル（RELOAD）を使用して、オーバーレイマルチキャストツリーを作成するためのメッセージを定義します。 RELOADは、いくつかのオーバーレイトポロジをサポートするメカニズムを提供します。したがって、このドキュメントで定義されているオーバーレイマルチキャストフレームワークはP2P-SIPで使用でき、Scalable Adaptive Multicast（SAM）フレームワークオーバーレイにとらわれません。
As discussed in the SAM requirements document [SAM-GENERIC], there are a variety of ALM tree formation and tree maintenance algorithms. The intent of this specification is to be algorithm agnostic, similar to how RELOAD is overlay algorithm agnostic. We assume that all control messages are propagated using overlay routed messages.
SAM要件ドキュメント[SAM-GENERIC]で説明されているように、さまざまなALMツリー形成およびツリーメンテナンスアルゴリズムがあります。この仕様の意図は、RELOADがオーバーレイアルゴリズムに依存しないのと同様に、アルゴリズムに依存しないことです。すべての制御メッセージは、オーバーレイルーティングメッセージを使用して伝播されると想定しています。
The message types needed for ALM behavior are divided into the following categories:
ALMの動作に必要なメッセージタイプは、次のカテゴリに分類されます。
o Tree lifecycle (Create, Join, Leave, Reform, Heartbeat)
o ツリーのライフサイクル（作成、参加、脱退、改革、ハートビート）
o Peer region and multicast properties
o ピアリージョンとマルチキャストプロパティ
The message codes are defined in Section 14.2 of this document. Messages are mapped to the RELOAD experimental message type.
メッセージコードは、このドキュメントのセクション14.2で定義されています。メッセージは、RELOAD試験運用メッセージタイプにマッピングされます。
In the following sections, the protocol messages as mapped to RELOAD are discussed. Detailed example message flows are provided in Section 11.
次のセクションでは、RELOADにマップされたプロトコルメッセージについて説明します。メッセージフローの詳細な例は、セクション11に記載されています。
In the following descriptions, we use the datatype Dictionary, which is a set of opaque values indexed by an opaque key with one value for each key. A single dictionary entry is represented by a DictionaryEntry as defined in Section 7.2.3 of the RELOAD document [RELOAD]. The Dictionary datatype is defined as follows:
次の説明では、データ型ディクショナリを使用します。これは、各キーに1つの値を持つ不透明なキーによってインデックスが付けられた不透明な値のセットです。単一の辞書エントリは、RELOADドキュメント[RELOAD]のセクション7.2.3で定義されているDictionaryEntryによって表されます。辞書データ型は次のように定義されます。
struct {
DictionaryEntry elements<0..2^16-1>;
} Dictionary;
Peers use the overlay to transmit ALM operations defined in this section.
ピアは、オーバーレイを使用して、このセクションで定義されたALM操作を送信します。
A new ALM tree is created in the overlay with the identity specified by group_id. The common interpretation in a DHT-based overlay of group_id is that the peer with a peer_id closest to and less than the group_id is the root of the tree. However, other overlay types are supported. The tree has no children at the time it is created.
新しいALMツリーが、group_idで指定されたIDでオーバーレイに作成されます。 group_idのDHTベースのオーバーレイでの一般的な解釈は、group_idに最も近く、それよりも小さいpeer_idを持つピアがツリーのルートであるというものです。ただし、他のオーバーレイタイプはサポートされています。作成時のツリーには子がありません。
The group_id is generated from a well-known session key to be used by other peers to address the multicast tree in the overlay. The generation of the group_id from the session_key MUST be done using the overlay's ID-generation mechanism.
group_idは、オーバーレイのマルチキャストツリーをアドレス指定するために他のピアが使用する既知のセッションキーから生成されます。 session_keyからのgroup_idの生成は、オーバーレイのID生成メカニズムを使用して行う必要があります。
struct {
node_id peer_id;
opaque session_key<0..2^32-1>;
node_id group_id;
Dictionary options;
} ALMTree;
peer_id: overlay address of the peer that creates the multicast tree.
peer_id：マルチキャストツリーを作成するピアのオーバーレイアドレス。
session_key: a well-known string that when hashed using the overlay's ID-generation algorithm produces the group_id.
session_key：オーバーレイのID生成アルゴリズムを使用してハッシュするとgroup_idを生成する既知の文字列。
group_id: overlay address of the root of the tree.
group_id：ツリーのルートのオーバーレイアドレス。
options: name-value list of properties to be associated with the tree, such as the maximum size of the tree, restrictions on peers joining the tree, latency constraints, preference for distributed or centralized tree formation and maintenance, and Heartbeat interval.
オプション：ツリーに関連付けられるプロパティの名前と値のリスト。たとえば、ツリーの最大サイズ、ツリーに参加するピアの制限、レイテンシの制約、分散または集中型ツリーの形成とメンテナンスの優先順位、ハートビート間隔など。
Tree creation is subject to access control since it involves a Store operation. The NODE-MATCH access policy defined in Section 7.3.2 of [RELOAD] is used.
ツリーの作成にはストア操作が含まれるため、アクセス制御の対象になります。 [RELOAD]のセクション7.3.2で定義されたNODE-MATCHアクセスポリシーが使用されます。
A successful CreateALMTree causes an ALMTree structure to be stored in the overlay at the node G responsible for the group_id. This node G performs the RELOAD-defined StoreReq operation as a side effect of performing the CreateALMTree. If the StoreReq fails, the CreateALMTree fails too.
CreateALMTreeが成功すると、ALMTree構造がgroup_idを担当するノードGのオーバーレイに格納されます。このノードGは、CreateALMTreeを実行する副作用として、RELOAD定義のStoreReq操作を実行します。 StoreReqが失敗すると、CreateALMTreeも失敗します。
After a successful CreateALMTree, peers can use the RELOAD Fetch method to retrieve the ALMTree struct at address group_id. The ALMTree Kind is defined in Section 12.1.
CreateALMTreeが成功した後、ピアはRELOAD Fetchメソッドを使用して、アドレスgroup_idにあるALMTree構造体を取得できます。 ALMTreeの種類は、セクション12.1で定義されています。
After receiving a CreateALMTree message from node S, the peer sends a CreateALMTreeResponse to node S.
ノードSからCreateALMTreeメッセージを受信した後、ピアはCreateALMTreeResponseをノードSに送信します。
struct {
Dictionary options;
} CreateALMTreeResponse;
options: A node may provide algorithm-dependent parameters about the created tree to the requesting node.
オプション：ノードは、作成されたツリーに関するアルゴリズムに依存するパラメーターを要求側ノードに提供できます。
Join causes the distributed algorithm for peer join of a specific ALM group to be invoked. The definition of the Join request is shown below. If successful, the joining peer is notified of one or more candidate parent peers in one or more JoinAccept messages. The particular ALM join algorithm is not specified in this protocol.
結合により、特定のALMグループのピア結合の分散アルゴリズムが呼び出されます。参加リクエストの定義を以下に示します。成功した場合、参加ピアには、1つ以上のJoinAcceptメッセージで1つ以上の候補親ピアが通知されます。特定のALM結合アルゴリズムは、このプロトコルでは指定されていません。
struct {
node_id peer_id;
node_id group_id;
Dictionary options;
} Join;
peer_id: overlay address of joining/leaving peer
peer_id：参加/離脱ピアのオーバーレイアドレス
group_id: overlay address of the root of the tree
group_id：ツリーのルートのオーバーレイアドレス
options: name-value list of options proposed by joining peer RELOAD is a request-response protocol. Consequently, the messages JoinAccept and JoinReject (defined below) are matching responses for Join. If JoinReject is received, then no further action on this request is carried out. If JoinAccept is received, then either a JoinConfirm or a JoinDecline message (see below) is sent. The matching response for JoinConfirm is JoinConfirmResponse. The matching response for JoinDecline is JoinDeclineResponse.
options：ピアRELOADに参加することで提案されるオプションの名前と値のリストは、要求と応答のプロトコルです。したがって、JoinAcceptおよびJoinReject（以下で定義）のメッセージは、Joinの応答と一致します。 JoinRejectを受信した場合、この要求に対してそれ以上のアクションは実行されません。 JoinAcceptが受信されると、JoinConfirmまたはJoinDeclineメッセージ（下記参照）が送信されます。 JoinConfirmに一致する応答は、JoinConfirmResponseです。 JoinDeclineに一致する応答は、JoinDeclineResponseです。
The following list shows the matching request-responses according to the request-response mechanism defined in [RELOAD].
次のリストは、[RELOAD]で定義されている要求/応答メカニズムに従って一致する要求/応答を示しています。
Join -- JoinAccept: Node C sends a Join request to node P. If node P accepts, it responds with JoinAccept.
参加-JoinAccept：ノードCはノードPに参加リクエストを送信します。ノードPが承認した場合、ノードCはJoinAcceptで応答します。
Join -- JoinReject: Node C sends a Join request to node P. If node P does not accept the Join request, it responds with JoinReject.
結合-JoinReject：ノードCはノードPに結合要求を送信します。ノードPが結合要求を受け入れない場合、ノードPはJoinRejectで応答します。
JoinConfirm -- JoinConfirmResponse: If node P sent node C a JoinAccept and node C confirms with a JoinConfirm request, then node P responds with a JoinConfirmResponse.
JoinConfirm-JoinConfirmResponse：ノードPがノードCにJoinAcceptを送信し、ノードCがJoinConfirmリクエストで確認した場合、ノードPはJoinConfirmResponseで応答します。
JoinDecline -- JoinDeclineResponse: If node P sent node C a JoinAccept and node C declines with a JoinDecline request, then node P responds with a JoinDeclineResponse.
JoinDecline-JoinDeclineResponse：ノードPがノードCにJoinAcceptを送信し、ノードCがJoinDeclineリクエストで拒否した場合、ノードPはJoinDeclineResponseで応答します。
Thus, Join, JoinConfirm, and JoinDecline are treated as requests as defined in RELOAD, are mapped to the RELOAD exp_a_req message, and are therefore retransmitted until either a retry limit is reached or a matching response received. JoinAccept, JoinReject, JoinConfirmResponse, and JoinDeclineResponse are treated as message responses as defined above and are mapped to the RELOAD exp_a_ans message.
したがって、Join、JoinConfirm、およびJoinDeclineは、RELOADで定義された要求として扱われ、RELOAD exp_a_reqメッセージにマップされるため、再試行制限に達するか、一致する応答が受信されるまで再送信されます。 JoinAccept、JoinReject、JoinConfirmResponse、およびJoinDeclineResponseは、上記で定義されたメッセージ応答として扱われ、RELOAD exp_a_ansメッセージにマップされます。
The Join behavior can be described as follows:
結合動作は次のように説明できます。
if(checkAccept(msg)) {
recvJoins.add(msg.source, msg.group_id)
SEND(JoinAccept(node_id, msg.source, msg.group_id))
}
JoinAccept tells the requesting joining peer that the indicated peer is available to act as its parent in the ALM tree specified by group_id, with the corresponding options specified. A peer MAY receive more than one JoinAccept from different candidate parent peers in the group_id tree. The peer accepts a peer as parent using a JoinConfirm message. A JoinAccept that receives neither a JoinConfirm nor JoinDecline message MUST expire. RELOAD implementations are able to read a local configuration file for settings. It is assumed that this file contains the timeout value to be used.
JoinAcceptは、要求された参加ピアに、指定されたピアがgroup_idで指定されたALMツリーの親として機能し、対応するオプションが指定されていることを通知します。ピアは、group_idツリーの異なる候補の親ピアから複数のJoinAcceptを受信する場合があります。ピアは、JoinConfirmメッセージを使用してピアを親として受け入れます。 JoinConfirmメッセージもJoinDeclineメッセージも受信しないJoinAcceptは、期限切れにする必要があります。 RELOAD実装は、設定用のローカル構成ファイルを読み取ることができます。このファイルには、使用されるタイムアウト値が含まれていると想定されています。
struct {
node_id parent_peer_id;
node_id child_peer_id;
node_id group_id;
Dictionary options;
} JoinAccept;
parent_peer_id: overlay address of a peer that accepts the joining peer
parent_peer_id：参加するピアを受け入れるピアのオーバーレイアドレス
child_peer_id: overlay address of joining peer
child_peer_id：参加するピアのオーバーレイアドレス
group_id: overlay address of the root of the tree
group_id：ツリーのルートのオーバーレイアドレス
options: name-value list of options accepted by parent peer
options：親ピアが受け入れるオプションの名前と値のリスト
A peer receiving a Join request responds with a JoinReject response to indicate the request is rejected.
Join要求を受信したピアは、JoinReject応答で応答して、要求が拒否されたことを示します。
A peer receiving a JoinAccept message that it wishes to accept MUST explicitly accept it using a JoinConfirm message before the expiration of a timer for the JoinAccept message. The joining peer MUST include only those options from the JoinAccept that it also accepts, completing the negotiation of options between the two peers.
受け入れることを希望するJoinAcceptメッセージを受信するピアは、JoinAcceptメッセージのタイマーが切れる前に、JoinConfirmメッセージを使用して明示的に受け入れる必要があります。参加するピアは、JoinAcceptからのオプションも含める必要があり、それも受け入れることで、2つのピア間のオプションのネゴシエーションを完了します。
struct {
node_id child_peer_id;
node_id parent_peer_id;
node_id group_id;
Dictionary options;
} JoinConfirm;
child_peer_id: overlay address of joining peer that is a child of the parent peer
child_peer_id：親ピアの子である参加ピアのオーバーレイアドレス
parent_peer_id: overlay address of the peer that is the parent of the joining peer group_id: overlay address of the root of the tree
parent_peer_id：参加するピアの親であるピアのオーバーレイアドレスgroup_id：ツリーのルートのオーバーレイアドレス
options: name-value list of options accepted by both peers
options：両方のピアが受け入れるオプションの名前と値のリスト
The JoinConfirm message behavior is described below:
JoinConfirmメッセージの動作を以下に説明します。
if(recvJoins.contains(msg.source,msg.group_id)){
if !(groups.contains(msg.group_id)) {
groups.add(msg.group_id)
SEND(msg,msg.group_id)
}
groups[msg.group_id].children.add(msg.source)
recvJoins.del(msg.source, msg.group_id)
}
A peer receiving a JoinConfirm message responds with a JoinConfirmResponse message.
JoinConfirmメッセージを受信するピアは、JoinConfirmResponseメッセージで応答します。
A peer receiving a JoinAccept message that it does not wish to accept MAY explicitly decline it using a JoinDecline message.
受け入れることを望まないJoinAcceptメッセージを受信するピアは、JoinDeclineメッセージを使用して明示的に拒否してもよい（MAY）。
struct {
node_id peer_id;
node_id parent_peer_id;
node_id group_id;
} JoinDecline;
peer_id: overlay address of joining peer that declines the JoinAccept
peer_id：JoinAcceptを拒否する参加ピアのオーバーレイアドレス
parent_peer_id: overlay address of the peer that issued a JoinAccept to this peer
parent_peer_id：このピアにJoinAcceptを発行したピアのオーバーレイアドレス
group_id: overlay address of the root of the tree
group_id：ツリーのルートのオーバーレイアドレス
The behavior of the JoinDecline message is described as follows:
JoinDeclineメッセージの動作は次のとおりです。
if(recvJoins.contains(msg.source,msg.group_id)) recvJoins.del(msg.source, msg.group_id)
if（recvJoins.contains（msg.source、msg.group_id））recvJoins.del（msg.source、msg.group_id）
A peer receiving a JoinConfirm message responds with a JoinDeclineResponse message.
JoinConfirmメッセージを受信するピアは、JoinDeclineResponseメッセージで応答します。
A peer that is part of an ALM tree identified by group_id that intends to detach from either a child or parent peer SHOULD send a Leave request to the peer from which it wishes to detach. A peer receiving a Leave request from a peer that is neither in its parent nor child lists SHOULD ignore the message.
子または親ピアのいずれかから切り離すつもりであるgroup_idによって識別されるALMツリーの一部であるピアは、切り離したいピアにLeaveリクエストを送信する必要があります（SHOULD）。親リストにも子リストにもないピアからLeaveリクエストを受信するピアは、メッセージを無視する必要があります。
struct {
node_id peer_id;
node_id group_id;
Dictionary options;
} Leave;
peer_id: overlay address of leaving peer
peer_id：離脱するピアのオーバーレイアドレス
group_id: overlay address of the root of the tree
group_id：ツリーのルートのオーバーレイアドレス
options: name-value list of options
オプション：オプションの名前と値のリスト
The behavior of the Leave request can be described as:
休暇申請の動作は次のように説明できます。
groups[msg.group_id].children.remove(msg.source) if (groups[msg.group].children = 0) SEND(msg,groups[msg.group_id].parent)
groups [msg.group_id] .children.remove（msg.source）if（groups [msg.group] .children = 0）SEND（msg、groups [msg.group_id] .parent）
A peer receiving a Leave request responds with a LeaveResponse message.
Leaveリクエストを受信したピアは、LeaveResponseメッセージで応答します。
This triggers a reorganization of either the entire tree or only a subtree. It MAY include hints to specific peers of recommended parent or child peers to which to reconnect. A peer receiving this message MAY ignore it, MAY propagate it to other peers in its subtree, and MAY invoke local algorithms for selecting preferred parent and/or child peers.
これにより、ツリー全体またはサブツリーのみの再編成がトリガーされます。再接続する推奨の親または子ピアの特定のピアへのヒントを含めることができます。このメッセージを受信するピアはそれを無視してもよいし、そのサブツリー内の他のピアにメッセージを伝播してもよいし、優先される親および/または子ピアを選択するためのローカルアルゴリズムを呼び出してもよい（MAY）。
struct {
node_id group_id;
node_id peer_id;
Dictionary options;
} Reform;
group_id: overlay address of the root of the tree peer_id: if omitted, then the tree is reorganized starting from the root; otherwise, it is reorganized only at the subtree identified by peer_id.
group_id：ツリーのルートのオーバーレイアドレスpeer_id：省略した場合、ツリーはルートから再編成されます。それ以外の場合は、peer_idで識別されるサブツリーでのみ再編成されます。
options: name-value list of options
オプション：オプションの名前と値のリスト
A peer receiving a Reform message responds with a ReformResponse.
Reformメッセージを受信するピアは、ReformResponseで応答します。
struct {
Dictionary options;
} ReformResponse;
options: algorithm-dependent information about the results of the Reform operation
オプション：Reform操作の結果に関するアルゴリズム依存情報
A child node signals to its adjacent parent nodes in the tree that it is alive. If a parent node does not receive a Heartbeat message within N Heartbeat time intervals, it MUST treat this as an explicit Leave request from the unresponsive peer. N is configurable. RELOAD implementations are able to read a local configuration file for settings. It is assumed that this file contains the value for N to be used.
子ノードは、ツリー内の隣接する親ノードに、生きていることを知らせます。親ノードがNハートビート時間間隔内にハートビートメッセージを受信しない場合は、これを無応答ピアからの明示的な脱退要求として処理する必要があります。 Nは構成可能です。 RELOAD実装は、設定用のローカル構成ファイルを読み取ることができます。このファイルには、使用されるNの値が含まれていると想定されています。
struct {
node_id peer_id_src;
node_id peer_id_dst;
node_id group_id;
Dictionary options;
} Heartbeat;
peer_id_src: source of Heartbeat
peer_id_src：Heartbeatのソース
peer_id_dst: destination of Heartbeat
peer_id_dst：ハートビートの宛先
group_id: overlay address of the root of the tree
group_id：ツリーのルートのオーバーレイアドレス
options: an algorithm may use the Heartbeat message to provide state information to adjacent nodes in the tree
オプション：アルゴリズムはハートビートメッセージを使用して、ツリー内の隣接ノードに状態情報を提供します。
A parent node responds with a HeartbeatResponse to a Heartbeat from a child node indicating that it has received the Heartbeat message.
親ノードは、子ノードからのハートビートに対してHeartbeatResponseで応答し、ハートビートメッセージを受信したことを示します。
The NodeQuery message is used to obtain information about the state and performance of the tree on a per-node basis. A set of nodes could be queried to construct a centralized view of the multicast trees, similar to a web crawler.
NodeQueryメッセージは、ノードごとにツリーの状態とパフォーマンスに関する情報を取得するために使用されます。ノードのセットをクエリして、Webクローラーと同様に、マルチキャストツリーの集中管理ビューを構築できます。
struct {
node_id peer_id_src;
node_id peer_id_dst;
} NodeQuery;
peer_id_src: source of query
peer_id_src：クエリのソース
peer_id_dst: destination of query
peer_id_dst：クエリの宛先
The response to a NodeQuery message contains a NodeStatistics instance for this node.
NodeQueryメッセージへの応答には、このノードのNodeStatisticsインスタンスが含まれています。
public struct {
uint32 node_lifetime;
uint32 total_number_trees;
uint16 number_algorithms_supported;
uint8 algorithms_supported[32];
TreeData max_tree_data;
uint16 number_active_trees;
TreeData tree_data<0..2^8-1>;
ImplementationInfo impl_info;
} NodeStatistics;
node_lifetime: time the node has been alive in seconds since last restart
node_lifetime：最後に再起動してからノードが存続していた時間（秒）
total_number_trees: total number of trees this node has been part of during the node lifetime
total_number_trees：ノードの存続期間中にこのノードが属していたツリーの総数
number_algorithms_supported: value between 0..2^16-1 corresponding to the number of algorithms supported
number_algorithms_supported：サポートされるアルゴリズムの数に対応する0..2 ^ 16-1の間の値
algorithms_supported: list of algorithms, each byte encoded using the corresponding algorithm code max_tree_data: data about tree with largest number of nodes that this node was part of. NodeQuery can be used to crawl all the nodes in an ALM tree to fill this field. This is intended to support monitoring, algorithm design, and general experimentation with ALM in RELOAD.
algorithm_supported：アルゴリズムのリスト、対応するアルゴリズムコードを使用してエンコードされた各バイトmax_tree_data：このノードが属していたノードの最大数を持つツリーに関するデータ。 NodeQueryを使用して、ALMツリー内のすべてのノードをクロールして、このフィールドを埋めることができます。これは、RELOADでの監視、アルゴリズム設計、およびALMの一般的な実験をサポートすることを目的としています。
number_active_trees: current number of trees that the node is part of
number_active_trees：ノードが属しているツリーの現在の数
tree_data: details of each active tree; the number of such is specified by number_active_trees
tree_data：各アクティブなツリーの詳細。そのような数はnumber_active_treesによって指定されます
impl_info: information about the implementation of this Usage
impl_info：この使用法の実装に関する情報
public struct {
uint32 tree_id;
uint8 algorithm;
node_id tree_root;
uint8 number_parents;
node_id parent<0..2^8-1>;
uint16 number_child_nodes;
node_id children<0..2^16-1>;
uint32 path_length_to_root;
uint32 path_delay_to_root;
uint32 path_delay_to_child;
} TreeData;
tree_id: the ID of the tree
tree_id：ツリーのID
algorithm: code identifying the multicast algorithm used by this tree
アルゴリズム：このツリーで使用されるマルチキャストアルゴリズムを識別するコード
tree_root: node_id of tree root, or 0 if unknown
tree_root：ツリールートのnode_id、不明の場合は0
number_parents: 0 .. 2^8-1 indicates number of parent nodes for this node
number_parents：0 .. 2 ^ 8-1は、このノードの親ノードの数を示します
parent: the RELOAD node_id of each parent node
parent：各親ノードのRELOAD node_id
number_child_nodes: 0..2^16-1 indicates number of children
number_child_nodes：0..2 ^ 16-1は子の数を示します
children: the RELOAD node_id of each child node
子：各子ノードのRELOAD node_id
path_length_to_root: number of overlay hops to the root of the tree
path_length_to_root：ツリーのルートへのオーバーレイホップの数
path_delay_to_root: RTT in milliseconds to root node path_delay_to_child: last measured RTT in milliseconds to child node with largest RTT
path_delay_to_root：ルートノードへのミリ秒単位のRTT path_delay_to_child：最大のRTTを持つ子ノードへの最後に測定されたミリ秒単位のRTT
public struct {
uint32 join_confirm_timeout;
uint32 heartbeat_interval;
uint32 heartbeat_response_timeout;
uint16 info_length;
uint8 info<0..2^16-1>;
} ImplementationInfo;
join_confirm_timeout: The default time for JoinConfirm/JoinDecline, intended to provide sufficient time for a Join request to receive all responses and confirm the best choice. Default value is 5000 msec. An implementation can change this value.
join_confirm_timeout：JoinConfirm / JoinDeclineのデフォルト時間。Joinリクエストがすべての応答を受信し、最良の選択を確認するための十分な時間を提供することを目的としています。デフォルト値は5000ミリ秒です。実装はこの値を変更できます。
heartbeat_interval: The default Heartbeat interval is 2000 msec. Different interoperating implementations could use different intervals.
heartbeat_interval：デフォルトのハートビート間隔は2000ミリ秒です。異なる相互運用実装では、異なる間隔を使用できます。
heartbeat_response_timeout: The default Heartbeat timeout is 5000 msec and is the max time between Heartbeat reports from an adjacent node in the tree at which point the Heartbeat is missed.
heartbeat_response_timeout：デフォルトのハートビートタイムアウトは5000ミリ秒で、ツリー内の隣接ノードからのハートビートレポート間の最大時間であり、この時点でハートビートが失われます。
info_length: length of the info field
info_length：情報フィールドの長さ
info: implementation-specific information, such as name of implementation, build version, and implementation-specific features
info：実装名、ビルドバージョン、実装固有の機能など、実装固有の情報
A peer sends arbitrary multicast data to other peers in the tree. Nodes in the tree forward this message to adjacent nodes in the tree in an algorithm-dependent way.
ピアは、ツリー内の他のピアに任意のマルチキャストデータを送信します。ツリー内のノードは、このメッセージをアルゴリズムに依存する方法でツリー内の隣接ノードに転送します。
struct {
node_id group_id;
uint8 priority;
uint32 length;
uint8 data<0..2^32-1>;
} Push;
group_id: overlay address of root of the ALM tree
group_id：ALMツリーのルートのオーバーレイアドレス
priority: the relative priority of the message; highest priority is 255. A node may ignore this field.
優先度：メッセージの相対的な優先度。最高の優先順位は255です。ノードはこのフィールドを無視できます。
length: length of the data field in bytes
length：データフィールドの長さ（バイト単位）
data: the data
データ：データ
In pseudocode, the behavior of Push can be described as:
疑似コードでは、Pushの動作は次のように説明できます。
foreach(groups[msg.group_id].children as node_id) SEND(msg,node_id) if memberOf(msg.group_id) invokeMessageHandler(msg.group_id, msg)
foreach（groups [msg.group_id] .children as node_id）SEND（msg、node_id）if memberOf（msg.group_id）invokeMessageHandler（msg.group_id、msg）
After receiving a Push message from node S, the receiving peer sends a PushResponse to node S.
ノードSからPushメッセージを受信した後、受信ピアはPushResponseをノードSに送信します。
struct {
Dictionary options;
} PushResponse;
options: A node may provide feedback to the sender about previous Push messages in some window, for example, the last N Push messages. The feedback could include, for each Push message received, the number of adjacent nodes that were forwarded the Push message and the number of adjacent nodes from which a PushResponse was received.
オプション：ノードは、ウィンドウの前のプッシュメッセージ、たとえば最後のNプッシュメッセージに関するフィードバックを送信者に提供する場合があります。フィードバックには、受信した各Pushメッセージについて、Pushメッセージが転送された隣接ノードの数と、PushResponseを受信した隣接ノードの数を含めることができます。
Figure 3 shows a mapping between RELOAD ALM messages (as defined in Section 5 of this document) and Scribe messages as defined in [CASTRO2002].
図3は、RELOAD ALMメッセージ（このドキュメントのセクション5で定義）と[CASTRO2002]で定義されたScribeメッセージの間のマッピングを示しています。
+---------+-------------------+-----------------+
| Section |RELOAD ALM Message | Scribe Message |
+---------+-------------------+-----------------+
| 7.2.1 | CreateALMTree | Create |
+---------+-------------------+-----------------+
| 7.2.3 | Join | Join |
+---------+-------------------+-----------------+
| 7.2.4 | JoinAccept | |
+---------+-------------------+-----------------+
| 7.2.6 | JoinConfirm | |
+---------+-------------------+-----------------+
| 7.2.8 | JoinDecline | |
+---------+-------------------+-----------------+
| 7.2.10 | Leave | Leave |
+---------+-------------------+-----------------+
| 7.2.12 | Reform | |
+---------+-------------------+-----------------+
| 7.2.14 | Heartbeat | |
+---------+-------------------+-----------------+
| 7.2.16 | NodeQuery | |
+---------+-------------------+-----------------+
| 7.2.18 | Push | Multicast |
+---------+-------------------+-----------------+
| | Note 1 | deliver |
+---------+-------------------+-----------------+
| | Note 1 | forward |
+---------+-------------------+-----------------+
| | Note 1 | route |
+---------+-------------------+-----------------+
| | Note 1 | send |
+---------+-------------------+-----------------+
Figure 3: Mapping to Scribe Messages
図3：Scribeメッセージへのマッピング
Note 1: These Scribe messages are handled by RELOAD messages.
注1：これらのScribeメッセージはRELOADメッセージによって処理されます。
The following sections describe the Scribe algorithm in more detail.
次のセクションでは、Scribeアルゴリズムについて詳しく説明します。
This message will create a group with group_id. This message MUST be delivered to the node whose node_id is closest to the group_id. This node becomes the rendezvous point and root for the new multicast tree. Groups MAY have multiple sources of multicast messages.
このメッセージは、group_idでグループを作成します。このメッセージは、node_idがgroup_idに最も近いノードに配信される必要があります。このノードは、新しいマルチキャストツリーのランデブーポイントおよびルートになります。グループには、マルチキャストメッセージの複数のソースがある場合があります。
To join a multicast tree, a node SHOULD send a Join request with the group_id as the key. This message gets routed by the overlay to the rendezvous point of the tree. If an intermediate node is already a forwarder for this tree, it SHOULD add the joining node as a child. Otherwise, the node SHOULD create a child table for the group and add the joining node. It SHOULD then send the Join request towards the rendezvous point terminating the Join request from the child.
マルチキャストツリーに参加するには、ノードはgroup_idをキーとして参加リクエストを送信する必要があります（SHOULD）。このメッセージは、オーバーレイによってツリーのランデブーポイントにルーティングされます。中間ノードがこのツリーのフォワーダーである場合は、参加ノードを子として追加する必要があります（SHOULD）。それ以外の場合、ノードはグループの子テーブルを作成して、参加ノードを追加する必要があります（SHOULD）。次に、子からの参加リクエストを終了するランデブーポイントに向けて参加リクエストを送信する必要があります。
To adapt the Scribe algorithm to the ALM Usage proposed here, after a Join request is accepted, a JoinAccept message MUST be returned to the joining node.
Scribeアルゴリズムをここで提案されているALMの使用法に適合させるには、Joinリクエストが受け入れられた後、JoinAcceptメッセージが参加ノードに返される必要があります。
When leaving a multicast group, a node SHOULD change its local state to indicate that it left the group. If the node has no children in its table, it MUST send a Leave request to its parent, from where it SHOULD travel up the multicast tree and stop at a node that still has children remaining after removing the leaving node.
マルチキャストグループを離れるとき、ノードはグループを離れたことを示すためにローカル状態を変更する必要があります（SHOULD）。ノードのテーブルに子がない場合、ノードは親にLeave要求を送信する必要があります。そこから、マルチキャストツリーを上に移動し、離脱ノードを削除した後、まだ子が残っているノードで停止する必要があります。
This message is not part of the Scribe protocol but is required by the basic protocol proposed in this document. Thus, the Usage MUST send this message to confirm a joining node accepting its parent node.
このメッセージはScribeプロトコルの一部ではありませんが、このドキュメントで提案されている基本的なプロトコルで必要です。したがって、Usageはこのメッセージを送信して、親ノードを受け入れる参加ノードを確認する必要があります。
Like JoinConfirm, this message is not part of the Scribe protocol. Thus, the Usage MUST send this message if a peer receiving a JoinAccept message wishes to decline it.
JoinConfirmと同様に、このメッセージはScribeプロトコルの一部ではありません。したがって、JoinAcceptメッセージを受信するピアが拒否したい場合、Usageはこのメッセージを送信する必要があります。
A message to be multicast to a group MUST be sent to the rendezvous node from where it is forwarded down the tree. If a node is a member of the tree rather than just a forwarder, it SHOULD pass the multicast data up to the application.
グループにマルチキャストされるメッセージは、ランデブーノードに送信されなければならず、そこからツリーに転送されます。ノードが単なるフォワーダーではなくツリーのメンバーである場合は、マルチキャストデータをアプリケーションに渡す必要があります（SHOULD）。
P2PCast [P2PCAST] creates a forest of related trees to increase load balancing. P2PCast is independent of the underlying P2P substrate. Its goals and approach are similar to SplitStream [SPLITSTREAM] (which assumes Pastry as the P2P overlay). In P2PCast, the content provider splits the stream of data into f stripes. Each tree in the forest of multicast trees is an (almost) full tree of arity f. These trees are conceptually separate: every node of the system appears once in each tree, with the content provider being the source in all of them. To ensure that each peer contributes as much bandwidth as it receives, every node is a leaf in all the trees except for one, in which the node will serve as an internal node (proper tree of this node). To reduce the complexity of the discussion that follows, the remainder of this section will assume that f = 2. However, the algorithm scales for any number f.
P2PCast [P2PCAST]は、関連するツリーのフォレストを作成して、負荷分散を向上させます。 P2PCastは、基盤となるP2P基板から独立しています。その目標とアプローチは、SplitStream [SPLITSTREAM]（PastryをP2Pオーバーレイとして想定）に似ています。 P2PCastでは、コンテンツプロバイダーはデータのストリームをf個のストライプに分割します。マルチキャストツリーのフォレスト内の各ツリーは、（ほぼ）完全なアリティツリーfです。これらのツリーは概念的に分離されています。システムのすべてのノードが各ツリーに一度表示され、すべてのソースがコンテンツプロバイダーです。各ピアが受信した帯域幅と同じだけの帯域幅を提供することを保証するために、ノードは内部ノード（このノードの適切なツリー）として機能する1つを除くすべてのツリーのリーフです。以下の説明の複雑さを軽減するために、このセクションの残りの部分では、f = 2であると想定します。ただし、アルゴリズムは任意の数fに対してスケーリングします。
P2PCast distinguishes the following types of nodes:
P2PCastは、次のタイプのノードを区別します。
o Incomplete Node: A node with less than f children in its proper stripe
o 不完全なノード：適切なストライプにf未満の子があるノード
o Only-Child Node: A node whose parent (in any multicast tree) is an incomplete node
o Only-Child Node：（マルチキャストツリー内の）親が不完全なノードであるノード
o Complete Node: A node with exactly f children in its proper stripe
o 完全なノード：適切なストライプにちょうどf個の子を持つノード
o Special Node: A single node that is a leaf in all multicast trees of the forest
o 特殊ノード：フォレストのすべてのマルチキャストツリーのリーフである単一ノード
Figure 4 shows a mapping between RELOAD ALM messages (as defined in Section 5 of this document) and P2PCast messages as defined in [P2PCAST].
図4は、RELOAD ALMメッセージ（このドキュメントのセクション5で定義）と[P2PCAST]で定義されたP2PCastメッセージ間のマッピングを示しています。
+---------+-------------------+-----------------+
| Section |RELOAD ALM Message | P2PCast Message |
+---------+-------------------+-----------------+
| 7.2.1 | CreateALMTree | Create |
+---------+-------------------+-----------------+
| 7.2.3 | Join | Join |
+---------+-------------------+-----------------+
| 7.2.4 | JoinAccept | |
+---------+-------------------+-----------------+
| 7.2.6 | JoinConfirm | |
+---------+-------------------+-----------------+
| 7.2.8 | JoinDecline | |
+---------+-------------------+-----------------+
| 7.2.10 | Leave | Leave |
+---------+-------------------+-----------------+
| 7.2.12 | Reform | Takeon |
| | | Substitute |
| | | Search |
| | | Replace |
| | | Direct |
| | | Update |
+---------+-------------------+-----------------+
| 7.2.14 | Heartbeat | |
+---------+-------------------+-----------------+
| 7.2.16 | NodeQuery | |
+---------+-------------------+-----------------+
| 7.2.18 | Push | Multicast |
+---------+-------------------+-----------------+
Figure 4: Mapping to P2PCast Messages
図4：P2PCastメッセージへのマッピング
The following sections describe the mapping of the P2PCast messages in more detail.
次のセクションでは、P2PCastメッセージのマッピングについて詳しく説明します。
This message will create a group with group_id. This message MUST be delivered to the node whose node_id is closest to the group_id. This node becomes the rendezvous point and root for the new multicast tree. The rendezvous point will maintain f subtrees.
このメッセージは、group_idでグループを作成します。このメッセージは、node_idがgroup_idに最も近いノードに配信される必要があります。このノードは、新しいマルチキャストツリーのランデブーポイントおよびルートになります。ランデブーポイントはf個のサブツリーを維持します。
To join a multicast tree, a joining node N MUST send a Join request to a random node A already part of the tree. Depending on the type of A, the joining algorithm continues as follows:
マルチキャストツリーに参加するには、参加ノードNは、すでにツリーの一部であるランダムノードAに参加要求を送信する必要があります。 Aのタイプに応じて、結合アルゴリズムは次のように続行されます。
o Incomplete Node: Node A will arbitrarily select for which tree it wants to serve as an internal node and adopt N in that tree. In the other tree, node N will adopt node A as a child (taking node A's place in the tree), thus becoming an internal node in the stripe that node A didn't choose.
o 不完全なノード：ノードAは、内部ノードとして機能するツリーを任意に選択し、そのツリーでNを採用します。もう一方のツリーでは、ノードNがノードAを子として採用し（ノードAのツリーでの位置を取得）、ノードAが選択しなかったストライプの内部ノードになります。
o Only-Child Node: As this node has a parent that is an incomplete node, the joining node will be redirected to the parent node and will handle the request as detailed above.
o 唯一の子ノード：このノードには不完全なノードである親があるため、参加ノードは親ノードにリダイレクトされ、上記のように要求を処理します。
o Complete Node: The contacted node A must be a leaf in the other tree. If node A is a leaf node in Stripe 1, node N will become an internal node in Stripe 1, taking the place of node A and adopting it at the same time. To find a place for itself in the other stripe, node N starts a random walk down the subtree rooted at the sibling of node A (if node A is the root and thus does not have siblings, node N is sent directly to a leaf in that tree), which ends as soon as node N finds an incomplete node or a leaf. In this case, node N is adopted by the incomplete node.
o 完全なノード：連絡先のノードAは、他のツリーのリーフでなければなりません。ノードAがストライプ1のリーフノードである場合、ノードNはストライプ1の内部ノードになり、ノードAの代わりにそれを採用します。他のストライプで自分自身の場所を見つけるために、ノードNはノードAの兄弟をルートとするサブツリーのランダムウォークを開始します（ノードAがルートであり、したがって兄弟がない場合、ノードNは直接リーフに送信されますそのツリー）。ノードNが不完全なノードまたは葉を見つけるとすぐに終了します。この場合、ノードNは不完全なノードによって採用されます。
o Special Node: as this node is a leaf in all subtrees, the joining node MAY adopt the node in one tree and become a child in the other.
o 特殊ノード：このノードはすべてのサブツリーのリーフであるため、参加ノードは1つのツリーのノードを採用し、他のツリーの子になる場合があります。
P2PCast uses defined messages for communication between nodes during reorganization. To use P2PCast in this context, these messages are encapsulated by the message type Reform. In doing so, the P2PCast message is to be included in the options parameter of Reform. The following reorganization messages are defined by P2PCast:
P2PCastは、再編成中にノード間の通信に定義されたメッセージを使用します。このコンテキストでP2PCastを使用するには、これらのメッセージをメッセージタイプReformでカプセル化します。その際、P2PCastメッセージはReformのオプションパラメータに含まれます。以下の再編成メッセージは、P2PCastによって定義されています。
Takeon: To take another peer as a child
武雄：別の仲間を子供にする
Substitute: To take the place of a child of some peer
代理：仲間の子の代わりをする
Search: To obtain the child of a node in a particular stripe
検索：特定のストライプのノードの子を取得するには
Replace: Different from Substitute in that the calling node that makes a node its child sheds off a random child
Replace：Substituteとは異なり、ノードを子にする呼び出しノードはランダムな子を発生させます。
Direct: To direct a node to its would-be parent
直接：ノードをその親になるノードに向ける
Update: A node sends its updated state to its children
更新：ノードは更新された状態を子に送信します
To adapt the P2PCast algorithm to the ALM Usage proposed here, after a Join request is accepted, a JoinAccept message MUST be returned to the joining node (one for every subtree).
P2PCastアルゴリズムをここで提案されたALMの使用法に適合させるには、Joinリクエストが受け入れられた後、JoinAcceptメッセージが参加ノードに返される必要があります（サブツリーごとに1つ）。
When leaving a multicast group, a node will change its local state to indicate that it left the group. Disregarding the case where the leaving node is the root of the tree, the leaving node must be complete or incomplete in its proper tree. In the other trees, the node is a leaf and can just disappear by notifying its parent. For the proper tree, if the node is incomplete, it is replaced by its child. However, if the node is complete, a gap is created that is filled by a random child. If this child is incomplete, it can simply fill the gap. However, if it is complete, it needs to shed a random child. This child is directed to its sibling, which sheds a random child. This process ripples down the tree until the next-to-last level is reached. The shed node is then taken as a child by the parent of the deleted node in the other stripe.
マルチキャストグループを脱退すると、ノードはローカル状態を変更して、グループを脱退したことを示します。離脱ノードがツリーのルートである場合を無視して、離脱ノードは適切なツリーで完全または不完全である必要があります。他のツリーでは、ノードは葉であり、その親に通知するだけで消えます。適切なツリーでは、ノードが不完全な場合、ノードはその子に置き換えられます。ただし、ノードが完全な場合、ランダムな子によって埋められるギャップが作成されます。この子が不完全な場合、ギャップを埋めることができます。ただし、それが完全な場合、ランダムな子を落とす必要があります。この子は、ランダムな子を落とす兄弟に向けられます。このプロセスは、最後から2番目のレベルに到達するまでツリーを波及させます。削除されたノードは、他のストライプで削除されたノードの親によって子として扱われます。
Again, for the reorganization of the tree, the Reform message type is used as defined in the previous section.
この場合も、ツリーの再編成では、前のセクションで定義されているように、Reformメッセージタイプが使用されます。
This message is not part of the P2PCast protocol but is required by the basic protocol defined in this document. Thus, the Usage MUST send this message to confirm a joining node accepting its parent node. As with Join and JoinAccept, this MUST be carried out for every subtree.
このメッセージはP2PCastプロトコルの一部ではありませんが、このドキュメントで定義されている基本プロトコルで必要です。したがって、Usageはこのメッセージを送信して、親ノードを受け入れる参加ノードを確認する必要があります。 JoinやJoinAcceptと同様に、これはすべてのサブツリーに対して実行する必要があります。
A message to be multicast to a group MUST be sent to the rendezvous node from where it is forwarded down the tree by being split into k stripes. Each stripe is then sent via a subtree. If a receiving node is a member of the tree rather than just a forwarder, it MAY pass the multicast data up to the application.
グループにマルチキャストされるメッセージは、ランデブーノードに送信される必要があります。ランデブーノードからは、kストライプに分割されることにより、ツリーの下方に転送されます。その後、各ストライプはサブツリーを介して送信されます。受信ノードが単なるフォワーダーではなくツリーのメンバーである場合は、マルチキャストデータをアプリケーションに渡すことができます（MAY）。
All messages are mapped to the RELOAD experimental message type. The mapping is shown in Figure 5. The message codes are listed in Section 14.2. The format of the body of a message is provided in [RELOAD].
すべてのメッセージは、RELOAD試験運用メッセージタイプにマップされます。マッピングを図5に示します。メッセージコードはセクション14.2にリストされています。メッセージの本文の形式は、[RELOAD]で提供されます。
+-------------------------+------------------+
| Message |RELOAD Code Point |
+-------------------------+------------------+
| CreateALMTree | exp_a_req |
+-------------------------+------------------+
| CreateALMTreeResponse | exp_a_ans |
+-------------------------+------------------+
| Join | exp_a_req |
+-------------------------+------------------+
| JoinAccept | exp_a_ans |
+-------------------------+------------------+
| JoinReject | exp_a_ans |
+-------------------------+------------------+
| JoinConfirm | exp_a_req |
+-------------------------+------------------+
| JoinConfirmResponse | exp_a_ans |
+-------------------------+------------------+
| JoinDecline | exp_a_req |
+-------------------------+------------------+
| JoinDeclineResponse | exp_a_ans |
+-------------------------+------------------+
| Leave | exp_a_req |
+-------------------------+------------------+
| LeaveResponse | exp_a_ans |
+-------------------------+------------------+
| Reform | exp_a_req |
+-------------------------+------------------+
| ReformResponse | exp_a_ans |
+-------------------------+------------------+
| Heartbeat | exp_a_req |
+-------------------------+------------------+
| HeartbeatResponse | exp_a_ans |
+-------------------------+------------------+
| NodeQuery | exp_a_req |
+-------------------------+------------------+
| NodeQueryResponse | exp_a_ans |
+-------------------------+------------------+
| Push | exp_a_req |
+-------------------------+------------------+
| PushResponse | exp_a_ans |
+-------------------------+------------------+
Figure 5: RELOAD Message Code Mapping
図5：RELOADメッセージコードマッピング
For Data Kind-IDs, the RELOAD specification [RELOAD] states: "Code points in the range 0xF0000001 to 0xFFFFFFFE are reserved for private use". ALM Usage Kind-IDs are defined in the private use range.
データの種類IDの場合、RELOAD仕様[RELOAD]には、「0xF0000001から0xFFFFFFFEの範囲のコードポイントは私的使用のために予約されています」と記載されています。 ALM Usage Kind-IDは、私用範囲で定義されます。
All ALM Usage messages map to the RELOAD Message Extension mechanism.
すべてのALM Usageメッセージは、RELOADメッセージ拡張メカニズムにマップされます。
Code points for the Kinds defined in this document MUST NOT conflict with any defined code points for RELOAD. RELOAD defines exp_a_req and exp_a_ans for experimental purposes. This specification uses only these message types for all ALM messages. RELOAD defines the MessageContents data structure. The ALM mapping uses the fields as follows:
このドキュメントで定義されている種類のコードポイントは、RELOADの定義されているコードポイントと競合してはなりません。 RELOADは、実験目的でexp_a_reqおよびexp_a_ansを定義します。この仕様では、すべてのALMメッセージに対してこれらのメッセージタイプのみを使用します。 RELOADはMessageContentsデータ構造を定義します。 ALMマッピングは、フィールドを次のように使用します。
o message_code: exp_a_req for requests and exp_a_ans for responses
o message_code：リクエストの場合はexp_a_req、レスポンスの場合はexp_a_ans
o message_body: contains one instance of ALMHeader followed by one instance of ALMMessageContents
o message_body：ALMHeaderの1つのインスタンスと、それに続くALMMessageContentsの1つのインスタンスが含まれます。
o extensions: unused
o 拡張機能：未使用
struct {
uint32 sam_token;
uint16 alm_algorithm_id;
uint8 version;
} ALMHeader;
The fields in ALMHeader are used as follows:
ALMHeaderのフィールドは次のように使用されます。
sam_token: The first four bytes identify this message as an ALM message. This field MUST contain the value 0xD3414D42 (the string "SAMB" with the high bit of the first byte set).
sam_token：最初の4バイトは、このメッセージをALMメッセージとして識別します。このフィールドには、値0xD3414D42（最初のバイトセットの上位ビットを含む文字列 "SAMB"）を含める必要があります。
alm_algorithm_id: The ALM Algorithm ID of the ALM algorithm being used. Each multicast tree uses only one algorithm. Trees with different ALM algorithms can coexist and can share the same nodes. ALM Algorithm ID codes are defined in Section 14.1.
alm_algorithm_id：使用されているALMアルゴリズムのALMアルゴリズムID。各マルチキャストツリーは1つのアルゴリズムのみを使用します。 ALMアルゴリズムが異なるツリーは共存でき、同じノードを共有できます。 ALMアルゴリズムIDコードは、セクション14.1で定義されています。
version: The version of the ALM protocol being used. This is a fixed-point integer between 0.1 and 25.4. This document describes version 1.0 with a value of 0xA.
version：使用されているALMプロトコルのバージョン。これは、0.1〜25.4の固定小数点整数です。このドキュメントでは、値が0xAのバージョン1.0について説明します。
struct {
uint16 alm_message_code;
opaque alm_message_body;
} ALMMessageContents;
The fields in ALMMessageContents are used as follows:
ALMMessageContentsのフィールドは次のように使用されます。
alm_message_code: This indicates the message being sent. The message codes are listed in Section 14.2.
alm_message_code：これは、送信されているメッセージを示します。メッセージコードはセクション14.2にリストされています。
alm_message_body: The message body itself, represented as a variable-length string of bytes. The bytes themselves are dependent on the code value. See Sections 8 and 9, which describe the various ALM methods for the definitions of the payload contents.
alm_message_body：可変長のバイト文字列として表されるメッセージ本文自体。バイト自体はコード値に依存します。ペイロードの内容の定義については、さまざまなALMメソッドについて説明しているセクション8および9を参照してください。
Response codes are defined in Section 6.3.3.1 of [RELOAD]. This specification maps to RELOAD ErrorResponse as follows:
応答コードは、[RELOAD]のセクション6.3.3.1で定義されています。この仕様は、次のようにRELOAD ErrorResponseにマッピングされます。
ErrorResponse.error_code = Error_Exp_A;
ErrorResponse.error_code = Error_Exp_A;
Error_info contains an ALMErrorResponse instance.
Error_infoには、ALMErrorResponseインスタンスが含まれています。
public struct {
uint16 alm_error_code;
opaque alm_error_info<0..2^16-1>;
} ALMErrorResponse;
alm_error_code: The following error code values are defined. Numeric values for these are defined in Section 14.3.
alm_error_code：次のエラーコード値が定義されています。これらの数値はセクション14.3で定義されています。
Error_Unknown_Algorithm: The multicast algorithm is not known or not supported.
Error_Unknown_Algorithm：マルチキャストアルゴリズムが不明またはサポートされていません。
Error_Child_Limit_Reached: The maximum number of child nodes has been reached for this node.
Error_Child_Limit_Reached：このノードの子ノードの最大数に達しました。
Error_Node_Bandwidth_Reached: The overall data bandwidth limit through this node has been reached.
Error_Node_Bandwidth_Reached：このノード全体のデータ帯域幅の上限に達しました。
Error_Node_Conn_Limit_Reached: The total number of connections to this node has been reached.
Error_Node_Conn_Limit_Reached：このノードへの接続の総数に達しました。
Error_Link_Cap_Limit_Reached: The capacity of a link has been reached.
Error_Link_Cap_Limit_Reached: The capacity of a link has been reached.
Error_Node_Mem_Limit_Reached: An internal memory capacity of the node has been reached.
Error_Node_Mem_Limit_Reached：ノードの内部メモリ容量に達しました。
Error_Node_CPU_Cap_Limit_Reached: An internal processing capacity of the node has been reached.
Error_Node_CPU_Cap_Limit_Reached：ノードの内部処理能力に達しました。
Error_Path_Limit_Reached: The maximum path length in hop count over the multicast tree has been reached.
Error_Path_Limit_Reached：マルチキャストツリー上のホップカウントの最大パス長に達しました。
Error_Path_Delay_Limit_Reached: The maximum path length in message delay over the multicast tree has been reached.
Error_Path_Delay_Limit_Reached：マルチキャストツリー上のメッセージ遅延の最大パス長に達しました。
Error_Tree_Fanout_Limit_Reached: The maximum fanout of a multicast tree has been reached.
Error_Tree_Fanout_Limit_Reached：マルチキャストツリーの最大ファンアウトに達しました。
Error_Tree_Depth_Limit_Reached: The maximum height of a multicast tree has been reached.
Error_Tree_Depth_Limit_Reached：マルチキャストツリーの最大の高さに達しました。
Error_Other: A human-readable description is placed in the alm_error_info field.
Error_Other：人間が読める形式の説明がalm_error_infoフィールドに配置されます。
All peers in the examples are assumed to have completed bootstrapping. "Pn" refers to peer N. "group_id" refers to a peer responsible for storing the ALMTree instance with group_id.
例のすべてのピアは、ブートストラップが完了していると想定されています。 「Pn」はピアNを指します。「group_id」は、group_idでALMTreeインスタンスを格納する責任があるピアを指します。
A node with "NODE-MATCH" rights sends a CreateALMTree request to the group_id node, which also has NODE-MATCH rights for its own address. The group_id node determines whether to create the new tree and, if so, performs a local StoreReq. If the CreateALMTree succeeds, the ALMTree instance can be retrieved using Fetch. An example message flow for creating a tree is depicted in Figure 6.
「NODE-MATCH」権限を持つノードは、CreateALMTreeリクエストをgroup_idノードに送信します。このノードには、自身のアドレスに対するNODE-MATCH権限もあります。 group_idノードは、新しいツリーを作成するかどうかを決定し、作成する場合はローカルのStoreReqを実行します。 CreateALMTreeが成功した場合、ALMTreeインスタンスはFetchを使用して取得できます。ツリーを作成するためのメッセージフローの例を図6に示します。
P1 P2 P3 P4 group_id
| | | | |
| | | | |
| | | | |
| CreateALMTree | | |
|------------------------------->|
| | | | |
| | | | | StoreReq
| | | | |--+
| | | | | |
| | | | | |
| | | | |<-+
| | | | | StoreResponse
| | | | |--+
| | | | | |
| | | | | |
| | | | |<-+
| | | | |
| | | | |
| | CreateALMTreeResponse |
|<-------------------------------|
| | | | |
| | | | |
| Fetch | | |
|------------------------------->|
| | | | |
| | | | |
| | FetchResponse |
|<-------------------------------|
| | | | |
Figure 6: Message Flow Example for CreateALMTree
図6：CreateALMTreeのメッセージフローの例
P1 joins node group_id as child node. P2 joins the tree as a child of P1. P4 joins the tree as a child of P1. The corresponding message flow is shown in Figure 7.
P1はノードgroup_idを子ノードとして結合します。 P2はP1の子としてツリーに参加します。 P4はP1の子としてツリーに参加します。対応するメッセージフローを図7に示します。
P1 P2 P3 P4 group_id
| | | | |
| | | | |
| Join |
|------------------------------->|
| | | | |
| JoinAccept |
|<-------------------------------|
| | | | |
| | | | |
| |Join |
| |----------------------->|
| | | | |
| Join|
|<-------------------------------|
| | | | |
|JoinAccept | | |
|------>| | | |
| | | | |
|JoinConfirm | | |
|<------| | | |
| | | | |
| | | |Join |
| | | |------>|
| | | | Join |
|<-------------------------------|
| | | | |
| Join | | | |
|------>| | | |
| | | | |
| JoinAccept | | |
|----------------------->| |
| | | | |
| | JoinAccept | |
| |--------------->| |
| | | | |
| | | | |
| | JoinConfirm | |
|<-----------------------| |
| | | | |
| | JoinDecline | |
| |<---------------| |
| | | | |
| | | | |
Figure 7: Message Flow Example for Tree Join
図7：ツリー結合のメッセージフローの例
P1 P2 P3 P4 group_id
| | | | |
| | | | |
| | | Leave | |
|<-----------------------| |
| | | | |
| LeaveResponse | | |
|----------------------->| |
| | | | |
| | | | |
Figure 8: Message Flow Example for Leave Tree
図8：リーブツリーのメッセージフローの例
The multicast data is pushed recursively P1 => group_id => P1 => P2, P4 following the tree topology created in the Join example above. An example message flow is shown in Figure 9.
マルチキャストデータは、上記の結合の例で作成したツリートポロジに従って、P1 => group_id => P1 => P2、P4と再帰的にプッシュされます。メッセージフローの例を図9に示します。
P1 P2 P3 P4 group_id
| | | | |
| Push | | | |
|------------------------------->|
| | | | |
| | | PushResponse|
|<-------------------------------|
| | | | |
| | | | Push|
|<-------------------------------|
| | | | |
| PushResponse | | |
|------------------------------->|
| | | | |
|Push | | | |
|------>| | | |
| | | | |
|PushResponse | | |
|<------| | | |
| | | | |
| Push | | | |
|----------------------->| |
| | | | |
| | PushResponse | |
|<-----------------------| |
| | | | |
| | | | |
| | | | |
Figure 9: Message Flow Example for Pushing Data
Figure 9: Message Flow Example for Pushing Data
This section defines the ALMTree Kind per Section 7.4.5 of [RELOAD]. An instance of the ALMTree Kind is stored in the overlay for each ALM tree instance. It is stored at the address group_id.
This section defines the ALMTree Kind per Section 7.4.5 of [RELOAD]. An instance of the ALMTree Kind is stored in the overlay for each ALM tree instance. It is stored at the address group_id.
Kind-ID: 0xF0000001. (This is a private-use code point per Section 14.6 of [RELOAD].) The Resource Name for the ALMTree Kind-ID is the session_key used to identify the ALM tree.
種類ID：0xF0000001。 （これは、[RELOAD]のセクション14.6に基づく私的使用のコードポイントです。）ALMTree Kind-IDのリソース名は、ALMツリーを識別するために使用されるsession_keyです。
Data Model: The data model is the ALMTree structure.
Data Model: The data model is the ALMTree structure.
Access Control: NODE-MATCH. The node performing the store operation is required to have NODE-MATCH access.
アクセス制御：NODE-MATCH。ストア操作を実行するノードには、NODE-MATCHアクセスが必要です。
Meaning: The meaning of the fields is given in Section 7.2.1.
意味：フィールドの意味はセクション7.2.1に記載されています。
struct {
node_id peer_id;
opaque session_key<0..2^32-1>;
node_id group_id;
Dictionary options;
} ALMTree;
There are no ALM parameters defined for the RELOAD configuration file.
RELOAD構成ファイルに定義されたALMパラメーターはありません。
This section contains the new code points registered by this document.
このセクションには、このドキュメントによって登録された新しいコードポイントが含まれています。
IANA has created the "SAM ALM Algorithm IDs" registry. Entries in this registry are 16-bit integers denoting Application-Layer Multicast algorithms as described in Section 10.1 of this document. Code points in the range 0x0003 to 0x7FFF SHALL be registered via RFC 5226 [RFC5226] Expert Review. Code points in the range 0x8000 to 0xFFFF are reserved for private use. The initial contents of this registry are:
IANAは「SAM ALM Algorithm IDs」レジストリを作成しました。このレジストリのエントリは、このドキュメントのセクション10.1で説明されているアプリケーション層マルチキャストアルゴリズムを示す16ビット整数です。 0x0003から0x7FFFの範囲のコードポイントは、RFC 5226 [RFC5226] Expert Reviewを介して登録する必要があります。 0x8000から0xFFFFの範囲のコードポイントは、私的使用のために予約されています。このレジストリの初期内容は次のとおりです。
+----------------+-------------------+-----------+
| Algorithm Name | ALM Algorithm ID | RFC |
+----------------+-------------------+-----------+
| INVALID-ALG | 0x0000 | RFC 7019 |
| SCRIBE-SAM | 0x0001 | RFC 7019 |
| P2PCAST-SAM | 0x0002 | RFC 7019 |
| Reserved | 0x8000-0xFFFF | RFC 7019 |
+----------------+-------------------+-----------+
Figure 10: "SAM ALM Algorithm IDs" Registry Allocations
図10：「SAM ALMアルゴリズムID」のレジストリ割り当て
These values have been made available for the purposes of experimentation. These values are not meant for vendor-specific use of any sort and MUST NOT be used for operational deployments.
これらの値は、実験のために提供されています。これらの値は、ベンダー固有の使用を意図したものではなく、運用展開に使用してはなりません。
IANA has created the "SAM ALM Message Codes" registry. Entries in this registry are 16-bit integers denoting message codes as described in Section 10.2 of this document. Code points in the range 0x0014 to 0x7FFF SHALL be registered via RFC 5226 [RFC5226] Expert Review. Code points in the range 0x8000 to 0xFFFF are reserved for private use. The initial contents of this registry are:
IANAは「SAM ALMメッセージコード」レジストリを作成しました。このレジストリのエントリは、このドキュメントのセクション10.2で説明されているメッセージコードを示す16ビット整数です。 0x0014から0x7FFFの範囲のコードポイントは、RFC 5226 [RFC5226]エキスパートレビューを介して登録する必要があります。 0x8000から0xFFFFの範囲のコードポイントは、私的使用のために予約されています。このレジストリの初期内容は次のとおりです。
+-------------------------+----------------------+-----------+
| Message Code Name | Message Code Value | RFC |
+-------------------------+----------------------+-----------+
| InvalidMessageCode | 0x0000 | RFC 7019 |
| CreateALMTree | 0x0001 | RFC 7019 |
| CreateALMTreeResponse | 0x0002 | RFC 7019 |
| Join | 0x0003 | RFC 7019 |
| JoinAccept | 0x0004 | RFC 7019 |
| JoinReject | 0x0005 | RFC 7019 |
| JoinConfirm | 0x0006 | RFC 7019 |
| JoinConfirmResponse | 0x0007 | RFC 7019 |
| JoinDecline | 0x0008 | RFC 7019 |
| JoinDeclineResponse | 0x0009 | RFC 7019 |
| Leave | 0x000A | RFC 7019 |
| LeaveResponse | 0x000B | RFC 7019 |
| Reform | 0x000C | RFC 7019 |
| ReformResponse | 0x000D | RFC 7019 |
| Heartbeat | 0x000E | RFC 7019 |
| HeartbeatResponse | 0x000F | RFC 7019 |
| NodeQuery | 0x0010 | RFC 7019 |
| NodeQueryResponse | 0x0011 | RFC 7019 |
| Push | 0x0012 | RFC 7019 |
| PushResponse | 0x0013 | RFC 7019 |
| Reserved | 0x8000-0xFFFF | RFC 7019 |
+-------------------------+----------------------+-----------+
Figure 11: "SAM ALM Message Codes" Registry Allocations
図11：「SAM ALMメッセージコード」のレジストリ割り当て
These values have been made available for the purposes of experimentation. These values are not meant for vendor-specific use of any sort and MUST NOT be used for operational deployments.
These values have been made available for the purposes of experimentation. These values are not meant for vendor-specific use of any sort and MUST NOT be used for operational deployments.
IANA has created the "SAM ALM Error Codes" registry. Entries in this registry are 16-bit integers denoting error codes as described in Section 10.3 of this document. Code points in the range 0x000D to
IANAは「SAM ALMエラーコード」レジストリを作成しました。このレジストリのエントリは、このドキュメントのセクション10.3で説明されているエラーコードを示す16ビット整数です。 0x000Dから
0x7FFF SHALL be registered via RFC 5226 [RFC5226] Expert Review. Code points in the range 0x8000 to 0xFFFF are reserved for private use. The initial contents of this registry are:
0x7FFFはRFC 5226 [RFC5226]エキスパートレビューを介して登録する必要があります。 0x8000から0xFFFFの範囲のコードポイントは、私的使用のために予約されています。このレジストリの初期内容は次のとおりです。
+----------------------------------+---------------+-----------+
| Error Code Name | Code Value | RFC |
+----------------------------------+---------------+-----------+
| InvalidErrorCode | 0x0000 | RFC 7019 |
| Error_Unknown_Algorithm | 0x0001 | RFC 7019 |
| Error_Child_Limit_Reached | 0x0002 | RFC 7019 |
| Error_Node_Bandwidth_Reached | 0x0003 | RFC 7019 |
| Error_Node_Conn_Limit_Reached | 0x0004 | RFC 7019 |
| Error_Link_Cap_Limit_Reached | 0x0005 | RFC 7019 |
| Error_Node_Mem_Limit_Reached | 0x0006 | RFC 7019 |
| Error_Node_CPU_Cap_Limit_Reached | 0x0007 | RFC 7019 |
| Error_Path_Limit_Reached | 0x0008 | RFC 7019 |
| Error_Path_Delay_Limit_Reached | 0x0009 | RFC 7019 |
| Error_Tree_Fanout_Limit_Reached | 0x000A | RFC 7019 |
| Error_Tree_Depth_Limit_Reached | 0x000B | RFC 7019 |
| Error_Other | 0x000C | RFC 7019 |
| Reserved | 0x8000-0xFFFF | RFC 7019 |
+----------------------------------+---------------+-----------+
Figure 12: "SAM ALM Error Codes" Registry Allocations
図12： "SAM ALMエラーコード"レジストリの割り当て
These values have been made available for the purposes of experimentation. These values are not meant for vendor-specific use of any sort and MUST NOT be used for operational deployments.
これらの値は、実験のために提供されています。これらの値は、ベンダー固有の使用を意図したものではなく、運用展開に使用してはなりません。
Overlays are vulnerable to DoS and collusion attacks. We are not solving overlay security issues. We assume that the node authentication model as defined in [RELOAD] will be used.
オーバーレイは、DoSおよび共謀攻撃に対して脆弱です。オーバーレイのセキュリティ問題は解決していません。 [RELOAD]で定義されているノード認証モデルが使用されることを想定しています。
Security issues specific to ALM Usage include the following:
ALMの使用に固有のセキュリティの問題には、次のものがあります。
o The right to create group_id at some node_id
o いくつかのnode_idでgroup_idを作成する権限
o The right to store Tree info at some location in the DHT
o DHTのある場所にツリー情報を保存する権利
o A limit on number of messages per second and bandwidth use
o 1秒あたりのメッセージ数と帯域幅の使用に関する制限
o The right to join an ALM tree
o ALMツリーに参加する権利
Marc Petit-Huguenin, Michael Welzl, Joerg Ott, and Lars Eggert provided important comments on earlier versions of this document.
Marc Petit-Huguenin、Michael Welzl、Joerg Ott、およびLars Eggertは、このドキュメントの以前のバージョンに関する重要なコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[BUFORD2008] Buford, J. and H. Yu, "P2P: Overlay Multicast", Encyclopedia of Wireless and Mobile Communications, 2008, <http://www.tandfonline.com/doi/abs/10.1081/ E-EWMC-120043583>.
[BUFORD2008]ビュフォード、J。およびH.ユウ、「P2P：オーバーレイマルチキャスト」、ワイヤレスおよびモバイル通信の百科事典、2008年、<http://www.tandfonline.com/doi/abs/10.1081/ E-EWMC-120043583 >。
[BUFORD2009] Buford, J., Yu, H., and E. Lua, "P2P Networking and Applications (Chapter 9)", Morgan Kaufman, 2009, <http://www.sciencedirect.com/science/book/ 9780123742148>.
[BUFORD2009] Buford、J.、Yu、H。、およびE. Lua、「P2Pネットワーキングおよびアプリケーション（第9章）」、Morgan Kaufman、2009年、<http://www.sciencedirect.com/science/book/ 9780123742148 >。
[CASTRO2002] Castro, M., Druschel, P., Kermarrec, A., and A. Rowstron, "SCRIBE: A large-scale and decentralized application-level multicast infrastructure", IEEE Journal on Selected Areas in Communications, Vol. 20, No. 8, October 2002, <http://ieeexplore.ieee.org/xpl/ login.jsp?tp=&arnumber=1038579>.
[CASTRO2002] Castro、M.、Druschel、P.、Kermarrec、A。、およびA. Rowstron、「SCRIBE：大規模で分散型のアプリケーションレベルのマルチキャストインフラストラクチャ」、IEEE Journal on Selected Areas in Communications、Vol。 20、No。8、2002年10月、<http://ieeexplore.ieee.org/xpl/ login.jsp？tp =＆arnumber = 1038579>。
[CASTRO2003] Castro, M., Jones, M., Kermarrec, A., Rowstron, A., Theimer, M., Wang, H., and A. Wolman, "An Evaluation of Scalable Application-level Multicast Built Using Peer-to-peer Overlays", Proceedings of IEEE INFOCOM 2003, April 2003, <http://ieeexplore.ieee.org/xpl/ login.jsp?tp=&arnumber=1208986>.
[CASTRO2003] Castro、M.、Jones、M.、Kermarrec、A.、Rowstron、A.、Theimer、M.、Wang、H。、およびA. Wolman、「ピアを使用して構築されたスケーラブルなアプリケーションレベルのマルチキャストの評価-to-peer Overlays」、Proceedings of IEEE INFOCOM 2003、2003年4月、<http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1208986>。
[COMMON-API] Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API for Transparent Hybrid Multicast", Work in Progress, April 2013.
[COMMON-API] Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API for Transparent Hybrid Multicast", Work in Progress, April 2013.
[KOLBERG2010] Kolberg, M., "Employing Multicast in P2P Overlay Networks", Handbook of Peer-to-Peer Networking, 2010, <http://link.springer.com/content/pdf/ 10.1007%2F978-0-387-09751-0_30.pdf>.
[KOLBERG2010] Kolberg、M。、「Eploying Multicast in P2P Overlay Networks」、Handbook of Peer-to-Peer Networking、2010、<http://link.springer.com/content/pdf/10.1007%2F978-0-387 -09751-0_30.pdf>。
[P2PCAST] Nicolosi, A. and S. Annapureddy, "P2PCast: A Peer-to-Peer Multicast Scheme for Streaming Data", Stanford Secure Computer Systems Group Report, May 2003, <http://www.scs.stanford.edu/~reddy/research/p2pcast/ report.pdf>.
[P2PCAST] Nicolosi、A。およびS. Annapureddy、「P2PCast：ストリーミングデータ用のピアツーピアマルチキャストスキーム」、スタンフォードセキュアコンピュータシステムグループレポート、2003年5月、<http://www.scs.stanford.edu /〜reddy / research / p2pcast / report.pdf>。
[RELOAD] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Work in Progress, February 2013.
[RELOAD] Jennings、C.、Lowekamp、B.、Ed。、Rescorla、E.、Baset、S。、およびH. Schulzrinne、「REsource LOcation And Discovery（RELOAD）Base Protocol」、Work in Progress、2013年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[SAM-GENERIC] Muramoto, E., Imai, Y., and N. Kawaguchi, "Requirements for Scalable Adaptive Multicast Framework in Non-GIG Networks", Work in Progress, November 2006.
[SAM-GENERIC]村本英樹、今井裕介、川口直人、「非GIGネットワークにおけるスケーラブルな適応型マルチキャストフレームワークの要件」、進行中の作業、2006年11月。
[SPLITSTREAM] Castro, M., Druschel, P., Nandi, A., Kermarrec, A., Rowstron, A., and A. Singh, "SplitStream: High-Bandwidth Multicast in a Cooperative Environment", SOSP '03, Lake Bolton, New York, October 2003, <http://dl.acm.org/citation.cfm?id=945474>.
[SPLITSTREAM] Castro、M.、Druschel、P.、Nandi、A.、Kermarrec、A.、Rowstron、A。、およびA. Singh、「SplitStream：協調環境における高帯域幅マルチキャスト」、SOSP '03、 2003年10月、ニューヨーク州ボルトン湖、<http://dl.acm.org/citation.cfm?id=945474>。
Authors' Addresses
著者のアドレス
John Buford Avaya Labs Research 211 Mt. Airy Rd. Basking Ridge, New Jersey 07920 USA
ジョンブフォードアバイアラボリサーチ211エアリーロードバスキングリッジ、ニュージャージー07920米国
Phone: +1 908 848 5675
EMail: buford@avaya.com
Mario Kolberg (editor) University of Stirling Dept. of Computing Science and Mathematics Stirling FK9 4LA UK
マリオコルバーグ（編集者）スターリング大学コンピューティング科学および数学科スターリングFK9 4LA英国
Phone: +44 1786 46 7440
EMail: mkolberg@ieee.org
URI: http://www.cs.stir.ac.uk/~mko