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
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)
资源定位和发现的应用层多播扩展（重新加载）
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）定义了一个资源位置和发现（RELOAD）用法，以及一个到RELOAD实验消息类型的映射，以支持ALM。ALM的使用旨在以独立于覆盖的方式支持各种ALM控制算法。基于Scribe和P2PCast定义了两个示例算法。
This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).
本文档是可伸缩自适应多播研究组（SAM RG）的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。该RFC代表了互联网研究任务组（IRTF）可扩展自适应多播研究小组的共识。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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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
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
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 通过全球Internet连接节点的树
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:
应用层多播（ALM）已被证明是一种可行的多播技术，在本地多播不可用的情况下。已经提出了许多ALM设计。此ALM用途的重点是：
o ALM implemented in RELOAD-based overlays
o 在基于重载的覆盖中实现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] 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[重新加载]有一个应用程序扩展机制，在该机制中，新类型的应用程序定义了一种用法。重载用法定义了一组数据类型及其使用规则。此外，本文档还描述了其他消息类型和新的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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
We adopt the terminology defined in Section 3 of [RELOAD], specifically the distinction between "node", "peer", and "client".
我们采用[重新加载]第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
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]。覆盖多播中的主机专门处理组管理、路由和树构造，而不受Internet路由器的任何支持。这也称为应用层多播（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树：发送数据消息的节点将消息发送给其父节点及其子节点。从一个边缘接收数据消息的每个节点将其转发到其连接的其余树边缘。
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.
Castro等人[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）覆盖，以及对等点互连和路由消息的机制。重载是一种通用的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遍历。我们允许客户端成为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.
所有树控制消息都在覆盖中路由。设想了两种类型的数据或媒体拓扑：1）树边是覆盖中的路径，2）树边是树中父节点和子节点之间的直接连接，使用重新加载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所示，有两个变化。新的ALM消息使用重新加载实验消息类型映射到重新加载消息传输。ALM算法插件处理ALM状态和控制。ALM算法由应用程序通过组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 |
+-------------------+
+---------+
|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 --------------
---------- Overlay Link Service Boundary --------------
Figure 2: RELOAD Architecture Extensions
图2：重新加载架构扩展
The ALM components interact with RELOAD as follows:
ALM组件与重新加载交互作用如下：
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使用重新加载数据存储功能在覆盖中创建新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应用程序和管理工具可以使用重新加载数据存储功能来存储有关树操作的诊断信息，包括平均树数、从源节点到叶节点的延迟、带宽使用和分组丢失率。此外，诊断信息可以包括特定于树根或树中任何节点的统计信息。
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.
重新加载的应用在可存储在DHT中的数据类型中受到限制。应用程序的可接受数据类型的配置文件称为用法。重新加载的设计使新的应用程序可以轻松定义新的用法。多播应用程序需要新的重新加载用法，因为基本重新加载中的数据类型和现有用法是不够的。
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.
我们在重新加载中定义ALM的用法。对于覆盖中需要ALM功能的应用程序，此ALM使用就足够了。图2显示了ALM使用的内部结构。其中包含组API（[COMMON-API]）、ALM算法插件（如Scribe）和ALM消息，然后将这些消息发送到重新加载网络。
A RELOAD Usage is required [RELOAD] to define the following:
需要重新加载使用[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的资源名称，该资源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组\u id是重新加载节点\u id。ALM组的所有者按照[重新加载]中的指定创建重新加载节点\u id。这意味着组id用作覆盖路由目的的重新加载目的地。
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
o 改革或优化树
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.
有多种算法可供对等点在覆盖中形成多播树。这里介绍的方法允许在覆盖中支持多个这样的算法，因为不同的算法可能更适合某些应用需求；该方法还支持实验。因此，对应于覆盖多播操作集的覆盖消息必须携带算法标识信息。
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.
例如，对于小型组，连接点可能由集合点直接分配，而对于大型树，连接请求可能会沿着树向下传播，候选父节点将其位置直接转发到新节点。
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.
下面是一个在覆盖中形成多播树的简单表示法。它的主要优点是使用覆盖来路由控制和数据消息。组创建者不必是树的根，甚至不必是树中的根。它不考虑每个节点负载、接纳控制或替代路径。在创建树之后，可能通过在DHT中发布来在带外发布或分发组id。类似地，加入对等方将发现带外的组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.
组_id=create（）；//分配唯一的组id//根是覆盖中最近的//对等方。
2. Any joining peer:
2. 任何加入的对等方：
joinTree(group_id); // sends "join group_id" message
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.
覆盖层使用覆盖层路由机制将加入请求路由到与组\u ID具有最近ID的对等方。该对等方是根。根路径上的对等节点作为转发点加入树。
3. Leave Tree:
3. 离开树：
leaveTree(group_id); // removes this node from the tree
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.
将休假请求传播到每个子节点和父节点。如果父节点是转发节点，并且这是其最后一个子节点，则它会将休假请求传播到其父节点。从父节点接收请假请求的子节点向组id发送加入请求。
4. Message forwarding:
4. 邮件转发：
multicastMsg(group_id, msg);
多播消息（组id，消息）；
For message forwarding, both Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) approaches may be used.
对于消息转发，可以使用任何源多播（ASM）和源特定多播（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），定义用于创建覆盖多播树的消息。重载提供了支持多种覆盖拓扑的机制。因此，本文中定义的覆盖多播框架可用于P2P-SIP，并使可扩展自适应多播（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树形成和树维护算法。本规范的目的是算法不可知，类似于重载是覆盖算法不可知的。我们假设所有控制消息都使用覆盖路由消息进行传播。
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节定义了消息代码。消息映射到重新加载实验消息类型。
In the following sections, the protocol messages as mapped to RELOAD are discussed. Detailed example message flows are provided in Section 11.
在以下部分中，将讨论映射到重新加载的协议消息。第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:
在下面的描述中，我们使用数据类型字典，它是一组由不透明键索引的不透明值，每个键有一个值。单个词典条目由重新加载文档[重新加载]第7.2.3节中定义的词典条目表示。字典数据类型定义如下：
struct {
DictionaryEntry elements<0..2^16-1>;
} Dictionary;
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指定。基于DHT的group_id覆盖中的常见解释是，对等id最接近且小于group_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.
组id是从一个众所周知的会话密钥生成的，其他对等方将使用该密钥来寻址覆盖中的多播树。必须使用覆盖的id生成机制从会话密钥生成组id。
struct {
node_id peer_id;
opaque session_key<0..2^32-1>;
node_id group_id;
Dictionary options;
} ALMTree;
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生成算法对其进行哈希运算时，会生成组_ID。
group_id: overlay address of the root of the tree.
组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.
树的创建受访问控制，因为它涉及存储操作。使用[重新加载]第7.3.2节中定义的节点匹配访问策略。
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会导致在负责组id的节点G的覆盖中存储一个ALMTree结构。该节点G执行重新加载定义的StoreReq操作，作为执行CreateALMTree的副作用。如果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.
成功创建ALMTree后，对等方可以使用重新加载获取方法检索地址组_id处的ALMTree结构。ALMTree类型在第12.1节中定义。
After receiving a CreateALMTree message from node S, the peer sends a CreateALMTreeResponse to node S.
从节点S接收CreateALMTree消息后，对等方向节点S发送CreateALMTree响应。
struct {
Dictionary options;
} CreateALMTreeResponse;
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.
Join导致调用特定ALM组的对等连接的分布式算法。加入请求的定义如下所示。如果成功，加入对等方将在一个或多个JoinAccept消息中收到一个或多个候选父对等方的通知。此协议中未指定特定的ALM连接算法。
struct {
node_id peer_id;
node_id group_id;
Dictionary options;
} Join;
struct {
node_id peer_id;
node_id group_id;
Dictionary options;
} Join;
peer_id: overlay address of joining/leaving peer
peer_id：加入/离开peer的覆盖地址
group_id: overlay address of the root of the tree
组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.
重载是一种请求-响应协议。因此，消息JoinAccept和JoinReject（定义如下）与Join的响应相匹配。如果收到JoinReject，则不会对此请求执行进一步的操作。如果接收到JoinAccept，则发送JoinConfirm或JoinDecept消息（见下文）。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.
Join--JoinAccept：节点C向节点P发送一个Join请求。如果节点P接受，它将用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.
Join--JoinReject：节点C向节点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.
JoinDecept--JoinDeclineResponse：如果节点P向节点C发送了JoinAccept，节点C使用JoinDecept请求进行拒绝，则节点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和JoinDecept被视为重新加载中定义的请求，被映射到重新加载exp_a_req消息，因此被重新传输，直到达到重试限制或收到匹配的响应为止。JoinAccept、JoinReject、JoinConfirmResponse和JoinDeclineResponse被视为上面定义的消息响应，并映射到RELOAD exp_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))
}
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
JoinAccept告诉请求加入的对等方，指定的对等方可以在group_id指定的ALM树中充当其父节点，并指定相应的选项。对等方可以从组id树中的不同候选父对等方接收多个JoinAccept。对等方使用
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.
确认信息。既不接收JoinConfirm也不接收JoinDecept消息的JoinAccept必须过期。重新加载实现能够读取本地配置文件进行设置。假定此文件包含要使用的超时值。
struct {
node_id parent_peer_id;
node_id child_peer_id;
node_id group_id;
Dictionary options;
} JoinAccept;
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
子节点\节点id：加入节点的覆盖地址
group_id: overlay address of the root of the tree
组id：树根的覆盖地址
options: name-value list of options accepted by parent peer
选项：父节点接受的选项的名称值列表
A peer receiving a Join request responds with a JoinReject response to indicate the request is rejected.
接收连接请求的对等方使用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的选项，以完成两个对等方之间的选项协商。
struct {
node_id child_peer_id;
node_id parent_peer_id;
node_id group_id;
Dictionary options;
} JoinConfirm;
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
parent_peer_id：作为加入对等方的父方的对等方的覆盖地址
group_id: overlay address of the root of the tree
组id：树根的覆盖地址
options: name-value list of options accepted by both peers
选项：两个对等方接受的选项的名称值列表
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)
}
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消息的对等方可以使用JoinDecept消息显式拒绝该消息。
struct {
node_id peer_id;
node_id parent_peer_id;
node_id group_id;
} JoinDecline;
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
组id：树根的覆盖地址
The behavior of the JoinDecline message is described as follows:
JoinDecept消息的行为描述如下：
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树的一部分，打算从子节点或父节点分离的节点应向希望分离的节点发送休假请求。从既不在父列表中也不在子列表中的对等方接收请假请求的对等方应忽略该消息。
struct {
node_id peer_id;
node_id group_id;
Dictionary options;
} Leave;
struct {
node_id peer_id;
node_id group_id;
Dictionary options;
} Leave;
peer_id: overlay address of leaving peer
peer_id：离开peer的覆盖地址
group_id: overlay address of the root of the tree
组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)
组[msg.group\u id].children.remove（msg.source）if（组[msg.group].children=0）SEND（msg，组[msg.group\u id].parent）
A peer receiving a Leave request responds with a LeaveResponse message.
接收请假请求的对等方使用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.
这会触发整个树或仅子树的重组。它可能包括对建议重新连接到的父节点或子节点的特定节点的提示。接收此消息的对等方可以忽略它，可以将其传播到其子树中的其他对等方，并且可以调用本地算法来选择首选父和/或子对等方。
struct {
node_id group_id;
node_id peer_id;
Dictionary options;
} Reform;
struct {
node_id group_id;
node_id peer_id;
Dictionary options;
} Reform;
group_id: overlay address of the root of the tree
组id：树根的覆盖地址
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.
peer_id：如果省略，则从根开始重新组织树；否则，它将仅在由peer_id标识的子树上重新组织。
options: name-value list of options
选项：选项的名称值列表
A peer receiving a Reform message responds with a ReformResponse.
接收到改革消息的对等方以ReformResponse进行响应。
struct {
Dictionary options;
} ReformResponse;
struct {
Dictionary options;
} ReformResponse;
options: algorithm-dependent information about the results of the Reform operation
选项：关于改革操作结果的算法相关信息
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是可配置的。重新加载实现能够读取本地配置文件进行设置。假定此文件包含要使用的N值。
struct {
node_id peer_id_src;
node_id peer_id_dst;
node_id group_id;
Dictionary options;
} Heartbeat;
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\u id\u src：心跳的来源
peer_id_dst: destination of Heartbeat
对等id:Heartbeat的目标
group_id: overlay address of the root of the tree
组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;
struct {
node_id peer_id_src;
node_id peer_id_dst;
} NodeQuery;
peer_id_src: source of query
peer\u id\u 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;
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
支持的算法数：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.
max_tree_data：关于此节点所属节点数最大的树的数据。NodeQuery可用于爬网ALM树中的所有节点以填充此字段。这旨在支持在重新加载时使用ALM进行监控、算法设计和一般实验。
number_active_trees: current number of trees that the node is part of
活动树数：节点所属的树的当前数目
tree_data: details of each active tree; the number of such is specified by number_active_trees
tree_数据：每个活动树的详细信息；这些树的数量由活动树的数量指定
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;
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
树id：树的id
algorithm: code identifying the multicast algorithm used by this tree
算法：标识此树使用的多播算法的代码
tree_root: node_id of tree root, or 0 if unknown
树根：树根的节点id，如果未知，则为0
number_parents: 0 .. 2^8-1 indicates number of parent nodes for this node
家长人数：0。。2^8-1表示此节点的父节点数
parent: the RELOAD node_id of each parent node
父节点：每个父节点的重新加载节点\u id
number_child_nodes: 0..2^16-1 indicates number of children
子节点数：0..2^16-1表示子节点数
children: the RELOAD node_id of each child node
子节点：每个子节点的重新加载节点\u 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
路径\u延迟\u到\u根：到根节点的RTT（毫秒）
path_delay_to_child: last measured RTT in milliseconds to child node with largest RTT
路径\u延迟\u到\u子节点：最后测量的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;
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\u confirm\u timeout：JoinConfirm/JoinDecept的默认时间，用于为加入请求提供足够的时间来接收所有响应并确认最佳选择。默认值为5000毫秒。实现可以更改此值。
heartbeat_interval: The default Heartbeat interval is 2000 msec. Different interoperating implementations could use different intervals.
心跳间隔：默认心跳间隔为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：默认的heartbeat timeout为5000毫秒，是树中相邻节点的heartbeat报告之间的最长时间，此时heartbeat丢失。
info_length: length of the info field
信息长度：信息字段的长度
info: implementation-specific information, such as name of implementation, build version, and implementation-specific features
信息：特定于实现的信息，例如实现的名称、生成版本和特定于实现的功能
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;
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
组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
长度：数据字段的长度（字节）
data: the data
数据：数据
In pseudocode, the behavior of Push can be described as:
在伪代码中，推送的行为可以描述为：
foreach(groups[msg.group_id].children as node_id) SEND(msg,node_id) if memberOf(msg.group_id) invokeMessageHandler(msg.group_id, msg)
如果memberOf（msg.group\u id）调用MessageHandler（msg.group\u id，msg），则foreach（groups[msg.group\u id]。子节点作为节点id）发送（msg，节点id）
After receiving a Push message from node S, the receiving peer sends a PushResponse to node S.
在从节点S接收推送消息之后，接收对等方向节点S发送推送响应。
struct {
Dictionary options;
} PushResponse;
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个推送消息。对于接收到的每个推送消息，反馈可以包括转发推送消息的相邻节点的数量和接收到推送响应的相邻节点的数量。
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显示了重新加载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 |
+---------+-------------------+-----------------+
+---------+-------------------+-----------------+
| 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
Figure 3: Mapping to Scribe Messagestranslate error, please retry
Note 1: These Scribe messages are handled by RELOAD messages.
注1：这些Scribe消息由重载消息处理。
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.
此消息将创建具有组\u id的组。此消息必须传递到其节点\u id最接近组\u 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.
要加入多播树，节点应发送一个以组id为密钥的加入请求。此消息由覆盖路由到树的集合点。如果中间节点已经是此树的转发器，则应将加入节点添加为子节点。否则，节点应为组创建子表并添加加入节点。然后，它应该向集合点发送连接请求，终止来自子节点的连接请求。
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用法，在接受加入请求后，必须向加入节点返回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.
离开多播组时，节点应更改其本地状态以指示其离开了该组。如果节点的表中没有子节点，它必须向其父节点发送一个请假请求，从父节点向上移动多播树，并在移除离开节点后仍有子节点的节点处停止。
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协议的一部分，但本文件中提出的基本协议要求此消息。因此，用法必须发送此消息以确认加入节点接受其父节点。
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消息的对等方希望拒绝该消息，则使用必须发送该消息。
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.
必须将要多播到组的消息发送到集合节点，并从该节点沿树向下转发。如果节点是树的成员而不仅仅是转发器，那么它应该将多播数据传递给应用程序。
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条带。多播树森林中的每一棵树都是一棵（几乎）完整的arity f树。这些树在概念上是分开的：系统的每个节点在每个树中出现一次，其中内容提供者是所有树中的源。为了确保每个对等节点贡献的带宽与其接收的带宽相同，每个节点都是所有树中的一个叶，除了一个，其中该节点将用作内部节点（该节点的适当树）。为了减少后面讨论的复杂性，本节的其余部分将假设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 独子节点：其父节点（在任何多播树中）是不完整节点的节点
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显示了重新加载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 |
+---------+-------------------+-----------------+
+---------+-------------------+-----------------+
| 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.
此消息将创建具有组\u id的组。此消息必须传递到其节点\u id最接近组\u 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的类型，连接算法如下所示：
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 特殊节点：由于此节点是所有子树中的一个叶，因此加入节点可以采用一棵树中的节点，而成为另一棵树中的子节点。
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，这些消息由消息类型改革封装。在此过程中，P2PCast消息将包含在改革的选项参数中。P2PCast定义了以下重组消息：
Takeon: To take another peer as a child
Taken：把另一个同伴当作孩子
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：与Replace不同的是，使节点成为其子节点的调用节点会释放一个随机子节点
Direct: To direct a node to its would-be parent
Direct：将节点定向到其可能的父节点
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用法，在接受加入请求后，必须向加入节点返回一条JoinAccept消息（每个子树一条）。
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.
离开多播组时，节点将更改其本地状态以指示其离开了该组。不管离开节点是树的根，离开节点在其适当的树中必须是完整的或不完整的。在其他树中，节点是一片叶子，只需通知其父节点即可消失。对于正确的树，如果节点不完整，则将替换为其子节点。但是，如果节点已完成，则会创建一个由随机子节点填充的间隙。如果这个孩子是不完整的，它可以简单地填补空白。然而，如果它是完整的，它需要摆脱一个随机的孩子。此孩子被定向到其兄弟姐妹，兄弟姐妹随机生下一个孩子。这个过程沿着树向下波动，直到到达下一个最后一级。然后，另一条带中已删除节点的父节点将shed节点作为子节点。
Again, for the reorganization of the tree, the Reform message type is used as defined in the previous section.
同样，对于树的重组，如前一节中所定义的，使用改革消息类型。
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协议的一部分，但本文档中定义的基本协议需要此消息。因此，用法必须发送此消息以确认加入节点接受其父节点。与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条带向下转发。然后通过子树发送每个条带。如果接收节点是树的成员，而不仅仅是转发器，则它可以将多播数据向上传递给应用程序。
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].
所有消息都映射到重新加载实验消息类型。映射如图5所示。第14.2节列出了信息代码。[重新加载]中提供了消息正文的格式。
+-------------------------+------------------+
| 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 |
+-------------------------+------------------+
+-------------------------+------------------+
| 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：重新加载消息代码映射
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]规定：“0xF0000001到0xFFFFFE范围内的代码点保留供私人使用”。ALM使用种类ID在专用范围内定义。
All ALM Usage messages map to the RELOAD Message Extension mechanism.
所有ALM使用消息都映射到重新加载消息扩展机制。
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为实验目的定义exp_a_req和exp_a_ans。本规范仅对所有ALM消息使用这些消息类型。重新加载定义MessageContents数据结构。ALM映射使用以下字段：
o message_code: exp_a_req for requests and exp_a_ans for responses
o 消息代码：exp_a_req用于请求，exp_a_ans用于响应
o message_body: contains one instance of ALMHeader followed by one instance of ALMMessageContents
o message_body：包含一个ALMHeader实例，后跟一个ALMMessageContents实例
o extensions: unused
o 扩展：未使用
struct {
uint32 sam_token;
uint16 alm_algorithm_id;
uint8 version;
} ALMHeader;
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_令牌：前四个字节将此消息标识为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。每个多播树只使用一种算法。具有不同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.
版本：正在使用的ALM协议的版本。这是一个介于0.1和25.4之间的定点整数。本文档描述了值为0xA的版本1.0。
struct {
uint16 alm_message_code;
opaque alm_message_body;
} ALMMessageContents;
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_消息代码：表示正在发送的消息。第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：消息体本身，表示为可变长度的字节字符串。字节本身取决于代码值。参见第8节和第9节，其中描述了各种ALM方法，以了解有效负载内容的定义。
Response codes are defined in Section 6.3.3.1 of [RELOAD]. This specification maps to RELOAD ErrorResponse as follows:
响应代码在[重新加载]第6.3.3.1节中定义。本规范映射到重新加载错误响应，如下所示：
ErrorResponse.error_code = Error_Exp_A;
ErrorResponse.error\u code=错误\u Exp\u A；
Error_info contains an ALMErrorResponse instance.
错误信息包含一个ALMErrorResponse实例。
public struct {
uint16 alm_error_code;
opaque alm_error_info<0..2^16-1>;
} 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_错误代码：定义了以下错误代码值。第14.3节中定义了这些数值。
Error_Unknown_Algorithm: The multicast algorithm is not known or not supported.
错误\未知\算法：多播算法未知或不受支持。
Error_Child_Limit_Reached: The maximum number of child nodes has been reached for this node.
错误\u Child\u Limit\u已达到：已达到此节点的最大子节点数。
Error_Node_Bandwidth_Reached: The overall data bandwidth limit through this node has been reached.
错误\节点\带宽\已达到：已达到通过此节点的总体数据带宽限制。
Error_Node_Conn_Limit_Reached: The total number of connections to this node has been reached.
错误\u节点\u连接\u限制\u已达到：已达到此节点的连接总数。
Error_Link_Cap_Limit_Reached: The capacity of a link has been reached.
错误\u链接\u上限\u已达到：已达到链接的容量。
Error_Node_Mem_Limit_Reached: An internal memory capacity of the node has been reached.
错误\u Node\u Mem\u Limit\u已达到：已达到节点的内部内存容量。
Error_Node_CPU_Cap_Limit_Reached: An internal processing capacity of the node has been reached.
错误\u节点\u CPU\u上限\u已达到：已达到节点的内部处理能力。
Error_Path_Limit_Reached: The maximum path length in hop count over the multicast tree has been reached.
错误\u路径\u限制\u已达到：已达到多播树上跃点计数的最大路径长度。
Error_Path_Delay_Limit_Reached: The maximum path length in message delay over the multicast tree has been reached.
错误\路径\延迟\限制\已达到：已达到多播树上消息延迟的最大路径长度。
Error_Tree_Fanout_Limit_Reached: The maximum fanout of a multicast tree has been reached.
错误\u Tree\u Fanout\u Limit\u已达到：已达到多播树的最大Fanout。
Error_Tree_Depth_Limit_Reached: The maximum height of a multicast tree has been 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.
具有“节点匹配”权限的节点将CreateALMTree请求发送到组id节点，该组id节点对其自己的地址也具有节点匹配权限。group_id节点确定是否创建新树，如果是，则执行本地StoreReq。如果CreateALMTree成功，则可以使用Fetch检索ALMTree实例。创建树的示例消息流如图6所示。
P1 P2 P3 P4 group_id
| | | | |
| | | | |
| | | | |
| CreateALMTree | | |
|------------------------------->|
| | | | |
| | | | | StoreReq
| | | | |--+
| | | | | |
| | | | | |
| | | | |<-+
| | | | | StoreResponse
| | | | |--+
| | | | | |
| | | | | |
| | | | |<-+
| | | | |
| | | | |
| | CreateALMTreeResponse |
|<-------------------------------|
| | | | |
| | | | |
| Fetch | | |
|------------------------------->|
| | | | |
| | | | |
| | FetchResponse |
|<-------------------------------|
| | | | |
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将节点组_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 | |
| |<---------------| |
| | | | |
| | | | |
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 | | |
|----------------------->| |
| | | | |
| | | | |
P1 P2 P3 P4 group_id
| | | | |
| | | | |
| | | Leave | |
|<-----------------------| |
| | | | |
| LeaveResponse | | |
|----------------------->| |
| | | | |
| | | | |
Figure 8: Message Flow Example for Leave Tree
图8:leavetree的消息流示例
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 | |
|<-----------------------| |
| | | | |
| | | | |
| | | | |
P1 P2 P3 P4 group_id
| | | | |
| Push | | | |
|------------------------------->|
| | | | |
| | | PushResponse|
|<-------------------------------|
| | | | |
| | | | Push|
|<-------------------------------|
| | | | |
| PushResponse | | |
|------------------------------->|
| | | | |
|Push | | | |
|------>| | | |
| | | | |
|PushResponse | | |
|<------| | | |
| | | | |
| Push | | | |
|----------------------->| |
| | | | |
| | PushResponse | |
|<-----------------------| |
| | | | |
| | | | |
| | | | |
Figure 9: Message Flow Example for Pushing Data
图9：推送数据的消息流示例
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.
本节根据[重新加载]第7.4.5节定义了ALMTree类型。每个ALM树实例的覆盖中都存储了一个ALMTree类型的实例。它存储在地址组_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。（根据[重新加载]第14.6节，这是一个专用代码点。）ALMTree种类ID的资源名称是用于标识ALM树的会话密钥。
Data Model: The data model is the ALMTree structure.
数据模型：数据模型为ALMTree结构。
Access Control: NODE-MATCH. The node performing the store operation is required to have NODE-MATCH access.
访问控制：节点匹配。执行存储操作的节点需要具有节点匹配访问权限。
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;
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.
没有为重新加载配置文件定义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算法ID”注册表。此注册表中的条目是16位整数，表示本文档第10.1节中描述的应用层多播算法。0x0003至0x7FFF范围内的代码点应通过RFC 5226[RFC5226]专家评审进行注册。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 |
+----------------+-------------------+-----------+
+----------------+-------------------+-----------+
| 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消息代码”注册表。此注册表中的条目为16位整数，表示本文件第10.2节所述的消息代码。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 |
+-------------------------+----------------------+-----------+
+-------------------------+----------------------+-----------+
| 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.
这些值已用于实验目的。这些值不适用于任何种类的供应商特定用途，也不得用于操作部署。
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错误代码”注册表。此注册表中的条目为16位整数，表示本文件第10.3节所述的错误代码。0x000D到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 |
+----------------------------------+---------------+-----------+
+----------------------------------+---------------+-----------+
| 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.
覆盖易受拒绝服务和共谋攻击。我们没有解决覆盖安全问题。我们假设将使用[RELOAD]中定义的节点身份验证模型。
Security issues specific to ALM Usage include the following:
与ALM使用相关的安全问题包括：
o The right to create group_id at some node_id
o 在某个节点\u id上创建组\u 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 对每秒消息数和带宽使用的限制
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 Huguein、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]Buford，J.和H.Yu，“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>.
[Castro 2002]Castro，M.，Druschel，P.，Kermarec，A.，和A.Rowstron，“抄写器：大规模分散的应用级多播基础设施”，IEEE通信选定领域杂志，第20卷，第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>.
[Castro 2003]Castro，M.，Jones，M.，Kermarec，A.，Rowstron，A.，Theimer，M.，Wang，H.，和A.Wolman，“使用对等覆盖构建的可伸缩应用程序级多播的评估”，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.，和S.Venaas，“透明混合多播的通用API”，正在进行的工作，2013年4月。
[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.“在P2P覆盖网络中使用多播”，《对等网络手册》，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.
[重新加载]Jennings，C.，Lowekamp，B.，Ed.，Rescorla，E.，Baset，S.，和H.Schulzrinne，“资源定位和发现（重新加载）基本协议”，正在进行的工作，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，“在RFCs中编写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]Muramoto，E.，Imai，Y.，和N.Kawaguchi，“非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
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
Mario Kolberg（编辑）斯特林大学计算科学与数学系斯特灵FK94LAUK
Phone: +44 1786 46 7440
EMail: mkolberg@ieee.org
URI: http://www.cs.stir.ac.uk/~mko
Phone: +44 1786 46 7440
EMail: mkolberg@ieee.org
URI: http://www.cs.stir.ac.uk/~mko