[要約] RFC 5384は、PIM（Protocol Independent Multicast）Join属性のフォーマットに関する規格であり、マルチキャストグループへの参加要求を表すための属性を定義しています。このRFCの目的は、異なるネットワークプロトコルでのマルチキャストグループへの参加要求を統一的に扱うための標準化です。
Network Working Group A. Boers
Request for Comments: 5384 I. Wijnands
Category: Standards Track E. Rosen
Cisco Systems, Inc.
November 2008
The Protocol Independent Multicast (PIM) Join Attribute Format
Protocol Independent Multicast（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format.
「プロトコル独立したマルチキャスト - スパースモード」結合特定のノードから送信されたメッセージは、そのノードが参加したい1つ以上のマルチキャスト配布ツリーを識別します。各ツリーは、マルチキャストグループアドレスとソースアドレス（ソースアドレスが「ワイルドカード」である可能性がある）の組み合わせによって識別されます。特定の条件下では、ツリーに参加するときに、ツリーの構築に関連する追加情報を指定するのに役立ちます。しかし、今までそうする方法はありませんでした。このドキュメントでは、ノードが属性を特定のツリーに関連付けることができる結合メッセージの変更について説明します。属性は、タイプ長値形式でエンコードされます。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Use of Join Attributes ..........................................3
3.1. Sending Join Attributes ....................................3
3.2. The Join Attribute Option in the PIM Hello .................4
3.3. Receiving Join Attributes ..................................4
3.3.1. General Considerations ..............................4
3.3.2. Transitive and Non-Transitive Attributes ............5
3.3.3. Conflicting Attributes ..............................5
3.3.4. Attribute Change ....................................6
3.4. PIM Attribute Packet Format ................................7
3.4.1. PIM Join Packet Format ..............................7
3.4.2. PIM Join Attribute Hello Option .....................8
4. IANA Considerations .............................................8
5. Security Considerations .........................................9
6. Acknowledgments .................................................9
7. Normative References ............................................9
8. Informative References ..........................................9
In the protocol known as "Protocol Independent Multicast - Sparse Mode" [RFC4601] (henceforth referred to as "PIM"), a Join message sent by a given node may identify one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate an attribute, encoded in Type-Length-Value (TLV) format, with a particular tree that it wishes to join. These attributes are known as "PIM Join Attributes".
「プロトコル独立マルチキャスト - スパースモード」として知られるプロトコル[RFC4601]（以降、「PIM」と呼ばれる）では、特定のノードから送信された結合メッセージは、そのノードが結合したい1つ以上のマルチキャスト配布ツリーを識別する場合があります。各ツリーは、マルチキャストグループアドレスとソースアドレス（ソースアドレスが「ワイルドカード」である可能性がある）の組み合わせによって識別されます。特定の条件下では、ツリーに参加するときに、ツリーの構築に関連する追加情報を指定するのに役立ちます。しかし、今までそうする方法はありませんでした。このドキュメントでは、ノードがタイプレングスバリュー（TLV）形式でエンコードされた属性を関連付けることを可能にする結合メッセージの変更について説明します。これらの属性は、「PIM結合属性」と呼ばれます。
In the PIM Join message, the Source Address is identified by being encoded as an "Encoded-Source Address" ([RFC4601], section 4.9.1). Each Encoded-Source Address occurs in the context of a particular group address, represented as an "Encoded-Group Address". Together, the Encoded-Source Address and the Encoded-Group Address identify a multicast distribution tree. The Encoded-Source Address contains an "encoding type" field. The only value defined in [RFC4601] is 0. This specification is the first to assign another encoding type value.
PIM結合メッセージでは、ソースアドレスは、「エンコードされたソースアドレス」（[RFC4601]、セクション4.9.1）としてエンコードされることにより識別されます。各エンコードされたソースアドレスは、「エンコードされたグループアドレス」として表される特定のグループアドレスのコンテキストで発生します。一緒に、エンコードされたソースアドレスとエンコードされたグループアドレスは、マルチキャスト分布ツリーを識別します。エンコードされたソースアドレスには、「エンコードタイプ」フィールドが含まれています。[RFC4601]で定義されている唯一の値は0です。この仕様は、別のエンコードタイプ値を割り当てる最初のものです。
In order to associate TLVs with a particular tree, this specification defines a new encoding type for the Encoded-Source Address: type 1. When type 1 is used, the Encoded-Source Address may contain a sequence of "Join Attributes", each of which is encoded as a TLV. Then the type 1 Encoded-Source Address, in the context of the associated Encoded-Group Address, identifies a multicast distribution tree and specifies (via the Join Attribute TLVs) the attributes that apply to the tree. Apart from the fact that the type 1 Encoded-Source Address may contain Join Attributes, it is otherwise identical to the type 0 Encoded-Source Address.
TLVを特定のツリーに関連付けるために、この仕様では、エンコードされたソースアドレスの新しいエンコードタイプを定義します。タイプ1を使用すると、エンコードされたソースアドレスには「結合属性」のシーケンスが含まれます。TLVとしてエンコードされています。次に、関連するエンコードされたグループアドレスのコンテキストで、タイプ1エンコードされたソースアドレスがマルチキャスト分布ツリーを識別し、（結合属性TLVを介して）ツリーに適用される属性を指定します。タイプ1エンコードされたソースアドレスに結合属性が含まれている可能性があるという事実とは別に、それ以外の場合は、タイプ0エンコードソースアドレスと同じです。
This document does not contain the specification for any particular Join Attribute. It specifies how Join Attributes are to be encoded into the Join messages and it specifies generic procedures that are common to all Join Attributes. The content and purpose of any particular Join Attribute is outside the scope of this document.
このドキュメントには、特定の結合属性の仕様は含まれていません。結合属性が参加メッセージにエンコードされる方法を指定し、すべての参加属性に共通する一般的な手順を指定します。特定の結合属性のコンテンツと目的は、このドキュメントの範囲外です。
The use of Join Attributes in "Protocol Independent Multicast - Dense Mode" [RFC3973] is not considered.
「Protocol Independent Multicast -Dense Mode」[RFC3973]での結合属性の使用は考慮されていません。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Join Attributes are encoded as TLVs into the Encoded-Source Address field of a PIM Join message, as specified in section 3.4.1 below. Each attribute applies to the same multicast distribution tree that is identified by the combination of the Encoded-Source Address and the associated Encoded-Group Address. The multicast distribution tree may be either a source-specific tree or a shared tree.
結合属性は、以下のセクション3.4.1で指定されているように、PIM結合メッセージのエンコードされたソースアドレスフィールドにTLVとしてエンコードされます。各属性は、エンコードされたソースアドレスと関連するエンコードされたグループアドレスの組み合わせによって識別される同じマルチキャスト分布ツリーに適用されます。マルチキャスト分布ツリーは、ソース固有のツリーまたは共有ツリーのいずれかです。
The encoding of the "source address" field within the Encoded-Source Address is exactly the same for a type 1 Encoded-Source Address as for a type 0 Encoded-Source Address, specified in [RFC4601].
エンコードされたソースアドレス内の「ソースアドレス」フィールドのエンコーディングは、[RFC4601]で指定されたタイプ0エンコードソースアドレスの場合とまったく同じです。
A type 1 Encoded-Source Address MUST contain at least one Join Attribute. The way to specify that there are no Join Attributes for a particular tree is to use the type 0 Encoded-Source Address.
タイプ1エンコードされたソースアドレスには、少なくとも1つの結合属性を含める必要があります。特定のツリーに結合属性がないことを指定する方法は、タイプ0エンコードソースアドレスを使用することです。
Multiple Join Attributes of the same type or of different types may occur within a single Encoded-Source Address. This specification does not require all attributes of a given type to occur contiguously. There is no header field that specifies the number of attributes; rather the last attribute is specially marked as such.
同じタイプまたは異なるタイプの複数の結合属性が、単一のエンコードされたソースアドレス内で発生する場合があります。この仕様では、特定のタイプのすべての属性が連続的に発生する必要はありません。属性の数を指定するヘッダーフィールドはありません。むしろ、最後の属性はそのように特別にマークされています。
Any PIM router that does not understand the type 1 Encoded-Source Address will not be able to process a PIM Join message that contains it. Further, if the use of any particular Join Attribute affects the construction of the multicast distribution tree, the tree may not be formed correctly unless the attribute is understood by all PIM routers that receive it. As a consequence, attributes are only useful within a single administrative domain (or perhaps a small set of contiguous, cooperating administrative domains) where it can be determined a priori that all deployed PIM routers understand the type 1 Encoded-Source Address, as well as whatever specific attributes are in use.
タイプ1エンコードされたソースアドレスを理解していないPIMルーターは、それを含むPIM結合メッセージを処理できません。さらに、特定の結合属性の使用がマルチキャスト分布ツリーの構築に影響する場合、属性がそれを受け取ったすべてのPIMルーターによって理解されない限り、ツリーは正しく形成されない場合があります。結果として、属性は、単一の管理ドメイン（または、おそらく隣接する、協力する管理ドメインの小さなセット）内でのみ有用です。ここでは、すべての展開されたPIMルーターがタイプ1エンコードされたソースアドレスを理解しているという先験的なものと判断できます。どのような具体的な属性が使用されていても。
To ensure that a type 1 Encoded-Source Address is not sent to a PIM neighbor that does not understand this encoding, a new PIM Hello option, the "Join Attribute" option, is defined. This option MUST be included in the PIM Hellos of any PIM router that is willing to receive type 1 Encoded-Source Address. A PIM router MUST NOT send a type 1 Encoded-Source Address out any interface on which there is a PIM neighbor that has not included this option in its Hellos. (Even a router that is not the upstream neighbor must be able parse the packet in order to do Join suppression or overriding.)
タイプ1エンコードされたソースアドレスがこのエンコードを理解していないPIM隣人に送信されないようにするために、新しいPIM Helloオプション、「Join属性」オプションが定義されています。このオプションは、タイプ1のエンコードソースアドレスを受け取ることをいとわないPIMルーターのPIM Hellosに含める必要があります。PIMルーターは、このオプションをHellosに含めていないPIMネイバーがあるインターフェイスをタイプ1のエンコードソースアドレスから送信してはなりません。（上流の隣人ではないルーターでさえ、抑制またはオーバーライドを行うためにパケットを解析できる必要があります。）
Note that a PIM router that sends the "Join Attribute" Hello option does not necessarily understand every possible attribute type. As there is no immediate way to act on a neighbor's inability to process certain attribute types, it is not desired to have a Hello option for each possible attribute type.
「結合属性」Helloオプションを送信するPIMルーターは、すべての可能な属性タイプを必ずしも理解していないことに注意してください。特定の属性タイプを処理できない隣人の能力に即座に行動する方法はないため、可能な属性タイプごとにHelloオプションを持つことは望ましくありません。
A PIM router that receives a type 1 Encoded-Source Address MUST examine all the attributes in the order in which they appear.
タイプ1エンコードされたソースアドレスを受信するPIMルーターは、それらが表示される順序ですべての属性を調べる必要があります。
The specification for a given attribute type MUST specify the procedure to apply if there are multiple instances of that attribute type.
特定の属性タイプの仕様は、その属性タイプの複数のインスタンスがある場合、適用する手順を指定する必要があります。
Processing an attribute may affect the following:
属性の処理は、次のことに影響を与える可能性があります。
- the construction of the associated multicast distribution tree,
- 関連するマルチキャスト分布ツリーの構造、
- the processing of other attributes of the same type that also occur in the type 1 Encoded-Source Address, and
- タイプ1エンコードされたソースアドレスでも発生する同じタイプの他の属性の処理と
- the forwarding (or not) of the attribute itself and/or other attributes of the same type that also occur in the type 1 Encoded-Source Address.
- 属性自体および/または同じタイプのその他の属性の転送（または属性）は、タイプ1エンコードソースアドレスでも発生します。
If the processing of a received attribute has any effect on the construction of the multicast distribution tree or on the set of attributes that are forwarded up the tree, then state MUST be maintained associating the received attribute with the adjacency or adjacencies from which it was received.
受信した属性の処理が、マルチキャスト配布ツリーの構築またはツリーに転送される属性のセットに影響を与える場合、受信した属性を隣接または隣接する隣接に関連付けて状態を維持する必要があります。。
If a PIM router understands a particular attribute type, the attribute is processed as specified above.
PIMルーターが特定の属性タイプを理解している場合、属性は上記のように処理されます。
If a PIM router does not understand the type of a particular attribute, the PIM router either forwards that attribute or discards it, depending upon the setting of the attribute's F-bit. If the F-bit is set, then the router MUST forward the attribute; if the F-bit is clear, then the router MUST discard it.
PIMルーターが特定の属性のタイプを理解していない場合、PIMルーターは、属性のFビットの設定に応じて、その属性または破棄を転送します。Fビットが設定されている場合、ルーターは属性を転送する必要があります。Fビットがクリアな場合は、ルーターを破棄する必要があります。
If one or more non-transitive attributes are discarded, the rest of the Join Attributes (if any) are still forwarded. If there are no Join Attributes left to forward, a Join with a type 0 Encoded-Source Address field MUST be forwarded.
1つまたは複数の非転倒的な属性が破棄されている場合、結合属性の残り（もしあれば）がまだ転送されます。フォワードまでの結合属性がない場合は、タイプ0エンコードされたソースアドレスアドレスフィールドとの結合を転送する必要があります。
It is possible that a router receives conflicting attribute information from different downstream routers. Conflicts only occur with attributes of the same type.
ルーターは、異なる下流ルーターから競合する属性情報を受信する可能性があります。競合は、同じタイプの属性でのみ発生します。
( Edge A1 ) ( Edge B1 )---- [R1]
/ \ /
/ \ /
[S] ( Core )
\ / \
\ / \
( Edge A2 ) ( Edge B2 )---- [R2]
Figure 1
図1
As an example, consider Figure 1 and suppose a Join Attribute is used to indicate a choice of exit router. There are 2 receivers for the same group connected to Edge B1 and B2. Suppose that edge router B1 prefers A1 and B2 prefers A2 as exit points to reach the source S. If both Edge B1 and B2 send a Join including an attribute to prefer their exit router in the network and they cross the same core router, the core router will get conflicting attribute information for the source. If this happens, we use the attribute from the PIM adjacency with the numerically smallest IP address. In the case of IPv6, the link local address will be used. When two neighbors have the same IP address, either for IPv4 or IPv6, the interface index MUST be used as a tie breaker. The attributes from other sending routers MAY be remembered; that way, if the adjacency that supplied the selected attribute gets pruned or expires, we are able to immediately use the attribute that was sent by the adjacency that is next in the order of preference. This enables us to converge quickly without waiting for the next periodic update.
例として、図1を考慮し、参加属性が出口ルーターの選択を示すために使用されると仮定します。Edge B1とB2に接続された同じグループに2つの受信機があります。Edge Router B1は、エッジB1とB2の両方がネットワーク内の出口ルーターを好む属性を含む結合を送信し、同じコアルーターを越えてコアであるコアを越えた場合、Edge Router B1がA1とB2がSOURCE Sに到達するためにA2を好むことを好むと仮定します。ルーターは、ソースの競合属性情報を取得します。これが発生した場合、数値的に最小のIPアドレスでPIM隣接の属性を使用します。IPv6の場合、リンクローカルアドレスが使用されます。IPv4またはIPv6のいずれかの場合、2人の近隣が同じIPアドレスを持っている場合、インターフェイスインデックスはタイブレーカーとして使用する必要があります。他の送信ルーターからの属性を記憶することができます。そうすれば、選択された属性を提供した隣接が剪定または有効期限が取られた場合、すぐに隣接する隣接によって送信された属性を順番に使用することができます。これにより、次の定期的な更新を待たずに迅速に収束することができます。
When a particular attribute type is specified, the specification MAY include a conflict resolution procedure specific to that type. If so, that conflict resolution procedure MUST be used instead of the procedure described in this section.
特定の属性タイプが指定されている場合、仕様には、そのタイプに固有の競合解決手順が含まれる場合があります。その場合、このセクションで説明する手順の代わりに、その紛争解決手順を使用する必要があります。
It is possible that a router will receive, from two different adjacencies, transitive attributes of a given type. If the router does not understand attributes of that type and if the two adjacencies have not sent the exact same set of attributes of that type, then the conflict resolution procedure described in this section MUST be applied to those attributes. Two adjacencies are said to have sent the exact same set of attributes of a given type if they have sent the same number of instances of that attribute and if corresponding instances are byte-for-byte identical.
ルーターは、2つの異なる隣接から、特定のタイプの推移的な属性を受け取る可能性があります。ルーターがそのタイプの属性を理解していない場合、および2つの隣接がそのタイプの属性のまったく同じセットを送信していない場合、このセクションで説明する競合解決手順をそれらの属性に適用する必要があります。2つの隣接が、その属性の同じ数のインスタンスを送信し、対応するインスタンスがBYTE-by-viteの同一である場合、特定のタイプの属性のまったく同じセットを送信したと言われています。
A PIM router may decide to change the set of attributes it has associated with a given multicast distribution tree. This can happen if one of its downstream neighbors on the tree has changed the set of attributes. It can also happen as a result of processing the attributes. It can also happen for reasons outside the scope of this specification (such as a change in configuration).
PIMルーターは、特定のマルチキャスト分布ツリーに関連付けられている属性のセットを変更することを決定する場合があります。これは、ツリー上の下流の隣人の1つが属性のセットを変更した場合に発生する可能性があります。属性の処理の結果としても発生する可能性があります。また、この仕様の範囲外（構成の変更など）以外の理由で発生する可能性があります。
If a PIM router needs to change the set of attributes for a given tree but does not change its upstream neighbor for that tree, it MUST send a new Join for that tree, specifying the new set of attributes. If the new set of attributes is the null set, the type 0 Encoded-Source format MUST be used.
PIMルーターが特定のツリーの属性のセットを変更する必要があるが、そのツリーの上流の隣人を変更しない場合、そのツリーの新しい結合を送信して、新しい属性セットを指定する必要があります。新しい属性のセットがnullセットである場合、タイプ0エンコードされたソース形式を使用する必要があります。
If a PIM router needs to change the set of attributes for a given tree and as a result changes its upstream neighbor for that tree, it sends a Prune to the old upstream neighbor. The Prune does not need to carry any attributes.
PIMルーターが特定のツリーの属性のセットを変更する必要があり、その結果、そのツリーの上流の隣接を変更する場合、古い上流の隣人にプルーンを送信します。Pruneは属性を運ぶ必要はありません。
When a PIM router receives a Join for a given tree and the Join does not contain exactly the same set of attributes as the prior Join, the set of attributes in the new Join becomes the entire new set of attributes. No attribute information from the prior Join is retained. There is no way to advertise incremental changes to the set of attributes; any attributes that are no longer present are considered to have been withdrawn. If, as the result of receiving a Join, a PIM router determines that the set of attributes has changed, it will need to send a new Join upstream that contains the new set of attributes. (Of course, the procedures for resolving attribute conflicts may need to be applied first.)
PIMルーターが特定のツリーの結合を受信し、結合に前の結合とまったく同じ属性セットが含まれていない場合、新しい結合の属性のセットは、属性の新しいセット全体になります。事前結合からの属性情報は保持されません。属性のセットにインクリメンタルな変更を宣伝する方法はありません。存在しない属性は、撤回されたと見なされます。結合を受信した結果、PIMルーターが属性のセットが変更されたと判断した場合、新しい属性セットを含む新しい結合アップストリームを送信する必要があります。（もちろん、属性競合を解決する手順を最初に適用する必要がある場合があります。）
When a PIM router R1 receives a Prune for a given tree from a given downstream neighbor R2, where R2 had previously sent attributes applying to that tree, those attributes are considered to have been withdrawn. Depending on the attributes that R1 has received from its other downstream neighbors (if any) on the tree, R1 may determine that the set of attributes applying to the tree has changed, in which case it needs to send a new Join, with the new attribute set, to its upstream neighbor on the tree.
PIMルーターR1が特定の下流の隣接R2から特定のツリーのプルーンを受信すると、R2が以前にそのツリーに適用される属性を送信していたため、それらの属性は撤回されたと見なされます。R1がツリー上の他の下流の隣人（ある場合）から受け取った属性に応じて、R1はツリーに適用される属性のセットが変更されたと判断する場合があります。属性セット、ツリー上の上流の隣人に。
There is no space in the default PIM source encoding to include an attribute field. Therefore we introduce a new source encoding type. The attributes are formatted as TLVs. The new Encoded-Source Address looks like this:
属性フィールドを含むようにエンコードするデフォルトのPIMソースにスペースはありません。したがって、新しいソースエンコードタイプを紹介します。属性はTLVとしてフォーマットされます。新しいエンコードされたソースアドレスは次のようになります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
|F|E| Attr_Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
|F|E| Attr_Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
. . .
. . .
- Encoding Type: 1
- エンコードタイプ：1
- F-bit, Transitive Attribute. If this bit is set, the attribute is a transitive attribute; otherwise, it is a non-transitive attribute. See section 3.3.2.
- f-bit、transitive属性。このビットが設定されている場合、属性は推移的な属性です。それ以外の場合、それは非転倒的な属性です。セクション3.3.2を参照してください。
- E-bit, End of Attributes. If this bit is set, then this is the last Join Attribute appearing in this Encoded-Source Address field.
- e-bit、属性の終わり。このビットが設定されている場合、これはこのエンコードされたソースアドレスフィールドに表示される最後の結合属性です。
- "Attr_Type", a 6-bit field identifying the type of the Attribute.
- 「attr_type」、属性のタイプを識別する6ビットフィールド。
- Length field, a 1-octet field specifying the length in octets, encoded as an unsigned binary integer, of the value field.
- 長さフィールド、オクテットの長さを指定する1オクセットフィールド、値フィールドの符号なしのバイナリ整数としてエンコードされています。
The other fields are the same as described in [RFC4601].
他のフィールドは、[RFC4601]の説明と同じです。
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 = 26 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Option type: 26.
- オプションタイプ：26。
A new IANA registry has been created for "PIM Join Attribute Types". These are values of the "Attr_Type" field depicted in section 3.4.1. Assignments are to be made according to the policy "IETF Review" as defined in [RFC5226].
「PIM Join属性タイプ」用に新しいIANAレジストリが作成されました。これらは、セクション3.4.1に示されている「attr_type」フィールドの値です。[RFC5226]で定義されているように、ポリシー「IETFレビュー」に従って割り当てが行われます。
IANA has assigned the PIM Hello option value 26 to the "Join Attribute" option, with this document as the reference.
IANAは、このドキュメントを参照として、PIM Hello Option値26を「属性」オプションに割り当てました。
[RFC4601] should have, but did not, create a registry for the "Encoding Type" field of the Encoded-Source Address format defined therein. IANA has set up a registry for this, referencing both this document and [RFC4601]. Assignments should be made according to the policy "IETF Review" as defined in [RFC5226]. Two encoding types are defined:
[RFC4601]は、そこに定義されているエンコードされたソースアドレス形式の「エンコードタイプ」フィールドのレジストリを作成する必要があります。IANAは、このドキュメントと[RFC4601]の両方を参照して、これのレジストリを設定しました。[RFC5226]で定義されているように、ポリシー「IETFレビュー」に従って割り当てを行う必要があります。2つのエンコードタイプが定義されています。
- The encoding type 0 has been allocated, defined as "native encoding for the address family", and [RFC4601] is the reference.
- エンコーディングタイプ0は、「住所ファミリーのネイティブエンコード」として定義され、[RFC4601]が参照であると定義されています。
- The encoding type 1 has been allocated, defined as "native encoding for the address family, but with zero or more PIM Join Attributes present", and this document is the reference.
- エンコードタイプ1は、「住所ファミリ向けのネイティブエンコードがありますが、ゼロ以上のPIM結合属性が存在する」と定義されている割り当てが割り当てられており、このドキュメントは参照です。
Security of the Join Attribute is only guaranteed by the security of the PIM packet, so the security considerations for PIM Join packets as described in [RFC4601] apply here. Additional security considerations may apply to specific attributes; if so, these will need to be documented in the specification of those attributes.
結合属性のセキュリティは、PIMパケットのセキュリティによってのみ保証されるため、[RFC4601]に記載されているPIM結合パケットのセキュリティに関する考慮事項はここに適用されます。追加のセキュリティ上の考慮事項は、特定の属性に適用される場合があります。その場合、これらはこれらの属性の仕様に文書化する必要があります。
Security considerations from [RFC5015] may apply as well.
[RFC5015]からのセキュリティ上の考慮事項も適用される場合があります。
The authors would like to thank Stig Venaas, James Lingard, Bharat Joshi, Marshall Eubanks, Pekka Savola, Tom Pusateri, and Elwyn Davies for their input.
著者は、Stig Venaas、James Lingard、Bharat Joshi、Marshall Eubanks、Pekka Savola、Tom Pusateri、およびElwyn Daviesの意見に感謝したいと思います。
[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、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973] Adams、A.、Nicholas、J.、およびW. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM -DM）：プロトコル仕様（改訂）」、RFC 3973、2005年1月。
[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、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、2007年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Arjen Boers Cisco Systems, Inc. Avda. Diagnoal, 682 Barcelona 08034
Arjen Boers Cisco Systems、Inc。AVDA。診断、682バルセロナ08034
EMail: aboers@cisco.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJSBRAND Wijnands Cisco Systems、Inc。de Kleetlaan 6a Diegem 1831ベルギー
EMail: ice@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州、01719
EMail: erosen@cisco.com