RFC2117 日本語訳
2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): ProtocolSpecification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1997. (Format: TXT=151886 bytes) (Obsoleted by RFC2362) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Estrin
Request for Comments: 2117 USC
Category: Experimental D. Farinacci
CISCO
A. Helmy
USC
D. Thaler
UMICH
S. Deering
XEROX
M. Handley
UCL
V. Jacobson
LBL
C. Liu
USC
P. Sharma
USC
L. Wei
CISCO
June 1997
Estrinがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2117年のUSCカテゴリ: 実験的なD.のシャルマUSC L.ウェイコクチマスファリナッチコクチマスA.Helmy USC D.ターレルUMICH S.デアリングゼロックスM.ハンドレーUCL V.ジェーコブソンLBL C.リュウUSC P.1997年6月
Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification
独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください: プロトコル仕様
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Acknowledgements
承認
The author list has been reordered to reflect the involvement in detailed editorial work on this specification document. The first four authors are the primary editors and are listed alphabetically. The rest of the authors, also listed alphabetically, participated in all aspects of the architectural and detailed design but managed to get away without hacking the latex!
作者リストは、この仕様ドキュメントへの詳細な編集の作業にかかわり合いを反映するために再命令されました。 最初の4人の作者が、第一のエディタであり、アルファベット順に、記載されています。 また、アルファベット順に、記載された作者の残りは、建築していて詳細なデザインの全面に参加しましたが、ハッキングなしでラテックスを何とか離れさせました!
Estrin, et. al. Experimental [Page 1] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [1ページ]実験的なRFC2117PIM-Sm1997年6月
1 Introduction
1つの序論
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups as defined in [1][2]. This document describes the protocol details. For the motivation behind the design and a description of the architecture, see [1][2]. Section 2 summarizes PIM-SM operation. It describes the protocol from a network perspective, in particular, how the participating routers interact to create and maintain the multicast distribution tree. Section 3 describes PIM-SM operations from the perspective of a single router implementing the protocol; this section constitutes the main body of the protocol specification. It is organized according to PIM-SM message type; for each message type we describe its contents, its generation, and its processing.
このドキュメントは、効率的に広い領域(そして、相互ドメイン)インターネットにかかるかもしれないマルチキャストグループに掘るためにプロトコルについて説明します。 私たちはプロトコル無党派Multicastとアプローチを呼びます--まばらなMode(PIM-SM)はどんな特定のユニキャストルーティングにも依存していないので、議定書を作ります、そして、それが設計されているので、サポートまばらに、[2]は[1]で定義されるように分類されています。 このドキュメントはプロトコルの詳細について説明します。 デザインの後ろの動機と構造の記述に関しては、[1][2]を見てください。 セクション2はPIM-SM操作をまとめます。 それはネットワーク見解からプロトコルについて説明します、特に、参加ルータが、マルチキャスト分配木を作成して、維持するためにどう相互作用するか。 セクション3はプロトコルを実行するただ一つのルータの見解からPIM-SM操作について説明します。 このセクションはプロトコル仕様の本体を構成します。 PIM-SMメッセージタイプに従って、それは組織化されます。 それぞれのメッセージタイプのために、私たちはコンテンツ、世代、およびその処理について説明します。
Sections 3.8 and 3.9 summarize the timers and flags referred to throughout this document. Section 4 provides packet format details.
セクション3.8と3.9はこのドキュメント中に示されたタイマと旗をまとめます。 セクション4はパケット・フォーマット詳細を明らかにします。
The most significant functional changes since the January '95 version involve the Rendezvous Point-related mechanisms, several resulting simplifications to the protocol, and removal of the PIM-DM protocol details to a separate document [3] (for clarity).
1月の95年のバージョン以来の最も重要な機能的な変化はRendezvous Point関連のメカニズム、プロトコルへのいくつかの結果として起こる簡素化、および別々のドキュメント[3]へのPIM-DMプロトコルの詳細の取り外し(明快のための)にかかわります。
2 PIM-SM Protocol Overview
2PIM-Smプロトコル概観
In this section we provide an overview of the architectural components of PIM-SM.
このセクションに、私たちはPIM-SMの建築構成の概観を供給します。
A router receives explicit Join/Prune messages from those neighboring routers that have downstream group members. The router then forwards data packets addressed to a multicast group, G, only onto those interfaces on which explicit joins have been received. Note that all routers mentioned in this document are assumed to be PIM-SM capable, unless otherwise specified.
川下のグループのメンバーがいるそれらの隣接しているルータから、ルータは明白なJoin/プルーンのメッセージを受け取ります。 ルータの当時のフォワードデータ・パケットがマルチキャストグループ、それらのインタフェースだけにオンなGに明白な状態でどれを記述したか、接合、受け取ってください、そうした。 別の方法で指定されない場合、本書では言及されたすべてのルータができるPIM-SMであると思われることに注意してください。
A Designated Router (DR) sends periodic Join/Prune messages toward a group-specific Rendezvous Point (RP) for each group for which it has active members. Each router along the path toward the RP builds a wildcard (any-source) state for the group and sends Join/Prune messages on toward the RP. We use the term route entry to refer to the state maintained in a router to represent the distribution tree. A route entry may include such fields as the source address, the group address, the incoming interface from which packets are accepted, the list of outgoing interfaces to which packets are sent,
Designated Router(DR)はそれが活動的なメンバーがいる各グループのためにグループ特有のRendezvous Point(RP)に向かって周期的なJoin/プルーンのメッセージを送ります。 RPに向かった経路に沿った各ルータがワイルドカードを組立てる、(いくらか、-、ソース、)、RPに向かってオンなメッセージをJoin/プルーンにグループのために述べて、送ります。 私たちは、分配木を表すためにルータで維持された状態について言及するのに用語ルートエントリーを使用します。 ルートエントリーはソースアドレスのような分野を含むかもしれません、グループアドレス、パケットが受け入れられる入って来るインタフェース、パケットが送られる外向的なインタフェースのリスト
Estrin, et. al. Experimental [Page 2] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [2ページ]実験的なRFC2117PIM-Sm1997年6月
timers, flag bits, etc. The wildcard route entry's incoming interface points toward the RP; the outgoing interfaces point to the neighboring downstream routers that have sent Join/Prune messages toward the RP. This state creates a shared, RP-centered, distribution tree that reaches all group members. When a data source first sends to a group, its DR unicasts Register messages to the RP with the source's data packets encapsulated within. If the data rate is high, the RP can send source-specific Join/Prune messages back towards the source and the source's data packets will follow the resulting forwarding state and travel unencapsulated to the RP. Whether they arrive encapsulated or natively, the RP forwards the source's decapsulated data packets down the RP-centered distribution tree toward group members. If the data rate warrants it, routers with local receivers can join a source-specific, shortest path, distribution tree, and prune this source's packets off of the shared RP-centered tree. For low data rate sources, neither the RP, nor last-hop routers need join a source-specific shortest path tree and data packets can be delivered via the shared, RP-tree.
タイマ、フラグビットなど ワイルドカードルートエントリーの入って来るインタフェースはRPに向かって指します。 外向的なインタフェースはJoin/プルーンにメッセージを送った隣接している川下のルータをRPに向かって示します。 この州はすべてのグループのメンバーに届く共有されて、RP中心の分配木を作成します。 データ送信端末が最初にグループに発信するとき、パケットが中のソースのデータを要約していたRPへのそのDRユニキャストRegisterメッセージです。 データ信号速度が高いなら、RPはソース特有のJoin/プルーンのメッセージをソースに向かって送って戻すことができます、そして、ソースのデータ・パケットはRPに非要約された結果として起こる推進状態と旅行に続くでしょう。 要約されていた状態で到着するか、またはネイティブであることにかかわらず、RPはグループのメンバーに向かったRP中心の分配木の下側にソースのdecapsulatedデータ・パケットを送ります。 データ信号速度がそれを保証するなら、地方の受信機があるルータは、ソース詳細、最短パス、分配木に合流して、共有されたRP中心の木からこのソースのパケットを剪定できます。 低データ速度ソースに、RPも最後でないホップでないのもルータはソース特有の最短パス木に加わらなければなりません、そして、共有(RP-木)を通してデータ・パケットを届けることができます。
The following subsections describe SM operation in more detail, in particular, the control messages, and the actions they trigger.
以下の小区分はその他の詳細におけるSM操作、特にコントロールメッセージ、およびそれらが引き金となる動作について説明します。
2.1 Local hosts joining a group
2.1 仲間に入る地元のホスト
In order to join a multicast group, G, a host conveys its membership information through the Internet Group Management Protocol (IGMP), as specified in [4][5], (see figure 1). From this point on we refer to such a host as a receiver, R, (or member) of the group G.
マルチキャストグループ、Gを接合するために、ホストは[4][5]で指定されるようにインターネットGroup Managementプロトコル(IGMP)を通して会員資格情報を伝えます(1図を参照してください)。 この地点から先は私たちはグループGについて受信機、R(または、メンバー)のようなホストについて言及します。
Note that all figures used in this section are for illustration and are not intended to be complete. For complete and detailed protocol action see Section 3.
このセクションで使用されるすべての数字がイラストのためにあって、完全であることを意図しないことに注意してください。 完全で詳細なプロトコル動きがセクション3を見るので。
[Figures are present only in the postscript version]
Fig. 1 Example: how a receiver joins, and sets up shared tree
[数字は追伸バージョンだけに存在しています] 図1Example: 受信機は、どう共有された木に合流して、セットアップするか。
When a DR (e.g., router A in figure 1) gets a membership indication from IGMP for a new group, G, the DR looks up the associated RP. The DR creates a wildcard multicast route entry for the group, referred to here as a (*,G) entry; if there is no more specific match for a particular source, the packet will be forwarded according to this entry.
G、DR(例えば、1図のルータA)が新しいグループのためにIGMPから会員資格指示を得るとき、DRは関連RPを見上げます。 DRは(*、G)エントリーとしてここと呼ばれたグループのためにワイルドカードマルチキャストルートエントリーを作成します。 特定のソースへのそれ以上の特定のマッチがないと、このエントリーに応じて、パケットを進めるでしょう。
Estrin, et. al. Experimental [Page 3] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [3ページ]実験的なRFC2117PIM-Sm1997年6月
The RP address is included in a special field in the route entry and is included in periodic upstream Join/Prune messages. The outgoing interface is set to that included in the IGMP membership indication for the new member. The incoming interface is set to the interface used to send unicast packets to the RP.
RPアドレスは、ルートエントリーにおける特別な分野に含まれていて、周期的な上流のJoin/プルーンのメッセージに含まれています。 外向的なインタフェースは新しいメンバーのためのIGMP会員資格指示にそれを含んでいることへのセットです。 入って来るインタフェースはユニキャストパケットをRPに送るのに使用されるインタフェースに設定されます。
When there are no longer directly connected members for the group, IGMP notifies the DR. If the DR has neither local members nor downstream receivers, the (*,G) state is deleted.
グループの直接接続されたメンバーがもういないとき、IGMPはDRに通知します。DRに地元会員も川下の受信機もないなら、(*、G)状態は削除されます。
2.2 Establishing the RP-rooted shared tree
2.2 RPが根づいている共有された木を設立すること。
Triggered by the (*,G) state, the DR creates a Join/Prune message with the RP address in its join list and the the wildcard bit (WC- bit) and RP-tree bit (RPT-bit) set to 1. The WC-bit indicates that any source may match and be forwarded according to this entry if there is no longer match; the RPT-bit indicates that this join is being sent up the shared, RP-tree. The prune list is left empty. When the RPT-bit is set to 1 it indicates that the join is associated with the shared RP-tree and therefore the Join/Prune message is propagated along the RP-tree. When the WC-bit is set to 1 it indicates that the address is an RP and the downstream receivers expect to receive packets from all sources via this (shared tree) path. The term RPT- bit is used to refer to both the RPT-bit flags associated with route entries, and the RPT-bit included in each encoded address in a Join/Prune message.
(*、G)状態によって引き起こされます、中にRPアドレスがある状態でDRがJoin/プルーンのメッセージを作成する、それ、リストとワイルドカードビット(トイレビット)とRP-木のビット(RPTによって噛み付かれた)セットに1で加わってください。 トイレビットは、どんなソースも合うかもしれなくて、マッチがもうなければこのエントリーに応じて転送されるのを示します。 RPT-ビットは、これが接合するのを示します。共有、RP-木に送ります。 プルーンのリストは空のままにされます。 RPT-ビットが1に設定されるとき、それを示す、接合、共有されたRP-木としたがって、Join/プルーンに関連づけられて、メッセージはRP-木に沿って伝播されます。 トイレビットが1に設定されるとき、それは、アドレスがRPであり、川下の受信機が、この(共有された木)経路を通してすべてのソースからパケットを受けると予想するのを示します。 ビットという用語RPTはルートエントリーに関連している両方のRPT-ビット旗を示すのに使用されました、そして、それぞれにRPT-ビットを含んでいると、Join/プルーンのメッセージのアドレスはコード化されました。
Each upstream router creates or updates its multicast route entry for (*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set. The interface on which the Join/Prune message arrived is added to the list of outgoing interfaces (oifs) for (*,G). Based on this entry each upstream router between the receiver and the RP sends a Join/Prune message in which the join list includes the RP. The packet payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit, Prune=NULL.
それぞれの上流のルータは、(*、G)のためのRPT-ビットとトイレビットセットでJoin/プルーンを受けるときのマルチキャストルートエントリーを作成するか、またはアップデートします。 Join/プルーンのメッセージが到着したインタフェースは(*、G)のために外向的なインタフェース(oifs)のリストに追加されます。 リストを接合してください。受信機とRPの間のそれぞれの上流のルータが送るこのエントリーに基づいてa Join/プルーンが中でどれを通信させるか、RPを含んでいます。 パケットペイロードはG、Join=RP、トイレで噛み付いていて、RPTによって噛み付かれたMulticast-アドレス=Prune=NULLを含んでいます。
2.3 Hosts sending to a group
2.3 グループに発信するホスト
When a host starts sending multicast data packets to a group, initially its DR must deliver each packet to the RP for distribution down the RP-tree (see figure 2). The sender's DR initially encapsulates each data packet in a Register message and unicasts it to the RP for that group. The RP decapsulates each Register message and forwards the enclosed data packet natively to downstream members on the shared RP-tree.
ホストが初めはマルチキャストデータ・パケットをグループに送り始めるとき、DRは分配のためにRP-木で各パケットをRPに渡さなければなりません(2が計算するのを確実にしてください)。 送付者のDRは初めは、Registerメッセージとユニキャストで各データ・パケットをカプセルに入れります。それはそれのためのRPに分類されます。 各Registerが通信させるRP decapsulatesと同封のデータパケットが共有されたRP-木の上で川下のメンバーにネイティブであるフォワード。
[Figures are present only in the postscript version]
Fig. 2 Example: a host sending to a group
[数字は追伸バージョンだけに存在しています] 図2Example: グループに発信するホスト
Estrin, et. al. Experimental [Page 4] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [4ページ]実験的なRFC2117PIM-Sm1997年6月
If the data rate of the source warrants the use of a source-specific shortest path tree (SPT), the RP may construct a new multicast route entry that is specific to the source, hereafter referred to as (S,G) state, and send periodic Join/Prune messages toward the source. Note that over time, the rules for when to switch can be modified without global coordination. When and if the RP does switch to the SPT, the routers between the source and the RP build and maintain (S,G) state in response to these messages and send (S,G) messages upstream toward the source.
ソースのデータ信号速度がソース特有の最短パス木(SPT)の使用を保証するなら、RPはソースに、特定の新しいマルチキャストルートエントリーを組み立てて、今後(S、G)と状態を呼んで、周期的なJoin/プルーンのメッセージをソースに向かって送るかもしれません。 時間がたつにつれてグローバルなコーディネートなしでいつ切り替わるか間の規則を変更できることに注意してください。 いつ切り替わるか、そして、RPがSPT、ソースの間のルータに切り替わるか、そして、RPは上流へソースに向かって建てて、これらのメッセージに対応して状態を維持して(S、G)、メッセージを送ります(S、G)。
The source's DR must stop encapsulating data packets in Registers when (and so long as) it receives Register-Stop messages from the RP. The RP triggers Register-Stop messages in response to Registers, if the RP has no downstream receivers for the group (or for that particular source), or if the RP has already joined the (S,G) tree and is receiving the data packets natively. Each source's DR maintains, per (S,G), a Register-Suppression-timer. The Register- Suppression-timer is started by the Register-Stop message; upon expiration, the source's DR resumes sending data packets to the RP, encapsulated in Register messages.
ソースのDRは、RPからRegister-停止メッセージを受け取るとき、Registersでデータ・パケットをカプセルに入れるのを止めなければなりません。 RPはRegistersに対応してRegister-停止メッセージの引き金となります、RPがRPではグループのためのどんな川下の受信機もないか(またはその特定のソースに)、既に(S、G)木に合流して、またはネイティブにデータ・パケットを受けているなら。 各ソースのDRは(S、G)単位でRegister抑圧タイマを維持します。 Register抑圧タイマはRegister-停止メッセージによって始動されます。 満了のときに、ソースのDRは、Registerメッセージで要約されたRPにデータ・パケットを送るのを再開します。
2.4 Switching from shared tree (RP-tree) to shortest path tree (SP-
tree)
2.4 共有された木(RP-木)から最短パス木に切り替わること。(SP木)
A router with directly-connected members first joins the shared RP- tree. The router can switch to a source's shortest path tree (SP- tree) after receiving packets from that source over the shared RP- tree. The recommended policy is to initiate the switch to the SP-tree after receiving a significant number of data packets during a specified time interval from a particular source. To realize this policy the router can monitor data packets from sources for which it has no source-specific multicast route entry and initiate such an entry when the data rate exceeds the configured threshold. As shown in figure 3, router `A' initiates a (S,G) state.
直接接続されたメンバーがいるルータは最初に、共有されたRP木に合流します。 共有されたRP木の上のそのソースからパケットを受けた後に、ルータはソースの最短パス木(SP木)に切り替わることができます。 お勧めの方針は指定された時間間隔の間、特定のソースから多くのデータ・パケットを受けた後にSP-木にスイッチを開始することです。 データ信号速度が構成された敷居を超えていると、ルータは、この方針がわかるために、それがどんなソース特有のマルチキャストルートエントリーも持っていないソースからデータ・パケットをモニターして、そのようなエントリーを開始できます。 (S、G)状態を3図、ルータにおける開始に見せているように。
[Figures are present only in the postscript version]
Fig. 3 Example: Switching from shared tree to shortest path tree
[数字は追伸バージョンだけに存在しています] 図3Example: 共有された木から最短パス木に切り替わること。
When a (S,G) entry is activated (and periodically so long as the state exists), a Join/Prune message is sent upstream towards the source, S, with S in the join list. The payload contains Multicast- Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the outgoing interface list is copied from (*,G), i.e., all local shared tree branches are replicated in the new shortest path tree. In this way when a data packet from S arrives and matches on this entry, all receivers will continue to receive the source's packets along this path. (In more complicated scenarios, other entries in the router have to be considered, as described in Section 3). Note that (S,G)
(S、G)エントリーが活性であるときに(そして、状態と同じくらい長い間、定期的に存在しています)、上流へJoin/プルーンのメッセージをソースに向かって送ります、S、中にSがある状態でリストを接合してください。 ペイロードはG、Join=S、Multicastアドレス=Prune=NULLを含んでいます。 (S、G)エントリーが作成されるとき、送信するインタフェースリストは(*、G)からコピーされます、すなわち、すべての地方の共有された木の枝が新しい最短パス木で模写されます。 Sからのデータ・パケットがこのエントリーのときに到着して、合っているとき、すべての受信機が、このように、この経路に沿ってソースのパケットを受け続けるでしょう。 (より複雑なシナリオでは、ルータにおける他のエントリーはセクション3で説明されるように考えられなければなりません。) それに注意してください。(S、G)
Estrin, et. al. Experimental [Page 5] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [5ページ]実験的なRFC2117PIM-Sm1997年6月
state must be maintained in each last-hop router that is responsible for initiating and maintaining an SP-tree. Even when (*,G) and (S,G) overlap, both states are needed to trigger the source-specific Join/Prune messages. (S,G) state is kept alive by data packets arriving from that source. A timer, Entry-timer, is set for the (S,G) entry and this timer is restarted whenever data packets for (S,G) are forwarded out at least one oif, or Registers are sent. When the Entry-timer expires, the state is deleted. The last-hop router is the router that delivers the packets to their ultimate end-system destination. This is the router that monitors if there is group membership and joins or prunes the appropriate distribution trees in response. In general the last-hop router is the Designated Router (DR) for the LAN. However, under various conditions described later, a parallel router connected to the same LAN may take over as the last-hop router in place of the DR.
それぞれのSP-木を開始して、維持するのに原因となる最後のホップルータで状態を維持しなければなりません。 (*、G)と(S、G)が重なるときさえ、両方の州がソース特有のJoin/プルーンのメッセージの引き金となるのが必要です。 (S、G) 状態はそのソースから到着するデータ・パケットによって生かされます。 タイマ(Entry-タイマ)は(S、G)エントリーのときに予定されます、そして、このタイマによる(S、G)のためのデータ・パケットがそうであるときはいつも、再開されて、外に送って、少なくとも1つがoifするか、またはRegistersを送るということです。 Entry-タイマが期限が切れるとき、状態は削除されます。 最後のホップルータはそれらの究極のエンドシステム送付先にパケットを届けるルータです。 これは、応答で適切な分配木をグループ会員資格があればそれがモニターするルータであり、合流するか、または剪定します。 一般に、最後のホップルータはLANのためのDesignated Router(DR)です。 しかしながら、後で説明された様々な条件のもとで、同じLANに関連づけられた平行なルータは最後のホップルータとしてDRに代わって引き継ぐかもしれません。
Only the RP and routers with local members can initiate switching to the SP-tree; intermediate routers do not. Consequently, last-hop routers create (S,G) state in response to data packets from the source, S; whereas intermediate routers only create (S,G) state in response to Join/Prune messages from downstream that have S in the Join list.
地元会員がいるRPとルータだけがSP-木との切り換えを開始できます。 中間的ルータはそうしません。 その結果、最後のホップルータはソース、Sからのデータ・パケットに対応して状態を創設します(S、G)。 中間的ルータは川下からのJoinにSを持っているJoin/プルーンのメッセージに対応して状態を創設するだけですが(S、G)、記載してください。
The (S,G) entry is initialized with the SPT-bit cleared, indicating that the shortest path tree branch from S has not yet been setup completely, and the router can still accept packets from S that arrive on the (*,G) entry's indicated incoming interface (iif). Each PIM multicast entry has an associated incoming interface on which packets are expected to arrive.
SPT-ビットがきれいにされている状態で、(S、G)エントリーは初期化されます、Sからの最短パス木の枝がまだ完全にセットアップであるというわけではなく、ルータがまだSからの(*、G)エントリーの示された入って来るインタフェース(iif)で到着するパケットを受け入れることができるのを示して。 それぞれのPIMマルチキャストエントリーには、パケットが到着すると予想される関連入って来るインタフェースがあります。
When a router with a (S,G) entry and a cleared SPT-bit starts to receive packets from the new source S on the iif for the (S,G) entry, and that iif differs from the (*,G) entry's iif, the router sets the SPT-bit, and sends a Join/Prune message towards the RP, indicating that the router no longer wants to receive packets from S via the shared RP-tree. The Join/Prune message sent towards the RP includes S in the prune list, with the RPT-bit set indicating that S's packets must not be forwarded down this branch of the shared tree. If the router receiving the Join/Prune message has (S,G) state (with or without the route entry's RPT-bit flag set), it deletes the arriving interface from the (S,G) oif list. If the router has only (*,G) state, it creates an entry with the RPT-bit flag set to 1. For
(S、G)エントリーがあるルータとクリアされたSPT-ビットが(S、G)エントリーへのiifの上の新しいソースSからパケットを受け始めて、iifが異なっている、(*、G) エントリーのiif、ルータはRP、ルータがもう共有されたRP-木を通してSからパケットを受けたがっていない表示に向かってSPT-ビットを設定して、Join/プルーンのメッセージを送ります。 RPに向かって送られたJoin/プルーンのメッセージはプルーンのリストにSを含んでいます、RPT-ビットセットが、共有された木のこの枝の下側にSのパケットを送ってはいけないのを示していて。 Join/プルーンのメッセージを受け取るルータが状態(ルートエントリーのRPT-ビット旗のセットのあるなしにかかわらず)を持っているなら(S、G)、それは(S、G)oifリストから到着インタフェースを削除します。 ルータに状態しかないなら、それはRPT-ビット旗のセットによるエントリーを1に作成します。 for
Estrin, et. al. Experimental [Page 6] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [6ページ]実験的なRFC2117PIM-Sm1997年6月
brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1 as an (S,G)RPT-bit entry. This notational distinction is useful to point out the different actions taken for (S,G) entries depending on the setting of the RPT-bit flag. Note that a router can have no more than one active (S,G) entry for any particular S and G, at any particular time; whether the RPT-bit flag is set or not. In other words, a router never has both an (S,G) and an (S,G)RPT-bit entry for the same S and G at the same time. The Join/Prune message payload contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit.
簡潔さ、私たちは(S、G)RPT-ビットエントリーとしてRPT-ビット旗を1に設定する(S、G)エントリーについて言及します。 この記号法の区別は、RPT-ビット旗の設定に依存する(S、G)エントリーに取られた異なった行動を指摘するために役に立ちます。 特定の何時でもルータがどんな特定のSとGのための1つ未満の活発な(S、G)エントリーも持つことができることに注意してください。 RPT-ビット旗は設定されるのであるかどうか 言い換えれば、ルータには両方が決してない、(S、G) そして、同じSとGのための同時にの(S、G)RPT-ビットエントリー。 Join/プルーンのメッセージペイロードはG、Join=NULL、Prune=S、RPT Multicast-アドレス=ビットを含んでいます。
A new receiver may join an existing RP-tree on which source-specific prune state has been established (e.g., because downstream receivers have switched to SP-trees). In this case the prune state must be eradicated upstream of the new receiver to bring all sources' data packets down to the new receiver. Therefore, when a (*,G) Join arrives at a router that has any (Si,G)RPT-bit entries (i.e., entries that cause the router to send source-specific prunes toward the RP), these entries must be updated upstream of the router so as to bring all sources' packets down to the new member. To accomplish this, each router that receives a (*,G) Join/Prune message updates all existing (S,G)RPT-bit entries. The router may also trigger a (*,G) Join/Prune message upstream to cause the same updating of RPT-bit settings upstream and pull down all active sources' packets. If the arriving (*,G) join has some sources included in its prune list, then the corresponding (S,G)RPT-bit entries are left unchanged (i.e., the RPT-bit remains set and no oif is added).
新しい受信機はソース特有のプルーンの状態を設置してある既存のRP-木に合流するかもしれません(例えば、川下の受信機がSP-木に切り替わったので)。 この場合、プルーンの状態はすべてのソースのデータ・パケットを新しい受信機まで持って来る新しい受信機の根絶された上流であるに違いありません。したがって、a(*、G)がいつ接合するかはどんな(Si、G)RPT-ビットエントリー(すなわち、ルータがソース特有のプルーンをRPに向かって送るエントリー)も持っているルータに到着して、これらのエントリーは、すべてのソースのパケットを新しいメンバーまで持って来るルータのアップデートされた上流でなければなりません。 a(*、G)を受ける各ルータは、これを達成するために、メッセージ最新版を参加するか、または剪定します。すべての存在(S、G)RPT-ビットエントリー。 また、よりこぎれいなa(*、G)は、上流へRPT-ビット設定の同じアップデートを引き起こして、すべての活発なソースのパケットを引き下げるためにメッセージ上流をルータは剪定するかもしれなくて、接合するか、または剪定します。 到着(*、G)が接合するなら、次に、プルーンのリスト、対応する(S、G)RPT-ビットエントリーに何人かのソースを含んでいるのは変わりがないままにされましたか?(すなわち、RPT-ビットが設定されたままで残っています、そして、oifは全く加えられません)
2.5 Steady state maintenance of distribution tree (i.e., router state)
2.5 分配木の定常状態維持(すなわち、ルータ状態)
In the steady state each router sends periodic Join/Prune messages for each active PIM route entry; the Join/Prune messages are sent to the neighbor indicated in the corresponding entry. These messages are sent periodically to capture state, topology, and membership changes. A Join/Prune message is also sent on an event-triggered basis each time a new route entry is established for some new source (note that some damping function may be applied, e.g., a short delay to allow for merging of new Join information). Join/Prune messages do not elicit any form of explicit acknowledgment; routers recover from lost packets using the periodic refresh mechanism.
定常状態では、各ルータはそれぞれの活発なPIMルートエントリーへの周期的なJoin/プルーンのメッセージを送ります。 Join/プルーンのメッセージを対応するエントリーで示された隣人に送ります。 状態、トポロジー、および会員資格変化を得るために定期的にこれらのメッセージを送ります。 また、新しいルートエントリーが新しいソースに設置されるたびに(何らかの湿気機能が適用されるかもしれないことに注意してください、例えば新しいJoin情報を合併するために許容する少し遅れ)出来事で引き起こされたベースでJoin/プルーンのメッセージを送ります。 メッセージを接合するか、または剪定してください。どんな形式の明白な承認も引き出さないでください。 ルータは無くなっているパケット使用から周期的を取り戻します。メカニズムをリフレッシュしてください。
2.6 Obtaining RP information
2.6 RP情報を得ること。
To obtain the RP information, all routers within a PIM domain collect Bootstrap messages. Bootstrap messages are sent hop-by-hop within the domain; the domain's bootstrap router (BSR) is responsible for originating the Bootstrap messages. Bootstrap messages are used to carry out a dynamic BSR election when needed and to distribute RP information in steady state.
RP情報を得るために、PIMドメインの中のすべてのルータがBootstrapメッセージを集めます。 独力で進んでください。ホップごとにドメインの中でメッセージを送ります。 ドメインのものは(BSR)はBootstrapメッセージを溯源しながら責任があるルータを独力で進みます。 使用されるメッセージを独力で進んで、ダイナミックなBSR選挙を必要であると行って、定常状態におけるRP情報を分配してください。
Estrin, et. al. Experimental [Page 7] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [7ページ]実験的なRFC2117PIM-Sm1997年6月
A domain in this context is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the rest of the internet.
ドメインはこのような関係においてはPIMをすべて実行して、PIM Multicast Border Routers(PMBRs)によって定義された共有する境界線の中で作動するために構成される隣接のセットのルータです。 PMBRsはそれぞれのPIMドメインをインターネットの残りにつなげます。
Routers use a set of available RPs (called the {RP-Set}) distributed
in Bootstrap messages to get the proper Group to RP mapping. The
following paragraphs summarize the mechanism; details of the
mechanism may be found in Sections 3.6 and Appendix 6.2. A (small)
set of routers, within a domain, are configured as candidate BSRs
and, through a simple election mechanism, a single BSR is selected
for that domain. A set of routers within a domain are also configured
as candidate RPs (C-RPs); typically these will be the same routers
that are configured as C-BSRs. Candidate RPs periodically unicast
Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that
domain. C-RP-Advs include the address of the advertising C-RP, as
well as an optional group address and a mask length field, indicating
the group prefix(es) for which the candidacy is advertised. The BSR
then includes a set of these Candidate-RPs (the RP-Set), along with
the corresponding group prefixes, in Bootstrap messages it
periodically originates. Bootstrap messages are distributed hop-by-
hop throughout the domain.
ルータは適切なGroupをRPマッピングに手に入れるBootstrapメッセージで分配された利用可能なRPs(RP-セットと呼ばれる)の1セットを使用します。 以下のパラグラフはメカニズムをまとめます。 メカニズムの細部はセクション3.6とAppendix6.2で見つけられるかもしれません。 (小さい)のセットのルータは候補BSRsとしてドメインの中で構成されます、そして、簡単な選挙メカニズムを通して、独身のBSRはそのドメインに選択されます。 また、ドメインの中の1セットのルータは候補RPs(C-RPs)として構成されます。 通常これらはC-BSRsとして構成されるルータになるでしょう同じの。 候補RPs、定期的に、ユニキャストCandidate-RP-広告は(C-RP-Advs)をそのドメインのBSRへ通信させます。 C-RP-Advsは広告C-RPのアドレスを含んでいます、任意のグループアドレスとマスク長さの分野と同様に、立候補が広告に掲載されているグループ接頭語(es)を示して。 次に、BSRはこれらのCandidate-RPs(RP-セット)の1セットを含んでいます、対応するグループ接頭語と共に、それが定期的に溯源するBootstrapメッセージで。 ドメイン中をホップを飛び越して分配されたメッセージを独力で進んでください。
Routers receive and store Bootstrap messages originated by the BSR. When a DR gets a membership indication from IGMP for (or a data packet from) a directly connected host, for a group for which it has no entry, the DR uses a hash function to map the group address to one of the C-RPs whose Group-prefix includes the group (see Section 3.7). The DR then sends a Join/Prune message towards (or unicasts Registers to) that RP.
ルータは、BSRによって溯源されたBootstrapメッセージを、受け取って、格納します。 DRがいつの間、IGMPから会員資格指示を得るか、(データ・パケット、)、それがエントリーを全く持っていないグループの直接接続されたホスト、DRはGroup-接頭語がグループを含んでいるC-RPsの1つにグループアドレスを写像するのにaハッシュ関数を使用します(セクション3.7を見てください)。 次に、DRがJoin/プルーンのメッセージを送る、(ユニキャストRegisters、)、そのRP。
The Bootstrap message indicates liveness of the RPs included therein. If an RP is included in the message, then it is tagged as `up' at the routers; while RPs not included in the message are removed from the list of RPs over which the hash algorithm acts. Each router continues to use the contents of the most recently received Bootstrap message until it receives a new Bootstrap message.
BootstrapメッセージはそこにRPsを含む活性を示します。 RPがメッセージに含まれているなら、'up'としてルータでそれにタグ付けをします。 メッセージに含まれていなかったRPsは細切れ肉料理アルゴリズムが行動するRPsのリストから取り外されますが。 各ルータは、新しいBootstrapメッセージを受け取るまで最も最近受信されたBootstrapメッセージのコンテンツを使用し続けています。
If a PIM domain partitions, each area separated from the old BSR will elect its own BSR, which will distribute an RP-Set containing RPs that are reachable within that partition. When the partition heals, another election will occur automatically and only one of the BSRs will continue to send out Bootstrap messages. As is expected at the time of a partition or healing, some disruption in packet delivery may occur. This time will be on the order of the region's round-trip time and the bootstrap router timeout value.
PIMドメインパーティションであるなら、古いBSRと切り離された各領域はそれ自身のBSRを選出するでしょう。(そのパーティションの中で届いているRPsを含んでいて、BSRはRP-セットを分配するでしょう)。 パーティションが回復すると、別の選挙は自動的に起こるでしょう、そして、BSRsのひとりだけがBootstrapメッセージを出し続けるでしょう。 そのままで、パーティション時点で、予想されているか、または治療であり、パケット配信における何らかの分裂が起こるかもしれません。 そして、領域の往復の時間の注文には今回がある、ルータタイムアウト価値を独力で進んでください。
Estrin, et. al. Experimental [Page 8] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [8ページ]実験的なRFC2117PIM-Sm1997年6月
2.7 Interoperation with dense mode protocols such as DVMRP
2.7 DVMRPなどの濃いモードプロトコルがあるInteroperation
In order to interoperate with networks that run dense-mode,
{broadcast and prune}, protocols, such as DVMRP, all packets
generated within a PIM-SM region must be pulled out to that region's
PIM Multicast Border Routers (PMBRs) and injected (i.e., broadcast)
into the DVMRP network. A PMBR is a router that sits at the boundary
of a PIM-SM domain and interoperates with other types of multicast
routers such as those that run DVMRP. Generally a PMBR would speak
both protocols and implement interoperability functions not required
by regular PIM routers. To support interoperability, a special entry
type, referred to as (*,*,RP), must be supported by all PIM routers.
For this reason we include details about (*,*,RP) entry handling in
this general PIM specification.
濃いモードを走らせるネットワーク、放送、およびプルーンで共同利用するために、すべてのパケットがDVMRPなどのようにPIM-SM領域の中で発生させたプロトコルをその領域のPIM Multicast Border Routers(PMBRs)に引き抜かれて、DVMRPネットワークに注入しなければなりません(すなわち、放送します)。 PMBRはPIM-SMドメインの境界に座って、他のタイプのDVMRPを走らせるものなどのマルチキャストルータで共同利用するルータです。 一般にPMBRは両方のプロトコルを話して、通常のPIMルータによって必要とされなかった相互運用性機能を実行するでしょう。 相互運用性を支持するために、すべてのPIMルータで(*、*、RP)に差し向けられた特別なエントリータイプを支持しなければなりません。 この理由で、私たちはこの一般的なPIM仕様で(*、*、RP)エントリー取り扱いに関する詳細を入れます。
A data packet will match on a (*,*,RP) entry if there is no more specific entry (such as (S,G) or (*,G)) and the destination group address in the packet maps to the RP listed in the (*,*,RP) entry. In this sense, a (*,*,RP) entry represents an aggregation of all the groups that hash to that RP. PMBRs initialize (*,*,RP) state for each RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to send (*,*,RP) Join/Prune messages toward each of the active RPs in the domain. As a result distribution trees are built that carry all data packets originated within the PIM domain (and sent to the RPs) down to the PMBRs.
それ以上の特定のエントリー((S、G)や(*、G)などの)がなくて、RPへのパケット地図の送付先グループアドレスが(*、*、RP)エントリーに記載したなら、データ・パケットは(*、*、RP)エントリーのときに合うでしょう。 この意味で、(*、*、RP)エントリーはそれにRPを論じ尽くすすべてのグループの集合を表します。 PMBRsはドメインのRPsetの各RPのために状態を初期化します(*、*、RP)。 (*、*、RP)州はPMBRsを発信させます。(*、*、RP)は、そのドメインのそれぞれのアクティブなRPsに向かってメッセージを接合するか、または剪定します。 それが結果分配木に建てられるように、PIMドメイン(そして、RPsに発信する)の中で溯源されたすべてのデータ・パケットをPMBRsまで運んでください。
PMBRs are also responsible for delivering externally-generated packets to routers within the PIM domain. To do so, PMBRs initially encapsulate externally-originated packets (i.e., received on DVMRP interfaces) in Register messages and unicast them to the corresponding RP within the PIM domain. The Register message has a bit indicating that it was originated by a border router and the RP caches the originating PMBR's address in the route entry so that duplicate Registers from other PMBRs can be declined with a Register-Stop message.
また、PMBRsもPIMドメインの中のルータに外部的に発生しているパケットを届けるのに責任があります。 そうするために、PMBRsは初めは、Registerメッセージとユニキャストで外部的に溯源されたパケット(すなわち、DVMRPインタフェースでは、受信する)をカプセルに入れります。PIMドメインの中の対応RPへのそれら。 それが境界ルータによって溯源されて、RPがRegister-停止メッセージで他のPMBRsからの写しRegistersを傾けることができるようにルートエントリーで由来しているPMBRのアドレスをキャッシュするのを示しながら、Registerメッセージは少しそうしました。
All PIM routers must be capable of supporting (*,*,RP) state and interpreting associated Join/Prune messages. We describe the handling of (*,*,RP) entries and messages throughout this document; however, detailed PIM Multicast Border Router (PMBR) functions will be specified in a separate interoperability document (see directory, http://catarina.usc.edu/pim/interop/).
すべてのPIMルータが、状態を支持して(*、*、RP)、関連Join/プルーンのメッセージを解釈できなければなりません。 私たちはこのドキュメント中で(*、*、RP)のエントリーとメッセージの取り扱いについて説明します。 しかしながら、詳細なPIM Multicast Border Router(PMBR)機能は別々の相互運用性ドキュメントで指定されるでしょう(ディレクトリ、 http://catarina.usc.edu/pim/interop/ を見てください)。
2.8 Multicast data packet processing
2.8 マルチキャストデータ・パケット処理
Data packets are processed in a manner similar to other multicast schemes. A router first performs a longest match on the source and group address in the data packet. A (S,G) entry is matched first if
データ・パケットは他のマルチキャスト計画と同様の方法で処理されます。 ルータは最初に、データ・パケットでソースとグループアドレスに最も長いマッチを実行します。 (S、G)エントリーは最初に、合われています。
Estrin, et. al. Experimental [Page 9] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [9ページ]実験的なRFC2117PIM-Sm1997年6月
one exists; a (*,G) entry is matched otherwise. If neither state exists, then a (*,*,RP) entry match is attempted as follows: the router hashes on G to identify the RP for group G, and looks for a (*,*,RP) entry that has this RP address associated with it. If none of the above exists, then the packet is dropped. If a state is matched, the router compares the interface on which the packet arrived to the incoming interface field in the matched route entry. If the iif check fails the packet is dropped, otherwise the packet is forwarded to all interfaces listed in the outgoing interface list.
1つは存在しています。 (*、G)エントリーは別の方法で合われています。 どちらの状態も存在していないなら、(*、*、RP)エントリーマッチは以下の通り試みられます: ルータは、それに関連しているこのRPアドレスを持っている(*、*、RP)エントリーを、グループGのためにRPを特定するGで論じ尽くして、見ます。 上記のいずれも存在していないなら、パケットは落とされます。 状態が取り組むなら、ルータは取り組んでいるルートエントリーでパケットが入って来るインタフェース分野に到着したインタフェースを比較します。 iifチェックが失敗するなら、パケットを落とします。さもなければ、送信するインタフェースリストに記載されたすべてのインタフェースにパケットを送ります。
Some special actions are needed to deliver packets continuously while switching from the shared to shortest-path tree. In particular, when a (S,G) entry is matched, incoming packets are forwarded as follows:
いくつかの特別な動きが、共有から最短パス木に切り替わっている間、絶え間なくパケットを届けるのに必要です。 (S、G)エントリーが取り組んでいるとき、特に、以下の通り入って来るパケットを進めます:
1 If the SPT-bit is set, then:
1 次に、SPT-ビットが設定されるなら:
1 if the incoming interface is the same as a matching
(S,G) iif, the packet is forwarded to the oif-list of
(S,G).
1 入って来るインタフェースが合っている(S、G)iifと同じであるなら、(S、G)のoif-リストにパケットを送ります。
2 if the incoming interface is different than a matching
(S,G) iif , the packet is discarded.
2 入って来るインタフェースが合っている(S、G)iifと異なるなら、パケットは捨てられます。
2 If the SPT-bit is cleared, then:
2 次に、SPT-ビットがきれいにされるなら:
1 if the incoming interface is the same as a matching
(S,G) iif, the packet is forwarded to the oif-list of
(S,G). In addition, the SPT bit is set for that entry
if the incoming interface differs from the incoming
interface of the (*,G) or (*,*,RP) entry.
1 入って来るインタフェースが合っている(S、G)iifと同じであるなら、(S、G)のoif-リストにパケットを送ります。 さらに、SPTビットがインタフェースが入って来るインタフェースと異なる入来であるならそのエントリーのときに予定される、(*、G) または、(*、*、RP)エントリー。
2 if the incoming interface is different than a matching
(S,G) iif, the incoming interface is tested against a
matching (*,G) or (*,*,RP) entry. If the iif is the
same as one of those, the packet is forwarded to the
oif-list of the matching entry.
2 入って来るインタフェースが合っている(S、G)iifと異なるなら、入って来るインタフェースはマッチング(*、G)か(*、*、RP)エントリーに対してテストされます。 iifがそれらの1つと同じであるなら、合っているエントリーのoif-リストにパケットを送ります。
3 Otherwise the iif does not match any entry for G and
the packet is discarded.
3 さもなければ、iifはGのための少しのエントリーにも合わないで、パケットは捨てられます。
Data packets never trigger prunes. However, data packets may trigger actions that in turn trigger prunes. For example, when router B in figure 3 decides to switch to SP-tree at step 3, it creates a (S,G) entry with SPT-bit set to 0. When data packets from S arrive at
データ・パケットはプルーンの決して引き金となりません。 しかしながら、データ・パケットは順番にプルーンの引き金となる動作の引き金となるかもしれません。 例えば、3図のルータBが、ステップ3でSP-木に切り替わると決めると、それはSPT-ビットセットによる(S、G)エントリーを0に作成します。 Sからのデータ・パケットが到着する時
Estrin, et. al. Experimental [Page 10] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [10ページ]実験的なRFC2117PIM-Sm1997年6月
interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is different than that for (S,G). This triggers the sending of prunes towards the RP.
Bのインタフェース2、(*、G)が(S、G)のためのそれと異なっているので、BはSPT-ビットをiif以来の1に設定します。 これはRPに向かってプルーンの発信の引き金となります。
2.9 Operation over Multi-access Networks
2.9 マルチアクセスネットワークの上の操作
This section describes a few additional protocol mechanisms needed to operate PIM over multi-access networks: Designated Router election, Assert messages to resolve parallel paths, and the Join/Prune- Suppression-Timer to suppress redundant Joins on multi-access networks.
このセクションはマルチアクセスネットワークの上でPIMを操作するのに必要であるいくつかの追加議定書メカニズムについて説明します: マルチアクセスネットワークで余分なJoinsを抑圧するためにRouter選挙、平行な経路を決議するAssertメッセージ、およびプルーンの抑圧Join/タイマに指定されます。
* Designated router election
* ルータ選挙に指定されます。
When there are multiple routers connected to a multi-access network, one of them must be chosen to operate as the designated router (DR) at any point in time. The DR is responsible for sending triggered Join/Prune and Register messages toward the RP.
マルチアクセスネットワークに関連づけられた複数のルータがあるとき、代表ルータとして作動するために時間内にの任意な点でそれらの1つを選ばなければなりません(DR)。 DRは引き起こされたJoin/プルーンとRegisterメッセージをRPに向かって送るのに責任があります。
A simple designated router (DR) election mechanism is used for both SM and traditional IP multicast routing. Neighboring routers send Hello messages to each other. The sender with the largest IP address assumes the role of DR. Each router connected to the multi-access LAN sends the Hellos periodically in order to adapt to changes in router status.
簡単な代表ルータ(DR)選挙メカニズムはSMと伝統的なIPマルチキャストルーティングの両方に使用されます。 隣接しているルータは互いにメッセージをHelloに送ります。 最も大きいIPアドレスをもっている送付者はDRの役割を引き受けます。マルチアクセスLANに関連づけられた各ルータは、ルータ状態の変化に順応するために定期的にハローズを送ります。
* Parallel paths to a source or the RP--Assert process
* ソースかRPへの平行な経路--断言の過程
If a router receives a multicast datagram on a multi-access LAN from a source whose corresponding (S,G) outgoing interface list includes the interface to that LAN, the packet must be a duplicate. In this case a single forwarder must be elected. Using Assert messages addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN, upstream routers can resolve which one will act as the forwarder. Downstream routers listen to the Asserts so they know which one was elected, and therefore where to send subsequent Joins. Typically this is the same as the downstream router's RPF (Reverse Path Forwarding) neighbor; but there are circumstances where this might not be the case, e.g., when using multiple unicast routing protocols on that LAN. The RPF neighbor for a particular source (or RP) is the next-hop router to which packets are forwarded en route to that source (or RP); and therefore is considered a good path via which to accept packets from that source.
ルータがマルチアクセスLANで対応する(S、G)送信するインタフェースリストがインタフェースを含んでいるソースからそのLANまでマルチキャストデータグラムを受けるなら、パケットは写しであるに違いありません。 この場合、独身の混載業者を選出しなければなりません。 Assertメッセージを使用すると.0が'224.0まで記述された、.13、'(すべて、-、PIM-ROUTERS、グループ) LANに、望んでいる上流のルータ缶の決心は混載業者として機能します。 川下のルータがAssertsを聞くので、彼らはどれが選出されたか、そして、したがって、その後のJoinsをどこに送るかを知っています。 これは川下のルータのRPF(Path Forwardingを逆にする)隣人と通常、同じです。 しかし、例えば、そのLANに関する複数のユニキャストルーティング・プロトコルを使用するとき、事情がこれがそうでないかもしれないところにあります。 特定のソース(または、RP)が次のホップルータであるので、そのソース(または、RP)への途中で、RPF隣人をどのパケットに送るか。 そして、したがって、考えられたa良い経路はを通って受け入れるそのソースからのパケットですか?
The upstream router elected is the one that has the shortest distance to the source. Therefore, when a packet is received on an outgoing interface a router sends an Assert message on the multi-access LAN indicating what metric it uses to reach the source of the data
選出された上流のルータは最短距離がソースまであるものです。 したがって、パケットによる外向的なインタフェースに受け取って、マルチアクセスLANに関するAssertメッセージがルータでメートル法でなにかを示すかということであるときに、それはデータの源を範囲に使用します。
Estrin, et. al. Experimental [Page 11] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [11ページ]実験的なRFC2117PIM-Sm1997年6月
packet. The router with the smallest numerical metric (with ties broken by highest address) will become the forwarder. All other upstream routers will delete the interface from their outgoing interface list. The downstream routers also do the comparison in case the forwarder is different than the RPF neighbor.
パケット。 最もわずかな数字のメートル法(結びつきが最も高いアドレスによって壊されている)の意志が混載業者になったルータ。 他のすべての上流のルータがそれらの送信するインタフェースリストからインタフェースを削除するでしょう。 また、混載業者がRPF隣人と異なるといけないので、川下のルータは比較します。
Associated with the metric is a metric preference value. This is provided to deal with the case where the upstream routers may run different unicast routing protocols. The numerically smaller metric preference is always preferred. The metric preference is treated as the high-order part of an assert metric comparison. Therefore, a metric value can be compared with another metric value provided both metric preferences are the same. A metric preference can be assigned per unicast routing protocol and needs to be consistent for all routers on the multi-access network.
メートル法に関連づけられているのは、メートル法の好みの値です。 上流のルータが異なったユニキャストルーティング・プロトコルを走らせるかもしれないケースに対処するためにこれを提供します。 数の上でより小さいメートル法の好みはいつも好まれます。 メートル法の好みが高位部分として扱われる、メートル法の比較について断言してください。 したがって、両方のメートル法の好みが同じであるなら、別のメートル法の数値にメートル法の数値をたとえることができます。 メートル法の優先は、ユニキャストルーティング・プロトコル単位で割り当てることができて、マルチアクセスネットワークのすべてのルータにおいて一貫している必要があります。
Asserts are also needed for (*,G) entries since an RP-Tree and an SP-Tree for the same group may both cross the same multi- access network. When an assert is sent for a (*,G) entry, the first bit in the metric preference (RPT-bit) is always set to 1 to indicate that this path corresponds to the RP tree, and that the match must be done on (*,G) if it exists. Furthermore, the RPT-bit is always cleared for metric preferences that refer to SP-tree entries; this causes an SP- tree path to always look better than an RP-tree path. When the SP- tree and RPtree cross the same LAN, this mechanism eliminates the duplicates that would otherwise be carried over the LAN.
断言、また、RP-木と同じグループのためのSP-木がともに同じマルチアクセスネットワークに交差するかもしれないので、(*、G)エントリーに必要です。 いつ、断言、a(*、G)エントリー(この経路が相当する(RPT-ビット)が示してくださいいつも1に設定されるメートル法の好みにおけるRPが木に追い上げて、存在しているなら(*、G)でマッチをしなければならない最初のビット)に送るか。 その上、RPT-ビットはSP-木のエントリーについて言及するメートル法の好みのためにいつもきれいにされます。 これはいつもSP木の経路をRP-木の経路より良く見せます。 SP木とRPtreeが同じLANに交差するとき、このメカニズムはそうでなければLANの上まで運ばれる写しを排除します。
In case the packet, or the Assert message, matches on oif for (*,*,RP) entry, a (*,G) entry is created, and asserts take place as if the matching state were (*,G).
パケット、またはAssertメッセージが(*、*、RP)エントリーへのoifに合っているといけないので、(*、G)エントリーは、作成されて、まるで合っている状態が(*、G)であるかのように行われるように断言します。
The DR may lose the (*,G) Assert process to another router on the LAN if there are multiple paths to the RP through the LAN. From then on, the DR is no longer the last-hop router for local receivers and removes the LAN from its (*,G) oif list. The winning router becomes the last-hop router and is responsible for sending (*,G) join messages to the RP.
LANを通してRPへの複数の経路があれば、DRは(*、G)断言の過程をLANに関する別のルータに失うかもしれません。 それ以来、DRは地方の受信機のためのもう最後のホップルータでなく、(*、G)oifリストからLANを取り除きます。 勝利ルータは、最後のホップルータになって、発信して、(*、G)がメッセージを接合するので、RPに原因となります。
* Join/Prune suppression
* 抑圧を参加するか、または剪定してください。
Join/Prune suppression may be used on multi-access LANs to reduce duplicate control message overhead; it is not required for correct performance of the protocol. If a Join/Prune message arrives and matches on the incoming interface for an existing (S,G), (*,G), or (*,*,RP) route entry, and the Holdtime included in the Join/Prune message is greater than the recipient's own [Join/Prune-Holdtime] (with ties resolved in favor of the higher IP address), a timer (the Join/Prune-Suppression-timer) in the recipient's route entry may be
抑圧が使用されるかもしれない/プルーンに合流してください。減少させるマルチアクセスLANはコントロールメッセージオーバーヘッドをコピーします。 それはプロトコルの正しい性能に必要ではありません。 Join/プルーンのメッセージが存在(S、G)、(*、G)のための入って来るインタフェースで到着して、合うか、(*、*、RP)がエントリーを発送して、またはJoin/プルーンのメッセージにHoldtimeを含んでいるのが受取人が自己であるより[/プルーン-Holdtimeを接合してください](結びつきが、より高いIPアドレスを支持して決議にされるので)大きいなら、受取人のルートエントリーにおけるタイマ(プルーンの抑圧Join/タイマ)は大きいです。
Estrin, et. al. Experimental [Page 12] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [12ページ]実験的なRFC2117PIM-Sm1997年6月
started to suppress further Join/Prune messages. After this timer expires, the recipient triggers a Join/Prune message, and resumes sending periodic Join/Prunes, for this entry. The Join/Prune- Suppression-timer should be restarted each time a Join/Prune message is received with a higher Holdtime.
一層のJoin/プルーンのメッセージを削除し始めました。 このタイマが期限が切れた後に、受取人は、Join/プルーンのメッセージの引き金となって、周期的なJoin/プルーンをこのエントリーに送るのを再開します。 プルーンの抑圧Join/タイマは、より高いHoldtimeと共にJoin/プルーンのメッセージを受け取るたびに再開されるべきです。
2.10 Unicast Routing Changes
2.10 ユニキャストルート設定変化
When unicast routing changes, an RPF check is done on all active (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming interfaces are updated. In particular, if the new incoming interface appears in the outgoing interface list, it is deleted from the outgoing interface list. The previous incoming interface may be added to the outgoing interface list by a subsequent Join/Prune from downstream. Join/Prune messages received on the current incoming interface are ignored. Join/Prune messages received on new interfaces or existing outgoing interfaces are not ignored. Other outgoing interfaces are left as is until they are explicitly pruned by downstream routers or are timed out due to lack of appropriate Join/Prune messages. If the router has a (S,G) entry with the SPT-bit set, and the updated iif(S,G) does not differ from iif(*,G) or iif(*,*,RP), then the router resets the SPT-bit.
ユニキャストルーティングが変化するとき、アクティブ(S、G)でRPFチェックをして、エントリーの、そして、すべて影響を受ける予想された入来が連結する(*、G)と(*、*、RP)をアップデートします。 新しい入って来るインタフェースが送信するインタフェースリストに現れるなら、特に、それは送信するインタフェースリストから削除されます。 前の入って来るインタフェースはその後のJoin/プルーンによって川下から送信するインタフェースリストに追加されるかもしれません。 電流に受け取って、入って来るインタフェースが無視されるというメッセージを接合するか、または剪定してください。 新しいインタフェースに受け取るか、または外向的に存在していて、インタフェースが無視されないというメッセージを接合するか、または剪定してください。 それらが川下のルータによって明らかに剪定されるか、または適切なJoin/プルーンのメッセージの不足による外で調節されるまで、他の外向的なインタフェースはそのままなままにされます。 ルータでSPT-ビットによる(S、G)エントリーを設定して、アップデートされたiif(S、G)がiif(*、G)かiif(*、*、RP)と異なっていないなら、ルータはSPT-ビットをリセットします。
The router must send a Join/Prune message with S in the Join list out any new incoming interfaces to inform upstream routers that it expects multicast datagrams over the interface. It may also send a Join/Prune message with S in the Prune list out the old incoming interface, if the link is operational, to inform upstream routers that this part of the distribution tree is going away.
ルータは、インタフェースの上でマルチキャストデータグラムを予想することを上流のルータに知らせるために外のSがJoinリストにあるJoin/プルーンのメッセージにどんな新しい入って来るインタフェースも送らなければなりません。 また、それは外のSがPruneリストにあるJoin/プルーンのメッセージに古い入って来るインタフェースを送るかもしれません、リンクが分配木のこの部分が遠ざかっていることを上流のルータに知らせるために操作上であるなら。
2.11 PIM-SM for Inter-Domain Multicast
2.11 相互ドメインマルチキャストのためのPIM-Sm
Future documents will address the use of PIM-SM as a backbone inter- domain multicast routing protocol. Design choices center primarily around the distribution and usage of RP information for wide area, inter-domain groups.
将来のドキュメントは背骨相互ドメインマルチキャストルーティング・プロトコルとしてPIM-SMの使用を記述するでしょう。 デザイン選択は主として広い領域のためのRP情報、相互ドメイングループの分配と用法を中心に置きます。
2.12 Security
2.12 セキュリティ
All PIM control messages may use IPsec [6] to address security concerns. Security mechanisms are likely to be enhanced in the near future.
すべてのPIMコントロールメッセージが、安全上の配慮を記述するのにIPsec[6]を使用するかもしれません。 セキュリティー対策は近い将来、高められそうです。
3 Detailed Protocol Description
3 詳細なプロトコル記述
This section describes the protocol operations from the perspective of an individual router implementation. In particular, for each message type we describe how it is generated and processed.
このセクションは個々のルータ実現の見解からプロトコル操作について説明します。 それぞれのメッセージタイプのために、特に、私たちはそれがどう発生して、処理されるかを説明します。
Estrin, et. al. Experimental [Page 13] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [13ページ]実験的なRFC2117PIM-Sm1997年6月
3.1 Hello
3.1 こんにちは
Hello messages are sent so neighboring routers can discover each other.
こんにちは、メッセージはそうです。隣接しているルータが互いを発見できるように、送ります。
3.1.1 Sending Hellos
3.1.1 送付ハローズ
Hello messages are sent periodically between PIM neighbors, every [Hello-Period] seconds. This informs routers what interfaces have PIM neighbors. Hello messages are multicast using address 224.0.0.13 (ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to [Hello-Holdtime], for neighbors to keep the information valid. Hellos are sent on all types of communication links.
こんにちは、定期的にPIM隣人の間にメッセージを送る、あらゆる、[こんにちは、-、以上、]、秒。 これは、どんなインタフェースにPIM隣人がいるかをルータに知らせます。 こんにちは、メッセージがマルチキャスト使用アドレス224.0.0.13である、(すべて、-、PIM-ROUTERS、グループ) パケットがHoldtime、セットを含んでいる、[こんにちは、-、Holdtime、]、隣人が情報を有効に保つように。 すべてのタイプの通信リンクでハローズを送ります。
3.1.2 Receiving Hellos
3.1.2 ハローズを受けること。
When a router receives a Hello message, it stores the IP address for that neighbor, sets its Neighbor-timer for the Hello sender to the Holdtime included in the Hello, and determines the Designated Router (DR) for that interface. The highest IP addressed system is elected DR. Each Hello received causes the DR's address to be updated.
ルータがHelloメッセージを受け取るとき、それは、その隣人のためにIPアドレスを格納して、HelloにHoldtimeへのHello送付者のためのNeighbor-タイマを含んでいて、セットして、Designated Router(DR)をそのインタフェースに決定します。 選出されたDRはそうです。最も高いIPはシステムを記述しました。受け取られた各HelloはDRのアドレスをアップデートさせます。
When a router that is the active DR receives a Hello from a new neighbor (i.e., from an IP address that is not yet in the DRs neighbor table), the DR unicasts its most recent RP-set information to the new neighbor.
ルータであるときに、すなわち、アクティブなDRは新しい隣人(すなわち、まだDRs隣人テーブルにないIPアドレスからの)からHelloを受けて、DRユニキャストは新しい隣人への最新のRP-情報集合です。
3.1.3 Timing out neighbor entries
3.1.3 タイミングアウト隣人エントリー
A periodic process is run to time out PIM neighbors that have not sent Hellos. If the DR has gone down, a new DR is chosen by scanning all neighbors on the interface and selecting the new DR to be the one with the highest IP address. If an interface has gone down, the router may optionally time out all PIM neighbors associated with the interface.
周期的な過程はハローズを送らないタイムアウトPIM隣人へ走ります。 DRが落ちたなら、インタフェースのすべての隣人をスキャンして、新しいDRがものであるのに選ぶことによって、新しいDRは最も高いIPアドレスで選ばれています。 インタフェースが落ちたなら、ルータは任意に落ちました。すべてのPIM隣人がインタフェースに関連づけたタイムアウト。
3.2 Join/Prune
3.2は/プルーンに合流します。
Join/Prune messages are sent to join or prune a branch off of the multicast distribution tree. A single message contains both a join and prune list, either one of which may be null. Each list contains a set of source addresses, indicating the source- specific trees or shared tree that the router wants to join or prune.
メッセージがマルチキャスト分配木からブランチを加わるか、または剪定するために送られる/プルーンに合流してください。 ただ一つのメッセージはaが接合する両方とプルーンのリストを含んでいます。そのどちらかがヌルであるかもしれません。 各リストは1セットのソースアドレスを含んでいます、ルータが接合したいか、または剪定したがっているソースの特定の木か共有された木を示して。
3.2.1 Sending Join/Prune Messages
3.2.1 発信して、メッセージを接合するか、または剪定してください。
Join/Prune messages are merged such that a message sent to a particular upstream neighbor, N, includes all of the current joined
接合、/プルーンメッセージが合併されているので、メッセージは特定の上流の隣人に発信しました、N、電流のすべてが接合したインクルード
Estrin, et. al. Experimental [Page 14] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [14ページ]実験的なRFC2117PIM-Sm1997年6月
and pruned sources that are reached via N; according to unicast routing Join/Prune messages are multicast to all routers on multi- access networks with the target address set to the next hop router towards S or RP. Join/Prune messages are sent every [Join/Prune- Period] seconds. In the future we will introduce mechanisms to rate- limit this control traffic on a hop by hop basis, in order to avoid excessive overhead on small links. In addition, certain events cause triggered Join/Prune messages to be sent.
Nを通して連絡されている剪定されたソース。 ユニキャストルーティングによると、Join/プルーンのメッセージはあて先アドレスがあるネットワークが次のホップルータに設定するマルチアクセスでのすべてのルータへのSかRPに向かったマルチキャストです。 メッセージが送られる/プルーンに合流してください、あらゆる、[期間を接合するか、または剪定します]秒。 将来、私たちはホップの上でホップ基礎で限界がこのコントロール交通であると評定するためにメカニズムを紹介するつもりです、小さいリンクの上に過度のオーバーヘッドを避けるために。 さらに、あるイベント原因は送られるべきJoin/プルーンのメッセージの引き金となりました。
3.2.1.1 Periodic Join/Prune Messages
3.2.1.1 周期的である、メッセージを接合するか、または剪定してください。
A router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor. A periodic Join/Prune message sent to a particular RPF neighbor is constructed as follows:
ルータは、それぞれ(S、G)、(*、G)に関連している隣人をそれぞれの異なったRPFへの周期的なJoin/プルーンのメッセージに送って、(*、*、RP)にエントリーを送ります。 RPF隣人がPIM隣人であるならメッセージが送られるだけである/プルーンに合流してください。 特定のRPF隣人に送られた周期的なJoin/プルーンのメッセージは以下の通り構成されます:
1 Each router determines the RP for a (*,G) entry by using
the hash function described. The RP address (with RPT and
WC bits set) is included in the join list of a periodic
Join/Prune message under the following conditions:
1 各ルータは、ハッシュ関数を使用するのによる(*、G)エントリーへのRPが説明したことを決定します。 RPアドレス(ビットが設定するRPTとトイレがある)が含まれている、以下の条件のもとで周期的なJoin/プルーンのメッセージのリストを接合してください:
1 The Join/Prune message is being sent to the RPF
neighbor toward the RP for an active (*,G) or (*,*,RP)
entry, and
そして1 能動態(*、G)か(*、*、RP)エントリーのためにJoin/プルーンのメッセージをRPに向かったRPF隣人に送る。
2 The outgoing interface list in the (*,G) or (*,*,RP)
entry is non-NULL, or the router is the DR on the same
interface as the RPF neighbor.
外向的なインタフェースが中に記載する2、(*、G)または(*、*、RP)エントリーが非NULLであるかルータはRPF隣人と同じインタフェースのDRです。
2 A particular source address, S, is included in the join
list with the RPT and WC bits cleared under the following
conditions:
特定のソースアドレス(S)が含まれている2、以下の条件のもとできれいにされるRPTとトイレビットにリストを接合してください:
1 The Join/Prune message is being sent to the RPF
neighbor toward S, and
そして1 Join/プルーンのメッセージをSに向かったRPF隣人に送る。
2 There exists an active (S,G) entry with the RPT-bit
flag cleared, and
そして2 RPT-ビット旗がきれいにされている活発な(S、G)エントリーが存在している。
3 The oif list in the (S,G) entry is not null.
3 (S、G)エントリーにおけるoifリストはヌルではありません。
3 A particular source address, S, is included in the prune
list with the RPT and WC bits cleared under the following
conditions:
3 特定のソースアドレス(S)はRPTとトイレビットが以下の条件のもとできれいにされているプルーンのリストに含まれています:
1 The Join/Prune message is being sent to the RPF
neighbor toward S, and
そして1 Join/プルーンのメッセージをSに向かったRPF隣人に送る。
Estrin, et. al. Experimental [Page 15] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [15ページ]実験的なRFC2117PIM-Sm1997年6月
2 There exists an active (S,G) entry with the RPT-bit
flag cleared, and
そして2 RPT-ビット旗がきれいにされている活発な(S、G)エントリーが存在している。
3 The oif list in the (S,G) entry is null.
3 (S、G)エントリーにおけるoifリストはヌルです。
4 A particular source address, S, is included in the prune
list with the RPT-bit set and the WC bit cleared under the
following conditions:
4 特定のソースアドレス(S)はRPT-ビットセットとトイレビットが以下の条件のもとできれいにされているプルーンのリストに含まれています:
1 The Join/Prune message is being sent to the RPF
neighbor toward the RP and there exists a (S,G) entry
with the RPT-bit flag set and null oif list, or
または1 Join/プルーンのメッセージをRPに向かったRPF隣人に送って、RPT-ビット旗のセットとヌルoifリストがある(S、G)エントリーが存在している。
2 The Join/Prune message is being sent to the RPF
neighbor toward the RP, there exists a (S,G) entry
with the RPT-bit flag cleared and SPT-bit set, and the
incoming interface toward S is different than the
incoming interface toward the RP, or
または2 Join/プルーンのメッセージをRPに向かったRPF隣人に送って、RPT-ビット旗がきれいにされている(S、G)エントリーが存在していて、SPT-ビットがセットして、Sに向かった入って来るインタフェースが入って来るインタフェースとRPに向かって異なっている。
3 The Join/Prune message is being sent to the RPF
neighbor toward the RP, and there exists a (*,G) entry
and (S,G) entry for a directly connected source.
3 Join/プルーンのメッセージをRPに向かったRPF隣人に送って、直接接続されたソースへの(*、G)エントリーと(S、G)エントリーは存在しています。
5 The RP address (with RPT and WC bits set) is included in
the prune list if:
RPが記述する(ビットが設定するRPTとトイレで)5がプルーンのリストに含まれている、:
1 The Join/Prune message is being sent to the RPF
neighbor toward the RP and there exists a (*,G) entry
with a null oif list (see Section 3.5.2).
1 Join/プルーンのメッセージをRPに向かったRPF隣人に送って、ヌルoifリストがある(*、G)エントリーは存在しています(セクション3.5.2を見てください)。
3.2.1.2 Triggered Join/Prune Messages
3.2.1.2 引き起こされて、メッセージを接合するか、または剪定してください。
In addition to periodic messages, the following events will trigger Join/Prune messages if as a result, a) a new entry is created, or b) the oif list changes from null to non-null or non-null to null. The contents of triggered messages are the same as the periodic, described above.
周期的なメッセージに加えて、その結果、a) 新しいエントリーが作成されるか、またはb) oifリストが非ヌルからヌルから非ヌルかヌルに変化すると、以下の出来事はJoin/プルーンのメッセージの引き金となるでしょう。 引き起こされたメッセージの内容は上で説明された周期的と同じです。
1 Receipt of an indication from IGMP that the state of
directly-connected- membership has changed (i.e., new members
have just joined `membership indication' or all members have
left), for a group G, may cause the last-hop router to build
or modify corresponding (*,G) state. When IGMP indicates
that there are no longer directly connected members, the oif
is removed from the oif list if the oif- timer is not
running. A Join/Prune message is triggered if and only if
a) a new entry is created, or b) the oif list changes from
null to non-null or non-null to null, as follows :
1 グループGのために、直接接続された会員資格の州が変えた(すなわち、新しいメンバーはちょうど'会員資格指示'に加わったところであるか、またはすべてのメンバーがいなくなりました)IGMPからの指示の領収書は、最後のホップルータが対応する(*、G)状態を造るか、または変更することを引き起こすかもしれません。 IGMPが、直接接続されたメンバーがもういないのを示すとき、oifタイマが動いていないなら、oifはoifリストから取り外されます。 そして、Join/プルーンのメッセージが引き起こされる、a)である場合にだけ、新しいエントリーが作成されるか、またはb) oifリストは非ヌルからヌルから非ヌルかヌルに変化します、以下の通りです:
Estrin, et. al. Experimental [Page 16] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [16ページ]実験的なRFC2117PIM-Sm1997年6月
1 If the receiving router does not have a route entry
for G the router creates a (*,G) entry, copies the
oif list from the corresponding (*,*,RP) entry
(if it exists), and includes the interface included
in the IGMP membership indication in the oif list;
as always, the router never includes the entry's iif
in the oif list. The router sends a Join/Prune
message towards the RP with the RP address and RPT-bit
and WC-bits set in the join list. Or,
1 受信ルータにGのためのルートエントリーがないなら、ルータは、(*、G)エントリーを作成して、対応する(*、*、RP)エントリー(存在しているなら)からoifリストをコピーして、oifリストにIGMP会員資格指示にインタフェースを含んでいるのを含んでいます。 いつものように、ルータはoifリストにエントリーのiifを決して含んでいません。 ルータがRPアドレスとRPT-ビットでJoin/プルーンのメッセージをRPに向かって送って、トイレビットが始まる、リストを接合してください。 または
2 If a (S,G)RPT-bit or (*,G) entry already exists, the
interface included in the IGMP membership indication
is added to the oif list (if it was not included already).
2 (S、G)RPT-ビットか(*、G)エントリーが既に存在しているなら、IGMP会員資格指示にインタフェースを含んでいるのはoifリストに追加されます(それが既に含まれなかったなら)。
2 Receipt of a Join/Prune message for (S,G), (*,G) or (*,*,RP)
will cause building or modifying corresponding state, and
subsequent triggering of upstream Join/Prune messages, in the
following cases:
2 原因が対応する状態、上流のJoin/プルーンのメッセージについてその後のおよび引き金となることを造るか、または変更して、(*、G)か(*、*、RP)がそうするでしょう、(S、G)へのJoin/プルーンのメッセージの領収書、以下の場合で:
1 When there is no current route entry, the RP address
included in the Join/Prune message is checked against
the local RP-Set information. If it matches, an entry
will be created and the new entry will in turn trigger
an upstream Join/Prune message. If the router has no
RP-Set information it may discard the message, or
optionally use the RP address included in the message.
1 どんな現在のルートエントリーもないとき、Join/プルーンのメッセージにRPアドレスを含んでいるのはローカルのRP-情報集合に対してチェックされます。 合っていると、エントリーは作成されるでしょう、そして、新しいエントリーは順番に上流のJoin/プルーンのメッセージの引き金となるでしょう。 ルータにRP-情報集合が全くないなら、それは、メッセージを捨てるか、または任意にメッセージに含まれていたRPアドレスを使用するかもしれません。
2 When the outgoing interface list of an (S,G)RPT-bit
entry becomes null, the triggered Join/Prune message
will contain S in the prune list.
2 (S、G)RPT-ビットエントリーの送信するインタフェースリストがヌルになるとき、引き起こされたJoin/プルーンのメッセージはプルーンのリストのSを含むでしょう。
3 When there exists a (S,G)RPT-bit with null oif list,
and an (*,G) Join/Prune message is received, the
arriving interface is added to the oif list and a (*,G)
Join/Prune message is triggered upstream.
そして、3 いつがヌルoifリストがある(S、G)RPT-ビットを存在させているか、(*、G)は、受け取られたメッセージを、接合するか、または剪定して、到着インタフェースによるリストとa(*、G)が接合するか、または余計なものを取り除くoifに加えられて、メッセージが上流へ引き起こされるということです。
4 When there exists a (*,G) with null oif list, and a
(*,*,RP) Join/Prune message is received, the receiving
interface is added to the oif list and a (*,*,RP)
Join/Prune message is triggered upstream.
4 ヌルoifリストがあるa(*、G)がいつ、存在するか、そして、a(*、*、RP)は、受け取られたメッセージを、接合するか、または剪定して、受信インタフェースによるリストとa(*、*、RP)が接合するか、または余計なものを取り除くoifに加えられて、メッセージが上流へ引き起こされるということです。
3 Receipt of a packet that matches on a (S,G) entry whose
SPT-bit is cleared triggers the following if the packet
arrived on the correct incoming interface and there is a
(*,G) or (*,*,RP) entry with a different incoming
interface: a) the router sets the SPT-bit on the (S,G)
entry, and b) the router sends a Join/Prune message
towards the RP with S and a set RPT-bit in the prune list.
3 パケットが正しい入って来るインタフェースで到着したなら、SPT-ビットがきれいにされる(S、G)エントリーのときに合っているパケットの領収書は以下の引き金となります、そして、異なった入来によるエントリーが連結する(*、G)か(*、*、RP)があります: a) ルータは(S、G)エントリーにSPT-ビットを設定して、SとセットRPT-ビットがプルーンのリストにある状態で、b) ルータはJoin/プルーンのメッセージをRPに向かって送ります。
Estrin, et. al. Experimental [Page 17] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [17ページ]実験的なRFC2117PIM-Sm1997年6月
4 When a Join/Prune message is received for a group G, the
prune list is checked. If the prune list contains a source
or RP for which the receiving router has a corresponding
active (S,G), (*,G) or (*,*,RP) entry, and whose iif is
that on which the Join/Prune was received, then a join for
(S,G), (*,G) or (*,*,RP) is triggered to override the prune,
respectively. (This is necessary in the case of parallel
downstream routers connected to a multi-access network.)
4 グループGのためにJoin/プルーンのメッセージを受け取るとき、プルーンのリストをチェックします。 プルーンのリストが受信ルータには対応する能動態(S、G)、(*、G)があるソースかRPを入れてあるか、または(*、*、RP)エントリーとだれのiifがJoin/プルーンが受け取られたその、次に、aであるかが(S、G)のために接合するなら、(*、G)か(*、*、RP)が、それぞれプルーンをくつがえすために引き起こされます。 (これがマルチアクセスネットワークに関連づけられた平行な川下のルータの場合で必要です。)
5 When the RP fails, the RP will not be included in the
Bootstrap messages sent to all routers in that domain.
This triggers the DRs to send (*,G) Join/Prune messages
towards new RP for the group, as determined by the RP-Set
and the hash function. As described earlier, PMBRs trigger
(*,*,RP) joins towards each RP in the RP-Set.
5 RPが失敗する場合、RPはそのドメインのすべてのルータに送られたBootstrapメッセージに含まれないでしょう。 これは発信するDRs(*、G)の引き金となります。グループのために新しいRPに向かってメッセージを接合するか、または剪定してください、RP-セットとハッシュ関数で決定するように。 より早く説明されるように、PMBRs引き金(*、*、RP)はRP-セットにおける各RPに向かって接合します。
6 When an entry's Join/Prune-Suppression timer expires, a
Join/Prune message is triggered upstream corresponding to
that entry, even if the outgoing interface has not
transitioned between null and non-null states.
6 エントリーのプルーンJoin/抑圧タイマが期限が切れるとき、Join/プルーンのメッセージはそのエントリーに対応しながら、上流へ引き起こされます、外向的なインタフェースがヌルの、そして、非ヌルの州の間で移行していなくても。
7 When the RPF neighbor changes (whether due to an Assert or
changes in unicast routing), the router sets a random delay
timer (the Random-Delay-Join-Timer) whose expiration triggers
sending of a Join/Prune message for the asserted route entry
to the Assert winner (if the Join/Prune Suppression timer has
expired.)
7 RPF隣人が変化するとき(ユニキャストルーティングにおけるAssertか変化にかかわらず)、ルータは満了が断言されたルートエントリーへのJoin/プルーンのメッセージの発信のAssert勝者に引き金となる無作為のディレイタイマ(Random遅れはタイマを接合している)を設定します。(Join/プルーンのSuppressionタイマが期限が切れたなら。)
We do not trigger prunes onto interfaces based on data packets. Data packets that arrive on the wrong incoming interface are silently dropped. However, on point-to-point interfaces triggered prunes may be sent as an optimization.
私たちはデータ・パケットに基づくインタフェースにプルーンの引き金となりません。 間違った入って来るインタフェースで到着するデータ・パケットは静かに落とされます。 しかしながら、二地点間インタフェースに、最適化として引き起こされたプルーンを送るかもしれません。
3.2.1.3 Fragmentation: It is possible that a Join/Prune message constructed according to the preceding rules could exceed the MTU of a network. In this case, the message can undergo semantic fragmentation whereby information corresponding to different groups can be sent in different messages. However, if a Join/Prune message must be fragmented the complete prune list corresponding to a group G must be included in the same Join/Prune message as the associated RP-tree Join for G. If such semantic fragmentation is not possible, IP fragmentation should be used between the two neighboring hops.
3.2.1.3 断片化: 前の規則に従って構成されたJoin/プルーンのメッセージがネットワークのMTUを超えているかもしれないのは、可能です。 この場合、メッセージは異なったメッセージで異なったグループに対応する情報を送ることができる意味断片化を受けることができます。 しかしながら、そのような意味断片化がJoin/プルーンのメッセージが断片化されて、G.Ifのための関連RP-木のJoinと同じJoin/プルーンのメッセージにグループGに対応する完全なプルーンのリストを含まなければならないということであるに違いないなら可能でない、IP断片化は2つの隣接しているホップの間で使用されるべきです。
Estrin, et. al. Experimental [Page 18] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [18ページ]実験的なRFC2117PIM-Sm1997年6月
3.2.2 Receiving Join/Prune Messages When a router receives a
Join/Prune message, it processes it as follows.
3.2.2 Join/プルーンのMessages Whenを受けて、ルータはJoin/プルーンのメッセージを受け取って、それは以下の通りそれを処理します。
The receiver of the Join/Prune notes the interface on which the PIM message arrived, call it I. The receiver then checks to see if the Join/Prune message was addressed to the receiving router itself (i.e., the router's address appears in the Unicast Upstream Neighbor Router field of the Join/Prune message). (If the router is connected to a multiaccess LAN, the message could be intended for a different router.) If the Join/Prune is for this router the following actions are taken.
Join/プルーンの受信機はPIMメッセージが到着したインタフェースに注意して、それを次に受信機がJoin/プルーンのメッセージが受信ルータ自体に記述されたかどうか(すなわち、ルータのアドレスはJoin/プルーンのメッセージのUnicast Upstream Neighbor Router分野に現れます)確認するためにチェックするI.と呼んでください。 (ルータが多重処理LANに関連づけられるなら、メッセージは異なったルータのために意図するかもしれません。) Join/プルーンがこのルータのためのものであるなら、以下の行動を取ります。
For each group address G, in the Join/Prune message, the associated join list is processed as follows. We refer to each address in the join list as Sj; Sj refers to the RP if the RPT- bit and WC-bit are both set. For each Sj in the join list of the Join/Prune message:
関連がJoin/プルーンのメッセージに接合するそれぞれのグループアドレスGにおいて、リストは以下の通り処理されます。 各アドレスが私たちが参照される、Sjとしてリストを接合してください。 RPTビットとトイレビットがともに設定されるなら、SjはRPについて言及します。 中の各Sj、Join/プルーンのメッセージのリストを接合してください:
1 If an address, Sj, in the join list of the Join/Prune
message has the RPT-bit and WC-bit set, then Sj is the RP
address used by the downstream router(s) and the following
actions are taken:
メッセージが持っているJoin/プルーンのリストを接合してください。1、アドレス、中のSjである、RPT-ビットとトイレビットはセットしました、そして、次に、Sjは川下ルータによって使用されるRPアドレスです、そして、以下の行動を取ります:
1 If Sj is not the same as the receiving router's RP
mapping for G, the receiving router may ignore the
Join/Prune message with respect to that group entry.
If the router does not have any RP-Set information, it
may use the address Sj included in the Join/Prune
message as the RP for the group.
1 SjがGのための受信ルータのRPマッピングと同じでないなら、受信ルータはそのグループエントリーに関してJoin/プルーンのメッセージを無視するかもしれません。 グループのためのRPとしてJoin/プルーンのメッセージにSjを含んでいて、ルータが少しのRP-情報集合も持っていないなら、それはアドレスを使用するかもしれません。
2 If Sj is the same as the receiving router's RP mapping
for G, the receiving router adds I to the outgoing
interface list of the (*,G) route entry (if there is
no (*,G) entry, the router creates one first) and sets
the Oif-timer for that interface to the Holdtime
specified in the Join/Prune message. In addition, the
Oif-Deletion-Delay for that interface is set to 1/3rd
the Holdtime specified in the Join/Prune message.
2 SjがGのための受信ルータのRPマッピングと同じであるなら、受信ルータは、私が(*、G)ルートエントリーのリストを外向的に連結する((*、G)エントリーが全くなければ、ルータは1/1を作成する)と言い足して、Join/プルーンのメッセージで指定されたHoldtimeへのそのインタフェースにOif-タイマを設定します。 さらに、そのインタフェースへのOif削除遅れはJoin/プルーンのメッセージで指定されたHoldtimeの1/3番目に設定されます。
If a (*,*,RP) entry exists, for the RP associated with
G, then the oif list of the newly created (*,G) entry
is copied from that (*,*,RP) entry.
(*、*、RP)エントリーがGに関連しているRPのために存在しているなら、新たに作成された(*、G)エントリーのoifリストはその(*、*、RP)エントリーからコピーされます。
3 For each (Si,G) entry associated with group G, if Si
is not included in the prune list, and if I is not the
iif then interface I is added to the oif list and the
Oif-timer for that interface in each affected entry
is increased (never decreased) to the Holdtime included
in the Join/Prune message. In addition, if the
3 Siがプルーンのリストに含まれていないならそれぞれの(Si、G)エントリーがグループGと交際して、私であるなら、私が加えられるiifの当時のインタフェースは、それぞれの影響を受けるエントリーが増加する(決して減少しません)そのインタフェースへのJoin/プルーンのメッセージにHoldtimeを含んでいるoifリストとOif-タイマではありませんか? 添加で
Estrin, et. al. Experimental [Page 19] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [19ページ]実験的なRFC2117PIM-Sm1997年6月
Oif-timer for that interface is increased, the
Oif-Deletion-Delay for that interface is set to 1/3rd
the Holdtime specified in the Join/Prune message.
そのインタフェースへのOif-タイマが増加されている、そのインタフェースへのOif削除遅れはJoin/プルーンのメッセージで指定されたHoldtimeの1/3番目に設定されます。
If the group address in the Join/Prune message is `*'
then every (*,G) and (S,G) entry, whose group address
hashes to the RP indicated in the (*,*,RP) Join/Prune
message, is updated accordingly. A `*' in the group
field of the Join/Prune is represented by a group
address 224.0.0.0 and a group mask length of 4,
indicating a (*,*,RP) Join.
その時Join/プルーンのメッセージのグループアドレスが'*'である、あらゆる、アドレスが中に示されたRPにエントリー、グループを論じ尽くす(*、G)と(S、G)、(*、*、RP)をメッセージを接合するか、または剪定して、それに従って、アップデートします。 Join/プルーンのグループ野原の中の'*'がグループアドレスによって表される、224.0、.0、.0、そして、(*、*、RP)が接合するのを示す4のグループマスクの長さ。
4 If the (Si,G) entry has its RPT-bit flag set to 1, and
its oif list is the same as the (*,G) oif list, then
the (Si,G)RPT-bit entry is deleted,
4 (Si、G)エントリーでRPT-ビット旗を1に設定して、oifリストが(*、G)oifリストと同じであるなら、(Si、G)RPT-ビットエントリーは削除されます。
5 The incoming interface is set to the interface used to
send unicast packets to the RP in the (*,G) route
entry, i.e., RPF interface toward the RP.
5 入って来るインタフェースは(*、G)ルートエントリーにユニキャストパケットをRPに送るのに使用されるインタフェースに設定されて、すなわち、RPFはRPに向かって連結します。
2 For each address, Sj, in the join list whose RPT-bit and
WC-bit are not set, and for which there is no existing (Sj,G)
route entry, the router initiates one. The router creates a
(S,G) entry and copies all outgoing interfaces from the
(S,G)RPT-bit entry, if it exists. If there is no (S,G) entry,
the oif list is copied from the (*,G) entry; and if there is
no (*,G) entry, the oif list is copied from the (*,*,RP)
entry, if it exists. In all cases, the iif of the (S,G)
entry is always excluded from the oif list.
各アドレス、中のSjのための2、RPT-ビットとトイレビットが設定されないで、またどんな既存(Sj、G)のルートエントリーもないリストを接合してください、ルータ開始1 存在しているなら、ルータは、(S、G)RPT-ビットエントリーを(S、G)エントリーを作成して、すべての外向的なインタフェースを回避します。 (S、G)エントリーが全くなければ、oifリストは(*、G)エントリーからコピーされます。 そして、存在していて、(*、G)エントリーが全くなければ、oifリストは(*、*、RP)エントリーからコピーされます。 すべての場合では、(S、G)エントリーのiifはoifリストからいつも除かれます。
1 The outgoing interface for (Sj,G) is set to I. The
incoming interface for (Sj,G) is set to the interface
used to send unicast packets to Sj (i.e., the RPF
neighbor).
1 (Sj、G)があるので、外向的なインタフェースはSjへのユニキャストパケットを送ってください(Sj、G)のための入って来るインタフェースが使用されるインタフェースに設定されるI.(すなわち、RPF隣人)にセットしました。
2 If the interface used to reach Sj, is the same as I,
this represents an error (or a unicast routing change)
and the Join/Prune must not be processed.
2 Sjに達するのに使用されるインタフェースが私と同じであるなら、これは誤り(または、ユニキャストルーティング変化)を表して、Join/プルーンは処理されてはいけません。
Estrin, et. al. Experimental [Page 20] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [20ページ]実験的なRFC2117PIM-Sm1997年6月
3 For each address, Sj, in the join list of the Join/Prune
message, for which there is an existing (Sj,G) route entry,
各アドレス、中のSjのための3、Join/プルーンのメッセージのリストを接合してください、どれが既存(Sj、G)のルートエントリーがあるように
1 If the RPT-bit is not set for Sj listed in the
Join/Prune message, but the RPT-bit flag is set on the
existing (Sj,G) entry, the router clears the RPT-bit
flag on the (Sj,G) entry, sets the incoming interface
to point towards Sj for that (Sj,G) entry, and sends a
Join/Prune message corresponding to that entry through
the new incoming interface; and
1 RPT-ビットがJoin/プルーンのメッセージに記載されたSjに設定されませんが、RPT-ビット旗が既存(Sj、G)のエントリーに設定されるなら、ルータは、(Sj、G)エントリーのときにRPT-ビット旗をきれいにして、その(Sj、G)エントリーのために入って来るインタフェースにSjを示すように設定して、そのエントリーに対応するJoin/プルーンのメッセージを新しい入って来るインタフェースを通して送ります。 そして
2 If I is not the same as the existing incoming
interface, the router adds I to the list of outgoing
interfaces.
2が私であるなら既存の入って来るインタフェースと同じでない、ルータは外向的のリストへの私が連結すると言い足します。
3 The Oif-timer for I is increased (never decreased)
to the Holdtime included in the Join/Prune message.
In addition, if the Oif-timer for that interface is
increased, the Oif-Deletion-Delay for that interface
is set to 1/3rd the Holdtime specified in the
Join/Prune message.
3 私がHoldtimeに増加されているので(決して減少していない)、Oif-タイマはJoin/プルーンにメッセージを含んでいました。 さらに、そのインタフェースへのOif-タイマが増加しているなら、そのインタフェースへのOif削除遅れはJoin/プルーンのメッセージで指定されたHoldtimeの1/3番目に設定されます。
4 The (Sj,G) entry's SPT bit is cleared until data comes
down the shortest path tree.
4 データが最短パス木で来るまで、(Sj、G)エントリーのSPTビットはきれいにされます。
For each group address G, in the Join/Prune message, the associated prune list is processed as follows. We refer to each address in the prune list as Sp; Sp refers to the RP if the RPT-bit and WC-bit are both set. For each Sp in the prune list of the Join/Prune message:
それぞれのグループアドレスGにおいて、Join/プルーンのメッセージでは、関連プルーンのリストは以下の通り処理されます。 私たちはプルーンのリストのSpとしての各アドレスを参照します。 RPT-ビットとトイレビットがともに設定されるなら、SpはRPについて言及します。 Join/プルーンのメッセージのプルーンのリストの各Spのために:
1 For each address, Sp, in the prune list whose RPT-bit and
WC-bit are cleared:
1 各アドレス、RPT-ビットとトイレビットがきれいにされるプルーンのリストのSpのために:
1 If there is an existing (Sp,G) route entry, the router
lowers the Oif-timer for I to its Oif-Deletion-Delay,
allowing for other downstream routers on a multi-
access LAN to override the prune. However, on point-
to-point links, the oif-timer is expired immediately.
1 既存(Sp、G)のルートエントリーがあれば、ルータはIのためにOif-タイマをOif削除遅れに下ろします、マルチアクセスLANに関する他の川下のルータがプルーンをくつがえすのを許容して。 しかしながら、ポイントへのポイントリンクの上では、oif-タイマはすぐに、吐き出されます。
2 If the router has a current (*,G), or (*,*,RP), route
entry, and if the existing (Sp,G) entry has its RPT-
bit flag set to 1, then this (Sp,G)RPT-bit entry is
maintained (not deleted) even if its outgoing
interface list is null.
2 ルータには電流(*、G)があるか、または(*、*、RP)がエントリーを発送して、RPTビットが既存(Sp、G)のエントリーでセットに1まで旗を揚げさせるなら、送信するインタフェースリストがヌルであっても、この(Sp、G)RPT-ビットエントリーは維持されます(削除されません)。
Estrin, et. al. Experimental [Page 21] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [21ページ]実験的なRFC2117PIM-Sm1997年6月
2 For each address, Sp, in the prune list whose RPT-bit is
set and whose WC-bit cleared:
2 各アドレス、プルーンのリストのRPT-ビットがセットとトイレビットがだれのものをクリアしたということであるSpのために:
1 If there is an existing (Sp,G) route entry, the router
lowers the entry's Oif-timer for I to its
Oif-Deletion-Delay, allowing for other downstream
routers on a multi- access LAN to override the prune.
However, on point-to-point links, the oif-timer is
expired immediately.
1 既存(Sp、G)のルートエントリーがあれば、ルータはIのためにエントリーのOif-タイマをOif削除遅れに下ろします、マルチアクセスLANに関する他の川下のルータがプルーンをくつがえすのを許容して。 しかしながら、ポイントツーポイント接続の上では、oif-タイマはすぐに、吐き出されます。
2 If the router has a current (*,G), or (*,*,RP), route
entry, and if the existing (Sp,G) entry has its
RPT- bit flag set to 1, then this (Sp,G)RPT-bit entry
is not deleted, and the Entry-timer is restarted, even
if its outgoing interface list is null.
2 ルータには電流(*、G)があるか、または(*、*、RP)がエントリーを発送して、RPTビットが既存(Sp、G)のエントリーでセットに1まで旗を揚げさせるなら、この(Sp、G)RPT-ビットエントリーは削除されません、そして、Entry-タイマは再開されます、送信するインタフェースリストがヌルであっても。
3 If (*,G), or corresponding (*,*,RP), state exists, but
there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is
created. The outgoing interface list is copied from the
(*,G), or (*,*,RP), entry, with the interface, I, on
which the prune was received, is deleted. Packets from
the pruned source, Sp, match on this state and are not
forwarded toward the pruned receivers.
3 (*、G)、または対応(*、*、RP)、状態が存在していますが、(Sp、G)エントリーが全くなければ、(Sp、G)RPT-ビットエントリーは作成されます。 送信するインタフェースリストがコピーされる、(*、G)、または(*、*、RP)、インタフェースがあるエントリー(私)は削除されます。(そこでは、プルーンが受け取られました)。 剪定されたソースからのパケット(Sp)は、この状態で合って、剪定された受信機に向かって送られません。
4 If there exists a (Sp,G) entry, with or without the
RPT-bit set, the oif-timer for I is expired, and the
Entry-timer is restarted.
4 私が満期であり、Entry-タイマが再開されるので(Sp、G)エントリーがRPT-ビットセット、oif-タイマのあるなしにかかわらず存在しているなら。
3 For each address, Sp, in the prune list whose RPT-bit and
WC-bit are both set:
3 各アドレス、Spに関しては、プルーンのリストでは、だれのRPT-ビットとトイレビットが両方であるかがセットしました:
1 If there is an existing (*,G) entry, with Sp as the RP
for G, the router lowers the entry's Oif-timer for I
to its Oif-Deletion-Delay, allowing for other
downstream routers on a multi-access LAN to override the
prune. However, on point-to-point links, the oif-timer
is expired immediately.
1 GのためのRPとしてSpとの既存(*、G)のエントリーがあれば、ルータはIのためにエントリーのOif-タイマをOif削除遅れに下ろします、マルチアクセスLANに関する他の川下のルータがプルーンをくつがえすのを許容して。 しかしながら、ポイントツーポイント接続の上では、oif-タイマはすぐに、吐き出されます。
2 If the corresponding (*,*,RP) state exists, but there
is no (*,G) entry, a (*,G) entry is created. The
outgoing interface list is copied from (*,*,RP) entry,
with the interface, I, on which the prune was
received, deleted.
2 対応する(*、*、RP)状態が存在していますが、(*、G)エントリーが全くなければ、(*、G)エントリーは作成されます。 送信するインタフェースリストはプルーンがどれであったかに関して受け取られた私がインタフェースで削除した(*、*、RP)エントリーからコピーされます。
For any new (S,G), (*,G) or (*,*,RP) entry created by an
incoming Join/Prune message, the SPT-bit is cleared (and if a
Join/Prune-Suppression timer is used, it is left off.)
いずれにおいても、新しくて(S、G)、(*、G)か入って来るJoin/プルーンのメッセージによって作成された(*、*、RP)エントリー、SPT-ビットがきれいにされます。(プルーンJoin/抑圧タイマが使用されているなら、それはやめられます。)
Estrin, et. al. Experimental [Page 22] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [22ページ]実験的なRFC2117PIM-Sm1997年6月
If the entry has a Join/Prune-Suppression timer associated with it, and if the received Join/Prune does not indicate the router as its target, then the receiving router examines the join and prune lists to see if any addresses in the list `completely- match' existing (S,G), (*,G), or (*,*,RP) state for which the receiving router currently schedules Join/Prune messages. An element on the join or prune list `completely-matches' a route entry only if both the IP addresses and RPT-bit flag are the same. If the incoming Join/Prune message completely matches an existing (S,G), (*,G), or (*,*,RP) entry and the Join/Prune arrived on the iif for that entry, then the router compares the Holdtime included in the Join/Prune message, to its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime] is lower, the Join/Prune-Suppression-timer is started at the [Join/Prune-Suppression-Timeout]. If the [Join/Prune-Holdtime] is equal, the tie is resolved in favor of the Join/Prune Message originator that has the higher IP address. When the Join/Prune timer expires, the router triggers a Join/Prune message for the corresponding entry(ies).
エントリーでプルーンJoin/抑圧があって、容認されたJoin/プルーンが目標としてルータを示さないなら、タイマはそれと交際しました、受信ルータが調べるその時、何かリストのアドレスが存在(S、G)、(*、G)に'完全に合わせているかどうか'を見るリストか受信ルータが現在Join/プルーンのメッセージの計画をする(*、*、RP)状態に加わって、剪定してください。 要素、オンである、接合してください。さもないと、IPアドレスとRPT-ビットが旗を揚げさせる両方が同じである場合にだけ、プルーンのリストはルートエントリーに'完全に合わせています'。 入って来るJoin/プルーンのメッセージが存在(S、G)、(*、G)に完全に合っているか、そして、(*、*、RP)エントリーとJoin/プルーンがiifでそのエントリーに到着しました、次に、Join/プルーンのメッセージにHoldtimeを含んでいて、ルータは比較されます、それ自身のものに[/プルーン-Holdtimeを接合してください]。 それ自身[/プルーン-Holdtimeを接合する]が低いなら、プルーンの抑圧Join/タイマで始められる、[/プルーン抑圧タイムアウトを接合します。] 同輩、繋がりが、より高いIPアドレスを持っているJoin/プルーンのMessage創始者を支持して決議されているということ[/プルーン-Holdtimeを接合する]です。 Join/プルーンのタイマが期限が切れると、ルータは対応するエントリー(ies)へのJoin/プルーンのメッセージの引き金となります。
3.3 Register and Register-Stop
3.3 レジスタとレジスタ停止
When a source first starts sending to a group its packets are encapsulated in Register messages and sent to the RP. If the data rate warrants source-specific paths, the RP sets up source specific state and starts sending (S,G) Join/Prune messages toward the source, with S in the join list.
ソースが最初にグループに発信し始めるとき、パケットをRegisterメッセージでカプセルに入れって、RPに送ります。 データ信号速度がソース特有の経路、RPセットをソースの特定の状態に保証して、発信し始めるなら、(S、G)は、ソースに向かってメッセージを加わるか、または剪定します、中にSがある状態でリストを接合してください。
3.3.1 Sending Registers and Receiving Register-Stops
3.3.1 レジスタを送って、レジスタ停止を受けること。
Register messages are sent as follows:
以下の通りレジスタメッセージを送ります:
1 When a DR receives a packet from a directly connected
source, S
DRであるときに、1は直接接続されたソース、Sからパケットを受けます。
1 If there is no corresponding (S,G) entry, and the
router has RP-Set information, the DR creates one with
the Register-Suppression-timer turned off and the RP
address set according to the hash function mapping for
the corresponding group. The oif list is copied from
existing (*,G) or (*,*,RP) entries, if they exist. The
iif of the (S,G) entry is always excluded from the oif
list.
1 どんな対応する(S、G)エントリーもなくて、ルータにRP-情報集合があるなら、Register抑圧タイマがオフにされて、対応するグループのためのハッシュ関数マッピングによると、RPアドレスが設定されている状態で、DRは1つを作成します。 存在しているなら、oifリストは存在(*、G)か(*、*、RP)エントリーからコピーされます。 (S、G)エントリーのiifはoifリストからいつも除かれます。
2 If there is a (S,G) entry in existence, the DR simply
restarts the corresponding Entry-timer.
2 現存する(S、G)エントリーがあれば、DRは単に対応するEntry-タイマを再開します。
Estrin, et. al. Experimental [Page 23] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [23ページ]実験的なRFC2117PIM-Sm1997年6月
When a PMBR (e.g., a router that connects the PIM-SM region to
a dense mode region running DVMRP or PIM-DM) receives a packet
from a source in the dense mode region, the router treats the
packet as if it were from a directly connected source. A
separate document will describe the details of
interoperability.
PMBR(例えば、DVMRPかPIM-DMを走らせる濃いモード領域にPIM-SM領域をつなげるルータ)が濃いモード領域のソースからパケットを受けるとき、ルータはまるで直接接続されたソースから来ているかのようにパケットを扱います。 別々のドキュメントは相互運用性の詳細について説明するでしょう。
2 If the new or previously-existing (S,G) entry's Register-
Suppression-timer is not running, the data packet is
encapsulated in a Register message and unicast to the RP
for that group. The data packet is also forwarded according
to (S,G) state in the DR if the oif list is not null; since
a receiver may join the SP-tree while the DR is still
registering to the RP.
2 新しいか以前に既存の(S、G)エントリーのRegister抑圧タイマが動いていないなら、データ・パケットはそのグループのためにRegisterメッセージとユニキャストでRPにカプセルに入れられます。 また、oifリストがヌルでないなら、DRの(S、G)状態に応じて、データ・パケットを進めます。 以来、DRがまだRPに登録している間、受信機はSP-木に合流するかもしれません。
3 If the (S,G) entry's Register-Suppression-timer is running,
the data packet is not sent in a Register message, it is
just forwarded according to the (S,G) oif list.
3 (S、G)エントリーのRegister抑圧タイマが動いているなら、Registerメッセージでデータ・パケットを送らないで、(S、G)oifリストに応じて、それをただ進めます。
When the DR receives a Register-Stop message, it restarts the Register-Suppression-timer in the corresponding (S,G) entry(ies) at [Register-Suppression-Timeout] seconds. If there is data to be registered, the DR may send a null Register (a Register message with a zero-length data portion in the inner IP packet) to the RP, [Probe-Time] seconds before the Register- Suppression-timer expires, to avoid sending occasional bursts of traffic to an RP unnecessarily.
DRが[抑圧タイムアウトを登録してください]秒にRegister-停止メッセージを受け取るとき、それは対応する(S、G)エントリー(ies)でRegister抑圧タイマを再開します。 登録されるためにデータがあれば、DRはRP Register抑圧タイマが不必要に交通の時々の炸裂をRPに送るのを避けるために期限が切れる秒前の[徹底的調査時間]にヌルRegister(ゼロ・レングスデータ部が内側のIPパケットにあるRegisterメッセージ)を送るかもしれません。
3.3.2 Receiving Register Messages and Sending Register-Stops
3.3.2 レジスタメッセージを受け取って、レジスタ停止を送ること。
When a router (i.e., the RP) receives a Register message, the router does the following:
ルータ(すなわち、RP)がRegisterメッセージを受け取るとき、ルータは以下をします:
1 Decapsulates the data packet, and checks for a
corresponding (S,G) entry.
1 データ・パケットをDecapsulatesして、対応する(S、G)エントリーがないかどうかチェックします。
1 If a (S,G) entry with cleared (0) SPT bit exists, and
the received Register does not have the Null-
Register-Bit set to 1, the packet is forwarded; and
the SPT bit is left cleared (0). If the SPT bit is 1,
the packet is dropped, and Register-Stop messages are
triggered. Register-Stops should be rate-limited (in
an implementation-specific manner) so that no more
than a few are sent per round trip time. This prevents
a high datarate stream of packets from triggering a
large number of Register-Stop messages between the
time that the first packet is received and the time
when the source receives the first Register-Stop.
1 クリアされた(0)SPTビットによる(S、G)エントリーが存在していて、容認されたRegisterがNullレジスタビットを1に設定させないなら、パケットを進めます。 そして、SPTビットは(0)に左でクリアされたということです。 SPTビットが1であるなら、パケットは落とされます、そして、Register-停止メッセージは引き起こされます。 レジスタ停止がレートによって限られるべきであるので(実現特有の方法による)、1周遊旅行時間単位でいくつかを送るだけです。 これは、パケットの高いdatarateの流れが最初のパケットが受け取られていることの時、情報筋が最初のRegister-停止を受ける時の間で多くのRegister-停止メッセージの引き金となるのを防ぎます。
Estrin, et. al. Experimental [Page 24] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [24ページ]実験的なRFC2117PIM-Sm1997年6月
2 If there is no (S,G) entry, but there is a (*,G)
entry, and the received Register does not have the
Null-Register-Bit set to 1, the packet is forwarded
according to the (*,G) entry.
2 (S、G)エントリーが全くありませんが、(*、G)エントリーがあって、容認されたRegisterがNullレジスタビットを1に設定させないなら、(*、G)エントリーに応じて、パケットを進めます。
3 If there is a (*,*,RP) entry but no (*,G) entry, and
the Register received does not have the Null-
Register-Bit set to 1, a (*,G) or (S,G) entry is
created and the oif list is copied from the (*,*,RP)
entry to the new entry. The packet is forwarded
according to the created entry.
3 a(*、*、RP)エントリーにもかかわらず、いいえ(*、G)、エントリーがあって、受け取られたRegisterがNullレジスタビットを1に設定させないなら、a(*、G)か(S、G)エントリーが作成されて、oifリストは(*、*、RP)エントリーから新しいエントリーまでコピーされます。 作成されたエントリーに応じて、パケットを進めます。
4 If there is no G or (*,*,RP) entry corresponding to G,
the packet is dropped, and a Register-Stop is
triggered.
4 Gに対応するどんなGも(*、*、RP)エントリーもなければ、パケットは落とされて、Register-停止は引き起こされます。
5 A "Border bit" bit is added to the Register message,
to facilitate interoperability mechanisms. PMBRs set
this bit when registering for external sources (see
Section 2.7). If the "Border bit" is set in the
Register, the RP does the following:
「境界ビット」ビットは、相互運用性メカニズムを容易にするためにRegisterメッセージに追加されます。5 外部電源に登録するとき、PMBRsはこのビットを設定します(セクション2.7を見てください)。 「境界ビット」がRegisterに設定されるなら、RPは以下をします:
1 If there is no matching (S,G) state, but there
exists (*,G) or (*,*,RP) entry, the RP creates a
(S,G) entry, with a `PMBR' field. This field
holds the source of the Register (i.e. the outer
IP address of the register packet). The RP
triggers a (S,G) join towards the source of the
data packet, and clears the SPT bit for the (S,G)
entry. If the received Register is not a `null
Register' the packet is forwarded according to
the created state. Else,
そこであるなら、1は合っている(S、G)状態ではありませんが、(*、G)が存在しているか、またはエントリー、(*、*、RP)RPは(S、G)エントリーを作成します、'PMBR'分野で。 この分野はRegister(すなわち、レジスタパケットの外側のIPアドレス)の源を保持します。 RP引き金のa(S、G)は、(S、G)エントリーにデータ・パケットの源に向かって接合して、SPTビットをきれいにします。 容認されたRegisterが'ヌルRegister'でないなら、作成された状態に応じて、パケットを進めます。 ほかに
2 If the `PMBR' field for the corresponding (S,G)
entry matches the source of the Register packet,
and the received Register is not a `null
Register', the decapsulated packet is forwarded
to the oif list of that entry. Else,
2 対応する(S、G)エントリーへの'PMBR'分野がRegisterパケットの源に合って、容認されたRegisterが'ヌルRegister'でないなら、そのエントリーのoifリストにdecapsulatedパケットを送ります。 ほかに
3 If the `PMBR' field for the corresponding (S,G)
entry matches the source of the Register packet,
the decapsulated packet is forwarded to the oif
list of that entry, else
3 対応する(S、G)エントリーへの'PMBR'分野がRegisterパケットの源に合っているなら、そのエントリーのoifリストにdecapsulatedパケットを送りますほかです。
4 The packet is dropped, and a Register-stop is
triggered towards the source of the Register.
4 パケットは落とされて、Register-停止はRegisterの源に向かって引き起こされます。
Estrin, et. al. Experimental [Page 25] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [25ページ]実験的なRFC2117PIM-Sm1997年6月
The (S,G) Entry-timer is restarted by Registers arriving from
that source to that group.
(S、G)エントリータイマはそのソースからそのグループまで到着するRegistersによって再開されます。
2 If the matching (S,G) or (*,G) state contains a null oif
list, the RP unicasts a Register-Stop message to the source
of the Register message; in the latter case, the source-
address field, within the Register-Stop message, is set to
the wildcard value (all 0's). This message is not processed
by intermediate routers, hence no (S,G) state is
constructed between the RP and the source.
マッチング(S、G)か(*、G)状態がヌルoifを含んでいるなら、2は記載して、RPユニキャストはRegisterメッセージの源へのRegister-停止メッセージです。 後者の場合では、ソースアドレス・フィールドはRegister-停止メッセージの中にワイルドカード値(すべての0)に設定されます。 このメッセージは中間的ルータによって処理されません、したがって、いいえ(S、G)、状態がRPとソースの間で構成されます。
3 If the Register message arrival rate warrants it and there
is no existing (S,G) entry, the RP sets up a (S,G) route
entry with the outgoing interface list, excluding iif(S,G),
copied from the (*,G) outgoing interface list, its SPT-bit
is initialized to 0. If a (*,G) entry does not exist, but
there exists a (*,*,RP) entry with the RP corresponding to
G , the oif list for (S,G) is copied -excluding the iif-
from that (*,*,RP) entry.
3 Registerメッセージ到着率がそれを保証して、どんな既存(S、G)のエントリーもなければ、RPは送信するインタフェースリストがiif(S、G)を除いた(*、G)送信するインタフェースリストからのコピーにされるので(S、G)ルートエントリーをセットアップして、SPT-ビットは0に初期化されます。 (*、G)エントリーが存在していませんが、(S、G)がコピーされるのでRPがG、oifリストに対応であっている中のそれ(*、*、RP)からのiifエントリーを除く(*、*、RP)エントリーが存在しているなら。
A timer (Entry-timer) is set for the (S,G) entry and this
timer is restarted by receipt of data packets for (S,G).
The (S,G) entry causes the RP to send a Join/Prune message
for the indicated group towards the source of the register
message.
タイマ(エントリータイマ)は(S、G)エントリーのときに予定されます、そして、このタイマは(S、G)のためにデータ・パケットの領収書で再開されます。 (S、G)エントリーで、RPは示されたグループへのJoin/プルーンのメッセージをレジスタメッセージの源に向かって送ります。
If the (S,G) oif list becomes null, Join/Prune messages
will not be sent towards the source, S.
(S、G)oifリストがヌルになると、Join/プルーンのメッセージはソース、Sに向かって送られないでしょう。
3.4 Multicast Data Packet Forwarding
3.4 マルチキャストデータ・パケット推進
Processing a multicast data packet involves the following steps:
マルチキャストデータ・パケットを処理すると、以下のステップはかかわります:
1 Lookup route state based on a longest match of the source
address, and an exact match of the destination address in
the data packet. If neither S, nor G, find a longest match
entry, and the RP for the packet's destination group
address has a corresponding (*,*,RP) entry, then the
longest match does not require an exact match on the
destination group address. In summary, the longest match is
performed in the following order: (1) (S,G), (2) (*,G). If
neither is matched, then a lookup is performed on (*,*,RP)
entries.
1 データ・パケットでソースアドレスの最も長いマッチ、および送付先アドレスの完全な一致に基づくルックアップルート状態。 どちらのS、およびGが、最も長いマッチがエントリーであることがわかって、パケットの送付先グループアドレスのためのRPに対応する(*、*、RP)エントリーがあるなら、最も長いマッチは送付先グループアドレスで完全な一致を必要としません。 概要では、最も長いマッチは以下のオーダーで実行されます: (1) (S、G), (2) (*、G。) どちらも取り組まないなら、ルックアップは(*、*、RP)エントリーに実行されます。
2 If the packet arrived on the interface found in the
matching-entry's iif field, and the oif list is not
null:
2 パケットが合っているエントリーのiif野原で発見されるインタフェースで到着して、oifリストがヌルならでない:
Estrin, et. al. Experimental [Page 26] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [26ページ]実験的なRFC2117PIM-Sm1997年6月
1 Forward the packet to the oif list for that entry
and restart the Entry-timer if the matching entry is
(S,G). Optionally, the (S,G) Entry-timer may be
restarted by periodic checking of the matching packet
count.
1 前方に、oifへのパケットは、合っているエントリーが(S、G)であるならそのエントリーに記載して、Entry-タイマを再開します。 任意に、(S、G)エントリータイマは合っているパケットカウントの周期的な照合で再開されるかもしれません。
2 If the entry is a (S,G) entry with a cleared SPT-bit,
and a (*,G) or associated (*,*,RP) also exists whose
incoming interface is different than that for (S,G),
set the SPT-bit for the (S,G) entry and trigger an
(S,G) RPT-bit prune towards the RP.
2 また、aがSPT-ビット、およびa(*、G)をきれいにするか、または交際したことでの入って来るインタフェースが(S、G)のためのそれと異なっているエントリー(*、*、RP)がエントリーがa(S、G)であるなら存在していて、セットが(S、G)エントリーへのSPT-ビットであり、引き金はRPに向かった(S、G)RPT-ビットプルーンです。
3 If the source of the packet is a directly-connected
host and the router is the DR on the receiving
interface, check the Register-Suppression-timer
associated with the (S,G) entry. If it is not running,
then the router encapsulates the data packet in a
register message and sends it to the RP.
パケットの源が直接接続されたホストとルータであるなら、3は受信インタフェース(Register抑圧タイマが(S、G)エントリーに関連づけたチェック)のDRです。 走っていないなら、ルータは、レジスタメッセージでデータ・パケットをカプセルに入れって、それをRPに送ります。
This covers the common case of a packet arriving on the RPF
interface to the source or RP and being forwarded to all
joined branches. It also detects when packets arrive on the
SP-tree, and triggers their pruning from the RP-tree. If it
is the DR for the source, it sends data packets
encapsulated in Registers to the RPs.
これはRPFインタフェースでソースに到着するパケットかRPとすべての接合ブランチに送るよくある例をカバーしています。 それは、また、パケットがいつSP-木の上で到着するかを検出して、RP-木から彼らの刈り込みの引き金となります。 ソースへのDRであるなら、それはRegistersでRPsにカプセルに入れられたデータ・パケットを送ります。
3 If the packet matches to an entry but did not arrive on the
interface found in the entry's iif field, check the
SPT-bit of the entry. If the SPT-bit is set, drop the
packet. If the SPT-bit is cleared, then lookup the (*,G),
or (*,*,RP), entry for G. If the packet arrived on the
iif found in (*,G), or the corresponding (*,*,RP),
forward the packet to the oif list of the matching
entry. This covers the case when a data packet matches on a
(S,G) entry for which the SP-tree has not yet been
completely established upstream.
パケットがエントリーに合っていましたが、インタフェースで到着しなかったなら、3はエントリーのiif分野、チェックでエントリーのSPT-ビットを見つけました。 SPT-ビットが設定されるなら、パケットを落としてください。 SPT-ビットがクリアされて、当時のルックアップである、(*、G)、または(*、*、RP)、G.Ifのためのパケットがiifに備え付けるところで到着したエントリー(*、G)、または対応(*、*、RP)が合っているエントリーのoifリストにパケットを送ります。 データ・パケットがSP-木がまだ完全に上流へ設立されるというわけではなかった(S、G)エントリーのときに合っていると、これはケースをカバーしています。
4 If the packet does not match any entry, but the source of
the data packet is a local, directly-connected host, and
the router is the DR on a multi-access LAN and has RP-Set
information, the DR uses the hash function to determine the
RP associated with the destination group, G. The DR creates
a (S,G) entry, with the Register-Suppression-timer not
running, encapsulates the data packet in a Register message
and unicasts it to the RP.
パケットは少しのエントリーにも合っているのではなく、データ・パケットの源を合わせるなら4が地方の、そして、直接接続されたホストであり、ルータがマルチアクセスLANのDRであり、RP-情報集合を持って、DRが目的地グループに関連しているRP(DRが(S、G)エントリーであって、Register抑圧タイマで走らないのに作成するG.)がRegisterメッセージとユニキャストでデータ・パケットをカプセルに入れることを決定するのにハッシュ関数を使用する、それ、RPに。
5 If the packet does not match to any entry, and it is not a
local host or the router is not the DR, drop the packet.
5 パケットがどんなエントリーにも合わないで、またそれがローカル・ホストでないルータがDRでないなら、パケットを落としてください。
Estrin, et. al. Experimental [Page 27] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [27ページ]実験的なRFC2117PIM-Sm1997年6月
3.4.1 Data triggered switch to shortest path tree (SP-tree)
3.4.1 データは最短パス木にスイッチの引き金となりました。(SP-木)
Different criteria can be applied to trigger switching over from the RP-based shared tree to source-specific, shortest path trees.
RPベースの共有された木からソース特有の最短パス木までの切り換えの引き金となるように異なった評価基準を適用できます。
One proposed example is to do so based on data rate. For example, when a (*,G), or corresponding (*,*,RP), entry is created, a data rate counter may be initiated at the last-hop routers. The counter is incremented with every data packet received for directly connected members of an SM group, if the longest match is (*,G) or (*,*,RP). If and when the data rate for the group exceeds a certain configured threshold (t1), the router initiates `source-specific' data rate counters for the following data packets. Then, each counter for a source, is incremented when packets matching on (*,G), or (*,*,RP), are received from that source. If the data rate from the particular source exceeds a configured threshold (t2), a (S,G) entry is created and a Join/Prune message is sent towards the source. If the RPF interface for (S,G) is not the same as that for (*,G) -or (*,*,RP), then the SPT-bit is cleared in the (S,G) entry.
1つの提案された例はデータ信号速度に基づいてそうすることです。 a(*、G)、または対応(*、*、RP)、エントリーが作成されるとき、例えば、データ信号速度カウンタは最後のホップルータで開始されるかもしれません。 カウンタはSMグループの直接接続されたメンバーのためにあらゆるデータ・パケットを受け取っていて増加されます、最も長いマッチが(*、G)か(*、*、RP)であるなら。 グループのためのデータ信号速度が、ある構成された敷居(t1)を超えているなら、ルータは以下のデータ・パケットのために'ソース特有'のデータ信号速度カウンタを開始します。 そして、そのソースから(*、G)、または(*、*、RP)に合っているパケットを受け取ると、ソースへのそれぞれのカウンタは増加しています。 特定のソースからのデータ信号速度が構成された敷居(t2)を超えているなら、(S、G)エントリーを作成します、そして、Join/プルーンのメッセージをソースに向かって送ります。 または、(S、G)が(*、G)のためのそれと同じでないのでRPFが連結する、-、(*、*、RP)、そして、SPT-ビットは(S、G)エントリーできれいにされます。
Other configured rules may be enforced to cause or prevent establishment of (S,G) state.
他の構成された規則は、(S、G)状態の設立を引き起こすか、または防ぐために励行されるかもしれません。
3.5 Assert
3.5は断言します。
Asserts are used to resolve which of the parallel routers connected to a multi-access LAN is responsible for forwarding packets onto the LAN.
断言、平行なルータのどれがマルチアクセスLANに接続したかは、パケットをLANに送るのに責任があると決議するために、使用されます。
3.5.1 Sending Asserts
3.5.1 発信は断言します。
The following Assert rules are provided when a multicast packet is received on an outgoing multi-access interface "I" of an existing (S,G) entry:
外向的なマルチアクセスインタフェース既存(S、G)のエントリーの「私」にマルチキャストパケットを受け取るとき、以下のAssert規則を提供します:
1 Do unicast routing table lookup on source IP address from
data packet, and send assert on interface "I" for source
IP address in data packet; include metric preference of
routing protocol and metric from routing table lookup.
1 ソースIPで索表を発送するのがデータ・パケットから記述して、送るユニキャストはデータ・パケットのソースIPアドレスのためにインタフェースで「私」について断言します。 索表を発送するのによるプロトコルの、そして、メートル法のルーティングのメートル法の好みを含めてください。
2 If route is not found, use metric preference of 0x7fffffff
and metric 0xffffffff.
2によって、ルートがあるなら、0x7fffffffとメートル法の0xffffffffのメートル法の好みを使用するようにわかりませんでした。
When an assert is sent for a (*,G) entry, the first bit in the metric preference (the RPT-bit) is set to 1, indicating the data packet is routed down the RP-tree.
いつ、(*、G)エントリーに送ります、メートル法の好み(RPT-ビット)における最初のビットが1に設定されるということであり、データ・パケットを示すのがRP-木の下側に発送されると断言してくださいか。
Asserts should be rate-limited in an implementation-specific manner.
レートによって制限されているべきであるように実現特有の方法で断言します。
Estrin, et. al. Experimental [Page 28] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [28ページ]実験的なRFC2117PIM-Sm1997年6月
3.5.2 Receiving Asserts
3.5.2 受信は断言します。
When an Assert is received the router performs a longest match on the source and group address in the Assert message. The router checks the first bit of the metric preference (RPT-bit).
Assertが受け取られているとき、ルータはAssertメッセージのソースとグループアドレスに最も長いマッチを実行します。 ルータはメートル法の好み(RPTによって噛み付かれた)の最初のビットをチェックします。
1 If the RPT-bit is set, the router first does a match on
(*,G), or (*,*,RP), entries; if no matching entry is found,
it ignores the Assert.
1 RPT-ビットが設定されるなら、ルータは最初に、(*、G)、または(*、*、RP)のマッチ、エントリーをします。 合っているエントリーが全く見つけられないなら、それはAssertを無視します。
2 If the RPT-bit is not set in the Assert, the router first
does a match on (S,G) entries; if no matching entry is
found, the router matches (*,G) or (*,*,RP) entries.
2 RPT-ビットがAssertに設定されないなら、ルータは(S、G)エントリーのときに最初に、マッチをします。 合っているエントリーが全く見つけられないなら、ルータマッチ(*、G)か(*、*、RP)エントリーです。
3.5.2.1 Receiving Asserts on an entry's outgoing interface
3.5.2.1 エントリーの外向的なインタフェースでAssertsを受けること。
If the interface that received the Assert message is in the oif list of the matched entry, then this Assert is processed by this router as follows:
Assertメッセージを受け取ったインタフェースが取り組んでいるエントリーのoifリストにあるなら、このAssertは以下のこのルータによって処理されます:
1 If the Assert's RPT-bit is set and the matching entry is
(*,*,RP), the router creates a (*,G) entry. If the Assert's
RPT-bit is cleared and the matching entry is (*,G), or
(*,*,RP), the router creates a (S,G)RPT-bit entry.
Otherwise, no new entry is created in response to the
Assert.
1 AssertのRPT-ビットが設定されて、合っているエントリーが(*、*、RP)であるなら、ルータは(*、G)エントリーを作成します。 (*、*、RP)、AssertのRPT-ビットがきれいにされるなら、合っているエントリーは(*、G)であるかルータは(S、G)RPT-ビットエントリーを作成します。 さもなければ、どんな新しいエントリーもAssertに対応して作成されません。
2 The router then compares the metric values received in the
Assert with the metric values associated with the matched
entry. The RPT-bit and metric preference (in that order)
are treated as the high-order part of an Assert metric
comparison. If the value in the Assert is less than the
router's value (with ties broken by the IP address, where
higher IP address wins), delete the interface from the
entry. When the deletion occurs for a (*,G) or (*,*,RP)
entry , the interface is also deleted from any associated
(S,G)RPT-bit or (*,G) entries, respectively. The Entry-
timer for the affected entries is restarted.
2 そして、ルータは取り組んでいるエントリーに関連しているメートル法の数値にAssertに受け取られたメートル法の数値をたとえます。 RPT-ビットとメートル法の好み(そのオーダーにおける)はAssertのメートル法の比較の高位部分として扱われます。 Assertの値がルータの値以下(結びつきがIPアドレスによって壊されている状態で、より高いIPアドレスが得られるところで)であるなら、エントリーからインタフェースを削除してください。 また、削除がa(*、G)か(*、*、RP)エントリーに起こるとき、インタフェースはどんな関連している(S、G)RPT-ビットや(*、G)エントリーからもそれぞれ削除されます。 影響を受けるエントリーのためのEntryタイマは再開されます。
3 If the router has won the election the router keeps the
interface in its outgoing interface list. It acts as the
forwarder for the LAN.
3 ルータが選挙に勝ったなら、ルータは送信するインタフェースリストのインタフェースを保ちます。 それはLANのための混載業者として機能します。
The winning router sends an Assert message containing its own metric to that outgoing interface. This will cause other routers on the LAN to prune that interface from their route entries. The winning router sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit entry was matched.
勝利ルータは自分自身その外向的なインタフェースへのメートル法ののを含むAssertメッセージを送ります。 これで、LANに関する他のルータは彼らのルートエントリーからそのインタフェースを剪定するでしょう。 a(*、G)か(S、G)RPT-ビットエントリーが合われていたなら、勝利ルータはRPT-ビットをAssertメッセージにはめ込みます。
Estrin, et. al. Experimental [Page 29] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [29ページ]実験的なRFC2117PIM-Sm1997年6月
3.5.2.2 Receiving Asserts on an entry's incoming interface
3.5.2.2 エントリーの入って来るインタフェースでAssertsを受けること。
If the Assert arrived on the incoming interface of an existing (S,G), (*,G), or (*,*,RP) entry, the Assert is processed as follows. If the Assert message does not match the entry, exactly, it is ignored; i.e, longest-match is not used in this case. If the Assert message does match exactly, then:
Assertが存在(S、G)、(*、G)の入って来るインタフェース、または(*、*、RP)エントリーのときに到着したなら、Assertは以下の通り処理されます。 Assertメッセージがエントリーに合っていないなら、まさに、それは無視されます。 i. e、最も長いマッチはこの場合使用されません。 次に、Assertメッセージがまさに合っているなら:
1 Downstream routers will select the upstream router with the
smallest metric preference and metric as their RPF
neighbor. If two metrics are the same, the highest IP
address is chosen to break the tie. This is important so
that downstream routers send subsequent Joins/Prunes (in
SM) to the correct neighbor. An Assert-timer is initiated
when changing the RPF neighbor to the Assert winner. When
the timer expires, the router resets its RPF neighbor
according to its unicast routing tables to capture network
dynamics and router failures.
1 川下のルータは彼らのRPF隣人としてのメートル法の好みの、そして、メートル法の最も小さいのがある上流のルータを選択するでしょう。 2つの測定基準が同じであるなら、最も高いIPアドレスは、繋がりを壊すために選ばれています。 これが重要であるので、川下のルータはその後のJoins/プルーン(SMの)を正しい隣人に送ります。 RPF隣人をAssert勝者に変えるとき、Assert-タイマは開始されます。 タイマが期限が切れると、ユニキャスト経路指定テーブルに従って、ルータは、ネットワーク力学とルータ失敗を得るためにRPF隣人をリセットします。
2 If the downstream routers have downstream members, and if
the Assert caused the RPF neighbor to change, the
downstream routers must trigger a Join/Prune message to
inform the upstream router that packets are to be forwarded
on the multi-access network.
2 川下のルータで川下のメンバーがいて、AssertがRPF隣人を変化させたなら、川下のルータはパケットがマルチアクセスネットワークで進められることになっていることを上流のルータに知らせるJoin/プルーンのメッセージの引き金とならなければなりません。
3.6 Candidate-RP-Advertisements and Bootstrap messages
3.6 候補RP広告とBootstrapメッセージ
Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM messages unicast to the BSR by those routers that are configured as Candidate-RPs (C-RPs).
候補RP広告(C-RP-Advs)はCandidate-RPs(C-RPs)として構成されるそれらのルータによるBSRへの周期的なPIMメッセージユニキャストです。
Bootstrap messages are periodic PIM messages originated by the Bootstrap router (BSR) within a domain, and forwarded hop-by-hop to distribute the current RP-set to all routers in that domain.
ドメインの中のBootstrapルータ(BSR)によって溯源された、周期的なPIMメッセージであり、ホップごとに転送されたメッセージを独力で進んで、そのドメインのすべてのルータに現在のRP-セットを分配してください。
The Bootstrap messages also support a simple mechanism by which the Candidate BSR (C-BSR) with the highest BSR-priority and IP address (referred to as the preferred BSR) is elected as the BSR for the domain. We recommend that each router configured as a C-RP also be configured as a C-BSR. Sections 3.6.2 and 3.6.3 describe the combined function of Bootstrap messages as the vehicle for BSR election and RP-Set distribution.
また、Bootstrapメッセージは最も高いBSR-優先度とIPアドレス(都合のよいBSRと呼ばれる)があるCandidate BSR(C-BSR)がドメインへのBSRとして選出される簡単なメカニズムをサポートします。 私たちは、また、C-RPとして構成された各ルータがC-BSRとして構成されることを勧めます。 3.6にBSR選挙でRPセットしていた状態で.2と.3が乗り物としてのBootstrapメッセージの結合機能について説明する3.6を区分する、分配。
A Finite State Machine description of the BSR election and RP- Set distribution mechanisms is included in Appendix II.
BSR選挙とRPセット分配メカニズムのFinite州Machine記述はAppendix IIに含まれています。
Estrin, et. al. Experimental [Page 30] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [30ページ]実験的なRFC2117PIM-Sm1997年6月
3.6.1 Sending Candidate-RP-Advertisements
3.6.1 送付候補RP広告
C-RPs periodically unicast C-RP-Advs to the BSR for that domain. The interval for sending these messages is subject to local configuration at the C-RP.
C-RPs、定期的である、それのためのBSRへのユニキャストC-RP-Advsドメイン。 これらのメッセージを送るための間隔はC-RPでの地方の構成を受けることがあります。
Candidate-RP-Advertisements carry group address and group mask fields. This enables the advertising router to limit the advertisement to certain prefixes or scopes of groups. The advertising router may enforce this scope acceptance when receiving Registers or Join/Prune messages. C-RPs should send C-RP-Adv messages with the Authoritative bit cleared.
候補RP広告はグループアドレスとグループマスク野原を載せます。 これは、広告ルータが広告をグループのある接頭語か範囲に制限するのを可能にします。 RegistersかJoin/プルーンのメッセージを受け取るとき、広告ルータはこの範囲承認を実施するかもしれません。 Authoritativeビットがきれいにされている状態で、C-RPsはC-RP-Advメッセージを送るはずです。
3.6.2 Receiving C-RP-Advs and Originating Bootstrap
3.6.2 C-RP-Advsを受けて、由来は独力で進みます。
Upon receiving a C-RP-Adv, a router does the following:
C-RP-Advを受けると、ルータは以下をします:
1 If the router is not the elected BSR, it ignores the
message, else
1 ルータが選出されたBSRでないなら、それはほかのメッセージを無視します。
2 The BSR adds the RP address to its local pool of candidate
RPs, according to the associated group prefix(es) in the
C-RP-Adv message. The Holdtime in the C-RP-Adv message is
also stored with the corresponding RP, to be included later
in the Bootstrap message. The BSR may apply a local
policy to limit the number of Candidate RPs included
in the Bootstrap message. The BSR may override the prefix
indicated in a C-RP-Adv unless the Authoritative bit in the
C-RP-Adv is set.
2 BSRは候補RPsの地方のプールにRPアドレスを加えます、C-RP-Advメッセージの関連グループ接頭語(es)によると。 また、C-RP-AdvメッセージのHoldtimeは、後でBootstrapメッセージに含まれるように対応するRPと共に格納されます。 BootstrapメッセージにCandidate RPsの数を含んでいる場合、BSRは制限するローカルの方針を適用するかもしれません。 BSRはC-RP-AdvのAuthoritativeビットが設定されない場合C-RP-Advで示された接頭語をくつがえすかもしれません。
The BSR keeps an RP-timer per RP in its local RP-set. The RP- timer is initialized to the Holdtime in the RP's C-RP-Adv. When the timer expires, the corresponding RP is removed from the RP- set. The RP- timer is restarted by the C-RP-Advs from the corresponding RP.
BSRは地方のRP-セットで1RPあたり1個のRP-タイマを保ちます。 RPタイマはRPのC RP副詞でHoldtimeに初期化されます。 タイマが期限が切れるとき、対応するRPはRPセットから取り外されます。 RPタイマは対応からのC-RP-Advs RPによって再開されます。
The BSR also uses its Bootstrap-timer to periodically send Bootstrap messages. In particular, when the Bootstrap-timer expires, the BSR originates an Bootstrap message on each of its PIM interfaces. The message is sent with a TTL of 1 to the `ALL-PIM-ROUTERS' group. In steady state, the BSR originates Bootstrap messages periodically. At startup, the Bootstrap-timer is initialized to [Bootstrap-Timeout], causing the first Bootstrap message to be originated only when and if the timer expires. For timer details, see Section 3.6.3. A DR unicasts a Bootstrap message to each new PIM neighbor, i.e., after the DR receives the neighbor's Hello message (it does so even if the new neighbor becomes the DR).
また、BSRは、定期的にメッセージをBootstrapに送るのにBootstrap-タイマを使用します。 Bootstrap-タイマが期限が切れると、特に、BSRはそれぞれのPIMインタフェースに関するBootstrapメッセージを溯源します。 1のTTLと共にメッセージを送る、'、すべて、-、PIM-ROUTERS、'分類してください。 定常状態では、BSRはBootstrapメッセージを定期的に溯源します。 始動では、溯源されるべき最初のBootstrapメッセージにいつだけを引き起こして、[タイムアウトを独力で進みます]に初期化されて、タイマが期限が切れるなら、Bootstrap-タイマはそうです。 タイマの詳細に関しては、セクション3.6.3を見てください。 それぞれの新しいPIM隣人へのDRユニキャストa Bootstrapメッセージ、すなわち、後に、DRは隣人のHelloメッセージを受け取ります(新しい隣人がDRになっても、それはそうします)。
Estrin, et. al. Experimental [Page 31] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [31ページ]実験的なRFC2117PIM-Sm1997年6月
The Bootstrap message is subdivided into sets of {group- prefix,RP-
Count,RP-addresses}. For each RP-address, the corresponding Holdtime
is included in the "RP-Holdtime" field. The format of the Bootstrap
message allows `semantic fragmentation', if the length of the
original Bootstrap message exceeds the packet maximum boundaries (see
Section 4). However, we recommend against configuring a large number
of routers as C-RPs, to reduce the semantic fragmentation required.
Bootstrapメッセージはグループ接頭語、RPカウント、RPアドレスのセットに細分されます。 各RP-アドレスにおいて、対応するHoldtimeは"RP-Holdtime"分野に含まれています。 Bootstrapメッセージの形式は'意味断片化'を許容します、オリジナルのBootstrapメッセージの長さがパケットの最大の境界を超えているなら(セクション4を見てください)。 しかしながら、私たちは、減少するためにC-RPsとして多くのルータを構成しないように意味断片化が必要であることを推薦します。
3.6.3 Receiving and Forwarding Bootstrap
3.6.3 受信と推進は独力で進みます。
Each router keeps a Bootstrap-timer, initialized to [Bootstrap- Timeout] at startup.
各ルータがBootstrap-タイマであって、初期化されていた状態で保つ、[タイムアウトを独力で進みます] 始動で。
When a router receives Bootstrap message sent to `ALL-PIM- ROUTERS' group, it performs the following:
ルータがいつまで送られたBootstrapメッセージを受け取るか、'、すべて、-、PIM- ROUTERS、'分類してください、そして、以下を実行します:
1 If the message was not sent by the RPF neighbor towards the
BSR address included, the message is dropped. Else
1 アドレスを含んでいて、メッセージがRPF隣人によってBSRに向かって送られなかったなら、メッセージは落とされます。 ほか
2 If the included BSR is not preferred over, and not equal
to, the currently active BSR:
2、BSRが等しくない都合のよくなくて、包含、現在アクティブなBSR:
1 If the Bootstrap-timer has not yet expired, or if the
receiving router is a C-BSR, then the Bootstrap
message is dropped. Else
1 Bootstrap-タイマがまだ期限が切れていないか、または受信ルータがC-BSRであるなら、Bootstrapメッセージは落とされます。 ほか
2 If the Bootstrap-timer has expired and the receiving
router is not a C-BSR, the receiving router stores the
RP-Set and BSR address and priority found in the
message, and restarts the timer by setting it to
[Bootstrap-Timeout]. The Bootstrap message is then
forwarded out all PIM interfaces, excluding the one
over which the message arrived, to `ALL-PIM-ROUTERS'
group, with a TTL of 1.
2 Bootstrap-タイマが期限が切れて、受信ルータがC-BSRでないなら、受信ルータは、メッセージで見つけられたRP-セット、BSRアドレス、および優先権を格納して、[タイムアウトを独力で進みます]にそれを設定することによって、タイマを再開します。 次に、メッセージが到着したものを除いて、PIMが連結するすべてからBootstrapメッセージを転送する、'、すべて、-、PIM-ROUTERS、'1のTTLと共に分類してください。
3 If the Bootstrap message includes a BSR address that is
preferred over, or equal to, the currently active BSR, the
router restarts its Bootstrap-timer at [Bootstrap-Timeout]
seconds. and stores the BSR address and RP-Set information.
3 Bootstrapメッセージが等しいです都合のよいか、現在アクティブなBSR、ルータが[タイムアウトを独力で進みます]の秒BSRが記述する店とRP-情報集合でBootstrap-タイマを再開するということであるBSRアドレスを含んでいるなら。
The Bootstrap message is then forwarded out all PIM
interfaces, excluding the one over which the message
arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1.
次に、メッセージが到着したものを除いて、PIMが連結するすべてからBootstrapメッセージを転送する、'、すべて、-、PIM-ROUTERS、'1のTTLと共に分類してください。
Estrin, et. al. Experimental [Page 32] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [32ページ]実験的なRFC2117PIM-Sm1997年6月
4 If the receiving router has no current RP set information
and the Bootstrap was unicast to it from a directly
connected neighbor, the router stores the information as
its new RP-set. This covers the startup condition when a
newly booted router obtains the RP-Set and BSR address from
its DR.
4 どんな現在のRPも受信ルータで情報を設定しないで、Bootstrapがそれへの直接接続された隣人からのユニキャストであったなら、ルータは新しいRP-セットとして情報を格納します。 新たに起動させられたルータがDRからRP-セットとBSRアドレスを入手するとき、これは始動状態をカバーしています。
When a router receives a new RP-Set, it checks if each of the RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or (S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in the new RP-set, that RP is considered unreachable and the hash algorithm (see below) is re-performed for each group with locally active state that previously hashed to that RP. This will cause those groups to be distributed among the remaining RPs. When the new RP-Set contains a new RP, the value of the new RP is calculated for each group covered by that C-RP's Group- prefix. Any group for which the new RP's value is greater than the previously active RP's value is switched over to the new RP.
ルータが新しいRP-セットを受けるとき、それは、新しいRP-セットに現状(すなわち、(*、G)で、(*、*、RP)、または(S、G)がエントリーにRPT噛み付いた)によって言及されたそれぞれのRPsがあるかをチェックします。 新しいRP-セットにRPがないなら、そのRPは手が届かないと考えられます、そして、細切れ肉料理アルゴリズム(以下を見る)は各グループのためにそれが以前にそのRPに論じ尽くした局所的に活動的な状態と共に再実行されます。 これで、残っているRPsの中でそれらのグループを配布するでしょう。 新しいRP-セットが新しいRPを含むとき、新しいRPの値はそのC-RPのGroup接頭語でカバーされた各グループのために計算されます。 新しいRPの値が以前にアクティブなRPの値より大きいどんなグループも新しいRPに転換されます。
3.7 Hash Function
3.7 ハッシュ関数
The hash function is used by all routers within a domain, to map a group to one of the C-RPs from the RP-Set. For a particular group, G, the hash function uses only those C-RPs whose Group- prefix covers G. The algorithm takes as input the group address, and the addresses of the Candidate RPs, and gives as output one RP address to be used.
ハッシュ関数はドメインの中のすべてのルータによって使用されて、グループをRP-セットからC-RPsの1つに写像します。 特定のグループ、Gのために、ハッシュ関数はアルゴリズムが使用されるためにGroup接頭語カバーG.をグループが記述する入力、およびCandidate RPsのアドレスとして取って、出力1RPアドレスとして与えるそれらのC-RPsだけを使用します。
The protocol requires that all routers hash to the same RP within a domain (except for transients). The following hash function must be used in each router:
プロトコルは、すべてのルータがドメイン(過渡現象を除いた)の中で同じくらいにRPを論じ尽くすのを必要とします。 各ルータに以下のハッシュ関数を使用しなければなりません:
1 For each RP address C(i) in the RP-Set, whose Group-prefix
covers G, compute a value:
1 Group-接頭語がGを覆うRP-セットにおけるそれぞれのRPアドレスC(i)に関しては、値を計算してください:
Value(G,M,C(i))= (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
値、(G、M、C(i))=(1103515245*(1103515245*(G&M)+12345)XOR C(i))+12345)のモッズ風の2^31
where M is a hash-mask included in Bootstrap messages.
This hash-mask allows a small number of consecutive groups
(e.g., 4) to always hash to the same RP. For instance,
hierarchically-encoded data can be sent on consecutive
group addresses to get the same delay and fate-sharing
characteristics.
MがBootstrapメッセージに含まれていた細切れ肉料理マスクであるところ。 この細切れ肉料理マスクはいつも同じRPに論じ尽くす連続したグループ(例えば、4)の少ない数を許容します。 例えば、同じ遅れと運命を共有する特性を得るために連続したグループアドレスで階層的でコード化されたデータを送ることができます。
2 The candidate with the highest resulting value is then
chosen as the RP for that group, and its identity and hash
value are stored with the entry created.
2 そして、それのためのRPが分類して、エントリーが作成されている状態でそのアイデンティティとハッシュ値が格納されるとき、最も高い結果として起こる値をもっている候補は選ばれています。
Estrin, et. al. Experimental [Page 33] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [33ページ]実験的なRFC2117PIM-Sm1997年6月
Ties between C-RPs having the same hash value, are broken
in advantage of the highest address.
同じハッシュ値を持っているC-RPsの間の結びつきは最も高いアドレスの利点で壊れています。
The hash function algorithm is invoked by a DR, upon reception of a packet, or IGMP membership indication, for a group, for which the DR has no entry. It is invoked by any router that has (*,*,RP) state when a packet is received for which there is no corresponding (S,G) or (*,G) entry. Furthermore, the hash function is invoked by all routers upon receiving a (*,G) or (*,*,RP) Join/Prune message.
ハッシュ関数アルゴリズムはDRによって呼び出されます、パケット、またはIGMP会員資格指示のレセプションで、グループのために。(DRには、それのために、エントリーが全くありません)。 それはどれが対応してはいけないか(S、G)、さもなければ、(*、G)エントリーにパケットを受け取るとき状態を持っている(*、*、RP)どんなルータによっても呼び出されます。 その上、ハッシュ関数はメッセージを(*、G)か(*、*、RP)が接合する受信でのすべてのルータによって呼び出されるか、または剪定することです。
3.8 Processing Timer Events
3.8 処理タイマ出来事
In this subsection, we enumerate all timers that have been discussed or implied. Since some critical timer events are not associated with the receipt or sending of messages, they are not fully covered by earlier subsections.
この小区分では、私たちは議論するか、または含意されたすべてのタイマを数え上げます。 いくつかの批判的なタイマイベントが領収書に関連づけられもしませんし、メッセージを発信もさせないので、それらは以前の小区分で完全に覆われているというわけではありません。
Timers are implemented in an implementation-specific manner. For example, a timer may count up or down, or may simply expire at a specific time. Setting a timer to a value T means that it will expire after T seconds.
タイマは実現特有の方法で実行されます。 例えば、タイマが合計されるかもしれませんか、ダウンしてください、または特定の時に単に期限が切れるかもしれません。 値Tにタイマを設定するのは、それがT秒以降期限が切れることを意味します。
3.8.1 Timers related to tree maintenance
3.8.1 木の維持に関連するタイマ
Each (S,G), (*,G), and (*,*,RP) route entry has multiple timers associated with it: one for each interface in the outgoing interface list, one for the multicast routing entry itself, and one optional Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has an Assert-timer and a Random-Delay-Join-Timer for use with Asserts. In addition, DR's have a Register- Suppression-timer for each (S,G) entry and every router has a single Join/Prune-timer. (A router may optionally keep separate Join/Prune-timers for different interfaces or route entries if different Join/Prune periods are desired.)
それぞれ(S、G)、(*、G)、および(*、*、RP)ルートエントリーには、それに関連している複数のタイマがあります: 送信するインタフェースリストの各インタフェースあたり1つ、マルチキャストルーティングエントリー自体への1、および1個の任意のプルーンの抑圧Join/タイマ。 また、それぞれ(S、G)、(*、G)エントリーには、Assert-タイマとAssertsとのRandom遅れがタイマを接合している使用があります。 さらに、DRのものにはそれぞれの(S、G)エントリーのためのRegister抑圧タイマがあります、そして、あらゆるルータには、単一のプルーンJoin/タイマがあります。 (異なったJoin/プルーンの期間が望まれているなら、ルータは任意に異なったインタフェースかルートエントリーのための別々のプルーンJoin/タイマを保つかもしれません。)
* [Join/Prune-Timer] This timer is used for periodically
sending aggregate Join/Prune messages. To avoid
synchronization among routers booting simultaneously, it is
initially set to a random value between 1 and [Join/Prune-
Period]. When it expires, the timer is immediately
restarted to [Join/Prune-Period]. A Join/Prune message is
then sent out each interface. This timer should not be
restarted by other events.
* [/プルーンタイマを接合します] このタイマは、定期的に集合Join/プルーンのメッセージを送りながら、使用されます。 そして、同時にそれをブートしながらルータの中で同期を避けるのが初めは1の間の無作為の値に設定される、[期間を接合するか、または剪定します。] すぐに期限が切れるとき、タイマに再開されます[/プルーン期間を接合してください]。 Join/プルーンのメッセージは各インタフェースにそしてに出されたということです。 他の出来事はこのタイマを再開するべきではありません。
* [Join/Prune-Suppression-Timer (kept per route entry)] A
route entry's (optional) Join/Prune-Suppression-Timer may
be used to suppress duplicate joins from multiple
downstream routers on the same LAN. When a Join message is
received from a neighbor on the entry's incoming interface
* ルートエントリーの[/プルーン抑圧タイマ(ルートエントリー単位で保たれる)を接合します]もの(任意の)は/プルーン抑圧タイマを接合します。使用されて、写しを抑圧するのが同じLANに関する複数の川下のルータから接合するということであるかもしれません。 エントリーの入って来るインタフェースに隣人からJoinメッセージを受け取るとき
Estrin, et. al. Experimental [Page 34] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [34ページ]実験的なRFC2117PIM-Sm1997年6月
in which the included Holdtime is higher than the router's
own [Join/Prune-Holdtime] (with ties broken by higher IP
address), the timer is set to [Join/Prune-Suppression-
Timeout], with some random jitter introduced to avoid
synchronization of triggered Join/Prune messages on
expiration. (The random timeout value must be < 1.5 *
[Join/Prune-Period] to prevent losing data after 2 dropped
Join/Prunes.) The timer is restarted every time a
subsequent Join/Prune message (with higher Holdtime/IP
address) for the entry is received on its incoming
interface. While the timer is running, Join/Prune messages
for the entry are not sent. This timer is idle (not
running) for point-to-point links.
含まれているHoldtimeがルータが自己であるより[/プルーン-Holdtimeを接合してください](結びつきが、より高いIPアドレスによって壊されている状態で)高い、タイマがどれに設定されるかで[抑圧を参加しているか、または剪定しているタイムアウト]、引き起こされたJoin/の同期を避けるためにいくつかの無作為のジターを導入している状態で、満了に関するメッセージを剪定してください。 (無作為のタイムアウト値は2がJoin/プルーンを落とした後にデータを失うのを防ぐためには<1.5*でなければなりません[/プルーン期間を接合します]。) 入って来るインタフェースにエントリーへのその後のJoin/プルーンのメッセージ(より高いHoldtime/IPアドレスがある)を受け取るときはいつも、タイマは再開されます。 タイマが動いている間、エントリーへのJoin/プルーンのメッセージは送られません。 このタイマはポイントツーポイント接続に怠ける(走りません)ことです。
* [Oif-Timer (kept per oif for each route entry)] A timer for
each oif of a route entry is used to time out that oif.
Because some of the outgoing interfaces in an (S,G) entry
are copied from the (*,G) outgoing interface list, they may
not have explicit (S,G) join messages from some of the
downstream routers (i.e., where members are joining to the
(*,G) tree only). Thus, when an Oif-timer is restarted in a
(*,G) entry, the Oif-timer is restarted for that interface
in each existing (S,G) entry whose oif list contains that
interface. The same rule applies to (*,G) and (S,G) entries
when restarting an Oif-timer on a (*,*,RP) entry.
* [Oifタイマ(oif単位でそれぞれのルートエントリーに保たれる)の] ルートエントリーの各oifのためのタイマはそんなにoifにタイムアウトに使用されます。 (S、G)エントリーにおける外向的なインタフェースのいくつかからコピーされる、(明白にしないかもしれないG)外向的なインタフェースが、記載する*(S、G)は川下のルータのいくつかからのメッセージを接合します(すなわち、どこで、メンバーは(*、G)木だけにつないでいますか)。 Oif-タイマが(*、G)エントリーで再開されるとき、したがって、Oif-タイマはoifリストがそのインタフェースを含むそれぞれの既存(S、G)のエントリーにおけるそのインタフェースに再開されます。 (*、*、RP)エントリーのときにOif-タイマを再開するとき、同じ規則は(*、G)と(S、G)にエントリーを当てはまります。
The following table shows its usage when first adding the
oif to the entry's oiflist, when it should be restarted
(unless it is already higher), and when it should be
decreased (unless it is already lower).
最初にエントリーのoiflistにoifを加えるとき、以下のテーブルは用法を示しています、それが再開されるべきであり(それが既により高くない場合)、減少するべきであるとき(それが既に低くない場合)。
Estrin, et. al. Experimental [Page 35] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [35ページ]実験的なRFC2117PIM-Sm1997年6月
Set to | When | Applies to
-------------------------|------------------------------|------------
included Holdtime | adding oif off Join/Prune | (S,G) (*,G)
| | (*,*,RP)
セットされます。| いつ| 申し込みます。-------------------------|------------------------------|------------ 含まれているHoldtime| Join/プルーンからoifを加えます。| (S、G) (*、G) | | (*、*、RP)
Increased (only) to | When | Applies to
-------------------------|------------------------------|------------
included Holdtime | received Join/Prune | (S,G) (*,G)
| | (*,*,RP)
| |
Value of (*,*,RP) | (*,*,RP) oif-timer restarted | (S,G) (*,G)
oif-timer | |
| |
Value of (*,G) | (*,G) oif-timer restarted | (S,G)
oif-timer | |
増加します(単に)。| いつ| 申し込みます。-------------------------|------------------------------|------------ 含まれているHoldtime| 容認されたJoin/プルーン| (S、G) (*、G) | | (*、*、RP) | | (*、*、RP)の値| (*、*、RP) oif-タイマは再開しました。| (S、G) (*、G) oif-タイマ| | | | (*、G)の値| (*、G) oif-タイマは再開しました。| (S、G) oif-タイマ| |
Decreased (only) to | When | Applies to -------------------------|------------------------------|------------ Oif-Deletion-Delay | prune received | (S,G) (*,G)
減少します(単に)。| いつ| 申し込みます。-------------------------|------------------------------|------------ Oif削除遅れ| プルーンは受信されました。| (S、G) (*、G)
When the timer expires, the oif is removed from the oiflist
if there are no directly-connected members. When deleted,
the oif is also removed in any associated (S,G) or (*,G)
entries.
タイマが期限が切れるとき、どんな直接接続されたメンバーもいなければ、oifはoiflistから取り外されます。 削除されていて、oifはいつまた、取り外された何か関連しているか、そして、(S、G)(*、G)エントリー。
* [Entry-Timer (kept per route entry)] A timer for each route
entry is used to time out that entry. The following table
summarizes its usage when first adding the oif to the
entry's oiflist, and when it should be restarted (unless it
is already higher).
* それぞれのルートエントリーのための[エントリータイマ(ルートエントリー単位で保たれる)]タイマはタイムアウトに使用されます。そのエントリー。 最初にエントリーのoiflistとそれがいつ再開されるべきであるかに(それが既により高くない場合)oifを加えるとき、以下のテーブルは用法をまとめます。
Estrin, et. al. Experimental [Page 36] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [36ページ]実験的なRFC2117PIM-Sm1997年6月
Set to | When | Applies to
----------------------|--------------------------|------------
[Data- Timeout] | created off data packet | (S,G)
| |
included Holdtime | created off Join/Prune | (S,G) (*,G)
(*,*,RP)
セットされます。| いつ| 申し込みます。----------------------|--------------------------|------------ [データタイムアウト]| データ・パケットから、作成されます。| (S、G) | | 含まれているHoldtime| Join/プルーンから、作成されます。| (S、G) (*、G) (*、*、RP)
Increased (only) to | When | Applies to
----------------------|--------------------------|------------
[Data-Timeout] | receiving data packets | (S,G)no RPT-bit
| |
Value of oif-timer | any oif-timer restarted | (S,G)RPT-bit (*,G)
| | (*,*,RP)
| |
[Assert-Timeout] | assert received | (S,G)RPT-bit
| | (*,G)w/null oif
増加します(単に)。| いつ| 申し込みます。----------------------|--------------------------|------------ [データタイムアウト]| データ・パケットを受けます。| (S、G)RPT-ビットがありません。| | oif-タイマの値| どんなoif-タイマも再開しました。| (S、G)RPT-ビット(*、G)| | (*、*、RP) | | [タイムアウトについて断言します]です。| 受け取って、断言します。| (S、G)RPT-ビット| | (*、G)ヌルoifで
When the timer expires, the route entry is deleted; if the
entry is a (*,G) or (*,*,RP) entry, all associated
(S,G)RPT-bit entries are also deleted.
タイマが期限が切れるとき、ルートエントリーは削除されます。 エントリーであるなら、(*、G)か(*、*、RP)がエントリーです、また、すべての関連している(S、G)RPT-ビットエントリーが削除されます。
* [Register-Suppression-Timer (kept per (S,G) route entry)]
An (S,G) route entry's Register-Suppression-Timer is used
to suppress registers when the RP is receiving data packets
natively. When a Register-Stop message for the entry is
received from the RP, the timer is set to a random value in
the range 0.5 * [Register-Suppression-Timeout] to 1.5 *
[Register-Suppression-Timeout]. While the timer is running,
Registers for that entry will be suppressed. If null
registers are used, a null register is sent [Probe-Time]
seconds before the timer expires.
* [抑圧タイマを登録してください((S、G)ルートエントリー単位で保たれます)] (S、G)ルートエントリーのRegister抑圧タイマは、RPがネイティブにデータ・パケットを受けているとき、レジスタを抑圧するのに使用されます。 RPからエントリーのためのRegister-停止メッセージを受け取るとき、タイマは範囲0.5*1.5への[レジスタ抑圧タイムアウト]*の無作為の値へのセット[抑圧タイムアウトを登録する]です。 タイマが動いている間、そのエントリーへのRegistersは抑圧されるでしょう。 ヌルレジスタが使用されているなら、タイマが期限が切れる秒前にヌルレジスタを送ります[徹底的調査時間]。
* [Assert-Timer (per (S,G) or (*,G) route entry)] The
Assert-Timer for an (S,G) or (*,G) route entry is used for
timing out Asserts received. When an Assert is received and
the RPF neighbor is changed to the Assert winner, the
Assert-Timer is set to [Assert-Timeout], and is restarted
to this value every time a subsequent Assert for the entry
is received on its incoming interface. When the timer
expires, the router resets its RPF neighbor according to
its unicast routing table.
* [タイマについて断言している((S、G)か(*、G)に従って、エントリーを発送してください)]Assert-タイマ、(S、G)または(*、G)ルートエントリーが出ているAssertsが受けたタイミングに使用されます。 Assertが受け取られていて、RPF隣人がAssert勝者に変わるとき、Assert-タイマは、設定されて[タイムアウトについて断言している]、入って来るインタフェースにエントリーへのその後のAssertを受け取るときはいつも、この値に再開されます。 タイマが期限が切れると、ユニキャスト経路指定テーブルに従って、ルータはRPF隣人をリセットします。
* [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)]
The Random-Delay-Join-Timer for an (S,G) or (*,G) route
entry is used to prevent synchronization among downstream
routers on a LAN when their RPF neighbor changes. When the
* Random遅れが[無作為の遅れはタイマを接合します((S、G)か(*、G)に従って、エントリーを発送してください)]タイマを接合している、(彼らのRPF隣人が変化するとき、S、G)または(*、G)ルートエントリーが、LANで川下のルータの中で同期を防ぐのに使用されます。 いつ
Estrin, et. al. Experimental [Page 37] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [37ページ]実験的なRFC2117PIM-Sm1997年6月
RPF neighbor changes, this timer is set to a random value
between 0 and [Random-Delay-Join-Timeout] seconds. When the
timer expires, a triggered Join/Prune message is sent for
the entry unless its Join/Prune-Suppression-Timer is
running.
RPF隣人は変化して、このタイマは0と[無作為の遅れはタイムアウトを接合しています]の秒の間の無作為の値へのセットです。 タイマが期限が切れるとき、プルーンの抑圧Join/タイマが動いていない場合、引き起こされたJoin/プルーンのメッセージをエントリーに送ります。
3.8.2 Timers relating to neighbor discovery
3.8.2 隣人発見に関係するタイマ
* [Hello-Timer] This timer is used to periodically send Hello
messages. To avoid synchronization among routers booting
simultaneously, it is initially set to a random value
between 1 and [Hello-Period]. When it expires, the timer is
immediately restarted to [Hello-Period]. A Hello message is
then sent out each interface. This timer should not be
restarted by other events.
* [こんにちは、-、タイマ、]、このタイマは、定期的にメッセージをHelloに送るのに使用されます。 そして、同時にそれをブートしながらルータの中で同期を避けるのが初めは1の間の無作為の値に設定される、[こんにちは、-、以上、] いつまで期限が切れて、タイマがすぐに再開されるか、[こんにちは、-、以上、] Helloメッセージは各インタフェースにそしてに出されたということです。 他の出来事はこのタイマを再開するべきではありません。
* [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer for
each neighbor is used to time out the neighbor state. When
a Hello message is received from a new neighbor, the timer
is initially set to the Holdtime included in the Hello
message (which is equal to the neighbor's value of [Hello-
Holdtime]). Every time a subsequent Hello is received from
that neighbor, the timer is restarted to the Holdtime in
the Hello. When the timer expires, the neighbor state is
removed.
* [隣人タイマ(隣人単位で保たれる)] 各隣人のためのNeighbor-タイマは隣人が述べるタイムアウトに使用されます。 初めは新しい隣人からHelloメッセージを受け取るとき、Helloメッセージに含まれていたHoldtimeにタイマを設定する、(隣人の値への同輩がどれのものであるか、[こんにちは、-、Holdtime) その隣人からその後のHelloを受け取るときはいつも、タイマはHelloのHoldtimeに再開されます。 タイマが期限が切れるとき、隣人状態を取り除きます。
3.8.3 Timers relating to RP information
3.8.3 RP情報に関係するタイマ
* [C-RP-Adv-Timer (C-RP's only)] Routers configured as
candidate RP's use this timer to periodically send C-RP-Adv
messages. To avoid synchronization among routers booting
simultaneously, the timer is initially set to a random
value between 1 and [C-RP-Adv-Period]. When it expires, the
timer is immediately restarted to [C-RP-Adv-Period]. A C-
RP-Adv message is then sent to the elected BSR. This timer
should not be restarted by other events.
* [C RP-Advタイマ(専用C RP)] ルータは、定期的にC-RP-Advメッセージを送るために候補RPの使用としてこのタイマを構成しました。 1と[C RP-Advの期間]の間の無作為の値に設定されて、初めは、同時にタイマをブートしながらルータの中で同期を避けるのは、そうです。 すぐに期限が切れるとき、タイマは[C RP-Advの期間]まで再開されます。 そして、C RP-Advメッセージを選出されたBSRに送ります。 他の出来事はこのタイマを再開するべきではありません。
* [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR uses a
timer per RP in the RP-Set to monitor liveness. When a C-RP
is added to the RP-Set, its timer is set to the Holdtime
included in the C-RP-Adv message from that C-RP (which is
equal to the C-RP's value of [RP-Holdtime]). Every time a
subsequent C-RP-Adv is received from that RP, its timer is
restarted to the Holdtime in the C-RP-Adv. When the timer
expires, the RP is removed from the RP-Set included in
Bootstrap messages.
* [RP-タイマ(RP-セットで1RPあたり唯一の、そして、保たれたBSR)] BSRは、活性をモニターするのにRP-セットに1RPあたり1個のタイマを使用します。 C-RPがRP-セットに追加されるとき、タイマはそのC-RP([RP-Holdtime]のC-RP値と等しい)からのC-RP-AdvメッセージにHoldtimeを含んでいることへのセットです。 そのRPからその後のC-RP-Advを受け取るときはいつも、タイマはC RP副詞でHoldtimeに再開されます。 タイマが期限が切れるとき、RPはBootstrapメッセージにRP-セットを含むのから取り外されます。
Estrin, et. al. Experimental [Page 38] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [38ページ]実験的なRFC2117PIM-Sm1997年6月
* [Bootstrap-Timer] This timer is used by the BSR to
periodically originate Bootstrap messages, and by other
routers to time out the BSR (see 3.6.3). This timer is
initially set to [Bootstrap-Timeout]. A C-BSR restarts
this timer to [Bootstrap-Timeout] upon receiving a Bootstrap
message from a preferred router, and originates an Bootstrap
message and restarts the timer to [Bootstrap-Period] when it
expires. Routers not configured as C-BSR's restart this
timer to [Bootstrap-Timeout] upon receiving a Bootstrap
message from the elected or a more preferred BSR, and ignore
Bootstrap messages from non-preferred C-BSRs while it is
running.
* この[タイマを独力で進んだ]タイマが定期的にBootstrapメッセージ、およびタイムアウトへの他のルータによるBSRを溯源するのにBSRによって使用される、(見る、3.6、.3、) このタイマは初めは、[タイムアウトを独力で進みます]に設定されます。 期限が切れると、C-BSRは[期間を独力で進みます]に都合のよいルータからBootstrapメッセージを受け取るときの[タイムアウトを独力で進みます]にこのタイマを再開して、Bootstrapメッセージを溯源して、タイマを再開します。 ルータはC-BSRの再開として選出か、より都合のよいBSRからBootstrapメッセージを受け取るときの[タイムアウトを独力で進みます]にこのタイマを構成しませんでした、そして、走っている間、非都合のよいC-BSRsからのBootstrapメッセージを無視してください。
3.8.4 Default timer values
3.8.4 デフォルトタイマ値
Most of the default timeout values for state information are 3.5 times the refresh period. For example, Hellos refresh Neighbor state and the default Hello-timer period is 30 seconds, so a default Neighbor-timer duration of 105 seconds is included in the Holdtime field of the Hellos. In order to improve convergence, however, the default timeout value for information related to RP liveness and Bootstrap messages is 2.5 times the refresh period.
州の情報のためのデフォルトタイムアウト値の大部分が3.5回である、期間をリフレッシュしてください。 例えば、ハローズがNeighbor状態をリフレッシュして、デフォルトHello-タイマの期間が30秒であるので、105秒のデフォルトNeighbor-タイマ持続時間はハローズのHoldtime分野に含まれています。 しかしながら、RP活性とBootstrapメッセージに関連する情報のためのデフォルトタイムアウト価値が集合を改良する2.5回である、期間をリフレッシュしてください。
In this version of the spec, we suggest particular numerical timer settings. A future version of the specification will specify a mechanism for timer values to be scaled based upon observed network parameters.
仕様のこのバージョンでは、私たちは特定の数字のタイマ設定を勧めます。 仕様の将来のバージョンは、タイマ値が観測された回路パラメータに基づいた状態でスケーリングされるためにメカニズムを指定するでしょう。
* [Join/Prune-Period] This is the interval between
sending Join/Prune messages. {Default: 60 seconds.} This
value may be set to take into account such things as the
configured bandwidth and expected average number of
multicast route entries for the attached network or link
(e.g., the period would be longer for lower-speed links, or
for routers in the center of the network that expect to
have a larger number of entries ). In addition, a router
could modify this value (and corresponding Join/Prune-
Holdtime value) if the number of route entries changes
significantly (e.g., by an order of magnitude). For
example, given a default minimum Join/Prune-Period value,
if the number of route entries with a particular iif
increases from N to N*100, the router could increase its
Join/Prune-Period (and Join/Prune-Holdtime), for that
interface, by a factor of 10; and if/when the number of
entries decreases back to N, the Join/Prune-Period (and
Join/Prune-Holdtime) could be decreased to its previous
value. If the Join/Prune-Period is modified, these changes
should be made relatively infrequently and the router
* [/プルーン期間を接合します] これは送付Join/プルーンのメッセージの間隔です。 デフォルトとしてください:60秒 構成された帯域幅のようなものを考慮に入れて、付属ネットワークのために平均した数のマルチキャストルートエントリーを予想するか、またはこの値がリンクするように設定されるかもしれません(例えば期間が下側の速度リンク、またはルータのための、より長い間、より多くのエントリーを持っていると予想するネットワークのセンターにあるでしょう)。 さらに、ルートエントリーの数がかなり(例えば、1桁)変化するなら、ルータはこの値(そして、対応するJoin/プルーンのHoldtime価値)を変更するかもしれません。 例えば、デフォルト最小のプルーンJoin/期間の価値を考えて、特定のiifとのルートエントリーの数がNからN*100まで増加するなら、ルータはプルーンJoin/期間(そして、プルーンJoin/Holdtime)を増加させるかもしれません、そのインタフェースに、10の要素で。 そして、エントリーの数であるときに、/がNと減少して戻るなら、プルーンJoin/期間(そして、プルーンJoin/Holdtime)は前の値と減少するかもしれません。 プルーンJoin/期間は変更されていて、これらの変更が比較的まれに行われるべきであるということであるかどうか、そして、ルータ
Estrin, et. al. Experimental [Page 39] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [39ページ]実験的なRFC2117PIM-Sm1997年6月
should continue to refresh at its previous Join/Prune-
Period for at least Join/Prune-Holdtime, in order to allow
the upstream router to adapt.
前のJoin/プルーンの期間に少なくともプルーンJoin/Holdtimeのためにリフレッシュし続けるべきです、上流のルータが適合するのを許容するために。
* [Join-Prune Holdtime] This is the Holdtime specified in
Join/Prune messages, and is used to time out oifs. This
should be set to 3.5 * [Join/Prune-Period]. {Default: 210
seconds.}
* [プルーンに合流しているHoldtime] これは、Join/プルーンのメッセージで指定されたHoldtimeであり、タイムアウトoifsに使用されます。 これは3.5に設定されるべきです。*[/プルーン期間を接合します]。 デフォルトとしてください:210秒
* [Join/Prune-Suppression-Timeout] This is the mean
interval between receiving a Join/Prune with a higher
Holdtime (with ties broken by higher IP addres) and
allowing duplicate Join/Prunes to be sent again. This
should be set to approximately 1.25 * [Join/Prune-Period].
{Default: 75 seconds. }
* [/プルーン抑圧タイムアウトを接合します] これは、より高いHoldtime(結びつきが、より高いIP addresによって壊されている)と共にJoin/プルーンを受けて、写しJoin/プルーンが再び送られるのを許容するところの意地悪な間隔です。 これはおよそ1.25に設定されるべきです。*[/プルーン期間を接合します]。 デフォルトとしてください:75秒
* [Data-Timeout] This is the time after which (S,G) state
for a silent source will be deleted. {Default: 210
seconds.}
* [データタイムアウト]これは黙っているソースへの(S、G)状態が削除される時です。 デフォルトとしてください:210秒
* [Register-Suppression-Timeout] This is the mean
interval between receiving a Register-Stop and allowing
Registers to be sent again. A lower value means more
frequent register bursts at RP, while a higher value means
longer join latency for new receivers. {Default: 60
seconds.} (Note that if null Registers are sent [Probe-
Time] seconds before the timeout, register bursts are
prevents, and [Register-Suppression-Timeout] may be lowered
to decrease join latency.)
* [抑圧タイムアウトを登録してください] これはRegister-停止を受けて、Registersが再び送られるのを許容するところの意地悪な間隔です。 下側の値はRPで、より頻繁なレジスタ炸裂を意味します、より高い値が、新しい受信機のために、より長い間潜在を接合することを意味しますが。 デフォルトとしてください:60秒 (タイムアウトの秒前の[徹底的調査時間]のときにヌルRegistersを送るなら、レジスタ炸裂が送ることに注意してください、防止、[レジスタ抑圧タイムアウト] 下ろされて、減少するのが潜在を接合するということであるかもしれません。)
* [Probe-Time] When null Registers are used, this is the
time between sending a null Register and the Register-
Suppression-Timer expiring unless it is restarted by
receiving a Register-Stop. Thus, a null Register would be
sent when the Register-Suppression-Timer reaches this
value. {Default: 5 seconds.}
* ヌルRegistersが使用されている[徹底的調査時間]、これはそれがRegister-停止を受けることによって再開されない場合ヌルRegisterとRegister抑圧タイマを期限が切れさせることの間の時間です。 Register抑圧タイマがこの値に達するとき、したがって、ヌルRegisterを送るでしょう。 デフォルトとしてください:5秒
* [Assert-Timeout] This is the interval between the last
time an Assert is received, and the time at which the
assert is timed out. {Default: 180 seconds.}
* [タイムアウトについて断言している]これがAssertが受け取られている最後の時、時の間隔である、どれ、断言、外では、調節されているか。 デフォルトとしてください:180秒
* [Random-Delay-Join-Timeout] This is the maximum
interval between the time when the RPF neighbor changes,
and the time at which a triggered Join/Prune message is
sent. {Default: 4.5 seconds.}
* [無作為の遅れはタイムアウトを接合します] これはRPF隣人が変化する時、引き起こされたJoin/プルーンのメッセージが送られる時の最大の間隔です。 デフォルトとしてください:4.5秒
* [Hello-Period] This is the interval between sending
Hello messages. {Default: 30 seconds.}
* [こんにちは、-、以上、]、これは送付Helloメッセージの間隔です。 デフォルトとしてください:30秒
Estrin, et. al. Experimental [Page 40] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [40ページ]実験的なRFC2117PIM-Sm1997年6月
* [Hello-Holdtime] This is the Holdtime specified in
Hello messages, after which neighbors will time out their
neighbor entries for the router. This should be set to 3.5
* [Hello-Period]. {Default: 105 seconds.}
* [こんにちは、-、Holdtime、]、これは隣人がルータのための彼らの隣人エントリーをタイムアウトに望んでいるHelloメッセージで指定されたHoldtimeです。 これが3.5に*を設定することであるべきである、[こんにちは、-、以上、] デフォルトとしてください:105秒
* [C-RP-Adv-Period] For C-RPs, this is the interval
between sending C-RP-Adv messages. {Default: 60 seconds.}
* [C RP-Advの期間] C-RPsに関しては、これは送付C-RP-Advメッセージの間隔です。 デフォルトとしてください:60秒
* [RP-Holdtime] For C-RPs, this is the Holdtime specified
in C-RP-Adv messages, and is used by the BSR to time out
RPs. This should be set to 2.5 * [C-RP-Adv-Period].
{Default: 150 seconds.}
* C-RPsのための[RP-Holdtime]、これは、C-RP-Advメッセージで指定されたHoldtimeであり、BSRによってタイムアウトRPsに使用されます。 これは2.5に設定されるべきです。*[C RP-Advの期間]。 デフォルトとしてください:150秒
* [Bootstrap-Period] At the elected BSR, this is the
interval between originating Bootstrap messages, and should
be equal to 60 seconds.
* [期間を独力で進んだ] 選出されたBSRでは、これは、由来しているBootstrapメッセージの間隔であり、60秒と等しいはずです。
* [Bootstrap-Timeout] This is the time after which the
elected BSR will be assumed unreachable when Bootstrap
messages are not received from it. This should be set to
2.5 * [Bootstrap-Period]. {Default: 150 seconds.}
* [タイムアウトを独力で進んだ]これはBootstrapメッセージがそれから受け取られない選出されたBSRが手が届かないと思われる時です。 これは2.5に設定されるべきです。*[期間を独力で進んだ]。 デフォルトとしてください:150秒
Estrin, et. al. Experimental [Page 41] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [41ページ]実験的なRFC2117PIM-Sm1997年6月
3.9 Summary of flags used
3.9 使用される旗の概要
Following is a summary of all the flags used in our scheme.
以下に、私たちの計画に使用されるすべての旗の概要があります。
Bit | Used in | Definition
ビット| 使用にされる| 定義
Authoritative | C-RP-Adv | Group-prefix information should not be
over-ridden by BSR
Border | Register | Register for external sources is coming
from PIM multicast border router
Null | Register | Register sent as Probe of RP, the
encapsulated IP data packet should not
be forwarded
RPT | Route entry | Entry represents state on the RP-tree
RPT | Join/Prune | Join is associated with the shared tree
and therefore the Join/Prune message is
propagated along the RP-tree (source
encoded is an RP address)
RPT | Assert | The data packet was routed down the shared
tree; thus, the path indicated corresponds
to the RP tree
SPT | (S,G) entry | Packets have arrived on the iif towards S,
and the iif is different from the (*,G)
iif
WC |Join | The receiver expects to receive packets
from all sources via this (shared tree)
path. Thus, the Join/Prune applies to a
(*,G) entry
WC | Route entry | Wildcard entry; if there is no more
specific match for a particular source,
packets will be forwarded according to
this entry
正式| C-RP-Adv| BSR Borderはグループ接頭語情報をくつがえすはずがありません。| レジスタ| 外部電源へのレジスタはPIMマルチキャスト境界ルータNullから来るでしょう。| レジスタ| レジスタはRPのProbeとして発信して、要約のIPデータ・パケットにRPTを送るべきではありません。| ルートエントリー| エントリーはRP-木のRPTに状態を表します。| /プルーンに合流してください。| 接合、共有された木としたがって、Join/プルーンのメッセージに関連づけられているのが、RP-木に沿って伝播された(コード化されたソースはRPアドレスである)RPTであるということです。| 断言します。| データ・パケットは共有された木の下側に発送されました。 その結果、RP木のSPTに対応しています経路が、示した。| (S、G) エントリー| パケットはiifでSに向かって到着しました、そして、iifは(*、G)iifトイレと異なっています。|接合してください。| 受信機は、この(共有された木)経路を通してすべてのソースからパケットを受けると予想します。 したがって、Join/プルーンは(*、G)エントリートイレに適用されます。| ルートエントリー| ワイルドカードエントリー。 特定のソースへのそれ以上の特定のマッチがないと、このエントリーに応じて、パケットを進めるでしょう。
3.10 Security
3.10 セキュリティ
All PIM control messages may use IPSec [6] to address security concerns.
すべてのPIMコントロールメッセージが、安全上の配慮を記述するのにIPSec[6]を使用するかもしれません。
4 Packet Formats
4 パケット形式
This section describes the details of the packet formats for PIM control messages.
このセクションはPIMコントロールメッセージのためにパケット・フォーマットの詳細について説明します。
All PIM control messages have protocol number 103.
すべてのPIMコントロールメッセージには、プロトコル番号103があります。
Estrin, et. al. Experimental [Page 42] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [42ページ]実験的なRFC2117PIM-Sm1997年6月
Basically, PIM messages are either unicast (e.g. Registers and Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group `224.0.0.13' (e.g. Join/Prune, Asserts, etc.).
'分類してください'。PIMメッセージが基本的に、ユニキャスト(例えば、RegistersとRegister-停止)かマルチキャストホップのどちらかであることごとの'、すべて、-、PIM-ROUTERS、224.0 .0 .13 '(例えば、Join/プルーン、Assertsなど。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Addr length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver
PIM Version number is 2.
PIM Ver PIMバージョン番号は2です。
Type Types for specific PIM messages. PIM Types are:
特定のPIMメッセージのためにTypesをタイプしてください。 PIM Typesは以下の通りです。
0 = Hello
1 = Register
2 = Register-Stop
3 = Join/Prune
4 = Bootstrap
5 = Assert
6 = Graft (used in PIM-DM only)
7 = Graft-Ack (used in PIM-DM only)
8 = Candidate-RP-Advertisement
0が等しい、こんにちは、3=が参加するか、または剪定するレジスタ停止4 1つの=レジスタ2==は汚職(中では、PIM-DMだけを使用する)7=汚職-Ack(PIM-DMだけでは、使用される)8=候補RP=が6であると断言する5=広告を独力で進みます。
Addr length
Address length in bytes. Throughout this section this
would indicate the number of bytes in the Address field of
an address, including unicast and group addresses.
バイトで表現されるAddr長さのAddressの長さ。 このセクション中では、これはアドレスのAddress分野でバイト数を示すでしょう、ユニキャストとグループアドレスを含んでいて。
Checksum
The checksum is the 16-bit one's complement of the one's
complement sum of the entire PIM message, (excluding the
data portion in the Register message). For computing the
checksum, the checksum field is zeroed.
チェックサム、チェックサムは全体のPIMメッセージの1の補数合計、(データがRegisterメッセージで分配する除外)の16ビットの1の補数です。 チェックサムを計算するのにおいて、チェックサム分野のゼロは合わせられています。
4.1 Encoded Source and Group Address formats
4.1 コード化されたSourceとGroup Address形式
1 Unicast address: Only the address is included. The length
of the unicast address in bytes is specified in the `Addr
length' field in the header.
1 ユニキャストアドレス: アドレスだけが含まれています。 バイトで表現されるユニキャストアドレスの長さはヘッダーの'Addrの長さ'分野で指定されます。
2 Encoded-Group-Address: Takes the following format:
2 コード化されたグループアドレス: 以下の形式を取ります:
Estrin, et. al. Experimental [Page 43] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [43ページ]実験的なRFC2117PIM-Sm1997年6月
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Mask Len | Group multicast Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Group multicast Address ...| +-+-+-+-+-+-+-+-+-+-+~+~+~+~+~+~+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| レンにマスクをかけてください。| マルチキャストAddressを分類してください… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...マルチキャストAddressを分類してください…| +-+-+-+-+-+-+-+-+-+-+~+~+~+~+~+~+
Reserved
Transmitted as zero. Ignored upon receipt.
ゼロとしての予約されたTransmitted。 領収書では、無視されます。
Mask Length
The Mask length is 8 bits. The value is the number of
contiguous bits left justified used as a mask which
describes the address. It is less than or equal to
Addr length * 8. If the message is sent for a single
group then the Mask length must equal Addr length * 8
(i.e. 32 for IPv4 and 128 for IPv6).
Lengthにマスクをかけてください。Maskの長さは8ビットです。 値はアドレスについて説明するマスクとして使用されていた状態で正当化されるように残っている隣接のビットの数です。 それは、よりAddr長さ*8以下です。 ただ一つのグループのためにメッセージを送るなら、Maskの長さはAddr長さ*8(すなわち、IPv4のための32とIPv6のための128)と等しくなければなりません。
Group multicast Address
contains the group address, and has number of bytes
equal to that specified in the Addr length field.
グループマルチキャストAddressはグループアドレスを含んでいて、Addr長さの分野で指定されたそれと等しいバイト数を持っています。
3 Encoded-Source-Address: Takes the following format:
3 コード化されたソースアドレス: 以下の形式を取ります:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsrvd |S|W|R| Mask Len | Source Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsrvd|S|W|R| レンにマスクをかけてください。| ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+-+
Reserved
Transmitted as zero, ignored on receipt.
領収書の上で無視されたゼロとしての予約されたTransmitted。
S,W,R See Section 4.5 for details.
S、W、詳細のためのR Seeセクション4.5。
Estrin, et. al. Experimental [Page 44] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [44ページ]実験的なRFC2117PIM-Sm1997年6月
Mask Length
Mask length is 8 bits. The value is the number of
contiguous bits left justified used as a mask which
describes the address. The mask length must be less
than or equal to Addr Length * 8. If the message is
sent for a single source then the Mask length must
equal Addr length * 8. In version 2 of PIM, it is
strongly recommended that this field be set to 32 for
IPv4.
マスクLength Maskの長さは8ビットです。 値はアドレスについて説明するマスクとして使用されていた状態で正当化されるように残っている隣接のビットの数です。 マスクの長さはAddr Length*8以下であるに違いありません。 単独のソースにメッセージを送るなら、Maskの長さはAddr長さ*8と等しくなければなりません。 PIMのバージョン2では、この分野がIPv4のために32に設定されることが強く勧められます。
Source Address
The address length is indicated from the Addr length
field at the beginning of the header. For IPv4, the
address length is 4 octets.
Addressの出典を明示してください。アドレスの長さはヘッダーの始めにAddr長さの分野から示されます。 IPv4に関しては、アドレスの長さは4つの八重奏です。
4.2 Hello Message
4.2に、こんにちは、メッセージ
It is sent periodically by routers on all interfaces.
ルータはすべてのインタフェースで定期的にそれを送ります。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Addr length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType| OptionLength| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType| OptionLength| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
PIM Version, Type, Addr length, Checksum
Described above.
PIMバージョン、Type、Addrの長さ、上のChecksum Described。
OptionType
The type of the option given in the following OptionValue
field.
以下のOptionValue分野で与えられたオプションのタイプのOptionType。
OptionLength
The length of the OptionValue field in bytes.
バイトで表現されるOptionValue分野の長さのOptionLength。
Estrin, et. al. Experimental [Page 45] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [45ページ]実験的なRFC2117PIM-Sm1997年6月
OptionValue
A variable length field, carrying the value of the option.
オプションの値を運ぶOptionValue A可変長フィールド。
The Option fields may contain the following values:
Option分野は以下の値を含むかもしれません:
* OptionType = 1; OptionLength = 2; OptionValue = Holdtime;
where Holdtime is the amount of time a receiver must keep
the neighbor reachable, in seconds. If the Holdtime is set
to `0xffff', the receiver of this message never times out
the neighbor. This may be used with ISDN lines, to avoid
keeping the link up with periodic Hello messages.
Furthermore, if the Holdtime is set to `0', the information
is timed out immediately.
* OptionType=1。 OptionLength=2。 OptionValueはHoldtimeと等しいです。 Holdtimeが時間であるところでは、受信機は秒に隣人を届くように保たなければなりません。 Holdtimeがそうなら、隣人から'0xffff'、このメッセージの受信機に決して少しの回も設定しないでください。 これは、周期的なHelloメッセージでリンクを維持するのを避けるのにISDN線と共に使用されるかもしれません。 その上、Holdtimeが'0'に用意ができているなら、情報はすぐに、外で調節されています。
* OptionType 2 to 16: reserved
* OptionType2〜16: 予約されます。
* The rest of the OptionTypes are defined in another
document.
* OptionTypesの残りは別のドキュメントで定義されます。
In general, options may be ignored; but a router must not ignore the 'Holdtime' OptionType.
一般に、オプションは無視されるかもしれません。 しかし、ルータは'Holdtime'OptionTypeを無視してはいけません。
4.3 Register Message
4.3 レジスタメッセージ
A Register message is sent by the DR or a PMBR to the RP when a multicast packet needs to be transmitted on the RP-tree. Source IP address is set to the address of the DR, destination IP address is to the RP's address.
マルチキャストパケットが、RP-木の上で伝えられる必要があるとき、RegisterメッセージはDRかPMBRによってRPに送られます。 ソースIPアドレスはDRのアドレスに設定されて、RPのアドレスには送付先IPアドレスがあります。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Addr length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Multicast data packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|N| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ マルチキャストデータ・パケット~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Addr length, Checksum
Described above. {Note that the checksum for Registers
is done only on the PIM header, excluding the data packet
portion.}
PIMバージョン、Type、Addrの長さ、上のChecksum Described。 データ・パケット部分を除いて、PIMヘッダーだけでRegistersのためのチェックサムをすることに注意してください。
Estrin, et. al. Experimental [Page 46] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [46ページ]実験的なRFC2117PIM-Sm1997年6月
B The Border bit. If the router is a DR for a source that it
is directly connected to, it sets the B bit to 0. If the
router is a PMBR for a source in a directly connected
cloud, it sets the B bit to 1.
B Borderは噛み付きました。 ルータがそれが直接接されるソースへのDRであるなら、それはBビットを0に設定します。 ルータが直接接続された雲におけるソースへのPMBRであるなら、それはBビットを1に設定します。
N The Null-Register bit. Set to 1 by a DR that is probing
the RP before expiring its local Register-Suppression
timer. Set to 0 otherwise.
噛み付かれたN Null-レジスタ。 地方のRegister-抑圧タイマを吐き出す前にRPを調べる予定であるDRで1にセットしてください。 そうでなければ、0にセットしてください。
Multicast data packet
The original packet sent by the source.
オリジナルのパケットがソースで送ったマルチキャストデータ・パケット。
For (S,G) null Registers, the Multicast data packet portion contains only a dummy IP header with S as the source address, G as the destination address, and a data length of zero.
(S、G)ヌルRegistersに関しては、Multicastデータ・パケット部分はSと共にソースアドレス、送付先アドレスとしてのG、およびゼロのデータの長さとしてダミーのIPヘッダーだけを含んでいます。
4.4 Register-Stop Message
4.4 レジスタ停止メッセージ
A Register-Stop is unicast from the RP to the sender of the Register message. Source IP address is the address to which the register was addressed. Destination IP address is the source address of the register message.
RPからRegisterメッセージの送付者までRegister-停止はユニキャストです。 ソースIPアドレスはレジスタが記述されたアドレスです。 送付先IPアドレスはレジスタメッセージのソースアドレスです。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Addr length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast-Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Addr length, Checksum
Described above.
PIMバージョン、Type、Addrの長さ、上のChecksum Described。
Encoded-Group Address
Format described above. Note that for Register-Stops the
Mask Len field contains Addr length * 8 (32 for IPv4), if
the message is sent for a single group.
上で説明されたコード化されたグループAddress Format。 Register-停止に、Maskレン分野がAddr長さ*8(IPv4のための32)を含むことに注意してください、ただ一つのグループのためにメッセージを送るなら。
Unicast-Source Address
IP host address of source from multicast data packet in
register. The length of this field in bytes is specified in
the Addr length field. A special wild card value (0.0.0.0),
can be used to indicate any source.
レジスタのマルチキャストデータ・パケットからのソースのユニキャストソースAddress IPホスト・アドレス。 バイトで表現されるこの分野の長さはAddr長さの分野で指定されます。 特別なワイルドカード値、(0.0 .0 .0) どんなソースも示すのに使用できます。
Estrin, et. al. Experimental [Page 47] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [47ページ]実験的なRFC2117PIM-Sm1997年6月
4.5 Join/Prune Message
4.5は、メッセージを接合するか、または剪定します。
A Join/Prune message is sent by routers towards upstream sources and RPs. Joins are sent to build shared trees (RP trees) or source trees (SPT). Prunes are sent to prune source trees when members leave groups as well as sources that do not use the shared tree.
ルータはJoin/プルーンのメッセージを上流のソースとRPsに向かって送ります。 接合、共有された木(RP木)かソース木(SPT)を建てるために、送ります。 メンバーが共有された木を使用しないソースと同様にグループを出るとき、ソース木を剪定するためにプルーンを送ります。
Estrin, et. al. Experimental [Page 48] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [48ページ]実験的なRFC2117PIM-Sm1997年6月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Addr length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast-Upstream Neighbor Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Multicast Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Multicast Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャスト上流隣人アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| ヌムグループ| Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたマルチキャストグループアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースの数| 剪定されたソースの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて接合されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて接合されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたマルチキャストグループアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースの数| 剪定されたソースの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて接合されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて接合されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 49] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [49ページ]実験的なRFC2117PIM-Sm1997年6月
PIM Version, Type, Addr length, Checksum
Described above.
PIMバージョン、Type、Addrの長さ、上のChecksum Described。
Upstream Neighbor Address
The IP address of the RPF or upstream neighbor.
IPが記述するRPFか上流の隣人の上流のNeighbor Address。
Reserved
Transmitted as zero, ignored on receipt.
領収書の上で無視されたゼロとしての予約されたTransmitted。
Holdtime
The amount of time a receiver must keep the Join/Prune
state alive, in seconds. If the Holdtime is set to
`0xffff', the receiver of this message never times out the
oif. This may be used with ISDN lines, to avoid keeping the
link up with periodical Join/Prune messages. Furthermore,
if the Holdtime is set to `0', the information is timed out
immediately.
秒の受信機がJoin/プルーンの状態を生かさなければならない時間のHoldtime。 Holdtimeがそうなら、oifから'0xffff'、このメッセージの受信機に決して少しの回も設定しないでください。 これは、定期刊行のJoin/プルーンのメッセージでリンクを維持するのを避けるのにISDN線と共に使用されるかもしれません。 その上、Holdtimeが'0'に用意ができているなら、情報はすぐに、外で調節されています。
Number of Groups
The number of multicast group sets contained in the
message.
マルチキャストグループセットの数がメッセージに含んだGroupsの数。
Encoded-Multicast group address
For format description see Section
4.1. A wild card group in the (*,*,RP) join is represented
by a 224.0.0.0 in the group address field and `4' in the
mask length field. A (*,*,RP) join also has the WC-bit and
the RPT-bit set.
コード化されたマルチキャストグループアドレスFor書式の記述はセクション4.1を見ます。 (*、*、RP)は接合します。中のワイルドカードグループ、グループアドレスの.0がさばくa224.0.0と'4'時までには、マスク長さの分野では、表されます。 (*、*、RP)は接合します、また、トイレビットとRPT-ビットはセットしましたか?
Number of Joined Sources
Number of join source addresses listed for a given group.
Joined Sources Numberの数、与えられたグループのために記載されたソースアドレスを接合してください。
Join Source Address-1 .. n
This list contains the sources that the sending router
will forward multicast datagrams for if received on the
interface this message is sent on.
Source Address-1を接合してください。n Thisリストはこのメッセージが送られるインタフェースに受け取るなら送付ルータがマルチキャストデータグラムを送るソースを含んでいます。
See format section 4.1. The fields explanation for the
Encoded-Source-Address format follows:
形式部4.1を見てください。 Encodedソースアドレス形式のための説明が続く野原:
Reserved
Described above.
上の予約されたDescribed。
S The Sparse bit is a 1 bit value, set to 1 for PIM-SM.
It is used for PIM v.1 compatibility.
噛み付かれたS SparseはPIM-SMのために1に設定された1ビットの値です。 それはPIM v.1の互換性に使用されます。
Estrin, et. al. Experimental [Page 50] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [50ページ]実験的なRFC2117PIM-Sm1997年6月
W The WC bit is a 1 bit value. If 1, the join or prune
applies to the (*,G) or (*,*,RP) entry. If 0, the join
or prune applies to the (S,G) entry where S is Source
Address. Joins and prunes sent towards the RP must
have this bit set.
噛み付かれたWトイレは1ビットの値です。 1であるなら接合してください。さもないと、プルーンが、接合する、(*、G) または、(*、*、RP)エントリー。 0であるなら適用する、接合してください。さもないと、プルーンはSがSource Addressである(S、G)エントリーに適用されます。 このビットが必須で設定するRPに向かって送って、接合して、剪定します。
R The RPT-bit is a 1 bit value. If 1, the information
about (S,G) is sent towards the RP. If 0, the
information must be sent toward S, where S is the
Source Address.
R、RPT-ビットは1ビットの値です。 1、(S、G)の情報をRPに向かって送るなら。 0であるなら、Sに向かって情報を送らなければなりません。そこでは、SがSource Addressです。
Mask Length, Source Address
Described above.
Length、上のSource Address Describedにマスクをかけてください。
Represented in the form of < WC-bit >< RPT-bit > < Mask length
><Source address>:
<トイレビット><RPT-ビット><Maskの長さの><Sourceアドレス>の形で表される:
A source address could be a host IP address :
ソースアドレスはホストIPアドレスであるかもしれません:
< 0 >< 0 >< 32 >< 192.1.1.17 >
<0><0><32><192.1.1.17>。
A source address could be the RP's IP address :
ソースアドレスはRPのIPアドレスであるかもしれません:
< 1 >< 1 >< 32 >< 131.108.13.111 >
1>の1>の<<<32><131.108.13.111>。
A source address could be a subnet address to prune from the
RP-tree :
ソースアドレスはRP-木から剪定するサブネットアドレスであるかもしれません:
< 0 >< 1 >< 28 >< 192.1.1.16 >
<0><1><28><192.1.1.16>。
A source address could be a general aggregate :
ソースアドレスは一般的な集合であるかもしれません:
< 0 >< 0 >< 16 >< 192.1.0.0 >
<0><0><16><192.1.0.0>。
Number of Pruned Sources
Number of prune source addresses listed for a group.
プルーンのソースアドレスのPruned Sources Numberの数はグループのために記載しました。
Prune Source Address-1 .. n
This list contains the sources that the sending router
does not want to forward multicast datagrams for when
received on the interface this message is sent on. If the
Join/Prune message boundary exceeds the maximum packet
size, then the join and prune lists for the same group must
be included in the same packet.
Source Address-1から余計なものを取り除いてください。n Thisリストは送付ルータがインタフェースに受け取って、このメッセージが転送される時の間にマルチキャストデータグラムを進めたがっていないソースを含んでいます。 メッセージ限界はJoin/プルーンであるなら最大のパケットサイズを超えています、そして含まれているコネが同じパケットであったに違いないなら同じグループのためのリストを接合して、剪定してください。
Estrin, et. al. Experimental [Page 51] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [51ページ]実験的なRFC2117PIM-Sm1997年6月
4.6 Bootstrap Message
4.6はメッセージを独力で進みます。
The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group, out all interfaces having PIM neighbors (excluding the one over which the message was received). Bootstrap messages are sent with TTL value of 1. Bootstrap messages originate at the BSR, and are forwarded by intermediate routers.
Bootstrapメッセージがマルチキャストである、'、すべて、-、PIM-ROUTERS、'PIM隣人(メッセージが受け取られたものを除いた)がいるすべてのインタフェースから、分類してください。 メッセージを独力で進んでください。1のTTL値と共に送ります。 メッセージを独力で進んでください。BSRで由来して、中間的ルータは進めます。
Bootstrap message is divided up into `semantic fragments', if the original message exceeds the maximum packet size boundaries.
オリジナルのメッセージが最大のパケットサイズ境界を超えているなら'意味断片'に上がった状態で分割されたメッセージを独力で進んでください。
The semantics of a single `fragment' is given below:
単一の'断片'の意味論を以下に与えます:
Estrin, et. al. Experimental [Page 52] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [52ページ]実験的なRFC2117PIM-Sm1997年6月
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Addr length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Tag | Hash Mask len | BSR-priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast-BSR-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-1 | Frag RP-Cnt-1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | Unicast- . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RP-Address-2 | RP2-Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | Encoded- . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Group Address-2 . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-m | Frag RP-Cnt-m | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | Unicast- . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RP-Address-2 | RP2-Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 断片タグ| 細切れ肉料理Mask len| BSR-優先権| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストBSRアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPカウント1| RP-Cnt-1を破片手榴弾で殺傷してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストRPアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime| ユニキャスト…| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RPアドレス2| RP2-Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストRPアドレスm| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rpm Holdtime| コード化されます…| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . アドレス-2を分類してください…| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPはmを数えます。| RP-Cnt-mを破片手榴弾で殺傷してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストRPアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime| ユニキャスト…| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RPアドレス2| RP2-Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストRPアドレスm| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rpm Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 53] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [53ページ]実験的なRFC2117PIM-Sm1997年6月
PIM Version, Type, Addr length, Checksum
Described above.
PIMバージョン、Type、Addrの長さ、上のChecksum Described。
Fragment Tag
A randomly generated number, acts to distinguish the
fragments belonging to different Bootstrap messages;
fragments belonging to same Bootstrap message carry the
same `Fragment Tag'.
断片Tag Aは数、異なったBootstrapメッセージに属す断片を区別する行為を手当たりしだいに発生させました。 同じBootstrapメッセージに属す断片が同じ'断片Tag'を運びます。
Hash Mask len
The length (in bits) of the mask to use in the hash
function. For IPv4 we recommend a value of 30. For IPv6 we
recommend a value of 126.
細切れ肉料理の中に使用するマスクの長さ(ビットの)の細切れ肉料理Mask lenは機能します。 IPv4に関しては、私たちは30の値を推薦します。 IPv6に関しては、私たちは126の値を推薦します。
BSR-priority
Contains the BSR priority value of the included BSR. This
field is considered as a high order byte when comparing BSR
addresses.
BSR-優先権Contains、含まれているBSRのBSR優先順位の値。 BSRアドレスを比較するとき、この分野は高位バイトであるとみなされます。
Unicast-BSR-Address
The IP address of the bootstrap router for the domain. The
length of this field in bytes is specified in Addr length.
IPが記述するユニキャストBSRアドレス、ドメインにルータを独力で進んでください。 バイトで表現されるこの分野の長さはAddrの長さで指定されます。
Encoded-Group Address-1..n
The group prefix (address and mask) with which the
Candidate RPs are associated. Format previously described.
コード化されたグループアドレス-1。Candidate RPsが関連しているグループが前に置くn(記述して、マスクをかけます)。 以前に説明された形式。
RP-Count-1..n
The number of Candidate RP addresses included in the whole
Bootstrap message for the corresponding group prefix. A
router does not replace its old RP-Set for a given group
prefix until/unless it receives `RP-Count' addresses for
that prefix; the addresses could be carried over several
fragments. If only part of the RP-Set for a given group
prefix was received, the router discards it, without
updating that specific group prefix's RP-Set.
RPは1を数えます。対応への全体のBootstrapメッセージにCandidate RPアドレスの数を含んでいるnは接頭語を分類します。 その接頭語のための'RP-カウント'というアドレスを受け取らない場合、ルータは与えられたグループ接頭語のために/まで古いRP-セットに取って代わりません。 数個の断片の上までアドレスを運ぶことができました。 与えられたグループ接頭語のためのRP-セットの一部だけを受け取ったなら、ルータはそれを捨てます、その特定のグループ接頭語のRP-セットをアップデートしないで。
Frag RP-Cnt-1..m
The number of Candidate RP addresses included in this
fragment of the Bootstrap message, for the corresponding
group prefix. The `Frag RP-Cnt' field facilitates parsing
of the RP-Set for a given group prefix, when carried over
more than one fragment.
RP-Cnt-1を破片手榴弾で殺傷してください。対応するグループ接頭語へのBootstrapメッセージのこの断片にCandidate RPアドレスの数を含んでいるm。 'RP-Cntを破片手榴弾で殺傷してください'という分野は1個以上の断片の上まで運ばれた状態で与えられたグループ接頭語のためのRP-セットの構文解析、いつを容易にするか。
Unicast-RP-address-1..m
The address of the Candidate RPs, for the corresponding
group prefix. The length of this field in bytes is
specified in Addr length.
ユニキャストRPは1を記述します。m、対応するグループ接頭語のためのCandidate RPsのアドレス。 バイトで表現されるこの分野の長さはAddrの長さで指定されます。
Estrin, et. al. Experimental [Page 54] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [54ページ]実験的なRFC2117PIM-Sm1997年6月
RP1..m-Holdtime
The Holdtime for the corresponding RP. This field is copied
from the `Holdtime' field of the associated RP stored at
the BSR.
RP1。対応するRPのためのm-Holdtime Holdtime。 この分野はBSRに格納された関連RPの'Holdtime'分野からコピーされます。
4.7 Assert Message
4.7はメッセージについて断言します。
The Assert message is sent when a multicast data packet is received on an outgoing interface corresponding to the (S,G) or (*,G) associated with the source.
対応しながら外向的なインタフェースにマルチキャストデータ・パケットを受け取るとき、Assertメッセージを送る、(S、G)かソースに関連している(*、G。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Addr length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast-Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| メートル法の好み| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Addr length, Checksum
Described above.
PIMバージョン、Type、Addrの長さ、上のChecksum Described。
Encoded-Group Address
The group address to which the data packet was addressed,
and which triggered the Assert. Format previously
described.
データ・パケットが記述されて、Assertの引き金となったグループが記述するコード化されたグループAddress。 以前に説明された形式。
Unicast-Source Address
Source IP address from IP multicast datagram that
triggered the Assert packet to be sent. The length of this
field in bytes is specified in Addr length.
送られるAssertパケットの引き金となったIPマルチキャストデータグラムからのユニキャストソースAddress Source IPアドレス。 バイトで表現されるこの分野の長さはAddrの長さで指定されます。
R RPT-bit is a 1 bit value. If the IP multicast datagram
that triggered the Assert packet is routed down the RP
tree, then the RPT-bit is 1; if the IP multicast datagram
is routed down the SPT, it is 0.
R RPT-ビットは1ビットの値です。 Assertパケットの引き金となったIPマルチキャストデータグラムがRP木の下側に発送されるなら、RPT-ビットは1です。 IPマルチキャストデータグラムがSPTの下側に発送されるなら、それは0です。
Metric Preference
Preference value assigned to the unicast routing protocol
that provided the route to Host address.
メートル法のPreference Preference値はHostアドレスへのルートであるならユニキャストルーティング・プロトコルにそれを割り当てました。
Estrin, et. al. Experimental [Page 55] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [55ページ]実験的なRFC2117PIM-Sm1997年6月
Metric The unicast routing table metric. The metric is in units
applicable to the unicast routing protocol used.
メートル法、ユニキャスト経路指定テーブルメートル法です。 メートル法がルーティング・プロトコルが使用したユニキャストに適切なユニットにあります。
4.8 Graft Message
4.8 汚職メッセージ
Used in dense-mode. Refer to PIM dense mode specification.
濃いモードで、使用されています。 PIMの濃いモード仕様を参照してください。
4.9 Graft-Ack Message
4.9 汚職-Ackメッセージ
Used in dense-mode. Refer to PIM dense mode specification.
濃いモードで、使用されています。 PIMの濃いモード仕様を参照してください。
4.10 Candidate-RP-Advertisement
4.10 候補RP広告
Candidate-RP-Advertisements are periodically unicast from the C-RPs to the BSR.
定期的に候補RP広告はそうです。C-RPsからBSRまでのユニキャスト。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Addr length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Cnt |A| Reserved | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast-RP-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| Addrの長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語-Cnt|A| 予約されます。| Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャストRPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Addr length, Checksum
Described above.
PIMバージョン、Type、Addrの長さ、上のChecksum Described。
Prefix-Cnt
The number of encoded group addresses included in the
message; indicating the group prefixes for which the C-RP
is advertising. A Prefix-Cnt of `0' implies a prefix of
224.0.0.0 with mask length of 4; i.e. all multicast groups.
If the C-RP is not configured with Group-prefix
information, the C-RP puts a default value of `0' in this
field.
メッセージにコード化されることの数が分類する接頭語-Cntアドレスを含んでいます。 C-RPが広告であるグループ接頭語を示します。 '0'のPrefix-Cntが224.0の接頭語を含意する、.0 .0 4のマスクの長さで。 すなわちすべてのマルチキャストが分類されます。 C-RPがGroup-接頭語情報によって構成されないなら、C-RPはこの分野の'0'のデフォルト値を置きます。
Estrin, et. al. Experimental [Page 56] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [56ページ]実験的なRFC2117PIM-Sm1997年6月
A The Authoritative bit. This bit indicates that the BSR
should not override the group-prefix information indicated
in the C-RP Advertisement. In most cases C-RPs set this bit
to 0.
Authoritativeは噛み付きました。 このビットは、BSRがC-RP Advertisementで示されたグループ接頭語情報に優越するはずがないのを示します。 多くの場合、C-RPsはこのビットを0に設定します。
Holdtime
The amount of time the advertisement is valid. This field
allows advertisements to be aged out.
Holdtime、広告が有効である時間。 この分野は熟成するべき広告の外出することを許します。
Unicast-RP-Address
The address of the interface to advertise as a Candidate
RP. The length of this field in bytes is specified in Addr
length.
ユニキャストRPアドレス、Candidate RPとして広告を出すインタフェースのアドレス。 バイトで表現されるこの分野の長さはAddrの長さで指定されます。
Encoded-Group Address-1..n
The group prefixes for which the C-RP is advertising.
Format previously described.
コード化されたグループアドレス-1。C-RPが広告であるグループが前に置くn。 以前に説明された形式。
5 Acknowledgments
5つの承認
Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang and Girish Chandranmenon provided detailed comments on previous drafts. The authors of CBT [7] and membership of the IDMR WG provided many of the motivating ideas for this work and useful feedback on design details.
トニーBallardie、スコットBrim、ジョン・クロウクロフト、ビル・フェナー、ポール・フランシス、ジョエル・アルペルン、ホルスト・ホーデル、ポリー・ホアン、スティーブン・オストロウスキー、Lixiaチャン、およびGirish Chandranmenonは前の草稿の詳細なコメントを提供しました。 CBT[7]の作者とIDMR WGの会員資格はこの仕事のための動機づけている考えとデザインの詳細の役に立つフィードバックの多くを提供しました。
This work was supported by the National Science Foundation, ARPA, cisco Systems and Sun Microsystems.
この仕事は国立科学財団、ARPA、コクチマスSystems、およびサン・マイクロシステムズによって支持されました。
Estrin, et. al. Experimental [Page 57] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [57ページ]実験的なRFC2117PIM-Sm1997年6月
6 Appendices
6個の付録
6.1 Appendix I: Major Changes and Updates to the Spec
6.1 付録I: 仕様への大きな変化とアップデート
This appendix populates the major changes in the specification document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'.
'草稿ietf-idmr-pim仕様01.ps、txt'と比べて、この付録は仕様ドキュメントにおける大きな変化に居住します。
* Major Changes
* 大きな変化
List of changes since March '96 IETF:
3月の96年IETF以来変化について記載してください:
(*,*,RP) Joins state and data forwarding check; replaces (*,G- Prefix) Joins state for interoperability. (*,G) negative cache introduced for the (*,*,RP) state supporting mechanisms.
(*、*、RP)は状態に加わります、そして、データ推進はチェックします。 取り替え、(*、G接頭語)は相互運用性を州と一緒に楽しみます。 (*、G) 否定的キャッシュは(*、*、RP)状態にサポートメカニズムを取り入れました。
Semantic fragmentation for the Bootstrap message.
Bootstrapメッセージのための意味断片化。
Refinement of Assert details.
Assertの詳細の気品。
Addition and refinement of Join/Prune suppression and Register suppression (introduction of null Registers).
Join/プルーンの抑圧とRegister抑圧(ヌルRegistersの導入)の添加と気品。
Editorial changes and clarifications to the timers section.
タイマ部分への編集の変化と明確化。
Addition of Appendix II (BSR Election and RP-Set Distribution), and Appendix III (Glossary of Terms).
付録II(BSR選挙とRP-セット分配)、および付録III(用語の用語集)の添加。
Addition of table of contents.
目次の添加。
List of changes incurred since version 1 of the spec.:
仕様のバージョン1以来被られた変化のリスト、:
Proposal and refinement of bootstrap router (BSR) election mechanisms
提案と気品、ルータ(BSR)選挙メカニズムを独力で進んでください。
Introduction of hash functions for Group to RP mapping
RPマッピングへのGroupのためのハッシュ関数の導入
New RP-liveness indication mechanisms based upon the the Bootstrap Router (BSR) and the Bootstrap messages.
新しいRP-活性指示メカニズムは(BSR)とBootstrapメッセージをBootstrap Routerに基礎づけました。
Removal of reachability messages, RP reports and multiple RPs per group.
1グループあたりの可到達性メッセージ、RPレポート、および複数のRPsの解任。
* Packet Format Changes
* パケット・フォーマット変化
Packet Format incurred updates to accommodate different address lengths, and address aggregation.
パケットFormatは、異なったアドレスの長さ、およびアドレス集合を収容するためにアップデートを被りました。
Estrin, et. al. Experimental [Page 58] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [58ページ]実験的なRFC2117PIM-Sm1997年6月
1 The `Addr length' field was added to the PIM fixed header
to specify the address length in bytes of the underlying
protocol, see section 4.
1 'Addrの長さ'分野は基本的なプロトコルのバイトで表現されるアドレスの長さを指定するためにヘッダーに固定されたPIMに加えられました、とセクション4は見ます。
2 The Encoded source and group address formats were
introduced, with the use of a `Mask length' field to allow
aggregation, section 4.1.
2 Encodedソースとグループアドレス形式は'マスクの長さ'分野の使用によって紹介されて、集合(セクション4.1)を許容しました。
3 Packet formats are no longer IGMP messages; rather PIM
messages.
3 パケット形式はもうIGMPメッセージではありません。 むしろPIMメッセージ。
PIM message types and formats were also modified:
また、PIMメッセージタイプと形式は変更されました:
[Note: most changes were made to the May 95 version, unless otherwise specified].
[注意: 別の方法で指定しない場合ほとんどの変更を5月95日のバージョンにしました]。
1 Obsolete messages:
1 メッセージを時代遅れにしてください:
Register-Ack [Feb. 96]
レジスタ-Ack[2月96日]
Poll and Poll Response [Feb. 96]
応答に投票して、投票してください。[2月96日]
RP-Reachability [Feb. 96]
RP-可到達性[2月96日]
RPlist-Mapping [Feb. 96]
RPlistを写像しています。[2月96日]
2 New messages:
2つの新しいメッセージ:
Candidate-RP-Advertisement [change made in October 95]
RP-Set [Feb. 96]
候補RP広告[10月95日に行われた変更]RP-セット[2月96日]
3 Modified messages:
3つの変更されたメッセージ:
Join/Prune [Feb. 96]
Register [Feb. 96]
Register-Stop [Feb. 96]
Hello (addition of OptionTypes) [Aug 96]
レジスタ[2月96日]レジスタ停止[2月96日]を参加するか、または剪定してください、[2月96日]こんにちは、(OptionTypesの添加)[8月96日]
4 Renamed messages:
4はメッセージを改名しました:
Query messages are renamed as Hello messages [Aug. 96]
RP-Set messages are renamed as Bootstrap messages [Aug. 96]
Helloメッセージ[8月96日]RP-セットメッセージがBootstrapメッセージとして改名されるように質問メッセージは改名されます。[8月96日]
Estrin, et. al. Experimental [Page 59] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [59ページ]実験的なRFC2117PIM-Sm1997年6月
6.2 Appendix II: BSR Election and RP-Set Distribution
6.2 付録II: BSR選挙とRP-セット分配
For simplicity, the Bootstrap message is used in both the BSR election and the RP-Set distribution.
簡単さのために、BootstrapメッセージはBSR選挙とRP-セット分配の両方で使用されます。
The above two mechanisms; the BSR election, and the RP-Set distribution; are realized through the following state machine, illustrated in figure 4:
上の2つのメカニズム。 BSR選挙、およびRP-セット分配。 以下の州のマシンを通して実感されていて、例証されて、4が中で計算するということです:
[Figures are present only in the postscript version]
Fig. 4 State Diagram for the BSR election and RP-Set
distribution mechanisms
[数字は追伸バージョンだけに存在しています] 図4 BSR選挙のための州DiagramとRP-セット分配メカニズム
The protocol transitions for a C-BSR are given in state diagram (a). For routers not configured as C-BSRs, the protocol transitions are given in state diagram (b).
州のダイヤグラム(a)でC-BSRのためのプロトコル変遷を与えます。 C-BSRsとして構成されなかったルータにおいて、州のダイヤグラム(b)でプロトコル変遷を与えます。
Each PIM router keeps a Bootstrap-timer, initialized to [Bootstrap-Timeout], in addition to a local BSR field `LclBSR' (initialized to a local address if C-BSR, or to 0 otherwise), and a local RP-Set `LclRP-Set' (initially empty). The two main stimuli to the state machine are the timer events, and receiving an Bootstrap message:
それぞれのPIMルータは地方のBSRに加えた[タイムアウトを独力で進みます]の分野'LclBSR'(別の方法でC-BSRであるか、0へのローカルアドレスに初期化される)、および地方のRP-セット'LclRP-セット'に初期化されたBootstrap-タイマを(初めは、空です)に保ちます。 州のマシンへの2つの主な刺激が、タイマ出来事であり、Bootstrapメッセージを受け取っています:
* Initial States and Timer Events
* 初期状態とタイマ出来事
1 If the router is a C-BSR:
1 ルータがC-BSRであるなら:
1 The router operates initially in the `CandBSR' state, where
it does not originate any Bootstrap messages.
1 ルータは初めは、'CandBSR'状態で作動します。そこでは、それがどんなBootstrapメッセージも溯源しません。
2 If the Bootstrap-timer expires, and the current state is
`CandBSR', the router originates an Bootstrap message -
carrying the local RP-Set, and its own BSR priority and
address-, restarts the Bootstrap-timer at [Bootstrap-
Period] seconds and transits into the `ElectedBSR' state.
2 Bootstrap-タイマが期限が切れて、現状が'CandBSR'であるなら、ルータはBootstrapメッセージを溯源します--それ自身の地方のRP-セット、BSR優先権、およびアドレスを運ぶと、Bootstrap-タイマは[期間を独力で進みます]秒とトランジットのときに'ElectedBSR'状態に再開します。
3 If the Bootstrap-timer expires, and the current state is
`ElectedBSR', the router originates an Bootstrap message,
and restarts the RP-Set timer at [Bootstrap-Period]. No
state transition is incurred.
3 Bootstrap-タイマが期限が切れて、現状が'ElectedBSR'であるなら、ルータは、[期間を独力で進みます]でBootstrapメッセージを溯源して、RP-セットタイマを再開します。 状態遷移は全く被られません。
This way, the elected BSR originates periodic Bootstrap
messages every [Bootstrap-Period].
このように、選出されたBSRが周期的なBootstrapメッセージを溯源する、あらゆる、[期間を独力で進んだ。]
Estrin, et. al. Experimental [Page 60] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [60ページ]実験的なRFC2117PIM-Sm1997年6月
2 If a router is not a C-BSR:
2 ルータがC-BSRでないなら:
1 The router operates initially in the 'AxptAny' state. In
such state, a router accepts the first Bootstrap message
from the RPF neighbor toward the included BSR. The Reverse
Path Forwarding (RPF) neighbor in this case is the next hop
router en route to the included BSR.
1 ルータは初めは、'AxptAny'状態で作動します。 そのような状態では、ルータは最初のBootstrapメッセージをRPF隣人から含まれているBSRに向かって受け入れます。 含まれているBSRへの途中で、この場合Reverse Path Forwarding(RPF)隣人は次のホップルータです。
2 If the Bootstrap-timer expires, and the current state is
`AxptPref', -where the router accepts only preferred.
Bootstrap messages from the RPF neighbor toward the
included BSR-, the router transits into the `AxptAny'
state (preferred Bootstrap messages are those that carry
BSR-priority and address higher than, or equal to,
`LclBSR').
2 Bootstrap-タイマが期限が切れて、現状が'AxptPref'であるなら-、どこ、ルータは受け入れるか都合のよいだけである状態で。 RPF隣人からのBSR、包含に向かってルータが'AxptAny'状態に通過するというメッセージを独力で進んでください、(都合のよいBootstrapメッセージがBSR-優先権とアドレスをより高く運ぶものである、等しい、'LclBSR')
In this case, if an elected BSR becomes unreachable, the
routers start accepting Bootstrap messages from another C-
BSR after the Bootstrap-timer expires. All PIM routers
within a domain converge on the preferred (with highest
priority and address) reachable C-BSR.
この場合、選出されたBSRが手が届かなくなるなら、Bootstrap-タイマが期限が切れた後にルータは別のC BSRからBootstrapメッセージを受け入れ始めます。 ドメインの中のすべてのPIMルータが都合のよい(最優先とアドレスがある)届いているC-BSRに集まります。
* Receiving Bootstrap Message
* 受信して、メッセージを独力で進んでください。
To avoid loops, an RPF check is performed on the included BSR address. Upon receiving an Bootstrap message from the RPF neighbor toward the included BSR, the following actions are taken:
輪を避けるために、RPFチェックは含まれているBSRアドレスに実行されます。 RPF隣人からBootstrapメッセージを含まれているBSRに向かって受け取ると、以下の行動を取ります:
1 If the router is not a C-BSR:
1 ルータがC-BSRでないなら:
1 If the current state is 'AxptAny', the router accepts the
Bootstrap message, and transits into the 'AxptPref' state.
1 現状が'AxptAny'であるなら、ルータは、Bootstrapメッセージを受け入れて、'AxptPref'状態に通過します。
2 If the current state is 'AxptPref', and the Bootstrap
message is preferred, the message is accepted. No state
transition is incurred.
2 現状が'AxptPref'であり、Bootstrapメッセージを好むなら、メッセージを受け入れます。 状態遷移は全く被られません。
2 If the router is a C-BSR, and the Bootstrap message is
preferred, the message is accepted. Further, if this happens
when the current state is
2 ルータがC-BSRであり、Bootstrapメッセージを好むなら、メッセージを受け入れます。 現状が起こるとき、さらに、これは起こります。
When an Bootstrap message is accepted, the router restarts the Bootstrap-timer at [Bootstrap-Timeout], stores the received BSR priority and address in `LclBSR', and the received RP-Set in `LclRP-Set', and forwards the Bootstrap message out all interfaces except the receiving interface.
Bootstrapメッセージを受け入れるとき、ルータは、受信インタフェース以外のすべてのインタフェースから'LclBSR'に容認されたBSR優先権とアドレスを格納して、'LclRP-セット'で容認されたRP-セットを格納して、[タイムアウトを独力で進みます]でBootstrap-タイマを再開して、Bootstrapメッセージを転送します。
Estrin, et. al. Experimental [Page 61] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [61ページ]実験的なRFC2117PIM-Sm1997年6月
If an Bootstrap message is rejected, no state transitions are triggered.
Bootstrapメッセージが拒絶されるなら、状態遷移は全く引き起こされません。
6.3 Appendix III: Glossary of Terms
6.3 付録III: 用語の用語集
Following is an alphabetized list of terms and definitions used throughout this specification.
以下に、この仕様中で使用される用語と定義のアルファベット順にされたリストがあります。
* {Bootstrap router (BSR)}. A BSR is a dynamically elected router
within a PIM domain. It is responsible for constructing the RP-
Set and originating Bootstrap messages.
* ルータ(BSR)を独力で進んでください。 BSRはPIMドメインの中のダイナミックに選出されたルータです。 それはRPセットと由来しているBootstrapメッセージを構成するのに責任があります。
* {Candidate-BSR (C-BSR)}. A C-BSR is a router configured to
participate in the BSR election and act as BSRs if elected.
* 候補-BSR(C-BSR)。 C-BSRは選出されるならBSRsとしてBSR選挙と行為に参加するために構成されたルータです。
* {Candidate RP (C-RP)}. A C-RP is a router configured to send
periodic Candidate-RP-Advertisement messages to the BSR, and act
as an RP when it receives Join/Prune or Register messages for
the advertised group prefix.
* 候補RP(C-RP)。 C-RPは周期的なCandidate-RP-広告メッセージをBSRに送るために構成されたルータと、Join/プルーンを受けるときのRPとしての行為か広告を出しているグループ接頭語へのRegisterメッセージです。
* {Designated Router (DR)}. The DR sets up multicast route
entries and sends corresponding Join/Prune and Register messages
on behalf of directly-connected receivers and sources,
respectively. The DR may or may not be the same router as the
IGMP Querier. The DR may or may not be the long-term, last-hop
router for the group; a router on the LAN that has a lower
metric route to the data source, or to the group's RP, may take
over the role of sending Join/Prune messages.
* 代表ルータ(DR)。 DRはそれぞれ直接接続された受信機とソースを代表してマルチキャストルートエントリーをセットアップして、対応するJoin/プルーンとRegisterにメッセージを送ります。 DRはIGMP Querierと同じルータであるかもしれません。 DRはグループのための長期的で、最後のホップのルータであるかもしれません。 データ送信端末、または、グループのRPに低いメートル法のルートを持っているLANに関するルータは送付Join/プルーンのメッセージの役割を引き継ぐかもしれません。
* {Incoming interface (iif)}. The iif of a multicast route entry
indicates the interface from which multicast data packets are
accepted for forwarding. The iif is initialized when the entry
is created.
* 入って来るインタフェース(iif)。 マルチキャストルートエントリーのiifはマルチキャストデータ・パケットが推進のために受け入れられるインタフェースを示します。 エントリーが作成されるとき、iifは初期化されます。
* {Join list}. The Join list is one of two lists of addresses that
is included in a Join/Prune message; each address refers to a
source or RP. It indicates those sources or RPs to which
downstream receiver(s) wish to join.
* リストを接合してください。 JoinリストはJoin/プルーンのメッセージに含まれているアドレスの2つのリストの1つです。 各アドレスはソースかRPについて言及します。 それは接合するというどの川下の受信機願望にそれらのソースかRPsを示すか。
* {Last-hop router}. The last-hop router is the last router to
receive multicast data packets before they are delivered to
directly-connected member hosts. In general the last-hop router
is the DR for the LAN. However, under various conditions
described in this document a parallel router connected to the
same LAN may take over as the last-hop router in place of the
DR.
* 最後にルータを飛び越してください。 最後のホップルータは直接接続されたメンバーホストにそれらを渡す前にマルチキャストデータ・パケットを受ける最後のルータです。 一般に、最後のホップルータはLANのためのDRです。 しかしながら、本書では説明された様々な条件のもとで、同じLANに関連づけられた平行なルータは最後のホップルータとしてDRに代わって引き継ぐかもしれません。
Estrin, et. al. Experimental [Page 62] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [62ページ]実験的なRFC2117PIM-Sm1997年6月
* {Outgoing interface (oif) list}. Each multicast route entry has
an oif list containing the outgoing interfaces to which
multicast packets should be forwarded.
* 外向的なインタフェース(oif)リスト。 それぞれのマルチキャストルートエントリーには、マルチキャストパケットが送られるべきである外向的なインタフェースを含むoifリストがあります。
* {Prune List}. The Prune list is the second list of addresses
that is included in a Join/Prune message. It indicates those
sources or RPs from which downstream receiver(s) wish to prune.
* リストを剪定してください。 PruneリストはJoin/プルーンのメッセージに含まれている2番目の住所録です。 それはどの川下の受信機願望を剪定したらよいかからそれらのソースかRPsを示します。
* {PIM Multicast Border Router (PMBR)}. A PMBR connects a PIM
domain to other multicast routing domain(s).
* PIMマルチキャスト境界ルータ(PMBR)。 PMBRは他のマルチキャスト経路ドメインにPIMドメインをつなげます。
* {Rendezvous Point (RP)}. Each multicast group has a shared-tree
via which receivers hear of new sources and new receivers hear
of all sources. The RP is the root of this per-group shared
tree, called the RP-Tree.
* ポイント(RP)を集合させてください。 それぞれのマルチキャストグループはを通した受信機が新しいソースを知る共有された木と新しい受信機にすべてのソースを知らせます。 RPはRP-木と呼ばれるこの1グループあたりの共有された木の根です。
* {RP-Set}. The RP-Set is a set of RP addresses constructed by
the BSR based on Candidate-RP advertisements received. The RP-
Set information is distributed to all PIM routers in the BSR's
PIM domain.
* RPによって設定されています。 RP-セットは受け取られたCandidate-RP広告に基づくBSRによって構成された1セットのRPアドレスです。 RP情報集合はBSRのPIMドメインのすべてのPIMルータに分配されます。
* {Reverse Path Forwarding (RPF)}. RPF is used to select the
appropriate incoming interface for a multicast route entry . The
RPF neighbor for an IP address X is the the next-hop router used
to forward packets toward X. The RPF interface is the interface
to that RPF neighbor. In the common case this is the next hop
used by the unicast routing protocol for sending unicast packets
toward X. For example, in cases where unicast and multicast
routes are not congruent, it can be different.
* 経路推進(RPF)を逆にしてください。 RPFは、適切な入って来るインタフェースをマルチキャストルートエントリーに選択するのに使用されます。RPF隣人は、IPアドレスXが次のホップルータであるので、以前はよくX.に向かってパケットを送っていました。RPFインタフェースはそのRPF隣人へのインタフェースです。 よくある例では、これは送付ユニキャストパケットにユニキャストルーティング・プロトコルによってX.Forの例に向かって使用される次のホップです、ユニキャストとマルチキャストルートが一致していない、それが異なる場合がある場合で。
* {Route entry.} A multicast route entry is state maintained in a
router along the distribution tree and is created, and updated
based on incoming control messages. The route entry may be
different from the forwarding entry; the latter is used to
forward data packets in real time. Typically a forwarding entry
is not created until data packets arrive, the forwarding entry's
iif and oif list are copied from the route entry, and the
forwarding entry may be flushed and recreated at will.
* ルートエントリー。 入って来るコントロールメッセージに基づいてマルチキャストルートエントリーを分配木に沿ってルータで維持された状態であり、作成して、アップデートします。 ルートエントリーは推進エントリーと異なっているかもしれません。 後者は、リアルタイムでデータ・パケットを進めるのに使用されます。 通常、データ・パケットが到着するまで推進エントリーが作成されないで、推進エントリーのiifとoifリストがルートエントリーからコピーされて、推進エントリーは、自由自在に洗い流されて、休養させられるかもしれません。
* {Shortest path tree (SPT)}. The SPT is the multicast
distribution tree created by the merger of all of the shortest
paths that connect receivers to the source (as determined by
unicast routing).
* 最短パス木(SPT)。 SPTは受信機をソースに接続する最短パスのすべての合併で作成されたマルチキャスト分配木(ユニキャストルーティングで決定するように)です。
* {Sparse Mode (SM)}. SM is one mode of operation of a multicast
protocol. PIM SM uses explicit Join/Prune messages and
Rendezvous points in place of Dense Mode PIM's and DVMRP's
broadcast and prune mechanism.
* まばらなモード(Sm)。 SMはマルチキャストプロトコルの1つの運転モードです。 PIM SMはDVMRPのDense Mode PIMに代わった明白なJoin/プルーンのメッセージとRendezvousポイント、放送、およびプルーンのメカニズムを使用します。
Estrin, et. al. Experimental [Page 63] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [63ページ]実験的なRFC2117PIM-Sm1997年6月
* {Wildcard (WC) multicast route entry}. Wildcard multicast route
entries are those entries that may be used to forward packets
for any source sending to the specified group. Wildcard bots in
the join list of a Join/Prune message represent either a (*,G)
or (*,*,RP) join; in the prune list they represent a (*,G)
prune.
* ワイルドカード(トイレ)マルチキャストルートエントリー。 ワイルドカードマルチキャストルートエントリーは指定されたグループへのどんなソース発信のためにもパケットを進めるのに使用されるかもしれないそれらのエントリーです。 中のワイルドカードウマバエの幼虫、a(*、G)を表してください。さもないと、(*、*、RP)が接合するというJoin/プルーンのメッセージのリストを接合してください。 プルーンのリストでは、彼らは(*、G)プルーンを表します。
* {(S,G) route entry}. (S,G) is a source-specific route entry. It
may be created in response to data packets, Join/Prune messages,
or Asserts. The (S,G) state in routers creates a source-rooted,
shortest path (or reverse shortest path) distribution tree.
(S,G)RPT bit entries are source-specific entries on the shared
RP-Tree; these entries are used to prune particular sources off
of the shared tree.
* (S、G)はエントリーを発送します。 (S、G) ソース特有のルートはエントリーですか? それはデータ・パケット、Join/プルーンのメッセージ、またはAssertsに対応して作成されるかもしれません。 ルータにおける(S、G)州はソースが根づいている最短パス(最短パスを逆にする)分配木を作成します。 (S、G)RPTビットエントリーは共有されたRP-木の上のソース特有のエントリーです。 これらのエントリーは、共有された木からの特定のソースを剪定するのに使用されます。
* {(*,G) route entry}. Group members join the shared RP-Tree for
a particular group. This tree is represented by (*,G) multicast
route entries along the shortest path branches between the RP
and the group members.
* (*、G)はエントリーを発送します。 グループのメンバーは特定のグループのために共有されたRP-木に加わります。 この木はRPとグループのメンバーの間の最短パス支店に沿って(*、G)マルチキャストルートエントリーで表されます。
* {(*,*,RP) route entry}. (*,*,RP) refers to any source and any
multicast group that maps to the RP included in the entry. The
routers along the shortest path branches between a domain's
RP(s) and its PMBRs keep (*,*,RP) state and use it to determine
how to deliver packets toward the PMBRs if data packets arrive
for which there is not a longer match. The wildcard group in the
(*,*,RP) route entry is represented by a group address of
224.0.0.0 and a mask length of 4 bits.
* (*、*、RP)はエントリーを発送します。 (*、*、RP) RPへの地図がエントリーに含んでいたどんなソースとどんなマルチキャストグループについても言及します。 より長いマッチがないデータ・パケットが到着するなら、ドメインのRP(s)とそのPMBRsの間の最短パス支店に沿ったルータは、状態を維持して(*、*、RP)、PMBRsに向かってパケットを渡す方法を決定するのにそれを使用します。 (*、*、RP)ルートエントリーにおけるワイルドカードグループは4ビットの224.0の.0の.0とaマスクの長さのグループアドレスによって代表されます。
References
参照
1. Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei,
P.Sharma, and A.Helmy. Protocol independent multicast (pim) :
Motivation and architecture. Work in Progress.
1. デアリング、S.、D.Estrin、D.ファリナッチ、V.ジェーコブソン、C.リュウ、L.ウェイ、P.シャルマ、およびA.Helmy。 独立しているマルチキャスト(pim)について議定書の中で述べてください: 動機と構造。 進行中で、働いてください。
2. Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei.
The pim architecture for wide-area multicast routing.
ACM Transactions on Networks, April 1996.
2. デアリング、S.、D.Estrin、D.ファリナッチ、V.ジェーコブソン、C.リュウ、およびL.ウェイ。 広い領域マルチキャストルーティングのためのpim構造。 1996年4月のネットワークにおけるACM取引。
3. Estrin, D., D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and
A.Helmy. Protocol independent multicast-dense mode (pim-dm) :
Protocol specification. Work in Progress.
3. Estrin、D.、D.ファリナッチ、V.ジェーコブソン、C.リュウ、L.ウェイ、P.シャルマ、およびA.Helmy。 独立しているマルチキャスト濃いモード(pim-dm)を議定書の中で述べてください: 仕様を議定書の中で述べてください。 進行中で、働いてください。
4. Deering, S. Host extensions for ip multicasting, Aug 1989. RFC1112.
4. デアリング、ipマルチキャスティング、1989年8月のためのS.Host拡張子。 RFC1112。
Estrin, et. al. Experimental [Page 64] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [64ページ]実験的なRFC2117PIM-Sm1997年6月
5. Fenner, W. Internet group management protocol, version 2.
Work in Progress.
5. フェナー、W.インターネットグループ管理プロトコル、バージョン2。 進行中で、働いてください。
6. Atkinson, R. Security architecture for the internet protocol,
August 1995. RFC-1825.
6. アトキンソン、インターネットプロトコル、1995年8月のためのR.Security構造。 RFC-1825。
7. Ballardie, A.J., P.F. Francis, and J.Crowcroft. Core based trees.
In Proceedings of the ACM SIGCOMM, San Francisco, 1993.
7. Ballardie、A.J.、P.F.フランシス、およびJ.クロウクロフト。 コアは木を基礎づけました。 ACM SIGCOMM、サンフランシスコ1993年の議事で。
Addresses of Authors:
作者のアドレス:
Deborah Estrin Computer Science Dept/ISI University of Southern Calif. Los Angeles, CA 90089 estrin@usc.edu
南部のカリフォルニアのデボラEstrinコンピュータサイエンス部/ISI大学 ロサンゼルス(カリフォルニア)90089 estrin@usc.edu
Dino Farinacci Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134 dino@cisco.com
恐竜ファリナッチシスコシステムズ株式会社170の西タスマンDrive、サンノゼ(カリフォルニア)95134 dino@cisco.com
Ahmed Helmy Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089 ahelmy@catarina.usc.edu
アフマドHelmyコンピュータサイエンス部 南部のカリフォルニア大学 ロサンゼルス(カリフォルニア)90089 ahelmy@catarina.usc.edu
David Thaler EECS Department University of Michigan Ann Arbor, MI 48109 thalerd@eecs.umich.edu
デヴィッド・ターレルEECS部のミシガン大学アナーバー、マイル48109 thalerd@eecs.umich.edu
Stephen Deering Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 deering@parc.xerox.com
スティーブンデアリングゼロックスPARC3333コヨーテヒル・Roadパロアルト(カリフォルニア)94304 deering@parc.xerox.com
Estrin, et. al. Experimental [Page 65] RFC 2117 PIM-SM June 1997
et Estrin、アル。 [65ページ]実験的なRFC2117PIM-Sm1997年6月
Mark Handley Department of Computer Science University College London Gower Street London, WC1E 6BT UK m.handley@cs.ucl.ac.uk
マーク・ハンドレー・コンピュータサイエンス学部ユニバーシティ・カレッジロンドンガウアー・ストリートロンドン、WC1E 6BTイギリスの m.handley@cs.ucl.ac.uk
Van Jacobson Lawrence Berkeley Laboratory 1 Cyclotron Road Berkeley, CA 94720 van@ee.lbl.gov
ヴァンジェーコブソンローレンスバークレイ研究所1サイクロトロンRoadバークレー(カリフォルニア)94720 van@ee.lbl.gov
Ching-gung Liu Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089 charley@catarina.usc.edu
チン-gungリュウコンピュータサイエンス部 南部のカリフォルニア大学 ロサンゼルス(カリフォルニア)90089 charley@catarina.usc.edu
Puneet Sharma Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089 puneet@catarina.usc.edu
Puneetシャルマコンピュータサイエンス部 南部のカリフォルニア大学 ロサンゼルス(カリフォルニア)90089 puneet@catarina.usc.edu
Liming Wei Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134 lwei@cisco.com
ウェイシスコシステムズ株式会社170の西タスマンDrive、サンノゼ(カリフォルニア)95134 lwei@cisco.com に石灰をまきます。
Estrin, et. al. Experimental [Page 66]
et Estrin、アル。 実験的[66ページ]
一覧
スポンサーリンク
