RFC2907 日本語訳
2907 MADCAP Multicast Scope Nesting State Option. R. Kermode. September 2000. (Format: TXT=27572 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Kermode Request for Comments: 2907 Motorola Category: Standards Track September 2000
コメントを求めるワーキンググループR.カーモードの要求をネットワークでつないでください: 2907年のモトローラカテゴリ: 標準化過程2000年9月
MADCAP Multicast Scope Nesting State Option
向こう見ずなマルチキャスト範囲巣篭もり州のオプション
Status of this Memo
この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) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
このドキュメントは、入れ子にされた見ることを支持するためにMulticast Address Dynamic Client Allocationプロトコル(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
1. 序論。 . . . . . . . . . . . . . . . . . . . . 2 1.1 生きる時間(TTL)の見るのは地平線効果を分けました。 2 1.2 管理見. . . . . . . . . . . . . 3 1.3る用語で分裂地平線効果を排除します。 . . . . . . . . . . . . . . . . . . 4 2. マルチキャストは、状態を見ながら、巣ごもりました。 . . . . . . . . . . . 5 3. マルチキャスト範囲巣篭もり州のオプション。 . . . . . . . . 5 3.1 マルチキャスト範囲巣篭もりを表すマルチキャスト範囲リストオプション. . . . . . . . . . 5 3.2が.63.3マルチキャスト範囲巣篭もり州のオプション用法. . . 7 4を述べます。 ダイナミックな入れ子にされた範囲を管理します。 . . . . . . . . . . . 8 4.1 MZAPメッセージのMADCAP Server処理。 . . . 9 4.2 Timer Expiration. . . . . . . . . . . . . . 9 5のためDynamic Nested Scopesのために州をアップデートします。 マルチキャスト範囲巣篭もり州のオプション形式. . . . . 9 6。 定数. . . . . . . . . . . . . . . . . . . . . . 10 7。 セキュリティ問題. . . . . . . . . . . . . . . 11 8。 IANA問題. . . . . . . . . . . . . . . . . 11 9。 承認。 . . . . . . . . . . . . . . . . . . 11
Kermode Standards Track [Page 1] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[1ページ]RFC2907の向こう見ずなマルチキャスト範囲
10. References. . . . . . . . . . . . . . . . . . . . . . 11 11. Author's Address. . . . . . . . . . . . . . . . . . . 12 12. Full Copyright Statement. . . . . . . . . . . . . . . 13
10. 参照。 . . . . . . . . . . . . . . . . . . . . . 11 11. 作者のアドレス。 . . . . . . . . . . . . . . . . . . 12 12. 完全な著作権宣言文。 . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
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.
Multicast Address Dynamic Client Allocationプロトコル(MADCAP)[RFC2730]はマルチキャストアドレス配分サーバからマルチキャストアドレス配分サービスを要求する能力をクライアントアプリケーションに提供します。 Multicast Address Allocation Architecture[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は探します。 拡張範囲検索が拡張リング検索における現在のEffectのSplit-地平線に苦しまないで、したがって、両方が、プロトコルデザインを簡素化して、より良いローカライズを提供します。
1.1 Time-To-Live (TTL) Scoping Split Horizon Effect
1.1 生きる時間(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は大きくなります、そして、マルチキャスト木の中の要求か応答のどちらかを受け取るだけである受信機の数は非常に大きくなることができます。
Kermode Standards Track [Page 2] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[2ページ]RFC2907の向こう見ずなマルチキャスト範囲
....... *******
... *** *** 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 *
.. ** .. **
... *** ***
....... *******
....... ******* ... *** *** OnlyはSを聞きます。 ** .. ** BはSとR*を聞きます。*C OnlyはR**S<を聞きます。------->R*S*R A*B C***TTL境界へのTTL境界。 ** .. ** ... *** *** ....... *******
Figure 1 : Split Horizon Problem from TTL scoping
図1: TTLの見るのからの分裂Horizon Problem
1.2 Eliminating the Split Horizon Effect with Administrative Scoping
1.2 管理見るのがある分裂地平線効果を排除すること。
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.
. .
. .
........................
........................ . . . 多くのホップ. .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に示されたそれなどの階層構造が構成されるのを許容します。
Kermode Standards Track [Page 3] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[3ページ]RFC2907の向こう見ずなマルチキャスト範囲
. . . . . . . . . . . . . . . . . .
. 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 # /.
.\ #### #####/ \ ##### #### /.
.\____________/ \_____________/.
. . . . . . . . . . . . . . . . .
aを見てください。…… 範囲Boundaries=は…aを見ます。_______________ ________________ . - = c範囲b、/はb\/範囲c\を見ます。#=がd、e、f、およびgを見る、|| | |. .| ##### ##### | | ##### ##### |. . | #範囲##範囲#| | #範囲##範囲#|. . \#d##e#| | # f###g/\#########/\#########/\____________/ \_____________/. . . . . . . . . . . . . . . . . .
Figure 3 : Admin Scope Zone Nesting Hierarchy example
図3: アドミンScope Zone Nesting Hierarchyの例
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) 要請者が範囲に要求を出して、aが時間の量を指定した後に応答を聞かないなら、それは同じ範囲のa少ない番号の追加回要求を再送します。 これらの再試行が応答を引き出さないなら、要請者は、範囲を次の最も大きい範囲まで増加させて、再試行します。
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に従って、応答が受け取られているか、またはセッションのための最も大きい法的な範囲に達するまで、要請者は要求の範囲を増加させます。 セッションのための可能な限り大きい範囲で応答を引き出す試みが応答、要請者がそうする利回りに失敗するなら、要求を迎えることができないと結論を下してください。
1.3. Terminology
1.3. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Kermode Standards Track [Page 4] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[4ページ]RFC2907の向こう見ずなマルチキャスト範囲
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を通してマルチキャストアドレス配分サービスを要求するホストについて言及します。
2. Multicast Nested Scoping State
2. マルチキャストの入れ子にされた見る状態
Two scopes, X and Y, can be related in one of four possible ways.
4つの可能な方法の1つで、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番目はSHOULDをケースに入れます。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サーバSHOULDは「範囲Xは範囲Yを巣造りし」て、逆もまた同様です、説明する状態の2つの断片を定義します。 「巣篭もり関係が指示されるものとするこのドキュメントの残り、」 /、」 X/Yが関係を定義するところでは、「XはYで巣ごもります」。 この関係が値の1つを「虚偽で「本当に」、または」取るのが理解されているものとします。 不確定であることの巣篭もり関係状態が「誤っている」と考えられます。
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プロトコルの中のオプションが見る「マルチキャスト範囲リスト」巣を増大させるために提案されます。 提案されたオプションがOPTIONALである、すなわち、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]などのある他のプロトコルでこの追加巣篭もり情報を学ぶものとします。
3.1 Multicast Scope List Option
3.1 マルチキャスト範囲リストオプション
To understand the "Multicast Scope Nesting State" option one must first understand the "Multicast Scope List" option.
「マルチキャスト範囲巣篭もり州」オプション1を理解しているのは最初に、「マルチキャスト範囲リスト」オプションを理解しなければなりません。
Kermode Standards Track [Page 5] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[5ページ]RFC2907の向こう見ずなマルチキャスト範囲
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のMulticast Scope ListオプションはMADCAPサーバによって使用されて、ゾーンが目に見えるMADCAPクライアントに知らせます。 目に見える範囲は連続したtuplesとしてオプションで数え上げられます:(そこでは、各tupleが以下の情報から成ります)。
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つ以上の言語種名。
3.2 Representing the Multicast Scope Nesting State
3.2 マルチキャスト範囲巣篭もり州を代表すること。
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.
Multicast Scope Listを考えて、n範囲1のための記述を含んでいると、n(n-1)/2つの組み合わせを形成できます。 各組み合わせが4つの可能な州の1つを帯びることができるのがセクション2で示されたように。 したがって、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.
完全なマトリクスを使用することでこの状態を表すいくつかの方法と、まばらなマトリクスと、可変長リストのリストを使用するのがあります。 最大限度の効率と柔軟性のために、Optionが使用するMulticast Nesting州はマトリクスアプローチを少し梱包しました。 このアプローチでは、マトリクスは、Xが列であり、YがコラムであるX/Y状態の断片を使用することで構成されます。 「マトリクスによる1インチは、「列はコラムの中で入れ子にする」関係が本当に、aである間、「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のためにどう構成されるだろうかに関する例。 多くの追加巣篭もり関係がこのセットから含意されることに注意してください。
Kermode Standards Track [Page 6] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[6ページ]RFC2907の向こう見ずなマルチキャスト範囲
________________________________
/............ \ \ \
/.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
________________________________ /............ \\\/.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 0xfc2|0 1 1 1 1 1 1| 0*11111 0111 1100 0x7c3|0 0 1 0 1 1 1| 00*0111 0001 1100 0x1c4|0 0 0 1 1 1 1| =>000*111=>0001 1100=>0x1c5|0 0 0 0 1 1 1| 0000*11 0000 1100 0x0c6|0 0 0 0 0 1 1| 00000、*1 0000 0100、0×04、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 0x0c0x04 0×00
Figure 4. Scope Nesting Example
図4。 範囲巣篭もりの例
3.3 Multicast Scope Nesting State Option Usage
3.3 マルチキャスト範囲巣篭もり州のオプション用法
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".
「マルチキャスト範囲巣篭もり州」オプションは「マルチキャスト範囲リスト」オプションに依存しています。 以下の推理に従ってこの決定をしました。 Multicast Nest州Optionは、範囲が彼らの巣篭もりの特性と共に特定されるのを必要とします。 範囲について説明するのに必要である情報がMulticast Scope Listオプションに含まれていて、この情報が変化できるので、Multicast Scope Nesting州オプションを含む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.
Multicast Nest州オプションがMulticast Scope Listオプションに依存しているので、Multicast Scope Listオプションなしでそれを含んではいけません。
Kermode Standards Track [Page 7] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[7ページ]RFC2907の向こう見ずなマルチキャスト範囲
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.
したがって、「マルチキャスト範囲リスト」と「マルチキャスト範囲巣篭もり州」オプションコードがOption Requestオプションで記載されている状態で、明らかに範囲の間の巣篭もり関係を学ぶ必要があるクライアントはGETINFOメッセージをサーバに送るべきです。
4. Managing Dynamically Nested Scopes
4. ダイナミックに管理するのは範囲を入れ子にしました。
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個のタイマを実行しなければなりません。 巣_いいえ、_決定_タイマ、ゾーン_は存在しています。_タイマ。
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_いいえ、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.
また、ゾーンXとゾーンYへの境界が変化する場合NEST_いいえ、_DECISION_TIMERタイマが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.
1か範囲の両方が破壊される場合、2の間の内部の状態はタイマZONES_EXIST_TIMERがタイムアウトに使用される秒に見られます。
Kermode Standards Track [Page 8] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[8ページ]RFC2907の向こう見ずなマルチキャスト範囲
4.1 MADCAP Server processing of MZAP messages
4.1 MZAPメッセージのMADCAP Server処理
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サーバは管理範囲境界維持の常軌の間に定期的にZone Border Routers(ZBR)によって送られるMZAPメッセージに盗み聞かれるでしょう。 このように、彼らは、どの範囲が存在しているか、そして、(Zone Announcement Messagesを通したZAMs)これらの範囲のどれが何か巣(Not Inside Messagesを通した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が範囲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は_NEST_いいえ、DECISION_TIMERを新たにアップデートされたX/Y状態に再開しなければなりません。
4.2 Updating State for Dynamic Scopes due to timer expiration.
4.2 タイマ満了のためDynamic Scopesのために州をアップデートします。
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 DECISION_TIMERが州のエントリーX/Yまで吐き出すNEST_ノー_が示しますが、範囲Xがどんな巣の内部の範囲にもYをしないのを示さないどんなMADCAPメッセージも受け取ったなら、MADCAP Server(S)は、範囲Xが結果SがX/Yを「本当である」「虚偽で」変える範囲Y.Asの中で巣ごもると結論を下さなければなりません。
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のために起こると、SはX/YのためにZONES_EXIST_TIMERタイマを始動しなければなりません。 それが最後の時間再開されて以来、ゾーンXとゾーンYの両方のためにZone Announcement Message(ZAM)であるときにだけTIMERがリセットするはずであるZONES_EXIST_を受け取っています。 これは、ゾーン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 SHOULDは、ゾーンYかゾーンXのどちらかがもう存在していなくて、したがって、X/YとY/X状態の両方が破壊されるべきであると結論を下します。
5. Multicast Scope Nesting State Option Format
5. マルチキャスト範囲巣篭もり州のオプション形式
Code Len Count Nest State Matrix
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 17 | p | m | N1 | | Nm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
コードレンカウント巣の州のマトリクス+-----+-----+-----+-----+-----+-----+-...-+-----+ | 17 | p| m| N1| | nm| +-----+-----+-----+-----+-----+-----+-...-+-----+
Kermode Standards Track [Page 9] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[9ページ]RFC2907の向こう見ずなマルチキャスト範囲
Code: 16 bits
Option identifier 17.
コード: 16ビットのOption識別子17。
Len: 16 bits
The length of the option in bytes.
レン: バイトで表現されるオプションの長さの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に州マトリクスを提示します。 この値は前のMulticast州Listオプションにおける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.
巣の州のマトリクス: 図4の同じ方法で誘導されたマトリクスの圧縮されたビットが詰まっている表現。 N範囲によって圧縮されたマトリクスが長さバイトのN回のceilになN-1()/8()ることに注意してください。そこでは、ceil()はそれが最も近い整数まで一周させる機能です。 このマトリクスに関する列とコラムに対応する範囲はMulticast Scope List Optionに現れるように同次で記載します。
6. Constants
6. 定数
[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_いいえ、DECISION_TIMER]MADCAPサーバかクライアントが、2つのゾーンがどんな巣もしないと発表するメッセージが受け取られるべきでないと仮定できる時。 このタイマの長さはゾーンが現在存在するMADCAPルータを知らせるのに使用されるゾーン発表プロトコルに依存しています。 MZAP[RFC2776]が使用されているとき、この値はMZAPタイムアウト値のNIM-INTERVALより+30%大きいはずです。 これは2340 1800+30%の値=秒(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]が使用されているとき、この値は少なくともMZAPタイムアウト値のNIM-HOLDTIMEであるべきです(5460秒(91分)のデフォルトがあります)。
Kermode Standards Track [Page 10] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[10ページ]RFC2907の向こう見ずなマルチキャスト範囲
7. Security Considerations
7. セキュリティ問題
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.
これらに加えて、関心はMulticast Scope Nesting州オプションにおける情報が改竄されることになっているなら起こるものです。 この場合、クライアントに関して誤伝されるでしょう(お互いの中で巣を見ます)。 そして、この出来事では、クライアントは範囲を使用するオーダーに関する不正確な決定をするでしょう。 この効果は、必要とするより大きい範囲を使用して、階層構造の存在によって提供された利点を無効にするだろうことです。(事実上、範囲はどんな範囲階層構造プレゼントも平らにするでしょう)。
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.
したがって、見る階層構造の存在を当てにするプロトコルは奇形の、または、いじられたMulticast Scope Nestingオプションでそれほどよくない比例しないかもしれませんが、それは、それらが働いているのを防がないでしょう。
8. IANA Considerations
8. IANA問題
The Multicast Nesting State Option has been assigned MADCAP option code 17 by the IANA [RFC2730].
MADCAPオプションコード17はIANA[RFC2730]によってMulticast Nesting州Optionに割り当てられました。
9. Acknowledgments
9. 承認
The Author would like to acknowledge Mark Handley and Dave Thaler for the helpful discussions and feedback which helped shape and refine this document.
Authorは形を助けた役立つ議論とフィードバックのためにマーク・ハンドレーとデーヴThalerを承認して、このドキュメントを洗練したがっています。
10. References
10. 参照
[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] カーモード、R.、「賢いネットワークは以下をキャッシュします」。 「局所化された内容とアプリケーションはマルチキャストメディア分配のために回収機構を交渉した」博士Thesis、MITメディアラボ、1998年6月。
[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月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
Kermode Standards Track [Page 11] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[11ページ]RFC2907の向こう見ずなマルチキャスト範囲
[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.ハンナ、「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、RFC2730、1999年12月。
[RFC2776] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", RFC 2776, February
2000.
[RFC2776]ハンドレーとM.とターレルとD.とR.カーモード、「マルチキャスト範囲ゾーン発表プロトコル(MZAP)」、RFC2776 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、「インターネットマルチキャストアドレス配分構造」、RFC2908、2000年9月。
11. Author's Address
11. 作者のアドレス
Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany, NSW 1455 Australia
ロジャーカーモードモトローラのオーストラリアの研究センター鍵をかけた袋5028植物学、NSW1455オーストラリア
EMail: Roger.Kermode@motorola.com
メール: Roger.Kermode@motorola.com
Kermode Standards Track [Page 12] RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
州のオプション2000年9月に巣ごもるカーモード標準化過程[12ページ]RFC2907の向こう見ずなマルチキャスト範囲
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Kermode Standards Track [Page 13]
カーモード標準化過程[13ページ]
一覧
スポンサーリンク
