RFC3353 日本語訳
3353 Overview of IP Multicast in a Multi-Protocol Label Switching(MPLS) Environment. D. Ooms, B. Sales, W. Livens, A. Acharya, F.Griffoul, F. Ansari. August 2002. (Format: TXT=65860 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループD.オームスの要求をネットワークでつないでください: 3353年のアルカテルカテゴリ: 情報のB.販売アルカテルW.はF.GriffoulアルティコムF.Ansariベル研究所2002年8月にコルト電子通信A.Acharya IBMを賑します。
Overview of IP Multicast in a
Multi-Protocol Label Switching (MPLS) Environment
マルチプロトコルラベルスイッチング(MPLS)環境における、IPマルチキャストの概観
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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)の技術の結果は記載されています。 ポイントツーポイントとマルチアクセスネットワークの両方が考えられます。
Ooms, et al. Informational [Page 1] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[1ページ]のRFC3353IPマルチキャスト
Table of Contents
目次
1. Introduction ............................................. 3
2. Layer 2 Characteristics .................................. 4
3. Taxonomy of IP Multicast Routing Protocols
in the Context of MPLS ................................... 5
3.1. Aggregation .............................................. 5
3.2. Flood & Prune ............................................ 5
3.3. Source/Shared Trees ...................................... 6
3.4. Co-existence of Source and Shared Trees .................. 7
3.5. Uni/Bi-directional Shared Trees .......................... 10
3.6. Encapsulated Multicast Data .............................. 11
3.7. Loop-free-ness ........................................... 11
3.8. Mapping of Characteristics on Existing Protocols ......... 11
4. Mixed L2/L3 Forwarding in a Single Node .................. 12
5. Taxonomy of IP Multicast LSP Triggers .................... 14
5.1. Request Driven ........................................... 14
5.1.1. General .................................................. 14
5.1.2. Multicast Routing Messages ............................... 15
5.1.3. Resource Reservation Messages ............................ 15
5.2. Topology Driven .......................................... 16
5.3. Traffic Driven ........................................... 16
5.3.1. General .................................................. 16
5.3.2. An Implementation Example ................................ 17
5.4. Combinations of Triggers and Label Distribution Modes .... 18
6. Piggy-backing ............................................ 18
7. Explicit Routing ......................................... 20
8. QoS/CoS .................................................. 20
8.1. DiffServ ................................................. 20
8.2. IntServ and RSVP ......................................... 21
9. Multi-access Networks .................................... 21
10. More Issues .............................................. 22
10.1. TTL Field ................................................ 22
10.2. Independent vs. Ordered Label Distribution Control ....... 23
10.3. Conservative vs. Liberal Label Retention Mode ............ 24
10.4. Downstream vs. Upstream Label Allocation ................. 25
10.5. Explicit vs. Implicit Label Distribution ................. 25
11. Security Considerations .................................. 26
12. Acknowledgements ......................................... 26
Informative References........................................... 27
Authors' Addresses .............................................. 28
Full Copyright Statement ........................................ 30
1. 序論… 3 2. 2つの特性を層にしてください… 4 3. MPLSの文脈のIPマルチキャストルーティング・プロトコルの分類学… 5 3.1. 集合… 5 3.2. あふれて、剪定します。 5 3.3. ソース/共有された木… 6 3.4. ソースと共有された木の共存… 7 3.5. Uni/双方向の共有された木… 10 3.6. マルチキャストデータを要約します… 11 3.7. 無輪の岬… 11 3.8. 既存のプロトコルの特性に関するマッピング… 11 4. ただ一つのノードにおけるMixed L2/L3推進… 12 5. IPマルチキャストLSP引き金の分類学… 14 5.1. 追い立てられた要求… 14 5.1.1. 一般… 14 5.1.2. マルチキャストルーティング・メッセージ… 15 5.1.3. 資源予約メッセージ… 15 5.2. トポロジー駆動… 16 5.3. 交通駆動… 16 5.3.1. 一般… 16 5.3.2. 実現の例… 17 5.4. 引き金とラベル分配モードの組み合わせ… 18 6. 便乗します… 18 7. 明白なルート設定… 20 8. QoS/CoS… 20 8.1. DiffServ… 20 8.2. IntServとRSVP… 21 9. マルチアクセスネットワーク… 21 10. より多くの問題… 22 10.1. TTL分野… 22 10.2. 命令されたラベル分配に対して独立しているコントロール… 23 10.3. 寛容なラベル保有モードに対する保守的な人… 24 10.4. 上流に対して川下のラベル配分… 25 10.5. 暗黙のラベル分配に対して明白… 25 11. セキュリティ問題… 26 12. 承認… 26 有益な参照… 27人の作者のアドレス… 28 完全な著作権宣言文… 30
Ooms, et al. Informational [Page 2] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[2ページ]のRFC3353IPマルチキャスト
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
送付者DVMRP Distant Vector Multicastルート設定プロトコルFR Frame Relay IGMPインターネットGroup ManagementプロトコルIPインターネットプロトコルL2 2(例えば、ATM、Frame Relay)L3層3(例えば、IP)のLSP Label Switched Path LSR Label Switching Router LSRd Downstream LSR LSRu Upstream LSR MOSPF Multicast OSPF mp2mp層の受信機DRsend Designated RouterのService DLCI Data Link Connection Identifier DRrecv Designated RouterのATM Asynchronous Transfer Node CBT Core Based Tree CoS Class; Service RP Rendezvous Point RPT-ビットRP Treeの多点から多点への台北新交通システムMulticastルート設定Table p2mpポイントツーマルチポイントPIM-DMプロトコルのMulticast濃いMode PIM-SMプロトコル無党派Multicastまばらな無党派Mode QoS QualityはDEER RSVP Resource reSerVationプロトコルSPT-ビットShortest Path Tree DEER SSM Source Specific Multicast TCP通信制御プロトコルUDPユーザー・データグラム・プロトコルVC Virtual Circuit VCI Virtual Circuit Identifier VP Virtual Path VPI Virtual Path Identifierに噛み付きました。
1. Introduction
1. 序論
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.
現在のユニキャストルーティング・プロトコルは確信している(ソース、目的地)組のために定常状態における同じ(最適の)最短パスを発生させます。 ユニキャストプロトコルが等しい費用経路に関して異なった状態でわずかに振る舞うことができると述べてください。
Ooms, et al. Informational [Page 3] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[3ページ]のRFC3353IPマルチキャスト
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.
議論はイントラドメインマルチキャストルーティング・プロトコルに焦点を合わせられます。 相互ドメインルーティングの局面はこのドキュメントの範囲を超えています。
2. Layer 2 Characteristics
2. 層2の特性
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の上のFrame Relayのために作られています。 以下として制限をまとめることができます。
- Limited Label Space: either the standardized or the implemented
number of bits available for a label can be small (e.g. VPI/VCI
space, DLCI space), limiting the number of LSPs that can be
established.
- 株式会社のラベルスペース: ラベルに有効なビットの標準化か実行された数のどちらかが少ない場合があります(例えば、VPI/VCIスペース、DLCIスペース)、設立できるLSPsの数を制限して。
- 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.
- 合併します: LSPsの合併を妨げて、これらの技術のいくつかのL2技術か実現が多点から多点からポイント、そして/または、多点への'接続'を支持しません。
- 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が配備されるとき、上の制限は消え失せます。 そのうえ、MPLSユニキャストとマルチキャストのための異なったEtherTypesが定義されるので[ローズ]、PPPとイーサネットリンクの上では、同時に、ユニキャストとマルチキャストLSPに同じラベルを使用できます。
Ooms, et al. Informational [Page 4] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[4ページ]のRFC3353IPマルチキャスト
3. Taxonomy of IP Multicast Routing Protocols in the Context of MPLS
3. MPLSの文脈のIPマルチキャストルーティング・プロトコルの分類学
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
- 集合--洪水とPrune--ソース/共有された木--SourceとShared Treesの共存--Uni/双方向の共有された木--要約のマルチキャストデータ--無輪の岬
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マルチキャストルーティング・プロトコルがインターネットで配備されるのは、不可能ではありません。
3.1. Aggregation
3.1. 集合
In unicast different destination addresses are aggregated to one entry in the routing table, yielding one FEC and one LSP.
ユニキャストの異なった目的地では、1FECと1LSPをもたらして、アドレスが経路指定テーブルの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)のための共有された木と(S、G)のためのもの(*、G)です。 1LSPに関する異なったマルチキャスト'目的地'アドレスがあるマルチキャスト木の集合はさらなる研究への対象です。
3.2. Flood & Prune
3.2. 洪水とプルーン
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:
浸水してください。そうすれば、Pruneマルチキャストルーティング・プロトコルはユニキャストルーティング・プロトコルとかなり異なっているいくつかの特性を持っています:
Ooms, et al. Informational [Page 5] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[5ページ]のRFC3353IPマルチキャスト
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) 揮発性。 プロトコルのFlood&Prune本質のため、非常に揮発性の木構造は発生します。 シグナリングオーバーヘッドとLSP準備時間で効率的になるL2 p2mp LSPの必要性にダイナミックなL3 p2mp木を写像するソリューション。 揮発性の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.
- したがって、そのままで通常、ユニキャストでしていた状態でLSPsをあらかじめ設立できません。 交通到着と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(Demandラベル広告での上流のUnsolicitedかDownstream)を作成するイニシアチブを取るのを必要とさえします。
3.3. Source/Shared Trees
3.3. ソース/共有された木
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)あたり1本の木か共有された木(*、G)(すなわち、マルチキャストグループ(図1)あたり1本の木)のどちらかを作成します。
R1 R1 R1
S1 / / /
\ / / /
\ / / /
C---R2 S1---R2 S2---R2
/ \ \ \
/ \ \ \
S2 \ \ \
R3 R3 R3
R1 R1 R1 S1///\///\///C---R2 S1---R2 S2---R2/\\\/\\\S2\\\R3 R3 R3
Figure 1. Shared tree and Source trees
図1。 共有された木とSource木
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個のラベル対ソースとグループあたり1個のラベル)より少ないラベルを消費するということです。
Ooms, et al. Informational [Page 6] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[6ページ]のRFC3353IPマルチキャスト
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)へのLSPsに含意されます。 詰まるところ、mp2mp LSPsを実行するという問題は、より早く議論した合併している問題になります。
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.
実際には、グループの新しい源を発見するのにしばしば共有された木を使用するだけであり、非常に低いbitratesでソース木への転換をすることに注意してください。
3.4. Co-existence of Source and Shared Trees
3.4. ソースと共有された木の共存
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.Twoケースが以下で説明されると述べると主張できます。 送付者のSiと受信機Riとtopologiesを仮定してください。 RPはRendezvous Pointです。 NiはLSRsです。 数がインタフェース番号である、「レッジ」はRegisterインタフェースです。 すべてのIGMPとPIM Join/プルーンのメッセージが数字に示されます。 また、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は共有されるのからソース木までの転換を示しています。 N1-N2-N5を通してR1からRPまでの最短パスがあると仮定してください。 N1(受信機R1(DRrecv)のDesignated Router)は、ソース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
PJ IJ PJS PJS->1 2->1 2->1 2R1-----N1------N2------N3----S1 3| |3 IJ=Igmpは接合します。||PPS| PJ=Pimは(*、G)を接合します。|vPJ| PJS=PimはIJ PJを接合します(S1、G)。| PJ| PPS=Pimプルーン(S1、G)の->->。|3 ->。| R2-----N4------N5------RP----S2 1 2 1 2 1
Figure 2
図2
Ooms, et al. Informational [Page 7] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[7ページ]のRFC3353IPマルチキャスト
The multicast routing states created in the Multicast Routing Table (MRT) are:
Multicastルート設定Table(台北新交通システム)に創設されたマルチキャストルーティング州は以下の通りです。
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):N1のレッジ>1(すなわち、入って来るitf=レッジ; 出発しているitf=1): (*、G):N2の2>1: (*、G):3>1(S1、G): N3の2>1: (S1、G):N4の1歳の2>のレッジ: (*、G):N5の2>1: (*、G):3(S1、G)RPT-ビット: 2>1、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は、転換がなくても、州の共存が起こることができるのを示します。 送付者からのマルチキャスト交通が送付者のDesignated Routerに状態を創設する、(S、G)(DRsend。 図3のN3はS)のDRsendです。 共有された木の上の各ノードには、状態があります(*、G)。 したがって、木の上のDRsendには、(*、G)と(S、G)状態の両方があります。 また、DRsendが木であるなら、SのためにRPに向かってプルーンを送るでしょう、すべてのノードにブランチ(図3のN1とN2)を持っている最初のルータまで状態を創設して(S、G)。
S
PPS PPS |
PJ PJ PJ |2 PJ IJ
1 <- 1 3<- <- | <- <- PJ=Pim Join
RP------N1----N2----N3----N4----R1 IJ=Igmp Join
^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G)
PJ|| IJ
1| <-
N5----R2
2
Figure 3
S PPS PPS| PJ PJ PJ|2 PJ IJ1<1 3<-<。| <。 <。 PJ=PimはRPを接合します。------N1----N2----N3----N4----R1 IJ=Igmpは^を接合します。|2 1 2 1 3 1 2PPS=Pimプルーン(S、G)のPJ|| IJ1| <。 N5----R2 2数値3
The multicast routing states created in the MRT are:
台北新交通システムで創設されたマルチキャストルーティング州は以下の通りです。
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):N1のレッジ>1(すなわち、入って来るitf=レッジ; 出発しているitf=1): (*、G):3(S、G)RPT-ビット: 1>2、N2の1>2: (*、G):1>の2(S、G)RPT-ビット:N3の1>でないなにも: (*、G):1>3(S、G): N4の3歳の2>のレッジ: (*、G):N5の1>2: (*、G):1>2
Ooms, et al. Informational [Page 8] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[8ページ]のRFC3353IPマルチキャスト
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の交通が両方の入って来るインタフェースで一時到着できるだけである、(*、G) そして、(S、G)エントリー(図2のN5と図3のN1がプルーンのメッセージを処理するまで)。 このタイプのノードで写しパケットL3推進の一時的な推進を避けるのを適用できます。 人が気にしないなら、一時的な写しパケットL2推進を適用できます。 この場合、(*、G)、および(S、G)流れが溶け込まれなければならない、(*、G) それらの一般的な外向的なインタフェースのLSP。
2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3). The
(*, G) and (S, G) state have the same incoming interface. The (S,
G) traffic must be extracted from the (*, G) stream. In MPLS this
state co-existence can be handled in several ways. Four
approaches to this problem will be described:
2) (S、G) RPT-ビットで、(図2のN5、図3のN1)を設定してください。 (*、G)、および(S、G)州には、同じ入って来るインタフェースがあります。 (*、G)流れから(S、G)交通を抜粋しなければなりません。 MPLSでは、いくつかの方法でこの州の共存を扱うことができます。 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) この州の共存を扱う最初の方法は、L3でLSPsを終えて、このグループのすべての交通を進めることです。 しかしながら、外向的なインタフェースのない(S、G)エントリーが台北新交通システム(図3のN2)に加えられるといけないので、L3へのリターンを避けることができます。 このエントリーは一時交通を受けるだけでしょう。 この場合は人は、(S、G)状態を無視して、存在(*、G)を維持できました。 LSP、非常に短い間写し交通である不都合。
b) A second approach is to assign source specific labels on the
nodes of the shared tree. Multiple labels will be associated
with one (*, G) entry, corresponding to one label per active
source. Since the nodes only know which sources are active
when traffic from these sources arrives, the LSPs cannot be
pre-established and a fast LSP setup method is favorable.
b) 2番目のアプローチは共有された木の節で特定のラベルをソースに割り当てることです。 複数のラベルが、1つ(*、G)のエントリーに関連していて、活発なソースあたり1個のラベルに対応するようになるでしょう。 LSPsをあらかじめ設立できません、そして、ノード以来、これらのソースからの交通が到着するとき、どのソースが活発であるかを単に知ってください、そして、速い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番目の道はソース木だけをlabelswitchedして、L3でいつも共有された木における交通を進めるということです。 これは、共有された木がソースがだれであるかを見つけるのに受信機のための方法として使用されるだけであると仮定します。 非常にすぐに木の出典を明示する低bitrate転換敷居であり、1つがそれを確実にすることができるのを構成するのによる受信機転換。
Ooms, et al. Informational [Page 9] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[9ページ]のRFC3353IPマルチキャスト
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番目のアプローチ、(S、G)を持っているLSRで 非ヌルoifがある状態にRPT噛み付いて、次に、(S、G)がRPに向かったそれぞれの上流のLSRによって上流のLSRとこのラベル広告に伝播されるので、ラベルの広告を出します。 専用LSPがRPからLSRまでの(S、G)交通に作成されるこのよう、(S、G) RPT-ビット状態。 後者のLSRで(S、G) LSPが合併されている、(*、G) 適切な外向的なインタフェースへのLSP。 これは、共有された木の上を移動する(S、G)パケットがSを剪定したどんなLSRの先でもそれを作らないのを確実にします。
3.5. Uni/Bi-directional Shared Trees
3.5. Uni/双方向の共有された木
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
| | | | | |
S1 S2|| || v| <。 <。 <。 <。 |<<に対して| ->->->->。| ->。----N----M----M----M----M----M----N|| || || || || || |v|v|v|v|v|v| | | | | |
Figure 4.
Multicast traffic flows from 2 senders on a bidirectional tree
図4。 マルチキャスト交通は双方向の木の上の2人の送付者から流れます。
In Figure 5 the same situation for unidirectional shared trees is depicted. In this case the data of the senders is tunneled towards the root node R, yielding only a single merging point, namely the root of the shared tree itself.
図5では、単方向の共有された木のための同じ状況は叙述されます。 この場合、送付者のデータは根のノードRに向かってトンネルを堀られます、ポイントを合併するシングル、すなわち、共有された木自体の根だけをもたらして。
S1
tunnel || S2
<----- v| tunnel ||
to R<------------------------- v|
-> -> | -> -> -> -> | ->
----N----N----N----N----N----N----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
S1トンネル|| S2<。----- v| トンネル|| 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人の送付者から流れます。
Ooms, et al. Informational [Page 10] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[10ページ]のRFC3353IPマルチキャスト
3.6. Encapsulated Multicast Data
3.6. 要約のマルチキャストデータ
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.
単方向の共有された木の源と双方向の共有された木の非会員源は根のノードに向かってデータを要約します。 そして、データは根のノードでdecapsulatedされます。 マルチキャストデータのカプセル化と被膜剥離術は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(カプセル化)のRegisterインタフェースで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が(セクション4)を進めながら混ぜられたL2/L3を支持するなら、Registerインタフェース以外のすべての外向的なインタフェースでL2でまだDRsendの(S、G)交通を進めることができます。
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を組み立てることができます。
3.7. Loop-free-ness
3.7. 無輪の岬
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.
現在の、輪の検出は自由民主党で構成可能なオプションです、そして、輪の防止のためのメカニズムの決定は延期されます。
3.8. Mapping of Characteristics on Existing Protocols
3.8. 既存のプロトコルの特性に関するマッピング
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マルチキャストルーティング・プロトコルに関する非完全なりストのためにTable1にまとめられます: DVMRP[プーサ]、MOSPF[MOY]、CBT[ボール]、PIM-DM[アダム]、PIM-Sm[鹿]、SSM[HOLB]、Sm[パール]。
Ooms, et al. Informational [Page 11] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[11ページ]のRFC3353IPマルチキャスト
+------------------+------+------+------+------+------+------+------+ | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM | +------------------+------+------+------+------+------+------+------+ |Aggregation |no |no |no |no |no |no |no | +------------------+------+------+------+------+------+------+------+ |Flood & Prune |yes |no |no |yes |no |no |option| +------------------+------+------+------+------+------+------+------+ |Tree Type |source|source|shared|source|both |source|shared| +------------------+------+------+------+------+------+------+------+ |State Co-existence|no |no |no |no |yes |no |no | +------------------+------+------+------+------+------+------+------+ |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi | +------------------+------+------+------+------+------+------+------+ |Encapsulation |no |no |yes |no |yes |no |yes | +------------------+------+------+------+------+------+------+------+ |Loop Free |no |no |no |no |no |no |no | +------------------+------+------+------+------+------+------+------+
+------------------+------+------+------+------+------+------+------+ | |DVMRP|MOSPF|CBT|PIM-DM|PIM-Sm|SSM|Sm| +------------------+------+------+------+------+------+------+------+ |集合|いいえ|いいえ|いいえ|いいえ|いいえ|いいえ|いいえ| +------------------+------+------+------+------+------+------+------+ |洪水とプルーン|はい|いいえ|いいえ|はい|いいえ|いいえ|オプション| +------------------+------+------+------+------+------+------+------+ |木のタイプ|ソース|ソース|共有されます。|ソース|両方|ソース|共有されます。| +------------------+------+------+------+------+------+------+------+ |州の共存|いいえ|いいえ|いいえ|いいえ|はい|いいえ|いいえ| +------------------+------+------+------+------+------+------+------+ |Uni/双方向です。|なし|なし|2|なし|uni|uni|2| +------------------+------+------+------+------+------+------+------+ |カプセル化|いいえ|いいえ|はい|いいえ|はい|いいえ|はい| +------------------+------+------+------+------+------+------+------+ |無料で輪にしてください。|いいえ|いいえ|いいえ|いいえ|いいえ|いいえ|いいえ| +------------------+------+------+------+------+------+------+------+
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.
Flood&Prune L3木がL2木に写像されるとき、1つが引き出すことができるTable1から、例えば、そのDVMRPは多くのラベルを消費するでしょう。 DVMRPがソース木を使用するので、ラベルの切り換えが適用されているとき、その上、それは合併している問題を全く経験しません。 同様に、他のプロトコルのためにテーブルを解釈できます。
4. Mixed L2/L3 Forwarding in a Single Node
4. ただ一つのノードにおけるMixed L2/L3推進
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つの外向的なインタフェースがあるので、L3(図6)のL2 ORで交通を進めます。 ものがケースであると考えることができる1つ以上の外向的なインタフェースにマルチキャスト交通を送ることができるので、L2の上と、そして、L3(図7)の上の他のブランチにいくつかのブランチへのその交通を送ります。
+--------+ +--------+
| L3 | | L3 |
| +>>+ | | |
| | | | | |
+--|--|--+ +--------+
| | | | | |
->-----+ +-----> ->------>>----->
| L2 | | L2 |
+--------+ +--------+
+--------+ +--------+ | L3| | L3| | + >>+| | | | | | | | | +--|--|--+ +--------+ | | | | | | ->、-、-、-、--+ +----->->。------>>、-、-、-、--、>| L2| | L2| +--------+ +--------+
Figure 6. Unicast forwarding on resp. L3 or L2
図6。 respにおけるユニキャスト推進。 L3かL2
Ooms, et al. Informational [Page 12] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[12ページ]のRFC3353IPマルチキャスト
+--------+ +--------+ +--------+
| L3 | | L3 | | L3 |
| +>>++ | | +>>+ | | |
| | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+
+--------+ +--------+ +--------+ | L3| | L3| | L3| | + >>++| | + >>+| | | | | || | | | | | | | +--|--||-+ +--|--|--+ +--------+ | | |+---->|、| +----->| +---->->。-----+ | | | |L2| ->、-、-、-、--、>>、-+ | | L2+----->->。-----+ >>。------>| L2+---->+--------+ +--------+ +--------+
Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2
図7。 respにおけるマルチキャスト推進。 L3、混ぜられたL2/L3またはL2
Nodes that support this 'mixed L2/L3 forwarding' feature allow splitting of a multicast tree into branches in which some are forwarded at L3 while others are switched at L2.
この'複雑な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におけるそれらの交通を得るそれらのブランチで進められないことに注意しなければなりません。 Multicastルート設定Tableで例えば、提供でこれを余分なビット達成できます。
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(エイト環)がブランチのためのLSR Bに向かったMPLS縁のノードとLSR C.に向かったブランチのためのMPLSコアノードであると仮定してください。複雑なL2/L3推進は、Cに向かったブランチがLSR AでL3へのリターンで擾乱されないのを許容します。
+-------------+
| MPLS cloud |
| N |
| / \ |
| / \ |
| / \ |
| A N |
|/ \ \ |
| \ \ |
/| \ |
B | C |
| |
+-------------+
+-------------+ | MPLS雲| | N| | / \ | | / \ | | / \ | | N| |/ \ \ | | \ \ | /| \ | B| C| | | +-------------+
Figure 8. Mixed L2/L3 forwarding in node A
エイト環。 ノードAにおけるMixed L2/L3推進
Ooms, et al. Informational [Page 13] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[13ページ]のRFC3353IPマルチキャスト
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で説明されるように交通駆動の引き金のDownstream UnsolicitedかUpstreamがDemandラベル分配モードにある使用を可能にします。
5. Taxonomy of IP Multicast LSP Triggers
5. IPマルチキャストLSP引き金の分類学
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木に写像してください。(それは、Multicastルート設定Tableで利用可能です)。 交通が全くなくても、マッピングをします。
c) Traffic driven: the L3 tree is mapped onto a L2 tree when data
arrives on the tree.
c) 交通駆動: データが木の上で到着するとき、L3木はL2木に写像されます。
5.1. Request Driven
5.1. 追い立てられた要求
5.1.1. General
5.1.1. 一般
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.
外向的(ラベルが川下のLSRによって要求されているのが必要である)か入って来る(ラベルが上流のLSRによって要求されているのが必要である)コントロールメッセージの妨害でLSPsの設立を引き起こすことができます。 図9はこれらの2つのケースを例証します。
LSRu LSRd LSRu LSRd
-------+ +--- ---+ +-------
| control | | control |
<---*<-----message------- <-------message-------*----
| | | | | |
trigger| | | | | |trigger
| | bind | | bind | |
+--------or---------> <---------or----------+
| bind-request | | bind-request |
| | | |
| | | |
|----data----->| |-----data---->|
LSRu LSRd LSRu LSRd-------+ +--- ---+ +------- | コントロール| | コントロール| <--*<、-、-、-、--メッセージ------- <、-、-、-、-、-、--メッセージ-------*---- | | | | | | 引き金| | | | | |引き金| | ひも| | ひも| | +--------または---------><。---------または----------+ | ひも要求| | ひも要求| | | | | | | | | |----データ----->| |-----データ---->|
incoming outgoing
入来外向的です。
Figure 9. Request driven trigger
(interception of resp. incoming and outgoing control messages)
図9。 駆動引き金を要求してください。(resp送受信のコントロールメッセージの妨害)
Ooms, et al. Informational [Page 14] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[14ページ]のRFC3353IPマルチキャスト
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を設立すると決めて、それは自由民主党ひも(上流のUnsolicitedモード)か自由民主党のひもの要求(Demandモードの川下の)をLSRdに送るでしょう。
Currently, for multicast, we can identify two important types of control messages: the multicast routing messages and the resource reservation messages.
現在、マルチキャストのために、私たちは2つの重要なタイプに関するコントロールメッセージを特定できます: マルチキャストルーティング・メッセージと資源予約メッセージ。
5.1.2. Multicast Routing Messages
5.1.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のJoinメッセージ。 しかしながら、IPマルチキャストルーティング・プロトコル自体を変更する費用でこのタイプの引き金[FARI]を支えるために注意のそのDVMRPとPIM-DMを適合させることができます!
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 Join+CBT Join-Ack)と軟性国家の両方を作成できます(定期的に例えばPIM-SM Joinsを送ります)。 後者は、木のメンテナンスのために、より多くのコントロール交通を発生させて、その結果、さらに処理するのを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.
マルチキャストルーティング・プロトコルメッセージに基づく引き金は'ルーティング計算'がMulticastルート設定TableがMPLSモジュールで繰り返されることを決定するためにマルチキャストルーティングデーモンで実行した不都合を持っています。 前者はL3で使用される木を決定して、L2によって使用されるように、後者は同じ木について計算します。 同じタスクが二度実行されるので、Multicastルート設定Table自身から抜粋された情報に基づいてマルチキャスト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.
最初のルータにはホストが二地点間接続がいるとき、1つは、マルチキャストルーティング・メッセージだけではなく、また、IGMP Join/プルーンのメッセージ([フェン])も傍受することによって、'エンドユーザまでのLSPs'を作成するかもしれません。
5.1.3. Resource Reservation Messages
5.1.3. 資源予約メッセージ
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:
ユニキャストのためのケースのように、LSPsを証明するのに引き金としてRSVP Resvメッセージを使用できます。 マルチキャストグループの源はRSVP Pathメッセージを木の下側に送るでしょう、とそして、受信機がRSVP Resvメッセージで返答できます。 RSVPがマルチキャストのためにユニキャストのためにするように等しくよくスケーリングする、:
Ooms, et al. Informational [Page 15] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[15ページ]のRFC3353IPマルチキャスト
a) RSVP Resv messages can merge.
a) RSVP Resvメッセージは合併できます。
b) RSVP Resv messages are only sent up to the first branch which made
the required reservation.
b) RSVP Resvメッセージを必要な予約をした最初のブランチまで送るだけです。
5.2. Topology Driven
5.2. 運転されたトポロジー
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.
Multicastルート設定Table(台北新交通システム)はIPマルチキャストルーティング・プロトコルデーモンによって維持されます。 MPLSモジュールはこのL3木のトポロジー情報をL2 p2mp LSPsに写像します。
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モジュールは、木のtopologiesを抽出するために台北新交通システムに投票できます。 あるいはまた、直接台北新交通システムへのどんな変化のMPLSモジュールにも通知するようにマルチキャストデーモンを変更できます。
The disadvantage of this method is that labels are consumed even when no traffic exists.
この方法の不都合は交通が全く存在さえしないとき、ラベルが消費されるということです。
5.3. Traffic Driven
5.3. 追い立てられた交通
5.3.1. General
5.3.1. 一般
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.
交通駆動の引き金の方法は交通を運ぶ木のためにLSPsを組み立てるだけでしょう。 それはトポロジー駆動の方法より少ないラベルを消費します、マルチキャスト木の上に交通があるときだけ、ラベルを割り当てるとき。
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(DemandかUpstream Unsolicitedモードの川下の)によって要求されているラベル分配モードを必要とします。 図10では、あるグループのためのLSPがLSRd1に存在して、別のLSRd2が木に合流したがっていると仮定してください。 LSRd2が引き金を開始するように、それは既に木からの交通を受けなければなりません。 L2において、または、L3にこれはあることができます。 前のケースは、鶏肉と卵の問題です。 後者のケースは、LSRuで能力を進める混ぜられたL2/L3が、L3が分岐すると言い足すのを必要とします。
Ooms, et al. Informational [Page 16] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[16ページ]のRFC3353IPマルチキャスト
+--------+
| LSRd1 |
| |
+--------+ | L3 |
| LSRu | +--------+
| | | |
| L3 | +-------------------------->
+--------+ / | L2 |
| | / +--------+
->-------------+
| L2 | +--------+
+--------+ | LSRd2 |
| |
| L3 |
+--------+
| |
| |
| L2 |
+--------+
+--------+ | LSRd1| | | +--------+ | L3| | LSRu| +--------+ | | | | | L3| +-------------------------->+--------+ / | L2| | | / +--------+ ->。-------------+ | L2| +--------+ +--------+ | LSRd2| | | | L3| +--------+ | | | | | L2| +--------+
Figure 10. The LSRu has to request the label.
図10。 LSRuはラベルを要求しなければなりません。
5.3.2. An Implementation Example
5.3.2. 実現の例
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.
選ぶことによって、適切な引き金1がその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プラットホームにおける現在の実現には、Multicast Forwarding Cache(MFC)があります。 MFCはMulticastルート設定Tableのキャッシュされたコピーです。 入って来るマルチキャストパケットのための'キャッシュミス'を経験するとき、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測定値でアップデートする必要があります。
Ooms, et al. Informational [Page 17] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[17ページ]のRFC3353IPマルチキャスト
5.4. Combinations of Triggers and Label Distribution Modes
5.4. 引き金とラベル分配モードの組み合わせ
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) |
+----------------+-----------+----------+-----------+----------+
+----------------+---------------------------------------------+ | | 要求されたラベル| | | LSRu| LSRd| | +----------------------+----------------------+ | | 上流|川下|川下|上流| | |求められていません|要求に関して|求められていません|要求に関して| +----------------+-----------+----------+-----------+----------+ |追い立てられた要求| | | | | |(入って来るmsg) | X| X| | | +----------------+-----------+----------+-----------+----------+ |追い立てられた要求| | | | | |(出発しているmsg) | | | X| X| +----------------+-----------+----------+-----------+----------+ |運転されたトポロジー| X| X| X| X| +----------------+-----------+----------+-----------+----------+ |追い立てられた交通| X| X| (X) | (X) | +----------------+-----------+----------+-----------+----------+
Table 2. Valid combinations of triggers and label distribution modes
2を見送ってください。 引き金とラベル分配モードの有効な組み合わせ
6. Piggy-backing
6. 便乗します。
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つの別々のメッセージにラベル広告を送ることの代わりにそれを背負うことができるのを観測できます。 マルチキャストtwoピギーバックに関しては、候補は存在します:
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などのプロトコルには、ラベルマッピングを運ぶことができた明白なJoinメッセージがあります。 このアプローチは[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.
マルチキャストルーティング・メッセージで便乗する賛否両論は現在、説明されるでしょう。
Ooms, et al. Informational [Page 18] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[18ページ]のRFC3353IPマルチキャスト
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つの自由民主党の機能(発見と隣接番組)も背負われるとき。
d) Piggy-backing assumes the Downstream Unsolicited label
distribution mode, this excludes a number of trigger methods (see
Table 2).
d) 便乗は、Downstream Unsolicitedラベル分配がモードであると仮定して、これは多くの引き金の方法を除きます(Table2を見てください)。
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) 同輩ノードの信頼できるコミュニケーションを保証して、通常、自由民主党をTCPの上で経営しています。 便乗しているラベル広告はしばしば信頼できるコミュニケーションを周期的な軟性国家ラベル広告に取り替えます。 この周期的なラベル広告のために、コントロール交通(バイト数における)は増加するでしょう。
Ooms, et al. Informational [Page 19] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[19ページ]のRFC3353IPマルチキャスト
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通知メカニズム[名賀]を必要とするなら、通常、新設されたVCを通して自由民主党ひもを送ることによって、(バンド)の通知ができます。 このようだけに、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マルチキャスト解決策のちょうど1つの可能な成分です。
7. Explicit Routing
7. 明白なルート設定
Explicit routing for unicast refers to overriding the unicast routing table by using LSPs.
ユニキャストのための明白なルーティングはLSPsを使用することによってユニキャスト経路指定テーブルをくつがえすのを示します。
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最短パスルートの代わりに)を使用するということです。
8. QoS/CoS
8. QoS/CoS
8.1. DiffServ
8.1. DiffServ
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.
Differentiated Servicesアプローチをまた、マルチキャストに適用できます。 それは、よりすばらしい流れの粒状(余分な識別因子としてのDiffServ Codepoint(DSCP))を導入します。 送付者は異なったDSCPsと共に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)木をLSPsに写像できます。 この場合、1つは様々なDSCPsのために異なった属性があるLSPsを作成できます。 しかしながら、木の工事メカニズム自体が入力としてDSCPをみなさない限り、これらのLSPsがまだ同じルートを使用していることに注意してください。
Ooms, et al. Informational [Page 20] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[20ページ]のRFC3353IPマルチキャスト
8.2. IntServ and RSVP
8.2. IntServとRSVP
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.
QoSと共にマルチキャスト木をセットアップするのにRSVPを使用できます。 重要なマルチキャスト問題はどうL2(それがIPで解決されていないという注意)に'異種の受信機'パラダイムを写像するかに関する問題です。 この対象は[CRAW]で取り組まれます。 実際的なアプローチは、ベストエフォート型サービスを許す'限られたHeterogeneity Model'と、独身の交互のQoS(例えばRSVP Pathメッセージで送付者によって提案されたQoS)と独身のQoSだけを許容する'均質のModel'です。
The first approach will construct full trees for each service class. The sender has to send its traffic twice across the network (e.g. 1 best-effort and 1 QoS tree). Both trees can be label switched.
最初のアプローチはそれぞれのサービスのクラスのために完全木を組み立てるでしょう。 送付者はネットワーク(例えば、1本のベストエフォート型木と1本のQoS木)の向こう側に二度交通を送らなければなりません。 両方の木は切り換えられたラベルであるかもしれません。
The second approach constructs one tree and the best-effort users are connected to the QoS tree. If the branches created for best-effort users are not to be label switched, (thus carried by a hop-by-hop default LSP) the QoS multicast traffic has to be merged onto these default LSPs. This function can be provided by the 'mixed L2/L3 forwarding' feature described in section 4. If this is not available, merging is necessary to avoid a return to L3 in the QoS LSP.
2番目のアプローチは1本の木を組み立てます、そして、ベストエフォート型ユーザはQoS木に接続されます。 ベストエフォート型ユーザのために創設されたブランチによる切り換えられて、(ホップごとのデフォルトLSPによってこのようにして運ばれます)のラベルでないつもりであるなら、QoSマルチキャスト交通はこれらのデフォルトLSPsに合併されなければなりません。 セクション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サービスカテゴリに関するマッピングは[ガー]で研究されます。
9. Multi-access Networks
9. マルチアクセスネットワーク
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はリンクの上のすべての広告を出しているラベルを暗記します、どれか容認されたaが関連グループのためにそれで接合しないでも。 LSRがマルチアクセスリンクに加えられるならリンクの上の別のLSRからのこの情報を検索しなければならない、軟性国家ラベル広告の場合に、ラベルを割り当てることができる前にそれはさもなければ、ある時間を待つことができます。 LSRsがラベルを割り当てるなら、'同時に'最も高いIPアドレスがあるLSRはそれを保つかもしれません、他のLSRsがラベルを引っ込めますが。
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がマルチアクセスリンクに加えられるなら、ラベル範囲が再び交渉されなければならなくて、ことによると既存のLSPsは取りこわされて、他のラベルで再建されます。
Ooms, et al. Informational [Page 21] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[21ページ]のRFC3353IPマルチキャスト
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) マルチアクセスに従って、ラベル配分に責任があるようにリンク1LSRを選出できました。 LSRがラベルを必要とすると、それはこのLabel Allocation 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:
ユニキャストケースと異なって、マルチキャストの流れはすべてが同じラベルを使用するために持っている1つ以上の川下の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]は共有されたリンクの上のすべてのLSRsへのラベル広告をマルチキャストに提案します。 マルチキャストが信頼できないので、時間内にラベル広告写しをもたらして、これは周期的なラベル広告を必要とします。
2) Another approach is that an LSR unicasts its label advertisements
in a reliable way (TCP) to all other (or to all interested) LSRs
on the shared link. In this approach the hard-state character of
LDP can be maintained but the label advertisement is duplicated in
space.
2) 別のアプローチ、それがLSRユニキャストである、すべてへの他の信頼できる道(TCP)(または、すべてに関心がある)におけるそのラベル広告 共有のLSRsはリンクします。 このアプローチでは、自由民主党の固い州のキャラクタを維持できますが、ラベル広告はスペースにコピーされます。
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.
彼らに長い寿命があって、共有されたリンクの上のLSRsの数が限られているのでLSPsが報酬を与えているだけであるので、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.
マルチアクセスネットワークにおけるマルチキャストの別の問題は上流の、または、川下のラベル課題を使用するかどうかということです。 マルチキャスト交通において、1マルチキャスト木に属すリンクあたり1つの上流のノードしかあることができないので、上流のラベル配分は、より簡単です。 この(上流)のノードはFECのためにユニークなラベルを割り当てることができます。 川下の配分と共に、マルチアクセスリンクの上に与えられた木のための複数の川下のノードがあるかもしれません。 各ノードはリンクの上にマルチキャストFECあたり1個の単一のラベルを思いつくために何らかの解決の過程を必要とする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変化が変化すると、これは起こるかもしれません。
10. More Issues
10. より多くの問題
10.1. TTL Field
10.1. TTL分野
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値を設定することによってマルチキャストパケットの範囲を制限するのに使用されます。
Ooms, et al. Informational [Page 22] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[22ページ]のRFC3353IPマルチキャスト
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)をサポートしないLSRsでは、範囲制限機能は影響を受けます。 人があらかじめLSPが横断するホップの数について計算できたと仮定してください。 そして、ユニキャストでは、LSPはイングレスか出口ノードで減少できましたTTLが、評価する。 TTLは、マルチキャストのために、木のすべての枝が異なった長さを持つことができて、TTLが、ゼロであると判明するなら潜在的に帯域幅を浪費する出口ノードで減少するので、否定的であるだけである場合があります。
10.2. Independent vs. Ordered Label Distribution Control
10.2. 命令されたラベル配給統制に対して独立しています。
Current Label Distribution Terminology is only defined for unicast. The following sections explore what this terminology might mean in a multicast context.
現在のLabel Distribution Terminologyはユニキャストのために定義されるだけです。 以下のセクションはこの用語がマルチキャスト文脈で意味するかもしれないことについて調査します。
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.
無党派Control([ANDE])では、各LSRはラベルマッピングをするイニシアチブを取ることができます。 次のホップからラベルを既に受けたときだけ、Ordered Control([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)が無党派Controlに結合します。 ラベル分配が駆動アプローチが無党派Controlと共に使用されるという要求であるならOrdered Controlのようにまだ振る舞っていることに注意してください: ラベル広告に同じ系列を課して、コントロールメッセージは出口ノード上流から流れます。
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推進を支えないといけないので、交通駆動の引き金には、命令されたControlは適切ではありません。 Table2によると、本件は、ラベルが上流のLSRによって要求されているのを含意します。 図11でLSPがSからR1まで存在していて、新しいブランチをR2に加えなければならないと仮定してください。 ラベルが既にB-Cリンクに割り当てられる場合にだけ、BはA-Bリンクの上のラベルを受け入れるでしょう。 しかしながら、B-Cリンクの上のラベルを証明するために、Bは既にA-Bリンクにおける交通を受けなければなりません。
N---N---R1
/
/
S -----A
\
\
B---C---R2
N---N---R1//S-----\\B---C---R2
Figure 11.
図11。
Ooms, et al. Informational [Page 23] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[23ページ]のRFC3353IPマルチキャスト
10.3. Conservative vs. Liberal Label Retention Mode
10.3. 寛容なラベル保有モードに対して保守的です。
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:
保守党員Mode([ANDE])では、推進データ(FECのための次のホップがラベルの広告を出したLSRであるなら)に使用されるラベルだけが、割り当てられて、維持されます。 自由党員では、Modeラベルは、すべての隣人に広告を出して、維持されます。 寛容なModeはマルチキャストで理解できません。 これのために2つの理由を特定できます:
1) All LSRs have a route for each unicast FEC. This is not true for
multicast FECs.
1) すべてのLSRsには、各ユニキャストFECのためのルートがあります。 マルチキャストFECsには、これは本当ではありません。
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は、いつもラベル要求かラベル地図メッセージを送るのをどの隣人に知っているか。 例えば、ユニキャストDownstream Unsolicitedモード(以下を見る)で、LSRはラベルマッピングをどこに送るかを知らないで、その結果、すべての隣人にマッピングを送らなければなりません。 この場合自由党員Modeを支持する場合、余分なメッセージは発生しません、そして、(それはまだ余分な州の情報とラベルスペースを必要としています)その結果、低いと自由党員Modeを支持する敷居を考えることができました。
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 |
+---------+----------------+-----------------+
+---------+----------------------------------+ | | 要求されたラベル| | | LSRu| LSRd| +---------+----------------+-----------------| |ユニキャスト| はい| いいえ| +---------+----------------+-----------------| |マルチキャスト| はい| はい| +---------+----------------+-----------------+
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はUpstream UnsolicitedかDownstreamの場合にDemandモードで要求を送るものです)。 前のホップをどんなにも見つけることができないかなら、LSRはそうです。 前のホップが必ずソースに向かった次のホップであるというわけではない、AからBまでの経路が必ず経路とBからA.Suchまで同じであるというわけではないので、非対称のリンクの結果が測定するか、または複数の等しい費用経路が存在している場合[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は次のホップと前のホップの両方を知っています。 マルチキャスト木が逆の最短パス方法を使用することで組み立てられるので、いつも前のホップはソースか木の根に向かった次のホップです。
Ooms, et al. Informational [Page 24] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[24ページ]のRFC3353IPマルチキャスト
10.4. Downstream vs. Upstream Label Allocation
10.4. 上流のラベル配分に対して川下です。
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(Demand、Downstream Unsolicitedの川下の)か上流のLSR(Demand、Upstream Unsolicitedの上流の、そして、暗黙の)のどちらかがラベルを割り当てることができます。 川下のラベル配分の利点は以下の通りです。
a) It is the same mode as for unicast LDP, thus eliminating the need
to develop upstream label distribution procedures.
a) それはユニキャスト自由民主党のように同じモードであって、その結果、上流のラベル分配手順を開発する必要性を排除します。
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.
この枠組みの範囲の外に上流の、または、川下のラベル分配を使用するかどうかがあります。 相対的な操作上の複雑さと同様に必要である必要なプロトコル拡大と解決メカニズムの間の相対的な複雑さは行くどの方法に影響を及ぼすだろうか。
10.5. Explicit vs. Implicit Label Distribution
10.5. 暗黙のラベル分配に対して明白です。
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]は、未知のラベルを使用することによって、暗黙のラベル分配方法を提案します。 この方法は、上流のラベル配分方法のすべての利点を持って、たぶん交通の引き起こされたLSPsのための最も速いラベル広告方法です。
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を特定するのに必要なすべての情報がパケットに存在しているというわけではないなら)。
Ooms, et al. Informational [Page 25] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[25ページ]のRFC3353IPマルチキャスト
Explicit distribution allows pre-establishment (before the arrival of data) of LSPs with topology or request driven triggers.
明白な分配はトポロジーか要求によるLSPsのプレ設立(データの到着の前の)に駆動引き金を許容します。
11. Security Considerations
11. セキュリティ問題
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.
マルチキャスト木が既存のマルチキャストルーティング・プロトコルで決定するとき(これは本書ではされた仮定です、Explicitルート設定部以外に)、明確に追加担保問題は全く木の形に関して紹介されません(交通、…を注入して、例えば、権限のない接合、叩きがblackholingされて)。 これらの安全保障問題はマルチキャストルーティング・プロトコルの仕様に記述されるべきでした。
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資源配分(例えば、LSPs)の引き金となるのは、可能です。 セキュリティー・フローが既存のプロトコル(ことによるとオリジナルの文脈でそれほど有害でない)でまだ存在しているなら、そのようなコントロールメッセージの虐待的な発信は、より厳しい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.
の場合に、「明白である、発送されて、ネットワーク・ノードで木をセットアップするコントロールメッセージで」 中心で計算されて、十分な認証である木をしなければなりません。
12. Acknowledgements
12. 承認
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、フィリップ・デュモルティエ、ハンス・Deネーブ、ジャン・バンフート、アレックスMondrus、およびジェラードGastaudに感謝したがっています。
Ooms, et al. Informational [Page 26] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[26ページ]のRFC3353IPマルチキャスト
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、「速い気圧セル輸送(IPSOFACTO)の上で以下を切り換えるIP」 「切り換えMulticastは流れる」IEEE Globecom97年。
[ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent
Multicast Version 2 Dense Mode Specification", Work In
Progress.
「[アダム]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.トーマス、「自由民主党仕様」、RFC3036、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.Srinivasan、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing
Architecture", RFC 2201, September 1997.
[ボール] Ballardie、A.、「コアのベースの木(CBT)のマルチキャストルート設定構造」、RFC2201、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、「フレームリレーネットワークにおけるラベルの切り換えの使用」、RFC3034、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.
[餌袋]クローリー、E.、バーガー、L.、Berson、S.、ベイカー、F.、ボーデン、M.、およびJ.Krawczyk、「気圧での統合サービスとRSVPのための枠組み」、RFC2382(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.
[ダヴィ]デイビーとB.とローレンスとJ.とMcCloghrieとK.、RekhterとY.とローゼンとE.とSwallowとG.とP.Doolan、「自由民主党とATM VCの切り換えを使用するMPLS」RFC3035(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.、Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびLウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、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] 「マルチキャストルートにMPLSラベルを分配するのにPIMを使用し」て、D.ファリナッチ、Y.Rekhter、E.ローゼン、およびT.チエンは進行中で働いています。
[FENN] Fenner, W., "Internet Group Management Protocol, IGMP,
Version 2", RFC 2236, November 1997.
w.[フェン]フェナー、「インターネット集団経営は1997年11月にRFC2236についてIGMP、バージョン2インチ議定書の中で述べます」。
[GARR] Garrett, M. and M. Borden, "Interoperation of Controlled-Load
Service and Guaranteed Service with ATM", RFC 2381, August
1998.
[ガー]ギャレットとM.とM.ボーデン、「気圧との制御負荷サービスと保証されたサービスのInteroperation」、RFC2381、1998年8月。
Ooms, et al. Informational [Page 27] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[27ページ]のRFC3353IPマルチキャスト
[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] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[NAGA] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan,
"VCID Notification over ATM link for LDP", RFC 3038, January
2001.
[名賀]のNagami、K.、Demizu、N.、江崎、H.、Katsube、Y.、およびP.Doolan、「ATMの上のVCID Notificationは自由民主党のためにリンクします」、RFC3038、2001年1月。
[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
Maufer, "Simple Multicast", Work In Progress.
[パール] R.パールマン、C-Y。 リー、A.Ballardie、J.クロウクロフト、Z.ワング、「簡単なマルチキャスト」というT.Mauferは進行中で働いています。
[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol",
Work In Progress.
「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」という[プーサ]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.パクソン、「インターネットの終わりから終わりへのルート設定振舞い」、Networking 5(5)、ページのIEEE/ACM Transactions 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.
[上昇しました] ローゼン、E.、Rekhter、Y.、タッパン、D.、ファリナッチ、D.、Fedorkow、G.、李、T.、およびA.コンタ、「MPLSはスタックコード化をラベルします」、RFC3032、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
短剣のオームスアルカテル法人のリサーチセンター、フラン。 Wellesplein1、2018アントワープ(ベルギー)。 以下に電話をしてください。 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
バーナード販売アルカテル法人のリサーチセンター、フラン。 Wellesplein1、2018アントワープ(ベルギー)。 以下に電話をしてください。 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
ヴィムはコルト電子通信Zweefvliegtuigstraat10、ブリュッセル(ベルギー)が電話をする1130を賑します: 32 2 7901705ファックス: 32 2 7901711 メール: WLivens@colt-telecom.be
Ooms, et al. Informational [Page 28] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[28ページ]のRFC3353IPマルチキャスト
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
アーラップAcharya IBM TJワトソン研究所30製材機械川の道路、ニューヨーク 10532が電話をするサンザシ: 1 7481年の914 784メール: arup@us.ibm.com
Frederic Griffoul Ulticom, Inc. Les Algorithmes, 2000 Route des Lucioles, BP29 06901 Sophia-Antipolis, FRANCE EMail: griffoul@ulticom.com
フレディリックGriffoulアルティコムInc.レスAlgorithmes、2000台のRoute desルシオール、BP29 06901ソフィア-Antipolis、フランス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ベル研究所、透明な技術者。 Holmdel、ニュージャージー 101Crawfordsコーナー通り、07733は以下に電話をします。 1 5249年の732 949ファックス: 1 4556年の732 949メール: furquan@dnrc.bell-labs.com
Ooms, et al. Informational [Page 29] RFC 3353 IP Multicast in an MPLS Environment August 2002
オームス、他 MPLS環境2002年8月の情報[29ページ]のRFC3353IPマルチキャスト
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Ooms, et al. Informational [Page 30]
オームス、他 情報[30ページ]
一覧
スポンサーリンク
