RFC3973 日本語訳
3973 Protocol Independent Multicast - Dense Mode (PIM-DM): ProtocolSpecification (Revised). A. Adams, J. Nicholas, W. Siadak. January 2005. (Format: TXT=136708 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Adams
Request for Comments: 3973 NextHop Technologies
Category: Experimental J. Nicholas
ITT A/CD
W. Siadak
NextHop Technologies
January 2005
コメントを求めるワーキンググループA.アダムスの要求をネットワークでつないでください: 3973年のNextHop技術カテゴリ: 実験的なJ.ニコラスITTは/CD W.Siadak NextHop技術2005年1月です。
Protocol Independent Multicast - Dense Mode (PIM-DM):
Protocol Specification (Revised)
プロトコルの独立しているマルチキャスト--濃いモード(PIM-DM): プロトコル仕様(改訂されます)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information.
このドキュメントはプロトコル無党派Multicastを指定します--濃いMode(PIM-DM)。 PIM-DMはすべてのマルチキャストルータへマルチキャストデータグラムをあふれさせるのに基本的なユニキャストルーティング情報ベースを使用するマルチキャストルーティング・プロトコルです。 プルーンのメッセージは、将来のメッセージがグループ会員資格情報なしでルータに伝播されるのを防ぐのに使用されます。
Adams, et al. Experimental [Page 1] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[1ページ]RFC3973PIM--濃いモード2005年1月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . 5
3. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . . 5
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . 7
4.1.1. General Purpose State . . . . . . . . . . . . . 7
4.1.2. (S,G) State . . . . . . . . . . . . . . . . . . 8
4.1.3. State Summarization Macros . . . . . . . . . . . 8
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . 10
4.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Sending Hello Messages . . . . . . . . . . . . . 11
4.3.2. Receiving Hello Messages . . . . . . . . . . . . 11
4.3.3. Hello Message Hold Time . . . . . . . . . . . . 12
4.3.4. Handling Router Failures . . . . . . . . . . . . 12
4.3.5. Reducing Prune Propagation Delay on LANs . . . . 13
4.4. PIM-DM Prune, Join, and Graft Messages . . . . . . . . . 13
4.4.1. Upstream Prune, Join, and Graft Messages . . . . 14
4.4.1.1. Transitions from the Forwarding
(F) State . . . . . . . . . . . . . . 17
4.4.1.2. Transitions from the Pruned
(P) State . . . . . . . . . . . . . . 18
4.4.1.3. Transitions from the AckPending
(AP) State . . . . . . . . . . . . . . 19
4.4.2. Downstream Prune, Join, and Graft Messages . . . 21
4.4.2.1. Transitions from the NoInfo State . . 23
4.4.2.2. Transitions from the PrunePending
(PP) State . . . . . . . . . . . . . . 24
4.4.2.3. Transitions from the Prune
(P) State . . . . . . . . . . . . . . 25
4.5. State Refresh . . . . . . . . . . . . . . . . . . . . . 26
4.5.1. Forwarding of State Refresh Messages . . . . . . 26
4.5.2. State Refresh Message Origination . . . . . . . 28
4.5.2.1. Transitions from the NotOriginator
(NO) State . . . . . . . . . . . . . . 29
4.5.2.2. Transitions from the Originator
(O) State . . . . . . . . . . . . . . 29
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 定義. . . . . . . . . . . . . . . . . . . . . . 4 2.2。 擬似コード記法. . . . . . . . . . . . . . . . . . 5 3。 PIM-DMは概観. . . . . . . . . . . . . . . . . . . 5 4について議定書の中で述べます。 仕様. . . . . . . . . . . . . . . . . . . . 6 4.1を議定書の中で述べてください。 PIMは州. . . . . . . . . . . . . . . . . . . 7 4.1の.1について議定書の中で述べます。 汎用の州. . . . . . . . . . . . . 7 4.1の.2。 (S、G) 州. . . . . . . . . . . . . . . . . . 8 4.1の.3。 総括マクロ. . . . . . . . . . . 8 4.2を述べてください。 データ・パケット推進は.104.3を統治します。 こんにちは、メッセージ. . . . . . . . . . . . . . . . . . . . . 11 4.3.1 発信、こんにちは、メッセージ. . . . . . . . . . . . . 11 4.3.2 こんにちはを受けるのが.3を.114.3に通信させます。 こんにちは、メッセージ保持時間. . . . . . . . . . . . 12 4.3.4 ルータ失敗. . . . . . . . . . . . 12 4.3.5を扱います。 LAN. . . . 13 4.4でプルーンの伝播遅延を減少させます。 PIM-DMはメッセージ. . . . . . . . . 13 4.4.1を剪定して、接合して、接ぎ木します。 上流は、.1にメッセージ. . . . 14 4.4.1を剪定して、接合して、接ぎ木します。 推進(F)州. . . . . . . . . . . . . . 17 4.4の.1.2からの変遷。 剪定された(p)州. . . . . . . . . . . . . . 18 4.4の.1.3からの変遷。 AckPending(AP)州. . . . . . . . . . . . . . 19 4.4の.2からの変遷。 川下では、メッセージ. . . 21 4.4.2は、.1に剪定して、接合して、接ぎ木されます。 NoInfo州. . 23 4.4の.2.2からの変遷。 PrunePending(pp)からの変遷は.244.4に.3に.2を述べます。 プルーンの(p)からの変遷は.254.5を述べます。 .1に.264.5をリフレッシュするように述べてください。 進めて、状態では、メッセージ. . . . . . 26 4.5.2をリフレッシュしてください。 メッセージ創作. . . . . . . 28 4.5.2.1をリフレッシュするように述べてください。 NotOriginator(いいえ)州. . . . . . . . . . . . . . 29 4.5の.2.2からの変遷。 創始者(o)状態. . . . . . . . . . . . . . 29からの変遷
Adams, et al. Experimental [Page 2] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[2ページ]RFC3973PIM--濃いモード2005年1月
4.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . 30
4.6.1. Assert Metrics . . . . . . . . . . . . . . . . . 30
4.6.2. AssertCancel Messages . . . . . . . . . . . . . 31
4.6.3. Assert State Macros . . . . . . . . . . . . . . 32
4.6.4. (S,G) Assert Message State Machine . . . . . . . 32
4.6.4.1. Transitions from NoInfo State . . . . 34
4.6.4.2. Transitions from Winner State . . . . 35
4.6.4.3. Transitions from Loser State . . . . . 36
4.6.5. Rationale for Assert Rules . . . . . . . . . . . 38
4.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . 38
4.7.1. PIM Header . . . . . . . . . . . . . . . . . . . 38
4.7.2. Encoded Unicast Address . . . . . . . . . . . . 39
4.7.3. Encoded Group Address . . . . . . . . . . . . . 40
4.7.4. Encoded Source Address . . . . . . . . . . . . . 41
4.7.5. Hello Message Format . . . . . . . . . . . . . . 42
4.7.5.1. Hello Hold Time Option . . . . . . . . 43
4.7.5.2. LAN Prune Delay Option . . . . . . . . 43
4.7.5.3. Generation ID Option . . . . . . . . . 44
4.7.5.4. State Refresh Capable Option . . . . . 44
4.7.6. Join/Prune Message Format . . . . . . . . . . . 45
4.7.7. Assert Message Format . . . . . . . . . . . . . 47
4.7.8. Graft Message Format . . . . . . . . . . . . . . 48
4.7.9. Graft Ack Message Format . . . . . . . . . . . . 48
4.7.10. State Refresh Message Format . . . . . . . . . . 48
4.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . 50
5. Protocol Interaction Considerations . . . . . . . . . . . . . 53
5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . 53
5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . 54
5.3. Source Specific Multicast (SSM) Interactions . . . . . . 54
5.4. Multicast Group Scope Boundary Interactions . . . . . . 54
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . 54
6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . 55
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 55
7.1. Attacks Based on Forged Messages . . . . . . . . . . . . 55
7.2. Non-cryptographic Authentication Mechanisms . . . . . . 56
7.3. Authentication Using IPsec . . . . . . . . . . . . . . . 56
7.4. Denial of Service Attacks . . . . . . . . . . . . . . . 58
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Normative References . . . . . . . . . . . . . . . . . . 58
9.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 61
4.6. PIMは、メッセージ. . . . . . . . . . . . . . . . . . 30 4.6が.1であると断言します。 測定基準. . . . . . . . . . . . . . . . . 30 4.6が.2であると断言してください。 AssertCancelメッセージ. . . . . . . . . . . . . 31 4.6.3。 州のマクロ. . . . . . . . . . . . . . 32 4.6が.4であると断言してください。 (S、G) メッセージが州マシン. . . . . . . 32 4.6.4の.1であると断言してください。 NoInfo州. . . . 34 4.6の.4.2からの変遷。 勝者州. . . . 35 4.6の.4.3からの変遷。 敗者州. . . . . 36 4.6の.5からの変遷。 原理、規則. . . . . . . . . . . 38 4.7について断言してください。 PIMパケット・フォーマット. . . . . . . . . . . . . . . . . . . 38 4.7.1。 PIMヘッダー. . . . . . . . . . . . . . . . . . . 38 4.7.2。 ユニキャストアドレス. . . . . . . . . . . . 39 4.7.3をコード化しました。 グループアドレス. . . . . . . . . . . . . 40 4.7.4をコード化しました。 ソースアドレス. . . . . . . . . . . . . 41 4.7.5をコード化しました。 こんにちは、形式. . . . . . . . . . . . . . 42 4.7.5を.1に通信させてください。 こんにちは、保持時間オプション. . . . . . . . 43 4.7.5.2 LANプルーン遅れオプション. . . . . . . . 43 4.7.5.3。 世代IDオプション. . . . . . . . . 44 4.7.5.4。 できるオプション. . . . . 44 4.7.6をリフレッシュするように述べてください。 メッセージ・フォーマット. . . . . . . . . . . 45 4.7.7を接合するか、または剪定してください。 メッセージ・フォーマット. . . . . . . . . . . . . 47 4.7が.8であると断言してください。 メッセージ・フォーマット. . . . . . . . . . . . . . 48 4.7.9を接ぎ木してください。 Ackメッセージ・フォーマット. . . . . . . . . . . . 48 4.7.10を接ぎ木してください。 メッセージ・フォーマット. . . . . . . . . . 48 4.8をリフレッシュするように述べてください。 PIM-DMタイマ. . . . . . . . . . . . . . . . . . . . . 50 5。 相互作用問題. . . . . . . . . . . . . 53 5.1について議定書の中で述べてください。 PIM-Sm相互作用. . . . . . . . . . . . . . . . . . 53 5.2。 IGMP相互作用. . . . . . . . . . . . . . . . . . . 54 5.3。 ソースの特定のマルチキャスト(SSM)相互作用. . . . . . 54 5.4。 マルチキャストグループ範囲境界相互作用. . . . . . 54 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 54 6.1。 PIMは家族. . . . . . . . . . . . . . . . . . . 54 6.2に演説します。 PIM、こんにちは、オプション. . . . . . . . . . . . . . . . . . . 55 7 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 55 7.1. 攻撃は偽造メッセージ. . . . . . . . . . . . 55 7.2を基礎づけました。 非暗号の認証機構. . . . . . 56 7.3。 IPsec. . . . . . . . . . . . . . . 56 7.4を使用する認証。 サービス不能攻撃. . . . . . . . . . . . . . . 58 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 58 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.1。 引用規格. . . . . . . . . . . . . . . . . . 58 9.2。 有益な参照. . . . . . . . . . . . . . . . . 59作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 60の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 61
Adams, et al. Experimental [Page 3] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[3ページ]RFC3973PIM--濃いモード2005年1月
1. Introduction
1. 序論
This specification defines a multicast routing algorithm for multicast groups that are densely distributed across a network. This protocol does not have a topology discovery mechanism often used by a unicast routing protocol. It employs the same packet formats sparse mode PIM (PIM-SM) uses. This protocol is called PIM - Dense Mode. The foundation of this design was largely built on Deering's early work on IP multicast routing [12].
この仕様はネットワークの向こう側に密に配布されるマルチキャストグループのためにマルチキャストルーティング・アルゴリズムを定義します。 このプロトコルで、ユニキャストルーティング・プロトコルはしばしばトポロジー発見メカニズムを使用しません。 それはまばらなモードPIM(PIM-SM)が使用する同じパケット・フォーマットを使います。 このプロトコルはPIMと呼ばれます--濃いMode。 このデザインの基礎はIPマルチキャストルーティング[12]に対するデアリングの早めの仕事のときに主に築き上げられました。
2. Terminology
2. 用語
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 [11] and indicate requirement levels for compliant PIM-DM implementations.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[11]について説明して、対応するPIM-DM実現のために要件レベルを示すとき解釈されることであるべきですか?
2.1. Definitions
2.1. 定義
Multicast Routing Information Base (MRIB)
This is the multicast topology table, which is typically derived
from the unicast routing table, or from routing protocols such as
MBGP that carry multicast-specific topology information. PIM-DM
uses the MRIB to make decisions regarding RPF interfaces.
マルチキャスト経路情報基地、(MRIB) これはマルチキャストトポロジーテーブルです。(そのテーブルはユニキャスト経路指定テーブルか、マルチキャスト特有のトポロジー情報を運ぶMBGPなどのルーティング・プロトコルから通常引き出されます)。 PIM-DMは、RPFに関する決定をインタフェースにするのにMRIBを使用します。
Tree Information Base (TIB)
This is the collection of state maintained by a PIM router and
created by receiving PIM messages and IGMP information from local
hosts. It essentially stores the state of all multicast
distribution trees at that router.
Information基地(TIB)を木に追い上げてください。ローカル・ホストからPIMルータによって維持されて、PIMメッセージとIGMP情報を受け取ることによって創設された状態の収集。 それはそのルータで本質的にはすべてのマルチキャスト分配木の状態を格納します。
Reverse Path Forwarding (RPF)
RPF is a multicast forwarding mode in which a data packet is
accepted for forwarding only if it is received on an interface used
to reach the source in unicast.
逆のPath Forwarding(RPF)RPFはユニキャストでソースに届くのに使用されるインタフェースにそれを受け取る場合にだけ推進のためにデータ・パケットを受け入れるマルチキャスト推進モードです。
Upstream Interface
Interface toward the source of the datagram. Also known as the RPF
Interface.
データグラムの源に向かった上流のInterface Interface。 また、RPF Interfaceとして、知られています。
Downstream Interface
All interfaces that are not the upstream interface, including the
router itself.
ルータ自体を含んでいて、上流でない川下のInterface Allインタフェースは連結します。
(S,G) Pair
Source S and destination group G associated with an IP packet.
(S、G) 組Source Sと目的地グループGはIPパケットと交際しました。
Adams, et al. Experimental [Page 4] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[4ページ]RFC3973PIM--濃いモード2005年1月
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
are the elements of set A that are not in set B.
(-)BはセットBにないセットAの要素です。
NULL
is the empty set or list.
NULLは空集合かリストです。
Note that operations MUST be conducted in the order specified. This is due to the fact that (-) is not a true difference operator, because B is not necessarily a subset of A. That is, A (+) B (-) C = A (-) C (+) B is not a true statement unless C is a subset of both A and B.
オーダーで操作を行わなければならないというメモは指定しました。 これは(-)が正しい差分演算子でないという事実のためであり、Bが必ずA.の部分集合であるというわけではないことがThatの理由であり、CがAとBの両方の部分集合でないなら、(-)C(+)A(+)B(-)C=Bは本当の話ではありません。
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-DM Protocol Overview
3. PIM-DMプロトコル概観
This section provides an overview of PIM-DM behavior. It is intended as an introduction to how PIM-DM works and is NOT definitive. For the definitive specification, see Section 4, Protocol Specification.
このセクションはPIM-DMの振舞いの概観を提供します。 それは序論としてPIM-DMがどう働いて、決定的であるか意図しません。 プロトコルSpecification、決定的な仕様に関しては、セクション4を見てください。
PIM-DM assumes that when a source starts sending, all downstream systems want to receive multicast datagrams. Initially, multicast datagrams are flooded to all areas of the network. PIM-DM uses RPF to prevent looping of multicast datagrams while flooding. If some areas of the network do not have group members, PIM-DM will prune off the forwarding branch by instantiating prune state.
PIM-DMは、ソースが発信し始めるとき、すべての川下のシステムがマルチキャストデータグラムを受け取りたがっていると仮定します。初めは、マルチキャストデータグラムはネットワークのすべての領域へあふれます。 PIM-DMは、浸水している間、マルチキャストデータグラムを輪にするのを防ぐのにRPFを使用します。 ネットワークのいくつかの領域にグループのメンバーがいないと、PIM-DMは、推進でプルーンの状態を例示することによって、ブランチを剪定するでしょう。
Prune state has a finite lifetime. When that lifetime expires, data will again be forwarded down the previously pruned branch.
プルーンの州には、有限寿命があります。 その寿命が期限が切れるとき、再び以前に剪定されたブランチの下側にデータを転送するでしょう。
Prune state is associated with an (S,G) pair. When a new member for a group G appears in a pruned area, a router can "graft" toward the source S for the group, thereby turning the pruned branch back into a forwarding branch.
プルーンの状態は(S、G)組に関連しています。 グループGの新しいメンバーが剪定された領域に現れると、ルータはグループのためにソースSに向かって「接ぎ木にされできます」、その結果、剪定されたブランチを推進ブランチとして折り返します。
Adams, et al. Experimental [Page 5] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[5ページ]RFC3973PIM--濃いモード2005年1月
The broadcast of datagrams followed by pruning of unwanted branches is often referred to as a flood and prune cycle and is typical of dense mode protocols.
求められていないブランチを取り除くのがあとに続いたデータグラムの放送は、しばしば洪水とプルーンのサイクルに言及されて、濃いモードプロトコルの典型です。
To minimize repeated flooding of datagrams and subsequent pruning associated with a particular (S,G) pair, PIM-DM uses a state refresh message. This message is sent by the router(s) directly connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message causes an existing prune state to be refreshed.
データグラムの繰り返された氾濫と特定(S、G)の組に関連しているその後の刈り込み、PIM-DM用途を最小にするために、州はメッセージをリフレッシュします。 このメッセージは、直接ソースに接されたルータによって送られて、ネットワーク中で伝播されます。 RPFにルータで受け取って、インタフェース、状態がリフレッシュするとき、メッセージで、既存のプルーンの状態をリフレッシュします。
Compared with multicast routing protocols with built-in topology discovery mechanisms (e.g., DVMRP [13]), PIM-DM has a simplified design and is not hard-wired into a specific topology discovery protocol. However, this simplification does incur more overhead by causing flooding and pruning to occur on some links that could be avoided if sufficient topology information were available; i.e., to decide whether an interface leads to any downstream members of a particular group. Additional overhead is chosen in favor of the simplification and flexibility gained by not depending on a specific topology discovery protocol.
トポロジー発見メカニズム内蔵マルチキャストルーティング・プロトコルと比較されました。(例えば、DVMRP[13])、PIM-DMは簡略設計を持って、特定のトポロジー発見プロトコルに配線されません。 しかしながら、氾濫と刈り込みが十分なトポロジー情報が利用可能であるなら避けることができるいくつかのリンクの上に起こることを引き起こすことによって、この簡素化は、より多くのオーバーヘッドを被ります。 すなわち、インタフェースが何か特定のグループの川下のメンバーに通じるかどうか決めるために。 追加オーバーヘッドは特定のトポロジー発見プロトコルによらないことによって獲得された簡素化と柔軟性を支持して選ばれています。
PIM-DM differs from PIM-SM in two essential ways: 1) There are no periodic joins transmitted, only explicitly triggered prunes and grafts. 2) There is no Rendezvous Point (RP). This is particularly important in networks that cannot tolerate a single point of failure. (An RP is the root of a shared multicast distribution tree. For more details, see [4]).
PIM-DMは2つの不可欠の方法でPIM-SMと異なっています: 1) 伝えられて、接合して、明らかに引き起こされるだけであって、そこでは、ノーが周期的です。剪定して、接ぎ木します。 2) Rendezvous Point(RP)が全くありません。 これは1ポイントの失敗を許容できないネットワークで特に重要です。 (RPは共有されたマルチキャスト分配木の根です。 その他の詳細に関しては、[4])を見てください。
4. Protocol Specification
4. プロトコル仕様
The specification of PIM-DM is broken into several parts:
数個の部品がPIM-DMの仕様に細かく分けられます:
* Section 4.1 details the protocol state stored.
* Section 4.2 specifies the data packet forwarding rules.
* Section 4.3 specifies generation and processing of Hello messages.
* Section 4.4 specifies the Join, Prune, and Graft generation and
processing rules.
* Section 4.5 specifies the State Refresh generation and forwarding
rules.
* Section 4.6 specifies the Assert generation and processing rules.
* Section 4.7 gives details on PIM-DM Packet Formats.
* Section 4.8 summarizes PIM-DM timers and their defaults.
* セクション4.1は州が格納したプロトコルを詳しく述べます。 * セクション4.2はデータ・パケット推進規則を指定します。 * セクション4.3はHelloメッセージの世代と処理を指定します。 * セクション4.4はJoin、Prune、およびGraft世代を指定します、そして、処理は統治されます。 * セクション4.5は州Refresh世代と推進規則を指定します。 * セクション4.6はAssert世代と処理規則を指定します。 * セクション4.7はPIM-DM Packet Formatsに関する詳細を述べます。 * セクション4.8はPIM-DMタイマとそれらのデフォルトをまとめます。
Adams, et al. Experimental [Page 6] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[6ページ]RFC3973PIM--濃いモード2005年1月
4.1. PIM Protocol State
4.1. PIMプロトコル状態
This section specifies all the protocol states that a PIM-DM implementation should maintain to function correctly. We term this state the Tree Information Base or TIB, as it holds the state of all the multicast distribution trees at this router. In this specification, we define PIM-DM 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-DM実現が正しく機能するように維持するべきであるすべてのプロトコル州を指定します。 私たち、これがTree Information基地を述べる用語かTIB、持ちこたえるとき、すべてのマルチキャスト分配の状態はこのルータで木に登られます。 この仕様では、私たちはTIBに関してPIM-DMメカニズムを定義します。 しかしながら、非常に簡単な実現だけが実際にこの状態に関してパケット推進操作を実行するでしょう。 ほとんどの実現が、マルチキャスト推進テーブルを組立てるのにこの状態を使用するでしょう。(次に、TIBの関連状態が変化するとき、テーブルはアップデートされるでしょう)。
Unlike PIM-SM, PIM-DM does not maintain a keepalive timer associated with each (S,G) route. Within PIM-DM, route and state information associated with an (S,G) entry MUST be maintained as long as any timer associated with that (S,G) entry is active. When no timer associated with an (S,G) entry is active, all information concerning that (S,G) route may be discarded.
PIM-SMと異なって、PIM-DMはそれぞれの(S、G)ルートに関連しているのにkeepaliveタイマを維持しません。 PIM-DMの中では、その(S、G)エントリーに関連しているどんなタイマもアクティブである限り、(S、G)エントリーに関連しているルートと州の情報を保守しなければなりません。 (S、G)エントリーに関連しているどんなタイマもアクティブでないときに、その(S、G)ルートのすべての情報が捨てられるかもしれません。
Although we precisely specify the state to be kept, this does not mean that an implementation of PIM-DM has 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-DM implementation is free to hold whatever internal state it requires and will still be conformant with this specification as long as it results in the same externally visible protocol behavior as an abstract router that holds the following state.
私たちは保たれるために正確に状態を指定しますが、これは、PIM-DMの実現がこのフォームに状態を保持しなければならないことを意味しません。 これは実際に抽象的な州の定義です。(その定義が、ルータの振舞いを指定するのに必要です)。 以下の状態を保持する抽象的なルータと同じ外部的に目に見えるプロトコルの振舞いをもたらす限り、PIM-DM実現は、それが必要とするどんな内部の状態も保持するのにおいて自由であり、まだこの仕様をもってconformantになっているでしょう。
4.1.1. General Purpose State
4.1.1. 汎用の状態
A router stores the following non-group-specific state:
ルータは以下の非グループの詳細状態を格納します:
For each interface:
Hello Timer (HT)
State Refresh Capable
LAN Delay Enabled
Propagation Delay (PD)
Override Interval (OI)
それぞれに関しては、連結してください: できるLAN遅れ可能にされた伝播遅延(PD)オーバーライド間隔をリフレッシュしますこんにちは、タイマ(HT)が、述べる。(OI)
Neighbor State:
For each neighbor:
Information from neighbor's Hello
Neighbor's Gen ID.
Neighbor's LAN Prune Delay
Neighbor's Override Interval
Neighbor's State Refresh Capability
Neighbor Liveness Timer (NLT)
隣人州: 各隣人のために: 隣人のHello NeighborのGen IDからの情報。 間隔隣人のオーバーライドものが能力隣人活性タイマをリフレッシュすると述べる隣人の隣人のLANプルーンの遅れもの(NLT)
Adams, et al. Experimental [Page 7] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[7ページ]RFC3973PIM--濃いモード2005年1月
4.1.2. (S,G) State
4.1.2. (S、G) 状態
For every source/group pair (S,G), a router stores the following state:
すべてのソース/グループ組(S、G)のために、ルータは以下の状態を格納します:
(S,G) state:
For each interface:
Local Membership:
State: One of {"NoInfo", "Include"}
(S、G) 州: それぞれに関しては、連結してください: 地方の会員資格: 州: 1つ"NoInfo"、「包含」
PIM (S,G) Prune State:
State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending"
(PP)}
Prune Pending Timer (PPT)
Prune Timer (PT)
PIM(S、G)は状態を剪定します: 州: "NoInfo"(Ni)、「剪定された」(p)、"PrunePending"(pp)プルーンの未定のタイマ(PPT)の1つはタイマから余計なものを取り除きます。(太平洋標準時)です。
(S,G) Assert Winner State:
State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won
Assert" (W)}
Assert Timer (AT)
Assert winner's IP Address
Assert winner's Assert Metric
(S、G)は勝者状態について断言します: 州: 1つ、"NoInfo"(NI)、「私はAssertをなくした」という(L)、「私はAssertを獲得した」という(W)では、Timer(AT)が勝者のIP Address Assert勝者のAssert Metricについて断言すると断言してください。
Upstream interface-specific:
Graft/Prune State:
State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F),
"AckPending" (AP) }
GraftRetry Timer (GRT)
Override Timer (OT)
Prune Limit Timer (PLT)
上流インタフェース詳細: 状態を接ぎ木するか、または剪定してください: 州: 1つ、"NoInfo"(Ni)が(p)、「推進」(F)を「剪定した」という"AckPending"(AP)GraftRetryタイマ(GRT)オーバーライドタイマ(OT)プルーンの限界タイマ(PLT)
Originator State:
Source Active Timer (SAT)
State Refresh Timer (SRT)
創始者州: ソースのアクティブなタイマ(土曜日)州はタイマをリフレッシュします。(SRT)
4.1.3. State Summarization Macros
4.1.3. 州の総括マクロ
Using the state defined above, the following "macros" are defined and will be used in the descriptions of the state machines and pseudocode in the following sections.
上で定義された状態を使用して、以下の「マクロ」は、定義されて、以下のセクションの州のマシンと擬似コードの記述に使用されるでしょう。
The most important macros are those defining the outgoing interface list (or "olist") for the relevant state.
最も重要なマクロは関連状態のための送信するインタフェースリスト(または、"olist")を定義するものです。
immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+)
(pim_include(*,G) (-) pim_exclude(S,G) ) (+)
pim_include(S,G) (-) lost_assert(S,G) (-)
boundary(G)
即座の_olist(S、G)=pim_nbrs(-)プルーン(S、G)(+)(pim_は(-) _が除くpim(S、G)を含んでいます(*、G))(+)のpim_は無くなっている_が(-)境界であると断言する(S、G)(-)を含んでいます(S、G)。(G)
Adams, et al. Experimental [Page 8] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[8ページ]RFC3973PIM--濃いモード2005年1月
olist(S,G) = immediate_olist(S,G) (-) RPF_interface(S)
olist(S、G)は即座の_olist(S、G)(-)RPF_インタフェースと等しいです。(S)
The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces to which traffic might or might not be forwarded because of hosts that are local members on those interfaces.
_が含むpim(*、G)とpim_が含むマクロ(S、G)は交通が送られるかもしれないか、またはそれらのインタフェースの地元会員であるホストのために送られないかもしれないインタフェースを示します。
pim_include(*,G) = {all interfaces I such that:
local_receiver_include(*,G,I)}
pim_include(S,G) = {all interfaces I such that:
local_receiver_include(S,G,I)}
pim_exclude(S,G) = {all interfaces I such that:
local_receiver_exclude(S,G,I)}
Iそれ: そのような地方の_受信機_が含むすべてのpim_インクルード(*、G)=インタフェース(*、G、I)がpimに、Iそれ: そのような地方の_受信機_が含むすべての_インクルード(S、G)=インタフェース(S、G、I)をpimする、_=を除いてください(S、G)。Iそれ: そのような地方の_受信機_が除くすべてのインタフェース(S、G、I)
The macro RPF_interface(S) returns the RPF interface for source S. That is to say, it returns the interface used to reach S as indicated by the MRIB.
ソースS.ThatのためのRPFインタフェースが言うことになっているマクロRPF_インタフェース(S)リターン、それはMRIBによって示されるようにSに達するのに使用されるインタフェースを返します。
The macro local_receiver_include(S,G,I) is true if the IGMP module or other local membership mechanism ([1], [2], [3], [6]) has determined that there are local members on interface I that seek to receive traffic sent specifically by S to G.
[2] [3] マクロの地方の_受信機_インクルード(S、G、I)がIGMPモジュールか他のローカルの会員資格メカニズム([1]であるなら本当である、[6])はインタフェースIの特にSからGによって送られた交通を受けようとする地元会員がいることを決定しました。
The macro local_receiver_include(*,G,I) is true if the IGMP module or other local membership mechanism has determined that there are local members on interface I that seek to receive all traffic sent to G. Note that this determination is expected to account for membership joins initiated on or by the router.
マクロの地方の_受信機_インクルード(*、G、I)はルータかルータによって開始されて、IGMPモジュールか他のローカルの会員資格メカニズムが、インタフェースIのこの決断が説明すると予想されるG.Noteに送られたすべての交通を受けようとする地元会員がいることを決定したなら本当に、会員資格が接合するということです。
The macro local_receiver_exclude(S,G,I) is true if local_receiver_include(*,G,I) is true but none of the local members seek to receive traffic from S.
地方の_受信機_インクルード(*、G、I)が本当ですが、地元会員のだれもSからの交通を受けようとしないなら、_が除くマクロの地方の_受信機(S、G、I)は本当です。
The set pim_nbrs is the set of all interfaces on which the router has at least one active PIM neighbor.
セットpim_nbrsはルータには少なくとも1人の活発なPIM隣人がいるすべてのインタフェースのセットです。
The set prunes(S,G) is the set of all interfaces on which the router has received Prune(S,G) messages:
セットプルーン(S、G)はルータがPrune(S、G)メッセージを受け取ったすべてのインタフェースのセットです:
prunes(S,G) = {all interfaces I such that
DownstreamPState(S,G,I) is in Pruned state}
=を剪定します(S、G)。DownstreamPState(S、G、I)がPruned状態にあるように、Iをすべて連結します。
Adams, et al. Experimental [Page 9] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[9ページ]RFC3973PIM--濃いモード2005年1月
The set lost_assert(S,G) is the set of all interfaces on which the router has lost an (S,G) Assert.
無くなっている_がルータが損をしたすべてのインタフェースのセットであると断言する(S、G)セット、(S、G) 断言します。
lost_assert(S,G) = {all interfaces I such that
lost_assert(S,G,I) == TRUE}
_失われて、=について断言してください(S、G)。Iあれほどそんなに無くなっている_が断言するすべてのインタフェース(S、G、I)=TRUE
boundary(G) = {all interfaces I with an administratively scoped
boundary for group G}
境界(G)=グループGのための行政上見られた境界とのすべてのインタフェースI
The following pseudocode macro definitions are also used in many places in the specification. Basically RPF' is the RPF neighbor toward a source unless a PIM-DM Assert has overridden the normal choice of neighbor.
また、以下の擬似コードマクロ定義は仕様による多くの場所で使用されます。 '基本的にRPF'はそうです。PIM-DM Assertが隣人の通常の選択をくつがえしていない場合、aに向かったRPF隣人は出典を明示します。
neighbor RPF'(S,G) {
if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) {
return AssertWinner(S, G, RPF_interface(S) )
} else {
return MRIB.next_hop( S )
}
}
'隣人RPF'(S、G)(I_Am_Assert_敗者、(S、G、RPF_インタフェース(S) ))、AssertWinnerを返してください、(S、G、RPF_インタフェース(S) )、ほかのリターンMRIB.next_ホップ(S)
The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine (in Section 4.6) for (S,G) on interface I is in the "I am Assert Loser" state.
マクロ、I_Am_Assert_敗者(S、G、I)はAssertが(S、G)に、オンなマシン(セクション4.6における)を述べるなら本当に、インタフェースIが「私はAssert Loserです」状態にあるということです。
4.2. Data Packet Forwarding Rules
4.2. データ・パケット推進規則
The PIM-DM packet forwarding rules are defined below in pseudocode.
PIM-DMパケット推進規則は以下で擬似コードで定義されます。
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). RPF_interface(S) is the interface the MRIB indicates would be used to route packets to S.
iifはパケットの入って来るインタフェースです。 Sはパケットのソースアドレスです。 Gはパケット(グループアドレス)の送付先アドレスです。 RPF_インタフェース(S)はMRIBがパケットをSに発送するのに使用されるのを示すインタフェースです。
First, an RPF check MUST be performed to determine whether the packet should be accepted based on TIB state and the interface on which that the packet arrived. Packets that fail the RPF check MUST NOT be forwarded, and the router will conduct an assert process for the (S,G) pair specified in the packet. Packets for which a route to the source cannot be found MUST be discarded.
最初にパケットがTIB状態とインタフェースに基づいてオンであると受け入れられるべきであるかどうか決定するためにRPFチェックを実行しなければならない、どれ、パケットは到着したか。 RPFチェックに失敗するパケットを進めてはいけません、そして、ルータはパケットで指定された(S、G)組のために断言の過程を行うでしょう。 ソースへのルートを見つけることができないパケットを捨てなければなりません。
If the RPF check has been passed, an outgoing interface list is constructed for the packet. If this list is not empty, then the packet MUST be forwarded to all listed interfaces. If the list is empty, then the router will conduct a prune process for the (S,G) pair specified in the packet.
RPFチェックが通過されたなら、送信するインタフェースリストはパケットのために構成されます。 このリストが空でないなら、すべての記載されたインタフェースにパケットを送らなければなりません。 リストが空であるなら、ルータはパケットで指定された(S、G)組のために剪定の過程を行うでしょう。
Adams, et al. Experimental [Page 10] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[10ページ]RFC3973PIM--濃いモード2005年1月
Upon receipt of a data packet from S addressed to G on interface iif:
Gに記述されたSからのデータ・パケットを受け取り次第、iifを連結してください:
if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) {
oiflist = olist(S,G)
} else {
oiflist = NULL
}
forward packet on all interfaces in oiflist
(RPF_インタフェース(S)とUpstreamPState(S、G)!=が余計なものを取り除いたiif=)oiflist=olist(S、G)ほかのoiflist=NULLがoiflistのすべてのインタフェースでパケットを進めるなら
This pseudocode employs the following "macro" definition:
この擬似コードは以下の「マクロ」定義を使います:
UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in Section 4.4.1.
UpstreamPState(S、G)はセクション4.4.1におけるUpstream(S、G)州のマシンの状態です。
4.3. Hello Messages
4.3. こんにちは、メッセージ
This section describes the generation and processing of Hello messages.
このセクションはHelloメッセージの世代と処理について説明します。
4.3.1. Sending Hello Messages
4.3.1. 発信、こんにちは、メッセージ
PIM-DM uses Hello messages to detect other PIM routers. Hello messages are sent periodically on each PIM enabled interface. Hello messages are multicast to the ALL-PIM-ROUTERS group. When PIM is enabled on an interface or when a router first starts, the Hello Timer (HT) MUST be set to random value between 0 and Triggered_Hello_Delay. This prevents synchronization of Hello messages if multiple routers are powered on simultaneously.
PIM-DMは他のPIMルータを検出するHelloメッセージを使用します。 こんにちは、メッセージはそうです。定期的に各PIMがインタフェースを可能にしたのを転送しました。 こんにちは、メッセージがマルチキャストである、すべて、-、PIM-ROUTERS、分類してください。 PIMがインタフェースで有効にされるか、またはルータが最初に始まるとき、Hello Timer(HT)は0とTriggered_Hello_Delayの間の無作為の値へのセットであるに違いありません。 複数のルータが同時に電源を入れられているなら、これはHelloメッセージの同期を防ぎます。
After the initial Hello message, a Hello message MUST be sent every Hello_Period. A single Hello timer MAY be used to trigger sending Hello messages on all active interfaces. The Hello Timer SHOULD NOT be reset except when it expires.
初期のHelloメッセージの後に、あらゆるHello_PeriodをHelloメッセージに送らなければなりません。 単一のHelloタイマは、すべてのアクティブなインタフェースに関する送付Helloメッセージの引き金となるのに使用されるかもしれません。 Hello Timer SHOULD、それが期限が切れる時以外に、リセットされないでください。
4.3.2. Receiving Hello Messages
4.3.2. こんにちはを受けるのを通信します。
When a Hello message is received, the receiving router SHALL record the receiving interface, the sender, and any information contained in recognized options. This information is retained for a number of seconds in the Hold Time field of the Hello Message. If a new Hello message is received from a particular neighbor N, the Neighbor Liveness Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime. If a Hello message is received from a new neighbor, the receiving router SHOULD send its own Hello message after a random delay between 0 and Triggered_Hello_Delay.
Helloメッセージが受信されているとき、受信ルータSHALLは認識されたオプションに含まれた受信インタフェース、送付者、およびどんな情報も記録します。 この情報は秒数のためにHello MessageのHold Time分野で保有されます。 特定の隣人Nから新しいHelloメッセージを受け取るなら、Neighbor Liveness Timer(NLT(N、I))を新たに受け取られたHello Holdtimeにリセットしなければなりません。 新しい隣人からHelloメッセージを受け取るなら、受信ルータSHOULDは0とTriggeredの間の無作為の遅れの後のそれ自身のHelloメッセージに_Hello_Delayを送ります。
Adams, et al. Experimental [Page 11] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[11ページ]RFC3973PIM--濃いモード2005年1月
4.3.3. Hello Message Hold Time
4.3.3. こんにちは、メッセージ保持時間
The Hold Time in the Hello Message should be set to a value that can reasonably be expected to keep the Hello active until a new Hello message is received. On most links, this will be 3.5 times the value of Hello_Period.
Hello MessageのHold Timeは新しいHelloメッセージが受信されるまでHelloをアクティブに保つと合理的に予想できる値に用意ができるべきです。 ほとんどのリンクの上では、これはHello_Periodの値の3.5倍になるでしょう。
If the Hold Time is set to '0xffff', the receiving router MUST NOT time out that Hello message. This feature might be used for on- demand links to avoid keeping the link up with periodic Hello messages.
If the Hold Time is set to '0xffff', the receiving router MUST NOT time out that Hello message. This feature might be used for on- demand links to avoid keeping the link up with periodic Hello messages.
If a Hold Time of '0' is received, the corresponding neighbor state expires immediately. When a PIM router takes an interface down or changes IP address, a Hello message with a zero Hold Time SHOULD be sent immediately (with the old IP address if the IP address is changed) to cause any PIM neighbors to remove the old information immediately.
If a Hold Time of '0' is received, the corresponding neighbor state expires immediately. When a PIM router takes an interface down or changes IP address, a Hello message with a zero Hold Time SHOULD be sent immediately (with the old IP address if the IP address is changed) to cause any PIM neighbors to remove the old information immediately.
4.3.4. Handling Router Failures
4.3.4. Handling Router Failures
If a Hello message is received from an active neighbor with a different Generation ID (GenID), the neighbor has restarted and may not contain the correct (S,G) state. A Hello message SHOULD be sent after a random delay between 0 and Triggered_Hello_Delay (see 4.8) before any other messages are sent. If the neighbor is downstream, the router MAY replay the last State Refresh message for any (S,G) pairs for which it is the Assert Winner indicating Prune and Assert status to the downstream router. These State Refresh messages SHOULD be sent out immediately after the Hello message. If the neighbor is the upstream neighbor for an (S,G) entry, the router MAY cancel its Prune Limit Timer to permit sending a prune and reestablishing a Pruned state in the upstream router.
If a Hello message is received from an active neighbor with a different Generation ID (GenID), the neighbor has restarted and may not contain the correct (S,G) state. A Hello message SHOULD be sent after a random delay between 0 and Triggered_Hello_Delay (see 4.8) before any other messages are sent. If the neighbor is downstream, the router MAY replay the last State Refresh message for any (S,G) pairs for which it is the Assert Winner indicating Prune and Assert status to the downstream router. These State Refresh messages SHOULD be sent out immediately after the Hello message. If the neighbor is the upstream neighbor for an (S,G) entry, the router MAY cancel its Prune Limit Timer to permit sending a prune and reestablishing a Pruned state in the upstream router.
Upon startup, a router MAY use any State Refresh messages received within Hello_Period of its first Hello message on an interface to establish state information. The State Refresh source will be the RPF'(S), and Prune status for all interfaces will be set according to the Prune Indicator bit in the State Refresh message. If the Prune Indicator is set, the router SHOULD set the PruneLimitTimer to Prune_Holdtime and set the PruneTimer on all downstream interfaces to the State Refresh's Interval times two. The router SHOULD then propagate the State Refresh as described in Section 4.5.1.
Upon startup, a router MAY use any State Refresh messages received within Hello_Period of its first Hello message on an interface to establish state information. The State Refresh source will be the RPF'(S), and Prune status for all interfaces will be set according to the Prune Indicator bit in the State Refresh message. If the Prune Indicator is set, the router SHOULD set the PruneLimitTimer to Prune_Holdtime and set the PruneTimer on all downstream interfaces to the State Refresh's Interval times two. The router SHOULD then propagate the State Refresh as described in Section 4.5.1.
Adams, et al. Experimental [Page 12] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 12] RFC 3973 PIM - Dense Mode January 2005
4.3.5. Reducing Prune Propagation Delay on LANs
4.3.5. Reducing Prune Propagation Delay on LANs
If all routers on a LAN support the LAN Prune Delay option, then the PIM routers on that LAN will use the values received to adjust their J/P_Override_Interval on that interface and the interface is LAN Delay Enabled. Briefly, to avoid synchronization of Prune Override (Join) messages when multiple downstream routers share a multi-access link, sending of these messages is delayed by a small random amount of time. The period of randomization is configurable and has a default value of 3 seconds.
If all routers on a LAN support the LAN Prune Delay option, then the PIM routers on that LAN will use the values received to adjust their J/P_Override_Interval on that interface and the interface is LAN Delay Enabled. Briefly, to avoid synchronization of Prune Override (Join) messages when multiple downstream routers share a multi-access link, sending of these messages is delayed by a small random amount of time. The period of randomization is configurable and has a default value of 3 seconds.
Each router on the LAN expresses its view of the amount of randomization necessary in the Override Interval field of the LAN Prune Delay option. When all routers on a LAN use the LAN Prune Delay Option, all routers on the LAN MUST set their Override_Interval to the largest Override value on the LAN.
Each router on the LAN expresses its view of the amount of randomization necessary in the Override Interval field of the LAN Prune Delay option. When all routers on a LAN use the LAN Prune Delay Option, all routers on the LAN MUST set their Override_Interval to the largest Override value on the LAN.
The LAN 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. When all routers on a link use the LAN Prune Delay Option, all routers on the LAN MUST set Propagation Delay to the largest LAN Delay on the LAN.
The LAN 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. When all routers on a link use the LAN Prune Delay Option, all routers on the LAN MUST set Propagation Delay to the largest LAN Delay on the LAN.
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 and triggered messages to be sent later than intended. Setting this LAN Prune 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 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 and triggered messages to be sent later than intended. Setting this LAN Prune 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.
4.4. PIM-DM Prune, Join, and Graft Messages
4.4. PIM-DM Prune, Join, and Graft Messages
This section describes the generation and processing of PIM-DM Join, Prune, and Graft messages. Prune messages are sent toward the upstream neighbor for S to indicate that traffic from S addressed to group G is not desired. In the case of downstream routers A and B, where A wishes to continue receiving data and B does not, A will send a Join in response to B's Prune to override the Prune. This is the only situation in PIM-DM in which a Join message is used. Finally, a Graft message is used to re-join a previously pruned branch to the delivery tree.
This section describes the generation and processing of PIM-DM Join, Prune, and Graft messages. Prune messages are sent toward the upstream neighbor for S to indicate that traffic from S addressed to group G is not desired. In the case of downstream routers A and B, where A wishes to continue receiving data and B does not, A will send a Join in response to B's Prune to override the Prune. This is the only situation in PIM-DM in which a Join message is used. Finally, a Graft message is used to re-join a previously pruned branch to the delivery tree.
Adams, et al. Experimental [Page 13] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 13] RFC 3973 PIM - Dense Mode January 2005
4.4.1. Upstream Prune, Join, and Graft Messages
4.4.1. Upstream Prune, Join, and Graft Messages
The Upstream(S,G) state machine for sending Prune, Graft, and Join messages is given below. There are three states.
The Upstream(S,G) state machine for sending Prune, Graft, and Join messages is given below. There are three states.
Forwarding (F)
This is the starting state of the Upsteam(S,G) state machine.
The state machine is in this state if it just started or if
oiflist(S,G) != NULL.
Forwarding (F) This is the starting state of the Upsteam(S,G) state machine. The state machine is in this state if it just started or if oiflist(S,G) != NULL.
Pruned (P)
The set, olist(S,G), is empty. The router will not forward data
from S addressed to group G.
Pruned (P) The set, olist(S,G), is empty. The router will not forward data from S addressed to group G.
AckPending (AP)
The router was in the Pruned(P) state, but a transition has
occurred in the Downstream(S,G) state machine for one of this
(S,G) entry's outgoing interfaces, indicating that traffic from S
addressed to G should again be forwarded. A Graft message has
been sent to RPF'(S), but a Graft Ack message has not yet been
received.
AckPending (AP) The router was in the Pruned(P) state, but a transition has occurred in the Downstream(S,G) state machine for one of this (S,G) entry's outgoing interfaces, indicating that traffic from S addressed to G should again be forwarded. A Graft message has been sent to RPF'(S), but a Graft Ack message has not yet been received.
In addition, there are three state-machine-specific timers:
In addition, there are three state-machine-specific timers:
GraftRetry Timer (GRT(S,G))
This timer is set when a Graft is sent upstream. If a
corresponding GraftAck is not received before the timer expires,
then another Graft is sent, and the GraftRetry Timer is reset.
The timer is stopped when a Graft Ack message is received. This
timer is normally set to Graft_Retry_Period (see 4.8).
GraftRetry Timer (GRT(S,G)) This timer is set when a Graft is sent upstream. If a corresponding GraftAck is not received before the timer expires, then another Graft is sent, and the GraftRetry Timer is reset. The timer is stopped when a Graft Ack message is received. This timer is normally set to Graft_Retry_Period (see 4.8).
Override Timer (OT(S,G))
This timer is set when a Prune(S,G) is received on the upstream
interface where olist(S,G) != NULL. When the timer expires, a
Join(S,G) message is sent on the upstream interface. This timer
is normally set to t_override (see 4.8).
Override Timer (OT(S,G)) This timer is set when a Prune(S,G) is received on the upstream interface where olist(S,G) != NULL. When the timer expires, a Join(S,G) message is sent on the upstream interface. This timer is normally set to t_override (see 4.8).
Prune Limit Timer (PLT(S,G))
This timer is used to rate-limit Prunes on a LAN. It is only
used when the Upstream(S,G) state machine is in the Pruned state.
A Prune cannot be sent if this timer is running. This timer is
normally set to t_limit (see 4.8).
Prune Limit Timer (PLT(S,G)) This timer is used to rate-limit Prunes on a LAN. It is only used when the Upstream(S,G) state machine is in the Pruned state. A Prune cannot be sent if this timer is running. This timer is normally set to t_limit (see 4.8).
Adams, et al. Experimental [Page 14] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 14] RFC 3973 PIM - Dense Mode January 2005
+-------------+ +-------------+
| | olist == NULL | |
| Forward |----------------------->| Pruned |
| | | |
+-------------+ +-------------+
^ | ^ |
| | | |
| |RPF`(S) Changes olist == NULL| |
| | | |
| | +-------------+ | |
| +-------->| |----------+ |
| | AckPending | |
+-------------| |<-------------+
Rcv GraftAck OR +-------------+ olist != NULL
Rcv State Refresh
With (P==0) OR
S Directly Connect
+-------------+ +-------------+ | | olist == NULL | | | Forward |----------------------->| Pruned | | | | | +-------------+ +-------------+ ^ | ^ | | | | | | |RPF`(S) Changes olist == NULL| | | | | | | | +-------------+ | | | +-------->| |----------+ | | | AckPending | | +-------------| |<-------------+ Rcv GraftAck OR +-------------+ olist != NULL Rcv State Refresh With (P==0) OR S Directly Connect
Figure 1: Upstream Interface State Machine
Figure 1: Upstream Interface State Machine
In tabular form, the state machine is defined as follows:
In tabular form, the state machine is defined as follows:
+-------------------------------+--------------------------------------+ | | Previous State | | +------------+------------+------------+ | Event | Forwarding | Pruned | AckPending | +-------------------------------+------------+------------+------------+ | Data packet arrives on | ->P Send | ->P Send | N/A | | RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | | | olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| | | PLT(S,G) not running | | | | +-------------------------------+------------+------------+------------+ | State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set | | from RPF`(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) | | Prune Indicator == 1 | | | | +-------------------------------+------------+------------+------------+ | State Refresh(S,G) received | ->F | ->P Send |->F Cancel | | from RPF`(S) AND | | Prune(S,G) | GRT(S,G) | | Prune Indicator == 0 AND | |Set PLT(S,G)| | | PLT(S,G) not running | | | | +-------------------------------+------------+------------+------------+
+-------------------------------+--------------------------------------+ | | Previous State | | +------------+------------+------------+ | Event | Forwarding | Pruned | AckPending | +-------------------------------+------------+------------+------------+ | Data packet arrives on | ->P Send | ->P Send | N/A | | RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | | | olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| | | PLT(S,G) not running | | | | +-------------------------------+------------+------------+------------+ | State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set | | from RPF`(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) | | Prune Indicator == 1 | | | | +-------------------------------+------------+------------+------------+ | State Refresh(S,G) received | ->F | ->P Send |->F Cancel | | from RPF`(S) AND | | Prune(S,G) | GRT(S,G) | | Prune Indicator == 0 AND | |Set PLT(S,G)| | | PLT(S,G) not running | | | | +-------------------------------+------------+------------+------------+
Adams, et al. Experimental [Page 15] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 15] RFC 3973 PIM - Dense Mode January 2005
+-------------------------------+--------------------------------------+ | | Previous State | + +------------+------------+------------+ | Event | Forwarding | Pruned | AckPending | +-------------------------------+------------+------------+------------+ | See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel | | | OT(S,G) | | OT(S,G) | +-------------------------------+------------+------------+------------+ | See Prune(S,G) | ->F Set | ->P |->AP Set | | | OT(S,G) | | OT(S,G) | +-------------------------------+------------+------------+------------+ | OT(S,G) Expires | ->F Send | N/A |->AP Send | | | Join(S,G) | | Join(S,G) | +-------------------------------+------------+------------+------------+ | olist(S,G)->NULL | ->P Send | N/A |->P Send | | | Prune(S,G) | | Prune(S,G) | | |Set PLT(S,G)| |Set PLT(S,G)| | | | | Cancel | | | | | GRT(S,G) | +-------------------------------+------------+------------+------------+ | olist(S,G)->non-NULL | N/A | ->AP Send | N/A | | | | Graft(S,G) | | | | |Set GRT(S,G)| | +-------------------------------+------------+------------+------------+ | RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send | | olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) | | |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)| +-------------------------------+------------+------------+------------+ | RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel | | olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) | +-------------------------------+------------+------------+------------+ | S becomes directly connected | ->F | ->P |->F Cancel | | | | | GRT(S,G) | +-------------------------------+------------+------------+------------+ | GRT(S,G) Expires | N/A | N/A |->AP Send | | | | | Graft(S,G) | | | | |Set GRT(S,G)| +-------------------------------+------------+------------+------------+ | Receive GraftAck(S,G) from | ->F | ->P |->F Cancel | | RPF'(S) | | | GRT(S,G) | +-------------------------------+------------+------------+------------+
+-------------------------------+--------------------------------------+ | | Previous State | + +------------+------------+------------+ | Event | Forwarding | Pruned | AckPending | +-------------------------------+------------+------------+------------+ | See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel | | | OT(S,G) | | OT(S,G) | +-------------------------------+------------+------------+------------+ | See Prune(S,G) | ->F Set | ->P |->AP Set | | | OT(S,G) | | OT(S,G) | +-------------------------------+------------+------------+------------+ | OT(S,G) Expires | ->F Send | N/A |->AP Send | | | Join(S,G) | | Join(S,G) | +-------------------------------+------------+------------+------------+ | olist(S,G)->NULL | ->P Send | N/A |->P Send | | | Prune(S,G) | | Prune(S,G) | | |Set PLT(S,G)| |Set PLT(S,G)| | | | | Cancel | | | | | GRT(S,G) | +-------------------------------+------------+------------+------------+ | olist(S,G)->non-NULL | N/A | ->AP Send | N/A | | | | Graft(S,G) | | | | |Set GRT(S,G)| | +-------------------------------+------------+------------+------------+ | RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send | | olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) | | |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)| +-------------------------------+------------+------------+------------+ | RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel | | olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) | +-------------------------------+------------+------------+------------+ | S becomes directly connected | ->F | ->P |->F Cancel | | | | | GRT(S,G) | +-------------------------------+------------+------------+------------+ | GRT(S,G) Expires | N/A | N/A |->AP Send | | | | | Graft(S,G) | | | | |Set GRT(S,G)| +-------------------------------+------------+------------+------------+ | Receive GraftAck(S,G) from | ->F | ->P |->F Cancel | | RPF'(S) | | | GRT(S,G) | +-------------------------------+------------+------------+------------+
The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack message targeted to this router's address on the incoming interface for the (S,G) entry. If the destination address is not correct, the state transitions in this state machine must not occur.
The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack message targeted to this router's address on the incoming interface for the (S,G) entry. If the destination address is not correct, the state transitions in this state machine must not occur.
Adams, et al. Experimental [Page 16] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 16] RFC 3973 PIM - Dense Mode January 2005
4.4.1.1. Transitions from the Forwarding (F) State
4.4.1.1. Transitions from the Forwarding (F) State
When the Upstream(S,G) state machine is in the Forwarding (F) state, the following events may trigger a transition:
When the Upstream(S,G) state machine is in the Forwarding (F) state, the following events may trigger a transition:
Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND
S NOT directly connected
The Upstream(S,G) state machine MUST transition to the Pruned (P)
state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit
seconds.
Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S NOT directly connected The Upstream(S,G) state machine MUST transition to the Pruned (P) state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit seconds.
State Refresh(S,G) Received from RPF'(S)
The Upstream(S,G) state machine remains in a Forwarding state.
If the received State Refresh has the Prune Indicator bit set to
one, this router must override the upstream router's Prune state
after a short random interval. If OT(S,G) is not running and the
Prune Indicator bit equals one, the router MUST set OT(S,G) to
t_override seconds.
State Refresh(S,G) Received from RPF'(S) The Upstream(S,G) state machine remains in a Forwarding state. If the received State Refresh has the Prune Indicator bit set to one, this router must override the upstream router's Prune state after a short random interval. If OT(S,G) is not running and the Prune Indicator bit equals one, the router MUST set OT(S,G) to t_override seconds.
See Join(S,G) to RPF'(S)
This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) send
a Join(S,G) to RPF'(S,G). If the OT(S,G) is running, then it
means that the router had scheduled a Join to override a
previously received Prune. Another router has responded more
quickly with a Join, so the local router SHOULD cancel its
OT(S,G), if it is running. The Upstream(S,G) state machine
remains in the Forwarding (F) state.
See Join(S,G) to RPF'(S) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Join(S,G) to RPF'(S,G). If the OT(S,G) is running, then it means that the router had scheduled a Join to override a previously received Prune. Another router has responded more quickly with a Join, so the local router SHOULD cancel its OT(S,G), if it is running. The Upstream(S,G) state machine remains in the Forwarding (F) state.
See Prune(S,G) AND S NOT directly connected
This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) send
a Prune(S,G). As this router is in Forwarding state, it must
override the Prune after a short random interval. If OT(S,G) is
not running, the router MUST set OT(S,G) to t_override seconds.
The Upstream(S,G) state machine remains in Forwarding (F) state.
See Prune(S,G) AND S NOT directly connected This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(S,G). As this router is in Forwarding state, it must override the Prune after a short random interval. If OT(S,G) is not running, the router MUST set OT(S,G) to t_override seconds. The Upstream(S,G) state machine remains in Forwarding (F) state.
OT(S,G) Expires AND S NOT directly connected
The OverrideTimer (OT(S,G)) expires. The router MUST send a
Join(S,G) to RPF'(S) to override a previously detected prune.
The Upstream(S,G) state machine remains in the Forwarding (F)
state.
OT(S,G) Expires AND S NOT directly connected The OverrideTimer (OT(S,G)) expires. The router MUST send a Join(S,G) to RPF'(S) to override a previously detected prune. The Upstream(S,G) state machine remains in the Forwarding (F) state.
olist(S,G) -> NULL AND S NOT directly connected
The Upstream(S,G) state machine MUST transition to the Pruned (P)
state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit
seconds.
olist(S,G) -> NULL AND S NOT directly connected The Upstream(S,G) state machine MUST transition to the Pruned (P) state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit seconds.
Adams, et al. Experimental [Page 17] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 17] RFC 3973 PIM - Dense Mode January 2005
RPF'(S) Changes AND olist(S,G) is non-NULL AND S NOT directly
connected
Unicast routing or Assert state causes RPF'(S) to change,
including changes to RPF_Interface(S). The Upstream(S,G) state
machine MUST transition to the AckPending (AP) state, unicast a
Graft to the new RPF'(S), and set the GraftRetry Timer (GRT(S,G))
to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) is non-NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the AckPending (AP) state, unicast a Graft to the new RPF'(S), and set the GraftRetry Timer (GRT(S,G)) to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) is NULL
Unicast routing or Assert state causes RPF'(S) to change,
including changes to RPF_Interface(S). The Upstream(S,G) state
machine MUST transition to the Pruned (P) state.
RPF'(S) Changes AND olist(S,G) is NULL Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the Pruned (P) state.
4.4.1.2. Transitions from the Pruned (P) State
4.4.1.2. Transitions from the Pruned (P) State
When the Upstream(S,G) state machine is in the Pruned (P) state, the following events may trigger a transition:
When the Upstream(S,G) state machine is in the Pruned (P) state, the following events may trigger a transition:
Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT
directly connected
Either another router on the LAN desires traffic from S addressed
to G or a previous Prune was lost. To prevent generating a
Prune(S,G) in response to every data packet, the PruneLimit Timer
(PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs
to send another prune in response to a data packet not received
directly from the source. A Prune(S,G) MUST be sent to RPF'(S),
and the PLT(S,G) MUST be set to t_limit.
Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT directly connected Either another router on the LAN desires traffic from S addressed to G or a previous Prune was lost. To prevent generating a Prune(S,G) in response to every data packet, the PruneLimit Timer (PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs to send another prune in response to a data packet not received directly from the source. A Prune(S,G) MUST be sent to RPF'(S), and the PLT(S,G) MUST be set to t_limit.
State Refresh(S,G) Received from RPF'(S)
The Upstream(S,G) state machine remains in a Pruned state. If
the State Refresh has its Prune Indicator bit set to zero and
PLT(S,G) is not running, a Prune(S,G) MUST be sent to RPF'(S),
and the PLT(S,G) MUST be set to t_limit. If the State Refresh
has its Prune Indicator bit set to one, the router MUST reset
PLT(S,G) to t_limit.
State Refresh(S,G) Received from RPF'(S) The Upstream(S,G) state machine remains in a Pruned state. If the State Refresh has its Prune Indicator bit set to zero and PLT(S,G) is not running, a Prune(S,G) MUST be sent to RPF'(S), and the PLT(S,G) MUST be set to t_limit. If the State Refresh has its Prune Indicator bit set to one, the router MUST reset PLT(S,G) to t_limit.
See Prune(S,G) to RPF'(S)
A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The
Upstream(S,G) state machine stays in the Pruned (P) state. The
router MAY reset its PLT(S,G) to the value in the Holdtime field
of the received message if it is greater than the current value
of the PLT(S,G).
See Prune(S,G) to RPF'(S) A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The Upstream(S,G) state machine stays in the Pruned (P) state. The router MAY reset its PLT(S,G) to the value in the Holdtime field of the received message if it is greater than the current value of the PLT(S,G).
olist(S,G)->non-NULL AND S NOT directly connected
The set of interfaces defined by the olist(S,G) macro becomes
non-empty, indicating that traffic from S addressed to group G
must be forwarded. The Upstream(S,G) state machine MUST cancel
PLT(S,G), transition to the AckPending (AP) state and unicast a
olist(S,G)->non-NULL AND S NOT directly connected The set of interfaces defined by the olist(S,G) macro becomes non-empty, indicating that traffic from S addressed to group G must be forwarded. The Upstream(S,G) state machine MUST cancel PLT(S,G), transition to the AckPending (AP) state and unicast a
Adams, et al. Experimental [Page 18] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 18] RFC 3973 PIM - Dense Mode January 2005
Graft message to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST
be set to Graft_Retry_Period.
Graft message to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) == non-NULL AND S NOT directly
connected
Unicast routing or Assert state causes RPF'(S) to change,
including changes to RPF_Interface(S). The Upstream(S,G) state
machine MUST cancel PLT(S,G), transition to the AckPending (AP)
state, send a Graft unicast to the new RPF'(S), and set the
GraftRetry Timer (GRT(S,G)) to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) == non-NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST cancel PLT(S,G), transition to the AckPending (AP) state, send a Graft unicast to the new RPF'(S), and set the GraftRetry Timer (GRT(S,G)) to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected
Unicast routing or Assert state causes RPF'(S) to change,
including changes to RPF_Interface(S). The Upstream(S,G) state
machine stays in the Pruned (P) state and MUST cancel the
PLT(S,G) timer.
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine stays in the Pruned (P) state and MUST cancel the PLT(S,G) timer.
S becomes directly connected
Unicast routing changed so that S is directly connected. The
Upstream(S,G) state machine remains in the Pruned (P) state.
S becomes directly connected Unicast routing changed so that S is directly connected. The Upstream(S,G) state machine remains in the Pruned (P) state.
4.4.1.3. Transitions from the AckPending (AP) State
4.4.1.3. Transitions from the AckPending (AP) State
When the Upstream(S,G) state machine is in the AckPending (AP) state, the following events may trigger a transition:
When the Upstream(S,G) state machine is in the AckPending (AP) state, the following events may trigger a transition:
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1
The Upstream(S,G) state machine remains in an AckPending state.
The router must override the upstream router's Prune state after
a short random interval. If OT(S,G) is not running and the Prune
Indicator bit equals one, the router MUST set OT(S,G) to
t_override seconds.
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1 The Upstream(S,G) state machine remains in an AckPending state. The router must override the upstream router's Prune state after a short random interval. If OT(S,G) is not running and the Prune Indicator bit equals one, the router MUST set OT(S,G) to t_override seconds.
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0
The router MUST cancel its GraftRetry Timer (GRT(S,G)) and
transition to the Forwarding (F) state.
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0 The router MUST cancel its GraftRetry Timer (GRT(S,G)) and transition to the Forwarding (F) state.
See Join(S,G) to RPF'(S,G)
This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) send
a Join(S,G) to RPF'(S,G). If the OT(S,G) is running, then it
means that the router had scheduled a Join to override a
previously received Prune. Another router has responded more
quickly with a Join, so the local router SHOULD cancel its
OT(S,G), if it is running. The Upstream(S,G) state machine
remains in the AckPending (AP) state.
See Join(S,G) to RPF'(S,G) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Join(S,G) to RPF'(S,G). If the OT(S,G) is running, then it means that the router had scheduled a Join to override a previously received Prune. Another router has responded more quickly with a Join, so the local router SHOULD cancel its OT(S,G), if it is running. The Upstream(S,G) state machine remains in the AckPending (AP) state.
Adams, et al. Experimental [Page 19] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 19] RFC 3973 PIM - Dense Mode January 2005
See Prune(S,G)
This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) send
a Prune(S,G). As this router is in AckPending (AP) state, it
must override the Prune after a short random interval. If
OT(S,G) is not running, the router MUST set OT(S,G) to t_override
seconds. The Upstream(S,G) state machine remains in AckPending
(AP) state.
See Prune(S,G) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(S,G). As this router is in AckPending (AP) state, it must override the Prune after a short random interval. If OT(S,G) is not running, the router MUST set OT(S,G) to t_override seconds. The Upstream(S,G) state machine remains in AckPending (AP) state.
OT(S,G) Expires
The OverrideTimer (OT(S,G)) expires. The router MUST send a
Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in
the AckPending (AP) state.
OT(S,G) Expires The OverrideTimer (OT(S,G)) expires. The router MUST send a Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in the AckPending (AP) state.
olist(S,G) -> NULL
The set of interfaces defined by the olist(S,G) macro becomes
null, indicating that traffic from S addressed to group G should
no longer be forwarded. The Upstream(S,G) state machine MUST
transition to the Pruned (P) state. A Prune(S,G) MUST be
multicast to the RPF_interface(S), with RPF'(S) named in the
upstream neighbor field. The GraftRetry Timer (GRT(S,G)) MUST be
cancelled, and PLT(S,G) MUST be set to t_limit seconds.
olist(S,G) -> NULL The set of interfaces defined by the olist(S,G) macro becomes null, indicating that traffic from S addressed to group G should no longer be forwarded. The Upstream(S,G) state machine MUST transition to the Pruned (P) state. A Prune(S,G) MUST be multicast to the RPF_interface(S), with RPF'(S) named in the upstream neighbor field. The GraftRetry Timer (GRT(S,G)) MUST be cancelled, and PLT(S,G) MUST be set to t_limit seconds.
RPF'(S) Changes AND olist(S,G) does not become NULL AND S NOT
directly connected
Unicast routing or Assert state causes RPF'(S) to change,
including changes to RPF_Interface(S). The Upstream(S,G) state
machine stays in the AckPending (AP) state. A Graft MUST be
unicast to the new RPF'(S) and the GraftRetry Timer (GRT(S,G))
reset to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) does not become NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine stays in the AckPending (AP) state. A Graft MUST be unicast to the new RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected
Unicast routing or Assert state causes RPF'(S) to change,
including changes to RPF_Interface(S). The Upstream(S,G) state
machine MUST transition to the Pruned (P) state. The GraftRetry
Timer (GRT(S,G)) MUST be cancelled.
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the Pruned (P) state. The GraftRetry Timer (GRT(S,G)) MUST be cancelled.
S becomes directly connected
Unicast routing has changed so that S is directly connected. The
GraftRetry Timer MUST be cancelled, and the Upstream(S,G) state
machine MUST transition to the Forwarding(F) state.
S becomes directly connected Unicast routing has changed so that S is directly connected. The GraftRetry Timer MUST be cancelled, and the Upstream(S,G) state machine MUST transition to the Forwarding(F) state.
Adams, et al. Experimental [Page 20] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 20] RFC 3973 PIM - Dense Mode January 2005
GRT(S,G) Expires
The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry.
The Upstream(S,G) state machine stays in the AckPending (AP)
state. Another Graft message for (S,G) SHOULD be unicast to
RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to
Graft_Retry_Period. It is RECOMMENDED that the router retry a
configured number of times before ceasing retries.
GRT(S,G) Expires The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry. The Upstream(S,G) state machine stays in the AckPending (AP) state. Another Graft message for (S,G) SHOULD be unicast to RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is RECOMMENDED that the router retry a configured number of times before ceasing retries.
See GraftAck(S,G) from RPF'(S)
A GraftAck is received from RPF'(S). The GraftRetry Timer MUST
be cancelled, and the Upstream(S,G) state machine MUST transition
to the Forwarding(F) state.
See GraftAck(S,G) from RPF'(S) A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be cancelled, and the Upstream(S,G) state machine MUST transition to the Forwarding(F) state.
4.4.2. Downstream Prune, Join, and Graft Messages
4.4.2. Downstream Prune, Join, and Graft Messages
The Prune(S,G) Downstream state machine for receiving Prune, Join and Graft messages on interface I is given below. This state machine MUST always be in the NoInfo state on the upstream interface. It contains three states.
The Prune(S,G) Downstream state machine for receiving Prune, Join and Graft messages on interface I is given below. This state machine MUST always be in the NoInfo state on the upstream interface. It contains three states.
NoInfo(NI)
The interface has no (S,G) Prune state, and neither the Prune
timer (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is
running.
NoInfo(NI) The interface has no (S,G) Prune state, and neither the Prune timer (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running.
PrunePending(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 PrunePending state functions exactly like the
NoInfo state.
PrunePending(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 PrunePending state functions exactly like the NoInfo state.
Pruned(P)
The router has received a Prune(S,G) on this interface from a
downstream neighbor, and the Prune was not overridden. Data from
S addressed to group G is no longer being forwarded on this
interface.
Pruned(P) The router has received a Prune(S,G) on this interface from a downstream neighbor, and the Prune was not overridden. Data from S addressed to group G is no longer being forwarded on this interface.
In addition, there are two timers:
In addition, there are two timers:
PrunePending Timer (PPT(S,G,I))
This timer is set when a valid Prune(S,G) is received. Expiry of
the PrunePending Timer (PPT(S,G,I)) causes the interface to
transition to the Pruned state.
PrunePending Timer (PPT(S,G,I)) This timer is set when a valid Prune(S,G) is received. Expiry of the PrunePending Timer (PPT(S,G,I)) causes the interface to transition to the Pruned state.
Adams, et al. Experimental [Page 21] RFC 3973 PIM - Dense Mode January 2005
Adams, et al. Experimental [Page 21] RFC 3973 PIM - Dense Mode January 2005
Prune Timer (PT(S,G,I))
This timer is set when the PrunePending Timer (PT(S,G,I))
expires. Expiry of the Prune Timer (PT(S,G,I)) causes the
interface to transition to the NoInfo (NI) state, thereby
allowing data from S addressed to group G to be forwarded on the
interface.
Timer(太平洋標準時(S、G、I)の)から余計なものを取り除いてください。PrunePending Timer(太平洋標準時(S、G、I)の)が期限が切れるとき、このタイマは設定されます。 Prune Timer(太平洋標準時(S、G、I)の)の満期はNoInfo(NI)状態への変遷にインタフェースを引き起こします、その結果、Gを分類するために記述されたSからのデータがインタフェースで転送されるのを許容します。
+-------------+ +-------------+
| | PPT Expires | |
|PrunePending |----------------------->| Pruned |
| | | |
+-------------+ +-------------+
| ^ |
| | |
| |Rcv Prune |
| | |
| | +-------------+ |
| +---------| | |
| | NoInfo |<-------------+
+------------>| | Rcv Join/Graft OR
Rcv Join/Graft OR +-------------+ PT Expires OR
RPF_Interface(S)->I RPF_Interface(S)->I
+-------------+ +-------------+ | | PPTは期限が切れます。| | |PrunePending|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 剪定されます。| | | | | +-------------+ +-------------+ | ^ | | | | | |Rcvプルーン| | | | | | +-------------+ | | +---------| | | | | NoInfo| <、-、-、-、-、-、-、-、-、-、-、-、--+ +------------>|、| Rcvが接合するか、接ぎ木します、またはRcvは/汚職か+に参加します。-------------PTが吐き出す+かRPF_がI RPF_が連結する(S)->を連結する、(S)>I
Figure 2: Downstream Interface State Machine
図2: 川下の界面準位マシン
Adams, et al. Experimental [Page 22] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[22ページ]RFC3973PIM--濃いモード2005年1月
In tabular form, the state machine is as follows:
表にして、州のマシンは以下の通りです:
+-------------------------------+--------------------------------------+ | | Previous State | + +------------+------------+------------+ | Event | No Info | PrunePend | Pruned | +-------------------------------+------------+------------+------------+ | Receive Prune(S,G) |->PP Set |->PP |->P Reset | | | PPT(S,G,I) | | PT(S,G,I) | +-------------------------------+------------+------------+------------+ | Receive Join(S,G) |->NI |->NI Cancel |->NI Cancel | | | | PPT(S,G,I) | PT(S,G,I) | +-------------------------------+------------+------------+------------+ | Receive Graft(S,G) |->NI Send |->NI Send |->NI Send | | | GraftAck | GraftAck | GraftAck | | | | Cancel | Cancel | | | | PPT(S,G,I) | PT(S,G,I) | +-------------------------------+------------+------------+------------+ | PPT(S,G) Expires | N/A |->P Set | N/A | | | | PT(S,G,I) | | +-------------------------------+------------+------------+------------+ | PT(S,G) Expires | N/A | N/A |->NI | +-------------------------------+------------+------------+------------+ | RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel | | | | PPT(S,G,I) | PT(S,G,I) | +-------------------------------+------------+------------+------------+ | Send State Refresh(S,G) out I |->NI |->PP |->P Reset | | | | | PT(S,G,I) | +-------------------------------+------------+------------+------------+
+-------------------------------+--------------------------------------+ | | 先に| + +------------+------------+------------+ | 出来事| インフォメーションがありません。| PrunePend| 剪定されます。| +-------------------------------+------------+------------+------------+ | プルーン(S、G)を受けてください。|->ppはセットしました。|->pp|->Pリセット| | | PPT(S、G、I)| | PT(S、G、I)| +-------------------------------+------------+------------+------------+ | 受信、(S、G)を接合してください。|->Ni|->Niキャンセル|->Niキャンセル| | | | PPT(S、G、I)| PT(S、G、I)| +-------------------------------+------------+------------+------------+ | 汚職(S、G)を受けてください。|->Niは発信します。|->Niは発信します。|->Niは発信します。| | | GraftAck| GraftAck| GraftAck| | | | キャンセル| キャンセル| | | | PPT(S、G、I)| PT(S、G、I)| +-------------------------------+------------+------------+------------+ | PPT(S、G)は期限が切れます。| なし|->Pはセットしました。| なし| | | | PT(S、G、I)| | +-------------------------------+------------+------------+------------+ | PT(S、G)は期限が切れます。| なし| なし|->Ni| +-------------------------------+------------+------------+------------+ | RPF_Interface(S)は私になります。|->Ni|->Niキャンセル|->Niキャンセル| | | | PPT(S、G、I)| PT(S、G、I)| +-------------------------------+------------+------------+------------+ | 発信、出かけているIをリフレッシュする(S、G)ように述べてください。|->Ni|->pp|->Pリセット| | | | | PT(S、G、I)| +-------------------------------+------------+------------+------------+
The transition events "Receive Graft(S,G)", "Receive Prune(S,G)", and "Receive Join(S,G)" denote receiving a Graft, Prune, or Join message in which this router's address on I is contained in the message's upstream neighbor field. If the upstream neighbor field does not match this router's address on I, then these state transitions in this state machine must not occur.
(S、G)を接合します。そして、変遷出来事「汚職(S、G)を受けてください」、「プルーン(S、G)を受ける」、「受信、」 Graftを受けるPruneを指示してください。さもないと、Iに関するこのルータのアドレスがメッセージの上流の隣人分野に保管されているJoinは通信します。 上流の隣人分野であるなら、次に、私、この州のマシンのこれらの状態遷移に関するこのルータのアドレスがそうしなければならないマッチは現れませんか?
4.4.2.1. Transitions from the NoInfo State
4.4.2.1. NoInfo状態からの変遷
When the Prune(S,G) Downstream state machine is in the NoInfo (NI) state, the following events may trigger a transition:
Prune(S、G)の川下の州のマシンがNoInfo(NI)状態にあるとき、以下の出来事は変遷の引き金となるかもしれません:
Receive Prune(S,G)
A Prune(S,G) is received on interface I with the upstream
neighbor field set to the router's address on I. The Prune(S,G)
Downstream state machine on interface I MUST transition to the
PrunePending (PP) state. The PrunePending Timer (PPT(S,G,I))
MUST be set to J/P_Override_Interval if the router has more than
上流の隣人分野とのインタフェースIにI.に関するルータのアドレスに設定されて、受け取られたPrune(S、G)A Prune(S、G)を受けてください。インタフェースIのPrune(S、G)の川下の州のマシンはPrunePending(PP)状態に移行しなければなりません。 ルータに以上があるなら、PrunePending Timer(PPT(S、G、I))は_J/P Override_Intervalに用意ができなければなりません。
Adams, et al. Experimental [Page 23] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[23ページ]RFC3973PIM--濃いモード2005年1月
one neighbor on I. If the router has only one neighbor on
interface I, then it SHOULD set the PPT(S,G,I) to zero,
effectively transitioning immediately to the Pruned (P) state.
I.Ifの上のルータには、ある隣人しかいないある隣人がIを連結して、次に、それはSHOULDです。PPT(S、G、I)をゼロに設定してください、事実上、すぐPruned(P)状態に移行して。
Receive Graft(S,G)
A Graft(S,G) is received on the interface I with the upstream
neighbor field set to the router's address on I. The Prune(S,G)
Downstream state machine on interface I stays in the NoInfo (NI)
state. A GraftAck(S,G) MUST be unicast to the originator of the
Graft(S,G) message.
I. インタフェースIのPrune(S、G)の川下の州のマシンに関するルータのアドレスへの上流の隣人分野セットがあるIがNoInfo(NI)状態にいるインタフェースで受け取られたGraft(S、G)A Graft(S、G)を受けてください。 GraftAck(S、G)はGraft(S、G)メッセージの創始者へのユニキャストであるに違いありません。
4.4.2.2. Transitions from the PrunePending (PP) State
4.4.2.2. PrunePending(pp)状態からの変遷
When the Prune(S,G) downstream state machine is in the PrunePending (PP) state, the following events may trigger a transition.
Prune(S、G)の川下の州のマシンがPrunePending(PP)状態にあるとき、以下の出来事は変遷の引き金となるかもしれません。
Receive Join(S,G)
A Join(S,G) is received on interface I with the upstream neighbor
field set to the router's address on I. The Prune(S,G)
Downstream state machine on interface I MUST transition to the
NoInfo (NI) state. The PrunePending Timer (PPT(S,G,I)) MUST be
cancelled.
上流の隣人分野とのインタフェースIにI.に関するルータのアドレスに設定されて、受け取られたJoin(S、G)A Join(S、G)を受けてください。インタフェースIのPrune(S、G)の川下の州のマシンはNoInfo(NI)状態に移行しなければなりません。 PrunePending Timer(PPT(S、G、I))を取り消さなければなりません。
Receive Graft(S,G)
A Graft(S,G) is received on interface I with the upstream
neighbor field set to the router's address on I. The Prune(S,G)
Downstream state machine on interface I MUST transition to the
NoInfo (NI) state and MUST unicast a Graft Ack message to the
Graft originator. The PrunePending Timer (PPT(S,G,I)) MUST be
cancelled.
上流の隣人分野とのインタフェースIにI.に関するルータのアドレスに設定されて、受け取られたGraft(S、G)A Graft(S、G)を受けてください。インタフェースIのPrune(S、G)の川下の州のマシンは、NoInfo(NI)状態に移行しなければならなくて、Graft創始者へのユニキャストa Graft Ackメッセージが移行しなければなりません。 PrunePending Timer(PPT(S、G、I))を取り消さなければなりません。
PPT(S,G,I) Expires
The PrunePending Timer (PPT(S,G,I)) expires, indicating that no
neighbors have overridden the previous Prune(S,G) message. The
Prune(S,G) Downstream state machine on interface I MUST
transition to the Pruned (P) state. The Prune Timer (PT(S,G,I))
is started and MUST be initialized to the received
Prune_Hold_Time minus J/P_Override_Interval. A PruneEcho(S,G)
MUST be sent on I if I has more than one PIM neighbor. A
PruneEcho(S,G) is simply a Prune(S,G) message multicast by the
upstream router to a LAN, with itself as the Upstream Neighbor.
Its purpose is to add additional reliability so that if a Join
that should have overridden the Prune is lost locally on the LAN,
the PruneEcho(S,G) may be received and trigger a new Join
message. A PruneEcho(S,G) is OPTIONAL on an interface with only
one PIM neighbor. In addition, the router MUST evaluate any
possible transitions in the Upstream(S,G) state machine.
どんな隣人も前のPrune(S、G)メッセージに優越していないのを示して、PPT(S、G、I)は(PPT(S、G、I))が吐き出すPrunePending Timerを吐き出します。 インタフェースIのPrune(S、G)の川下の州のマシンはPruned(P)状態に移行しなければなりません。 Prune Timer(太平洋標準時(S、G、I)の)を始められて、_J/P Override_Intervalを引いて容認された_Prune_Hold Timeに初期化しなければなりません。 私に1人以上のPIM隣人がいるなら、PruneEcho(S、G)は転送された私であるに違いありません。 PruneEcho(S、G)はLANへの上流のルータによる単にPrune(S、G)メッセージマルチキャストです、Upstream Neighborとしてのそれ自体で。 目的は、LANで局所的にPruneをくつがえすはずであったJoinをなくすなら、PruneEcho(S、G)を受け取ることができるように追加信頼性を加えて、新しいJoinメッセージの引き金となることです。 PruneEcho(S、G)は1人のPIM隣人だけとのインタフェースのOPTIONALです。 さらに、ルータはUpstream(S、G)州のマシンのどんな可能な変遷も評価しなければなりません。
Adams, et al. Experimental [Page 24] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[24ページ]RFC3973PIM--濃いモード2005年1月
RPF_Interface(S) becomes interface I
The upstream interface for S has changed. The Prune(S,G)
Downstream state machine on interface I MUST transition to the
NoInfo (NI) state. The PrunePending Timer (PPT(S,G,I)) MUST be
cancelled.
RPF_Interface(S)はSのための上流のインタフェースが変えたインタフェースIになります。 インタフェースIのPrune(S、G)の川下の州のマシンはNoInfo(NI)状態に移行しなければなりません。 PrunePending Timer(PPT(S、G、I))を取り消さなければなりません。
4.4.2.3. Transitions from the Prune (P) State
4.4.2.3. プルーンの(p)状態からの変遷
When the Prune(S,G) Downstream state machine is in the Pruned (P) state, the following events may trigger a transition.
Prune(S、G)の川下の州のマシンがPruned(P)状態にあるとき、以下の出来事は変遷の引き金となるかもしれません。
Receive Prune(S,G)
A Prune(S,G) is received on the interface I with the upstream
neighbor field set to the router's address on I. The Prune(S,G)
Downstream state machine on interface I remains in the Pruned (P)
state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the
holdtime contained in the Prune(S,G) message if it is greater
than the current value.
I. インタフェースIのPrune(S、G)の川下の州のマシンに関するルータのアドレスへの上流の隣人分野セットがあるIがPruned(P)州に残っているインタフェースで受け取られたPrune(S、G)A Prune(S、G)を受けてください。 Prune Timer(太平洋標準時(S、G、I)の)SHOULD、それが現行価値より大きいならPrune(S、G)メッセージに含まれたholdtimeにリセットされてください。
Receive Join(S,G)
A Join(S,G) is received on the interface I with the upstream
neighbor field set to the router's address on I. The Prune(S,G)
downstream state machine on interface I MUST transition to the
NoInfo (NI) state. The Prune Timer (PT(S,G,I)) MUST be
cancelled. The router MUST evaluate any possible transitions in
the Upstream(S,G) state machine.
上流の隣人分野があるIがI.に関するルータのアドレスに設定するインタフェースで受け取られたJoin(S、G)A Join(S、G)を受けてください。インタフェースIのPrune(S、G)の川下の州のマシンはNoInfo(NI)状態に移行しなければなりません。 Prune Timer(太平洋標準時(S、G、I)の)を取り消さなければなりません。 ルータはUpstream(S、G)州のマシンのどんな可能な変遷も評価しなければなりません。
Receive Graft(S,G)
A Graft(S,G) is received on interface I with the upstream
neighbor field set to the router's address on I. The Prune(S,G)
Downstream state machine on interface I MUST transition to the
NoInfo (NI) state and send a Graft Ack back to the Graft's
source. The Prune Timer (PT(S,G,I)) MUST be cancelled. The
router MUST evaluate any possible transitions in the
Upstream(S,G) state machine.
上流の隣人分野とのインタフェースIにI.に関するルータのアドレスに設定されて、受け取られたGraft(S、G)A Graft(S、G)を受けてください。インタフェースIのPrune(S、G)の川下の州のマシンは、NoInfo(NI)状態に移行して、GraftのソースにGraft Ackを送り返さなければなりません。 Prune Timer(太平洋標準時(S、G、I)の)を取り消さなければなりません。 ルータはUpstream(S、G)州のマシンのどんな可能な変遷も評価しなければなりません。
PT(S,G,I) Expires
The Prune Timer (PT(S,G,I)) expires, indicating that it is again
time to flood data from S addressed to group G onto interface I.
The Prune(S,G) Downstream state machine on interface I MUST
transition to the NoInfo (NI) state. The router MUST evaluate
any possible transitions in the Upstream(S,G) state machine.
PT(S、G、I)は(PT(S、G、I))が吐き出すPrune Timerを吐き出します、再びGをインタフェースI.に分類するために記述されたSからデータをあふれさせるように、インタフェースIのPrune(S、G)の川下の州のマシンがNoInfo(NI)状態に移行しなければならないという時間であることを示して。 ルータはUpstream(S、G)州のマシンのどんな可能な変遷も評価しなければなりません。
RPF_Interface(S) becomes interface I
The upstream interface for S has changed. The Prune(S,G)
Downstream state machine on interface I MUST transition to the
NoInfo (NI) state. The PruneTimer (PT(S,G,I)) MUST be cancelled.
RPF_Interface(S)はSのための上流のインタフェースが変えたインタフェースIになります。 インタフェースIのPrune(S、G)の川下の州のマシンはNoInfo(NI)状態に移行しなければなりません。 PruneTimer(太平洋標準時(S、G、I)の)を取り消さなければなりません。
Adams, et al. Experimental [Page 25] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[25ページ]RFC3973PIM--濃いモード2005年1月
Send State Refresh(S,G) out interface I
The router has refreshed the Prune(S,G) state on interface I.
The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime
from an active Prune received on interface I. The Holdtime used
SHOULD be the largest active one but MAY be the most recently
received active Prune Holdtime.
ルータがリフレッシュした州Refresh(S、G)の出かけているインタフェースIにインタフェースI.のPrune(S、G)状態を送ってください。ルータはインタフェースI.に受け取られたアクティブなPruneからHoldtimeにPrune Timer(太平洋標準時(S、G、I)の)をリセットしなければなりません。Holdtimeの中古のSHOULDは最も大きいアクティブな方ですが、最も最近容認されたアクティブなPrune Holdtimeであってもよいです。
4.5. State Refresh
4.5. リフレッシュするように述べてください。
This section describes the major portions of the state refresh mechanism.
このセクションは主要部について説明します。状態では、メカニズムをリフレッシュしてください。
4.5.1. Forwarding of State Refresh Messages
4.5.1. 進めて、状態では、メッセージをリフレッシュしてください。
When a State Refresh message, SRM, is received, it is forwarded according to the following pseudo-code.
州Refreshメッセージ(SRM)が受信されているとき、以下の中間コードに応じて、それを進めます。
if (iif != RPF_interface(S))
return;
if (RPF'(S) != srcaddr(SRM))
return;
if (StateRefreshRateLimit(S,G) == TRUE)
return;
(iif!はRPF_インタフェース(S))リターンと等しいです。 (RPF'(S)!=srcaddr(SRM)リターン'。 (StateRefreshRateLimit(S、G)=TRUE)が戻るなら。
for each interface I in pim_nbrs {
if (TTL(SRM) == 0 OR (TTL(SRM) - 1) < Threshold(I))
continue; /* Out of TTL, skip this interface */
if (boundary(I,G))
continue; /* This interface is scope boundary, skip it */
if (I == iif)
continue; /* This is the incoming interface, skip it */
if (lost_assert(S,G,I) == TRUE)
continue; /* Let the Assert Winner do State Refresh */
TTLからの/*、(境界(I、G))が続くなら、このインタフェース*/をスキップしてください; これが連結する/*は範囲境界であり、0OR(TTL(SRM)--1)<TTL(SRM)=Threshold(I))は続きます; スキップはそれです。pim_nbrsの各インタフェースI、(*/は(私=iif)であるなら続きます;、/、*これが入って来るインタフェースであり、*/を気にしてください、(_失われて、(S、G、I)=TRUE)は続きます; Assert Winnerが/*で州Refresh*/をしたと断言してください。
Copy SRM to SRM'; /* Make a copy of SRM to forward */
'SRMへのコピーSRM'。 /*は、*/を進めるためにSRMのコピーを作ります。
if (I contained in prunes(S,G)) {
set Prune Indicator bit of SRM' to 1;
'、(私はプルーンに(S、G)を含みました)、SRMのPrune Indicatorビットを設定してください、'1に。
if StateRefreshCapable(I) == TRUE
set PT(S,G) to largest active holdtime read from a Prune
message accepted on I;
StateRefreshCapable(I)=TRUEがセットするなら、Pruneメッセージからの最も大きい活発なholdtime読書へのPT(S、G)はIで受け入れました。
Adams, et al. Experimental [Page 26] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[26ページ]RFC3973PIM--濃いモード2005年1月
} else {
set Prune Indicator bit of SRM' to 0;
}
ほか'、SRMのPrune Indicatorビットを設定してください、'0に。 }
set srcaddr(SRM') to my_addr(I);
set TTL of SRM' to TTL(SRM) - 1;
set metric of SRM' to metric of unicast route used to reach S;
set pref of SRM' to preference of unicast route used to reach S;
set mask of SRM' to mask of route used to reach S;
'srcaddrを設定してください、(SRM、'、)、私の_addr(I)に。 TTL(SRM)への'SRMのTTLを設定してください'--1 ユニキャストルートにおけるメートル法への'SRMにおけるメートル法のセット'は以前はよくSに達していました。 ユニキャストルートの好みへの'SRMのセットpref'は以前はよくSに達していました。 ルートのマスクへの'SRMのセットマスク'は以前はよくSに達していました。
if (AssertState == NoInfo) {
set Assert Override of SRM' to 1;
} else {
set Assert Override of SRM' to 0;
}
'(AssertState=NoInfo)である、SRMのAssert Overrideを設定してください、'1に;、ほか'、SRMのAssert Overrideを設定してください、'0に。
transmit SRM' on I;
}
Iの'SRMを伝えてください'。 }
The pseudocode above employs the following macro definitions.
上記の擬似コードは以下のマクロ定義を使います。
Boundary(I,G) is TRUE if an administratively scoped boundary for group G is configured on interface I.
グループGのための行政上見られた境界がインタフェースIで構成されるなら、境界(I、G)はTRUEです。
StateRefreshCapable(I) is TRUE if all neighbors on an interface use the State Refresh option.
インタフェースのすべての隣人が州Refreshオプションを使用するなら、StateRefreshCapable(I)はTRUEです。
StateRefreshRateLimit(S,G) is TRUE if the time elapsed since the last received StateRefresh(S,G) is less than the configured RefreshLimitInterval.
最終がStateRefresh(S、G)を受けたので経過時間が構成されたRefreshLimitInterval以下であるなら、StateRefreshRateLimit(S、G)はTRUEです。
TTL(SRM) returns the TTL contained in the State Refresh Message, SRM. This is different from the TTL contained in the IP header.
TTL(SRM)は州Refresh Message、SRMに含まれたTTLを返します。 これはIPヘッダーに含まれたTTLと異なっています。
Threshold(I) returns the minimum TTL that a packet must have before it can be transmitted on interface I.
インタフェースIでそれを伝えることができる前に敷居(I)はパケットが持たなければならない最小のTTLを返します。
srcaddr(SRM) returns the source address contained in the network protocol (e.g., IPv4) header of the State Refresh Message, SRM.
srcaddr(SRM)は州Refresh Message、SRMのネットワーク・プロトコル(例えば、IPv4)ヘッダーに含まれたソースアドレスを返します。
my_addr(I) returns this node's network (e.g., IPv4) address on interface I.
私の_addr(I)はインタフェースIに関するこのノードのネットワーク(例えば、IPv4)アドレスを返します。
Adams, et al. Experimental [Page 27] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[27ページ]RFC3973PIM--濃いモード2005年1月
4.5.2. State Refresh Message Origination
4.5.2. メッセージ創作をリフレッシュするように述べてください。
This section describes the origination of State Refresh messages. These messages are generated periodically by the PIM-DM router directly connected to a source. One Origination(S,G) state machine exists per (S,G) entry in a PIM-DM router.
このセクションは州Refreshメッセージの創作について説明します。 これらのメッセージは定期的に直接ソースに接されたPIM-DMルータで発生します。 1台のOrigination(S、G)州のマシンがPIM-DMルータで(S、G)エントリー単位で存在しています。
The Origination(S,G) state machine has the following states:
Origination(S、G)州のマシンには、以下の州があります:
NotOriginator(NO)
This is the starting state of the Origination(S,G) state machine.
While in this state, a router will not originate State Refresh
messages for the (S,G) pair.
NotOriginator、(いいえ) これはOrigination(S、G)州のマシンの始めの状態です。 ルータは(S、G)組のためにこの状態で州Refreshメッセージを溯源しないでしょうが。
Originator(O)
When in this state the router will periodically originate State
Refresh messages. Only routers directly connected to S may
transition to this state.
この状態のルータであるときに、創始者(O)は定期的に州Refreshメッセージを溯源するでしょう。 直接Sに接続されたルータだけはこの状態への変遷がそうするかもしれません。
In addition, there are two state machine specific timers:
さらに、2州のマシン特有のタイマがあります:
State Refresh Timer (SRT(S,G))
This timer controls when State Refresh messages are generated.
The timer is initially set when that Origination(S,G) state
machine transitions to the O state. It is cancelled when the
Origination(S,G) state machine transitions to the NO state. This
timer is normally set to StateRefreshInterval (see 4.8).
州Refreshメッセージが発生するときこのタイマが制御するRefresh Timer(SRT(S、G))を述べてください。 そのOrigination(S、G)が初めはO状態へのマシン変遷を述べるとき、タイマは設定されます。 Origination(S、G)がいいえ状態へのマシン変遷を述べるとき、それは取り消されます。 通常、このタイマはStateRefreshIntervalに設定されます(4.8を見てください)。
Source Active Timer (SAT(S,G))
This timer is first set when the Origination(S,G) state machine
transitions to the O state and is reset on the receipt of every
data packet from S addressed to group G. When it expires, the
Origination(S,G) state machine transitions to the NO state. This
timer is normally set to SourceLifetime (see 4.8).
Active Timer(土曜日(S、G))の出典を明示してください。このタイマによるOrigination(S、G)がO状態へのマシン変遷を述べるときの第一セットであり、あらゆるデータ・パケットの領収書の上にG.Whenを分類するために記述されたSからリセットされて、期限が切れます、いいえ状態へのOrigination(S、G)州のマシン変遷ということです。 通常、このタイマはSourceLifetimeに設定されます(4.8を見てください)。
+-------------+ Rcv Directly From S +-------------+
| |----------------------->| |
|NotOriginator| | Originator |
| |<-----------------------| |
+-------------+ SAT Expires OR +-------------+
S NOT Direct Connect
+-------------+ 直接S+からのRcv-------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |NotOriginator| | 創始者| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +-------------土曜日が吐き出す+か+-------------Sが指示しない+は接続します。
Figure 3: State Refresh State Machine
図3: 州のマシンをリフレッシュするように述べてください。
Adams, et al. Experimental [Page 28] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[28ページ]RFC3973PIM--濃いモード2005年1月
In tabular form, the state machine is defined as follows:
表にして、州のマシンは以下の通り定義されます:
+----------------------------------------------------------------------+ | | Previous State | | +---------------+-------------------+ | Event | NotOriginator | Originator | +----------------------------------+---------------+-------------------+ | Receive Data from S AND | ->O | ->O Reset | | S directly connected | Set SRT(S,G) | SAT(S,G) | | | Set SAT(S,G) | | +----------------------------------+---------------+-------------------+ | SRT(S,G) Expires | N/A | ->O Send | | | | StateRefresh(S,G) | | | | Reset SRT(S,G) | +----------------------------------+---------------+-------------------+ | SAT(S,G) Expires | N/A | ->NO Cancel | | | | SRT(S,G) | +----------------------------------+---------------+-------------------+ | S no longer directly connected | ->NO | ->NO | | | | Cancel SRT(S,G) | | | | Cancel SAT(S,G) | +----------------------------------+---------------+-------------------+
+----------------------------------------------------------------------+ | | 先に| | +---------------+-------------------+ | 出来事| NotOriginator| 創始者| +----------------------------------+---------------+-------------------+ | S ANDからの受信データ| ->O| ->Oリセット| | 直接接続されたS| SRT(S、G)を設定してください。| 座っています(S、G)。| | | 土曜日(S、G)にセットします。| | +----------------------------------+---------------+-------------------+ | SRT(S、G)は期限が切れます。| なし| ->Oは発信します。| | | | StateRefresh(S、G)| | | | リセットSRT(S、G)| +----------------------------------+---------------+-------------------+ | 土曜日に、(S、G)は期限が切れます。| なし| ->いいえキャンセル| | | | SRT(S、G)| +----------------------------------+---------------+-------------------+ | もう直接接続されなかったS| ->ノー| ->ノー| | | | SRT(S、G)を取り消してください。| | | | 土曜日に(S、G)を取り消してください。| +----------------------------------+---------------+-------------------+
4.5.2.1. Transitions from the NotOriginator (NO) State
4.5.2.1. NotOriginator(いいえ)状態からの変遷
When the Originating(S,G) state machine is in the NotOriginator (NO) state, the following event may trigger a transition:
Originating(S、G)州のマシンがNotOriginator(いいえ)状態にあるとき、以下の出来事は変遷の引き金となるかもしれません:
Data Packet received from directly connected Source S addressed to
group G
The router MUST transition to an Originator (O) state, set
SAT(S,G) to SourceLifetime, and set SRT(S,G) to
StateRefreshInterval. The router SHOULD record the TTL of the
packet for use in State Refresh messages.
ルータがそうしなければならないグループGに記述された直接接続されたSource Sから変遷を土曜日(S、G)にSourceLifetimeに設定されたOriginator(O)状態に受信して、データPacketはセットSRT(S、G)をStateRefreshIntervalに受信しました。 ルータSHOULDは州Refreshメッセージにおける使用のためにパケットのTTLを記録します。
4.5.2.2. Transitions from the Originator (O) State
4.5.2.2. 創始者(o)状態からの変遷
When the Originating(S,G) state machine is in the Originator (O) state, the following events may trigger a transition:
Originating(S、G)州のマシンがOriginator(O)状態にあるとき、以下の出来事は変遷の引き金となるかもしれません:
Receive Data Packet from S addressed to G
The router remains in the Originator (O) state and MUST reset
SAT(S,G) to SourceLifetime. The router SHOULD increase its
recorded TTL to match the TTL of the packet, if the packet's TTL
is larger than the previously recorded TTL. A router MAY record
the TTL based on an implementation specific sampling policy to
avoid examining the TTL of every multicast packet it handles.
土曜日の(O)が述べて、リセットしなければならないOriginatorにルータの残りのGに記述されたS(S、G)からSourceLifetimeまでData Packetを受けてください。 ルータSHOULDはパケットのTTLを合わせるために記録されたTTLを増加させます、パケットのTTLが以前に記録されたTTLより大きいなら。 ルータはそれが扱うあらゆるマルチキャストパケットのTTLを調べるのを避けるために実現の特定の標本抽出方針に基づくTTLを記録するかもしれません。
Adams, et al. Experimental [Page 29] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[29ページ]RFC3973PIM--濃いモード2005年1月
SRT(S,G) Expires
The router remains in the Originator (O) state and MUST reset
SRT(S,G) to StateRefreshInterval. The router MUST also generate
State Refresh messages for transmission, as described in the
State Refresh Forwarding rules (Section 4.5.1), except for the
TTL. If the TTL of data packets from S to G are being recorded,
then the TTL of each State Refresh message is set to the highest
recorded TTL. Otherwise, the TTL is set to the configured State
Refresh TTL. Let I denote the interface over which a State
Refresh message is being sent. If the Prune(S,G) Downstream
state machine is in the Pruned (P) state, then the Prune-
Indicator bit MUST be set to 1 in the State Refresh message being
sent over I. Otherwise, the Prune-Indicator bit MUST be set to 0.
SRT(S、G)はOriginator(O)状態にルータの残りを吐き出して、SRT(S、G)をStateRefreshIntervalにリセットしなければなりません。 また、ルータはトランスミッションへの州Refreshメッセージを発生させなければなりません、州Refresh Forwarding規則(セクション4.5.1)で説明されるように、TTLを除いて。 SからGまでのデータ・パケットのTTLが記録されているなら、それぞれの州RefreshメッセージのTTLは最も高い記録されたTTLに用意ができています。 さもなければ、TTLは構成された州Refresh TTLに用意ができています。 貸されて、私は州Refreshメッセージが送られるインタフェースを指示します。 Prune(S、G)の川下の州のマシンがPruned(P)状態にあるなら、I.Otherwiseの上に送られる州Refreshメッセージの1にPruneインディケータビットを設定しなければならなくて、Prune-インディケータビットを0に設定しなければなりません。
SAT(S,G) Expires
The router MUST cancel the SRT(S,G) timer and transition to the
NotOriginator (NO) state.
土曜日に、(S、G)はルータを吐き出します。NotOriginator(いいえ)状態へのSRT(S、G)タイマと変遷を中止しなければなりません。
S is no longer directly connected
The router MUST transition to the NotOriginator (NO) state and
cancel both the SAT(S,G) and SRT(S,G).
Sによるもう直接接続されないで、ルータがNotOriginator(いいえ)状態に移行して、土曜日(S、G)、SRT(S、G)の両方を取り消さなければならないということです。
4.6. PIM Assert Messages
4.6. PIMはメッセージについて断言します。
4.6.1. Assert Metrics
4.6.1. 測定基準について断言してください。
Assert metrics are defined as follows:
測定基準が以下の通り定義されると断言してください:
struct assert_metric {
metric_preference;
route_metric;
ip_address;
};
structはメートル法で_について断言します。メートル法の_好み; メートル法で_を発送してください; ip_アドレス。
When assert_metrics are compared, the metric_preference and route_metric field are compared in order, where the first lower value wins. If all fields are equal, the IP address of the router that sourced the Assert message is used as a tie-breaker, with the highest IP address winning.
いつが、オーダーで_測定基準が比べて、メートル法の_好みとルート_メートル法の分野が比較されるということであると断言しますか?そこでは、最初の下側の値が得られます。 すべての分野が等しいなら、出典を明示されて、AssertメッセージがそうであるルータのIPアドレスがタイブレークとして使用されて、最も高いIPと共に、勝利を記述してください。
Adams, et al. Experimental [Page 30] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[30ページ]RFC3973PIM--濃いモード2005年1月
An Assert metric for (S,G) to include in (or compare against) an Assert message sent on interface I should be computed by using the following pseudocode:
中(比較する)にAssertメッセージを含む(S、G)における、メートル法のAssertは、インタフェースIが以下の擬似コードを使用することによって計算されるべきであるのを転送しました:
assert_metric
my_assert_metric(S,G,I) {
if (CouldAssert(S,G,I) == TRUE) {
return spt_assert_metric(S,G,I)
} else {
return infinite_assert_metric()
}
}
メートル法で_について断言してください、私の_はメートル法で(S、G、I)_について断言します。(CouldAssert(S、G、I)=TRUE)がほかにメートル法で(S、G、I)_が_であると断言するsptを返すなら、リターンの無限の_は、_がメートル法の()であると断言します。
spt_assert_metric(S,I) gives the Assert metric we use if we're sending an Assert based on active (S,G) forwarding state:
spt_はメートル法で_について断言します。私たちが活動的な(S、G)推進状態に基づくAssertを送るなら、(S、I)はメートル法の私たちが使用するAssertに与えます:
assert_metric
spt_assert_metric(S,I) {
return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)}
}
_メートル法のspt_がメートル法で(S、I)_について断言すると断言してください。0、MRIB.pref(S)、MRIB.metric(S)、私の_addr(I)を返してください。
MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing metrics associated with the route to a particular (unicast) destination X, as determined by the MRIB. my_addr(I) is simply the router's network (e.g., IP) address associated with the local interface I.
MRIB.pref(X)とMRIB.metric(X)は特定の(ユニキャスト)の目的地Xへのルートに関連しているルーティング好みとルーティング測定基準です、MRIBによって決定されるように。私の_addr(I)による単にネットワーク(例えば、IP)アドレスが局所界面に関連づけたルータが私であるということです。
infinite_assert_metric() gives the Assert metric we need to send an Assert but doesn't match (S,G) forwarding state:
無限の_は、_メートル法の()がメートル法の私たちが送る必要があるAssertにAssertを与えますが、推進状態に合っていない(S、G)と断言します:
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,0}
}
_メートル法の無限の_が、_がメートル法の()であると断言すると断言してください。リターン、1、無限、無限、0
4.6.2. AssertCancel Messages
4.6.2. AssertCancelメッセージ
An AssertCancel(S,G) message is simply an Assert message for (S,G) with infinite metric. The Assert winner sends this message when it changes its upstream interface to this interface. Other routers will see this metric, causing those with forwarding state to send their own Asserts and re-establish an Assert winner.
AssertCancel(S、G)メッセージは単に無限によるメートル法の(S、G)へのAssertメッセージです。 それが上流のインタフェースをこのインタフェースに変えるとき、Assert勝者はこのメッセージを送ります。 他のルータは、これがメートル法であることを見るでしょう、推進状態があるものがそれら自身のAssertsを送って、Assert勝者を復職させることを引き起こして。
AssertCancel messages are simply an optimization. The original Assert timeout mechanism will eventually allow a subnet to become consistent; the AssertCancel mechanism simply causes faster convergence. No special processing is required for an AssertCancel message, as it is simply an Assert message from the current winner.
AssertCancelメッセージは単に最適化です。 オリジナルのAssertタイムアウトメカニズムによって、サブネットは結局、一貫するようになるでしょう。 AssertCancelメカニズムは単により速い集合を引き起こします。 どんな特別な処理も、それが単に現在の勝者からのAssertメッセージであるので、AssertCancelメッセージに必要ではありません。
Adams, et al. Experimental [Page 31] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[31ページ]RFC3973PIM--濃いモード2005年1月
4.6.3. Assert State Macros
4.6.3. 状態がマクロであると断言してください。
The macro lost_assert(S,G,I), is used in the olist computations of Section 4.1.3, and is defined as follows:
マクロ無くなっている_は、(S、G、I)がセクション4.1.3のolist計算に使用されて、以下の通り定義されると断言します:
bool lost_assert(S,G,I) {
if ( RPF_interface(S) == I ) {
return FALSE
} else {
return (AssertWinner(S,G,I) != me AND
(AssertWinnerMetric(S,G,I) is better than
spt_assert_metric(S,G,I)))
}
}
無くなっている_が断言するbool(S、G、I)(RPF_インタフェース(S)=私)がほかにFALSEを返す、リターン、(AssertWinner(S、G、I)!=私と(AssertWinnerMetric(S、G、I)はspt_がメートル法で(S、G、I)_について断言するより良いです))
AssertWinner(S,G,I) defaults to NULL, and AssertWinnerMetric(S,G,I) defaults to Infinity when in the NoInfo state.
AssertWinner(S、G、I)はNULLをデフォルトとします、そして、NoInfo状態にあるとき、AssertWinnerMetric(S、G、I)はInfinityをデフォルトとします。
4.6.4. (S,G) Assert Message State Machine
4.6.4. (S、G) メッセージ状態がマシンであると断言してください。
The (S,G) Assert state machine for interface I is shown in Figure 4. There are three states:
(S、G)は、インタフェースIへの州のマシンが図4で見せられると断言します。 3つの州があります:
NoInfo (NI)
This router has no (S,G) Assert state on interface I.
NoInfo、(NI) このルータで、いいえ(S、G)はインタフェースIで状態について断言します。
I am Assert Winner (W)
This router has won an (S,G) Assert on interface I. It is now
responsible for forwarding traffic from S destined for G via
interface I.
私がこのルータが獲得したAssert Winner(W)である、(S、G)は、Itが現在責任があるインタフェースI.で交通を進めて、Sから、私がGのためにインタフェースを通して運命づけていたと断言します。
I am Assert Loser (L)
This router has lost an (S,G) Assert on interface I. It must not
forward packets from S destined for G onto interface I.
私がこのルータがなくしたAssert Loser(L)である、(S、G)は、インタフェースI.でItがGのためにインタフェースIに運命づけられたSからパケットを進めてはいけないと断言します。
In addition, an Assert Timer (AT(S,G,I)) is used to time out the Assert state.
さらに、Assert Timer(AT(S、G、I))はAssertが述べるタイムアウトに使用されます。
Adams, et al. Experimental [Page 32] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[32ページ]RFC3973PIM--濃いモード2005年1月
+-------------+ +-------------+
| | Rcv Pref Assert or SR | |
| Winner |----------------------->| Loser |
| | | |
+-------------+ +-------------+
^ | ^ |
| | Rcv Pref Assert or| |
| |AT Expires OR State Refresh| |
| |CouldAssert->FALSE | |
| | | |
| | +-------------+ | |
| +-------->| |----------+ |
| | No Info | |
+-------------| |<-------------+
Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR
OR Rcv Inferior Assert Rcv Inf SR from Winner OR
OR Rcv Inferior SR AT Expires OR
CouldAssert Changes OR
Winner's NLT Expires
+-------------+ +-------------+ | | Rcv Prefが断言する、SR| | | 勝者|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 敗者| | | | | +-------------+ +-------------+ ^ | ^ | | | またはRcv Prefが断言する。| | | |期限が切れるか、またはリフレッシュするように述べます。| | | |CouldAssert->、誤り| | | | | | | | +-------------+ | | | +-------->| |----------+ | | | インフォメーションがありません。| | +-------------| | <、-、-、-、-、-、-、-、-、-、-、-、--+ dnstrm+からのRcv Data-------------+ Rcv Infが、Win ORかRcv目下から勝者ORかRcvの粗悪なSRからRcv Inf SRについて断言するように断言する、CouldAssert変化か勝者のNLTが吐き出すORを吐き出します。
Figure 4: Assert State Machine
図4: 状態がマシンであると断言してください。
In tabular form, the state machine is defined as follows:
表にして、州のマシンは以下の通り定義されます:
+-------------------------------+--------------------------------------+ | | Previous State | | +------------+------------+------------+ | Event | No Info | Winner | Loser | +-------------------------------+------------+------------+------------+ | An (S,G) Data packet received | ->W Send | ->W Send | ->L | | on downstream interface | Assert(S,G)| Assert(S,G)| | | | Set | Set | | | | AT(S,G,I) | AT(S,G,I) | | +-------------------------------+--------------------------------------+ | Receive Inferior (Assert OR | N/A | N/A |->NI Cancel | | State Refresh) from Assert | | | AT(S,G,I) | | Winner | | | | +-------------------------------+--------------------------------------+ | Receive Inferior (Assert OR | ->W Send | ->W Send | ->L | | State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| | | Winner AND CouldAssert==TRUE | Set | Set | | | | AT(S,G,I) | AT(S,G,I) | | +-------------------------------+--------------------------------------+
+-------------------------------+--------------------------------------+ | | 先に| | +------------+------------+------------+ | 出来事| インフォメーションがありません。| 勝者| 敗者| +-------------------------------+------------+------------+------------+ | (S、G)データ・パケットは受信されました。| ->Wは発信します。| ->Wは発信します。| ->L| | 川下のインタフェースに関して| (S、G)について断言してください。| (S、G)について断言してください。| | | | セットします。| セットします。| | | | (S、G、I)で| (S、G、I)で| | +-------------------------------+--------------------------------------+ | 劣った状態で、受信してください。(ORについて断言してください|、なし|、なし、|、-、>Ni、| | 州がリフレッシュするキャンセル)、断言| | | (S、G、I)で| | 勝者| | | | +-------------------------------+--------------------------------------+ | 目下(ORについて断言してください| ->Wは発信します| ->Wは発信します| ->L| | 状態はリフレッシュする)を受ける、非、断言| (S、G)について断言してください。| (S、G)について断言してください。| | | 勝者AND CouldAssert=、本当| セットします。| セットします。| | | | (S、G、I)で| (S、G、I)で| | +-------------------------------+--------------------------------------+
Adams, et al. Experimental [Page 33] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[33ページ]RFC3973PIM--濃いモード2005年1月
+-------------------------------+--------------------------------------+ | | Previous State | | +------------+------------+------------+ | Event | No Info | Winner | Loser | +-------------------------------+------------+------------+------------+ | Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set | | State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) | | | Set | Set | | | | AT(S,G,I) | AT(S,G,I) | | +-------------------------------+--------------------------------------+ | Send State Refresh | ->NI | ->W Reset | N/A | | | | AT(S,G,I) | | +-------------------------------+--------------------------------------+ | AT(S,G) Expires | N/A | ->NI | ->NI | +-------------------------------+--------------------------------------+ | CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel | | | | AT(S,G,I) | AT(S,G,I) | +-------------------------------+--------------------------------------+ | CouldAssert -> TRUE | ->NI | N/A |->NI Cancel | | | | | AT(S,G,I) | +-------------------------------+--------------------------------------+ | Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel | | | | | AT(S,G,I) | +-------------------------------+--------------------------------------+ | Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send | | or Graft(S,G) | | | Assert(S,G)| +-------------------------------+--------------------------------------+
+-------------------------------+--------------------------------------+ | | 先に| | +------------+------------+------------+ | 出来事| インフォメーションがありません。| 勝者| 敗者| +-------------------------------+------------+------------+------------+ | 受信、好まれて、ORについて断言してください。| ->Lは発信します。| ->Lは発信します。| ->Lはセットしました。| | リフレッシュするように述べてください。| (S、G)を剪定してください。| (S、G)を剪定してください。| (S、G、I)で| | | セットします。| セットします。| | | | (S、G、I)で| (S、G、I)で| | +-------------------------------+--------------------------------------+ | 発信、リフレッシュするように述べてください。| ->Ni| ->Wリセット| なし| | | | (S、G、I)で| | +-------------------------------+--------------------------------------+ | (S、G)は期限が切れます。| なし| ->Ni| ->Ni| +-------------------------------+--------------------------------------+ | CouldAssert->偽| ->Ni|->Niキャンセル|->Niキャンセル| | | | (S、G、I)で| (S、G、I)で| +-------------------------------+--------------------------------------+ | CouldAssert->、本当| ->Ni| なし|->Niキャンセル| | | | | (S、G、I)で| +-------------------------------+--------------------------------------+ | 勝者のNLT(N、I)は期限が切れます。| なし| なし|->Niキャンセル| | | | | (S、G、I)で| +-------------------------------+--------------------------------------+ | プルーン(S、G)を受けてください、そして、(S、G)を接合してください。| ->Ni| ->W| ->Lは発信します。| | または、(S、G)を接ぎ木してください。| | | (S、G)について断言してください。| +-------------------------------+--------------------------------------+
Terminology: A "preferred assert" is one with a better metric than the current winner. An "inferior assert" is one with a worse metric than my_assert_metric(S,G,I).
用語: 「都合のよさ、断言、」 aが現在の勝者よりよくメートル法であることで1つがありますか? 「目下が断言する、」 aが、より悪い1つは私の_がメートル法で(S、G、I)_について断言するよりメートル法ですか?
The state machine uses the following macro:
州のマシンは以下のマクロを使用します:
CouldAssert(S,G,I) = (RPF_interface(S) != I)
CouldAssert(S、G、I)=(RPF_インタフェース(S)!=私)
4.6.4.1. Transitions from NoInfo State
4.6.4.1. NoInfo状態からの変遷
In the NoInfo state, the following events may trigger transitions:
NoInfo状態では、以下の出来事は変遷の引き金となるかもしれません:
An (S,G) data packet arrives on downstream interface I
An (S,G) data packet arrived on a downstream interface. It is
optimistically assumed that this router will be the Assert winner
for this (S,G). The Assert state machine MUST transition to the
"I am Assert Winner" state, send an Assert(S,G) to interface I,
store its own address and metric as the Assert Winner, and set
the Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating
the Assert negotiation for (S,G).
(S、G)データ・パケットは川下のインタフェースI An(S、G)データ・パケットの上で到着します。川下のインタフェースでは、到着しました。 このルータがこれ(S、G)のためにAssert勝者になると楽観的に思われます。 Assert州のマシンは、「私はAssert Winnerです」状態に移行して、Iを連結するように、Assert(S、G)を送って、自分自身Assert Winnerとしてのアドレスの、そして、メートル法ののを格納して、Assert_Timerを設定しなければなりません。(その結果(S、G)のためのAssert交渉を開始するAssert_TimeへのAT(S、G、I)。
Adams, et al. Experimental [Page 34] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[34ページ]RFC3973PIM--濃いモード2005年1月
Receive Inferior (Assert OR State Refresh) AND
CouldAssert(S,G,I)==TRUE
An Assert or State Refresh is received for (S,G) that is inferior
to our own assert metric on interface I. The Assert state machine
MUST transition to the "I am Assert Winner" state, send an
Assert(S,G) to interface I, store its own address and metric as
the Assert Winner, and set the Assert Timer (AT(S,G,I)) to
Assert_Time.
TRUE An Assertか州Refreshが受け取られている私たち自身のに劣ったInferior(OR州Refreshについて断言する)とCouldAssert(S、G、I)=(S、G)を受けてください、断言、メートル法、インタフェースI.では、Assert州のマシンは、Assert_Timeに「私はAssert Winnerです」状態に移行して、Iを連結するように、Assert(S、G)を送って、自分自身Assert Winnerとしてのアドレスの、そして、メートル法ののを格納して、Assert Timer(AT(S、G、I))を設定しなければなりません。
Receive Preferred Assert or State Refresh
The received Assert or State Refresh has a better metric than
this router's, and therefore the Assert state machine MUST
transition to the "I am Assert Loser" state and store the Assert
Winner's address and metric. If the metric was received in an
Assert, the router MUST set the Assert Timer (AT(S,G,I)) to
Assert_Time. If the metric was received in a State Refresh, the
router MUST set the Assert Timer (AT(S,G,I)) to three times the
received State Refresh Interval. If CouldAssert(S,G,I) == TRUE,
the router MUST also multicast a Prune(S,G) to the Assert winner
with a Prune Hold Time equal to the Assert Timer and evaluate any
changes in its Upstream(S,G) state machine.
Preferred Assertを受けてください。さもないと、州Refreshの容認されたAssertか州Refreshがaをルータのこのものよりよくメートル法にします、そして、したがって、Assert州のマシンは「私はAssert Loserです」状態に移行して、Assert Winnerのアドレスとメートル法を格納しなければなりません。 Assertにメートル法を受け取ったなら、ルータはAssert Timer(AT(S、G、I))をAssert_Timeに設定しなければなりません。 州Refreshにメートル法を受け取ったなら、ルータはAssert Timer(AT(S、G、I))を容認された州Refresh Intervalの3倍に設定しなければなりません。 ルータがCouldAssert(S、G、I)=TRUEであるなら、TRUEでなければならなくて、また、Prune Hold TimeをもっているAssert勝者へのマルチキャストa Prune(S、G)はUpstream(S、G)州のマシンにおけるどんな変化ともAssert Timerと等しく、評価します。
4.6.4.2. Transitions from Winner State
4.6.4.2. 勝者状態からの変遷
When in "I am Assert Winner" state, the following events trigger transitions:
以下の出来事が「私はAssert Winnerです」状態で変遷の引き金となると:
An (S,G) data packet arrives on downstream interface I
An (S,G) data packet arrived on a downstream interface. The
Assert state machine remains in the "I am Assert Winner" state.
The router MUST send an Assert(S,G) to interface I and set the
Assert Timer (AT(S,G,I) to Assert_Time.
(S、G)データ・パケットは川下のインタフェースI An(S、G)データ・パケットの上で到着します。川下のインタフェースでは、到着しました。 Assert州のマシンは「私はAssert Winnerです」州に残っています。 ルータは、Iを連結して、Assert Timerを設定するために、Assert(S、G)を送らなければなりません。(Assert_TimeへのAT(S、G、I)。
Receive Inferior Assert or State Refresh
An (S,G) Assert is received containing a metric for S that is
worse than this router's metric for S. Whoever sent the Assert
is in error. The router MUST send an Assert(S,G) to interface I
and reset the Assert Timer (AT(S,G,I)) to Assert_Time.
Inferior Assertを受けてください。さもないと、S.WhoeverがAssertを送ったので、Refresh An(S、G)がこのルータがメートル法であるより悪いSにおける、メートル法のaを含むのにおいて受け取られていると断言する州は間違っています。 ルータは、Iを連結する(S、G)をAssertに送って、Assert_TimeへのAssert Timer(AT(S、G、I))をリセットに送らなければなりません。
Receive Preferred Assert or State Refresh
An (S,G) Assert or State Refresh is received that has a better
metric than this router's metric for S on interface I. The
Assert state machine MUST transition to "I am Assert Loser" state
and store the new Assert Winner's address and metric. If the
metric was received in an Assert, the router MUST set the Assert
Timer (AT(S,G,I)) to Assert_Time. If the metric was received in
a State Refresh, the router MUST set the Assert Timer (AT(S,G,I))
to three times the State Refresh Interval. The router MUST also
受信、Preferred Assertか州Refresh An(S、G)が断言する、または、Assert州が機械加工するインタフェースI.のSが「私はAssert Loserです」状態に移行して、新しいAssert Winnerのアドレスとメートル法を格納しなければならないのでルータこののよりよくメートル法のaをメートル法にする受け取られた州Refresh。 Assertにメートル法を受け取ったなら、ルータはAssert Timer(AT(S、G、I))をAssert_Timeに設定しなければなりません。 州Refreshにメートル法を受け取ったなら、ルータはAssert Timer(AT(S、G、I))を州Refresh Intervalの3倍に設定しなければなりません。 また、ルータはそうしなければなりません。
Adams, et al. Experimental [Page 35] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[35ページ]RFC3973PIM--濃いモード2005年1月
multicast a Prune(S,G) to the Assert winner, with a Prune Hold
Time equal to the Assert Timer, and evaluate any changes in its
Upstream(S,G) state machine.
Assert勝者へのマルチキャストa Prune(S、G)、aで、Prune Hold TimeはUpstream(S、G)州のマシンにおけるどんな変化ともAssert Timerと等しく、評価します。
Send State Refresh
The router is sending a State Refresh(S,G) message on interface
I. The router MUST set the Assert Timer (AT(S,G,I)) to three
times the State Refresh Interval contained in the State
Refresh(S,G) message.
州Refresh(S、G)メッセージに含まれた州Refresh Intervalの3倍へのAssert Timer(AT(S、G、I))をルータがRefresh(S、G)がルータが設定しなければならないインタフェースI.で通信させる州を送る州Refreshに送ってください。
AT(S,G,I) Expires
The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state
machine MUST transition to the NoInfo (NI) state.
AT(S、G、I)が期限が切れる、(S、G)は、Timer(AT(S、G、I))が期限が切れると断言します。 Assert州のマシンはNoInfo(NI)状態への変遷がそうしなければなりません。
CouldAssert(S,G,I) -> FALSE
This router's RPF interface changed, making CouldAssert(S,G,I)
false. This router can no longer perform the actions of the
Assert winner, so the Assert state machine MUST transition to
NoInfo (NI) state, send an AssertCancel(S,G) to interface I,
cancel the Assert Timer (AT(S,G,I)), and remove itself as the
Assert Winner.
CouldAssert(S、G、I)を誤るようにして、CouldAssert(S、G、I)->FALSE ThisルータのRPFインタフェースは変化しました。 このルータがもうAssert勝者の動作を実行できないで、Assert州のマシンは、NoInfo(NI)状態に移行して、Assert Timer(AT(S、G、I))を取り消して、Iを連結するように、AssertCancel(S、G)を送るので、Assert Winnerとして立ち退かなければなりません。
4.6.4.3. Transitions from Loser State
4.6.4.3. 敗者状態からの変遷
When in "I am Assert Loser" state, the following transitions can occur:
以下の変遷が「私はAssert Loserです」状態に起こることができるなら:
Receive Inferior Assert or State Refresh from Current Winner
An Assert or State Refresh is received from the current Assert
winner that is worse than this router's metric for S (typically,
the winner's metric became worse). The Assert state machine MUST
transition to NoInfo (NI) state and cancel AT(S,G,I). The router
MUST delete the previous Assert Winner's address and metric and
evaluate any possible transitions to its Upstream(S,G) state
machine. Usually this router will eventually re-assert and win
when data packets from S have started flowing again.
Current Winner An AssertからInferior Assertか州Refreshを受けてください。さもないと、州Refreshによる現在のAssertから受け取って、(の通常勝者Sがメートル法であるのでこのルータがメートル法であるより悪い勝者がさらに悪くなったということである、) Assert州のマシンは、NoInfo(NI)状態に移行して、AT(S、G、I)を取り消さなければなりません。 ルータは、前のAssert Winnerのアドレスとメートル法を削除して、Upstream(S、G)州のマシンへのどんな可能な変遷も評価しなければなりません。 通常Sからのデータ・パケットが結局再び流れ始めたとき、ルータが再断言して、勝つこれ。
Receive Preferred Assert or State Refresh
An Assert or State Refresh is received that has a metric better
than or equal to that of the current Assert winner. The Assert
state machine remains in Loser (L) state. If the metric was
received in an Assert, the router MUST set the Assert Timer
(AT(S,G,I)) to Assert_Time. If the metric was received in a
State Refresh, the router MUST set the Assert Timer (AT(S,G,I))
to three times the received State Refresh Interval. If the
metric is better than the current Assert Winner, the router MUST
現在のAssert勝者のものと、より良いか、または等しい状態でaをメートル法にするPreferred Assert、州Refresh An Assertまたは受け取られた州Refreshを受けてください。 Assert州のマシンはLoser(L)州に残っています。 Assertにメートル法を受け取ったなら、ルータはAssert Timer(AT(S、G、I))をAssert_Timeに設定しなければなりません。 州Refreshにメートル法を受け取ったなら、ルータはAssert Timer(AT(S、G、I))を容認された州Refresh Intervalの3倍に設定しなければなりません。 メートル法が現在のAssert Winner、ルータがそうしなければならないより良いなら
Adams, et al. Experimental [Page 36] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[36ページ]RFC3973PIM--濃いモード2005年1月
store the address and metric of the new Assert Winner, and if
CouldAssert(S,G,I) == TRUE, the router MUST multicast a
Prune(S,G) to the new Assert winner.
新しいAssert Winnerにおけるアドレスとメートル法を格納してください。そうすれば、ルータはCouldAssert(S、G、I)=TRUEであるなら、新しいAssert勝者へのマルチキャストa Prune(S、G)をTRUEでなければなりません。
AT(S,G,I) Expires
The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state
machine MUST transition to NoInfo (NI) state. The router MUST
delete the Assert Winner's address and metric. If CouldAssert ==
TRUE, the router MUST evaluate any possible transitions to its
Upstream(S,G) state machine.
AT(S、G、I)が期限が切れる、(S、G)は、Timer(AT(S、G、I))が期限が切れると断言します。 Assert州のマシンはNoInfo(NI)状態への変遷がそうしなければなりません。 ルータはAssert Winnerのアドレスとメートル法を削除しなければなりません。 CouldAssert=TRUEであるなら、ルータはUpstream(S、G)州のマシンへのどんな可能な変遷も評価しなければなりません。
CouldAssert -> FALSE
CouldAssert has become FALSE because interface I has become the
RPF interface for S. The Assert state machine MUST transition to
NoInfo (NI) state, cancel AT(S,G,I), and delete information
concerning the Assert Winner on I.
インタフェースIがS.のためのRPFインタフェースになったので、CouldAssert->FALSE CouldAssertはFALSEになりました。Assert州のマシンは、NoInfo(NI)状態に移行して、AT(S、G、I)を取り消して、IでAssert Winnerに関して情報を削除しなければなりません。
CouldAssert -> TRUE
CouldAssert has become TRUE because interface I used to be the
RPF interface for S, and now it is not. The Assert state machine
MUST transition to NoInfo (NI) state, cancel AT(S,G,I), and
delete information concerning the Assert Winner on I.
私がS、および現在のそれのためのRPFインタフェースになるのに使用したインタフェースがなっていなかったので、CouldAssert->TRUE CouldAssertはTRUEになりました。 Assert州のマシンは、NoInfo(NI)状態に移行して、AT(S、G、I)を取り消して、IでAssert Winnerに関して情報を削除しなければなりません。
Current Assert Winner's NeighborLiveness Timer Expires
The current Assert winner's NeighborLiveness Timer (NLT(N,I)) has
expired. The Assert state machine MUST transition to the NoInfo
(NI) state, delete the Assert Winner's address and metric, and
evaluate any possible transitions to its Upstream(S,G) state
machine.
現在のAssert Winnerの現在の勝者のAssertもののNeighborLiveness Timer ExpiresのNeighborLiveness Timer(NLT(N、I))は期限が切れました。 Assert州のマシンは、NoInfo(NI)状態に移行して、Assert Winnerのアドレスとメートル法を削除して、Upstream(S、G)州のマシンへのどんな可能な変遷も評価しなければなりません。
Receive Prune(S,G), Join(S,G), or Graft(S,G)
A Prune(S,G), Join(S,G), or Graft(S,G) message was received on
interface I with its upstream neighbor address set to the
router's address on I. The router MUST send an Assert(S,G) on
the receiving interface I to initiate an Assert negotiation. The
Assert state machine remains in the Assert Loser(L) state. If a
Graft(S,G) was received, the router MUST respond with a
GraftAck(S,G).
Prune(S、G)を受けてください、Join(S、G)、または、上流の隣人アドレスセットとのインタフェースIにPrune(S、G)、Join(S、G)、またはGraft(S、G)が通信させるGraft(S、G)をI.に関するルータのアドレスに受け取りました。ルータは、Assert交渉を開始するために受信インタフェースのAssert(S、G)にIを送らなければなりません。 Assert州のマシンはAssert Loser(L)州に残っています。 Graft(S、G)を受け取ったなら、ルータはGraftAck(S、G)と共に応じなければなりません。
Adams, et al. Experimental [Page 37] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[37ページ]RFC3973PIM--濃いモード2005年1月
4.6.5. Rationale for Assert Rules
4.6.5. 原理、規則について断言してください。
The following is a summary of the rules for generating and processing Assert messages. It is not intended to be definitive (the state machines and pseudocode provide the definitive behavior). Instead, it provides some rationale for the behavior.
↓これはAssertメッセージを発生して、処理するための規則の概要です。 それが決定的であることを意図しません(州のマシンと擬似コードは決定的な振舞いを提供します)。 代わりに、それは何らかの原理を振舞いに提供します。
1. The Assert winner for (S,G) must act as the local forwarder for
(S,G) on behalf of all downstream members.
2. PIM messages are directed to the RPF' neighbor and not to the
regular RPF neighbor.
3. An Assert loser that receives a Prune(S,G), Join(S,G), or
Graft(S,G) directed to it initiates a new Assert negotiation so
that the downstream router can correct its RPF'(S).
4. An Assert winner for (S,G) sends a cancelling assert when it is
about to stop forwarding on an (S,G) entry. Example: If a router
is being taken down, then a canceling assert is sent.
1. (S、G)必須のためのAssert勝者は(S、G)のための地元の混載業者としてすべての川下のメンバーを代表して務めます。 2. 'PIMメッセージはレギュラーのRPF隣人ではなく、RPF'隣人に向けられます。 3. Prune(S、G)、Join(S、G)、またはそれに向けられたGraft(S、G)を受け取るAssert敗者は、川下のルータがRPF'(S)'を修正できるように、新しいAssert交渉を開始します。 4. (S、G)が取り消しを送るので、Assert勝者は、それがそうしようとしているとき、(S、G)エントリーに送るのを止めるように断言します。 例: ルータが降ろされていて、次に、送られるなら取り消しが、断言する。
4.7. PIM Packet Formats
4.7. PIMパケット・フォーマット
All PIM-DM packets use the same format as PIM-SM packets. In the event of a discrepancy, PIM-SM [4] should be considered the definitive specification. All PIM control messages have IP protocol number 103. All PIM-DM messages MUST be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to the sender of the Graft.
すべてのPIM-DMパケットがPIM-SMパケットと同じ形式を使用します。 食い違いの場合、PIM-SM[4]は決定的な仕様であると考えられるべきです。 すべてのPIMコントロールメッセージには、IPプロトコル番号103があります。 1のTTLと共にすべてのPIM-DMメッセージを送らなければなりません。 Graft以外のすべてのPIM-DMメッセージとGraft Ackメッセージを送らなければならない、すべて、-、PIM-ROUTERS、分類してください。 RPFへのユニキャストが'(S)'であったならメッセージSHOULDを接ぎ木してください。 汚職AckメッセージはGraftの送付者へのユニキャストであるに違いありません。
The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM- ROUTERS group is 'ff02::d'.
グループはそうです。IPv4、すべて、-、PIM-ROUTERS、224.0 .0 .13。 IPv6、すべて、-、PIM- ROUTERS、グループは'ff02です:、:、''d'。
4.7.1. PIM Header
4.7.1. PIMヘッダー
All PIM control messages have the following header:
すべてのPIMコントロールメッセージには、以下のヘッダーがあります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver PIM version number is 2.
PIM Ver PIMバージョン番号は2です。
Adams, et al. Experimental [Page 38] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[38ページ]RFC3973PIM--濃いモード2005年1月
Type
Types for specific PIM messages. Available types are as follows:
0 = Hello
1 = Register (PIM-SM only)
2 = Register Stop (PIM-SM only)
3 = Join/Prune
4 = Bootstrap (PIM-SM only)
5 = Assert
6 = Graft
7 = Graft Ack
8 = Candidate RP Advertisement (PIM-SM only)
9 = State Refresh
特定のPIMメッセージのためにTypesをタイプしてください。 手があいているタイプは以下の通りです: 0がこんにちは、(PIM-SM専用)3=が接合する1つの=レジスタ(PIM-SM専用)2=レジスタStopと等しい、/プルーン4の=は候補RP Advertisement(PIM-SM専用)9=州=が6=汚職7=汚職Ack8であると断言する5=Refreshを独力で進みます(PIM-SM専用)。
Reserved
Set to zero on transmission. Ignored upon receipt.
Setをトランスミッションのゼロまで予約しました。 領収書では、無視されます。
Checksum
The checksum is the standard IP checksum; i.e., the 16 bit one's
complement of the one's complement sum of the entire PIM message.
For computing checksum, the checksum field is zeroed.
チェックサム、チェックサムは標準のIPチェックサムです。 すなわち、16は全体のPIMメッセージの1の補数合計の1の補数に噛み付きました。 チェックサムを計算するのにおいて、チェックサム分野のゼロは合わせられています。
For IPv6, the checksum also includes the IPv6 "pseudo-header", as
specified in RFC 2460, Section 8.1 [5].
また、IPv6に関しては、チェックサムはRFC2460、セクション8.1[5]で指定されるようにIPv6「疑似ヘッダー」を含んでいます。
4.7.2. Encoded Unicast Address
4.7.2. コード化されたユニキャストアドレス
An Encoded Unicast Address has the following format:
Encoded Unicast Addressには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr家| タイプをコード化します。| ユニキャストアドレス++++++++++++++++++++++++++…
Addr Family
The PIM Address Family of the 'Unicast Address' field of this
address. Values 0 - 127 are as assigned by the IANA for Internet
Address Families in [9]. Values 128 - 250 are reserved to be
assigned by the IANA for PIM specific Address Families. Values 251
- 255 are designated for private use. As there is no assignment
authority for this space; collisions should be expected.
このアドレスの'ユニキャストAddress'分野のAddr Family PIM Address Family。 [9]のインターネットAddress FamiliesのためにIANAによって割り当てられるように値0--127があります。 PIMの特定のAddress FamiliesのためにIANAによって割り当てられるように、値128--250は予約されます。 値251--255は私的使用目的で指定されます。 このスペースへの課題権威が全くないので。 衝突は予想されるべきです。
Encoding Type
The type of encoding used with a specific Address Family. The
value '0' is reserved for this field and represents the native
encoding of the Address Family.
特定のAddress Familyと共に使用されるコード化のタイプのTypeをコード化します。 値'0'は、この分野に予約されて、Address Familyのネイティブのコード化を表します。
Adams, et al. Experimental [Page 39] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[39ページ]RFC3973PIM--濃いモード2005年1月
Unicast Address
The unicast address as represented by the given Address Family and
Encoding Type.
与えられたAddress FamilyとEncoding Typeによって表されるようにユニキャストが記述するユニキャストAddress。
4.7.3. Encoded Group Address
4.7.3. コード化されたグループアドレス
An Encoded Group address has the following format:
Encoded Groupアドレスには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr家| タイプをコード化します。|B| 予約されます。|Z| レンにマスクをかけてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストアドレス++++++++++++++++++++++++++を分類してください…
Addr Family
As described above.
上で説明されたAddr Family As。
Encoding Type
As described above.
上で説明されたType Asをコード化します。
B
Indicates that the group range should use Bidirectional PIM [16].
Transmitted as zero; ignored upon receipt.
Bは、グループ範囲がBidirectional PIM[16]を使用するべきであるのを示します。 ゼロとして、伝えられます。 領収書では、無視されます。
Reserved
Transmitted as zero. Ignored upon receipt.
ゼロとしての予約されたTransmitted。 領収書では、無視されます。
Z
Indicates that the group range is an admin scope zone. This is
used in the Bootstrap Router Mechanism [18] only. For all other
purposes, this bit is set to zero and ignored on receipt.
Zは、グループ範囲がアドミン範囲ゾーンであることを示します。 これはBootstrap Router Mechanismだけで使用されます。 他のすべての目的のために、このビットは、ゼロに設定されて、領収書の上で無視されます。
Mask Len
The mask length field is 8 bits. The value is the number of
contiguous left justified one bits used as a mask, which, combined
with the address, describes a range of addresses. It is less than
or equal to the address length in bits for the given Address Family
and Encoding Type. If the message is sent for a single address
then the mask length MUST equal the address length. PIM-DM routers
MUST only send for a single address.
レンにマスクをかけてください。マスク長さの分野は8ビットです。 値はマスクとして使用される左の隣接の正当な1ビットの数です。アドレスに結合されていた状態で、マスクはさまざまなアドレスについて説明します。 それは与えられたAddress FamilyとEncoding Typeのためのビットのアドレスの、より長さ以下です。 ただ一つのアドレスのためにメッセージを送るなら、マスクの長さはアドレスの長さと等しくなければなりません。 PIM-DMルータはただ一つのアドレスのために発信するだけでよいです。
Group Multicast Address
The address of the multicast group.
マルチキャストのアドレスが分類するMulticast Addressを分類してください。
Adams, et al. Experimental [Page 40] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[40ページ]RFC3973PIM--濃いモード2005年1月
4.7.4. Encoded Source Address
4.7.4. コード化されたソースアドレス
An Encoded Source address has the following format:
Encoded Sourceアドレスには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr家| タイプをコード化します。| Rsrvd|S|W|R| レンにマスクをかけてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス++++++++++++++++++++++++++…
Addr Family
As described above.
上で説明されたAddr Family As。
Encoding Type
As described above.
上で説明されたType Asをコード化します。
Rsrvd
Reserved. Transmitted as zero. Ignored upon receipt.
予約されたRsrvd。 ゼロとして、伝えられます。 領収書では、無視されます。
S
The Sparse Bit. Set to 0 for PIM-DM. Ignored upon receipt.
Sまばらなビット。 PIM-DMのために0にセットしてください。 領収書では、無視されます。
W
The Wild Card Bit. Set to 0 for PIM-DM. Ignored upon receipt.
Wワイルド・カードに噛み付きました。 PIM-DMのために0にセットしてください。 領収書では、無視されます。
R
The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon
receipt.
R Rendezvous Point Treeは噛み付きました。 PIM-DMのために0にセットしてください。 領収書では、無視されます。
Mask Len
As described above. PIM-DM routers MUST only send for a single
source address.
上で説明されたレンAsにマスクをかけてください。 PIM-DMルータはただ一つのソースアドレスのために発信するだけでよいです。
Source Address
The source address.
ソースのAddressが演説するソース。
Adams, et al. Experimental [Page 41] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[41ページ]RFC3973PIM--濃いモード2005年1月
4.7.5. Hello Message Format
4.7.5. こんにちは、メッセージ・フォーマット
The PIM Hello message, as defined by PIM-SM [4], has the following format:
PIM-SM[4]によって定義されるPIM Helloメッセージは以下の形式を持っています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション価値| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション価値| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum
Described above.
PIM Ver、Type、Reserved、上のChecksum Described。
Option Type
The type of option given in the Option Value field. Available
types are as follows:
Option Value分野で与えられたオプションのタイプをTypeにゆだねてください。 手があいているタイプは以下の通りです:
0 Reserved
1 Hello Hold Time
2 LAN Prune Delay
3 - 16 Reserved
17 To be assigned by IANA
18 Deprecated and SHOULD NOT be used
19 DR Priority (PIM-SM Only)
20 Generation ID
21 State Refresh Capable
22 Bidir Capable
23 - 65000 To be assigned by IANA
65001 - 65535 Reserved for Private Use [9]
0は1Hello Hold Time2のLAN Prune Delay3--16Reserved17Toを予約しました。中古の19DR Priority(PIM-SM Only)20Generation ID21州Refresh Capable22がBidir Capable23であったならIANA18DeprecatedとSHOULD NOTによって割り当てられてください--、65000To、IANA65001によって割り当てられてください--、兵士のUseのための65535Reserved[9]
Unknown options SHOULD be ignored.
未知はSHOULDにゆだねます。無視されます。
Adams, et al. Experimental [Page 42] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[42ページ]RFC3973PIM--濃いモード2005年1月
4.7.5.1. Hello Hold Time Option
4.7.5.1. こんにちは、保持時間オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =1をタイプしてください。| 長さ=2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hold Time is the number of seconds a receiver MUST keep the neighbor reachable. If the Hold Time is set to '0xffff', the receiver of this message never times out the neighbor. This may be used with dial- on-demand links to avoid keeping the link up with periodic Hello messages. Furthermore, if the Holdtime is set to '0', the information is timed out immediately. The Hello Hold Time option MUST be used by PIM-DM routers.
保持Timeは受信機がそうしなければならない秒の数が隣人を届くように保つということです。 Hold Timeがそうなら、隣人から'0xffff'、このメッセージの受信機に決して少しの回も設定しないでください。 これは、周期的なHelloメッセージでリンクを維持するのを避けるのにダイヤルの要求次第のリンクと共に使用されるかもしれません。 その上、Holdtimeが'0'に用意ができているなら、情報はすぐに、外で調節されています。 PIM-DMルータでHello Hold Timeオプションを使用しなければなりません。
4.7.5.2. LAN Prune Delay Option
4.7.5.2. LANプルーンの遅れオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| LAN Prune Delay | Override Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =2をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| LANプルーンの遅れ| オーバーライド間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAN_Prune_Delay option is used to tune the prune propagation delay on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0 by PIM-DM routers and ignored upon receipt. The LAN Delay and Override Interval fields are time intervals in units of milliseconds and are used to tune the value of the J/P Override Interval and its derived timer values. Section 4.3.5 describes how these values affect the behavior of a router. The LAN Prune Delay SHOULD be used by PIM-DM routers.
LAN_Prune_Delayオプションは、マルチアクセスLANでプルーンの伝播遅延を調整するのに使用されます。 Tビットは、PIM-DMによる0へのセットがルータであったならPIM-SMとSHOULDによって使用されて、領収書で無視されます。 LAN DelayとOverride Interval分野は、ユニットのミリセカンドで表現される時間間隔であり、J/P Override Intervalの値とその派生しているタイマ値を調整するのに使用されます。 セクション4.3 .5 これらの値がどうルータの振舞いに影響するかを説明します。 LAN Prune Delay SHOULD、PIM-DMルータで、使用されてください。
Adams, et al. Experimental [Page 43] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[43ページ]RFC3973PIM--濃いモード2005年1月
4.7.5.3. Generation ID Option
4.7.5.3. 世代IDオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 20 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 世代ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generation ID is a random value for the interface on which the Hello message is sent. The Generation ID is regenerated whenever PIM forwarding is started or restarted on the interface. The Generation ID option MAY be used by PIM-DM routers.
世代IDはHelloメッセージが送られるインタフェースへの無作為の値です。 PIM推進がインタフェースで始められるか、または再開されるときはいつも、Generation IDは作り直されます。 Generation IDオプションはPIM-DMルータによって使用されるかもしれません。
4.7.5.4. State Refresh Capable Option
4.7.5.4. できるオプションをリフレッシュするように述べてください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 21 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 | Interval | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =21をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン=1| 間隔| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Interval field is the router's configured State Refresh Interval in seconds. The Reserved field is set to zero and ignored upon receipt. The State Refresh Capable option MUST be used by State Refresh capable PIM-DM routers.
Interval分野は秒のルータの構成された州Refresh Intervalです。 Reserved分野は、ゼロに設定されて、領収書で無視されます。 州のRefreshのできるPIM-DMルータで州Refresh Capableオプションを使用しなければなりません。
Adams, et al. Experimental [Page 44] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[44ページ]RFC3973PIM--濃いモード2005年1月
4.7.6. Join/Prune Message Format
4.7.6. メッセージ・フォーマットを接合するか、または剪定してください。
PIM Join/Prune messages, as defined in PIM-SM [4], have the following format:
PIM-SM[4]で定義されるPIM Join/プルーンのメッセージは以下の形式を持っています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Neighbor Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num Groups | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 上流の隣人アドレス(ユニキャスト形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| ヌムグループ| 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address 1 (Encoded Group Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address m (Encoded Group Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストグループアドレス1(グループ形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースの数| 剪定されたソースの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースアドレス1(ソース形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合Source Address n(Source Formatをコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 剪定されたソースアドレス1(ソース形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 剪定されたSource Address n(Source Formatをコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストグループアドレスm(グループ形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースの数| 剪定されたソースの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合ソースアドレス1(ソース形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adams, et al. Experimental [Page 45] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[45ページ]RFC3973PIM--濃いモード2005年1月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接合Source Address n(Source Formatをコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 剪定されたソースアドレス1(ソース形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 剪定されたSource Address n(Source Formatをコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum
Described above.
PIM Ver、Type、Reserved、上のChecksum Described。
Upstream Neighbor Address
The address of the upstream neighbor. The format for this address
is given in the Encoded Unicast address in Section 4.7.2. PIM-DM
routers MUST set this field to the RPF next hop.
上流のアドレスが近所付き合いさせる上流のNeighbor Address。 セクション4.7.2におけるEncoded Unicastアドレスでこのアドレスのための書式を与えます。 PIM-DMルータはRPF次ホップにこの分野を設定しなければなりません。
Reserved
Transmitted as zero. Ignored upon receipt.
ゼロとしての予約されたTransmitted。 領収書では、無視されます。
Hold Time
The number of seconds a receiving PIM-DM router MUST keep a Prune
state alive, unless removed by a Join or Graft message. If the
Hold Time is '0xffff', the receiver MUST NOT remove the Prune state
unless a corresponding Join or Graft message is received. The Hold
Time is ignored in Join messages.
Timeは受信PIM-DMルータが継続しているPrune状態であることを保たなければならない秒数を保持してください、JoinかGraftメッセージによって取り除かれない場合。 Hold Timeが'0xffff'であり、対応するJoinかGraftメッセージが受信されていない場合、受信機はPrune状態を取り除いてはいけません。 Hold TimeはJoinメッセージで無視されます。
Number of Groups
Number of multicast group sets contained in the message.
マルチキャストのGroups Numberの数はメッセージに含まれたセットを分類します。
Multicast Group Address
The multicast group address in the Encoded Multicast address format
given in Section 4.7.3.
マルチキャストグループがセクション4.7.3で与えられたEncoded Multicastアドレス形式で扱うマルチキャストGroup Address。
Number of Joined Sources
Number of Join source addresses listed for a given group.
JoinソースアドレスのJoined Sources Numberの数は与えられたグループのために記載しました。
Number of Pruned Sources
Number of Prune source addresses listed for a given group.
PruneソースアドレスのPruned Sources Numberの数は与えられたグループのために記載しました。
Adams, et al. Experimental [Page 46] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[46ページ]RFC3973PIM--濃いモード2005年1月
Join Source Address 1..n
This list contains the sources from which the sending router wishes
to continue to receive multicast messages for the given group on
this interface. The addresses use the Encoded Source address
format given in Section 4.7.4.
ソースアドレス1を接合してください。n Thisリストは付与へのマルチキャストメッセージを受け取り続けているという送付ルータ願望がこのインタフェースで分類されるソースを含んでいます。 アドレスはセクション4.7.4で与えられたEncoded Sourceアドレス形式を使用します。
Prune Source Address 1..n
This list contains the sources from which the sending router does
not wish to receive multicast messages for the given group on this
interface. The addresses use the Encoded Source address format
given in Section 4.7.4.
ソースアドレス1を剪定してください。n Thisリストは送付ルータがこのインタフェースに関する与えられたグループへのマルチキャストメッセージを受け取りたがっていないソースを含んでいます。 アドレスはセクション4.7.4で与えられたEncoded Sourceアドレス形式を使用します。
4.7.7. Assert Message Format
4.7.7. メッセージ・フォーマットについて断言してください。
PIM Assert Messages, as defined in PIM-SM [4], have the following format:
PIM-SM[4]で定義されるPIM Assert Messagesは以下の形式を持っています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address (Encoded Group Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストグループアドレス(グループ形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス(ユニキャスト形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| メートル法の好み| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum
Described above.
PIM Ver、Type、Reserved、上のChecksum Described。
Multicast Group Address
The multicast group address in the Encoded Multicast address format
given in Section 4.7.3.
マルチキャストグループがセクション4.7.3で与えられたEncoded Multicastアドレス形式で扱うマルチキャストGroup Address。
Source Address
The source address in the Encoded Unicast address format given in
Section 4.7.2.
ソースのAddressがセクション4.7.2で与えられたEncoded Unicastアドレス形式で演説するソース。
R
The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon
receipt.
R Rendezvous Point Treeは噛み付きました。 PIM-DMのために0にセットしてください。 領収書では、無視されます。
Adams, et al. Experimental [Page 47] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[47ページ]RFC3973PIM--濃いモード2005年1月
Metric Preference
The preference value assigned to the unicast routing protocol that
provided the route to the source.
好みの値がルートをソースに提供したユニキャストルーティング・プロトコルに割り当てたメートル法のPreference。
Metric
The cost metric of the unicast route to the source. The metric is
in units applicable to the unicast routing protocol used.
メートル法、ソースにおける、ユニキャストルートにおけるメートル法の費用。 メートル法がルーティング・プロトコルが使用したユニキャストに適切なユニットにあります。
4.7.8. Graft Message Format
4.7.8. 汚職メッセージ・フォーマット
PIM Graft messages use the same format as Join/Prune messages, except that the Type field is set to 6. The source address MUST be in the Join section of the message. The Hold Time field SHOULD be zero and SHOULD be ignored when a Graft is received.
Type分野が6に設定されるのを除いて、PIM GraftメッセージはJoin/プルーンのメッセージと同じ形式を使用します。 ソースアドレスがメッセージのJoin部にあるに違いありません。 ゼロとSHOULDになってください。Hold TimeがSHOULDをさばく、Graftが受け取られているとき、無視されます。
4.7.9. Graft Ack Message Format
4.7.9. 汚職Ackメッセージ・フォーマット
PIM Graft Ack messages are identical in format to the received Graft message, except that the Type field is set to 7. The Upstream Neighbor Address field SHOULD be set to the sender of the Graft message and SHOULD be ignored upon receipt.
PIM Graft Ackメッセージは形式が受信されたGraftメッセージと同じです、Type分野が7に設定されるのを除いて。 Upstream Neighbor AddressはGraftの送付者へのセットがメッセージとSHOULDであったならSHOULDをさばきます。領収書では、無視されます。
4.7.10. State Refresh Message Format
4.7.10. メッセージ・フォーマットをリフレッシュするように述べてください。
PIM State Refresh Messages have the following format:
PIM州Refresh Messagesには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address (Encoded Group Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Masklen | TTL |P|N|O|Reserved | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストグループアドレス(グループ形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス(ユニキャスト形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者アドレス(ユニキャスト形式をコード化します)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| メートル法の好み| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Masklen| TTL|P|N|O|予約されます。| 間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum
Described above.
PIM Ver、Type、Reserved、上のChecksum Described。
Adams, et al. Experimental [Page 48] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[48ページ]RFC3973PIM--濃いモード2005年1月
Multicast Group Address
The multicast group address in the Encoded Multicast address format
given in Section 4.7.3.
マルチキャストグループがセクション4.7.3で与えられたEncoded Multicastアドレス形式で扱うマルチキャストGroup Address。
Source Address
The address of the data source in the Encoded Unicast address
format given in Section 4.7.2.
ソースAddressはセクション4.7で.2に与えられたEncoded Unicastアドレス形式のデータ送信端末のアドレスです。
Originator Address
The address of the first hop router in the Encoded Unicast address
format given in Section 4.7.2.
創始者Addressはセクション4.7で.2に与えられたEncoded Unicastアドレス形式における最初のホップルータのアドレスです。
R
The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon
receipt.
R Rendezvous Point Treeは噛み付きました。 PIM-DMのために0にセットしてください。 領収書では、無視されます。
Metric Preference
The preference value assigned to the unicast routing protocol that
provided the route to the source.
好みの値がルートをソースに提供したユニキャストルーティング・プロトコルに割り当てたメートル法のPreference。
Metric
The cost metric of the unicast route to the source. The metric is
in units applicable to the unicast routing protocol used.
メートル法、ソースにおける、ユニキャストルートにおけるメートル法の費用。 メートル法がルーティング・プロトコルが使用したユニキャストに適切なユニットにあります。
Masklen
The length of the address mask of the unicast route to the source.
ソースへのユニキャストルートのアドレスマスクの長さのMasklen。
TTL
Time To Live of the State Refresh message. Decremented each time
the message is forwarded. Note that this is different from the IP
Header TTL, which is always set to 1.
州RefreshメッセージのTTL Time To Live。 その都度減少して、メッセージを転送します。 これがIP Header TTLと異なっていることに注意してください。(Header TTLはいつも1に用意ができています)。
P
Prune indicator flag. This MUST be set to 1 if the State Refresh
is to be sent on a Pruned interface. Otherwise, it MUST be set to
0.
Pプルーンのインディケータ旗。 Prunedインタフェースで州Refreshを送るつもりであるなら、1にこれを設定しなければなりません。 さもなければ、0にそれを設定しなければなりません。
N
Prune Now flag. This SHOULD be set to 1 by the State Refresh
originator on every third State Refresh message and SHOULD be
ignored upon receipt. This is for compatibility with earlier
versions of state refresh.
Nは現在、旗から余計なものを取り除きます。 このSHOULD、州による1へのセットがあらゆる3番目の州RefreshメッセージとSHOULDの上のRefresh創始者であったなら、領収書で無視されてください。 これは状態の以前のバージョンとの互換性がリフレッシュするからです。
O
Assert Override flag. This SHOULD be set to 1 by upstream routers
on a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be
ignored upon receipt. This is for compatibility with earlier
versions of state refresh.
○ Overrideが弛むと断言してください。 このSHOULD、LANに関する上流のルータによる1へのセットがAssert Timer(AT(S、G))が稼働する予定でないか、そして、SHOULDであったなら、領収書で無視されてください。 これは状態の以前のバージョンとの互換性がリフレッシュするからです。
Adams, et al. Experimental [Page 49] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[49ページ]RFC3973PIM--濃いモード2005年1月
Reserved
Set to zero and ignored upon receipt.
Setをゼロまで予約して、領収書で無視されます。
Interval
Set by the originating router to the interval (in seconds) between
consecutive State Refresh messages for this (S,G) pair.
これ(S、G)への連続した州Refreshメッセージの間隔(秒の)までの起因するルータによる間隔Setは対にします。
4.8. PIM-DM Timers
4.8. PIM-DMタイマ
PIM-DM maintains the following timers. All timers are countdown timers -- they are set to a value and count down to zero, at which point they typically trigger an action. Of course they can just as easily be implemented as count-up timers, where the absolute expiry time is stored and compared against a real-time clock, but the language in this specification assumes that they count downward towards zero.
PIM-DMは以下のタイマを維持します。 すべてのタイマがカウントダウンタイマです--値とカウントダウンにそれらが通常どのポイントの引き金となるかで動作のゼロに合うように設定されます。 もちろん、カウント上がっているタイマとしてただ同じくらい容易にそれらを実装することができます。絶対満期時間は、リアルタイム時計に対して保存されて、比較されますが、そこでは、この仕様による言語は、彼らが下向きにゼロに向かって数えると仮定します。
Global Timers
Hello Timer: HT
グローバルなタイマ、こんにちは、タイマ: HT
Per interface (I):
Per neighbor (N):
Neighbor Liveness Timer: NLT(N,I)
インタフェース(I)単位で: 隣人(N)単位で: 隣人活性タイマ: NLT(N、I)
Per (S,G) Pair:
(S,G) Assert Timer: AT(S,G,I)
(S,G) Prune Timer: PT(S,G,I)
(S,G) PrunePending Timer: PPT(S,G,I)
1(S、G)組単位で: (S、G) タイマについて断言してください: (S、G、I)(S、G)プルーンのタイマで: PT(S、G、I)(S、G)PrunePendingタイマ: PPT(S、G、I)
Per (S,G) Pair:
(S,G) Graft Retry Timer: GRT(S,G)
(S,G) Upstream Override Timer: OT(S,G)
(S,G) Prune Limit Timer: PLT(S,G)
(S,G) Source Active Timer: SAT(S,G)
(S,G) State Refresh Timer: SRT(S,G)
1(S、G)組単位で: (S、G) 再試行タイマを接ぎ木してください: GRT(S、G)(S、G)の上流のオーバーライドタイマ: OT(S、G)(S、G)は限界タイマから余計なものを取り除きます: PLT(S、G)(S、G)のソースのアクティブなタイマ: 土曜日に、(S、G)(S、G)は、タイマをリフレッシュするように述べます: SRT(S、G)
Adams, et al. Experimental [Page 50] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[50ページ]RFC3973PIM--濃いモード2005年1月
When timer values are started or restarted, they are set to default values. The following tables summarize those default values.
タイマ値が開始するか、または再開されるとき、それらはデフォルト値に設定されます。 以下のテーブルはそれらのデフォルト値をまとめます。
Timer Name: Hello Timer (HT) +----------------------+--------+--------------------------------------+ | Value Name | Value | Explanation | +----------------------+--------+--------------------------------------+ |Hello_Period | 30 sec | Periodic interval for hello messages | +----------------------+--------+--------------------------------------+ |Triggered_Hello_Delay | 5 sec | Random interval for initial Hello | | | | message on bootup or triggered Hello | | | | message to a rebooting neighbor | +----------------------+--------+--------------------------------------+
タイマ名: こんにちは、タイマ(HT)+----------------------+--------+--------------------------------------+ | 値の名| 値| 説明| +----------------------+--------+--------------------------------------+ |こんにちは、_の期間| 30秒| 周期的な間隔、こんにちは、メッセージ| +----------------------+--------+--------------------------------------+ |_の引き金となる、こんにちは、_延着してください。| 5秒| 初期のHelloのための無作為の間隔| | | | bootupか引き起こされたHelloに関するメッセージ| | | | リブートしている隣人へのメッセージ| +----------------------+--------+--------------------------------------+
Hello messages are sent on every active interface once every Hello_Period seconds. At system power-up, the timer is initialized to rand(0,Triggered_Hello_Delay) to prevent synchronization. When a new or rebooting neighbor is detected, a responding Hello is sent within rand(0,Triggered_Hello_Delay).
こんにちは、メッセージはそうです。かつてのあらゆるHello_Periodが後援するあらゆるアクティブなインタフェースを転送しました。 システムパワーアップすることでは、タイマは、同期を防ぐために底ならし革(0、Triggered_Hello_Delay)に初期化されます。 新しいかリブートしている隣人を検出するとき、底ならし革(0、Triggered_Hello_Delay)の中に応じるHelloを送ります。
Timer Name: Neighbor Liveness Timer (NLT(N,I)) +-------------------+-----------------+--------------------------------+ | Value Name | Value | Explanation | +-------------------+-----------------+--------------------------------+ | Hello Holdtime | From message | Hold Time from Hello Message | +-------------------+-----------------+--------------------------------+
タイマ名: 隣人活性タイマ(NLT(N、I))+-------------------+-----------------+--------------------------------+ | 値の名| 値| 説明| +-------------------+-----------------+--------------------------------+ | こんにちは、Holdtime| メッセージから| 保持時間、こんにちは、メッセージ| +-------------------+-----------------+--------------------------------+
Timer Name: PrunePending Timer (PPT(S,G,I)) +-----------------------+---------------+------------------------------+ | Value Name | Value | Explanation | +-----------------------+---------------+------------------------------+ | J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to | | | | allow other routers on the | | | | LAN to send a Join | +-----------------------+---------------+------------------------------+
タイマ名: PrunePendingタイマ(PPT(S、G、I))+-----------------------+---------------+------------------------------+ | 値の名| 値| 説明| +-----------------------+---------------+------------------------------+ | J/P_オーバーライド_間隔| OI(I)+PD(I)| Pruneの後の時にショートします。| | | | 他のルータを許容します。| | | | Joinを送るLAN| +-----------------------+---------------+------------------------------+
The J/P_Override_Interval is the sum of the interface's Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all routers on a LAN are using the LAN Prune Delay option, both parameters MUST be set to the largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST be set to 2.5 seconds, and the Propagation_Delay (PD(I)) MUST be set to 0.5 seconds.
J/P_Override_IntervalがインタフェースのOverride_Intervalの合計である、(OI(I))とPropagation_Delay、(PD(I))。 LANに関するすべてのルータがLAN Prune Delayオプションを使用しているなら、LANで最も大きい値に両方のパラメタを設定しなければなりません。 そうでなければ、Override_Interval、(OI(I)) MUST、2.5秒、およびPropagation_Delayに設定されてください、(PD(I)) MUST、0.5秒に設定されてください。
Adams, et al. Experimental [Page 51] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[51ページ]RFC3973PIM--濃いモード2005年1月
Timer Name: Prune Timer (PT(S,G,I)) +----------------+----------------+------------------------------------+ | Value Name | Value | Explanation | +----------------+----------------+------------------------------------+ | Prune Holdtime | From message | Hold Time read from Prune Message | +----------------+----------------+------------------------------------+
タイマ名: プルーンのタイマ(太平洋標準時(S、G、I)の)+----------------+----------------+------------------------------------+ | 値の名| 値| 説明| +----------------+----------------+------------------------------------+ | プルーンのHoldtime| メッセージから| TimeがPrune Messageから読まれるままにしてください。| +----------------+----------------+------------------------------------+
Timer Name: Assert Timer (AT(S,G,I)) +--------------------------+---------+---------------------------------+ | Value Name | Value | Explanation | +--------------------------+---------+---------------------------------+ | Assert Time | 180 sec | Period after last assert before | | | | assert state is timed out | +--------------------------+---------+---------------------------------+
タイマ名: タイマ((S、G、I)の)が+であると断言してください。--------------------------+---------+---------------------------------+ | 値の名| 値| 説明| +--------------------------+---------+---------------------------------+ | 時間について断言してください。| 180秒| 後最終が以前断言する期間| | | | 状態が外で調節されていると断言してください。| +--------------------------+---------+---------------------------------+
Note that, for historical reasons, the Assert message lacks a Holdtime field. Thus, changing the Assert Time from the default value is not recommended. If all members of a LAN are state refresh enabled, the Assert Time will be three times the received RefreshInterval(S,G).
Assertメッセージが歴史的な理由でHoldtime分野を欠いていることに注意してください。 したがって、デフォルト値からAssert Timeを変えるのは推薦されません。 LANのすべてのメンバーが状態であるなら、可能にされた状態でリフレッシュしてください、そして、Assert Timeは容認されたRefreshInterval(S、G)の3倍になるでしょう。
Timer Name: Graft Retry Timer (GRT(S,G)) +--------------------+-------+-----------------------------------------+ | Value Name | Value | Explanation | +--------------------+-------+-----------------------------------------+ | Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck | | | | message, the time before retransmission | | | | of a Graft message | +--------------------+-------+-----------------------------------------+
タイマ名: 汚職再試行タイマ(GRT(S、G))+--------------------+-------+-----------------------------------------+ | 値の名| 値| 説明| +--------------------+-------+-----------------------------------------+ | 汚職_再試行_の期間| 3秒| GraftAckの領収書がないとき| | | | メッセージ、「再-トランスミッション」の前の時間| | | | Graftメッセージについて| +--------------------+-------+-----------------------------------------+
Timer Name: Upstream Override Timer (OT(S,G)) +------------+----------------+----------------------------------------+ | Value Name | Value | Explanation | +------------+----------------+----------------------------------------| | t_override | rand(0, OI(I)) | Randomized delay to prevent response | | | | implosion when sending a join message | | | | to override someone else's prune | +------------+----------------+----------------------------------------+
タイマ名: 上流のオーバーライドタイマ(OT(S、G))+------------+----------------+----------------------------------------+ | 値の名| 値| 説明| +------------+----------------+----------------------------------------| | t_オーバーライド| 底ならし革、(0、OI(I))| 応答を防ぐランダマイズされた遅れ| | | | aを送るとき、内部破裂はメッセージを接合します。| | | | 他の誰かのプルーンをくつがえすために| +------------+----------------+----------------------------------------+
t_override is a random value between 0 and the interface's Override_Interval (OI(I)). If all routers on a LAN are using the LAN Prune Delay option, the Override_Interval (OI(I)) MUST be set to the largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST be set to 2.5 seconds.
t_オーバーライドは0とインタフェースのOverride_Intervalの間の無作為の値です。(OI(I))。 LANに関するルータはすべてならLAN Prune Delayオプションを使用しています、Override_Interval、(OI(I)) MUST、LANで最も大きい値に設定されてください。 そうでなければ、Override_Interval、(OI(I)) MUST、2.5秒に設定されてください。
Adams, et al. Experimental [Page 52] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[52ページ]RFC3973PIM--濃いモード2005年1月
Timer Name: Prune Limit Timer (PLT(S,G)) +------------+--------------------+------------------------------------+ | Value Name | Value | Explanation | +------------+--------------------+------------------------------------| | t_limit | Default: 210 secs | Used to prevent Prune storms on a | | | | LAN | +------------+--------------------+------------------------------------+
タイマ名: プルーンの限界タイマ(PLT(S、G))+------------+--------------------+------------------------------------+ | 値の名| 値| 説明| +------------+--------------------+------------------------------------| | t_限界| デフォルト: 210 secs| aでPrune嵐を防ぐために、使用されます。| | | | LAN| +------------+--------------------+------------------------------------+
Timer Name: Source Active Timer (SAT(S,G)) +----------------+-------------------+---------------------------------+ | Value Name | Value | Explanation | +----------------+-------------------+---------------------------------+ | SourceLifetime | Default: 210 secs | Period of time after receiving | | | | a multicast message a directly | | | | attached router will continue | | | | to send State Refresh messages | +----------------+-------------------+---------------------------------+
タイマ名: ソースのアクティブなタイマ(土曜日(S、G))+----------------+-------------------+---------------------------------+ | 値の名| 値| 説明| +----------------+-------------------+---------------------------------+ | SourceLifetime| デフォルト: 210 secs| 受信した後の期間| | | | マルチキャストはaを直接通信させます。| | | | 付属ルータは続くでしょう。| | | | 州Refreshメッセージを送るために| +----------------+-------------------+---------------------------------+
Timer Name: State Refresh Timer (SRT(S,G)) +-----------------+------------------+---------------------------------+ | Value Name | Value | Explanation | +-----------------+------------------+---------------------------------+ | RefreshInterval | Default: 60 secs | Interval between successive | | | | state refresh messages | +-----------------+------------------+---------------------------------+
タイマ名: タイマ(SRT(S、G))+をリフレッシュするように述べてください。-----------------+------------------+---------------------------------+ | 値の名| 値| 説明| +-----------------+------------------+---------------------------------+ | RefreshInterval| デフォルト: 60 secs| 連続するところの間隔| | | | メッセージをリフレッシュするように述べてください。| +-----------------+------------------+---------------------------------+
5. Protocol Interaction Considerations
5. プロトコル相互作用問題
PIM-DM is designed to be independent of underlying unicast routing protocols and will interact only to the extent needed to perform RPF checks. It is generally assumed that multicast area and autonomous system boundaries will correspond to the same boundaries for unicast routing, though a deployment that does not follow this assumption is not precluded by this specification.
PIM-DMは基本的なユニキャストルーティング・プロトコルから独立しているように設計されていて、RPFチェックを実行するのに必要である範囲だけに相互作用するでしょう。 一般に、マルチキャスト領域と自律システム境界がユニキャストルーティングのための同じ境界に対応すると思われます、この仮定に続かない展開はこの仕様によって排除されませんが。
In general, PIM-DM interactions with other multicast routing protocols should be in compliance with RFC 2715 [7]. Other specific interactions are noted below.
一般に、他のマルチキャストルーティング・プロトコルとのPIM-DM相互作用がRFC2715[7]に従ってあるべきです。 他の特定の相互作用は以下に述べられます。
5.1. PIM-SM Interactions
5.1. PIM-Sm相互作用
PIM-DM is not intended to interact directly with PIM-SM, even though they share a common packet format. It is particularly important to note that a router cannot differentiate between a PIM-DM neighbor and a PIM-SM neighbor based on Hello messages.
彼らは一般的なパケット・フォーマットを共有しますが、PIM-DMが直接PIM-SMと対話することを意図しません。 ルータがHelloメッセージに基づくPIM-DM隣人とPIM-SM隣人を区別できないことに注意するのは特に重要です。
Adams, et al. Experimental [Page 53] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[53ページ]RFC3973PIM--濃いモード2005年1月
In the event that a PIM-DM router becomes a neighbor of a PIM-SM router, the two will effectively form a simplex link, with the PIM-DM router sending all multicast messages to the PIM-SM router while the PIM-SM router sends no multicast messages to the PIM-DM router.
PIM-DMルータがPIM-SMルータの隣人になると、事実上、2はシンプレクスリンクを形成するでしょう、PIM-SMルータがマルチキャストメッセージを全くPIM-DMルータに送らない間、PIM-DMルータがすべてのマルチキャストメッセージをPIM-SMルータに送って。
The common packet format permits a hybrid PIM-SM/DM implementation that would use PIM-SM when a rendezvous point is known and PIM-DM when one is not. Such an implementation is outside the scope of this document.
1つが可能にしないとき、一般的なパケット・フォーマットはランデブーポイントが知られているとPIM-SMを使用するハイブリッドPIM-SM/DM実装とPIM-DMを可能にします。 このドキュメントの範囲の外にそのような実装はあります。
5.2. IGMP Interactions
5.2. IGMP相互作用
PIM-DM will forward received multicast data packets to neighboring host group members in all cases except when the PIM-DM router is in an Assert Loser state on that interface. Note that a PIM Prune message is not permitted to prevent the delivery of messages to a network with group members.
PIM-DMはそのインタフェースでPIM-DMルータがAssert Loser状態にある時以外のすべての場合における隣接しているホストグループのメンバーに容認されたマルチキャストデータ・パケットを送るでしょう。 PIM Pruneメッセージがグループのメンバーと共にメッセージの配送をネットワークに防ぐことが許可されていないことに注意してください。
A PIM-DM Router MAY use the DR Priority option described in PIM-SM [14] to elect an IGMP v1 querier.
PIM-DM RouterはIGMP v1 querierを選出するためにPIM-SM[14]で説明されたDR Priorityオプションを使用するかもしれません。
5.3. Source Specific Multicast (SSM) Interactions
5.3. ソースの特定のマルチキャスト(SSM)相互作用
PIM-DM makes no special considerations for SSM [15]. All Prunes and Grafts within the protocol are for a specific source, so no additional checks have to be made.
PIM-DMはどんなSSMに、特別な問題も[15]にしません。 特定のソースにはプロトコルの中のすべてのPrunesとGraftsがあるので、どんな追加チェックもしてはいけません。
5.4. Multicast Group Scope Boundary Interactions
5.4. マルチキャストグループ範囲境界相互作用
Although multicast group scope boundaries are generally identical to routing area boundaries, it is conceivable that a routing area might be partitioned for a particular multicast group. PIM-DM routers MUST NOT send any messages concerning a particular group across that group's scope boundary.
マルチキャストグループ範囲の限界は一般にルーティングエリアの境界と同じですが、ルーティング領域が特定のマルチキャストグループのために仕切られるのが想像できます。 PIM-DMルータは特定のグループに関してそのグループの範囲境界の向こう側にどんなメッセージも送ってはいけません。
6. IANA Considerations
6. IANA問題
6.1. PIM Address Family
6.1. PIMアドレスファミリー
The PIM Address Family field was chosen to be 8 bits as a tradeoff between packet format and use of the IANA assigned numbers. When the PIM packet format was designed, only 15 values were assigned for Address Families, and large numbers of new Address Families were not envisioned; 8 bits seemed large enough. However, the IANA assigns Address Families in a 16 bit value. Therefore, the PIM Address Family is allocated as follows:
IANAのパケット・フォーマットと使用の間の見返りが数を割り当てたとき、PIM Address Family分野は、8ビットになるように選ばれました。 PIMパケット・フォーマットが設計されたとき、15の値だけがAddress Familiesのために割り当てられました、そして、多くの新しいAddress Familiesは思い描かれませんでした。 8ビットは十分大きく見えました。 しかしながら、IANAは16ビットの値でAddress Familiesを割り当てます。 したがって、以下の通りPIM Address Familyを割り当てます:
Adams, et al. Experimental [Page 54] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[54ページ]RFC3973PIM--濃いモード2005年1月
Values 0 - 127 are designated to have the same meaning as IANA assigned Address Family Numbers [9].
値0--127は、Address Family民数記[9]が割り当てられたIANAと同じ意味を持つために指定されます。
Values 128 - 250 are designated to be assigned by the IANA based on IESG approval, as defined in [8].
[8]で定義されるようにIESG承認に基づくIANAによって割り当てられるように、値128--250は指定されます。
Values 251 - 255 are designated for Private Use, as defined in [8].
値251--255は兵士のUseのために[8]で定義されるように指定されます。
6.2. PIM Hello Options
6.2. PIM、こんにちは、オプション
Values 17 - 65000 are to be assigned by the IANA. Since the space is large, they may be assigned as First Come First Served, as defined in [8]. Assignments are valid for one year and may be renewed. Permanent assignments require a specification, as defined in [8].
値17--65000はIANAによって割り当てられることです。 以来、[8]で定義されて、スペースは大きくて、それらがFirst Come First Servedとして割り当てられるかもしれないということです。 課題は、1年間有効であり、更新されるかもしれません。 永久的な課題は[8]で定義されるように仕様を必要とします。
7. Security Considerations
7. セキュリティ問題
The IPsec authentication header [10] MAY be used to provide data integrity protection and groupwise data origin authentication of PIM protocol messages. Authentication of PIM messages can protect against unwanted behaviors caused by unauthorized or altered PIM messages. In any case, a PIM router SHOULD NOT accept and process PIM messages from neighbors unless a valid Hello message has been received from that neighbor.
IPsec認証ヘッダー[10]は、データ保全保護を提供して、PIMプロトコルメッセージのデータ発生源認証をgroupwiseするのに使用されるかもしれません。 PIMメッセージの認証は権限のないか変えられたPIMメッセージによって引き起こされた求められていない振舞いから守ることができます。 どのような場合でも、受け入れて、有効なHelloメッセージがその隣人から受け取られていない場合、PIMルータSHOULD NOTは隣人からPIMメッセージを処理します。
Note that PIM-DM has no rendezvous point, and therefore no single point of failure that may be vulnerable. Because PIM-DM uses unicast routes provided by an unknown routing protocol, it may suffer collateral effects if the unicast routing protocol is attacked.
PIM-DMはランデブーポイントを全く持っていなくて、またしたがって、被害を受け易いかもしれない失敗のどんな単一のポイントも持っていないことに注意してください。 PIM-DMが未知のルーティング・プロトコルによって提供されたユニキャストルートを使用するので、ユニキャストルーティング・プロトコルが攻撃されるなら、それは傍系の効果を受けるかもしれません。
7.1. Attacks Based on Forged Messages
7.1. 偽造メッセージに基づく攻撃
The extent of possible damage depends on the type of counterfeit messages accepted. We next consider the impact of possible forgeries. A forged PIM-DM message is link local and can only reach a LAN if it was sent by a local host or if it was allowed onto the LAN by a compromised or non-compliant router.
可能な損害の程度は受け入れられたにせのメッセージのタイプに頼っています。 私たち、次は可能な偽造の影響を考えます。 それがローカル・ホストによって送られたか、またはそれが感染しているか不従順なルータによってLANに許容された場合にだけ、偽造PIM-DMメッセージは、リンク地方であり、LANに達することができます。
1. A forged Hello message can cause multicast traffic to be delivered
to links where there are no legitimate requestors, potentially
wasting bandwidth on that link. On a multi-access LAN, the
effects are limited without the capability to forge a Join
message, as other routers will Prune the link if the traffic is
not desired.
1. 偽造Helloメッセージでどんな正統の要請者もいないリンクにマルチキャストトラフィックを提供できます、潜在的にそのリンクに帯域幅を浪費して。 マルチアクセスLANでは、効果はJoinメッセージを作り出す能力なしで制限されます、トラフィックが望まれないなら他のルータがPruneにリンクを望んでいるとき。
2. A forged Join/Prune message can cause multicast traffic to be
delivered to links where there are no legitimate requestors,
potentially wasting bandwidth on that link. A forged Prune
2. 偽造Join/プルーンのメッセージでどんな正統の要請者もいないリンクにマルチキャストトラフィックを提供できます、潜在的にそのリンクに帯域幅を浪費して。 偽造Prune
Adams, et al. Experimental [Page 55] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[55ページ]RFC3973PIM--濃いモード2005年1月
message on a multi-access LAN is generally not a significant
attack in PIM, because any legitimately joined router on the LAN
would override the Prune with a Join before the upstream router
stops forwarding data to the LAN.
一般に、マルチアクセスLANに関するメッセージはPIMでの重要な攻撃ではありません、データをLANに転送するのを止める前にLANに関するどんな合法的に接合されたルータもJoinと共にPruneをくつがえすでしょう、したがって。
3. A forged Graft message can cause multicast traffic to be delivered
to links where there are no legitimate requestors, potentially
wasting bandwidth on that link. In principle, Graft messages
could be sent multiple hops because they are unicast to the
upstream router. This should not be a problem, as the remote
forger should have no way to get a Hello message to the target of
the attack. Without a valid Hello message, the receiving router
SHOULD NOT accept the Graft.
3. 偽造Graftメッセージでどんな正統の要請者もいないリンクにマルチキャストトラフィックを提供できます、潜在的にそのリンクに帯域幅を浪費して。 原則として、それらが上流のルータへのユニキャストであるので、複数のホップをGraftメッセージに送ることができました。 これは問題であるべきではありません、リモート捏造者にHelloメッセージを攻撃の目標に得る方法が全くあるべきでないとき。 有効なHelloメッセージがなければ、受信ルータSHOULD NOTはGraftを受け入れます。
4. A forged GraftAck message has no impact, as it will be ignored
unless the router has recently sent a Graft to its upstream
router.
4. 偽造GraftAckメッセージには、影響力が全くありません、ルータが最近上流のルータにGraftを送らないとそれが無視されるとき。
5. By forging an Assert message on a multi-access LAN, an attacker
could cause the legitimate forwarder to stop forwarding traffic to
the LAN. Such a forgery would prevent any hosts downstream of
that LAN from receiving traffic.
5. マルチアクセスLANにAssertメッセージを作り出すことによって、攻撃者は正統の混載業者にトラフィックをLANに送るのを止めさせることができるでしょう。 そのような偽造は、川下でそのLANについてトラフィックを受けるのをどんなホストも防ぐでしょう。
6. A forged State Refresh message on a multi-access LAN would have
the same impact as a forged Assert message, having the same
general functions. In addition, forged State Refresh messages
would be propagated downstream and might be used in a denial of
service attack. Therefore, a PIM-DM router SHOULD rate limit
State Refresh messages propagated.
6. マルチアクセスLANに関する偽造州Refreshメッセージには、偽造Assertメッセージと同じ影響力があるでしょう、同じ一般的な機能を持っていて。 さらに、偽造州Refreshメッセージは、川下に伝播されて、サービス不能攻撃に使用されるかもしれません。 したがって、SHOULDが限界州Refreshメッセージであると評定するPIM-DMルータは伝播されました。
7.2. Non-cryptographic Authentication Mechanisms
7.2. 非暗号の認証機構
A PIM-DM router SHOULD provide an option to limit the set of neighbors from which it will accept PIM-DM messages. Either static configuration of IP addresses or an IPSec security association may be used. All options that restrict the range of addresses from which packets are accepted MUST default to allowing all packets.
SHOULDがそれがPIM-DMメッセージを受け入れる隣人のセットを制限するためにオプションを提供するPIM-DMルータ。 IPアドレスの静的な構成かIPSecセキュリティ協会のどちらかが使用されるかもしれません。 パケットが受け入れられるアドレスの範囲を制限するすべてのオプションがすべてのパケットを許容するのをデフォルトとしなければなりません。
Furthermore, a PIM router SHOULD NOT accept protocol messages from a router from which it has not yet received a valid Hello message.
その上、SHOULD NOTが受け入れるPIMルータはそれが有効なHelloメッセージをまだ受け取っていないルータからのメッセージについて議定書の中で述べます。
7.3. Authentication Using IPsec
7.3. IPsecを使用する認証
The IPSec [10] transport mode using the Authentication Header (AH) is the recommended method to prevent the above attacks in PIM. The specific AH authentication algorithm and parameters, including the choice of authentication algorithm and the choice of key, are configured by the network administrator. The Encapsulating Security
Authentication Header(AH)を使用するIPSec[10]交通機関はPIMで上の攻撃を防ぐお勧めのメソッドです。 認証アルゴリズムの選択とキーの選択を含む特定のAH認証アルゴリズムとパラメタはネットワーク管理者によって構成されます。 要約セキュリティ
Adams, et al. Experimental [Page 56] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[56ページ]RFC3973PIM--濃いモード2005年1月
Payload (ESP) MAY also be used to provide both encryption and authentication of PIM protocol messages. When IPsec authentication is used, a PIM router SHOULD reject (drop without processing) any unauthorized PIM protocol messages.
また、有効搭載量(超能力)は、暗号化とPIMプロトコルメッセージの認証の両方を提供するのに使用されるかもしれません。 IPsecであるときに、認証は使用されていて、PIMルータSHOULD廃棄物(処理なしで低下する)はあらゆる権限のないPIMプロトコルメッセージです。
To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices that are used by senders to authenticate PIM protocol messages and are used by receivers to authenticate received PIM protocol messages. This document does not describe protocols for establishing Security Associations. It assumes that manual configuration of Security Associations is performed, but it does not preclude the use of some future negotiation protocol such as GDOI [17] to establish Security Associations.
IPSecを使用するために、PIMネットワークの管理者は1Security AssociationsでそれぞれのPIMルータを構成します、そして、PIMプロトコルメッセージを認証するのに送付者によって使用されて、認証する受信機によって使用される関連Security Parameters IndicesはPIMプロトコルメッセージを受け取りました。 このドキュメントは、Security Associationsを設立するためにプロトコルについて説明しません。 それは、Security Associationsの手動の構成が実行されますが、Security Associationsを証明するためにGDOI[17]などの何らかの将来の交渉プロトコルの使用を排除しないと仮定します。
The network administrator defines a Security Association (SA) and Security Parameters Index (SPI) to be used to authenticate all PIM-DM protocol messages from each router on each link in a PIM-DM domain.
ネットワーク管理者は、PIM-DMドメインの各リンクの上の各ルータからのすべてのPIM-DMプロトコルメッセージを認証するのに使用されるために、Security Association(SA)とSecurity Parameters Index(SPI)を定義します。
In order to avoid the problem of allocating individual keys for each neighbor on a link to each individual router, it is acceptable to establish only one authentication key for all PIM-DM routers on a link. This will not specifically authenticate the individual router sending the message, but will ensure that the sender is a PIM-DM router on that link. If this method is used, the receiver of the message MUST ignore the received sequence number, thus disabling anti-replay mechanisms. The effects of disabling anti-replay mechanisms are essentially the same as the effects of forged messages, described in Section 7.1, with the additional protection that the forger can only reuse legitimate messages.
各隣人のためにそれぞれの個々のルータへのリンクの上に個々のキーを割り当てるという問題を避けるために、リンクの上のすべてのPIM-DMルータのために1個の認証キーだけを設立するのは許容できます。 これは、明確にメッセージを送る個々のルータを認証しませんが、送付者がそのリンクの上のPIM-DMルータであることを確実にするでしょう。 このメソッドが使用されているなら、メッセージの受信機は容認された一連番号を無視しなければなりません、その結果、反再生メカニズムを無効にします。反再生メカニズムを無効にするという効果は捏造者が正統のメッセージを再利用できるだけであるというセクション7.1で追加保護で説明された偽造メッセージの効果と本質的には同じです。
The Security Policy Database at a PIM-DM router should be configured to ensure that all incoming and outgoing PIM-DM packets use the SA associated with the interface to which the packet is sent. Note that, according to [10], there is nominally a different Security Association Database (SAD) for each router interface. Thus, the selected Security Association for an inbound PIM-DM packet can vary depending on the interface on which the packet arrived. This fact allows the network administrator to use different authentication methods for each link, even though the destination address is the same for most PIM-DM packets, regardless of interface.
PIM-DMルータにおけるSecurity Policy Databaseは、すべての送受信のPIM-DMパケットがパケットが送られるインタフェースに関連しているSAを使用するのを保証するために構成されるべきです。 [10]によると、それぞれのルータインタフェースへの異なったSecurity Association Database(SAD)が名目上はあることに注意してください。 したがって、パケットが到着したインタフェースによって、本国行きのPIM-DMパケットのための選択されたSecurity Associationは異なることができます。 ネットワーク管理者は各リンクにこの事実で異なった認証方法を使用できます、ほとんどのPIM-DMパケットに、送付先アドレスが同じですが、インタフェースにかかわらず。
Adams, et al. Experimental [Page 57] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[57ページ]RFC3973PIM--濃いモード2005年1月
7.4. Denial of Service Attacks
7.4. サービス不能攻撃
There are a number of possible denial of service attacks against PIM that can be caused by generating false PIM protocol messages or even by generating false data traffic. Authenticating PIM protocol traffic prevents some, but not all, of these attacks. The possible attacks include the following:
多くの可能なサービス不能攻撃が誤ったPIMプロトコルメッセージを生成するか、または誤ったデータがトラフィックであると生成さえすることによって引き起こされる場合があるPIMに反対しています。 PIMプロトコルトラフィックを認証すると、すべてではなく、これらの攻撃のいくつかが防がれます。 可能な攻撃は以下を含んでいます:
* Sending packets to many different group addresses quickly can
amount to a denial of service attack in and of itself. These
messages will initially be flooded throughout the network before
they are pruned back. The maintenance of state machines and State
Refresh messages will be a continual drain on network resources.
* すばやく多くの異なったグループアドレスにパケットを送るのはそういうもののサービス不能攻撃に達することができます。 それらが剪定し返される前にこれらのメッセージは初めは、ネットワーク中で水につかるでしょう。 州のマシンと州Refreshメッセージのメインテナンスはネットワーク資源の上に絶え間ないドレインになるでしょう。
* Forged State Refresh messages sent quickly could be propagated by
downstream routers, creating a potential denial of service attack.
Therefore, a PIM-DM router SHOULD limit the rate of State Refresh
messages propagated.
* サービス攻撃の潜在的否定を作成して、川下のルータはすばやく送られた偽造州Refreshメッセージを伝播できました。 したがって、州Refreshメッセージのレートが伝播したPIM-DMルータSHOULD限界。
8. Acknowledgments
8. 承認
The major features of PIM-DM were originally designed by Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, David Meyer, and Liming Wei. Additional features for state refresh were designed by Dino Farinacci, Isidor Kouvelas, and Kurt Windisch. This revision was undertaken to incorporate some of the lessons learned during the evolution of the PIM-SM specification and early deployments of PIM-DM.
PIM-DMの主要な特徴は元々、スティーブン・デアリング、デボラEstrin、ディーノ・ファリナッチ、ヴァン・ジェーコブソン、アフマドHelmy、デヴィッド・マイヤー、およびLimingウェイによって設計されました。 状態がリフレッシュするので、付加的な機能はディーノ・ファリナッチ、Isidor Kouvelas、およびカート・ウィンディッシュによって設計されました。 この改正は、発展の間に学習されたレッスンのいくつかを取り入れるためにPIM-DMのPIM-SM仕様と早めの展開について引き受けられました。
Thanks the PIM Working Group for their comments.
彼らのコメントについてPIM作業部会に感謝します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[1] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
2236, November 1997.
[2] w.フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[3] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
Adams, et al. Experimental [Page 58] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[58ページ]RFC3973PIM--濃いモード2005年1月
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei,
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[4] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[5] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[6] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[7] Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999.
[7] ターレル、D.、「マルチキャストルーティング・プロトコルのための相互運用性規則」、RFC2715、1999年10月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[9] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html.
[9] 「アドレスファミリーナンバ」というIANAは http://www.iana.org/numbers.html からリンクしました。
[10] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[10] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[11] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[12] Deering, S.E., "Multicast Routing in a Datagram Internetwork",
Ph.D. Thesis, Electrical Engineering Dept., Stanford University,
December 1991.
[12] デアリング、東南、「データグラムインターネットワークにおけるマルチキャストルート設定」、博士Thesis、電気工学部、スタンフォード大学、1991年12月。
[13] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, November 1988.
[13]WaitzmanとD.とヤマウズラ、C.とS.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、1988年11月。
[14] Fenner, W., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work in Progress.
[14] フェナー、W.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、処理中の作業。
[15] Holbrook, H. and B. Cain, "Source Specific Multicast for IP",
Work in Progress.
[15] 「IPのためのソースの特定のマルチキャスト」というホルブルック、H.、およびB.カインは進行中で働いています。
[16] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-
directional Protocol Independent Multicast", Work in Progress.
[16] Progressのハンドレー、M.、Kouvelas、I.、Speakman、T.、およびL.Vicisano、「両性愛者の方向のプロトコル無党派Multicast」Work。
[17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.
2003年7月の[17]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
Adams, et al. Experimental [Page 59] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[59ページ]RFC3973PIM--濃いモード2005年1月
[18] Fenner, W., Handley, M., Kermode, R., and D. Thaler, "Bootstrap
Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress.
[18] フェナー、W.、ハンドレー、M.、カーモード、R.、およびD.ターレルは「PIMのまばらなモードのためにルータ(BSR)メカニズムを独力で進みます」、処理中の作業。
Authors' Addresses
作者のアドレス
Andrew Adams NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
アンドリューアダムスNextHop Technologies825勝者道、アナーバー、Suite100MI48108-2738
EMail: ala@nexthop.com
メール: ala@nexthop.com
Jonathan Nicholas ITT Industries Aerospace/Communications Division 100 Kingsland Rd Clifton, NJ 07014
ジョナサンニコラスITT産業通信課100キングスランド・航空宇宙/第クリフトン(ニュージャージー)07014
EMail: jonathan.nicholas@itt.com
メール: jonathan.nicholas@itt.com
William Siadak NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
ウィリアムSiadak NextHop Technologies825勝者道、アナーバー、Suite100MI48108-2738
EMail: wfs@nexthop.com
メール: wfs@nexthop.com
Adams, et al. Experimental [Page 60] RFC 3973 PIM - Dense Mode January 2005
アダムス、他 実験的な[60ページ]RFC3973PIM--濃いモード2005年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Adams, et al. Experimental [Page 61]
アダムス、他 実験的[61ページ]
一覧
スポンサーリンク
