RFC4601 日本語訳
4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): ProtocolSpecification (Revised). B. Fenner, M. Handley, H. Holbrook, I.Kouvelas. August 2006. (Format: TXT=340632, PDF=304538 bytes) (Obsoletes RFC2362) (Updated by RFC5059) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Fenner
Request for Comments: 4601 AT&T Labs - Research
Obsoletes: 2362 M. Handley
Category: Standards Track UCL
H. Holbrook
Arastra
I. Kouvelas
Cisco
August 2006
コメントを求めるワーキンググループB.フェナーの要求をネットワークでつないでください: 4601のAT&T研究室--研究は以下を時代遅れにします。 2362年のM.ハンドレーカテゴリ: 標準化過程UCL H.ホルブルックArastra I.Kouvelasコクチマス2006年8月
Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)
プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm): プロトコル仕様(改訂されます)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.
このドキュメントはプロトコル無党派Multicastを指定します--まばらなMode(PIM-SM)。 PIM-SMは基本的なユニキャストルーティング情報ベースか別々のマルチキャストできるルーティング情報ベースを使用できるマルチキャストルーティング・プロトコルです。 それは、グループ単位でRendezvous Point(RP)に根づいている単方向の共有された木を建てて、ソース単位で最短パス木を任意に作成します。
This document obsoletes RFC 2362, an Experimental version of PIM-SM.
このドキュメントはRFC2362、PIM-SMのExperimentalバージョンを時代遅れにします。
Fenner, et al. Standards Track [Page 1] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................5
2. Terminology .....................................................5
2.1. Definitions ................................................5
2.2. Pseudocode Notation ........................................7
3. PIM-SM Protocol Overview ........................................7
3.1. Phase One: RP Tree .........................................8
3.2. Phase Two: Register-Stop ...................................8
3.3. Phase Three: Shortest-Path Tree ............................9
3.4. Source-Specific Joins .....................................10
3.5. Source-Specific Prunes ....................................11
3.6. Multi-Access Transit LANs .................................11
3.7. RP Discovery ..............................................12
4. Protocol Specification .........................................12
4.1. PIM Protocol State ........................................13
4.1.1. General Purpose State ..............................14
4.1.2. (*,*,RP) State .....................................15
4.1.3. (*,G) State ........................................16
4.1.4. (S,G) State ........................................17
4.1.5. (S,G,rpt) State ....................................20
4.1.6. State Summarization Macros .........................21
4.2. Data Packet Forwarding Rules ..............................26
4.2.1. Last-Hop Switchover to the SPT .....................28
4.2.2. Setting and Clearing the (S,G) SPTbit ..............29
4.3. Designated Routers (DR) and Hello Messages ................30
4.3.1. Sending Hello Messages .............................30
4.3.2. DR Election ........................................32
4.3.3. Reducing Prune Propagation Delay on LANs ...........34
4.3.4. Maintaining Secondary Address Lists ................37
4.4. PIM Register Messages .....................................38
4.4.1. Sending Register Messages from the DR ..............38
4.4.2. Receiving Register Messages at the RP ..............43
4.5. PIM Join/Prune Messages ...................................45
4.5.1. Receiving (*,*,RP) Join/Prune Messages .............45
4.5.2. Receiving (*,G) Join/Prune Messages ................49
4.5.3. Receiving (S,G) Join/Prune Messages ................53
4.5.4. Receiving (S,G,rpt) Join/Prune Messages ............56
4.5.5. Sending (*,*,RP) Join/Prune Messages ...............62
4.5.6. Sending (*,G) Join/Prune Messages ..................66
4.5.7. Sending (S,G) Join/Prune Messages ..................71
4.5.8. (S,G,rpt) Periodic Messages ........................76
4.5.9. State Machine for (S,G,rpt) Triggered Messages .....77
4.5.10. Background: (*,*,RP) and (S,G,rpt) Interaction ....82
4.6. PIM Assert Messages .......................................83
4.6.1. (S,G) Assert Message State Machine .................83
4.6.2. (*,G) Assert Message State Machine .................91
4.6.3. Assert Metrics .....................................98
1. 序論…5 2. 用語…5 2.1. 定義…5 2.2. 擬似コード記法…7 3. PIM-Smプロトコル概要…7 3.1. フェーズ1: RP木…8 3.2. フェーズTwo: レジスタで止まってください…8 3.3. フェーズThree: 最短パス木…9 3.4. ソース詳細は接合します…10 3.5. ソース特有のプルーン…11 3.6. マルチアクセス輸送機関LAN…11 3.7. RP発見…12 4. 仕様を議定書の中で述べてください…12 4.1. PIMは状態について議定書の中で述べます…13 4.1.1. 汎用の状態…14 4.1.2. (*、*、RP) 状態…15 4.1.3. (*、G) 状態…16 4.1.4. (S、G) 状態…17 4.1.5. (S、G、rpt) 状態…20 4.1.6. 総括マクロを述べてください…21 4.2. データ・パケット推進は統治されます…26 4.2.1. 最後にSPTへの転換を飛び越してください…28 4.2.2. (S、G)SPTbitを設定して、きれいにします…29 4.3. ルータ(DR)に指定されて、こんにちは、メッセージ…30 4.3.1. 発信、こんにちは、メッセージ…30 4.3.2. DR選挙…32 4.3.3. プルーンの伝播を抑えて、LANで延着してください…34 4.3.4. セカンダリアドレスを維持するのは記載します…37 4.4. PIMはメッセージを登録します…38 4.4.1. DRからレジスタメッセージを送ります…38 4.4.2. RPにレジスタメッセージを受け取ります…43 4.5. PIMはメッセージを接合するか、または剪定します…45 4.5.1. 受信して(*、*、RP)、メッセージを接合するか、または剪定してください…45 4.5.2. 受信して(*、G)、メッセージを接合するか、または剪定してください…49 4.5.3. 受信して(S、G)、メッセージを接合するか、または剪定してください…53 4.5.4. 受信して(S、G、rpt)、メッセージを接合するか、または剪定してください…56 4.5.5. 発信して(*、*、RP)、メッセージを接合するか、または剪定してください…62 4.5.6. 発信して(*、G)、メッセージを接合するか、または剪定してください…66 4.5.7. 発信して(S、G)、メッセージを接合するか、または剪定してください…71 4.5.8. (S、G、rpt) 周期的なメッセージ…76 4.5.9. (S、G、rpt)のために引き起こされたメッセージを機械加工するように述べてください…77 4.5.10. バックグラウンド: (*、*、RP) (S、G、rpt)相互作用…82 4.6. PIMはメッセージについて断言します…83 4.6.1. (S、G) メッセージ状態がマシンであると断言してください…83 4.6.2. (*、G) メッセージ状態がマシンであると断言してください…91 4.6.3. 測定基準について断言してください…98
Fenner, et al. Standards Track [Page 2] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[2ページ]。
4.6.4. AssertCancel Messages ..............................99
4.6.5. Assert State Macros ...............................100
4.7. PIM Bootstrap and RP Discovery ...........................103
4.7.1. Group-to-RP Mapping ...............................104
4.7.2. Hash Function .....................................105
4.8. Source-Specific Multicast ................................106
4.8.1. Protocol Modifications for SSM Destination
Addresses .........................................106
4.8.2. PIM-SSM-Only Routers ..............................107
4.9. PIM Packet Formats .......................................108
4.9.1. Encoded Source and Group Address Formats ..........110
4.9.2. Hello Message Format ..............................113
4.9.3. Register Message Format ...........................116
4.9.4. Register-Stop Message Format ......................119
4.9.5. Join/Prune Message Format .........................119
4.9.5.1. Group Set Source List Rules ..............122
4.9.5.2. Group Set Fragmentation ..................126
4.9.6. Assert Message Format .............................126
4.10. PIM Timers ..............................................128
4.11. Timer Values ............................................129
5. IANA Considerations ...........................................135
5.1. PIM Address Family .......................................135
5.2. PIM Hello Options ........................................136
6. Security Considerations .......................................136
6.1. Attacks Based on Forged Messages .........................136
6.1.1. Forged Link-Local Messages ........................136
6.1.2. Forged Unicast Messages ...........................137
6.2. Non-Cryptographic Authentication Mechanisms ..............137
6.3. Authentication Using IPsec ...............................138
6.3.1. Protecting Link-Local Multicast Messages ..........138
6.3.2. Protecting Unicast Messages .......................139
6.3.2.1. Register Messages ........................139
6.3.2.2. Register-Stop Messages ...................139
6.4. Denial-of-Service Attacks ................................140
7. Acknowledgements ..............................................140
8. Normative References ..........................................141
9. Informative References ........................................141
Appendix A. PIM Multicast Border Router Behavior .................143
A.1. Sources External to the PIM-SM Domain ....................143
A.2. Sources Internal to the PIM-SM Domain ...................144
Appendix B. Index ................................................146
4.6.4. AssertCancelメッセージ…99 4.6.5. 状態がマクロであると断言してください…100 4.7. そして、PIMが摘み皮である、RP発見…103 4.7.1. グループからRPへのマッピング…104 4.7.2. 機能を論じ尽くしてください…105 4.8. ソース特有のマルチキャスト…106 4.8.1. SSM送付先アドレスのための変更について議定書の中で述べてください…106 4.8.2. PIM-SSMだけルータ…107 4.9. PIMパケット・フォーマット…108 4.9.1. ソースとグループアドレス形式をコード化します…110 4.9.2. こんにちは、メッセージ・フォーマット…113 4.9.3. メッセージ・フォーマットを示してください…116 4.9.4. レジスタ停止メッセージ形式…119 4.9.5. メッセージ・フォーマットを接合するか、または剪定してください…119 4.9.5.1. セットソース・リスト規則を分類してください…122 4.9.5.2. セット断片化を分類してください…126 4.9.6. メッセージ・フォーマットについて断言してください…126 4.10. PIMタイマ…128 4.11. タイマ値…129 5. IANA問題…135 5.1. PIMはファミリーに演説します…135 5.2. PIM、こんにちは、オプション…136 6. セキュリティ問題…136 6.1. 攻撃は偽造メッセージを基礎づけました…136 6.1.1. リンクローカルのメッセージを作り出します…136 6.1.2. ユニキャストメッセージを作り出します…137 6.2. 非暗号の認証機構…137 6.3. IPsecを使用する認証…138 6.3.1. リンクローカルのマルチキャストメッセージを保護します…138 6.3.2. ユニキャストメッセージを保護します…139 6.3.2.1. メッセージを登録してください…139 6.3.2.2. メッセージをレジスタで止めてください…139 6.4. サービス不能攻撃…140 7. 承認…140 8. 標準の参照…141 9. 有益な参照…141 付録A.PIMマルチキャスト境界ルータの振舞い…143 A.1。 PIM-Smドメインへの外部のソース…143 A.2。 PIM-Smドメインへの内部のソース…144付録B.は索引をつけます…146
Fenner, et al. Standards Track [Page 3] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[3ページ]。
List of Figures
数字のリスト
Figure 1. Per-(S,G) register state machine at a DR ................38
Figure 2. Downstream per-interface (*,*,RP) state machine .........46
Figure 3. Downstream per-interface (*,G) state machine ............50
Figure 4. Downstream per-interface (S,G) state machine ............53
Figure 5. Downstream per-interface (S,G,rpt) state machine ........57
Figure 6. Upstream (*,*,RP) state machine .........................62
Figure 7. Upstream (*,G) state machine ............................67
Figure 8. Upstream (S,G) state machine ............................71
Figure 9. Upstream (S,G,rpt) state machine for triggered
messages ................................................77
Figure 10. Per-interface (S,G) Assert State machine ...............84
Figure 11. Per-interface (*,G) Assert State machine ...............92
図1。 -、(S、G)はDRに州のマシンを登録します…38 図2。 川下のインタフェース(*、*、RP)州のマシン…46 図3。 川下のインタフェース(*、G)州のマシン…50 図4。 川下のインタフェース(S、G)州のマシン…53 図5。 川下のインタフェース(S、G、rpt)州のマシン…57 図6。 上流(*、*、RP)の州のマシン…62 図7。 上流(*、G)の州のマシン…67 エイト環。 上流(S、G)の州のマシン…71 図9。 引き起こされたメッセージのための上流(S、G、rpt)の州のマシン…77 図10。 インタフェースに従って、(S、G)は、州がマシンであると断言します…84 図11。 インタフェースに従って、(*、G)は、州がマシンであると断言します…92
Fenner, et al. Standards Track [Page 4] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[4ページ]。
1. Introduction
1. 序論
This document specifies a protocol for efficiently routing multicast groups that may span wide-area (and inter-domain) internets. This protocol is called Protocol Independent Multicast - Sparse Mode (PIM-SM) because, although it may use the underlying unicast routing to provide reverse-path information for multicast tree building, it is not dependent on any particular unicast routing protocol.
このドキュメントは効率的に広い領域(そして、相互ドメイン)インターネットにかかるかもしれないマルチキャストグループを発送するのにプロトコルを指定します。 このプロトコルはプロトコル無党派Multicastと呼ばれます--、まばらなMode、(PIM-SM) マルチキャスト木のビルのための逆経路情報を提供するのに基本的なユニキャストルーティングを使用するかもしれませんが、それがどんな特定のユニキャストルーティング・プロトコルにも依存していないので。
PIM-SM version 2 was originally specified in RFC 2117 and was revised in RFC 2362, both Experimental RFCs. This document is intended to obsolete RFC 2362, to correct a number of deficiencies that have been identified with the way PIM-SM was previously specified, and to bring PIM-SM onto the IETF Standards Track. As far as possible, this document specifies the same protocol as RFC 2362 and only diverges from the behavior intended by RFC 2362 when the previously specified behavior was clearly incorrect. Routers implemented according to the specification in this document will be able to interoperate successfully with routers implemented according to RFC 2362.
PIM-SMバージョン2は、元々RFC2117で指定されて、RFC2362、両方のExperimental RFCsで改訂されました。 このドキュメントは、RFC2362を時代遅れにして、PIM-SMが以前に指定された方法と同一視された多くの欠乏を修正して、PIM-SMをIETF Standards Trackに持って来ることを意図します。 このドキュメントは、できるだけ、RFC2362と同じプロトコルを指定して、以前に指定された振舞いが明確に不正確であったRFC2362年までに意図する振舞いからそれるだけです。 RFC2362によると、ルータが実装されている状態で、仕様通りに実装されたルータは本書では首尾よく共同利用できるでしょう。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant PIM-SM implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは対応するPIM-Sm実装のためにRFCで2119[1]について説明して、要件レベルを示すとき解釈されることであるべきですか?
2.1. Definitions
2.1. 定義
The following terms have special significance for PIM-SM:
次の用語には、PIM-SMに、特別な意味があります:
Rendezvous Point (RP):
An RP is a router that has been configured to be used as the
root of the non-source-specific distribution tree for a
multicast group. Join messages from receivers for a group are
sent towards the RP, and data from senders is sent to the RP so
that receivers can discover who the senders are and start to
receive traffic destined for the group.
ポイント(RP)を集合させてください: RPはマルチキャストグループに非ソースの詳細分配木の根として使用されるために構成されたルータです。 RPに向かってグループを送って、受信機が、送付者がだれであるかを発見して、グループのために運命づけられたトラフィックを受け始めることができるように送付者からのデータをRPに送るので、受信機からのメッセージを接合してください。
Designated Router (DR):
A shared-media LAN like Ethernet may have multiple PIM-SM
routers connected to it. A single one of these routers, the
DR, will act on behalf of directly connected hosts with respect
to the PIM-SM protocol. A single DR is elected per interface
(LAN or otherwise) using a simple election process.
代表ルータ(DR): イーサネットのような共有されたメディアLANで、複数のPIM-SMルータをそれに接続するかもしれません。 これらのルータの単一の1つ(DR)はPIM-SMプロトコルに関する直接接続されたホストを代表して行動するでしょう。 独身のDRは、簡単な選挙プロセスを使用することでインタフェース(LANの、または、そうでない)単位で選出されます。
Fenner, et al. Standards Track [Page 5] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[5ページ]。
MRIB Multicast Routing Information Base. This is the multicast
topology table, which is typically derived from the unicast
routing table, or routing protocols such as Multiprotocol BGP
(MBGP) that carry multicast-specific topology information. In
PIM-SM, the MRIB is used to decide where to send Join/Prune
messages. A secondary function of the MRIB is to provide
routing metrics for destination addresses; these metrics are
used when sending and processing Assert messages.
MRIBマルチキャスト経路情報基地。 これは、マルチキャストトポロジーテーブル、またはマルチキャスト特有のトポロジー情報を運ぶMultiprotocol BGP(MBGP)などのルーティング・プロトコルです。(それは、ユニキャスト経路指定テーブルから通常得られます)。 PIM-SMでは、MRIBは、どこでJoin/プルーンにメッセージを送るかを決めるのに使用されます。 MRIBの二次的な機能はルーティング測定基準を送付先アドレスに提供することです。 Assertメッセージを送って、処理するとき、これらの測定基準は使用されています。
RPF Neighbor
RPF stands for "Reverse Path Forwarding". The RPF Neighbor of
a router with respect to an address is the neighbor that the
MRIB indicates should be used to forward packets to that
address. In the case of a PIM-SM multicast group, the RPF
neighbor is the router that a Join message for that group would
be directed to, in the absence of modifying Assert state.
RPF Neighbor RPFは「逆の経路推進」を表します。 アドレスに関するルータのRPF NeighborはMRIBがそのアドレスにパケットを送るのに使用されるべきであるのを示す隣接物です。 PIM-SMマルチキャストグループ、RPF隣人場合には、そのグループへのJoinメッセージが向けられるルータがあります、Assert状態を変更することが不在のとき。
TIB Tree Information Base. This is the collection of state at a
PIM router that has been created by receiving PIM Join/Prune
messages, PIM Assert messages, and Internet Group Management
Protocol (IGMP) or Multicast Listener Discovery (MLD)
information from local hosts. It essentially stores the state
of all multicast distribution trees at that router.
TIB木のInformation基地。 これはローカル・ホストからPIM Join/プルーンのメッセージ、PIM Assertメッセージ、およびインターネットGroup Managementプロトコル(IGMP)かMulticast Listenerディスカバリー(MLD)情報を受け取ることによって作成されたPIMルータにおける状態の収集です。 それはそのルータで本質的にはすべてのマルチキャスト分配木の状態を保存します。
MFIB Multicast Forwarding Information Base. The TIB holds all the
state that is necessary to forward multicast packets at a
router. However, although this specification defines
forwarding in terms of the TIB, to actually forward packets
using the TIB is very inefficient. Instead, a real router
implementation will normally build an efficient MFIB from the
TIB state to perform forwarding. How this is done is
implementation-specific and is not discussed in this document.
MFIBマルチキャスト推進Information基地。 TIBはすべてのルータでマルチキャストパケットを進めるのに必要な状態を保持します。 しかしながら、この仕様はTIBに関して推進を定義しますが、実際にTIBを使用することでパケットを進めるのは非常に効率が悪いです。 代わりに、通常、本当のルータ実装は、推進を実行するためにTIB状態から効率的なMFIBを造るでしょう。 これがどう完了しているかについて、実装特有であり、本書では議論しません。
Upstream
Towards the root of the tree. The root of tree may be either
the source or the RP, depending on the context.
木の根の上流のTowards。 文脈によって、木の根は、ソースかRPのどちらかであるかもしれません。
Downstream
Away from the root of the tree.
木の根からの川下のAway。
GenID Generation Identifier, used to detect reboots.
リブートを検出するのに使用されるGenID Generation Identifier。
PMBR PIM Multicast Border Router, joining a PIM domain with another
multicast domain.
別のマルチキャストドメインにPIMドメインを接合するPMBR PIM Multicast Border Router。
Fenner, et al. Standards Track [Page 6] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[6ページ]。
2.2. Pseudocode Notation
2.2. 擬似コード記法
We use set notation in several places in this specification.
私たちは方々にこの仕様でセット記法を使用します。
A (+) B is the union of two sets, A and B.
(+)Bは2人セット、A、およびBの組合です。
A (-) B is the elements of set A that are not in set B.
(-)BはセットBにないセットAの要素です。
NULL is the empty set or list.
NULLは空集合かリストです。
In addition, we use C-like syntax:
さらに、私たちはCのような構文を使用します:
= denotes assignment of a variable.
= 変数の課題を指示します。
== denotes a comparison for equality.
== 平等のための比較を指示します。
!= denotes a comparison for inequality.
=は不平等のための比較を指示します。
Braces { and } are used for grouping.
そして、歯列矯正器、組分けのために、使用されます。
3. PIM-SM Protocol Overview
3. PIM-Smプロトコル概観
This section provides an overview of PIM-SM behavior. It is intended as an introduction to how PIM-SM works, and it is NOT definitive. For the definitive specification, see Section 4.
このセクションはPIM-SMの振舞いの概観を提供します。 それは序論としてPIM-SMが働いて、どう決定的であるか意図しません。 決定的な仕様に関しては、セクション4を見てください。
PIM relies on an underlying topology-gathering protocol to populate a routing table with routes. This routing table is called the Multicast Routing Information Base (MRIB). The routes in this table may be taken directly from the unicast routing table, or they may be different and provided by a separate routing protocol such as MBGP [10]. Regardless of how it is created, the primary role of the MRIB in the PIM protocol is to provide the next-hop router along a multicast-capable path to each destination subnet. The MRIB is used to determine the next-hop neighbor to which any PIM Join/Prune message is sent. Data flows along the reverse path of the Join messages. Thus, in contrast to the unicast RIB, which specifies the next hop that a data packet would take to get to some subnet, the MRIB gives reverse-path information and indicates the path that a multicast data packet would take from its origin subnet to the router that has the MRIB.
PIMは、ルートがある経路指定テーブルに居住するために基本的なトポロジー集会プロトコルを当てにします。 この経路指定テーブルはMulticast経路情報基地(MRIB)と呼ばれます。 直接ユニキャスト経路指定テーブルからこのテーブルのルートを取るかもしれないか、それらを異なって、MBGP[10]などの別々のルーティング・プロトコルは提供するかもしれません。 それがどう作成されるかにかかわらず、PIMプロトコルのMRIBの第一の役割はマルチキャストできる経路に沿って次のホップルータをそれぞれの目的地サブネットに提供することです。 MRIBは、どんなPIM Join/プルーンのメッセージも送られる次のホップ隣人を決定するのに使用されます。 データはJoinメッセージの逆の経路に沿って流れます。 したがって、MRIBはユニキャストRIBと対照して逆経路情報を教えて、マルチキャストデータ・パケットが起源サブネットからMRIBを持っているルータまで取る経路を示します。RIBはデータ・パケットが何らかのサブネットを始めるために取る次のホップを指定します。
Like all multicast routing protocols that implement the service model from RFC 1112 [3], PIM-SM must be able to route data packets from sources to receivers without either the sources or receivers knowing a priori of the existence of the others. This is essentially done in three phases, although as senders and receivers may come and go at any time, all three phases may occur simultaneously.
RFC1112[3]からサービスモデルを実行するすべてのマルチキャストルーティング・プロトコルのように、PIM-SMは情報筋も先験的に他のものの存在を知っている受信機のどちらかなしでデータ・パケットをソースから受信機まで発送できなければなりません。 三相で本質的にはこれをします、送付者と受信機がいつでも来て、行くかもしれないのに従って、すべての三相が同時に、起こるかもしれませんが。
Fenner, et al. Standards Track [Page 7] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[7ページ]。
3.1. Phase One: RP Tree
3.1. フェーズ1: RP木
In phase one, a multicast receiver expresses its interest in receiving traffic destined for a multicast group. Typically, it does this using IGMP [2] or MLD [4], but other mechanisms might also serve this purpose. One of the receiver's local routers is elected as the Designated Router (DR) for that subnet. On receiving the receiver's expression of interest, the DR then sends a PIM Join message towards the RP for that multicast group. This Join message is known as a (*,G) Join because it joins group G for all sources to that group. The (*,G) Join travels hop-by-hop towards the RP for the group, and in each router it passes through, multicast tree state for group G is instantiated. Eventually, the (*,G) Join either reaches the RP or reaches a router that already has (*,G) Join state for that group. When many receivers join the group, their Join messages converge on the RP and form a distribution tree for group G that is rooted at the RP. This is known as the RP Tree (RPT), and is also known as the shared tree because it is shared by all sources sending to that group. Join messages are resent periodically so long as the receiver remains in the group. When all receivers on a leaf-network leave the group, the DR will send a PIM (*,G) Prune message towards the RP for that multicast group. However, if the Prune message is not sent for any reason, the state will eventually time out.
フェーズ1では、マルチキャスト受信機はマルチキャストグループのために運命づけられた交通を受けることへの関心を示します。 通常、IGMP[2]かMLD[4]を使用することでこれをしますが、また、他のメカニズムはこの目的に役立つかもしれません。 受信機のローカルルータの1つはそのサブネットのためのDesignated Router(DR)として選出されます。 そして、受信機の興味がある表現を受けると、DRはそのマルチキャストグループのためにPIM JoinメッセージをRPに向かって送ります。 そのグループへのすべてのソースをグループGと一緒に楽しむのでa(*、G)が接合するとき、このJoinメッセージは知られています。 (*、G)はグループのためにRPに向かったホップごとの旅行に参加します、そして、それが通り抜ける各ルータでは、グループGのためのマルチキャスト木の状態は例示されます。 (*、G)は接合します。結局、RPに達するか、またはそれで既にそのグループを州と一緒に楽しむ(*、G)ルータに達します。 多くの受信機がグループに加わるとき、それらのJoinメッセージは、RPに根づくグループGのために、RPに集まって、分配木を形成します。 これは、RP Tree(RPT)として知られていて、また、それがそのグループに発信するすべてのソースによって共有されるので、共有された木として知られています。 メッセージを接合してください。受信機がグループに残っている限り、定期的に再送します。 葉ネットワークのすべての受信機が仲間から抜けるとき、DRはそのマルチキャストグループのためにPIM(*、G)プルーンのメッセージをRPに向かって送るでしょう。 しかしながら、どんな理由でもPruneメッセージを送らないと、状態は結局タイムアウトを送るでしょう。
A multicast data sender just starts sending data destined for a multicast group. The sender's local router (DR) takes those data packets, unicast-encapsulates them, and sends them directly to the RP. The RP receives these encapsulated data packets, decapsulates them, and forwards them onto the shared tree. The packets then follow the (*,G) multicast tree state in the routers on the RP Tree, being replicated wherever the RP Tree branches, and eventually reaching all the receivers for that multicast group. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are known as PIM Register packets.
マルチキャストデータ送付者はただマルチキャストグループのために運命づけられたデータを送り始めます。 送付者のローカルルータ(DR)は、それらのデータ・パケットを連れて行って、それらをユニキャストで要約して、直接RPにそれらを送ります。 RPは共有された木にこれらの要約のデータ・パケットを受けて、それらをdecapsulatesして、それらを送ります。 次に、パケットはRP Treeの上のルータで(*、G)マルチキャスト木の状態に続きます、RP Treeがどこで分岐しても模写されて、結局そのマルチキャストグループのためのすべての受信機に達して。 データ・パケットをRPにカプセルに入れる過程は登録と呼ばれます、そして、カプセル化パケットはPIM Registerパケットとして知られています。
At the end of phase one, multicast traffic is flowing encapsulated to the RP, and then natively over the RP tree to the multicast receivers.
フェーズ1の終わりでは、マルチキャスト交通は、RPに要約された流れと、そして、マルチキャスト受信機へのRP木の上のネイティブです。
3.2. Phase Two: Register-Stop
3.2. フェーズTwo: レジスタ停止
Register-encapsulation of data packets is inefficient for two reasons:
データ・パケットのレジスタカプセル化は2つの理由で効率が悪いです:
o Encapsulation and decapsulation may be relatively expensive
operations for a router to perform, depending on whether or not the
router has appropriate hardware for these tasks.
o カプセル化と被膜剥離術はルータが実行する比較的高価な操作であるかもしれません、これらのタスクのためにルータには適切なハードウェアがあるかどうかによって。
Fenner, et al. Standards Track [Page 8] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[8ページ]。
o Traveling all the way to the RP, and then back down the shared tree
may result in the packets traveling a relatively long distance to
reach receivers that are close to the sender. For some
applications, this increased latency or bandwidth consumption is
undesirable.
o 送付者の近くにある受信機に達するように比較的長い距離を旅行するパケットをRP、および次に共有された木がもたらすかもしれない逆下になるまでのいっぱいに旅行します。 いくつかのアプリケーションにおいて、この増加する潜在か帯域幅消費が望ましくありません。
Although Register-encapsulation may continue indefinitely, for these reasons, the RP will normally choose to switch to native forwarding. To do this, when the RP receives a register-encapsulated data packet from source S on group G, it will normally initiate an (S,G) source- specific Join towards S. This Join message travels hop-by-hop towards S, instantiating (S,G) multicast tree state in the routers along the path. (S,G) multicast tree state is used only to forward packets for group G if those packets come from source S. Eventually the Join message reaches S's subnet or a router that already has (S,G) multicast tree state, and then packets from S start to flow following the (S,G) tree state towards the RP. These data packets may also reach routers with (*,G) state along the path towards the RP; if they do, they can shortcut onto the RP tree at this point.
Register-カプセル化はこれらの理由で無期限に続くかもしれませんが、通常、RPは、ネイティブの推進に切り替わるのを選ぶでしょう。 RPがグループGのソースSからレジスタで要約されたデータ・パケットを受けるとき、これをするために、通常、Sに向かったホップごとのS.This Joinメッセージ旅行に向かって(S、G)ソースの特定のJoinを開始するでしょう、経路に沿ってルータでマルチキャスト木の状態を例示して(S、G)。 (S、G) (S、G)木の状態にRPに向かって続いて、それらのパケットはS始めから流れにソースS.EventuallyからJoinメッセージ範囲Sのサブネットか既にマルチキャスト木の状態を持っている(S、G)ルータを来させて、次に、パケットを使用されるなら、マルチキャスト木の状態は使用されますが、グループGのためにパケットを進めます。 また、経路に沿って(*、G)状態がある状態で、これらのデータ・パケットはRPに向かってルータに達するかもしれません。 そうするなら、それらはここのRP木への近道をそうすることができます。
While the RP is in the process of joining the source-specific tree for S, the data packets will continue being encapsulated to the RP. When packets from S also start to arrive natively at the RP, the RP will be receiving two copies of each of these packets. At this point, the RP starts to discard the encapsulated copy of these packets, and it sends a Register-Stop message back to S's DR to prevent the DR from unnecessarily encapsulating the packets.
Sのためにソース特有の木に合流することの途中にRPがある間、データ・パケットは、RPに要約され続けるでしょう。 また、SからのパケットがネイティブにRPに到着し始めるとき、RPはそれぞれのこれらのパケットのコピー2部を受けるでしょう。 ここに、RPはこれらのパケットの要約のコピーを捨て始めます、そして、それはDRが不必要にパケットをカプセルに入れるのを防ぐためにRegister-停止メッセージをSのDRに送り返します。
At the end of phase 2, traffic will be flowing natively from S along a source-specific tree to the RP, and from there along the shared tree to the receivers. Where the two trees intersect, traffic may transfer from the source-specific tree to the RP tree and thus avoid taking a long detour via the RP.
フェーズ2の終わりでは、交通は共有された木に沿ってソース特有の木に沿ったSからRPまでそこから受信機にネイティブに流れるでしょう。 2本の木が交差しているところでは、交通は、ソース特有の木からRP木まで移して、その結果、RPを通して長い回り道を取るのを避けるかもしれません。
Note that a sender may start sending before or after a receiver joins the group, and thus phase two may happen before the shared tree to the receiver is built.
以前か受信機がグループに加わった後に送付者が、発信し始めるかもしれないことに注意してください。そうすれば、その結果、受信機への共有された木が組立している前にフェーズtwoは起こってもよいです。
3.3. Phase Three: Shortest-Path Tree
3.3. フェーズThree: 最短パス木
Although having the RP join back towards the source removes the encapsulation overhead, it does not completely optimize the forwarding paths. For many receivers, the route via the RP may involve a significant detour when compared with the shortest path from the source to the receiver.
RPに接合させますが、ソースに向かった後部はカプセル化オーバーヘッドを取り除いて、それは完全に推進経路を最適化するというわけではありません。 多くの受信機に関しては、ソースから受信機まで最短パスと比べると、RPを通したルートは重要な回り道を伴うかもしれません。
Fenner, et al. Standards Track [Page 9] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[9ページ]。
To obtain lower latencies or more efficient bandwidth utilization, a router on the receiver's LAN, typically the DR, may optionally initiate a transfer from the shared tree to a source-specific shortest-path tree (SPT). To do this, it issues an (S,G) Join towards S. This instantiates state in the routers along the path to S. Eventually, this join either reaches S's subnet or reaches a router that already has (S,G) state. When this happens, data packets from S start to flow following the (S,G) state until they reach the receiver.
下側の潜在か、より効率的な帯域幅利用を得るために、受信機のLANに関するルータ(通常DR)は任意に共有された木からソース特有の最短パス木(SPT)までの転送を起こすかもしれません。 (S、G)はS.に向かって接合します。これをしてください、と発行する、Thisは経路に沿ってルータでS.Eventuallyに状態を例示して、これは既に状態を持っている(S、G)範囲Sのサブネットか範囲aルータを接合します。 これが起こると、受信機に達するまで(S、G)状態に続いて、Sからのデータ・パケットは流れ始めます。
At this point, the receiver (or a router upstream of the receiver) will be receiving two copies of the data: one from the SPT and one from the RPT. When the first traffic starts to arrive from the SPT, the DR or upstream router starts to drop the packets for G from S that arrive via the RP tree. In addition, it sends an (S,G) Prune message towards the RP. This is known as an (S,G,rpt) Prune. The Prune message travels hop-by-hop, instantiating state along the path towards the RP indicating that traffic from S for G should NOT be forwarded in this direction. The prune is propagated until it reaches the RP or a router that still needs the traffic from S for other receivers.
ここに、受信機(または、受信機のルータ上流)はデータのコピー2部を受けるでしょう: SPTからの1とRPTからの1。 最初の交通がSPTから到着し始めるとき、DRか上流のルータがSからのGのためのRP木を通して到着するパケットを落とし始めます。 さらに、それは(S、G)プルーンのメッセージをRPに向かって送ります。 これは(S、G、rpt)プルーンとして知られています。 Pruneメッセージはホップごとに移動します、経路に沿ってGのためのSからの交通がこの方向に送られるべきでないのを示すRPに向かって状態を例示して。 まだ他の受信機のためのSからの交通を必要とするRPかルータに達するまで、プルーンは伝播されます。
By now, the receiver will be receiving traffic from S along the shortest-path tree between the receiver and S. In addition, the RP is receiving the traffic from S, but this traffic is no longer reaching the receiver along the RP tree. As far as the receiver is concerned, this is the final distribution tree.
今ごろ、受信機は最短パス木に沿って受信機とS.In添加の間にSからの交通を受けるでしょうが、RPはSからの交通を受けていますが、この交通はもうRP木に沿って受信機に達しないことです。 受信機に関する限り、これは最終的な分配木です。
3.4. Source-Specific Joins
3.4. ソース詳細は接合します。
IGMPv3 permits a receiver to join a group and specify that it only wants to receive traffic for a group if that traffic comes from a particular source. If a receiver does this, and no other receiver on the LAN requires all the traffic for the group, then the DR may omit performing a (*,G) join to set up the shared tree, and instead issue a source-specific (S,G) join only.
IGMPv3は、受信機が、仲間に入って、その交通が特定のソースから来る場合にだけグループのために交通を受けたがっていると指定するのを可能にします。 受信機がこれをして、LANで他のどんな受信機もグループのためにすべての交通を必要とするというわけではないなら、DRはa(*、G)が共有された木をセットアップするために接合する実行、および代わりにソース詳細(S、G)が接合する問題だけを省略するかもしれません。
The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is currently set aside for source-specific multicast in IPv4. For groups in this range, receivers should only issue source-specific IGMPv3 joins. If a PIM router receives a non-source-specific join for a group in this range, it should ignore it, as described in Section 4.8.
マルチキャストの範囲は232.0から.0を.0〜232.255に記述します。.255 現在、.255はIPv4のソース特有のマルチキャストのための傍らにセットです。 この範囲のグループのために、受信機はIGMPv3が接合するソース詳細を発行するだけであるはずです。 PIMルータが非ソースの詳細を受けるなら、この範囲のグループのために接合してください、そして、それを無視するべきです、セクション4.8で説明されるように。
Fenner, et al. Standards Track [Page 10] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[10ページ]。
3.5. Source-Specific Prunes
3.5. ソース特有のプルーン
IGMPv3 also permits a receiver to join a group and to specify that it only wants to receive traffic for a group if that traffic does not come from a specific source or sources. In this case, the DR will perform a (*,G) join as normal, but may combine this with an (S,G,rpt) prune for each of the sources the receiver does not wish to receive.
また、IGMPv3は、受信機が、仲間に入って、その交通が特定のソースかソースから来ない場合にだけグループのために交通を受けたがっていると指定するのを可能にします。 この場合、DRはa(*、G)を実行するでしょう。標準として接合しますが、受信機が受け取りたがっていないそれぞれの源のために(S、G、rpt)プルーンにこれを結合するかもしれません。
3.6. Multi-Access Transit LANs
3.6. マルチアクセス輸送機関LAN
The overview so far has concerned itself with point-to-point transit links. However, using multi-access LANs such as Ethernet for transit is not uncommon. This can cause complications for three reasons:
今までのところの概観は二地点間トランジットリンクに携わりました。 しかしながら、トランジットのためのイーサネットなどのマルチアクセスLANを使用するのは珍しくはありません。 これは3つの理由で複雑さを引き起こす場合があります:
o Two or more routers on the LAN may issue (*,G) Joins to different
upstream routers on the LAN because they have inconsistent MRIB
entries regarding how to reach the RP. Both paths on the RP tree
will be set up, causing two copies of all the shared tree traffic
to appear on the LAN.
o どうRPに達するかに関してそれらには無節操なMRIBエントリーがあるので、LANに関するルータが発行するかもしれない2(*、G)以上はLANで異なった上流のルータにつなぎます。 RP木の上の両方の経路はセットアップされるでしょう、すべての共有された木の交通のコピー2部がLANに現れることを引き起こして。
o Two or more routers on the LAN may issue (S,G) Joins to different
upstream routers on the LAN because they have inconsistent MRIB
entries regarding how to reach source S. Both paths on the source-
specific tree will be set up, causing two copies of all the traffic
from S to appear on the LAN.
o ソースS.Bothに達するように、ソースの特定の木の上の経路がどうセットアップされるかに関してそれらには無節操なMRIBエントリーがあるので、LANに関するルータが発行するかもしれない2(S、G)以上はLANで異なった上流のルータにつなぎます、Sからのすべての交通のコピー2部がLANに現れることを引き起こして。
o A router on the LAN may issue a (*,G) Join to one upstream router
on the LAN, and another router on the LAN may issue an (S,G) Join
to a different upstream router on the same LAN. Traffic from S may
reach the LAN over both the RPT and the SPT. If the receiver
behind the downstream (*,G) router doesn't issue an (S,G,rpt)
prune, then this condition would persist.
o LANに関するルータが(*、G)がLANに関する、ある上流のルータに接合して、LANに関する別のルータが発行するかもしれないaを発行するかもしれない、(S、G)は同じLANで異なった上流のルータにつなぎます。 Sからの交通はRPTとSPTの両方の上でLANに達するかもしれません。 川下(*、G)のルータの後ろの受信機が(S、G、rpt)プルーンを発行しないなら、この状態は持続しているでしょう。
All of these problems are caused by there being more than one upstream router with join state for the group or source-group pair. PIM does not prevent such duplicate joins from occurring; instead, when duplicate data packets appear on the LAN from different routers, these routers notice this and then elect a single forwarder. This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router that has (S,G) state; or, if neither or both router has (S,G) state, then the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source to source-specific trees.
これらの問題のすべてが1つ以上の上流のルータであるのでそこによって引き起こされる、グループかソースグループ組のために状態に加わってください。 PIMは、写しが接合するそのようなものが起こるのを防ぎません。 代わりに、重複データパケットがLANに異なったルータから現れるとき、これらのルータは、これに気付いて、次に、独身の混載業者を選出します。 この選挙は状態を持っている(S、G)上流のルータを支持して問題を解決するPIM Assertメッセージを使用することで実行されます。 または、ルータには、状態がどちらも両方であるならあって(S、G)、次に、問題はRP木における、RPへのメートル法のベスト、またはソースにおける、ソース特有の木へのメートル法のベストがあるルータを支持して解決されています。
These Assert messages are also received by the downstream routers on the LAN, and these cause subsequent Join messages to be sent to the upstream router that won the Assert.
また、LANに川下のルータでこれらのAssertメッセージを受け取ります、そして、これらはAssertを獲得した上流のルータに送られるべきその後のJoinメッセージを引き起こします。
Fenner, et al. Standards Track [Page 11] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[11ページ]。
3.7. RP Discovery
3.7. RP発見
PIM-SM routers need to know the address of the RP for each group for which they have (*,G) state. This address is obtained automatically (e.g., embedded-RP), through a bootstrap mechanism, or through static configuration.
PIM-SMルータは、それらには状態がある(*、G)各グループでRPのアドレスを知る必要があります。 自動的(例えば、-RPを埋め込む)にこのアドレスを得て、aを通してメカニズムを独力で進むか、または静的な構成を通して。
One dynamic way to do this is to use the Bootstrap Router (BSR) mechanism [11]. One router in each PIM domain is elected the Bootstrap Router through a simple election process. All the routers in the domain that are configured to be candidates to be RPs periodically unicast their candidacy to the BSR. From the candidates, the BSR picks an RP-set, and periodically announces this set in a Bootstrap message. Bootstrap messages are flooded hop-by- hop throughout the domain until all routers in the domain know the RP-Set.
これをする1つのダイナミックな方法はBootstrap Router(BSR)メカニズム[11]を使用することです。 それぞれのPIMドメインの1つのルータが簡単な選挙の過程でBootstrap Routerに選出されます。 それが定期的のRPsである候補がユニキャストであったなら構成されるドメインのすべてのルータ、BSRへの彼らの立候補。 候補から、BSRはRP-セットを選んで、Bootstrapメッセージでこのセットを定期的に発表します。 独力で進んでください。そのドメインのすべてのルータがRP-セットを知るまで、メッセージはドメイン中の近く水につかっている跳びホップです。
To map a group to an RP, a router hashes the group address into the RP-set using an order-preserving hash function (one that minimizes changes if the RP-Set changes). The resulting RP is the one that it uses as the RP for that group.
グループをRPに写像するために、ルータはオーダーを保存するハッシュ関数(RP-場面の転換であるなら変化を最小にするもの)を使用することでRP-セットにグループアドレスを論じ尽くします。 それのためのRPが分類するとき、結果として起こるRPはそれが使用するものです。
4. Protocol Specification
4. プロトコル仕様
The specification of PIM-SM is broken into several parts:
数個の部品がPIM-SMの仕様に細かく分けられます:
o Section 4.1 details the protocol state stored.
o セクション4.1は州が格納したプロトコルを詳しく述べます。
o Section 4.2 specifies the data packet forwarding rules.
o セクション4.2はデータ・パケット推進規則を指定します。
o Section 4.3 specifies Designated Router (DR) election and the rules
for sending and processing Hello messages.
o セクション4.3はDesignated Router(DR)選挙と規則を発信と処理Helloメッセージに指定します。
o Section 4.4 specifies the PIM Register generation and processing
rules.
o セクション4.4はPIM Register世代と処理規則を指定します。
o Section 4.5 specifies the PIM Join/Prune generation and processing
rules.
o セクション4.5はPIM Join/プルーンの世代と処理規則を指定します。
o Section 4.6 specifies the PIM Assert generation and processing
rules.
o セクション4.6はPIM Assert世代と処理規則を指定します。
o Section 4.7 specifies the RP discovery mechanisms.
o セクション4.7はRP発見メカニズムを指定します。
o The subset of PIM required to support Source-Specific Multicast,
PIM-SSM, is described in Section 4.8.
o Source特有のMulticastを支持しなければならなかったPIMの部分集合(PIM-SSM)はセクション4.8で説明されます。
o PIM packet formats are specified in Section 4.9.
o PIMパケット・フォーマットはセクション4.9で指定されます。
Fenner, et al. Standards Track [Page 12] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[12ページ]。
o A summary of PIM-SM timers and their default values is given in
Section 4.10.
o セクション4.10でPIM-SMタイマとそれらのデフォルト値の概要をします。
o Appendix A specifies the PIM Multicast Border Router behavior.
o 付録AはPIM Multicast Border Routerの振舞いを指定します。
4.1. PIM Protocol State
4.1. PIMプロトコル状態
This section specifies all the protocol state that a PIM implementation should maintain in order to function correctly. We term this state the Tree Information Base (TIB), as it holds the state of all the multicast distribution trees at this router. In this specification, we define PIM mechanisms in terms of the TIB. However, only a very simple implementation would actually implement packet forwarding operations in terms of this state. Most implementations will use this state to build a multicast forwarding table, which would then be updated when the relevant state in the TIB changes.
このセクションはPIM実現が正しく機能するように維持するべきであるすべてのプロトコル状態を指定します。 私たち、これがTree Information基地(TIB)を述べる用語、持ちこたえるとき、すべてのマルチキャスト分配の状態はこのルータで木に登られます。 この仕様では、私たちはTIBに関してPIMメカニズムを定義します。 しかしながら、非常に簡単な実現だけが実際にこの状態に関してパケット推進操作を実行するでしょう。 ほとんどの実現が、マルチキャスト推進テーブルを組立てるのにこの状態を使用するでしょう。(次に、TIBの関連状態が変化するとき、テーブルはアップデートされるでしょう)。
Although we specify precisely the state to be kept, this does not mean that an implementation of PIM-SM needs to hold the state in this form. This is actually an abstract state definition, which is needed in order to specify the router's behavior. A PIM-SM implementation is free to hold whatever internal state it requires and will still be conformant with this specification so long as it results in the same externally visible protocol behavior as an abstract router that holds the following state.
私たちは保たれるために正確に状態を指定しますが、これは、PIM-SMの実現が、このフォームに状態を保持する必要を意味しません。 これは実際に抽象的な州の定義です。(その定義が、ルータの振舞いを指定するのに必要です)。 以下の状態を保持する抽象的なルータと同じ外部的に目に見えるプロトコルの振舞いをもたらす限り、PIM-SM実現は、それが必要とするどんな内部の状態も保持するのにおいて自由であり、まだこの仕様をもってconformantになっているでしょう。
We divide TIB state into four sections:
私たちはTIB状態を4つのセクションに分割します:
(*,*,RP) state
State that maintains per-RP trees, for all groups served by a
given RP.
(*、*、RP)は与えられたRPによって役立たれたすべてのグループのために1RPあたりの木を維持する州を述べます。
(*,G) state
State that maintains the RP tree for G.
(*、G)はGのためにRP木を維持する州を述べます。
(S,G) state
State that maintains a source-specific tree for source S and
group G.
(S、G)はソースSとグループGのためにソース特有の木を維持する州を述べます。
(S,G,rpt) state
State that maintains source-specific information about source S
on the RP tree for G. For example, if a source is being
received on the source-specific tree, it will normally have been
pruned off the RP tree. This prune state is (S,G,rpt) state.
(S、G、rpt) ソース特有の木の上にソースを受け取っているならG.Forの例のためのRP木の上のソースSに関するソース特殊情報を維持する州の州、通常、それはRP木で剪定されてしまうでしょう。 このプルーンの状態は(S、G、rpt)状態です。
Fenner, et al. Standards Track [Page 13] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[13ページ]。
The state that should be kept is described below. Of course, implementations will only maintain state when it is relevant to forwarding operations; for example, the "NoInfo" state might be assumed from the lack of other state information rather than being held explicitly.
維持されるべきである状態は以下で説明されます。 もちろん、それが推進操作に関連しているときだけ、実現は状態を維持するでしょう。 例えば、"NoInfo"状態は明らかに保持されるより他の州の情報の不足からむしろ想定されるかもしれません。
4.1.1. General Purpose State
4.1.1. 汎用の状態
A router holds the following non-group-specific state:
ルータは以下の非グループの詳細状態を保持します:
For each interface:
それぞれに関しては、連結してください:
o Effective Override Interval
o 有効なオーバーライド間隔
o Effective Propagation Delay
o 有効な伝播遅延
o Suppression state: One of {"Enable", "Disable"}
o 抑圧州: 1つ「無能にする」「可能にする」
Neighbor State:
隣人州:
For each neighbor:
各隣人のために:
o Information from neighbor's Hello
o 隣人のHelloからの情報
o Neighbor's GenID.
o 隣人のGenID。
o Neighbor Liveness Timer (NLT)
o 隣人活性タイマ(NLT)
Designated Router (DR) State:
代表ルータ(DR)州:
o Designated Router's IP Address
o 代表ルータのIPアドレス
o DR's DR Priority
o DRのDR優先権
The Effective Override Interval, the Effective Propagation Delay and the Interface suppression state are described in Section 4.3.3. Designated Router state is described in Section 4.3.
Effective Override Interval、Effective Propagation Delay、およびInterface抑圧状態はセクション4.3.3で説明されます。 指定されたRouter状態はセクション4.3で説明されます。
Fenner, et al. Standards Track [Page 14] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[14ページ]。
4.1.2. (*,*,RP) State
4.1.2. (*、*、RP) 状態
For every RP, a router keeps the following state:
あらゆるRPに関しては、ルータは以下の状態を維持します:
(*,*,RP) state:
For each interface:
(*、*、RP) 州: それぞれに関しては、連結してください:
PIM (*,*,RP) Join/Prune State:
PIM(*、*、RP)は状態を加わるか、または剪定します:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o 州: 1つ(J)、「未定のプルーン」(pp)を"NoInfo"(Ni)は「接合します」。
o Prune-Pending Timer (PPT)
o 未定のプルーンのタイマ(PPT)
o Join/Prune Expiry Timer (ET)
o 満期タイマから接合するか、または余計なものを取り除いてください。(ET)
Not interface specific:
インタフェース特有でない:
Upstream (*,*,RP) Join/Prune State:
上流(*、*、RP)は、状態を加わるか、または剪定します:
o State: One of {"NotJoined(*,*,RP)",
"Joined(*,*,RP)"}
o 州: 1つ「NotJoined(*、*、RP)」は「(*、*、RP)を接合しました」。
o Upstream Join/Prune Timer (JT)
o 上流は、タイマから接合するか、または余計なものを取り除きます。(JT)
o Last RPF Neighbor towards RP that was used
o 使用されたRPに向かった最後のRPF Neighbor
PIM (*,*,RP) Join/Prune state is the result of receiving PIM (*,*,RP) Join/Prune messages on this interface and is specified in Section 4.5.1.
PIM(*、*、RP)は状態を加わるか、または剪定します。PIMを受けるという(*、*、RP)がこのインタフェースに関するメッセージを接合するか、または剪定するという結果であり、セクション4.5.1で指定されます。
The upstream (*,*,RP) Join/Prune State reflects the state of the upstream (*,*,RP) state machine described in Section 4.5.5.
上流(*、*、RP)は、州を加わるか、または剪定します。セクション4.5.5で説明された上流(*、*、RP)州のマシンの状態を反映します。
The upstream (*,*,RP) Join/Prune Timer is used to send out periodic Join(*,*,RP) messages, and to override Prune(*,*,RP) messages from peers on an upstream LAN interface.
上流(*、*、RP)は、周期的なJoin(*、*、RP)メッセージを出して、上流のLANインタフェースで同輩からのPrune(*、*、RP)メッセージに優越するために使用されるTimerから接合するか、または余計なものを取り除きます。
The last RPF neighbor towards the RP is stored because if the MRIB changes, then the RPF neighbor towards the RP may change. If it does so, then we need to trigger a new Join(*,*,RP) to the new upstream neighbor and a Prune(*,*,RP) to the old upstream neighbor. Similarly, if a router detects through a changed GenID in a Hello message that the upstream neighbor towards the RP has rebooted, then it should re-instantiate state by sending a Join(*,*,RP). These mechanisms are specified in Section 4.5.5.
MRIBが変化するならRPに向かったRPF隣人が変化するかもしれないので、RPに向かった最後のRPF隣人は格納されます。 それがそうするなら、私たちは、新しい上流の隣人への新しいJoin(*、*、RP)と年取った上流の隣人へのPrune(*、*、RP)の引き金となる必要があります。 同様に、ルータがHelloに変えられたGenIDを通してRPに向かった上流の隣人がリブートしたというメッセージを検出するなら、それは、Join(*、*、RP)を送ることによって、状態を再例示するべきです。 これらのメカニズムはセクション4.5.5で指定されます。
Fenner, et al. Standards Track [Page 15] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[15ページ]。
4.1.3. (*,G) State
4.1.3. (*、G) 状態
For every group G, a router keeps the following state:
あらゆるグループGのために、ルータは以下の状態を維持します:
(*,G) state:
For each interface:
(*、G) 州: それぞれに関しては、連結してください:
Local Membership:
State: One of {"NoInfo", "Include"}
地方の会員資格: 州: 1つ"NoInfo"、「包含」
PIM (*,G) Join/Prune State:
PIM(*、G)は状態を加わるか、または剪定します:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o 州: 1つ(J)、「未定のプルーン」(pp)を"NoInfo"(Ni)は「接合します」。
o Prune-Pending Timer (PPT)
o 未定のプルーンのタイマ(PPT)
o Join/Prune Expiry Timer (ET)
o 満期タイマから接合するか、または余計なものを取り除いてください。(ET)
(*,G) Assert Winner State
(*、G)は勝者状態について断言します。
o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)}
o 州: 1つ"NoInfo"(NI)、「私はAssertをなくした」という(L)、「私はAssertを獲得した」という(W)
o Assert Timer (AT)
o タイマについて断言してください。(AT)
o Assert winner's IP Address (AssertWinner)
o 勝者のIP Addressについて断言してください。(AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric)
o 勝者のAssert Metricについて断言してください。(AssertWinnerMetric)
Not interface specific:
インタフェース特有でない:
Upstream (*,G) Join/Prune State:
上流(*、G)は、状態を加わるか、または剪定します:
o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
o 州: 1つ「NotJoined(*、G)」は「(*、G)を接合しました」。
o Upstream Join/Prune Timer (JT)
o 上流は、タイマから接合するか、または余計なものを取り除きます。(JT)
o Last RP Used
o 使用される最後のRP
o Last RPF Neighbor towards RP that was used
o 使用されたRPに向かった最後のRPF Neighbor
Local membership is the result of the local membership mechanism (such as IGMP or MLD) running on that interface. It need not be kept if this router is not the DR on that interface unless this router won a (*,G) assert on this interface for this group, although implementations may optionally keep this state in case they become the DR or assert winner. We recommend storing this information if
地方の会員資格はそのインタフェースで走るローカルの会員資格メカニズム(IGMPかMLDなどの)の結果です。 それは彼らがDRになるといけないか、または勝者について断言するといけないので実現が任意にそうするかもしれませんが、ウォンa(*、G)がこのグループのためにこのインタフェースで断言するこのルータがこの状態を維持しないならこのルータがそのインタフェースのDRでないなら保たれる必要はありません。 私たちは、この情報を格納することを勧めます。
Fenner, et al. Standards Track [Page 16] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[16ページ]。
possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(*,G) macro described in Section 4.1.6.
_可能です、DRこの情報の変化を引き起こす失敗がpimによって使用された後に安定作業条件に一点に集まるレイテンシを減少させるように、セクション4.1.6で説明されたマクロを含めてください(*、G)。
PIM (*,G) Join/Prune state is the result of receiving PIM (*,G) Join/Prune messages on this interface and is specified in Section 4.5.2. The state is used by the macros that calculate the outgoing interface list in Section 4.1.6, and in the JoinDesired(*,G) macro (defined in Section 4.5.6) that is used in deciding whether a Join(*,G) should be sent upstream.
PIM(*、G)は状態を加わるか、または剪定します。PIMを受けるという(*、G)がこのインタフェースに関するメッセージを接合するか、または剪定するという結果であり、セクション4.5.2で指定されます。 状態はセクション4.1.6、およびJoin(*、G)が上流へ送られるべきであるかどうか決める際に使用されるJoinDesired(*、G)マクロ(セクション4.5.6では、定義される)で送信するインタフェースリストについて計算するマクロによって使用されます。
(*,G) Assert Winner state is the result of sending or receiving (*,G) Assert messages on this interface. It is specified in Section 4.6.2.
(*、G)が、Winner状態が発信するという結果であると断言するか、または受信して、(*、G)はこのインタフェースでメッセージについて断言します。 それはセクション4.6.2で指定されます。
The upstream (*,G) Join/Prune State reflects the state of the upstream (*,G) state machine described in Section 4.5.6.
上流(*、G)は、州を加わるか、または剪定します。セクション4.5.6で説明された上流(*、G)州のマシンの状態を反映します。
The upstream (*,G) Join/Prune Timer is used to send out periodic Join(*,G) messages, and to override Prune(*,G) messages from peers on an upstream LAN interface.
上流(*、G)は、周期的なJoin(*、G)メッセージを出して、上流のLANインタフェースで同輩からのPrune(*、G)メッセージに優越するために使用されるTimerから接合するか、または余計なものを取り除きます。
The last RP used must be stored because if the RP-Set changes (Section 4.7), then state must be torn down and rebuilt for groups whose RP changes.
状態はRP-場面の転換(セクション4.7)であるならRP変化を引き裂かれて、グループのために再建しなければならないので、RPが使用した最終を格納しなければなりません。
The last RPF neighbor towards the RP is stored because if the MRIB changes, then the RPF neighbor towards the RP may change. If it does so, then we need to trigger a new Join(*,G) to the new upstream neighbor and a Prune(*,G) to the old upstream neighbor. Similarly, if a router detects through a changed GenID in a Hello message that the upstream neighbor towards the RP has rebooted, then it should re-instantiate state by sending a Join(*,G). These mechanisms are specified in Section 4.5.6.
MRIBが変化するならRPに向かったRPF隣人が変化するかもしれないので、RPに向かった最後のRPF隣人は格納されます。 それがそうするなら、私たちは、新しい上流の隣人への新しいJoin(*、G)と年取った上流の隣人へのPrune(*、G)の引き金となる必要があります。 同様に、ルータがHelloに変えられたGenIDを通してRPに向かった上流の隣人がリブートしたというメッセージを検出するなら、それは、Join(*、G)を送ることによって、状態を再例示するべきです。 これらのメカニズムはセクション4.5.6で指定されます。
4.1.4. (S,G) State
4.1.4. (S、G) 状態
For every source/group pair (S,G), a router keeps the following state:
すべてのソース/グループ組(S、G)のために、ルータは以下の状態を維持します:
(S,G) state:
(S、G) 州:
For each interface:
それぞれに関しては、連結してください:
Local Membership:
State: One of {"NoInfo", "Include"}
地方の会員資格: 州: 1つ"NoInfo"、「包含」
Fenner, et al. Standards Track [Page 17] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[17ページ]。
PIM (S,G) Join/Prune State:
PIM(S、G)は状態を加わるか、または剪定します:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o 州: 1つ(J)、「未定のプルーン」(pp)を"NoInfo"(Ni)は「接合します」。
o Prune-Pending Timer (PPT)
o 未定のプルーンのタイマ(PPT)
o Join/Prune Expiry Timer (ET)
o 満期タイマから接合するか、または余計なものを取り除いてください。(ET)
(S,G) Assert Winner State
(S、G)は勝者状態について断言します。
o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)}
o 州: 1つ"NoInfo"(NI)、「私はAssertをなくした」という(L)、「私はAssertを獲得した」という(W)
o Assert Timer (AT)
o タイマについて断言してください。(AT)
o Assert winner's IP Address (AssertWinner)
o 勝者のIP Addressについて断言してください。(AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric)
o 勝者のAssert Metricについて断言してください。(AssertWinnerMetric)
Not interface specific:
インタフェース特有でない:
Upstream (S,G) Join/Prune State:
上流(S、G)は、状態を加わるか、または剪定します:
o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
o 州: 1つ「NotJoined(S、G)」は「(S、G)を接合しました」。
o Upstream (S,G) Join/Prune Timer (JT)
o 上流(S、G)は、タイマから接合するか、または余計なものを取り除きます。(JT)
o Last RPF Neighbor towards S that was used
o 使用されたSに向かった最後のRPF Neighbor
o SPTbit (indicates (S,G) state is active)
o SPTbit(状態が活動的であることを示します(S、G))
o (S,G) Keepalive Timer (KAT)
o (S、G) Keepaliveタイマ(カット)
Additional (S,G) state at the DR:
DRの追加している(S、G)州:
o Register state: One of {"Join" (J), "Prune" (P),
"Join-Pending" (JP), "NoInfo" (NI)}
o 状態を示してください: 1つ(J)、「プルーン」(p)を「接合する」、「接合、-、未定である、」 (JP)、"NoInfo"(Ni)
o Register-Stop timer
o レジスタ停止タイマ
Additional (S,G) state at the RP:
RPの追加している(S、G)州:
o PMBR: the first PMBR to send a Register for this
source with the Border bit set.
o PMBR: BorderビットでこのソースにRegisterを送る最初のPMBRはセットしました。
Fenner, et al. Standards Track [Page 18] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[18ページ]。
Local membership is the result of the local source-specific membership mechanism (such as IGMP version 3) running on that interface and specifying that this particular source should be included. As stored here, this state is the resulting state after any IGMPv3 inconsistencies have been resolved. It need not be kept if this router is not the DR on that interface unless this router won a (S,G) assert on this interface for this group. However, we recommend storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(S,G) macro described in Section 4.1.6.
地方の会員資格はそのインタフェースで走って、この特定のソースが含まれるべきであると指定するローカルのソース特有の会員資格メカニズム(IGMPバージョン3などの)の結果です。 ここに格納されるように、どんなIGMPv3矛盾も決議された後にこの状態は結果として起こる状態です。 それはこのルータがa(S、G)に勝たなかったならこのルータがそのインタフェースのDRでないなら保たれる必要はありません。このインタフェースでは、このグループのために、断言します。 _しかしながら、私たちは、できれば、この情報を格納することを勧めて、DRこの情報の変化を引き起こす失敗がpimによって使用された後に安定作業条件に一点に集まるレイテンシを減少させるようにセクション4.1.6で説明されたマクロを入れてください(S、G)。
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) Join/Prune messages on this interface and is specified in Section 4.5.2. The state is used by the macros that calculate the outgoing interface list in Section 4.1.6, and in the JoinDesired(S,G) macro (defined in Section 4.5.7) that is used in deciding whether a Join(S,G) should be sent upstream.
PIM(S、G)は状態を加わるか、または剪定します。PIMを受けるという(S、G)がこのインタフェースに関するメッセージを接合するか、または剪定するという結果であり、セクション4.5.2で指定されます。 状態はセクション4.1.6、およびJoin(S、G)が上流へ送られるべきであるかどうか決める際に使用されるJoinDesired(S、G)マクロ(セクション4.5.7では、定義される)で送信するインタフェースリストについて計算するマクロによって使用されます。
(S,G) Assert Winner state is the result of sending or receiving (S,G) Assert messages on this interface. It is specified in Section 4.6.1.
(S、G)が、Winner状態が発信するという結果であると断言するか、または受信して、(S、G)はこのインタフェースでメッセージについて断言します。 それはセクション4.6.1で指定されます。
The upstream (S,G) Join/Prune State reflects the state of the upstream (S,G) state machine described in Section 4.5.7.
上流(S、G)は、州を加わるか、または剪定します。セクション4.5.7で説明された上流(S、G)州のマシンの状態を反映します。
The upstream (S,G) Join/Prune Timer is used to send out periodic Join(S,G) messages, and to override Prune(S,G) messages from peers on an upstream LAN interface.
上流(S、G)は、周期的なJoin(S、G)メッセージを出して、上流のLANインタフェースで同輩からのPrune(S、G)メッセージに優越するために使用されるTimerから接合するか、または余計なものを取り除きます。
The last RPF neighbor towards S is stored because if the MRIB changes, then the RPF neighbor towards S may change. If it does so, then we need to trigger a new Join(S,G) to the new upstream neighbor and a Prune(S,G) to the old upstream neighbor. Similarly, if the router detects through a changed GenID in a Hello message that the upstream neighbor towards S has rebooted, then it should re- instantiate state by sending a Join(S,G). These mechanisms are specified in Section 4.5.7.
MRIBが変化するならSに向かったRPF隣人が変化するかもしれないので、Sに向かった最後のRPF隣人は格納されます。 それがそうするなら、私たちは、新しい上流の隣人への新しいJoin(S、G)と年取った上流の隣人へのPrune(S、G)の引き金となる必要があります。 同様に、ルータがHelloに変えられたGenIDを通してSに向かった上流の隣人がリブートしたというメッセージを検出するなら、それは、Join(S、G)を送ることによって、状態を再例示するべきです。 これらのメカニズムはセクション4.5.7で指定されます。
The SPTbit is used to indicate whether forwarding is taking place on the (S,G) Shortest Path Tree (SPT) or on the (*,G) tree. A router can have (S,G) state and still be forwarding on (*,G) state during the interval when the source-specific tree is being constructed. When SPTbit is FALSE, only (*,G) forwarding state is used to forward packets from S to G. When SPTbit is TRUE, both (*,G) and (S,G) forwarding state are used.
SPTbitは、推進が(S、G)最も短いPath Tree(SPT)の上、または、(*、G)木の上で行われているかどうかを示すのに使用されます。 ルータは、状態を持って(S、G)、ソース特有の木が組み立てられる予定である間隔の間、(*、G)でまだ状態を進めることができます。 SPTbitがFALSEであるときに、唯一の推進状態がSからG.When SPTbitまでパケットを進めるのに使用されているのが、TRUEであるということである、状態を進める(*、G)と(S、G)の両方が使用されています。
Fenner, et al. Standards Track [Page 19] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[19ページ]。
The (S,G) Keepalive Timer is updated by data being forwarded using this (S,G) forwarding state. It is used to keep (S,G) state alive in the absence of explicit (S,G) Joins. Amongst other things, this is necessary for the so-called "turnaround rules" -- when the RP uses (S,G) joins to stop encapsulation, and then (S,G) prunes to prevent traffic from unnecessarily reaching the RP.
状態を進めながらこれ(S、G)を使用することで転送されるデータは(S、G)Keepalive Timerをアップデートします。 それは、明白が不在のとき継続している州(S、G)が合流する(S、G)を保つのに使用されます。 他のものの中では、これがいわゆる「ターンアラウンド規則」に必要です--RP用途であるときに、(S、G)は、交通が不必要にRPに達するのを防ぐために停止カプセル化、および次に(S、G)、プルーンに接合します。
On a DR, the (S,G) Register State is used to keep track of whether to encapsulate data to the RP on the Register Tunnel; the (S,G) Register-Stop timer tracks how long before encapsulation begins again for a given (S,G).
DRでは、(S、G)レジスタ州はRegister Tunnelの上のRPにデータを要約するかどうかに関する道を保つのに使用されます。 カプセル化が当然のこと(S、G)のためにやり直す前に(S、G)レジスタ停止タイマはどれくらい長い間、追跡されるか。
On an RP, the PMBR value must be cleared when the Keepalive Timer expires.
Keepalive Timerが期限が切れるとき、RPでは、PMBR値を精算しなければなりません。
4.1.5. (S,G,rpt) State
4.1.5. (S、G、rpt) 状態
For every source/group pair (S,G) for which a router also has (*,G) state, it also keeps the following state:
また、またルータには状態がある(*、G)すべてのソース/グループ組(S、G)のために、以下の状態を維持します:
(S,G,rpt) state:
(S、G、rpt) 州:
For each interface:
それぞれに関しては、連結してください:
Local Membership:
State: One of {"NoInfo", "Exclude"}
地方の会員資格: 州: 1つ"NoInfo"、「除外」
PIM (S,G,rpt) Join/Prune State:
PIM(S、G、rpt)は状態を加わるか、または剪定します:
o State: One of {"NoInfo", "Pruned", "Prune-
Pending"}
o 州: 1つ「剪定された」「プルーンの未定」の"NoInfo"
o Prune-Pending Timer (PPT)
o 未定のプルーンのタイマ(PPT)
o Join/Prune Expiry Timer (ET)
o 満期タイマから接合するか、または余計なものを取り除いてください。(ET)
Not interface specific:
インタフェース特有でない:
Upstream (S,G,rpt) Join/Prune State:
上流(S、G、rpt)は、状態を加わるか、または剪定します:
o State: One of {"RPTNotJoined(G)",
"NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"}
o 州: 1つ「NotPruned(S、G、rpt)」という"RPTNotJoined(G)"は「(S、G、rpt)を剪定しました」。
o Override Timer (OT)
o オーバーライドタイマ(OT)
Local membership is the result of the local source-specific membership mechanism (such as IGMPv3) running on that interface and specifying that although there is (*,G) Include state, this
地方の会員資格は(*、G)がありますが、状態を含んでいるそのインタフェースと指定で走るローカルのソース特有の会員資格メカニズム(IGMPv3などの)の結果です、これ
Fenner, et al. Standards Track [Page 20] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[20ページ]。
particular source should be excluded. As stored here, this state is the resulting state after any IGMPv3 inconsistencies between LAN members have been resolved. It need not be kept if this router is not the DR on that interface unless this router won a (*,G) assert on this interface for this group. However, we recommend storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_exclude(S,G) macro described in Section 4.1.6.
特定のソースは除かれるべきです。 ここに格納されるように、LANメンバーの間のどんなIGMPv3矛盾も決議された後にこの状態は結果として起こる状態です。 それはこのルータがa(*、G)に勝たなかったならこのルータがそのインタフェースのDRでないなら保たれる必要はありません。このインタフェースでは、このグループのために、断言します。 _しかしながら、私たちは、できれば、この情報を格納することを勧めて、DRこの情報の変化を引き起こす失敗がpimによって使用された後に安定作業条件に一点に集まるレイテンシを減少させるようにセクション4.1.6で説明されたマクロを除いてください(S、G)。
PIM (S,G,rpt) Join/Prune state is the result of receiving PIM (S,G,rpt) Join/Prune messages on this interface and is specified in Section 4.5.4. The state is used by the macros that calculate the outgoing interface list in Section 4.1.6, and in the rules for adding Prune(S,G,rpt) messages to Join(*,G) messages specified in Section 4.5.8.
PIM(S、G、rpt)は状態を加わるか、または剪定します。PIMを受けるという(S、G、rpt)がこのインタフェースに関するメッセージを接合するか、または剪定するという結果であり、セクション4.5.4で指定されます。 状態はセクション4.5.8で指定されたJoin(*、G)メッセージにPrune(S、G、rpt)メッセージを追加するためにセクション4.1.6、および規則による送信するインタフェースリストについて計算するマクロによって使用されます。
The upstream (S,G,rpt) Join/Prune state is used along with the Override Timer to send the correct override messages in response to Join/Prune messages sent by upstream peers on a LAN. This state and behavior are specified in Section 4.5.9.
上流(S、G、rpt)は、LANで上流の同輩によって送られたJoin/プルーンのメッセージに対応して正しいオーバーライドメッセージを送るためにOverride Timerと共に使用される状態を、加わるか、または剪定します。 この状態と振舞いはセクション4.5.9で指定されます。
4.1.6. State Summarization Macros
4.1.6. 州の総括マクロ
Using this state, we define the following "macro" definitions, which we will use in the descriptions of the state machines and pseudocode in the following sections.
この状態を使用して、私たちは以下の「マクロ」定義を定義します。(私たちは以下のセクションの州のマシンと擬似コードの記述に定義を使用するつもりです)。
The most important macros are those that define the outgoing interface list (or "olist") for the relevant state. An olist can be "immediate" if it is built directly from the state of the relevant type. For example, the immediate_olist(S,G) is the olist that would be built if the router only had (S,G) state and no (*,G) or (S,G,rpt) state. In contrast, the "inherited" olist inherits state from other types. For example, the inherited_olist(S,G) is the olist that is relevant for forwarding a packet from S to G using both source- specific and group-specific state.
最も重要なマクロは関連状態のための送信するインタフェースリスト(または、"olist")を定義するものです。 それが直接関連タイプの状態から建てられるなら、olistは「即座であることができます」。 例えば、即座の_olist(S、G)はルータに州とノー(*、G)か(S、G、rpt)状態があるだけであるなら(S、G)造られるolistです。 対照的に、「引き継いでいる」olistは他のタイプから状態を引き継ぎます。 例えば、引き継いでいる_olist(S、G)はソース特有のものと同様にグループ特有の状態を使用することでSからGまでパケットを進めるのにおいて、関連しているolistです。
There is no immediate_olist(S,G,rpt) as (S,G,rpt) state is negative state; it removes interfaces in the (*,G) olist from the olist that is actually used to forward traffic. The inherited_olist(S,G,rpt) is therefore the olist that would be used for a packet from S to G forwarding on the RP tree. It is a strict subset of (immediate_olist(*,*,RP) (+) immediate_olist(*,G)).
どんな即座の_olist(S、G、rpt)も(S、G、rpt)状態が否定的状態であるので、ありません。 それは(*、G)olistで交通を進めるのに実際に使用されるolistからインタフェースを取り除きます。 したがって、引き継いでいる_olist(S、G、rpt)はパケットにRP木の上でSからG推進まで使用されるolistです。 それは(即座の_olist(*、*、RP)(+)の即座の_olist(*、G))の厳しい部分集合です。
Generally speaking, the inherited olists are used for forwarding, and the immediate_olists are used to make decisions about state maintenance.
概して、引き継いでいるolistsは推進に使用されます、そして、即座の_olistsは、状態に関する決定を維持にするのに使用されます。
Fenner, et al. Standards Track [Page 21] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[21ページ]。
immediate_olist(*,*,RP) =
joins(*,*,RP)
即座の_olist(*、*、RP)=は接合します。(*、*、RP)
immediate_olist(*,G) =
joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
即座の_olist(*、G)=は無くなっている_が断言するpim_インクルード(*、G)(-)を接合します(*、G)(+)。(*、G)
immediate_olist(S,G) =
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
即座の_olist(S、G)=は無くなっている_が断言するpim_インクルード(S、G)(-)を接合します(S、G)(+)。(S、G)
inherited_olist(S,G,rpt) =
( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
引き継いでいる_olist(S、G、rpt)=、((-)を接合します(**RP(G))(+)は(-) プルーンに合流します(*、G)(S、Gはrptされます))(+)(pim_が除くpim_インクルード(*、G)(-)(S、G))。(_失われて、無くなっている_が断言する(+)(S、G、rpt)について断言してください(*、G))
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
_olistに引き継がれた引き継いでいる_olist(S、G)=(S、Gはrptされます)(+)は無くなっている_が断言するpim_インクルード(S、G)(-)を接合します(S、G)(+)。(S、G)
The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces to which traffic might be forwarded because of hosts that are local members on that interface. Note that normally only the DR cares about local membership, but when an assert happens, the assert winner takes over responsibility for forwarding traffic to local members that have requested traffic on a group or source/group pair.
_が含むpim(*、G)とpim_が含むマクロ(S、G)はそのインタフェースで交通が地元会員であるホストのために送られるかもしれないインタフェースを示します。 そんなに通常、しかし、地方の会員資格、いつ頃にDR厄介だけに注意してくださいか、断言、起こる、勝者がグループかソース/グループ組における交通を要求した地元会員に交通を送ることへの責任を引き継ぐと断言してください。
pim_include(*,G) =
{ all interfaces I such that:
( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me )
AND local_receiver_include(*,G,I) }
pim_は=を含んでいます(*、G)。以下のことのようなもの(I_は_DR(I)と無くなっている_は、=がFALSEであると断言します(*、G、I))OR AssertWinner(*、G、I)=私である)と地方の_受信機_が含むすべてのインタフェースI(*、G、I)
pim_include(S,G) =
{ all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
OR AssertWinner(S,G,I) == me )
AND local_receiver_include(S,G,I) }
pim_は=を含んでいます(S、G)。以下のことのようなもの(I_は_DR(I)と無くなっている_は、=がFALSEであると断言します(S、G、I))OR AssertWinner(S、G、I)=私である)と地方の_受信機_が含むすべてのインタフェースI(S、G、I)
pim_exclude(S,G) =
{ all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me )
AND local_receiver_exclude(S,G,I) }
pim_は=を除きます(S、G)。以下のことのようなもの(I_は_DR(I)と無くなっている_は、=がFALSEであると断言します(*、G、I))OR AssertWinner(*、G、I)=私である)と地方の_受信機_が除くすべてのインタフェースI(S、G、I)
The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD module or other local membership mechanism has determined that local members on interface I desire to receive traffic sent specifically by S to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD module or other local membership mechanism has determined that local
「地方の_受信機_インクルード(S、G、I)」という節はIGMP/MLDモジュールか他のローカルの会員資格メカニズムが、交通を受けるインタフェースI願望の地元会員が特にSでG.に発信したことを決定したならIGMP/MLDモジュールか他のローカルの会員資格メカニズムがそのローカルを決定したなら本当に、「地方の_受信機_インクルード(*、G、I)」が本当であるということです。
Fenner, et al. Standards Track [Page 22] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[22ページ]。
members on interface I desire to receive all traffic sent to G (possibly excluding traffic from a specific set of sources). "local_receiver_exclude(S,G,I) is true if "local_receiver_include(*,G,I)" is true but none of the local members desire to receive traffic from S.
私がすべての交通を受けることを望んでいるインタフェースのメンバーはGに発信しました(ことによると特定のセットの源に交通を入れないようにして)。 「「地方の_受信機_インクルード(*、G、I)」が本当ですが、地元会員のだれも、Sからの交通を受けることを望んでいないなら、_が除く地方の_受信機(S、G、I)は本当です。」
The set "joins(*,*,RP)" is the set of all interfaces on which the router has received (*,*,RP) Joins:
セット、「接合、(*、*、RP) 」 ルータが受信されたすべてのインタフェース(*、*、RP)のセットが加わるということです:
joins(*,*,RP) =
{ all interfaces I such that
DownstreamJPState(*,*,RP,I) is either Join or
Prune-Pending }
=を接合します(*、*、RP)。DownstreamJPState(*、*、RP、I)がJoinか未定のPruneのどちらかであるようにIをすべて連結します。
DownstreamJPState(*,*,RP,I) is the state of the finite state machine in Section 4.5.1.
DownstreamJPState(*、*、RP、I)はセクション4.5.1における有限状態機械の状態です。
The set "joins(*,G)" is the set of all interfaces on which the router has received (*,G) Joins:
セット、「接合、(*、G) 」 ルータが受信されたすべてのインタフェース(*、G)のセットが加わるということです:
joins(*,G) =
{ all interfaces I such that
DownstreamJPState(*,G,I) is either Join or Prune-Pending }
=を接合します(*、G)。DownstreamJPState(*、G、I)がJoinか未定のPruneのどちらかであるようにIをすべて連結します。
DownstreamJPState(*,G,I) is the state of the finite state machine in Section 4.5.2.
DownstreamJPState(*、G、I)はセクション4.5.2における有限状態機械の状態です。
The set "joins(S,G)" is the set of all interfaces on which the router has received (S,G) Joins:
セット、「接合、(S、G) 」 ルータが受信されたすべてのインタフェース(S、G)のセットが加わるということです:
joins(S,G) =
{ all interfaces I such that
DownstreamJPState(S,G,I) is either Join or Prune-Pending }
=を接合します(S、G)。DownstreamJPState(S、G、I)がJoinか未定のPruneのどちらかであるようにIをすべて連結します。
DownstreamJPState(S,G,I) is the state of the finite state machine in Section 4.5.3.
DownstreamJPState(S、G、I)はセクション4.5.3における有限状態機械の状態です。
The set "prunes(S,G,rpt)" is the set of all interfaces on which the router has received (*,G) joins and (S,G,rpt) prunes.
設定「プルーン(S、Gはrptされる)」はインタフェース(*、G)がルータが受けたものに関して接合するか、そして、(S、G、rpt)が剪定するすべてのセットです。
prunes(S,G,rpt) =
{ all interfaces I such that
DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp }
(S、G、rpt)=を剪定します。DownstreamJPState(I、S、Gはrptされる)がPruneかPruneTmpであるようにIをすべて連結します。
DownstreamJPState(S,G,rpt,I) is the state of the finite state machine in Section 4.5.4.
DownstreamJPState(I、S、Gはrptされる)はセクション4.5.4における有限状態機械の状態です。
Fenner, et al. Standards Track [Page 23] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[23ページ]。
The set "lost_assert(*,G)" is the set of all interfaces on which the router has received (*,G) joins but has lost a (*,G) assert. The macro lost_assert(*,G,I) is defined in Section 4.6.5.
「無くなっている_は断言(*、G)」セットはルータが受信されたすべてのインタフェース(*、G)のセットが接合しますが、損をしたということです。a(*、G)は断言します。 定義される無くなっている_がセクション4.6.5で断言する(*、G、I)マクロ。
lost_assert(*,G) =
{ all interfaces I such that
lost_assert(*,G,I) == TRUE }
_失われて、=について断言してください(*、G)。Iあれほどそんなに無くなっている_が断言するすべてのインタフェース(*、G、I)=TRUE
The set "lost_assert(S,G,rpt)" is the set of all interfaces on which the router has received (*,G) joins but has lost an (S,G) assert. The macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5.
「無くなっている_は断言(S、Gはrptされます)」セットがルータが受信されたすべてのインタフェース(*、G)のセットが接合しますが、損をしたということである、(S、G) 断言します。 定義される無くなっている_がセクション4.6.5で断言する(I、S、Gはrptされます)マクロ。
lost_assert(S,G,rpt) =
{ all interfaces I such that
lost_assert(S,G,rpt,I) == TRUE }
_失われて、=について断言してください(S、G、rpt)。Iあれほどそんなに無くなっている_が断言する(I、S、Gはrptされます)すべてのインタフェース=TRUE
The set "lost_assert(S,G)" is the set of all interfaces on which the router has received (S,G) joins but has lost an (S,G) assert. The macro lost_assert(S,G,I) is defined in Section 4.6.5.
「無くなっている_は断言(S、G)」セットがルータが受信されたすべてのインタフェース(S、G)のセットが接合しますが、損をしたということである、(S、G) 断言します。 定義される無くなっている_がセクション4.6.5で断言する(S、G、I)マクロ。
lost_assert(S,G) =
{ all interfaces I such that
lost_assert(S,G,I) == TRUE }
_失われて、=について断言してください(S、G)。Iあれほどそんなに無くなっている_が断言するすべてのインタフェース(S、G、I)=TRUE
The following pseudocode macro definitions are also used in many places in the specification. Basically, RPF' is the RPF neighbor towards an RP or source unless a PIM-Assert has overridden the normal choice of neighbor.
また、以下の擬似コードマクロ定義は仕様による多くの場所で使用されます。 '基本的にRPF'がRPかソースに向かったRPF隣人である、隣人の通常の選択をくつがえしましたaが、PIM断言する。
neighbor RPF'(*,G) {
if ( I_Am_Assert_Loser(*, G, RPF_interface(RP(G))) ) {
return AssertWinner(*, G, RPF_interface(RP(G)) )
} else {
return NBR( RPF_interface(RP(G)), MRIB.next_hop( RP(G) ) )
}
}
'隣人RPF'(*、G)(I_Am_Assert_Loser、(*、G、RPF_インタフェース、(RP(G))) )、AssertWinnerを返してください、(*、G、RPF_インタフェース、(RP(G)) )、ほか、NBRを返してください、(RPF_インタフェース、(RP(G))、MRIB.next_ホップ、(RP(G) ) )
neighbor RPF'(S,G,rpt) {
if( I_Am_Assert_Loser(S, G, RPF_interface(RP(G)) ) ) {
return AssertWinner(S, G, RPF_interface(RP(G)) )
} else {
return RPF'(*,G)
}
}
'隣人RPF'(S、G、rpt)'、(I_Am_Assert_Loser、(S、G、RPF_インタフェース、(RP(G)) ) )、AssertWinnerを返してください、(S、G、RPF_インタフェース、(RP(G)) )、ほかに、'(*、G)をRPFに返してください。
Fenner, et al. Standards Track [Page 24] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[24ページ]。
neighbor RPF'(S,G) {
if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) {
return AssertWinner(S, G, RPF_interface(S) )
} else {
return NBR( RPF_interface(S), MRIB.next_hop( S ) )
}
}
'隣人RPF'(S、G)(I_Am_Assert_Loser、(S、G、RPF_インタフェース(S) ))、AssertWinnerを返してください、(S、G、RPF_インタフェース(S) )、ほかのリターンNBR(RPF_インタフェース(S)、MRIB.next_ホップ(S))
RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets should be coming and to which joins should be sent on the RP tree and SPT, respectively.
'RPF'(*、G)とRPF、'(S、G)はどのデータ・パケットは来るべきであり、RP木でどれが接合するかに送るべきであるか、そして、SPTから隣人をそれぞれ示します。
RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an Assert(S,G) on RPF_interface(RP(G)). In such a case, packets from S will be originating from a different router than RPF'(*,G). If we only have active (*,G) Join state, we need to accept packets from RPF'(S,G,rpt) and add a Prune(S,G,rpt) to the periodic Join(*,G) messages that we send to RPF'(*,G) (see Section 4.5.8).
'変更されて(*、G)、RPFはRPF_インタフェースのAssert(S、G)の結果による'基本的にRPF(S、G、rpt)です'。(RP(G))。 'このような場合には、SからのパケットはRPFと異なったルータから発する'(*、G)。 '能動態(*、G)を状態に加わらせるだけであるなら、私たちは、RPFからパケットを受け入れる必要があっ'て(S、Gはrptされます)、私たちが'(*、G)をRPFに送るという(セクション4.5.8を見てください)周期的なJoin(*、G)メッセージにPrune(S、Gはrptされる)を追加してください。
The function MRIB.next_hop( S ) returns an address of the next-hop PIM neighbor toward the host S, as indicated by the current MRIB. If S is directly adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for G, MRIB.next_hop( RP(G)) returns NULL.
機能MRIB.next_ホップ(S)は次のホップPIM隣人のアドレスをホストSに向かって返します、現在のMRIBによって示されるように。 Sが直接隣接しているなら、MRIB.next_ホップ(S)はNULLを返します。 GのためのRPでは、MRIB.next_は跳びます。(RP(G))はNULLを返します。
The function NBR( I, A ) uses information gathered through PIM Hello messages to map the IP address A of a directly connected PIM neighbor router on interface I to the primary IP address of the same router (Section 4.3.4). The primary IP address of a neighbor is the address that it uses as the source of its PIM Hello messages. Note that a neighbor's IP address may be non-unique within the PIM neighbor database due to scope issues. The address must, however, be unique amongst the addresses of all the PIM neighbors on a specific interface.
機能NBR(I、A)はインタフェースIで同じルータ(セクション4.3.4)の第一のIPアドレスに直接接続されたPIM隣人ルータのIPアドレスAを写像するPIM Helloメッセージを通して集められた情報を使用します。 隣人の第一のIPアドレスはそれがPIM Helloメッセージの源として使用するアドレスです。 隣人のIPアドレスが範囲問題のためにPIM隣人データベースの中で非ユニークであるかもしれないことに注意してください。 しかしながら、アドレスは特定のインタフェースのすべてのPIM隣人のアドレスの中でユニークであるに違いありません。
I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser" state.
I_Am_Assert_Loser(S、G、I)によるAssertが(S、G)に、オンなマシン(セクション4.6.1における)を述べるなら本当に、Interface Iが「私はAssert Loserです」状態にあるということです。
I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" state.
I_Am_Assert_Loser(*、G、I)によるAssertが(*、G)に、オンなマシン(セクション4.6.2における)を述べるなら本当に、Interface Iが「私はAssert Loserです」状態にあるということです。
Fenner, et al. Standards Track [Page 25] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[25ページ]。
4.2. Data Packet Forwarding Rules
4.2. データ・パケット推進規則
The PIM-SM packet forwarding rules are defined below in pseudocode.
PIM-SMパケット推進規則は以下で擬似コードで定義されます。
iif is the incoming interface of the packet.
S is the source address of the packet.
G is the destination address of the packet (group address).
RP is the address of the Rendezvous Point for this group.
RPF_interface(S) is the interface the MRIB indicates would be used
to route packets to S.
RPF_interface(RP) is the interface the MRIB indicates would be
used to route packets to RP, except at the RP when it is the
decapsulation interface (the "virtual" interface on which register
packets are received).
iifはパケットの入って来るインタフェースです。 Sはパケットのソースアドレスです。 Gはパケット(グループアドレス)の送付先アドレスです。 RPはこのグループのためのRendezvous Pointのアドレスです。 RPF_インタフェース(S)によるそれが被膜剥離術インタフェース(レジスタパケットが受け取られている「仮想」のインタフェース)であるときに、MRIBがS. RPF_インタフェース(RP)にパケットを発送するのに使用されるのを示すインタフェースがMRIBがRPを除いて、パケットをRPに発送するのに使用されるのを示すインタフェースであるということです。
First, we restart (or start) the Keepalive Timer if the source is on a directly connected subnet.
まず最初に、ソースが直接接続されたサブネットにあるなら、私たちはKeepalive Timerを再開します(始まってください)。
Second, we check to see if the SPTbit should be set because we've now switched from the RP tree to the SPT.
2番目に、私たちは、私たちが現在RP木からSPTに切り替わったのでSPTbitが用意ができるべきであるかどうか確認するためにチェックします。
Next, we check to see whether the packet should be accepted based on TIB state and the interface that the packet arrived on.
次に、私たちは、パケットがパケットが到着したTIB状態とインタフェースに基づいて受け入れられるべきであるかどうかを見るためにチェックします。
If the packet should be forwarded using (S,G) state, we then build an outgoing interface list for the packet. If this list is not empty, then we restart the (S,G) state Keepalive Timer.
パケットがそうするなら、状態を使用することで(S、G)転送されてください、そして、次に、私たちはパケットのための送信するインタフェースリストを造ります。 このリストが空でないなら、私たちは(S、G)州のKeepalive Timerを再開します。
If the packet should be forwarded using (*,*,RP) or (*,G) state, then we just build an outgoing interface list for the packet. We also check if we should initiate a switch to start receiving this source on a shortest path tree.
(*、*、RP)を使用するか、(*、G)状態にパケットを送るなら、私たちはただパケットのための送信するインタフェースリストを造ります。 また、私たちは、最短パス木の上にこのソースを受け取り始めるためにスイッチを開始するべきであるかどうかチェックします。
Finally we remove the incoming interface from the outgoing interface list we've created, and if the resulting outgoing interface list is not empty, we forward the packet out of those interfaces.
最終的に私たちは作成した送信するインタフェースリストから入って来るインタフェースを取り除きます、そして、結果として起こる送信するインタフェースリストが空でないなら、それらのインタフェースからパケットを進めます。
Fenner, et al. Standards Track [Page 26] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[26ページ]。
On receipt of data from S to G on interface iif:
if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
set KeepaliveTimer(S,G) to Keepalive_Period
# Note: a register state transition or UpstreamJPState(S,G)
# transition may happen as a result of restarting
# KeepaliveTimer, and must be dealt with here.
}
インタフェースiifに関するSからGまでのデータを受け取り次第: (DirectlyConnected(S)=TRUE AND iif=RPF_インタフェース(S) )Keepalive_Period#NoteにKeepaliveTimer(S、G)を設定してください: ここの変遷は#KeepaliveTimerを再開しながらその結果起こるかもしれなくて、取扱わなければならないレジスタ状態遷移かUpstreamJPState(S、G)#
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
inherited_olist(S,G) != NULL ) {
set KeepaliveTimer(S,G) to Keepalive_Period
}
(RPF_インタフェースiif=(S)、UpstreamJPState(S、G)=Joined、および引き継いでいる_olist(S、G)!=NULL)です。KeepaliveTimer(S、G)をKeepalive_Periodに設定してください。
Update_SPTbit(S,G,iif) oiflist = NULL
アップデート_SPTbit(S、G、iif)oiflistはNULLと等しいです。
if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {
oiflist = inherited_olist(S,G)
} else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE) {
oiflist = inherited_olist(S,G,rpt)
CheckSwitchToSpt(S,G)
} else {
# Note: RPF check failed
# A transition in an Assert FSM may cause an Assert(S,G)
# or Assert(*,G) message to be sent out interface iif.
# See section 4.6 for details.
if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif
} else if ( SPTbit(S,G) == FALSE AND
iif is in inherited_olist(S,G,rpt) {
send Assert(*,G) on iif
}
}
ほかの(RPF_インタフェースiif=(S)とSPTbit(S、G)=TRUE)引き継いでいる_oiflist=olist(S、G)である、(ほかのiif=RPF_インタフェース(RP(G)) AND SPTbit(S、G)=FALSE)引き継いでいる_olist(S、G、rpt)oiflist=CheckSwitchToSpt(S、G){ # 以下に注意してください。 RPFがAssert FSMの変遷がAssert(S、G)#、を引き起こすかもしれない失敗した#、をAチェックするか、または出されるべきAssert(*、G)メッセージはiifを連結します。 # 詳細に関してセクション4.6を見てください。(_olistに引き継がれて、TRUE AND iifがいるSPTbit(S、G)=(S、G))であるならほかに、Assert(S、G)をiifに送ってください、(FALSE AND SPTbit(S、G)=iifは引き継いでいる_olist(S、G、rpt)でAssert(*、G)をiifに送ることです。}
oiflist = oiflist (-) iif forward packet on all interfaces in oiflist
oiflistはoiflistのすべてのインタフェースでoiflist(-)iifの前進のパケットと等しいです。
This pseudocode employs several "macro" definitions:
この擬似コードはいくつかの「マクロ」定義を使います:
DirectlyConnected(S) is TRUE if the source S is on any subnet that is directly connected to this router (or for packets originating on this router).
ソースSが直接このルータ(またはこのルータで由来するパケットのために)に関連づけられるどんなサブネットにもあるなら、DirectlyConnected(S)はTRUEです。
inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section 4.1.
引き継いでいる_olist(S、G)と引き継いでいる_olist(S、G、rpt)はセクション4.1で定義されます。
Fenner, et al. Standards Track [Page 27] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[27ページ]。
Basically, inherited_olist(S,G) is the outgoing interface list for packets forwarded on (S,G) state, taking into account (*,*,RP) state, (*,G) state, asserts, etc.
基本的に、引き継いでいる_olist(S、G)は(S、G)状態で進められたパケットのための送信するインタフェースリストです、州((*、G)状態)が断言するアカウント(*、*、RP)などを連れていって
inherited_olist(S,G,rpt) is the outgoing interface list for packets forwarded on (*,*,RP) or (*,G) state, taking into account (S,G,rpt) prune state, asserts, etc.
引き継いでいる_olist(S、G、rpt)は状態、アカウント(S、G、rpt)プルーンの状態への取りが断言する(*、*、RP)で進められたパケットか(*、G)のための送信するインタフェースリストですなど。
Update_SPTbit(S,G,iif) is defined in Section 4.2.2.
アップデート_SPTbit(S、G、iif)はセクション4.2.2で定義されます。
CheckSwitchToSpt(S,G) is defined in Section 4.2.1.
CheckSwitchToSpt(S、G)はセクション4.2.1で定義されます。
UpstreamJPState(S,G) is the state of the finite state machine in Section 4.5.7.
UpstreamJPState(S、G)はセクション4.5.7における有限状態機械の状態です。
Keepalive_Period is defined in Section 4.10.
Keepalive_Periodはセクション4.10で定義されます。
Data-triggered PIM-Assert messages sent from the above forwarding code should be rate-limited in a implementation-dependent manner.
データで引き起こされる、上の推進コードから送られたメッセージがレートによって実現依存する方法で限られるべきであるとPIM断言してください。
4.2.1. Last-Hop Switchover to the SPT
4.2.1. 最後にSPTへの転換を飛び越してください。
In Sparse-Mode PIM, last-hop routers join the shared tree towards the RP. Once traffic from sources to joined groups arrives at a last-hop router, it has the option of switching to receive the traffic on a shortest path tree (SPT).
Sparse-モードPIMでは、最後のホップルータはRPに向かって共有された木に合流します。 ソースから接合グループまでの交通がいったん最後のホップルータに到着すると、それは最短パス木(SPT)の上に交通を受けるために切り替わるオプションを持っています。
The decision for a router to switch to the SPT is controlled as follows:
ルータがSPTに切り替わるという決定は以下の通り制御されます:
void
CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) {
# Note: Restarting the KAT will result in the SPT switch
set KeepaliveTimer(S,G) to Keepalive_Period
}
}
空のCheckSwitchToSpt(S、G)#(pim_インクルード(*、G)(-)pim_はpim_インクルード(S、G)!=NULLを除きます(S、G)(+))とSwitchToSptDesired(S、G))であるなら、Note: KATを再開すると、Keepalive_PeriodへのSPTスイッチセットKeepaliveTimer(S、G)はもたらされるでしょう。
SwitchToSptDesired(S,G) is a policy function that is implementation defined. An "infinite threshold" policy can be implemented by making SwitchToSptDesired(S,G) return false all the time. A "switch on first packet" policy can be implemented by making SwitchToSptDesired(S,G) return true once a single packet has been received for the source and group.
SwitchToSptDesired(S、G)は定義された実現である方針機能です。 SwitchToSptDesired(S、G)を絶えず虚偽で戻らせることによって、「無限の敷居」政策を実施されることができます。 ソースとグループのためにいったん単一のパケットを受け取るとSwitchToSptDesired(S、G)を本当に戻らせることによって、「最初のパケットの上のスイッチ」政策を実施されることができます。
Fenner, et al. Standards Track [Page 28] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[28ページ]。
4.2.2. Setting and Clearing the (S,G) SPTbit
4.2.2. (S、G)SPTbitを設定して、きれいにします。
The (S,G) SPTbit is used to distinguish whether to forward on (*,*,RP)/(*,G) or on (S,G) state. When switching from the RP tree to the source tree, there is a transition period when data is arriving due to upstream (*,*,RP)/(*,G) state while upstream (S,G) state is being established, during which time a router should continue to forward only on (*,*,RP)/(*,G) state. This prevents temporary black-holes that would be caused by sending a Prune(S,G,rpt) before the upstream (S,G) state has finished being established.
(*、*、RP)/(*、G)のフォワードにか否かに関係なく、区別するのに使用されるか、または(S、G)SPTbitは(S、G)状態でそうします。 データが上流のため到着して、(*、*、RP)/(*、G)は、状態が上流(S、G)である間設置されていると述べます、(*、*、RP)/(*、G)だけで送るルータが状態を続けるべきであるどの時間ことであるかときに、RP木からソース木に切り替わるとき、過渡期があります。 これは上流(S、G)の州が、設立され終える前にPrune(S、G、rpt)を送ることによって引き起こされる一時的なブラックホールを防ぎます。
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
したがって、パケットが到着すると、以下の通り(S、G)SPTbitをアップデートします:
void
Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) {
Set SPTbit(S,G) to TRUE
}
}
空のUpdate_SPTbit(S、G、iif)RPF iif=_は(S)とJoinDesired(S、G)=TRUE ANDを連結します。'、((TRUE OR RPF DirectlyConnected(S)=_が(S)=!RPF_を連結する、インタフェース、(RP(G)) OR引き継いでいる_olist(S、G、rpt)=NULL OR(RPF'(S、G)=RPF'(*、G))AND、(RPF、'(S、G!) =NULL)OR(I_Am_Assert_Loser(S、Gはiifされる))はSPTbit(S、G)をTRUEに設定しました。
Additionally, a router can set SPTbit(S,G) to TRUE in other cases, such as when it receives an Assert(S,G) on RPF_interface(S) (see Section 4.6.1).
さらに、ルータは他の場合でSPTbit(S、G)をTRUEに設定できます、それがRPF_インタフェース(S)でAssert(S、G)を受ける(セクション4.6.1を見てください)時のように。
JoinDesired(S,G) is defined in Section 4.5.7 and indicates whether we have the appropriate (S,G) Join state to wish to send a Join(S,G) upstream.
JoinDesired(S、G)は、セクション4.5.7で定義されて、私たちが適切を上流へ、Join(S、G)を送ることを願うために状態に加わらせるかどうかを(S、G)示します。
Basically, Update_SPTbit will set the SPTbit if we have the appropriate (S,G) join state, and if the packet arrived on the correct upstream interface for S, and if one or more of the following conditions applies:
基本的に、私たちが適切を状態に加わらせて(S、G)、パケットがSのために正しい上流のインタフェースで到着して、以下の条件の1つ以上が申し込まれると、Update_SPTbitはSPTbitを設定するでしょう:
1. The source is directly connected, in which case the switch to the
SPT is a no-op.
1. ソースは直接接されます、その場合、SPTへのスイッチがオプアートではありません。
2. The RPF interface to S is different from the RPF interface to the
RP. The packet arrived on RPF_interface(S), and so the SPT must
have been completed.
2. SへのRPFインタフェースはRPFインタフェースからRPまで異なっています。 パケットがRPF_インタフェース(S)で到着したので、SPTは完成したに違いありません。
3. Noone wants the packet on the RP tree.
3. ヌーンはRP木の上でパケットが欲しいです。
Fenner, et al. Standards Track [Page 29] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[29ページ]。
4. RPF'(S,G) == RPF'(*,G). In this case, the router will never be
able to tell if the SPT has been completed, so it should just
switch immediately.
4. 'RPF'(S、G)=RPF'(*、G)。 この場合ルータが、SPTが完成したかどうか決してわからないので、それはすぐに、ただ切り替わるべきです。
In the case where the RPF interface is the same for the RP and for S, but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which indicates that the upstream router with (S,G) state believes the SPT has been completed. However, item (3) above is needed because there may not be any (*,G) state to trigger an Assert(S,G) to happen.
''RPFインタフェースがRPとSのための同じくらいですが、RPFが(S、G)であるケースとRPF'(*、G)は異なって、私たちはAssert(S、G)を待ちます。(Assertは、(S、G)状態がある上流のルータが、SPTが完成したと信じているのを示します)。 しかしながら、起こるAssert(S、G)の引き金となる少しの(*、G)状態もないかもしれないので、上の項目(3)が必要です。
The SPTbit is cleared in the (S,G) upstream state machine (see Section 4.5.7) when JoinDesired(S,G) becomes FALSE.
JoinDesired(S、G)がFALSEになるとき、SPTbitは(S、G)上流の州のマシン(セクション4.5.7を見る)できれいにされます。
4.3. Designated Routers (DR) and Hello Messages
4.3. ルータ(DR)に指定されて、こんにちは、メッセージ
A shared-media LAN like Ethernet may have multiple PIM-SM routers connected to it. A single one of these routers, the DR, will act on behalf of directly connected hosts with respect to the PIM-SM protocol. Because the distinction between LANs and point-to-point interfaces can sometimes be blurred, and because routers may also have multicast host functionality, the PIM-SM specification makes no distinction between the two. Thus, DR election will happen on all interfaces, LAN or otherwise.
イーサネットのような共有されたメディアLANで、複数のPIM-SMルータをそれに接続するかもしれません。 これらのルータの単一の1つ(DR)はPIM-SMプロトコルに関する直接接続されたホストを代表して行動するでしょう。 時々LANと二地点間インタフェースの区別をぼかすことができて、また、ルータにはマルチキャストホストの機能性があるかもしれないので、PIM-SM仕様は2つの間で区別を全くしません。 したがって、DR選挙はLANの、または、そうでないすべてのインタフェースで起こるでしょう。
DR election is performed using Hello messages. Hello messages are also the way that option negotiation takes place in PIM, so that additional functionality can be enabled, or parameters tuned.
DR選挙は、Helloメッセージを使用することで実行されます。 こんにちは、メッセージはそうです、また、交渉をゆだねる道が中のPIMによってその追加機能性を可能にすることができる場所、または調整されたパラメタを取ります。
4.3.1. Sending Hello Messages
4.3.1. 発信、こんにちは、メッセージ
PIM Hello messages are sent periodically on each PIM-enabled interface. They allow a router to learn about the neighboring PIM routers on each interface. Hello messages are also the mechanism used to elect a Designated Router (DR), and to negotiate additional capabilities. A router must record the Hello information received from each PIM neighbor.
それぞれのPIMによって可能にされたインタフェースで定期的にPIM Helloメッセージを送ります。 彼らは各インタフェースで隣接しているPIMルータに関してルータを学ばせます。 また、メカニズムは、こんにちは、メッセージがそうであり、Designated Router(DR)を選出して、以前はよく追加能力を交渉していました。 ルータはそれぞれのPIM隣人から受け取られたHello情報を記録しなければなりません。
Hello messages MUST be sent on all active interfaces, including
physical point-to-point links, and are multicast to the 'ALL-PIM-
ROUTERS' group address ('224.0.0.13' for IPv4 and 'ff02::d' for
IPv6).
こんにちは、メッセージが物理的なポイントツーポイント接続を含むすべてのアクティブなインタフェースで送らなければならなくて、マルチキャストである、'、すべて、-、PIM- ROUTERS、'アドレスを分類してください、('224.0、.0、IPv6のためのIPv4と'ff02: : d'のための.13')
We note that some implementations do not send Hello messages on
point-to-point interfaces. This is non-compliant behavior. A
compliant PIM router MUST send Hello messages, even on point-to-
point interfaces.
私たちは、いくつかの実現が二地点間インタフェースでメッセージをHelloに送らないことに注意します。 これは不従順な振舞いです。 対応するPIMルータはポイントからポイントへのインタフェースでさえメッセージをHelloに送らなければなりません。
Fenner, et al. Standards Track [Page 30] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[30ページ]。
A per-interface Hello Timer (HT(I)) is used to trigger sending Hello messages on each active interface. When PIM is enabled on an interface or a router first starts, the Hello Timer of that interface is set to a random value between 0 and Triggered_Hello_Delay. This prevents synchronization of Hello messages if multiple routers are powered on simultaneously. After the initial randomized interval, Hello messages must be sent every Hello_Period seconds. The Hello Timer should not be reset except when it expires.
1インタフェースあたり1Hello Timer、(HT(I))は、それぞれのアクティブなインタフェースに関する送付Helloメッセージの引き金となるのに使用されます。 PIMがインタフェースで有効にされるか、またはルータが最初に始まるとき、そのインタフェースのHello Timerは0とTriggered_Hello_Delayの間の無作為の値へのセットです。 複数のルータが同時に電源を入れられているなら、これはHelloメッセージの同期を防ぎます。 イニシャルが間隔をランダマイズした後に、Periodが後援するあらゆるHello_をHelloメッセージに送らなければなりません。 それが期限が切れる時以外に、Hello Timerをリセットするべきではありません。
Note that neighbors will not accept Join/Prune or Assert messages from a router unless they have first heard a Hello message from that router. Thus, if a router needs to send a Join/Prune or Assert message on an interface on which it has not yet sent a Hello message with the currently configured IP address, then it MUST immediately send the relevant Hello message without waiting for the Hello Timer to expire, followed by the Join/Prune or Assert message.
彼らが最初にそのルータからのHelloメッセージを聞いていなかったなら隣人がルータからJoin/プルーンかAssertメッセージを受け入れないことに注意してください。 したがって、ルータが、それがまだ現在構成されたIPアドレスがあるHelloメッセージを送らないインタフェースにJoin/プルーンかAssertメッセージを送る必要があるなら、それはすぐにHello Timerが期限が切れるのを待つことのない関連Helloメッセージを送らなければなりません、続いて、Join/プルーンかAssertメッセージを送ります。
The DR_Priority Option allows a network administrator to give preference to a particular router in the DR election process by giving it a numerically larger DR Priority. The DR_Priority Option SHOULD be included in every Hello message, even if no DR Priority is explicitly configured on that interface. This is necessary because priority-based DR election is only enabled when all neighbors on an interface advertise that they are capable of using the DR_Priority Option. The default priority is 1.
DR_Priority Optionは、ネットワーク管理者にDR選挙の過程による特定のルータに優先を数の上でより大きいDR Priorityをそれに与えることによって、与えさせます。 DR_Priority Option SHOULDがあらゆるHelloメッセージに含まれていて、DR Priorityが全くそれで明らかに構成されないでも、連結してください。 インタフェースのすべての隣人が、彼らがDR_Priority Optionを使用できるのは広告を出すときだけ、優先権ベースのDR選挙が可能にされるので、これが必要です。 デフォルト優先権は1です。
The Generation_Identifier (GenID) Option SHOULD be included in all Hello messages. The GenID option contains a randomly generated 32-bit value that is regenerated each time PIM forwarding is started or restarted on the interface, including when the router itself restarts. When a Hello message with a new GenID is received from a neighbor, any old Hello information about that neighbor SHOULD be discarded and superseded by the information from the new Hello message. This may cause a new DR to be chosen on that interface.
含まれていて、Identifier(GenID)がSHOULDにゆだねるGeneration_はすべてのHelloで通信します。 GenIDオプションはPIM推進がインタフェースで始められるか、または再開されるたびに作り直される手当たりしだいに発生している32ビットの値を含んでいます、ルータ自体がいつ再開するかを含んでいて。 隣人から新しいGenIDがあるHelloメッセージを受け取るとき、新しいHelloメッセージからの情報によって捨てられて、取って代わられたその隣人SHOULDのどんな古いHello情報です。 これで、そのインタフェースで新しいDRを選ぶかもしれません。
The LAN Prune Delay Option SHOULD be included in all Hello messages sent on multi-access LANs. This option advertises a router's capability to use values other than the defaults for the Propagation_Delay and Override_Interval, which affect the setting of the Prune-Pending, Upstream Join, and Override Timers (defined in Section 4.10).
LAN Prune Delay Option SHOULD、マルチアクセスLANで送られたすべてのHelloメッセージで含められてください。 このオプションは未定のPrune、Upstream Join、およびOverride Timers(セクション4.10では、定義される)の設定に影響するPropagation_DelayとOverride_Intervalのためのデフォルト以外の値を使用するルータの能力の広告を出します。
The Address List Option advertises all the secondary addresses associated with the source interface of the router originating the message. The option MUST be included in all Hello messages if there are secondary addresses associated with the source interface and MAY be omitted if no secondary addresses exist.
Address List Optionはメッセージを溯源するルータのソースのインタフェースに関連しているすべての二次アドレスの広告を出します。 どんな二次アドレスも存在していないなら省略されるソースのインタフェースと5月に関連している二次アドレスがあれば、すべてのHelloメッセージにオプションを含まなければなりません。
Fenner, et al. Standards Track [Page 31] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[31ページ]。
To allow new or rebooting routers to learn of PIM neighbors quickly, when a Hello message is received from a new neighbor, or a Hello message with a new GenID is received from an existing neighbor, a new Hello message should be sent on this interface after a randomized delay between 0 and Triggered_Hello_Delay. This triggered message need not change the timing of the scheduled periodic message. If a router needs to send a Join/Prune to the new neighbor or send an Assert message in response to an Assert message from the new neighbor before this randomized delay has expired, then it MUST immediately send the relevant Hello message without waiting for the Hello Timer to expire, followed by the Join/Prune or Assert message. If it does not do this, then the new neighbor will discard the Join/Prune or Assert message.
新しいかリブートしているルータが、新しい隣人からHelloメッセージを受け取るか、または既存の隣人から新しいGenIDがあるHelloメッセージを受け取るとき、すぐに、新しいHelloメッセージが受け取るべきであることをPIM隣人に学ぶのをランダマイズされた遅れの後にこのインタフェースで0とTriggered_Hello_Delayの間に送った状態で許容するために。 この引き起こされたメッセージは予定されている周期的なメッセージのタイミングを変える必要はありません。 ルータが、Join/プルーンを新しい隣人に送るか、またはこのランダマイズされた遅れが期限が切れる前に新しい隣人からのAssertメッセージに対応してAssertメッセージを送る必要があるなら、それはすぐにHello Timerが期限が切れるのを待つことのない関連Helloメッセージを送らなければなりません、続いて、Join/プルーンかAssertメッセージを送ります。 これをしないと、新しい隣人はJoin/プルーンかAssertメッセージを捨てるでしょう。
Before an interface goes down or changes primary IP address, a Hello message with a zero HoldTime should be sent immediately (with the old IP address if the IP address changed). This will cause PIM neighbors to remove this neighbor (or its old IP address) immediately. After an interface has changed its IP address, it MUST send a Hello message with its new IP address. If an interface changes one of its secondary IP addresses, a Hello message with an updated Address_List option and a non-zero HoldTime should be sent immediately. This will cause PIM neighbors to update this neighbor's list of secondary addresses immediately.
インタフェースが落ちるか、または第一のIPアドレスを変える前に、すぐに、HoldTimeがないHelloメッセージを送るべきです(古いIPアドレスで、アドレスはIPであるなら変化しました)。 これで、PIM隣人はすぐに、この隣人(または、古いIPアドレス)を外すでしょう。 インタフェースがIPアドレスを変えた後に、それは新しいIPアドレスがあるHelloメッセージを送らなければなりません。 インタフェースが二次IPアドレスの1つを変えるなら、すぐに、アップデートされたAddress_Listオプションと非ゼロHoldTimeがあるHelloメッセージを送るべきです。 これで、PIM隣人はすぐに、この隣人の二次アドレスのリストをアップデートするでしょう。
4.3.2. DR Election
4.3.2. DR選挙
When a PIM Hello message is received on interface I, the following information about the sending neighbor is recorded:
インタフェースIにPIM Helloメッセージを受け取るとき、送付隣人の以下の情報は記録しています:
neighbor.interface
The interface on which the Hello message arrived.
neighbor.interface、Helloメッセージが到着したインタフェース。
neighbor.primary_ip_address
The IP address that the PIM neighbor used as the source
address of the Hello message.
neighbor.primary_ip_はPIM隣人がHelloメッセージのソースアドレスとして使用したIPアドレスを記述します。
neighbor.genid
The Generation ID of the PIM neighbor.
PIMのGeneration IDが近所付き合いさせるneighbor.genid。
neighbor.dr_priority
The DR Priority field of the PIM neighbor, if it is present in
the Hello message.
DR PriorityがさばくPIM隣人のneighbor.dr_優先権それがHelloメッセージに存在しているなら。
neighbor.dr_priority_present
A flag indicating if the DR Priority field was present in the
Hello message.
DR Priority分野がHelloメッセージに存在していたかどうかを示すneighbor.dr_優先権の_の現在のA旗。
Fenner, et al. Standards Track [Page 32] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[32ページ]。
neighbor.timeout
A timer value to time out the neighbor state when it becomes
stale, also known as the Neighbor Liveness Timer.
それであるときに隣人が述べるタイムアウトへのneighbor.timeout Aタイマ価値は聞き古した、また、Neighbor Liveness Timerとして知られるようになります。
The Neighbor Liveness Timer (NLT(N,I)) is reset to
Hello_Holdtime (from the Hello Holdtime option) whenever a
Hello message is received containing a Holdtime option, or to
Default_Hello_Holdtime if the Hello message does not contain
the Holdtime option.
HelloメッセージがHoldtimeオプションを含むのにおいて受信されているときはいつも、Neighbor Liveness Timer(NLT(N、I))がHello_Holdtime(Hello Holdtimeオプションからの)にリセットされるか、またはHelloが通信するなら、Default_Helloに、_HoldtimeはHoldtimeオプションを含んでいません。
Neighbor state is deleted when the neighbor timeout expires.
隣人タイムアウトが期限が切れるとき、隣人状態は削除されます。
The function for computing the DR on interface I is:
インタフェースのDRを計算するための機能:
host
DR(I) {
dr = me
for each neighbor on interface I {
if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
dr = neighbor
}
}
return dr
}
ホストDR(I)インタフェースIの各隣人のためにdrに私と等しい、(dr_が_より良い(隣人、dr、私) =TRUE)dr=隣接物である、drを返してください。
The function used for comparing DR "metrics" on interface I is:
機能はDRを比較するのにインタフェースにおける「測定基準」を使用しました:
bool
dr_is_better(a,b,I) {
if( there is a neighbor n on I for which n.dr_priority_present
is false ) {
return a.primary_ip_address > b.primary_ip_address
} else {
return ( a.dr_priority > b.dr_priority ) OR
( a.dr_priority == b.dr_priority AND
a.primary_ip_address > b.primary_ip_address )
}
}
bool dr_は、よりよく(a、b、I)_です。ほかの(隣人nがどのn.dr_優先権_プレゼントが偽であるかためにIにいます)_ip_アドレス>予備選挙_リターンa.予備選挙b.ip_アドレスであるなら、OR(a.dr_優先権=b.dr_優先権と第一のa.の_ip_アドレス>予備選挙_b.ip_アドレス)を(a.dr_優先権>b.dr_優先権)に返してください。
The trivial function I_am_DR(I) is defined to aid readability:
些細な機能I_による_DR(I)が読み易さを支援するために定義されるということです:
bool
I_am_DR(I) {
return DR(I) == me
}
bool I_は_DR(I)です。リターンDR(I)=私
Fenner, et al. Standards Track [Page 33] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[33ページ]。
The DR Priority is a 32-bit unsigned number, and the numerically larger priority is always preferred. A router's idea of the current DR on an interface can change when a PIM Hello message is received, when a neighbor times out, or when a router's own DR Priority changes. If the router becomes the DR or ceases to be the DR, this will normally cause the DR Register state machine to change state. Subsequent actions are determined by that state machine.
DR Priorityは32ビットの符号のない数です、そして、数の上でより大きい優先権はいつも好まれます。 ルータが自己であるときに、ルータのインタフェースの現在のDRの考えが、外でいつa隣人回数であるかときに、PIM Helloメッセージが受信されているかを変えることができますか、またはDR Priorityは変化します。 ルータが、DRになるか、またはDRであることをやめると、これで、通常、DR Register州のマシンは状態を変えるでしょう。 その後の動作はその州のマシンで決定します。
We note that some PIM implementations do not send Hello messages on
point-to-point interfaces and thus cannot perform DR election on
such interfaces. This is non-compliant behavior. DR election MUST
be performed on ALL active PIM-SM interfaces.
私たちは、いくつかのPIM実現が二地点間インタフェースでメッセージをHelloに送らないで、その結果、そのようなインタフェースにDR選挙を実行できないことに注意します。 これは不従順な振舞いです。 すべてのアクティブなPIM-SMインタフェースにDR選挙を実行しなければなりません。
4.3.3. Reducing Prune Propagation Delay on LANs
4.3.3. LANでプルーンの伝播遅延を減少させます。
In addition to the information recorded for the DR Election, the following per neighbor information is obtained from the LAN Prune Delay Hello option:
DR Election、1隣人以下のために記録された情報に加えて、LAN Prune Delay Helloオプションから情報を得ます:
neighbor.lan_prune_delay_present
A flag indicating if the LAN Prune Delay option was present in
the Hello message.
LAN Prune DelayオプションがHelloメッセージに存在していたかどうかを示すneighbor.lan_プルーンの_遅れ_プレゼントA旗。
neighbor.tracking_support
A flag storing the value of the T bit in the LAN Prune Delay
option if it is present in the Hello message. This indicates
the neighbor's capability to disable Join message suppression.
それがHelloメッセージに存在しているなら、Tの値を格納するneighbor.tracking_サポートA旗にLAN Prune Delayオプションで噛み付きました。 これはJoinメッセージ抑圧を無効にする隣人の能力を示します。
neighbor.propagation_delay
The Propagation Delay field of the LAN Prune Delay option (if
present) in the Hello message.
Propagation DelayがさばくHelloメッセージにおけるLAN Prune Delayオプション(存在しているなら)のneighbor.propagation_遅れ。
neighbor.override_interval
The Override_Interval field of the LAN Prune Delay option (if
present) in the Hello message.
Override_IntervalがさばくHelloメッセージにおけるLAN Prune Delayオプション(存在しているなら)のneighbor.override_間隔。
The additional state described above is deleted along with the DR neighbor state when the neighbor timeout expires.
隣人タイムアウトが期限が切れるとき、上で説明された追加状態はDR隣人状態と共に削除されます。
Just like the DR_Priority option, the information provided in the LAN Prune Delay option is not used unless all neighbors on a link advertise the option. The function below computes this state:
まさしくDR_Priorityオプションのように、リンクの上のすべての隣人がオプションの広告を出さないなら、LAN Prune Delayオプションに提供された情報は使用されていません。 以下の関数はこの状態を計算します:
Fenner, et al. Standards Track [Page 34] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[34ページ]。
bool
lan_delay_enabled(I) {
for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) {
return false
}
}
return true
}
bool lan_遅れ_は(I)を可能にしました。インタフェースの各隣人に関して、(遅れ_が= 虚偽で寄贈するneighbor.lan_プルーンの_)が虚偽で戻るなら、私は本当に戻ります。
The Propagation Delay inserted by a router in the LAN Prune Delay option expresses the expected message propagation delay on the link and should be configurable by the system administrator. It is used by upstream routers to figure out how long they should wait for a Join override message before pruning an interface.
ルータによってLAN Prune Delayオプションに挿入されたPropagation Delayはリンクの上に予想されたメッセージ伝播遅延を言い表して、システム管理者は構成可能であるべきです。 それは上流のルータによって使用されて、インタフェースを剪定する前にそれらがどれくらい長い間Joinオーバーライドメッセージを待つべきであるかを理解します。
PIM implementers should enforce a lower bound on the permitted values for this delay to allow for scheduling and processing delays within their router. Such delays may cause received messages to be processed later as well as triggered messages to be sent later than intended. Setting this Propagation Delay to too low a value may result in temporary forwarding outages because a downstream router will not be able to override a neighbor's Prune message before the upstream neighbor stops forwarding.
この遅れがそれらのルータの中で遅れの計画をして、処理すると考慮するように、PIM implementersは下界に受入れられた値に押しつけるはずです。 そのような遅れは後で意図するより遅く送られるべき引き起こされたメッセージと同様に処理されるべき受信されたメッセージを引き起こすかもしれません。 低過ぎる値にこのPropagation Delayを設定すると、上流の隣人が、進めるのを止める前に川下のルータが隣人のPruneメッセージに優越できないので、一時的な推進供給停止はもたらされるかもしれません。
When all routers on a link are in a position to negotiate a Propagation Delay different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective_Propagation_Delay of interface I is:
リンクの上のすべてのルータがデフォルトと異なったPropagation Delayを交渉する立場にあるとき、各隣人によって広告に掲載されたものからの最も大きい値は選ばれています。 インタフェースについてEffective_Propagation_Delayを計算するための機能:
time_interval
Effective_Propagation_Delay(I) {
if ( lan_delay_enabled(I) == false ) {
return Propagation_delay_default
}
delay = Propagation_Delay(I)
for each neighbor on interface I {
if ( neighbor.propagation_delay > delay ) {
delay = neighbor.propagation_delay
}
}
return delay
}
時間_間隔Effective_Propagation_Delay(I)((I) = 虚偽で有効にされたlan_遅れ_)リターンPropagation_遅れ_デフォルト遅れがインタフェースの各隣人のために伝播_Delay(I)と等しいなら、(neighbor.propagation_遅れ>遅れ)が=neighbor.propagation_遅れを遅らせるなら、私は遅れを返します。
To avoid synchronization of override messages when multiple downstream routers share a multi-access link, sending of such messages is delayed by a small random amount of time. The period of randomization should represent the size of the PIM router population
そのようなメッセージを発信させて、複数の川下のルータがマルチアクセスリンクを共有するときのオーバーライドメッセージの同期を避けるのは小さい無作為の時間までに遅れます。 無作為化の一区切りはPIMルータ人口のサイズを表すべきです。
Fenner, et al. Standards Track [Page 35] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[35ページ]。
on the link. Each router expresses its view of the amount of randomization necessary in the Override Interval field of the LAN Prune Delay option.
リンクに関して。 各ルータはLAN Prune DelayオプションのOverride Interval分野で必要な無作為化の量の視点を言い表します。
When all routers on a link are in a position to negotiate an Override Interval different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Override Interval of interface I is:
リンクの上のすべてのルータがデフォルトと異なったOverride Intervalを交渉する立場にあるとき、各隣人によって広告に掲載されたものからの最も大きい値は選ばれています。 インタフェースのEffective Override Intervalを計算するための機能:
time_interval
Effective_Override_Interval(I) {
if ( lan_delay_enabled(I) == false ) {
return t_override_default
}
delay = Override_Interval(I)
for each neighbor on interface I {
if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval
}
}
return delay
}
時間_間隔Effective_Override_Interval(I)((I) = 虚偽で有効にされたlan_遅れ_)リターンt_オーバーライド_デフォルト遅れがインタフェースの各隣人のためにオーバーライド_Interval(I)と等しいなら、私は(neighbor.override_間隔>遅れ)遅れ=neighbor.override_間隔であるなら遅れを返します。
Although the mechanisms are not specified in this document, it is possible for upstream routers to explicitly track the join membership of individual downstream routers if Join suppression is disabled. A router can advertise its willingness to disable Join suppression by using the T bit in the LAN Prune Delay Hello option. Unless all PIM routers on a link negotiate this capability, explicit tracking and the disabling of the Join suppression mechanism are not possible. The function for computing the state of Suppression on interface I is:
メカニズムが本書では指定されませんが、上流のルータが明らかに追跡されるのが、可能である、Join抑圧は障害があるなら、個々の川下のルータの会員資格を接合してください。 ルータはLAN Prune Delay HelloオプションにTビットを使用することによってJoin抑圧を無効にする意欲の広告を出すことができます。 リンクの上のすべてのPIMルータがこの能力を交渉しないなら、Join抑圧メカニズムを明白な追跡と無能にするのは可能ではありません。 インタフェースのSuppressionの州を計算するための機能:
bool
Suppression_Enabled(I) {
if ( lan_delay_enabled(I) == false ) {
return true
}
for each neighbor on interface I {
if ( neighbor.tracking_support == false ) {
return true
}
}
return false
}
bool Suppression_Enabled(I)((I) = 虚偽で有効にされたlan_遅れ_)が各隣人のために本当にインタフェースで戻るなら、(_が= 虚偽で支持するneighbor.tracking)が本当に戻るなら、私は虚偽で戻ります。
Note that the setting of Suppression_Enabled(I) affects the value of t_suppressed (see Section 4.10).
Suppression_Enabled(I)の設定が抑圧されたt_の値に影響することに注意してください(セクション4.10を見てください)。
Fenner, et al. Standards Track [Page 36] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[36ページ]。
4.3.4. Maintaining Secondary Address Lists
4.3.4. 二次住所録を維持します。
Communication of a router's interface secondary addresses to its PIM neighbors is necessary to provide the neighbors with a mechanism for mapping next_hop information obtained through their MRIB to a primary address that can be used as a destination for Join/Prune messages. The mapping is performed through the NBR macro. The primary address of a PIM neighbor is obtained from the source IP address used in its PIM Hello messages. Secondary addresses are carried within the Hello message in an Address List Hello option. The primary address of the source interface of the router MUST NOT be listed within the Address List Hello option.
PIM隣人へのルータのインタフェースの二次アドレスのコミュニケーションが、彼らのMRIBを通してJoin/プルーンのメッセージに目的地として使用できる第一のアドレスに得られた次の_ホップ情報を写像するためにメカニズムを隣人に提供するのに必要です。 マッピングはNBRマクロを通して実行されます。 アドレスがPIM Helloメッセージで使用したソースIPからPIM隣人の第一のアドレスを得ます。 二次アドレスはAddress List HelloオプションにおけるHelloメッセージの中で運ばれます。 Address List Helloオプションの中にルータのソースのインタフェースの第一のアドレスを記載してはいけません。
In addition to the information recorded for the DR Election, the following per neighbor information is obtained from the Address List Hello option:
DR Election、1隣人以下のために記録された情報に加えて、Address List Helloオプションから情報を得ます:
neighbor.secondary_address_list
The list of secondary addresses used by the PIM neighbor on
the interface through which the Hello message was transmitted.
二次アドレスのリストがHelloメッセージが送られたインタフェースのPIM隣人で使用したneighbor.secondary_アドレス_リスト。
When processing a received PIM Hello message containing an Address List Hello option, the list of secondary addresses in the message completely replaces any previously associated secondary addresses for that neighbor. If a received PIM Hello message does not contain an Address List Hello option, then all secondary addresses associated with the neighbor must be deleted. If a received PIM Hello message contains an Address List Hello option that includes the primary address of the sending router in the list of secondary addresses (although this is not expected), then the addresses listed in the message, excluding the primary address, are used to update the associated secondary addresses for that neighbor.
Address List Helloオプションを含む受信されたPIM Helloメッセージを処理するとき、メッセージの二次アドレスのリストはその隣人のためにどんな以前に関連している二次アドレスも完全に置き換えます。 受信されたPIM HelloメッセージがAddress List Helloオプションを含んでいないなら、隣人に関連しているすべての二次アドレスを削除しなければなりません。 受信されたPIM Helloメッセージが二次アドレスのリストに送付ルータの第一のアドレスを含んでいるAddress List Helloオプションを含んでいるなら(これは予想されませんが)、第一のアドレスを除いて、メッセージに記載されたアドレスは、その隣人のために関連二次アドレスをアップデートするのに使用されます。
All the advertised secondary addresses in received Hello messages must be checked against those previously advertised by all other PIM neighbors on that interface. If there is a conflict and the same secondary address was previously advertised by another neighbor, then only the most recently received mapping MUST be maintained, and an error message SHOULD be logged to the administrator in a rate-limited manner.
以前にそのインタフェースの他のすべてのPIM隣人によって広告に掲載されたものに対して受信されたHelloメッセージのすべての広告を出している二次アドレスをチェックしなければなりません。 闘争があって、同じ二次アドレスが以前に別の隣人によって広告に掲載されたなら、最も最近受信された唯一のマッピングは、維持されていてエラーメッセージSHOULDであるに違いありません。レートで限られた方法で管理者に登録されてください。
Within one Address List Hello option, all the addresses MUST be of the same address family. It is not permitted to mix IPv4 and IPv6 addresses within the same message. In addition, the address family of the fields in the message SHOULD be the same as the IP source and destination addresses of the packet header.
1つのAddress List Helloオプションの中に、同じアドレス家族にはすべてのアドレスがあるに違いありません。 それが同じメッセージの中でIPv4とIPv6アドレスを混ぜることが許可されていません。 添加で演説する、IPソースと目的地と同じくらいがパケットのヘッダーのアドレスであったならメッセージSHOULDの分野の家族に演説してください。
Fenner, et al. Standards Track [Page 37] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[37ページ]。
4.4. PIM Register Messages
4.4. PIMはメッセージを登録します。
The Designated Router (DR) on a LAN or point-to-point link encapsulates multicast packets from local sources to the RP for the relevant group unless it recently received a Register-Stop message for that (S,G) or (*,G) from the RP. When the DR receives a Register-Stop message from the RP, it starts a Register-Stop Timer to maintain this state. Just before the Register-Stop Timer expires, the DR sends a Null-Register Message to the RP to allow the RP to refresh the Register-Stop information at the DR. If the Register- Stop Timer actually expires, the DR will resume encapsulating packets from the source to the RP.
最近RPからのそれ(S、G)のためのRegister-停止メッセージか(*、G)を受け取らなかったなら、LANかポイントツーポイント接続の上のDesignated Router(DR)は関連グループのために地元筋からRPまでマルチキャストパケットをカプセルに入れります。 DRがRPからRegister-停止メッセージを受け取るとき、それは、この状態を維持するためにRegister-停止Timerを始動します。 Register-停止Timerが期限が切れるすぐ前に、DRは、RPがDRでRegister-停止情報をリフレッシュするのを許容するためにNull-レジスタMessageをRPに送ります。Register停止Timerが実際に期限が切れると、DRは、ソースからRPまでパケットをカプセルに入れるのを再開するでしょう。
4.4.1. Sending Register Messages from the DR
4.4.1. DRからレジスタメッセージを送ります。
Every PIM-SM router has the capability to be a DR. The state machine below is used to implement Register functionality. For the purposes of specification, we represent the mechanism to encapsulate packets to the RP as a Register-Tunnel interface, which is added to or removed from the (S,G) olist. The tunnel interface then takes part in the normal packet forwarding rules as specified in Section 4.2.
あらゆるPIM-SMルータには、DRである能力があります。以下の州のマシンは、Registerの機能性を実行するのに使用されます。 仕様の目的のために、私たちは要約するメカニズムを表します。Register-トンネルのインタフェース((S、G)olistから加えられたか取り除かれたもの)としてのRPへのパケット。 そして、トンネルのインタフェースはセクション4.2の指定されるとしての正常なパケット推進規則に参加します。
If register state is maintained, it is maintained only for directly connected sources and is per-(S,G). There are four states in the DR's per-(S,G) Register state machine:
レジスタ状態が維持されるなら、それが直接接続されたソースだけに維持されて、ある、-、(S、G。) 4つの州がDRのところにある、-、(S、G)は州のマシンを登録します:
Join (J)
The register tunnel is "joined" (the join is actually implicit,
but the DR acts as if the RP has joined the DR on the tunnel
interface).
接合、(J) レジスタトンネルが「接合される」、(接合、実際に暗黙です、まるでRPがトンネルのインタフェースのDRを接合したかのようにDRだけが行動するということである、)
Prune (P)
The register tunnel is "pruned" (this occurs when a Register-
Stop is received).
レジスタがトンネルを堀るプルーン(P)は「剪定される」(Register停止が受け取られているとき、これは起こります)。
Join-Pending (JP)
The register tunnel is pruned but the DR is contemplating adding
it back.
接合、-、未定である、(JP) レジスタトンネル余計なものを取り除かれますが、DRは、それを加え返すと熟考しています。
NoInfo (NI)
No information. This is the initial state, and the state when
the router is not the DR.
NoInfo(NI)いいえ情報。 これは初期状態です、そして、ルータであるときに、状態はDRではありません。
In addition, a Register-Stop Timer (RST) is kept if the state machine is not in the NoInfo state.
さらに、州のマシンがNoInfo状態にないなら、Register-停止Timer(RST)は保たれます。
Fenner, et al. Standards Track [Page 38] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[38ページ]。
Figure 1: Per-(S,G) register state machine at a DR in tabular form
図1: -、(S、G)はDRに表にして州のマシンを登録します。
+----------++----------------------------------------------------------+ | || Event | | ++----------+-----------+-----------+-----------+-----------+ |Prev State||Register- | Could | Could | Register- | RP changed| | ||Stop Timer| Register | Register | Stop | | | ||expires | ->True | ->False | received | | +----------++----------+-----------+-----------+-----------+-----------+ |NoInfo ||- | -> J state| - | - | - | |(NI) || | add reg | | | | | || | tunnel | | | | +----------++----------+-----------+-----------+-----------+-----------+ | ||- | - | -> NI | -> P state| -> J state| | || | | state | | | | || | | remove reg| remove reg| update reg| |Join (J) || | | tunnel | tunnel; | tunnel | | || | | | set | | | || | | | Register- | | | || | | | Stop | | | || | | | Timer(*) | | +----------++----------+-----------+-----------+-----------+-----------+ | ||-> J state| - | -> NI | -> P state| -> J state| | || | | state | | | |Join- ||add reg | | | set | add reg | |Pending ||tunnel | | | Register- | tunnel; | |(JP) || | | | Stop | cancel | | || | | | Timer(*) | Register- | | || | | | | Stop Timer| +----------++----------+-----------+-----------+-----------+-----------+ | ||-> JP | - | -> NI | - | -> J state| | ||state | | state | | | | ||set | | | | add reg | |Prune (P) ||Register- | | | | tunnel; | | ||Stop | | | | cancel | | ||Timer(**);| | | | Register- | | ||send Null-| | | | Stop Timer| | ||Register | | | | | +----------++----------+-----------+-----------+-----------+-----------+
+----------++----------------------------------------------------------+ | || 出来事| | ++----------+-----------+-----------+-----------+-----------+ |Prev状態||登録してください。| could| could| 登録してください。| RPは変化しました。| | ||タイマを止めてください。| レジスタ| レジスタ| 停止| | | ||期限が切れます。| ->、本当| ->偽| 受信します。| | +----------++----------+-----------+-----------+-----------+-----------+ |NoInfo||- | ->J状態| - | - | - | |(Ni) || | regを加えてください。| | | | | || | トンネル| | | | +----------++----------+-----------+-----------+-----------+-----------+ | ||- | - | ->Ni| ->P状態| ->J状態| | || | | 状態| | | | || | | regを取り外してください。| regを取り外してください。| アップデートreg| |(J)を接合してください。|| | | トンネル| トンネルを堀ってください。 | トンネル| | || | | | セットします。| | | || | | | 登録してください。| | | || | | | 停止| | | || | | | タイマ(*)| | +----------++----------+-----------+-----------+-----------+-----------+ | ||->J状態| - | ->Ni| ->P状態| ->J状態| | || | | 状態| | | |接合してください。||regを加えてください。| | | セットします。| regを加えてください。| |未定||トンネル| | | 登録してください。| トンネルを堀ってください。 | |(JP) || | | | 停止| キャンセル| | || | | | タイマ(*)| 登録してください。| | || | | | | タイマを止めてください。| +----------++----------+-----------+-----------+-----------+-----------+ | ||->JP| - | ->Ni| - | ->J状態| | ||状態| | 状態| | | | ||セットします。| | | | regを加えてください。| |プルーンの(p)||登録してください。| | | | トンネルを堀ってください。 | | ||停止| | | | キャンセル| | ||タイマ(**);、|| | | 登録してください。| | ||Nullを送ってください。| | | | タイマを止めてください。| | ||レジスタ| | | | | +----------++----------+-----------+-----------+-----------+-----------+
Notes:
注意:
(*) The Register-Stop Timer is set to a random value chosen
uniformly from the interval ( 0.5 * Register_Suppression_Time,
1.5 * Register_Suppression_Time) minus Register_Probe_Time.
(*) Register-停止TimerはRegister_Probe_Timeを引いて間隔(__0.5*レジスタSuppression_Time、1.5*レジスタSuppression_Time)から一様に選ばれた無作為の値へのセットです。
Fenner, et al. Standards Track [Page 39] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[39ページ]。
Subtracting off Register_Probe_Time is a bit unnecessary because
it is really small compared to Register_Suppression_Time, but
this was in the old spec and is kept for compatibility.
Register_Suppression_Timeと比べて、それが本当に小さいのですが、これが古い仕様にあって、互換性のために保たれるので、Register_Probe_Timeで引くのは少し不要です。
(**) The Register-Stop Timer is set to Register_Probe_Time.
(**) Register-停止TimerはRegister_Probe_Timeに用意ができています。
The following three actions are defined:
以下の3つの動作が定義されます:
Add Register Tunnel
レジスタトンネルを加えてください。
A Register-Tunnel virtual interface, VI, is created (if it doesn't
already exist) with its encapsulation target being RP(G).
DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel
interface to be added to immediate_olist(S,G) and
inherited_olist(S,G).
Register-トンネルの仮想インターフェース(VI)はRP(G)であるカプセル化目標で作成されます(既に存在していないなら)。 トンネルのインタフェースが即座の_olist(S、G)と引き継いでいる_olist(S、G)に加えられることを引き起こして、DownstreamJPState(S、G、VI)はJoin状態に用意ができています。
Remove Register Tunnel
レジスタトンネルを取り外してください。
VI is the Register-Tunnel virtual interface with encapsulation
target of RP(G). DownstreamJPState(S,G,VI) is set to NoInfo
state, causing the tunnel interface to be removed from
immediate_olist(S,G) and inherited_olist(S,G). If
DownstreamJPState(S,G,VI) is NoInfo for all (S,G), then VI can be
deleted.
VIはRP(G)のカプセル化目標とのRegister-トンネルの仮想インターフェースです。 トンネルのインタフェースが即座の_olist(S、G)と引き継いでいる_olist(S、G)から取り除かれることを引き起こして、DownstreamJPState(S、G、VI)はNoInfo状態に用意ができています。 DownstreamJPState(S、G、VI)がすべて(S、G)のためのNoInfoであるなら、VIを削除できます。
Update Register Tunnel
アップデートレジスタトンネル
This action occurs when RP(G) changes.
RP(G)が変化すると、この動作は起こります。
VI_old is the Register-Tunnel virtual interface with encapsulation
target old_RP(G). A Register-Tunnel virtual interface, VI_new, is
created (if it doesn't already exist) with its encapsulation
target being new_RP(G). DownstreamJPState(S,G,VI_old) is set to
NoInfo state and DownstreamJPState(S,G,VI_new) is set to Join
state. If DownstreamJPState(S,G,VI_old) is NoInfo for all (S,G),
then VI_old can be deleted.
VI_老人はカプセル化目標老人_RP(G)とのRegister-トンネルの仮想インターフェースです。 VI_新しいRegister-トンネルの仮想インターフェースは新しい_RP(G)であるカプセル化目標で作成されます(既に存在していないなら)。 DownstreamJPState(S、G、VI_老人)はNoInfo状態に用意ができています、そして、DownstreamJPState(Gの、そして、VI_新しいS)はJoin状態に用意ができています。 DownstreamJPState(S、G、VI_老人)がすべて(S、G)のためのNoInfoであるなら、VI_老人を削除できます。
Note that we cannot simply change the encapsulation target of
VI_old because not all groups using that encapsulation tunnel will
have moved to the same new RP.
そのカプセル化トンネルを使用するというわけではないすべてのグループが同じ新しいRPに動いてしまうだろうので私たちが古い状態でVI_のカプセル化目標を絶対に変えることができないことに注意してください。
Fenner, et al. Standards Track [Page 40] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[40ページ]。
CouldRegister(S,G)
CouldRegister(S、G)
The macro "CouldRegister" in the state machine is defined as:
州のマシンのマクロ"CouldRegister"は以下と定義されます。
bool CouldRegister(S,G) {
return ( I_am_DR( RPF_interface(S) ) AND
KeepaliveTimer(S,G) is running AND
DirectlyConnected(S) == TRUE )
}
bool CouldRegister(S、G)リターン、(I_は_DR(KeepaliveTimer(S、G)が走らせているRPF_インタフェース(S) )ANDとDirectlyConnected(S)=TRUE)です。
Note that on reception of a packet at the DR from a directly
connected source, KeepaliveTimer(S,G) needs to be set by the
packet forwarding rules before computing CouldRegister(S,G) in the
register state machine, or the first packet from a source won't be
registered.
直接接続されたソース、レジスタ州のマシンでCouldRegister(S、G)を計算する前に規則を進めるパケットによって設定されるべきKeepaliveTimer(S、G)の必要性、またはソースからの最初のパケットからのDRのパケットのレセプションのそれが登録されないことに注意してください。
Encapsulating Data Packets in the Register Tunnel
レジスタトンネルでデータ・パケットをカプセルに入れります。
Conceptually, the Register Tunnel is an interface with a smaller
MTU than the underlying IP interface towards the RP. IP
fragmentation on packets forwarded on the Register Tunnel is
performed based upon this smaller MTU. The encapsulating DR may
perform Path MTU Discovery to the RP to determine the effective
MTU of the tunnel. Fragmentation for the smaller MTU should take
both the outer IP header and the PIM register header overhead into
account. If a multicast packet is fragmented on the way into the
Register Tunnel, each fragment is encapsulated individually so it
contains IP, PIM, and inner IP headers.
概念的に、Register TunnelはRPに向かった基本的なIPインタフェースより小さいMTUとのインタフェースです。 Register Tunnelで進められたパケットにおけるIP断片化はこのより小さいMTUに基づいた状態で実行されます。 要約のDRは、トンネルの有効なMTUを決定するためにPath MTUディスカバリーをRPに実行するかもしれません。 より小さいMTUのための断片化は外側のIPヘッダーを両方に連れて行くべきです、そして、PIMはヘッダーオーバーヘッドをアカウントに示します。 マルチキャストパケットが途中でRegister Tunnelに断片化されるなら、各断片が個別にカプセルに入れられるので、それはIP、PIM、および内側のIPヘッダーを含んでいます。
In IPv6, the DR MUST perform Path MTU discovery, and an ICMP
Packet Too Big message MUST be sent by the encapsulating DR if it
receives a packet that will not fit in the effective MTU of the
tunnel. If the MTU between the DR and the RP results in the
effective tunnel MTU being smaller than 1280 (the IPv6 minimum
MTU), the DR MUST send Fragmentation Required messages with an MTU
value of 1280 and MUST fragment its PIM register messages as
required, using an IPv6 fragmentation header between the outer
IPv6 header and the PIM Register header.
IPv6では、博士はPath MTU発見を実行しなければなりません、そして、それがトンネルの有効なMTUをうまくはめ込まないパケットを受けるなら、要約のDRはICMP Packet Too Bigメッセージを送らなければなりません。 DRとRPの間のMTUが1280年(IPv6の最小のMTU)より小さい有効なトンネルMTUをもたらすなら、博士は、1280年のMTU値があるメッセージをFragmentation Requiredに送らなければならなくて、必要に応じてPIMレジスタメッセージを断片化しなければなりません、外側のIPv6ヘッダーとPIM Registerヘッダーの間のIPv6断片化ヘッダーを使用して。
The TTL of a forwarded data packet is decremented before it is
encapsulated in the Register Tunnel. The encapsulating packet
uses the normal TTL that the router would use for any locally-
generated IP packet.
それがRegister Tunnelで要約される前に進められたデータ・パケットのTTLは減少します。 要約パケットはルータがどんな局所的に発生したIPパケットにも使用する正常なTTLを使用します。
The IP ECN bits should be copied from the original packet to the
IP header of the encapsulating packet. They SHOULD NOT be set
independently by the encapsulating router.
IP電子証券取引ネットワークビットはオリジナルのパケットから要約パケットのIPヘッダーまでコピーされるべきです。 それら、SHOULD NOT、要約ルータによって独自に設定されてください。
Fenner, et al. Standards Track [Page 41] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[41ページ]。
The Diffserv Code Point (DSCP) should be copied from the original
packet to the IP header of the encapsulating packet. It MAY be
set independently by the encapsulating router, based upon static
configuration or traffic classification. See [12] for more
discussion on setting the DSCP on tunnels.
Diffserv Code Point(DSCP)はオリジナルのパケットから要約パケットのIPヘッダーまでコピーされるべきです。 それは静的な構成か交通分類に基づく要約ルータによって独自に設定されるかもしれません。 トンネルにDSCPをけしかけるのと、より多くの議論のための[12]を見てください。
Handling Register-Stop(*,G) Messages at the DR
DRの取り扱いレジスタ停止(*、G)メッセージ
An old RP might send a Register-Stop message with the source
address set to all zeros. This was the normal course of action in
RFC 2362 when the Register message matched against (*,G) state at
the RP, and it was defined as meaning "stop encapsulating all
sources for this group". However, the behavior of such a
Register-Stop(*,G) is ambiguous or incorrect in some
circumstances.
古いRPはソースアドレスセットがあるRegister-停止メッセージをすべてのゼロに送るかもしれません。 これはRegisterメッセージがRPで(*、G)状態に対して合っていたRFC2362年の通常の行動でした、そして、「このグループのためにすべてのソースを要約するのを止めます」と意味するとそれは定義されました。 しかしながら、そのようなRegister-停止(*、G)の振舞いは、中であいまいであるか、または不正確です。いくつかの事情。
We specify that an RP should not send Register-Stop(*,G) messages,
but for compatibility, a DR should be able to accept one if it is
received.
私たちは、RPがRegister-停止(*、G)メッセージを送るはずがないと指定しますが、それが受け取られているなら、互換性において、DRは1つを受け入れるはずであることができます。
A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for
all (S,G) Register state machines that are not in the NoInfo
state. A router should not apply a Register-Stop(*,G) to sources
that become active after the Register-Stop(*,G) was received.
Register-停止(*、G)はNoInfo状態にないレジスタ州のマシンのためのRegister-停止(S、G)として扱われるべきです。 ルータはRegister-停止(*、G)を受けた後にアクティブになるソースにRegister-停止(*、G)を適用するべきではありません。
Fenner, et al. Standards Track [Page 42] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[42ページ]。
4.4.2. Receiving Register Messages at the RP
4.4.2. RPにレジスタメッセージを受け取ります。
When an RP receives a Register message, the course of action is decided according to the following pseudocode:
RPがRegisterメッセージを受け取るとき、以下の擬似コードによると、行動は決められます:
packet_arrives_on_rp_tunnel( pkt ) {
if( outer.dst is not one of my addresses ) {
drop the packet silently.
# Note: this may be a spoofing attempt
}
if( I_am_RP(G) AND outer.dst == RP(G) ) {
sentRegisterStop = FALSE;
if ( register.borderbit == TRUE ) {
if ( PMBR(S,G) == unknown ) {
PMBR(S,G) = outer.src
} else if ( outer.src != PMBR(S,G) ) {
send Register-Stop(S,G) to outer.src
drop the packet silently.
}
}
if ( SPTbit(S,G) OR
( SwitchToSptDesired(S,G) AND
( inherited_olist(S,G) == NULL ))) {
send Register-Stop(S,G) to outer.src
sentRegisterStop = TRUE;
}
if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
if ( sentRegisterStop == TRUE ) {
set KeepaliveTimer(S,G) to RP_Keepalive_Period;
} else {
set KeepaliveTimer(S,G) to Keepalive_Period;
}
}
if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
decapsulate and forward the inner packet to
inherited_olist(S,G,rpt) # Note (+)
}
} else {
send Register-Stop(S,G) to outer.src
# Note (*)
}
}
パケット_が届く、_rp_トンネル(pkt)の上の_{ (outer.dstは私のアドレスの1つではありません){ 静かにパケットを落としてください。 # 以下に注意してください。 これがスプーフィング試みであるかもしれない、(I_は_RP(G) AND outer.dst=RP(G) )です。{ sentRegisterStopは偽と等しいです。 (register.borderbit=TRUE)です。{ ほかの(PMBR(S、G)=未知)PMBR(S、G)=outer.srcである、(outer.src!=PMBR(S、G))である、静かにouter.srcへのRegister-停止(S、G)低下にパケットを送ってください。 (SPTbit(S、G)OR(SwitchToSptDesired(S、G)と(引き継いでいる_olist(S、G)=NULL)))である、Register-停止(S、G)をouter.src sentRegisterStop=TRUEに送ってください。 (SPTbit(S、G)OR SwitchToSptDesired(S、G))である、(sentRegisterStop=TRUE)である、RP_Keepalive_PeriodにKeepaliveTimer(S、G)を設定してください。 ほか、KeepaliveTimer(S、G)をKeepalive_Periodに設定してください。 (SPTbit(S、G)AND!pkt.NullRegisterBit)が引き継いでいる_olist(S、Gはrptされる)#Note(+)に内側のパケットをdecapsulateして、送る、ほかに、Register-停止(S、G)をouter.src#Note(*)に送ってください。}
outer.dst is the IP destination address of the encapsulating header.
outer.dstは要約のヘッダーの受信者IPアドレスです。
outer.src is the IP source address of the encapsulating header, i.e., the DR's address.
outer.srcはすなわち、要約のヘッダー、DRのアドレスのIPソースアドレスです。
Fenner, et al. Standards Track [Page 43] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[43ページ]。
I_am_RP(G) is true if the group-to-RP mapping indicates that this router is the RP for the group.
I_による_グループからRPへのマッピングが、このルータがグループのためのRPであることを示すならRP(G)が本当であるということです。
Note (*): This may block traffic from S for Register_Suppression_Time
if the DR learned about a new group-to-RP mapping before the RP
did. However, this doesn't matter unless we figure out some way
for the RP also to accept (*,G) joins when it doesn't yet realize
that it is about to become the RP for G. This will all get sorted
out once the RP learns the new group-to-rp mapping. We decided to
do nothing about this and just accept the fact that PIM may suffer
interrupted (*,G) connectivity following an RP change.
注意(*): DRがグループからRPへの新しいマッピングに関して学んだなら、RPが交通の妨害になる前にこれはRegister_Suppression_TimeのためのSから交通の妨害になるかもしれません。 しかしながら、私たちが、RPがいったんグループからrpへの新しいマッピングを学ぶとThisがすべて、整理させるG.のためのRPになろうとしているのがまだ換金されていないとき、また、RPが受け入れる何らかの方法(*、G)が接合するのを理解しないなら、これは重要ではありません。 私たちは、これに関して何もしないで、ただ、RP変化に続いて、PIMが中断している(*、G)接続性を受けるかもしれないという事実を認めると決めました。
Note (+): Implementations are advised not to make this a special
case, but to arrange that this path rejoin the normal packet
forwarding path. All of the appropriate actions from the "On
receipt of data from S to G on interface iif" pseudocode in
Section 4.2 should be performed.
以下に注意してください(+)。 実現がこれを特別なケースにしないように教えられます、しかし、それをアレンジするために、この経路は正常なパケット推進経路に再び加わります。 セクション4.2の「インタフェースiifに関するSからGまでのデータを受け取り次第」擬似コードからの適切な行動のすべてが実行されるべきです。
KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the proper tunnel interface and the RP desires to switch to the SPT or the SPTbit is already set. This may cause the upstream (S,G) state machine to trigger a join if the inherited_olist(S,G) is not NULL.
パケットが適切なトンネルのインタフェースとSPTに切り替わるRP願望で到着するとき、KeepaliveTimer(S、G)がRPで再開されるか、またはSPTbitは既に用意ができます。 これは引き継いでいる_olist(S、G)がNULLでないなら上流(S、G)の州のマシンをaが接合する引き金に引き起こすかもしれません。
An RP should preserve (S,G) state that was created in response to a Register message for at least ( 3 * Register_Suppression_Time ); otherwise, the RP may stop joining (S,G) before the DR for S has restarted sending registers. Traffic would then be interrupted until the Register-Stop Timer expires at the DR.
RPは少なくとも(3*レジスタ_Suppression_Time)へのRegisterメッセージに対応して創設された状態を保持するはずです(S、G)。 さもなければ、SのためのDRが再開する前にRPは、レジスタを送りながら、(S、G)を接合するのを止めるかもしれません。 そして、Register-停止TimerがDRで期限が切れるまで、交通は中断されるでしょう。
Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Register_Suppression_Time + Register_Probe_Time ).
したがって、RPでは、KeepaliveTimer(S、G)は(3*レジスタ_Suppression_Time+レジスタ_Probe_Time)に再開されるべきです。
When forwarding a packet from the Register Tunnel, the TTL of the original data packet is decremented after it is decapsulated.
Register Tunnelからパケットを進めるとき、それがdecapsulatedされた後にオリジナルのデータ・パケットのTTLは減少します。
The IP ECN bits should be copied from the IP header of the Register packet to the decapsulated packet.
IP電子証券取引ネットワークビットはRegisterパケットのIPヘッダーからdecapsulatedパケットまでコピーされるべきです。
The Diffserv Code Point (DSCP) should be copied from the IP header of the Register packet to the decapsulated packet. The RP MAY retain the DSCP of the inner packet or re-classify the packet and apply a different DSCP. Scenarios where each of these might be useful are discussed in [12].
Diffserv Code Point(DSCP)はRegisterパケットのIPヘッダーからdecapsulatedパケットまでコピーされるべきです。 RP MAYは内側のパケットのDSCPを保有するか、パケットに分類し直して、または異なったDSCPを適用します。 [12]でそれぞれのこれらが役に立つかもしれないシナリオについて議論します。
Fenner, et al. Standards Track [Page 44] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[44ページ]。
4.5. PIM Join/Prune Messages
4.5. PIMはメッセージを接合するか、または剪定します。
A PIM Join/Prune message consists of a list of groups and a list of Joined and Pruned sources for each group. When processing a received Join/Prune message, each Joined or Pruned source for a Group is effectively considered individually, and applies to one or more of the following state machines. When considering a Join/Prune message whose Upstream Neighbor Address field addresses this router, (*,G) Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream state machines, while (*,*,RP), (S,G), and (S,G,rpt) Joins and Prunes can only affect their respective downstream state machines. When considering a Join/Prune message whose Upstream Neighbor Address field addresses another router, most Join or Prune messages could affect each upstream state machine.
PIM Join/プルーンのメッセージは各グループのためのグループのリストとJoinedとPrunedソースのリストから成ります。 容認されたJoin/プルーンのメッセージを処理するとき、GroupのためのそれぞれのJoinedかPrunedソースが、事実上、個別に考えられて、以下の州のマシンの1つ以上に当てはまります。 Upstream Neighbor Address分野がこのルータを記述するJoin/プルーンのメッセージを考えるとき、(*、G)が接合して、Prunesが両方に影響できる、(*、G)、および(S、G、rpt)川下の州は(*、*、RP)である間の(S、G)を機械加工して、(S、G、rpt)は接合して、Prunesは彼らのそれぞれの川下の州のマシンに影響できるだけです。 Upstream Neighbor Address分野が別のルータを記述するJoin/プルーンのメッセージを考えるとき、ほとんどのJoinかPruneメッセージがそれぞれの上流の州のマシンに影響するかもしれません。
In general, a PIM Join/Prune message should only be accepted for processing if it comes from a known PIM neighbor. A PIM router hears about PIM neighbors through PIM Hello messages. If a router receives a Join/Prune message from a particular IP source address and it has not seen a PIM Hello message from that source address, then the Join/Prune message SHOULD be discarded without further processing. In addition, if the Hello message from a neighbor was authenticated using IPsec AH (see Section 6.3), then all Join/Prune messages from that neighbor MUST also be authenticated using IPsec AH.
一般に、知られているPIM隣人から来る場合にだけ、処理のためにPIM Join/プルーンのメッセージを受け入れるべきです。 PIMルータはPIM Helloメッセージを通してPIM隣人について聞きます。 ルータが受信されるなら、特定のIPソースアドレスとそれからのJoin/プルーンのメッセージは、そのソースアドレスからのPIM Helloメッセージ、次に、Join/プルーンのメッセージSHOULDがさらなる処理なしで捨てられるのを見ていません。 さらに、隣人からのHelloメッセージがIPsec AHを使用することで認証されたなら(セクション6.3を見てください)、また、IPsec AHを使用して、その隣人からのすべてのJoin/プルーンのメッセージを認証しなければなりません。
We note that some older PIM implementations incorrectly fail to send Hello messages on point-to-point interfaces, so we also RECOMMEND that a configuration option be provided to allow interoperation with such older routers, but that this configuration option SHOULD NOT be enabled by default.
私たちはいくつかの、より古いPIM実現が二地点間インタフェースで不当にメッセージをHelloに送らないで、そうが私たちであることに注意します、また、そのようなより古いルータがあるinteroperationを許容するために設定オプションがあるRECOMMENDを提供して、この構成がSHOULD NOTにゆだねていなかったなら、デフォルトで可能にされてください。
4.5.1. Receiving (*,*,RP) Join/Prune Messages
4.5.1. 受信して(*、*、RP)、メッセージを接合するか、または剪定してください。
The per-interface state machine for receiving (*,*,RP) Join/Prune Messages is given below. There are three states:
受信して、(*、*、RP)がMessagesから接合するか、または余計なものを取り除くので、1界面準位あたりのマシンを以下に与えます。 3つの州があります:
NoInfo (NI)
The interface has no (*,*,RP) Join state and no timers
running.
NoInfo、(NI) インタフェースで、いいえ(*、*、RP)は状態にもかかわらず、タイマ走行でないのを接合します。
Join (J)
The interface has (*,*,RP) Join state, which will cause the
router to forward packets destined for any group handled by RP
from this interface except if there is also (S,G,rpt) prune
information (see Section 4.5.4) or the router lost an assert
on this interface.
インタフェースでルータにまた(S、G、rpt)、プルーンの情報があったか(セクション4.5.4を見てください)、またはルータが損をしたのを除いて、RPによってこのインタフェースから扱われたどんなグループのためにも運命づけられたパケットを進めさせる州に加わる(*、*、RP)(J)を接合してください、このインタフェースでは、断言します。
Fenner, et al. Standards Track [Page 45] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[45ページ]。
Prune-Pending (PP)
The router has received a Prune(*,*,RP) on this interface from
a downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly
like the Join state.
ルータにはある未定のプルーン(PP)は、このインタフェースで川下の隣人からPrune(*、*、RP)を受けて、プルーンが別の川下のルータによってくつがえされるかどうかを見るのを待っています。 推進目的のために、未定のPrune状態はちょうどJoin状態のように機能します。
In addition, the state machine uses two timers:
さらに、州のマシンは2個のタイマを使用します:
ExpiryTimer (ET)
This timer is restarted when a valid Join(*,*,RP) is received.
Expiry of the ExpiryTimer causes the interface state to revert
to NoInfo for this RP.
ExpiryTimer、(ET) 有効なJoin(*、*、RP)が受け取られているとき、このタイマは再開されます。 ExpiryTimerの満期で、界面準位はこのRPのためにNoInfoに戻ります。
Prune-Pending Timer (PPT)
This timer is set when a valid Prune(*,*,RP) is received.
Expiry of the Prune-Pending Timer causes the interface state
to revert to NoInfo for this RP.
未定のプルーンのTimer、(PPT) 有効なPrune(*、*、RP)が受け取られているとき、このタイマは設定されます。 未定のPrune Timerの満期で、界面準位はこのRPのためにNoInfoに戻ります。
Figure 2: Downstream per-interface (*,*,RP) state machine
in tabular form
図2: 表フォームでの川下のインタフェース(*、*、RP)州のマシン
+------------++--------------------------------------------------------+ | || Event | | ++-------------+-------------+--------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,*,RP) | Prune | Pending | Expires | | || | (*,*,RP) | Timer | | | || | | Expires | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune-| | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+-------------+--------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,*,RP) | | +------------++-------------+-------------+--------------+-------------+
+------------++--------------------------------------------------------+ | || 出来事| | ++-------------+-------------+--------------+-------------+ |Prev状態||受信してください。| 受信してください。| プルーン| 満期タイマ| | ||(*、*、RP)を接合してください。| プルーン| 未定| 期限が切れます。| | || | (*、*、RP) | タイマ| | | || | | 期限が切れます。| | +------------++-------------+-------------+--------------+-------------+ | ||->J状態| ->NI状態| - | - | |NoInfo(Ni)||Expiryを始動してください。| | | | | ||タイマ| | | | +------------++-------------+-------------+--------------+-------------+ | ||->J状態| ->PP状態| - | ->NI状態| |(J)を接合してください。||再開| Pruneを始動してください。| | | | ||満期タイマ| 未定| | | | || | タイマ| | | +------------++-------------+-------------+--------------+-------------+ |プルーン||->J状態| ->PP状態| ->NI状態| ->NI状態| |未定の(pp)||再開| | プルーンを送ってください。| | | ||満期タイマ| | (*、*、RP)を反響してください。| | +------------++-------------+-------------+--------------+-------------+
Fenner, et al. Standards Track [Page 46] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[46ページ]。
The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines.
」 (*、*、RP)「プルーン(*、*、RP)を受けてください」を接合してください。変遷出来事、「受信、JoinかPruneが容認されたインタフェースに関するこのルータの第一のIPアドレスに狙った受信を含意してください。 上流の隣人アドレス・フィールドが正しくないなら、そのようなパケットが他の州のマシンで状態遷移を引き起こすかもしれないのがわかりますが、この州のマシンのこれらの状態遷移は起こってはいけません。
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
ポイントツーポイント接続の上の無数のインタフェースでは、ルータのアドレスはそれがそのインタフェースの上で送ったHelloメッセージに選んだソースアドレスと同じであるべきです。 しかしながら、また、ポイントからポイントへのまた私たちが後方にようにそれを推薦するリンクの上では、すべてのゼロの上流の隣人アドレス・フィールドがある互換性PIM Join/プルーンのメッセージを受け入れます。
Transitions from NoInfo State
NoInfo状態からの変遷
When in NoInfo state, the following event may trigger a transition:
以下の出来事がNoInfo状態で変遷の引き金となるかもしれないなら:
Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたJoin(*、*、RP)A Join(*、*、RP)を受けてください。
The (*,*,RP) downstream state machine on interface I
transitions to the Join state. The Expiry Timer (ET) is
started and set to the HoldTime from the triggering Join/Prune
message.
インタフェースIの(*、*、RP)川下の州のマシンはJoin状態に移行します。 Expiry Timer(ET)は引き金となっているJoin/プルーンのメッセージからHoldTimeに始動されて、用意ができています。
Note that it is possible to receive a Join(*,*,RP) message for
an RP for which we do not have information telling us that it
is an RP. In the case of (*,*,RP) state, so long as we have a
route to the RP, this will not cause a problem, and the
transition should still take place.
私たちがそれがRPであると私たちに言う情報を持っていないRPへのJoin(*、*、RP)メッセージを受け取るのが可能であることに注意してください。 (*、*、RP)状態の場合では、私たちがRPにルートを持っている限り、これは問題を引き起こさないでしょう、そして、変遷はまだ行われているべきです。
Transitions from Join State
移行する、状態に加わってください。
When in Join state, the following events may trigger a transition:
以下の出来事がJoin状態で変遷の引き金となるかもしれないなら:
Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたJoin(*、*、RP)A Join(*、*、RP)を受けてください。
The (*,*,RP) downstream state machine on interface I remains
in Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the
triggering Join/Prune message.
私がJoin状態、およびExpiry Timerに留まるインタフェースの(*、*、RP)川下の州のマシンは再開されて(ET)、現行価値と引き金となるのからのHoldTimeの最大へのセットはJoin/プルーンのメッセージです。
Fenner, et al. Standards Track [Page 47] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[47ページ]。
Receive Prune(*,*,RP)
A Prune(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたPrune(*、*、RP)A Prune(*、*、RP)を受けてください。
The (*,*,RP) downstream state machine on interface I
transitions to the Prune-Pending state. The Prune-Pending
Timer is started. It is set to the J/P_Override_Interval(I)
if the router has more than one neighbor on that interface;
otherwise, it is set to zero, causing it to expire
immediately.
インタフェースIの(*、*、RP)川下の州のマシンは未定のPrune状態に移行します。 未定のPrune Timerは始動されます。 ルータに1人以上の隣人がそのインタフェースにいるなら、それは_J/P Override_Interval(I)に設定されます。 さもなければ、それがすぐに期限が切れることを引き起こして、それはゼロに設定されます。
Expiry Timer Expires
The Expiry Timer for the (*,*,RP) downstream state machine on
interface I expires.
(*、*、RP)川下への満期Timer Expires Expiry Timerは私が吐き出すインタフェースにマシンを述べます。
The (*,*,RP) downstream state machine on interface I
transitions to the NoInfo state.
インタフェースIの(*、*、RP)川下の州のマシンはNoInfo状態に移行します。
Transitions from Prune-Pending State
未定のプルーンの状態からの変遷
When in Prune-Pending state, the following events may trigger a transition:
以下の出来事が未定のPrune状態で変遷の引き金となるかもしれないなら:
Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたJoin(*、*、RP)A Join(*、*、RP)を受けてください。
The (*,*,RP) downstream state machine on interface I
transitions to the Join state. The Prune-Pending Timer is
canceled (without triggering an expiry event). The Expiry
Timer is restarted, set to maximum of its current value and
the HoldTime from the triggering Join/Prune message.
インタフェースIの(*、*、RP)川下の州のマシンはJoin状態に移行します。 未定のPrune Timerは取り消されます(満期出来事の引き金とならないで)。 Expiry Timerは再開されて、現行価値と引き金となるのからのHoldTimeの最大へのセットはJoin/プルーンのメッセージです。
Expiry Timer Expires
The Expiry Timer for the (*,*,RP) downstream state machine on
interface I expires.
(*、*、RP)川下への満期Timer Expires Expiry Timerは私が吐き出すインタフェースにマシンを述べます。
The (*,*,RP) downstream state machine on interface I
transitions to the NoInfo state.
インタフェースIの(*、*、RP)川下の州のマシンはNoInfo状態に移行します。
Prune-Pending Timer Expires
The Prune-Pending Timer for the (*,*,RP) downstream state
machine on interface I expires.
(*、*、RP)川下への未定のプルーンのTimer Expires未定のPrune Timerは私が吐き出すインタフェースにマシンを述べます。
The (*,*,RP) downstream state machine on interface I
transitions to the NoInfo state. A PruneEcho(*,*,RP) is sent
onto the subnet connected to interface I.
インタフェースIの(*、*、RP)川下の州のマシンはNoInfo状態に移行します。 PruneEcho(*、*、RP)による送って、サブネットに、私が連結するように接続したということです。
Fenner, et al. Standards Track [Page 48] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[48ページ]。
The action "Send PruneEcho(*,*,RP)" is triggered when the
router stops forwarding on an interface as a result of a
prune. A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) message
sent by the upstream router on a LAN with its own address in
the Upstream Neighbor Address field. Its purpose is to add
additional reliability so that if a Prune that should have
been overridden by another router is lost locally on the LAN,
then the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,*,RP) need not be sent on an interface
that contains only a single PIM neighbor during the time this
state machine was in Prune-Pending state.
ルータが、プルーンの結果、インタフェースで進めるのを止めると、動作「PruneEcho(*、*、RP)を送ってください」は引き起こされます。 PruneEcho(*、*、RP)は単にそれ自身のアドレスがUpstream Neighbor Address分野にあるLANの上流のルータによって送られたPrune(*、*、RP)メッセージです。 目的は、LANで局所的に別のルータによってくつがえされるべきであったPruneをなくすならPruneEchoを受け取ることができるように追加信頼性を言い足して、オーバーライドが起こることを引き起こすことです。 この州のマシンが未定のPrune状態にあった時独身のPIM隣人だけを含むインタフェースでPruneEcho(*、*、RP)を送る必要はありません。
4.5.2. Receiving (*,G) Join/Prune Messages
4.5.2. 受信して(*、G)、メッセージを接合するか、または剪定してください。
When a router receives a Join(*,G), it must first check to see whether the RP in the message matches RP(G) (the router's idea of who the RP is). If the RP in the message does not match RP(G), the Join(*,G) should be silently dropped. (Note that other source list entries, such as (S,G,rpt) or (S,G), in the same Group-Specific Set should still be processed.) If a router has no RP information (e.g., has not recently received a BSR message), then it may choose to accept Join(*,G) and treat the RP in the message as RP(G). Received Prune(*,G) messages are processed even if the RP in the message does not match RP(G).
ルータがJoin(*、G)を受けるとき、それは、最初に、メッセージのRPがRP(G)(RPがだれであるかに関するルータの考え)に合っているかどうか確認するためにチェックしなければなりません。 メッセージのRPがRP(G)に合っていないなら、Join(*、G)は静かに落とされるべきです。 (他の情報筋が(S、G、rpt)などのエントリーを記載することに注意してください。さもないと、(S、G)は同じGroup特有のSetでまだ処理されているべきです。) ルータにRP情報(例えば、最近、BSRメッセージを受け取っていない)が全くないなら、それは、Join(*、G)を受け入れて、メッセージのRPをRP(G)として扱うのを選ぶかもしれません。 メッセージのRPがRP(G)に合わないでも、容認されたPrune(*、G)メッセージは処理されます。
The per-interface state machine for receiving (*,G) Join/Prune Messages is given below. There are three states:
受信して、(*、G)がMessagesから接合するか、または余計なものを取り除くので、1界面準位あたりのマシンを以下に与えます。 3つの州があります:
NoInfo (NI)
The interface has no (*,G) Join state and no timers running.
NoInfo、(NI) インタフェースで、いいえ(*、G)は状態にもかかわらず、タイマ走行でないのを接合します。
Join (J)
The interface has (*,G) Join state, which will cause the
router to forward packets destined for G from this interface
except if there is also (S,G,rpt) prune information (see
Section 4.5.4) or the router lost an assert on this interface.
インタフェースでルータにまた(S、G、rpt)、プルーンの情報があったか(セクション4.5.4を見てください)、またはルータが損をしたのを除いて、このインタフェースからのGのために運命づけられたパケットを進めさせる州に加わる(*、G)(J)を接合してください、このインタフェースでは、断言します。
Prune-Pending (PP)
The router has received a Prune(*,G) on this interface from a
downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly
like the Join state.
ルータにはある未定のプルーン(PP)は、このインタフェースで川下の隣人からPrune(*、G)を受けて、プルーンが別の川下のルータによってくつがえされるかどうかを見るのを待っています。 推進目的のために、未定のPrune状態はちょうどJoin状態のように機能します。
Fenner, et al. Standards Track [Page 49] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[49ページ]。
In addition, the state machine uses two timers:
さらに、州のマシンは2個のタイマを使用します:
Expiry Timer (ET)
This timer is restarted when a valid Join(*,G) is received.
Expiry of the Expiry Timer causes the interface state to
revert to NoInfo for this group.
有効なJoin(*、G)が受け取られているこのタイマが再開される満期Timer(ET)。 Expiry Timerの満期で、界面準位はこのグループのためにNoInfoに戻ります。
Prune-Pending Timer (PPT)
This timer is set when a valid Prune(*,G) is received. Expiry
of the Prune-Pending Timer causes the interface state to
revert to NoInfo for this group.
未定のプルーンのTimer、(PPT) 有効なPrune(*、G)が受け取られているとき、このタイマは設定されます。 未定のPrune Timerの満期で、界面準位はこのグループのためにNoInfoに戻ります。
Figure 3: Downstream per-interface (*,G) state machine in tabular form
図3: 表フォームでの川下のインタフェース(*、G)州のマシン
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,G) | Prune(*,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,G) | | +------------++-------------+--------------+-------------+-------------+
+------------++--------------------------------------------------------+ | || 出来事| | ++-------------+--------------+-------------+-------------+ |Prev状態||受信してください。| 受信してください。| プルーン| 満期タイマ| | ||(*、G)を接合してください。| (*、G)を剪定してください。| 未定| 期限が切れます。| | || | | タイマ| | | || | | 期限が切れます。| | +------------++-------------+--------------+-------------+-------------+ | ||->J状態| ->NI状態| - | - | |NoInfo(Ni)||Expiryを始動してください。| | | | | ||タイマ| | | | +------------++-------------+--------------+-------------+-------------+ | ||->J状態| ->PP状態| - | ->NI状態| |(J)を接合してください。||再開| Pruneを始動してください。| | | | ||満期タイマ| 未定| | | | || | タイマ| | | +------------++-------------+--------------+-------------+-------------+ |プルーン||->J状態| ->PP状態| ->NI状態| ->NI状態| |未定の(pp)||再開| | プルーンを送ってください。| | | ||満期タイマ| | (*、G)を反響してください。| | +------------++-------------+--------------+-------------+-------------+
The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines.
」 (*、G)「プルーン(*、G)を受けてください」を接合してください。変遷出来事、「受信、JoinかPruneが容認されたインタフェースに関するこのルータの第一のIPアドレスに狙った受信を含意してください。 上流の隣人アドレス・フィールドが正しくないなら、そのようなパケットが他の州のマシンで状態遷移を引き起こすかもしれないのがわかりますが、この州のマシンのこれらの状態遷移は起こってはいけません。
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to-
ポイントツーポイント接続の上の無数のインタフェースでは、ルータのアドレスはそれがそのインタフェースの上で送ったHelloメッセージに選んだソースアドレスと同じであるべきです。 しかしながら、オンである、指摘、-
Fenner, et al. Standards Track [Page 50] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[50ページ]。
point links we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
また私たちが推薦するまたすべてのゼロの上流の隣人アドレス・フィールドがある遅れている互換性PIM Join/プルーンのメッセージのために受け入れられるリンクを指してください。
Transitions from NoInfo State
NoInfo状態からの変遷
When in NoInfo state, the following event may trigger a transition:
以下の出来事がNoInfo状態で変遷の引き金となるかもしれないなら:
Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたJoin(*、G)A Join(*、G)を受けてください。
The (*,G) downstream state machine on interface I transitions
to the Join state. The Expiry Timer (ET) is started and set
to the HoldTime from the triggering Join/Prune message.
インタフェースIの(*、G)川下の州のマシンはJoin状態に移行します。 Expiry Timer(ET)は引き金となっているJoin/プルーンのメッセージからHoldTimeに始動されて、用意ができています。
Transitions from Join State
移行する、状態に加わってください。
When in Join state, the following events may trigger a transition:
以下の出来事がJoin状態で変遷の引き金となるかもしれないなら:
Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたJoin(*、G)A Join(*、G)を受けてください。
The (*,G) downstream state machine on interface I remains in
Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the
triggering Join/Prune message.
私がJoin状態、およびExpiry Timerに留まるインタフェースの(*、G)川下の州のマシンは再開されて(ET)、現行価値と引き金となるのからのHoldTimeの最大へのセットはJoin/プルーンのメッセージです。
Receive Prune(*,G)
A Prune(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたPrune(*、G)A Prune(*、G)を受けてください。
The (*,G) downstream state machine on interface I transitions
to the Prune-Pending state. The Prune-Pending Timer is
started. It is set to the J/P_Override_Interval(I) if the
router has more than one neighbor on that interface;
otherwise, it is set to zero, causing it to expire
immediately.
インタフェースIの(*、G)川下の州のマシンは未定のPrune状態に移行します。 未定のPrune Timerは始動されます。 ルータに1人以上の隣人がそのインタフェースにいるなら、それは_J/P Override_Interval(I)に設定されます。 さもなければ、それがすぐに期限が切れることを引き起こして、それはゼロに設定されます。
Expiry Timer Expires
The Expiry Timer for the (*,G) downstream state machine on
interface I expires.
(*、G)川下への満期Timer Expires Expiry Timerは私が吐き出すインタフェースにマシンを述べます。
The (*,G) downstream state machine on interface I transitions
to the NoInfo state.
インタフェースIの(*、G)川下の州のマシンはNoInfo状態に移行します。
Fenner, et al. Standards Track [Page 51] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[51ページ]。
Transitions from Prune-Pending State
未定のプルーンの状態からの変遷
When in Prune-Pending state, the following events may trigger a transition:
以下の出来事が未定のPrune状態で変遷の引き金となるかもしれないなら:
Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I.
Upstream Neighbor AddressとのインタフェースIにIに関するルータの第一のIPアドレスに設定されて、受け取られたJoin(*、G)A Join(*、G)を受けてください。
The (*,G) downstream state machine on interface I transitions
to the Join state. The Prune-Pending Timer is canceled
(without triggering an expiry event). The Expiry Timer is
restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
インタフェースIの(*、G)川下の州のマシンはJoin状態に移行します。 未定のPrune Timerは取り消されます(満期出来事の引き金とならないで)。 Expiry Timerは再開されて、現行価値と引き金となるのからのHoldTimeの最大へのセットはJoin/プルーンのメッセージです。
Expiry Timer Expires
The Expiry Timer for the (*,G) downstream state machine on
interface I expires.
(*、G)川下への満期Timer Expires Expiry Timerは私が吐き出すインタフェースにマシンを述べます。
The (*,G) downstream state machine on interface I transitions
to the NoInfo state.
インタフェースIの(*、G)川下の州のマシンはNoInfo状態に移行します。
Prune-Pending Timer Expires
The Prune-Pending Timer for the (*,G) downstream state machine
on interface I expires.
(*、G)川下への未定のプルーンのTimer Expires未定のPrune Timerは私が吐き出すインタフェースにマシンを述べます。
The (*,G) downstream state machine on interface I transitions
to the NoInfo state. A PruneEcho(*,G) is sent onto the subnet
connected to interface I.
インタフェースIの(*、G)川下の州のマシンはNoInfo状態に移行します。 PruneEcho(*、G)による送って、サブネットに、私が連結するように接続したということです。
The action "Send PruneEcho(*,G)" is triggered when the router
stops forwarding on an interface as a result of a prune. A
PruneEcho(*,G) is simply a Prune(*,G) message sent by the
upstream router on a LAN with its own address in the Upstream
Neighbor Address field. Its purpose is to add additional
reliability so that if a Prune that should have been
overridden by another router is lost locally on the LAN, then
the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,G) need not be sent on an interface
that contains only a single PIM neighbor during the time this
state machine was in Prune-Pending state.
ルータが、プルーンの結果、インタフェースで進めるのを止めると、動作「PruneEcho(*、G)を送ってください」は引き起こされます。 PruneEcho(*、G)は単にそれ自身のアドレスがUpstream Neighbor Address分野にあるLANの上流のルータによって送られたPrune(*、G)メッセージです。 目的は、LANで局所的に別のルータによってくつがえされるべきであったPruneをなくすならPruneEchoを受け取ることができるように追加信頼性を言い足して、オーバーライドが起こることを引き起こすことです。 この州のマシンが未定のPrune状態にあった時独身のPIM隣人だけを含むインタフェースでPruneEcho(*、G)を送る必要はありません。
Fenner, et al. Standards Track [Page 52] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[52ページ]。
4.5.3. Receiving (S,G) Join/Prune Messages
4.5.3. 受信して(S、G)、メッセージを接合するか、または剪定してください。
The per-interface state machine for receiving (S,G) Join/Prune messages is given below and is almost identical to that for (*,G) messages. There are three states:
受信して、(S、G)がメッセージを接合するか、または剪定するので、1界面準位あたりのマシンは、以下に与えられていて、(*、G)メッセージに、それとほとんど同じです。 3つの州があります:
NoInfo (NI)
The interface has no (S,G) Join state and no (S,G) timers
running.
NoInfo、(NI) インタフェースで、いいえ(S、G)は状態といいえ(S、G)、タイマ走りに参加します。
Join (J)
The interface has (S,G) Join state, which will cause the
router to forward packets from S destined for G from this
interface if the (S,G) state is active (the SPTbit is set)
except if the router lost an assert on this interface.
インタフェースでルータに(S、G)状態が活動的であるなら(SPTbitは用意ができています)ルータが損をしたのを除いて、このインタフェースからのGのために運命づけられたSからパケットを進めさせる州に加わる(S、G)(J)を接合してください、このインタフェースでは、断言します。
Prune-Pending (PP)
The router has received a Prune(S,G) on this interface from a
downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly
like the Join state.
ルータにはある未定のプルーン(PP)は、このインタフェースで川下の隣人からPrune(S、G)を受けて、プルーンが別の川下のルータによってくつがえされるかどうかを見るのを待っています。 推進目的のために、未定のPrune状態はちょうどJoin状態のように機能します。
In addition, there are two timers:
さらに、2個のタイマがあります:
Expiry Timer (ET)
This timer is set when a valid Join(S,G) is received. Expiry
of the Expiry Timer causes this state machine to revert to
NoInfo state.
有効なJoin(S、G)が受け取られているとき、このタイマがある満期Timer(ET)はセットしました。 Expiry Timerの満期で、この州のマシンはNoInfo状態に戻ります。
Prune-Pending Timer (PPT)
This timer is set when a valid Prune(S,G) is received. Expiry
of the Prune-Pending Timer causes this state machine to revert
to NoInfo state.
未定のプルーンのTimer、(PPT) 有効なPrune(S、G)が受け取られているとき、このタイマは設定されます。 未定のPrune Timerの満期で、この州のマシンはNoInfo状態に戻ります。
Fenner, et al. Standards Track [Page 53] RFC 4601 PIM-SM Specification August 2006
フェナー、他 規格はPIM-Sm仕様2006年8月にRFC4601を追跡します[53ページ]。
Figure 4: Downstream per-interface (S,G) state machine in tabular form
図4: 表フォームでの川下のインタフェース(S、G)州のマシン
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(S,G) | Prune(S,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(S,G) | | +------------++-------------+--------------+-------------+-------------+
+------------++--------------------------------------------------------+ | || 出来事| | ++-------------+--------------+-------------+-------------+ |Prev状態||受信してください。| 受信してください。| プルーン| 満期タイマ| | ||(S、G)を接合してください。| (S、G)を剪定してください。| 未定| 期限が切れます。| | || | | タイマ| | | || | | 期限が切れます。| | +------------++-------------+--------------+-------------+-------------+ | ||->J状態| ->NI状態| - | - | |NoInfo(Ni)||Expiryを始動してください。| | | | | ||タイマ| | | | +------------++-------------+--------------+-------------+-------------+ | ||->J状態| ->PP状態| - | ->NI状態| |(J)を接合してください。||再開| Pruneを始動してください。| | | | ||満期タイマ| 未定| | | | || | タイマ| | | +------------++-------------+--------------+-------------+-------------+ |プルーン||->J状態| ->PP状態| ->NI状態| ->NI状態| |未定の(pp)||再開| | プルーンを送ってください。| | | ||満期タイマ| | (S、G)を反響してください。| | +------------++-------------+--------------+-------------+-------------+
一覧
スポンサーリンク
