RFC5059 日本語訳
5059 Bootstrap Router (BSR) Mechanism for Protocol IndependentMulticast (PIM). N. Bhaskar, A. Gall, J. Lingard, S. Venaas. January 2008. (Format: TXT=100749, PDF=85519 bytes) (Obsoletes RFC2362) (Updates RFC4601) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Bhaskar
Request for Comments: 5059 Arastra
Obsoletes: 2362 A. Gall
Updates: 4601 SWITCH
Category: Standards Track J. Lingard
Arastra
S. Venaas
UNINETT
January 2008
Bhaskarがコメントのために要求するワーキンググループN.をネットワークでつないでください: 5059Arastraは以下を時代遅れにします。 2362のA.胆汁アップデート: 4601年のスイッチカテゴリ: 標準化過程J.リンガードArastra S.Venaas UNINETT2008年1月
Bootstrap Router (BSR) Mechanism
for Protocol Independent Multicast (PIM)
プロトコルの独立しているマルチキャストのためにルータ(BSR)メカニズムを独力で進んでください。(PIM)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure.
このドキュメントは、特定のマルチキャストグループに発信するソースを発見するために受信機に手段としてRendezvous Pointの概念を使用するPIM(プロトコル無党派Multicast)家における、マルチキャストルーティング・プロトコルのクラスにBootstrap Router(BSR)メカニズムを指定します。 BSRは、機能するマルチキャストルータが、グループからRPへのマッピングのセットが必要であったことを学ぶことができる1つの方法です。 メカニズムは、ダイナミックであって、自己を主に構成していて、ルータ失敗に強健です。
Bhaskar, et al. Standards Track [Page 1] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Protocol Overview ..........................................5
1.3. Administrative Scoping and BSR .............................6
2. BSR State and Timers ............................................8
3. Bootstrap Router Election and RP-Set Distribution ...............9
3.1. Bootstrap Router Election ..................................9
3.1.1. Per-Scope-Zone Candidate-BSR State Machine .........10
3.1.2. Per-Scope-Zone State Machine for
Non-Candidate-BSR Routers ..........................11
3.1.3. Bootstrap Message Processing Checks ................13
3.1.4. State Machine Transition Events ....................14
3.1.5. State Machine Actions ..............................15
3.2. Sending Candidate-RP-Advertisement Messages ...............17
3.3. Creating the RP-Set at the BSR ............................18
3.4. Forwarding Bootstrap Messages .............................21
3.5. Bootstrap Messages to New and Rebooting Routers ...........22
3.5.1. No-Forward Bootstrap Messages ......................23
3.5.2. Unicasting Bootstrap Messages ......................23
3.6. Receiving and Using the RP-Set ............................23
4. Message Formats ................................................24
4.1. Bootstrap Message Format ..................................26
4.1.1. Semantic Fragmentation of BSMs .....................30
4.2. Candidate-RP-Advertisement Message Format .................31
5. Timers and Timer Values ........................................33
6. Security Considerations ........................................36
6.1. Possible Threats ..........................................36
6.2. Limiting Third-Party DoS Attacks ..........................36
6.3. Bootstrap Message Security ................................37
6.3.1. Unicast Bootstrap Messages .........................37
6.3.2. Multi-Access Subnets ...............................38
6.4. Candidate-RP-Advertisement Message Security ...............38
6.4.1. Non-Cryptographic Security of C-RP-Adv Messages ....38
6.4.2. Cryptographic Security of C-RP-Adv Messages ........39
6.5. Denial of Service using IPsec .............................39
7. Contributors ...................................................40
8. Acknowledgments ................................................40
9. Normative References ...........................................40
10. Informative References ........................................41
1. 序論…3 1.1. バックグラウンド…3 1.2. 概観について議定書の中で述べてください…5 1.3. 管理見るのとBSR…6 2. BSR状態とタイマ…8 3. ルータ選挙とRP-セット分配を独力で進んでください…9 3.1. ルータ選挙を独力で進んでください…9 3.1.1. 範囲ゾーンに従って、候補-BSRはマシンを述べます…10 3.1.2. 範囲ゾーンに従って、非候補BSRルータのためにマシンを述べてください…11 3.1.3. メッセージ処理チェックを独力で進んでください…13 3.1.4. マシン変遷出来事を述べてください…14 3.1.5. マシン動作を述べてください…15 3.2. 候補RP広告メッセージを送ります…17 3.3. RP-セットをBSRに創設します…18 3.4. 進めて、メッセージを独力で進んでください…21 3.5. 新しくてリブートしているルータにメッセージを独力で進んでください…22 3.5.1. どんなフォワードもメッセージを独力で進みません…23 3.5.2. Unicastingして、メッセージを独力で進んでください…23 3.6. RP-セットを受けて、使用します…23 4. メッセージ形式…24 4.1. メッセージ・フォーマットを独力で進んでください…26 4.1.1. BSMsの意味断片化…30 4.2. 候補RP広告メッセージ・フォーマット…31 5. タイマとタイマ値…33 6. セキュリティ問題…36 6.1. 可能な脅威…36 6.2. 第三者DoSを制限するのは攻撃されます…36 6.3. メッセージセキュリティを独力で進んでください…37 6.3.1. ユニキャストはメッセージを独力で進みます…37 6.3.2. マルチアクセスサブネット…38 6.4. 候補RP広告メッセージセキュリティ…38 6.4.1. C-RP-Advメッセージの非暗号のセキュリティ…38 6.4.2. C-RP-Advメッセージの暗号のセキュリティ…39 6.5. IPsecを使用するサービス妨害…39 7. 貢献者…40 8. 承認…40 9. 標準の参照…40 10. 有益な参照…41
Bhaskar, et al. Standards Track [Page 2] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[2ページ]。
1. Introduction
1. 序論
This document assumes some familiarity with the concepts of Protocol Independent Multicast - Sparse Mode (PIM-SM) [1] and Bidirectional Protocol Independent Multicast (BIDIR-PIM) [2], as well as with Administratively Scoped IP Multicast [3] and the IPv6 Scoped Address Architecture [4].
このドキュメントはプロトコル無党派Multicastの概念への何らかの親しみを仮定します--Administratively Scoped IP Multicast[3]とIPv6 Scoped Address Architecture[4]と同じくらい良いまばらなMode(PIM-SM)[1]とBidirectionalプロトコル無党派Multicast(BIDIR-PIM)[2]。
For correct operation, every multicast router within a PIM domain must be able to map a particular multicast group address to the same Rendezvous Point (RP). The PIM specifications do not mandate the use of a single mechanism to provide routers with the information to perform this group-to-RP mapping.
正しい操作において、PIMドメインの中のあらゆるマルチキャストルータが同じRendezvous Point(RP)に特定のマルチキャストグループアドレスを写像できなければなりません。 PIM仕様は、グループからRPへのこのマッピングを実行するために情報をルータに提供するためにただ一つのメカニズムの使用を強制しません。
This document describes the PIM Bootstrap Router (BSR) mechanism. BSR is one way that a multicast router can learn the information required to perform the group-to-RP mapping. The mechanism is dynamic, largely self-configuring, and robust to router failure.
このドキュメントはPIM Bootstrap Router(BSR)メカニズムについて説明します。 BSRはマルチキャストルータが、情報が、グループからRPへのマッピングを実行するのを必要としたことを学ぶことができる1つの方法です。 メカニズムは、ダイナミックであって、自己を主に構成していて、ルータ失敗に強健です。
BSR was first defined in RFC 2362 [7] as part of the original PIM-SM specification, which has been obsoleted by RFC 4601 [1]. This document provides an updated specification of the BSR mechanism from RFC 2362, and also extends it to cope with administratively scoped region boundaries and different flavors of routing protocols.
BSRは最初に、RFC2362[7]で当初のPIM-SM仕様の一部と定義されました。(仕様はRFC4601[1]によって時代遅れにされました)。 このドキュメントは、RFC2362からBSRメカニズムのアップデートされた仕様を提供して、また、ルーティング・プロトコルの行政上見られた領域境界と異なった風味に対処するためにそれを広げています。
Throughout the document, any reference to the PIM protocol family is restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR-PIM, unless stated otherwise.
ドキュメント中では、PIMプロトコル家についてのどんな言及もすなわち、RPベースのプロトコル、PIM-SM、およびBIDIR-PIMの部分集合に制限されます、別の方法で述べられない場合。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
1.1. Background
1.1. バックグラウンド
A PIM domain is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the rest of the Internet.
PIMドメインはPIMをすべて実行して、PIM Multicast Border Routers(PMBRs)によって定義された共有する境界線の中で作動するために構成される隣接のセットのルータです。 PMBRsはそれぞれのPIMドメインをインターネットの残りにつなげます。
Every PIM multicast group needs to be associated with the IP address of a Rendezvous Point (RP). This address is used as the root of a group-specific distribution tree whose branches extend to all nodes in the domain that want to receive traffic sent to the group. Senders inject packets into the tree in such a manner that they reach all connected receivers. How this is done and how the packets are forwarded along the distribution tree depends on the particular routing protocol.
あらゆるPIMマルチキャストグループが、Rendezvous Point(RP)のIPアドレスに関連している必要があります。 ブランチが交通を受けたがっているドメインですべてのノードに達するグループ特有の分配木の根がグループに発信したので、このアドレスは使用されています。 送付者はすべての接続受信機に達するくらいの方法で木にパケットを注ぎます。 これは完了しています、そして、分配木に沿ってどうパケットを進めるかはどう特定のルーティング・プロトコルによるか。
Bhaskar, et al. Standards Track [Page 3] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[3ページ]。
For all senders to reach all receivers, it is crucial that all routers in the domain use the same mappings of group addresses to RP addresses.
すべての送付者がすべての受信機に達するように、そのドメインのすべてのルータがグループアドレスに関する同じマッピングをRPアドレスに使用するのは、重要です。
An exception to the above is where a PIM domain has been broken up into multiple administrative scope regions. These are regions where a border has been configured so that a set of multicast groups will not be forwarded across that border. In this case, all PIM routers within the same scope region must map a particular scoped group to the same RP within that region.
上記の例外はPIMドメインが複数の管理範囲の地域に終えられたところです。 これらは境界が1セットのマルチキャストグループがその境界の向こう側に転送されないように構成された領域です。 この場合、同じ範囲の地域の中のすべてのPIMルータがその領域の中で特定の見られたグループを同じRPに写像しなければなりません。
In order to determine the RP for a multicast group, a PIM router maintains a collection of group-to-RP mappings, called the RP-Set. A group-to-RP mapping contains the following elements.
マルチキャストグループのためにRPを決定するために、RP-セットは、PIMルータがグループからRPへのマッピングの収集を維持すると呼びました。 グループからRPへのマッピングは以下の要素を含んでいます。
o Multicast group range, expressed as an address and prefix
length
o アドレスとして表されたマルチキャストグループ範囲と接頭語の長さ
o RP priority
o RP優先権
o RP address
o RPアドレス
o Hash mask length
o 細切れ肉料理マスクの長さ
o SM / BIDIR flag
o SM / BIDIR旗
In general, the group ranges of these group-to-RP mappings may overlap in arbitrary ways; hence, a particular multicast group may be covered by multiple group-to-RP mappings. When this is the case, the router chooses only one of the RPs by applying a deterministic algorithm so that all routers in the domain make the same choice. It is important to note that this algorithm is part of the specification of the individual routing protocols (and may differ among them), not of the BSR specification. For example, PIM-SM [1] defines one such algorithm. It makes use of a hash function for the case where a group range has multiple RPs with the same priority. The hash mask length is used by this function.
一般に、グループからRPへのこれらのマッピングのグループ範囲は任意の方法で重なるかもしれません。 したがって、特定のマルチキャストグループはグループからRPへの複数のマッピングでカバーされているかもしれません。 これがそうであるときに、ルータは、RPsについてそのドメインのすべてのルータが同じ選択をするように決定論アルゴリズムを適用することによって、1つだけを選びます。 このアルゴリズムがBSR仕様ではなく、個々のルーティング・プロトコル(そして、それらの中で異なるかもしれない)の仕様の一部であることに注意するのは重要です。 例えば、PIM-SM[1]はそのようなアルゴリズムの1つを定義します。 それはグループ範囲が同じ優先権がある複数のRPsを持っているケースにハッシュ関数を利用します。 細切れ肉料理マスクの長さはこの機能によって使用されます。
There are a number of ways in which such group-to-RP mappings can be established. The simplest solution is for all the routers in the domain to be statically configured with the same information. However, static configuration generally doesn't scale well, and, except when used in conjunction with Anycast-RP (see [8] and [9]), does not dynamically adapt to route around router or link failures.
グループからRPへのそのようなマッピングを確立できる多くの方法があります。 最も簡単な解決策はそのドメインのすべてのルータが同じ情報によって静的に構成されることです。 しかしながら、そして、一般に、Anycast-RPに関連して使用される時以外に、静的な構成がよく比例しない、([8]と[9])を見るか、ダイナミックにルータの周りのルートに順応しないか、または失敗をリンクします。
The BSR mechanism provides a way in which viable group-to-RP mappings can be created and rapidly distributed to all the PIM routers in a domain. It is adaptive, in that if an RP becomes unreachable, this
BSRメカニズムはグループからRPへの実行可能なマッピングを作成して、急速にドメインのすべてのPIMルータに分配できる方法を提供します。 それは中で適応型です。それがRPであるなら手が届かなくなる、これ
Bhaskar, et al. Standards Track [Page 4] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[4ページ]。
will be detected and the RP-Sets will be modified so that the unreachable RP is no longer used.
検出されて、RP-セットが変更されるので、手の届かないRPはもう使用されません。
1.2. Protocol Overview
1.2. プロトコル概観
In this section we give an informal and non-definitive overview of the BSR mechanism. The definitive specification begins in section 2.
このセクションでは、私たちはBSRメカニズムの非公式の、そして、非決定的な概観を与えます。 決定的な仕様はセクション2で始まります。
The general idea behind the BSR mechanism is that some of the PIM routers within a PIM domain are configured to be potential RPs for the domain. These are known as Candidate-RPs (C-RPs). A subset of the C-RPs will eventually be used as the actual RPs for the domain. In addition, some of the PIM routers in the domain are configured to be candidate bootstrap routers, or Candidate-BSRs (C-BSRs). One of these C-BSRs will be elected to be the bootstrap router (BSR) for the domain, and all the PIM routers in the domain will learn the result of this election through Bootstrap messages. The C-RPs will then report their candidacy to the elected BSR, which chooses a subset of these C-RPs and distributes corresponding group-to-RP mappings to all the routers in the domain through Bootstrap messages.
BSRメカニズムの後ろの概念はPIMドメインの中のPIMルータのいくつかがドメインへの潜在的RPsになるように構成されるということです。 これらはCandidate-RPs(C-RPs)として知られています。 C-RPsの部分集合は結局、ドメインに実際のRPsとして使用されるでしょう。 さらに、そのドメインのPIMルータのいくつかが、候補がルータ、またはCandidate-BSRs(C-BSRs)を独力で進むということになるように構成されます。 これらのC-BSRsの1つが選ばれる、ルータ(BSR)をドメインに独力で進んでください。そうすれば、そのドメインのすべてのPIMルータがBootstrapメッセージを通したこの選挙の結果を学ぶでしょう。 C-RPsは次に、彼らの立候補を選出されたBSRに報告して、Bootstrapメッセージを通してそのドメインのすべてのルータにグループからRPへの対応するマッピングを分配します。(BSRはこれらのC-RPsの部分集合を選びます)。
In more detail, the BSR mechanism works as follows. There are four basic phases (although in practice, all phases may be occurring simultaneously):
さらに詳細に、BSRメカニズムは以下の通り動作します。 4つの基本的なフェーズがあります(すべてのフェーズが同時に、実際には起こるかもしれませんが):
1. BSR Election. Each Candidate-BSR originates Bootstrap messages
(BSMs). Every BSM contains a BSR Priority field. Routers within
the domain flood the BSMs throughout the domain. A C-BSR that
hears about a higher-priority C-BSR than itself suppresses its
sending of further BSMs for some period of time. The single
remaining C-BSR becomes the elected BSR, and its BSMs inform all
the other routers in the domain that it is the elected BSR.
1. BSR選挙。 各Candidate-BSRはBootstrapメッセージ(BSMs)を溯源します。 あらゆるBSMがBSR Priority分野を含んでいます。 ドメインの中のルータはドメイン中にBSMsをあふれさせます。 それはそれ自体よりさらに高い優先度C-BSRについて聞きます。C-BSR、いつかの期間の間、一層のBSMsの発信を抑圧します。 独身の残っているC-BSRは選出されたBSRになります、そして、BSMsはそのドメインでそれが選出されたBSRであることを他のすべてのルータに知らせます。
2. C-RP Advertisement. Each Candidate-RP within a domain sends
periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the
elected BSR. A C-RP-Adv message includes the priority of the
advertising C-RP, as well as a list of group ranges for which the
candidacy is advertised. In this way, the BSR learns about
possible RPs that are currently up and reachable.
2. C-RP広告。 ドメインの中の各Candidate-RPは周期的なCandidate-RP-広告(C-RP-Adv)メッセージを選出されたBSRに送ります。 C-RP-Advメッセージは広告C-RPの優先権を含んでいます、立候補が広告に掲載されているグループ範囲のリストと同様に。 このように、BSRは現在、上がっていて届いている可能なRPsに関して学びます。
3. RP-Set Formation. The BSR selects a subset of the C-RPs that it
has received C-RP-Adv messages from to form the RP-Set. In
general, it should do this in such a way that the RP-Set is
neither so large that all the routers in the domain cannot be
informed about it, nor so small that the load is overly
concentrated on some RPs. It should also attempt to produce an
RP-Set that does not change frequently.
3. RP-セット構成。 BSRはそれがRP-セットを形成するためにC-RP-Advメッセージを受け取ったC-RPsの部分集合を選択します。 一般に、それはRP-セットがそれに関してそのドメインのすべてのルータを知らすことができるというわけではないくらいには大きくなくて、また非常に小さくないので負荷がいくつかのRPsにひどく集結されるような方法でこれをするべきです。 また、それは、頻繁に変化しないRP-セットを生産するのを試みるべきです。
Bhaskar, et al. Standards Track [Page 5] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[5ページ]。
4. RP-Set Flooding. In future Bootstrap messages, the BSR includes
the RP-Set information. Bootstrap messages are flooded through
the domain, which ensures that the RP-Set rapidly reaches all the
routers in the domain. BSMs are originated periodically to
ensure consistency after failure restoration.
4. RP-セット氾濫。 将来のBootstrapメッセージでは、BSRはRP-情報集合を含んでいます。 独力で進んでください。メッセージはドメインを通して水につかっています。ドメインは、RP-セットがそのドメインで急速にすべてのルータに達するのを確実にします。 BSMsは、失敗回復の後に一貫性があることを保証するために定期的に溯源されます。
When a PIM router receives a Bootstrap message, it adds the
group-to-RP mappings contained therein to its pool of mappings
obtained from other sources (e.g., static configuration). It
calculates the final mappings of group addresses to RP addresses
from this pool according to rules specific to the particular
routing protocol and uses that information to construct multicast
distribution trees.
PIMルータがBootstrapメッセージを受け取るとき、それはグループからRPへのそこに他のソース(例えば、静的な構成)から得られたマッピングのプールに含まれたマッピングを加えます。 それは、特定のルーティング・プロトコルに特定の規則に従ってこのプールからRPアドレスにグループアドレスの最終的なマッピングについて計算して、マルチキャスト分配木を組み立てるのにその情報を使用します。
If a PIM domain becomes partitioned, each area separated from the old BSR will elect its own BSR, which will distribute an RP-Set containing RPs that are reachable within that partition. When the partition heals, another election will occur automatically and only one of the BSRs will continue to send out Bootstrap messages. As is expected at the time of a partition or healing, some disruption in packet delivery may occur. The duration of the disruption period will be on the order of the region's round-trip time and the BS_Timeout value.
PIMドメインが仕切られるようになると、古いBSRと切り離された各領域はそれ自身のBSRを選出するでしょう。(そのパーティションの中で届いているRPsを含んでいて、BSRはRP-セットを分配するでしょう)。 パーティションが回復すると、別の選挙は自動的に起こるでしょう、そして、BSRsのひとりだけがBootstrapメッセージを出し続けるでしょう。 そのままで、パーティション時点で、予想されているか、または治療であり、パケット配信における何らかの分裂が起こるかもしれません。 分裂の期間の持続時間が領域の往復の時間の注文とBS_Timeout値にあるでしょう。
1.3. Administrative Scoping and BSR
1.3. 管理見るのとBSR
The mechanism described in the previous section does not work when the PIM domain is divided into administratively scoped regions. To handle this situation, we use the protocol modifications described in this section.
PIMドメインが行政上見られた領域に分割されるとき、前項で説明されたメカニズムは動作しません。 この状況を扱うために、私たちはこのセクションで説明されたプロトコル変更を使用します。
In the remainder of this document, we will use the term scope zone, or simply zone, when we are talking about a connected region of topology of a given scope. For a more precise definition of scope zones, see [4], which emphasizes that the scope zones are administratively configured.
このドキュメントの残りでは、私たちは用語範囲ゾーン、または単にゾーンを使用するつもりです。(その時、私たちは与えられた範囲のトポロジーの接続領域に関して話します)。 範囲ゾーンの、より正確な定義に関しては、[4]を見てください。([4]は、範囲ゾーンが行政上構成されると強調します)。
Administrative scoping permits a PIM domain to be divided into multiple admin-scope zones. Each admin-scope zone is a convex connected set of PIM routers and is associated with a set of group addresses. The boundary of the admin-scope zone is formed by Zone Border Routers (ZBRs). ZBRs are configured not to forward traffic for any of the scoped group addresses into or out of the scoped zone. It is important to note that a given scope boundary always creates at least two scoped zones: one on either side of the boundary.
管理見るのは、PIMドメインが複数のアドミン範囲ゾーンに分割されることを許可します。 それぞれのアドミン範囲ゾーンは、凸連結集合のPIMルータであり、1セットのグループアドレスに関連しています。 アドミン範囲ゾーンの境界はZone Border Routers(ZBRs)によって形成されます。 ZBRsは、ゾーンの中、または、見られたゾーンの外へから見られたグループアドレスのどれかの交通を進めないように構成されます。 与えられた範囲境界がいつも少なくとも2つの見られたゾーンを作成することに注意するのは重要です: 境界のどちらかの側の1。
Bhaskar, et al. Standards Track [Page 6] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[6ページ]。
In IPv4, administratively scoped zones are associated with a set of addresses given by an address and a prefix length. In IPv6, administratively scoped zones are associated with a set of addresses given by a single scope ID value. The set of addresses corresponding to a given scope ID value is defined in [5]. For example, a scope ID of 5 maps to the 16 IPv6 address ranges ff[0-f]5::/16.
IPv4では、行政上見られたゾーンはアドレスと接頭語の長さで与える1セットのアドレスに関連しています。 IPv6では、行政上見られたゾーンはただ一つの範囲ID価値で与える1セットのアドレスに関連しています。 与えられた範囲ID価値に対応するアドレスのセットは[5]で定義されます。 例えば、5の範囲IDは16のIPv6アドレスの範囲ff[0-f]5に以下を写像します:/16.
There are certain topological restrictions on admin-scope zones. The scope zone border must be complete and convex. By this we mean that there must be no path from the inside to the outside of the scoped zone that does not pass through a configured scope border router, and that the multicast capable path between any arbitrary pair of multicast routers in the scope zone must remain in the zone.
ある位相的な制限がアドミン範囲ゾーンにあります。 範囲のゾーンの境界は、完全であって、凸状であるに違いありません。 これで、私たちは、内部から構成された範囲境界ルータを通り抜けない見られたゾーンの外部まで経路が全くあるはずがなくて、範囲ゾーンのどんな任意の組のマルチキャストルータの間のマルチキャストのできる経路がゾーンに残らなければならないと言っています。
Administrative scoping complicates BSR because we do not want a PIM router within the scoped zone to use an RP outside the scoped zone. Thus we need to modify the basic mechanism to ensure that this doesn't happen.
私たちが、見られたゾーンの中のPIMルータに見られたゾーンの外でRPを使用して欲しいと思わないので、管理見るのはBSRを複雑にします。 したがって、私たちは、これが起こらないのを保証するように基本的機構を変更する必要があります。
This is done by running a separate copy of the basic BSR mechanism, as described in the previous section, within each admin-scope zone of a PIM domain. Thus a separate BSR election takes place for each admin-scope zone, a C-RP typically registers to the BSR of every admin-scope zone it is in, and every PIM router receives Bootstrap messages for every scope zone it is in. The Bootstrap messages sent by the BSR for a particular scope zone contain information about the RPs that should be used for the set of addresses associated with that scope zone.
基本的なBSRメカニズムの別々のコピーを動かすことによって、これをします、前項で説明されるように、PIMドメインのそれぞれのアドミン範囲ゾーンの中で。 したがって、別々のBSR選挙はそれぞれのアドミン範囲ゾーンに行われます、そして、C-RPはそれがあるあらゆるアドミン範囲ゾーンのBSRに通常登録します、そして、あらゆるPIMルータがそれがあるあらゆる範囲ゾーンへのBootstrapメッセージを受け取ります。 BSRによって特定の範囲ゾーンに送られたBootstrapメッセージはその範囲ゾーンに関連しているアドレスのセットに使用されるべきであるRPsの情報を含んでいます。
Bootstrap messages are marked to indicate which scope zone they belong to. Such admin-scoped Bootstrap messages are flooded in the normal way, but will not be forwarded by a ZBR across the boundary for that scope zone.
マークされたメッセージを独力で進んで、それらがどの範囲ゾーンに属すかを示してください。 そのようなアドミンで見られたBootstrapメッセージは、正常な方法で水につかりますが、境界の向こう側にZBRによってその範囲ゾーンに転送されないでしょう。
For the BSR mechanism to function correctly with admin scoping, there must be at least one C-BSR within each admin-scope zone, and there must be at least one C-RP that is configured to be a C-RP for the set of group addresses associated with the scoped zone.
アドミンが見られている状態でBSRメカニズムが正しく機能するように、それぞれのアドミン範囲ゾーンの中に少なくとも1C-BSRがあるに違いありません、そして、見られたゾーンに関連しているグループアドレスのセットのためのC-RPになるように構成される少なくとも1C-RPがあるに違いありません。
Even when administrative scoping is used, a copy of the BSR mechanism is still used across the entire PIM domain in order to distribute RP information for groups that are not administratively scoped. We call this copy of the mechanism non-scoped BSR. The copies of the mechanism run for each admin-scope zone are called scoped BSR.
管理見るのが使用されてさえいるとき、BSRメカニズムのコピーは、行政上見られないグループのためのRP情報を分配するのに全体のPIMドメインの向こう側にまだ使用されています。 私たちは、メカニズムのこのコピーを非見られたBSRと呼びます。 それぞれのアドミン範囲ゾーンのためのメカニズム走行のコピーは見られたBSRと呼ばれます。
Only the C-BSRs and the ZBRs need to be configured to know about the existence of the scope zones. Other routers, including the C-RPs, learn of their existence from Bootstrap messages.
C-BSRsとZBRsだけが、範囲ゾーンの存在に関して知るために構成される必要があります。 C-RPsを含む他のルータがBootstrapメッセージから彼らの存在を知っています。
Bhaskar, et al. Standards Track [Page 7] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[7ページ]。
All PIM routers within a PIM bootstrap domain where admin-scope ranges are in use must be capable of receiving Bootstrap messages and storing the winning BSR and RP-Set for all admin-scope zones that apply. Thus, PIM routers that only implement RFC 2362 or non-scoped BSR (which only allows one BSR per domain) cannot be used within the admin-scope zones of a PIM domain.
PIMの中のすべてのPIMルータがアドミン範囲の範囲が使用にBootstrapメッセージを受け取ることができて勝利BSRとRP-セットを格納しなければならないドメインを適用されるすべてのアドミン範囲ゾーンに独力で進みます。 したがって、PIMドメインのアドミン範囲ゾーンの中でRFC2362か非見られたBSR(1ドメインあたり1BSRしか許容しない)を実行するだけであるPIMルータは使用できません。
2. BSR State and Timers
2. BSR状態とタイマ
A PIM router implementing BSR holds the following state.
BSRを実行するPIMルータは以下の状態を保持します。
RP-Set
RP-セット
Per Configured or Learned Scope Zone (Z):
構成されたか学術的な範囲ゾーン(Z)単位で:
At all routers:
すべてのルータで:
Current Bootstrap Router's IP Address
電流はルータのIPアドレスを独力で進みます。
Current Bootstrap Router's BSR Priority
電流はルータのBSR優先権を独力で進みます。
Last BSM received from current BSR
最後に、BSMは現在のBSRから受信しました。
Bootstrap Timer (BST(Z))
タイマを独力で進んでください。(BST(Z))
Per group-to-RP mapping (M):
(M)を写像するグループからRP単位で:
Group-to-RP mapping Expiry Timer (GET(M,Z))
Expiry Timerを写像するグループからRP((M、Z)を得ます)
At a Candidate-BSR for Z:
Zのための候補-BSRで:
My state: One of "Candidate-BSR", "Pending-BSR",
"Elected-BSR"
私の州: 「候補-BSR」の1つ、「未定のBSR」「選出されたBSR」
At a router that is not a Candidate-BSR for Z:
ルータでは、それはZのためのCandidate-BSRではありません:
My state: One of "Accept Any", "Accept Preferred"
私の州: 1つ、「いずれも受け入れてください」では「受け入れてください都合のよい状態で」
Scope-Zone Expiry Timer (SZT(Z))
範囲ゾーン満期タイマ(SZT(Z))
At the current Bootstrap Router for Z only:
Zだけのための現在のBootstrap Routerで:
Per group-to-C-RP mapping (M):
(M)を写像するグループからC RP単位で:
Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
Expiry Timerを写像するグループからC RP(CGET(M、Z))
Bhaskar, et al. Standards Track [Page 8] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[8ページ]。
At a C-RP only:
C-RPだけで:
C-RP Advertisement Timer (CRPT)
C-RP広告タイマ(CRPT)
3. Bootstrap Router Election and RP-Set Distribution
3. ルータ選挙とRP-セット分配を独力で進んでください。
3.1. Bootstrap Router Election
3.1. ルータ選挙を独力で進んでください。
For simplicity, Bootstrap messages are used in both the BSR election and the RP-Set distribution mechanisms.
簡単さのために、BootstrapメッセージはBSR選挙とRP-セット分配メカニズムの両方で使用されます。
Each Bootstrap message indicates the scope to which it belongs. If the Admin Scope Zone bit is set in the first group range in the Bootstrap message, the message is called a scoped BSM. If the Admin Scope Zone bit is not set in the first group range in the Bootstrap message, the message is called a non-scoped BSM.
それぞれのBootstrapメッセージはそれが属する範囲を示します。 Admin Scope ZoneビットがBootstrapメッセージにおける最初のグループ範囲に設定されるなら、メッセージは見られたBSMと呼ばれます。 Admin Scope ZoneビットがBootstrapメッセージにおける最初のグループ範囲に設定されないなら、メッセージは非見られたBSMと呼ばれます。
In a scoped IPv4 BSM, the scope of the message is given by the first group range in the message, which can be any sub-range of 224/4. In a scoped IPv6 BSM, the scope of the message is given by the scope ID of the first group range in the message, which must have a mask length of at least 16. For example, a group range of ff05::/16 with the Admin Scope Zone bit set indicates that the Bootstrap message is for the scope with scope ID 5. If the mask length of the first group range in a scoped IPv6 BSM is less than 16, the message MUST be dropped and a warning SHOULD be logged.
見られたIPv4 BSMでは、メッセージにおける最初のグループ範囲はメッセージの範囲を与えます。(メッセージはどんな224/4のサブ範囲であるかもしれません)。 見られたIPv6 BSMでは、少なくとも16のマスクの長さを持たなければならないメッセージにおける最初のグループ範囲の範囲IDはメッセージの範囲を与えます。 例えば、ff05のグループ範囲:、:Admin Scope Zoneビットがセットしたことでの/16は、範囲にはBootstrapメッセージが範囲ID5と共にあるのを示します。 見られたIPv6 BSMの最初のグループ範囲のマスクの長さが16未満、メッセージを落とさなければならないということであり、警告がSHOULDであるなら、登録されてください。
The state machine for Bootstrap messages depends on whether or not a router has been configured to be a Candidate-BSR for a particular scope zone. The per-scope-zone state machine for a C-BSR is given below, followed by the state machine for a router that is not configured to be a C-BSR.
Bootstrapメッセージのための州のマシンは特定の範囲ゾーンのためにルータがCandidate-BSRになるように構成されたかどうかによります。 C-BSRのための範囲単位で帯状になっている州のマシンに下を与えます、続いて、C-BSRになるように構成されないルータのために州のマシンを与えます。
A key part of the election mechanism is that we associate a weight with each BSR. The weight of a BSR is defined to be the concatenation in fixed-precision unsigned arithmetic of the BSR Priority field from the Bootstrap message and the IP address of the BSR from the Bootstrap message (with the BSR Priority taking the most-significant bits and the IP address taking the least-significant bits).
選挙メカニズムの主要な部分は私たちが各BSRに重りを関連づけるということです。 BSRの重さは、BootstrapメッセージからのBSR Priority分野とBootstrapメッセージからのBSRのIPアドレス(BSR Priorityが最も多くの重要なビット取っていて、IPアドレスが最下位ビットを取っている)の固定精度の無記名の演算における連結になるように定義されます。
Bhaskar, et al. Standards Track [Page 9] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[9ページ]。
3.1.1. Per-Scope-Zone Candidate-BSR State Machine
3.1.1. 範囲ゾーンに従って、候補-BSRはマシンを述べます。
+-------------------------------------------------------------------+ | When in C-BSR state | +----------+-----------------+-------------------+------------------+ | Event | Receive | Bootstrap | Receive Non- | | | Preferred BSM | Timer Expires | preferred BSM | | | | | from Elected | | | | | BSR | +----------+-----------------+-------------------+------------------+ | | -> C-BSR state | -> P-BSR state | -> P-BSR state | | | Forward BSM; | Set Bootstrap | Forward BSM; | | Action | Store RP-Set; | Timer to | Set Bootstrap | | | Set Bootstrap | BS_Rand_Override | Timer to | | | Timer to | | BS_Rand_Override | | | BS_Timeout | | | +----------+-----------------+-------------------+------------------+
+-------------------------------------------------------------------+ | C-BSR状態のいつ| +----------+-----------------+-------------------+------------------+ | 出来事| 受信してください。| 独力で進んでください。| 受信、非| | | 都合のよいBSM| タイマは期限が切れます。| 都合のよいBSM| | | | | 選出にされる| | | | | BSR| +----------+-----------------+-------------------+------------------+ | | ->C-BSR状態| ->P-BSR状態| ->P-BSR状態| | | BSMを進めてください。 | 設定されて、独力で進んでください。| BSMを進めてください。 | | 動作| RP-セットを格納してください。 | タイマ| 設定されて、独力で進んでください。| | | 設定されて、独力で進んでください。| BS_底ならし革_オーバーライド| タイマ| | | タイマ| | BS_底ならし革_オーバーライド| | | BS_タイムアウト| | | +----------+-----------------+-------------------+------------------+
+-------------------------------------------------------------------+ | When in P-BSR state | +-----------+------------------+------------------+-----------------+ | Event | Receive | Bootstrap | Receive Non- | | | Preferred BSM | Timer Expires | preferred BSM | +-----------+------------------+------------------+-----------------+ | | -> C-BSR state | -> E-BSR state | -> P-BSR state | | | Forward BSM; | Originate BSM; | Forward BSM | | Action | Store RP-Set; | Set Bootstrap | | | | Set Bootstrap | Timer to | | | | Timer to | BS_Period | | | | BS_Timeout | | | +-----------+------------------+------------------+-----------------+
+-------------------------------------------------------------------+ | P-BSR状態のいつ| +-----------+------------------+------------------+-----------------+ | 出来事| 受信してください。| 独力で進んでください。| 受信、非| | | 都合のよいBSM| タイマは期限が切れます。| 都合のよいBSM| +-----------+------------------+------------------+-----------------+ | | ->C-BSR状態| ->E- BSR状態| ->P-BSR状態| | | BSMを進めてください。 | BSMを溯源してください。 | 前進のBSM| | 動作| RP-セットを格納してください。 | 設定されて、独力で進んでください。| | | | 設定されて、独力で進んでください。| タイマ| | | | タイマ| BS_期間| | | | BS_タイムアウト| | | +-----------+------------------+------------------+-----------------+
+-------------------------------------------------------------------+ | When in E-BSR state | +-----------+------------------+------------------+-----------------+ | Event | Receive | Bootstrap | Receive Non- | | | Preferred BSM | Timer Expires | preferred BSM | +-----------+------------------+------------------+-----------------+ | | -> C-BSR state | -> E-BSR state | -> E-BSR state | | | Forward BSM; | Originate BSM; | Originate BSM; | | Action | Store RP-Set; | Set Bootstrap | Set Bootstrap | | | Set Bootstrap | Timer to | Timer to | | | Timer to | BS_Period | BS_Period | | | BS_Timeout | | | +-----------+------------------+------------------+-----------------+
+-------------------------------------------------------------------+ | E-BSR状態のいつ| +-----------+------------------+------------------+-----------------+ | 出来事| 受信してください。| 独力で進んでください。| 受信、非| | | 都合のよいBSM| タイマは期限が切れます。| 都合のよいBSM| +-----------+------------------+------------------+-----------------+ | | ->C-BSR状態| ->E- BSR状態| ->E- BSR状態| | | BSMを進めてください。 | BSMを溯源してください。 | BSMを溯源してください。 | | 動作| RP-セットを格納してください。 | 設定されて、独力で進んでください。| 設定されて、独力で進んでください。| | | 設定されて、独力で進んでください。| タイマ| タイマ| | | タイマ| BS_期間| BS_期間| | | BS_タイムアウト| | | +-----------+------------------+------------------+-----------------+
Bhaskar, et al. Standards Track [Page 10] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[10ページ]。
A Candidate-BSR may be in one of three states for a particular scope zone:
Candidate-BSRが特定の範囲ゾーンへの3つの州の1つにあるかもしれません:
Candidate-BSR (C-BSR)
The router is a candidate to be the BSR for the scope zone, but
currently another router is the preferred BSR.
候補-BSR、(C-BSR) ルータは範囲ゾーンへのBSRである候補ですが、現在の別のルータは都合のよいBSRです。
Pending-BSR (P-BSR)
The router is a candidate to be the BSR for the scope zone.
Currently, no other router is the preferred BSR, but this router
is not yet the elected BSR. This is a temporary state that
prevents rapid thrashing of the choice of BSR during BSR
election.
BSR、(P-BSR)ルータは範囲ゾーンへのBSRである候補です。 現在、他のどんなルータも都合のよいBSRではありませんが、しかし、このルータは選出されたBSRではありません。 これはBSR選挙の間にBSRの選択について急速な打つことを防ぐ一時的な状態です。
Elected-BSR (E-BSR)
The router is the elected BSR for the scope zone and it must
perform all the BSR functions.
選出されたBSR、(E- BSR) ルータは範囲ゾーンへの選出されたBSRであり、それはすべてのBSR機能を実行しなければなりません。
In addition to the three states, there is one timer:
3つの州に加えて、ワンタイマーがあります:
o The Bootstrap Timer (BST) - used to time out old bootstrap router
information, and used in the election process to terminate P-BSR
state.
o Bootstrap Timer(BST)--タイムアウトに古い状態で使用されて、ルータ情報を独力で進んでください、そして、選挙に使用されて、処理して、P-BSR状態を終えてください。
The initial state for this configured scope zone is "Pending-BSR"; the Bootstrap Timer is initialized to BS_Rand_Override. This is the case both if the router is a Candidate-BSR at startup, and if it is reconfigured to become one later.
この構成された範囲ゾーンへの初期状態は「未定のBSR」です。 Bootstrap TimerはBS_Rand_Overrideに初期化されます。 ルータが始動のCandidate-BSRであり両方の、後で1つになるのが再構成されているなら、これはそうです。
3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers
3.1.2. 範囲ゾーンに従って、非候補BSRルータのためにマシンを述べてください。
The following state machine is used for scope zones that are discovered by the router from bootstrap messages. A simplified state machine is used for scope zones that are explicitly configured on the router and for the global zone. The differences are listed at the end of this section.
以下の州のマシンがルータによって発見される範囲ゾーンに使用される、メッセージを独力で進んでください。 簡易型の州のマシンはルータで明らかに構成される範囲ゾーンとグローバルなゾーンに使用されます。 違いはこのセクションの端に記載されています。
+-------------------------------------------------------------------+ | When in NoInfo state | +--------------+----------------------------------------------------+ | Event | Receive BSM | +--------------+----------------------------------------------------+ | | -> AP state | | Action | Forward BSM; Store RP-Set; | | | Set Bootstrap Timer to BS_Timeout | +--------------+----------------------------------------------------+
+-------------------------------------------------------------------+ | NoInfo状態のいつ| +--------------+----------------------------------------------------+ | 出来事| BSMを受けてください。| +--------------+----------------------------------------------------+ | | ->AP状態| | 動作| BSMを進めてください。 RP-セットを格納してください。 | | | 設定されて、BS_タイムアウトにタイマを独力で進んでください。| +--------------+----------------------------------------------------+
Bhaskar, et al. Standards Track [Page 11] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[11ページ]。
+-------------------------------------------------------------------+ | When in Accept Any state | +-------------+---------------------------+-------------------------+ | Event | Receive BSM | Scope-Zone Expiry | | | | Timer Expires | +-------------+---------------------------+-------------------------+ | | -> AP state | -> NoInfo state | | | Forward BSM; Store | Remove scope zone | | Action | RP-Set; Set | state | | | Bootstrap Timer to | | | | BS_Timeout | | +-------------+---------------------------+-------------------------+
+-------------------------------------------------------------------+ | Accept Any状態のいつ| +-------------+---------------------------+-------------------------+ | 出来事| BSMを受けてください。| 範囲ゾーン満期| | | | タイマは期限が切れます。| +-------------+---------------------------+-------------------------+ | | ->AP状態| ->NoInfo状態| | | BSMを進めてください。 ストア| 範囲ゾーンを取り除いてください。| | 動作| RP-セット。 セットします。| 状態| | | タイマを独力で進みます。| | | | BS_タイムアウト| | +-------------+---------------------------+-------------------------+
+-------------------------------------------------------------------+ | When in Accept Preferred state | +---------+---------------------+------------------+----------------+ | Event | Receive Preferred | Bootstrap | Receive Non- | | | BSM | Timer Expires | preferred BSM | +---------+---------------------+------------------+----------------+ | | -> AP state | -> AA state | -> AP state | | | Forward BSM; Store | Refresh RP- | | | Action | RP-Set; Set | Set; Remove | | | | Bootstrap Timer to | BSR state; Set | | | | BS_Timeout | SZT to | | | | | SZ_Timeout | | +---------+---------------------+------------------+----------------+
+-------------------------------------------------------------------+ | Accept Preferred状態のいつ| +---------+---------------------+------------------+----------------+ | 出来事| 受信してください都合のよい状態で。| 独力で進んでください。| 受信、非| | | BSM| タイマは期限が切れます。| 都合のよいBSM| +---------+---------------------+------------------+----------------+ | | ->AP状態| ->AA状態| ->AP状態| | | BSMを進めてください。 ストア| RPをリフレッシュしてください。| | | 動作| RP-セット。 セットします。| セットしてください。 取り外してください。| | | | タイマを独力で進みます。| BSR状態。 セットします。| | | | BS_タイムアウト| SZT| | | | | SZ_タイムアウト| | +---------+---------------------+------------------+----------------+
A router that is not a Candidate-BSR may be in one of three states:
Candidate-BSRでないルータが3つの州の1つにあるかもしれません:
NoInfo
The router has no information about this scope zone. When in
this state, no state information is held and no timers (that
refer to this scope zone) run. Conceptually, the state machine
is only instantiated when the router receives a scoped BSM for a
scope about which it has no prior knowledge. However, because
the router immediately transitions to the AA state
unconditionally, the NoInfo state can be considered to be
virtual in a certain sense. For this reason, it is omitted from
the description in section 2.
NoInfo、ルータには、この範囲ゾーンの情報が全くありません。 この状態では、州の情報が全くいつ、保持されないか、そして、タイマ(それはこの範囲ゾーンを示す)は全く動きません。 ルータがそれがどんな先の知識も持っていない範囲に見られたBSMを受けるときだけ、概念的に、州のマシンは例示されます。 しかしながら、ルータがすぐに無条件にAA状態に移行するので、ある意味では仮想でNoInfo状態を考えることができます。 この理由で、それはセクション2で記述から省略されます。
Accept Any (AA)
The router does not know of an active BSR, and will accept the
first Bootstrap message it sees as giving the new BSR's identity
and the RP-Set.
ルータがアクティブなBSRを知らないAny(AA)を受け入れてください、そして、それが新しいBSRのアイデンティティを与えるのを見る最初のBootstrapメッセージとRP-セットを受け入れるでしょう。
Bhaskar, et al. Standards Track [Page 12] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[12ページ]。
Accept Preferred (AP)
The router knows the identity of the current BSR, and is using
the RP-Set provided by that BSR. Only Bootstrap messages from
that BSR or from a C-BSR with higher weight than the current BSR
will be accepted.
Preferredを受け入れてください。(AP)ルータは、現在のBSRのアイデンティティを知って、そのBSRによって提供されたRP-セットを使用しています。 そのBSRか現在のBSRより高い重さがあるC-BSRからのBootstrapメッセージだけを受け入れるでしょう。
In addition to the three states, there are two timers:
3つの州に加えて、2個のタイマがあります:
o The Bootstrap Timer (BST) - used to time out old bootstrap router
information.
o Bootstrap Timer(BST)--タイムアウトに古い状態で使用されて、ルータ情報を独力で進んでください。
o The Scope-Zone Expiry Timer (SZT) - used to time out the scope
zone itself if Bootstrap messages specifying this scope zone stop
arriving.
o Scope-ゾーンExpiry Timer(SZT)--この範囲ゾーンを指定するBootstrapメッセージが、到着するのを止めるなら、範囲ゾーン自体をタイムアウトに使用しました。
The initial state for scope zones about which the router has no knowledge is "NoInfo".
ルータが知識を全く持っていない範囲ゾーンへの初期状態は"NoInfo"です。
The state machine used for scopes that have been configured explicitly on the router and for the global scope (which always exists) differs from the state machine above as follows.
ルータで明らかに構成された範囲とグローバルな範囲(いつも存在する)に使用される州のマシンは以下の通り上で州のマシンと異なっています。
o The "NoInfo" state doesn't exist.
o "NoInfo"状態は存在していません。
o No SZT is maintained. Hence, the event "Scope-Zone Expiry Timer
Expires" does not exist and no actions with regard to this timer
are executed.
o SZTは全く維持されません。 したがって、「範囲ゾーン満期タイマは吐き出す」出来事が存在していません、そして、このタイマに関する動作は全く実行されません。
The initial state for this state machine is "Accept Any".
この州のマシンのための初期状態は「いずれも受け入れてください」です。
3.1.3. Bootstrap Message Processing Checks
3.1.3. メッセージ処理チェックを独力で進んでください。
When a Bootstrap message is received, the following initial checks must be performed:
Bootstrapメッセージが受信されているとき、以下の初期のチェックを実行しなければなりません:
if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR
(we have no Hello state for BSM.src_ip_address)) {
drop the Bootstrap message silently
}
((DirectlyConnected(BSM.src_ip_アドレス)=FALSE)OR(私たちには、BSM.src_ip_アドレスのためのHello状態が全くない))です。静かにBootstrapメッセージを落としてください。
if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
if (BSM.no_forward_bit == 0) {
if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
drop the Bootstrap message silently
}
} else if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
(BSM.dst_ip_アドレス=、すべて、-、PIM-ROUTERS、)、((BSM.src_ip_アドレス!=RPF_隣人(BSM.BSR_ip_アドレス))が静かにBootstrapメッセージを落とすなら、_の前進のBSM.no_は(この範囲へのどんな前のBSMも受け入れました)OR(始動以来BS_Periodが経過しているよりさらに)であるならほかに=0)に噛み付きました)
Bhaskar, et al. Standards Track [Page 13] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[13ページ]。
#only accept no-forward BSM if quick refresh on startup
drop the Bootstrap message silently
}
} else if ((Unicast BSM support enabled) AND
(BSM.dst_ip_address is one of my addresses)) {
if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#the packet was unicast, but this wasn't
#a quick refresh on startup
drop the Bootstrap message silently
}
} else {
drop the Bootstrap message silently
}
#onlyに受け入れてください、迅速であるなら、フォワードがないBSMは始動低下の上で静かにBootstrapメッセージをリフレッシュします。 ほか、(BSMサポートが可能にしたユニキャスト)AND(BSM.dst_ip_アドレスは私のアドレスの1つである)である、((この範囲へのどんな前のBSMも受け入れました)OR(始動以来BS_Periodが経過しているよりさらに))である、#パケットがユニキャストでしたが、これが迅速に#aでなかった、始動低下の上で静かにBootstrapメッセージをリフレッシュしてください。 ほか静かにBootstrapメッセージを落としてください。
if (the interface the message arrived on is an admin scope
border for the BSM.first_group_address) {
drop the Bootstrap message silently
}
(メッセージが到着したインタフェースは. 最初の_グループ_が記述するBSMのためのアドミン範囲の境界です)静かにBootstrapメッセージを落としてください。
Basically, the packet must have come from a directly connected neighbor for which we have active Hello state. It must have been sent to the ALL-PIM-ROUTERS group, and unless it is a No-Forward BSM, it must have been sent by the correct upstream router towards the BSR that originated the Bootstrap message; or, if it is a No-Forward BSM, we must have recently restarted and have no BSR state for that admin scope. Also, if unicast BSM support is enabled, a unicast BSM is accepted if it is addressed to us, we have recently restarted, and we have no BSR state for that admin scope. In addition, it must not have arrived on an interface that is a configured admin-scope border for the first group address contained in the Bootstrap message.
基本的に、パケットは私たちが活動的なHello状態を持っている直接接続された隣人から来たに違いありません。 それを送ったに違いない、すべて、-、PIM-ROUTERS、分類してください。そうすれば、正しい上流のルータはそれがいいえ、前方でBSMでないなら、Bootstrapメッセージを溯源したBSRに向かってそれを送ったに違いありません。 または、それがフォワードがないBSMであるなら、私たちは、そのアドミン範囲に最近、再開して、BSR状態を全く持ってはいけません。 また、ユニキャストBSMサポートを可能にして、それが私たちに記述されて、私たちが最近、再開して、私たちにそのアドミン範囲へのBSR状態が全くないなら、ユニキャストBSMを受け入れます。 さらに、それはBootstrapメッセージに含まれた最初のグループアドレスのための構成されたアドミン範囲の境界であるインタフェースで到着していてはいけません。
3.1.4. State Machine Transition Events
3.1.4. 州のマシン変遷イベント
If the Bootstrap message passes the initial checks above without being discarded, then it may cause a state transition event in one of the above state machines. For both candidate and non-candidate BSRs, the following transition events are defined:
Bootstrapメッセージが捨てられないての上の初期のチェックを通過するなら、それは上の州のマシンの1つの状態遷移出来事を引き起こすかもしれません。 両方の候補と非候補BSRsに関しては、以下の変遷出来事は定義されます:
Receive Preferred BSM
A Bootstrap message is received from a BSR that has weight
higher than or equal to that of the current BSR. If a router
is in P-BSR state, then it uses its own weight as that of the
current BSR.
重さを現在のBSRのものと、より高いか等しくするBSRから受け取られたPreferred BSM A Bootstrapメッセージを受け取ってください。 ルータがP-BSR状態にあるなら、それは現在のBSRのものとしてそれ自身の重りを使用します。
A Bootstrap message is also preferred if it is from the
current BSR with a lower weight than the previous BSM it sent,
provided that if the router is a Candidate-BSR the current BSR
また、それが送った前のBSMより低重りと共に現在のBSRから来ているならBootstrapメッセージが好まれる、ルータはCandidate-BSRの現在のBSRです。
Bhaskar, et al. Standards Track [Page 14] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[14ページ]。
still has a weight higher than or equal to that of the router
itself. In this case, the "Current Bootstrap Router's BSR
Priority" state must be updated. (For lower weight, see Non-
preferred BSM from Elected BSR case.)
まだ、ルータ自体のものと、より高いか、または等しい状態で重りを持っています。 この場合、「電流はルータのBSR優先権を独力で進む」という状態をアップデートしなければなりません。 (下側の重さに関して、NonがElected BSRケースからBSMを好んだのを確実にしてください。)
Receive Non-preferred BSM
A Bootstrap message is received from a BSR other than the
current BSR that has lower weight than that of the current
BSR. If a router is in P-BSR state, then it uses its own
weight as that of the current BSR.
現在のBSRのものより低重さを持っている現在のBSR以外のBSRから受け取られたNonが都合のよいBSM A Bootstrapメッセージを受け取ってください。 ルータがP-BSR状態にあるなら、それは現在のBSRのものとしてそれ自身の重りを使用します。
Receive Non-preferred BSM from Elected BSR
A Bootstrap message is received from the elected BSR, but the
BSR Priority field in the received message has changed, so
that now the currently elected BSR has lower weight than that
of the router itself.
受け取られたElected BSR A Bootstrapメッセージから選出されたBSRからNonが都合のよいBSMを受けてくださいが、受信されたメッセージのBSR Priority分野は変化しました、今、現在選出されたBSRにはルータのものより低重さ自体があるように。
Receive BSM
A Bootstrap message is received, regardless of BSR weight.
BSRの重さにかかわらず受け取られたBSM A Bootstrapメッセージを受け取ってください。
In addition to state machine transitions caused by the receipt of Bootstrap messages, a state machine transition takes place each time the Bootstrap Timer or Scope-Zone Expiry Timer expires.
Bootstrapメッセージの領収書で引き起こされた州のマシン変遷に加えて、Bootstrap TimerかScope-ゾーンExpiry Timerが期限が切れるたびに州のマシン変遷は行われます。
3.1.5. State Machine Actions
3.1.5. 州のマシン動作
The state machines specify actions that include setting the Bootstrap Timer and the Scope-Zone Expiry Timer to various values. These values are defined in section 5.
州のマシンはBootstrap TimerとScope-ゾーンExpiry Timerを様々な値に設定するのを含んでいる動作を指定します。 これらの値はセクション5で定義されます。
In addition to setting and cancelling the timers, the following actions may be triggered by state changes in the state machines:
タイマを設定して、取り消すことに加えて、以下の動作は州のマシンにおける州の変化によって引き起こされるかもしれません:
Forward BSM
A multicast Bootstrap message with No-Forward bit cleared that
passes the Bootstrap Message Processing Checks is forwarded
out of all interfaces with PIM neighbors (including the
interface it is received on), except where this would cause
the BSM to cross an admin-scope boundary for the scope zone
indicated in the message. For details, see section 3.4.
PIM隣人とのすべてのインタフェースからフォワードがないビットがきれいにされているBootstrap Message Processing Checksを渡す前進のBSM AマルチキャストBootstrapメッセージを転送します(それが受け取られるインタフェースを含んでいて)、BSMがこれでメッセージで示された範囲ゾーンにアドミン範囲境界を渡るところを除いて。 詳細に関しては、セクション3.4を見てください。
Originate BSM
A new Bootstrap message is constructed by the BSR, giving the
BSR's address and BSR priority, and containing the BSR's
chosen RP-Set. The message is forwarded out of all interfaces
on which PIM neighbors exist, except where this would cause
the BSM to cross an admin-scope boundary for the scope zone
indicated in the message.
BSRのアドレスとBSR優先を与えて、BSRによって構成されて、BSRの選ばれたRP-セットを含むBSMのA新しいBootstrapメッセージを溯源してください。 すべてのインタフェースから外PIM隣人が存在するメッセージを転送します、BSMがこれでメッセージで示された範囲ゾーンにアドミン範囲境界を渡るところを除いて。
Bhaskar, et al. Standards Track [Page 15] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[15ページ]。
Store RP-Set
The router uses the group-to-RP mappings contained in a BSM to
update its local RP-Set.
地方のRP-セットをアップデートするためにBSMに含まれたルータが使用するRP-セットRPへのグループマッピングを格納してください。
This action is skipped for an empty BSM. A BSM is empty if it
contains no group ranges, or if it only contains a single
group range where that group range has the Admin Scope Zone
bit set (a scoped BSM) and an RP count of zero.
この動作は空のBSMのためにサボられます。 グループ範囲を全く含んでいないか、またはそのグループ範囲でAdmin Scope Zoneビットを設定するただ一つのグループ範囲(見られたBSM)とゼロのRPカウントを含むだけであるなら、BSMは空です。
If a mapping does not yet exist, it is created and the
associated Group-to-RP mapping Expiry Timer (GET) is
initialized with the holdtime from the BSM.
マッピングがまだ存在していないなら、それは作成されます、そして、関連Expiry Timer(GET)を写像するGroupからRPはholdtimeでBSMから初期化されます。
If a mapping already exists, its GET is set to the holdtime
from the BSM. If the holdtime is zero, the mapping is removed
immediately. Note that for an existing mapping, the RP
priority must be updated if changed.
マッピングが既に存在しているなら、GETはBSMからholdtimeに用意ができています。 holdtimeがゼロであるなら、マッピングはすぐに、取り除かれます。 変えるなら、既存のマッピングに関して、RP優先権をアップデートしなければならないことに注意してください。
Mappings for a group range are also to be immediately removed
if they are not present in the received group range. This
means that if there are any existing group-to-RP mappings for
a range where the respective RPs are not in the received
range, then those mappings must be removed.
グループ範囲のためのマッピングはそれらが容認されたグループ範囲に存在していないならまた、すぐに取り除くことです。 これは、何か範囲のためのグループからRPへの既存のマッピングがそれぞれのRPsが容認された範囲にないところにあればそれらのマッピングを取り除かなければならないことを意味します。
All RP mappings associated with the scope zone of the BSM are
updated with the new hash mask length from the received BSM.
This includes RP mappings for all group ranges learned for
this zone, not just the ranges in this particular BSM.
新しい細切れ肉料理マスクの長さで容認されたBSMからBSMの範囲ゾーンに関連しているすべてのRPマッピングをアップデートします。 これはこの特定のBSMの範囲だけではなく、このゾーンに学習されたすべてのグループ範囲のためのRPマッピングを含んでいます。
In addition, the entire BSM is stored for use in the action
Refresh RP-Set and to prime a new PIM neighbor as described
below.
さらに、全体のBSMは、動作Refresh RP-セットにおける使用、以下で説明されるように新しいPIM隣人を用意するために格納されます。
Refresh RP-Set
When the Bootstrap Timer expires, the router uses the copy of
the last BSM that it has received to refresh its RP-Set
according to the action Store RP-Set as if it had just
received it. This will increase the chance that the group-to-
RP mappings will not expire during the election of the new
BSR.
When Bootstrap Timerが吐き出すRP-セットをリフレッシュしてください、そして、ルータはそれがまるでちょうどそれを受けたかのように動作ストアRP-セットに従ってRP-セットをリフレッシュするために受けた最後のBSMのコピーを使用します。 これはグループからRPへのマッピングが新しいBSRの選挙の間期限が切れないという可能性を高めるでしょう。
Remove BSR state
When the Bootstrap Timer expires, all state associated with
the current BSR is removed (address, priority, BST, and saved
last BSM; see section 2). Note that this does not include any
group-to-RP mappings.
When Bootstrap Timerが吐き出すBSR状態を取り除いてください、そして、現在のBSRに関連しているすべての状態を取り除きます(アドレス、BSTであって、救われた優先権はBSMを持続します; セクション2を見てください)。 これがグループからRPへのどんなマッピングも含んでいないことに注意してください。
Bhaskar, et al. Standards Track [Page 16] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[16ページ]。
Remove scope zone state
When the Scope-Zone Expiry Timer expires, all state associated
with the scope zone is removed (see section 2).
Expiry Timerが吐き出す範囲ゾーン州のWhen Scope-ゾーンを取り除いてください、そして、範囲ゾーンに関連しているすべての状態を取り除きます(セクション2を見てください)。
3.2. Sending Candidate-RP-Advertisement Messages
3.2. 送付候補RP広告メッセージ
Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each scope zone for which it has state, to inform the BSR of the C-RP's willingness to function as an RP. These messages are sent with an interval of C_RP_Adv_Period, except when a new BSR is elected; see below.
あらゆるC-RP、定期的である、それがRPとして機能するC-RP意欲についてBSRに知らせるために状態を持っているそれぞれの範囲ゾーンへのBSRへのユニキャストa C-RP-Advメッセージ。 新しいBSRが選出される時を除いて、C_RP_Adv_Periodの間隔と共にこれらのメッセージを送ります。 以下を見てください。
When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv messages and wait a small randomized period C_RP_Adv_Backoff before sending each message. We recommend sending three messages because it is important that the BSR quickly learns which RPs are active, and some packet loss may occur when a new BSR is elected due to changes in the network. One way of implementing this is to set the CRPT to C_RP_Adv_Backoff when the new BSR is elected, as well as setting a counter to 2. Whenever the CRPT expires, we first send a C-RP-Adv message as usual. Next, if the counter is non-zero, it is decremented and the CRPT is again set to C_RP_Adv_Backoff instead of C_RP_Adv_Period.
新しいBSRが選出されるとき、C-RP MUSTは1〜3つのC-RP-Advメッセージを送って、各メッセージを送る_C RP_Adv_Backoff前の小さいランダマイズされた期間を待っています。 BSRが、どのRPsがアクティブであるかをすばやく学ぶのが、重要であるので、私たちは、3つのメッセージを送ることを勧めます、そして、新しいBSRがネットワークにおける変化のため選出されるとき、いくらかのパケット損失が起こるかもしれません。 これを実行する1つの方法は2に計数器をセットすることと同様に新しいBSRが選出されるとき、C_RP_Adv_BackoffにCRPTを設定することです。 CRPTが期限が切れるときはいつも、私たちは最初に、通常通りのC-RP-Advメッセージを送ります。 次に、カウンタが非ゼロであるなら、減少します、そして、再び、CRPTはC_RP_Adv_Periodの代わりにC_RP_Adv_Backoffへのセットです。
The Priority field in these messages is used by the BSR to select which C-RPs to include in the RP-Set. Note that lower values of this field indicate higher priorities, so that a value of zero is the highest possible priority. C-RPs should, by default, send C-RP-Adv messages with the Priority field set to 192.
これらのメッセージのPriority分野は、RP-セットにどのC-RPsを含んだらよいかを選択するのにBSRによって使用されます。 この分野の下側の値が、より高いプライオリティを示すことに注意してください、ゼロの値が可能な限り高い優先度であるように。 C-RPsはデフォルトでPriority分野セットがあるC-RP-Advメッセージを192に送るはずです。
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv message to the BSR for each scope zone for which it is currently serving as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR will then immediately time out the C-RP and generate a new Bootstrap message with the shut down RP holdtime set to 0.
いつC-RPが存在であるかは停止して、それはSHOULDです。至急、それが現在RPとして機能しているそれぞれの範囲ゾーンのためにC-RP-AdvメッセージをBSRに送ってください。 このC-RP-AdvメッセージのHoldtimeはゼロであるべきです。 BSRはすぐにその時、C-RPをタイムアウトに望んでいて、RP holdtimeが0に設定する閉鎖で新しいBootstrapメッセージを発生させます。
A C-RP-Adv message carries a list of group address and group mask field pairs. This enables the C-RP to specify the group ranges for which it is willing to be the RP. If the C-RP becomes an RP, it may enforce this scope acceptance when receiving Register or Join/Prune messages.
C-RP-Advメッセージはグループアドレスとグループマスク分野組のリストを運びます。 これは、C-RPがそれがRPであっても構わないと思っているグループ範囲を指定するのを可能にします。 RegisterかJoin/プルーンのメッセージを受け取るとき、C-RPがRPになるなら、それはこの範囲承認を実施するかもしれません。
A C-RP is configured with a list of group ranges for which it should advertise itself as the C-RP. A C-RP uses the following algorithm to determine which ranges to send to a given BSR.
C-RPはそれがC-RPとして自分を売り込むべきであるグループ範囲のリストによって構成されます。 C-RPは、どれが与えられたBSRに発信するために及ぶかを決定するのに以下のアルゴリズムを使用します。
Bhaskar, et al. Standards Track [Page 17] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[17ページ]。
For each group range R in the list, the C-RP advertises that range to the scoped BSR for the smallest scope that "contains" R. For IPv6, the containing scope is determined by matching the scope identifier of the group range with the scope of the BSR. For IPv4, it is the longest-prefix match for R, amongst the known admin-scope ranges. If no scope is found to contain the group range, the C-RP includes it in the C-RP-Adv sent to the non-scoped BSR. If a non-scoped BSR is not known, the range is not included in any C-RP-Adv.
リストのそれぞれのグループ範囲Rにおいて、含んでいる範囲は、C-RPがR.For IPv6を「含む」最も小さい範囲のために見られたBSRにその範囲の広告を出すとBSRの範囲にグループ範囲に関する範囲識別子を合わせることによって、決心しています。 IPv4に関しては、それは知られているアドミン範囲の範囲の中のRのための最も長い接頭語マッチです。 範囲が全くグループ範囲を含むのがわかっていないなら、C-RPは非見られるのに送られたC-RP-Adv BSRにそれを含んでいます。 非見られたBSRが知られていないなら、範囲はどんなC RP副詞にも含まれていません。
In addition, for each IPv4 group range R in the list, for each scoped BSR whose scope range is strictly contained within R, the C-RP SHOULD by default advertise that BSR's scope range to that BSR. And for each IPv6 group range R in the list with prefix length < 16, the C-RP SHOULD by default advertise each sub-range of prefix length 16 to the scoped BSR with the corresponding scope ID. An implementation MAY supply a configuration option to prevent the behavior described in this paragraph, but such an option SHOULD be disabled by default.
さらに、リストのそれぞれのIPv4グループ範囲R、範囲の範囲がRの中に厳密に含まれているそれぞれの見られたBSRに関して、C-RP SHOULDは、デフォルトでBSRの範囲がそのBSRに変化するのは広告を出します。 そして、接頭語長さ<16があるリストのそれぞれのIPv6グループ範囲Rのために、C-RP SHOULDはデフォルトで対応する範囲IDで接頭語長さ16のそれぞれのサブ範囲の見られたBSRに広告を出します。 実現は設定オプションを供給するかもしれません。しかし、このパラグラフ、そのようなオプションSHOULDで説明された振舞いを防ぐには、デフォルトで障害があってください。
For IPv6, the mask length of all group ranges included in the C-RP-Adv message sent to a scoped BSR MUST be >= 16.
IPv6、C-RP-Advメッセージにすべてのグループ範囲を含む長さが見られたBSR MUSTに送ったマスクに関しては、>=16になってください。
If the above algorithm determines that there are no group ranges to advertise to the BSR for a particular scope zone, a C-RP-Adv message MUST NOT be sent to that BSR. A C-RP MUST NOT send a C-RP-Adv message with no group ranges in it.
上のアルゴリズムが、特定の範囲ゾーンのためにBSRに広告を出すグループ範囲が全くないことを決定するなら、C-RP-AdvメッセージをそのBSRに送ってはいけません。 C-RP MUST NOTはそれのグループ範囲なしでC-RP-Advメッセージを送ります。
If the same router is the BSR for more than one scope zone, the C-RP-Adv messages for these scope zones MAY be combined into a single message.
同じルータが1つ以上の範囲ゾーンへのBSRであるなら、これらの範囲ゾーンへのC-RP-Advメッセージはただ一つのメッセージに結合されるかもしれません。
If the C-RP is a ZBR for an admin-scope zone, then the Admin Scope Zone bit MUST be set in the C-RP-Adv messages it sends for that scope zone; otherwise this bit MUST NOT be set. This information is currently only used for logging purposes by the BSR, but might allow for future extensions of the protocol.
C-RPがアドミン範囲ゾーンへのZBRであるなら、それがその範囲ゾーンに送るC-RP-AdvメッセージにAdmin Scope Zoneビットを設定しなければなりません。 さもなければ、このビットを設定してはいけません。 この情報は、現在伐採目的にBSRによって使用されるだけですが、プロトコルの今後の拡大を考慮するかもしれません。
3.3. Creating the RP-Set at the BSR
3.3. RP-セットをBSRに創設します。
Upon receiving a C-RP-Adv message, the router needs to decide whether or not to accept each of the group ranges included in the message. For each group range in the message, the router checks to see if it is the elected BSR for any scope zone that contains the group range, or if it is elected as the non-scoped BSR. If so, the group range is accepted; if not, the group range is ignored.
C-RP-Advメッセージを受け取ると、ルータは、メッセージにそれぞれのグループ範囲を含んでいて、受け入れるかどうか決める必要があります。 メッセージのそれぞれのグループ範囲がないかどうか、ルータは、グループ範囲を含むのが、何か範囲ゾーンへの選出されたBSRであるかどうかかそれともそれが非見られたBSRとして選出されるかどうか確認するためにチェックします。 そうだとすれば、グループ範囲を受け入れます。 そうでなければ、グループ範囲は無視されます。
Bhaskar, et al. Standards Track [Page 18] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[18ページ]。
For security reasons, we recommend that implementations have a way of restricting which IP addresses the BSR accepts C-RP-Adv messages from, e.g., access lists. For use of scoped BSR, it may also be useful to specify which group ranges should be accepted.
安全保障上の理由で、私たちは、実現にはBSRがC-RP-Advメッセージを受け入れるどのIPアドレスを制限するか方法(例えば、アクセスリスト)があることを勧めます。 また、見られたBSRの使用に、どのグループ範囲が受け入れられるべきであるかを指定するのも役に立つかもしれません。
If the group range is accepted, a group-to-C-RP mapping is created for this group range and the RP Address from the C-RP-Adv message.
グループ範囲を受け入れるなら、このグループ範囲とRP AddressのためにC-RP-AdvメッセージからグループからC RPへのマッピングを作成します。
If the mapping is not already part of the C-RP-Set, it is added to the C-RP-Set and the associated Group-to-C-RP mapping Expiry Timer (CGET) is initialized to the holdtime from the C-RP-Adv message. Its priority is set to the Priority from the C-RP-Adv message.
マッピングが既にC RPセットの一部でないなら、Expiry Timerを写像しながら、(CGET)がC-RP-Advメッセージからholdtimeに初期化されるとC RPセットとC RPへの関連Groupに追加されます。 優先権はC-RP-AdvメッセージからのPriorityに設定されます。
If the mapping is already part of the C-RP-Set, it is updated with the Priority from the C-RP-Adv message, and its associated CGET is reset to the holdtime from the C-RP-Adv message. If the holdtime is zero, the mapping is immediately removed from the C-RP-Set.
マッピングが既にC RPセットの一部であるなら、Priorityと共にC-RP-Advメッセージからそれをアップデートします、そして、C-RP-Advメッセージからholdtimeに関連CGETをリセットします。 holdtimeがゼロであるなら、マッピングはすぐに、C RPセットから取り除かれます。
The hash mask length is a global property of the BSR and is therefore the same for all mappings managed by the BSR.
細切れ肉料理マスクの長さは、BSRの巨視的性質であり、BSRによって管理されたすべてのマッピングに、したがって、同じです。
For compatibility with the previous version of the BSR specification, a C-RP-Adv message with no group ranges SHOULD be treated as though it contained the single group range ff00::/8 or 224/4. Therefore, according to the rule above, this group range will be accepted if and only if the router is elected as the non-scoped BSR.
BSR仕様の旧バージョンとの互換性のために、まるでシングルを含んでいるかのようにグループ範囲SHOULDが全く扱われていないC-RP-Advメッセージは範囲ff00を分類します:、:/8か224/4。 そして、したがって、規則に従って、上では、このグループ範囲を受け入れる、ルータが非見られたBSRとして選出される場合にだけ。
When a CGET expires, the corresponding group-to-C-RP mapping is removed from the C-RP-Set.
CGETが期限が切れるとき、グループからC RPへの対応するマッピングはC RPセットから取り除かれます。
The BSR constructs the RP-Set from the C-RP-Set. It may apply a local policy to limit the number of Candidate-RPs included in the RP-Set. The BSR may override the range indicated in a C-RP-Adv message unless the 'Priority' field from the C-RP-Adv message is less than 128.
BSRはC RPセットからRP-セットを構成します。 RP-セットにCandidate-RPsの数を含んでいる場合、それは制限するローカルの方針を適用するかもしれません。 BSRはC-RP-Advメッセージからの'優先権'分野が128未満でないならC-RP-Advメッセージで示された範囲をくつがえすかもしれません。
If the BSR learns of both BIDIR and PIM-SM Candidate-RPs for the same group range, the BSR MUST only include RPs for one of the protocols in the BSMs. The default behavior SHOULD be to prefer BIDIR.
BSRがBIDIRと同じグループ範囲へのPIM-SM Candidate-RPs、BSR MUSTだけが含む両方を知っているなら、BSMs. デフォルトの振舞いSHOULDにおけるプロトコルの1つのRPsはBIDIRを好むことになっています。
For inclusion in a BSM, the RP-Set is subdivided into sets of {group-
range, RP-Count, RP-addresses}. For each RP-address, the
"RP-Holdtime" field is set to the Holdtime from the C-RP-Set, subject
to the constraint that it MUST be larger than BS_Period and SHOULD be
larger than 2.5 times BS_Period to allow for some Bootstrap messages
getting lost. If some holdtimes from the C-RP-Sets do not satisfy
BSMでの包含において、RP-セットはグループ範囲、RP-カウント、RPアドレスのセットに細分されます。 各RP-アドレスにおいて、"RP-Holdtime"分野はC RPセットからのHoldtimeに設定されます、失せるいくつかのBootstrapメッセージを考慮するのがBS_PeriodとSHOULDより2.5回のBS_Periodより大きい状態で大きいに違いないという規制を受けることがあります。 C RPセットからのいくつかのholdtimesが満足させられないなら
Bhaskar, et al. Standards Track [Page 19] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[19ページ]。
this constraint, the BSR MUST replace those holdtimes with a value satisfying the constraint. An exception to this is the holdtime of zero, which is used to immediately withdraw mappings.
この規制であり、BSR MUSTはそれらのholdtimesを規制を満たす値に取り替えます。 これへの例外はゼロのholdtimeです。(それは、すぐにマッピングを引き下がらせるのに使用されます)。
The format of the Bootstrap message allows 'semantic fragmentation', if the length of the original Bootstrap message exceeds the packet maximum boundaries. However, to reduce the semantic fragmentation required, we recommend against configuring a large number of routers as C-RPs.
Bootstrapメッセージの形式は'意味断片化'を許容します、オリジナルのBootstrapメッセージの長さがパケットの最大の境界を超えているなら。 私たちは、C-RPsとして多くのルータを構成しないようにしかしながら、減少するのに、意味断片化が必要であることを推薦します。
In general, BSMs are originated at regular intervals according to the BS_Period timer. We do recommend that a BSM is also originated whenever the RP-set to be announced in the BSMs changes. This will usually happen when receiving C-RP advertisements from a new C-RP, or when a C-RP is shut down (C-RP advertisement with a holdtime of zero). There MUST however be a minimum of BS_Min_Interval between each time a BSM is sent. In particular, when a new BSR is elected, it will first send one BSM (which is likely to be empty since it has not yet received any C-RP advertisements), and then wait at least BS_Min_Interval before sending a new one. During that time, it is likely to have received C-RP advertisements from all usable C-RPs (since we say that a C-RP should send one or more advertisements with small random delays of C_RP_Adv_Backoff when a new BSR is elected). For this case in particular, where routers may not have a usable RP- set, we recommend originating a BSM as soon as BS_Min_Interval has passed. We suggest though that a BSR can do this in general. One way of implementing this, is to decrease the Bootstrap Timer to BS_Min_Interval whenever the RP-set changes, while not changing the timer if it is less than or equal to BS_Min_Interval.
一般に、一定の間隔を置いてBS_Periodタイマに従って、BSMsは溯源されます。 私たちは、また、BSMsで発表されるべきRP-セットが変化するときはいつも、BSMが溯源されることを勧めます。 新しいC-RPかそれともC-RPがいつ止められるかから(ゼロのholdtimeとのC-RP広告)C-RP広告を受け取るとき、通常、これは起こるでしょう。 しかしながら、BSMが送られる各回の間には、最小BS_Min_Intervalがあるに違いありません。 1BSM(まだ少しのC-RP広告も受け取っていないので空である傾向がある)を発信させて、新しいものを送る前に、新しいBSRが選出されるとき、次に、それは最初に、少なくとも待ちBS_Min_Intervalが特に、発信になるでしょう。 その時の間、それはすべての使用可能なC-RPsからC-RP広告を受け取りそうでした(私たちが、新しいBSRが選出されるとき、C-RPがC_RP_Adv_Backoffの小さい無作為の遅れがある1つ以上の広告を送るはずであると言うので)。 このような場合、特に、私たちは、ルータで使用可能なRPを用意ができさせないかもしれないところでBS_Min_Intervalが通るとすぐに、BSMを溯源することを勧めます。 もっとも、私たちは、一般に、BSRがこれができることを提案します。 一方通行、これを実行して、それであるならタイマを変えていない間のRP-場面の転換がBS_Min_よりInterval以下であるときはいつも、BS_Min_IntervalとBootstrap Timerを減少させることになっています。
A BSR originates separate scoped BSMs for each scope zone for which it is the elected BSR, as well as originating non-scoped BSMs if it is the elected non-scoped BSR.
BSRはそれが選出された非見られたBSRであるなら非見られたBSMsを溯源することと同様にそれが選出されたBSRであるそれぞれの範囲ゾーンに別々の見られたBSMsを溯源します。
Each group-to-C-RP mapping is included in precisely one of these BSMs -- namely, the scoped BSM for the narrowest scope containing the group range of the mapping, if any, or the non-scoped BSM otherwise.
グループからC RPへのそれぞれのマッピングは正確にこれらのBSMsの1つに含まれています--すなわち、そうでなければもしあればマッピングのグループ範囲か非見られたBSMを含む最も狭い範囲への見られたBSM。
A scoped BSM MUST have at least one group range, and the first group range in a scoped BSM MUST have the Admin Scope Zone bit set. This group range identifies the scope of the BSM. In a scoped IPv4 BSM, the first group range is the range corresponding to the scope of the BSM. In a scoped IPv6 BSM, the first group range may be any group range subject to the general condition that all the group ranges in such a BSM MUST have a mask length of at least 16 and MUST have the same scope ID as the scope of the BSM.
見られたBSM MUSTには、少なくとも1つのグループ範囲があります、そして、見られたBSM MUSTにおける最初のグループ範囲で、Admin Scope Zoneビットを設定します。 このグループ範囲はBSMの範囲を特定します。 見られたIPv4 BSMでは、最初のグループ範囲はBSMの範囲に対応する範囲です。 見られたIPv6 BSMでは、最初のグループ範囲は、そのようなBSM MUSTのすべてのグループ範囲には少なくとも16のマスクの長さがあるという一般的な条件を条件としたどんなグループ範囲であるかもしれなくも、BSMの範囲と同じ範囲IDを持たなければなりません。
Bhaskar, et al. Standards Track [Page 20] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[20ページ]。
Apart from identifying the scope, the first group range in a scoped BSM is treated like any other range with respect to RP mappings. That is, all mappings in the RP-set for this group range, if any, must be included in this first group range in the BSM. After this group range, other group ranges in this scope (for which there are RP mappings) appear in any order.
範囲を特定することは別として、見られたBSMにおける最初のグループ範囲はRPマッピングに関するいかなる他の範囲のようにも扱われます。 BSMのこの最初のグループ範囲にもしあればこのグループ範囲へのRP-セットにおけるすなわちすべてのマッピングを含まなければなりません。 このグループが及んだ後に、この範囲(RPマッピングがある)の他のグループ範囲は順不同に現れます。
The Admin Scope Zone bit of all group ranges other than the first SHOULD be set to 0 on origination, and MUST be ignored on receipt.
最初のSHOULD以外のすべてのグループ範囲のAdmin Scope Zoneビットを創作のときに0に設定されて、領収書の上で無視しなければなりません。
When an elected BSR is being shut down, it should immediately originate a Bootstrap message listing its current RP-Set, but with the BSR Priority field set to the lowest priority value possible. This will cause the election of a new BSR to happen more quickly.
選出されたBSRがすぐに止められる予定であるとき、それは現在のRP-セットを記載するBootstrapメッセージを溯源するべきですが、BSR Priorityと共に、分野は可能な最も低い優先順位の値にセットしました。 これで、新しいBSRの選挙は、より急速に起こるでしょう。
3.4. Forwarding Bootstrap Messages
3.4. 進めて、メッセージを独力で進んでください。
Generally, bootstrap messages originate at the BSR, and are hop-by- hop forwarded by intermediate routers if they pass the Bootstrap Message Processing Checks. There are two exceptions to this. One is that a bootstrap message is not forwarded if its No-Forward bit is set; see section 3.5.1. The other is that unicast BSMs (see section 3.5.2) are usually not forwarded. Implementers MAY, however, at their own discretion choose to re-send a No-Forward or unicast BSM in a multicast BSM, which MUST have the No-Forward bit cleared. It is essential that the No-Forward bit is cleared, since no Reverse Path Forwarding (RPF) check is performed by the receiver when it is set.
一般に、独力で進んでください。メッセージは、BSRで由来して、Bootstrap Message Processing Checksを渡すなら中間的ルータによって進められた近く跳びホップです。 これへの2つの例外があります。 1つはaが独力で進むということです。前進していないビットが設定されるなら、メッセージは転送されません。 セクション3.5.1を見てください。 もう片方は通常、ユニキャストBSMs(セクション3.5.2を見る)が進められないということです。 しかしながら、Implementersは、一存でいいえフォワードかフォワードがないビットをきれいにさせなければならないマルチキャストBSMのユニキャストBSMを再送するのを選ぶかもしれません。 フォワードがないビットがきれいにされるのは、不可欠です、それが設定されるとき、Reverse Path Forwarding(RPF)チェックが全く受信機によって実行されないので。
By hop-by-hop forwarding, we mean that the Bootstrap message itself is forwarded, not the entire IP packet. Each hop constructs an IP packet for each of the interfaces the BSM is to be forwarded out of; each packet contains the entire BSM that was received.
ホップごとの推進で、私たちは、Bootstrapメッセージ自体が全体のIPパケットではなく転送されると言っています。 各ホップはBSMが進められることになっているそれぞれのインタフェースにIPパケットを組み立てます。 各パケットは受け取られた全体のBSMを含んでいます。
When a Bootstrap message is forwarded, it is forwarded out of every multicast-capable interface that has PIM neighbors (including the one over which the message was received). The exception to this is if the interface is an admin-scope boundary for the admin-scope zone indicated in the first group range in the Bootstrap message packet.
Bootstrapメッセージを転送するとき、PIM隣人がいるあらゆるマルチキャストできるインタフェースからそれを進めます(メッセージが受け取られたものを含んでいて)。 これへの例外はインタフェースが最初のグループ範囲で示されたアドミン範囲ゾーンへのアドミン範囲境界であるかどうかというBootstrapメッセージパケットのことです。
As an optimization, a router MAY choose not to forward a BSM out of the interface the message was received on if that interface is a point-to-point interface. On interfaces with multiple PIM neighbors, a router SHOULD forward an accepted BSM out of the interface that BSM was received on, but if the number of PIM neighbors on that interface is large, it MAY delay forwarding a BSM out of that interface by a small randomized interval to prevent message implosion. A
最適化として、ルータは、そのインタフェースが二地点間インタフェースであるならメッセージが受け取られたインタフェースからBSMを進めないのを選ぶかもしれません。 複数のPIM隣人とのインタフェース、SHOULDが受け入れられたBSMをインタフェースから送るルータでは、そのBSMに受け取りましたが、そのインタフェースのPIM隣人の数が大きいなら、それは、メッセージ内部破裂を防ぐために小さいランダマイズされた間隔のそばでそのインタフェースからBSMを進めるのを遅らせるかもしれません。 A
Bhaskar, et al. Standards Track [Page 21] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[21ページ]。
configuration option MAY be provided to disable forwarding out of the interface a message was received on, but we recommend that the default behavior is to forward out of that interface.
メッセージが受け取られたインタフェースから推進を無効にするために設定オプションを提供するかもしれませんが、私たちは、そのインタフェースの外にフォワードにはデフォルトの振舞いがあることを勧めます。
Rationale: A BSM needs to be forwarded out of the interface the message was received on (in addition to the other interfaces) because the routers on a LAN may not have consistent routing information. If three routers on a LAN are A, B, and C, and at router B RPF(BSR)==A and at router C RPF(BSR)==B, then router A originally forwards the BSM onto the LAN, but router C will only accept it when router B re- forwards the message onto the LAN. If the underlying routing protocol configuration guarantees that the routers have consistent routing information, then forwarding out of the incoming interface may safely be disabled.
原理: BSMは、LANのルータには一貫したルーティング情報がないかもしれないのでメッセージが受け取られたインタフェース(他のインタフェースに加えた)から進められる必要があります。 LANに関する3つのルータがAと、Bと、Cであり、次に、ルータB RPF(BSR)=AにおいてルータC RPF(BSR)=Bでは、ルータAが元々、BSMをLANに送りますが、ルータBがメッセージをLANに再転送するときだけルータCがそれを受け入れるなら。 基本的なルーティング・プロトコル構成が、ルータには一貫したルーティング情報があるのを保証するなら、入って来るインタフェースからの推進は安全に無効にされるかもしれません。
A ZBR constrains all BSMs that are of equal or smaller scope than the configured boundary. That is, the BSMs are not accepted from, originated, or forwarded on the interfaces on which the boundary is configured. For IPv6, the check is a comparison between the scope of the first range in the scoped BSM and the scope of the configured boundary. For IPv4, the first range in the scoped BSM is checked to see if it is contained in or is the same as the range of the configured boundary.
ZBRは構成された境界より等しいか小さい範囲のものであるすべてのBSMsを抑制します。 境界が構成されるインタフェースですなわち、BSMsを受け入れもしませんし、溯源もしませんし、進めもしません。 IPv6に関しては、チェックは見られたBSMの最初の範囲の範囲と構成された境界の範囲での比較です。 IPv4がないかどうか、見られたBSMにおける最初の範囲は、それが構成された境界の範囲と中に含まれているか、または同じであるかを確認するためにチェックされます。
3.5. Bootstrap Messages to New and Rebooting Routers
3.5. 新しくてリブートしているルータにメッセージを独力で進んでください。
When a Hello message is received from a new neighbor, or a Hello message with a new GenID is received from an existing neighbor, one router on the LAN sends a stored copy of the Bootstrap message for each admin-scope zone to the new or rebooting router. This allows new or rebooting routers to learn the RP-Set quickly.
新しい隣人からHelloメッセージを受け取るか、または既存の隣人から新しいGenIDがあるHelloメッセージを受け取るとき、LANに関する1つのルータがそれぞれのアドミン範囲ゾーンへのBootstrapメッセージの格納されたコピーを新しいかリブートしているルータに送ります。 これで、新しいかリブートしているルータはすばやくRP-セットを学ぶことができます。
This message SHOULD be sent as a No-Forward Bootstrap message; see section 3.5.1. For backwards compatibility, this message MAY instead or in addition be sent as a unicast Bootstrap message; see section 3.5.2. These messages MUST only be accepted at startup; see section 3.1.3.
これはSHOULDを通信させます。前進していないBootstrapメッセージとして、送ってください。 セクション3.5.1を見てください。 遅れている互換性において、ユニキャストBootstrapメッセージとしてこのメッセージをさらに、代わりにか送るかもしれません。 セクション3.5.2を見てください。 始動でこれらのメッセージを受け入れるだけでよいです。 セクション3.1.3を見てください。
The router that does this is the Designated Router (DR) on the LAN, or, if the new or rebooting router is the DR, the router that would be the DR if the new or rebooting router were excluded from the DR election process.
これをするルータはLAN、または新しいかリブートしているルータがDRであることの新しいかリブートしているルータがDR選挙の過程から除かれるならDRであるルータのDesignated Router(DR)です。
Before sending a Bootstrap message in this manner, the router must wait until it has sent a triggered Hello message on this interface; otherwise, the new neighbor will discard the Bootstrap message.
この様にBootstrapメッセージを送る前に、引き起こされたHelloメッセージをこのインタフェースに送るまで、ルータは待たなければなりません。 さもなければ、新しい隣人はBootstrapメッセージを捨てるでしょう。
Bhaskar, et al. Standards Track [Page 22] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[22ページ]。
3.5.1. No-Forward Bootstrap Messages
3.5.1. どんなフォワードもメッセージを独力で進みません。
A No-Forward Bootstrap message, is a bootstrap message that has the No-Forward bit set. All implementations SHOULD support sending of No-Forward Bootstrap messages, and SHOULD also accept them. The RPF check MUST NOT be performed in the BSM processing check for a No- Forward BSM; see section 3.1.3. The messages have the same source and destination addresses as the usual multicast Bootstrap messages.
フォワードがないBootstrapメッセージはaがフォワードがないことの噛み付いているセットを持っているメッセージを独力で進むということです。 すべての実現SHOULDが、フォワードがないBootstrapメッセージを発信させるのを支持します、そして、また、SHOULDはそれらを受け入れます。 いいえの前進のBSMのためにBSM処理チェックでRPFチェックを実行してはいけません。 セクション3.1.3を見てください。 メッセージには、普通のマルチキャストBootstrapメッセージとして同じソースと送付先アドレスがあります。
3.5.2. Unicasting Bootstrap Messages
3.5.2. Unicastingして、メッセージを独力で進んでください。
For backwards compatibility, implementations MAY support unicast Bootstrap messages. Whether to send unicast Bootstrap messages instead of or in addition to No-Forward Bootstrap messages, and also whether to accept such messages, SHOULD be configurable. This message is unicast to the neighbor.
遅れている互換性のために、実現はユニキャストBootstrapメッセージを支持するかもしれません。 SHOULD、受諾かフォワードがないBootstrapメッセージとまた、そのようなメッセージを受け入れるかどうかに加えてユニキャストBootstrapを送るかどうか通信させます。構成可能であってください。 このメッセージは隣人へのユニキャストです。
3.6. Receiving and Using the RP-Set
3.6. RP-セットを受けて、使用します。
The RP-Set maintained by BSR is used by RP-based multicast routing protocols like PIM-SM and BIDIR-PIM. These protocols may obtain RP- Sets from other sources as well. How the final group-to-RP mappings are obtained from these RP-Sets is not part of the BSR specification. In general, the routing protocols need to re-calculate the mappings when any of their RP-Sets change. How such a change is signalled to the routing protocol is also not part of the present specification.
BSRによって維持されたRP-セットはPIM-SMとBIDIR-PIMのようなRPベースのマルチキャストルーティング・プロトコルによって使用されます。 これらのプロトコルはまた、他のソースからRPセットを入手するかもしれません。 これらのRP-セットからグループからRPへの最終的なマッピングをどう得るかは、BSR仕様の一部ではありません。 一般に、ルーティング・プロトコルは、それらのRP-セットのどれかが変化するとき、マッピングについて再計算する必要があります。 また、そのような変化がどうルーティング・プロトコルに合図されるかは、現在の仕様の一部ではありません。
Some group-to-RP mappings in the RP-Set indicate group ranges for which PIM-SM should be used; others indicate group ranges for use with BIDIR-PIM. Routers that support only one of these protocols MUST NOT ignore ranges indicated as being for the other protocol. They MUST NOT treat them as being for the protocol they support.
RP-セットにおけるグループからRPへのいくつかのマッピングがPIM-SMが使用されるべきであるグループ範囲を示します。 他のものはBIDIR-PIMとの使用のためにグループ範囲を示します。 これらのプロトコルの1つだけを支持するルータはもう片方のプロトコルのためにあるとして示された範囲を無視してはいけません。 彼らは彼らがサポートするプロトコルのためにいるとしてそれらを扱ってはいけません。
If a mapping is not already part of the RP-Set, it is added to the RP-Set and the associated Group-to-RP mapping Expiry Timer (GET) is initialized to the holdtime from the Bootstrap message. Its priority is set to the Priority from the Bootstrap message.
マッピングが既にRP-セットの一部でないなら、Expiry Timerを写像しながら、(GET)がBootstrapメッセージからholdtimeに初期化されるとRP-セットとRPへの関連Groupに追加されます。 優先権はBootstrapメッセージからPriorityに設定されます。
If a mapping is already part of the RP-Set, it is updated with the Priority from the Bootstrap message and its associated GET is reset to the holdtime from the Bootstrap message. If the holdtime is zero, the mapping is removed from the RP-Set immediately.
マッピングが既にRP-セットの一部であるなら、Priorityと共にBootstrapメッセージからそれをアップデートします、そして、Bootstrapメッセージからholdtimeに関連GETをリセットします。 holdtimeがゼロであるなら、マッピングはすぐに、RP-セットから取り除かれます。
Bhaskar, et al. Standards Track [Page 23] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[23ページ]。
4. Message Formats
4. メッセージ・フォーマット
BSR messages are PIM messages, as defined in [1]. The values of the PIM Message Type field for BSR messages are:
BSRメッセージは[1]で定義されるようにPIMメッセージです。 BSRメッセージのためのPIM Message Type分野の値は以下の通りです。
4 Bootstrap
4は独力で進みます。
8 Candidate-RP-Advertisement
8 候補RP広告
As with all other PIM control messages, BSR messages have IP protocol number 103.
他のすべてのPIMコントロールメッセージのように、BSRメッセージにはIPプロトコル番号103があります。
Candidate-RP-Advertisement messages are unicast to a BSR. Usually, Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS group, but in some circumstances (described in section 3.5.2) Bootstrap messages may be unicast to a specific PIM neighbor.
候補RP広告メッセージはBSRへのユニキャストです。 通常、BootstrapメッセージがTTL1があるマルチキャストである、すべて、-、PIM-ROUTERS、分類しなさい、ただし、事情(セクション3.5.2では、説明される)が独力で進むいくつかでは、メッセージはPIMが近所付き合いさせる詳細へのユニキャストであるかもしれません。
The IP source address used for Candidate-RP-Advertisement messages is a domain-wide reachable address. The IP source address used for Bootstrap messages (regardless of whether they are being originated or forwarded) is the link-local address of the interface on which the message is being sent (i.e., the same source address that the router uses for the Hello messages that it sends out that interface).
Candidate-RP-広告メッセージに使用されるIPソースアドレスはドメイン全体の届いているアドレスです。 Bootstrapメッセージ(それらを溯源するか、または進めていることにかかわらず)に使用されるIPソースアドレスはメッセージが送られるインタフェース(すなわち、ルータがそのインタフェースを出すというHelloメッセージに使用する同じソースアドレス)のリンクローカルアドレスです。
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。
In this section, we use the following terms defined in the PIM-SM specification [1]:
このセクションでは、私たちはPIM-SM仕様[1]に基づき定義された次の用語を使用します:
o Encoded-Unicast format
o コード化されたユニキャスト形式
o Encoded-Group format
o コード化されたグループ形式
We repeat these here to aid readability.
私たちは、読み易さを支援するためにここでこれらを繰り返します。
Encoded-Unicast address
コード化されたユニキャストアドレス
An Encoded-Unicast address takes the following format:
Encoded-ユニキャストアドレスは以下の形式を取ります:
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家| タイプをコード化します。| ユニキャストアドレス+++++++++++++++++++++++++…
Bhaskar, et al. Standards Track [Page 24] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[24ページ]。
Addr Family
The PIM address family of the 'Unicast Address' field of this
address.
Addr Family PIMはこのアドレスの'ユニキャストAddress'分野の家族に演説します。
Values of 0-127 are as assigned by the IANA for Internet Address
Families in [11]. Values 128-250 are reserved to be assigned by
the IANA for PIM-specific Address Families. Values 251 though
255 are designated for private use. As there is no assignment
authority for this space, collisions should be expected.
[11]のインターネットAddress FamiliesのためにIANAによって割り当てられるように0-127の値があります。 PIM特有のAddress FamiliesのためにIANAによって割り当てられるように、値128-250は予約されます。 255ですが、値251は私的使用目的で指定されます。 このスペースへの課題権威が全くなくて、衝突は予想されるべきです。
Encoding Type
The type of encoding used within a specific Address Family. The
value '0' is reserved for this field, and represents the native
encoding of the Address Family.
特定のAddress Familyの中で使用されたコード化のタイプのTypeをコード化します。 値'0'は、この分野に予約されて、Address Familyのネイティブのコード化を表します。
Unicast Address
The unicast address as represented by the given Address Family
and Encoding Type.
与えられたAddress FamilyとEncoding Typeによって表されるようにユニキャストが記述するユニキャストAddress。
Encoded-Group address
コード化されたグループアドレス
Encoded-Group addresses take the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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| レンにマスクをかけてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストAddress+++++++++++++++++++を分類してください…
Addr Family
Described above.
上のAddr Family Described。
Encoding Type
Described above.
上のType Describedをコード化します。
[B]IDIR bit
When set, all BIDIR-capable PIM routers will operate the
protocol described in [2] for the specified group range.
[B] IDIRビットWhenはセットして、すべてのBIDIRできるPIMルータが指定されたグループ範囲への[2]で説明されたプロトコルを操作するでしょう。
Reserved
Transmitted as zero. Ignored upon receipt.
ゼロとしての予約されたTransmitted。 領収書では、無視されます。
Admin Scope [Z]one
When set, this bit indicates that this group range is an
administratively scoped range.
アドミンScope[Z]1Whenはセットして、このビットは、このグループ範囲が行政上見られた範囲であることを示します。
Bhaskar, et al. Standards Track [Page 25] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[25ページ]。
Mask Len
The Mask length field is 8 bits. The value is the number of
contiguous one bits that are left justified and used as a mask;
when combined with the group address, it describes a range of
groups. It is less than or equal to the address length in bits
for the given Address Family and Encoding Type. If the message
is sent for a single group, then the Mask length must equal the
address length in bits for the given Address Family and Encoding
Type (e.g., 32 for IPv4 native encoding and 128 for IPv6 native
encoding).
長さがさばくMaskレンMaskは8ビットです。 値は正当化されるように残されて、マスクとして使用される隣接の1ビットの数です。 グループアドレスに結合されると、それはさまざまなグループについて説明します。 それは与えられたAddress FamilyとEncoding Typeのためのビットのアドレスの、より長さ以下です。 ただ一つのグループのためにメッセージを送るなら、Maskの長さは与えられたAddress FamilyとEncoding Type(例えば、IPv4のネイティブのコード化のための32とIPv6のネイティブのコード化のための128)のためにビットのアドレスの長さと等しくなければなりません。
Group multicast Address
Contains the group address.
グループが記述するマルチキャストAddress Containsを分類してください。
4.1. Bootstrap Message Format
4.1. メッセージ・フォーマットを独力で進んでください。
A Bootstrap message may be divided up into 'semantic fragments' if the resulting IP datagram would exceed the maximum packet size boundaries. Basically, a single Bootstrap message can be sent as multiple semantic fragments (each in a separate IP datagram), so long as the fragment tags of all the semantic fragments comprising the message are the same. The format of a single non-fragmented message is the same as the one used for semantic fragments.
結果として起こるIPデータグラムが最大のパケットサイズ境界を超えているなら、Bootstrapメッセージは'意味断片'に分割されるかもしれません。 基本的に、同じくらい複数の意味断片(別々のIPデータグラムのそれぞれ)をただ一つのBootstrapメッセージに送ることができます、メッセージを含むすべての意味断片の断片タグが同じである限り。 ただ一つの非断片化しているメッセージの形式は意味断片に使用されるものと同じです。
The format of a single 'fragment' is given below:
単一の'断片'の書式を以下に与えます:
Bhaskar, et al. Standards Track [Page 26] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[26ページ]。
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 |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask Len | BSR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSR Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count 1 | Frag RP Cnt 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1 Holdtime | RP1 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2 Holdtime | RP2 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count n | Frag RP Cnt n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1 Holdtime | RP1 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2 Holdtime | RP2 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ|N| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 断片タグ| Maskレンを論じ尽くしてください。| BSR優先権| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSR Address(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループAddress1(コード化されたグループ形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPカウント1| RP Cnt1を破片手榴弾で殺傷してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address1(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1 Holdtime| RP1優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address2(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2 Holdtime| RP2優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address m(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rpm Holdtime| rpm、優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループAddress2(コード化されたグループ形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループAddress n(コード化されたグループ形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Count n| RP Cnt nを破片手榴弾で殺傷してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address1(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1 Holdtime| RP1優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address2(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2 Holdtime| RP2優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . |
Bhaskar, et al. Standards Track [Page 27] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[27ページ]。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address m (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm Holdtime | RPm Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address m(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rpm Holdtime| rpm、優先権| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum
Described in [1].
チェックサムが[1]で説明した予約されたPIMバージョン。
Type
PIM Message Type. Value is 4 for a Bootstrap message.
PIMメッセージタイプをタイプしてください。 値はBootstrapメッセージのための4です。
[N]o-Forward bit
When set, this bit means that the Bootstrap message fragment is
not to be forwarded.
[N]o前進のビットWhenはセットして、このビットは、Bootstrapメッセージ断片が進められないことであることを意味します。
Fragment Tag
A randomly generated number, acts to distinguish the fragments
belonging to different Bootstrap messages; fragments belonging
to same Bootstrap message carry the same 'Fragment Tag'.
断片Tag Aは数、異なったBootstrapメッセージに属す断片を区別する行為を手当たりしだいに発生させました。 同じBootstrapメッセージに属す断片が同じ'断片Tag'を運びます。
Hash Mask Len
The length (in bits) of the mask to use in the hash function.
For IPv4, we recommend a value of 30. For IPv6, we recommend a
value of 126.
ハッシュ関数に使用するマスクの長さ(ビットの)のMaskレンを論じ尽くしてください。 IPv4に関しては、私たちは30の値を推薦します。 IPv6に関しては、私たちは126の値を推薦します。
BSR Priority
Contains the BSR priority value of the included BSR. This field
is considered as a high-order byte when comparing BSR addresses.
BSRs should by default set this field to 64. Note that for
historical reasons, the highest BSR priority is 255 (the higher
the better), whereas the highest RP Priority (see below) is 0
(the lower the better).
BSR Priority Contains、含まれているBSRのBSR優先順位の値。 BSRアドレスを比較するとき、この分野は高位バイトであるとみなされます。 BSRsはデフォルトでこの分野を64に設定するはずです。 歴史的な理由で、最も高いBSR優先度が255(より良いのは、より高い)であることにもかかわらずの、最も高いRP Priority(以下を見る)が0歳(より良いのは、より低い)であるというメモ。
BSR Address
The address of the bootstrap router for the domain. The format
for this address is given in the Encoded-Unicast address in [1].
BSR Address、アドレス、ドメインにルータを独力で進んでください。 [1]のEncoded-ユニキャストアドレスでこのアドレスのための書式を与えます。
Bhaskar, et al. Standards Track [Page 28] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[28ページ]。
Group Address 1..n
The group ranges (address and mask) with which the Candidate-RPs
are associated. Format described in [1]. In a fragment
containing admin-scope ranges, the first group range in the
fragment MUST satisfy the following conditions:
アドレス1を分類してください。n、Candidate-RPsが関連しているグループは及びます(記述して、マスクをかけます)。 [1]で説明された形式。 アドミン範囲の範囲を含む断片では、断片における最初のグループ範囲は以下の条件を満たさなければなりません:
o it MUST have the Admin Scope Zone bit set;
o for IPv4, it MUST be the group range for the entire admin-
scope range (this is required even if there are no RPs in the
RP-Set for the entire admin-scope range -- in this case, the
sub-ranges for the RP-Set are specified later in the fragment
along with their RPs);
o for IPv6, the Mask Len MUST be at least 16 and have the scope
ID of the admin-scope range.
o それで、Admin Scope Zoneビットを設定しなければなりません。 o IPv4に関しては、それは全体のアドミン範囲の範囲へのグループ範囲であるに違いありません(全体のアドミン範囲の範囲へのRP-セットにRPsが全くなくても、これが必要です--この場合、RP-セットのためのサブ範囲は後でそれらのRPsに伴う断片で指定されます)。 o IPv6に関しては、Maskレンは、少なくとも16歳であり、アドミン範囲の範囲の範囲IDを持たなければなりません。
RP Count 1..n
The number of Candidate-RP addresses included in the whole
Bootstrap message for the corresponding group range. A router
does not replace its old RP-Set for a given group range
until/unless it receives 'RP-Count' addresses for that range;
the addresses could be carried over several fragments. If only
part of the RP-Set for a given group range was received, the
router discards it without updating that specific group range's
RP-Set.
RPは1を数えます。対応するグループにおける全体のBootstrapメッセージにCandidate-RPアドレスの数を含んでいるnは及びます。 その範囲への'RP-カウント'というアドレスを受け取らない場合、ルータは/まで古いRP-セットに与えられたグループ範囲に取って代わりません。 数個の断片の上までアドレスを運ぶことができました。 与えられたグループ範囲へのRP-セットの一部だけを受け取ったなら、その特定のグループ範囲のRP-セットをアップデートしないで、ルータはそれを捨てます。
Frag RP Cnt 1..m
The number of Candidate-RP addresses included in this fragment
of the Bootstrap message, for the corresponding group range.
The 'Frag RP Cnt' field facilitates parsing of the RP-Set for a
given group range, when carried over more than one fragment.
RP Cnt1を破片手榴弾で殺傷してください。対応するグループ範囲へのBootstrapメッセージのこの断片にCandidate-RPアドレスの数を含んでいるm。 'RP Cntを破片手榴弾で殺傷してください'という分野は1個以上の断片の上まで運ばれた状態で与えられたグループ範囲へのRP-セットの構文解析、いつを容易にするか。
RP address 1..m
The address of the Candidate-RPs, for the corresponding group
range. The format for these addresses is given in the Encoded-
Unicast address in [1].
RPは1を記述します。m、対応するグループ範囲へのCandidate-RPsのアドレス。 [1]のEncodedユニキャストアドレスでこれらのアドレスのための書式を与えます。
RP1..m Holdtime
The Holdtime (in seconds) for the corresponding RP. This field
is copied from the 'Holdtime' field of the associated RP stored
at the BSR.
RP1。対応するRPのためのm Holdtime Holdtime(秒の)。 この分野はBSRに格納された関連RPの'Holdtime'分野からコピーされます。
RP1..m Priority
The 'Priority' of the corresponding RP and Encoded-Group
Address. This field is copied from the 'Priority' field stored
at the BSR when receiving a C-RP-Adv message. The highest
priority is '0' (i.e., unlike BSR priority, the lower the value
of the 'Priority' field, the better). Note that the priority is
per RP and per Group Address.
RP1。対応するRPとEncoded-グループAddressのm Priority'優先権'。 この分野はC-RP-Advメッセージを受け取るときBSRに格納された'優先権'野原からコピーされます。 最優先は'0'(すなわち、BSR優先権と異なって、'優先権'分野の値が低ければ低いほど、より良い)です。 優先権がRPとGroup Address単位であることに注意してください。
Bhaskar, et al. Standards Track [Page 29] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[29ページ]。
Within a Bootstrap message, the BSR Address, all the Group Addresses, and all the RP Addresses MUST be of the same address family. In addition, the address family of the fields in the message MUST be the same as the IP source and destination addresses of the packet. This permits maximum implementation flexibility for dual-stack IPv4/IPv6 routers.
Bootstrapメッセージの中に、同じアドレス家族にはBSR Address、すべてのGroup Addresses、およびすべてのRP Addressesがあるに違いありません。 さらに、メッセージの分野のアドレス家族はパケットのIPソースと送付先アドレスと同じでなければなりません。 これはデュアルスタックIPv4/IPv6ルータのために最大の実現の自在性を可能にします。
4.1.1. Semantic Fragmentation of BSMs
4.1.1. BSMsの意味断片化
Bootstrap messages may be split over several PIM Bootstrap Message Fragments (BSMFs); this is known as semantic fragmentation. Each of these must follow the above format. All fragments of a given Bootstrap message MUST have identical values for the Type, No-Forward bit, Fragment Tag, Hash Mask Len, BSR Priority, and BSR Address fields. That is, only the group-to-RP mappings may differ between fragments.
数個のPIM Bootstrap Message Fragmentsの上の分裂が(BSMFs)であったかもしれないならメッセージを独力で進んでください。 これは意味断片化として知られています。 それぞれのこれらは上の形式に続かなければなりません。 与えられたBootstrapメッセージのすべての断片には、Type、フォワードがないビット、Fragment Tag、Hash Maskレン、BSR Priority、およびBSR Address分野への同じ値がなければなりません。 すなわち、グループからRPへのマッピングだけが断片の間で異なるかもしれません。
This is useful if the BSM would otherwise exceed the MTU of the link the message will be forwarded over. If one relies purely on IP fragmentation, one would lose the entire message if a single fragment is lost. By use of semantic fragmentation, a single lost IP fragment will only cause the loss of the semantic fragment that the IP fragment was part of. As described below, a router only needs to receive all the RPs for a specific group range to update that range. This means that loss of a semantic fragment, due to an IP fragment getting lost, only affects the group ranges for which the lost semantic fragment contains information.
そうでなければ、BSMがメッセージが転送されるリンクのMTUを超えているなら、これは役に立ちます。人が純粋にIP断片化に依存するなら、ただ一つの断片が無くなるなら、1つは全体のメッセージを失うでしょう。 意味断片化、シングルの無くなっているIP断片がIP断片がそうであった意味断片の損失に部分を引き起こすだけである使用で。 以下で説明されるように、ルータは、特定のグループ範囲がその範囲をアップデートするようにすべてのRPsを受け取る必要があるだけです。 これは、意味断片の損失がなくなるIP断片のため、無くなっている意味断片が情報を含むグループ範囲に影響するだけであることを意味します。
If the BSR can split up the BSM so that each group range (and all of its RP information) can fit entirely inside one BSMF, then it should do so. If a BSMF is lost, the state from the previous BSM for the group ranges from the missing BSMF will be retained. Each fragment that does arrive will update the RP information for the group ranges contained in that fragment, and the new group-to-RP mappings for those can be used immediately. The information from the missing fragment will be obtained when the next BSM is transmitted.
BSRがそれぞれのグループ範囲(そして、RP情報のすべて)が完全に1BSMFの中で合うことができるようにBSMを分けることができるなら、それはそうするべきです。 BSMFが無くなると、なくなったBSMFからのグループ範囲への前のBSMからの状態は保有されるでしょう。 届く各断片はその断片に含まれたグループ範囲のためのRP情報をアップデートするでしょう、そして、すぐに、それらのためのグループからRPへの新しいマッピングは使用できます。 次のBSMを伝えるとき、なくなった断片からの情報を得るでしょう。
If the list of RPs for a single group range is long, one may split the information across multiple BSMFs to avoid IP fragmentation. In this case, all the BSMFs comprising the information for that group range must be received before the group-to-RP mapping in use can be modified. This is the purpose of the RP Count field -- a router receiving BSMFs from the same BSM (i.e., that have the same fragment tag) must wait until BSMFs providing RP Count RPs for that group range have been received before the new group-to-RP mapping can be used for that group range. If a single BSMF from such a large group
ただ一つのグループ範囲へのRPsのリストが長いなら、IP断片化を避けるために複数のBSMFsの向こう側に情報を分けるかもしれません。 この場合、グループからRPへの使用中であるマッピングを変更できる前にそのグループ範囲のための情報を包括するすべてのBSMFsを受け取らなければなりません。 これはRP Count分野の目的です--同じBSM(すなわち、それには、同じ断片タグがある)からBSMFsを受けるルータはそのグループ範囲にグループからRPへの新しいマッピングを使用できる前にそのグループ範囲にRP Count RPsを提供するBSMFsを受け取るまで待たなければなりません。 a独身のBSMFがそのような多くから分類するなら
Bhaskar, et al. Standards Track [Page 30] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[30ページ]。
range is lost, then that entire group range will have to wait until the next BSM is originated. Hence, in this case, the benefit of using semantic fragmentation is dubious.
範囲が無くなる、そして、次のBSMが溯源されるまで、その全体のグループ範囲は待っていなければなりません。 したがって、この場合、意味断片化を使用する利益は疑わしいです。
Next we need to consider how a BSR would remove group ranges. A router receiving a set of BSMFs cannot tell if a group range is missing. If it has seen a group range before, it must assume that that group range still exists, and that the BSMF describing that group range has been lost. The router should retain this information for BS_Timeout. Thus, for a BSR to remove a group range, it should include that group range, but with an RP Count of zero, and it should resend this information in each BSM for BS_Timeout.
次に、私たちは、BSRがどのようにグループ範囲を取り除くかを考える必要があります。 BSMFsの1セットを受けるルータは、グループ範囲がなくなるかどうかわかりません。 以前グループ範囲を見たことがあるなら、それは、そのグループ範囲がまだ存在していて、グループが及ぶと説明するBSMFがなくされたと仮定しなければなりません。 ルータはBS_Timeoutのためのこの情報を保有するべきです。 したがって、BSRがグループ範囲を取り除くように、それは、そのグループ範囲を含むべきですが、BS_Timeoutのためにゼロ、およびそれのRP Countと共に各BSMのこの情報を再送するべきです。
4.2. Candidate-RP-Advertisement Message Format
4.2. 候補RP広告メッセージ・フォーマット
Candidate-RP-Advertisement messages are periodically unicast from the C-RPs to the BSR.
定期的に候補RP広告メッセージはそうです。C-RPsからBSRまでのユニキャスト。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語カウント| 優先権| Holdtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address(コード化されたユニキャスト形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループAddress1(コード化されたグループ形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループAddress n(コード化されたグループ形式)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum
Described in [1].
チェックサムが[1]で説明した予約されたPIMバージョン。
Type
PIM Message Type. Value is 8 for a Candidate-RP-Advertisement
message.
PIMメッセージタイプをタイプしてください。 値はCandidate-RP-広告メッセージのための8です。
Prefix Count
The number of Encoded-Group Addresses included in the message;
indicating the group range for which the C-RP is advertising.
C-RPs MUST NOT send C-RP-Adv messages with a Prefix Count of
'0'.
メッセージにEncoded-グループAddressesの数を含んでいて、Countを前に置いてください。 C-RPが広告であるグループ範囲を示します。 C-RPsは'0'のPrefix CountがあるC-RP-Advメッセージを送ってはいけません。
Bhaskar, et al. Standards Track [Page 31] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[31ページ]。
Priority
The 'Priority' of the included RP, for the corresponding
Encoded- Group Address (if any). The highest priority is '0'
(i.e., the lower the value of the 'Priority' field, the higher
the priority). This field is stored at the BSR upon receipt
along with the RP address and corresponding Encoded-Group
Address.
優先権対応のための含まれているRPの'優先権'Encodedは(もしあれば)のAddressを分類します。 最優先は'0'(すなわち、'優先権'分野の値が低ければ低いほど、優先度は、より高い)です。 この分野はRPアドレスと対応するEncoded-グループAddressに伴う領収書のBSRに保存されます。
Holdtime
The amount of time (in seconds) the advertisement is valid.
This field allows advertisements to be aged out. This field
should be set to 2.5 times C_RP_Adv_Period.
Holdtime、広告が有効である時間(秒の)。 この分野は熟成するべき広告の外出することを許します。 この分野は2.5回のC_RP_Adv_Periodに設定されるべきです。
RP Address
The address of the interface to advertise as a Candidate-RP.
The format for this address is given in the Encoded-Unicast
address in [1].
RP Address、Candidate-RPとして広告を出すインタフェースのアドレス。 [1]のEncoded-ユニキャストアドレスでこのアドレスのための書式を与えます。
Group Address-1..n
The group ranges for which the C-RP is advertising. Format
described in Encoded-Group-Address in [1].
アドレス-1を分類してください。グループが及ぶC-RPが広告を出しているn。 [1]のEncodedグループアドレスで説明された形式。
Within a Candidate-RP-Advertisement message, the RP Address and all the Group Addresses MUST be of the same address family. In addition, the address family of the fields in the message MUST be the same as the IP source and destination addresses of the packet. This permits maximum implementation flexibility for dual-stack IPv4/IPv6 routers.
Candidate-RP-広告メッセージの中に、同じアドレスファミリーにはRP AddressとすべてのGroup Addressesがあるに違いありません。 さらに、メッセージの分野のアドレスファミリーはパケットのIPソースと送付先アドレスと同じでなければなりません。 これはデュアルスタックIPv4/IPv6ルータのために最大の実装の自在性を可能にします。
Bhaskar, et al. Standards Track [Page 32] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[32ページ]。
5. Timers and Timer Values
5. タイマとタイマ値
Timer Name: Bootstrap Timer (BST(Z))
タイマ名: タイマを独力で進んでください。(BST(Z))
+------------------+-------------------------+----------------------+ | Value Name | Value | Explanation | +------------------+-------------------------+----------------------+ | BS_Period | Default: 60 seconds | Periodic interval | | | | with which BSMs | | | | are normally | | | | originated | +------------------+-------------------------+----------------------+ | BS_Timeout | Default: 130 seconds | Interval after | | | | which a BSR is | | | | timed out if no | | | | BSM is received | | | | from that BSR | +------------------+-------------------------+----------------------+ | BS_Min_Interval | Default: 10 seconds | Minimum interval | | | | with which BSMs | | | | may be originated | +------------------+-------------------------+----------------------+ | BS_Rand_Override | see below | Randomized | | | | interval used to | | | | reduce control | | | | message overhead | | | | during BSR | | | | election | +------------------+-------------------------+----------------------+
+------------------+-------------------------+----------------------+ | 値の名| 値| 説明| +------------------+-------------------------+----------------------+ | BS_期間| デフォルト: 60秒| 周期的な間隔| | | | どのBSMsと共に| | | | 通常である| | | | 起因します。| +------------------+-------------------------+----------------------+ | BS_タイムアウト| デフォルト: 130秒| 後の間隔| | | | BSRはどれですか。| | | | いいえなら、調節されています。| | | | BSMは受け取られています。| | | | そのBSRから| +------------------+-------------------------+----------------------+ | BS_分_間隔| デフォルト: 10秒| 最小間隔| | | | どのBSMsと共に| | | | 溯源されるかもしれません。| +------------------+-------------------------+----------------------+ | BS_底ならし革_オーバーライド| 以下を見てください。| ランダマイズされます。| | | | 間隔は以前はよくそうしていました。| | | | コントロールを抑えてください。| | | | メッセージオーバーヘッド| | | | BSRの間| | | | 選挙| +------------------+-------------------------+----------------------+
Note that BS_Timeout MUST be larger than BS_Period, even if their values are changed from the defaults. We recommend that BS_Timeout is set to 2 times BS_Period plus 10 seconds.
デフォルトから彼らの値を変えても、BS_TimeoutがBS_Periodより大きいに違いないことに注意してください。 私たちは、BS_Timeoutが2回へのBS_Periodと10秒セットであることを推薦します。
BS_Rand_Override is calculated using the following pseudocode, in which all values are in units of seconds. The values of BS_Rand_Override generated by this pseudocode are between 5 and 23 seconds, with smaller values generated if the C-BSR has a high bootstrap weight, and larger values generated if the C-BSR has a low bootstrap weight.
BS_Rand_Overrideは、以下の擬似コード(ユニットの秒に、すべての値がある)を使用することで計算されます。 Overrideがこの擬似コードで生成したBS_Rand_の値は5〜23秒です、C-BSRが高値に重さ、およびC-BSRが安値に重さを独力で進ませるなら生成されたより大きい値を独力で進ませるなら生成されたより小さい値で。
BS_Rand_Override = 5 + priorityDelay + addrDelay
BS_底ならし革_オーバーライドは5+priorityDelay+addrDelayと等しいです。
where priorityDelay is given by:
以下はどこpriorityDelayを与えるか。
priorityDelay = 2 * log_2(1 + bestPriority - myPriority)
priorityDelayは2*ログ_2と等しいです。(1+bestPriority--myPriority)
and addrDelay is given by the following for IPv4:
そして、以下はIPv4のためにaddrDelayを与えます:
Bhaskar, et al. Standards Track [Page 33] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[33ページ]。
if (bestPriority == myPriority) {
addrDelay = log_2(1 + bestAddr - myAddr) / 16
} else {
addrDelay = 2 - (myAddr / 2^31)
}
addrDelayが(bestPriority=myPriority)であるならログ_2(1+bestAddr--myAddr)/16と等しい、ほか{addrDelayは2と等しいです--(myAddr / 2^31)}
and addrDelay is given by the following for IPv6:
そして、以下はIPv6のためにaddrDelayを与えます:
if (bestPriority == myPriority) {
addrDelay = log_2(1 + bestAddr - myAddr) / 64
} else {
addrDelay = 2 - (myAddr / 2^127)
}
addrDelayが(bestPriority=myPriority)であるならログ_2(1+bestAddr--myAddr)/64と等しい、ほか{addrDelayは2と等しいです--(myAddr / 2^127)}
and bestPriority is given by:
そして、以下はbestPriorityを与えます。
bestPriority = max(storedPriority, myPriority)
bestPriority=最大(storedPriority、myPriority)
and bestAddr is given by:
そして、以下はbestAddrを与えます。
bestAddr = max(storedAddr, myAddr)
bestAddr=最大(storedAddr、myAddr)
and where myAddr is the Candidate-BSR's address, storedAddr is the stored BSR's address, myPriority is the Candidate-BSR's configured priority, and storedPriority is the stored BSR's priority.
そして、storedAddrはmyAddrがCandidate-BSRのアドレスであることの保存されたBSRのアドレスです、そして、myPriorityはCandidate-BSRの構成された優先権です、そして、storedPriorityは保存されたBSRの優先権です。
Timer Name: Scope Zone Expiry Timer (SZT(Z))
タイマ名: 範囲ゾーン満期タイマ(SZT(Z))
+---------------+---------------------------+-----------------------+ | Value Name | Value | Explanation | +---------------+---------------------------+-----------------------+ | SZ_Timeout | Default: 1300 seconds | Interval after | | | | which a scope zone | | | | is timed out if no | | | | BSM is received | | | | for that scope | | | | zone | +---------------+---------------------------+-----------------------+
+---------------+---------------------------+-----------------------+ | 値の名| 値| 説明| +---------------+---------------------------+-----------------------+ | SZ_タイムアウト| デフォルト: 1300秒| 後の間隔| | | | どのa範囲ゾーン| | | | いいえなら、調節されています。| | | | BSMは受け取られています。| | | | その範囲に| | | | ゾーン| +---------------+---------------------------+-----------------------+
Note that SZ_Timeout MUST be larger than BS_Timeout, even if their values are changed from the defaults. We recommend that SZ_Timeout is set to 10 times BS_Timeout.
デフォルトから彼らの値を変えても、SZ_TimeoutがBS_Timeoutより大きいに違いないことに注意してください。 私たちは、SZ_Timeoutが10回のBS_Timeoutに用意ができることを勧めます。
Bhaskar, et al. Standards Track [Page 34] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[34ページ]。
Timer Name: Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
タイマ名: Expiry Timerを写像するグループからC RP(CGET(M、Z))
+------------------------+-------------------+----------------------+ | Value Name | Value | Explanation | +------------------------+-------------------+----------------------+ | C-RP Mapping Timeout | from message | Holdtime from C- | | | | RP-Adv message | +------------------------+-------------------+----------------------+
+------------------------+-------------------+----------------------+ | 値の名| 値| 説明| +------------------------+-------------------+----------------------+ | タイムアウトを写像するC-RP| メッセージから| CからのHoldtime| | | | RP-Advメッセージ| +------------------------+-------------------+----------------------+
Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z))
タイマ名: Expiry Timerを写像するグループからRP((M、Z)を得ます)
+-----------------------+-------------------+-----------------------+ | Value Name | Value | Explanation | +-----------------------+-------------------+-----------------------+ | RP Mapping Timeout | from message | Holdtime from BSM | +-----------------------+-------------------+-----------------------+
+-----------------------+-------------------+-----------------------+ | 値の名| 値| 説明| +-----------------------+-------------------+-----------------------+ | タイムアウトを写像するRP| メッセージから| BSMからのHoldtime| +-----------------------+-------------------+-----------------------+
Timer Name: C-RP Advertisement Timer (CRPT)
タイマ名: C-RP広告タイマ(CRPT)
+-------------------+------------------------+----------------------+ | Value Name | Value | Explanation | +-------------------+------------------------+----------------------+ | C_RP_Adv_Period | Default: 60 seconds | Periodic interval | | | | with which C-RP- | | | | Adv messages are | | | | sent to a BSR | +-------------------+------------------------+----------------------+ | C_RP_Adv_Backoff | Default: 0-3 seconds | Whenever a | | | | triggered C_RP_Adv | | | | is sent, a new | | | | randomized value | | | | between 0 and 3 | | | | is used | +-------------------+------------------------+----------------------+
+-------------------+------------------------+----------------------+ | 値の名| 値| 説明| +-------------------+------------------------+----------------------+ | C_RP_のAdv_期間| デフォルト: 60秒| 周期的な間隔| | | | どのC-RP、-| | | | Advメッセージはそうです。| | | | BSRに発信します。| +-------------------+------------------------+----------------------+ | C_RP_Adv_Backoff| デフォルト: 0-3秒| いつ| | | | 引き起こされた_C RP_Adv| | | | 送って、a新しいです。| | | | ランダマイズされた値| | | | 0〜3| | | | 使用にされる| +-------------------+------------------------+----------------------+
Bhaskar, et al. Standards Track [Page 35] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[35ページ]。
6. Security Considerations
6. セキュリティ問題
6.1. Possible Threats
6.1. 可能な脅威
Threats affecting the PIM BSR mechanism are primarily of two forms: denial-of-service (DoS) attacks and traffic-diversion attacks. An attacker that subverts the BSR mechanism can prevent multicast traffic from reaching the intended recipients, can divert multicast traffic to a place where they can monitor it, and can potentially flood third parties with traffic.
PIM BSRメカニズムに影響する脅威は主として2つのフォームのものです: サービスの否定(DoS)は攻撃されます、そして、トラフィック転換は攻撃されます。 BSRメカニズムを打倒する攻撃者は、マルチキャストトラフィックが意図している受取人に届くのを防ぐことができて、彼らがそれをモニターできる場所にマルチキャストトラフィックを逸らすことができて、トラフィックで第三者を潜在的にあふれさせることができます。
Traffic can be prevented from reaching the intended recipients by one of two mechanisms:
2つのメカニズムの1つで意図している受取人に届くのをトラフィックを防ぐことができます:
o Subverting a BSM, and specifying RPs that won't actually forward
traffic.
o BSMを打倒して、実際にトラフィックを進めないRPsを指定します。
o Registering with the BSR as a C-RP, and then not forwarding
traffic.
o C-RPとしてBSRとともに記名して、次に、トラフィックを進めません。
Traffic can be diverted to a place where it can be monitored by both of the above mechanisms; in this case, the RPs would forward the traffic, but are located so as to aid monitoring or man-in-the-middle attacks on the multicast traffic.
上のメカニズムの両方でそれをモニターできる場所にトラフィックを逸らすことができます。 この場合、RPsは、トラフィックを進めるでしょうが、マルチキャストトラフィックでモニターか介入者攻撃を支援するために見つけられています。
A third party can be flooded by either of the above two mechanisms by specifying the third party as the RP, and register traffic will then be forwarded to the third party.
上の2つのメカニズムのどちらかでRPとして第三者を指定することによって、第三者をあふれさせることができます、そして、次に、レジスタトラフィックを第三者に送るでしょう。
6.2. Limiting Third-Party DoS Attacks
6.2. 第三者DoS攻撃を制限します。
The third-party DoS attack above can be greatly reduced if PIM routers acting as DR do not continue to forward Register traffic to the RP in the presence of ICMP Protocol Unreachable or ICMP Host Unreachable responses. If a PIM router sending Register packets to an RP receives one of these responses to a data packet it has sent, it should rate- limit the transmission of future Register packets to that RP for a short period of time.
DRとして機能するPIMルータが、ICMPプロトコルUnreachableかICMP Host Unreachable応答があるときRPへのトラフィックをRegisterに送り続けていないなら、DoSが上で攻撃する第三者は大いに減少できます。 RPへのパケットをRegisterに送るPIMルータがそれが送ったデータ・パケットへのこれらの応答の1つを受け取るなら、それは、短期間の間、限界が将来のRegisterパケットのトランスミッションであるとそのRPに評定するべきです。
As this does not affect interoperability, the precise details are left to the implementer to decide. However, we note that a router implementing such rate limiting must only do so if the ICMP packet correctly echoes part of a Register packet that was sent to the RP. If this check were not made, then simply sending ICMP Unreachable packets to the DR with the source address of the RP spoofed would be sufficient to cause a denial-of-service attack on the multicast traffic originating from that DR.
これが相互運用性に影響しないのに従って、正確な詳細が決めるのがimplementerに残されます。 しかしながら、私たちは、ICMPパケットが正しくRPに送られたRegisterパケットの一部を反響するならそのようなレート制限を実装するルータがそうするだけでよいことに注意します。 このチェックをしないなら、RPのソースアドレスが偽造されている状態で単にDRへのパケットをICMP Unreachableに送るのは、そのDRから発しながらマルチキャストトラフィックでサービス不能攻撃を引き起こすために十分でしょうに。
Bhaskar, et al. Standards Track [Page 36] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[36ページ]。
6.3. Bootstrap Message Security
6.3. メッセージセキュリティを独力で進んでください。
If a legitimate PIM router in a domain is compromised, there is little any security mechanism can do to prevent that router from subverting PIM traffic in that domain.
ドメインの正統のPIMルータが感染されるなら、少ししかがどんなセキュリティー対策もそのドメインでPIMトラフィックを打倒するのからのそのルータを防ぐためにできるありません。
Implementations SHOULD provide a per-interface configuration option where one can specify that no Bootstrap messages are to be sent out of or accepted on the interface. This should generally be configured on all PMBRs in order not to receive messages from neighboring domains. This avoids receiving legitimate messages with conflicting BSR information from other domains, and also prevents BSR attacks from neighboring domains. This option is also useful on leaf interfaces where there are only hosts present. However, the Security Considerations section of [1] states that there should be a mechanism for not accepting PIM Hello messages on leaf interfaces and that messages should only be accepted from valid PIM neighbors. There may however be additional issues with unicast Bootstrap messages; see below. In addition to dropping all multicast Bootstrap messages on PMBRs, we also recommend configuring PMBRs (both towards other domains and on leaf interfaces) to drop all unicast PIM messages (Bootstrap message, Candidate-RP Advertisement, PIM register, and PIM register stop).
実装SHOULDは1つがインタフェースでどんなBootstrapメッセージも送られないことであると指定するか、または受け入れることができた1インタフェースあたり1つの設定オプションを提供します。 一般に、これは隣接しているドメインからメッセージを受け取らない命令におけるすべてのPMBRsで構成されるべきです。 これは、闘争しているBSR情報で他のドメインから正統のメッセージを受け取るのを避けて、また、隣接しているドメインからBSR攻撃を防ぎます。 また、このオプションも出席しているホストしかいない葉のインタフェースで役に立ちます。 しかしながら、[1]のSecurity Considerations部は、PIM Helloメッセージを受け入れないためのメカニズムが葉のインタフェースにあるはずであり、メッセージが有効なPIM隣人から受け入れられるだけであるべきであると述べます。 しかしながら、ユニキャストBootstrapメッセージには追加設定があるかもしれません。 以下を見てください。 また、PMBRsに関するすべてのマルチキャストBootstrapメッセージを下げることに加えて、私たちは、すべてのユニキャストPIMメッセージを下げるために、PMBRs(他のドメインと葉のインタフェースの上の)を構成することを勧めます(PIMは登録します、そして、Candidate-RP Advertisement、メッセージを独力で進んでください、そして、PIMは停止を登録します)。
6.3.1. Unicast Bootstrap Messages
6.3.1. ユニキャストはメッセージを独力で進みます。
There are some possible security issues with unicast Bootstrap messages. The Bootstrap Message Processing Checks prevent a router from accepting a Bootstrap message from outside of the PIM Domain, as the source address on Bootstrap messages must be an immediate PIM neighbor. There is however a small window of time after a reboot where a PIM router will accept a bad Bootstrap message that is unicast from an immediate neighbor, and it might be possible to unicast a Bootstrap message to a router during this interval from outside the domain, using the spoofed source address of a neighbor. The best way to protect against this is to use the above-mentioned mechanism of configuring border and leaf interfaces to drop all bootstrap messages, including unicast messages. This can also be prevented if PMBRs perform source-address filtering to prevent packets entering the PIM domain with IP source addresses that are infrastructure addresses in the PIM domain.
ユニキャストBootstrapメッセージにはいくつかの可能な安全保障問題があります。 Bootstrap Message Processing Checksは、ルータがPIM Domainの外部からBootstrapメッセージを受け入れるのを防ぎます、Bootstrapメッセージに関するソースアドレスが即座のPIM隣人であるに違いないので。 しかしながら、リブートの後に、時間の小さい窓がPIMルータがすぐ隣の人からユニキャストである悪いBootstrapメッセージを受け入れて、それがドメインの外からのこの間隔の間ルータへのユニキャストa Bootstrapメッセージに可能であるかもしれないところにあります、隣人の偽造しているソースアドレスを使用して。 これから守る最も良い方法は接してください。そうすれば、下げる葉のインタフェースがすべて、メッセージを独力で進むのを構成する上記のメカニズムを使用することです、ユニキャストメッセージを含んでいて。 また、PMBRsがPIMドメインでパケットがインフラストラクチャアドレスであるIPソースアドレスでPIMドメインに入るのを防ぐためにソースアドレスフィルタリングを実行するなら、これを防ぐことができます。
The use of unicast Bootstrap messages is for backwards compatibility only. Due to the possible security implications, implementations supporting unicast Bootstrap messages SHOULD provide a configuration option for whether they are to be used.
ユニキャストBootstrapメッセージの使用は遅れている互換性だけのためのものです。 可能なセキュリティ含意のため、ユニキャストBootstrapメッセージがSHOULDであるとサポートする実装がそれらが使用されていることになっているかどうかためには設定オプションを提供します。
Bhaskar, et al. Standards Track [Page 37] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[37ページ]。
6.3.2. Multi-Access Subnets
6.3.2. マルチアクセスサブネット
As mentioned above, implementations SHOULD provide a per-interface configuration option so that leaf interfaces and interfaces facing other domains can be configured to drop all Bootstrap messages. In this section, we will consider multi-access subnets where there are both multiple PIM routers in a PIM domain and PIM routers outside the PIM domain or non-trusted hosts. On such subnets, one should (if possible) configure the PMBRs to drop Bootstrap messages. This is possible provided that the routers in the PIM domain receive Bootstrap messages on other internal subnets. That is, for each of the routers on the multi-access subnet that are in our domain, the RPF interface for each of the Candidate-BSR addresses must be an internal interface (an interface not on a multi-access subnet). There are however network topologies where this is not possible. For such topologies, we recommend that IPsec Authentication Header (AH) is used to protect communication between the PIM routers in the domain, and that such routers are configured to drop and log communication attempts from any nodes that do not pass the authentication check. When all the PIM routers are under the same administrative control, this authentication may use a configured shared secret. In order to prevent replay attacks, one will need to have one security association (SA) per sender and use the sender address for SA lookup. The securing of interactions between PIM neighbors is discussed in more detail in the Security Considerations section of [1], and so we do not discuss the details further here. The same security mechanisms that can be used to secure PIM Join, Prune, and Assert messages should also be used to secure Bootstrap messages. How exactly to secure PIM link-local messages is still being worked on by the PIM working group; see [10].
以上のように、実装SHOULDは、すべてのBootstrapメッセージを下げるために葉のインタフェースと他のドメインに直面しているインタフェースは構成できるように1インタフェースあたり1つの設定オプションを提供します。 このセクションでは、PIMドメインか非信じられたホストの外にPIMドメインの複数のPIMルータとPIMルータの両方があるところで私たちは、マルチアクセスがサブネットであると考えるつもりです。 (できれば、)そのようなサブネットでは、Bootstrapメッセージを下げるためにPMBRsを構成するべきです。 PIMドメインのルータが他の内部サブネットに関するBootstrapメッセージを受け取れば、これは可能です。 すなわち、マルチアクセスサブネットの私たちのドメインにあるそれぞれのルータのために、それぞれのCandidate-BSRアドレスのためのRPFインタフェースは内部のインタフェースでなければなりません(マルチアクセスサブネットでないところのインタフェース)。 しかしながら、ネットワークtopologiesがこれが可能でないところにあります。 そのようなtopologiesに関しては、私たちは、IPsec Authentication Header(AH)がそのドメインのPIMルータのコミュニケーションを保護するのに使用されて、そのようなルータが低下するために構成されることを勧めます、そして、認証を通過しないどんなノードからのログコミュニケーション試みもチェックします。 すべてのPIMルータが同じ運営管理コントロールの下にあるとき、この認証は構成された共有秘密キーを使用するかもしれません。 反射攻撃を防ぐために、人は、送付者単位で1つのセキュリティ協会を持って(SA)、SAルックアップに送付者アドレスを使用する必要があるでしょう。 さらに詳細に[1]のSecurity Considerations部でPIM隣人の間の相互作用を機密保護することについて議論するので、私たちはここでさらに詳細について議論しません。 また、PIM Join、Prune、およびAssertにメッセージを保証するのに使用できるのと同じセキュリティー対策は、Bootstrapにメッセージを保証するのに使用されるべきです。 PIMワーキンググループはいったいどうやってリンクローカルのメッセージをPIMに保証するかまだ働かせています。 [10]を見てください。
6.4. Candidate-RP-Advertisement Message Security
6.4. 候補RP広告メッセージセキュリティ
Even if it is not possible to subvert Bootstrap messages, an attacker might be able to perform most of the same attacks by simply sending C-RP-Adv messages to the BSR specifying the attacker's choice of RPs. Thus, it is necessary to control the sending of C-RP-Adv messages in essentially the same ways that we control Bootstrap messages. However, C-RP-Adv messages are unicast and normally travel multiple hops, so controlling them is more difficult.
Bootstrapメッセージを打倒するのが可能でなくても、攻撃者は、単に攻撃者のRPsの選択を指定するBSRにC-RP-Advメッセージを送ることによって、同じ攻撃の大部分を実行できるかもしれません。 したがって、本質的には同じようにおける、C-RP-Advメッセージの発信を制御するために、私たちがBootstrapメッセージを制御するのが必要です。 しかしながら、C-RP-Advメッセージがユニキャストであり、通常複数のホップを旅行するので、それらを制御するのは、より難しいです。
6.4.1. Non-Cryptographic Security of C-RP-Adv Messages
6.4.1. C-RP-Advメッセージの非暗号のセキュリティ
We recommend that PMBRs are configured to drop C-RP-Adv messages. One might configure the PMBRs to drop all unicast PIM messages (Bootstrap message, Candidate-RP Advertisement, PIM register, and PIM register stop). PMBRs may also perform source-address filtering to prevent packets entering the PIM domain with IP source addresses that
私たちは、PMBRsがC-RP-Advメッセージを下げるために構成されることを勧めます。 1つは、すべてのユニキャストPIMメッセージを下げるためにPMBRsを構成するかもしれません(PIMが登録します、そして、Candidate-RP Advertisement、メッセージを独力で進んでください、そして、PIMは停止を登録します)。 また、PMBRsは、IPソースと共にPIMドメインに入るのがそれを扱うパケットを防ぐためにソースアドレスフィルタリングを実行するかもしれません。
Bhaskar, et al. Standards Track [Page 38] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[38ページ]。
are infrastructure addresses in the PIM domain. We also recommend that implementations have a way of restricting which IP addresses the BSR accepts C-RP-Adv messages from. The BSR can then be configured to only accept C-RP-Adv messages from infrastructure addresses or the subset used for Candidate-RPs.
インフラストラクチャアドレスがPIMドメインにありますか? また、私たちは、実装にはBSRがC-RP-Advメッセージを受け入れるどのIPアドレスを制限するか方法があることを勧めます。 そして、Candidate-RPsに使用されるインフラストラクチャアドレスか部分集合からC-RP-Advメッセージを受け入れるだけであるためにBSRを構成できます。
If the unicast and multicast topologies are known to be congruent, the following checks should be made. On interfaces that are configured to be leaf subnets, all C-RP-Adv messages should be dropped. On multi- access subnets with multiple PIM routers and hosts that are not trusted, the router can at least check that the source Media Access Control (MAC) address is that of a valid PIM neighbor.
一致しているのをユニキャストとマルチキャストtopologiesを知っているなら、以下のチェックをするべきです。 葉のサブネットになるように構成されるインタフェースでは、すべてのC-RP-Advメッセージが下げられるべきです。 複数のPIMルータと信じられないホストがいるマルチアクセスサブネットでは、ルータは、ソースメディアAccess Control(MAC)アドレスが有効なPIM隣人のものであることを少なくともチェックできます。
6.4.2. Cryptographic Security of C-RP-Adv Messages
6.4.2. C-RP-Advメッセージの暗号のセキュリティ
For true security, we recommend that all C-RPs are configured to use IPsec authentication. The authentication process for a C-RP-Adv message between a C-RP and the BSR is identical to the authentication process for PIM Register messages between a DR and the relevant RP, except that there will normally be fewer C-RPs in a domain than there are DRs, so key management is a little simpler. We do not describe the details of this process further here, but refer to the Security Considerations section of [1]. Note that the use of cryptographic security for C-RP-Adv messages does not remove the need for the non- cryptographic mechanisms, as explained above.
本当のセキュリティのために、私たちは、すべてのC-RPsがIPsec認証を使用するために構成されることを勧めます。 DRと関連RPの間のPIM Registerメッセージに、C-RPとBSRの間のC-RP-Advメッセージのための認証過程は認証過程と同じです、管理が通常、ドメインのあるより少ないC-RPs DRsがあるでしょう、非常に主要であるので少し簡単であるのを除いて。 私たちはここでさらにこのプロセスの細部について説明しませんが、[1]のSecurity Considerations部を参照してください。 暗号のセキュリティのC-RP-Advメッセージの使用が非暗号のメカニズムの必要性を取り除かないことに注意してください、上で説明されるように。
6.5. Denial of Service using IPsec
6.5. IPsecを使用するサービス妨害
An additional concern is that of denial-of-service attacks caused by sending high volumes of Bootstrap messages or C-RP-Adv messages with invalid IPsec authentication information. It is possible that these messages could overwhelm the CPU resources of the recipient.
無効のIPsec認証情報でBootstrapメッセージかC-RP-Advメッセージの高い量を送ることによって引き起こされて、追加関心はサービス不能攻撃のものです。 これらのメッセージが受取人のCPUリソースを圧倒するかもしれないのは、可能です。
The non-cryptographic security mechanisms above restrict from where unicast Bootstrap messages and C-RP-Adv messages are accepted. In addition, we recommend that rate-limiting mechanisms can be configured, to be applied on receipt of unicast PIM packets. The rate-limiter MUST independently rate-limit different types of PIM packets -- for example, a flood of C-RP-Adv messages MUST NOT cause a rate limiter to drop low- rate Bootstrap messages. Such a rate- limiter might itself be used to cause a denial-of-service attack by causing valid packets to be dropped, but in practice this is more likely to constrain bad PIM messages. The rate-limiter will prevent attacks on PIM from affecting other activity on the receiving router, such as unicast routing.
上のメカニズムがユニキャストBootstrapメッセージとC-RP-Advメッセージが受け入れられるところから制限する非暗号のセキュリティ。 さらに、私たちは、ユニキャストPIMパケットを受け取り次第適用されるためにレートを制限するメカニズムは構成できることを勧めます。 レートリミタは独自に異なったタイプのPIMパケットをレートで制限しなければなりません--例えば、C-RP-Advメッセージの洪水で、レートリミタは少ないレートBootstrapメッセージを下げてはいけません。 そのようなaはリミタ力自体を評定します。使用されて、有効なパケットが下げられることを引き起こすのにもかかわらずの、おそらく、習慣におけるサービス不能攻撃が悪いPIMメッセージを抑制することを引き起こしてください。 レートリミタは、PIMに対する攻撃がユニキャストルーティングなどの受信ルータで他の活動に影響するのを防ぐでしょう。
Bhaskar, et al. Standards Track [Page 39] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[39ページ]。
7. Contributors
7. 貢献者
Bill Fenner, Mark Handley, Roger Kermode, and David Thaler have contributed greatly to this document. They were authors of this document up to version 03, and much of the current text comes from version 03.
ビル・フェナー、マーク・ハンドレー、ロジャー・カーモード、およびデヴィッドThalerはこのドキュメントに大いに貢献しました。 彼らはバージョン03までのこのドキュメントの作者でした、そして、現在のテキストの多くがバージョン03から来ます。
8. Acknowledgments
8. 承認
PIM-SM was designed over many years by a large group of people, including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas, and Hugh Holbrook. This BSR specification draws heavily on text from RFC 2362.
PIM-SMは何年間もにわたっても人々の大きいグループによって設計されました、デボラEstrin、ディーノ・ファリナッチ、アフマドHelmy、スティーブ・デアリング、ヴァン・ジェーコブソン、C.リュウ、Puneetシャルマ、Limingウェイ、トムPusateri、トニーBallardie、スコットBrim、ジョン・クロウクロフト、ポール・フランシス、ジョエル・アルペルン、ホルスト・ホーデル、ポリー・ホアン、スティーブン・オストロウスキー、Lixiaチャン、Girish Chandranmenon、パブリン・ラドスラーボフ、ジョンZwiebel、Isidor Kouvelas、およびヒューHolbrookからの考えを含んでいて。 このBSR仕様は大いにRFC2362からのテキストを利用します。
Many members of the PIM Working Group have contributed comments and corrections for this document, including Christopher Thomas Brown, Ardas Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran, Rishabh Parekh, and Katta Sambasivarao.
PIM作業部会の多くのメンバーがこのドキュメントのためのコメントと修正を寄付しました、クリストファー・トーマス・ブラウン、Ardas Cilingiroglu、Murthy Esakonu、Venugopal Hemige、Prashant Jhingran、Rishabh Parekh、およびKatta Sambasivaraoを含んでいて。
9. Normative References
9. 引用規格
[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
[1] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[2] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC
5015, October 2007.
[2] ハンドレー、M.、Kouvelas、I.、Speakman、T.、およびL.Vicisano、「双方向のプロトコル独立しているマルチキャスト(BIDIR-PIM)」、RFC5015、2007年10月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[3] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[4] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B.
Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[4] デアリングとS.とハーバーマンとB.とJinmeiとT.とNordmark、E.とB.Zill、「IPv6はアドレス体系を見た」RFC4007、2005年3月。
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[5]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Bhaskar, et al. Standards Track [Page 40] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[40ページ]。
10. Informative References
10. 有益な参照
[7] Estrin, D., et al., "Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998.
[7]Estrin、D.、他、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[8] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)",
RFC 3446, January 2003.
[8] キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、「プロトコルの無党派Multicast(PIM)とMulticast Sourceディスカバリープロトコル(MSDP)を使用するAnycast Rendevous Point(RP)メカニズム」、RFC3446(2003年1月)。
[9] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent
Multicast (PIM)", RFC 4610, August 2006.
[9] ファリナッチとD.とY.Cai、「プロトコルの独立しているマルチキャスト(PIM)を使用するAnycast-RP」、RFC4610、2006年8月。
[10] Atwood, W. and S. Islam, "Security Issues in PIM-SM Link-local
Messages", Work in Progress, July 2007.
[10] 「PIM-Smのリンクローカルのメッセージの安全保障問題」というアトウッド、W.、およびS.イスラム教は進歩、2007年7月に働いています。
[11] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.
[11]IANA、「アドレスファミリーナンバ」、<http://www.iana.org/課題/アドレスファミリーナンバ>。
Authors' Addresses
作者のアドレス
Nidhi Bhaskar Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA EMail: nidhi@arastra.com
Nidhi Bhaskar Arastra Inc.P.O. Box10905カリフォルニア94303パロアルト(米国)はメールされます: nidhi@arastra.com
Alexander Gall SWITCH P.O. Box CH-8021 Zurich Switzerland EMail: alexander.gall@switch.ch
アレクサンダー胆汁スイッチ私書箱CH-8021チューリッヒスイスメール: alexander.gall@switch.ch
James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA EMail: jchl@arastra.com
ジェームスリンガードArastra Inc.P.O. Box10905パロアルト(カリフォルニア)94303米国メール: jchl@arastra.com
Stig Venaas UNINETT NO-7465 Trondheim Norway EMail: venaas@uninett.no
7465年がないスティVenaas UNINETTトロンヘイムノルウェーEMail: venaas@uninett.no
Bhaskar, et al. Standards Track [Page 41] RFC 5059 BSR Mechanism for PIM January 2008
Bhaskar、他 規格は2008年1月にPIMのためにRFC5059BSRメカニズムを追跡します[41ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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に情報を記述してください。
Bhaskar, et al. Standards Track [Page 42]
Bhaskar、他 標準化過程[42ページ]
一覧
スポンサーリンク
