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
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.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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つまたは複数のマルチキャスト配信ツリーを識別する。各ツリーは、マルチキャストグループアドレスとの組み合わせ（送信元アドレスが、おそらく「ワイルドカード」である）送信元アドレスによって識別されます。ツリーに参加する際、特定の条件下では、ツリーの建設に関連する追加情報を指定するために、役立つことがあります。しかし、今まではそうする方法がなかったです。この文書では、ノードは、特定の木に属性を関連付けることができますJoinメッセージの変更について説明します。属性はなType-Length-値の形式でエンコードされています。
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]、そのノードが参加を希望する1つまたは複数のマルチキャスト配信ツリーを識別することができる所与のノードによって送信された参加メッセージ（以下、「PIM」と呼びます）。各ツリーは、マルチキャストグループアドレスとの組み合わせ（送信元アドレスが、おそらく「ワイルドカード」である）送信元アドレスによって識別されます。ツリーに参加する際、特定の条件下では、ツリーの建設に関連する追加情報を指定するために、役立つことがあります。しかし、今まではそうする方法がなかったです。この文書では、ノードが参加を希望する特定のツリーと、タイプレングス値（TLV）形式でエンコードされた属性を関連付けることができJoinメッセージの変更を記載しています。これらの属性は、「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タイプ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.
「プロトコル独立マルチキャスト - 稠密モード」に参加する属性の使用[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 Joinメッセージのエンコード・ソースアドレスフィールドにの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、符号化ソースアドレス、のような1型、符号化ソースアドレスのために全く同じです。
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 Joinメッセージを処理することができません。さらに、特定の参加属性を使用すると、属性がそれを受信するすべての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こんにちはオプション、「属性への参加」オプションが、定義されています。このオプションは、タイプ1エンコード・ソースアドレスを受信しようとしているすべてのPIMルータのPIMハローズに含めなければなりません。 PIMルータは、1型エンコード-Sourceはそのハローズでこのオプションを含めていないPIMネイバーが存在している任意のインターフェイスからアドレス送ってはいけません。 （上流隣接でなくてもルータが抑制またはオーバーライドに参加行うためにパケットを解析することができなければなりません。）
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ルータが特定の属性の種類を理解していない場合は、属性または属性のFビットの設定によっては、それを破棄PIMルータのいずれかを転送。 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.
一つ以上の非推移属性が破棄された場合は、参加属性（もしあれば）の残りの部分は、まだ転送されます。何の属性を転送するために左に、タイプ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を考慮し、参加属性は、出口ルータの選択を示すために使用されているとします。エッジB1とB2に接続された同じグループのための2つの受信機があります。エッジルータB1はA1とB2は、エッジB1とB2の両方がネットワークにその出口ルーターを好む属性を含み、それらは同じコア・ルータを横断参加を送信する場合、ソースSに到達するために出口点としてA2を好む好むと仮定し、コアルータはソースの矛盾する属性情報を取得します。この問題が発生した場合、我々は数値的に最小のIPアドレスを持つPIM隣接からの属性を使用します。 IPv6の場合には、リンクローカルアドレスが使用されます。 2つのネイバーが同じIPアドレスを持っている場合、IPv4またはIPv6のいずれかで、インタフェースインデックスは、タイブレーカとして使用されなければなりません。他の送信ルータからの属性が記憶されるかもしれません。選択した属性を供給隣接関係が剪定されたか期限切れになってしまった場合、その方法は、我々はすぐに優先順に隣接している隣接によって送信された属性を使用することができます。これは、次回の定期更新を待たずにすぐに収束することを可能にします。
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つの隣接関係がそのタイプの属性の正確な同じセットを送信していない場合は、このセクションで説明する紛争解決手続は、それらの属性に適用されなければならない場合。二つの隣接関係は、彼らがその属性のインスタンスの同じ番号を送信した場合、対応するインスタンスはバイト単位に同一であれば、与えられたタイプの属性の正確な同じセットを送ってきたと言われています。
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ルータは、それが特定のマルチキャスト配信ツリーに関連付けられた属性のセットを変更することもできます。木の上のその下流の隣人の一つは一連の属性を変更した場合に発生します。また、属性を処理した結果として発生する可能性があります。それはまた、（このような構成の変化として）本明細書の範囲外の理由で発生する可能性があります。
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ルータが与えられた木の属性のセットを変更する必要があるが、その木のためにその上流の隣人を変更しない場合は、属性の新しいセットを指定して、その木のために参加し、新しいを送らなければなりません。属性の新しいセットが空集合である場合には、タイプ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ルータが与えられた木の属性のセットを変更する必要があり、結果はその木のために、その上流の隣人を変更するよう、それは昔の上流の隣人にプルーンを送信した場合。プルーンは、任意の属性を実行する必要はありません。
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ルータが与えられた木のために参加し、事前参加としての属性とまったく同じセットが含まれていませんJoinを受信すると、新しい内の属性の集合参加は、属性の全体の新しいセットになります。参加前からの属性情報が保持されません。属性セットに増分変更を宣伝する方法はありません。もはや存在しない任意の属性が撤回されたと考えられています。参加受信した結果、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ビット、推移属性。このビットがセットされている場合、属性は推移属性です。それ以外の場合は、非推移属性です。セクション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-ビット、属性の終わり。このビットが設定されている場合、これは、このエンコード・ソースアドレスフィールドに登場する最後の参加属性です。
- "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.
- 長さフィールド、値フィールドの符号なし2進整数として符号化されたオクテットの長さを指定する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].
新しいIANAレジストリは、「PIMは属性タイプの参加」のために作成されています。これらは、セクション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ハローオプション値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レビュー」に従ってなされるべきです。二つの符号化タイプが定義されています。
- 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.
作者は彼らの入力のためにスティグVenaas、ジェームズ・リンガード、バーラト・ジョシ、マーシャルユーバンクス、ペッカSavola、トムPusateri、とエルウィン・デイヴィスに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フェナー、B.、ハンドリー、M.、ホルブルック、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]アダムス、A.、ニコラス、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]ハンドレー、M.、Kouvelas、I.、スピークマン、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
アリエン・ボーア人シスコシステムズ、株式会社星Avda。 Diagnoal、682バルセロナ08034
EMail: aboers@cisco.com
メールアドレス：aboers@cisco.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnandsシスコシステムズ株式会社Kleetlaan 6aはディーゲム1831ベルギー
EMail: ice@cisco.com
メールアドレス：ice@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA、01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com