RFC5384 日本語訳
5384 The Protocol Independent Multicast (PIM) Join Attribute Format.A. Boers, I. Wijnands, E. Rosen. November 2008. (Format: TXT=22330 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Boers
Request for Comments: 5384 I. Wijnands
Category: Standards Track E. Rosen
Cisco Systems, Inc.
November 2008
ボーア人がコメントのために要求するワーキンググループA.をネットワークでつないでください: 5384年のI.Wijnandsカテゴリ: 標準化過程E.ローゼンシスコシステムズInc.2008年11月
The Protocol Independent Multicast (PIM)
Join Attribute Format
プロトコルの独立しているマルチキャスト(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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/license-info )へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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.
「独立しているマルチキャストについて議定書の中で述べてください--まばらなモード」という与えられたノードによって送られたJoinメッセージはそのノードが合流したがっている1本以上のマルチキャスト分配木を特定します。 各木はマルチキャストグループアドレスとソースアドレス(ソースアドレスがことによると「ワイルドカード」であるところ)の組み合わせで特定されます。 木の工事に関連する追加情報を指定するために木に合流するとき、一定の条件の下でそれは役に立つ場合があります。 しかしながら、現在までそうする方法が全くありませんでした。 このドキュメントはノードが特定の木に属性を関連づけることができるJoinメッセージの変更について説明します。 属性はType長さの価値の形式でコード化されます。
Boers, et al. Standards Track [Page 1] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[1ページ]RFC5384PIMは属性2008年11月に接合します。
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
1. 序論…2 2. 要件の仕様…3 3. 使用、属性を接合してください…3 3.1. 発信して、属性を接合してください…3 3.2. PIMの属性オプションに参加してください、こんにちは…4 3.3. 受信して、属性を接合してください…4 3.3.1. 一般問題…4 3.3.2. 他動詞と非他動詞属性…5 3.3.3. 闘争属性…5 3.3.4. 変化を結果と考えてください…6 3.4. PIMはパケット・フォーマットを結果と考えます…7 3.4.1. PIMはパケット・フォーマットを接合します…7 3.4.2. PIMが属性を接合する、こんにちは、オプション…8 4. IANA問題…8 5. セキュリティ問題…9 6. 承認…9 7. 標準の参照…9 8. 有益な参照…9
1. Introduction
1. 序論
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"と呼ばれる)、aとして知られているプロトコルと、送って、当然のことのノードがそのノードが合流したがっている1本以上のマルチキャスト分配木を特定するかもしれないというメッセージを接合してください。 各木はマルチキャストグループアドレスとソースアドレス(ソースアドレスがことによると「ワイルドカード」であるところ)の組み合わせで特定されます。 木の工事に関連する追加情報を指定するために木に合流するとき、一定の条件の下でそれは役に立つ場合があります。 しかしながら、現在までそうする方法が全くありませんでした。 このドキュメントはノードがType長さの価値(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 Joinメッセージでは、Source Addressは、「コード化されたソースアドレス」([RFC4601]、セクション4.9.1)としてコード化されることによって、特定されます。 それぞれのEncoded-ソースAddressは「コード化されたグループアドレス」として表された特定のグループアドレスの文脈に起こります。 Encoded-ソースAddressとEncoded-グループAddressはマルチキャスト分配木を一緒に、特定します。 Encoded-ソースAddressは「コード化して、タイプしてください」という分野を含んでいます。 [RFC4601]で定義された唯一の値が0です。 この仕様は、タイプ値をコード化しながら、1番目に別のものを割り当てます。
Boers, et al. Standards Track [Page 2] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[2ページ]RFC5384PIMは属性2008年11月に接合します。
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.
特定の木にTLVsを関連づけるために、この仕様はEncoded-ソースAddressのための新しいコード化しているタイプを定義します: 1をタイプしてください。 タイプ1が使用されているとき、Encoded-ソースAddressは「属性を接合してください」の系列を含むかもしれません。それはTLVとしてそれぞれコード化されます。 次に、タイプの1つのEncoded-ソースのAddressは関連Encoded-グループAddressの文脈でマルチキャスト分配木を特定して、木に適用される属性を指定します(Join Attribute TLVsを通して)。 そうでなければ、1EncodedのタイプソースAddressがJoin Attributesを含むかもしれないという事実は別として、タイプ0Encoded-ソースAddressに、それは同じです。
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.
このドキュメントはどんな特定のJoin Attributeのための仕様も含んでいません。 それはJoin AttributesがJoinメッセージにコード化されることになっている方法を指定します、そして、すべてのJoin Attributesに共通のジェネリック手順を指定します。 このドキュメントの範囲の外にどんな特定のJoin Attributeの内容と目的もあります。
The use of Join Attributes in "Protocol Independent Multicast - Dense Mode" [RFC3973] is not considered.
「独立しているマルチキャストについて議定書の中で述べてください--濃いモード」という[RFC3973]におけるJoin Attributesの使用は考えられません。
2. Specification of Requirements
2. 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Use of Join Attributes
3. 使用、属性を接合してください。
3.1. Sending Join Attributes
3.1. 発信して、属性を接合してください。
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.
Attributesを接合してください。PIM JoinメッセージのEncoded-ソースAddress分野へのTLVs、指定にされるとしてセクション3.4.1未満でコード化されます。 各属性はEncoded-ソースAddressと関連Encoded-グループAddressの組み合わせで特定されるのと同じマルチキャスト分配木に適用されます。 マルチキャスト分配木は、ソース特有の木か共有された木のどちらかであるかもしれません。
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].
Encoded-ソースAddressの中の「ソースアドレス」分野のコード化は、1タイプEncoded-ソースAddressにはまさに同じで0タイプEncoded-ソースAddressのように、[RFC4601]で指定されています。
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タイプEncoded-ソースAddressが少なくとも1Join Attributeを含まなければなりません。 特定の木のためのJoin Attributesが全くないと指定する方法はタイプ0Encoded-ソースAddressを使用することです。
Boers, et al. Standards Track [Page 3] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[3ページ]RFC5384PIMは属性2008年11月に接合します。
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.
同じタイプか異なったタイプの複数のJoin Attributesが独身のEncoded-ソースAddressの中に起こるかもしれません。 この仕様は、与えられたタイプのすべての属性が近接して起こるのを必要としません。 属性の数を指定するヘッダーフィールドが全くありません。 特に、むしろ最後の属性はそういうものとしてマークされます。
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つのEncoded-ソースのAddressを理解していないどんなPIMルータもそれを含むPIM Joinメッセージを処理できないでしょう。 さらに、どんな特定のJoin Attributeの使用もマルチキャスト分配木の工事に影響して、属性がそれを受けるすべてのPIMルータに解釈されない場合、木は正しく形成されないかもしれません。 単に結果として、属性はただ一つの管理ドメイン(または、恐らく小さいセットの隣接の、そして、協力関係を持っている管理ドメイン)で中PIMルータであると配布されたすべてがタイプの1つのEncoded-ソースのAddressを理解していることを先験的に決定できる役に立ちます、いかなる使用中の特定の属性と同様に。
3.2. The Join Attribute Option in the PIM Hello
3.2. PIMの属性オプションに参加してください、こんにちは。
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タイプEncoded-ソースAddressがこのコード化を理解していないPIM隣人に送られないのを保証するために、新しいPIM Helloオプション(「属性を接合してください」というオプション)は定義されます。 1タイプEncoded-ソースAddressを受け取っても構わないと思っているどんなPIMルータのPIMハローズにもこのオプションを含まなければなりません。 PIMルータはハローズにこのオプションを含んでいないPIM隣人がいるどんなインタフェースからも1タイプEncoded-ソースAddressを送ってはいけません。 (上流の隣人でないルータさえJoinに抑圧するためにパケットを分析するか、またはくつがえすのにおいてできるに違いありません。)
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オプションがあることが望まれていません。
3.3. Receiving Join Attributes
3.3. 受信して、属性を接合してください。
3.3.1. General Considerations
3.3.1. 一般問題
A PIM router that receives a type 1 Encoded-Source Address MUST examine all the attributes in the order in which they appear.
1タイプEncoded-ソースAddressを受けるPIMルータはそれらが現れるオーダーにおけるすべての属性を調べなければなりません。
The specification for a given attribute type MUST specify the procedure to apply if there are multiple instances of that attribute type.
その属性タイプの複数のインスタンスがあれば、与えられた属性タイプへの仕様は、適用するために手順を指定しなければなりません。
Boers, et al. Standards Track [Page 4] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[4ページ]RFC5384PIMは属性2008年11月に接合します。
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つのEncoded-ソースのAddressで起こる同じタイプの他の属性の処理。
- 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.
- また、1EncodedのタイプソースAddressで起こる属性自体の推進(or not)、そして/または、同じタイプの他の属性。
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.
容認された属性の処理がマルチキャスト分配木の工事の上、または、木に送られる属性のセットの上に何か影響を与えるなら、それが受け取られた隣接番組か隣接番組に容認された属性を関連づけて、状態を維持しなければなりません。
3.3.2. Transitive and Non-Transitive Attributes
3.3.2. 遷移的で非遷移的な属性
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つ以上の非他動詞属性が捨てるなら、まだJoin Attributes(もしあれば)の残りを進めています。 Join Attributesが全く進める残っていないなら、タイプ0Encoded-ソースAddress分野があるJoinを進めなければなりません。
3.3.3. Conflicting Attributes
3.3.3. 闘争属性
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]
(縁のA1) (縁のB1)---- [R1]/\//\/[S](コア)\/\\/\(縁のA2)(縁のB2)---- [R2]
Figure 1
図1
Boers, et al. Standards Track [Page 5] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[5ページ]RFC5384PIMは属性2008年11月に接合します。
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を考えてください、そして、Join Attributeが出口ルータの選択を示すのに使用されると仮定してください。 Edge B1とB2に接続された同じグループのための2台の受信機があります。 その縁のルータB1がA1を好んで、B2が、エキジットポイントとしてのA2がEdge B1とB2の両方がネットワークでそれらの出口ルータを好むために属性を含むJoinを送るソースS.Ifに達するのを好んで、それらが同じコアルータに交差していると、コアルータは闘争している属性情報をソースに届けるでしょう。 これが起こるなら、私たちは数の上で最も小さい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つの隣接番組が全く同じセットのそのタイプの属性を送らないなら、このセクションで説明された紛争解決手順をそれらの属性に適用しなければなりません。 その属性の同じ数のインスタンスを送って、対応するインスタンスがバイトバイト同じであるなら、2つの隣接番組が全く同じセットの与えられたタイプの属性を送ったと言われます。
3.3.4. Attribute Change
3.3.4. 属性変化
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ルータが与えられた木のために属性のセットを変えるのが必要ですが、その木のために上流の隣人を変えないなら、その木のために新しいJoinを送らなければなりません、新しいセットの属性を指定して。 新しいセットの属性が零集合であるなら、0Encodedソースがフォーマットするタイプを使用しなければなりません。
Boers, et al. Standards Track [Page 6] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[6ページ]RFC5384PIMは属性2008年11月に接合します。
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を送ります。 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ルータが与えられた木のためにJoinを受けて、Joinがまさに同じセットの先のJoinへの属性を含んでいないと、新しいJoinの属性のセットは全体の新しいセットの属性になります。 先のJoinからの属性情報は全く保有されません。 属性のセットへの漸進的変化の広告を出す方法が全くありません。 どんなもう存在していない属性も引き下がったと考えられます。 PIMルータが、Joinを受けるという結果として属性のセットが変化したことを決定すると、それは、新しいセットの属性を含む新しいJoin上流を送る必要があるでしょう。 (もちろん、属性闘争を解決するための手順は最初に適用される必要があるかもしれません。)
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からPruneを受けます。そこでは、R2が以前に属性をその木に適用させられて、それらの属性は引き下がったと考えられます。 R1が木の上で他の川下の隣人(もしあれば)から受けた属性によって、R1は、属性が木に適用されるセットが変化したことを決定するかもしれません、それが新しいJoinを送るために必要とするどの場合に、新しい属性セットで、木の上の上流の隣人に。
3.4. PIM Attribute Packet Format
3.4. PIM属性パケット・フォーマット
3.4.1. PIM Join Packet Format
3.4.1. PIMはパケット・フォーマットを接合します。
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ソースコード化にはスペースが全くありません。 したがって、私たちはタイプをコード化する新しいソースを紹介します。 属性はTLVsとしてフォーマットされます。 新しいEncoded-ソースAddressはこれに似ています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
|F|E| Attr_Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
|F|E| Attr_Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
. . .
. . .
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addrファミリー| タイプをコード化します。| Rsrvd|S|W|R| レンにマスクをかけてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス++++++++++++++++++++++++++++++… |F|E| Attr_タイプ| 長さ| ++++++++++++++++++++++++++++++を評価してください… |F|E| Attr_タイプ| 長さ| ++++++++++++++++++++++++++++++を評価してください… . . . . . .
Boers, et al. Standards Track [Page 7] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[7ページ]RFC5384PIMは属性2008年11月に接合します。
- 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.
- 電子ビット、属性の終わり。 このビットが設定されるなら、これはこのEncoded-ソースAddress分野に現れる最後のJoin Attributeです。
- "Attr_Type", a 6-bit field identifying the type of the Attribute.
- 「Attr_Type」、Attributeのタイプを特定する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]で説明されるのと同じです。
3.4.2. PIM Join Attribute Hello Option
3.4.2. PIMが属性を接合する、こんにちは、オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType = 26 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
4. IANA Considerations
4. IANA問題
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は属性タイプに加わる」ために新しいIANA登録を作成してあります。 これらはセクション3.4.1で表現された「Attr_タイプ」分野の値です。 課題は方針「IETFレビュー」に従って[RFC5226]で定義されるように作られていることです。
IANA has assigned the PIM Hello option value 26 to the "Join Attribute" option, with this document as the reference.
IANAは参照としてこのドキュメントで「属性を接合してください」というオプションにPIM Helloオプション価値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]「コード化して、タイプしてください」というそこに定義されたEncoded-ソースAddress書式の分野に登録を作成してください。 このドキュメントと[RFC4601]の両方に参照をつけて、IANAはこれのために登録をセットアップしました。 [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]です。
Boers, et al. Standards Track [Page 8] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[8ページ]RFC5384PIMは属性2008年11月に接合します。
- 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 Join Attributesが提示するゼロか以上でコード化するネイティブ」と割り当てられて、定義されています、そして、このドキュメントは参照です。
5. Security Considerations
5. セキュリティ問題
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.
Join AttributeのセキュリティがPIMパケットのセキュリティによって保証されるだけであるので、[RFC4601]で説明されるPIM Joinパケットのためのセキュリティ問題はここに適用されます。 追加担保問題は特定の属性に適用されるかもしれません。 そうだとすれば、これらは、それらの属性の仕様に記録される必要があるでしょう。
Security considerations from [RFC5015] may apply as well.
また、[RFC5015]からのセキュリティ問題は適用されるかもしれません。
6. Acknowledgments
6. 承認
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、およびElwynデイヴィースに感謝したがっています。
7. Normative References
7. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
8. Informative References
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):、」 「プロトコル仕様(改訂される)」、RFC3973、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.、Speakman、T.、およびL.Vicisano、「双方向のプロトコル独立しているマルチキャスト(BIDIR-PIM)」、RFC5015、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問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
Boers, et al. Standards Track [Page 9] RFC 5384 PIM Join Attribute November 2008
ボーア人、他 標準化過程[9ページ]RFC5384PIMは属性2008年11月に接合します。
Authors' Addresses
作者のアドレス
Arjen Boers Cisco Systems, Inc. Avda. Diagnoal, 682 Barcelona 08034
Arjenボーア人シスコシステムズInc.Avda。 Diagnoal、682バルセロナ08034
EMail: aboers@cisco.com
メール: aboers@cisco.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand WijnandsシスコシステムズInc.De kleetlaan 6a Diegem1831ベルギー
EMail: ice@cisco.com
メール: ice@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Boers, et al. Standards Track [Page 10]
ボーア人、他 標準化過程[10ページ]
一覧
スポンサーリンク
