[要約] 要約：RFC 3353は、MPLS環境でのIPマルチキャストの概要を提供しています。 目的：このRFCの目的は、MPLSネットワークでのIPマルチキャストの実装と運用に関するガイダンスを提供することです。
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.
Copyright（c）The Internet Society（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
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 COS COSクラスクラスDLCIデータ接続識別子識別子DRSEND DVMRP遠隔ベクトルマルチキャストルーティングプロトコルの指定ルーターの指定ルーターDVMRP遠隔マルチキャストルーティングプロトコルIGMPインターネットグループ管理プロトコルL2レイヤー2（例えば、ATM、フレームリレー）L3レイヤー3（例：IP）LSPラベルスイッチドパスLSRラベルスイッチングルーターLSRDダウンストリームLSR LSRUアップストリームUPSTREAM UPSTRE独立したマルチキャスト濃度モードPIM-SMプロトコル独立したマルチキャストスパールモードQoSサービスの品質RP RENDEZVOUS POINT RPT-BIT RP TREE BIT [DEER] RSVPリソース予約プロトコルSPTビット最小パスツリープロトコル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ノードを相互接続するための最小コスト）は、シュタイナーツリーの計算を課します。残念ながら、今日のマルチキャストルーティングプロトコルは、このような最適なツリーを維持することはできません。したがって、異なるマルチキャストプロトコルは、一般に、異なるツリーを生成します。
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プロトコルのみを考慮しています。MPLは、いくつかの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]に記載されているいくつかの制限を提起します。[続き]の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.
- 限られたラベルスペース：ラベルで使用可能な標準化されたビットまたは実装されたビット数は、確立できるLSPの数を制限して、小さい場合があります（VPI/VCIスペース、DLCIスペースなど）。
- 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-Decrement」関数をサポートしていません。
All three limitations can impact the implementation of multicast in MPLS as will be described in this document.
3つの制限はすべて、このドキュメントで説明されるように、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およびイーサネットリンクで同じラベルを同時に、UnicastとMulticast 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.
これらの特性の議論は、1つの優れたマルチキャストルーティングプロトコルの選択につながることはありません。別のIPマルチキャストルーティングプロトコルがインターネットに展開されることは不可能ではありません。
In unicast different destination addresses are aggregated to one entry in the routing table, yielding one FEC and one LSP.
ユニキャストでは、異なる宛先アドレスがルーティングテーブルの1つのエントリに集約され、1つのFECと1つの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）ソースアドレスであり、gマルチキャストグループアドレスです。1つの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.
マルチキャストツリーを確立するには、いくつかのIPマルチキャストルーティングプロトコル（DVMRP、PIM-DMなど）がネットワークにマルチキャストデータをあふれさせます。その後、ブランチは、特定のマルチキャストグループのデータを受信したくないノードによって剪定できます。このプロセスは定期的に繰り返されます。
Flood & Prune multicast routing protocols have some characteristics which significantly differ from unicast routing protocols: 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.
Flood＆Pruneマルチキャストルーティングプロトコルには、ユニキャストルーティングプロトコルとは大幅に異なる特性があります。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つのツリーを作成します（図1）。
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で共有されたツリーエンドツーエンドをマッピングすると、Multipoint-to-Multipoint（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など）の両方をサポートし、1つのルーターは同じグループGに対して（*、g）と（s、g）状態の両方を維持できます。状態共存の2つの症例を以下に説明します。送信者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を介してであると仮定します。受信機R1（DRECV）の指定されたルーターであるN1は、ソースS1のソースツリーを開始することを決定しました。N2のソースツリーを介してデータが到着した後、N2はソースS1のプルーンをN5に送信します。状態の共存は、共有ツリーとソースツリーのオーバーラップが始まるノード（N2）と、S1が共有ツリー（N5）の転送を必要としないノード（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
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
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
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 the examples one can observe that two types of state co-existence occur:
例では、2種類の状態共存が発生することを観察できます。
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-bitが設定されていない（図2のn2、図3のn3）。（*、g）および（s、g）状態には、さまざまな着信界面がありますが、いくつかの一般的な発信インターフェイスがあります。Sのトラフィックが（*、g）と（s、g）インターフェイスの両方に到着する可能性があります。通常のL3転送では、（s、g）SPTビットエントリにより、（*、g）着信インターフェイスに到着するSからのトラフィックの転送が禁止されています。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）状態は同じ着信インターフェイスを持っています。（s、g）トラフィックは、（*、g）ストリームから抽出する必要があります。MPLSでは、この状態の共存はいくつかの方法で処理できます。この問題に対する4つのアプローチについて説明します。
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で転送することです。ただし、発信インターフェイスのないA（S、G）エントリがMRT（図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) 2番目のアプローチは、共有ツリーのノードにソース固有のラベルを割り当てることです。複数のラベルは、アクティブソースごとに1つのラベルに対応する1つの（*、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) 3番目の方法は、ソースツリーのみがラベルスイッチされ、共有ツリーのトラフィックが常に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) 4番目のアプローチでは、非ヌルOIFを備えた（s、g）rptビット状態を持つLSRは、上流のLSRに（s、g）のラベルを宣伝し、このラベル広告は各上流のLSRによって伝播されます。RP。このようにして、（S、G）RPTビット状態を使用して、RPから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 [ボール]）には、共有ツリーのノード（n）に多くのマージポイント（m）を作成するという欠点があります。図4は、双方向ツリー上の2人の送信者S1とS2に起因するこれらのマージポイントを示しています。
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
| | | | | |
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].
上記の特性は、既存のIPマルチキャストルーティングプロトコルの非網羅的リストについて表1に要約されています：DVMRP [PUSA]、MOSPF [MOY]、CBT [BALL]、PIM-DM [ADAM]、PIM-SM [ディア]、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 |
+------------------+------+------+------+------+------+------+------+
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から派生できます。そのDVMRPは、Flood＆Prune L3ツリーがL2ツリーにマッピングされると、多くのラベルを消費します。さらに、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).
ユニキャストトラフィックには1つの着信と1つの発信インターフェイスがあるため、トラフィックはL2またはL3で転送されます（図6）。マルチキャストトラフィックは複数の発信インターフェイスに転送できるため、一部のブランチへのトラフィックがL2およびL3の他のブランチに転送される場合を考慮することができます（図7）。
+--------+ +--------+
| L3 | | L3 |
| +>>+ | | |
| | | | | |
+--|--|--+ +--------+
| | | | | |
->-----+ +-----> ->------>>----->
| L2 | | L2 |
+--------+ +--------+
Figure 6. Unicast forwarding on resp. L3 or L2
図6. RESPのユニキャスト転送。L3またはL2
+--------+ +--------+ +--------+
| L3 | | L3 | | L3 |
| +>>++ | | +>>+ | | |
| | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+
Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2
図7.それぞれのマルチキャスト転送。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.
この「混合L2/L3転送」機能をサポートするノードにより、マルチキャストツリーをブランチに分割することができ、一部はL3で転送され、他は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.
混合L2/L3転送にはL3でのトラフィックの処理が必要ですが、L3転送エンジンの負荷は一般に純粋なL3ノードよりも少ないです。
Supporting this 'mixed L2/L3 forwarding' feature has the following advantages:
この「混合L2/L3転送」機能には、次の利点があります。
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コアノードであると仮定LSR A.
+-------------+
| MPLS cloud |
| N |
| / \ |
| / \ |
| / \ |
| A N |
|/ \ \ |
| \ \ |
/| \ |
B | C |
| |
+-------------+
Figure 8. Mixed L2/L3 forwarding in node A
図8.ノードAの混合L2/L3転送
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は、これら2つのケースを示しています。
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.要求駆動トリガー（rep。着信および発信コントロールメッセージのインターセプト）
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の確立を決定する場合、LDPバインド（上流の未承諾モード）またはLDPバインドリクエスト（ダウンストリームオンデマンドモード）をLSRDに送信します。
Currently, for multicast, we can identify two important types of control messages: the multicast routing messages and the resource reservation messages.
現在、マルチキャストの場合、マルチキャストルーティングメッセージとリソース予約メッセージの2つの重要な制御メッセージを特定できます。
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は、IPマルチキャストルーティングプロトコル自体を変更するために、このタイプのトリガー[fari]をサポートするために適応できることに注意してください！
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 Join-ackなど）とソフト状態（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で使用する同一のツリーを計算します。同じタスクが2回実行されるため、マルチキャストルーティングテーブル自体から抽出された情報に基づいて、マルチキャスト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: a) RSVP Resv messages can merge.
ユニキャストの場合と同様に、RSVP RESVメッセージはLSPを確立するトリガーとして使用できます。マルチキャストグループのソースは、RSVPパスメッセージをツリーに送信し、レシーバーはRSVP RESVメッセージで返信できます。rsvpは、マルチキャストの場合、ユニキャストの場合と同様に、次のようにスケールします。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では、特定のグループのLSPがLSRD1に存在し、別のLSRD2がツリーに参加したいと仮定します。LSRD2がトリガーを開始するためには、既にツリーからトラフィックを受信する必要があります。これは、L2またはL3で行うことができます。前者のケースは鶏肉と卵の問題です。後者のケースでは、LSRUでL3分岐を追加するためにLSRUの混合L2/L3転送機能が必要です。
+--------+
| 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.
IPマルチキャストルーティングプロトコル（DVMRP、PIM）のUNIXプラットフォームでの現在の実装には、マルチキャスト転送キャッシュ（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動作を保持するには、MFCのL3カウンターをL2測定によって更新する必要があります。
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）は、混合L2/L3転送機能が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) |
+----------------+-----------+----------+-----------+----------+
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（発信ケース）では、2つの個別のメッセージを送信する代わりに、ラベル広告を既存のコントロールメッセージに貯蔵することができることを観察できます。マルチキャストの場合、2つのピギーバック候補が存在します。
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メッセージ：マルチキャストにも適用されるRSVPのラベルマッピング拡張オブジェクトが[AWDU]で提案されています。
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）の2番目のソリューションは、ピギーバッキングと組み合わせて適用することはできません。
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) ピギーバッキングでは、マルチキャストルーティングプロトコルを拡張する必要があるため、複数のマルチキャストルーティングプロトコルでラベル広告をサポートする必要がある場合、魅力的ではなくなります。特に、ラベルの広告だけでなく、他の2つのLDP関数（発見と隣接）がピギー補助されている場合。
d) Piggy-backing assumes the Downstream Unsolicited label distribution mode, this excludes a number of trigger methods (see Table 2).
d) ピギーバッキングは、下流の未承諾ラベル分布モードを想定しています。これは、多くのトリガー方法を除外します（表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バインドを送信することで実行できます。これにより、1つのメッセージのみが必要です。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がすでにユニキャストに使用されているかどうかに大きく依存します。マルチキャストソリューション。
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ツリーによってマルチキャストルーティングプロトコルによって確立されたツリーをオーバーライドします（たとえば、オフラインツールによって計算されたシュタイナーツリー）。この解釈では、現在の「最短パス」マルチキャストルーティングプロトコルは時代遅れになり、明示的なルート（シュタイナーツリーのブランチなど）に従うラベル広告メッセージに置き換えることができます。
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.
「マルチキャスト明示的ルーティング」を解釈する2番目の方法は、既知のマルチキャストルーティングプロトコルが実行されていることですが、これらのプロトコルによって生成されたメッセージは、明示的なユニキャストルートを使用して（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で1つ以上のツリーを構築できます。
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に非常に簡単にマッピングできます。この場合、さまざまなDSCPの異なる属性を持つLSPを作成できます。ただし、これらのLSPは、ツリー構造メカニズム自体がDSCPを入力として取得しない限り、同じルートを使用していることに注意してください。
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でも解決されていないことに注意してください）。この主題は[craw]で取り組まれています。実用的なアプローチは、最良の努力サービスと単一の代替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.
最初のアプローチでは、各サービスクラスのフルツリーを構築します。送信者は、ネットワーク全体でトラフィックを2回送信する必要があります（例：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.
2番目のアプローチは1つのツリーを構築し、最良のユーザーがQoSツリーに接続されます。Best-Effortユーザー向けに作成されたブランチがラベルを切り替えない場合（したがって、ホップバイホップのデフォルトLSPによって運ばれます）、QoSマルチキャストトラフィックをこれらのデフォルトのLSPにマージする必要があります。この機能は、セクション4で説明されている「混合L2/L3転送」機能によって提供できます。これが利用できない場合は、QoS LSPのL3への戻りを避けるためにマージが必要です。
The mapping of the IntServ service categories onto L2 for ATM service categories is studied in [GARR].
ATMサービスカテゴリのL2へのINTSERVサービスカテゴリのマッピングは、[GARR]で研究されています。
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に）。これは3つの方法で実現できます。
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が「同じ瞬間に」ラベルを割り当てる場合、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) マルチアクセスリンクごとに、1つの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があります。ラベル広告の2つのソリューションは、次のように考えることができます。
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) もう1つのアプローチは、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の数が制限されている場合にのみ報われるため、2番目のアプローチは有利と思われます。
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.
MultiCastのMulti-Accessネットワークの別の問題は、上流のラベル割り当てを使用するか、下流のラベル割り当てを使用するかです。マルチキャストトラフィックの場合、マルチキャストツリーに属するリンクごとに1つのアップストリームノードしかないため、上流のラベル割り当てはより簡単です。この（上流）ノードは、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減少関数（ATM LSRなど）をサポートしていないLSRでは、スコープ制限関数が影響を受けます。LSPトラバースのホップ数を事前に計算できるとします。ユニキャストLSPでは、TTL値をイングレスまたは出力ノードで減らすことができます。マルチキャストの場合、ツリーのすべての枝は異なる長さを持つことができるため、TTLはEgressノードでのみ減少することができ、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.
ノードが混合L2/L3転送をサポートしていない場合、順序付けられた制御はトラフィック駆動トリガーに適用されません。表2によると、このケースは、上流のLSRによってラベルが要求されることを意味します。図11に、LSPがSからR1に存在し、新しい分岐をR2に追加する必要があるとします。Bは、B-Cリンクにラベルが既に割り当てられている場合にのみ、A-Bリンクのラベルを受け入れます。ただし、B-Cリンクにラベルを確立するには、bは既にA-Bリンクのトラフィックを受信する必要があります。
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である場合）は割り当てられ、維持されます。リベラルモードでは、ラベルが宣伝され、すべての隣人に維持されています。リベラルモードはマルチキャストでは意味がありません。これについては、2つの理由を特定できます。
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は常にラベルリクエストまたはラベルマップメッセージを送信する隣人がどの隣人に知っていますか。例えばUnicastダウンストリーム未承諾モード（以下を参照）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 |
+---------+----------------+-----------------+
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は以前のホップを見つけることができません。前のホップは必ずしもソースへの次のホップではありません。AからBまでのパスは必ずしもBからAまでのパスと同じではないため複数の等しいコストパスが存在します[Paxs]。
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コンテキストでは、コントロールメッセージがL2リソースの割り当てをトリガーする可能性があります（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.
著者は、エリック・ローゼン、ピエット・ヴァン・ミーゲム、フィリップ・ドゥモルティエ、ハンス・デ・ネヴェ、ヤン・ヴァンフッテ、アレックス・モンドルス、ジェラルド・ガストーに、この文書の徹底的な改訂について感謝します。
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セル輸送（IPSOFACTO）のIPスイッチング：マルチキャストフローの切り替え」、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、Protocol Independent Multicastバージョン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。and 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。and V. Srinivasan、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[ボール] Ballardie、A。、「コアベースの木（CBT）マルチキャストルーティングアーキテクチャ」、RFC 2201、1997年9月。
[CONT] Conta, D., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks", RFC 3034, January 2001.
[続き] Conta、D.、Doolan、P。およびA. Malis、「フレームリレーネットワークのラベルスイッチングの使用」、RFC 3034、2001年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.
[Craw] 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.
[ディア]ディアリング、S。、エストリン、D。、ファリナッチ、D。、ヘルミー、A。、ターラー、D。、ハンドリー、M。、ジェイコブソン、V。、リュー、C.、シャルマ、P。およびLウェイ、「プロトコル独立したマルチキャスト - スズパーズモード（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. Farinacci、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。and 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へのマルチキャスト拡張」、RFC 1584、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、「Simple Multicast」、作業中。
[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、「インターネットでのエンドツーエンドのルーティング動作」、Networking 5（5）のIEEE/ACMトランザクション、pp。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.、Farinacci、D.、Fedorkow、G.、Li、T。およびA. Conta、「Mpls Label Stack Encoding」、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
Dirk Ooms Alcatel Corporate Research Center Fr.Wellesplein 1、2018 Antwerp、ベルギー。電話：32 3 2404732ファックス：32 3 2409879メール：dirk.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 1、2018 Antwerp、ベルギー。電話：32 3 2409574メール：bernard.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 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
Wim Livens Colt Telecom Zweefvliegtuigstraat 10、1130 Brussels、Belgium電話：32 2 7901705ファックス：32 2 7901711メール：wlivens@colt-telecom.be arup acharya ibm tjson redulice Center784 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、France Email：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 Labs、Lucent Tech。101 Crawfords Corner Rd。、Holmdel、NJ 07733電話：1 732 949 5249 FAX：1 732 949 4556メール：furquan@dnrc.bell-labs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。