Network Working Group R. Boivie
Request for Comments: 5058 N. Feldman
Category: Experimental IBM
Y. Imai
WIDE / Fujitsu
W. Livens
ESCAUX
D. Ooms
OneSparrow
November 2007
Network Working Group R. Boivie
Request for Comments: 5058 N. Feldman
Category: Experimental IBM
Y. Imai
WIDE / Fujitsu
W. Livens
ESCAUX
D. Ooms
OneSparrow
November 2007
Explicit Multicast (Xcast) Concepts and Options
显式多播（Xcast）概念和选项
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
Abstract
摘要
While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.
虽然传统的IP多播方案（RFC 1112）对于非常大的多播组是可伸缩的，但是对于大量不同的多播组，它们存在可伸缩性问题。本文描述了Xcast（显式多单播），这是一种具有互补伸缩特性的新多播方案：Xcast支持大量的小型多播会话。Xcast通过显式编码数据包中的目的地列表而不是使用多播组地址来实现这一点。
This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.
本文件讨论了Xcast在几个方面的概念和选项；它没有提供完整的技术规范。
Table of Contents
目录
1. Introduction ....................................................3
2. Xcast Overview ..................................................4
3. The Cost of the Traditional IP Multicast Schemes ................6
4. Motivation ......................................................9
5. Application ....................................................11
6. Xcast Flexibility ..............................................12
7. Xcast Control Plane Options ....................................13
7.1. SIP Control Plane for Xcast ...............................14
7.2. Receiver-Initiated Join for Xcast .........................14
8. Optional Information ...........................................15
8.1. List of Ports .............................................15
8.2. List of DSCPs .............................................15
8.3. Channel Identifier ........................................15
9. Possible Xcast Packet Encoding .................................16
9.1. General ...................................................16
9.2. IPv4 ......................................................17
9.2.1. IPv4 Header ........................................17
9.2.2. Xcast4 Header ......................................17
9.3. IPv6 ......................................................20
9.3.1. IPv6 Header ........................................20
9.3.2. Xcast6 Header ......................................20
9.3.2.1. Routing Extension Header ..................21
9.3.2.2. Destination Extension Header ..............21
10. Impact on Upper-Layer Protocols ...............................22
10.1. Checksum Calculation in Transport-Layer Headers ..........22
10.2. IPsec ....................................................22
11. Gradual Deployment ............................................23
11.1. Tunneling ................................................23
11.2. Premature X2U ............................................25
11.3. Semi-Permeable Tunneling (IPv6 Only) .....................25
11.4. Special Case: Deployment without Network Support .........26
11.5. Using a Small Number of Xcast-Aware Routers to
Provide Xcast ............................................27
12. (Socket) API ..................................................28
13. Unresolved Issues .............................................28
13.1. The Format of the "List of Addresses" ....................28
13.2. The size of Channel Identifier ...........................28
13.3. Incremental Deployment ...................................28
13.4. DSCP usage ...............................................29
13.5. Traversing a Firewall or NAT Products ....................29
13.6. The Size of BITMAP .......................................29
14. Security Considerations .......................................29
15. IANA Considerations ...........................................30
16. Informative References ........................................31
17. Contributors ..................................................33
1. Introduction ....................................................3
2. Xcast Overview ..................................................4
3. The Cost of the Traditional IP Multicast Schemes ................6
4. Motivation ......................................................9
5. Application ....................................................11
6. Xcast Flexibility ..............................................12
7. Xcast Control Plane Options ....................................13
7.1. SIP Control Plane for Xcast ...............................14
7.2. Receiver-Initiated Join for Xcast .........................14
8. Optional Information ...........................................15
8.1. List of Ports .............................................15
8.2. List of DSCPs .............................................15
8.3. Channel Identifier ........................................15
9. Possible Xcast Packet Encoding .................................16
9.1. General ...................................................16
9.2. IPv4 ......................................................17
9.2.1. IPv4 Header ........................................17
9.2.2. Xcast4 Header ......................................17
9.3. IPv6 ......................................................20
9.3.1. IPv6 Header ........................................20
9.3.2. Xcast6 Header ......................................20
9.3.2.1. Routing Extension Header ..................21
9.3.2.2. Destination Extension Header ..............21
10. Impact on Upper-Layer Protocols ...............................22
10.1. Checksum Calculation in Transport-Layer Headers ..........22
10.2. IPsec ....................................................22
11. Gradual Deployment ............................................23
11.1. Tunneling ................................................23
11.2. Premature X2U ............................................25
11.3. Semi-Permeable Tunneling (IPv6 Only) .....................25
11.4. Special Case: Deployment without Network Support .........26
11.5. Using a Small Number of Xcast-Aware Routers to
Provide Xcast ............................................27
12. (Socket) API ..................................................28
13. Unresolved Issues .............................................28
13.1. The Format of the "List of Addresses" ....................28
13.2. The size of Channel Identifier ...........................28
13.3. Incremental Deployment ...................................28
13.4. DSCP usage ...............................................29
13.5. Traversing a Firewall or NAT Products ....................29
13.6. The Size of BITMAP .......................................29
14. Security Considerations .......................................29
15. IANA Considerations ...........................................30
16. Informative References ........................................31
17. Contributors ..................................................33
While traditional IP multicast schemes [1112] are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.
虽然传统的IP多播方案[1112]对于非常大的多播组是可伸缩的，但是对于大量不同的多播组，它们存在可伸缩性问题。本文描述了Xcast（显式多单播（Xcast）），这是一种新的多播方案，具有互补的伸缩特性：Xcast支持大量的小型多播会话。Xcast通过显式编码数据包中的目的地列表而不是使用多播组地址来实现这一点。本文件讨论了Xcast在几个方面的概念和选项；它没有提供完整的技术规范。
Multicast, the ability to efficiently send data to a group of destinations, is becoming increasingly important for applications such as IP telephony and video-conferencing.
对于IP电话和视频会议等应用程序来说，多播（Multicast）这种将数据高效发送到一组目的地的能力正变得越来越重要。
Two kinds of multicast seem to be important: a broadcast-like multicast that sends data to a very large number of destinations, and a "narrowcast" multicast that sends data to a fairly small group [BOIV]. An example of the first is the audio and video multicasting of a presentation to all employees in a corporate intranet. An example of the second is a videoconference involving three or four parties. For reasons described below, it seems prudent to use different mechanisms for these two cases. As the Reliable Multicast Transport working group has stated: "it is believed that a 'one size fits all' protocol will be unable to meet the requirements of all applications" [RMT]. Note that the 1998 IAB Routing Workshop [2902] came to the same conclusion: "For example, providing for many groups of small conferences (a small number of widely dispersed people) with global topological scope scales badly given the current multicast model".
两种类型的多播似乎很重要：一种是向大量目的地发送数据的类似广播的多播，另一种是向相当小的组发送数据的“窄播”多播[BOIV]。第一种方法的一个例子是在公司内部网中向所有员工播放演示文稿的音频和视频多播。第二种方法的一个例子是有三方或四方参加的视频会议。出于下述原因，对这两种情况使用不同的机制似乎是谨慎的。正如可靠多播传输工作组所说：“人们相信‘一刀切’的协议将无法满足所有应用的要求”[RMT]。请注意，1998年IAB路由研讨会[2902]得出了相同的结论：“例如，考虑到当前的多播模型，为许多具有全局拓扑范围的小型会议组（少量分布广泛的人）提供了糟糕的服务。”。
Today's multicast schemes can be used to minimize bandwidth consumption. Explicit Multi-Unicast (Xcast) also can be used to minimize bandwidth consumption for "small groups". But it has an additional advantage as well. Xcast eliminates the per-session signaling and per-session state information of traditional IP multicast schemes and this allows Xcast to support very large numbers of multicast sessions. This scalability is important since it enables important classes of applications such as IP telephony, videoconferencing, collaborative applications, networked games, etc., where there are typically very large numbers of small multicast groups.
当今的多播方案可用于最小化带宽消耗。显式多单播（Xcast）也可用于最小化“小组”的带宽消耗。但它也有一个额外的优势。Xcast消除了传统IP多播方案的每会话信令和每会话状态信息，这使得Xcast能够支持大量的多播会话。这种可扩展性非常重要，因为它支持重要的应用程序类别，如IP电话、视频会议、协作应用程序、网络游戏等，其中通常有大量的小型多播组。
Interestingly, the idea for Xcast has been around for some time, although this was not immediately known to the three groups that independently re-invented it in the late 1990's. In fact the very
有趣的是，Xcast的想法已经存在了一段时间，尽管在20世纪90年代末独立重新发明Xcast的三个小组还不知道这一点。事实上
first proposal of the multicast concept in the Internet community, by Lorenzo Aguilar in his 1984 SIGCOMM paper [AGUI] proposed the use of an explicit list of destinations discussed in more detail below. At about the same time, David Cheriton and Stephen Deering developed Host Group Multicast in 1985 [CHER].
Lorenzo Aguilar在其1984年的SIGCOMM论文[AGUI]中首次提出了互联网社区中的多播概念，并提出使用一个明确的目的地列表，下文将对此进行更详细的讨论。大约在同一时间，David Cheriton和Stephen Deering在1985年开发了主机组多播[CHER]。
The Internet community compared the two proposals and concluded that a single mechanism was preferable to multiple mechanisms. Further, since Aguilar's proposal seemed to have serious scaling problems, the Host Group model was adopted.
互联网界比较了这两项建议，得出结论认为单一机制优于多种机制。此外，由于Aguilar的提案似乎存在严重的规模问题，因此采用了东道国集团模式。
However, for reasons described below, we believe it makes sense to use different mechanisms for the two different kinds of multicast discussed above. While Host Group multicast may have been sufficient in the Internet of 1985, we believe that Xcast can be an important complement to Host Group multicast in the Internet of the 21st century.
然而，出于下述原因，我们认为对上述两种不同类型的多播使用不同的机制是有意义的。虽然主机组多播在1985年的互联网上可能已经足够了，但我们相信Xcast可以成为21世纪互联网上主机组多播的重要补充。
In this document, the following terminology will be used:
在本文件中，将使用以下术语：
- Session: in Xcast, the term 'multicast session' will be used instead of 'multicast group' to avoid the strong association of multicast groups with multicast group addresses in traditional IP multicast.
- 会话：在Xcast中，将使用术语“多播会话”代替“多播组”，以避免传统IP多播中多播组与多播组地址的强关联。
- Channel: in a session with multiple senders (e.g., a video conference), the flow sourced by one sender will be called a channel. So, a session can contain one or more channels.
- 通道：在与多个发送者的会话中（例如，视频会议），由一个发送者提供的流将被称为通道。因此，会话可以包含一个或多个通道。
In the Host Group Model, the packet carries a multicast address as a logical identifier of all group members. In Xcast, the source node keeps track of the destinations in the multicast channel that it wants to send packets to.
在主机组模型中，数据包携带多播地址作为所有组成员的逻辑标识符。在Xcast中，源节点跟踪它要向其发送数据包的多播信道中的目的地。
The source encodes the list of destinations in the Xcast header, and then sends the packet to a router. Each router along the way parses the header, partitions the destinations based on each destination's next hop, and forwards a packet with an appropriate Xcast header to each of the next hops.
源对Xcast报头中的目的地列表进行编码，然后将数据包发送到路由器。沿途的每个路由器解析报头，根据每个目的地的下一跳对目的地进行分区，并将带有适当Xcast报头的数据包转发给每个下一跳。
When there is only one destination left, the Xcast packet can be converted into a normal unicast packet, which can be unicasted along the remainder of the route. This is called X2U (Xcast to Unicast).
当只剩下一个目的地时，可以将Xcast数据包转换为正常的单播数据包，该数据包可以沿路由的其余部分单播。这称为X2U（Xcast-to-Unicast）。
For example, suppose that A is trying to get packets distributed to B, C, and D in Figure 1 below:
例如，假设A正试图获得分布到图1中B、C和D的数据包：
R4 ---- B
/
/
A----- R1 ---- R2 ---- R3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- R7
\
\
R9 ---- D
R4 ---- B
/
/
A----- R1 ---- R2 ---- R3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- R7
\
\
R9 ---- D
Figure 1
图1
This is accomplished as follows: A sends an Xcast packet with the list of destinations in its Xcast header to the first router, R1.
这是通过以下方式完成的：A向第一个路由器R1发送一个Xcast数据包，其中包含其Xcast报头中的目的地列表。
Since the Xcast header will be slightly different for IPv4 and IPv6 [2460], we won't reveal any details on the encoding of the Xcast header in this section (see Section 9). So, ignoring the details, the packet that A sends to R1 looks like this:
由于IPv4和IPv6[2460]的Xcast报头略有不同，因此在本节中，我们不会透露有关Xcast报头编码的任何详细信息（请参阅第9节）。因此，忽略细节，A发送给R1的数据包如下所示：
[ src = A | dest = B C D | payload ]
[src=A | dest=B C D |有效载荷]
When R1 receives this packet, it needs to properly process the Xcast header. The processing that a router does on receiving one of these Xcast packets is as follows:
当R1收到此数据包时，它需要正确处理Xcast报头。路由器在接收其中一个Xcast数据包时所做的处理如下：
- Perform a route table lookup to determine the next hop for each of the destinations listed in the packet.
- 执行路由表查找以确定数据包中列出的每个目的地的下一跳。
- Partition the set of destinations based on their next hops.
- 根据目标的下一个跃点对目标集进行分区。
- Replicate the packet so that there's one copy of the packet for each of the next hops found in the previous steps.
- 复制数据包，以便在前面的步骤中找到的每个下一个跃点都有一个数据包副本。
- Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop.
- 修改每个副本中的目的地列表，以便给定下一跳的副本中的列表仅包括应该通过该下一跳路由的目的地。
- Send the modified copies of the packet on to the next hops.
- 将数据包的修改副本发送到下一个跃点。
- Optimization: If there is only one destination for a particular next hop, the packet can be sent as a standard unicast packet to the destination (X2U).
- 优化：如果特定下一跳只有一个目的地，则可以将数据包作为标准单播数据包发送到目的地（X2U）。
So, in the example above, R1 will send a single packet on to R2 with a destination list of < B C D >, and R2 will send a single packet to R3 with the same destination list.
因此，在上面的示例中，R1将向R2发送一个带有<bcd>目的地列表的单个数据包，R2将向R3发送带有相同目的地列表的单个数据包。
When R3 receives the packet, it will, by the algorithm above, send one copy of the packet to next hop R5 with an Xcast list of < C D >, and one ordinary unicast packet addressed to < B > to R4. R4 will receive a standard unicast packet and forward it on to < B >. R5 will forward the Xcast packet that it receives on to R6, which will pass it on to R7. When the packet reaches R7, R7 will transmit ordinary unicast packets addressed to < C > and < D >, respectively. R8 and R9 will receive standard unicast packets, and forward the packets on to < C > and < D >, respectively.
当R3接收到该分组时，它将通过上述算法将该分组的一个副本发送到下一跳R5，其中Xcast列表为<cd>，并将一个普通单播分组发送到R4。R4将接收标准单播数据包并将其转发到<B>。R5将接收到的Xcast数据包转发给R6，R6将把它传递给R7。当分组到达R7时，R7将分别向<C>和<D>发送普通单播分组。R8和R9将接收标准单播数据包，并将数据包分别转发到<C>和<D>。
It's important that the Xcast packet that is sent to a given next hop only includes destinations for which that next hop is the next hop listed in the route table. If the list of destinations in the packet sent to R4, for example, had also included C and D, R4 would send duplicate packets.
重要的是，发送到给定下一跳的Xcast数据包只包括下一跳是路由表中列出的下一跳的目的地。例如，如果发送到R4的数据包中的目的地列表也包括C和D，则R4将发送重复的数据包。
Note that when routing topology changes, the routing for an Xcast channel will automatically adapt to the new topology since the path an Xcast packet takes to a given destination always follows the ordinary, unicast routing for that destination.
请注意，当路由拓扑发生变化时，Xcast通道的路由将自动适应新拓扑，因为Xcast数据包到给定目的地的路径始终遵循该目的地的普通单播路由。
Traditional IP multicast schemes [DEER, DEE2, FARI] were designed to handle very large multicast groups. These work well if one is trying to distribute broadcast-like channels all around the world but they have scalability problems when there is a very large number of groups.
传统的IP多播方案[DEER、DEE2、FARI]设计用于处理非常大的多播组。如果一个人试图在全世界范围内分发类似广播的频道，这些功能很好，但是当有大量的组时，它们的可伸缩性就会出现问题。
The characteristics of the traditional IP multicast model are determined by its two components: the Host Group model [DEER] and a Multicast Routing Protocol. Both components make multicast very different from unicast.
传统IP多播模型的特征由其两个组成部分决定：主机组模型[DEER]和多播路由协议。这两个组件使多播与单播非常不同。
In the Host Group model, a group of hosts is identified by a multicast group address, which is used both for subscriptions and forwarding. This model has two main costs:
在主机组模型中，主机组由多播组地址标识，该地址用于订阅和转发。这种模式有两个主要成本：
- Multicast address allocation: The creator of a multicast group must allocate a multicast address that is unique in its scope (scope will often be global). This issue is being addressed by the MALLOC working group, which is proposing a set of Multicast Address Allocation Servers (MAAS) and three protocols (Multicast Address Set Claim (MASC), Address Allocation Protocol (AAP), Multicast Address Dynamic Client Allocation Protocol (MADCAP)).
- 多播地址分配：多播组的创建者必须分配在其作用域中唯一的多播地址（作用域通常是全局的）。MALLOC工作组正在解决这个问题，该工作组提出了一组多播地址分配服务器（MAA）和三个协议（多播地址集声明（MASC）、地址分配协议（AAP）、多播地址动态客户端分配协议（MADCAP））。
- Destination unawareness: When a multicast packet arrives in a router, the router can determine the next hops for the packet, but knows nothing about the ultimate destinations of the packet, nor about how many times the packet will be duplicated later on in the network. This complicates the security, accounting and policy functions.
- 目的地不可知：当多播数据包到达路由器时，路由器可以确定数据包的下一个跃点，但不知道数据包的最终目的地，也不知道数据包稍后在网络中被复制的次数。这使安全、会计和政策职能复杂化。
In addition to the Host Group model, a routing algorithm is required to maintain the member state and the delivery tree. This can be done using a (truncated) broadcast algorithm or a multicast algorithm [DEER]. Since the former consumes too much bandwidth by unnecessarily forwarding packets to some routers, only the multicast algorithms are considered. These multicast routing protocols have the following costs:
除了主机组模型外，还需要一个路由算法来维护成员国和传递树。这可以使用（截断的）广播算法或多播算法[DEER]来实现。由于前者通过不必要地将数据包转发给某些路由器而消耗了太多的带宽，因此只考虑了多播算法。这些多播路由协议具有以下成本：
- Connection state: The multicast routing protocols exchange messages that create state for each (source, multicast group) in all the routers that are part of the point-to-multipoint tree. This can be viewed as "per flow" signaling that creates multicast connection state, possibly yielding huge multicast forwarding tables. Some of these schemes even disseminate this multicast routing information to places where it isn't necessarily needed [1075]. Other schemes try to limit the amount of multicast routing information that needs to be disseminated, processed, and stored throughout the network. These schemes (e.g., [2201]) use a "shared distribution tree" that is shared by all the members of a multicast group and they try to limit the distribution of multicast routing information to just those nodes that "really need it". But these schemes also have problems. Because of the shared tree, they use less than optimal paths in routing packets to their destinations and they tend to concentrate traffic in small portions of a network. And these schemes still involve lots of "per flow" signaling and "per flow" state.
- 连接状态：多播路由协议交换消息，为作为点对多点树一部分的所有路由器中的每个（源、多播组）创建状态。这可以看作是创建多播连接状态的“按流”信令，可能会产生巨大的多播转发表。其中一些方案甚至将这种多播路由信息传播到不一定需要的地方[1075]。其他方案试图限制需要在整个网络中传播、处理和存储的多播路由信息的数量。这些方案（例如，[2201]）使用由多播组的所有成员共享的“共享分发树”，并且它们试图将多播路由信息的分发限制到“真正需要它”的节点。但这些计划也存在问题。由于共享树，它们在将数据包路由到目的地时使用的路径不太理想，而且它们往往将流量集中在网络的一小部分。这些方案仍然涉及大量的“每流”信令和“每流”状态。
- Source advertisement mechanism: Multicast routing protocols provide a mechanism by which members get 'connected' to the sources for a certain group without knowing the sources themselves. In sparse-mode protocols [2201, DEE2], this is achieved by having a core node, which needs to be advertised in the complete domain. On the other hand, in dense-mode protocols [1075] this is achieved by a "flood and prune" mechanism. Both approaches raise additional scalability issues.
- 源播发机制：多播路由协议提供了一种机制，通过该机制，成员可以在不知道源的情况下“连接”到特定组的源。在稀疏模式协议[2201，DEE2]中，这是通过拥有一个核心节点来实现的，该节点需要在整个域中公布。另一方面，在密集模式协议[1075]中，这是通过“洪水和修剪”机制实现的。这两种方法都会带来额外的可伸缩性问题。
- Inter-domain routing: Multicast routing protocols that rely on a core node [2201, DEE2] additionally need an inter-domain multicast routing protocol (e.g., [FARI]).
- 域间路由：依赖于核心节点[2201，DEE2]的多播路由协议还需要域间多播路由协议（例如[FARI]）。
The cost of multicast address allocation, destination unawareness and the above scalability issues lead to a search for other multicast schemes. Source-Specific Multicast (SSM) [4607] addresses some of the above drawbacks: in SSM, a host joins a specific source, thus the channel is identified by the couple (source address, multicast address). This approach avoids multicast address allocation as well as the need for an inter-domain routing protocol. The source advertisement is taken out of the multicast routing protocol and is moved to an out-of-band mechanism (e.g., web page).
多播地址分配的成本、目的地不可知性以及上述可伸缩性问题导致了对其他多播方案的搜索。源特定多播（SSM）[4607]解决了上述一些缺点：在SSM中，主机加入特定的源，因此通道由该对（源地址，多播地址）标识。这种方法避免了多播地址分配以及域间路由协议的需要。源广告从多播路由协议中取出，并移动到带外机制（例如，网页）。
Note that SSM still creates state and signaling per multicast channel in each on-tree node. Figure 2 depicts the above costs as a function of the number of members in the session or channel. All the costs have a hyperbolic behavior.
注意，SSM仍然在每个on树节点中为每个多播信道创建状态和信令。图2将上述成本描述为会话或通道中成员数量的函数。所有的成本都有一个双曲线行为。
cost of the traditional
IP multicast model
per member
^
| costly| OK
| <-----|----->
| . |
| .. |
| ..|..
| | .........
| | ........
+--------------------------->
| number of members
v
alternative=Xcast
cost of the traditional
IP multicast model
per member
^
| costly| OK
| <-----|----->
| . |
| .. |
| ..|..
| | .........
| | ........
+--------------------------->
| number of members
v
alternative=Xcast
Figure 2
图2
The traditional IP multicast model becomes expensive for its members if the groups are small. Small groups are typical for conferencing, gaming, and collaborative applications. These applications are well-served by Xcast.
如果组较小，传统的IP多播模型对其成员来说成本较高。小型组通常用于会议、游戏和协作应用程序。Xcast很好地服务于这些应用程序。
In practice, traditional IP multicast routing protocols impose limitations on the number of groups and the size of the network in which they are deployed. For Xcast, these limitations do not exist.
在实践中，传统的IP多播路由协议对组的数量和部署它们的网络的大小施加了限制。对于Xcast，这些限制并不存在。
Xcast takes advantage of one of the fundamental tenets of the Internet "philosophy", namely, that one should move complexity to the edges of the network and keep the middle of the network simple. This is the principle that guided the design of IP and TCP and it's the principle that has made the incredible growth of the Internet possible. For example, one reason that the Internet has been able to scale so well is that the routers in the core of the network deal with large Classless Inter-Domain Routing (CIDR) blocks as opposed to individual hosts or individual "connections". The routers in the core don't need to keep track of the individual TCP connections that are passing through them. Similarly, the IETF's Diffserv effort is based on the idea that the routers shouldn't have to keep track of a large number of individual Resource Reservation Protocol (RSVP) flows that might be passing through them. It's the authors' belief that the routers in the core shouldn't have to keep track of a large number of individual multicast flows, either.
Xcast利用了互联网“哲学”的一个基本原则，即将复杂性转移到网络的边缘，并保持网络的中间部分简单。这是指导IP和TCP设计的原则，也是使互联网难以置信的发展成为可能的原则。例如，互联网能够如此良好地扩展的一个原因是网络核心中的路由器处理大型无类域间路由（CIDR）块，而不是单个主机或单个“连接”。核心路由器不需要跟踪通过它们的各个TCP连接。类似地，IETF的Diffserv工作基于这样一个想法，即路由器不必跟踪可能通过它们的大量单独资源预留协议（RSVP）流。作者认为，核心路由器也不必跟踪大量单独的多播流。
Compared to traditional IP multicast, Xcast has the following advantages:
与传统IP组播相比，Xcast具有以下优势：
1) Routers do not have to maintain state per session (or per channel) [SOLA]. This makes Xcast very scalable in terms of the number of sessions that can be supported since the nodes in the network do not need to disseminate or store any multicast routing information for these sessions.
1) 路由器不必维护每个会话（或每个通道）的状态[SOLA]。这使得Xcast在可支持的会话数量方面非常可伸缩，因为网络中的节点不需要传播或存储这些会话的任何多播路由信息。
2) No multicast address allocation required.
2) 不需要多播地址分配。
3) No need for multicast routing protocols (neither intra- nor inter-domain). Xcast packets always take the "right" path as determined by the ordinary unicast routing protocols.
3) 不需要多播路由协议（域内或域间）。Xcast数据包总是采用普通单播路由协议确定的“正确”路径。
4) No core node, so no single point of failure. Unlike the shared tree schemes, Xcast minimizes network latency and maximizes network "efficiency".
4) 没有核心节点，因此没有单点故障。与共享树方案不同，Xcast最小化了网络延迟并最大化了网络“效率”。
5) Symmetric paths are not required. Traditional IP multicast routing protocols create non-shortest-path trees if paths are not symmetric. (A path between two nodes A and B is symmetric if the path is both the shortest path from A to B as well as the shortest path from B to A.) It is expected that an increasing number of paths in the Internet will be asymmetric in the future as a result of traffic engineering and policy routing, and thus the traditional IP multicast schemes will result in an increasing amount of suboptimal routing.
5) 对称路径不是必需的。如果路径不对称，传统的IP多播路由协议会创建非最短路径树。（如果两个节点A和B之间的路径是从A到B的最短路径以及从B到A的最短路径，则两个节点A和B之间的路径是对称的。）由于流量工程和策略路由，预计未来互联网中越来越多的路径将是非对称的，因此，传统的IP多播方案将导致越来越多的次优路由。
6) Automatic reaction to unicast reroutes. Xcast will react immediately to unicast route changes. In traditional IP multicast routing protocols, a communication between the unicast and the multicast routing protocol needs to be established. In many implementations, this is on a polling basis, yielding a slower reaction to, e.g., link failures. It may also take some time for traditional IP multicast routing protocols to fix things up if there is a large number of groups that need to be fixed.
6) 对单播重路由的自动反应。Xcast将立即对单播路由更改作出反应。在传统的IP多播路由协议中，需要在单播和多播路由协议之间建立通信。在许多实现中，这是在轮询的基础上进行的，因此对链路故障的反应较慢。如果有大量的组需要修复，传统的IP多播路由协议也可能需要一些时间来修复。
7) Easy security and accounting. In contrast with the Host Group Model, in Xcast all the sources know the members of the multicast channel, which gives the sources the means to, e.g., reject certain members or count the traffic going to certain members quite easily. Not only a source, but also a border router is able to determine how many times a packet will be duplicated in its domain. It also becomes easier to restrict the number of senders or the bandwidth per sender.
7) 容易的安全和会计。与主机组模型相比，在Xcast中，所有源都知道多播信道的成员，这为源提供了方法，例如，拒绝某些成员或非常容易地统计流向某些成员的流量。不仅源路由器，而且边界路由器都能够确定一个数据包在其域中被复制的次数。限制发送者的数量或每个发送者的带宽也变得更加容易。
8) Heterogeneous receivers. Besides the list of destinations, the packet could (optionally) also contain a list of Diffserv Code Points (DSCPs). While traditional IP multicast protocols have to create separate groups for each service class, Xcast incorporates the possibility of having receivers with different service requirements within one multicast channel.
8) 异构接收机。除了目的地列表外，数据包还可以（可选地）包含区分服务代码点（DSCP）列表。虽然传统的IP多播协议必须为每个服务类别创建单独的组，但Xcast结合了在一个多播信道中具有不同服务需求的接收器的可能性。
9) Xcast packets can make use of traffic-engineered unicast paths.
9) Xcast数据包可以利用流量工程单播路径。
10) Simple implementation of reliable protocols on top of Xcast, because Xcast can easily address a subset of the original list of destinations to do a retransmission.
10） 在Xcast之上简单地实现可靠的协议，因为Xcast可以轻松地处理原始目的地列表的子集以进行重传。
11) Flexibility (see Section 6).
11） 灵活性（见第6节）。
12) Easy transition mechanisms (see Section 11).
12） 简易过渡机构（见第11节）。
It should be noted that Xcast has a number of disadvantages as well:
应该注意的是，Xcast也有许多缺点：
1) Overhead. Each packet contains all remaining destinations. But, the total amount of data is still much less than for unicast (payload is only sent once). A method to compress the list of destination addresses might be useful.
1) 开销每个数据包包含所有剩余的目的地。但是，总的数据量仍然比单播要少得多（有效负载只发送一次）。压缩目标地址列表的方法可能很有用。
2) More complex header processing. Each destination in the packet needs a routing table lookup. So, an Xcast packet with n destinations requires the same number of routing table lookups as n unicast headers. Additionally, a different header has to be constructed per next hop. Note however that:
2) 更复杂的报头处理。数据包中的每个目的地都需要路由表查找。因此，具有n个目的地的Xcast数据包需要与n个单播头相同数量的路由表查找。此外，每个下一跳必须构造不同的头。但请注意：
a) Since Xcast will typically be used for super-sparse sessions, there will be a limited number of branching points, compared to non-branching points. Only in a branching point do new headers need to be constructed.
a) 由于Xcast通常用于超稀疏会话，因此与非分支点相比，分支点的数量有限。只有在分支点中，才需要构造新的头。
b) The header construction can be reduced to a very simple operation: overwriting a bitmap.
b) 标题构造可以简化为一个非常简单的操作：覆盖位图。
c) Among the non-branching points, a lot of them will contain only one destination. In these cases, normal unicast forwarding can be applied.
c) 在非分支点中，很多只包含一个目的地。在这些情况下，可以应用正常的单播转发。
d) By using a hierarchical encoding of the list of destinations in combination with the aggregation in the forwarding tables the forwarding can be accelerated [OOMS].
d) 通过使用目的地列表的分层编码以及转发表中的聚合，可以加速转发[OOMS]。
e) When the packet enters a region of the network where link bandwidth is not an issue anymore, the packet can be transformed by a Premature X2U. Premature X2U (see Section 11.2) occurs when a router decides to transform the Xcast packet for one or more destinations into unicast packets. This avoids more complex processing downstream.
e) 当数据包进入链路带宽不再是问题的网络区域时，数据包可以通过X2U进行转换。当路由器决定将一个或多个目的地的Xcast数据包转换为单播数据包时，会出现过早的X2U（参见第11.2节）。这避免了更复杂的下游处理。
f) Other mechanisms to reduce the processing have been described in [IMAI] (tractable list) and [OOMS] (caching), but are not (yet) part of the Xcast specification.
f) 其他减少处理的机制已经在[IMAI]（可处理列表）和[OOMS]（缓存）中描述过，但是（目前）还不是Xcast规范的一部分。
3) Xcast only works with a limited number of receivers.
3) Xcast仅适用于数量有限的接收器。
While Xcast is not suitable for multicast sessions with a large number of members, such as the broadcast of an IETF meeting, it does provide an important complement to existing multicast schemes in that it can support very large numbers of small sessions. Thus, Xcast enables important applications such as IP telephony, videoconferencing, multi-player games, collaborative e-meetings, etc. The number of these sessions will become huge.
虽然Xcast不适用于具有大量成员的多播会话，例如IETF会议的广播，但它确实提供了对现有多播方案的重要补充，因为它可以支持大量的小会话。因此，Xcast支持IP电话、视频会议、多人游戏、协作电子会议等重要应用。这些会话的数量将变得巨大。
Some may argue that it is not worthwhile to use multicast for sessions with a limited number of members, and that it's preferable to use unicast instead. But in certain cases, limited bandwidth in the "last mile" makes it important to have some form of multicast, as the following example illustrates. Assume n residential users set up a video conference. Typically, access technologies are asymmetric (e.g., xDSL, General Packet Radio Service (GPRS), or cable modem). So, a host with xDSL has no problem receiving n-1 basic 100 kb/s
有些人可能会争辩说，在成员数量有限的会话中使用多播是不值得的，最好使用单播。但在某些情况下，“最后一英里”的有限带宽使得采用某种形式的多播变得非常重要，如下例所示。假设n个住宅用户设置了视频会议。通常，接入技术是不对称的（例如，xDSL、通用分组无线业务（GPRS）或电缆调制解调器）。因此，具有xDSL的主机接收n-1基本100 kb/s没有问题
video channels, but the host is not able to send its own video data n-1 times at this rate. Because of the limited and often asymmetric access capacity, some type of multicast is mandatory.
视频通道，但主机无法按此速率发送自己的视频数据n-1次。由于访问容量有限且往往不对称，因此必须使用某种类型的多播。
A simple but important application of Xcast lies in bridging the access link. The host sends the Xcast packet with the list of unicast addresses and the first router performs a Premature X2U.
Xcast的一个简单但重要的应用在于桥接接入链路。主机发送带有单播地址列表的Xcast数据包，第一个路由器执行提前X2U。
Since Xcast is not suitable for large groups, Xcast will not replace the traditional IP multicast model, but it does offer an alternative for multipoint-to-multipoint communications when there can be very large numbers of small sessions.
由于Xcast不适用于大型组，因此Xcast将不会取代传统的IP多播模型，但它确实为可能存在大量小型会话的多点对多点通信提供了一种替代方案。
The main goal of multicast is to avoid duplicate information flowing over the same link. By using traditional IP multicast instead of unicast, bandwidth consumption decreases while the state and signaling per session increases. Xcast has a cost of 0 in these two dimensions, but it does introduce a third dimension corresponding to the header processing per packet. This three-dimensional space is depicted in Figure 3.
多播的主要目标是避免重复信息在同一链路上流动。通过使用传统的IP多播代替单播，带宽消耗减少，而每个会话的状态和信令增加。Xcast在这两个维度上的成本为0，但它确实引入了与每个数据包的报头处理相对应的第三个维度。该三维空间如图3所示。
state&signaling
per session
in router
^
|
|
....
B | ....
. | ....
. | ....
. | ....
. +------------------..---> processing
. / .... C per packet
. / ..... in router
. / .....
. / .....
./ .....
/A....
/
/
link bandwidth
state&signaling
per session
in router
^
|
|
....
B | ....
. | ....
. | ....
. | ....
. +------------------..---> processing
. / .... C per packet
. / ..... in router
. / .....
. / .....
./ .....
/A....
/
/
link bandwidth
Figure 3
图3
One method of delivering identical information from a source to n destinations is to unicast the information n times (A in Figure 3). A second method, the traditional IP multicast model (B in Figure 3), sends the information only once to a multicast address. In Xcast, the information is sent only once, but the packet contains a list of destinations (point C).
从一个源向n个目的地传递相同信息的一种方法是单播n次信息（图3中的a）。第二种方法是传统的IP多播模型（图3中的B），它只向多播地址发送一次信息。在Xcast中，信息只发送一次，但数据包包含一个目的地列表（C点）。
The three points A, B, and C define a plane (indicated with dots in Figure 3): a plane of conservation of misery. All three approaches have disadvantages. The link bandwidth is a scarce resource, especially in access networks. State&signaling/session encounters limitations when the number of sessions becomes large, and an increased processing/packet is cumbersome for high-link speeds.
三个点A、B和C定义了一个平面（图3中用点表示）：一个痛苦守恒平面。这三种方法都有缺点。链路带宽是一种稀缺资源，尤其是在接入网中。当会话数量变大时，状态和信令/会话会遇到限制，并且对于高链路速度而言，增加的处理/数据包是很麻烦的。
One advantage of Xcast is that it allows a router to move within this plane of conservation of misery based upon its location in a network. For example, in the core of the network, a cache could be used to move along the line from C to B without introducing any per-flow signaling. Another possibility, as suggested above, is to use premature X2U to move along the line from C to A in an access network if there is an abundance of bandwidth in the backbone.
Xcast的一个优点是，它允许路由器根据其在网络中的位置在痛苦守恒平面内移动。例如，在网络的核心中，可以使用缓存沿线路从C移动到B，而不引入任何每流信令。如上所述，另一种可能性是，如果主干网中有大量带宽，则在接入网络中使用过早的X2U沿着从C到A的线路移动。
Unlike traditional IP multicast schemes, Xcast does not specify a "control plane". There is no Internet Group Management Protocol (IGMP [3376]), and as mentioned above, there are no intra- or inter-domain multicast routing protocols. With Xcast, the means by which multicast sessions are defined is an application-level issue and applications are not confined to the model in which hosts use IGMP to join a multicast session. For example:
与传统的IP多播方案不同，Xcast没有指定“控制平面”。没有Internet组管理协议（IGMP[3376]），如上所述，没有域内或域间多播路由协议。对于Xcast，定义多播会话的方法是应用程序级别的问题，并且应用程序不限于主机使用IGMP加入多播会话的模型。例如：
- Some applications might want to use an IGMP-like receiver-join model.
- 某些应用程序可能希望使用类似IGMP的接收器连接模型。
- Other applications might want to use a model in which a user places a call to the party or parties that he or she wants to talk to (similar to the way that one puts together a conference call today using the buttons on one's telephone).
- 其他应用程序可能希望使用这样一种模式：用户向他或她想要通话的一方或多方打电话（类似于今天使用电话上的按钮进行电话会议的方式）。
- One might define a session based on the cells that are close to a moving device in order to provide for a "smooth handoff" between cells when the moving device crosses cell boundaries.
- 可以基于靠近移动设备的小区定义会话，以便在移动设备跨越小区边界时提供小区之间的“平滑切换”。
- In some applications, the members of the session might be specified as arguments on a command line.
- 在某些应用程序中，会话的成员可能被指定为命令行上的参数。
- One might define an application that uses GPS to send video from a bank robbery to the three police cars that are closest to the bank being robbed.
- 你可以定义一个应用程序，它使用GPS将银行抢劫的视频发送到离被抢劫银行最近的三辆警车。
Thus, the application developer is not limited to the receiver-initiated joins of the IGMP model. There will be multiple ways in which an Xcast sender determines the addresses of the members of the channel.
因此，应用程序开发人员不限于接收端发起的IGMP模型连接。Xcast发送方可以通过多种方式确定通道成员的地址。
For the purpose of establishing voice and multimedia conferences over IP networks, several control planes have already been defined, including SIP [3261] and H.323 [H323].
为了在IP网络上建立语音和多媒体会议，已经定义了几个控制平面，包括SIP[3261]和H.323[H323]。
In SIP, a host takes the initiative to set up a session. With the assistance of a SIP server, a session is created. The session state is kept in the hosts. Data delivery can be achieved by several mechanisms: meshed unicast, bridged, or multicast. Note that for the establishment of multicast delivery, a multicast protocol and communication with Multicast Address Allocation Servers (MAAS) are still required.
在SIP中，主机主动建立会话。在SIP服务器的帮助下，创建会话。会话状态保留在主机中。数据传输可以通过几种机制实现：网状单播、桥接或多播。注意，为了建立多播传送，仍然需要多播协议和与多播地址分配服务器（MAA）的通信。
In "meshed unicast" or "multi-unicasting", the application keeps track of the participants' unicast addresses and sends a unicast to each of those addresses. For reasons described in Section 3, multi-unicasting (rather than multicast) is the prevalent solution in use today. It's a simple matter to replace multi-unicast code with Xcast code. All that the developer has to do is replace a loop that sends a unicast to each of the participants by a single "xcast_send" that sends the data to the participants. Thus it's easy to incorporate Xcast into real conferencing applications.
在“网状单播”或“多单播”中，应用程序跟踪参与者的单播地址，并向每个地址发送单播。由于第3节中所述的原因，多单播（而非多播）是当今流行的解决方案。用Xcast代码替换多单播代码是一件简单的事情。开发人员所要做的就是将向每个参与者发送单播的循环替换为向参与者发送数据的单个“xcast_send”。因此，很容易将Xcast合并到实际的会议应用程序中。
Both Xcast and SIP address super-sparse multicast sessions. It turns out that Xcast (a very flexible data plane mechanism) can be easily integrated with SIP (a very flexible control plane protocol). When an application decides to use Xcast forwarding it does not affect its interface to the SIP agent: it can use the same SIP messages as it would for multi-unicasting. SIP could be used with Xcast to support the conferencing model mentioned above in which a caller places a call to several parties.
Xcast和SIP都可以寻址超级稀疏多播会话。事实证明，Xcast（一种非常灵活的数据平面机制）可以很容易地与SIP（一种非常灵活的控制平面协议）集成。当应用程序决定使用Xcast转发时，它不会影响其与SIP代理的接口：它可以使用与多单播相同的SIP消息。SIP可以与Xcast一起使用，以支持上面提到的会议模型，在该模型中，呼叫者向多个参与方发出呼叫。
In the previous section, it was discussed how to establish an Xcast session among well known participants of a multi-party conference. In some cases, it is useful for participants to be able to join a session without being invited. For example, the chairman of a video
在上一节中，讨论了如何在多方会议的知名与会者之间建立Xcast会议。在某些情况下，参与者能够在不受邀请的情况下参加会议是很有用的。例如，一个视频的主席
chat may want to leave the door of their meeting open for newcomers. The IGMP-like receiver-initiated join model mentioned above can be implemented by introducing a server that hosts can talk to, to join a conference.
聊天室可能希望为新来者敞开会议的大门。上面提到的类似于IGMP的接收方发起的加入模型可以通过引入主机可以对话的服务器来实现，以加入会议。
Although an extension to SIP could be arranged such that all participants in a session use the same transport (UDP) port number, in the general case, it is possible for each participant to listen on a different port number. To cover this case, the Xcast packet optionally contains a list of port numbers.
虽然SIP的扩展可以安排为会话中的所有参与者使用相同的传输（UDP）端口号，但在一般情况下，每个参与者都可以监听不同的端口号。为了涵盖这种情况，Xcast数据包可选地包含端口号列表。
If the list of port numbers is present, the destination port number in the transport-layer header will be set to zero. On X2U, the destination port number in the transport-layer header will be set to the port number corresponding to the destination of the unicast packet.
如果存在端口号列表，则传输层标头中的目标端口号将设置为零。在X2U上，传输层报头中的目标端口号将设置为与单播数据包的目标对应的端口号。
The Xcast packet could (optionally) also contain a list of Diffserv Code Points (DSCPs). While traditional IP multicast protocols have to create separate groups for each service class, Xcast incorporates the possibility of having receivers with different service requirements within one channel.
Xcast数据包还可以（可选）包含一个区分服务代码点（DSCP）列表。虽然传统的IP多播协议必须为每个服务类别创建单独的组，但Xcast结合了在一个通道中具有不同服务需求的接收器的可能性。
The DSCP in the IP header will be set to the most demanding DSCP of the list of DSCPs. This DSCP in the IP header will determine, e.g., the scheduler to use.
IP报头中的DSCP将设置为DSCP列表中要求最高的DSCP。IP报头中的此DSCP将决定要使用的调度程序。
If two destinations, with the same next-hop, have 'non-mergeable' DSCPs, two Xcast packets will be created. 'Non-mergeable' meaning that one cannot say that one is more or less stringent than the other.
如果具有相同下一跳的两个目的地具有“不可合并”的DSCP，则将创建两个Xcast数据包“不可合并”指一方不能说一方比另一方严格或不严格。
Optionally, a sender can decide to add an extra number in the Xcast header: the Channel Identifier. If the source does not want to use this option, it must set the Channel Identifier to zero. If the Channel Identifier is non-zero, the pair (Source Address, Channel Identifier) must uniquely identify the channel (note that this is similar to the (S, G) pair in SSM). This document does not assign any other semantics to the Channel Identifier besides the one above.
或者，发送方可以决定在Xcast头中添加一个额外的数字：通道标识符。如果源不想使用此选项，则必须将通道标识符设置为零。如果信道标识符为非零，则该对（源地址、信道标识符）必须唯一标识信道（注意，这与SSM中的（S，G）对类似）。除上述语义外，本文档不为通道标识符分配任何其他语义。
This Channel Identifier could be useful for several purposes:
此通道标识符可用于多种用途：
1) A key to a caching table [OOMS].
1) 缓存表[OOMS]的键。
2) "Harmonization" when used with Host Group Multicast (to be discussed in greater detail in another document).
2) 与主机组多播一起使用时的“协调”（将在另一份文档中详细讨论）。
3) An identifier of the channel in error, flow control, etc., messages.
3) 错误、流控制等消息中通道的标识符。
4) It gives an extra demultiplexing possibility (beside the port-number).
4) 它提供了额外的解复用可能性（除了端口号）。
5) ...
5) ...
The size of the channel identifier and its semantics are TBD.
通道标识符的大小及其语义待定。
The source address field of the IP header contains the address of the Xcast sender. The destination address field carries the All-Xcast-Routers address (to be assigned link-local multicast address); this is to have a fixed value. Every Xcast router joins this multicast group. The reasons for putting a fixed number in the destination field are:
IP头的源地址字段包含Xcast发送方的地址。目的地地址字段携带所有Xcast路由器地址（分配给链路本地多播地址）；这是一个固定的值。每个Xcast路由器都加入此多播组。在目的地字段中放置固定号码的原因如下：
1) The destination address field is part of the IP pseudo header and the latter is covered by transport layer checksums (e.g., UDP checksum). So, the fixed value avoids a (delta) recalculation of the checksum.
1) 目标地址字段是IP伪报头的一部分，后者由传输层校验和（例如UDP校验和）覆盖。因此，固定值避免了校验和的（增量）重新计算。
2) The IPsec Authentication Header (AH) [4302] covers the IP header destination address, hence preventing any modification to that field. Also, both AHs and Encapsulating Security Payloads (ESPs) cover the whole UDP packet (via authentication and/or encryption). The UDP checksum cannot therefore be updated if the IP header destination address were to change.
2) IPsec认证头（AH）[4302]覆盖IP头目的地址，因此防止对该字段进行任何修改。此外，AHs和封装安全有效载荷（ESP）都覆盖整个UDP数据包（通过身份验证和/或加密）。因此，如果IP标头目标地址发生更改，则无法更新UDP校验和。
3) In Xcast for IPv6, the Routing Extension shall be used; this header extension is only checked by a router if the packet is destined to this router. This is achieved by making all Xcast routers part of the All_Xcast_Routers group.
3) 在用于IPv6的Xcast中，应使用路由扩展；如果数据包的目的地是该路由器，则该报头扩展仅由路由器检查。这是通过使所有Xcast路由器成为所有Xcast路由器组的一部分来实现的。
4) Normally Xcast packets are only visible to Xcast routers. However, if a non-Xcast router receives an Xcast packet by accident (or by criminal intent), it will not send ICMP errors since the Xcast packet carries a multicast address in the destination address field [1812].
4) 通常，Xcast数据包仅对Xcast路由器可见。但是，如果非Xcast路由器意外（或出于犯罪目的）接收到Xcast数据包，它将不会发送ICMP错误，因为Xcast数据包在目的地址字段中带有多播地址[1812]。
Note that some benefits only hold when the multicast address stays in the destination field until it reaches the end-node (thus not combinable with X2U).
请注意，只有当多播地址停留在目的地字段中，直到到达结束节点（因此不能与X2U组合）时，一些好处才起作用。
[AGUI] and [1770] proposed (for a slightly different purpose) to carry multiple destinations in the IPv4 option. But because of the limited flexibility (limited size of the header), Xcast will follow another approach. The list of destinations will be encoded in a separate header. The Xcast header for IPv4 (in short, Xcast4) would be carried between the IPv4 header and the transport-layer header.
[AGUI]和[1770]建议（出于稍微不同的目的）在IPv4选项中承载多个目的地。但由于灵活性有限（标头的大小有限），Xcast将采用另一种方法。目的地列表将编码在单独的标题中。IPv4的Xcast报头（简而言之，Xcast4）将在IPv4报头和传输层报头之间传输。
[IPv4 header | Xcast4 | transport header | payload ]
[IPv4标头| Xcast4 |传输标头|有效负载]
Note also that since the Xcast header is added to the data portion of the packet, if the sender wishes to avoid IP fragmentation, it must take the size of the Xcast header into account.
还请注意，由于Xcast报头添加到数据包的数据部分，因此如果发送方希望避免IP碎片，则必须考虑Xcast报头的大小。
The Xcast4 header is carried on top of an IP header. The IP header will carry the protocol number listed as usable for experimental purposes in RFC 4727 [4727]. See also Section 15. The source address field contains the address of the Xcast sender. The destination address field carries the All_Xcast_Routers address.
Xcast4报头位于IP报头的顶部。IP报头将携带RFC 4727[4727]中列出的可用于实验目的的协议编号。另见第15节。源地址字段包含Xcast发送方的地址。destination address（目标地址）字段包含All_Xcast_路由器地址。
The Xcast4 header is format depicted in Figure 4. It is composed of two parts: a fixed part (first 12 octets) and two variable-length parts that are specified by the fixed part.
Xcast4头的格式如图4所示。它由两部分组成：一个固定部分（前12个八位字节）和由固定部分指定的两个可变长度部分。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROT ID | LENGTH | RESV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROT ID | LENGTH | RESV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
图4
VERSION = Xcast version number. This document describes version 1.
版本=Xcast版本号。本文档介绍版本1。
A = Anonymity bit: if this bit is set, the destination addresses for which the corresponding bit in the bitmap is zero must be overwritten by zero.
A=匿名位：如果设置了该位，位图中对应位为零的目标地址必须被零覆盖。
X = Xcast bit: if this bit is set, a router must not reduce the Xcast packet to unicast packet(s), i.e., the packet must stay an Xcast packet end-to-end. This bit can be useful when IPsec [4301] is applied. If this bit is cleared a router should apply X2U if there is only one destination left in the Xcast packet. In some cases a router could decide not to apply X2U to a packet with the Xcast bit cleared, e.g., the router has no directly connected hosts and wants to avoid the extra processing required by X2U.
X=Xcast位：如果设置了该位，路由器不得将Xcast数据包减少为单播数据包，即数据包必须保持Xcast数据包端到端。当应用IPsec[4301]时，此位可能很有用。如果此位被清除，则如果Xcast数据包中只剩下一个目的地，路由器应应用X2U。在某些情况下，路由器可能决定不将X2U应用于Xcast位已清除的数据包，例如，路由器没有直接连接的主机，并且希望避免X2U所需的额外处理。
D = DSCP bit: if this bit is set, the packet will contain a DS byte for each destination.
D=DSCP位：如果设置了该位，则数据包将包含每个目的地的DS字节。
P = Port bit: if this bit is set, the packet will contain a port number for each destination.
P=端口位：如果设置了该位，则数据包将包含每个目的地的端口号。
NBR_OF_DEST = the number of original destinations.
NBR\u OF\u DEST=原始目的地的数量。
CHECKSUM = A checksum on the Xcast header only. This is verified and recomputed at each point that the Xcast header is processed. The checksum field is the 16-bit one's complement of the one's complement sum of all the bytes in the header. For purposes of computing the checksum, the value of the checksum field is zero. It is not clear yet whether a checksum is needed (for further study). If only one destination is wrong it can still be useful to forward the packet to N-1 correct destinations and 1 incorrect destination.
校验和=仅在Xcast头上的校验和。在处理Xcast报头的每个点上都会验证并重新计算。校验和字段是报头中所有字节的补码和的16位1的补码。为了计算校验和，校验和字段的值为零。目前尚不清楚是否需要校验和（用于进一步研究）。如果只有一个目的地出错，将数据包转发到N-1个正确的目的地和1个错误的目的地仍然是有用的。
CHANNEL IDENTIFIER = 4-octet Channel Identifier (see Section 8.3). Since it is located within the first 8 bytes of the header, it will be returned in ICMP messages.
信道标识符=4-八位字节信道标识符（见第8.3节）。由于它位于报头的前8个字节内，因此将在ICMP消息中返回。
PROT ID = specifies the protocol of the following header.
PROT ID=指定以下标头的协议。
LENGTH = length of the Xcast header in 4-octet words. This field puts an upper boundary to the number of destinations. This value is also determined by the NBR_OF_DEST field and the D and P bits.
长度=Xcast头的长度（4个八位字节）。此字段为目的地的数量设置上限。该值还由目的字段的NBR_以及D和P位确定。
RESV = R = Reserved. It must be zero on transmission and must be ignored on receipt.
RESV=R=Reserved。传输时必须为零，接收时必须忽略。
The first variable part is the 'List of Addresses and DSCPs', the second variable part is the 'List of Port Numbers'. Both are 4-octet aligned. The second variable part is only present if the P-bit is set.
第一个变量部分是“地址和DSCP列表”，第二个变量部分是“端口号列表”。两者都是4-八位组对齐的。第二个变量部分仅在设置P位时出现。
Figure 5 gives an example of the variable part for the case that the P-bit is set and the D-bit is cleared (in this example, N is odd):
图5给出了设置P位和清除D位情况下的可变部分示例（在本例中，N为奇数）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BITMAP |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 1 | Port 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BITMAP |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 1 | Port 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
图5
BITMAP = every destination has a corresponding bit in the bitmap to indicate whether the destination is still valid on this branch of the tree. The first bit corresponds to the first destination in the list. This field is 4-octet aligned (e.g., for 49 destinations, there will be a 64-bit bitmap). If Xcast is applied in combination with IPsec, the bitmap -- since it can change en route -- has to be moved to a new to-be-defined IPv4 option.
位图=每个目标在位图中都有一个对应的位，用于指示目标在树的此分支上是否仍然有效。第一位对应于列表中的第一个目的地。该字段是4位八位组对齐的（例如，对于49个目的地，将有一个64位位图）。如果Xcast与IPsec结合使用，则位图（因为它可以在路由中更改）必须移动到新的待定义IPv4选项。
List of Destinations. Each address size is 4 octets.
目的地清单。每个地址大小为4个八位字节。
List of Port Numbers. List of 2-octet destination port number(s), where each port corresponds in placement to the preceding Destination Address.
端口号列表。2个八位字节的目标端口号列表，其中每个端口的位置对应于前面的目标地址。
The Xcast6 header encoding is similar to IPv4, except that Xcast information would be stored in IPv6 extension headers.
Xcast6报头编码与IPv4相似，只是Xcast信息将存储在IPv6扩展报头中。
[IPv6 header | Xcast6 | transport header | payload ]
[IPv6标头| Xcast6 |传输标头|有效负载]
The IPv6 header will carry the NextHeader value 'Routing Extension'. The source address field contains the address of the Xcast sender. The destination address field carries the All_Xcast_Routers address.
IPv6报头将携带下一个订单值“路由扩展”。源地址字段包含Xcast发送方的地址。destination address（目标地址）字段包含All_Xcast_路由器地址。
The Xcast6 header is also composed of a fixed part and two variable parts. The fixed part and the first variable part are carried in a Routing Extension. The second variable part is carried in a Destination Extension.
Xcast6标头还由一个固定部分和两个可变部分组成。固定部件和第一个可变部件携带在路由扩展中。第二个可变部分携带在目的地扩展中。
The P-bit of Xcast4 is not present because it is implicit by the presence or absence of the Destination Extension (Figure 6).
Xcast4的P位不存在，因为它是由目标扩展的存在或不存在所隐含的（图6）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |RouteType=Xcast| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |RouteType=Xcast| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
图6
HdrExtLen = The header length is expressed in 8-octets; thus, a maximum of 127 destinations can be listed (this is why NBR_OF_DEST is 7 bits).
HdrExtLen=报头长度以8个八位字节表示；因此，最多可以列出127个目的地（这就是为什么目的地的NBR_为7位）。
RouteType = Xcast (see Section 15)
RouteType=Xcast（见第15节）
The fourth octet is set to 0.
第四个八位字节设置为0。
R = Reserved.
R=保留。
CHANNEL IDENTIFIER = 16-octet Channel Identifier (see Section 8.3).
信道标识符=16个八位组信道标识符（见第8.3节）。
The other fields are defined in Section 9.2.2.
第9.2.2节定义了其他字段。
The 'List of Addresses and DSCPs' is 8-octet aligned. The size of the bitmap is determined by the number of destinations and is a multiple of 64 bits.
“地址和DSCP列表”是8位八位组对齐的。位图的大小由目标数量决定，是64位的倍数。
Optionally, the Destination Extension (Figure 7) is present to specify the list of Port Numbers. The destination header is only evaluated by the destination node.
或者，存在目标扩展（图7）来指定端口号列表。目标标头仅由目标节点计算。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
图7
For the Option Type for Ports, see Section 15. The first three bits must be 010 to indicate that the packet must be discarded if the option is unknown and that the option cannot be changed en-route.
有关端口的选项类型，请参见第15节。前三位必须为010，以指示如果选项未知且无法在路由中更改该选项，则必须丢弃该数据包。
The number of Ports must be equal to the number of destinations specified in the Routing header.
端口数必须等于路由标头中指定的目标数。
Some fields in the Xcast header(s) can be modified as the packet travels along its delivery path. This has an impact on:
当数据包沿着其传送路径传送时，可以修改Xcast报头中的某些字段。这会对以下方面产生影响：
In transport-layer headers, the target of the checksum calculation includes the IP pseudo header, transport header, and payload (IPv6 header extensions are not a target).
在传输层标头中，校验和计算的目标包括IP伪标头、传输标头和有效负载（IPv6标头扩展不是目标）。
The transformation of an Xcast packet to a normal unicast packet -- (premature) X2U -- replaces the multicast address in the IP header destination field by the address of a final destination. If the Xcast header contains a Port List, the port number in the transport layer (which should be zero) also needs to be replaced by the port number corresponding to the destination. This requires a recalculation of these checksums. Note that this does not require a complete recalculation of the checksum, only a delta calculation, e.g., for IPv4:
将Xcast数据包转换为普通单播数据包--（过早）X2U--将IP报头目的地字段中的多播地址替换为最终目的地的地址。如果Xcast头包含端口列表，则传输层中的端口号（应为零）也需要替换为与目标对应的端口号。这需要重新计算这些校验和。请注意，这不需要完全重新计算校验和，只需要增量计算，例如，对于IPv4：
Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp')
Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp')
In which "'" indicates the new values, "da" the destination address, "dp" the destination port, and "H" and "L" the higher and lower 16 bits, respectively.
其中“'”表示新值，“da”表示目标地址，“dp”表示目标端口，“H”和“L”分别表示高16位和低16位。
This is described in [PARI].
这在[PARI]中进行了描述。
One way to deploy Xcast in a network that has routers that have no knowledge of Xcast is to setup "tunnels" between Xcast peers (MBone approach [MBONE]). This enables the creation of a virtual network layered on top of an existing network [2003]. The Xcast routers exchange and maintain Xcast routing information via any standard unicast routing protocol (e.g., RIP, OSPF, IS-IS, BGP). The Xcast routing table that is created is simply a standard unicast routing table that contains the destinations that have Xcast connectivity, along with their corresponding Xcast next hops. In this way, packets may be forwarded hop-by-hop to other Xcast routers, or may be "tunneled" through non- Xcast routers in the network.
在路由器不知道Xcast的网络中部署Xcast的一种方法是在Xcast对等点之间建立“隧道”（MBone方法[MBone]）。这使得能够在现有网络的基础上创建分层的虚拟网络[2003]。Xcast路由器通过任何标准单播路由协议（例如RIP、OSPF、IS-IS、BGP）交换和维护Xcast路由信息。创建的Xcast路由表只是一个标准的单播路由表，其中包含具有Xcast连接的目的地及其相应的Xcast下一个跃点。以这种方式，分组可以逐跳转发到其他Xcast路由器，或者可以通过网络中的非Xcast路由器“隧道化”。
For example, suppose that A is trying to get packets distributed to B, C, and D in Figure 8 below, where "X" routers are Xcast-capable, and "R" routers are not. Figure 9 shows the routing tables created via the Xcast tunnels:
例如，假设A试图将数据包分发到下图8中的B、C和D，其中“X”路由器支持Xcast，而“R”路由器不支持Xcast。图9显示了通过Xcast隧道创建的路由表：
R4 ---- B
/
/
A ----- X1 ---- R2 ---- X3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- X7
\
\
R9 ---- D
R4 ---- B
/
/
A ----- X1 ---- R2 ---- X3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- X7
\
\
R9 ---- D
Figure 8
图8
Router X1 establishes a tunnel to Xcast peer X3. Router X3 establishes a tunnel to Xcast peers X1 and X7. Router X7 establishes a tunnel to Xcast peer X3.
路由器X1建立到Xcast对等方X3的隧道。路由器X3建立到Xcast对等点X1和X7的隧道。路由器X7建立到Xcast对等方X3的隧道。
X1 routing table: X3 routing table: X7 routing table:
Dest | NextHop Dest | NextHop Dest | NextHop
------+---------- ------+--------- ------+---------
B | X3 A | X1 A | X3
C | X3 C | X7 B | X3
D | X3 D | X7
X1 routing table: X3 routing table: X7 routing table:
Dest | NextHop Dest | NextHop Dest | NextHop
------+---------- ------+--------- ------+---------
B | X3 A | X1 A | X3
C | X3 C | X7 B | X3
D | X3 D | X7
Figure 9
图9
The source A will send an Xcast packet to its default Xcast router, X1, that includes the list of destinations for the packet. The packet on the link between X1 and X3 is depicted in Figure 10:
源A将向其默认的Xcast路由器X1发送一个Xcast数据包，其中包括该数据包的目的地列表。X1和X3之间链路上的数据包如图10所示：
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| B,C,D |
| prot=UDP |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| outer IP |
| src=X1 |
| dst=X3 |
| prot=IP |
+----------+
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| B,C,D |
| prot=UDP |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| outer IP |
| src=X1 |
| dst=X3 |
| prot=IP |
+----------+
Figure 10
图10
When X3 receives this packet, it processes it as follows:
当X3收到此数据包时，它将按如下方式处理：
- Perform a route table lookup in the Xcast routing table to determine the Xcast next hop for each of the destinations listed in the packet.
- 在Xcast路由表中执行路由表查找，以确定数据包中列出的每个目的地的Xcast下一跳。
- If no Xcast next hop is found, replicate the packet and send a standard unicast to the destination.
- 如果未找到Xcast下一跳，则复制数据包并向目标发送标准单播。
- For those destinations for which an Xcast next hop is found, partition the destinations based on their next hops.
- 对于那些找到Xcast下一跳的目的地，根据其下一跳对目的地进行分区。
- Replicate the packet so that there's one copy of the packet for each of the Xcast next hops found in the previous steps.
- 复制数据包，以便在前面的步骤中找到的每个Xcast下一个跃点都有一个数据包副本。
- Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop.
- 修改每个副本中的目的地列表，以便给定下一跳的副本中的列表仅包括应该通过该下一跳路由的目的地。
- Send the modified copies of the packet on to the next hops.
- 将数据包的修改副本发送到下一个跃点。
- Optimization: If there is only one destination for a particular Xcast next hop, send the packet as a standard unicast packet to the destination, since there is no advantage to forwarding it as an Xcast packet.
- 优化：如果某个特定的Xcast下一跳只有一个目的地，则将数据包作为标准单播数据包发送到目的地，因为将其作为Xcast数据包转发没有任何好处。
So, in the example above, X1 will send a single packet on to X3 with a destination list of < B C D >. This packet will be received by R2 as a unicast packet with destination X3, and R2 will forward it on, having no knowledge of Xcast. When X3 receives the packet, it will, by the algorithm above, send one copy of the packet to destination < B > as an ordinary unicast packet, and 1 copy of the packet to X7 with a destination list of < C D >. R4, R5, and R6 will behave as standard routers with no knowledge of Xcast. When X7 receives the packet, it will parse the packet and transmit ordinary unicast packets addressed to < C > and < D >, respectively.
因此，在上面的示例中，X1将向X3发送一个目的地列表为<bcd>的数据包。R2将接收该数据包作为目标为X3的单播数据包，R2将在不知道Xcast的情况下转发该数据包。当X3接收到数据包时，它将通过上述算法将数据包的一个副本作为普通单播数据包发送到目的地<B>，并将数据包的一个副本发送到目的地列表为<cd>的X7。R4、R5和R6将作为标准路由器运行，而不了解Xcast。当X7接收到数据包时，它将解析数据包，并分别向<C>和<D>发送普通单播数据包。
The updating of this route table, while simple in an intra-domain environment, would be more complex in an inter-domain environment. Thus, the use of tunneling in an inter-domain environment requires further consideration.
该路由表的更新虽然在域内环境中很简单，但在域间环境中会更复杂。因此，在域间环境中使用隧道需要进一步考虑。
If a router discovers that its downstream neighbor is not Xcast capable, it can perform a Premature X2U, i.e., send a unicast packet for each destination in the Xcast header that has this neighbor as a next hop. Thus, duplication is done before the Xcast packet reached its actual branching point.
如果路由器发现其下游邻居不支持Xcast，它可以执行过早的X2U，即，为Xcast报头中的每个目的地发送单播数据包，该目的地将该邻居作为下一跳。因此，在Xcast数据包到达其实际分支点之前就完成了复制。
A mechanism (protocol/protocol extension) to discover the Xcast capability of a neighbor is for further study. Among others, one could think of an extension to a routing protocol to advertise Xcast capabilities, or one could send periodic 'Xcast pings' to its neighbors (send an Xcast packet that contains its own address as a destination and check whether the packet returns).
发现邻居的Xcast能力的机制（协议/协议扩展）有待进一步研究。除此之外，可以考虑对路由协议进行扩展，以公布Xcast功能，或者可以定期向其邻居发送“Xcast ping”（发送包含其自身地址的Xcast数据包作为目的地，并检查数据包是否返回）。
This is an optimization of tunneling in the sense that it does not require (manual) configuration of tunnels. It is enabled by adding a Hop-by-Hop Xcast6 header. An IPv6 packet can initiate/trigger additional processing in the on-route routers by using the IPv6 Hop-by-hop option.
这是一种隧道优化，因为它不需要（手动）配置隧道。它通过添加逐跳Xcast6头来启用。IPv6数据包可以使用IPv6逐跳选项在路由路由器中启动/触发附加处理。
The type of the Xcast6 Hop-by-hop option has a prefix '00' so that routers that cannot recognize Xcast6 can treat the Xcast6 datagram as a normal IPv6 datagram and forward it toward the destination in the IPv6 header.
Xcast6逐跳选项的类型具有前缀“00”，因此无法识别Xcast6的路由器可以将Xcast6数据报视为正常IPv6数据报，并将其转发到IPv6标头中的目标。
Packets will be delivered to all members if at least all participating hosts are upgraded.
如果至少升级了所有参与主机，则数据包将传递给所有成员。
When the source A sends an Xcast packet via semi-permeable tunneling to destinations B, C, and D, it will create the packet of Figure 11. One of the final destinations will be put in the destination address field of the outer IP header.
当源A通过半渗透隧道向目的地B、C和D发送Xcast数据包时，它将创建图11所示的数据包。最终目的地之一将放在外部IP报头的目的地地址字段中。
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| Xcast |
|SP-tunnel |
|Hop-by-hop|
+----------+
| outer IP |
| src=A |
| dst=B |
| prot=IP |
+----------+
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| Xcast |
|SP-tunnel |
|Hop-by-hop|
+----------+
| outer IP |
| src=A |
| dst=B |
| prot=IP |
+----------+
Figure 11
图11
Semi-permeable tunneling is a special tunneling technology that permits intermediate Xcast routers on a tunnel to check the destinations and branch if destinations have a different next hop.
半渗透隧道是一种特殊的隧道技术，允许隧道上的中间Xcast路由器检查目的地，并在目的地具有不同的下一跳时进行分支。
Note that with the introduction of an Xcast IPv4 option, this technique could also be applied in IPv4 networks.
请注意，随着Xcast IPv4选项的引入，这种技术也可以应用于IPv4网络。
A special method of deploying Xcast is possible by upgrading only the hosts. By applying tunneling (see Sections 11.1 and 11.3) with one of the final destinations as a tunnel endpoint, the Xcast packet will be delivered to all destinations when all the hosts are Xcast aware. Both normal and semi-permeable tunneling can be used.
部署Xcast的一种特殊方法是只升级主机。通过使用最终目的地之一作为隧道端点应用隧道（见第11.1和11.3节），当所有主机都知道Xcast时，Xcast数据包将被传送到所有目的地。正常和半透水隧洞均可使用。
If host B receives this packet, in the above example, it will notice the other destinations in the Xcast header. B will create a new Xcast packet and will send it to one of the remaining destinations.
在上面的示例中，如果主机B接收到该数据包，它将注意到Xcast报头中的其他目的地。B将创建一个新的Xcast数据包，并将其发送到剩余的目的地之一。
In the case of Xcast6 and semi-permeable tunneling, Xcast routers can be introduced in the network without the need of configuring tunnels.
在Xcast6和半渗透隧道的情况下，可以在网络中引入Xcast路由器，而无需配置隧道。
The disadvantages of this method are:
这种方法的缺点是：
- all hosts in the session need to be upgraded.
- 会话中的所有主机都需要升级。
- non-optimal routing.
- 非最优路由。
- anonymity issue: hosts can know the identity of other parties in the session (which is not a big issue in conferencing, but maybe for some other application).
- 匿名性问题：主机可以知道会话中其他方的身份（这在会议中不是一个大问题，但可能对于其他应用程序）。
- host has to perform network functions and needs an upstream link which has the same bandwidth as its downstream link.
- 主机必须执行网络功能，并且需要一个与其下游链路具有相同带宽的上游链路。
11.5. Using a Small Number of Xcast-Aware Routers to Provide Xcast in a Not-So-Small Network
11.5. 在一个不太小的网络中使用少量支持Xcast的路由器来提供Xcast
In this approach, an Xcast packet uses a special 32-bit unicast address in the destination field of the IP header. In the simplest version of this scheme, there might be only a single Xcast-aware router in a network. This Xcast-aware router looks like a "server" to the other routers and it is configured so that its IP address (or one of its IP addresses) corresponds to the "special" 32-bit address. Thus, when Xcast clients send Xcast packets, the non-Xcast-aware routers will route these packets to the Xcast-aware router and the Xcast-aware router can "explode" (X2U) them into an appropriate set of unicast packets. This allows clients anywhere in a network to use Xcast to overcome the problem of limited bandwidth in the "first mile" with a minimum number of Xcast-aware routers (i.e., 1).
在这种方法中，Xcast分组在IP报头的目的地字段中使用特殊的32位单播地址。在这个方案的最简单版本中，网络中可能只有一个支持Xcast的路由器。这个Xcast感知路由器对于其他路由器来说就像一个“服务器”，并且它被配置为其IP地址（或其中一个IP地址）对应于“特殊”32位地址。因此，当Xcast客户端发送Xcast分组时，非Xcast感知路由器将这些分组路由到Xcast感知路由器，并且Xcast感知路由器可以将它们“分解”（X2U）成一组适当的单播分组。这使得网络中任何地方的客户端都可以使用Xcast来克服“第一英里”中带宽有限的问题，同时使用最少数量的Xcast感知路由器（即1个）。
Another possibility is to deploy a few of these Xcast-aware routers at various points in the network and to configure each of these with the special 32-bit address. This provides redundancy, eliminating the single point of failure, and reduces the distance an Xcast packet needs to travel to reach an Xcast-aware router, reducing network latencies. In this case, the Xcast-aware routers appear to be a single server that is "multihomed" (i.e., connected to the network at more than one place) and the non-Xcast-aware routers will, via ordinary unicast routing, deliver packets that are addressed to this "multihomed virtual server" via the shortest available path.
另一种可能是在网络中的不同点部署一些支持Xcast的路由器，并使用特殊的32位地址配置每个路由器。这提供了冗余，消除了单点故障，并缩短了Xcast数据包到达支持Xcast的路由器所需的距离，从而减少了网络延迟。在这种情况下，支持Xcast的路由器似乎是“多址”（即，连接到多个位置的网络）的单个服务器，而不支持Xcast的路由器将通过普通单播路由，通过最短的可用路径将数据包发送到该“多址虚拟服务器”。
Note that this scheme of delivering packets to any host in a group is also known as an "anycast" and is described in more detail in RFCs [1546], [2526], and [3068]. Note too that RFC 1546 says:
注意，将分组传送到组中的任何主机的这种方案也称为“选播”，在RFCs[1546]、[2526]和[3068]中有更详细的描述。还请注意，RFC 1546指出：
The important observation is that multiple routes to an anycast address appear to a router as multiple routes to a unicast destination, and the router can use standard algorithms to choose the best route.
重要的观察结果是，到选播地址的多条路由在路由器看来是到单播目的地的多条路由，路由器可以使用标准算法选择最佳路由。
In the most simple use of Xcast, the final destinations of an Xcast packet receive an ordinary unicast UDP packet. This means that hosts can receive an Xcast packet with a standard, unmodified TCP/IP stack.
在最简单的Xcast使用中，Xcast数据包的最终目的地接收普通的单播UDP数据包。这意味着主机可以使用标准的、未修改的TCP/IP堆栈接收Xcast数据包。
Hosts can also transmit Xcast packets with a standard TCP/IP stack with a small Xcast library that sends Xcast packets on a raw socket. This has been used to implement Xcast-based applications on both Unix and Windows platforms without any kernel changes.
主机还可以使用标准TCP/IP堆栈传输Xcast数据包，该堆栈带有一个小的Xcast库，可以在原始套接字上发送Xcast数据包。这已用于在Unix和Windows平台上实现基于Xcast的应用程序，而无需任何内核更改。
Another possibility is to modify the sockets interface slightly. For example, one might add an "xcast_sendto" function that works like "sendto" but that uses a list of destination addresses in place of the single address that "sendto" uses.
另一种可能是稍微修改套接字接口。例如，可以添加一个“xcast_sendto”函数，该函数的工作方式类似于“sendto”，但它使用目标地址列表来代替“sendto”使用的单个地址。
Additional work is needed in several areas.
需要在几个领域开展额外的工作。
Additional details need to be specified. For example, in the IPv4 case, the format of the DSCPs option needs to be specified.
需要指定其他详细信息。例如，在IPv4情况下，需要指定DSCP选项的格式。
The size of the channel identifiers in IPv4 and IPv6 are different in this document. 32 bits might be sufficient for both IPv6 and IPv4.
本文档中IPv4和IPv6中通道标识符的大小不同。对于IPv6和IPv4，32位可能就足够了。
Several possible methods of incremental deployment are discussed in this document including tunneling, premature X2U, etc. Additional work is needed to determine the best means of incremental deployment for an intra-domain as well as an inter-domain deployment of Xcast. If tunneling is used, additional details need to be specified (e.g., tunneling format, use of tunnels in the inter-domain case).
本文档讨论了几种可能的增量部署方法，包括隧道、过早部署X2U等。需要进行额外的工作，以确定Xcast域内和域间增量部署的最佳方法。如果使用隧道，则需要指定其他细节（例如，隧道格式、域间情况下隧道的使用）。
DSCP usage needs some work. DSCPs may have to be rewritten as packets cross inter-domain boundaries.
DSCP的使用需要一些工作。当数据包跨越域间边界时，可能必须重写DSCP。
The usage of a different, carried protocol type for IPv4 may cause difficulty in traversing some firewall and NAT products.
IPv4使用不同的承载协议类型可能会导致穿越某些防火墙和NAT产品的困难。
Given that this is designed for small groups, it might make sense to simply mandate a fixed size for the bitmap.
考虑到这是为小团体设计的，因此简单地为位图指定一个固定大小可能是有意义的。
The list of destinations in Xcast is provided by an application layer that manages group membership as well as authorization if authorization is desired.
Xcast中的目的地列表由应用程序层提供，该应用程序层管理组成员资格以及需要授权时的授权。
Since a source has the list of destinations and can make changes to the list, it has more control over where its packets go than in traditional multicast and can prevent anonymous eavesdroppers from joining a multicast session, for example.
由于源具有目的地列表并且可以对列表进行更改，因此与传统多播相比，它可以更好地控制其数据包的去向，并且可以防止匿名窃听者加入多播会话。
Some forms of denial-of-service attack can use Xcast to increase their "effect". A smurf attack, for example, sends an ICMP Echo Request in which the source address in the packet is set to the address of the target of the attack so that the target will receive the ICMP echo reply. With Xcast, the ICMP Echo Request could be sent to a list of destinations that could cause each member of the list to send an Echo Reply to the target.
某些形式的拒绝服务攻击可以使用Xcast来增强其“效果”。例如，smurf攻击发送ICMP回送请求，其中数据包中的源地址设置为攻击目标的地址，以便目标接收ICMP回送回复。使用Xcast，ICMP回显请求可以发送到目的地列表，该列表可能导致列表中的每个成员向目标发送回显回复。
Measures have been taken in traditional multicast to avoid this kind of attack. A router or host can be configured so that it will not reply to ICMP requests addressed to a multicast address. The Reverse Path Forwarding check in traditional multicast architectures also helps limit these attacks. In Xcast, it can be difficult for a host to recognize that an ICMP request has been addressed to multiple destinations since the packet may be an ordinary unicast packet by the time it reaches the host. On the other hand, a router can detect Xcast packets that are used to send ICMP requests to multiple destinations and can be configured to drop those packets. Note, too, that since Xcast sends packets to a short list of destinations, the problem of sending attack packets to multiple destination is less of
传统的多播已经采取了一些措施来避免这种攻击。可以对路由器或主机进行配置，以使其不会回复发往多播地址的ICMP请求。传统多播架构中的反向路径转发检查也有助于限制这些攻击。在Xcast中，主机可能很难识别ICMP请求已被发送到多个目的地，因为数据包到达主机时可能是普通的单播数据包。另一方面，路由器可以检测用于向多个目的地发送ICMP请求的Xcast数据包，并且可以配置为丢弃这些数据包。还要注意的是，由于Xcast将数据包发送到一个简短的目的地列表，因此将攻击数据包发送到多个目的地的问题较少
a problem than in traditional multicast. Obviously, the use of IPsec to provide confidentiality and/or authentication can further diminish the risk of this type of attack.
这是一个比传统多播更大的问题。显然，使用IPsec提供机密性和/或身份验证可以进一步降低此类攻击的风险。
The problem of secure group communications has been addressed by the Multicast Security (MSEC) working group, which has defined an architecture for securing IP-multicast-based group communications [3740]. Many of the concepts discussed in the MSEC working group, such as managing group membership, identifying and authenticating group members, protecting the confidentiality and integrity of multicast traffic, and managing and securely distributing and refreshing keys, also apply to Xcast-based group communications. And many of the same mechanisms seem to apply. One significant difference between multicast and Xcast is the fact that the Xcast header (or at least a bitmap in the Xcast header) needs to change as an Xcast packet travels from a source to a destination. This affects the use of IPsec and suggests that at least the Xcast header bitmap must be in a "mutable" field. A complete solution for securing Xcast-based group communications addressing all the issues listed above will be the subject of additional work which will be discussed in one or more additional documents. We expect that this effort will build on the work that has already been done in the msec working group.
多播安全（MSEC）工作组已经解决了安全组通信的问题，该工作组定义了一种用于保护基于IP多播的组通信的体系结构[3740]。MSEC工作组中讨论的许多概念，如管理组成员资格、识别和验证组成员、保护多播通信的机密性和完整性、管理和安全分发及刷新密钥，也适用于基于Xcast的组通信。许多相同的机制似乎也适用。多播和Xcast之间的一个显著区别是，Xcast报头（或者至少是Xcast报头中的位图）需要随着Xcast数据包从源传输到目的地而改变。这会影响IPsec的使用，并建议至少Xcast头位图必须位于“可变”字段中。解决上述所有问题的基于Xcast的集团通信安全完整解决方案将是附加工作的主题，将在一个或多个附加文档中讨论。我们期望这一努力将建立在msec工作组已经完成的工作的基础上。
Experimentation with the Xcast protocol requires the use of protocol numbers maintained by IANA. For example, to implement XCAST6, implementations must agree on four protocol numbers:
实验Xcast协议需要使用IANA维护的协议编号。例如，要实现XCAST6，实现必须在四个协议编号上达成一致：
(1) Multicast Address for All_Xcast_Routers (2) Routing Type of IPv6 Routing Header (3) Option Type of IPv6 Destination Option Header (4) Option Type of IPv6 Hop-by-Hop Options Header
(1) 所有路由器的多播地址（2）IPv6路由头的路由类型（3）IPv6目标选项头的选项类型（4）IPv6逐跳选项头的选项类型
A protocol implementer may temporarily experiment with Xcast by using the values set aside for experimental use in RFC [4727]. An implementer must verify that no other experiment uses the same values on the Xcast testbed at the same time.
协议实现者可以通过使用RFC中为实验使用而预留的值来临时试验Xcast[4727]。实现者必须验证没有其他实验同时在Xcast测试床上使用相同的值。
A future revision of the Xcast specification published on the standards track is required before IANA can assign permanent registry entries for Xcast. Implementers should be aware that they will need to modify their implementations when such permanent allocations are made.
在IANA为Xcast分配永久注册表项之前，需要对标准轨道上发布的Xcast规范进行未来修订。实现者应该意识到，在进行此类永久性分配时，他们将需要修改其实现。
[1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[1546]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC 1546，1993年11月。
[2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC 3068，2001年6月。
[1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[1075]Waitzman，D.，Partridge，C.，和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[1770]Graff，C.，“发送方定向多目的地交付的IPv4选项”，RFC 1770，1995年3月。
[1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[1812]Baker，F.，Ed.“IP版本4路由器的要求”，RFC 1812，1995年6月。
[2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[2201] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[2201]Ballardie，A.，“基于核心的树（CBT）多播路由架构”，RFC 2201，1997年9月。
[2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[2902] Deering, S., Hares, S., Perkins, C., and R. Perlman, "Overview of the 1998 IAB Routing Workshop", RFC 2902, August 2000.
[2902]Deering，S.，Hares，S.，Perkins，C.，和R.Perlman，“1998年IAB路由研讨会概述”，RFC 2902，2000年8月。
[3261] 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.
[3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[4302]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC 4607，2006年8月。
[4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[AGUI] L. Aguilar, "Datagram Routing for Internet Multicasting", SIGCOMM '84, March 1984.
[AGUI]L.Aguilar，“互联网多播的数据报路由”，SIGCOMM'841984年3月。
[CHER] David R. Cheriton, Stephen E. Deering, "Host groups: a multicast extension for datagram internetworks", Proceedings of the ninth symposium on Data communications, p. 172-179, September 1985, Whistler Moutain, British Columbia, Canada.
[CHER]David R.Cheriton，Stephen E.Deering，“主机组：数据报互联网的多播扩展”，《第九届数据通信研讨会论文集》，第页。1985年9月172-179日，加拿大不列颠哥伦比亚省惠斯勒山。
[BOIV] Boivie, R. and N. Feldman, "Small Group Multicast", Work in Progress, February 2001.
[BOIV]Boivie，R.和N.Feldman，“小组多播”，正在进行的工作，2001年2月。
[DEER] S. Deering, "Multicast Routing in a datagram internetwork", PhD thesis, December 1991.
[DEER]S.Deering，“数据报网络中的多播路由”，博士论文，1991年12月。
[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei, "The Pim Architecture for Wide-area Multicast Routing", ACM Transactions on Networks, April 1996.
[DEE2]S.Deering，D.Estrin，D.Farinaci，V.Jacobson，C.Liu和L.Wei，“广域多播路由的Pim体系结构”，ACM网络事务，1996年4月。
[FARI] Farinacci, D., et al., "Multicast Source Discovery Protocol", Work in Progress, June 1998.
[FARI]Farinaci，D.等人，“多播源发现协议”，正在进行的工作，1998年6月。
[H323] ITU-T Recommendation H.323 (2000), Packet-Based Multimedia Communications Systems.
[H323]ITU-T建议H.323（2000），基于分组的多媒体通信系统。
[IMAI] Imai, Y., "Multiple Destination option on IPv6 (MDO6)", Work in Progress, September 2000,
[IMAI]IMAI，Y.，“IPv6上的多目标选项（MDO6）”，正在进行的工作，2000年9月，
[MBONE] Casner, S., "Frequently Asked Questions (FAQ) on the Multicast Backbone (MBONE)", <ftp://ftp.isi.edu/mbone/faq.txt>.
[MBONE]Casner，S.，“多播主干网（MBONE）上的常见问题（FAQ）”<ftp://ftp.isi.edu/mbone/faq.txt>.
[OOMS] Ooms, D., Livens, W., and O. Paridaens, "Connectionless Multicast", Work in Progress, April 2000.
[OOMS]OOMS，D.，Livens，W.，和O.Paridaens，“无连接多播”，正在进行的工作，2000年4月。
[PARI] Paridaens, O., Ooms, D., and B. Sales, "Security Framework for Explicit Multicast", Work in Progress, June 2002.
[PARI]Paridaens，O.，Ooms，D.，和B.销售，“显式多播的安全框架”，正在进行的工作，2002年6月。
[RMT] Reliable Multicast Transport Working Group web site, <http://www.ietf.org/html.charters/rmt-charter.html>, June 15, 1999.
[RMT]可靠多播传输工作组网站<http://www.ietf.org/html.charters/rmt-charter.html>，一九九九年六月十五日。
[SOLA] M. Sola, M. Ohta, T. Maeno, "Scalability of Internet Multicast Protocols", INET'98, <http://www.isoc.org/inet98/proceedings/6d/6d_3.htm>.
[SOLA]M.SOLA，M.Ohta，T.Maeno，“互联网多播协议的可扩展性”，INET'98<http://www.isoc.org/inet98/proceedings/6d/6d_3.htm>.
Olivier Paridaens Alcatel Network Strategy Group Fr. Wellesplein 1, 2018 Antwerpen, Belgium Phone: 32 3 2409320 EMail: Olivier.Paridaens@alcatel.be
Olivier Paridaens阿尔卡特网络战略集团Fr.Welleslein 2018年1月1日比利时安特卫普电话：32 3 2409320电子邮件：Olivier。Paridaens@alcatel.be
Eiichi Muramoto Matsushita Electric Industrial Co., Ltd. 4-12-4 Higashi-shinagawa, Shinagawa-ku Tokyo 140-8587, Japan Phone: +81-3-6710-2031 EMail: muramoto@xcast.jp
村本荣一松下电器实业有限公司4-12-4日本新川县东川县东京140-8587电话：+81-3-6710-2031电子邮件：muramoto@xcast.jp
Authors' Addresses
作者地址
Rick Boivie IBM T. J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 Phone: 914-784-3251 EMail: rhboivie@us.ibm.com
Rick Boivie IBM T.J.Watson研究中心纽约州霍桑市天际大道19号电话：914-784-3251电子邮件：rhboivie@us.ibm.com
Nancy Feldman IBM T. J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 EMail: nkfeldman@yahoo.com
Nancy Feldman IBM T.J.Watson研究中心，纽约州霍桑市天际大道19号，邮编10532电子邮件：nkfeldman@yahoo.com
Yuji Imai Fujitsu Laboratories Ltd. 1-1, Kamikodanaka 4-Chome, Nakahara-ku Kawasaki 211-8588, Japan Phone: +81-44-754-2628 Fax : +81-44-754-2793 EMail: ug@xcast.jp
Yuji Imai Fujitsu Laboratories Ltd.1-1，Kamikodanaka 4-Chome，Nakahara ku Kawasaki 211-8588，日本电话：+81-44-754-2628传真：+81-44-754-2793电子邮件：ug@xcast.jp
Wim Livens ESCAUX Krijtstraat 17, 2600 Berchem, Belgium EMail: wim@livens.net
Wim Livens ESCAUX Krijtstraat 172600 Berchem，比利时电子邮件：wim@livens.net
Dirk Ooms OneSparrow Belegstraat 13; 2018 Antwerp, Belgium EMail: dirk@onesparrow.com
德克是一只13岁的麻雀；2018年比利时安特卫普电子邮件：dirk@onesparrow.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.