Internet Research Task Force (IRTF) M. Waehlisch
Request for Comments: 7046 link-lab & FU Berlin
Category: Experimental T. Schmidt
ISSN: 2070-1721 HAW Hamburg
S. Venaas
Cisco Systems
December 2013
Internet Research Task Force (IRTF) M. Waehlisch
Request for Comments: 7046 link-lab & FU Berlin
Category: Experimental T. Schmidt
ISSN: 2070-1721 HAW Hamburg
S. Venaas
Cisco Systems
December 2013
A Common API for Transparent Hybrid Multicast
透明混合多播的通用API
Abstract
摘要
Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.
组通信服务存在于不同协议层的各种风格和技术实现中。多播数据分发最有效地在最低可用层上执行，但多播技术在整个Internet上的异构部署状态需要在运行时进行自适应服务绑定。如今，很难编写一个在任何地方都能运行并同时利用网络中最有效的多播服务的应用程序。面对健壮性需求，开发人员经常被迫使用由应用程序本身提供的稳定的上层协议。本文档描述了一个通用的多播API，该API适用于底层和覆盖层中的透明通信，并允许访问不同风格的多播。它提出了一种使用多播URI的抽象命名方案，并讨论了不同名称空间和分发技术之间的映射机制。此外，本文档还描述了此API在构建网关方面的应用，这些网关通过Internet互连当前多播域。它报告编程接口的实现，包括服务中间件。本文档是可伸缩自适应多播（SAM）研究组的产品。
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/rfc7046.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7046.
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. Use Cases for the Common API ...............................6
1.2. Illustrative Examples ......................................7
1.2.1. Support of Multiple Underlying Technologies .........7
1.2.2. Support of Multi-Resolution Multicast ...............9
2. Terminology ....................................................10
3. Overview .......................................................10
3.1. Objectives and Reference Scenarios ........................10
3.2. Group Communication API and Protocol Stack ................12
3.3. Naming and Addressing .....................................14
3.4. Namespaces ................................................15
1. Introduction ....................................................4
1.1. Use Cases for the Common API ...............................6
1.2. Illustrative Examples ......................................7
1.2.1. Support of Multiple Underlying Technologies .........7
1.2.2. Support of Multi-Resolution Multicast ...............9
2. Terminology ....................................................10
3. Overview .......................................................10
3.1. Objectives and Reference Scenarios ........................10
3.2. Group Communication API and Protocol Stack ................12
3.3. Naming and Addressing .....................................14
3.4. Namespaces ................................................15
3.5. Name-to-Address Mapping ...................................15
3.5.1. Canonical Mapping ..................................16
3.5.2. Mapping at End Points ..............................16
3.5.3. Mapping at Inter-Domain Multicast Gateways .........16
3.6. A Note on Explicit Multicast (Xcast) ......................16
3.7. MTU Handling ..............................................17
4. Common Multicast API ...........................................18
4.1. Notation ..................................................18
4.2. URI Scheme Definition .....................................18
4.2.1. Syntax .............................................18
4.2.2. Semantic ...........................................19
4.2.3. Generic Namespaces .................................20
4.2.4. Application-Centric Namespaces .....................20
4.2.5. Future Namespaces ..................................20
4.3. Additional Abstract Data Types ............................21
4.3.1. Interface ..........................................21
4.3.2. Membership Events ..................................21
4.4. Group Management Calls ....................................22
4.4.1. Create .............................................22
4.4.2. Delete .............................................22
4.4.3. Join ...............................................22
4.4.4. Leave ..............................................23
4.4.5. Source Register ....................................23
4.4.6. Source Deregister ..................................23
4.5. Send and Receive Calls ....................................24
4.5.1. Send ...............................................24
4.5.2. Receive ............................................24
4.6. Socket Options ............................................25
4.6.1. Get Interfaces .....................................25
4.6.2. Add Interface ......................................25
4.6.3. Delete Interface ...................................26
4.6.4. Set TTL ............................................26
4.6.5. Get TTL ............................................26
4.6.6. Atomic Message Size ................................27
4.7. Service Calls .............................................27
4.7.1. Group Set ..........................................27
4.7.2. Neighbor Set .......................................28
4.7.3. Children Set .......................................28
4.7.4. Parent Set .........................................28
4.7.5. Designated Host ....................................29
4.7.6. Enable Membership Events ...........................29
4.7.7. Disable Membership Events ..........................30
4.7.8. Maximum Message Size ...............................30
5. Implementation .................................................30
6. IANA Considerations ............................................30
7. Security Considerations ........................................31
8. Acknowledgements ...............................................31
3.5. Name-to-Address Mapping ...................................15
3.5.1. Canonical Mapping ..................................16
3.5.2. Mapping at End Points ..............................16
3.5.3. Mapping at Inter-Domain Multicast Gateways .........16
3.6. A Note on Explicit Multicast (Xcast) ......................16
3.7. MTU Handling ..............................................17
4. Common Multicast API ...........................................18
4.1. Notation ..................................................18
4.2. URI Scheme Definition .....................................18
4.2.1. Syntax .............................................18
4.2.2. Semantic ...........................................19
4.2.3. Generic Namespaces .................................20
4.2.4. Application-Centric Namespaces .....................20
4.2.5. Future Namespaces ..................................20
4.3. Additional Abstract Data Types ............................21
4.3.1. Interface ..........................................21
4.3.2. Membership Events ..................................21
4.4. Group Management Calls ....................................22
4.4.1. Create .............................................22
4.4.2. Delete .............................................22
4.4.3. Join ...............................................22
4.4.4. Leave ..............................................23
4.4.5. Source Register ....................................23
4.4.6. Source Deregister ..................................23
4.5. Send and Receive Calls ....................................24
4.5.1. Send ...............................................24
4.5.2. Receive ............................................24
4.6. Socket Options ............................................25
4.6.1. Get Interfaces .....................................25
4.6.2. Add Interface ......................................25
4.6.3. Delete Interface ...................................26
4.6.4. Set TTL ............................................26
4.6.5. Get TTL ............................................26
4.6.6. Atomic Message Size ................................27
4.7. Service Calls .............................................27
4.7.1. Group Set ..........................................27
4.7.2. Neighbor Set .......................................28
4.7.3. Children Set .......................................28
4.7.4. Parent Set .........................................28
4.7.5. Designated Host ....................................29
4.7.6. Enable Membership Events ...........................29
4.7.7. Disable Membership Events ..........................30
4.7.8. Maximum Message Size ...............................30
5. Implementation .................................................30
6. IANA Considerations ............................................30
7. Security Considerations ........................................31
8. Acknowledgements ...............................................31
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................33
Appendix A. C Signatures ..........................................35
Appendix B. Use Case for the API ..................................37
Appendix C. Deployment Use Cases for Hybrid Multicast .............38
C.1. DVMRP ......................................................38
C.2. PIM-SM .....................................................38
C.3. PIM-SSM ....................................................39
C.4. BIDIR-PIM ..................................................40
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................33
Appendix A. C Signatures ..........................................35
Appendix B. Use Case for the API ..................................37
Appendix C. Deployment Use Cases for Hybrid Multicast .............38
C.1. DVMRP ......................................................38
C.2. PIM-SM .....................................................38
C.3. PIM-SSM ....................................................39
C.4. BIDIR-PIM ..................................................40
Currently, group application programmers need to choose the distribution technology that the application will require at runtime. There is no common communication Interface that abstracts multicast transmission and subscriptions from the deployment state at runtime, nor has the use of DNS for Group Addresses been established. The standard multicast socket options [RFC3493] [RFC3678] are bound to an IP version by not distinguishing between the naming and addressing of multicast identifiers. Group communication, however,
目前，组应用程序程序员需要选择应用程序在运行时所需的分发技术。没有通用通信接口在运行时从部署状态提取多播传输和订阅，也没有为组地址使用DNS。标准多播套接字选项[RFC3493][RFC3678]通过不区分多播标识符的命名和寻址绑定到IP版本。然而，团体沟通，
o is commonly implemented in different flavors, such as any-source multicast (ASM) vs. source-specific multicast (SSM),
o 通常以不同的方式实现，例如任意源多播（ASM）与源特定多播（SSM），
o is commonly implemented on different layers (e.g., IP vs. application-layer multicast), and
o 通常在不同的层上实现（例如，IP与应用层多播），以及
o may be based on different technologies on the same tier, as seen with IPv4 vs. IPv6.
o 可能基于同一层上的不同技术，如IPv4与IPv6。
The objective of this document is to provide for programmers a universal access to group services.
本文档的目的是为程序员提供对组服务的通用访问。
Multicast application development should be decoupled from technological deployment throughout the infrastructure. It requires a common multicast API that offers calls to transmit and receive multicast data independent of the supporting layer and the underlying technological details. For inter-technology transmissions, a consistent view of multicast states is needed as well. This document describes an abstract group communication API and core functions necessary for transparent operations. Specific implementation guidelines with respect to operating systems or programming languages are out of scope for this document.
多播应用程序开发应与整个基础设施的技术部署分离。它需要一个通用的多播API，该API提供独立于支持层和底层技术细节的发送和接收多播数据的调用。对于技术间传输，还需要多播状态的一致视图。本文档描述了透明操作所需的抽象组通信API和核心功能。有关操作系统或编程语言的具体实施指南不在本文档范围内。
In contrast to the standard multicast socket Interface, the API introduced in this document abstracts naming from addressing. Using a multicast address in the current socket API predefines the corresponding routing layer. In this specification, the multicast name used for joining a group denotes an application-layer data stream that is identified by a multicast URI, independent of its binding to a specific distribution technology. Such a Group Name can be mapped to variable routing identifiers.
与标准的多播套接字接口不同，本文介绍的API将命名从寻址中抽象出来。在当前套接字API中使用多播地址可以预定义相应的路由层。在本规范中，用于加入组的多播名称表示由多播URI标识的应用层数据流，与其与特定分发技术的绑定无关。这样的组名可以映射到可变路由标识符。
The aim of this common API is twofold:
此通用API的目的有两个：
o Enable any application programmer to implement group-oriented data communication independent of the underlying delivery mechanisms. In particular, allow for a late binding of group applications to multicast technologies that makes applications efficient but robust with respect to deployment aspects.
o 使任何应用程序程序员能够实现独立于底层交付机制的面向组的数据通信。特别是，允许将组应用程序后期绑定到多播技术，这使得应用程序在部署方面既高效又健壮。
o Allow for flexible namespace support in group addressing and thereby separate naming and addressing (or routing) schemes from the application design. This abstraction not only decouples programs from specific aspects of underlying protocols but may open application design to extend to specifically flavored group services.
o 允许在组寻址中提供灵活的命名空间支持，从而将命名和寻址（或路由）方案与应用程序设计分开。这种抽象不仅将程序与底层协议的特定方面分离，而且还可以开放应用程序设计，以扩展到特定风格的组服务。
Multicast technologies may be of various peer-to-peer kinds, IPv4 or IPv6 network-layer multicast, or implemented by some other application service. Corresponding namespaces may be IP addresses or DNS naming, overlay hashes, or other application-layer group identifiers like <sip:*@peanuts.org>, but they can also be names independently defined by the applications. Common namespaces are introduced later in this document but follow an open concept suitable for further extensions.
多播技术可以是各种对等类型、IPv4或IPv6网络层多播，或者由一些其他应用服务实现。相应的名称空间可以是IP地址或DNS命名、覆盖哈希或其他应用层组标识符，如<sip:@peanuts.org>，但也可以是应用程序独立定义的名称。通用名称空间将在本文档后面介绍，但遵循适合进一步扩展的开放概念。
This document also discusses mapping mechanisms between different namespaces and forwarding technologies and proposes expressions of defaults for an intended binding. Additionally, the multicast API provides internal Interfaces to access current multicast states at the host. Multiple multicast protocols may run in parallel on a single host. These protocols may interact to provide a gateway function that bridges data between different domains. The usage of this API at gateways operating between current multicast instances throughout the Internet is described as well. Finally, a report on an implementation of the programming Interface, including service middleware, is presented.
本文档还讨论了不同名称空间和转发技术之间的映射机制，并提出了预期绑定的默认表达式。此外，多播API提供内部接口以访问主机上的当前多播状态。多个多播协议可以在单个主机上并行运行。这些协议可以相互作用以提供网关功能，在不同域之间桥接数据。本文还描述了该API在网关上的使用，这些网关在Internet上的当前多播实例之间运行。最后，报告了编程接口的实现，包括服务中间件。
This document represents the consensus of the SAM Research Group. It has been reviewed by the Research Group members active in the specific area of work. In addition, this document has been comprehensively reviewed by people who are not "in" the Research Group but are experts in the area.
本文件代表SAM研究小组的共识。该报告已由活跃于特定工作领域的研究小组成员审查。此外，本文件已由非研究小组成员但该领域专家的人士进行了全面审查。
The following generic use cases can be identified; these use cases require an abstract common API for multicast services:
可以确定以下通用用例；这些用例需要多播服务的抽象通用API：
Application Programming Independent of Technologies: Application programmers are provided with group primitives that remain independent of multicast technologies and their deployment in target domains. Thus, for a given application, they can develop a program that will run in every deployment scenario. The use of Group Names in the form of abstract metadata types allows applications to remain namespace-agnostic in the sense that the resolution of namespaces and name-to-address mappings may be delegated to a system service at runtime. Complexity is thereby minimized, as developers need not care about how data is distributed in groups, while the system service can take advantage of extended information of the network environment as acquired at startup.
独立于技术的应用程序编程：向应用程序程序员提供组原语，这些原语保持独立于多播技术及其在目标域中的部署。因此，对于给定的应用程序，他们可以开发一个在每个部署场景中运行的程序。以抽象元数据类型的形式使用组名允许应用程序保持名称空间不可知，因为名称空间的解析和名称到地址的映射可能在运行时委托给系统服务。因此，复杂性被最小化，因为开发人员不需要关心数据如何在组中分布，而系统服务可以利用启动时获得的网络环境的扩展信息。
Global Identification of Groups: Groups can be identified independent of technological instantiations and beyond deployment domains. Taking advantage of the abstract naming, an application can thus match data received from different Interface technologies (e.g., IPv4, IPv6, and overlays) to belong to the same group. This not only increases flexibility -- an application may, for instance, combine heterogeneous multipath streams -- but also simplifies the design and implementation of gateways.
组的全局标识：可以独立于技术实例化和部署域之外标识组。因此，利用抽象命名，应用程序可以将从不同接口技术（例如IPv4、IPv6和覆盖）接收的数据匹配为属于同一组。这不仅增加了灵活性（例如，应用程序可以组合异构多路径流），还简化了网关的设计和实现。
Uniform Access to Multicast Flavors: The URI naming scheme uniformly supports different flavors of group communication, such as any-source multicast and source-specific multicast, and selective broadcast, independent of their service instantiation. The traditional SSM model, for instance, can experience manifold support by directly mapping the multicast URI (i.e., "group@instantiation") to an (S,G) state on the IP layer, by first resolving S for a subsequent Group Address query, by transferring this process to any of the various source-specific overlay schemes, or by delegating to a plain replication server. The application programmer can invoke any of these underlying mechanisms with the same line of code.
统一访问多播风格：URI命名方案统一支持不同风格的组通信，例如任何源多播和源特定多播，以及选择性广播，与它们的服务实例化无关。例如，传统的SSM模型可以通过直接映射多播URI（即group@instantiation）转换为IP层上的（S，G）状态，方法是首先解析S以进行后续组地址查询，然后将此过程传输到各种特定于源的覆盖方案，或者通过委托给普通复制服务器。应用程序程序员可以用同一行代码调用任何这些底层机制。
Simplified Service Deployment through Generic Gateways: The common multicast API allows for an implementation of abstract gateway functions with mappings to specific technologies residing at the system level. Generic gateways may provide a simple bridging service and facilitate an inter-domain deployment of multicast.
通过通用网关简化服务部署：通用多播API允许实现抽象网关功能，并映射到驻留在系统级别的特定技术。通用网关可以提供简单的桥接服务，并促进多播的域间部署。
Mobility-Agnostic Group Communication: Group naming and management as foreseen in the common multicast API remain independent of locators. Naturally, applications stay unaware of any mobility-related address changes. Handover-initiated re-addressing is delegated to the mapping services at the system level and may be designed to smoothly interact with mobility management solutions provided at the network or transport layer (see [RFC5757] for mobility-related aspects).
移动性不可知的组通信：公共多播API中预见的组命名和管理仍然独立于定位器。当然，应用程序不知道任何与移动相关的地址更改。切换启动的重新寻址被委托给系统级的映射服务，并可设计为与网络或传输层提供的移动性管理解决方案平滑交互（移动性相关方面见[RFC5757]）。
On a very high level, the common multicast API provides the application programmer with one single Interface to manage multicast content independent of the technology underneath. Considering the following simple example in Figure 1, a multicast source S is connected via IPv4 and IPv6. It distributes one flow of multicast content (e.g., a movie). Receivers are connected via IPv4/v6 and Overlay Multicast (OM), respectively.
在一个非常高的层次上，通用多播API为应用程序程序员提供了一个单独的接口来管理多播内容，而与下面的技术无关。考虑图1中的以下简单示例，多播源S通过IPv4和IPv6连接。它分发一个多播内容流（例如电影）。接收器分别通过IPv4/v6和覆盖多播（OM）连接。
+-------+ +-------+ +-------+
| S | | R1 | | R3 |
+-------+ +-------+ +-------+
v6| v4| |v4 |OM
| | / |
| ***| *** ***/ ** *** /*** *** ***
\* |* ** /** * * /* ** ** *
*\ \_______/_______*__v4__+-------+ * / *
*\ IPv4/v6 * | R2 |__OM__ *_/ Overlay Mcast *
* \_________________*__v6__+-------+ * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
+-------+ +-------+ +-------+
| S | | R1 | | R3 |
+-------+ +-------+ +-------+
v6| v4| |v4 |OM
| | / |
| ***| *** ***/ ** *** /*** *** ***
\* |* ** /** * * /* ** ** *
*\ \_______/_______*__v4__+-------+ * / *
*\ IPv4/v6 * | R2 |__OM__ *_/ Overlay Mcast *
* \_________________*__v6__+-------+ * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
Figure 1: Common Scenario: Source S Sends the Same Multicast Content via Different Technologies
图1：常见场景：源S通过不同的技术发送相同的多播内容
Using the current BSD socket API, the application programmer needs to decide on the IP technologies at coding time. Additional distribution techniques, such as overlay multicast, must be individually integrated into the application. For each technology, the application programmer needs to create a separate socket and
使用当前的BSD套接字API，应用程序程序员需要在编码时决定IP技术。附加的分发技术，如覆盖多播，必须单独集成到应用程序中。对于每种技术，应用程序程序员都需要创建一个单独的套接字和
initiate a dedicated join or send. As the current socket API does not distinguish between Group Name and Group Address, the content will be delivered multiple times to the same receiver (cf. R2). Whenever the source distributes content via a technology that is not supported by the receivers or its Internet Service Provider (cf. R3), a gateway is required. Gateway functions rely on a coherent view of the Multicast Group states.
启动专用加入或发送。由于当前的套接字API不区分组名和组地址，因此内容将多次发送到同一接收者（参见R2）。每当源通过接收方或其互联网服务提供商（参见R3）不支持的技术分发内容时，都需要网关。网关功能依赖于多播组状态的一致视图。
The common multicast API simplifies programming of multicast applications, as it abstracts content distribution from specific technologies. In addition to calls that implement the receiving and sending of multicast data, the API provides service calls to grant access to internal multicast states at the host. The API description provided in this document defines a minimal set of programming Interfaces to the system components at the host to operate group communication. It is left to specific implementations to provide additional convenience functions for programmers.
通用多播API简化了多播应用程序的编程，因为它从特定技术中抽象出内容分发。除了实现接收和发送多播数据的调用外，API还提供服务调用，以授予对主机内部多播状态的访问权。本文档中提供的API描述定义了主机上系统组件的一组最小编程接口，以操作组通信。留给特定的实现为程序员提供额外的方便函数。
The implementation of content distribution for the example shown in Figure 1 may then look like:
图1所示示例的内容分发实现可能如下所示：
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Associate all available Interfaces
m.addInterface(getInterfaces());
//Subscribe to Multicast Group
m.join(URI("ham:opaque:news@cnn.com"));
//Send to Multicast Group
m.send(URI("ham:opaque:news@cnn.com"),message);
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Associate all available Interfaces
m.addInterface(getInterfaces());
//Subscribe to Multicast Group
m.join(URI("ham:opaque:news@cnn.com"));
//Send to Multicast Group
m.send(URI("ham:opaque:news@cnn.com"),message);
Send/receive example using the common multicast API
使用公共多播API的发送/接收示例
The gateway function for R2 can be implemented by service calls that look like:
R2的网关功能可以通过如下服务调用实现：
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Check (a) host is designated multicast node for this Interface
// (b) receivers exist
for all this.getInterfaces() {
if(designatedHost(this.interface) &&
childrenSet(this.interface,
URI("ham:opaque:news@cnn.com")) != NULL) {
m.addInterface(this.interface);
}
}
while(true) {
m.send(URI("ham:opaque:news@cnn.com"),message);
}
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Check (a) host is designated multicast node for this Interface
// (b) receivers exist
for all this.getInterfaces() {
if(designatedHost(this.interface) &&
childrenSet(this.interface,
URI("ham:opaque:news@cnn.com")) != NULL) {
m.addInterface(this.interface);
}
}
while(true) {
m.send(URI("ham:opaque:news@cnn.com"),message);
}
Gateway example using the common multicast API
使用公共多播API的网关示例
Multi-resolution multicast adjusts the multicast stream to consider heterogeneous end devices. The multicast data (e.g., available by different compression levels) is typically announced using multiple multicast addresses that are unrelated to each other. Using the common API, multi-resolution multicast can be implemented transparently by an operator with the help of name-to-address mapping, or by systematic naming from a subscriber-centric perspective.
多分辨率组播对组播流进行调整，考虑异构终端设备。多播数据（例如，通过不同的压缩级别可用）通常使用彼此无关的多播地址来宣布。通过使用公共API，运营商可以借助名称到地址的映射透明地实现多分辨率多播，或者从以订户为中心的角度进行系统命名。
Operator-Centric: An operator deploys a domain-specific mapping. In this case, any multicast receiver (e.g., mobile or DSL user) subscribes to the same multicast name, which will be resolved locally to different multicast addresses. In this case, each Group Address represents a different level of data quality.
以操作员为中心：操作员部署特定于域的映射。在这种情况下，任何多播接收器（例如，移动或DSL用户）订阅相同的多播名称，该名称将在本地解析为不同的多播地址。在这种情况下，每个组地址代表不同级别的数据质量。
Subscriber-Centric: In a subscriber-centric example, the multicast receiver chooses the quality in advance, based on a predefined naming syntax. Consider a layered video stream "blockbuster" available at different qualities Q_i, each of which consists of the base layer plus the sum of EL_j, j <= i enhancement layers. Each individual layer may then be accessible by a name "EL_j.Q_i.blockbuster", j <= i, while a specific quality aggregates the corresponding layers to "Q_i.blockbuster", and the full-size movie may be just called "blockbuster".
以订户为中心：在以订户为中心的示例中，多播接收器根据预定义的命名语法提前选择质量。考虑一个分层视频流“大片”在不同质量QQI，其中每一个包括基本层加上Eljj，j＝i增强层的总和。然后，每个单独的层可以通过名称“EL_j.Q_i.blockbuster”，j<=i访问，而特定质量将相应的层聚合为“Q_i.blockbuster”，并且全尺寸电影可以被称为“blockbuster”。
This document uses the terminology as defined for the multicast protocols discussed in [RFC2710], [RFC3376], [RFC3810], [RFC4601], and [RFC4604]. In addition, the following terms will be used:
本文档使用[RFC2710]、[RFC3376]、[RFC3810]、[RFC4601]和[RFC4604]中讨论的多播协议定义的术语。此外，将使用以下术语：
Group Address: A Group Address is a routing identifier. It represents a technological specifier and thus reflects the distribution technology in use. Multicast packet forwarding is based on this address.
组地址：组地址是路由标识符。它表示一个技术说明符，因此反映了正在使用的分发技术。多播数据包转发基于此地址。
Group Name: A Group Name is an application identifier used by applications to manage communication in a Multicast Group (e.g., join/leave and send/receive). The Group Name does not predefine any distribution technologies. Even if it syntactically corresponds to an address, it solely represents a logical identifier.
组名：组名是应用程序用来管理多播组中的通信的应用程序标识符（例如，加入/离开和发送/接收）。组名不预定义任何分发技术。即使它在语法上对应于一个地址，它也只表示一个逻辑标识符。
Multicast Namespace: A Multicast Namespace is a collection of designators (i.e., names or addresses) for groups that share a common syntax. Typical instances of namespaces are IPv4 or IPv6 multicast addresses, overlay group IDs, Group Names defined on the application layer (e.g., SIP or email), or some human-readable string.
多播命名空间：多播命名空间是共享公共语法的组的标识符（即名称或地址）的集合。名称空间的典型实例是IPv4或IPv6多播地址、覆盖组ID、应用层上定义的组名（例如SIP或电子邮件）或一些人类可读的字符串。
Interface: An Interface is a forwarding instance of a distribution technology on a given node, for example, the IP Interface 192.168.1.1 at an IPv4 host, or an overlay routing Interface.
接口：接口是给定节点上分发技术的转发实例，例如IPv4主机上的IP接口192.168.1.1或覆盖路由接口。
Multicast Domain: A Multicast Domain hosts nodes and routers of a common, single multicast forwarding technology and is bound to a single namespace.
多播域：多播域承载一种常见的、单一的多播转发技术的节点和路由器，并绑定到一个名称空间。
Inter-domain Multicast Gateway (IMG): An IMG is an entity that interconnects different Multicast Domains. Its objective is to forward data between these domains, e.g., between an IP layer and overlay multicast.
域间多播网关（IMG）：IMG是连接不同多播域的实体。其目标是在这些域之间转发数据，例如，在IP层和覆盖多播之间转发数据。
The default use case addressed in this document targets applications that participate in a group by using some common identifier taken from some common namespace. This Group Name is typically learned at runtime from user interaction, such as the selection of an IPTV channel, or from dynamic session negotiations as used with the Session Initiation Protocol (SIP) [RFC3261] or Peer-to-Peer SIP
本文档中介绍的默认用例以使用从某个公共名称空间中获取的某个公共标识符参与组的应用程序为目标。该组名称通常在运行时从用户交互（例如IPTV频道的选择）或从与会话发起协议（SIP）[RFC3261]或对等SIP一起使用的动态会话协商中学习
(P2PSIP) [SIP-RELOAD], but may as well have been predefined for an application as a common Group Name. Technology-specific system functions then transparently map the Group Name to Group Addresses such that
（P2PSIP）[SIP-RELOAD]，但也可能已作为通用组名为应用程序预定义。然后，特定于技术的系统功能将组名透明地映射到组地址，以便
o programmers can process Group Names in their programs without the need to consider technological mappings that relate to designated deployments in target domains;
o 程序员可以在他们的程序中处理组名称，而不需要考虑与目标域中的指定部署相关的技术映射；
o applications can identify packets that belong to a logically named group, independent of the Interface technology used for sending and receiving packets; this shall also hold true for multicast gateways.
o 应用程序可以识别属于逻辑命名组的数据包，与用于发送和接收数据包的接口技术无关；这也适用于多播网关。
This document considers two reference scenarios that cover the following hybrid deployment cases displayed in Figure 2:
本文档考虑了两个参考场景，它们涵盖了图2中显示的以下混合部署案例：
1. Multicast Domains running the same multicast technology but remaining isolated, possibly only connected by network-layer unicast.
1. 运行相同多播技术但保持隔离的多播域，可能仅通过网络层单播连接。
2. Multicast Domains running different multicast technologies but hosting nodes that are members of the same Multicast Group.
2. 运行不同多播技术但承载属于同一多播组成员的节点的多播域。
+-------+ +-------+
| Member| | Member|
| Foo | | G |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
* *
* Mcast Tech. A *
* *
* ** ** ** *
*** *** *** ***
+-------+ +-------+ |
| Member| | Member| +-------+
| G | | Foo | | IMG |
+-------+ +-------+ +-------+
| | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * +-------+ * *
* Mcast Tech. A * --| IMG |-- * Mcast Tech. B * +------+
* * +-------+ * * -|Member|
* ** ** ** * * ** ** ** * | G |
*** *** *** *** *** *** *** *** +------+
+-------+ +-------+
| Member| | Member|
| Foo | | G |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
* *
* Mcast Tech. A *
* *
* ** ** ** *
*** *** *** ***
+-------+ +-------+ |
| Member| | Member| +-------+
| G | | Foo | | IMG |
+-------+ +-------+ +-------+
| | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * +-------+ * *
* Mcast Tech. A * --| IMG |-- * Mcast Tech. B * +------+
* * +-------+ * * -|Member|
* ** ** ** * * ** ** ** * | G |
*** *** *** *** *** *** *** *** +------+
Figure 2: Reference Scenarios for Hybrid Multicast, Interconnecting Group Members from Isolated Homogeneous and Heterogeneous Domains
图2：混合多播的参考场景，从孤立的同质和异构域互连组成员
The group communication API abstracts the socket concept and consists of four parts. Two parts combine the essential communication functions, while the remaining two offer optional extensions for enhanced monitoring and management:
组通信API抽象了套接字的概念，由四个部分组成。两个部分结合了基本的通信功能，其余两个部分提供了可选的扩展，以增强监控和管理：
Group Management Calls: provide the minimal API to instantiate an abstract multicast socket and manage group membership;
组管理调用：提供用于实例化抽象多播套接字和管理组成员身份的最小API；
Send/Receive Calls: provide the minimal API to send and receive multicast data in a technology-transparent fashion;
发送/接收调用：提供最小的API，以技术透明的方式发送和接收多播数据；
Socket Options: provide extension calls for an explicit configuration of the multicast socket, such as setting hop limits or associated Interfaces;
套接字选项：为多播套接字的显式配置提供扩展调用，例如设置跃点限制或相关接口；
Service Calls: provide extension calls that grant access to internal multicast states of an Interface, such as the Multicast Groups under subscription or the multicast forwarding information base.
服务调用：提供允许访问接口内部多播状态的扩展调用，例如订阅下的多播组或多播转发信息库。
Multicast applications that use the common API require assistance from a group communication stack. This protocol stack serves two needs:
使用公共API的多播应用程序需要组通信堆栈的帮助。该协议栈满足两个需求：
o It provides system-level support to transfer the abstract functions of the common API, including namespace support, into protocol operations at Interfaces.
o 它提供系统级支持，以将公共API的抽象函数（包括命名空间支持）转换为接口处的协议操作。
o It provides group communication services across different multicast technologies at the local host.
o 它在本地主机上跨不同的多播技术提供组通信服务。
A general initiation of a multicast communication in this setting proceeds as follows:
在此设置中，多播通信的一般启动如下进行：
1. An application opens an abstract multicast socket.
1. 应用程序打开一个抽象的多播套接字。
2. The application subscribes to / leaves / (de)registers a group using a Group Name.
2. 应用程序使用组名订阅/离开/（取消）注册组。
3. An intrinsic function of the stack maps the logical group ID (Group Name) to a technical group ID (Group Address). This function may make use of deployment-specific knowledge, such as available technologies and Group Address management in its domain.
3. 堆栈的固有功能将逻辑组ID（组名称）映射到技术组ID（组地址）。此功能可以利用特定于部署的知识，例如其域中的可用技术和组地址管理。
4. Packet distribution proceeds to and from one or several multicast-enabled Interfaces.
4. 数据包分发在一个或多个支持多播的接口之间进行。
The abstract multicast socket represents a group communication channel composed of one or multiple Interfaces. A socket may be created without explicit Interface association by the application, which leaves the choice of the underlying forwarding technology to the group communication stack. However, an application may also bind the socket to one or multiple dedicated Interfaces and therefore predefine the forwarding technology and the Multicast Namespace(s) of the Group Address(es).
抽象多播套接字表示由一个或多个接口组成的组通信信道。应用程序可以在没有显式接口关联的情况下创建套接字，这将底层转发技术的选择留给组通信堆栈。然而，应用程序还可以将套接字绑定到一个或多个专用接口，从而预定义转发技术和组地址的多播命名空间。
Applications are not required to maintain mapping states for Group Addresses. The group communication stack accounts for the mapping of the Group Name to the Group Address(es) and vice versa. Multicast data passed to the application will be augmented by the corresponding Group Name. Multiple multicast subscriptions thus can be conducted on a single multicast socket without the need for Group Name encoding on the application side.
应用程序不需要维护组地址的映射状态。组通信堆栈负责将组名称映射到组地址，反之亦然。传递给应用程序的多播数据将由相应的组名进行扩充。因此，可以在单个多播套接字上执行多个多播订阅，而无需在应用程序端进行组名编码。
Hosts may support several multicast protocols. The group communication stack discovers available multicast-enabled Interfaces. It provides a minimal hybrid function that bridges data between different Interfaces and Multicast Domains. The details of service discovery are out of scope for this document.
主机可能支持多种多播协议。组通信堆栈发现可用的支持多播的接口。它提供了一个最小的混合功能，在不同接口和多播域之间架起数据桥梁。服务发现的详细信息超出了本文档的范围。
The extended multicast functions can be implemented by middleware, as conceptually presented in Figure 3.
扩展的多播功能可以通过中间件实现，如图3所示。
*-------* *-------*
| App 1 | | App 2 |
*-------* *-------*
| |
*---------------------* ---|
| Middleware | |
*---------------------* |
| | |
*---------* | |
| Overlay | | \ Group Communication
*---------* | / Stack
| | |
| | |
*---------------------* |
| Underlay | |
*---------------------* ---|
*-------* *-------*
| App 1 | | App 2 |
*-------* *-------*
| |
*---------------------* ---|
| Middleware | |
*---------------------* |
| | |
*---------* | |
| Overlay | | \ Group Communication
*---------* | / Stack
| | |
| | |
*---------------------* |
| Underlay | |
*---------------------* ---|
Figure 3: Architecture of a Group Communication Stack with Middleware Offering Uniform Access to Multicast in Underlay and Overlay
图3：具有中间件的组通信堆栈的体系结构，该中间件在底层和覆盖层中提供对多播的统一访问
Applications use Group Names to identify groups. Names can uniquely determine a group in a global communication context and hide technological deployment for data distribution from the application. In contrast, multicast forwarding operates on Group Addresses. Even though both identifiers may be symbolically identical, they carry different meanings. They may also belong to different Multicast Namespaces. The namespace of a Group Address reflects a routing technology, while the namespace of a Group Name represents the context in which the application operates.
应用程序使用组名来标识组。名称可以唯一地确定全局通信上下文中的组，并对应用程序隐藏数据分发的技术部署。相反，多播转发在组地址上运行。尽管两个标识符在符号上可能相同，但它们具有不同的含义。它们也可能属于不同的多播名称空间。组地址的名称空间反映路由技术，而组名称的名称空间表示应用程序运行的上下文。
URIs [RFC3986] are a common way to represent namespace-specific identifiers in applications in the form of an abstract metadata type. Throughout this document, all Group Names follow a URI notation using the syntax defined in Section 4.2. Examples are ham:ip:224.1.2.3:5000 for a canonical IPv4 ASM group at UDP port 5000 and ham:sip:news@cnn.com for application-specific naming with service instantiator and default port selection.
URI[RFC3986]是以抽象元数据类型的形式表示应用程序中特定于命名空间的标识符的常用方法。在本文档中，所有组名都使用第4.2节中定义的语法遵循URI表示法。例如，UDP端口5000处的规范IPv4 ASM组的ham:ip:224.1.2.3:5000和ham:sip:news@cnn.com使用服务实例化器和默认端口选择进行特定于应用程序的命名。
An implementation of the group communication stack can provide convenience functions that detect the namespace of a Group Name or further optimize service instantiation. In practice, such a library would provide support for high-level data types to the application, similar to some versions of the current socket API (e.g., InetAddress in Java). Using this data type could implicitly determine the namespace. The details of automatic namespace identification or service handling are out of scope for this document.
组通信堆栈的实现可以提供方便的功能，用于检测组名称的名称空间或进一步优化服务实例化。实际上，这样的库将为应用程序提供对高级数据类型的支持，类似于当前socket API的某些版本（例如Java中的InetAddress）。使用此数据类型可以隐式确定名称空间。自动名称空间标识或服务处理的详细信息不在本文档的范围内。
Namespace identifiers in URIs are placed in the scheme element and characterize syntax and semantics of the group identifier. They enable the use of convenience functions and high-level data types while processing URIs. When used in names, they may indicate an application context or may facilitate a default mapping and a recovery of names from addresses. When used in addresses, they characterize the group identifier's type.
URI中的命名空间标识符放在scheme元素中，并描述组标识符的语法和语义。它们允许在处理URI时使用方便的函数和高级数据类型。在名称中使用时，它们可能表示应用程序上下文，或者可能有助于默认映射和从地址恢复名称。在地址中使用时，它们表示组标识符的类型。
In compliance with the URI concept, namespace schemes can be added. Examples of schemes are generic (see Section 4.2.3) or inherited from applications (see Section 4.2.4).
根据URI概念，可以添加名称空间方案。方案示例为通用（见第4.2.3节）或从应用程序继承（见第4.2.4节）。
The multicast communication paradigm requires all group members to subscribe to the same Group Name, taken from a common Multicast Namespace, and to thereby identify the group in a technology-agnostic way. Following this common API, a sender correspondingly registers a Group Name prior to transmission.
多播通信范例要求所有组成员订阅来自公共多播命名空间的相同组名，从而以技术无关的方式标识组。遵循此通用API，发送方在传输之前相应地注册组名。
At communication end points, Group Names require a mapping to Group Addresses prior to service instantiation at the Interfaces of the end points. Similarly, a mapping is needed at gateways to consistently translate between Group Addresses from different namespaces. Two requirements need to be met by a mapping function that translates between Multicast Names and Addresses:
在通信端点，在端点接口处的服务实例化之前，组名称需要映射到组地址。类似地，网关需要一个映射，以便在来自不同名称空间的组地址之间进行一致的转换。在多播名称和地址之间转换的映射功能需要满足两个要求：
a. For a given Group Name, identify an Address that is appropriate for a local distribution instance.
a. 对于给定的组名，标识适合本地分发实例的地址。
b. For a given Group Address, invert the mapping to recover the Group Name.
b. 对于给定的组地址，反转映射以恢复组名称。
In general, mappings can be complex and do not need to be invertible. A mapping can be realized by embedding smaller namespaces into larger namespaces or selecting an arbitrary, unused ID in a smaller target namespace. For example, it is not obvious how to map a large
通常，映射可能很复杂，不需要是可逆的。映射可以通过将较小的名称空间嵌入较大的名称空间或在较小的目标名称空间中选择任意未使用的ID来实现。例如，如何绘制大型地图并不明显
identifier space (e.g., IPv6) to a smaller, collision-prone set like IPv4 (see [MCAST-v4v6-FRAMEWORK], [MCAST-v4v6], and [RFC6219]). Mapping functions can be stateless in some contexts but may require states in others. The application of such functions depends on the cardinality of the namespaces, the structure of address spaces, and possible address collisions. However, some namespaces facilitate a canonical, invertible transformation to default address spaces.
标识符空间（如IPv6）到较小的易冲突集，如IPv4（请参阅[MCAST-v4v6-FRAMEWORK]、[MCAST-v4v6]和[RFC6219]）。映射函数在某些上下文中可能是无状态的，但在其他上下文中可能需要状态。这些函数的应用取决于名称空间的基数、地址空间的结构和可能的地址冲突。但是，有些名称空间有助于实现到默认地址空间的规范、可逆转换。
Some Multicast Namespaces defined in Section 3.4 can express a canonical default mapping. For example, ham:ip:224.1.2.3:5000 indicates the correspondence to 224.1.2.3 in the default IPv4 multicast address space at port 5000. This default mapping is bound to a technology and may not always be applicable, e.g., in the case of address collisions. Note that under canonical mapping, the multicast URI can be completely recovered from any data message received within this group.
第3.4节中定义的一些多播名称空间可以表示规范的默认映射。例如，ham:ip:224.1.2.3:5000表示端口5000的默认IPv4多播地址空间中与224.1.2.3的对应关系。此默认映射绑定到一种技术，可能并不总是适用，例如在地址冲突的情况下。请注意，在规范映射下，可以从该组中接收的任何数据消息中完全恢复多播URI。
Multicast listeners or senders require a name-to-address conversion for all technologies they actively run in a group. Even though a mapping applies to the local Multicast Domain only, end points may need to learn a valid Group Address from neighboring nodes, e.g., from a gateway in the collision-prone IPv4 domain. Once set, an end point will always be aware of the name-to-address correspondence and thus can autonomously invert the mapping.
多播侦听器或发送器需要对其在组中活动运行的所有技术进行名称到地址的转换。即使映射仅适用于本地多播域，端点也可能需要从相邻节点（例如，从易发生冲突的IPv4域中的网关）学习有效的组地址。一旦设置，端点将始终知道名称到地址的对应关系，因此可以自动反转映射。
Multicast data may arrive at an IMG via one technology and request that the gateway re-address packets for another distribution system. At initial arrival, the IMG may not have explicit knowledge of the corresponding Multicast Group Name. To perform a consistent mapping, the Group Name needs to be acquired. It may have been distributed at source registration or may have been learned from a neighboring node, the details of which are beyond the scope of this document.
多播数据可以经由一种技术到达IMG，并请求网关为另一个分发系统重新寻址分组。在初始到达时，IMG可能不清楚相应的多播组名称。要执行一致映射，需要获取组名。它可能是在源注册时分发的，也可能是从相邻节点获悉的，其详细信息超出了本文档的范围。
In Explicit Multicast (Xcast) [RFC5058], the multicast source explicitly predefines the receivers. From a conceptual perspective, Xcast is an additional distribution technology (i.e., a new technology-specific Interface) for this API. Xcast requires aggregated knowledge of receivers that is available at the origin of
在显式多播（Xcast）[RFC5058]中，多播源显式预定义接收器。从概念上看，Xcast是该API的一种附加分发技术（即，一种新的特定于技术的接口）。Xcast需要在源位置可用的接收器的聚合知识
the distribution tree. The instantiation part of the Group Name may refer to such a management instance and tree root, which can be the source or some co-located processor.
分布树。组名的实例化部分可以引用这样的管理实例和树根，树根可以是源处理器或某个共位处理器。
An implementation of Xcast then requires a topology-dependent mapping of the Group Name to the set of subscribers. The defining details of this multi-destination mapping are out of scope for this document.
然后，Xcast的实现需要将组名映射到订阅服务器集的拓扑依赖性映射。此多目标映射的定义详细信息超出了本文档的范围。
This API considers a multi-technology scenario in which different technologies may have different Maximum Transmission Unit (MTU) sizes. Even if the MTU size between two hosts has been determined, it may change over time, as initiated by either the network (e.g., path changes) or end hosts (e.g., Interface changes due to mobility).
该API考虑了一种多技术场景，其中不同的技术可能具有不同的最大传输单元（MTU）大小。即使已经确定了两台主机之间的MTU大小，它也可能随着时间的推移而改变，这是由网络（例如，路径改变）或终端主机（例如，由于移动性引起的接口改变）发起的。
The design of this API is based on the objective of robust communication and easy application development. MTU handling and the implementation of fragmentation are thus guided by the following observations:
该API的设计基于健壮通信和易于应用程序开发的目标。因此，MTU处理和碎片化的实施受以下观察结果的指导：
Application: Application programmers need a simple way to transmit packets in a technology-agnostic fashion. For this, it is convenient at the time of coding to rely on a transparent maximum amount of data that can be sent in one message from a socket. A regular program flow should not be distracted by querying and changing MTU sizes. Technically, the configuration of the maximum message size used by the application programmer may change and disrupt communication when (a) Interfaces are added or excluded or (b) the path MTU changes during transmission and thus disables the corresponding Interfaces.
应用程序：应用程序程序员需要一种简单的方式以一种与技术无关的方式传输数据包。为此，在编码时，可以方便地依赖于从套接字在一条消息中发送的透明最大数据量。常规程序流不应因查询和更改MTU大小而分心。从技术上讲，当（a）添加或排除接口或（b）在传输过程中路径MTU改变并因此禁用相应接口时，应用程序员使用的最大消息大小的配置可能会改变并中断通信。
Middleware: Middleware situated between application and technology Interfaces ensures a general packet-handling capability, which in turn prevents the application programmer from implementing fragmentation. A uniform maximum message size that cannot be changed during runtime shall be guaranteed by the group communication stack (e.g., middleware). Otherwise, this would conflict with a technology-agnostic application.
中间件：位于应用程序和技术接口之间的中间件确保了通用的数据包处理能力，从而防止应用程序程序员实现碎片化。组通信堆栈（例如中间件）应保证在运行时不能更改的统一最大消息大小。否则，这将与技术无关的应用程序相冲突。
Technology Interfaces: Fragmentation requirements depend on the technology in use. Hence, the (technology-bound) Interfaces need to cope with MTU sizes that may vary among Interfaces and along different paths.
技术接口：碎片化需求取决于使用的技术。因此，（受技术限制的）接口需要处理MTU大小，这些MTU大小可能在接口之间以及在不同路径上有所不同。
The concept of this API also aims at guaranteeing a maximum message size for the application programmer, to thereby handle fragmentation at the Interface level, if needed. Nevertheless, the application programmer should be able to determine the technology-specific atomic message size to optimize data distribution, or for other reasons.
此API的概念还旨在保证应用程序程序员的最大消息大小，从而在需要时在接口级别处理碎片。然而，应用程序程序员应该能够确定特定于技术的原子消息大小，以优化数据分布，或者出于其他原因。
The uniform maximum message size should take realistic values (e.g., following IP clients) to enable smooth and efficient services. A detailed selection scheme of MTU values is out of scope for this document.
统一的最大消息大小应采用实际值（例如，遵循IP客户端），以实现平滑高效的服务。MTU值的详细选择方案不在本文件范围内。
The following description of the common multicast API is expressed in pseudo-syntax. Variables that are passed to function calls are declared by "in", and return values are declared by "out". A list of elements is denoted by "<>". The pseudo-syntax assumes that lists include an attribute that represents the number of elements.
下面对公共多播API的描述是用伪语法表示的。传递给函数调用的变量由“in”声明，返回值由“out”声明。元素列表用“<>”表示。伪语法假定列表包含一个表示元素数量的属性。
The corresponding C signatures are defined in Appendix A.
附录A中定义了相应的C签名。
Multicast Names and Multicast Addresses used in this API are represented by a URI scheme that is specified in the following subsections. A corresponding ham-URI denotes a multicast channel and may be dereferenced to retrieve data published to that channel.
此API中使用的多播名称和多播地址由以下小节中指定的URI方案表示。对应的ham URI表示多播信道，并且可以解引用以检索发布到该信道的数据。
The syntax of the multicast URI is specified using the Augmented Backus-Naur Form (ABNF) [RFC5234] and is defined as follows:
多播URI的语法使用扩展的Backus Naur表单（ABNF）[RFC5234]指定，定义如下：
ham-URI = ham-scheme ":" namespace ":" group [ "@" instantiation ]
[ ":" port ] [ "/" sec-credentials ]
ham-URI = ham-scheme ":" namespace ":" group [ "@" instantiation ]
[ ":" port ] [ "/" sec-credentials ]
ham-scheme = "ham" ; hybrid adaptive multicast
namespace = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
group = "*" / 1*unreserved ; unreserved per [RFC3986]
instantiation = 1*unreserved ; unreserved per [RFC3986]
port = 1*DIGIT
sec-credentials = alg ";" val
alg = 1*unreserved ; unreserved per [RFC3986]
val = 1*unreserved ; unreserved per [RFC3986]
ham-scheme = "ham" ; hybrid adaptive multicast
namespace = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
group = "*" / 1*unreserved ; unreserved per [RFC3986]
instantiation = 1*unreserved ; unreserved per [RFC3986]
port = 1*DIGIT
sec-credentials = alg ";" val
alg = 1*unreserved ; unreserved per [RFC3986]
val = 1*unreserved ; unreserved per [RFC3986]
Percent-encoding is applied to distinguish between reserved and unreserved assignments of the same character in the same ham-URI component (cf. [RFC3986]).
百分比编码用于区分同一ham URI组件中相同字符的保留和非保留赋值（参见[RFC3986]）。
The semantic of the different parts of the URI is defined as follows:
URI不同部分的语义定义如下：
ham-scheme: refers to the specification of the assigned identifier "ham".
ham方案：指指定标识符“ham”的说明。
namespace: takes the role of the Multicast Namespace. It defines the syntax of the group and instantiation part of the ham-URI. A basic syntax for these elements is specified in Section 4.2.1. The namespace may further restrict the syntax of designators. Example namespaces are described in Sections 4.2.3 and 4.2.4.
命名空间：担任多播命名空间的角色。它定义了组的语法和ham URI的实例化部分。第4.2.1节规定了这些元素的基本语法。名称空间可能进一步限制指示符的语法。第4.2.3节和第4.2.4节介绍了示例名称空间。
group: uniquely identifies the group within the Multicast Namespace given in the namespace. The literal "*" represents all members of the Multicast Group.
组：唯一标识命名空间中给定的多播命名空间内的组。文本“*”表示多播组的所有成员。
instantiation: identifies the entity that generates the instance of the group (e.g., a SIP domain or a source in SSM, a dedicated routing entity, or a named processor that accounts for the group communication), using syntax and semantics as defined by the namespace. This parameter is optional. Note that ambiguities (e.g., identical node addresses in multiple overlay instances) can be distinguished by ports.
实例化：使用命名空间定义的语法和语义标识生成组实例的实体（例如，SSM中的SIP域或源、专用路由实体或负责组通信的命名处理器）。此参数是可选的。请注意，可通过端口区分歧义（例如，多个覆盖实例中的相同节点地址）。
port: identifies a specific application at an instance of a group. This parameter is optional.
端口：标识组实例上的特定应用程序。此参数是可选的。
sec-credentials: used to implement security mechanisms (e.g., to authorize Multicast Group access or authenticate multicast operations). This parameter is optional. "alg" represents the security algorithm in use. "val" represents the actual value for Authentication, Authorization, and Accounting (AAA). Note that security credentials may carry a distinct technical meaning w.r.t. AAA schemes and may differ between group members. Hence, the sec-credentials are not considered part of the Group Name.
sec凭证：用于实现安全机制（例如，授权多播组访问或验证多播操作）。此参数是可选的。“alg”表示正在使用的安全算法。“val”表示身份验证、授权和记帐（AAA）的实际值。请注意，安全凭证可能具有不同的技术含义w.r.t.AAA方案，并且在集团成员之间可能有所不同。因此，sec凭据不被视为组名的一部分。
IP: This namespace is comprised of regular IP node naming, i.e., DNS names and addresses taken from any version of the Internet Protocol. The syntax of the group and instantiation follows the "host" definition in [RFC3986], Section 3.2.2. A processor dealing with the IP namespace is required to determine the syntax (DNS name, IP address, version) of the group and instantiation expression.
IP：此名称空间由常规IP节点命名组成，即DNS名称和地址取自任何版本的Internet协议。组和实例化的语法遵循[RFC3986]第3.2.2节中的“主机”定义。处理IP命名空间的处理器需要确定组和实例化表达式的语法（DNS名称、IP地址、版本）。
SHA-2: This namespace carries address strings compliant with SHA-2 hash digests. The syntax of the group and instantiation follows the "val" definition in [RFC6920], Section 3. A processor handling those strings is required to determine the length of the expressions and passes appropriate values directly to a corresponding overlay.
SHA-2：此命名空间包含符合SHA-2哈希摘要的地址字符串。组和实例化的语法遵循[RFC6920]第3节中的“val”定义。处理这些字符串的处理器需要确定表达式的长度，并将适当的值直接传递给相应的覆盖。
Opaque: This namespace transparently carries strings without further syntactical information, meanings, or associated resolution mechanisms. The corresponding syntax for the group and instantiation part of the ham-URI is defined in Section 4.2.1.
不透明：这个名称空间透明地承载字符串，没有进一步的语法信息、含义或相关的解析机制。第4.2.1节定义了ham URI的组和实例化部分的相应语法。
SIP: The SIP namespace is an example of an application-layer scheme that bears inherent group functions (conferencing). SIP conference URIs may be directly exchanged and interpreted at the application, and mapped to Group Addresses at the system level to generate a corresponding Multicast Group. The syntax of the group and instantiation is represented by the "userinfo" component [RFC3261], Section 25.1.
SIP：SIP名称空间是承载固有组功能（会议）的应用层方案的一个示例。SIP会议URI可在应用程序处直接交换和解释，并在系统级映射到组地址以生成相应的多播组。组和实例化的语法由“userinfo”组件[RFC3261]第25.1节表示。
RELOAD: This namespace covers address strings that are valid in a REsource LOcation And Discovery [RELOAD] overlay network. A processor handling those strings may pass these values directly to a corresponding overlay that may manage multicast distribution according to [RFC7019].
重新加载：此命名空间包含在资源位置和发现[RELOAD]覆盖网络中有效的地址字符串。处理这些字符串的处理器可将这些值直接传递给相应的覆盖，该覆盖可根据[RFC7019]管理多播分发。
The concept of the common multicast API allows for any namespace that complies with the superset syntax defined in Section 4.2.1. This document specifies a basic set of Multicast Namespaces in Sections 4.2.3 and 4.2.4. If additional namespaces are needed in the future, a registry for those namespaces should be created and should be defined in a future document. All namespaces defined in such a document should then also be assigned to the registry.
公共多播API的概念允许任何符合第4.2.1节中定义的超集语法的命名空间。本文档在第4.2.3节和第4.2.4节中指定了一组基本的多播名称空间。如果将来需要其他名称空间，则应为这些名称空间创建一个注册表，并在将来的文档中定义。然后，还应将此类文档中定义的所有名称空间分配给注册表。
The Interface denotes the layer and instance on which the corresponding call takes effect. In agreement with [RFC3493], we identify an Interface by an identifier, which is a positive integer starting at 1.
接口表示相应调用生效的层和实例。与[RFC3493]一致，我们通过标识符标识接口，标识符是从1开始的正整数。
Properties of an Interface are stored in the following data structure:
接口的属性存储在以下数据结构中：
struct ifProp {
UnsignedInt if_index; /* 1, 2, ... */
String *ifName; /* "eth0", "eth1:1", "lo", ... */
String *ifAddr; /* "1.2.3.4", "abc123", ... */
String *ifTech; /* "ip", "overlay", ... */
};
struct ifProp {
UnsignedInt if_index; /* 1, 2, ... */
String *ifName; /* "eth0", "eth1:1", "lo", ... */
String *ifAddr; /* "1.2.3.4", "abc123", ... */
String *ifTech; /* "ip", "overlay", ... */
};
The following function retrieves all available Interfaces from the system:
以下函数从系统检索所有可用接口：
getInterfaces(out Interface <ifs>);
getInterfaces(out Interface <ifs>);
It extends the functions for Interface identification as defined in [RFC3493], Section 4 and can be implemented by:
它扩展了[RFC3493]第4节中定义的接口标识功能，可通过以下方式实现：
struct ifProp(out IfProp <ifsProps>);
struct ifProp(out IfProp <ifsProps>);
A membership event is triggered by a multicast state change that is observed by the current node. It is related to a specific Group Name and may be receiver or source oriented.
成员资格事件由当前节点观察到的多播状态更改触发。它与特定的组名相关，可以是面向接收方的，也可以是面向源的。
eventType {
joinEvent;
leaveEvent;
newSourceEvent;
};
eventType {
joinEvent;
leaveEvent;
newSourceEvent;
};
event {
EventType event;
Uri groupName;
Interface if;
};
event {
EventType event;
Uri groupName;
Interface if;
};
An event will be created by the group communication stack and passed to applications that have registered for events.
组通信堆栈将创建一个事件，并将其传递给已注册事件的应用程序。
The create call initiates a multicast socket and provides the application programmer with a corresponding handle. If no Interfaces will be assigned based on the call, the default Interface will be selected and associated with the socket. The call returns an error code in the case of failures, e.g., due to non-operational communication middleware.
create调用启动一个多播套接字，并为应用程序程序员提供相应的句柄。如果没有基于调用分配接口，则将选择默认接口并将其与套接字关联。如果出现故障（例如，由于不可操作的通信中间件），调用将返回错误代码。
createMSocket(in Interface <ifs>,
out Socket s);
createMSocket(in Interface <ifs>,
out Socket s);
The ifs argument denotes a list of Interfaces (if_indexes) that will be associated with the multicast socket. This parameter is optional.
ifs参数表示将与多播套接字关联的接口（if_索引）列表。此参数是可选的。
On success, a multicast socket identifier is returned; otherwise, it is NULL.
成功时，返回多播套接字标识符；否则，它是空的。
The delete call removes the multicast socket.
delete调用删除多播套接字。
deleteMSocket(in Socket s, out Int error);
deleteMSocket（在套接字s中，输出Int错误）；
The s argument identifies the multicast socket for destruction.
s参数标识要销毁的多播套接字。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The join call initiates a subscription for the given Group Name. Depending on the Interfaces that are associated with the socket, this may result in an IGMP / Multicast Listener Discovery (MLD) report or overlay subscription, for example.
join调用启动给定组名的订阅。例如，根据与套接字关联的接口，这可能导致IGMP/多播侦听器发现（MLD）报告或覆盖订阅。
join(in Socket s, in Uri groupName, out Int error);
join（在套接字s中，在urigroupname中，在out Int error中）；
The s argument identifies the multicast socket.
s参数标识多播套接字。
The groupName argument identifies the group.
groupName参数标识组。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The leave call results in an unsubscription for the given Group Name.
leave call会导致对给定组名的取消订阅。
leave(in Socket s, in Uri groupName, out Int error);
leave（在套接字s中，在urigroupname中，在out Int error中）；
The s argument identifies the multicast socket.
s参数标识多播套接字。
The groupName argument identifies the group.
groupName参数标识组。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The srcRegister call registers a source for a group on all active Interfaces of the socket s. This call may assist group distribution in some technologies -- for example, the creation of sub-overlays -- or may facilitate a name-to-address mapping. Likewise, it may remain without effect in some multicast technologies.
srcRegister调用在套接字的所有活动接口上注册组的源。此调用可能有助于某些技术中的组分发（例如，创建子覆盖），或者可能有助于名称到地址的映射。同样，在某些多播技术中，它可能仍然无效。
srcRegister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);
srcRegister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);
The s argument identifies the multicast socket.
s参数标识多播套接字。
The groupName argument identifies the Multicast Group to which a source intends to send data.
groupName参数标识源要向其发送数据的多播组。
The ifs argument points to the list of Interface indexes for which the source registration failed. A NULL pointer is returned if the list is empty. This parameter is optional.
ifs参数指向源注册失败的接口索引列表。如果列表为空，则返回空指针。此参数是可选的。
If source registration succeeded for all Interfaces associated with the socket, the out parameter error is 0; otherwise, -1 is returned.
如果与套接字关联的所有接口的源注册成功，则out参数错误为0；否则返回-1。
The srcDeregister call indicates that a source no longer intends to send data to the Multicast Group. This call may remain without effect in some multicast technologies.
srcDeregister调用表示源不再打算向多播组发送数据。在某些多播技术中，此调用可能仍然无效。
srcDeregister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);
srcDeregister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);
The s argument identifies the multicast socket.
s参数标识多播套接字。
The groupName argument identifies the Multicast Group to which a source has stopped sending multicast data.
groupName参数标识源已停止向其发送多播数据的多播组。
The ifs argument points to the list of Interfaces for which the source deregistration failed. A NULL pointer is returned if the list is empty.
ifs参数指向源注销失败的接口列表。如果列表为空，则返回空指针。
If source deregistration succeeded for all Interfaces associated with the socket, the out parameter error is 0; otherwise, -1 is returned.
如果与套接字关联的所有接口的源注销成功，则out参数错误为0；否则返回-1。
The send call passes multicast data destined for a Multicast Name from the application to the multicast socket.
发送调用将多播数据从应用程序传递到多播套接字，该多播数据的目的地是多播名称。
It is worth noting that it is the choice of the programmer to send data via one socket per group or to use a single socket for multiple groups.
值得注意的是，程序员可以选择通过每组一个套接字发送数据，也可以选择使用单个套接字发送多个组。
send(in Socket s, in Uri groupName, in Size msgLen, in Msg msgBuf, out Int error);
发送（在套接字s中，在Uri groupName中，在大小msgLen中，在Msg msgBuf中，在out Int error中）；
The s argument identifies the multicast socket.
s参数标识多播套接字。
The groupName argument identifies the group to which data will be sent.
groupName参数标识将向其发送数据的组。
The msgLen argument holds the length of the message to be sent.
msgLen参数保存要发送的消息的长度。
The msgBuf argument passes the multicast data to the multicast socket.
msgBuf参数将多播数据传递给多播套接字。
On success, the out parameter error is 0; otherwise, -1 is returned. A message that is too long is indicated by an implementation-specific error code (e.g., EMSGSIZE in C).
成功时，out参数错误为0；否则返回-1。过长的消息由特定于实现的错误代码表示（例如，C中的EMSGSIZE）。
The receive call passes multicast data and the corresponding Group Name to the application. This may come in a blocking or non-blocking variant.
receive调用将多播数据和相应的组名传递给应用程序。这可能有阻塞或非阻塞变体。
It is worth noting that it is the choice of the programmer to receive data via one socket per group or to use a single socket for multiple groups.
值得注意的是，程序员可以选择通过每个组一个套接字接收数据，或者对多个组使用单个套接字。
receive(in Socket s, out Uri groupName, out Size msgLen, out Msg msgBuf, out Int error);
接收（在套接字s中，输出Uri groupName，输出大小msgLen，输出消息msgBuf，输出Int error）；
The s argument identifies the multicast socket.
s参数标识多播套接字。
The groupName argument identifies the Multicast Group for which data was received.
groupName参数标识接收数据的多播组。
The msgLen argument holds the length of the received message.
msgLen参数保存所接收消息的长度。
The msgBuf argument points to the payload of the received multicast data.
msgBuf参数指向接收的多播数据的有效负载。
On success, the out parameter error is 0; otherwise, -1 is returned. A message that is too long is indicated by an implementation-specific error code (e.g., EMSGSIZE).
成功时，out参数错误为0；否则返回-1。过长的消息由特定于实现的错误代码（例如EMSGSIZE）表示。
The following calls configure an existing multicast socket.
以下调用配置现有的多播套接字。
The getInterfaces call returns an array of all available multicast communication Interfaces associated with the multicast socket.
getInterfaces调用返回与多播套接字关联的所有可用多播通信接口的数组。
getInterfaces(in Socket s,
out Interface <ifs>, out Int error);
getInterfaces(in Socket s,
out Interface <ifs>, out Int error);
The s argument identifies the multicast socket.
s参数标识多播套接字。
The ifs argument points to an array of Interface index identifiers.
ifs参数指向接口索引标识符数组。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The addInterface call adds a distribution channel to the socket. This may be an overlay or underlay Interface, e.g., IPv6 or Distributed Hash Table (DHT). Multiple Interfaces of the same technology may be associated with the socket.
addInterface调用向套接字添加分发通道。这可能是覆盖或参考底图接口，例如IPv6或分布式哈希表（DHT）。同一技术的多个接口可能与套接字相关联。
addInterface(in Socket s, in Interface if, out Int error);
addInterface（在套接字s中，在接口if中，在接口out Int error中）；
The s and if arguments identify a multicast socket and Interface, respectively.
s和if参数分别标识多播套接字和接口。
On success, the value 0 is returned; otherwise, -1 is returned.
成功时，返回值0；否则返回-1。
The delInterface call removes the Interface from the multicast socket.
deinterface调用从多播套接字中删除接口。
delInterface(in Socket s, Interface if, out Int error);
取消接口（在套接字s中，接口if，输出Int错误）；
The s and if arguments identify a multicast socket and Interface, respectively.
s和if参数分别标识多播套接字和接口。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The setTTL call configures the maximum hop count for the socket that a multicast message is allowed to traverse.
setTTL调用配置允许多播消息遍历的套接字的最大跃点计数。
setTTL(in Socket s, in Int h, in Interface <ifs>, out Int error);
setTTL（在套接字s中，在Int h中，在接口<ifs>中，在out Int error中）；
The s and h arguments identify a multicast socket and the maximum hop count, respectively.
s和h参数分别标识多播套接字和最大跳数。
The ifs argument points to an array of Interface index identifiers. This parameter is optional.
ifs参数指向接口索引标识符数组。此参数是可选的。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The getTTL call returns the maximum hop count that a multicast message is allowed to traverse for the interface bound to the socket.
getTTL调用返回绑定到套接字的接口允许多播消息遍历的最大跃点计数。
getTTL(in Socket s, in Interface if, out Int h, out Int error);
getTTL（在套接字s中，在接口if中，out Int h，out Int error）；
The s argument identifies a multicast socket.
s参数标识多播套接字。
The if argument identifies an interface that is bound to socket s.
if参数标识绑定到套接字的接口。
The h argument holds the maximum number of hops associated with the interface.
h参数保存与接口关联的最大跃点数。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The getAtomicMsgSize function returns the maximum message size that an application is allowed to transmit per socket at once without fragmentation. This value depends on the Interfaces associated with the socket in use and thus may change during runtime.
getAtomicMsgSize函数返回允许应用程序在不分段的情况下一次传输每个套接字的最大消息大小。此值取决于与正在使用的套接字关联的接口，因此在运行时可能会更改。
getAtomicMsgSize(in Socket s, out Int return);
getAtomicMsgSize（在套接字s中，在Int返回中）；
On success, the function returns a positive value of appropriate message size; otherwise, -1 is returned.
成功时，函数返回一个适当消息大小的正值；否则返回-1。
The groupSet call returns all Multicast Groups registered at a given Interface. This information can be provided by group management states or routing protocols. The return values distinguish between sender and listener states.
groupSet调用返回在给定接口上注册的所有多播组。这些信息可以由组管理状态或路由协议提供。返回值区分发送方和侦听器状态。
struct GroupSet {
Uri groupName; /* registered Multicast Group */
Int type; /* 0 = listener state, 1 = sender state,
2 = sender and listener state */
}
struct GroupSet {
Uri groupName; /* registered Multicast Group */
Int type; /* 0 = listener state, 1 = sender state,
2 = sender and listener state */
}
groupSet(in Interface if,
out GroupSet <groupSet>, out Int error);
groupSet(in Interface if,
out GroupSet <groupSet>, out Int error);
The if argument identifies the Interface for which states are maintained.
if参数标识维护状态的接口。
The groupSet argument points to a list of group states.
groupSet参数指向组状态列表。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The neighborSet function returns the set of neighboring nodes for a given Interface as seen by the multicast routing protocol.
neighborSet函数返回多播路由协议看到的给定接口的相邻节点集。
neighborSet(in Interface if,
out Uri <neighborsAddresses>, out Int error);
neighborSet(in Interface if,
out Uri <neighborsAddresses>, out Int error);
The if argument identifies the Interface for which information regarding neighbors is requested.
if参数标识为其请求有关邻居的信息的接口。
The neighborsAddresses argument points to a list of neighboring nodes on a successful return.
NeightorAddresses参数指向成功返回时相邻节点的列表。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The childrenSet function returns the set of child nodes that receive multicast data from a specified Interface for a given group. For a common multicast router, this call retrieves the multicast forwarding information base per Interface.
childrenSet函数返回从给定组的指定接口接收多播数据的子节点集。对于公共多播路由器，此调用检索每个接口的多播转发信息库。
childrenSet(in Interface if, in Uri groupName,
out Uri <childrenAddresses>, out Int error);
childrenSet(in Interface if, in Uri groupName,
out Uri <childrenAddresses>, out Int error);
The if argument identifies the Interface for which information regarding children is requested.
if参数标识为其请求有关子项的信息的接口。
The groupName argument defines the Multicast Group for which distribution is considered.
groupName参数定义要考虑分发的多播组。
The childrenAddresses argument points to a list of neighboring nodes on a successful return.
childrenAddresses参数指向成功返回时相邻节点的列表。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The parentSet function returns the set of neighbors from which the current node receives multicast data at a given Interface for the specified group.
parentSet函数返回当前节点在指定组的给定接口处从中接收多播数据的邻居集。
parentSet(in Interface if, in Uri groupName,
out Uri <parentsAddresses>, out Int error);
parentSet(in Interface if, in Uri groupName,
out Uri <parentsAddresses>, out Int error);
The if argument identifies the Interface for which information regarding parents is requested.
if参数标识为其请求有关父级的信息的接口。
The groupName argument defines the Multicast Group for which distribution is considered.
groupName参数定义要考虑分发的多播组。
The parentsAddresses argument points to a list of neighboring nodes on a successful return.
parentsaddress参数指向成功返回时相邻节点的列表。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功时，out参数错误为0；否则返回-1。
The designatedHost function inquires about whether this host has the role of a designated forwarder (or querier), or not. Such information is provided by almost all multicast protocols to prevent packet duplication, if multiple multicast instances provide service on the same subnet.
DesignedHost函数查询此主机是否具有指定转发器（或查询器）的角色。如果多个多播实例在同一子网上提供服务，则几乎所有多播协议都会提供此类信息，以防止数据包重复。
designatedHost(in Interface if, in Uri groupName out Int return);
指定的主机（接口中的if，Uri中的groupName out Int return）；
The if argument identifies the Interface for which information regarding designated forwarding is requested.
if参数标识为其请求有关指定转发的信息的接口。
The groupName argument specifies the group for which the host may attain the role of designated forwarder.
groupName参数指定主机可以获得指定转发器角色的组。
The function returns 1 if the host is a designated forwarder or querier. The return value -1 indicates an error. Otherwise, 0 is returned.
如果主机是指定的转发器或查询器，则函数返回1。返回值-1表示错误。否则，返回0。
The enableEvents function registers an application at the group communication stack to receive information about group changes. State changes are the result of new receiver subscriptions or leaves, as well as source changes. Upon receiving an event, the group service may obtain additional information from further service calls.
enableEvents函数在组通信堆栈中注册应用程序，以接收有关组更改的信息。状态更改是新接收方订阅或离开以及源更改的结果。在接收到事件后，组服务可以从进一步的服务调用中获得附加信息。
enableEvents();
使能事件（）；
Calling this function, the stack starts to pass membership events to the application. Each event includes an event type identifier and a Group Name (cf. Section 4.3.2).
调用此函数，堆栈开始将成员资格事件传递给应用程序。每个事件包括事件类型标识符和组名称（参见第4.3.2节）。
The multicast protocol does not have to support membership tracking in order to enable this feature. This function can also be implemented at the middleware layer.
为了启用此功能，多播协议不必支持成员身份跟踪。该功能也可以在中间件层实现。
The disableEvents function deactivates the information about group state changes.
disableEvents函数可停用有关组状态更改的信息。
disableEvents();
禁用事件（）；
On success, the stack will not pass membership events to the application.
成功后，堆栈将不会将成员资格事件传递给应用程序。
The getMaxMsgSize function returns the maximum message size that an application is allowed to transmit per socket at once. This value is statically guaranteed by the group communication stack.
getMaxMsgSize函数返回允许应用程序一次传输每个套接字的最大消息大小。该值由组通信堆栈静态保证。
getMaxMsgSize(out Int return);
getMaxMsgSize（输出整数返回）；
On success, the function returns a positive value of allowed message size; otherwise, -1 is returned.
成功时，函数返回允许的消息大小的正值；否则返回-1。
A reference implementation of the Common API for Transparent Hybrid Multicast is available with the HAMcast stack [HAMcast-DEV] [GC2010] [LCN2012]. This open-source software supports the multicast API (C++ and Java library) for group application development, the middleware as a user space system service, and several multicast-technology modules. The middleware is implemented in C++.
透明混合多播通用API的参考实现可从HAMcast堆栈[HAMcast DEV][GC2010][LCN2012]获得。此开源软件支持用于组应用程序开发的多播API（C++和Java库）、作为用户空间系统服务的中间件以及多播技术模块。中间件是在C++中实现的。
This API is verified and adjusted based on the real-world experiences gathered in the HAMcast project, and by additional users of the stack.
此API根据在HAMcast项目中收集的实际经验以及堆栈的其他用户进行验证和调整。
This document specifies the "ham" URI scheme that has been registered by IANA as one of the "Provisional URI Schemes" according to [RFC4395].
本文件规定了IANA根据[RFC4395]注册为“临时URI方案”之一的“ham”URI方案。
URI scheme name ham
URI方案名称
Status provisional
临时地位
URI scheme syntax See Section 4.2.1.
URI方案语法见第4.2.1节。
URI scheme semantics See Section 4.2.2.
URI方案语义见第4.2.2节。
Encoding See Section 4.2.1 considerations
编码参见第4.2.1节注意事项
Applications/protocols The scheme is used by multicast applications that use this URI to access multicast content. scheme name
应用程序/协议该方案由使用此URI访问多播内容的多播应用程序使用。方案名称
Interoperability None considerations
互操作性无需考虑
Security See Section 7. considerations
安全见第7节。考虑
Contact Matthias Waehlisch, mw@link-lab.net
联系Matthias Waehlisch，mw@link-实验室网络
Author/Change IRTF controller
编写/更改IRTF控制器
References As specified in this document.
本文件中规定的参考文件。
This document does not introduce additional messages or novel protocol operations.
本文档不介绍其他消息或新的协议操作。
We would like to thank the HAMcast team at the HAW Hamburg -- Nora Berg, Gabriel Hege, Fabian Holler, Alexander Knauf, Sebastian Meiling, Sebastian Woelke, and Sebastian Zagaria -- for many fruitful discussions and for their continuous critical feedback while implementing the common multicast API and hybrid multicast middleware. Special thanks to Dominik Charousset of the HAMcast team for in-depth perspectives on the matter of code. We gratefully acknowledge WeeSan, Mario Kolberg, and John Buford for reviewing and their suggestions to improve the document. We would like to thank the Name-Based Socket BoF (in particular Dave Thaler) for clarifying insights into the question of meta-function calls. We thank Lisandro Zambenedetti Granville and Tony Li for very careful reviews of the pre-final versions of this document. Barry Leiba and Graham Klyne provided very constructive input to find a suitable URI scheme. They are gratefully acknowledged.
我们要感谢HAW Hamburg的HAMcast团队——Nora Berg、Gabriel Hege、Fabian Holler、Alexander Knauf、Sebastian Meiling、Sebastian Woelke和Sebastian Zagaria——在实施通用多播API和混合多播中间件的过程中进行了许多富有成效的讨论，并提供了持续的关键反馈。特别感谢HAMcast团队的Dominik Charousset对代码问题的深入分析。我们非常感谢WeeSan、Mario Kolberg和John Buford对本文件的审查及其改进建议。我们要感谢基于名称的Socket BoF（特别是Dave Thaler）澄清了对元函数调用问题的见解。我们感谢Lisandro Zambenedetti Granville和Tony Li对本文件定稿前版本进行了非常仔细的审查。Barry Leiba和Graham Klyne为找到合适的URI方案提供了非常有建设性的意见。感谢他们。
This work is partially supported by the German Federal Ministry of Education and Research within the HAMcast project (see <http://hamcast.realmv6.org>), which is part of G-Lab.
这项工作得到德国联邦教育和研究部在HAMcast项目中的部分支持（见<http://hamcast.realmv6.org>)，它是G-Lab的一部分。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[RFC1075]Waitzman，D.，Partridge，C.，和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[RFC3678]Thaler，D.，Fenner，B.，和B.Quinn，“多播源过滤器的套接字接口扩展”，RFC 3678，2004年1月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[RFC5058] Boivie, R., Feldman, N., Imai, Y., Livens, W., and D. Ooms, "Explicit Multicast (Xcast) Concepts and Options", RFC 5058, November 2007.
[RFC5058]Boivie，R.，Feldman，N.，Imai，Y.，Livens，W.，和D.Ooms，“显式多播（Xcast）概念和选项”，RFC 5058，2007年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
[RFC6920]Farrell，S.，Kutscher，D.，Dannewitz，C.，Ohlman，B.，Keranen，A.，和P.Hallam Baker，“用哈希命名事物”，RFC 6920，2013年4月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, October 2013.
[AMT]Bumgardner，G.，“自动多播隧道”，正在进行的工作，2013年10月。
[GC2010] Meiling, S., Charousset, D., Schmidt, T., and M. Waehlisch, "System-assisted Service Evolution for a Future Internet - The HAMcast Approach to Pervasive Multicast", Proc. IEEE GLOBECOM 2010 Workshops, MCS 2010, pp. 913-917, Piscataway, NJ, USA, IEEE Press, December 2010.
[GC2010]Meiling，S.，Charousset，D.，Schmidt，T.，和M.Waehlisch，“未来互联网的系统辅助服务演化-普及多播的HAMcast方法”，Proc。IEEE GLOBECOM 2010研讨会，MCS 2010，第913-917页，皮斯卡塔韦，新泽西州，美国，IEEE出版社，2010年12月。
[HAMcast-DEV] "HAMcast developers", <http://hamcast.realmv6.org/developers>.
[HAMcast开发人员]“HAMcast开发人员”<http://hamcast.realmv6.org/developers>.
[LCN2012] Meiling, S., Schmidt, T., and M. Waehlisch, "Large-Scale Measurement and Analysis of One-Way Delay in Hybrid Multicast Networks", Proc. 37th Annual IEEE Conference on Local Computer Networks (LCN 2012), Piscataway, NJ, USA, IEEE Press, October 2012.
[LCN2012]Meiling，S.，Schmidt，T.，和M.Waehlisch，“混合多播网络中单向延迟的大规模测量和分析”，Proc。第37届IEEE本地计算机网络年会（LCN 2012），皮斯卡塔韦，新泽西州，美国，IEEE出版社，2012年10月。
[MCAST-v4v6] Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An IPv4 - IPv6 multicast translator", Work in Progress, December 2010.
[MCAST-v4v6]Venaas，S.，Asaeda，H.，SUZUKI，S.，和T.Fujisaki，“IPv4-IPv6多播转换器”，正在进行的工作，2010年12月。
[MCAST-v4v6-FRAMEWORK] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation", Work in Progress, June 2011.
[MCAST-v4v6-FRAMEWORK]Venaas，S.，Li，X.，和C.Bao，“IPv4/IPv6多播转换框架”，正在进行的工作，2011年6月。
[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月。
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010.
[RFC5757]Schmidt，T.，Waehlisch，M.，和G.Fairhurst，“移动IP版本6（MIPv6）中的多播移动性：问题陈述和简要调查”，RFC 5757，2010年2月。
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, May 2011.
[RFC6219]Li，X.，Bao，C.，Chen，M.，Zhang，H.，和J.Wu，“针对IPv4/IPv6共存和过渡的中国教育和研究网络（CERNET）IVI翻译设计和部署”，RFC 6219，2011年5月。
[RFC7019] Buford, J. and M. Kolberg, "Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)", RFC 7019, September 2013.
[RFC7019]Buford，J.和M.Kolberg，“资源定位和发现的应用层多播扩展（重新加载）”，RFC 7019，2013年9月。
[SIP-RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, Ed., "A SIP Usage for RELOAD", Work in Progress, July 2013.
[SIP-RELOAD]Jennings，C.，Lowekamp，B.，Rescorla，E.，Baset，S.，Schulzrinne，H.，和T.Schmidt，Ed.，“重新加载的SIP使用”，正在进行的工作，2013年7月。
This section describes the C signatures of the common multicast API (Section 4).
本节介绍通用多播API的C签名（第4节）。
int createMSocket(int* result, size_t num_ifs,
const uint32_t* ifs);
int createMSocket(int* result, size_t num_ifs,
const uint32_t* ifs);
int deleteMSocket(int s);
int deleteMSocket（int-s）；
int join(int msock, const char* group_uri);
int join(int msock, const char* group_uri);
int leave(int msock, const char* group_uri);
int leave(int msock, const char* group_uri);
int srcRegister(int msock, const char* group_uri, size_t num_ifs, uint32_t* ifs);
int src寄存器（int msock、const char*group\u uri、size\u t num\u ifs、uint32\u t*ifs）；
int srcDeregister(int msock, const char* group_uri, size_t num_ifs, uint32_t* ifs);
int srcDeregister（int msock、const char*group\u uri、size\u t num\u ifs、uint32\u t*ifs）；
int send(int msock, const char* group_uri, size_t buf_len, const void* buf);
int send（int msock，const char*group_uri，size_t buf_len，const void*buf）；
int receive(int msock, const char* group_uri, size_t buf_len, void* buf);
int接收（int msock，const char*group_uri，size_t buf_len，void*buf）；
int getInterfaces(int msock,
size_t* num_ifs,
uint32_t** ifs);
int getInterfaces(int msock,
size_t* num_ifs,
uint32_t** ifs);
int addInterface(int msock, uint32_t iface);
int addInterface（int msock，uint32_t iface）；
int delInterface(int msock, uint32_t iface);
内部接口（内部msock，uint32_t iface）；
int setTTL(int msock, uint8_t value, size_t num_ifs, uint32_t* ifs);
int setTTL（int msock、uint8值、大小数量ifs、uint32*ifs）；
int getTTL(int msock, uint8_t* result);
int getTTL(int msock, uint8_t* result);
int getAtomicMsgSize(int msock);
intgetatomicmsgsize（intmsock）；
typedef struct {
char* group_uri; /* registered mcast group */
int type; /* 0: listener state
1: sender state
2: sender and listener state */
}
GroupSet;
typedef struct {
char* group_uri; /* registered mcast group */
int type; /* 0: listener state
1: sender state
2: sender and listener state */
}
GroupSet;
int groupSet(uint32_t iface,
size_t* num_groups,
GroupSet** groups);
int groupSet(uint32_t iface,
size_t* num_groups,
GroupSet** groups);
int neighborSet(uint32_t iface,
const char* group_name,
size_t* num_neighbors,
char** neighbor_uris);
int neighborSet(uint32_t iface,
const char* group_name,
size_t* num_neighbors,
char** neighbor_uris);
int childrenSet(uint32_t iface,
const char* group_name,
size_t* num_children,
char** children_uris);
int childrenSet(uint32_t iface,
const char* group_name,
size_t* num_children,
char** children_uris);
int parentSet(uint32_t iface,
const char* group_name,
size_t* num_parents,
char** parents_uris);
int parentSet(uint32_t iface,
const char* group_name,
size_t* num_parents,
char** parents_uris);
int designatedHost(uint32_t iface, const char* group_name);
int指定主机（uint32 iface，常量字符*组名称）；
typedef void (*MembershipEventCallback)
(int, /* event type */
uint32_t, /* Interface id */
const char*); /* group uri */
typedef void (*MembershipEventCallback)
(int, /* event type */
uint32_t, /* Interface id */
const char*); /* group uri */
int registerEventCallback(MembershipEventCallback callback);
int registerEventCallback（MembershipEventCallback回调）；
int enableEvents();
int enableEvents（）；
int disableEvents();
int disableEvents（）；
int getMaxMsgSize();
int getMaxMsgSize（）；
For the sake of readability, we demonstrate development of applications using the API based on a high-level Java-like syntax; we do not consider error handling.
为了可读性，我们演示了使用基于高级Java语法的API开发应用程序；我们不考虑错误处理。
-- Application above middleware:
--中间件之上的应用程序：
//Initialize multicast socket;
//the middleware selects all available Interfaces
MulticastSocket m = new MulticastSocket();
//Initialize multicast socket;
//the middleware selects all available Interfaces
MulticastSocket m = new MulticastSocket();
m.join(URI("ham:ip:224.1.2.3:5000"));
m.join(URI("ham:ip:[ff02:0:0:0:0:0:0:3]:6000"));
m.join(URI("ham:sip:news@cnn.com"));
m.join(URI("ham:ip:224.1.2.3:5000"));
m.join(URI("ham:ip:[ff02:0:0:0:0:0:0:3]:6000"));
m.join(URI("ham:sip:news@cnn.com"));
-- Middleware:
--中间件：
join(URI mcAddress) {
//Select Interfaces in use
for all this.interfaces {
switch (interface.type) {
case "ipv6":
//... map logical ID to routing address
Inet6Address rtAddressIPv6 = new Inet6Address();
mapNametoAddress(mcAddress,rtAddressIPv6);
interface.join(rtAddressIPv6);
case "ipv4":
//... map logical ID to routing address
Inet4Address rtAddressIPv4 = new Inet4Address();
mapNametoAddress(mcAddress,rtAddressIPv4);
interface.join(rtAddressIPv4);
case "sip-session":
//... map logical ID to routing address
SIPAddress rtAddressSIP = new SIPAddress();
mapNametoAddress(mcAddress,rtAddressSIP);
interface.join(rtAddressSIP);
case "dht":
//... map logical ID to routing address
DHTAddress rtAddressDHT = new DHTAddress();
mapNametoAddress(mcAddress,rtAddressDHT);
interface.join(rtAddressDHT);
//...
}
}
}
join(URI mcAddress) {
//Select Interfaces in use
for all this.interfaces {
switch (interface.type) {
case "ipv6":
//... map logical ID to routing address
Inet6Address rtAddressIPv6 = new Inet6Address();
mapNametoAddress(mcAddress,rtAddressIPv6);
interface.join(rtAddressIPv6);
case "ipv4":
//... map logical ID to routing address
Inet4Address rtAddressIPv4 = new Inet4Address();
mapNametoAddress(mcAddress,rtAddressIPv4);
interface.join(rtAddressIPv4);
case "sip-session":
//... map logical ID to routing address
SIPAddress rtAddressSIP = new SIPAddress();
mapNametoAddress(mcAddress,rtAddressSIP);
interface.join(rtAddressSIP);
case "dht":
//... map logical ID to routing address
DHTAddress rtAddressDHT = new DHTAddress();
mapNametoAddress(mcAddress,rtAddressDHT);
interface.join(rtAddressDHT);
//...
}
}
}
This section describes the application of the defined API to implement an IMG.
本节描述定义的API在实现IMG中的应用。
The following procedure describes a transparent mapping of a DVMRP-based any-source multicast service to another many-to-many multicast technology, e.g., an overlay.
以下过程描述了基于DVMRP的任意源多播服务到另一种多对多多播技术（例如，覆盖）的透明映射。
An arbitrary Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] router will not be informed of new receivers but will learn about new sources immediately. The concept of DVMRP does not provide any central multicast instance. Thus, the IMG can be placed anywhere inside the multicast region, but the IMG requires a DVMRP neighbor connectivity. Thus, the group communication stack used by the IMG is enhanced by a DVMRP implementation. New sources in the underlay will be advertised based on the DVMRP flooding mechanism and received by the IMG. Based on this, the event "new_source_event" is created and passed to the application. The relay agent initiates a corresponding join in the native network and forwards the received source data towards the overlay routing protocol. Depending on the group states, the data will be distributed to overlay peers.
任意距离向量多播路由协议（DVMRP）[RFC1075]路由器不会被告知新的接收器，但会立即了解新的源。DVMRP的概念不提供任何中央多播实例。因此，IMG可以放置在多播区域内的任何位置，但是IMG需要DVMRP邻居连接。因此，IMG使用的组通信堆栈通过DVMRP实现得到增强。将根据DVMRP注水机制公布基线中的新震源，并由IMG接收。基于此，将创建事件“new_source_event”并将其传递给应用程序。中继代理在本机网络中发起相应的连接，并将接收到的源数据转发给覆盖路由协议。根据组状态，数据将分发到覆盖对等点。
DVMRP establishes source-specific multicast trees. Therefore, a graft message is only visible to DVMRP routers on the path from the new receiver subnet to the source, but in general not to an IMG. To overcome this problem, data of multicast senders in the overlay may become noticeable via the Source Register call, as well as by an IMG that initiates an all-group join in the overlay using the namespace extension of the API. Each IMG is initially required to forward the data received in the overlay to the underlay, independent of native multicast receivers. Subsequent prunes may limit unwanted data distribution thereafter.
DVMRP建立特定于源的多播树。因此，嫁接消息仅在从新接收器子网到源的路径上对DVMRP路由器可见，但通常对IMG不可见。为了克服这个问题，覆盖中的多播发送者的数据可以通过源寄存器调用以及使用API的名称空间扩展在覆盖中发起全组加入的IMG变得明显。每个IMG最初需要将覆盖中接收的数据转发到参考底图，独立于本机多播接收器。随后的修剪可能会限制此后不需要的数据分布。
The following procedure describes a transparent mapping of a PIM-SM-based any-source multicast service to another many-to-many multicast technology, e.g., an overlay.
以下过程描述了基于PIM SM的任何源多播服务到另一种多对多多播技术（例如，覆盖）的透明映射。
The Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] establishes rendezvous points (RPs). These entities receive listener subscriptions and source registering of a domain. For a continuous update, an IMG has to be co-located with an RP. Whenever PIM register messages are received, the IMG must signal internally a new multicast source using the event "new_source_event". Subsequently,
独立于协议的多播稀疏模式（PIM-SM）[RFC4601]建立集合点（RPs）。这些实体接收域的侦听器订阅和源注册。对于连续更新，IMG必须与RP位于同一位置。每当收到PIM寄存器消息时，IMG必须使用事件“new_source_event”在内部向新的多播源发送信号。随后
the IMG joins the group and a shared tree between the RP and the sources will be established; this shared tree may change to a source-specific tree after PIM switches to phase three. Source traffic will be forwarded to the RP based on the IMG join, even if there are no further receivers in the native Multicast Domain. Designated routers of a PIM domain send receiver subscriptions towards the PIM-SM RP. The reception of such messages initiates the event "join_event" at the IMG, which initiates a join towards the overlay routing protocol. Overlay multicast data arriving at the IMG will then be transparently forwarded in the underlay network and distributed through the RP instance.
IMG加入该组，并在RP和源之间建立共享树；PIM切换到第三阶段后，此共享树可能会更改为特定于源的树。即使本机多播域中没有其他接收器，源流量也将基于IMG连接转发到RP。PIM域的指定路由器向PIM-SM RP发送接收器订阅。此类消息的接收在IMG处发起事件“join_event”，该事件发起向覆盖路由协议的加入。然后，到达IMG的覆盖多播数据将在底层网络中透明转发，并通过RP实例分发。
The following procedure describes a transparent mapping of a PIM-SSM-based source-specific multicast service to another one-to-many multicast technology, e.g., an overlay.
以下过程描述了基于PIM SSM的源特定多播服务到另一种一对多多多播技术（例如，覆盖）的透明映射。
PIM Source-Specific Multicast (PIM-SSM) is defined as part of PIM-SM and admits source-specific joins (S,G) according to the source-specific host group model [RFC4604]. A multicast distribution tree can be established without the assistance of a rendezvous point.
PIM源特定多播（PIM-SSM）定义为PIM-SM的一部分，并根据源特定主机组模型[RFC4604]允许源特定连接（S，G）。无需集合点的帮助，就可以建立多播分发树。
Sources are not advertised within a PIM-SSM domain. Consequently, an IMG cannot anticipate the local join inside a sender domain and deliver a priori the multicast data to the overlay instance. If an IMG of a receiver domain initiates a group subscription via the overlay routing protocol, relaying multicast data fails, as data is not available at the overlay instance. The IMG instance of the receiver domain thus has to locate the IMG instance of the source domain to trigger the corresponding join. In agreement with the objectives of PIM-SSM, the signaling should not be flooded in the underlay and overlay.
源不会在PIM-SSM域中公布。因此，IMG无法预测发送方域内的本地连接，并将多播数据先验地传递给覆盖实例。如果接收方域的IMG通过覆盖路由协议发起组订阅，则中继多播数据将失败，因为覆盖实例中的数据不可用。因此，接收方域的IMG实例必须定位源域的IMG实例以触发相应的连接。根据PIM-SSM的目标，信号不应淹没在底层和覆盖层中。
A solution can be to intercept the subscription at both source sites and receiver sites: To monitor multicast receiver subscriptions ("join_event" or "leave_event") in the underlay, the IMG is placed on the path towards the source, e.g., at a domain border router. This router intercepts join messages and extracts the unicast source address S, initializing an IMG-specific join to S via regular unicast. Multicast data arriving at the IMG of the sender domain can be distributed via the overlay. Discovering the IMG of a multicast sender domain may be implemented analogously to Automatic Multicast Tunneling [AMT] by anycast. Consequently, the source address S of the group (S,G) should be built based on an anycast prefix. The corresponding IMG anycast address for a source domain is then derived from the prefix of S.
一种解决方案可以是在源站点和接收器站点截获订阅：为了在参考底图中监视多播接收器订阅（“加入事件”或“离开事件”），IMG被放置在通向源的路径上，例如，在域边界路由器处。该路由器拦截加入消息并提取单播源地址S，通过常规单播初始化IMG特定于S的加入。到达发送方域的IMG的多播数据可以通过覆盖进行分发。发现多播发送方域的IMG可以类似于通过anycast实现的自动多播隧道[AMT]。因此，组（S，G）的源地址S应基于选播前缀构建。然后，源域的相应IMG选播地址由S的前缀派生而来。
The following procedure describes a transparent mapping of a BIDIR-PIM-based any-source multicast service to another many-to-many multicast technology, e.g., an overlay.
以下过程描述了基于BIDIR-PIM的任意源多播服务到另一种多对多播技术（例如，覆盖）的透明映射。
Bidirectional PIM [RFC5015] is a variant of PIM-SM. In contrast to PIM-SM, the protocol pre-establishes bidirectional shared trees per group, connecting multicast sources and receivers. The rendezvous points are virtualized in BIDIR-PIM as an address to identify on-tree directions (up and down). Routers with the best link towards the (virtualized) rendezvous point address are selected as designated forwarders for a link-local domain and represent the actual distribution tree. The IMG is to be placed at the RP link, where the rendezvous point address is located. As source data in either case will be transmitted to the RP link, the BIDIR-PIM instance of the IMG receives the data and can internally signal new senders towards the stack via the "new_source_event". The first receiver subscription for a new group within a BIDIR-PIM domain needs to be transmitted to the RP to establish the first branching point. Using the "join_event", an IMG will thereby be informed of group requests from its domain, which are then delegated to the overlay.
双向PIM[RFC5015]是PIM-SM的一种变体。与PIM-SM不同，该协议预先为每个组建立双向共享树，连接多播源和接收器。集合点在BIDIR-PIM中虚拟化为一个地址，用于识别树上的方向（上下）。选择具有指向（虚拟化）集合点地址的最佳链路的路由器作为链路本地域的指定转发器，并表示实际的分发树。IMG将放置在RP链路上，集合点地址位于该链路上。由于任一情况下的源数据都将传输到RP链路，IMG的BIDIR-PIM实例将接收数据，并可通过“new_source_event”在内部向堆栈发送新发送方信号。BIDIR-PIM域内新组的第一接收器订阅需要发送到RP以建立第一分支点。使用“join_事件”，IMG将收到来自其域的组请求的通知，然后将这些请求委托给覆盖层。
Authors' Addresses
作者地址
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin 10318 Germany
德国柏林Hoenower街35号Matthias Waehlisch link实验室和FU
EMail: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl
EMail: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
Thomas C.Schmidt HAW Hamburg Berliner Tor 7汉堡20099德国
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道Stig Venaas思科系统公司，邮编95134
EMail: stig@cisco.com
EMail: stig@cisco.com