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
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
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
サービスDLCIデータリンクコネクション識別子DRrecvのATM非同期転送ノードCBTコアベースツリーのCoSクラスの受信機の指定ルータは、（送信者DVMRP遠いベクトルマルチキャストルーティングプロトコルFRフレームリレーIGMPインターネットグループ管理プロトコルIPインターネットプロトコルL2層2の指定ルータをDRsend例えばATM、フレームリレー）L3層3（スイッチング例えばIP）LSPラベルスイッチパスのLSRラベルルータLSRDダウンストリームLSR LSRu上流LSR MOSPFマルチキャストOSPF mp2mpマルチポイント・ツー・マルチポイントMRTマルチキャストルーティングテーブルのP2MPポイント・ツー・マルチポイントPIM-DMプロトコル独立マルチキャスト - 稠密モードPIM-SMプロトコル独立マルチキャスト - スパースモードのQoSサービス品質のRPランデブーポイントRPTビットのRPツリーのビット[DEER] RSVPリソース予約プロトコルSPTビット最短パスツリー[DEER] 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個のノードを相互接続するための最小コスト）スタイナーツリー計算を課します。残念ながら、マルチキャストルーティングプロトコルは、今日では、このような最適なツリーを維持することができません。異なるマルチキャストプロトコルは、したがって、一般的に、異なるツリーを生成します。
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へのマッピングに焦点を当てています。 ATMは、高いスイッチング容量とQoSの意識を提供していますが、MPLSの文脈では、[ダヴィ]で説明されているいくつかの制限をもたらします。同様の考察が[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.
- 限定ラベルスペース：標準化された又はラベルの利用可能なビットの実装数を確立することができる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-デクリメント」関数をサポートしていません。
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イーサネット上MPLSユニキャストおよびマルチキャストのための別のEtherTypeが定義されているため、同じラベルがユニキャストおよびマルチキャストLSPのために同時に使用することができる[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マルチキャストルーティングプロトコルの存在量が提案され、開発されています。すべてのこれらのプロトコルは、異なる特性（スケーラビリティ、計算の複雑さ、レイテンシー、制御メッセージのオーバーヘッド、ツリー型、など...）持っています。 MPLS技術に関連するだけでその特性がアドレス指定され、IPマルチキャストルーティングプロトコルの完全な分類を与えるために、この文書の目的ではありません。
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 1つずつLSPを得、ルーティングテーブル内の1つのエントリに集約されます。
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マルチキャストグループアドレスされています。 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.
洪水＆プルーンマルチキャストルーティングプロトコルは大幅ユニキャストルーティングプロトコルとは異なるいくつかの特性を有する：A）は、揮発性。プロトコルの洪水＆プルーン自然に、非常に揮発性のツリー構造が生成されます。 L2 P2MP LSPに動的L3のP2MPツリーをマッピングするための解決策は、シグナリングオーバーヘッドの用語および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）、ソース（S）とマルチキャストグループあたり（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上の共有ツリーのエンドツーエンドをマッピングするマルチポイントツーマルチポイント（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）および（S、G）G.状態の共存の2つのケースが以下に記載されている同じグループのための状態。送信者Siと受信機Riを持つトポロジーを前提としています。 RPは、ランデブーポイントです。 NiはLSRのです。番号はインターフェイス番号です、「レッグは、」登録インタフェースです。すべての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は、ソースS1ためN5にプルーンを送信します。状態の共存は、共有ソースツリー開始の重なりがノード（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
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
RPに（*、G）：REG-> 1（すなわち、着信ITF =レッグ;発信ITF = 1）N1で：（*、G）：2-> 1 N2中：（*、G）：3-> 1（S1、G）：2-> 1 N3で：（S1、G）：2->レッグ、1 N4において：（*、G）：2-> 1 N5で：（*、G）：2- > 1,3-（S1、G）RPTビット：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; N3は、図3のSのDRsendです）。共有ツリー上の各ノードは、（*、G）ステートを有しています。このようにツリーDRsend両方（*、G）および（S、G）状態を有します。 DRsendがオンツリーである場合、それはまた、（図3にN1とN2）ブランチを有する第一のルータまでのすべてのノードに（S、G）ステートを作成し、RPに向かってSためプルーンを送信します。
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
RPに（*、G）：REG-> 1（すなわち、着信ITF =レッグ;発信ITF = 1）N1で：（*、G）：1-> 2,3-（S、G）RPTビット：1 - > N2における2：（*、G）：1-> 2（S、G）RPTビット：1-> N3でなし：（*、G）：1-> 3（S、G）：2- N4で>レギュラー3：（*、G）：1-> 2 N5で：（*、G）：1-> 2
In the examples one can observe that two types of state co-existence occur:
例では1は、状態の共存の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ビット図2（N2、図3のN3）に設定されていないと。 （*、G）および（S、G）状態が異なる着信インターフェイスを持っているが、いくつかの共通の発信インターフェイス。 Sのトラフィックの両方（*、G）および（S、G）インターフェースに到着する可能性があります。通常L3に（S、G）SPTビットエントリを転送する（*、G）着信インターフェイスに到着Sからのトラフィックの転送を禁止します。 Sのトラフィックが一時的にのみ（図3において図2とN1にN5までプルーンメッセージを処理している）（*、G）および（S、G）エントリの両方の着信インターフェイスに到達することができます。重複パケットのL3転送の一時的な転送を回避するために、ノードのこのタイプに適用することができます。 1は気にしない場合は、一時的な重複したパケットの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にこのグループのすべてのトラフィックを転送することです。しかしL3への復帰は、発信インタフェースなしで（S、G）エントリがMRT（図3のN2）に添加した場合に回避することができます。このエントリは一時的にしかトラフィックを受信します。この特定のケースでは一方が（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）第三の方法は、ソースツリーをlabelswitchedされ、共有ツリー上のトラフィックは常にL3で転送されることです。これは、共有ツリーは受信機だけが情報源が誰であるかを知るための方法として使用されていることを前提としています。低ビットレートの切り替えしきい値を設定することで、1は、受信機は非常に迅速にソースツリーにスイッチオーバーすることを確実にすることができます。
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）のラベルをアドバタイズし、このラベル広告は、次いで、各アップストリームによって伝播されますRPへのLSR。このように、専用のLSPは（S、G）（S、G）RPTビットの状態にLSRにRPからのトラフィックのために作成されます。後者の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は、双方向ツリーに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.
LSR混合L2 / L3転送（セクション4）をサポートしている場合1）、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 [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 |
+------------------+------+------+------+------+------+------+------+
Table 1. Taxonomy of IP Multicast Routing Protocols
IPマルチキャストルーティングプロトコルの表1分類
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からの1つは、例えば、導出することができますそのDVMRPは洪水＆プルーン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つずつ発信インターフェースのトラフィックがいずれかL3 L2でORに転送される（図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.マルチキャストは、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.
この「混合L2 / L3転送」機能をサポートしているノードは、他のものはL2で切り替えながら一部はL3で転送されたブランチにマルチキャストツリーの分割を可能にします。
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）を混合L2 / L3転送がCに向かって分岐が復帰によって妨害されないことを可能にするLSR Bに向かって分岐し、LSR C.向かって分岐するためのMPLSコアノードのMPLSエッジノードでありますLSR A.でL3に
+-------------+
| MPLS cloud |
| N |
| / \ |
| / \ |
| / \ |
| A N |
|/ \ \ |
| \ \ |
/| \ |
B | C |
| |
+-------------+
Figure 8. Mixed L2/L3 forwarding in node A
ノードAにおける図8混在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）トポロジードリブン：L2ツリーに、マルチキャストルーティングテーブルに利用可能であるL3ツリーをマッピングします。マッピングは、トラフィックがない場合でも行われます。
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.要求駆動トリガ（それぞれの傍受。着信および発信制御メッセージ）
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にJoinメッセージを。 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参加-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回実行されるので、（セクション5.2および5.3を参照）は、マルチキャストルーティングテーブル自体から抽出された情報に基づいてマルチキャストLSPを作成する方がよいです。ルーティング計算は、より多くのメッセージを解釈しなければならないので（S、G）木に（*、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ないだけを遮断することによって「エンドユーザーまでの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 RESVメッセージで応答することができ、ツリーの下RSVP Pathメッセージを送信します。 A）RSVP RESVメッセージをマージすることができますので、それはユニキャストの場合と同様にRSVPは、マルチキャストのためにも等しくスケール。
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モジュールは、L2 P2MPのLSPにこのL3ツリートポロジ情報をマッピングします。
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をポーリングすることができます。代替的に、マルチキャストデーモンは、MRTへの変更の直接MPLSモジュールに通知するように改変することができます。
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のいずれかであることができます。前者の場合は、鶏と卵の問題です。後者の場合は、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）ピギーバッキングは、マルチキャストルーティングプロトコルを拡張する必要があり、ラベル広告が複数のマルチキャストルーティングプロトコルのためにサポートする必要がある場合、したがってあまり魅力的となります。ラベル広告だけでなく、他の二つの自民党機能（発見と隣接）だけではなくピギーバックされている場合は特に。
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.
VCID通知メカニズム[NAGA]が必要な場合はF）、（インバンド）通知は、通常、新しく設立された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.
ピギーバッキングは理にかなっているか、いないいるに大きく依存し、どのように多くのマルチキャストルーティングプロトコルは、自民党は既にトリガ機構が使用されているユニキャストに使用されているかどうか、配備されている...ピギーバッキングは、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ツリー（オフラインツールによって算出例えばスタイナー木）によってマルチキャストルーティングプロトコルによって確立されたツリーをオーバーライドです。この解釈では、現在の「最短経路」マルチキャストルーティングプロトコルは時代遅れになると（スタイナー木の枝等）明示的な経路をたどるラベル広告メッセージで置き換えることができます。
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コードポイント（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上に非常に容易にマッピングすることができます。この場合、1は、各種のDSCPのために異なる属性を持つ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に解決されていない発言）に「異種の受信者パラダイムをマッピングする方法の問題です。この主題は、[CRAW]で取り組まれています。実用的なアプローチは、ベストエフォート型サービスと（例えば、RSVP Pathメッセージに送信者によって提案されたQoS）単一代替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木）ネットワークを介して2倍のトラフィックを送信する必要があります。どちらの木はラベルを切り替えることができます。
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のアプローチは、一本の木を構築し、ベストエフォート型のユーザーは、QoSツリーに接続されています。ベストエフォート型のユーザーのために作成した枝がある場合は、ラベルは、QoS、マルチキャストトラフィックは、これらのデフォルトのLSPにマージする必要があります（したがって、ホップバイホップデフォルト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は常に既にグループ（リンク上の別の川下のLSRに）LSPに割り当てられているラベルを受け入れる準備ができなければなりません。これは、次の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は、それを保つことができます。
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を持つことができます。ラベル広告のための二つの溶液を考えることができます。
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は共有リンク上の他のすべての（またはすべての利害に）のLSRへの確実な方法（TCP）でそのラベル広告をユニキャストということです。このアプローチでは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.
彼らは長い寿命を持っており、共有リンク上のLSRの数が限られているので、第二のアプローチが有利と思われる場合のLSPは、唯一のやりがいですので。
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.
マルチアクセスネットワークにおけるマルチキャストの別の問題は、上流または下流のラベルの割り当てを使用するかどうかです。マルチキャストトラフィックのために、上流のラベル割り当ては、マルチキャストツリーに属しているリンクごとに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で、範囲制限機能が影響を受けます。 1は、事前に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.
順序付けられた制御ノードが混在L2 / L3転送をサポートしていない場合にトラフィック駆動トリガーには適用できません。表2によれば、この場合は、ラベルは、上流のLSRによって要求されていることを意味します。 LSPは、SからR1に存在し、新しい分岐がR2に追加されなければならないことを図11に仮定する。ラベルがすでにB-Cのリンクに割り当てられている場合Bは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である場合）転送データのために使用される唯一のラベルが割り当てられ、維持されます。リベラルモードでは、ラベルは、すべてのネイバーにアドバタイズされ、維持されています。リベラルモードは、マルチキャストで意味がありません。二つの理由は、このために識別することができます。
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 |
+---------+----------------+-----------------+
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へのパスと同じではないので、前のホップは、必ずしもソースに向かって次のホップではないこと複数の等コスト・パスが[パスカル秒]が存在します。
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は、ネクストホップ（S）と前ホップの両方を知っています。マルチキャストツリーは、逆最短パス法を用いて構築されているので、前のホップは常にソースに向かってまたはツリーのルートに向かって次のホップです。
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）は、同じラベルがマルチアクセスネットワーク上の利点であるルート変更、（セクション9を参照）に起因する場合、上流LSRの変更を維持することができます。
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).
マルチアクセスネットワークの下流モードでラベル割当されているだろう下流LSR（）はグループを離れるときb）は、同じラベル（セクション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.
著者は、実りある議論および/またはこのドキュメントの彼らの徹底的な改正のためにエリック・ローゼン、ピエト・ヴァンMieghem、フィリップDumortier、ハンス・デ・ネーヴ、ヤンVanhoutte、アレックスMondrusとジェラルド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.アンサリ、 "IPファストATMセルトランスポート（IPSOFACTO）をスイッチオーバー：スイッチングマルチキャストフロー"、IEEE GLOBECOM '97。
[ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress.
[ADAM] A.アダムス、J.ニコラス、W. Siadak、プロトコル独立マルチキャストバージョン2稠密モード仕様」、進行中の作業。
[ANDE] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
[ANDE]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.とR.トーマス、 "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.、バーガー、L.、ガン、D.、李、T.、ツバメ、G.およびV.スリニバサン、 "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.
[CONT]コンタ、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】クローリー、E.、バーガー、L.、Berson氏、S.、ベイカー、F.、ボーデン、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.
"切替LDPおよびATM VCを使用してMPLS" [ダヴィ]デイビー、B.、ローレンス、J.、McCloghrie、K.、Rekhter、Y.、ローゼン、E.、ツバメ、G.およびP. Doolan、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]デアリング、S.、Estrin、D.、ファリナッチ、D.、Helmy、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.ファリナッチ、Y. Rekhter、E.ローゼン及びT.銭、「マルチキャストルートのMPLSラベルを配布するPIMを使用した」、進行中の作業。
[FENN] Fenner, W., "Internet Group Management Protocol, IGMP, Version 2", RFC 2236, November 1997.
[フェン]フェナー、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]ギャレット、M.とM.ボーデン、「制御・ロード・サービスの相互運用およびATMでの保証サービス」、RFC 2381、1998年8月。
[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress.
[HOLB] H.ホルブルック、B.カイン、「IPのためのソース固有のマルチキャスト」、進行中の作業。
[MOY] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[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]永見、K.、Demizu、N.、江崎、H.、勝部、Y.、およびP. Doolan、RFC 3038、2001年1月 "LDPのためのATMリンク上VCID通知"。
[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress.
[PERL] R.パールマン、C-Y。リー、A. Ballardie、J.クロウクロフト、Z.王、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.
[パスカル秒] V.パクソン、「インターネットにおけるエンドツーエンドルーティング動作」、ネットワーク5（5）、頁601から615上のIEEE / ACMトランザクション。
[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】ローゼン、E.、Rekhter、Y.、タッパン、D.、ファリナッチ、D.、Fedorkow、G.、李、T.、およびA.コンタ、 "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
ディルクOomsアルカテルコーポレート・リサーチ・センター神父Wellesplein 1、2018年アントワープ、ベルギー。電話：32 3 2404732ファックス：32 3 2409879 Eメール：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
バーナード・販売アルカテルコーポレート・リサーチ・センター神父Wellesplein 1、2018年アントワープ、ベルギー。電話：32 3 2409574 Eメール：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
32 2 7901705ファックス：32 2 7901711電子メール：WLivens@colt-telecom.be WIMはコルトテレコムグライダー10、1130ブリュッセル、ベルギー電話をLivens
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
アラップアチャリヤIBM TJワトソン研究所30ソウミルリバーロード、ホーソーンNY 10532電話：1 914 784 7481 Eメール：arup@us.ibm.com
Frederic Griffoul Ulticom, Inc. Les Algorithmes, 2000 Route des Lucioles, BP29 06901 Sophia-Antipolis, FRANCE EMail: griffoul@ulticom.com
フレデリックGriffoul Ulticom、Inc.のアルゴリズム2000道路ホタル、BP29 06901ソフィアアンティポリス、FRANCE Eメール：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アンサリベル研究所、ルーセントテック。 101 CrawfordsコーナーRdを、ホルムデル、NJ 07733電話：1 732 949 5249ファックス：1 732 949 4556 Eメール：furquan@dnrc.bell-labs.com
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 Editor機能のための基金は現在、インターネット協会によって提供されます。