Network Working Group R. Kermode
Request for Comments: 2907 Motorola
Category: Standards Track September 2000
MADCAP Multicast Scope Nesting State Option
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) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence it may be used for expanding scope searches or hierarchical multicast transport.
この文書では、ネストされたスコープをサポートするために、マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）に新しいオプションを定義します。新しいオプションの目的は、クライアントがお互いの内側に巣をスコープ、ひいてはそれがスコープを検索したり、階層マルチキャストトランスポートを拡張するために使用することができるかを学習することができるようにすることです。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . 2
1.1 Time-To-Live (TTL) Scoping Split Horizon Effect. 2
1.2 Eliminating the Split Horizon Effect with
Administrative Scoping . . . . . . . . . . . . . 3
1.3 Terminology. . . . . . . . . . . . . . . . . . . 4
2. Multicast Nested Scoping State. . . . . . . . . . . . 5
3. Multicast Scope Nesting State Option. . . . . . . . . 5
3.1 Multicast Scope List Option . . . . . . . . . . 5
3.2 Representing the Multicast Scope Nesting State . 6
3.3 Multicast Scope Nesting State Option Usage . . . 7
4. Managing Dynamic Nested Scopes. . . . . . . . . . . . 8
4.1 MADCAP Server processing of MZAP messages. . . . 9
4.2 Updating State for Dynamic Nested Scopes due to
Timer Expiration . . . . . . . . . . . . . . 9
5. Multicast Scope Nesting State Option Format . . . . . 9
6. Constants . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . 11
9. Acknowledgements. . . . . . . . . . . . . . . . . . . 11
10. References. . . . . . . . . . . . . . . . . . . . . . 11
11. Author's Address. . . . . . . . . . . . . . . . . . . 12
12. Full Copyright Statement. . . . . . . . . . . . . . . 13
The Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] affords client applications the ability to request multicast address allocation services from multicast address allocation servers. As part of the Multicast Address Allocation Architecture [RFC2908], MADCAP gives clients the ability to reserve, request, and extend leases on multicast addresses.
マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）[RFC2730]は、クライアントアプリケーションのマルチキャストアドレス割り当てサーバからマルチキャストアドレス割り当てサービスを要求する能力を提供します。マルチキャストアドレス割り当てアーキテクチャ[RFC2908]の一環として、MADCAPは、クライアントに、予約要求、およびマルチキャストアドレスにリースを延長することができます。
A new MADCAP option, the "Multicast Scope Nesting State" option is proposed to allow clients to learn not only which scopes exist via the existing "Multicast Scope List" option, but how these scopes nest inside each other. This new option will also afford clients the ability to make better scope selections for a given session and also to construct hierarchies of administratively scoped zones. These hierarchies may then be used to perform expanding scope searches instead of the expanding ring or increasing-TTL searches. Expanding scope searches do not suffer from the Split-Horizon Effect present in expanding ring searches, and therefore both simplify protocol design and provide better localization.
新しいMADCAPオプション、「マルチキャストスコープネスト状態」オプションが提案されているが、クライアントがお互いの内部だけでなく、スコープは、既存の「マルチキャストスコープ一覧」オプションを使用して存在するが、どのようにこれらのスコープが巣を学ぶことを可能にします。この新しいオプションは、クライアントに与えられたセッションのためのより良い範囲の選択を行うためにも、管理スコープゾーンの階層を構築する能力を与えるであろう。これらの階層は、次に、拡張範囲の検索の代わりに、拡張リング又は増加-TTL検索を実行するために使用することができます。拡大範囲検索はリング検索の拡大にスプリットホライズンの影響の存在に苦しむので、両方のプロトコルの設計を簡素化し、より良いローカリゼーションを提供していません。
Multicast searching and localized recovery transport techniques that rely on TTL scoping are known to suffer when deployed in a wide scale manner. The failing lies in the split horizon effect shown below in Figure 1. Here a requestor and responder must each use a TTL that is sufficiently large that they will reach the other. When they are separated by many hops the TTL becomes large and the number of receivers within the multicast tree that only receive either the request or the response can become very large.
マルチキャスト検索とTTLスコープに依存しているローカライズされた回復輸送技術は、幅広い規模的に展開されたときに苦しむことが知られています。ここで、図1に、以下に示すスプリットホライズン効果に失敗嘘は、要求および応答は、それぞれそれらが他に到達することは十分に大きいTTLを使用しなければなりません。彼らは、多くによって分離されている場合TTLが大きくなり、唯一要求または応答のいずれかを受信し、マルチキャストツリー内の受信機の数が非常に大きくなる可能性がホップ。
....... *******
... *** *** A Only hears S
.. ** .. ** B hears S and R
. * . * C Only hears R
. * . *
. S<------->R * . TTL Boundary for S
. * . * * TTL Boundary for R
. A * B . C *
.. ** .. **
... *** ***
....... *******
Figure 1 : Split Horizon Problem from TTL scoping
図1：スプリットホライズンの問題TTLスコープから
Ideally, a mechanism that either eliminates or minimizes the size of the A and C regions in Figure 1. as shown in Figure 2. is needed to solve this problem. One mechanism that affords this ability is administrative scoping [RFC2365], in which routers prevent the passing of packets within a certain range of multicast addresses. Routers that have this feature can be configured to provide a perimeter around a region of the network. This perimeter is said to encompass an administratively scoped zone inside of which traffic sent to that particular range of multicast addresses can neither leave nor enter. Routers can construct and manage administratively scoped zones using the MZAP [RFC2776] protocol.
理想的には、いずれかの解消または図2に示すように、図1のAとC領域のサイズを最小限に抑えるが、この問題を解決するために必要とされる機構。この能力を提供する1つの機構は、ルータがマルチキャストアドレスの特定の範囲内のパケットの通過を防止する管理スコープ[RFC2365]です。この機能を有するルータは、ネットワークの領域の周囲に境界を提供するように構成することができます。この周囲は残さないでも入力することもできないマルチキャストアドレスの特定の範囲に送信されたトラフィックの内部で管理用スコープのゾーンを包含するように言われています。ルータはMZAP [RFC2776]プロトコルを使用して管理スコープゾーンを構築し、管理することができます。
........................
. .
. many hops .
.S<------------------------>R.
. .
. .
........................
Figure 2 : Eliminating the Split Horizon Effect
図2：スプリットホライズンの影響を除去
MZAP also includes the ability to determine whether or not administratively scoped regions nest inside one another. This allows hierarchies such as that shown in Figure 1. to be constructed.
MZAPは、互いに内側か否かを管理スコープ領域の巣を決定する能力を含みます。これは、図1に示すような階層構造が構築されることを可能にします。
. . . . . . . . . . . . . . . . . .
. scope a . Scope Boundaries
. . . = scope a
. _______________ ________________ . - = scopes b,c
. / scope b \ / scope c \ . # = scopes d,e,f, & g
.| | | |.
.| ##### ##### | | ##### ##### |.
.| #scope# #scope#| | #scope# #scope# |.
.\ # d # # e #| | # f # # g # /.
.\ #### #####/ \ ##### #### /.
.\____________/ \_____________/.
. . . . . . . . . . . . . . . . .
Figure 3 : Admin Scope Zone Nesting Hierarchy example
図3：管理範囲ゾーンのネスト階層の例
A generic expanding scope search algorithm [KERM] that exploits the existence of a hierarchy of administratively scoped zones is:
管理スコープのゾーンの階層が存在することを利用し、一般的な拡大範囲検索アルゴリズム[KERM]は次のようになります。
1) Starting with the smallest known scope for the session, a requestor in that session issues a request and waits for a reply.
1）セッションのための最小の既知のスコープから開始して、そのセッション内の要求者は、応答のための要求を待つを発行します。
2) If a node within that scope hears a request at a certain scope that it can satisfy it sends a response at that same scope, possibly after some random delay to reduce duplicate responses.
2）場合は、その範囲内のノードは、それが重複応答を減少させるために、おそらくいくつかのランダムな遅延後に、その同じ範囲での応答を送信満たすことができることは、特定の範囲で要求を聞きます。
3) Nodes that receive a response to a particular request while waiting to send a response to that request, suppress their own response.
3）その要求に対する応答を送信するために待っている間に、特定の要求に対する応答を受信するノードは、独自の応答を抑制する。
4) If a requestor issues a request to a scope, and does not hear a response after a specified amount of time, it retransmits its request at the same scope a small number of additional times. Should these retries fail to elicit a response, the requestor increases the scope to the next largest scope and tries again.
要求者がスコープに要求を発行し、指定された時間後に応答を聞いていない場合は4）、それは同じスコープの追加回数が少ない時にその要求を再送信します。これらの再試行が応答を誘発するために失敗すると、要求者は、次の最大のスコープにスコープを増加し、再試行します。
5) Requestors increase the scope of the request according to step 4 until either a response is received, or the largest legal scope for the session is reached. Should attempts to elicit a response at the largest possible scope for the session fail to yield a response, the requestor may conclude that the request cannot be met.
5）リクエスタは、応答が受信され、またはセッションの最大の法的範囲に達するのいずれかまで、ステップ4に従って、要求の範囲を増大させます。セッションのための最大の可能な範囲での応答を惹起する試みが応答を得るために失敗すると、要求者は、要求を満たすことができないと結論付けることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載されているように解釈されます。
Throughout the rest of this document, the words "server" or "MADCAP server" refer to a host providing multicast address allocation services via MADCAP. The words "client" or "MADCAP client" refer to a host requesting multicast address allocation services via MADCAP.
このドキュメントの残りの部分を通して、用語「サーバ」または「MADCAPサーバは、」MADCAPを経由して、マルチキャストアドレス割り当てサービスを提供するホストを参照してください。言葉「クライアント」または「MADCAPクライアントは」MADCAPを経由して、マルチキャストアドレス割り当てサービスを要求しているホストを参照してください。
Two scopes, X and Y, can be related in one of four possible ways.
2つのスコープ、XとYは、四つの可能な方法の一つに関連することができます。
1) X nests inside Y, 2) Y nests inside X, 3) X and Y do not nest (the overlap case), and 4) X and Y nest inside each other.
1）Y内のXの巣、2）X内部Yの巣、3）XとYはないネスト（重複ケース）を行い、そして互いに内側4）XとY巣。
The fourth case SHOULD be interpreted as meaning that X and Y have exactly the same border. This does not mean that X and Y are the same scope since X and Y may correspond to different ranges of the multicast address space.
第4のケースは、X及びYが正確に同じ境界を持っていることを意味するものとして解釈されるべきです。これは、XとYは、XとYは、マルチキャストアドレス空間の異なる範囲に対応することができるので、同じ範囲であることを意味するものではありません。
This state MUST be stored in the MADCAP servers which MUST allow the state to be updated as network conditions change. Each MADCAP server SHOULD therefore define two pieces of state that describe whether "scope X nests in scope Y" and vice versa. For the remainder of this document the nesting relationship shall be denoted as the "/" where X/Y defines the relation "X nests inside Y". This relation shall be understood to take one of the values "true", or "false". Nesting relationship state that is indeterminate is considered to be "false".
この状態は、状態はネットワークの状態の変化として更新することができるようにしなければならないMADCAPサーバに格納する必要があります。各MADCAPサーバは、従って、「範囲Yにおける範囲Xの巣」およびその逆かどうかを記述している状態の2個を定義する必要があります。この文書の残りの入れ子関係は「/」X / Y「がYの内部Xの巣」の関係を定義する場合と表記されなければなりません。この関係は、「真」、または「偽」のいずれかの値を取るように理解されなければなりません。不確定であるネスト関係の状態が「偽」であると考えられています。
3 Multicast Scope Nesting State Option
3マルチキャストスコープネストstateオプション
The "Multicast Scope Nesting State" option is proposed to augment the "Multicast Scope List" option within the MADCAP protocol by providing additional information to applications about how scopes nest. The proposed option is OPTIONAL, that is MADCAP servers MAY implement this new option, however they are not required to.
「マルチキャストスコープネスト状態」オプションが巣をスコープ方法についてのアプリケーションに付加的な情報を提供することにより、MADCAPプロトコル内で「マルチキャストスコープリスト」オプションを強化することが提案されています。提案されたオプションは、それがMADCAPサーバーがこの新しいオプションを実装してもよい（MAY）である、しかし、彼らはする必要はありません任意です。
MADCAP servers shall learn this additional nesting information by means of static configuration or via some other protocol such as MZAP [RFC2776] that manages administrative scopes in a dynamic fashion.
MADCAPサーバは、静的構成または動的な方法で管理スコープを管理するようMZAP [RFC2776]などのいくつかの他のプロトコルを介しての手段によってこの追加のネスティング情報を学習しなければなりません。
To understand the "Multicast Scope Nesting State" option one must first understand the "Multicast Scope List" option.
1は、最初の「マルチキャストスコープリスト」オプションを理解しなければならない「マルチキャストスコープネスト状態」オプションを理解するために。
The Multicast Scope List option in MADCAP is used by MADCAP servers to inform MADCAP clients of which zones are visible. Visible scopes are enumerated inside the option as successive tuples, where each tuple consists of the following information:
MADCAPにおけるマルチキャストスコープの一覧オプションは、ゾーンが表示されているのMADCAPクライアントに通知するためにMADCAPサーバによって使用されます。可視スコープは、各タプルは、以下の情報から成る連続タプルとしてオプション、内部に列挙されています。
o Scope ID: The smallest address for the range of multicast addresses covered by this scope.
OスコープID：この範囲に含まれるマルチキャストアドレス範囲の最小アドレス。
o Last Address: The largest address for the range of multicast addresses covered by this scope.
O最終住所：この範囲に含まれるマルチキャストアドレスの範囲の最大アドレス。
o TTL: The TTL to be used when sending messages to this scope.
OのTTL：このスコープにメッセージを送信するときに使用するTTL。
o Name(s): One or more language specific names for the scope.
O名：スコープするための1つのまたは複数の言語固有の名前。
Given a Multicast Scope List containing descriptions for n scopes one can form n(n-1)/2 pairings. As was shown in section 2 each pairing can take on one of four possible states. Thus, for a list of n scopes there exists 2 pieces of information for each pairing for a total of n(n-1) pieces of information regarding which scopes do and do not nest inside each other.
一つの形態N（N-1）/ 2のペアができNスコープの説明を含むマルチキャストスコープのリストを与えられました。セクション2に示されたように、各ペアは、4つの可能な状態のいずれかをとることができます。したがって、そこにNスコープのリストについては、N（N-1）の合計各ペアのための情報の2個行い、互いに内部ネストないいるスコープについての情報が存在します。
There are several ways to represent this state using full matrices, sparse-matrices, and using lists of variable length lists. In the interests of maximal efficiency and flexibility, the Multicast Nesting State Option uses a bit-packed matrix approach. In this approach a matrix is constructed using pieces of X/Y state where X is the row and Y is the column. A "1" in the matrix means that the relationship "row nests inside column" is true, while a "0" means that this relationship is either false or indeterminate. The diagonal of the matrix is removed, since this is the case where X is the same as Y, and each row is then zero-padded to the next byte boundary to give the final representation.
フル行列、スパース行列を使用して、可変長リストのリストを使用して、この状態を表現する方法はいくつかあります。最大の効率性と柔軟性の利益では、マルチキャストネストstateオプションは、ビットパックされた行列のアプローチを使用しています。このアプローチでは、マトリックスは、Xが行であり、YはカラムであるX / Y状態の部分を使用して構築されています。マトリックス中の「1」「0」この関係が偽の又は不定のいずれかであることを意味している間の関係「の欄内の行の巣」は、真であることを意味します。これは、XがYと同じである場合であり、各行は、最終的な表現を与えるために、次のバイト境界にゼロパディングされるので、行列の対角線は、除去されます。
An example of how a matrix would be constructed for the following scope nestings S1/S2, S2/S3, S2/S4, S3/S5, S4/S5, S5/S6, and S6/S7. Note that a number of additional nesting relationships are implied from this set.
行列は、以下の範囲のネスティングS1 / S2、S2 / S3、S2 / S4、S3 / S5、S4 / S5、S5 / S6、およびS6 / S7のために構築される方法の一例。追加のネスティング関係の数は、このセットから暗示されていることに注意してください。
________________________________
/............ \ \ \
/.S3 _________._____ \ \ \
|. /+--+ \ . \ | | |
|. | |S1| S2 | . S4 | S5 | S6 | S7 |
|. \+--+ / . | | | |
\. \______/ . | | | |
\....\....... / / / /
\ \___________/ / / /
\___________________/ / /
\ Y \______________________/ /
X \ 1 2 3 4 5 6 7 \_________________________/
+-+-+-+-+-+-+-+
1 |1 1 1 1 1 1 1| *111111 1111 1100 0xfc
2 |0 1 1 1 1 1 1| 0*11111 0111 1100 0x7c
3 |0 0 1 0 1 1 1| 00*0111 0001 1100 0x1c
4 |0 0 0 1 1 1 1| => 000*111 => 0001 1100 => 0x1c
5 |0 0 0 0 1 1 1| 0000*11 0000 1100 0x0c
6 |0 0 0 0 0 1 1| 00000*1 0000 0100 0x04
7 |0 0 0 0 0 0 1| 000000* 0000 0000 0x00
+-+-+-+-+-+-+-+ ^^
* = X/Y where zero padding
X == Y
Final Representation: 0xfc 0x7c 0x1c 0x1c 0x0c 0x04 0x00
Figure 4. Scope Nesting Example
図4スコープネスト例
The "Multicast Scope Nesting State" option is dependent upon the "Multicast Scope List" option. This decision was made according to the following reasoning. The Multicast Nest State Option requires that the scopes be identified along with their nesting properties. Since the information needed to describe a scope is contained in the Multicast Scope List option and this information can change, the MADCAP messages that contain the Multicast Scope Nesting State option must be atomic and therefore must include the "Multicast Scope List Option".
「マルチキャストスコープネスト状態」オプションは、「マルチキャストスコープ一覧」オプションに依存しています。この決定は、以下の推論に基づいて行われました。マルチキャストネスト状態のオプションは、スコープが営巣性質と一緒に識別されている必要があります。スコープを記述するために必要な情報は、マルチキャストスコープの一覧オプションに含まれており、この情報は変更することができますので、状態のオプションをネストマルチキャストスコープが含まれているMADCAPメッセージはアトミックでなければならないので、「マルチキャストスコープ一覧オプション」を含める必要があります。
Thus, the "Multicast Scope Nesting State" option MUST only be used in messages that carry the "Multicast Scope List" option, specifically:
このように、「国家をネストマルチキャストスコープ」オプションは、具体的には、「マルチキャストスコープ一覧」オプションを運ぶメッセージで使用されなければなりません。
ACK (in response to GETINFO)
（GETINFOに応答して）ACK
Since the Multicast Nest State option is dependent upon the Multicast Scope List option, it MUST NOT be included without the Multicast Scope List option.
マルチキャストネスト状態のオプションは、マルチキャストスコープの一覧オプションに依存しているので、それはマルチキャストスコープの一覧オプションを使用せずに含んではいけません。
Clients that need to explicitly learn the nesting relationships between scopes should therefore send a GETINFO message to the server with the "Multicast Scope List" AND "Multicast Scope Nesting State" option codes listed in an Option Request option.
明示的にスコープ間の入れ子関係を学ぶ必要があるクライアントは、したがって、「マルチキャストスコープ一覧」ANDオプション要求オプションに記載されている「マルチキャストスコープネスト状態」オプションコードをサーバーにGETINFOメッセージを送信する必要があります。
Scopes can either be manually or automatically configured. When scopes are manually configured the relationships between them will also be static, assuming that network does not partition due to router failure. Should the network partition or heal after a partition it is highly likely that the nesting relationships will change. Scope nesting relationships will also change as a network is brought up or when a change is deliberately made to a router either through manual reconfiguration or by some automatic means.
スコープは、手動または自動構成のいずれかであり得ます。スコープが手動で設定されている場合は、それらの間の関係も、そのネットワークが原因のルータの障害に分割していないと仮定すると、静的になります。ネットワークパーティションまたはネスト関係が変化する可能性が高いパーティションの後に癒す必要があります。ネットワークが育てているとして、あるいは変更が意図的に手動の再構成を通して、または一部の自動手段のいずれかによって、ルータに行われたときの関係をネストスコープも変更されます。
To ensure that nesting relationships are correctly determined when scope boundaries undergo change MADCAP servers MUST include a mechanism that allow for:
スコープの境界が変更MADCAPサーバを受けたときに、ネスト関係が正確に決定されていることを確認するには、を可能とする仕組みを含める必要があります。
a) whether the nesting decision is still under consideration or can be considered definitive, and therefore be announced to MADCAP clients.
a）のネスティング決定はまだ考慮中であるか、決定的と考えることができるため、MADCAPクライアントに発表されるかどうか。
b) whether one or both scopes for a particular nesting state entry have been destroyed, and hence whether the nesting state should therefore be discarded.
B）特定の入れ子状態のエントリのための1つまたは両方のスコープが破壊されているかどうか、したがって入れ子状態は、したがって、廃棄されるべきかどうか。
c) whether the scope boundaries have changed so that whereas scope X did or did not nest inside scope Y, the opposite is now true.
C）スコープXがやったか、範囲Y内の巣なかったのに対し、反対は今真実であるように、スコープの境界が変更されたかどうか。
To realize a) and b) MADCAP servers MUST implement the following two timers; NEST_NO_DECISION_TIMER, ZONES_EXIST_TIMER.
実現するためのa）及びb）MADCAPサーバは、次の2つのタイマーを実装しなければなりません。 NEST_NO_DECISION_TIMER、ZONES_EXIST_TIMER。
The first timer, NEST_NO_DECISION_TIMER, is used to mark time between a MADCAP server's first hearing of a scope and making a decision about its relationship to other zones. Up until the time this timer expires MADCAP servers MUST NOT conclude that the scope nests within another.
最初のタイマー、NEST_NO_DECISION_TIMERは、MADCAPサーバーの最初の範囲の聴覚と他のゾーンとの関係についての決定を行うまでの時間をマークするために使用されます。時間までは、このタイマーはMADCAPサーバが別の内のスコープの巣と結論付けてはならない期限が切れます。
The NEST_NO_DECISION_TIMER timer will also be used to timeout X/Y = "false" state to allow X/Y to be reset to true in the event that the boundaries for zone X and zone Y change so that zone X now nests inside zone Y.
NEST_NO_DECISION_TIMERタイマもそのゾーンXは現在、ゾーンY.の内側にネストするように、X / YがゾーンXとゾーンYの変化のための境界た場合にtrueにリセットすることができるようにX / Y =「false」の状態をタイムアウトするために使用されます
The second timer ZONES_EXIST_TIMER will be used to timeout the internal state between two scopes in the event that one or both scopes are destroyed.
第二のタイマZONES_EXIST_TIMERは、一方または両方のスコープが破壊された場合に、2つのスコープ間の内部状態をタイムアウトするために使用されます。
When MZAP is used to discover the nesting relationship between scopes MADCAP servers will eavesdrop into the MZAP messages that are periodically transmitted by the Zone Border Routers (ZBR) during the normal course of administrative scope boundary maintenance. In this way they will be able to learn which scopes exist (via Zone Announcement Messages, ZAMs) and which of these scopes do not nest (via Not Inside Messages, NIMs). This state must be cached within the MADCAP server.
MZAPは、スコープのMADCAPサーバーの間の入れ子関係を発見するために使用されている場合は、定期的に管理スコープ境界のメンテナンスの通常の過程の間、ゾーン境界ルータ（ZBR）によって送信されるMZAPメッセージに盗聴されます。このように、彼らはスコープ（、ゾーンアナウンスメッセージを介してZAMS）が存在するかを学習することができるようになりますと、これらのスコープのどの（内に入っていないメッセージを介して、のNIM）巣をしません。この状態はMADCAPサーバ内にキャッシュする必要があります。
When a MADCAP server S receives a NIM from a ZBR containing information that scope X does not nest in scope Y, it MUST update its internal state in the following manner.
MADCAPサーバSがスコープXが範囲Yに巣をしないという情報を含むZBRからNIMを受信すると、以下のようにして、その内部状態を更新する必要があります。
1) S MUST update its internal X/Y state to "false". 2) S MUST restart NEST_NO_DECISION_TIMER for the newly updated X/Y state.
1）Sは「偽」に内部X / Yの状態を更新する必要があります。 2）Sは、新たに更新されたX / Y状態のためNEST_NO_DECISION_TIMERを再起動する必要があります。
MADCAP servers will update X/Y nesting state upon the expiration of timers in the following manner.
MADCAPサーバーは、次のようにタイマーの満了時にX / Yの入れ子状態を更新します。
o If the NEST_NO_DECISION_TIMER expires for a state entry X/Y AND no MADCAP messages have been received that indicate scope X does not nest inside scope Y, a MADCAP Server, S, MUST conclude that scope X nests inside scope Y. As a result S will change X/Y from "false" to "true".
NEST_NO_DECISION_TIMERは状態エントリX / Yのために有効期限が切れるとNO MADCAPメッセージは、スコープXを示していることを受信していない場合はO範囲Y内の巣、MADCAPサーバ、Sは、結果SとしてスコープY.内部のその範囲のXの巣を締結しなければならないしません「真」を「false」からX / Yを変更します。
When a state change from "false" to "true" occurs for X/Y, S must also start the ZONES_EXIST_TIMER timer for X/Y. The ZONES_EXIST_TIMER should only reset when a Zone Announcement Message (ZAM) has been received for both zone X and zone Y since the last time it was restarted. This ensures that both zone X and zone Y are known to still exist.
「真」を「false」から状態変化がX / Yのために発生した場合、Sはまた、X / YのためのZONES_EXIST_TIMERタイマーを起動する必要があります。ゾーンアナウンス（ZAM）は、それが再起動された最後以来ゾーンXとゾーンYの両方のために受信されたときZONES_EXIST_TIMERにのみリセットする必要があります。これは、ゾーンXとゾーンYの両方がまだ存在することが知られていることを保証します。
o If the ZONES_EXIST_TIMER expires for a state entry X/Y, S SHOULD conclude that either zone Y or zone X no longer exists and hence that both X/Y and Y/X state should be destroyed.
ZONES_EXIST_TIMER状態エントリX / Yのために期限切れになった場合、O、SゾーンYまたはゾーンXのいずれかがもう存在しないこと、したがって、X / YとY / X状態の両方が破壊されるべきであると結論付けてはなりません。
Code Len Count Nest State Matrix
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 17 | p | m | N1 | | Nm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
Code: 16 bits Option identifier 17.
コード：16ビットオプション識別子17。
Len: 16 bits The length of the option in bytes.
LEN：16ビットバイトにおけるオプションの長さ。
Count: 8 bits The number of zones present in the Nest State Matrix. This value MUST be identical to the Count field in the preceding Multicast State List option. If this is not the case the scope nesting state information MUST BE ignored.
カウント：8ビット巣状態マトリックスに存在するゾーンの数を。この値は、前のマルチキャストステート一覧オプションでCountフィールドと同じでなければなりません。そうでない場合は、状態情報をネストスコープを無視しなければなりません。
Nest State Matrix: The compressed bit-packed representation of the matrix, derived in the same manner as shown in Figure 4. Note for N scopes the compressed matrix will be N times ceil((N-1)/8) bytes long, where ceil() is the function that rounds up to the nearest integer. The scopes corresponding to the rows and columns of this matrix list in the same order as they appear in the Multicast Scope List Option.
ネスト状態マトリックス：マトリックスの圧縮されたビットパック表現、Nについては、図4の注に示すと同様に、由来は、圧縮マトリックスがあろうスコープN回CEIL（（N-1）/ 8）バイト長であり、ここでCEIL（）は、最も近い整数まで丸め関数です。スコープは、彼らがマルチキャストスコープの一覧オプションに表示されるのと同じ順序で、この行列リストの行と列に対応します。
[NEST_NO_DECISION_TIMER] The time after which a MADCAP server or client can assume that a message announcing that two zones do not nest should not be received. The length of this timer is dependent upon the zone announcement protocol used to inform the MADCAP router of which zones currently exist. When MZAP [RFC2776] is used this value should be greater than the MZAP timeout value NIM-INTERVAL +30%. This corresponds to a timeout value of 1800 + 30% = 2340 seconds (39 minutes).
[NEST_NO_DECISION_TIMER]時間は後MADCAPサーバーまたはクライアントは、メッセージが2つのゾーンが巣を受信すべきでないないことを発表したと仮定することができます。このタイマーの長さは、ゾーンが現在存在するのMADCAPルータに通知するために使用されるゾーン発表プロトコルに依存しています。 MZAP [RFC2776]を使用する場合、この値はMZAPタイムアウト値NIM間隔+ 30％より大きくなければなりません。この1800 + 30％= 2340秒（39分）のタイムアウト値に相当します。
[ZONES_EXIST_TIMER] The time after which a MADCAP server or client should assume that the zone in question does not exist when zones are detected dynamically. The length of this timer is dependent upon the zone announcement protocol used to inform the MADCAP router of which zones currently exist. When MZAP [RFC2776] is used this value should be no less than the MZAP timeout value NIM-HOLDTIME, which has a default of 5460 seconds (91 minutes).
[ZONES_EXIST_TIMER] MADCAPサーバーまたはクライアント後の時間は、ゾーンが動的に検出された場合、問題のゾーンが存在しないことを前提とすべきです。このタイマーの長さは、ゾーンが現在存在するのMADCAPルータに通知するために使用されるゾーン発表プロトコルに依存しています。 MZAP [RFC2776]を使用する場合、この値は5460秒（91分）のデフォルトを有するMZAPタイムアウト値NIM-HOLDTIME、以上であってはなりません。
Since this document proposes an extension to the MADCAP protocol via the addition of a new option, the same set of security concerns apply.
このドキュメントは、新しいオプションの追加を介したMADCAPプロトコルの拡張を提案しているため、セキュリティ上の懸念の同じセットが適用されます。
In addition to these concerns are those that would arise were the information in the Multicast Scope Nesting State option to be falsified. In this case the clients would be misinformed as to which scopes nest inside one another. In this event, the client would then make incorrect decisions regarding the order in which to use the scopes. The effect of this would be to use larger scopes than necessary, which would effectively flatten any scope hierarchy present and nullify the advantage afforded by the hierarchy's presence.
これらの懸念に加えて、改ざんされるマルチキャストスコープネスト州立オプションの情報だった生じるであろうものです。互いの内側に巣をスコープにどのようこの場合、クライアントが誤解されるだろう。このイベントでは、クライアントは、スコープを使用する順序に関する誤った判断を下すだろう。この効果は、効果的に存在する任意の範囲の階層を平らにし、階層の存在によってもたらされる利点を無効と思われる、必要以上に大きなスコープを使用することであろう。
Thus a malformed or tampered Multicast Scope Nesting option may cause protocols that rely upon the existence of a scoping hierarchy to scale less well, but it would not prevent them from working.
したがって、不正な形式または改ざんマルチキャストスコープネストオプションはあまりうまくスケールするスコープの階層の存在に依存しているプロトコルを引き起こす可能性がありますが、それは働いてからそれらを防ぐことはできませんでしょう。
The Multicast Nesting State Option has been assigned MADCAP option code 17 by the IANA [RFC2730].
マルチキャストネスト状態のオプションはIANA [RFC2730]でMADCAPオプションコード17が割り当てられています。
The Author would like to acknowledge Mark Handley and Dave Thaler for the helpful discussions and feedback which helped shape and refine this document.
著者は、形状を助け、この文書を絞り込む役立つ議論やフィードバックのためのマーク・ハンドリーとDaveターラーを確認したいと思います。
[KERM] Kermode, R., "Smart Network Caches: Localized Content and Application Negotiated Recovery Mechanisms for Multicast Media Distribution", Ph.D. Thesis, MIT Media Laboratory, June 1998.
[KERM] Kermode、R.、：博士「スマート・ネットワークキャッシュのローカライズされたコンテンツとアプリケーションは、マルチキャストメディア配信のための回復メカニズムを交渉しました」論文、MITメディアラボ、1998年6月。
[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月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[RFC2730] Patel, B.V., Shah, M. and S.R. Hanna, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[RFC2730]パテル、B.V.、シャー、M.およびS.R.ハンナ、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。
[RFC2776] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[RFC2776]ハンドレー、M.、ターラー、D.およびR. Kermode、 "マルチキャストスコープゾーン発表プロトコル（MZAP）"、RFC 2776、2000年2月。
[RFC2908] Handley, M., Thaler, D. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[RFC2908]ハンドリー、M.、ターラー、D.とD. Estrin、 "インターネットマルチキャストアドレス配分アーキテクチャ"、RFC 2908、2000年9月。
Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany, NSW 1455 Australia
ロジャーKermodeモトローラオーストラリアの研究センターは、バッグ5028植物学、NSW 1455オーストラリアのロック
EMail: Roger.Kermode@motorola.com
メールアドレス：Roger.Kermode@motorola.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。