[要約] RFC 6807は、Protocol Independent Multicast（PIM）に人口カウント拡張を提供するためのものであり、マルチキャストグループのメンバーシップ数を追跡するための新しい機能を導入します。目的は、ネットワーク管理者がマルチキャストトラフィックのパフォーマンスを向上させるために、グループの人口カウント情報を利用できるようにすることです。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6807 G. Shepherd
Category: Experimental S. Venaas
ISSN: 2070-1721 Cisco Systems
Y. Cai
Microsoft
December 2012
Population Count Extensions to Protocol Independent Multicast (PIM)
Protocol Independent Multicast（PIM）の人口カウント拡張
Abstract
概要
This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion.
この仕様は、マルチキャスト配信ツリーアカウンティングデータを提供する方法を定義しています。 Protocol Independent Multicast（PIM）プロトコルへの単純な拡張により、スケーラブルな方法でツリーベースのデータのおおよその概算が可能になります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6807.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6807で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Pop-Count-Supported Hello Option . . . . . . . . . . . . . . . 4
3. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 5
3.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Link Speed Encoding . . . . . . . . . . . . . . . . . 10
3.2. Example Message Layouts . . . . . . . . . . . . . . . . . 10
4. How to Use Pop-Count Encoding . . . . . . . . . . . . . . . . 11
5. Implementation Approaches . . . . . . . . . . . . . . . . . . 12
6. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
This document specifies a mechanism to convey accounting information using the Protocol Independent Multicast (PIM) protocol [RFC4601] [RFC5015]. Putting the mechanism in PIM allows efficient distribution and maintenance of such accounting information. Previous mechanisms require data to be correlated from multiple router sources.
このドキュメントは、Protocol Independent Multicast（PIM）プロトコル[RFC4601] [RFC5015]を使用してアカウンティング情報を伝達するメカニズムを指定します。メカニズムをPIMに配置すると、そのようなアカウンティング情報の効率的な配布と保守が可能になります。以前のメカニズムでは、データを複数のルーターソースから関連付ける必要があります。
This mechanism allows a single router to be queried to obtain accounting and statistic information for a multicast distribution tree as a whole or any distribution sub-tree downstream from a queried router. The amount of information is fixed and does not increase as multicast membership, tree diameter, or branching increases.
このメカニズムにより、単一のルーターを照会して、マルチキャスト配布ツリー全体または照会されたルーターからダウンストリームの配布サブツリー全体のアカウンティングおよび統計情報を取得できます。情報の量は固定されており、マルチキャストメンバーシップ、ツリーの直径、または分岐が増加しても増加しません。
The sort of accounting data this specification provides, on a per-multicast-route basis, are:
この仕様がマルチキャストルートごとに提供するアカウンティングデータの種類は次のとおりです。
1. The number of branches in a distribution tree.
1. 配布ツリー内のブランチの数。
2. The membership type of the distribution tree, that is, Source-Specific Multicast (SSM) or Any-Source Multicast (ASM).
2. 配布ツリーのメンバーシップタイプ、つまり、Source-Specific Multicast（SSM）またはAny-Source Multicast（ASM）。
3. Routing domain and time zone boundary information.
3. ルーティングドメインとタイムゾーンの境界情報。
4. On-tree node and tree diameter counters.
4. ツリー上のノードとツリーの直径のカウンター。
5. Effective MTU and bandwidth.
5. 有効なMTUと帯域幅。
This document defines a new PIM Join Attribute type [RFC5384] for the Join/Prune message as well as a new Hello option. The mechanism is applicable to IPv4 and IPv6 multicast.
このドキュメントでは、Join / Pruneメッセージの新しいPIM Join Attributeタイプ[RFC5384]と、新しいHelloオプションが定義されています。このメカニズムは、IPv4およびIPv6マルチキャストに適用できます。
This is a new extension to PIM, and it is not completely understood what impact collecting information using PIM would have on the operation of PIM. This is an entirely new concept. Many PIM features (including the core protocols) were first introduced in Experimental RFCs, and it seems appropriate to advance this work as Experimental. Reports of implementation and deployment across whole distribution trees or within sub-trees (see Section 6) will enable an assessment of the desirability and stability of this specification. The PIM Working Group will then consider whether to move this work to the Standards Track.
これはPIMの新しい拡張機能であり、PIMを使用した情報の収集がPIMの運用に与える影響は完全には理解されていません。これはまったく新しいコンセプトです。多くのPIM機能（コアプロトコルを含む）は、実験的RFCで最初に導入されました。この作業を実験的として進めることが適切と思われます。配布ツリー全体またはサブツリー内での実装と展開のレポート（セクション6を参照）は、この仕様の望ましさと安定性の評価を可能にします。 PIMワーキンググループは、この作業を標準化トラックに移行するかどうかを検討します。
This document does not specify how an administrator or user can access this information. It is expected that an implementation may have a command-line interface or other ways of requesting and displaying this information. As this is currently an Experimental document, defining a MIB module has not been considered. If the PIM Working Group finds that this should move on to Standards Track, a MIB module should be considered.
このドキュメントでは、管理者またはユーザーがこの情報にアクセスする方法を指定していません。実装には、コマンドラインインターフェースや、この情報を要求および表示するその他の方法が含まれる場合があります。これは現在実験的なドキュメントであるため、MIBモジュールの定義は考慮されていません。 PIMワーキンググループがこれを標準化トラックに移行する必要があると判断した場合、MIBモジュールを検討する必要があります。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section defines the terms used in this document.
このセクションでは、このドキュメントで使用される用語を定義します。
Multicast Route: An (S,G) or (*,G) entry regardless of whether the route is in ASM, SSM, or BIDIR mode of operation.
マルチキャストルート：ルートがASM、SSM、またはBIDIRモードで動作しているかどうかに関係なく、（S、G）または（*、G）エントリ。
Stub Link: A link with members joined to the group via IGMP or Multicast Listener Discovery (MLD).
スタブリンク：IGMPまたはマルチキャストリスナーディスカバリ（MLD）を介してグループに参加したメンバーとのリンク。
Transit Link: A link put in the oif-list (outgoing interface list) for a multicast route because it was joined by PIM routers.
トランジットリンク：PIMルーターによって結合されたため、マルチキャストルートのoif-list（送信インターフェイスリスト）に追加されたリンク。
Note that a link can be both a Stub Link and a Transit Link at the same time.
リンクは、同時にスタブリンクとトランジットリンクの両方になる可能性があることに注意してください。
A PIM router indicates that it supports the mechanism specified in this document by including the Pop-Count-Supported Hello option in its PIM Hello message. Note that it also needs to include the Join-Attribute Hello option as specified in [RFC5384]. The format of the Pop-Count-Supported Hello option is defined to be:
PIMルーターは、PIM HelloメッセージにPop-Count-Supported Helloオプションを含めることにより、このドキュメントで指定されたメカニズムをサポートすることを示します。 [RFC5384]で指定されているように、Join-Attribute Helloオプションも含める必要があることに注意してください。 Pop-Count-Supported Helloオプションのフォーマットは、次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionType = 29, OptionLength = 0. Note that there is no option value included. In order to allow future updates of this specification that may include an option value, implementations of this document MUST accept and process this option even if the length is non-zero. Implementations of this specification MUST accept and process the option ignoring any option value that may be included.
OptionType = 29、OptionLength =0。オプション値は含まれていないことに注意してください。オプション値を含む可能性があるこの仕様の将来の更新を可能にするために、このドキュメントの実装は、長さがゼロでない場合でも、このオプションを受け入れて処理する必要があります。この仕様の実装は、含まれる可能性のあるオプション値を無視して、オプションを受け入れて処理する必要があります。
When a PIM router supports this mechanism and has determined from a received Hello that the neighbor supports this mechanism, and also that all the neighbors on the interface support the use of join attributes, it will send Join/Prune messages that MAY include a Pop-Count Join Attribute. The mechanism to process a PIM Join Attribute is described in [RFC5384]. The format of the new attribute is specified in the following.
PIMルーターがこのメカニズムをサポートし、受信したHelloから、ネイバーがこのメカニズムをサポートしていること、およびインターフェイスのすべてのネイバーが結合属性の使用をサポートしていることを確認した場合、POPルーターは、Pop-を含む可能性のあるJoin / Pruneメッセージを送信します結合属性をカウントします。 PIM加入属性を処理するメカニズムは、[RFC5384]で説明されています。新しい属性の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Options Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The above format is used only for entries in the join-list section of the Join/Prune message.
上記のフォーマットは、Join / Pruneメッセージのjoin-listセクションのエントリにのみ使用されます。
F bit: 0 (Non-Transitive Attribute).
Fビット：0（非推移的属性）。
E bit: As specified by [RFC5384].
Eビット：[RFC5384]で指定されているとおり。
Attr_Type: 3.
Attr_Type：3。
Length: The minimum length is 6.
長さ：最小長は6です。
Effective MTU: This contains the minimum MTU for any link in the oif-list. The sender of a Join/Prune message takes the minimum value for the MTU (in bytes) from each link in the oif-list. If this value is less than the value stored for the multicast route (the one received from downstream joiners), then the value should be reset and sent in a Join/Prune message. Otherwise, the value should remain unchanged.
有効なMTU：これには、oif-list内のリンクの最小MTUが含まれています。 Join / Pruneメッセージの送信側は、oif-listの各リンクからMTUの最小値（バイト単位）を取得します。この値がマルチキャストルート（ダウンストリームジョイナーから受信したもの）に格納されている値よりも小さい場合、値をリセットして、Join / Pruneメッセージで送信する必要があります。それ以外の場合、値は変更されません。
This provides the MTU supported by multicast distribution tree when examined at the first-hop router(s) or for sub-tree for any router on the distribution tree.
これにより、最初のホップのルーターで、または配布ツリー上のルーターのサブツリーを調べたときに、マルチキャスト配布ツリーでサポートされるMTUが提供されます。
Flags: The flags field has the following format:
フラグ：フラグフィールドの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unallocated/Reserved Flags: The flags that are currently not defined. If a new flag is defined and used by a new implementation, an old implementation should preserve the bit settings. This means that a router MUST preserve the settings of all Unallocated/Reserved Flags in PIM Join messages received from downstream routers in any PIM Join sent upstream.
未割り当て/予約済みフラグ：現在定義されていないフラグ。新しいフラグが定義され、新しい実装で使用される場合、古い実装はビット設定を保持する必要があります。つまり、ルーターは、上流に送信されたPIM Joinの下流ルーターから受信したPIM Joinメッセージのすべての未割り当て/予約済みフラグの設定を保持する必要があります。
S flag: This flag is set if an IGMPv3 or MLDv2 report with an INCLUDE mode group record was received on any oif-list entry or the bit was set from any PIM Join message. This bit should only be cleared when the above becomes untrue.
Sフラグ：このフラグは、INCLUDEモードのグループレコードを含むIGMPv3またはMLDv2レポートがoif-listエントリで受信された場合、またはビットがPIM Joinメッセージから設定された場合に設定されます。このビットは、上記が正しくない場合にのみクリアする必要があります。
A flag: This flag is set if an IGMPv3 or MLDv2 report with an EXCLUDE mode group record, or an IGMPv1, IGMPv2, or MLDv1 report, was received on any oif-list entry or the bit was set from any PIM Join message. This bit should only be cleared when the above becomes untrue.
フラグ：このフラグは、EXCLUDEモードのグループレコードを持つIGMPv3またはMLDv2レポート、あるいはIGMPv1、IGMPv2、またはMLDv1レポートが、oif-listエントリで受信された場合、またはビットがPIM Joinメッセージから設定された場合に設定されます。このビットは、上記が正しくない場合にのみクリアする必要があります。
A combination of settings for these bits indicate:
これらのビットの設定の組み合わせは、以下を示します。
A flag S flag Description
------ ------ --------------------------------------
0 0 There are no members for the group.
('Stub Oif-List Count' is 0)
0 1 All group members are using SSM.
1 0 All group members are using ASM.
1 1 A mixture of SSM and ASM group members.
t flag: This flag is set if there are any manually configured tunnels on the distribution tree. This means any tunnel that is not an auto-tunnel. If a manually configured tunnel is in the oif-list, a router sets this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners.
tフラグ：このフラグは、配布ツリーに手動で構成されたトンネルがある場合に設定されます。これは、自動トンネルではないトンネルを意味します。手動で構成されたトンネルがoif-listにある場合、ルーターはこのビットをJoin / Pruneメッセージに設定します。それ以外の場合は、下流のジョイナーからビット設定を伝達します。
a flag: This flag is set if there are any auto-tunnels on the distribution tree. If an auto-tunnel is in the oif-list, a router sets this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. An example of an auto-tunnel is a tunnel set up by the Automatic Multicast Tunneling [AMT] protocol.
フラグ：このフラグは、配布ツリーに自動トンネルがある場合に設定されます。自動トンネルがoif-listにある場合、ルーターは、Join / Pruneメッセージでこのビットを設定します。それ以外の場合は、下流のジョイナーからビット設定を伝達します。自動トンネルの例は、自動マルチキャストトンネリング[AMT]プロトコルによってセットアップされるトンネルです。
P flag: This flag is set by a router if all downstream routers support this specification. That is, they are all PIM Pop-Count capable. If a downstream router does not support this specification, it MUST be cleared. This allows one to tell if the entire sub-tree is completely accounting capable.
Pフラグ：すべてのダウンストリームルーターがこの仕様をサポートしている場合、このフラグはルーターによって設定されます。つまり、それらはすべてPIM Pop-Countに対応しています。ダウンストリームルーターがこの仕様をサポートしていない場合は、クリアする必要があります。これにより、サブツリー全体が完全にアカウンティングに対応しているかどうかを確認できます。
Options Bitmap: This is a bitmap that shows which options are present. The format of the bitmap is as follows:
オプションビットマップ：これは、存在するオプションを示すビットマップです。ビットマップの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|s|m|M|d|n|D|z| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each one of the bits T, s, m, M, d, n, D and z is associated with one option, where the option is included if and only if the respective bit is set. Included options MUST be in the same order as these bits are listed. The bits denote the following options:
ビットT、s、m、M、d、n、D、zの各1つは1つのオプションに関連付けられています。オプションは、対応するビットが設定されている場合にのみ含まれます。含まれるオプションは、これらのビットがリストされているのと同じ順序でなければなりません。ビットは次のオプションを示します。
bit Option
----- ------------------------
T Transit Oif-List Count
s Stub Oif-List Count
m Minimum Speed Link
M Maximum Speed Link
d Domain Count
n Node Count
D Diameter Count
z TZ Count
See Section 3.1 for details on the different options. The unallocated bits are reserved. Any unknown bits MUST be set to 0 when a message is sent, and treated as 0 (ignored) when received. This means that unknown options that are denoted by unknown bits are ignored.
さまざまなオプションの詳細については、セクション3.1を参照してください。未割り当てビットは予約されています。メッセージが送信されるとき、不明なビットは0に設定されなければならず、受信されたとき、0（無視される）として扱われなければなりません。これは、不明なビットで示される不明なオプションが無視されることを意味します。
By using this bitmap we can specify at most 16 options. If there becomes a need for more than 16 options, one can define a new option that contains a bitmap that can then be used to specify which further options are present. The last bit in the current bitmap could be used for that option. However, the exact definition of this is left for future documents.
このビットマップを使用することにより、最大16のオプションを指定できます。 16個を超えるオプションが必要になった場合は、ビットマップを含む新しいオプションを定義して、それを使用して、さらに存在するオプションを指定できます。現在のビットマップの最後のビットは、そのオプションに使用できます。ただし、これの正確な定義は将来のドキュメントに残されます。
Options: This field contains options. Which options are present is determined by the flag bits. As new flags and options may be defined in the future, any unknown/reserved flags MUST be ignored, and any additional trailing options MUST be ignored. See Section 3.1 for details on the options defined in this document.
オプション：このフィールドにはオプションが含まれます。存在するオプションは、フラグビットによって決定されます。新しいフラグとオプションは将来的に定義される可能性があるため、不明/予約済みフラグはすべて無視しなければならず、追加の後続オプションはすべて無視しなければなりません。このドキュメントで定義されているオプションの詳細については、セクション3.1を参照してください。
There are several options defined in this document. For each option, there is also a related flag that shows whether the option is present. See the Options Bitmap above for a list of the options and their respective bits. Each option has a fixed size. Note that there are no alignment requirements for the options, so an implementation cannot assume they are aligned.
このドキュメントでは、いくつかのオプションが定義されています。オプションごとに、オプションが存在するかどうかを示す関連フラグもあります。オプションとそれぞれのビットのリストについては、上記のオプションビットマップを参照してください。各オプションには固定サイズがあります。オプションの配置要件はないため、実装ではそれらが配置されていると想定できません。
Transit Oif-List Count: This is filled in by a router sending a Join/Prune message indicating the number of transit links on the multicast distribution tree. The value is the number of oifs (outgoing interfaces) for the multicast route that have been joined by PIM plus the sum of the values advertised by each of the downstream PIM routers that have joined on this oif. Length is 4 octets.
Transit Oif-List Count：これは、マルチキャスト配信ツリー上のトランジットリンクの数を示すJoin / Pruneメッセージを送信するルーターによって入力されます。この値は、PIMによって結合されたマルチキャストルートのoif（送信インターフェイス）の数と、このoifに結合された各ダウンストリームPIMルーターによってアドバタイズされた値の合計です。長さは4オクテットです。
Stub Oif-List Count: This is filled in by a router sending a Join/ Prune message indicating the number of stub links (links where there are host members) on the multicast distribution tree. The value is the number of oifs for the multicast route that have been joined by IGMP or MLD plus the sum of the values advertised by each of the downstream PIM routers that have joined on this oif. Length is 4 octets.
スタブOif-リスト数：これは、マルチキャスト配布ツリー上のスタブリンク（ホストメンバーが存在するリンク）の数を示すJoin / Pruneメッセージを送信するルーターによって入力されます。この値は、IGMPまたはMLDによって結合されたマルチキャストルートのoifの数に、このoifに結合された各ダウンストリームPIMルーターによって通知された値の合計を足したものです。長さは4オクテットです。
Minimum Speed Link: This contains the minimum bandwidth rate for any link in the oif-list and is encoded as specified in Section 3.1.1. The sender of a Join/Prune message takes the minimum value for each link in the oif-list for the multicast route. If this value is less than the value stored for the multicast route (the smallest value received from downstream joiners), then the value should be reset and sent in a Join/Prune message. Otherwise, the value should remain unchanged. This, together with the Maximum Speed Link option, provides a way to obtain the lowest- and highest-speed links for the multicast distribution tree. Length is 2 octets.
最小速度リンク：これには、oif-list内のリンクの最小帯域幅レートが含まれており、セクション3.1.1で指定されているようにエンコードされます。 Join / Pruneメッセージの送信者は、マルチキャストルートのoif-list内の各リンクの最小値をとります。この値がマルチキャストルート用に保存されている値（ダウンストリームジョイナーから受信した最小値）より小さい場合は、値をリセットして、Join / Pruneメッセージで送信する必要があります。それ以外の場合、値は変更されません。これは、Maximum Speed Linkオプションとともに、マルチキャスト配信ツリーの最低および最高速度のリンクを取得する方法を提供します。長さは2オクテットです。
Maximum Speed Link: This contains the maximum bandwidth rate for any link in the oif-list and is encoded as specified in Section 3.1.1. The sender of a Join/Prune message takes the maximum value for each link in the oif-list for the multicast route. If this value is greater than the value stored for the multicast route (the largest value received from downstream joiners), then the value should be reset and sent in a Join/Prune message. Otherwise, the value should remain unchanged. This, together with the Minimum Speed Link option, provides a way to obtain the lowest- and highest-speed links for the multicast distribution tree. Length is 2 octets.
最大速度リンク：これには、oif-list内のリンクの最大帯域幅レートが含まれており、セクション3.1.1で指定されているようにエンコードされます。 Join / Pruneメッセージの送信者は、マルチキャストルートのoif-list内の各リンクの最大値を取ります。この値がマルチキャストルート用に保存されている値（ダウンストリームジョイナーから受信した最大値）より大きい場合は、値をリセットして、Join / Pruneメッセージで送信する必要があります。それ以外の場合、値は変更されません。これは、Minimum Speed Linkオプションとともに、マルチキャスト配信ツリーの最低および最高速度のリンクを取得する方法を提供します。長さは2オクテットです。
Domain Count: This indicates the number of routing domains the distribution tree traverses. A router should increment this value if it is sending a Join/Prune message over a link that traverses a domain boundary. For this to work, an implementation needs a way of knowing that a neighbor or an interface is in a different domain. There is no standard way of doing this. Length is 1 octet.
ドメイン数：これは、配布ツリーが通過するルーティングドメインの数を示します。ドメイン境界を横断するリンクを介してJoin / Pruneメッセージを送信する場合、ルーターはこの値を増やす必要があります。これが機能するためには、実装では、ネイバーまたはインターフェースが別のドメインにあることを知る方法が必要です。これを行う標準的な方法はありません。長さは1オクテットです。
Node Count: This indicates the number of routers on the distribution tree. Each router will sum up all the Node Counts from all joiners on all oifs and increment by 1 before including this value in the Join/Prune message. Length is 1 octet.
ノード数：これは、配布ツリー上のルーターの数を示します。各ルーターは、すべてのoifのすべてのジョイナーからのすべてのノードカウントを合計し、Join / Pruneメッセージにこの値を含める前に1ずつ増分します。長さは1オクテットです。
Diameter Count: This indicates the longest length of any given branch of the tree in router hops. Each router that sends a Join increments the max value received by all downstream joiners by 1. Length is 1 octet.
直径カウント：これは、ルーターホップにおけるツリーの特定のブランチの最長の長さを示します。 Joinを送信する各ルーターは、すべてのダウンストリームジョイナーが受信する最大値を1ずつ増やします。長さは1オクテットです。
TZ Count: This indicates the number of time zones the distribution tree traverses. A router should increment this value if it is sending a Join/Prune message over a link that traverses a time zone. This can be a configured link attribute, or using other means to determine the time zone is acceptable. Length is 1 octet.
TZカウント：配布ツリーが通過するタイムゾーンの数を示します。タイムゾーンを通過するリンクを介してJoin / Pruneメッセージを送信する場合、ルーターはこの値を増やす必要があります。これは、構成済みのリンク属性にすることも、他の手段を使用してタイムゾーンを許容できるかどうかを判断することもできます。長さは1オクテットです。
The speed is encoded using 2 octets as follows:
速度は次のように2オクテットを使用してエンコードされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponent | Significand |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Using this format, the speed of the link is Significand * 10 ^ Exponent kbps. This allows specifying link speeds with up to 3 decimal digits precision and speeds from 1 kbps to 10 ^ 67 kbps. A computed speed of 0 kbps means the link speed is < 1 kbps.
この形式を使用すると、リンクの速度は有意* 10 ^指数kbpsになります。これにより、最大3桁の精度と1 kbpsから10 ^ 67 kbpsまでの速度でリンク速度を指定できます。計算された速度0 kbpsは、リンク速度が1 kbps未満であることを意味します。
Here are some examples of how this is used:
これがどのように使用されるかの例をいくつか示します。
Link Speed Exponent Significand
------------ ---------- -------------
500 kbps 0 500
500 kbps 2 5
155 Mbps 3 155
40 Gpbs 6 40
100 Gpbs 6 100
100 Gpbs 8 1
Here, we will give a few examples to illustrate the use of flags and options.
ここでは、フラグとオプションの使用法を示すいくつかの例を示します。
A minimum-size message has no option flags set and looks like this:
最小サイズのメッセージにはオプションフラグが設定されておらず、次のようになります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 6 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|0|0|0|0|0|0|0|0| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A message containing all the options defined in this document would look like this:
このドキュメントで定義されているすべてのオプションを含むメッセージは次のようになります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 18 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|1|1|1|1|1|1|1|1| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transit Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Speed Link | Maximum Speed Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Count | Node Count | Diameter Count| TZ Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A message containing only Stub Oif-List Count and Node Count would look like this:
Stub Oif-List CountとNode Countのみを含むメッセージは、次のようになります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 9 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|0|1|0|0|0|1|0|0| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node count |
+-+-+-+-+-+-+-+-+
A router supporting this mechanism MUST, unless administratively disabled, include the PIM Join Attribute option in its PIM Hellos. See [RFC5384] and "PIM-Hello Options" on [PIM-REG] for details.
このメカニズムをサポートするルーターは、管理上無効にされていない限り、PIM HelloにPIM Join Attributeオプションを含める必要があります。詳細については、[RFC5384]および[PIM-REG]の「PIM-Helloオプション」を参照してください。
It is RECOMMENDED that implementations allow for administrative control of whether to make use of this mechanism. Implementations MAY also allow further control of what information to store and send upstream.
実装により、このメカニズムを利用するかどうかの管理制御が可能になることをお勧めします。実装は、どの情報を保存し、上流に送信するかをさらに制御できるようにすることもできます（MAY）。
It is very important to note that any changes to the values maintained by this mechanism MUST NOT trigger a new Join/Prune message. Due to the periodic nature of PIM, the values can be accurately obtained at 1-minute intervals (or whatever Join/Prune interval used).
このメカニズムで維持されている値を変更しても、新しいJoin / Pruneメッセージをトリガーしてはならないことに注意してください。 PIMの定期的な性質により、値は1分間隔（または使用される結合/除去間隔）で正確に取得できます。
When a router removes a link from an oif-list, it needs to be able to reevaluate the values that it will advertise upstream. This happens when an oif-list entry is timed out or a Prune is received.
ルータがoif-listからリンクを削除するとき、アップストリームにアドバタイズする値を再評価できる必要があります。これは、oif-listエントリがタイムアウトになるか、プルーンを受信したときに発生します。
It is RECOMMENDED that the Join Attribute defined in this document be used only for entries in the join-list part of the Join/Prune message. If the attribute is used in the prune-list, an implementation MUST ignore it and process the Prune as if the attribute were not present.
このドキュメントで定義されている結合属性は、Join / Pruneメッセージの結合リスト部分のエントリにのみ使用することをお勧めします。属性がprune-listで使用される場合、実装はそれを無視し、属性が存在しないかのようにプルーンを処理する必要があります。
It is also RECOMMENDED that join suppression be disabled on a LAN when Pop-Count is used.
また、Pop-Countを使用する場合は、LANで結合抑制を無効にすることをお勧めします。
It is RECOMMENDED that, when triggered Join/Prune messages are sent by a downstream router, the accounting information not be included in the message. This way, when convergence is important, avoiding the processing time to build an accounting record in a downstream router and processing time to parse the message in the upstream router will help reduce convergence time. If an upstream router receives a Join/ Prune message with no accounting data, it SHOULD NOT interpret the message as a trigger to clear or reset the accounting data it has cached.
トリガーされたJoin / Pruneメッセージがダウンストリームルーターから送信された場合、メッセージにアカウンティング情報を含めないことをお勧めします。このように、コンバージェンスが重要な場合、ダウンストリームルータでアカウンティングレコードを作成する処理時間と、アップストリームルータでメッセージを解析する処理時間を回避することで、コンバージェンス時間を短縮できます。アップストリームルータがアカウンティングデータのないJoin / Pruneメッセージを受信した場合、キャッシュしたアカウンティングデータをクリアまたはリセットするトリガーとしてメッセージを解釈すべきではありません（SHOULD NOT）。
This section offers some non-normative suggestions for how Pop-Count may be implemented.
このセクションでは、Pop-Countの実装方法に関する非規範的な提案をいくつか示します。
An implementation can decide how the accounting attributes are maintained. The values can be stored as part of the multicast route data structure by combining the local information it has with the joined information on a per-oif basis. So, when it is time to send a Join/Prune message, the values stored in the multicast route can be copied to the message.
実装では、アカウンティング属性を維持する方法を決定できます。値は、ローカルの情報と結合された情報をoifごとに組み合わせることにより、マルチキャストルートデータ構造の一部として格納できます。したがって、Join / Pruneメッセージを送信するときに、マルチキャストルートに格納されている値をメッセージにコピーできます。
Or, an implementation could store the accounting values per oif and, when a Join/Prune message is sent, it can combine the oifs with its local information. Then, the combined information can be copied to the message.
または、実装はoifごとのアカウンティング値を格納でき、Join / Pruneメッセージが送信されると、oifをローカル情報と組み合わせることができます。次に、結合された情報をメッセージにコピーできます。
When a downstream joiner stops joining, accounting values cached must be evaluated. There are two approaches that can be taken. One is to keep values learned from each joiner, so when the joiner goes away, the count/max/min values are known and the combined value can be adjusted. The other approach is to set the value to 0 for the oif, and then start accumulating new values as subsequent Joins are received.
ダウンストリームジョイナーが参加を停止した場合、キャッシュされたアカウンティング値を評価する必要があります。取ることのできる2つのアプローチがあります。 1つは、各ジョイナーから学習した値を保持することです。そのため、ジョイナーがなくなると、カウント/最大/最小の値がわかり、組み合わせた値を調整できます。もう1つの方法は、oifの値を0に設定し、後続の結合が受信されたときに新しい値の累積を開始することです。
The same issue arises when an oif is removed from the oif-list. Keeping per-oif values allows you to adjust the per-route values when an oif goes away. Or, alternatively, a delay for reporting the new set a values from the route can occur while all oif values are zeroed (where accumulation of new values from subsequent Joins cause repopulation of values and a new max/min/count can be reevaluated for the route).
oifがoif-listから削除されたときにも同じ問題が発生します。 OIFごとの値を維持すると、OIFがなくなったときにルートごとの値を調整できます。または、すべてのoif値がゼロになっている間、ルートからの新しいセットの値を報告するための遅延が発生する可能性があります（後続の結合からの新しい値の累積により値が再入力され、新しい最大値/最小値/カウントを再評価できます）ルート）。
This specification requires each router on a multicast distribution tree to support this specification or else the accounting attributes for the tree will not be known.
この仕様では、マルチキャスト配信ツリーの各ルーターがこの仕様をサポートする必要があります。そうしないと、ツリーのアカウンティング属性がわかりません。
However, if there is a contiguous set of routers downstream in the distribution tree, they can maintain accounting information for the sub-tree.
ただし、ディストリビューションツリーの下流に隣接する一連のルーターがある場合、ルーターはサブツリーのアカウンティング情報を維持できます。
If there is a set of contiguous routers supporting this specification upstream on the multicast distribution tree, accounting information will be available, but it will not represent an accurate assessment of the entire tree. Also, it will not be clear how much of the distribution tree the accounting information covers.
マルチキャスト配布ツリーの上流でこの仕様をサポートする一連のルーターが存在する場合、アカウンティング情報は利用できますが、ツリー全体の正確な評価を表すものではありません。また、アカウンティング情報がどの程度の配布ツリーをカバーしているかは明らかではありません。
A new PIM-Hello Option type, 29, has been assigned by IANA. Although the length is specified as 0 in this specification, non-zero length is allowed, so IANA has listed the length as being variable.
新しいPIM-Helloオプションタイプ29がIANAによって割り当てられました。この仕様では長さを0と指定していますが、ゼロ以外の長さも許可されているため、IANAは長さを可変長としてリストしています。
A new PIM Join Attribute type, 3, has been assigned by IANA.
新しいPIM結合属性タイプ3がIANAによって割り当てられました。
The use of this specification requires some additional processing of PIM Join/Prune messages. However, the additional amount of processing is fairly limited, so this is not believed to be a significant concern.
この仕様を使用するには、PIM Join / Pruneメッセージの追加処理が必要です。ただし、追加の処理量はかなり限られているため、これは大きな問題とは考えられていません。
The use of this mechanism includes information like the number of receivers. This information is assumed to not be of a sensitive nature. If an operator has concerns about revealing this information to upstream routers or other routers/hosts that may potentially inspect this information, there should be a way to disable the mechanism or, alternatively, more detailed control of what information to include.
このメカニズムの使用には、レシーバーの数などの情報が含まれます。この情報はデリケートな性質のものではないと想定されています。オペレーターが、この情報を検査する可能性がある上流のルーターまたは他のルーター/ホストにこの情報を公開することについて懸念がある場合は、メカニズムを無効にする方法、または含める情報のより詳細な制御が必要です。
The authors would like to thank John Zwiebel, Amit Jain, and Clayton Wagar for their review comments on the initial versions of this document. Adrian Farrel did a detailed review of the document and proposed textual changes that have been incorporated. Further review and comments were provided by Thomas Morin and Zhaohui (Jeffrey) Zhang.
著者は、このドキュメントの最初のバージョンに関するレビューコメントを提供してくれたJohn Zwiebel、Amit Jain、およびClayton Wagarに感謝します。エイドリアン・ファレルは文書の詳細なレビューを行い、組み込まれたテキストの変更を提案しました。さらなるレビューとコメントは、Thomas MorinとZhaohui（Jeffrey）Zhangによって提供されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[RFC5384] Boers、A.、Wijnands、I。、およびE. Rosen、「Protocol Independent Multicast（PIM）Join Attribute Format」、RFC 5384、2008年11月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012.
[AMT] Bumgardner、G。、「Automatic Multicast Tunneling」、Work in Progress、2012年6月。
[PIM-REG] IANA, "Protocol Independent Multicast (PIM) Parameters", <http://www.iana.org/assignments/pim-parameters>.
[PIM-REG] IANA、「Protocol Independent Multicast（PIM）Parameters」、<http://www.iana.org/assignments/pim-parameters>。
Authors' Addresses
著者のアドレス
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA
Dino Farinacci Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: dino@cisco.com
Greg Shepherd Cisco Systems Tasman Drive San Jose, CA 95134 USA
Greg Shepherd Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: gjshep@gmail.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
Stig Venaas Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: stig@cisco.com
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
Y IグループCAI Microsoft 1065 LA av EN IDAマウンテンビュー、CA 94043米国
EMail: yiqunc@microsoft.com