[要約] RFC 2907は、MADCAP（Multicast Address Dynamic Client Allocation Protocol）のマルチキャストスコープネスティング状態オプションに関する仕様です。このRFCの目的は、MADCAPプロトコルでマルチキャストスコープのネスティング状態を管理するためのオプションを提供することです。
Network Working Group R. Kermode
Request for Comments: 2907 Motorola
Category: Standards Track September 2000
MADCAP Multicast Scope Nesting State Option
MADCAPマルチキャストスコープネスト状態オプション
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.
Copyright（c）The Internet Society（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.
理想的には、図1のAおよびC領域のサイズを排除または最小化するメカニズム。図2に示すように、この問題を解決するには必要です。この能力を提供するメカニズムの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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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は、可能な4つの方法のいずれかで関連することができます。
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) x巣の中に巣、2）y内部x、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サーバーは、「スコープxがスコープYでネスト」かどうかを説明する2つの状態を定義する必要があります。このドキュメントの残りの部分では、ネスト関係は「/」として示されるものとします。ここで、x/yは「y内の巣」の関係を定義します。この関係は、値の1つを「true」または「false」とすると理解されます。不確定性のネスト関係の状態は、「偽」と見なされます。
3 Multicast Scope Nesting State Option
3マルチキャストスコープネスティング状態オプション
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サーバーはこの新しいオプションを実装する場合がありますが、必要ではありません。
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.
「マルチキャストスコープネスト状」オプションを理解するには、最初に「マルチキャストスコープリスト」オプションを理解する必要があります。
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（n-1）/2ペアリングを形成できます。セクション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.
完全なマトリックス、スパースマトリック、および可変長さリストのリストを使用して、この状態を表す方法はいくつかあります。最大の効率と柔軟性のために、マルチキャストネスティング状態オプションは、ビットパックマトリックスアプローチを使用します。このアプローチでは、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)
ACK（getInfoに応じて）
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.
マルチキャストNest Stateオプションはマルチキャストスコープリストオプションに依存するため、マルチキャストスコープリストオプションなしでは含めてはなりません。
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.
したがって、スコープ間のネスト的な関係を明示的に学習する必要があるクライアントは、オプションリクエストオプションにリストされている「マルチキャストスコープリスト」と「マルチキャストスコープネスト状」オプションコードを使用して、サーバーに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 = "false"状態のタイムアウトにも使用され、ゾーンxとゾーンyの境界が変更され、ゾーンxがゾーンy内にネストされる場合にx/yをリセットすることができます。
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.
2番目のタイマーゾーン_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を使用して、Scopes MadCapサーバー間のネスト関係を発見すると、管理範囲の境界メンテナンスの通常の過程でゾーンボーダールーター（ZBR）によって定期的に送信されるMZAPメッセージに盗聴されます。このようにして、彼らはどのスコープが存在するか（ゾーンアナウンスメッセージ、ZAMを介して）存在し、これらのスコープのどれがネストしていないか（内部メッセージ、NIMSを介して）を学ぶことができます。この状態は、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が、Scope 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状態を「false」に更新する必要があります。2）新しく更新されたX/Y状態のnest_no_decision_timerを再起動する必要があります。
4.2 Updating State for Dynamic Scopes due to timer expiration.
4.2 タイマーの有効期限による動的スコープの状態を更新します。
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".
o nest_no_decision_timerが状態エントリx/yに対して有効期限が切れ、scope xがスコープy内にネストしないことを示すmadcapメッセージが受信されていない場合、madcapサーバーsは、スコープxがスコープy内にネストすると結論付けなければなりません。x/yを「false」から「true」に変更します。
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.
x/yに対して状態が「false」から「true」に変化する場合、sはx/yのzones_exist_timerタイマーも起動する必要があります。Zones_exist_timerは、ゾーンアナウンスメッセージ（zam）がゾーンxとゾーンyの両方で前回再起動した場合にのみリセットする必要があります。これにより、ゾーン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.
o Zones_exist_timerが状態エントリx/yに対して有効期限が切れる場合、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ビットします。この値は、前のマルチキャスト状態リストオプションのカウントフィールドと同一でなければなりません。そうでない場合は、スコープネスト状態情報を無視する必要があります。
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.
Nest State Matrix：図4に示すのと同じ方法で導出されたマトリックスの圧縮されたビットパック表現は、nスコープのメモは、圧縮されたマトリックスのn倍の天井（（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つのゾーンがネストしないことを発表するメッセージを受信してはならないと想定できます。このタイマーの長さは、ゾーンが現在存在するゾーンを通知するために使用されるゾーンアナウンスプロトコルに依存します。MZAP [RFC2776]を使用する場合、この値はMZAPタイムアウト値nim-interval 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サーバーまたはクライアントは、ゾーンが動的に検出されたときに問題のゾーンが存在しないと想定する必要があります。このタイマーの長さは、ゾーンが現在存在するゾーンを通知するために使用されるゾーンアナウンスプロトコルに依存します。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.
著者は、この文書の形成と改良に役立つ有用な議論とフィードバックについて、マーク・ハンドリーとデイブ・ターラーに感謝します。
[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。、「スマートネットワークキャッシュ：マルチキャストメディア分布のためのローカライズされたコンテンツとアプリケーションネゴシエートリカバリメカニズム」、Ph.D。論文、MIT Media Laboratory、1998年6月。
[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月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365] Meyer、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] Patel、B.V.、Shah、M.、S.R。Hanna、「マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）」、RFC 2730、1999年12月。
[RFC2776] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[RFC2776] Handley、M.、Thaler、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] Handley、M.、Thaler、D。、およびD. Estrin、「インターネットマルチキャストアドレスアロケーションアーキテクチャ」、RFC 2908、2000年9月。
Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany, NSW 1455 Australia
ロジャーカーモードモトローラオーストラリア研究センターロックされたバッグ5028ボタニー、NSW 1455オーストラリア
EMail: Roger.Kermode@motorola.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。