RFC2362 日本語訳
2362 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 1998. (Format: TXT=159833 bytes) (Obsoletes RFC2117) (Obsoleted by RFC4601, RFC5059) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Estrin
Request for Comments: 2362 USC
Obsoletes: 2117 D. Farinacci
Category: Experimental 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 1998
Estrinがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2362USCは以下を時代遅れにします。 2117年のD.ファリナッチカテゴリ: 実験的なコクチマスのシャルマUSC L.ウェイコクチマスA.Helmy USC D.ターレルUMICH S.デアリングゼロックスM.ハンドレーUCL V.ジェーコブソンLBL C.リュウUSC P.1998年6月
Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification
独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください: プロトコル仕様
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Estrin, et. al. Experimental [Page 1] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [1ページ]実験的なRFC2362PIM-Sm1998年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 2362 PIM-SM June 1998
et Estrin、アル。 [2ページ]実験的なRFC2362PIM-Sm1998年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)エントリーとしてここと呼ばれたグループのためにワイルドカードマルチキャストルートエントリーを作成します。 特定のソースへのそれ以上の特定のマッチがないと、このエントリーに応じて、パケットを進めるでしょう。
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に送るのに使用されるインタフェースに設定されます。
Estrin, et. al. Experimental [Page 3] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [3ページ]実験的なRFC2362PIM-Sm1998年6月
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: グループに発信するホスト
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
ソースのデータ信号速度がソース特有の最短パス木(SPT)の使用を保証するなら、RPはソースに、特定の新しいマルチキャストルートエントリーを組み立てて、今後(S、G)と状態を呼んで、周期的なJoin/プルーンのメッセージをソースに向かって送るかもしれません。 注意時間がたつにつれていつ切り替わるか間の規則を変更できる
Estrin, et. al. Experimental [Page 4] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [4ページ]実験的なRFC2362PIM-Sm1998年6月
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.
グローバルなコーディネート。 いつ切り替わるか、そして、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)}
共有された木(RP-木)から最短パス木(SP-木)に切り替わる2.4
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) 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)
(S、G)エントリーが活性であるときに(そして、状態と同じくらい長い間、定期的に存在しています)、上流へJoin/プルーンのメッセージをソースに向かって送ります、S、中にSがある状態でリストを接合してください。 ペイロードはG、Join=S、Multicastアドレス=Prune=NULLを含んでいます。 (S、G)エントリーが作成されるとき、送信するインタフェースリストは(*、G)からコピーされます、すなわち、すべての地方の共有された木の枝が新しい最短パス木で模写されます。 Sからのデータ・パケットがこのエントリーのときに到着して、合っているとき、すべての受信機が、このように、この経路に沿ってソースのパケットを受け続けるでしょう。 (より複雑なシナリオでは、ルータにおける他のエントリーはセクション3で説明されるように考えられなければなりません。) それぞれのSP-木を開始して、維持するのに原因となる最後のホップルータで(S、G)状態を維持しなければならないことに注意してください。 (*、G)と(S、G)が重なるときさえ、両方の州がソース特有のJoin/プルーンのメッセージの引き金となるのが必要です。 (S、G) 状態はそのソースから到着するデータ・パケットによって生かされます。 タイマ(Entry-タイマ)は設定されます。(S、G)
Estrin, et. al. Experimental [Page 5] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [5ページ]実験的なRFC2362PIM-Sm1998年6月
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.
エントリーとこのタイマによる(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 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)エントリーがあるルータとクリアされた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に作成します。 簡潔さについて、私たちは(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-アドレス=ビットを含んでいます。
Estrin, et. al. Experimental [Page 6] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [6ページ]実験的なRFC2362PIM-Sm1998年6月
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情報を分配してください。
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)
ルータは適切なGroupをRPマッピングに手に入れるBootstrapメッセージで分配された利用可能なRPs(RP-セットと呼ばれる)の1セットを使用します。 以下のパラグラフはメカニズムをまとめます。 メカニズムの細部はセクション3.6とAppendix6.2で見つけられるかもしれません。 A(小さい)
Estrin, et. al. Experimental [Page 7] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [7ページ]実験的なRFC2362PIM-Sm1998年6月
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.
セットされて、ルータは候補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メッセージを出し続けるでしょう。 そのままで、パーティション時点で、予想されているか、または治療であり、パケット配信における何らかの分裂が起こるかもしれません。 そして、領域の往復の時間の注文には今回がある、ルータタイムアウト価値を独力で進んでください。
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
濃いモード、放送、およびプルーンを走らせるネットワークと共に共同利用するために、すべてのパケットがDVMRPなどのようにPIM-SM領域の中で発生させたプロトコルをその領域のPIM Multicast Border Routers(PMBRs)に引き抜かれて、DVMRPネットワークに注入しなければなりません(すなわち、放送します)。 PMBRはPIM-SMドメインの境界に座って、他のタイプのDVMRPを走らせるものなどのマルチキャストルータで共同利用するルータです。 一般にPMBRは両方のプロトコルを話して、通常のPIMによって必要とされなかった相互運用性機能を実行するでしょう。
Estrin, et. al. Experimental [Page 8] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [8ページ]実験的なRFC2362PIM-Sm1998年6月
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.
ルータ。 相互運用性を支持するために、すべての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 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つが存在しているなら、(S、G)エントリーは最初に、合われています。 (*、G)エントリーは別の方法で合われています。 どちらの状態も存在していないなら、(*、*、RP)エントリーマッチは以下の通り試みられます: ルータは、それに関連しているこのRPアドレスを持っている(*、*、RP)エントリーを、グループGのためにRPを特定するGで論じ尽くして、見ます。 上記のいずれも存在していないなら、パケットは落とされます。 状態が取り組むなら、ルータは取り組んでいるルートエントリーでパケットが入って来るインタフェース分野に到着したインタフェースを比較します。 iifチェックが失敗するなら、パケットを落とします。さもなければ、送信するインタフェースリストに記載されたすべてのインタフェースにパケットを送ります。
Estrin, et. al. Experimental [Page 9] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [9ページ]実験的なRFC2362PIM-Sm1998年6月
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 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.
データ・パケットはプルーンの決して引き金となりません。 しかしながら、データ・パケットは順番にプルーンの引き金となる動作の引き金となるかもしれません。 例えば、3図のルータBが、ステップ3でSP-木に切り替わると決めると、それはSPT-ビットセットによる(S、G)エントリーを0に作成します。 Sからのデータ・パケットがBのインタフェース2に到着するとき、(*、G)が(S、G)のためのそれと異なっているので、BはSPT-ビットをiif以来の1に設定します。 これはRPに向かってプルーンの発信の引き金となります。
Estrin, et. al. Experimental [Page 10] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [10ページ]実験的なRFC2362PIM-Sm1998年6月
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 network layer 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に送ります。 最も大きいネットワーク層アドレスをもっている送付者は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 packet. The router with the smallest numerical metric (with ties broken by highest address) will become the forwarder. All other
選出された上流のルータは最短距離がソースまであるものです。 したがって、パケットによる外向的なインタフェースに受け取って、マルチアクセスLANに関するAssertメッセージがルータでメートル法でなにかを示すかということであるときに、それはデータ・パケットの源を範囲に使用します。 最もわずかな数字のメートル法(結びつきが最も高いアドレスによって壊されている)の意志が混載業者になったルータ。 すべて他です。
Estrin, et. al. Experimental [Page 11] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [11ページ]実験的なRFC2362PIM-Sm1998年6月
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 network layer address), a timer (the Join/Prune-Suppression-timer) in the recipient's route entry may be started to suppress further Join/Prune messages. After this timer expires, the recipient triggers a Join/Prune message, and
抑圧が使用されるかもしれない/プルーンに合流してください。減少させるマルチアクセスLANはコントロールメッセージオーバーヘッドをコピーします。 それはプロトコルの正しい性能に必要ではありません。 Join/プルーンのメッセージが存在(S、G)、(*、G)のための入って来るインタフェースで到着して、合うか、(*、*、RP)がエントリーを発送して、またはJoin/プルーンのメッセージにHoldtimeを含んでいるのが受取人が自己であるより[/プルーン-Holdtimeを接合してください](結びつきが、より高いネットワーク層アドレスを支持して決議にされるので)大きいなら、受取人のルートエントリーにおけるタイマ(プルーンの抑圧Join/タイマ)は、一層のJoin/プルーンのメッセージを削除するために始動されるかもしれません。 そしてこのタイマが期限が切れた後に、受取人がJoin/プルーンのメッセージの引き金となる。
Estrin, et. al. Experimental [Page 12] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [12ページ]実験的なRFC2362PIM-Sm1998年6月
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/タイマは、より高い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 2362 PIM-SM June 1998
et Estrin、アル。 [13ページ]実験的なRFC2362PIM-Sm1998年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 network layer 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 addressed system is elected DR. Each Hello received causes the DR's address to be updated.
ルータがHelloメッセージを受け取るとき、それは、その隣人のためにネットワーク層アドレスを格納して、HelloにHoldtimeへのHello送付者のためのNeighbor-タイマを含んでいて、セットして、Designated Router(DR)をそのインタフェースに決定します。 最も高い記述されたシステムはDRに選ばれます。Helloが受けたそれぞれがDRのアドレスをアップデートさせます。
When a router that is the active DR receives a Hello from a new neighbor (i.e., from an 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隣人テーブルにないアドレスからの)から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 network layer address. If an interface has gone down, the router may optionally time out all PIM neighbors associated with the interface.
周期的な過程はハローズを送らないタイムアウトPIM隣人へ走ります。 DRが落ちたなら、インタフェースのすべての隣人をスキャンして、新しいDRがものであるのに選ぶことによって、新しいDRは最も高いネットワーク層アドレスで選ばれています。 インタフェースが落ちたなら、ルータは任意に落ちました。すべての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セットのソースアドレスを含んでいます、ルータが接合したいか、または剪定したがっているソース特有の木か共有された木を示して。
Estrin, et. al. Experimental [Page 14] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [14ページ]実験的なRFC2362PIM-Sm1998年6月
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 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)はNを通して連絡されている現在の接合されて剪定されたソースのすべてを含んでいます。 ユニキャストルーティングによると、Join/プルーンのメッセージはあて先アドレスがあるネットワークが次のホップルータに設定するマルチアクセスでのすべてのルータへのSかRPに向かったマルチキャストです。 メッセージが送られる/プルーンに合流してください、あらゆる、[期間を接合するか、または剪定します]秒。 将来、私たちはホップの上でホップ基礎で限界がこのコントロール交通であると評定するためにメカニズムを紹介するつもりです、小さいリンクの上に過度のオーバーヘッドを避けるために。 さらに、あるイベント原因は送られるべきJoin/プルーンのメッセージの引き金となりました。
Periodic Join/Prune Messages:
周期的である、メッセージを接合するか、または剪定してください:
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リストはヌルではありません。
Estrin, et. al. Experimental [Page 15] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [15ページ]実験的なRFC2362PIM-Sm1998年6月
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隣人に送る。
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を見てください)。
Triggered Join/Prune Messages:
引き起こされて、メッセージを接合するか、または剪定してください:
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
直接接続された会員資格の州が変えたIGMPからの指示の1つの領収書、(すなわち、新しいメンバーはちょうど'会員資格指示'かメンバーが持っているすべてに加わったところです。
Estrin, et. al. Experimental [Page 16] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [16ページ]実験的なRFC2362PIM-Sm1998年6月
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:
左) グループGのために、最後のホップルータが対応する(*、G)状態を造るか、または変更することを引き起こすかもしれません。 IGMPが、直接接続されたメンバーがもういないのを示すとき、oif-タイマが動いていないなら、oifはoifリストから取り外されます。 そして、Join/プルーンのメッセージが引き起こされる、a)である場合にだけ、新しいエントリーが作成されるか、またはb) oifリストは非ヌルからヌルから非ヌルかヌルに変化します、以下の通りです:
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に加えられて、メッセージが上流へ引き起こされるということです。
Estrin, et. al. Experimental [Page 17] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [17ページ]実験的なRFC2362PIM-Sm1998年6月
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 in the prune
list and the RPT-bit set.
3 パケットが正しい入って来るインタフェースで到着したなら、SPT-ビットがきれいにされる(S、G)エントリーのときに合っているパケットの領収書は以下の引き金となります、そして、異なった入来によるエントリーが連結する(*、G)か(*、*、RP)があります: a) ルータは(S、G)エントリーにSPT-ビットを設定して、Sがプルーンのリストにあって、RPT-ビットが設定されている状態で、b) ルータはJoin/プルーンのメッセージをRPに向かって送ります。
4 Receipt of a packet at the DR from a directly connected
source S, on the subnet containing the address S, triggers a
Join/Prune message towards the RP with S in the prune list and
the RPT-bit set under the following conditions: a) there is no
matching (S,G) state, and b) there exists a (*,G) or (*,*,RP)
for which the DR is not the RP.
4 Sがプルーンのリストにあって、RPT-ビットが以下の条件のもとで設定されている状態で、直接接続されたソースSからのアドレスSを含むサブネットのDRのパケットの領収書はJoin/プルーンのメッセージのRPに向かって引き金となります: a) 合っている(S、G)状態が全くなくて、(*、G)か(*、*、RP)がDRがRPでないb)を存在させています。
5 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.)
5 グループGのためにJoin/プルーンのメッセージを受け取るとき、プルーンのリストをチェックします。 プルーンのリストが受信ルータには対応する能動態(S、G)、(*、G)があるソースかRPを入れてあるか、または(*、*、RP)エントリーとだれのiifがJoin/プルーンが受け取られたその、次に、aであるかが(S、G)のために接合するなら、(*、G)か(*、*、RP)が、それぞれプルーンをくつがえすために引き起こされます。 (これがマルチアクセスネットワークに関連づけられた平行な川下のルータの場合で必要です。)
6 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 the
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.
6 RPが失敗する場合、RPはそのドメインのすべてのルータに送られたBootstrapメッセージに含まれないでしょう。 これは発信するDRs(*、G)の引き金となります。グループのために新しいRPに向かってメッセージを接合するか、または剪定してください、RP-セットとハッシュ関数で決定するように。 より早く説明されるように、PMBRs引き金(*、*、RP)はRP-セットにおける各RPに向かって接合します。
7 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.
7 エントリーのプルーンJoin/抑圧タイマが期限が切れるとき、Join/プルーンのメッセージはそのエントリーに対応しながら、上流へ引き起こされます、外向的なインタフェースがヌルの、そして、非ヌルの州の間で移行していなくても。
8 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.)
8 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.
私たちはデータ・パケットに基づくインタフェースにプルーンの引き金となりません。 間違った入って来るインタフェースで到着するデータ・パケットは静かに落とされます。 しかしながら、二地点間インタフェースに、最適化として引き起こされたプルーンを送るかもしれません。
Estrin, et. al. Experimental [Page 18] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [18ページ]実験的なRFC2362PIM-Sm1998年6月
aragraphFragmentation 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.
aragraphFragmentation Itは前の規則に従って構成されたJoin/プルーンのメッセージがネットワークのMTUを超えるかもしれないのが可能です。 この場合、メッセージは異なったメッセージで異なったグループに対応する情報を送ることができる意味断片化を受けることができます。 しかしながら、そのような意味断片化がJoin/プルーンのメッセージが断片化されて、G.Ifのための関連RP-木のJoinと同じJoin/プルーンのメッセージにグループGに対応する完全なプルーンのリストを含まなければならないということであるに違いないなら可能でない、IP断片化は2つの隣接しているホップの間で使用されるべきです。
3.2.2 Receiving Join/Prune Messages When a router receives
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
2 SjがGのための受信ルータのRPマッピングと同じであるなら、受信ルータは、私が(*、G)ルートエントリーのリストを外向的に連結する((*、G)エントリーが全くなければ、ルータは1/1を作成する)と言い足して、Join/プルーンのメッセージで指定されたHoldtimeへのそのインタフェースにOif-タイマを設定します。 さらに、そのインタフェースがHoldtimeの1/3番目に設定されるので、Oif削除遅れは指定しました。
Estrin, et. al. Experimental [Page 19] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [19ページ]実験的なRFC2362PIM-Sm1998年6月
in the Join/Prune message. 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.
Join/プルーンのメッセージで。 (*、*、RP)エントリーがGに関連しているRPのために存在しているなら、新たに作成された(*、G)エントリーのoifリストはその(*、*、RP)エントリーからコピーされます。
3 For each (Si,G) entry associated with group G: i) if
Si is not included in the prune list, ii) if I is not on
the same subnet as the address Si, and iii) 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 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 それぞれ(Si、G)に関しては、エントリーはグループGと交際しました: i) 私はSiがプルーンのリスト、ii)に私が私であるならアドレスSi、およびiii)がiifでないから同じサブネットのであるかどうか含んで、次に、連結しないことであるならoifリストに追加されて、それぞれの影響を受けるエントリーにおけるそのインタフェースへのOif-タイマはJoin/プルーンのメッセージにHoldtimeを含んでいるのに増加されています(決して減少していない)。 さらに、そのインタフェースへの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 2362 PIM-SM June 1998
et Estrin、アル。 [20ページ]実験的なRFC2362PIM-Sm1998年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 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 maintained
(not deleted) even if its outgoing interface list is null.
2 ルータには電流(*、G)があるか、または(*、*、RP)がエントリーを発送して、既存(Sp、G)のエントリーでRPT-ビット旗を1に設定するなら、送信するインタフェースリストがヌルであっても、この(Sp、G)RPT-ビットエントリーは維持されます(削除されません)。
2 For each address, Sp, in the prune list whose RPT-bit is
set and whose WC-bit cleared:
2 各アドレス、プルーンのリストのRPT-ビットがセットとトイレビットがだれのものをクリアしたということであるSpのために:
Estrin, et. al. Experimental [Page 21] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [21ページ]実験的なRFC2362PIM-Sm1998年6月
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)がエントリーを発送して、既存(Sp、G)のエントリーでRPT-ビット旗を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.
(*、G)、または対応(*、*、RP)、状態が存在していますが、(Sp、G)エントリーが全くなければ、(Sp、G)RPT-ビットエントリーは作成されます。(そこでは、プルーンが受け取られました)。3、送信するインタフェースリストからコピーされる、(*、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/抑圧タイマが使用されているなら、それはやめられます。)
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
エントリーでプルーンJoin/抑圧があって、容認されたJoin/プルーンが目標としてルータを示さないなら、タイマはそれと交際しました、受信ルータが調べるその時、何かリストのアドレスが存在(S、G)、(*、G)に'完全に合わせているかどうか'を見るリストか受信ルータが現在Join/プルーンのメッセージの計画をする(*、*、RP)状態に加わって、剪定してください。 または要素、オンである、接合。
Estrin, et. al. Experimental [Page 22] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [22ページ]実験的なRFC2362PIM-Sm1998年6月
prune list `completely-matches' a route entry only if both the 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 network layer address. When the Join/Prune timer expires, the router triggers a Join/Prune message for the corresponding entry(ies).
アドレスとRPT-ビットが旗を揚げさせる両方が同じである場合にだけ、プルーンのリストはルートエントリーに'完全に合わせています'。 入って来るJoin/プルーンのメッセージが存在(S、G)、(*、G)に完全に合っているか、そして、(*、*、RP)エントリーとJoin/プルーンがiifでそのエントリーに到着しました、次に、Join/プルーンのメッセージにHoldtimeを含んでいて、ルータは比較されます、それ自身のものに[/プルーン-Holdtimeを接合してください]。 それ自身[/プルーン-Holdtimeを接合する]が低いなら、プルーンの抑圧Join/タイマで始められる、[/プルーン抑圧タイムアウトを接合します。] 同輩、繋がりが、より高いネットワーク層アドレスを持っている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, on the subnet containing the address S,
1 DRがアドレスSを含むサブネットで直接接続されたソース、Sからパケットを受けるとき
1 If there is no corresponding (S,G) entry, and the
router has RP-Set information, and the DR is not the RP for
G, the DR creates an (S,G) entry 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. If there
exists a (*,G) or (*,*,RP) entry, the DR sends a Join/Prune
message towards the RP with S in the prune list and the
RPT-bit set.
1 どんな対応する(S、G)エントリーもなくて、またルータにはRP-情報集合があって、DRがGのためのRPでないなら、Register抑圧タイマがオフにされて、対応するグループのためのハッシュ関数マッピングによると、RPアドレスが設定されている状態で、DRは(S、G)エントリーを作成します。 存在しているなら、oifリストは存在(*、G)か(*、*、RP)エントリーからコピーされます。 (S、G)エントリーのiifはoifリストからいつも除かれます。 存在しているなら、Sがプルーンのリストにあって、RPT-ビットが設定されている状態で、(*、G)かエントリー、(*、*、RP)DRがJoin/プルーンのメッセージをRPに向かって送ります。
2 If there is a (S,G) entry in existence, the DR simply
restarts the corresponding Entry-timer.
2 現存する(S、G)エントリーがあれば、DRは単に対応するEntry-タイマを再開します。
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
PMBRであるときに、(例えば、DVMRPかPIM-DMを走らせる濃いモード領域にPIM-SM領域をつなげるルータ)は濃いモード領域のソースからパケットを受けます、ルータ
Estrin, et. al. Experimental [Page 23] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [23ページ]実験的なRFC2362PIM-Sm1998年6月
treats the packet as if it were from a directly connected
source. A separate document will describe the details of
interoperability.
まるで直接接続されたソースから来ているかのようにパケットを扱います。 別々のドキュメントは相互運用性の詳細について説明するでしょう。
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 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はヌルRegister(ゼロ・レングスデータ部が内側のパケットにあるRegisterメッセージ)をRPに送るかもしれません、Register抑圧タイマが不必要に交通の時々の炸裂をRPに送るのを避けるために期限が切れる[徹底的調査時間]秒前に。
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-停止メッセージの引き金となるのを防ぎます。
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)エントリーに応じて、パケットを進めます。
Estrin, et. al. Experimental [Page 24] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [24ページ]実験的なRFC2362PIM-Sm1998年6月
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 network layer
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(すなわち、レジスタパケットの外側のネットワーク層アドレス)の源を保持します。 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の源に向かって引き起こされます。
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
マッチング(S、G)か(*、G)状態がヌルoifを含んでいるなら、2は記載して、RPユニキャストはRegisterメッセージの源へのRegister-停止メッセージです。 後者の場合では、ソースアドレス分野はRegister-停止メッセージの中にワイルドカードに設定されます。
Estrin, et. al. Experimental [Page 25] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [25ページ]実験的なRFC2362PIM-Sm1998年6月
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.
(すべての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)エントリーが存在していませんが、iifを除いて、(S、G)がその(*、*、RP)エントリーからコピーされるのでRPがG、oifリストに対応であっている中の(*、*、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リストがヌルならでない:
1 Forward the packet to the oif list for that entry,
excluding the subnet containing S, 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を含むサブネットを除いて、そのエントリーに記載して、合っているエントリーが(S、G)であるならEntryタイマを再開します。 任意に、(S、G)エントリータイマは合っているパケットカウントの周期的な照合で再開されるかもしれません。
Estrin, et. al. Experimental [Page 26] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [26ページ]実験的なRFC2362PIM-Sm1998年6月
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(S、G)であるなら、aがSPT-ビット、およびa(*、G)をきれいにするか、または交際したことでの入って来るインタフェースが(S、G)のためのそれと異なっているエントリー(*、*、RP)は存在していて、セットはRPに向かった(S、G)RPTが噛み付いた(S、G)のエントリーと引き金のためにSPTによって噛み付かれたプルーンです。
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でないなら、パケットを落としてください。
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ベースの共有された木からソース特有の最短パス木までの切り換えの引き金となるように異なった評価基準を適用できます。
Estrin, et. al. Experimental [Page 27] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [27ページ]実験的なRFC2362PIM-Sm1998年6月
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 active (S,G), (*,G) or (*,*,RP) entry:
いつ既存の能動態(S、G)、(*、G)の外向的なマルチアクセスインタフェース「I」にマルチキャストパケットを受け取るか、そして、(*、*、RP)エントリーを以下のAssert規則に提供します:
1 Do unicast routing table lookup on source address from data
packet, and send assert on interface "I" for source address in
data packet; include metric preference of routing protocol and
metric from routing table lookup.
1 ソースの上で索表を発送するのがデータ・パケットから記述して、送るユニキャストはデータ・パケットのソースアドレスのためにインタフェースで「私」について断言します。 索表を発送するのによるプロトコルの、そして、メートル法のルーティングのメートル法の好みを含めてください。
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 2362 PIM-SM June 1998
et Estrin、アル。 [28ページ]実験的なRFC2362PIM-Sm1998年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, only active entries -- that have packet forwarding state -- are matched. 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)エントリーです。
Receiving Asserts on an entry's outgoing interface:
エントリーの外向的なインタフェースの受信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 network layer 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アドレスによって壊されている状態で、より高いネットワーク層アドレスが得られるところで)であるなら、エントリーからインタフェースを削除してください。 また、削除が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 2362 PIM-SM June 1998
et Estrin、アル。 [29ページ]実験的なRFC2362PIM-Sm1998年6月
Receiving Asserts on an entry's incoming interface
エントリーの入って来るインタフェースで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 network layer 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つの測定基準が同じであるなら、最も高いネットワーク層アドレスは、繋がりを壊すために選ばれています。 これが重要であるので、川下のルータはその後の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 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-優先度とアドレス(都合のよい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 2362 PIM-SM June 1998
et Estrin、アル。 [30ページ]実験的なRFC2362PIM-Sm1998年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 `Priority' field set to `0'.
候補RP広告はグループアドレスとグループマスク野原を載せます。 これは、広告ルータが広告をグループのある接頭語か範囲に制限するのを可能にします。 RegistersかJoin/プルーンのメッセージを受け取るとき、広告ルータはこの範囲承認を実施するかもしれません。 C-RPsは'優先権'分野セットがあるC-RP-Advメッセージを'0'に送るはずです。
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
`Priority' field is not zero.
2 BSRは候補RPsの地方のプールにRPアドレスを加えます、C-RP- Advメッセージの関連グループ接頭語(es)によると。 また、C-RP-AdvメッセージのHoldtimeは、後でBootstrapメッセージに含まれるように対応するRPと共に格納されます。 BootstrapメッセージにCandidate RPsの数を含んでいる場合、BSRは制限するローカルの方針を適用するかもしれません。 BSRは'優先権'分野がゼロであるなら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 a Bootstrap message on each of its PIM interfaces. To reduce the bootstrap message overhead during partition healing, the BSR should set a random time (as a function of the priority and address) after which the Bootstrap message is originated only if no other preferred Bootstrap message is received. For details see appendix 6.2. 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
また、BSRは、定期的にメッセージをBootstrapに送るのにBootstrap-タイマを使用します。 Bootstrap-タイマが期限が切れると、特に、BSRはそれぞれのPIMインタフェースに関するBootstrapメッセージを溯源します。 減少する、パーティション回復の間、メッセージオーバーヘッドを独力で進んでください、そして、BSRは他のどんな都合のよいBootstrapメッセージも受信されていない場合にだけBootstrapメッセージが溯源されるa無作為の時(優先権とアドレスの機能としての)を決めるはずです。 詳細に関しては、付録6.2を見てください。 1のTTLと共にメッセージを送る、'、すべて、-、PIM- ROUTERS、'分類してください。 定常状態では、BSRはBootstrapメッセージを定期的に溯源します。 始動では、溯源されるべき最初のBootstrapメッセージにいつだけを引き起こして、[タイムアウトを独力で進みます]に初期化されて、タイマが期限が切れるなら、Bootstrap-タイマはそうです。 for
Estrin, et. al. Experimental [Page 31] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [31ページ]実験的なRFC2362PIM-Sm1998年6月
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).
タイマの詳細である、.3にセクション3.6を見てください。 それぞれの新しいPIM隣人へのDRユニキャストa Bootstrapメッセージ、すなわち、後に、DRは隣人のHelloメッセージを受け取ります(新しい隣人がDRになっても、それはそうします)。
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 2362 PIM-SM June 1998
et Estrin、アル。 [32ページ]実験的なRFC2362PIM-Sm1998年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 RP addresses in the RP-Set, whose Group-prefix covers
G, select the RPs with the highest priority (i.e. lowest
`Priority' value), and compute a value:
1 Group-接頭語がGを覆うRP-セットにおけるRPアドレスには、最優先(すなわち、最も低い'優先権'値)があるRPsを選択してください、そして、値を計算してください:
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 C_i is the RP address and M is a hash-mask included in
Bootstrap messages. The 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.
C_iがどこのRPアドレスとMであるかはBootstrapメッセージに含まれていた細切れ肉料理マスクです。 細切れ肉料理マスクはいつも同じRPに論じ尽くす連続したグループ(例えば、4)の少ない数を許容します。 例えば、同じ遅れと運命を共有する特性を得るために連続したグループアドレスで階層的でコード化されたデータを送ることができます。
For address families other than IPv4, a 32-bit digest to be used
as C_i must first be derived from the actual RP address. Such a
digest method must be used consistently throughout the PIM
IPv4以外のアドレス家族にとって、最初に、実際のRPアドレスからC_iとして使用されるべき32ビットのダイジェストを得なければなりません。 PIM中で一貫してそのようなダイジェスト方法を使用しなければなりません。
Estrin, et. al. Experimental [Page 33] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [33ページ]実験的なRFC2362PIM-Sm1998年6月
domain. For IPv6 addresses, we recommend using the equivalent
IPv4 address for an IPv4-compatible address, and the CRC-32
checksum [7] of all other IPv6 addresses.
ドメイン。 IPv6アドレスのために、私たちは、IPv4コンパチブルアドレスのための同等なIPv4アドレス、および他のすべてのIPv6アドレスのCRC-32チェックサム[7]を使用することを勧めます。
2 From the RPs with the highest priority (i.e. lowest
`Priority' value), 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 そして、最優先(すなわち、最も低い'優先権'値)があるRPsから、それのためのRPが分類して、エントリーが作成されている状態でそのアイデンティティとハッシュ値が格納されるとき、最も高い結果として起こる値をもっている候補は選ばれています。
Ties between RPs having the same hash value and priority, are
broken in advantage of the highest address.
同じハッシュ値と優先権を持っている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
* [/プルーンタイマを接合します] このタイマは、定期的に集合Join/プルーンのメッセージを送りながら、使用されます。 そして、同時にそれをブートしながらルータの中で同期を避けるのが初めは1の間の無作為の値に設定される、[期間を接合するか、または剪定します。] すぐに期限が切れるとき、タイマは再開されます。
Estrin, et. al. Experimental [Page 34] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [34ページ]実験的なRFC2362PIM-Sm1998年6月
to [Join/Prune-Period]. A Join/Prune message is then sent out
each interface. This timer should not be restarted by other
events.
[/プルーン期間を接合します。] 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 in which the
included Holdtime is higher than the router's own
[Join/Prune-Holdtime] (with ties broken by higher network
layer 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.
* ルートエントリーの[/プルーン抑圧タイマ(ルートエントリー単位で保たれる)を接合します]もの(任意の)は/プルーン抑圧タイマを接合します。使用されて、写しを抑圧するのが同じLANに関する複数の川下のルータから接合するということであるかもしれません。 含まれているHoldtimeがルータが自己であるより[/プルーン-Holdtimeを接合してください](結びつきが、より高いネットワーク層アドレスによって壊されている状態で)高いエントリーの入って来るインタフェースに隣人からJoinメッセージを受け取るとき、[抑圧を参加しているか、または剪定しているタイムアウト]にタイマを設定します、満了の引き起こされた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を加えるとき、以下のテーブルは用法を示しています、それが再開されるべきであり(それが既により高くない場合)、減少するべきであるとき(それが既に低くない場合)。
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)
(*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G)
(*,G) oif-timer value | (*,G) oif-timer restarted | (S,G)
増加します(単に)。| いつ| 含まれているHoldtimeに適用します。| 容認されたJoin/プルーン| (S、G) (*、G) | | (*、*、RP) (*、*、RP) oif-タイマ値| (*、*、RP) oif-タイマは再開しました。| (S、G) (*、G) (*、G) oif-タイマ値| (*、G) oif-タイマは再開しました。| (S、G)
Estrin, et. al. Experimental [Page 35] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [35ページ]実験的なRFC2362PIM-Sm1998年6月
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を加えるとき、以下のテーブルは用法をまとめます。
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
oif-timer value | 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隣人をリセットします。
Estrin, et. al. Experimental [Page 36] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [36ページ]実験的なRFC2362PIM-Sm1998年6月
* [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 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.
* Random遅れが[無作為の遅れはタイマを接合します((S、G)か(*、G)に従って、エントリーを発送してください)]タイマを接合している、(彼らのRPF隣人が変化するとき、S、G)または(*、G)ルートエントリーが、LANで川下のルータの中で同期を防ぐのに使用されます。 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 37] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [37ページ]実験的なRFC2362PIM-Sm1998年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 a 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 should continue to
refresh at its previous Join/Prune-Period for at least
Join/Prune-Holdtime, in order to allow the upstream router to
* [/プルーン期間を接合します] これは送付Join/プルーンのメッセージの間隔です。 デフォルト: 60秒。 構成された帯域幅のようなものを考慮に入れて、付属ネットワークのために平均した数のマルチキャストルートエントリーを予想するか、またはこの値がリンクするように設定されるかもしれません(例えば期間が下側の速度リンク、またはルータのための、より長い間、より多くのエントリーを持っていると予想するネットワークのセンターにあるでしょう)。 さらに、ルートエントリーの数がかなり(例えば、1桁)変化するなら、ルータはこの値(そして、対応するプルーンJoin/Holdtime値)を変更するかもしれません。 例えば、最小のJoin/プルーンの期間が評価するデフォルトを考えて、特定のiifとのルートエントリーの数がNからN*100まで増加するなら、ルータはプルーンJoin/期間(そして、プルーンJoin/Holdtime)を増加させるかもしれません、そのインタフェースに、10の要素で。 そして、エントリーの数であるときに、/がNと減少して戻るなら、プルーンJoin/期間(そして、プルーンJoin/Holdtime)は前の値と減少するかもしれません。 プルーンJoin/期間が変更されているなら、これらの変更は比較的まれに行われるべきです、そして、ルータは前のプルーンJoin/期間に少なくともプルーンJoin/Holdtimeのためにリフレッシュし続けるべきです、上流のルータを許容するために
Estrin, et. al. Experimental [Page 38] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [38ページ]実験的なRFC2362PIM-Sm1998年6月
adapt.
適合してください。
* [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 network layer address) and
allowing duplicate Join/Prunes to be sent again. This should
be set to approximately 1.25 * [Join/Prune-Period]. Default:
75 seconds.
* [/プルーン抑圧タイムアウトを接合します] これは、より高いHoldtime(結びつきが、より高いネットワーク層アドレスによって壊されている)と共に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秒。
* [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秒。
Estrin, et. al. Experimental [Page 39] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [39ページ]実験的なRFC2362PIM-Sm1998年6月
* [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 *
[Bootstrap-Period] + 10'. Default: 130 seconds.
* [タイムアウトを独力で進んだ]これはBootstrapメッセージがそれから受け取られない選出されたBSRが手が届かないと思われる時です。 これは'2*に設定されるべきです。[期間を独力で進んだ] + 10'。 デフォルト: 130秒。
3.9 Summary of flags used
3.9 使用される旗の概要
Following is a summary of all the flags used in our scheme.
以下に、私たちの計画に使用されるすべての旗の概要があります。
Bit | Used in | Definition
ビット| 使用にされる| 定義
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
境界| レジスタ| 外部電源へのレジスタはPIMマルチキャスト境界ルータNullから来るでしょう。| レジスタ| レジスタはRPのProbeとして発信して、カプセル化されたIPデータ・パケットにRPTを送るべきではありません。| ルートエントリー| エントリーはRP-木のRPTに状態を表します。| /プルーンに合流してください。| 接合、共有された木としたがって、Join/プルーンのメッセージに関連づけられているのが、RP-木に沿って伝播された(コード化されたソースはRPアドレスである)RPTであるということです。| 断言します。| データ・パケットは共有された木の下側に発送されました。 その結果、RP木のSPTに対応しています経路が、示した。| (S、G) エントリー| パケットはiifでSに向かって到着しました、そして、iifは(*、G)iifトイレと異なっています。|接合してください。| 受信機は、この(共有された木)経路を通してすべてのソースからパケットを受けると予想します。 したがって、Join/プルーンは(*、G)エントリートイレに適用されます。| ルートエントリー| ワイルドカードエントリー。 特定のソースへのそれ以上の特定のマッチがないと、このエントリーに応じて、パケットを進めるでしょう。
Estrin, et. al. Experimental [Page 40] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [40ページ]実験的なRFC2362PIM-Sm1998年6月
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があります。
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 | Reserved | 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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=広告を独力で進みます。
Reserved
set to zero. Ignored upon receipt.
セットをゼロまで予約しました。 領収書では、無視されます。
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の補数です。 チェックサムを計算するのにおいて、チェックサム分野のゼロは合わせられています。
Estrin, et. al. Experimental [Page 41] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [41ページ]実験的なRFC2362PIM-Sm1998年6月
4.1 Encoded Source and Group Address formats
4.1 コード化されたSourceとGroup Address形式
1 Encoded-Unicast-address: Takes the following format:
1 コード化されたユニキャストアドレス: 以下の形式を取ります:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addrファミリー| タイプをコード化します。| ユニキャストアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++
Addr Family
The address family of the `Unicast Address' field of
this address.
この'ユニキャストAddress'分野のアドレスファミリーが扱うAddr Family。
Here is the address family numbers assigned by IANA:
ここに、IANAによって割り当てられたアドレスファミリーナンバがあります:
Number Description
-------- ---------------------------------------------------------
0 Reserved
1 IP (IP version 4)
2 IP6 (IP version 6)
3 NSAP
4 HDLC (8-bit multidrop)
5 BBN 1822
6 802 (includes all 802 media plus Ethernet "canonical format")
7 E.163
8 E.164 (SMDS, Frame Relay, ATM)
9 F.69 (Telex)
10 X.121 (X.25, Frame Relay)
11 IPX
12 Appletalk
13 Decnet IV
14 Banyan Vines
15 E.164 with NSAP format subaddress
数の記述-------- --------------------------------------------------------- 0 NSAP形式「副-アドレス」がある1予約されたIP(IPバージョン4)2IP6(IPバージョン6)3NSAP4HDLC(8ビットのマルチドロップ)5BBN1822 6 802(すべての802のメディアとイーサネット「正準な形式」を含んでいる)7E.163 8E.164(SMDS、Frame Relay、ATM)9F.69(テレックス)10X.121(X.25、Frame Relay)11IPX12Appletalk13Decnet IV14Banyanバインズ15E.164
Encoding Type
The type of encoding used within a specific Address
Family. The value `0' is reserved for this field,
and represents the native encoding of the Address
Family.
特定のAddress Familyの中で使用されたコード化のタイプのTypeをコード化します。 値'0'は、この分野に予約されて、Address Familyのネイティブのコード化を表します。
Unicast Address
The unicast address as represented by the given
Address Family and Encoding Type.
与えられたAddress FamilyとEncoding Typeによって表されるようにユニキャストが扱うユニキャストAddress。
Estrin, et. al. Experimental [Page 42] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [42ページ]実験的なRFC2362PIM-Sm1998年6月
2 Encoded-Group-Address: Takes the following format:
2 コード化されたグループアドレス: 以下の形式を取ります:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addrファミリー| タイプをコード化します。| 予約されます。| レンにマスクをかけてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループマルチキャストAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr Family
described above.
上で説明されたAddr Family。
Encoding Type
described above.
上で説明されたTypeをコード化します。
Reserved
Transmitted as zero. Ignored upon receipt.
ゼロとしての予約されたTransmitted。 領収書では、無視されます。
Mask Len
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 the
address length in bits for the given Address Family
and Encoding Type. If the message is sent for a single
group then the Mask length must equal the address
length in bits for the given Address Family and
Encoding Type. (e.g. 32 for IPv4 native encoding and
128 for IPv6 native encoding).
レンにマスクをかけてください。Maskの長さは8ビットです。 値はアドレスについて説明するマスクとして使用されていた状態で正当化されるように残っている隣接のビットの数です。 それは与えられたAddress FamilyとEncoding Typeのためのビットのアドレスの、より長さ以下です。 ただ一つのグループのためにメッセージを送るなら、Maskの長さは与えられたAddress FamilyとEncoding Typeのためにビットのアドレスの長さと等しくなければなりません。 (例えば、IPv4のネイティブのコード化のための32とIPv6のネイティブのコード化のための128。)
Group multicast Address
contains the group address.
グループマルチキャストAddressはグループアドレスを含んでいます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addrファミリー| タイプをコード化します。| Rsrvd|S|W|R| レンにマスクをかけてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr Family
described above.
上で説明されたAddr Family。
Encoding Type
described above.
上で説明されたTypeをコード化します。
Estrin, et. al. Experimental [Page 43] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [43ページ]実験的なRFC2362PIM-Sm1998年6月
Reserved
Transmitted as zero, ignored on receipt.
領収書の上で無視されたゼロとしての予約されたTransmitted。
S,W,R See Section 4.5 for details.
S、W、詳細のためのR Seeセクション4.5。
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 the address length in bits for the
given Address Family and Encoding Type. If the message
is sent for a single group then the Mask length must
equal the address length in bits for the given Address
Family and Encoding Type. In version 2 of PIM, it is
strongly recommended that this field be set to 32 for
IPv4 native encoding.
マスクLength Maskの長さは8ビットです。 値はアドレスについて説明するマスクとして使用されていた状態で正当化されるように残っている隣接のビットの数です。 マスクの長さは与えられたAddress FamilyとEncoding Typeのためのビットのアドレスの、より長さ以下であるに違いありません。 ただ一つのグループのためにメッセージを送るなら、Maskの長さは与えられたAddress FamilyとEncoding Typeのためにビットのアドレスの長さと等しくなければなりません。 PIMのバージョン2では、この分野がIPv4のネイティブのコード化のために32に設定されることが強く勧められます。
Source Address
The source address.
ソースのAddressが演説するソース。
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 | Reserved | 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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType| OptionLength| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType| OptionLength| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
PIM Version, Type, Reserved, Checksum
Described above.
PIMバージョン、Type、Reserved、上のChecksum Described。
Estrin, et. al. Experimental [Page 44] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [44ページ]実験的なRFC2362PIM-Sm1998年6月
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。
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
一般に、オプションは無視されるかもしれません。 必須が無視しないルータ
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 address is set to the address of the DR, destination address is to the RP's address.
マルチキャストパケットが、RP-木の上で伝えられる必要があるとき、RegisterメッセージはDRかPMBRによってRPに送られます。 ソースアドレスはDRのアドレスに設定されて、RPのアドレスには送付先アドレスがあります。
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 | Reserved | 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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|N| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | マルチキャストデータ・パケット| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 45] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [45ページ]実験的なRFC2362PIM-Sm1998年6月
PIM Version, Type, Reserved, Checksum
Described above. Note that the checksum for Registers
is done only on the PIM header, excluding the data packet
portion.
PIMバージョン、Type、Reserved、上のChecksum Described。 データ・パケット部分を除いて、PIMヘッダーだけでRegistersのためのチェックサムをすることに注意してください。
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 header with S as the source address, G as
the destination address, and a data length of zero.
(S、G)ヌルRegistersに関しては、Multicastデータ・パケット部分はSと共にソースアドレス、送付先アドレスとしてのG、およびゼロのデータの長さとしてダミーのヘッダーだけを含んでいます。
4.4 Register-Stop Message
4.4 レジスタ停止メッセージ
A Register-Stop is unicast from the RP to the sender of the Register message. Source address is the address to which the register was addressed. Destination address is the source address of the register message.
RPからRegisterメッセージの送付者までRegister-停止はユニキャストです。 ソースアドレスはレジスタが扱われたアドレスです。 送付先アドレスはレジスタメッセージのソースアドレスです。
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described above.
PIMバージョン、Type、Reserved、上のChecksum Described。
Encoded-Group Address
Format described above. Note that for Register-Stops the
Mask Len field contains full address length * 8 (e.g. 32
for IPv4 native encoding), if the message is sent for a
single group.
上で説明されたコード化されたグループAddress Format。 Register-停止に、Maskレン分野が完全なアドレス長さ*8(例えば、IPv4のネイティブのコード化のための32)を含むことに注意してください、ただ一つのグループのためにメッセージを送るなら。
Estrin, et. al. Experimental [Page 46] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [46ページ]実験的なRFC2362PIM-Sm1998年6月
Encoded-Unicast-Source Address
host address of source from multicast data packet in
register. The format for this address is given in the
Encoded-Unicast-Address in 4.1. A special wild card value
(0's), can be used to indicate any source.
コード化されたユニキャストソースAddressはレジスタでマルチキャストデータ・パケットからのソースのアドレスをホスティングします。 4.1におけるEncodedユニキャストアドレスでこのアドレスのための書式を与えます。 特別なワイルドカードは(0)を評価して、どんなソースも示すのに使用できます。
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)を建てるために、送ります。 メンバーが共有された木を使用しないソースと同様にグループを出るとき、ソース木を剪定するためにプルーンを送ります。
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャスト上流隣人アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| ヌムグループ| Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたマルチキャストグループアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースの数| 剪定されたソースの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて接合されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて接合されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたマルチキャストグループアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースの数| 剪定されたソースの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 47] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [47ページ]実験的なRFC2362PIM-Sm1998年6月
| Encoded-Joined Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| コード化されて接合されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて接合されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されて剪定されたソースアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described above.
PIMバージョン、Type、Reserved、上のChecksum Described。
Encoded-Unicast Upstream Neighbor Address
The address of the RPF or upstream neighbor. The format
for this address is given in the Encoded-Unicast-Address in
4.1. .IP "Reserved"
Transmitted as zero, ignored on receipt.
RPFか上流のアドレスが近所付き合いさせるコード化されたユニキャストUpstream Neighbor Address。 4.1におけるEncodedユニキャストアドレスでこのアドレスのための書式を与えます。 .IPは領収書の上で無視されたゼロとして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の数、与えられたグループのために記載されたソースアドレスを接合してください。
Estrin, et. al. Experimental [Page 48] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [48ページ]実験的なRFC2362PIM-Sm1998年6月
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の互換性に使用されます。
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 IPv4 native encoding
address :
ソースアドレスはアドレスをコード化するホストIPv4ネイティブであるかもしれません:
< 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>。
Estrin, et. al. Experimental [Page 49] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [49ページ]実験的なRFC2362PIM-Sm1998年6月
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/プルーンであるなら最大のパケットサイズを超えています、そして含まれているコネが同じパケットであったに違いないなら同じグループのためのリストを接合して、剪定してください。
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:
単一の'断片'の意味論を以下に与えます:
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask len | BSR-priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-BSR-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-1 | Frag RP-Cnt-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 断片タグ| 細切れ肉料理Mask len| BSR-優先権| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストBSRアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPカウント1| RP-Cnt-1を破片手榴弾で殺傷してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストRPアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime| RP1-優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストRPアドレス2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime| RP2-優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 50] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [50ページ]実験的なRFC2362PIM-Sm1998年6月
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-n | Frag RP-Cnt-n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| コード化されたユニキャストRPアドレスm| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rpm Holdtime| rpm優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPはnを数えます。| RP-Cnt-nを破片手榴弾で殺傷してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストRPアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime| RP1-優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストRPアドレス2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime| RP2-優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストRPアドレスm| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rpm Holdtime| rpm優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described above.
PIMバージョン、Type、Reserved、上の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アドレスを比較するとき、この分野は高位バイトであるとみなされます。
Estrin, et. al. Experimental [Page 51] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [51ページ]実験的なRFC2362PIM-Sm1998年6月
Encoded-Unicast-BSR-Address
The address of the bootstrap router for the domain. The
format for this address is given in the Encoded-Unicast-
Address in 4.1. .IP "Encoded-Group Address-1..n"
The group prefix (address and mask) with which the
Candidate RPs are associated. Format previously described.
コード化されたユニキャストBSRアドレス、アドレス、ドメインにルータを独力で進んでください。 4.1におけるEncoded-ユニキャストアドレスでこのアドレスのための書式を与えます。 .IP「コード化されたグループアドレス-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-セットの構文解析、いつを容易にするか。
Encoded-Unicast-RP-address-1..m
The address of the Candidate RPs, for the corresponding
group prefix. The format for this address is given in the
Encoded-Unicast-Address in 4.1. .IP "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.
コード化されたユニキャストRPは1を記述します。m、対応するグループ接頭語のためのCandidate RPsのアドレス。 4.1におけるEncodedユニキャストアドレスでこのアドレスのための書式を与えます。 .IP"RP1"。対応するRPのための「m-Holdtime」Holdtime。 この分野はBSRに格納された関連RPの'Holdtime'分野からコピーされます。
RP1..m-Priority
The `Priority' of the corresponding RP and Encoded-Group
Address. This field is copied from the `Priority' field
stored at the BSR when receiving a Candidate-RP-
Advertisement. The highest priority is `0' (i.e. the lower
the value of the `Priority' field, the higher). Note that
the priority is per RP per Encoded-Group Address.
RP1。m優先権対応するRPとEncoded-グループの'優先権'Address。 この分野はCandidate-RP広告を受け取るときBSRに格納された'優先権'野原からコピーされます。 最優先は'0'(すなわち、'優先権'分野の値が低ければ低いほど、より高い)です。 優先権がEncoded-グループAddressあたりのRP単位であることに注意してください。
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。)
Estrin, et. al. Experimental [Page 52] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [52ページ]実験的なRFC2362PIM-Sm1998年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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| メートル法の好み| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described above.
PIMバージョン、Type、Reserved、上の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。 以前に説明された形式。
Encoded-Unicast-Source Address
Source address from multicast datagram that triggered the
Assert packet to be sent. The format for this address is
given in the Encoded-Unicast-Address in 4.1. .IP "R"
RPT-bit is a 1 bit value. If the multicast datagram that
triggered the Assert packet is routed down the RP tree,
then the RPT-bit is 1; if the multicast datagram is routed
down the SPT, it is 0.
送られるAssertパケットの引き金となったマルチキャストデータグラムからのコード化されたユニキャストソースAddress Sourceアドレス。 4.1におけるEncodedユニキャストアドレスでこのアドレスのための書式を与えます。 .IP「R」RPT-ビットは1ビットの値です。 Assertパケットの引き金となったマルチキャストデータグラムがRP木の下側に発送されるなら、RPT-ビットは1です。 マルチキャストデータグラムがSPTの下側に発送されるなら、それは0です。
Metric Preference
Preference value assigned to the unicast routing protocol
that provided the route to Host address.
メートル法のPreference Preference値はHostアドレスへのルートであるならユニキャストルーティング・プロトコルにそれを割り当てました。
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の濃いモード仕様を参照してください。
Estrin, et. al. Experimental [Page 53] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [53ページ]実験的なRFC2362PIM-Sm1998年6月
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Cnt | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-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| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語-Cnt| 優先権| Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたユニキャストRPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたグループアドレス-n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described above.
PIMバージョン、Type、Reserved、上の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'のデフォルト値を置きます。
Priority
The `Priority' of the included RP, for the corresponding
Encoded-Group Address (if any). highest priority is `0'
(i.e. the lower the value of the `Priority' field, the
higher the priority). This field is stored at the BSR upon
receipt along with the RP address and corresponding
Encoded-Group Address.
優先権包含の'優先権'RP、対応するEncoded-グループにおいて、Address(もしあれば)最優先は'0'(すなわち、'優先権'分野の値が低ければ低いほど、優先度は、より高い)です。 この野原はRPアドレスと対応するEncoded-グループAddressに伴う領収書でBSRに格納されます。
Holdtime
The amount of time the advertisement is valid. This field
allows advertisements to be aged out.
Holdtime、広告が有効である時間。 この分野は熟成するべき広告の外出することを許します。
Estrin, et. al. Experimental [Page 54] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [54ページ]実験的なRFC2362PIM-Sm1998年6月
Encoded-Unicast-RP-Address
The address of the interface to advertise as a Candidate
RP. The format for this address is given in the Encoded-
Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n"
The group prefixes for which the C-RP is advertising.
Format previously described.
コード化されたユニキャストRPアドレス、Candidate RPとして広告を出すインタフェースのアドレス。 4.1におけるEncodedユニキャストアドレスでこのアドレスのための書式を与えます。 .IP「コード化されたグループアドレス-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 [8] 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[8]の作者とIDMR WGの会員資格はこの仕事のための動機づけている考えとデザインの詳細の役に立つフィードバックの多くを提供しました。
This work was supported by the National Science Foundation, ARPA, cisco Systems and Sun Microsystems.
この仕事は国立科学財団、ARPA、コクチマスSystems、およびサン・マイクロシステムズによって支持されました。
Estrin, et. al. Experimental [Page 55] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [55ページ]実験的なRFC2362PIM-Sm1998年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'と比べて、この付録は仕様ドキュメントにおける大きな変化に居住します。
bsubsection*Major Changes
bsubsection*大きな変化
List of changes since March '96 IETF:
3月の96年IETF以来変化について記載してください:
1. (*,*,RP) Joins state and data forwarding check; replaces (*,G-
Prefix) Joins state for interoperability. (*,G) negative cache
introduced for the (*,*,RP) state supporting mechanisms.
1. (*、*、RP) チェックを進める州とデータに加わります。 取り替え、(*、G接頭語)は相互運用性を州と一緒に楽しみます。 (*、G) 否定的キャッシュは(*、*、RP)状態にサポートメカニズムを取り入れました。
2. Semantic fragmentation for the Bootstrap message.
2. Bootstrapメッセージのための意味断片化。
3. Refinement of Assert details.
3. Assertの詳細の気品。
4. Addition and refinement of Join/Prune suppression and Register
suppression (introduction of null Registers).
4. Join/プルーンの抑圧とRegister抑圧(ヌルRegistersの導入)の添加と気品。
5. Editorial changes and clarifications to the timers section.
5. タイマ部分への編集の変化と明確化。
6. Addition of Appendix II (BSR Election and RP-Set Distribution),
and Appendix III (Glossary of Terms).
6. 付録II(BSR選挙とRP-セット分配)、および付録III(用語の用語集)の添加。
7. Addition of table of contents.
7. 目次の添加。
List of changes incurred since version 1 of the spec.:
仕様のバージョン1以来被られた変化のリスト、:
1. Proposal and refinement of bootstrap router (BSR) election
mechanisms
1. 提案と気品、ルータ(BSR)選挙メカニズムを独力で進んでください。
2. Introduction of hash functions for Group to RP mapping
2. RPマッピングへのGroupのためのハッシュ関数の導入
3. New RP-liveness indication mechanisms based upon the the
Bootstrap Router (BSR) and the Bootstrap messages.
3. 新しいRP-活性指示メカニズムは(BSR)とBootstrapメッセージをBootstrap Routerに基礎づけました。
4. Removal of reachability messages, RP reports and multiple RPs
per group.
4. 1グループあたりの可到達性メッセージ、RPレポート、および複数のRPsの解任。
*Packet Format Changes
*パケット・フォーマット変化
Packet Format incurred updates to accommodate different address
lengths, and address aggregation.
パケットFormatは、異なったアドレスの長さ、およびアドレス集合を収容するためにアップデートを被りました。
Estrin, et. al. Experimental [Page 56] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [56ページ]実験的なRFC2362PIM-Sm1998年6月
1 The `Addr Family' and `Encoding Type' fields were added to the
packet formats.
1 'Addr Family'と'Typeをコード化します'分野はパケット・フォーマットに加えられました。
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 57] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [57ページ]実験的なRFC2362PIM-Sm1998年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 mechanisms. These mechanisms are described by the following state machine, illustrated in figure 4. The protocol transitions for a Candidate-BSR are given in state diagram (a). For routers not configured as Candidate-BSRs, the protocol transitions are given in state diagram (b).
中古のコネはBSR選挙とRP-セット分配メカニズムの両方ですか?簡単さのためにイラスト入りである、これらのメカニズムが以下の州のマシンによって説明されるというメッセージを独力で進んでください、図4では、イラスト入りです。 州のダイヤグラム(a)でCandidate-BSRのためのプロトコル変遷を与えます。 Candidate-BSRsとして構成されなかったルータにおいて、州のダイヤグラム(b)でプロトコル変遷を与えます。
[Figures are present only in the postscript version] Fig. 4 State
Diagram for the BSR election and RP-Set distribution
[数字は追伸バージョンだけに存在しています] 図4 BSR選挙のための州DiagramとRP-セット分配
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 Candidate-BSR, or to 0 otherwise), and a local RP- Set `LclRP-Set' (initially empty). The main stimuli to the state machine are timer events and arrival of bootstrap messages:
地方のBSR分野'LclBSR'(別の方法でCandidate-BSRであるか、0へのローカルアドレスに初期化される)、および地方のRPセット'LclRP-セット'に加えたPIMルータがタイマを独力で進んで、初期化されているようにaを保つそれぞれ[タイムアウトを独力で進みます](初めは空の)。 州のマシンへの主な刺激がタイマ出来事と到着である、メッセージを独力で進んでください:
bsubsection*Initial States and Timer Events
bsubsection*初期状態とタイマ出来事
1
1
2 If the router is a Candidate-BSR:
2 ルータがCandidate-BSRであるなら:
1
1
2 The router operates initially in the `CandBSR' state,
where it does not originate any bootstrap messages.
ルータが初めは'CandBSR'状態で操作する2はメッセージを独力で進みます。そこでは、それがいずれも溯源しません。
3 If the bootstrap-timer expires, and the current state
is `CandBSR', the router originates a 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. Note that the actual sending of
the bootstrap message may be delayed by a random value
to reduce transient control overhead. To obtain best
results, the random value is set such that the
preferred BSR is the first to originate a bootstrap
message. We propose the following as an efficient
implementation of the random value delay (in seconds):
タイマを独力で進むなら、3は期限が切れます、そして、現状は'CandBSR'、ルータがaを溯源するということです。[期間を独力で進みます]をタイマを独力で進んだ秒を再開します、そして、それ自身の地方のRP-セット、BSR優先権、およびアドレスを運びながらメッセージを独力で進んで、'ElectedBSR'状態に通過します。 メッセージを独力で進んでください。それに注意してください、実際の発信、無作為の値で遅れて、一時的なコントロールオーバーヘッドを下げてもよいです。 効果を収めるためには都合のよいBSRによるaを溯源する1番目がメッセージを独力で進むという無作為の値が設定されるのによることです。 私たちは無作為の値の遅れ(秒の)の効率的な実現として以下を提案します:
Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) + AddrDelay
5+2*遅れ=ログ_2(1+bestPriority--myPriority)+AddrDelay
where myPriority is the Candidate-BSR's
configured priority, and bestPriority equals:
myPriorityはどこのCandidate-BSRの構成された優先権ですか、そして、bestPriority同輩:
bestPriority = Max(storedPriority, myPriority) ]
bestPriorityはマックス(storedPriority、myPriority]と等しいです。
Estrin, et. al. Experimental [Page 58] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [58ページ]実験的なRFC2362PIM-Sm1998年6月
and AddrDelay is given by the following:
そして、以下はAddrDelayを与えます:
1 if ( bestPriority equals myPriority) then
[AddrDelay = log_2(bestAddr - myAddr) / 16, ]
1、(bestPriorityはmyPriorityと等しいです)その時です。[AddrDelayはログ_2(bestAddr--myAddr)/16と等しいです]
2 else [AddrDelay = 2 - (myAddr / 2^31) ]
2 ほかに[AddrDelay=2--(myAddr / 2^31)]
where myAddr is the Candidate-BSR's address, and
bestAddr is the stored BSR's address.
myAddrがCandidate-BSRのアドレスであり、bestAddrが格納されたBSRのアドレスであるところ。
4 If the bootstrap-timer expires, and the current state
is `ElectedBSR', the router originates a bootstrap
message, and restarts the RP-Set timer at [Bootstrap-
Period]. No state transition is incurred.
タイマを独力で進むなら、4は期限が切れます、そして、現状は'ElectedBSR'、ルータが由来するということです。そして、aがメッセージを摘み皮である、RP-セットタイマを再開する、[期間を独力で進みます。] 状態遷移は全く被られません。
This way, the elected BSR originates periodic
bootstrap messages every [Bootstrap-Period].
このように、選出されたBSRが周期的に由来する、メッセージを独力で進んでください、あらゆる、[期間を独力で進んだ。]
3 If a router is not a Candidate-BSR:
3 ルータがCandidate-BSRでないなら:
1
1
2 The router operates initially in the `AxptAny' state.
In such state, a router accepts the first bootstrap
message from the The Reverse Path Forwarding (RPF)
neighbor toward the included BSR. The RPF neighbor in
this case is the next hop router en route to the
included BSR.
2 ルータは初めは、'AxptAny'状態で作動します。 そのような状態、ルータが受け入れるaでは、1番目はReverse Path Forwarding(RPF)隣人からのメッセージを含まれているBSRに向かって独力で進みます。 含まれているBSRへの途中で、この場合RPF隣人は次のホップルータです。
3 If the bootstrap-timer expires, and the current state
is `AxptPref'-- where the router accepts only
preferred bootstrap messages (those that carry BSR-
priority and address higher than, or equal to,
`LclBSR') from the RPF neighbor toward the included
BSR-- the router transits into the `AxptAny' state.
タイマを独力で進むなら3が期限が切れて、現状がルータが受け入れる都合のよいだけである状態でところの'AxptPref'がメッセージを独力で進むということである、(BSR優先権とアドレスをより高く運ぶもの、等しい、'LclBSR')、含まれているBSRに向かったRPF隣人--ルータは'AxptAny'状態に通過します。
In this case, if an elected BSR becomes unreachable,
the routers start accepting bootstrap messages from
another Candidate-BSR after the bootstrap-timer
expires. All PIM routers within a domain converge on
the preferred reachable Candidate-BSR.
この場合、選出されたBSRが手が届かなくなるなら、タイマを独力で進むのが期限が切れた後にルータ受け付け開始は別のCandidate-BSRからのメッセージを独力で進みます。 ドメインの中のすべてのPIMルータが都合のよい届いているCandidate-BSRに集まります。
Estrin, et. al. Experimental [Page 59] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [59ページ]実験的なRFC2362PIM-Sm1998年6月
Receiving Bootstrap Message:
受信して、メッセージを独力で進んでください:
To avoid loops, an RPF check is performed on the included BSR
address. Upon receiving a bootstrap message from the RPF
neighbor toward the included BSR, the following actions are
taken:
輪を避けるために、RPFチェックは含まれているBSRアドレスに実行されます。 aを受けたら、含まれているBSRに向かってRPF隣人からのメッセージを独力で進んでください、そして、以下の行動を取ります:
1 If the router is not a Candidate-BSR:
1 ルータがCandidate-BSRでないなら:
1 If the current state is `AxptAny', the router accepts
the bootstrap message, and transits into the
`AxptPref' state.
ルータが、1が現状であるなら'AxptAny'であると受け入れる、'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'であるならメッセージを好んで、メッセージを受け入れます。 状態遷移は全く被られません。
2 If the router is a Candidate-BSR, and the bootstrap message
is preferred, the message is accepted. Further, if this
happens when the current state is `Elected BSR', the router
transits into the `CandBSR' state.
独力で進んでください。そして、2 ルータがCandidate-BSRであるならメッセージを好んで、メッセージを受け入れます。 さらに、現状が'BSRに選出される'とき、これが起こるなら、ルータは'CandBSR'状態に通過します。
When a 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.
aが独力で進むとき、メッセージを受け入れて、ルータが、[タイムアウトを独力で進みます]をタイマを独力で進むのを再開して、店が'LclBSR'の容認されたBSR優先権とアドレスであり、中の容認されたRP-セットが'LclRP-セット'と、フォワードである、受信インタフェース以外のすべてのインタフェースからメッセージを独力で進んでください。
If a bootstrap message is rejected, no state transitions are
triggered.
aが独力で進むなら、メッセージは拒絶されて、状態遷移は全く引き起こされません。
Estrin, et. al. Experimental [Page 60] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [60ページ]実験的なRFC2362PIM-Sm1998年6月
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に代わって引き継ぐかもしれません。
* { 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リストがあります。
Estrin, et. al. Experimental [Page 61] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [61ページ]実験的なRFC2362PIM-Sm1998年6月
* 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 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隣人は、アドレス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 62] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [62ページ]実験的なRFC2362PIM-Sm1998年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., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast (pim): Motivation and Architecture", Work in Progress.
1. デアリング、S.、Estrin、D.、ファリナッチ、D.、ジェーコブソン、V.、リュウ、C.、ウェイ、L.、シャルマ、P.、およびA.Helmy、「独立しているマルチキャスト(pim)について議定書の中で述べてください」 「動機と構造」は進行中で働いています。
2. S. Deering, 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., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., 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、「無党派のMulticast濃いMode(pim- dm)について議定書の中で述べてください」 「プロトコル仕様」、処理中の作業。
4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
4. デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
5. Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
5. w.フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
Estrin, et. al. Experimental [Page 63] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [63ページ]実験的なRFC2362PIM-Sm1998年6月
6. Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
6. アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年8月。
7. Mark R. Nelson. File verification using CRC. Dr. Dobb's Journal, May 1992.
7. R.ネルソンをマークしてください。 CRCを使用して、検証をファイルしてください。 1992年5月のドッブ博士のジャーナル。
8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993.
8. A.J.Ballardie、P.F.フランシス、およびJ.クロウクロフト。 コアは木を基礎づけました。 ACM SIGCOMM、サンフランシスコ1993年の議事で。
Authors' Addresses
作者のアドレス
NOTE: 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人の作者が、第一のエディタであり、アルファベット順に、記載されています。 また、アルファベット順に、記載された作者の残りは、建築していて詳細なデザインの全面に参加しましたが、ハッキングなしでラテックスを何とか離れさせました!
Deborah Estrin Computer Science Dept/ISI University of Southern Calif. Los Angeles, CA 90089
南部のカリフォルニアのデボラEstrinコンピュータサイエンス部/ISI大学 ロサンゼルス、カリフォルニア 90089
EMail: estrin@usc.edu
メール: estrin@usc.edu
Dino Farinacci Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134
サンノゼ、カリフォルニア 恐竜ファリナッチシスコシステムズ株式会社170の西タスマンDrive、95134
EMail: dino@cisco.com
メール: dino@cisco.com
Ahmed Helmy Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089
アフマドHelmyコンピュータサイエンス部 南部のカリフォルニア大学 ロサンゼルス、カリフォルニア 90089
EMail: ahelmy@catarina.usc.edu
メール: ahelmy@catarina.usc.edu
David Thaler EECS Department University of Michigan Ann Arbor, MI 48109
デヴィッド・ターレルEECS部のミシガン大学アナーバー、MI 48109
EMail: thalerd@eecs.umich.edu
メール: thalerd@eecs.umich.edu
Estrin, et. al. Experimental [Page 64] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [64ページ]実験的なRFC2362PIM-Sm1998年6月
Stephen Deering Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304
スティーブンデアリングゼロックスPARC3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304
EMail: deering@parc.xerox.com
メール: deering@parc.xerox.com
Mark Handley Department of Computer Science University College London Gower Street London, WC1E 6BT UK
マーク・ハンドレー・コンピュータサイエンス学部ユニバーシティ・カレッジロンドンガウアー・ストリートロンドン、WC1E 6BTイギリス
EMail: m.handley@cs.ucl.ac.uk
メール: m.handley@cs.ucl.ac.uk
Van Jacobson Lawrence Berkeley Laboratory 1 Cyclotron Road Berkeley, CA 94720
Roadバークレー、ヴァンジェーコブソンローレンスバークレイ研究所1Cyclotronカリフォルニア 94720
EMail: van@ee.lbl.gov
メール: van@ee.lbl.gov
Ching-gung Liu Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089
チン-gungリュウコンピュータサイエンス部 南部のカリフォルニア大学 ロサンゼルス、カリフォルニア 90089
EMail: charley@catarina.usc.edu
メール: charley@catarina.usc.edu
Puneet Sharma Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089
Puneetシャルマコンピュータサイエンス部 南部のカリフォルニア大学 ロサンゼルス、カリフォルニア 90089
EMail: puneet@catarina.usc.edu
メール: puneet@catarina.usc.edu
Liming Wei Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134
サンノゼ、カリフォルニア ウェイシスコシステムズ株式会社170の西タスマンDrive、95134に石灰をまきます。
EMail: lwei@cisco.com
メール: lwei@cisco.com
Estrin, et. al. Experimental [Page 65] RFC 2362 PIM-SM June 1998
et Estrin、アル。 [65ページ]実験的なRFC2362PIM-Sm1998年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Estrin, et. al. Experimental [Page 66]
et Estrin、アル。 実験的[66ページ]
一覧
スポンサーリンク
