Network Working Group D. Ooms
Request for Comments: 3353 Alcatel
Category: Informational B. Sales
Alcatel
W. Livens
Colt Telecom
A. Acharya
IBM
F. Griffoul
Ulticom
F. Ansari
Bell Labs
August 2002
Network Working Group D. Ooms
Request for Comments: 3353 Alcatel
Category: Informational B. Sales
Alcatel
W. Livens
Colt Telecom
A. Acharya
IBM
F. Griffoul
Ulticom
F. Ansari
Bell Labs
August 2002
Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment
多协议标签交换（MPLS）环境中的IP组播综述
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered.
本文档为MPLS环境中的IP多播部署提供了一个框架。综述了MPLS技术应用于IP组播时出现的问题。描述了MPLS环境下现有IP组播路由协议的优缺点，讨论了不同触发方法和标签分发模式之间的关系。列出了各种第2层（L2）技术的后果。同时考虑了点到点和多址网络。
Table of Contents
目录
1. Introduction ............................................. 3
2. Layer 2 Characteristics .................................. 4
3. Taxonomy of IP Multicast Routing Protocols
in the Context of MPLS ................................... 5
3.1. Aggregation .............................................. 5
3.2. Flood & Prune ............................................ 5
3.3. Source/Shared Trees ...................................... 6
3.4. Co-existence of Source and Shared Trees .................. 7
3.5. Uni/Bi-directional Shared Trees .......................... 10
3.6. Encapsulated Multicast Data .............................. 11
3.7. Loop-free-ness ........................................... 11
3.8. Mapping of Characteristics on Existing Protocols ......... 11
4. Mixed L2/L3 Forwarding in a Single Node .................. 12
5. Taxonomy of IP Multicast LSP Triggers .................... 14
5.1. Request Driven ........................................... 14
5.1.1. General .................................................. 14
5.1.2. Multicast Routing Messages ............................... 15
5.1.3. Resource Reservation Messages ............................ 15
5.2. Topology Driven .......................................... 16
5.3. Traffic Driven ........................................... 16
5.3.1. General .................................................. 16
5.3.2. An Implementation Example ................................ 17
5.4. Combinations of Triggers and Label Distribution Modes .... 18
6. Piggy-backing ............................................ 18
7. Explicit Routing ......................................... 20
8. QoS/CoS .................................................. 20
8.1. DiffServ ................................................. 20
8.2. IntServ and RSVP ......................................... 21
9. Multi-access Networks .................................... 21
10. More Issues .............................................. 22
10.1. TTL Field ................................................ 22
10.2. Independent vs. Ordered Label Distribution Control ....... 23
10.3. Conservative vs. Liberal Label Retention Mode ............ 24
10.4. Downstream vs. Upstream Label Allocation ................. 25
10.5. Explicit vs. Implicit Label Distribution ................. 25
11. Security Considerations .................................. 26
12. Acknowledgements ......................................... 26
Informative References........................................... 27
Authors' Addresses .............................................. 28
Full Copyright Statement ........................................ 30
1. Introduction ............................................. 3
2. Layer 2 Characteristics .................................. 4
3. Taxonomy of IP Multicast Routing Protocols
in the Context of MPLS ................................... 5
3.1. Aggregation .............................................. 5
3.2. Flood & Prune ............................................ 5
3.3. Source/Shared Trees ...................................... 6
3.4. Co-existence of Source and Shared Trees .................. 7
3.5. Uni/Bi-directional Shared Trees .......................... 10
3.6. Encapsulated Multicast Data .............................. 11
3.7. Loop-free-ness ........................................... 11
3.8. Mapping of Characteristics on Existing Protocols ......... 11
4. Mixed L2/L3 Forwarding in a Single Node .................. 12
5. Taxonomy of IP Multicast LSP Triggers .................... 14
5.1. Request Driven ........................................... 14
5.1.1. General .................................................. 14
5.1.2. Multicast Routing Messages ............................... 15
5.1.3. Resource Reservation Messages ............................ 15
5.2. Topology Driven .......................................... 16
5.3. Traffic Driven ........................................... 16
5.3.1. General .................................................. 16
5.3.2. An Implementation Example ................................ 17
5.4. Combinations of Triggers and Label Distribution Modes .... 18
6. Piggy-backing ............................................ 18
7. Explicit Routing ......................................... 20
8. QoS/CoS .................................................. 20
8.1. DiffServ ................................................. 20
8.2. IntServ and RSVP ......................................... 21
9. Multi-access Networks .................................... 21
10. More Issues .............................................. 22
10.1. TTL Field ................................................ 22
10.2. Independent vs. Ordered Label Distribution Control ....... 23
10.3. Conservative vs. Liberal Label Retention Mode ............ 24
10.4. Downstream vs. Upstream Label Allocation ................. 25
10.5. Explicit vs. Implicit Label Distribution ................. 25
11. Security Considerations .................................. 26
12. Acknowledgements ......................................... 26
Informative References........................................... 27
Authors' Addresses .............................................. 28
Full Copyright Statement ........................................ 30
Table of Abbreviations
缩略语表
ATM Asynchronous Transfer Node CBT Core Based Tree CoS Class of Service DLCI Data Link Connection Identifier DRrecv Designated Router of the receiver DRsend Designated Router of the sender DVMRP Distant Vector Multicast Routing Protocol FR Frame Relay IGMP Internet Group Management Protocol IP Internet Protocol L2 layer 2 (e.g. ATM, Frame Relay) L3 layer 3 (e.g. IP) LSP Label Switched Path LSR Label Switching Router LSRd Downstream LSR LSRu Upstream LSR MOSPF Multicast OSPF mp2mp multipoint-to-multipoint MRT Multicast Routing Table p2mp point-to-multipoint PIM-DM Protocol Independent Multicast-Dense Mode PIM-SM Protocol Independent Multicast-Sparse Mode QoS Quality of Service RP Rendezvous Point RPT-bit RP Tree bit [DEER] RSVP Resource reSerVation Protocol SPT-bit Shortest Path Tree [DEER] SSM Source Specific Multicast TCP Transmission Control Protocol UDP User Datagram Protocol VC Virtual Circuit VCI Virtual Circuit Identifier VP Virtual Path VPI Virtual Path Identifier
ATM异步传输节点基于CBT核心的树CoS服务类别DLCI数据链路连接标识符DRrecv接收方指定路由器DRsend发送方指定路由器DVMRP远程向量多播路由协议FR帧中继IGMP互联网组管理协议IP互联网协议L2层2（例如ATM、帧中继）L3第3层（例如IP）LSP标签交换路径LSR标签交换路由器LSRd下游LSR LSRu上游LSR MOSPF多播OSPF mp2mp多点到多点MRT多播路由表p2mp点到多点PIM-DM协议独立多播密集模式PIM-SM协议独立多播稀疏模式QoS服务质量RP会合点RPT位RP树位RSVP资源预留协议SPT位最短路径树SSM源特定多播TCP传输控制协议UDP用户数据报协议VC虚拟电路VCI虚拟电路标识符VP虚拟路径VPI虚拟路径标识符
In an MPLS cloud the routes are determined by a L3 routing protocol. These routes can then be mapped onto L2 paths to enhance network performance. Besides this, MPLS offers a vehicle for enhanced network services such as QoS/CoS, traffic engineering, etc.
在MPLS云中，路由由L3路由协议确定。然后可以将这些路由映射到L2路径，以提高网络性能。除此之外，MPLS还提供了增强网络服务的工具，如QoS/CoS、流量工程等。
Current unicast routing protocols generate a same (optimal) shortest path in steady state for a certain (source, destination) pair. Remark that unicast protocols can behave slightly different with regard to equal cost paths.
当前的单播路由协议在稳定状态下为特定（源、目标）对生成相同的（最优）最短路径。请注意，单播协议在相同成本路径下的行为可能略有不同。
For multicast, the optimal solution (minimum cost to interconnect N nodes) would impose a Steiner tree computation. Unfortunately, no multicast routing protocol today is able to maintain such an optimal tree. Different multicast protocols will therefore, in general, generate different trees.
对于多播，最佳解决方案（互连N个节点的最小成本）将采用Steiner树计算。不幸的是，目前没有一个多播路由协议能够保持这样的最优树。因此，不同的多播协议通常会生成不同的树。
The discussion is focused on intra-domain multicast routing protocols. Aspects of inter-domain routing are beyond the scope of this document.
讨论的重点是域内多播路由协议。域间路由方面超出了本文档的范围。
Although MPLS is multiprotocol both at L3 and at L2, in practice IP is the only considered L3 protocol. MPLS can run on top of several L2 technologies (PPP/Sonet, Ethernet, ATM, FR, ...).
虽然MPLS在L3和L2都是多协议的，但实际上IP是唯一考虑的L3协议。MPLS可以在几种L2技术（PPP/Sonet、以太网、ATM、FR等）之上运行。
When label switching is mapped on L2 switching capabilities (e.g. VPI/VCI is used as label), attention is mainly focused on the mapping to ATM [DAVI]. ATM offers high switching capacities and QoS awareness, but in the context of MPLS it poses several limitations which are described in [DAVI]. Similar considerations are made for Frame Relay on L2 in [CONT]. The limitations can be summarized as:
当标签交换映射到L2交换能力时（例如，VPI/VCI用作标签），注意力主要集中在映射到ATM[DAVI]上。ATM提供了高交换容量和QoS感知，但在MPLS环境中，它带来了[DAVI]中描述的一些限制。对于[CONT]中L2上的帧中继，也进行了类似的考虑。这些限制可以概括为：
- Limited Label Space: either the standardized or the implemented number of bits available for a label can be small (e.g. VPI/VCI space, DLCI space), limiting the number of LSPs that can be established.
- 有限的标签空间：标签可用的标准化或实现的位数可能很小（例如VPI/VCI空间、DLCI空间），从而限制可以建立的LSP数量。
- Merging: some L2 technologies or implementations of these technologies do not support multipoint-to-point and/or multipoint-to-multipoint 'connections', obstructing the merging of LSPs.
- 合并：某些L2技术或这些技术的实现不支持多点对点和/或多点对多点“连接”，从而阻碍LSP的合并。
- TTL: L2 technologies do not support a 'TTL-decrement' function.
- TTL:L2技术不支持“TTL递减”功能。
All three limitations can impact the implementation of multicast in MPLS as will be described in this document.
这三个限制都会影响MPLS中多播的实现，本文将对此进行描述。
When native MPLS is deployed the above limitations vanish. Moreover on PPP and Ethernet links the same label can be used at the same time for a unicast and a multicast LSP because different EtherTypes for MPLS unicast and multicast are defined [ROSE].
当部署本机MPLS时，上述限制消失了。此外，在PPP和以太网链路上，同一标签可同时用于单播和多播LSP，因为定义了MPLS单播和多播的不同以太网类型[ROSE]。
At the moment, an abundance of IP multicast routing protocols is being proposed and developed. All these protocols have different characteristics (scalability, computational complexity, latency, control message overhead, tree type, etc...). It is not the purpose of this document to give a complete taxonomy of IP multicast routing protocols, only their characteristics relevant to the MPLS technology will be addressed.
目前，大量的IP组播路由协议正在被提出和开发。所有这些协议都具有不同的特性（可伸缩性、计算复杂性、延迟、控制消息开销、树类型等）。本文档的目的不是给出IP多播路由协议的完整分类，只讨论它们与MPLS技术相关的特性。
The following characteristics are considered:
考虑了以下特征：
- Aggregation - Flood & Prune - Source/Shared trees - Co-existence of Source and Shared Trees - Uni/Bi-directional shared trees - Encapsulated multicast data - Loop-free-ness
- 聚合-泛洪和修剪-源/共享树-源和共享树共存-单向/双向共享树-封装的多播数据-无循环
The discussion of these characteristics will not lead to the selection of one superior multicast routing protocol. It is not impossible that different IP multicast routing protocols will be deployed in the Internet.
对这些特性的讨论不会导致选择一种更优的多播路由协议。在互联网上部署不同的IP多播路由协议并非不可能。
In unicast different destination addresses are aggregated to one entry in the routing table, yielding one FEC and one LSP.
在单播中，不同的目的地地址聚合到路由表中的一个条目，产生一个FEC和一个LSP。
The granularity of multicast streams is (*, G) for a shared tree and (S, G) for a source tree, S being the source address and G the multicast group address. Aggregation of multicast trees with different multicast 'destination' addresses on one LSP is a subject for further study.
多播流的粒度对于共享树为（*，G），对于源树为（S，G），S为源地址，G为多播组地址。在一个LSP上聚合具有不同多播“目的地”地址的多播树是一个有待进一步研究的课题。
To establish a multicast tree some IP multicast routing protocols (e.g. DVMRP, PIM-DM) flood the network with multicast data. The branches can then be pruned by nodes which do not want to receive the data of the specific multicast group. This process is repeated periodically.
To establish a multicast tree some IP multicast routing protocols (e.g. DVMRP, PIM-DM) flood the network with multicast data. The branches can then be pruned by nodes which do not want to receive the data of the specific multicast group. This process is repeated periodically.translate error, please retry
Flood & Prune multicast routing protocols have some characteristics which significantly differ from unicast routing protocols:
Flood&Prune多播路由协议具有一些与单播路由协议显著不同的特征：
a) Volatile. Due to the Flood & Prune nature of the protocol, very volatile tree structures are generated. Solutions to map a dynamic L3 p2mp tree to a L2 p2mp LSP need to be efficient in terms of signaling overhead and LSP setup time. The volatile L2 LSP will consume a lot of labels throughout the network, which is a disadvantage when label space is limited.
a) 不稳定的由于协议的泛洪和修剪特性，会生成非常不稳定的树结构。将动态L3 p2mp树映射到L2 p2mp LSP的解决方案需要在信令开销和LSP设置时间方面高效。易失性L2 LSP将在整个网络中消耗大量标签，这在标签空间有限时是一个缺点。
b) Traffic-driven. The router only creates state for a certain group when data arrives for that group. Routers also independently decide to remove state when an inactivity timer expires.
b) 交通驱动。当某个组的数据到达时，路由器仅为该组创建状态。当非活动计时器过期时，路由器也独立决定删除状态。
- Thus LSPs can not be pre-established as is usually done in unicast. To minimize the time between traffic arrival and LSP establishment a fast LSP setup method is favorable.
- 因此，lsp不能像通常在单播中那样预先建立。为了尽可能缩短流量到达和LSP建立之间的时间，有必要采用快速LSP建立方法。
- Since creation and deletion of a L3 route at each node is triggered by traffic, this suggests that the LSP associated with the route be setup and torn down in a traffic-driven manner as well.
- 由于每个节点上L3路由的创建和删除都是由流量触发的，因此这表明与路由相关联的LSP也应以流量驱动的方式设置和拆除。
- If an LSR does not support L3 forwarding this traffic-driven nature even requires that the upstream LSR takes the initiative to create an LSP (Upstream Unsolicited or Downstream on Demand label advertisement).
- 如果LSR不支持L3转发，这种流量驱动的特性甚至要求上游LSR主动创建LSP（上游未经请求或下游按需标签广告）。
IP multicast routing protocols create either source trees (S, G), i.e. a tree per source (S) and per multicast group (G), or shared trees (*, G), i.e. one tree per multicast group (Figure 1).
IP多播路由协议创建源树（S，G），即每个源和每个多播组（G）创建一棵树，或创建共享树（*，G），即每个多播组创建一棵树（图1）。
R1 R1 R1
S1 / / /
\ / / /
\ / / /
C---R2 S1---R2 S2---R2
/ \ \ \
/ \ \ \
S2 \ \ \
R3 R3 R3
R1 R1 R1
S1 / / /
\ / / /
\ / / /
C---R2 S1---R2 S2---R2
/ \ \ \
/ \ \ \
S2 \ \ \
R3 R3 R3
Figure 1. Shared tree and Source trees
图1。共享树和源树
The advantage of using shared trees, when label switching is applied, is that shared trees consume less labels than source trees (1 label per group versus 1 label per source and per group).
应用标签切换时，使用共享树的优点是，共享树比源树消耗更少的标签（每个组1个标签，而每个源和每个组1个标签）。
However, mapping a shared tree end-to-end on L2 implies setting up multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing mp2mp LSPs boils down to the merging problem discussed earlier.
然而，在L2上端到端映射共享树意味着设置多点到多点（mp2mp）LSP。实现mp2mp LSP的问题归结为前面讨论的合并问题。
Note that in practice shared trees are often only used to discover new sources of the group and a switchover to a source tree is made at very low bitrates.
注意，在实践中，共享树通常仅用于发现组的新源，并且以非常低的比特率切换到源树。
Some protocols support both source and shared trees (e.g. PIM-SM) and one router can maintain both (*, G) and (S, G) state for the same group G. Two cases of state co-existence are described below. Assume topologies with senders Si and receivers Ri. RP is the Rendezvous Point. Ni are LSRs. The numbers are the interface numbers, "Reg" is the Register interface. All IGMP and PIM Join/Prune messages are shown in the figures. It is also indicated whether the RPT-bit is set for the (S, G) state.
一些协议支持源树和共享树（例如PIM-SM），并且一个路由器可以维护同一组g的（*，g）和（S，g）状态。下面描述两种状态共存的情况。假设具有发送方Si和接收方Ri的拓扑。RP是会合点。Ni是LSR。编号为接口编号，“Reg”为寄存器接口。图中显示了所有IGMP和PIM加入/删除消息。还指示RPT位是否设置为（S，G）状态。
1) Figure 2 shows a switchover from shared to source tree. Assume that the shortest path from R1 to RP is via N1-N2-N5. N1, the Designated Router of receiver R1 (DRrecv), decides to initiate a source tree for source S1. After the arrival of data via the source tree in N2, N2 will send a prune to N5 for source S1. State co-existence occurs in the node where the overlap of shared and source tree starts (N2) and in the node where S1 does not need forwarding on the shared tree anymore (N5).
1) 图2显示了从共享树到源树的切换。假设从R1到RP的最短路径是通过N1-N2-N5。N1，接收器R1（DRrecv）的指定路由器，决定为源S1启动源树。数据通过N2中的源树到达后，N2将向N5发送源S1的剪枝。状态共存发生在共享树和源树重叠开始的节点（N2）和S1不再需要在共享树上转发的节点（N5）中。
PJ
IJ PJS PJS
-> 1 2 -> 1 2 -> 1 2
R1-----N1------N2------N3----S1
3| |3 IJ=Igmp Join
||PPS | PJ=Pim Join (*,G)
|vPJ | PJS=Pim Join (S1,G)
IJ PJ | PJ | PPS=Pim Prune (S1,G)
-> -> |3 -> |
R2-----N4------N5------RP----S2
1 2 1 2 1
PJ
IJ PJS PJS
-> 1 2 -> 1 2 -> 1 2
R1-----N1------N2------N3----S1
3| |3 IJ=Igmp Join
||PPS | PJ=Pim Join (*,G)
|vPJ | PJS=Pim Join (S1,G)
IJ PJ | PJ | PPS=Pim Prune (S1,G)
-> -> |3 -> |
R2-----N4------N5------RP----S2
1 2 1 2 1
Figure 2
图2
The multicast routing states created in the Multicast Routing Table (MRT) are:
在多播路由表（MRT）中创建的多播路由状态为：
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):2->1
in N2: (*,G):3->1
(S1,G):2->1
in N3: (S1,G):2->Reg,1
in N4: (*,G):2->1
in N5: (*,G):2->1,3
(S1,G)RPT-bit:2->1
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):2->1
in N2: (*,G):3->1
(S1,G):2->1
in N3: (S1,G):2->Reg,1
in N4: (*,G):2->1
in N5: (*,G):2->1,3
(S1,G)RPT-bit:2->1
2) Figure 3 shows that even without a switchover, state co-existence can occur. Multicast traffic from a sender will create (S, G) state in the Designated Router of the sender (DRsend; N3 in Figure 3 is the DRsend of S). Each node on a shared-tree has (*, G) state. Thus an on-tree DRsend has both (*, G) and (S, G) state. If the DRsend is on-tree it will also send a prune for S towards the RP, creating (S, G) state in all nodes until the first router which has a branch (N1 and N2 in Figure 3).
2) 图3显示，即使没有切换，状态也可能共存。来自发送方的多播通信将在发送方的指定路由器中创建（S，G）状态（DRsend；图3中的N3是S的DRsend）。共享树上的每个节点都有（*，G）状态。因此，树上DRsend同时具有（*，G）和（S，G）状态。如果DRsend在树上，它还将向RP发送S的剪枝，在所有节点中创建（S，G）状态，直到有分支的第一个路由器（图3中的N1和N2）。
S
PPS PPS |
PJ PJ PJ |2 PJ IJ
1 <- 1 3<- <- | <- <- PJ=Pim Join
RP------N1----N2----N3----N4----R1 IJ=Igmp Join
^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G)
PJ|| IJ
1| <-
N5----R2
2
Figure 3
S
PPS PPS |
PJ PJ PJ |2 PJ IJ
1 <- 1 3<- <- | <- <- PJ=Pim Join
RP------N1----N2----N3----N4----R1 IJ=Igmp Join
^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G)
PJ|| IJ
1| <-
N5----R2
2
Figure 3
The multicast routing states created in the MRT are:
在MRT中创建的多播路由状态为：
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):1->2,3
(S,G)RPT-bit:1->2
in N2: (*,G):1->2
(S,G)RPT-bit:1->none
in N3: (*,G):1->3
(S,G):2->Reg,3
in N4: (*,G):1->2
in N5: (*,G):1->2
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):1->2,3
(S,G)RPT-bit:1->2
in N2: (*,G):1->2
(S,G)RPT-bit:1->none
in N3: (*,G):1->3
(S,G):2->Reg,3
in N4: (*,G):1->2
in N5: (*,G):1->2
In the examples one can observe that two types of state co-existence occur:
在这些例子中，我们可以观察到两种状态共存：
1) (S, G) with RPT-bit not set (N2 in Figure 2, N3 in Figure 3). The (*, G) and (S, G) state have different incoming interfaces, but some common outgoing interfaces. It is possible that the traffic of S arrives on both the (*, G) and (S, G) interfaces. In normal L3 forwarding the (S, G)SPT-bit entry prohibits the forwarding of the traffic from S arriving on the (*, G) incoming interface. The traffic of S can only temporarily arrive on the incoming interfaces of both the (*, G) and (S, G) entries (until N5 in Figure 2 and N1 in Figure 3 have processed the prune messages). To avoid the temporary forwarding of duplicate packets L3 forwarding can be applied in this type of node. If one does not mind the temporary duplicate packets L2 forwarding can be applied. In this case the (*, G) and (S, G) streams have to be merged into the (*, G) LSP on their common outgoing interfaces.
1) （S，G）未设置RPT位（图2中为N2，图3中为N3）。（*，G）和（S，G）状态有不同的传入接口，但有一些通用的传出接口。S的通信量可能同时到达（*，G）和（S，G）接口。在正常L3转发中，（S，G）SPT位条目禁止转发到达（*，G）传入接口的流量。S的通信量只能临时到达（*，G）和（S，G）条目的传入接口（直到图2中的N5和图3中的N1处理完修剪消息）。为了避免重复数据包的临时转发，可以在这种类型的节点中应用L3转发。如果不介意，可以应用临时重复数据包L2转发。在这种情况下，（*，G）和（S，G）流必须在其公共输出接口上合并到（*，G）LSP中。
2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3). The (*, G) and (S, G) state have the same incoming interface. The (S, G) traffic must be extracted from the (*, G) stream. In MPLS this state co-existence can be handled in several ways. Four approaches to this problem will be described:
2) （S，G）带有RPT位集（图2中的N5，图3中的N1）。（*，G）和（S，G）状态具有相同的传入接口。必须从（*，G）流中提取（S，G）流量。在MPLS中，这种状态共存可以通过多种方式处理。将描述解决此问题的四种方法：
a) A first method to handle this state co-existence is to terminate the LSPs and forward all traffic of this group at L3. However a return to L3 can be avoided in case a (S, G) entry without an outgoing interface is added to the MRT (N2 in Figure 3). This entry will only receive traffic temporarily. In this particular case one could ignore the (S, G) state and maintain the existing (*, G) LSP, the disadvantage being duplicate traffic for a very short time.
a) 处理这种状态共存的第一种方法是终止lsp并在L3转发该组的所有通信量。但是，如果在MRT中添加了没有传出接口的（S，G）条目（图3中的N2），则可以避免返回L3。此条目将仅暂时接收流量。在这种特殊情况下，可以忽略（S，G）状态并保持现有（*，G）LSP，缺点是在很短的时间内重复通信量。
b) A second approach is to assign source specific labels on the nodes of the shared tree. Multiple labels will be associated with one (*, G) entry, corresponding to one label per active source. Since the nodes only know which sources are active when traffic from these sources arrives, the LSPs cannot be pre-established and a fast LSP setup method is favorable.
b) 第二种方法是在共享树的节点上指定特定于源的标签。多个标签将与一个（*，G）条目相关联，对应于每个活动源的一个标签。由于节点仅在来自这些源的流量到达时才知道哪些源处于活动状态，因此无法预先建立LSP，并且快速LSP设置方法是有利的。
c) A third way is that only source trees are labelswitched and that traffic on the shared tree is always forwarded at L3. This assumes that the shared tree is only used as a way for the receivers to find out who the sources are. By configuring a low bitrate switchover threshold, one can ensure that the receivers switchover to source trees very quickly.
c) 第三种方法是，只有源树是标签切换的，共享树上的流量总是在L3转发。这假设共享树仅用作接收者找出谁是源的一种方式。通过配置低比特率切换阈值，可以确保接收机快速切换到源树。
d) In the fourth approach, an LSR which has (S, G) RPT-bit state with a non-null oif, advertises a label for (S, G) to the upstream LSR and this label advertisement is then propagated by each upstream LSR towards the RP. In this way a dedicated LSP is created for (S, G) traffic from the RP to the LSR with the (S, G) RPT-bit state. In the latter LSR, the (S, G) LSP is merged onto the (*, G) LSP for the appropriate outgoing interfaces. This ensures that (S, G) packets traveling on the shared tree do not make it past any LSR which has pruned S.
d) 在第四种方法中，具有非空oif的（S，G）RPT比特状态的LSR向上游LSR播发（S，G）的标签，并且该标签播发随后由每个上游LSR向RP传播。以这种方式，为从RP到具有（S，G）RPT比特状态的LSR的（S，G）业务创建专用LSP。在后一个LSR中，（S，G）LSP被合并到（*，G）LSP中，用于适当的输出接口。这确保了在共享树上传输的（S，G）数据包不会通过任何修剪了S的LSR。
Bidirectional shared trees (e.g. CBT [BALL]) have the disadvantage of creating a lot of merging points (M) in the nodes (N) of the shared tree. Figure 4 shows these merging points resulting from 2 senders S1 and S2 on a bidirectional tree.
双向共享树（例如CBT[BALL]）具有在共享树的节点（N）中创建大量合并点（M）的缺点。图4显示了由双向树上的两个发送方S1和S2产生的这些合并点。
S1 S2
|| ||
v| <- <- <- <- |v
<- <- | -> -> -> -> | ->
----N----M----M----M----M----M----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
S1 S2
|| ||
v| <- <- <- <- |v
<- <- | -> -> -> -> | ->
----N----M----M----M----M----M----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
Figure 4. Multicast traffic flows from 2 senders on a bidirectional tree
图4。来自双向树上2个发送方的多播流量
In Figure 5 the same situation for unidirectional shared trees is depicted. In this case the data of the senders is tunneled towards the root node R, yielding only a single merging point, namely the root of the shared tree itself.
图5描述了单向共享树的相同情况。在这种情况下，发送方的数据通过隧道传输到根节点R，只产生一个合并点，即共享树本身的根。
S1
tunnel || S2
<----- v| tunnel ||
to R<------------------------- v|
-> -> | -> -> -> -> | ->
----N----N----N----N----N----N----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
S1
tunnel || S2
<----- v| tunnel ||
to R<------------------------- v|
-> -> | -> -> -> -> | ->
----N----N----N----N----N----N----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
Figure 5. Multicast traffic flows from 2 senders on a unidirectional tree
图5。来自单向树上2个发送方的多播流量
Sources of unidirectional shared trees and non-member sources of bidirectional shared trees encapsulate the data towards the root node. The data is then decapsulated in the root node. The encapsulation and decapsulation of multicast data are L3 processes.
单向共享树的源和双向共享树的非成员源将数据封装到根节点。然后，数据在根节点中被解除封装。多播数据的封装和解封是L3进程。
Thus in case of encapsulation/decapsulation a path can never be mapped onto an end-to-end LSP: the traffic can not be forwarded on L2 on the Register interface of the DRsend (encapsulation), nor can it cross the root (decapsulation) at L2.
因此，在封装/解除封装的情况下，路径永远不能映射到端到端LSP：通信量不能在DRsend（封装）的寄存器接口上的L2上转发，也不能在L2上跨越根（解除封装）。
Remarks:
评论：
1) If the LSR supports mixed L2/L3 forwarding (section 4), the (S, G) traffic in DRsend can still be forwarded at L2 on all outgoing interfaces other than the Register interface.
1) 如果LSR支持混合L2/L3转发（第4节），则DRsend中的（S，G）流量仍可在除寄存器接口以外的所有传出接口上的L2上转发。
2) The encapsulated traffic can also benefit from MPLS by label switching the tunnels.
2) 通过标签交换隧道，封装的流量也可以从MPLS中受益。
3) If the root node decides to join the source (to avoid encapsulation/decapsulation), an end-to-end (S, G) LSP can be constructed.
3) 如果根节点决定加入源节点（以避免封装/去封装），则可以构造端到端（S，G）LSP。
Multicast routing protocols which depend on a unicast routing protocol suffer from the same transient loops as the unicast protocols do, however the effect of loops will be much worse in the case of multicast. The reason being, each time a multicast packet goes around a loop, copies of the packet may be emitted from the loop if branches exist in the loop.
依赖于单播路由协议的多播路由协议与单播协议具有相同的瞬时环路，但是在多播的情况下，环路的效果会更差。原因是，每次多播数据包绕过一个循环时，如果循环中存在分支，则该数据包的副本可能会从循环中发出。
Currently loop detection is a configurable option in LDP and a decision on the mechanism for loop prevention is postponed.
目前，环路检测是LDP中的一个可配置选项，关于环路预防机制的决定被推迟。
The above characteristics are summarized in Table 1 for a non-exhaustive list of existing IP multicast routing protocols: DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM [HOLB], SM [PERL].
表1总结了现有IP多播路由协议的非详尽列表：DVMRP[PUSA]、MOSPF[MOY]、CBT[BALL]、PIM-DM[ADAM]、PIM-SM[DEER]、SSM[HOLB]、SM[PERL]。
+------------------+------+------+------+------+------+------+------+
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM |
+------------------+------+------+------+------+------+------+------+
|Aggregation |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+------+------+
|Flood & Prune |yes |no |no |yes |no |no |option|
+------------------+------+------+------+------+------+------+------+
|Tree Type |source|source|shared|source|both |source|shared|
+------------------+------+------+------+------+------+------+------+
|State Co-existence|no |no |no |no |yes |no |no |
+------------------+------+------+------+------+------+------+------+
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |
+------------------+------+------+------+------+------+------+------+
|Encapsulation |no |no |yes |no |yes |no |yes |
+------------------+------+------+------+------+------+------+------+
|Loop Free |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+------+------+
+------------------+------+------+------+------+------+------+------+
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM |
+------------------+------+------+------+------+------+------+------+
|Aggregation |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+------+------+
|Flood & Prune |yes |no |no |yes |no |no |option|
+------------------+------+------+------+------+------+------+------+
|Tree Type |source|source|shared|source|both |source|shared|
+------------------+------+------+------+------+------+------+------+
|State Co-existence|no |no |no |no |yes |no |no |
+------------------+------+------+------+------+------+------+------+
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |
+------------------+------+------+------+------+------+------+------+
|Encapsulation |no |no |yes |no |yes |no |yes |
+------------------+------+------+------+------+------+------+------+
|Loop Free |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+------+------+
Table 1. Taxonomy of IP Multicast Routing Protocols
表1。IP多播路由协议的分类
From Table 1 one can derive e.g. that DVMRP will consume a lot of labels when the Flood & Prune L3 tree is mapped onto a L2 tree. Furthermore since DVMRP uses source trees it experiences no merging problem when label switching is applied. The table can be interpreted in the same way for the other protocols.
从表1可以得出，例如，当Flood&Prune L3树映射到L2树时，DVMRP将消耗大量标签。此外，由于DVMRP使用源树，因此在应用标签切换时不会遇到合并问题。对于其他协议，可以用相同的方式解释该表。
Since unicast traffic has one incoming and one outgoing interface the traffic is either forwarded at L2 OR at L3 (Figure 6). Because multicast traffic can be forwarded to more than one outgoing interface one can consider the case that traffic to some branches is forwarded on L2 and to other branches on L3 (Figure 7).
由于单播通信有一个传入接口和一个传出接口，因此通信在L2或L3转发（图6）。因为多播业务可以被转发到一个以上的输出接口，所以可以考虑在L2上转发某些分支到L3上的其他分支的情况（图7）。
+--------+ +--------+
| L3 | | L3 |
| +>>+ | | |
| | | | | |
+--|--|--+ +--------+
| | | | | |
->-----+ +-----> ->------>>----->
| L2 | | L2 |
+--------+ +--------+
+--------+ +--------+
| L3 | | L3 |
| +>>+ | | |
| | | | | |
+--|--|--+ +--------+
| | | | | |
->-----+ +-----> ->------>>----->
| L2 | | L2 |
+--------+ +--------+
Figure 6. Unicast forwarding on resp. L3 or L2
图6。在resp上的单播转发。L3或L2
+--------+ +--------+ +--------+
| L3 | | L3 | | L3 |
| +>>++ | | +>>+ | | |
| | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+
+--------+ +--------+ +--------+
| L3 | | L3 | | L3 |
| +>>++ | | +>>+ | | |
| | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+
Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2
图7。resp上的多播转发。L3，混合L2/L3或L2
Nodes that support this 'mixed L2/L3 forwarding' feature allow splitting of a multicast tree into branches in which some are forwarded at L3 while others are switched at L2.
支持此“二级/三级混合转发”功能的节点允许将多播树拆分为分支，其中一些在三级转发，而另一些在二级交换。
The L3 forwarding has to take care that the traffic is not forwarded on those branches that already get their traffic on L2. This can be accomplished by e.g. providing an extra bit in the Multicast Routing Table.
L3转发必须注意，流量不会在已经在L2上获得流量的分支上转发。这可以通过例如在多播路由表中提供额外比特来实现。
Although the mixed L2/L3 forwarding requires processing of the traffic at L3, the load on the L3 forwarding engine is generally less than in a pure L3 node.
尽管混合二级/三级转发需要在三级处理流量，但三级转发引擎上的负载通常比纯三级节点中的负载小。
Supporting this 'mixed L2/L3 forwarding' feature has the following advantages:
支持这种“二级/三级混合转发”功能具有以下优点：
a) Assume LSR A (Figure 8) is an MPLS edge node for the branch towards LSR B and an MPLS core node for the branch towards LSR C. The mixed L2/L3 forwarding allows that the branch towards C is not disturbed by a return to L3 in LSR A.
a) 假设LSR A（图8）是朝向LSR B的分支的MPLS边缘节点，以及朝向LSR C的分支的MPLS核心节点。混合L2/L3转发允许朝向C的分支不受LSR A中返回L3的干扰。
+-------------+
| MPLS cloud |
| N |
| / \ |
| / \ |
| / \ |
| A N |
|/ \ \ |
| \ \ |
/| \ |
B | C |
| |
+-------------+
+-------------+
| MPLS cloud |
| N |
| / \ |
| / \ |
| / \ |
| A N |
|/ \ \ |
| \ \ |
/| \ |
B | C |
| |
+-------------+
Figure 8. Mixed L2/L3 forwarding in node A
图8。节点A中的混合二级/三级转发
b) Enables the use of the traffic driven trigger with the Downstream Unsolicited or Upstream on Demand label distribution mode, as explained in section 5.3.1.
b) 如第5.3.1节所述，允许在下游未经请求或上游按需标签分发模式下使用流量驱动触发器。
The creation of an LSP for multicast streams can be triggered by different events, which can be mapped on the well known categories of 'request driven', 'topology driven' and 'traffic driven'.
为多播流创建LSP可以由不同的事件触发，这些事件可以映射到众所周知的“请求驱动”、“拓扑驱动”和“流量驱动”类别。
a) Request driven: intercept the sending or receiving of control messages (e.g. multicast routing messages, resource reservation messages).
a) 请求驱动：拦截控制消息的发送或接收（例如，多播路由消息、资源保留消息）。
b) Topology driven: map the L3 tree, which is available in the Multicast Routing Table, to a L2 tree. The mapping is done even if there is no traffic.
b) 拓扑驱动：将L3树（在多播路由表中可用）映射到L2树。即使没有流量，也会进行映射。
c) Traffic driven: the L3 tree is mapped onto a L2 tree when data arrives on the tree.
c) 流量驱动：当数据到达树上时，L3树映射到L2树上。
The establishment of LSPs can be triggered by the interception of outgoing (requiring that the label is requested by the downstream LSR) or incoming (requiring that the label is requested by the upstream LSR) control messages. Figure 9 illustrates these two cases.
LSP的建立可以通过拦截传出（要求下游LSR请求标签）或传入（要求上游LSR请求标签）控制消息来触发。图9说明了这两种情况。
LSRu LSRd LSRu LSRd
-------+ +--- ---+ +-------
| control | | control |
<---*<-----message------- <-------message-------*----
| | | | | |
trigger| | | | | |trigger
| | bind | | bind | |
+--------or---------> <---------or----------+
| bind-request | | bind-request |
| | | |
| | | |
|----data----->| |-----data---->|
LSRu LSRd LSRu LSRd
-------+ +--- ---+ +-------
| control | | control |
<---*<-----message------- <-------message-------*----
| | | | | |
trigger| | | | | |trigger
| | bind | | bind | |
+--------or---------> <---------or----------+
| bind-request | | bind-request |
| | | |
| | | |
|----data----->| |-----data---->|
incoming outgoing
传入传出
Figure 9. Request driven trigger (interception of resp. incoming and outgoing control messages)
图9。请求驱动触发器（截获相应的传入和传出控制消息）
The downstream LSR (LSRd) sends a control message to the upstream LSR (LSRu). In the case that incoming control messages are intercepted and the MPLS module in LSRu decides to establish an LSP, it will send an LDP bind (Upstream Unsolicited mode) or an LDP bind request (Downstream on Demand mode) to LSRd.
下游LSR（LSRd）向上游LSR（LSRu）发送控制消息。在传入控制消息被截获且LSRu中的MPLS模块决定建立LSP的情况下，它将向LSRd发送LDP绑定（上游非请求模式）或LDP绑定请求（下游按需模式）。
Currently, for multicast, we can identify two important types of control messages: the multicast routing messages and the resource reservation messages.
目前，对于多播，我们可以识别两种重要的控制消息类型：多播路由消息和资源预留消息。
In principle, this mechanism can only be used by IP multicast routing protocols which use explicit signaling: e.g. the Join messages in PIM-SM or CBT. Remark that DVMRP and PIM-DM can be adapted to support this type of trigger [FARI], however, at the cost of modifying the IP multicast routing protocol itself!
原则上，该机制只能用于使用显式信令的IP多播路由协议：例如PIM-SM或CBT中的连接消息。请注意，DVMRP和PIM-DM可用于支持此类触发器[FARI]，但代价是修改IP多播路由协议本身！
IP multicast routing messages can create both hard states (e.g. CBT Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent periodically). The latter generates more control traffic for tree maintenance and thus requires more processing in the MPLS module.
IP多播路由消息可以创建硬状态（例如CBT连接+CBT连接确认）和软状态（例如定期发送PIM-SM连接）。后者为树维护生成更多的控制流量，因此需要在MPLS模块中进行更多处理。
Triggers based on the multicast routing protocol messages have the disadvantage that the 'routing calculations' performed by the multicast routing daemon to determine the Multicast Routing Table are repeated by the MPLS module. The former determines the tree that will be used at L3, the latter calculates an identical tree to be used by L2. Since the same task is performed twice, it is better to create the multicast LSP on the basis of information extracted from the Multicast Routing Table itself (see section 5.2 and 5.3). The routing calculations become more complex for protocols which support a switch-over from a (*, G) tree to a (S, G) tree because more messages have to be interpreted.
基于多播路由协议消息的触发器的缺点是，多播路由守护进程为确定多播路由表而执行的“路由计算”由MPLS模块重复。前者确定将在L3使用的树，后者计算L2使用的相同树。由于同一任务执行两次，因此最好根据从多播路由表本身提取的信息创建多播LSP（参见第5.2和5.3节）。对于支持从（*，G）树切换到（S，G）树的协议，路由计算变得更加复杂，因为需要解释更多的消息。
When a host has a point-to-point connection to the first router one could create 'LSPs up to the end-user' by intercepting not only the multicast routing messages but the IGMP Join/Prune messages ([FENN]) as well.
当主机与第一个路由器有点对点连接时，可以通过拦截多播路由消息以及IGMP加入/删减消息（[FENN]）来创建“到最终用户的LSP”。
As is the case for unicast the RSVP Resv message can be used as a trigger to establish LSPs. A source of a multicast group will send an RSVP Path message down the tree, the receivers can then reply with an RSVP Resv message. RSVP scales equally well for multicast as it does for unicast because:
与单播一样，RSVP Resv消息可以用作建立LSP的触发器。多播组的源将沿树向下发送RSVP Path消息，然后接收者可以使用RSVP Resv消息进行回复。RSVP对多播的扩展能力与单播相同，因为：
a) RSVP Resv messages can merge.
a) RSVP Resv消息可以合并。
b) RSVP Resv messages are only sent up to the first branch which made the required reservation.
b) RSVP Resv消息只发送到进行所需预订的第一个分支。
The Multicast Routing Table (MRT) is maintained by the IP multicast routing protocol daemon. The MPLS module maps this L3 tree topology information to L2 p2mp LSPs.
多播路由表（MRT）由IP多播路由协议守护进程维护。MPLS模块将此L3树拓扑信息映射到L2 p2mp LSP。
The MPLS module can poll the MRT to extract the tree topologies. Alternatively, the multicast daemon can be modified to notify the MPLS module directly of any change to the MRT.
MPLS模块可以轮询MRT以提取树拓扑。或者，可以修改多播守护进程以直接通知MPLS模块对MRT的任何更改。
The disadvantage of this method is that labels are consumed even when no traffic exists.
这种方法的缺点是，即使不存在流量，也会消耗标签。
A traffic driven trigger method will only construct LSPs for trees which carry traffic. It consumes less labels than the topology driven method, as labels are only allocated when there is traffic on the multicast tree.
流量驱动的触发方法只能为承载流量的树构造LSP。它比拓扑驱动方法消耗更少的标签，因为标签仅在多播树上有流量时分配。
If the mixed L2/L3 forwarding capability (see section 4) is not supported, the traffic driven trigger requires a label distribution mode in which the label is requested by the LSRu (Downstream on Demand or Upstream Unsolicited mode). In Figure 10, suppose an LSP for a certain group exists to LSRd1 and another LSRd2 wants to join the tree. In order for LSRd2 to initiate a trigger, it must already receive the traffic from the tree. This can be either at L2 or at L3. The former case is a chicken and egg problem. The latter case requires a mixed L2/L3 forwarding capability in LSRu to add the L3 branch.
如果不支持L2/L3混合转发能力（参见第4节），则流量驱动触发器需要标签分发模式，其中LSRu请求标签（下游按需或上游非请求模式）。在图10中，假设LSRd1中存在某个组的LSP，而另一个LSRd2想要加入该树。为了让LSRd2启动触发器，它必须已经接收到来自树的流量。这可以是在L2或L3。前一种情况是鸡和蛋的问题。后一种情况需要LSRu中的混合L2/L3转发能力来添加L3分支。
+--------+
| LSRd1 |
| |
+--------+ | L3 |
| LSRu | +--------+
| | | |
| L3 | +-------------------------->
+--------+ / | L2 |
| | / +--------+
->-------------+
| L2 | +--------+
+--------+ | LSRd2 |
| |
| L3 |
+--------+
| |
| |
| L2 |
+--------+
+--------+
| LSRd1 |
| |
+--------+ | L3 |
| LSRu | +--------+
| | | |
| L3 | +-------------------------->
+--------+ / | L2 |
| | / +--------+
->-------------+
| L2 | +--------+
+--------+ | LSRd2 |
| |
| L3 |
+--------+
| |
| |
| L2 |
+--------+
Figure 10. The LSRu has to request the label.
图10。LSRu必须请求标签。
To illustrate that by choosing an appropriate trigger one can conclude that MPLS multicast is independent of the deployed multicast routing protocol, the following implementation example is given.
为了说明通过选择适当的触发器，可以得出MPLS多播独立于已部署的多播路由协议的结论，给出了以下实现示例。
Current implementations on Unix platforms of IP multicast routing protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The MFC is a cached copy of the Multicast Routing Table. The MFC requests an entry for a certain multicast group when it experiences a 'cache miss' for an incoming multicast packet. The missing routing information is provided by the multicast daemon. If at a later point in time something changes to the route (outgoing interfaces added or removed), the multicast daemon will update the MFC.
当前在Unix平台上实现的IP多播路由协议（DVMRP、PIM）具有多播转发缓存（MFC）。MFC是多播路由表的缓存副本。当MFC遇到传入多播数据包的“缓存未命中”时，它请求特定多播组的条目。丢失的路由信息由多播守护进程提供。如果在稍后某个时间点路由发生更改（添加或删除传出接口），多播守护进程将更新MFC。
The MFC is implemented as a common component (part of the kernel), which makes this trigger very attractive because it can be transparently used for any IP multicast routing protocol.
MFC被实现为一个公共组件（内核的一部分），这使得这个触发器非常有吸引力，因为它可以透明地用于任何IP多播路由协议。
Entries in the MFC are removed when no traffic is received for this entry for a certain period of time. When label switching is applied to a certain MFC-entry, the L3 will not see any packets arriving anymore. To retain the normal MFC behavior, the L3 counters of the MFC need to be updated by L2 measurements.
当某段时间内没有收到该条目的流量时，MFC中的条目将被删除。当标签切换应用于某个MFC条目时，L3将不再看到任何数据包到达。为了保持正常的MFC行为，需要通过L2测量更新MFC的L3计数器。
Table 2 shows the valid combinations of label distribution modes and trigger types that were discussed in the previous sections. The (X) means that the combination is valid when the mixed L2/L3 forwarding feature is supported in the LSR.
表2显示了前几节讨论的标签分发模式和触发器类型的有效组合。（X）表示当LSR中支持混合二级/三级转发功能时，组合有效。
+----------------+---------------------------------------------+
| | label requested by |
| | LSRu | LSRd |
| +----------------------+----------------------+
| | upstream |downstream|downstream |upstream |
| |unsolicited|on demand |unsolicited|on demand |
+----------------+-----------+----------+-----------+----------+
|Request Driven | | | | |
|(incoming msg) | X | X | | |
+----------------+-----------+----------+-----------+----------+
|Request Driven | | | | |
|(outgoing msg) | | | X | X |
+----------------+-----------+----------+-----------+----------+
|Topology Driven | X | X | X | X |
+----------------+-----------+----------+-----------+----------+
|Traffic Driven | X | X | (X) | (X) |
+----------------+-----------+----------+-----------+----------+
+----------------+---------------------------------------------+
| | label requested by |
| | LSRu | LSRd |
| +----------------------+----------------------+
| | upstream |downstream|downstream |upstream |
| |unsolicited|on demand |unsolicited|on demand |
+----------------+-----------+----------+-----------+----------+
|Request Driven | | | | |
|(incoming msg) | X | X | | |
+----------------+-----------+----------+-----------+----------+
|Request Driven | | | | |
|(outgoing msg) | | | X | X |
+----------------+-----------+----------+-----------+----------+
|Topology Driven | X | X | X | X |
+----------------+-----------+----------+-----------+----------+
|Traffic Driven | X | X | (X) | (X) |
+----------------+-----------+----------+-----------+----------+
Table 2. Valid combinations of triggers and label distribution modes
表2。触发器和标签分发模式的有效组合
In Figure 9 (outgoing case) one can observe that instead of sending 2 separate messages the label advertisement can be piggy-backed on the existing control messages. For multicast two piggy-back candidates exist:
在图9（传出的情况）中，我们可以观察到，标签广告不是发送两条单独的消息，而是可以依靠现有的控制消息。对于多播，存在两个背驮候选：
a) Multicast routing messages: protocols such as PIM-SM and CBT have explicit Join messages which could carry the label mappings. This approach is described in [FARI]. When different multicast routing protocols are deployed, an extension to each of these protocols has to be defined.
a) 多播路由消息：PIM-SM和CBT等协议具有显式连接消息，可以携带标签映射。[FARI]中描述了这种方法。当部署不同的多播路由协议时，必须定义每个协议的扩展。
b) RSVP Resv messages: a label mapping extension object for RSVP, also applicable to multicast, is proposed in [AWDU].
b) RSVP Resv消息：[AWDU]中提出了RSVP的标签映射扩展对象，也适用于多播。
The pros and cons of piggy-backing on multicast routing messages will be described now.
现在将描述在多播路由消息上背驮的优点和缺点。
Piggy-backing has following advantages:
背驮有以下优点：
a) If the label advertisement is piggy-backed on multicast routing messages, then the distribution of routes and the distribution of labels is tightly synchronized. This eliminates difficult corner cases such as "what do I do with a label if I don't (yet) have a routing table entry to attach it to?". It also minimizes the interval between the establishment of the multicast route and the mapping of a label to the route.
a) 如果标签广告依赖于多播路由消息，则路由的分发和标签的分发是紧密同步的。这就消除了一些棘手的情况，比如“如果我（还）没有一个路由表条目来附加标签，我该如何处理它？”。它还最小化了建立多播路由和将标签映射到路由之间的间隔。
b) The number of control messages needed to support label advertisement beyond those needed to support the multicast routing itself is zero.
b) 除了支持多播路由本身所需的控制消息之外，支持标签广告所需的控制消息数量为零。
Following disadvantages of piggy-backing can be identified:
可以确定清管的以下缺点：
a) In dense-mode protocols there are no messages on which the label advertisement can be piggy-backed. [FARI] proposes to add periodic messages to dense-mode protocols for the purpose of label advertisement, which is a heavy impact on the multicast routing protocol and it eliminates the message conserving benefit of piggy-backing.
a) 在密集模式协议中，没有标签广告可以依靠的消息。[FARI]建议将周期性消息添加到密集模式协议中，以用于标签广告，这对多播路由协议造成了严重影响，并且消除了背驮的消息保存优势。
b) The second solution for the state co-existence problem (section 3.4) cannot be applied in combination with piggy-backing.
b) 国家共存问题的第二种解决方案（第3.4节）不能与背驮结合使用。
c) Piggy-backing requires extending the multicast routing protocol, and hence becomes less attractive if label advertisement needs to be supported for multiple multicast routing protocols. Especially when not only the label advertisement but also the other two LDP functions (discovery and adjacency) are piggy-backed.
c) Piggy backing需要扩展多播路由协议，因此，如果需要为多个多播路由协议支持标签广告，那么它的吸引力就会降低。特别是当不仅标签广告，而且其他两个LDP功能（发现和邻接）都是背负的时候。
d) Piggy-backing assumes the Downstream Unsolicited label distribution mode, this excludes a number of trigger methods (see Table 2).
d) Piggy backing采用下游未经请求的标签分发模式，这不包括许多触发方法（见表2）。
e) LDP normally runs on top of TCP, assuring a reliable communication between peer nodes. Piggy-backed label advertisement often replaces the reliable communication with periodic soft-state label advertisements. Because of this periodic label advertisement the control traffic (in number of bytes) will increase.
e) LDP通常运行在TCP之上，确保对等节点之间的可靠通信。背驮式标签广告通常用周期性的软状态标签广告取代可靠的通信。由于这种定期标签广告，控制流量（字节数）将增加。
f) If a VCID notification mechanism [NAGA] is required, the (in-band) notification can normally be done by sending the LDP bind through the newly established VC. This way only one message is required. This method cannot be combined with piggy-backing because the routing message is sent before the VC can be established. An extra handshake message is thus required, diminishing the benefit of piggy-backing.
f) 如果需要VCID通知机制[NAGA]，通常可以通过新建立的VC发送LDP绑定来完成（带内）通知。这样，只需要一条消息。此方法不能与piggy backing结合使用，因为路由消息是在VC建立之前发送的。因此，需要额外的握手信息，减少了背驮的好处。
So whether piggy-backing makes sense or not depends heavily on which and how many multicast routing protocols are deployed, whether LDP is already used for unicast, which trigger mechanism is used, ... Piggy-backing is just one possible component of an MPLS multicast solution.
所以，背驮是否有意义很大程度上取决于部署了哪些和多少多播路由协议，LDP是否已经用于单播，使用了哪种触发机制。。。Piggy backing只是MPLS多播解决方案的一个可能组件。
Explicit routing for unicast refers to overriding the unicast routing table by using LSPs.
单播显式路由是指使用LSP覆盖单播路由表。
A first way to interpret "multicast explicit routing" is overriding the tree established by the multicast routing protocol by another LSP tree (e.g. a Steiner tree calculated by an off-line tool). In this interpretation the current 'shortest path' multicast routing protocol becomes obsolete and can be replaced by label advertisement messages that follow an explicit route (e.g. a branch of the Steiner tree).
解释“多播显式路由”的第一种方法是用另一个LSP树（例如，由离线工具计算的Steiner树）覆盖多播路由协议建立的树。在这种解释中，当前的“最短路径”多播路由协议变得过时，可以用遵循显式路由（例如Steiner树的分支）的标签广告消息来代替。
A second way of interpreting "multicast explicit routing" is that the known multicast routing protocols are running, but that the messages generated by these protocols use explicit unicast routes (instead of the IGP shortest path routes) to construct trees.
第二种解释“多播显式路由”的方法是，已知的多播路由协议正在运行，但这些协议生成的消息使用显式单播路由（而不是IGP最短路径路由）来构造树。
The Differentiated Services approach can be applied to multicast as well. It introduces finer stream granularities (DiffServ Codepoint (DSCP) as an extra differentiator). A sender can construct one or more trees with different DSCPs.
区分服务方法也可以应用于多播。它引入了更精细的流粒度（DiffServ Codepoint（DSCP）作为额外的区分因素）。发送方可以使用不同的DSCP构造一个或多个树。
These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily onto LSPs when the traffic driven trigger is used. In this case one can create LSPs with different attributes for the various DSCPs. Note however that these LSPs still use the same route as long as the tree construction mechanism itself does not take the DSCP as an input.
当使用流量驱动触发器时，这些（S，G，DSCP）或（*，G，DSCP）树可以非常容易地映射到LSP上。在这种情况下，可以为不同的DSCPs创建具有不同属性的LSP。但是请注意，只要树构造机制本身不将DSCP作为输入，这些LSP仍然使用相同的路由。
RSVP can be used to setup multicast trees with QoS. An important multicast issue is the problem of how to map the 'heterogeneous receivers' paradigm onto L2 (remark that it is not solved in IP either). This subject is tackled in [CRAW]. Pragmatic approaches are the 'Limited Heterogeneity Model' which allows a best effort service and a single alternate QoS (e.g. a QoS proposed by the sender in a RSVP Path message) and the 'Homogeneous Model' which allows only a single QoS.
RSVP可用于建立具有QoS的多播树。一个重要的多播问题是如何将“异构接收器”范例映射到L2上的问题（请注意，它也没有在IP中解决）。这个问题在[克拉]中讨论。实用的方法是“有限的异构模型”，它允许尽力而为的服务和单一的备用QoS（例如，发送方在RSVP路径消息中提出的QoS），以及“同构模型”，它只允许单一QoS。
The first approach will construct full trees for each service class. The sender has to send its traffic twice across the network (e.g. 1 best-effort and 1 QoS tree). Both trees can be label switched.
第一种方法将为每个服务类构建完整的树。发送方必须在网络上发送其流量两次（例如，1个最大努力和1个QoS树）。两棵树都可以进行标签切换。
The second approach constructs one tree and the best-effort users are connected to the QoS tree. If the branches created for best-effort users are not to be label switched, (thus carried by a hop-by-hop default LSP) the QoS multicast traffic has to be merged onto these default LSPs. This function can be provided by the 'mixed L2/L3 forwarding' feature described in section 4. If this is not available, merging is necessary to avoid a return to L3 in the QoS LSP.
第二种方法构造一棵树，并将尽力而为的用户连接到QoS树。如果为尽力而为用户创建的分支不进行标签交换（因此由逐跳默认LSP承载），则必须将QoS多播通信合并到这些默认LSP上。此功能可通过第4节中描述的“混合二级/三级转发”功能提供。如果这不可用，则需要合并以避免返回QoS LSP中的L3。
The mapping of the IntServ service categories onto L2 for ATM service categories is studied in [GARR].
[GARR]研究了ATM服务类别的IntServ服务类别到L2的映射。
Multicast MPLS on multi-access networks poses a special problem. An LSR that wants to join a group must always be ready to accept the label that is already assigned to the group LSP (to another downstream LSR on the link). This can be achieved in three ways:
多址网络上的多播MPLS带来了一个特殊的问题。想要加入组的LSR必须随时准备接受已分配给组LSP（链接上的另一个下游LSR）的标签。这可以通过三种方式实现：
1) Each LSR on the multi-access link memorizes all the advertised labels on the link, even if it has not received a join for the associated group. If an LSR is added to the multi-access link it has to retrieve this information from another LSR on the link or in case of soft state label advertisement it can wait a certain time before it can allocate labels itself. If LSRs allocate a label 'at the same moment' the LSR with the highest IP address could keep it, while the other LSRs withdraw the label.
1) 多址链路上的每个LSR存储链路上的所有播发标签，即使它没有收到关联组的加入。如果一个LSR被添加到多址链路，它必须从链路上的另一个LSR检索该信息，或者在软状态标签广告的情况下，它可以等待一段时间，然后才能自己分配标签。如果LSR“同时”分配标签，则具有最高IP地址的LSR可以保留该标签，而其他LSR则收回该标签。
2) Each LSR gets its own label range to allocate labels from. A mechanism for label partitioning is described in [FARI]. If an LSR is added to the multi-access link, the label ranges have to be negotiated again and possibly existing LSPs are torn down and are reconstructed with other labels.
2) 每个LSR都有自己的标签范围来分配标签。[FARI]中描述了标签分区的机制。如果将LSR添加到多址链路，则必须再次协商标签范围，并且可能会拆除现有LSP并使用其他标签重建。
3) Per multi-access link one LSR could be elected to be responsible for label allocation. When an LSR needs a label, it can request it from this Label Allocation LSR.
3) 每个多址链路可以选择一个LSR负责标签分配。当LSR需要标签时，它可以从此标签分配LSR请求标签。
Unlike the unicast case, a multicast stream can have more than one downstream LSR which all have to use the same label. Two solutions for label advertisement can be thought of:
与单播情况不同，多播流可以有多个下游LSR，它们都必须使用相同的标签。可以考虑两种标签广告解决方案：
1) [FARI] proposes to multicast the label advertisements to all LSRs on the shared link. Since multicast is not reliable this requires periodic label advertisements, yielding label advertisement duplicates in time.
1) [FARI]建议将标签广告多播到共享链路上的所有LSR。由于多播是不可靠的，这需要定期的标签广告，及时产生重复的标签广告。
2) Another approach is that an LSR unicasts its label advertisements in a reliable way (TCP) to all other (or to all interested) LSRs on the shared link. In this approach the hard-state character of LDP can be maintained but the label advertisement is duplicated in space.
2) 另一种方法是，LSR以可靠的方式（TCP）将其标签广告单播到共享链路上的所有其他（或所有感兴趣的）LSR。在这种方法中，LDP的硬态特性可以保持，但标签广告在空间中是重复的。
Since LSPs are only rewarding if they have a long lifetime and since the number of LSRs on a shared link is limited the second approach seems advantageous.
由于LSP只有在寿命较长时才有回报，而且共享链路上的LSR数量有限，因此第二种方法似乎是有利的。
Another issue with multicast in multi-access networks is whether to use upstream or downstream label assignment. For multicast traffic, upstream label allocation is simpler since there can be only one upstream node per link that belongs to a multicast tree. This (upstream) node can assign a unique label for the FEC. With downstream allocation, there may be multiple downstream nodes for a given tree on a multi-access link; each node may propose a different label assignment for a FEC that would require some resolution process in order to come up with a single label per multicast FEC on the link.
多址网络中多播的另一个问题是使用上行还是下行标签分配。对于多播流量，上游标签分配更简单，因为每个属于多播树的链路只能有一个上游节点。此（上游）节点可为FEC分配唯一标签。对于下行分配，在多址链路上，对于给定的树可能有多个下行节点；每个节点可以为FEC提出不同的标签分配，这将需要一些解析过程，以便在链路上为每个多播FEC提供单个标签。
Once a label has been assigned, it is possible that the label assigner leaves the tree. With downstream label assignment, this could happen when the label allocator leaves the group. With upstream assignment this could happen when the upstream LSR changes due to a unicast topology change.
一旦分配了标签，标签分配者就有可能离开树。对于下游标签分配，当标签分配器离开组时，可能会发生这种情况。对于上行分配，当上行LSR由于单播拓扑的改变而改变时，这可能发生。
The TTL field in the IP header is typically used for loop detection. In IP multicast it is also used to limit the scope of the multicast packets by setting an appropriate TTL value.
IP报头中的TTL字段通常用于循环检测。在IP多播中，它还用于通过设置适当的TTL值来限制多播数据包的范围。
Thus in LSRs that do not support a TTL decrement function (e.g. ATM LSR), the scope restriction function is affected. Suppose one could calculate in advance the number of hops an LSP traverses. In a unicast LSP the TTL value could then be decremented at the ingress or the egress node. For multicast all the branches of the tree can have different lengths so the TTL can only be decremented at the egress node, potentially wasting bandwidth if the TTL turns out to be zero or negative.
因此，在不支持TTL递减功能的LSR（例如ATM LSR）中，作用域限制功能受到影响。假设可以预先计算LSP所经过的跳数。在单播LSP中，TTL值随后可在入口或出口节点处减小。对于多播，树的所有分支可以具有不同的长度，因此只能在出口节点处减少TTL，如果TTL为零或负，则可能会浪费带宽。
Current Label Distribution Terminology is only defined for unicast. The following sections explore what this terminology might mean in a multicast context.
当前的标签分发术语仅为单播定义。以下各节将探讨此术语在多播上下文中的含义。
In Independent Control ([ANDE]) each LSR can take the initiative to do a label mapping. In Ordered Control ([ANDE]) an LSR only maps a label when it already received a label from its next-hop.
在独立控制（[ANDE]）中，每个LSR可以主动进行标签映射。在有序控制（[ANDE]）中，LSR仅在从下一跳接收到标签时映射标签。
All the previously described trigger methods (section 5) combine with Independent Control. Note that if the request driven approach is used with Independent Control the label distribution still behaves as in Ordered Control: the control messages flow from the egress node upstream, imposing the same sequence to the label advertisement.
所有前面描述的触发方法（第5节）都与独立控制相结合。请注意，如果请求驱动的方法与独立控制一起使用，则标签分发仍表现为有序控制：控制消息从出口节点上游流出，将相同的顺序强加给标签播发。
Ordered Control is not applicable for a traffic driven trigger in case the node does not support mixed L2/L3 forwarding. According to Table 2, this case implies that labels are requested by the upstream LSR. Suppose in Figure 11 that an LSP exists from S to R1 and a new branch must be added to R2. B will only accept a label on the A-B link if a label is already assigned on the B-C link. However, to establish a label on the B-C link, B must already receive traffic on the A-B link.
如果节点不支持二级/三级混合转发，则有序控制不适用于流量驱动触发器。根据表2，这种情况意味着上游LSR请求标签。假设在图11中，从S到R1存在一个LSP，并且必须向R2添加一个新的分支。如果B-C链接上已分配标签，则B仅接受a-B链接上的标签。但是，要在B-C链路上建立标签，B必须已经在a-B链路上接收流量。
N---N---R1
/
/
S -----A
\
\
B---C---R2
N---N---R1
/
/
S -----A
\
\
B---C---R2
Figure 11.
图11。
In the Conservative Mode ([ANDE]) only the labels that are used for forwarding data (if the next-hop for the FEC is the LSR which advertised the label) are allocated and maintained. In the Liberal Mode labels are advertised and maintained to all neighbors. Liberal Mode does not make sense in multicast. Two reasons can be identified for this:
在保守模式（[ANDE]）中，仅分配和维护用于转发数据的标签（如果FEC的下一跳是公布标签的LSR）。在自由模式下，向所有邻居发布和维护标签。自由模式在多播中没有意义。可以确定两个原因：
1) All LSRs have a route for each unicast FEC. This is not true for multicast FECs.
1) 所有LSR对每个单播FEC都有一个路由。对于多播FEC，情况并非如此。
2) For multicast an LSR always knows to which neighbor to send the label request or the label map messages. In e.g. unicast Downstream Unsolicited mode (see below) the LSR does not know where to send the label mappings and thus has to send the mapping to all its neighbors. In this case supporting the Liberal Mode does not generate extra messages (it still requires extra state information and label space) and thus the threshold to support Liberal Mode could be considered lower.
2) 对于多播，LSR总是知道向哪个邻居发送标签请求或标签映射消息。例如，在单播下行非请求模式（见下文）中，LSR不知道向何处发送标签映射，因此必须向其所有邻居发送映射。在这种情况下，支持自由模式不会生成额外的消息（它仍然需要额外的状态信息和标签空间），因此支持自由模式的阈值可以认为更低。
Table 3 shows the cases where it is known by an LSR where to send its label requests.
表3显示了LSR知道向何处发送标签请求的情况。
+---------+----------------------------------+
| | label requested by |
| | LSRu | LSRd |
+---------+----------------+-----------------|
|unicast | Yes | No |
+---------+----------------+-----------------|
|multicast| Yes | Yes |
+---------+----------------+-----------------+
+---------+----------------------------------+
| | label requested by |
| | LSRu | LSRd |
+---------+----------------+-----------------|
|unicast | Yes | No |
+---------+----------------+-----------------|
|multicast| Yes | Yes |
+---------+----------------+-----------------+
Table 3. Does an LSR know where to send its label requests ?
表3。LSR知道在哪里发送标签请求吗？
For a unicast flow, an LSR can determine the next hop LSR, which is the one to send the request to in case of Upstream Unsolicited or Downstream on Demand mode. The LSR is however not able to find the previous hop. The previous hop is not necessarily the next hop towards the source, because the path from A to B is not necessarily the same as the path from B to A. Such a situation can occur as a result of asymmetric link measures or in the event that multiple equal cost paths exist [PAXS].
对于单播流，LSR可以确定下一跳LSR，该LSR是在上游未经请求或下游按需模式下发送请求的LSR。但是，LSR无法找到上一个跃点。前一个跃点不一定是指向源的下一个跃点，因为从A到B的路径不一定与从B到A的路径相同。这种情况可能是由于不对称链路测量或存在多个等成本路径[PAX]的情况下发生的。
In the case of multicast, an LSR knows both the next hop(s) and the previous hop. Because multicast trees are constructed using the reverse shortest path method, the previous hop is always the next hop towards the source or towards the root of the tree.
在多播的情况下，LSR知道下一跳和上一跳。由于多播树是使用反向最短路径方法构建的，因此前一跳始终是指向源或树根的下一跳。
The label can be allocated by either the downstream LSR (Downstream on Demand, Downstream Unsolicited) or the upstream LSR (Upstream on Demand, Upstream Unsolicited, implicit). The advantages of downstream label allocation are:
标签可以由下游LSR（下游按需，下游未经请求）或上游LSR（上游按需，上游未经请求，隐式）分配。下游标签分配的优点是：
a) It is the same mode as for unicast LDP, thus eliminating the need to develop upstream label distribution procedures.
a) 它与单播LDP的模式相同，因此无需开发上游标签分发程序。
b) The same label can be kept when the upstream LSR changes due to a route change, which is an advantage on multi-access networks (see section 9).
b) 当上游LSR由于路由改变而改变时，可以保持相同的标签，这在多址网络上是一个优势（参见第9节）。
c) Compatible with piggy-backing (especially the downstream distribution mode).
c) 与背驮（特别是下游配送模式）兼容。
The advantages of upstream label allocation are:
上游标签分配的优点是：
a) Easier label allocation in multi-access networks (see section 9).
a) 多址网络中更容易的标签分配（见第9节）。
b) The same label can be kept when the downstream LSR (which would have been the label allocator in downstream mode in a multi-access network) leaves the group (see section 9).
b) 当下游LSR（在多址网络中可能是下游模式下的标签分配器）离开组时，可以保留相同的标签（参见第9节）。
c) The upstream and implicit distribution mode allow a faster LSP setup when the LSP is traffic triggered.
c) 上游和隐式分发模式允许在触发LSP流量时更快地设置LSP。
Whether to use upstream or downstream label distribution is outside the scope of this framework. The relative complexity between the necessary protocol extensions and the resolution mechanism needed, as well as the relative operational complexity, will influence which way to go.
是否使用上游或下游标签分发不在本框架的范围内。必要的协议扩展和所需的解决机制之间的相对复杂度，以及相对的操作复杂度，将影响到该走哪条路。
Beside the explicit distribution modes (which use a signaling protocol), [ACHA] proposes an implicit label distribution method by using unknown labels. This method has all the advantages of the upstream label allocation method and is probably the fastest label advertisement method for traffic triggered LSPs.
除了显式分发模式（使用信令协议）之外，[ACHA]还提出了一种使用未知标签的隐式标签分发方法。该方法具有上游标签分配方法的所有优点，并且可能是流量触发LSP的最快标签广告方法。
Implicit label distribution is not applicable if the FEC-to-label binding has been advertised prior to traffic arrival, e.g. explicit routing (i.e. if all the information necessary to identify the FEC is not present in the packet).
如果FEC到标签的绑定在流量到达之前已经通告，例如显式路由（即，如果包中不存在识别FEC所需的所有信息），则隐式标签分发不适用。
Explicit distribution allows pre-establishment (before the arrival of data) of LSPs with topology or request driven triggers.
显式分发允许预先建立（在数据到达之前）带有拓扑或请求驱动触发器的LSP。
In general, the use of multicast in an MPLS environment poses no extra security issues beyond the ones that already exist in multicast and MPLS protocols as such.
一般来说，在MPLS环境中使用多播不会带来超出多播和MPLS协议中已经存在的安全问题之外的额外安全问题。
The protocols described in this document are however not suited to cross administrative boundaries.
然而，本文件中描述的协议不适用于跨管理边界。
When the multicast tree is determined by an existing multicast routing protocol (this is the assumption made in this document, except for the Explicit Routing section), clearly no additional security issues are introduced with respect to the shape of the tree (e.g. unauthorized joining, tapping, blackholing, injecting traffic, ...). These security issues should have been addressed in the specifications of the multicast routing protocols.
当多播树由现有的多播路由协议确定时（这是本文档中的假设，除了显式路由部分），显然不会对树的形状引入额外的安全问题（例如，未经授权的加入、窃听、黑洞、注入流量等）。这些安全问题应该在多播路由协议的规范中得到解决。
In the MPLS context it is possible that control messages trigger L2 resource allocations (e.g. LSPs). If security flaws would still be present in the existing protocols (which possibly are not too harmful in its original context) the abusive sending of such control messages can yield more severe DoS attacks.
在MPLS上下文中，控制消息可能触发二级资源分配（例如LSP）。如果现有协议中仍然存在安全缺陷（在其原始上下文中可能不会太有害），则滥用发送此类控制消息可能会产生更严重的DoS攻击。
In case of an "explicit routed" tree that is calculated centrally, sufficient authentication must be done on the control messages that set up the tree in the network nodes.
对于集中计算的“显式路由”树，必须对在网络节点中设置树的控制消息进行充分的身份验证。
The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard Gastaud for the fruitful discussions and/or their thorough revision of this document.
作者感谢Eric Rosen、Piet Van Mieghem、Philip Dumortier、Hans De Neve、Jan Vanhoutte、Alex Mondrus和Gerard Gastaud对本文件进行了富有成效的讨论和/或彻底修订。
Informative References
资料性引用
[ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE Globecom '97.
[ACHA]A.Acharya，R.Dighe和F.Ansari，“快速ATM信元传输上的IP交换（IPSOFATO）：交换多播流”，IEEE Globecom'97。
[ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress.
[ADAM]A.Adams，J.Nicholas，W.Siadak，协议独立多播第2版密集模式规范”，正在进行的工作。
[ANDE] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
[ANDE]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和R.Thomas，“LDP规范”，RFC 3036，2001年1月。
[AWDU] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[AWDU]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Swallow，G.和V.Srinivasan，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[BALL]Ballardie，A.，“基于核心的树（CBT）多播路由架构”，RFC 22011997年9月。
[CONT] Conta, D., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks", RFC 3034, January 2001.
[CONT]Conta，D.，Doolan，P.和A.Malis，“在帧中继网络上使用标签切换”，RFC 30342001年1月。
[CRAW] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M. and J. Krawczyk, "A Framework for Integrated Services and RSVP over ATM", RFC 2382, August 1998.
[Crawley，E.，Berger，L.，Berson，S.，Baker，F.，Borden，M.和J.Krawczyk，“ATM上的综合服务和RSVP框架”，RFC 2382，1998年8月。
[DAVI] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC switching", RFC 3035, January 2001.
[DAVI]Davie，B.，Lawrence，J.，McCloghrie，K.，Rekhter，Y.，Rosen，E.，Swallow，G.和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[DEER] Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[DEER]Deering，S.，Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[FARI] D. Farinacci, Y. Rekhter, E. Rosen and T. Qian, "Using PIM to Distribute MPLS Labels for Multicast Routes", Work In Progress.
[FARI]D.Farinaci，Y.Rekhter，E.Rosen和T.Qian，“使用PIM为多播路由分发MPLS标签”，工作正在进行中。
[FENN] Fenner, W., "Internet Group Management Protocol, IGMP, Version 2", RFC 2236, November 1997.
[FENN]Fenner，W.，“互联网组管理协议，IGMP，第2版”，RFC 2236，1997年11月。
[GARR] Garrett, M. and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998.
[GARR]Garrett，M.和M.Borden，“受控负载服务和保证服务与ATM的互操作”，RFC 2381，1998年8月。
[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress.
[HOLB]H.Holbrook，B.Cain，“IP的源特定多播”，工作正在进行中。
[MOY] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOY]MOY，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[NAGA] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.
[NAGA]Nagami，K.，Demizu，N.，Esaki，H.，Katsube，Y.和P.Doolan，“LDP ATM链路上的VCID通知”，RFC 3038，2001年1月。
[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress.
[PERL]R.Perlman，C-Y.Lee，A.Ballardie，J.Crowcroft，Z.Wang，T.Maufer，“简单多播”，正在进行中。
[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work In Progress.
[PUSA]T.Pusateri，“距离向量多播路由协议”，工作正在进行中。
[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking 5(5), pp. 601-615.
[PAXS]V.Paxson，“互联网中的端到端路由行为”，IEEE/ACM网络事务5（5），第601-615页。
[ROSE] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[ROSE]Rosen，E.，Rekhter，Y.，Tappan，D.，Farinaci，D.，Fedorkow，G.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
Authors Addresses
作者地址
Dirk Ooms Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerp, Belgium. Phone : 32 3 2404732 Fax : 32 3 2409879 EMail: Dirk.Ooms@alcatel.be
2018年1月1日，比利时安特卫普，德克奥姆斯阿尔卡特公司研究中心。电话：32 3 2404732传真：32 3 2409879电子邮件：德克。Ooms@alcatel.be
Bernard Sales Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerp, Belgium. Phone : 32 3 2409574 EMail: Bernard.Sales@alcatel.be
贝尔纳销售阿尔卡特公司研究中心Fr.Wellesplein 12018比利时安特卫普。电话：32322409574电子邮件：伯纳德。Sales@alcatel.be
Wim Livens Colt Telecom Zweefvliegtuigstraat 10, 1130 Brussels, Belgium Phone : 32 2 7901705 Fax : 32 2 7901711 EMail: WLivens@colt-telecom.be
Wim Livens Colt Telecom Zweeffliegtuigstraat 101130比利时布鲁塞尔电话：32 2 7901705传真：32 2 7901711电子邮件：WLivens@colt-电信公司
Arup Acharya IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne NY 10532 Phone : 1 914 784 7481 EMail: arup@us.ibm.com
Arup Acharya IBM TJ Watson研究中心纽约州霍桑市锯木勒河路30号电话：1914 784 7481电子邮件：arup@us.ibm.com
Frederic Griffoul Ulticom, Inc. Les Algorithmes, 2000 Route des Lucioles, BP29 06901 Sophia-Antipolis, FRANCE EMail: griffoul@ulticom.com
Frederic Griffoul Ulticom，Inc.Les Algorithmes，2000 Route des Lucioles，BP29 06901，Sophia Antipolis，法国电子邮件：griffoul@ulticom.com
Furquan Ansari Bell Labs, Lucent Tech. 101 Crawfords Corner Rd., Holmdel, NJ 07733 Phone : 1 732 949 5249 Fax : 1 732 949 4556 EMail: furquan@dnrc.bell-labs.com
Furquan Ansari Bell实验室，朗讯科技公司，地址：新泽西州霍姆德尔克劳福德角路101号07733电话：1732 949 5249传真：1 732 949 4556电子邮件：furquan@dnrc.bell-实验室网站
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。