RFC2909 日本語訳
2909 The Multicast Address-Set Claim (MASC) Protocol. P. Radoslavov,D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler. September 2000. (Format: TXT=127278 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Radoslavov
Request for Comments: 2909 D. Estrin
Category: Experimental R. Govindan
USC/ISI
M. Handley
ACIRI
S. Kumar
USC/ISI
D. Thaler
Microsoft
September 2000
コメントを求めるワーキンググループP.ラドスラーボフの要求をネットワークでつないでください: 2909年のD.Estrinカテゴリ: 実験的なR.のクマーUSC/ISI D.ターレルマイクロソフトGovindan USC/ISI M.ハンドレーACIRI S.2000年9月
The Multicast Address-Set Claim (MASC) Protocol
マルチキャストアドレスセットクレーム(MASC)プロトコル
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain group- specific distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist.
このドキュメントは相互ドメインマルチキャストアドレスセット配分に使用できるMulticast Address-セットクレーム(MASC)プロトコルについて説明します。 1つ以上のアドレス接頭語をそのノードのドメインにノード(通常ルータ)によってMASCは使用されて、要求して、割り当てます。 ドメインは、必ずそのドメインのホストがグループアドレスを割り当てることができるようにアドレスセットを割り当てる必要があるというわけではありませんが、アドレスセットをそのドメインに割り当てるのは、相互ドメイングループ特定の分配木が局所的に根づいて、交通が外部の受信機が存在するドメインの外で送られるのを確実にします。
Radoslavov, et al. Experimental [Page 1] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[1ページ]RFC2909MASCプロトコル2000年9月
Table of Contents
目次
1 Introduction .................................................. 4 1.1 Terminology ................................................. 4 1.2 Definitions ................................................. 4 2 Requirements for Inter-Domain Address Allocation .............. 5 3 Overall Architecture .......................................... 5 3.1 Claim-Collide vs. Query-Response Rationale .................. 6 4 MASC Topology ................................................. 6 4.1 Managed vs Locally-Allocated Space .......................... 8 4.2 Prefix Lifetime ............................................. 8 4.3 Active vs. Deprecated Prefixes .............................. 9 4.4 Multi-Parent Sibling-to-Sibling and Internal Peering ........ 9 4.5 Administratively-Scoped Address Allocation .................. 9 5 Protocol Details .............................................. 10 5.1 Claiming Space .............................................. 10 5.1.1 Claim Comparison Function ................................. 12 5.2 Renewing an Existing Claim .................................. 12 5.3 Expanding an Existing Prefix ................................ 12 5.4 Releasing Allocated Space ................................... 13 6 Constants ..................................................... 13 7 Message Formats ............................................... 14 7.1 Message Header Format ....................................... 14 7.2 OPEN Message Format ......................................... 15 7.3 UPDATE Message Format ....................................... 17 7.4 KEEPALIVE Message Format .................................... 21 7.5 NOTIFICATION Message Format ................................. 21 8 MASC Error Handling ........................................... 24 8.1 Message Header Error Handling ............................... 24 8.2 OPEN Message Error Handling ................................. 25 8.3 UPDATE Message Error Handling ............................... 26 8.4 Hold Timer Expired Error Handling ........................... 28 8.5 Finite State Machine Error Handling ......................... 28 8.6 NOTIFICATION Message Error Handling ......................... 28 8.7 Cease ....................................................... 29 8.8 Connection Collision Detection .............................. 29 9 MASC Version Negotiation ...................................... 30 10 MASC Finite State Machine .................................... 30 10.1 Open/Close MASC Connection FSM ............................. 31 11 UPDATE Message Processing .................................... 35 11.1 Accept/Reject an UPDATE .................................... 36 11.2 PREFIX_IN_USE Message Processing ........................... 38 11.2.1 PREFIX_IN_USE by PARENT .................................. 38 11.2.2 PREFIX_IN_USE by SIBLING ................................. 38 11.2.3 PREFIX_IN_USE by CHILD ................................... 38 11.2.4 PREFIX_IN_USE by INTERNAL_PEER ........................... 38 11.3 CLAIM_DENIED Message Processing ............................ 39 11.3.1 CLAIM_DENIED by CHILD or SIBLING ......................... 39
1つの序論… 4 1.1用語… 4 1.2の定義… 相互ドメインのための4 2の要件が配分を記述します… 5 3の総合的な構造… 5 3.1 質問応答原理に対してクレームで衝突してください… 6 4MASCトポロジー… 6 4.1は局所的に割り振りスペースに対して管理されました… 8 4.2 生涯を前に置いてください… 8 4.3 推奨しない接頭語に対してアクティブ… 9、4.4のマルチ親の兄弟から兄弟と内部のじっと見ること… 9 4.5は行政上アドレス配分を見ました… 9 5は詳細について議定書の中で述べます… 10 5.1 スペースを要求します… 10 5.1 .1 比較関数を要求してください… 12 5.2 既存のクレームを更新します… 12 5.3 既存の接頭語を広げます… 12 5.4 リリースはスペースを割り当てました… 13 6つの定数… 13 7 メッセージ形式… 14 7.1 メッセージヘッダー形式… 14 7.2 メッセージ・フォーマットを開いてください… 15 7.3 メッセージ・フォーマットをアップデートしてください… 17 7.4 KEEPALIVEメッセージ・フォーマット… 21 7.5 通知メッセージ・フォーマット… 21 8MASCエラー処理… 24 8.1メッセージヘッダーエラー処理… 24 8.2 メッセージエラー処理を開いてください… 25 8.3 メッセージエラー処理をアップデートしてください… 26 8.4 タイマの満期のエラー処理を保持してください… 28 8.5有限状態機械エラー処理… 28 8.6通知メッセージエラー処理… 28 8.7 やんでください… 29 8.8 接続衝突検出… 29 9 MASCバージョン交渉… 30 10MASC有限状態機械… 30 10.1 MASC接続FSMを開くか、または閉じてください… 31 11はメッセージ処理をアップデートします… 35 11.1 アップデートを受け入れるか、または拒絶してください… _の36 11.2接頭語_はメッセージ処理を使用します… 38 11.2.1 _親による使用で_を前に置いてください… 38 11.2.2 _兄弟による使用で_を前に置いてください… 38 11.2.3 _子供による使用で_を前に置いてください… 38 11.2.4 _内部の_同輩による使用で_を前に置いてください… 38 11.3 クレーム_はメッセージ処理を否定しました… 39 11.3.1 子供か兄弟によって否定された_を要求してください… 39
Radoslavov, et al. Experimental [Page 2] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[2ページ]RFC2909MASCプロトコル2000年9月
11.3.2 CLAIM_DENIED by INTERNAL_PEER ............................ 39 11.3.3 CLAIM_DENIED by PARENT ................................... 39 11.4 CLAIM_TO_EXPAND Message Processing ......................... 39 11.4.1 CLAIM_TO_EXPAND by PARENT ................................ 39 11.4.2 CLAIM_TO_EXPAND by SIBLING ............................... 40 11.4.3 CLAIM_TO_EXPAND by CHILD ................................. 40 11.4.4 CLAIM_TO_EXPAND by INTERNAL_PEER ......................... 40 11.5 NEW_CLAIM Message Processing ............................... 41 11.6 PREFIX_MANAGED Message Processing. ........................ 41 11.6.1 PREFIX_MANAGED by PARENT ................................. 41 11.6.2 PREFIX_MANAGED by CHILD or SIBLING ....................... 41 11.6.3 PREFIX_MANAGED by INTERNAL_PEER .......................... 41 11.7 WITHDRAW Message Processing ................................ 42 11.7.1 WITHDRAW by CHILD ........................................ 42 11.7.2 WITHDRAW by SIBLING ...................................... 42 11.7.3 WITHDRAW by INTERNAL ..................................... 42 11.7.4 WITHDRAW by PARENT ....................................... 43 11.8 UPDATE Message Ordering .................................... 43 11.8.1 Parent to Child .......................................... 43 11.8.2 Child to Parent .......................................... 44 11.8.3 Sibling to Sibling ....................................... 44 11.8.4 Internal to Internal ..................................... 44 12 Operational Considerations ................................... 45 12.1 Bootup Operations .......................................... 45 12.2 Leaf and Non-leaf MASC Domain Operation .................... 45 12.3 Clock Skew Workaround ...................................... 45 12.4 Clash Resolving Mechanism .................................. 46 12.5 Changing Network Providers ................................. 47 12.6 Debugging .................................................. 47 12.6.1 Prefix-to-Domain Lookup .................................. 47 12.6.2 Domain-to-Prefix Lookup .................................. 47 13 MASC Storage ................................................. 47 14 Security Considerations ...................................... 48 15 IANA Considerations .......................................... 48 16 Acknowledgments .............................................. 48 17 APPENDIX A: Sample Algorithms ................................ 49 17.1 Claim Size and Prefix Selection Algorithm .................. 49 17.1.1 Prefix Expansion ......................................... 49 17.1.2 Reducing Allocation Latency .............................. 50 17.1.3 Address Space Utilization ................................ 50 17.1.4 Prefix Selection After Increase of Demand ................ 50 17.1.5 Prefix Selection After Decrease of Demand ................ 51 17.1.6 Lifetime Extension Algorithm ............................. 51 18 APPENDIX B: Strawman Deployment .............................. 51 19 Authors' Addresses ........................................... 52 20 References ................................................... 54 21 Full Copyright Statement ..................................... 56
11.3.2 内部の_同輩によって否定された_を要求してください… 39 11.3.3 親によって否定された_を要求してください… _への39 11.4クレーム_はメッセージ処理を広げます… 39 11.4.1 _へのクレーム_は親で広がります… 39 11.4.2 _へのクレーム_は兄弟で広がります… 40 11.4.3 _へのクレーム_は子供で広がります… 40 11.4.4 _へのクレーム_は内部の_同輩で広がります… 40 11.5 新しい_クレームメッセージ処理… 41 11.6 接頭語_はメッセージ処理を管理しました。 ........................ 41 11.6.1 接頭語_は親に管理されました… 41 11.6.2 接頭語_は子供か兄弟に管理されました… 41 11.6.3 接頭語_は内部の_同輩に管理されました… 41 11.7 メッセージ処理を引き下がらせてください… 42 11.7.1 子供で、引き下がってください… 42 11.7.2 兄弟で、引き下がってください… 42 11.7.3 内部で、引き下がってください… 42 11.7.4 親で、引き下がってください… 43 11.8 メッセージ注文をアップデートしてください… 43 11.8.1 子供の親… 43 11.8.2 親への子供… 44 11.8.3 兄弟の兄弟… 44 11.8.4 内部への内部… 44 12の操作上の問題… 45 12.1 Bootup操作… 45 12.2 葉と非葉のMASCドメイン手術… 45 12.3 斜行次善策の時間を計ってください… 45 12.4 メカニズムを決議して、衝突してください… 46 12.5 ネットワーク内の提供者を変えます… 47 12.6 デバッグします。 47 12.6.1 接頭語からドメインへのルックアップ… 47 12.6.2 ドメインから接頭語へのルックアップ… 47 13MASC格納… 47 14のセキュリティ問題… 48 15のIANA問題… 48 16の承認… 48 17付録A: アルゴリズムを抽出してください… 49 17.1 サイズと接頭語選択がアルゴリズムであると主張してください… 49 17.1.1 拡大を前に置いてください… 49 17.1.2 配分レイテンシを減少させます… 50 17.1.3 アドレス空間利用… 50 17.1.4 需要増加の後に選択を前に置いてください… 50 17.1.5 要求の減少の後に選択を前に置いてください… 51 17.1.6 生涯拡大アルゴリズム… 51 18付録B: わら人形展開… 51 19人の作者のアドレス… 52 20の参照箇所… 54 21の完全な著作権宣言文… 56
Radoslavov, et al. Experimental [Page 3] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[3ページ]RFC2909MASCプロトコル2000年9月
1. Introduction
1. 序論
This document describes MASC, a protocol for inter-domain multicast address set allocation. The MASC protocol (a Layer-3 protocol in the multicast address allocation architecture [MALLOC]) is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. Each prefix has an associated lifetime, and is chosen out of a larger prefix with a lifetime at least as long, in a manner such that prefixes are aggregatable. At any time, each MASC node (a Prefix Coordinator in [MALLOC]) will typically advertise several prefixes with different lifetimes and scopes, allowing Multicast Address Allocation Servers (MAAS's) in that domain or child MASC domains to choose appropriate addresses for their clients.
このドキュメントは相互ドメインマルチキャストアドレスセット配分のためにMASC、プロトコルについて説明します。 1つ以上のアドレス接頭語をそのノードのドメインにノード(通常ルータ)によってMASCプロトコル(マルチキャストアドレス配分構造[MALLOC]のLayer-3プロトコル)は使用されて、要求して、割り当てます。 各接頭語は、関連生涯を持って、少なくとも寿命が長い状態で、より大きい接頭語から選ばれています、方法で接頭語は「集合-可能」です。 いつでも、それぞれのMASCノード([MALLOC]のPrefix Coordinator)は通常異なった生涯、範囲でいくつかの接頭語の広告を出すでしょう、そのドメインか子供MASCドメインのMulticast Address Allocation Servers(マースのもの)が彼らのクライアントのための適切なアドレスを選ぶのを許容して。
The set of prefixes ("address set") associated with a domain is
injected into an inter-domain routing protocol (e.g., BGP4+ [MBGP]),
where it can be used by an inter-domain multicast tree construction
protocol (e.g., BGMP [BGMP]) to construct inter-domain group-shared
trees.
ドメインに関連している接頭語(「アドレスはセットした」)のセットは相互ドメインルーティング・プロトコル(例えば、BGP4+[MBGP])に注がれます。そこでは相互ドメインマルチキャスト木の工事プロトコル(例えば、BGMP[BGMP])によってそれが使用されて、相互ドメインのグループによって共有された木を組み立てることができます。
Note that a domain does not need to allocate an address set for the hosts in that domain to be able to allocate group addresses, nor does allocating necessarily guarantee that hosts in other domains will not use an address in the set (since, for example, hosts are not forced to contact a MAAS before using a group address). Allocating an address set to a domain does, however, ensure that inter-domain group-specific multicast distribution trees for any group in the address set will be locally-rooted, and that traffic will be sent outside the given domain only when and where external receivers exist.
そのドメインのホストがグループアドレスを割り当てることができるようにドメインがアドレスセットを割り当てる必要はないことに注意してください、そして、割り当ては、必ず他のドメインのホストがセットにアドレスを使用しないのを保証するというわけではありません(例えば、グループアドレスを使用する前にホストがマースにやむを得ず接触しないので)。 しかしながら、アドレスセットをドメインに割り当てるのは、アドレスのどんなグループのための木も設定する相互ドメインのグループ特有のマルチキャスト分配が局所的に根づいて、交通が外部の受信機が存在する与えられたドメインの外で送られるのを確実にします。
1.1. Terminology
1.1. 用語
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]で説明されるように本書では解釈されることであるべきですか?
Constants used by this protocol are shown as [NAME_OF_CONSTANT], and summarized in Section 6.
このプロトコルによって使用される定数は、[NAME_OF_CONSTANT]として示されて、セクション6にまとめられます。
1.2. Definitions
1.2. 定義
This specification uses a number of terms that may not be familiar to the reader. This section defines some of these and refers to other documents for definitions of others.
この仕様は読者には、身近でないかもしれない項数を使用します。 このセクションは、これらのいくつかを定義して、他のものの定義のための他のドキュメントを示します。
Radoslavov, et al. Experimental [Page 4] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[4ページ]RFC2909MASCプロトコル2000年9月
MAAS (Multicast Address Allocation Server)
A host providing multicast address allocation services to end
users (e.g. via MADCAP [MADCAP]).
エンドユーザ(例えば、MADCAP[MADCAP]を通した)に対するマースの(マルチキャストAddress Allocation Server)Aホスト提供マルチキャストアドレス配分サービス。
MASC server
A node running MASC.
MASCサーバAノード走行MASC。
Peer
Other MASC speakers a node directly communicates with.
ノードが直接コミュニケートする同輩Other MASCスピーカー。
Multicast
IP Multicast, as defined for IPv4 in [RFC1112] and for IPv6 in
[RFC2460].
[RFC1112]のIPv4のために定義されて[RFC2460]のIPv6のためのマルチキャストIP Multicast。
Multicast Address
An IP multicast address or group address, as defined in [RFC1112]
and [RFC2373]. An identifier for a group of nodes.
アドレスかグループが[RFC1112]と[RFC2373]で定義されるように記述するマルチキャストAddress An IPマルチキャスト。 ノードのグループのための識別子。
2. Requirements for Inter-Domain Address Allocation
2. 相互ドメインアドレス配分のための要件
The key design requirements for the inter-domain address allocation mechanism are:
相互ドメインアドレス配分メカニズムのための主要な設計の品質は以下の通りです。
o Efficient address space utilization when space is scare, which
naturally implies that address allocations be based on the actual
address usage patterns, and therefore that it be dynamic.
o スペースであるときに、効率的なアドレス空間利用は恐怖です。(その恐怖はアドレス配分が絶対番地用法パターンに基づいていて、したがって、それがダイナミックであることを自然に含意します)。
o Address aggregation, that implies that the address allocation
mechanism be hierarchical.
o 集合を記述してください、そして、それは、アドレス配分メカニズムが階層的であることを含意します。
o Minimize flux in the allocated address sets (e.g. the address sets
should be reused when possible).
o 割り当てられたアドレスセットのフラックスを最小にしてください(可能であるときに、例えばアドレスセットは再利用されるべきです)。
o Robustness, by using decentralized mechanisms.
o 分散メカニズムを使用するのによる丈夫さ。
The timeliness in obtaining an address set is not a major design constraint as this is taken care of at a lower level [MALLOC].
これが下のレベル[MALLOC]で世話をされるとき、アドレスセットを入手することにおけるタイムリーさであるのは主要なデザイン規制ではありません。
3. Overall Architecture
3. 総合的な構造
The Multicast Address Set Claim (MASC) protocol is used by MASC domains to claim and allocate address sets for use by Multicast Address Allocation Servers (MAASs) within each domain. Typically one or more border routers of each domain that requires multicast address space of its own would run MASC. Throughout this document, the term "MASC domain" refers to a domain that has at least one node running MASC; typically these domains will be Autonomous Systems (AS's). A MASC node (on behalf of its domain) chooses an address set to claim,
Multicast Address Allocation Servers(MAASs)による使用のために各ドメインの中にアドレスセットをMulticast Address Setクレーム(MASC)プロトコルはMASCドメインによって使用されて、要求して、割り当てます。 通常、それ自身のマルチキャストアドレス空間を必要とするそれぞれのドメインの1つ以上の境界ルータは走行MASCがそうするでしょう。 このドキュメント中では、「MASCドメイン」という用語は少なくとも1つのノードがMASCを走らせるドメインについて言及します。 これらのドメインは通常、Autonomous Systemsになるでしょう(ASのもの)。 MASCノード(ドメインを代表した)は要求するアドレスセットを選びます。
Radoslavov, et al. Experimental [Page 5] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[5ページ]RFC2909MASCプロトコル2000年9月
sends a claim to other MASC domains in the network, and waits while listening for any colliding claims. If there is a collision, the losing claimer gives up the colliding claim and claims a different address set.
どんな衝突クレームのための聴取もゆったり過ごしてください。衝突があれば、負けているクレーマーが異なったアドレスが設定した衝突クレームとクレームをやめるというネットワークにおける他のMASCドメイン、および待ちへのクレームを送ります。
After a sufficiently long collision-free waiting period, the address set chosen by a MASC node is considered allocated to that node's domain. Three things may then happen:
十分長い無衝突の待ちの期間の後に、MASCノードによって選ばれたアドレスセットはそのノードのドメインに割り当てられると考えられます。 次に、3つのことが起こるかもしれません:
a) The allocated prefix can then be injected as a "multicast route"
into the inter-domain routing protocol (e.g., BGP4+ [MBGP]) as
"G-RIB" Network Layer Reachability Information (NLRI), where it
may be used by an inter-domain multicast routing protocol (e.g.,
BGMP [BGMP]) to construct group-shared trees. To reduce the size
and slow the growth of the G-RIB, MASC nodes may perform CIDR-like
aggregation [CIDR] of the multicast NLRI information. This
motivates the need for an algorithm to select prefixes for domains
in such a way as to ensure good aggregation in addition to
achieving good address space utilization.
a) 次に、「マルチキャストルート」として「G-あばら骨」ネットワーク層可到達性情報(NLRI)としての相互ドメインルーティング・プロトコル(例えば、BGP4+[MBGP])に割り当てられた接頭語を注入できます、相互ドメインマルチキャストルーティング・プロトコル(例えば、BGMP[BGMP])によってそれが使用されて、グループによって共有された木を組み立てるかもしれないところで。 サイズを減少させて、G-RIBの成長を遅くするために、MASCノードはマルチキャストNLRI情報のCIDRのような集合[CIDR]を実行するかもしれません。 これはアルゴリズムが接頭語をドメインに高級住宅地宇宙利用を達成することに加えて良い集合を確実にするほどそのような方法で選択する必要性を動機づけます。
b) The node's domain may assign to itself a sub-prefix which can be
used by MAASs within the domain.
b) ノードのドメインはドメインの中のMAASsが使用できるサブ接頭語をそれ自体に割り当てるかもしれません。
c) Sub-prefixes may be allocated to child domains, if any.
c) もしあればサブ接頭語を子供ドメインに割り当てるかもしれません。
3.1. Claim-Collide vs. Query-Response Rationale
3.1. 質問応答原理に対してクレームで衝突してください。
We choose a claim-collide mechanism instead of a query-response mechanism for the following reasons. In a query-response mechanism, replicas of the MASC node would be needed in parent MASC domains in order to make their responses be robust to failures. This brings about the associated problem of synchronization of the replicas and possibly additional fragmentation of the address space. In addition, even in this mechanism, address collisions would still need to be handled. We believe the proposed claim-collide mechanism is simpler and more robust than a query-response mechanism.
私たちは以下の理由による質問反応機構の代わりに-衝突するように主張しているメカニズムを選びます。 質問反応機構では、MASCノードのレプリカが、彼らの応答が失敗に体力を要するようにするのに親MASCドメインで必要でしょう。 これはレプリカの同期とアドレス空間のことによると追加している断片化の関連する問題を引き起こします。 このメカニズムでさえ、アドレス衝突は、まだ扱われる必要があるでしょう。 私たちは、提案された-衝突するように主張しているメカニズムが質問反応機構よりさらに簡単であって、強健であると信じています。
4. MASC Topology
4. MASCトポロジー
The domain hierarchy used by MASC is congruent to the somewhat hierarchical structure of the inter-domain topology, e.g., backbones connected to regionals, regionals connected to metropolitan providers, etc. As in BGP, MASC connections are locally configured. A MASC domain that is a customer of other MASC domains will have one or more of those provider domains as its parent. For example, a MASC domain that is a regional provider will choose one (or more) of its backbone provider domains as its parent(s). Children are configured with their parent MASC domain, and parents are configured with their
MASCによって使用されたドメイン階層構造が相互ドメイントポロジーのいくらか階層的な構造に一致している、例えば、背骨は地方版、首都のプロバイダーに関連づけられた地方版などに接続しました。 BGPのように、MASC接続は局所的に構成されます。 他のMASCドメインの顧客であるMASCドメインは親としてそれらのプロバイダードメインの1つ以上を持つでしょう。 例えば、地方のプロバイダーであるMASCドメインは親としてバックボーンプロバイダードメインの1つ(さらに)を選ぶでしょう。 子供が彼らの親MASCドメインによって構成されて、両親が構成される、彼ら
Radoslavov, et al. Experimental [Page 6] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[6ページ]RFC2909MASCプロトコル2000年9月
children domains. At the top, a number of Top-Level Domains are connected in a (sparse) mesh and share the global multicast address space. To improve the robustness, a pair of children of the same parent domain MAY be configured as siblings with regard to that parent.
子供ドメイン。 先端では、多くのTop-レベルDomainsが(まばら)のメッシュで接続されて、グローバルなマルチキャストアドレス空間を共有します。 丈夫さを改良するために、同じ親ドメインの子供の1組は兄弟としてその親に関して構成されるかもしれません。
Figure 1 illustrates a sample topology. Double-line links denote intra-domain TCP peering sessions, and single-line links denote inter-domain TCP connections. T1 and T2 are Top-Level Domains (e.g., backbone providers), containing MASC speakers T1a and T2a, respectively. P3 and P4 are regional domains, containing (P3a, P3b), and (P4a, P4b) respectively. P3 has a single customer (or "child"), C5, containing (C5a, C5b, C5c). P4 has three children, C5, C6, C7, containing (C5a, C5b, C5c), (C6a, C6b), and (C7a) respectively.
図1はサンプルトポロジーを例証します。 二重ライン・リンクはイントラドメインTCPじっと見るセッションを指示します、そして、単線のリンクは相互ドメインTCP接続を指示します。 T1とT2はそれぞれMASCスピーカーのT1aとT2aを含むTop-レベルDomains(例えば、バックボーンプロバイダー)です。 P3とP4はそれぞれ(P3a、P3b)、および(P4a、P4b)を含む地方のドメインです。 P3には、(C5a、C5b、C5c)を含んでいて、独身の顧客(または、「子供」)、C5があります。 そして、P4には3人の子供、C5、C6、(C5a、C5b、C5c)を含むC7(C6a、C6b)がある、(C7a)、それぞれ。
T1a-----------T2a
| |
| |
| |
P3a====P3b P4a====P4b
| | / | / | \
| | _______/ | / | \
| | / | / | \______
| | / | / | \
C5a====C5b C6a====C6b----------C7a
\\ //
\\//
C5c
T1a-----------T2a| | | | | | P3a====P3b P4a====P4b| | / | / | \ | | _______/ | / | \ | | / | / | \______ | | / | / | \C5a====C5b C6a====C6b----------C7a\\//\\//C5c
Figure 1: Example MASC Topology
図1: 例のMASCトポロジー
All MASC communications use TCP. Each MASC node is connected to and communicates directly with other MASC nodes. The local node acts in exactly one of the following four roles with respect to each remote note:
すべてのMASCコミュニケーションがTCPを使用します。 それぞれのMASCノードは、ノードを接続されて、直接他のMASCと伝えます。 ローカルのノードはそれぞれのリモート注意に関してちょうど以下の4つの役割の1つで行動します:
INTERNAL_PEER
The local and remote nodes are both in the same MASC domain. For
example, P4b is an INTERNAL_PEER of P4a.
地方のINTERNAL_PEERと遠隔ノードがともに同じMASCドメインにあります。 例えば、P4bはP4aのINTERNAL_PEERです。
CHILD
A customer relationship exists whereby the local node may obtain
address space from the remote node. For example, C6a is a CHILD
in its session with P4a.
ローカルのノードが遠隔ノードからアドレス空間を得るかもしれないCHILD A顧客関係は存在しています。 例えば、C6aはP4aとのセッションでCHILDです。
Radoslavov, et al. Experimental [Page 7] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[7ページ]RFC2909MASCプロトコル2000年9月
PARENT
A provider relationship exists whereby the remote node may obtain
address space from the local node. For example, T2a is a PARENT
in its session with P4a. Whether space is actually requested is
up to the implementation and local policy configuration.
遠隔ノードがローカルのノードからアドレス空間を得るかもしれないPARENT Aプロバイダー関係は存在しています。 例えば、T2aはP4aとのセッションでPARENTです。 スペースが実際に要求されているかどうかが実現と地方の方針構成まで達しています。
SIBLING
No customer-provider relationship exists. For example, T2a is a
SIBLING in its session with T1a (Top-Level Domain SIBLING
peering). Also, C6b is a SIBLING in its session with C7a with
regard to their common parent P4.
SIBLINGいいえ顧客プロバイダー関係は存在しています。 例えば、T2aはT1a(トップレベルDomain SIBLINGのじっと見る)とのセッションでSIBLINGです。 また、C6bはそれらの一般的な親P4に関するC7aとのセッションでSIBLINGです。
A node's message will be propagated to its parent, all siblings with the same parent, and its children. Since a domain need not have a direct peering session with every sibling, a MASC domain must propagate messages from a child domain to other children, can propagate messages from a parent domain to other siblings, and, if a Top-Level Domain, it must propagate messages from a sibling to other siblings, otherwise may propagate messages from a sibling domain to its parent and other siblings.
ノードのメッセージは親、同じ親と一緒にいるすべての兄弟、およびその子供に伝播されるでしょう。 兄弟から他の兄弟までメッセージを伝播しなければなりません。ドメインがすべての兄弟とのダイレクトじっと見るセッションを過す必要はないので、MASCドメインが子供ドメインから他の子供までメッセージを伝播しなければならなくて、親ドメインから他の兄弟までメッセージを伝播できて、Top-レベルDomainであるなら、それは、そうでなければ、兄弟ドメインから親と他の兄弟までメッセージを伝播するかもしれません。
4.1. Managed vs Locally-Allocated Space
4.1. 局所的に割り振りスペースに対して管理されます。
Each domain has a "Managed" Address Set, and a "Locally-Allocated" Address Set. The "managed" space includes all address space which a domain has successfully claimed via MASC. The "locally-allocated" space, on the other hand, includes all address space which MAASs inside the domain may use. Thus, the locally-allocated space is a subset of the managed space, and refers to the portion which a domain allocates for its own use.
各ドメインには、「管理された」Address Set、および「局所的に割り当てられた」Address Setがあります。 「管理された」スペースはドメインがMASCを通して首尾よく要求したすべてのアドレス空間を含んでいます。 他方では、「局所的に割り当てられた」スペースはドメインの中のMAASsが使用するかもしれないすべてのアドレス空間を含んでいます。 したがって、局所的に割り振りスペースは、管理されたスペースの部分集合であり、ドメインがそれ自身の使用のために割り当てる部分について言及します。
For leaf domains (ones with no children), these two sets are identical, since all claimed space is allocated for local use. A parent domain, on the other hand, "manages" all address space which it has claimed via MASC, while sub-prefixes can be allocated to itself and to its children.
葉のドメイン(子供のいないもの)に、これらの2セットは同じです、すべてが、スペースが地方の使用のために割り当てられると主張したので。 他方では、親ドメインはそれがMASCを通して要求したすべてのアドレス空間を「管理します」、それ自体と、そして、その子供にサブ接頭語を割り当てることができますが。
4.2. Prefix Lifetime
4.2. 生涯を前に置いてください。
Each prefix has an associated lifetime. If a domain wants to use a prefix longer than its lifetime, that domain must "renew" the prefix BEFORE its lifetime expires (see Section 5.2). If the lifetime cannot be extended, then the domain should either retry later to extend, or should choose and claim another prefix.
各接頭語には、関連寿命があります。 ドメインであるなら、生涯、そのドメインより長い間接頭語を使用する必需品は寿命が吐き出す接頭語BEFOREを「更新しなければならない」(セクション5.2を見てください)。 生涯を広げることができないなら、ドメインは、別の接頭語を後で広がるように再試行するべきであるか、選んで、または要求するべきです。
Radoslavov, et al. Experimental [Page 8] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[8ページ]RFC2909MASCプロトコル2000年9月
After a prefix's lifetime expires, MASC nodes in the domain that own that prefix must stop using that prefix. The corresponding entry from the G-RIB database must be removed, and all information associated with the expired prefix may be deleted from the MASC node's local memory.
接頭語の寿命が期限が切れた後に、そのドメインのその接頭語を所有しているMASCノードは、その接頭語を使用するのを止めなければなりません。 G-RIBデータベースからの対応するエントリーを取り除かなければなりません、そして、MASCノードのローカルの記憶から満期の接頭語に関連しているすべての情報を削除するかもしれません。
4.3. Active vs. Deprecated Prefixes
4.3. 推奨しない接頭語に対してアクティブです。
Each prefix advertised by a parent to its children can be either "active" or "deprecated". A "deprecated" prefix is a prefix that the parent wishes to discontinue to use after its lifetime expires. The "active" prefixes only are candidates for size expansion or lifetime extension. Usually, this information will be used by a child as a hint to know which of the parent's prefixes might have their lifetime extended.
子供の親によって広告に掲載されたそれぞれの接頭語は、「アクティブである」か「推奨しないことができます」。 寿命が期限が切れた後に「推奨しない」接頭語は親が使用として中止したがっている接頭語です。 唯一の「アクティブな」接頭語はサイズ拡大か生涯拡大の候補です。 通常、親の接頭語について彼らの生涯を持っているかもしれない知るヒントが広がったので、この情報は子供によって使用されるでしょう。
4.4. Multi-Parent Sibling-to-Sibling and Internal Peering
4.4. マルチ親の兄弟から兄弟と内部のじっと見ること
Two sibling nodes that have more than one common parent will create and use between them a number of transport-level connections, one per each common parent. The information associated with a parent will be sent over the connection that corresponds to the same parent. Internal peers do not need to open multiple connections between them; a single connection is used for all information.
1人以上の一般的な親がいる2つの兄弟ノードが、それらの間で多くのそれぞれの一般的な親あたり1つ歳の輸送レベル接続を創造して、使用するでしょう。 同じ親に文通する接続の上に親に関連している情報を送るでしょう。 内部の同輩は彼らの間の複数の接続を開く必要はありません。 単独結合はすべての情報に使用されます。
4.5. Administratively-Scoped Address Allocation
4.5. 行政上見られたアドレス配分
MASC can also be used for sub-allocating prefixes of addresses within an administrative scope zone [SCOPE], but only if the scope is "divisible" (as described in [MALLOC] and [MZAP]). A MASC node can learn what scopes it resides within by listening to MZAP [MZAP] messages.
また、範囲が「分割可能である」場合にだけ([MALLOC]と[MZAP]で説明されるように)、アドレスのサブの割り当て接頭語に管理範囲ゾーン[SCOPE]の中でMASCを使用できます。 MASCノードは、それがどんな範囲で住んでいるかをMZAP[MZAP]メッセージを聞くことによって、学ぶことができます。
A "Zone TLD" is a domain which has no parent domain within the scope zone. Zone TLDs act as TLDs for the prefix associated with the scope. Figure 2 gives an example, where a scope boundary around domains P3 and C5 has been added to Figure 1. Domain P3 is a Zone TLD, since its only parent (T1) is outside the boundary. Hence, P3 can claim space directly out of the prefix associated with the scope itself. Domain C5, on the other hand, has a parent within the scope (namely, P3), and hence is not a Zone TLD.
「ゾーンTLD」は範囲ゾーンの中に親ドメインを全く持っていないドメインです。 接頭語のためのTLDsが範囲と交際したので、ゾーンTLDsは行動します。 図2(ドメインのP3とC5の周りの範囲境界を図1に追加してあります)は作例を示します。 唯一の親(T1)が境界の外にいるので、ドメインP3はZone TLDです。 したがって、P3は直接範囲自体に関連している接頭語からスペースを要求できます。 ドメインC5は他方では、親が範囲(すなわち、P3)の中にいて、したがって、Zone TLDではありません。
Radoslavov, et al. Experimental [Page 9] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[9ページ]RFC2909MASCプロトコル2000年9月
T1a-----------T2a
| |
............|....... |
. | . |
. P3a====P3b . P4a
. | | . /
. | | _______/
. | | / .
. | | / .
. C5a====C5b .
. \\ // .
. \\// .
. C5c .
. .
. Admin Scope Zone .
....................
T1a-----------T2a| | ............|....... | . | . | . P3a====P3b P4a。| | . / . | | _______/ . | | / . . | | /C5a====C5b\\//\\//C5c… アドミン範囲ゾーン。
Figure 2: Scope Zone Example
図2: 範囲ゾーンの例
It is assumed that the role of a node (as discussed in Section 4) with respect to a given peering session is the same for every scope in which both ends are contained. A peering session that crosses a scope boundary (such as the session between C5b and P4a in Figure 2) is ignored when propagating messages that pertain to the given scope. That is, such messages are not sent across such sessions.
両端が保管されているあらゆる範囲に、与えられたじっと見るセッションに関するノード(セクション4で議論するように)の役割が同じであると思われます。 与えられた範囲に関係するメッセージを伝播するとき、範囲境界(図2のC5bとP4aとのセッションなどの)に交差するじっと見るセッションは無視されます。 すなわち、そのようなメッセージはそのようなセッションの向こう側に送られません。
5. Protocol Details
5. プロトコルの詳細
5.1. Claiming Space
5.1. スペースを要求します。
When a MASC node, on behalf of a MASC domain, needs more address space, it decides locally the size and the value of the address prefix(es) it will claim from one of its parents. For example, the decision might be based on the knowledge this node has about its parent's address set, its siblings' claims and allocations, its own address set, the claim messages from its siblings, and/or the demand pattern of its children and the local domain. A sample algorithm is given in Appendix A.
MASCノードがMASCドメインを代表して、より多くのアドレス空間を必要とすると、それは局所的にそれが両親のひとりから要求するアドレス接頭語(es)のサイズと値について決めます。 例えば、決定はこのノードが兄弟の親のアドレスセット、クレーム、および配分に関して持っている知識、それ自身のアドレスセット、兄弟からのクレームメッセージ、そして/または、子供の要求模範と局所領域に基づくかもしれません。 Appendix Aでサンプルアルゴリズムを与えます。
A MASC node which is not in a top-level domain can initiate a claim toward a parent MASC domain if and only if it currently has an established connection with at least one node in that parent domain.
そして、最上位のドメインにはないMASCノードが親MASCドメインに向かってクレームを開始できる、それに少なくとも1つのノードとの確立した接続が現在その親ドメインにある場合にだけ。
After the prefix address and size are decided, the claim proceeds as follows:
接頭語アドレスとサイズが決められた後に、クレームは以下の通り続きます:
Radoslavov, et al. Experimental [Page 10] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[10ページ]RFC2909MASCプロトコル2000年9月
a) The claim is scheduled to be sent after a random delay in the
interval (0, [INITIATE_CLAIM_DELAY]). If a claim originated by a
node from the same MASC domain is received, and that claim
eliminates the need for the local claim, the local claim is
canceled and no further action is taken.
a) 無作為の遅れの後に間隔でクレームは送られる予定です(0、[INITIATE_クレーム_DELAY])。 同じMASCドメインからのノードによって溯源されたクレームが受け取られていて、そのクレームがローカルのクレームの必要性を排除するなら、ローカルのクレームを中止します、そして、さらなる行動を全く取りません。
b) The claim is sent to one of the parents (if the domain is not a
top-level domain), all known siblings with the same parent, and
all internal peers. A Claim-Timer is then started at
[WAITING_PERIOD], and the MASC node starts listening for colliding
claims.
b) 両親(ドメインが最上位のドメインでないなら)、同じ親と一緒にいるすべての知られている兄弟、およびすべての内部の同輩のひとりにクレームを送ります。 そして、クレームタイマは[WAITING_PERIOD]、および衝突するために聴くのが要求するMASCノード始めで始動されます。
c) If a colliding claim is received while the Claim-Timer is running,
that claim is compared with the locally initiated claim using the
function described in Section 5.1.1. If the local claim is the
loser, a new prefix must be chosen to claim, and the loser claim's
Claim-Timer must be canceled. The loser claim can be either
explicitly withdrawn, or can be left to expire without taking
further actions. If the winning claim was originated by a node
from the same MASC domain, no new claim will be initiated. If the
local claim is the winner, no actions need to be taken.
c) クレームタイマが動いている間、衝突クレームが受け取られているなら、そのクレームはセクション5.1.1で説明された機能を使用する局所的に開始しているクレームにたとえられます。 ローカルのクレームがひどいしろものであるなら、新しい接頭語にクレームを選ばなければなりません、そして、敗者クレームのクレームタイマを取り消さなければなりません。 敗者クレームを明らかに引き下がることができるか、またはさらなる行動を取らないで期限が切れるのを残すことができます。 勝利クレームが同じMASCドメインからのノードによって溯源されたなら、どんな新しいクレームも開始されないでしょう。 ローカルのクレームが勝者であるなら、どんな動作も、取られる必要がありません。
d) If the Claim-Timer expires, the claimed prefix becomes associated
with the claimer's domain, i.e. it is considered allocated to that
domain and the following actions can be performed:
d) クレームタイマが期限が切れるなら、要求された接頭語はクレーマーのドメインに関連するようになります、そして、そのドメインに割り当てられるとすなわち、それを考えます、そして、以下の動作は実行できます:
o Advertise the prefix to its parent, and to all siblings with
the same parent, by sending a PREFIX_IN_USE claim to them.
o 同じ親と共に親と、そして、すべての兄弟への接頭語の広告を出してください、PREFIX_IN_USEクレームを彼らに送ることによって。
o Inject the prefix into the G-RIB of the inter-domain routing
protocol.
o 相互ドメインルーティング・プロトコルのG-RIBに接頭語を注いでください。
o Send a PREFIX_MANAGED message to all children and internal
peers, informing them that they may issue claims within the
managed space. A sub-prefix may then be claimed for local
usage (see Section 12.2).
o PREFIX_MANAGEDメッセージをすべての子供と内部の同輩に送ってください、彼らが管理されたスペースの中でクレームを発行するかもしれないことを彼らに知らせて。 そして、サブ接頭語はローカルの用法に代金を請求されるかもしれません(セクション12.2を見てください)。
Each MASC node receives all claims from its siblings and children. A received claim must be evaluated against all claims saved in the local cache using the function described in Section 5.1.1. The output of the function will define the further processing of that claim (see Section 11).
それぞれのMASCノードはその兄弟と子供からすべてのクレームを受け取ります。 ローカルなキャッシュでセクション5.1.1で説明された機能を使用することで保存されたすべてのクレームに対して受け取られていているクレームを評価しなければなりません。 機能の出力はそのクレームのさらなる処理を定義するでしょう(セクション11を見てください)。
Radoslavov, et al. Experimental [Page 11] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[11ページ]RFC2909MASCプロトコル2000年9月
5.1.1. Claim Comparison Function
5.1.1. クレーム比較関数
Each claim message includes:
それぞれのクレームメッセージは:
o a "type", being one of: PREFIX_IN_USE, CLAIM_DENIED,
CLAIM_TO_EXPAND, or NEW_CLAIM (PREFIX_MANAGED and WITHDRAW are
not considered as claims that have to be compared)
o 「タイプ」、以下の存在1 クレーム_が、_へのクレーム_が広げることを否定した_使用、または新しい_クレームにおける接頭語_(比べて、PREFIX_MANAGEDとWITHDRAWはそうしなければならないクレームであるとみなされません)
o timestamp when the claim was initiated
o クレームであるときに、タイムスタンプは開始されました。
o the claimed prefix and lifetime
o 要求された接頭語と生涯
o MASC Identifier of the node that originated the claim
o クレームを溯源したノードのMASC Identifier
When two claims are compared, first the type is compared based on the following precedence:
2つのクレームが比べるとき、最初に、タイプは以下の先行に基づいて比較されます:
PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_CLAIM
_使用での>クレーム_が>の新しい_クレームを広げることを_への>クレーム_を否定した接頭語_
If the type is the same, then the timestamps are used to compare the claims. In practice, two claims will have the same type if the type is either NEW_CLAIM (ordinary collision) or PREFIX_IN_USE (signal for a clash). When the timestamps are compared, the claim with the smallest, i.e. earliest timestamp wins. If the timestamps are the same, then the claim with the smallest Origin Node Identifier wins.
タイプが同じであるなら、タイムスタンプは、クレームを比較するのに使用されます。2つのクレームには、実際には、同じタイプがタイプがNEW_クレーム(普通の衝突)かPREFIX_INのどちらか_USE(衝突には、合図する)であるならあるでしょう。 タイムスタンプが比べるとき、最も小さくて、すなわち、最も初期のタイムスタンプがあるクレームは得られます。 タイムスタンプが同じであるなら、最も小さいOrigin Node Identifierとのクレームは得られます。
5.2. Renewing an Existing Claim
5.2. 既存のクレームを更新します。
The procedure for extending the lifetime of prefixes already in use is the same as claiming new space (see Section 5.1), except that the claim type must be CLAIM_TO_EXPAND, while the Address and the Mask of the claim (see Section 7.3) must be the same as the already allocated prefix. If the Claim-Timer expires and there is no collision, the desired lifetime is assumed.
既に使用中の接頭語の生涯を広げるための手順は新しいスペースを要求するのと同じです(セクション5.1を見てください)、クレームタイプがクレーム_TO_EXPANDであるに違いないのを除いて、クレーム(セクション7.3を見る)のAddressとMaskは既に割り当てられた接頭語と同じであるに違いありませんが。 クレームタイマが期限が切れて、衝突が全くなければ、必要な寿命は想定されます。
5.3. Expanding an Existing Prefix
5.3. 既存の接頭語を広げます。
The procedure for extending the lifetime of prefixes already in use is the same as claiming new space (see Section 5.1), except that the claim type must be CLAIM_TO_EXPAND, while the Address and the Mask of the claim (see Section 7.3) must be set to the desired values. If the Claim-Timer expires and there is no collision, the desired larger prefix is associated with the local domain.
既に使用中の接頭語の生涯を広げるための手順は新しいスペースを要求するのと同じです(セクション5.1を見てください)、クレームタイプがクレーム_TO_EXPANDであるに違いないのを除いて、クレーム(セクション7.3を見る)のAddressとMaskは目標値に用意ができなければなりませんが。 クレームタイマが期限が切れて、衝突が全くなければ、必要なより大きい接頭語は局所領域に関連しています。
Radoslavov, et al. Experimental [Page 12] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[12ページ]RFC2909MASCプロトコル2000年9月
5.4. Releasing Allocated Space
5.4. 割り振りスペースをリリースします。
If the lifetime of a prefix allocated to the local domain expires and the domain does not need to reuse it, all resources associated with this prefix are deleted and no further actions are taken. If the lifetime of the prefix has not expired, and if no subranges of that prefix have being allocated for local usage or by some of the children domains, the space may be released by sending a withdraw message to the parent domain, all known siblings with the same parent, and all internal peers.
局所領域に割り当てられた接頭語の寿命が期限が切れて、ドメインがそれを再利用する必要はないなら、この接頭語に関連しているすべてのリソースを削除します、そして、さらなる行動を全く取りません。 接頭語の寿命が期限が切れていなくて、またローカルの用法か子供ドメインのいくつかでその接頭語のサブレンジを全く割り当てていないなら、同じ親、およびすべての内部の同輩と共に親ドメインにメッセージを引き下がらせている、知られている兄弟を皆、送ることによって、スペースをリリースするかもしれません。
6. Constants
6. 定数
MASC uses the following constants:
MASCは以下の定数を使用します:
[PORT_NUMBER]
2587. The TCP port number used to listen for incoming MASC
connections, as assigned by IANA.
[ポート_数。]2587 IANAによって割り当てられるようにTCPポートナンバーは以前はよく入って来るMASC接続の聞こうとしていました。
[WAITING_PERIOD]
The amount of time (in seconds) that must pass between a NEW_CLAIM
(or CLAIM_TO_EXPAND), and a PREFIX_IN_USE for the same prefix.
This must be long enough to reasonably span any single inter-
domain network partition. Default: 172800 seconds (i.e. 48
hours).
[WAITING_PERIOD]それが同じ接頭語のためにNEW_クレーム(_がTO_EXPANDであることを要求する)と、PREFIX_INの間で_USEを渡さなければならない時間(秒の)。 これは合理的にどんなただ一つの相互ドメインネットワークパーティションにもかかることができるくらい長くなければなりません。 デフォルト: 172800秒(すなわち、48時間)。
[INITIATE_CLAIM_DELAY]
The amount of time (in seconds) a MASC node must wait before
initiating a new claim or a claim for space expansion. This must
be a random value in the interval (0, [INITIATE_CLAIM_DELAY]).
Default value for [INITIATE_CLAIM_DELAY]: 600 seconds (i.e. 10
minutes).
[INITIATE_クレーム_DELAY]スペース拡張のために新しいクレームかクレームを開始する前にMASCノードが待たなければならない時間(秒の)。 これは間隔(0、[INITIATE_クレーム_DELAY])の無作為の値であるに違いありません。 [INITIATE_クレーム_DELAY]のためのデフォルト値: 600秒(すなわち、10分)。
[TLD_ID]
The Parent Domain Identifier used by a Top-Level Domain (which has
no parent). Must be 0.
[TLD_ID] Top-レベルDomain(親が全くいない)によって使用されたParent Domain Identifier。 0はそうであるに違いありませんか?
[HOLDTIME]
The amount of time (in seconds) that must pass without any
messages received from a remote node before considering the
connection is down. Default: 240 seconds (i.e. 4 minutes).
[HOLDTIME] 接続を考える前に遠隔ノードから受け取られた少しもメッセージなしで経過しなければならない時間(秒の)は下がっています。 デフォルト: 240秒(すなわち、4分)。
Radoslavov, et al. Experimental [Page 13] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[13ページ]RFC2909MASCプロトコル2000年9月
7. Message Formats
7. メッセージ・フォーマット
This section describes message formats used by MASC.
このセクションはMASCによって使用されたメッセージ・フォーマットについて説明します。
Messages are sent over a reliable transport protocol connection. A message is processed only after it is entirely received. The maximum message size is 4096 octets. All implementations are required to support this maximum message size.
頼もしい輸送プロトコル接続の上にメッセージを送ります。 それを完全に受け取った後にだけメッセージを処理します。 最大のメッセージサイズは4096の八重奏です。 すべての実現が、この最大のメッセージサイズを支持するのに必要です。
7.1. Message Header Format
7.1. メッセージヘッダー形式
Each message has a fixed-size (4-octets) header. There may or may not be a data portion following the header, depending on the message type. The layout of these fields is shown below:
各メッセージには、固定サイズ(4八重奏)ヘッダーがあります。 メッセージタイプに頼っていて、ヘッダーに続くデータ部があるかもしれません。 これらの分野のレイアウトは以下に示されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| タイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length:
This 2-octet unsigned integer indicates the total length of the
message, including the header, in octets. Thus, e.g., it allows
one to locate in the transport-level stream the start of the next
message. The value of the Length field must always be at least 4
and no greater than 4096, and may be further constrained,
depending on the message type. No "padding" of extra data after
the message is allowed, so the Length field must have the smallest
value required given the rest of the message.
長さ: この2八重奏の符号のない整数は八重奏にヘッダーを含むメッセージの全長を示します。 このようにして、そして、例えば、それで、1つは輸送レベルの流れで次のメッセージの始まりの場所を見つけることができます。 Length分野の値は、いつも少なくとも4と、4096以下と、さらに抑制されるかもしれなくて、メッセージタイプに頼ることでなければなりません。 メッセージが許容された後に余分なデータのどんな「詰め物」によっても、メッセージの残りを考えて、Length分野で最も小さい値を必要としてはいけません。
Type:
This 1-octet unsigned integer indicates the type code of the
message. The following type codes are defined:
以下をタイプしてください。 この1八重奏の符号のない整数はメッセージのタイプコードを示します。 以下のタイプコードは定義されます:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
1--開いている2--アップデート3--通知4--KEEPALIVE
Reserved:
This 1-octet field is reserved. MUST be set to zero by the sender,
and MUST be ignored by the receiver.
予約される: この1八重奏の分野は予約されています。 送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
Radoslavov, et al. Experimental [Page 14] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[14ページ]RFC2909MASCプロトコル2000年9月
7.2. OPEN Message Format
7.2. 開いているメッセージ・フォーマット
After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
輸送プロトコル接続が確立された後に、それぞれの側によって送られた最初のメッセージはオープンメッセージです。 オープンメッセージが許容できるなら、オープンを確認するKEEPALIVEメッセージは返送されます。 いったんオープンを確認すると、UPDATE、KEEPALIVE、およびNOTIFICATIONメッセージを交換するかもしれません。
The minimum length of the OPEN message is 20 octets (including message header). In addition to the fixed-size MASC header, the OPEN message contains the following fields:
オープンメッセージの最小の長さは20の八重奏(メッセージヘッダーを含んでいて)です。 固定サイズMASCヘッダーに加えて、オープンメッセージは以下の分野を含んでいます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |R| AddrFam |Rol| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MASC Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent's Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン|R| AddrFam|Rol| 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者Domain Identifier(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者MASC Node Identifier(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 親のDomain Identifier(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + (任意のパラメタ)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
This 1-octet unsigned integer indicates the protocol version
number of the message. The current MASC version number is 1.
バージョン: この1八重奏の符号のない整数はメッセージのプロトコルバージョン番号を示します。 現在のMASCバージョン番号は1です。
R bit:
This 1-bit field is reserved. MUST be set to zero by the sender,
and MUST be ignored by the receiver.
Rに噛み付きました: この1ビットの分野は予約されています。 送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
AddrFam:
This 5-bit field is the IANA-assigned address family number of the
encoded prefix [IANA]. These include (among others):
AddrFam: この5ビットの分野はコード化された接頭語[IANA]のIANA-割り当てられたアドレスファミリーナンバです。 これらは以下を含んでいます(特に)。
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
数の記述------ ----------- 1 IP(IPバージョン4)2IPv6(IPバージョン6)
Radoslavov, et al. Experimental [Page 15] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[15ページ]RFC2909MASCプロトコル2000年9月
My Role (Rol):
This 2-bit field indicates the proposed relationship of the
sending system to the receiving system:
00 = INTERNAL_PEER (sent from one internal peer to another)
01 = CHILD (sent from a child to its parent)
10 = SIBLING (sent from one sibling to another)
11 = PARENT (sent from a parent to its child)
私の役割(Rol): この2ビットの分野は送付システムの提案された関係を受電方式に示します: 00 = INTERNAL_PEER(1人の内部の同輩から別の同輩まで発信する)01=CHILD(子供から親まで発信する)10=SIBLING(1人の兄弟から別の兄弟まで発信する)11はPARENTと等しいです。(親から子供まで発信します)
Hold Time:
This 2-octet unsigned integer indicates the number of seconds that
the sender proposes for the value of the Hold Timer. Upon receipt
of an OPEN message, a MASC speaker MUST calculate the value of the
Hold Timer by using the smaller of its configured Hold Time for
that peer and the Hold Time received in the OPEN message. The
Hold Time MUST be either zero or at least three seconds. An
implementation may reject connections on the basis of the Hold
Time. The calculated value indicates the maximum number of
seconds that may elapse between the receipt of successive
KEEPALIVE and/or UPDATE messages by the sender. RECOMMENDED value
is [HOLDTIME] seconds.
保持時間: この2八重奏の符号のない整数は送付者がHold Timerの値のために提案する秒数を示します。 オープンメッセージを受け取り次第、MASCスピーカーは、オープンメッセージに受け取られたその同輩とHold Timeに構成されたHold Timeについて、より小さいのを使用することによって、Hold Timerの値について計算しなければなりません。 Hold Timeはゼロか少なくとも3秒のどちらかでなければなりません。 実現はHold Timeに基づいて接続を拒絶するかもしれません。 計算された値は連続したKEEPALIVE、そして/または、UPDATEメッセージの領収書の間で送付者で経過するかもしれない秒の最大数を示します。 RECOMMENDED値は[HOLDTIME]秒です。
Sender Domain Identifier:
A globally unique identifier. Its length is determined based on
the Address Family, and should be treated as an unsigned integer
(e.g. a 4-octet integer for IPv4, or a 16-octet integer for IPv6),
but must be at least 4 octets long. It should be set to the
Autonomous System number of the sender, but the network unicast
prefix address is also acceptable.
送付者ドメイン識別子: グローバルにユニークな識別子。 長さは、Address Familyに基づいて断固として、符号のない整数として扱われるべきですが(例えば、IPv4のための4八重奏の整数、またはIPv6のための16八重奏の整数)、長い間少なくとも4つの八重奏であるに違いありません。 それは送付者のAutonomous System番号に設定されるべきですが、また、ネットワークユニキャスト接頭語アドレスも許容できます。
Sender MASC Node Identifier:
This field's length and format are same as the Sender Domain
Identifier field, and indicates the MASC Node Identifier of the
sender. A given MASC speaker sets the value of its MASC Node
Identifier to a globally-unique value assigned to that MASC
speaker (e.g., an IPv4 or IPv6 address). The value of the MASC
Node Identifier is determined on startup and is the same for every
MASC session opened.
送付者MASCノード識別子: このフィールドの長さと形式はSender Domain Identifierが送付者のMASC Node Identifierをさばいて、示すのと同じです。 与えられたMASCスピーカーはそのMASCスピーカー(例えば、IPv4かIPv6アドレス)に割り当てられたグローバルにユニークな値にMASC Node Identifierの値を設定します。 MASC Node Identifierの値は、始動で決定していて、開かれたあらゆるMASCセッションのために同じです。
Parent's Domain Identifier:
This field's length and format are same as the Sender Domain
Identifier field, and is set to the Domain Identifier of the
sender's parent (e.g. the parent's Autonomous System number, or
network prefix address), or is set to [TLD_ID] if the sender is a
TLD. Used only when Rol is INTERNAL_PEER or SIBLING, otherwise is
ignored. This field is used to determine the common parents
between siblings, to associate each sibling-to-sibling connection
with a particular parent, and to discover TLD-related
親のドメイン識別子: このフィールドの長さと形式は、Sender Domain Identifier分野と同じであり、送付者の親(例えば、親のAutonomous System番号、またはネットワーク接頭語アドレス)のDomain Identifierに設定されるか、または送付者がTLDであるなら[TLD_ID]に設定されます。 RolがINTERNAL_PEERかSIBLINGであり、別の方法で無視されるときだけ、使用されます。 この分野が兄弟の間の一般的な両親を決定して、特定の親との兄弟から兄弟とのそれぞれの接続を関連づけるのに使用される、発見する、TLD関連
Radoslavov, et al. Experimental [Page 16] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[16ページ]RFC2909MASCプロトコル2000年9月
configuration problems among internal peers. If a non-TLD node
does not know yet the Domain ID of any of its parents, it can use
its own Domain ID in the OPEN messages to its internal peers.
内部の同輩の中の設定問題。 非TLDノードが両親のいずれについてもまだDomain IDを知っていないなら、それはオープンメッセージでそれ自身のDomain IDを内部の同輩に使用できます。
Optional Parameters:
This field may contain a list of optional parameters, where each
parameter is encoded as a <Parameter Length, Parameter Type,
Parameter Value> triplet. The combined length of all optional
parameters can be derived from the Length field in the message
header.
任意のパラメタ: この分野は任意のパラメタのリストを含むかもしれません、Parameter Type、Parameter Value>三つ子。そこでは、各パラメタが<Parameter Lengthとしてコード化されます。 メッセージヘッダーのLength分野からすべての任意のパラメタの結合した長さを得ることができます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Length | Parm. Type | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Parm。 長さ| Parm。 タイプ| パラメタ価値(可変)の++++++++++++++++++++、-、…
Parameter Length is a one octet field that contains the length of
the Parameter Value field in octets. Parameter Type is a one
octet field that unambiguously identifies individual parameters.
Parameter Value is a variable length field that is interpreted
according to the value of the Parameter Type field. Unrecognized
optional parameters MUST be silently ignored.
パラメタLengthは八重奏における、Parameter Value分野の長さを含む1つの八重奏分野です。 パラメタTypeは明白に個々のパラメタを特定する1つの八重奏分野です。 パラメタValueはParameter Type分野の値に従って解釈される可変長フィールドです。 静かに認識されていない任意のパラメタを無視しなければなりません。
This document does not define any optional parameters.
このドキュメントはどんな任意のパラメタも定義しません。
7.3. UPDATE Message Format
7.3. アップデートメッセージ・フォーマット
UPDATE messages are used to transfer Claim/Collision/PrefixManaged information between MASC speakers. The UPDATE message always includes the fixed-size MASC header, and one or more attributes as described below. The minimum length of the UPDATE message is 40 octets (including the message header).
UPDATEメッセージは、クレーム/衝突/PrefixManaged情報をMASCスピーカーの間に移すのに使用されます。 UPDATEメッセージはいつも以下で説明される固定サイズMASCヘッダー、および1つ以上の属性を含んでいます。 UPDATEメッセージの最小の長さは40の八重奏(メッセージヘッダーを含んでいて)です。
Each attribute is of the form:
各属性はフォームのものです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| タイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All attributes are 4-octets aligned.
すべての属性が並べられた4八重奏です。
Radoslavov, et al. Experimental [Page 17] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[17ページ]RFC2909MASCプロトコル2000年9月
Length:
The Length is the length of the entire attribute, including the
length, type, and data fields. If other attributes are nested
within the data field, the length includes the size of all such
nested attributes.
長さ: Lengthは長さ、タイプ、およびデータ・フィールドを含む全体の属性の長さです。 他の属性がデータ・フィールドの中で入れ子にされるなら、長さはそのようなすべての入れ子にされた属性のサイズを含んでいます。
Type:
This 1-octet unsigned integer indicates the type code of the
attribute. The following type codes are defined:
以下をタイプしてください。 この1八重奏の符号のない整数は属性のタイプコードを示します。 以下のタイプコードは定義されます:
0 = PREFIX_IN_USE (prefix is being used by the origin)
1 = CLAIM_DENIED (the claim is refused (probably by the
origin's parent domain))
2 = CLAIM_TO_EXPAND (origin is trying to expand the size of
an existing prefix)
3 = NEW_CLAIM (origin is trying to claim a new prefix)
4 = PREFIX_MANAGED (parent is informing child of space
available)
5 = WITHDRAW (origin is withdrawing a previous claim)
0 = 1PREFIX_IN_USE(接頭語は起源によって使用されている)=クレーム_DENIED(クレームは拒否されます(たぶん起源の親ドメインのそばで))2=クレームNEW_TO_EXPAND(起源は既存の接頭語のサイズを広げようとしている)3=_は、4=PREFIX_がMANAGED(親は利用可能なスペースについて子供に知らせている)5=WITHDRAWであることを要求します(起源は新しい接頭語を要求しようとしています)。(起源は前のクレームを引き下がらせています)
Types 128-255 are reserved for "optional" attributes. If a
required attribute is unrecognized, a NOTIFICATION with UPDATE
Error Code and Unrecognized Required Attribute subcode will be
sent. Unrecognized optional attributes are simply ignored.
タイプ128-255は「任意」の属性のために予約されます。 必要な属性が認識されていないなら、UPDATE Error CodeとNOTIFICATIONとUnrecognized Required Attribute部分符号を送るでしょう。 認識されていない任意の属性は単に無視されます。
Reserved:
This 1-octet field is reserved. MUST be set to zero by the
sender, and MUST be ignored by the receiver.
予約される: この1八重奏の分野は予約されています。 送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
Types 0-3 are collectively called "CLAIMs". The message format below describes the encoding of a CLAIM, PREFIX_MANAGED and WITHDRAW.
タイプ0-3はまとめて「クレーム」と呼ばれます。 以下のメッセージ・フォーマットはクレーム、PREFIX_MANAGED、およびWITHDRAWのコード化について説明します。
Radoslavov, et al. Experimental [Page 18] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[18ページ]RFC2909MASCプロトコル2000年9月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 |D| AddrFam |Rol| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved1|D| AddrFam|Rol| Reserved2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クレームタイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯を要求してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クレームHoldtime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 起源Domain Identifier(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 起源Node Identifier(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マスク(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + (任意のパラメタ)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved1:
This 1-octet field is reserved. MUST be set to zero by the
sender, and MUST be ignored by the receiver.
Reserved1: この1八重奏の分野は予約されています。 送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
D-bit:
DEPRECATED_PREFIX bit. If set, indicates that the advertised
address prefix is Deprecated, otherwise the prefix is Active (see
Section 4.3).
D-ビット: DEPRECATED_PREFIXは噛み付きました。 セットして、広告を出しているアドレス接頭語がDeprecated、さもなければ、接頭語がActiveであるということであることを示します(セクション4.3を見ます)。
AddrFam:
This 5-bit field is the IANA-assigned address family number of the
encoded prefix [IANA].
AddrFam: この5ビットの分野はコード化された接頭語[IANA]のIANA-割り当てられたアドレスファミリーナンバです。
Rol:
This 2-bit field indicates the relationship/role of the Origin of
the message to the node sending that message:
00 = INTERNAL (originated by the sender's domain)
01 = CHILD (originated by a child of the sender's domain)
10 = SIBLING (originated by a sibling of the sender's domain)
11 = PARENT (originated by a parent of the sender's domain)
Rol: この2ビットの分野はメッセージのOriginの関係/役割をそのメッセージを送るノードに示します: 00 = INTERNAL(送付者のドメインで、溯源される)01=CHILD(送付者のドメインの子供によって溯源される)10=SIBLING(送付者のドメインの兄弟によって溯源される)11はPARENTと等しいです。(送付者のドメインの親によって溯源されます)
Reserved2:
This 2-octet field is reserved. MUST be set to zero by the
sender, and MUST be ignored by the receiver.
Reserved2: この2八重奏の分野は予約されています。 送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
Radoslavov, et al. Experimental [Page 19] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[19ページ]RFC2909MASCプロトコル2000年9月
Claim Timestamp:
The timestamp of the claim when it was originated. The timestamp
is expressed in number of seconds since midnight (0 hour), January
1, 1970, Greenwich.
タイムスタンプを要求してください: それであるときに、クレームに関するタイムスタンプは溯源されました。 (0時間)真夜中、1970年1月1日、グリニッジ以来タイムスタンプは秒数で言い表されます。
Claim Lifetime:
The time in seconds between the Claim Timestamp, and the time at
which the prefix will become free.
生涯を要求してください: クレームTimestampと、接頭語が自由になる時の間の秒の時間。
Claim Holdtime:
The time in seconds between the Claim Timestamp, and the time at
which the claim should be deleted from the local cache. For
PREFIX_IN_USE and PREFIX_MANAGED claims it should be equal to
Claim Lifetime; for CLAIM_TO_EXPAND, NEW_CLAIM, and CLAIM_DENIED
it should be equal to [WAITING_PERIOD].
Holdtimeを要求してください: クレームTimestampと、クレームがローカルなキャッシュから削除されるべきである時の間の秒の時間。 _PREFIX_INのUSEとPREFIX_に関しては、MANAGEDは、Lifetimeを要求するのが等しいはずであると主張します。 _クレームのTO_EXPAND、NEW_クレーム、およびクレーム_DENIEDにおいて、それは[WAITING_PERIOD]と等しいはずです。
Origin Domain Identifier:
The domain identifier of the claim originator. Its length and
format definition are same as the Sender Domain Identifier (see
Section 7.2).
起源ドメイン識別子: クレーム創始者のドメイン識別子。 その長さと形式定義はSender Domain Identifierと同じです(セクション7.2を見てください)。
Origin Node Identifier:
The MASC Node ID of the claim originator. Its length and format
definition are same as the Sender MASC Node Identifier (see
Section 7.2).
起源ノード識別子: クレーム創始者のMASC Node ID。 その長さと形式定義はSender MASC Node Identifierと同じです(セクション7.2を見てください)。
Address:
The address associated with the given prefix to be encoded. The
length is determined based on the Address Family (e.g. 4 octets
for IPv4, 16 for IPv6)
アドレス: アドレスは、コード化されるために与えられた接頭語と交際しました。 長さはAddress Familyに基づいて決定しています。(例えば、IPv4、IPv6のための16のための4つの八重奏)
Mask:
The mask associated with the given prefix. The length is the same
as the Address field and is determined based on the Address
Family. The field contains the full bitmask.
以下にマスクをかけてください。 マスクは与えられた接頭語と交際しました。 長さは、Address分野と同じであり、Address Familyに基づいて決定しています。 分野は完全なビットマスクを含んでいます。
Optional Parameters:
This field may contain a list of optional parameters, where each
parameter is encoded using same format as the optional parameters
of an OPEN message (see Section 7.2). Unrecognized optional
parameters MUST be silently ignored. This document does not
define any optional parameters.
任意のパラメタ: この分野は任意のパラメタのリストを含むかもしれません。(そこでは、各パラメタが、オープンメッセージの任意のパラメタと同じ形式を使用することでコード化されます(セクション7.2を見てください))。 静かに認識されていない任意のパラメタを無視しなければなりません。 このドキュメントはどんな任意のパラメタも定義しません。
Radoslavov, et al. Experimental [Page 20] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[20ページ]RFC2909MASCプロトコル2000年9月
7.4. KEEPALIVE Message Format
7.4. KEEPALIVEメッセージ・フォーマット
MASC does not use any transport protocol-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between the last KEEPALIVE or UPDATE message sent, and the time at which a KEEPALIVE message is sent, would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. An implementation MAY adjust the rate at which it sends KEEPALIVE messages as a function of the Hold Time interval.
MASCは、同輩が届くかどうか決定するのにどんな輸送のプロトコルベースの生きている生活費メカニズムも使用しません。 代わりに、Hold Timerが期限が切れることを引き起こさないで、同輩の間でKEEPALIVEメッセージをしばしば十分交換します。 KEEPALIVEかUPDATEメッセージが送った最終と、KEEPALIVEメッセージが送られる時の間の妥当な最大の時間はHold Time間隔の1/3でしょう。 1秒あたり1つより頻繁にKEEPALIVEメッセージを送ってはいけません。 実現はそれがHold Time間隔の機能としてメッセージをKEEPALIVEに送るレートを調整するかもしれません。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
交渉されたHold Time間隔がゼロであるなら、周期的なKEEPALIVEメッセージを送ってはいけません。
A KEEPALIVE message consists of only a message header, and has a length of 4 octets.
KEEPALIVEメッセージは、メッセージヘッダーだけから成って、4つの八重奏の長さを持っています。
7.5. NOTIFICATION Message Format
7.5. 通知メッセージ形式
A NOTIFICATION message is sent when an error condition is detected. Depending on the error condition, the MASC connection might or must be closed immediately after sending the message. If the sender of the NOTIFICATION decides that the connection is to be closed, it will indicate this by zeroing the O-bit in the NOTIFICATION message (see below).
エラー条件を検出するとき、NOTIFICATIONメッセージを送ります。 エラー条件によって、MASC接続は、閉店しなければならないかもしれないか、またはメッセージを送る直後閉店しなければなりません。 NOTIFICATIONの送付者が、接続が閉店していることになっていると決めると、それは、NOTIFICATIONメッセージでO-ビットのゼロを合わせることによって、これを示すでしょう(以下を見てください)。
In addition to the fixed-size MASC header, the NOTIFICATION message contains the following fields:
固定サイズMASCヘッダーに加えて、NOTIFICATIONメッセージは以下の分野を含んでいます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O| エラーコード| 誤り部分符号| データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O-bit:
Open-bit. If zero, it indicates that the sender will close the
connection. If '1', it indicates that the sender has chosen to
keep the connection open.
O-ビット: 抑えます開いている。 ゼロであるなら、それは、送付者が接続を終えるのを示します。 '1'であるなら、それは、送付者が、接続を開くように保つのを選んだのを示します。
Error Code:
This 7-bit unsigned integer indicates the type of NOTIFICATION.
The following Error Codes have been defined:
エラーコード: この7ビットの符号のない整数はNOTIFICATIONのタイプを示します。 以下のError Codesは定義されました:
Radoslavov, et al. Experimental [Page 21] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[21ページ]RFC2909MASCプロトコル2000年9月
Error Code Symbolic Name Reference
エラーコード英字名参照
1 Message Header Error Section 8.1
1 メッセージヘッダー誤り部分8.1
2 OPEN Message Error Section 8.2
2 開いているメッセージ誤り部8.2
3 UPDATE Message Error Section 8.3
3 アップデートメッセージ誤り部8.3
4 Hold Timer Expired Section 8.4
4 保持のタイマの満期の部分8.4
5 Finite State Machine Error Section 8.5
5 有限状態機械誤り部分8.5
6 NOTIFICATION Message Error Section 8.6
6 通知メッセージ誤り部8.6
7 Cease Section 8.7
7はセクション8.7をやめます。
Error subcode:
This 1-octet unsigned integer provides more specific information
about the nature of the reported error. Each Error Code may have
one or more Error Subcodes associated with it. If no appropriate
Error Subcode is defined, then a zero (Unspecific) value is used
for the Error Subcode field, and the O-bit must be zero (i.e. the
connection will be closed). The notation used in the error
description below is: MC = Must Close connection = O-bit is zero;
CC = Can Close connection = O-bit might be zero.
誤り部分符号: この1八重奏の符号のない整数は報告された誤りの本質の、より特定の情報を提供します。 各Error Codeには、それに関連している1Error Subcodesがあるかもしれません。 どんな適切なError Subcodeも定義されないなら、使用される(Unspecific)がError Subcode分野、およびO-ビットのために評価するゼロはゼロであるに違いありません(すなわち、接続は閉店するでしょう)。 以下でのエラー記述に使用される記法は以下の通りです。 =必須Close接続=ビットO-M.C.はゼロです。 CC=缶Close接続=O-ビットはゼロであるかもしれません。
Message Header Error subcodes:
0 - Unspecific (MC)
1 - Bad Message Length (MC)
2 - Bad Message Type (CC)
メッセージHeader Error部分符号: 0--Unspecific(M.C.)1--悪いメッセージ長(M.C.)2--悪いメッセージタイプ(CC)
OPEN Message Error subcodes:
オープンMessage Error部分符号:
0 - Unspecific (MC)
1 - Unsupported Version Number (MC)
2 - Bad Peer Domain ID (MC)
3 - Bad Peer MASC Node ID (MC)
6 - Unacceptable Hold Time (MC)
7 - Invalid Parent Configuration (MC)
8 - Inconsistent Role (MC)
9 - Bad Parent Domain ID (MC)
10 - No Common Parent (MC)
13 - Unrecognized Address Family (MC)
0--Unspecific(M.C.)1--サポートされないバージョン数の(M.C.)2--悪い同輩ドメインID(M.C.)3--悪い同輩MASCノードID(M.C.)6--容認できない保持時間(M.C.)7--無効の親構成(M.C.)8--矛盾した役割の(M.C.)9--悪い親ドメインID(M.C.)10--一般的な親(M.C.)がありません13--認識されていないアドレスファミリー(M.C.)
Radoslavov, et al. Experimental [Page 22] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[22ページ]RFC2909MASCプロトコル2000年9月
UPDATE Message Error subcodes:
0 - Unspecific (MC)
1 - Malformed Attribute List (MC)
2 - Unrecognized Required Attribute (CC)
5 - Attribute Length Error (MC)
10 - Invalid Address field (CC)
11 - Invalid Mask field (CC)
12 - Non-Contiguous Mask (CC)
13 - Unrecognized Address Family (MC)
14 - Claim Type Error (CC)
15 - Origin Domain ID Error (CC)
16 - Origin Node ID Error (CC)
17 - Claim Lifetime Too Short (CC)
18 - Claim Lifetime Too Long (CC)
19 - Claim Timestamp Too Old (CC)
20 - Claim Timestamp Too New (CC)
21 - Claim Prefix Size Too Small (CC)
22 - Claim Prefix Size Too Large (CC)
23 - Illegal Origin Role Error (CC)
24 - No Appropriate Parent Prefix (CC)
25 - No Appropriate Child Prefix (CC)
26 - No Appropriate Internal Prefix (CC)
27 - No Appropriate Sibling Prefix (CC)
28 - Claim Holdtime Too Short (CC)
29 - Claim Holdtime Too Long (CC)
UPDATE Message Error部分符号: 0 - Unspecific (MC) 1 - Malformed Attribute List (MC) 2 - Unrecognized Required Attribute (CC) 5 - Attribute Length Error (MC) 10 - Invalid Address field (CC) 11 - Invalid Mask field (CC) 12 - Non-Contiguous Mask (CC) 13 - Unrecognized Address Family (MC) 14 - Claim Type Error (CC) 15 - Origin Domain ID Error (CC) 16 - Origin Node ID Error (CC) 17 - Claim Lifetime Too Short (CC) 18 - Claim Lifetime Too Long (CC) 19 - Claim Timestamp Too Old (CC) 20 - Claim Timestamp Too New (CC) 21 - Claim Prefix Size Too Small (CC) 22 - Claim Prefix Size Too Large (CC) 23 - Illegal Origin Role Error (CC) 24 - No Appropriate Parent Prefix (CC) 25 - No Appropriate Child Prefix (CC) 26 - No Appropriate Internal Prefix (CC) 27 - No Appropriate Sibling Prefix (CC) 28 - Claim Holdtime Too Short (CC) 29 - Claim Holdtime Too Long (CC)
Hold Timer Expired subcodes (the O-bit is always zero):
Timer Expired部分符号(いつもO-ビットはゼロである)を保持してください:
0 - Unspecific (MC)
0--Unspecific(M.C.)
Finite State Machine Error subcodes:
有限州Machine Error部分符号:
0 - Unspecific (MC)
1 - Open/Close MASC Connection FSM Error (MC)
2 - Unexpected Message Type FSM Error (MC)
0--Unspecific(M.C.)1--開いているか近いMASC接続FSM誤り(M.C.)2--予期していなかったメッセージタイプFSM誤り(M.C.)
Cease subcodes (the O-bit is always zero):
部分符号(いつもO-ビットはゼロである)をやめてください:
0 - Unspecific (MC)
0--Unspecific(M.C.)
NOTIFICATION subcodes (the O-bit is always zero):
NOTIFICATION部分符号(いつもO-ビットはゼロです):
0 - Unspecific (MC)
0--Unspecific(M.C.)
Data:
This variable-length field is used to diagnose the reason for the
NOTIFICATION. The contents of the Data field depend upon the
Error Code and Error Subcode. See Section 8 for more details.
データ: この可変長の分野は、NOTIFICATIONの理由を診断するのに使用されます。 Data分野の内容はError CodeとError Subcodeによります。 その他の詳細に関してセクション8を見てください。
Radoslavov, et al. Experimental [Page 23] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[23ページ]RFC2909MASCプロトコル2000年9月
Note that the length of the Data field can be determined from the
message Length field by the formula:
公式でメッセージLength分野からData分野の長さを測定できることに注意してください:
Message Length = 6 + Data Length
メッセージ長は6+データの長さと等しいです。
The minimum length of the NOTIFICATION message is 6 octets
(including message header).
NOTIFICATIONメッセージの最小の長さは6つの八重奏(メッセージヘッダーを含んでいて)です。
8. MASC Error Handling
8. MASCエラー処理
This section describes actions to be taken when errors are detected while processing MASC messages. MASC Error Handling is similar to that of BGP [BGP].
このセクションは、MASCメッセージを処理している間誤りを検出するとき、取るために動作について説明します。 MASC Error HandlingはBGP[BGP]のものと同様です。
When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent. In addition, the MASC connection might be closed. If no Error Subcode is specified, then a zero (Unspecific) must be used.
ここで説明された状態のどれかを検出するとき、示されたError Code、Error Subcode、およびData分野があるNOTIFICATIONメッセージを送ります。 さらに、MASC接続は閉店するかもしれません。 Error Subcodeが全く指定されないなら、ゼロ(Unspecific)を使用しなければなりません。
The phrase "the MASC connection is closed" means that the transport protocol connection has been closed and that all resources for that MASC connection have been deallocated.
接続が持っているトランスポート・プロトコルをある「MASC接続は閉じられること」が意味する句が閉じました、そして、そのMASC接続へのすべてのリソースが「反-割り当て」られました。
Unless specified explicitly, the Data field of the NOTIFICATION message is empty.
明らかに指定されない場合、NOTIFICATIONメッセージのData分野は人影がありません。
8.1. Message Header Error Handling
8.1. メッセージヘッダーエラー処理
All errors detected while processing the Message Header are indicated by sending the NOTIFICATION message with Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error. The Data field contains the erroneous Message (including the message header).
Message Headerを処理している間に検出されたすべての誤りが、Error Code Message Header Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 Error Subcodeは誤りの特定の本質について詳しく説明します。 Data分野は誤ったMessageを含んでいます(メッセージヘッダーを含んでいて)。
If the Length field of the message header is less than 4 or greater than 4096, or if the length of an OPEN message is less than the minimum length of the OPEN message, or if the length of an UPDATE message is less than the minimum length of the UPDATE message, or if the length of a KEEPALIVE message is not equal to 4, then the Error Subcode is set to Bad Message Length.
メッセージヘッダーのLength分野があるか、4以上より4096オープンメッセージの長さがオープンメッセージの最小の長さかそれともUPDATEメッセージの長さが、より少ないかどうかよりUPDATEメッセージの最小の長さある、またはKEEPALIVEメッセージの長さが4と等しくないなら、Error SubcodeはBad Message Lengthに用意ができています。
If the Type field of the message header is not recognized, then the Error Subcode is set to Bad Message Type.
メッセージヘッダーのType分野が認識されないなら、Error SubcodeはBad Message Typeに用意ができています。
Radoslavov, et al. Experimental [Page 24] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[24ページ]RFC2909MASCプロトコル2000年9月
8.2. OPEN Message Error Handling
8.2. 開いているメッセージエラー処理
All errors detected while processing the OPEN message are indicated by sending the NOTIFICATION message with Error Code OPEN Message Error. The Error Subcode elaborates on the specific nature of the error. The Data field contains the erroneous OPEN Message (excluding the Message Header), unless stated otherwise.
オープンメッセージを処理している間に検出されたすべての誤りが、Error CodeオープンMessage Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 Error Subcodeは誤りの特定の本質について詳しく説明します。 別の方法で述べられない場合、Data分野は誤ったオープンMessage(Message Headerを除いた)を含んでいます。
If the version number contained in the Version field of the received OPEN message is not supported, then the Error Subcode is set to Unsupported Version Number. The Data field is a 1-octet unsigned integer, which indicates the largest locally supported version number less than the version the remote MASC node bid (as indicated in the received OPEN message).
受信されたオープンメッセージのバージョン分野に保管されていたバージョン番号がサポートされないなら、Error SubcodeはUnsupportedバージョンNumberに用意ができています。 Data分野は1八重奏の符号のない整数です。(その符号のない整数はリモートMASCノードが付けた(受信されたオープンメッセージにみられるように)バージョンほど示しません中で局所的にサポートしているバージョン番号最も大きい)。
If the Sender Domain Identifier field of the OPEN message is unacceptable, then the Error Subcode is set to Bad Peer Domain ID. The determination of acceptable Domain IDs is outside the scope of this protocol.
オープンメッセージのSender Domain Identifier分野が容認できないなら、Error SubcodeはBad Peer Domain IDに用意ができています。 このプロトコルの範囲の外に許容できるDomain IDの決断があります。
If the Sender MASC Node Identifier field of the OPEN message is unacceptable, then the Error Subcode is set to Bad Peer MASC Node ID. The determination of acceptable Node IDs is outside the scope of this protocol.
オープンメッセージのSender MASC Node Identifier分野が容認できないなら、Error SubcodeはBad Peer MASC Node IDに用意ができています。 このプロトコルの範囲の外に許容できるNode IDの決断があります。
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to Unacceptable Hold Time. An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. An implementation which accepts a Hold Time MUST use the negotiated value for the Hold Time.
オープンメッセージのHold Time分野が容認できないなら、Error SubcodeはUnacceptable Hold Timeに用意ができなければなりません。 実装は1秒か2秒のHold Time値を拒絶しなければなりません。 実装はどんな提案されたHold Timeも拒絶するかもしれません。 Hold Timeを受け入れる実装はHold Timeに交渉された値を使用しなければなりません。
If the remote system's proposed Role is INTERNAL_PEER, and either (but not both) the local system or the remote system's Parent Domain ID is [TLD_ID], then the Error Subcode is set to Invalid Parent Configuration. The Data field must be filled with all the local system's Parent Domain IDs.
リモートシステムの提案されたRoleがINTERNAL_PEERであり、(ともにない)ローカルシステムかリモートシステムのどちらかのParent Domain IDが[TLD_ID]であるなら、Error SubcodeはInvalid Parent Configurationに用意ができています。 すべてのローカルシステムのParent Domain IDでData分野を満たさなければなりません。
If the remote system's proposed Role conflicts with its expected role (based on the local system's configured Role), then the Error Subcode is set to Inconsistent Role. The Data field is 1-octet long, and contains the local system's configured Role.
リモートシステムが予想された役割(ローカルシステムの構成されたRoleに基づいている)とのRole闘争を提案したなら、Error SubcodeはInconsistent Roleに用意ができています。 Data分野は、長い間1八重奏であり、ローカルシステムの構成されたRoleを含んでいます。
If the remote system's Parent Domain ID is unacceptable, then the Error Subcode is set to Bad Parent Domain ID, and the Data field is filled with the erroneous Parent Domain ID. The determination of acceptable Parent Domain ID is outside the scope of this protocol.
リモートシステムのParent Domain IDが容認できないなら、Error SubcodeはBad Parent Domain IDに用意ができています、そして、Data分野は誤ったParent Domain IDで満たされます。 このプロトコルの範囲の外に許容できるParent Domain IDの決断があります。
Radoslavov, et al. Experimental [Page 25] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[25ページ]RFC2909MASCプロトコル2000年9月
If the remote system is supposed to be a sibling, but it does not have a common parent with the local system (based on the Parent Domain ID information in the OPEN message), the Error Subcode is set to No Common Parent, and the Data field is filled with all Parent Domain IDs of the local MASC domain.
リモートシステムが兄弟であるべきですが、それでは一般的な親がローカルシステム(オープンメッセージのParent Domain ID情報に基づいている)と共にいないなら、Error SubcodeはどんなCommon Parentにも用意ができていません、そして、Data分野は地方のMASCドメインのすべてのParent Domain IDで満たされます。
If the Address Family is unrecognized, then the Error Subcode is set to Unrecognized Address Family.
Address Familyが認識されていないなら、Error SubcodeはUnrecognized Address Familyに用意ができています。
8.3. UPDATE Message Error Handling
8.3. アップデートメッセージエラー処理
All errors detected while processing the UPDATE message are indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error. The Data field contains the erroneous UPDATE Message (including the attribute header, but excluding the Message Header), unless stated otherwise.
UPDATEメッセージを処理している間に検出されたすべての誤りが、Error Code UPDATE Message Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 誤り部分符号は誤りの特定の本質について詳しく説明します。 別の方法で述べられない場合、Data分野は誤ったUPDATE Message(属性ヘッダーを含んでいますが、Message Headerを除く)を含んでいます。
If any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode is set to Attribute Length Error.
どんな認識された属性にも予想された長さ(属性タイプコードに基づいている)と衝突するAttribute Lengthがあるなら、Error SubcodeはAttribute Length Errorに用意ができています。
If any of the mandatory well-known attributes are not recognized, then the Error Subcode is set to Unrecognized Required Attribute.
義務的なよく知られる属性のいずれも認識されないなら、Error SubcodeはUnrecognized Required Attributeに用意ができています。
If the Address field includes an invalid address (except 0), then the Error Subcode is set to Invalid Address.
Address分野が無効のアドレス(0を除いた)を含んでいるなら、Error SubcodeはInvalid Addressに用意ができています。
If the Mask field includes an invalid mask (for example, starting with 0), then the Error Subcode is set to Invalid Mask.
Mask分野が無効のマスク(例えば0をきっかけに)を含んでいるなら、Error SubcodeはInvalid Maskに用意ができています。
If the Mask field includes a non-contiguous bitmask, and that MASC server does not support, or is not configured to use non-contiguous masks, then the Error Subcode is set to Non-Contiguous Mask.
Mask分野が非隣接のビットマスクを含んでいて、そのMASCサーバがどんなサポートもしないか、または非隣接のマスクを使用するために構成されないなら、Error SubcodeはNon隣接のMaskに用意ができています。
If the Address Family is unrecognized, then the Error Subcode is set to Unrecognized Address Family.
Address Familyが認識されていないなら、Error SubcodeはUnrecognized Address Familyに用意ができています。
If the Origin Role/Claim Type combination is not one of the following, then the Error Subcode is set to Claim Type Error.
Origin Role/クレームType組み合わせが以下の1つでないなら、Error SubcodeはType Errorを要求するように用意ができています。
Radoslavov, et al. Experimental [Page 26] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[26ページ]RFC2909MASCプロトコル2000年9月
Origin Claim
Role Type
発生源クレーム役割型
ICS PREFIX_IN_USE (0)
I P CLAIM_DENIED (1)
ICS CLAIM_TO_EXPAND (2)
ICS NEW_CLAIM (3)
I P PREFIX_MANAGED (4)
ICSP WITHDRAW (5)
広げる_使用(0)I Pクレーム_の接頭語_が(1) _へのICSクレーム_を(2) ICSの新しい_クレーム(3)I P接頭語_を否定したICSがICSPが引き下がらせる(4)を管理しました。(5)
If there is a reason to believe that the Origin Domain ID is invalid, then the Error Subcode is set to Origin Domain ID Error. The same applies for Origin Node ID (the corresponding error is Origin Node ID Error).
Origin Domain IDが無効であると信じる理由があれば、Error SubcodeはOrigin Domain ID Errorに用意ができています。 同じくらいはOrigin Node IDに申し込みます(対応する誤りはOrigin Node ID Errorです)。
If a node (usually a parent receiving a claim from a child) decides that the Claim Lifetime is too short (for example, less than 172800, i.e. 48 hours), it MAY send an UPDATE Message Error with subcode Claim Lifetime Too Short.
ノード(通常子供からクレームを受け取る親)が、クレームLifetimeが(例えば、172800、すなわち、48時間)の間短過ぎると決めるなら、それは部分符号クレームLifetime Too Shortと共にUPDATE Message Errorを送るかもしれません。
If a node (usually a parent receiving a claim from a child) decides that the Claim Lifetime is too long (for example, more than 15,768,000, i.e. half year), then it MAY send an UPDATE Message Error with subcode Claim Lifetime Too Long. Note that usually a parent MASC node should send first CLAIM_DENIED collision messages with Claim Lifetime field filled with the longest acceptable lifetime. If the child refuses to claim with shorter lifetime, then Claim Lifetime Too Long should be sent.
ノード(通常子供からクレームを受け取る親)が、クレームLifetimeが(例えば、1576万8000以上、すなわち、半分の年)の間長過ぎると決めるなら、それは部分符号クレームLifetime Too Longと共にUPDATE Message Errorを送るかもしれません。 通常、親MASCノードがクレームLifetimeがあるメッセージがさばく最も長い許容できる生涯で満たされた最初のクレーム_DENIED衝突を送るはずであることに注意してください。 子供が、より短いことで生涯を要求するのを拒否するなら、クレームLifetime Too Longを送るべきです。
If a node (usually a parent receiving a claim from a child) decides that the Claim Timestamp is too small, i.e. too old (for example, if a node is self-confident that its clock is quite accurate), then it MUST send an UPDATE Message Error with subcode Claim Timestamp Too Old. Claim Timestamp Too New is defined similarly.
ノード(通常子供からクレームを受け取る親)が、クレームTimestampが小さ過ぎて、すなわち、古過ぎると決める、(ノードは例えば自信がある、時計はかなり正確です)、そして、それは部分符号クレームTimestamp Too Oldと共にUPDATE Message Errorを送らなければなりません。 クレームTimestamp Too Newは同様に定義されます。
If a node (usually a parent receiving a claim from a child) decides that the prefix size implied by the Mask field is too small (for example, smaller than 16 addresses), then it MAY send an UPDATE Message Error with subcode Claim Prefix Size Too Small.
ノード(通常子供からクレームを受け取る親)が、Mask分野のそばで暗示している接頭語サイズが小さ過ぎると(例えば、16より小さいアドレス)決めるなら、それは部分符号クレームPrefix Size Too Smallと共にUPDATE Message Errorを送るかもしれません。
If a node (usually a parent receiving a claim from a child) decides that the prefix size implied by the Mask field is too large, then it MAY send an UPDATE Message Error with subcode Claim Prefix Size Too Large. Note that usually a parent MASC node should send first CLAIM_DENIED collision messages for some subrange of the child's large claimed address range. If the child refuses to shrink the claim size, then Claim Prefix Size Too Large should be sent.
ノード(通常子供からクレームを受け取る親)が、Mask分野のそばで暗示している接頭語サイズが大き過ぎると決めるなら、それは部分符号クレームPrefix Size Too Largeと共にUPDATE Message Errorを送るかもしれません。 通常、親MASCノードが子供の大きい要求されたアドレスの範囲のいくつかのサブレンジへの衝突メッセージを最初に、クレーム_DENIEDに送るはずであることに注意してください。 子供が、クレームがサイズであると縮小するのを拒否するなら、クレームPrefix Size Too Largeを送るべきです。
Radoslavov, et al. Experimental [Page 27] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[27ページ]RFC2909MASCプロトコル2000年9月
If the received UPDATE message's computed Updated Origin Role is illegal (see Table 1 in Section 11.1), then the Error Subcode is set to Illegal Origin Role Error.
受信されたUPDATEメッセージの計算されたUpdated Origin Roleが不法であるなら(セクション11.1でTable1を見てください)、Error SubcodeはIllegal Origin Role Errorに用意ができています。
If the received UPDATE message needs to be associated with a parent's prefix, but the association is not successful, then the Error Subcode is set to No Appropriate Parent Prefix. The No Appropriate Child Prefix, No Appropriate Internal Prefix, and No Appropriate Sibling Prefix Error Subcodes are defined similarly.
受信されたUPDATEメッセージが、親の接頭語に関連している必要がありますが、協会がうまくいかないなら、Error SubcodeはどんなAppropriate Parent Prefixにも用意ができていません。 ノーAppropriate Child Prefix、Appropriate Internal Prefixがなく、およびAppropriate Sibling Prefix Error Subcodesは全く同様に定義されません。
If a node decides that the Claim Holdtime is too short (for example, just few seconds), it MAY send an UPDATE Message Error with subcode Claim Holdtime Too Short.
ノードが、クレームHoldtimeが短過ぎると(例えば、ちょうど数秒)決めるなら、それは部分符号クレームHoldtime Too Shortと共にUPDATE Message Errorを送るかもしれません。
If a node decides that the Claim Holdtime is too long (for example, more than 15,768,000, i.e. half year), then it SHOULD send an UPDATE Message Error with subcode Claim Holdtime Too Long.
ノードが決めるなら、クレームHoldtimeが(例えば、1576万8000以上、すなわち、半分の年)の間、長過ぎ、次に、それがSHOULDであることは部分符号クレームHoldtime Too Longと共にUPDATE Message Errorを送ります。
If any other error is encountered when processing attributes, then the Error Subcode is set to Malformed Attribute List, and the erratic attribute is included in the data field.
属性を処理するとき、他の誤りが遭遇するなら、Error SubcodeはMalformed Attribute Listに用意ができています、そして、不安定な属性はデータ・フィールドで含められています。
8.4. Hold Timer Expired Error Handling
8.4. タイマの満期のエラー処理を保持してください。
If a system does not receive successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages within the period specified in the Hold Time field of the OPEN message, then the NOTIFICATION message with Hold Timer Expired Error Code must be sent and the MASC connection closed.
システムがオープンメッセージのHold Time分野で指定された期間中に連続したKEEPALIVE、UPDATE、そして/または、NOTIFICATIONメッセージを受け取らないなら、Hold Timer Expired Error CodeがあるNOTIFICATIONメッセージを送らなければなりませんでした、そして、MASC接続は閉じました。
8.5. Finite State Machine Error Handling
8.5. 有限状態機械エラー処理
Any error detected by the MASC Finite State Machine (e.g., receipt of an unexpected event) is indicated by sending the NOTIFICATION message with Error Code Finite State Machine Error. The Error Subcode elaborates on the specific nature of the error.
MASC Finite州Machine(例えば、予期せぬ出来事の領収書)によって検出されたどんな誤りも、Error Code Finite州Machine Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 Error Subcodeは誤りの特定の本質について詳しく説明します。
8.6. NOTIFICATION Message Error Handling
8.6. 通知メッセージエラー処理
If a node sends a NOTIFICATION message, and there is an error in that message, and the O-bit of that message is not zero, a NOTIFICATION with O-bit zeroed, Error Code of NOTIFICATION Error, and subcode Unspecific must be sent. In addition, the Data field must include the erratic NOTIFICATION message. However, if the erratic NOTIFICATION message had the O-bit zeroed, then any error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged
ノードがNOTIFICATIONメッセージを送って、そのメッセージには誤りがあって、そのメッセージのO-ビットがゼロでないなら、合わせられたゼロO-ビットがあるNOTIFICATION、NOTIFICATION ErrorのError Code、および部分符号Unspecificを送らなければなりません。 さらに、Data分野は不安定なNOTIFICATIONメッセージを含まなければなりません。 しかしながら、不安定なNOTIFICATIONメッセージでO-ビットのゼロを合わせているなら、認識されていないError CodeかError Subcodeなどのどんな誤りも、気付かれて、登録されているでしょうに。
Radoslavov, et al. Experimental [Page 28] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[28ページ]RFC2909MASCプロトコル2000年9月
locally, and brought to the attention of the administrator of the remote node. The means to do this, however, lies outside the scope of this document.
局所的である、遠隔ノードの管理者の注意に持って来られます。 このドキュメントの範囲の外にしかしながら、これをする手段があります。
8.7. Cease
8.7. やんでください。
In absence of any fatal errors (that are indicated in this section), a MASC node may choose at any given time to close its MASC connection by sending the NOTIFICATION message with Error Code Cease. However, the Cease NOTIFICATION message must not be used when a fatal error indicated by this section does exist.
どんな致命的な誤り(それはこのセクションで示される)の欠如ではも、MASCノードは、その時々でError Code Ceaseと共にNOTIFICATIONメッセージを送ることによってMASC接続を終えるのを選ぶかもしれません。 しかしながら、このセクションによって示された致命的な誤りが存在するとき、Cease NOTIFICATIONメッセージを使用してはいけません。
8.8. Connection Collision Detection
8.8. 接続衝突検出
If a pair of MASC speakers try simultaneously to establish a TCP connection to each other, then two parallel connections between this pair of speakers might well be formed. We refer to this situation as connection collision. Clearly, one of these connections must be closed. Note that if the nodes were siblings, and each of those connections was associated with a different parent, then we do not consider this situation as collision (see Section 4.4).
1組のMASCスピーカーが同時にTCP接続を互いに確立しようとするなら、この組のスピーカーの間の2人の並列接続がたぶん形成されるでしょう。 私たちはこの状況を接続衝突と呼びます。 明確に、これらの接続のひとりを閉じなければなりません。 ノードが兄弟であり、それらの各人接続が異なった親に関連していたなら私たちが、この状況が衝突であるとみなさないことに注意してください(セクション4.4を見てください)。
Based on the value of the MASC Node Identifier a convention is established for detecting which MASC connection is to be preserved when a connection collision does occur. The convention is to compare the MASC Node Identifiers of the remote nodes involved in the collision and to retain only the connection initiated by the MASC speaker with the higher-valued MASC Node Identifier.
MASC Node Identifierの値に基づいて、コンベンションは、接続衝突が起こるとき、保存されるためにMASC接続がどれであるかを検出するために設立されます。 コンベンションは、衝突にかかわる遠隔ノードのMASC Node Identifiersを比較して、より高く評価されたMASC Node Identifierと共にMASCスピーカーによって開始された接続だけを保有することになっています。
Upon receipt of an OPEN message, the local system must examine all of its connections that are in the OpenConfirm state. A MASC speaker may also examine connections in an OpenSent state if it knows the MASC Node Identifier of the remote node by means outside of the protocol. If among these connections there is a connection to a remote MASC speaker whose MASC Node Identifier equals the one in the OPEN message, and, in case of a sibling-to-sibling connection, the Parent Domain ID of that connection equals the one in the OPEN message, then the local system performs the following connection collision resolution procedure:
オープンメッセージを受け取り次第、ローカルシステムはOpenConfirm状態にある接続のすべてを調べなければなりません。 また、プロトコルの外で遠隔ノードについて手段でMASC Node Identifierを知っているなら、MASCスピーカーはOpenSent状態で接続を調べるかもしれません。 これらの接続の中に、MASC Node Identifierがオープンメッセージのものと等しいリモートMASCスピーカーとの接続があって、その接続のParent Domain IDが兄弟から兄弟との接続の場合にオープンメッセージのものと等しいなら、ローカルシステムは以下の接続衝突解決手順を実行します:
1. The MASC Node Identifier of the local system is compared to the
MASC Node Identifier of the remote system (as specified in the
OPEN message). Comparing MASC Node Identifiers is done by
treating them as unsigned integers (e.g. 4-octets long for IPv4
and 16-octets long for IPv6).
1. ローカルシステムのMASC Node IdentifierはリモートシステムのMASC Node Identifierと比較されます(オープンメッセージで指定されるように)。 MASC Node Identifiersは、符号のない整数として彼らを扱うことによって、比較されます(例えば、4八重奏がIPv6のために長い間、IPv4と16八重奏にあこがれています)。
Radoslavov, et al. Experimental [Page 29] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[29ページ]RFC2909MASCプロトコル2000年9月
2. If the value of the local MASC Node Identifier is less than the
remote one, the local system closes MASC connection that already
exists (the one that is already in the OpenConfirm state), and
accepts the MASC connection initiated by the remote system.
2. 地方のMASC Node Identifierの値がリモートもの以下であるなら、ローカルシステムは、既に存在するMASC接続(OpenConfirm状態に既にあるもの)を終えて、リモートシステムによって開始されたMASC接続を受け入れます。
3. Otherwise, the local system closes the newly created MASC
connection (the one associated with the newly received OPEN
message), and continues to use the existing one (the one that is
already in the OpenConfirm state).
3. ローカルシステムは、新たに作成されたMASC接続(新たに受け取られたオープンメッセージに関連しているもの)を終えて、さもなければ、既存のものを使用し(OpenConfirm状態に既にあるもの)続けています。
A connection collision with an existing MASC connection that is in the Established state causes unconditional closing of the newly created connection. Note that a connection collision cannot be detected with connections that are in Idle, or Connect, or Active states (see Section 10).
Established状態にある既存のMASC接続との接続衝突は新たに作成された接続の無条件の閉鎖を引き起こします。 Idle、Connect、またはActive州にある接続と共に接続衝突を検出できないことに注意してください(セクション10を見てください)。
Closing the MASC connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
MASC接続(それは衝突解決手順から生じる)を終えるのは、Error Code Ceaseと共にNOTIFICATIONメッセージを送ることによって、実行されます。
9. MASC Version Negotiation
9. MASCバージョン交渉
MASC speakers may negotiate the version of the protocol by making multiple attempts to open a MASC connection, starting with the highest version number each supports. If an open attempt fails with an Error Code OPEN Message Error, and an Error Subcode Unsupported Version Number, then the MASC speaker has available the version number it tried, the version number the remote node tried, the version number passed by the remote node in the NOTIFICATION message, and the version numbers that it supports. If the two MASC speakers do support one or more common versions, then this will allow them to rapidly determine the highest common version. In order to support MASC version negotiation, future versions of MASC must retain the format of the OPEN and NOTIFICATION messages.
MASCスピーカーはMASC接続を開く複数の試みをすることによって、プロトコルのバージョンを交渉するかもしれません、それぞれがサポートする中で最も大きいバージョン番号から始まって。 開いている試みがError CodeオープンMessage Error、およびError Subcode UnsupportedバージョンNumberと共に失敗するなら、MASCスピーカーには、有効なそれが試みたバージョン番号、遠隔ノードが試みたバージョン番号、NOTIFICATIONメッセージの遠隔ノードによって通過されたバージョン番号、およびそれがサポートするバージョン番号があります。 2人のMASCスピーカーが1つ以上の一般的なバージョンをサポートすると、これで、彼らは急速に最も高い一般的なバージョンを決定できるでしょう。 MASCがバージョン交渉であるとサポートするために、MASCの将来のバージョンはオープンとNOTIFICATIONメッセージの形式を保有しなければなりません。
10. MASC Finite State Machine
10. MASC有限状態機械
This section specifies MASC operation in terms of a Finite State Machine (FSM). The FSM and the operations are peer peering session. Following is a brief summary and overview of MASC operations by state as determined by this FSM.
このセクションはFinite州Machine(FSM)に関してMASC操作を指定します。 FSMと操作は同輩じっと見るセッションです。 以下に、このFSMによって決定されるように状態によるMASC操作の簡潔な概要と概要があります。
Initially the peering session is in the Idle state.
初めは、じっと見るセッションがIdle状態にあります。
Radoslavov, et al. Experimental [Page 30] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[30ページ]RFC2909MASCプロトコル2000年9月
10.1. Open/Close MASC Connection FSM
10.1. 開いているか近いMASC接続FSM
Idle state:
状態を空費してください:
In this state MASC refuses all incoming MASC connections from the
peer. No resources are allocated to the remote node. In response
to the Start event (initiated by either system or operator) the
local system initializes all MASC resources, starts the
ConnectRetry timer, initiates a transport connection to the remote
node, while listening for a connection that may be initiated by
the remote MASC node, and changes its state to Connect. The exact
value of the ConnectRetry timer is a local matter, but should be
sufficiently large to allow TCP initialization.
この状態では、MASCは同輩からすべての入って来るMASC接続を拒否します。 リソースを全く遠隔ノードに割り当てません。 Startイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムは、すべてのMASCリソースを初期化して、ConnectRetryタイマを始動して、リモートMASCノードを開始されるかもしれない接続の聞こうとしている間、輸送接続の遠隔ノードを開始して、状態をConnectに変えます。 ConnectRetryタイマの正確な値は、地域にかかわる事柄ですが、TCPに初期化を許すことができるくらい大きいはずです。
If a MASC speaker detects an error, it shuts down the connection
and changes its state to Idle. Getting out of the Idle state
requires generation of the Start event. If such an event is
generated automatically, then persistent MASC errors may result in
persistent flapping of the speaker. To avoid such a condition it
is recommended that Start events should not be generated
immediately for a node that was previously transitioned to Idle
due to an error. For a node that was previously transitioned to
Idle due to an error, the time between consecutive generation of
Start events, if such events are generated automatically, shall
exponentially increase. The value of the initial timer shall be 60
seconds. The time shall be doubled for each consecutive retry, but
shall not be longer than 24 hours.
MASCスピーカーが誤りを検出するなら、それは接続と変化の下側にIdleへの状態を閉じます。 Idle状態から出るのはStartイベントを世代に要求します。 そのようなイベントが自動的に生成されるなら、永続的なMASC誤りはスピーカーについて永続的なばたつくことをもたらすかもしれません。 そのような状態を避けるために、イベントがすぐ以前にそうであったノードのために生成されるべきでないStartが誤りのためIdleに移行したのは、お勧めです。 誤りのために以前に移行しているIdleであったノードに関しては、そのようなイベントが自動的に生成されるなら、連続した世代のStartイベントの間の時間は指数関数的に増加するものとします。 初期のタイマの値は60秒になるでしょう。 時間は、それぞれの連続した再試行のために倍にされますが、24時間ほど、より長くならないでしょう。
Any other event received in the Idle state is ignored.
Idle状態に受け取られたいかなる他のイベントも無視されます。
Connect state:
状態をつなげてください:
In this state MASC is waiting for the transport protocol
connection to be completed.
この状態では、MASCは、輸送プロトコル接続が終了するのを待っています。
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to the remote node, and changes its state to
OpenSent. If the transport protocol connect fails (e.g.,
retransmission timeout), the local system restarts the
ConnectRetry timer, continues to listen for a connection that may
be initiated by the remote MASC node, and changes its state to
Active state.
輸送プロトコル接続が成功するなら、ローカルシステムは、ConnectRetryタイマをきれいにして、初期化を終了して、オープンメッセージを遠隔ノードに送って、状態をOpenSentに変えます。 プロトコルが接続する輸送が(例えば、再送タイムアウト)に失敗するなら、ローカルシステムは、Active状態にConnectRetryタイマを再開して、リモートMASCノードを開始されるかもしれない接続の聞こうとし続けて、状態を変えます。
Radoslavov, et al. Experimental [Page 31] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[31ページ]RFC2909MASCプロトコル2000年9月
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to the other MASC node, continues to listen for a
connection that may be initiated by the remote MASC node, and
stays in the Connect state.
ConnectRetryタイマ満期のイベントに対応して、ローカルシステムは、ConnectRetryタイマを再開して、もう片方のMASCノードに輸送接続を開始して、リモートMASCノードを開始されるかもしれない接続の聞こうとし続けて、Connect状態にいます。
The Start event is ignored in the Connect state.
StartイベントはConnect状態で無視されます。
In response to any other event (initiated by either system or
operator), the local system releases all MASC resources associated
with this connection and changes its state to Idle.
いかなる他のイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムは、この接続に関連しているすべてのMASCリソースを発表して、状態をIdleに変えます。
Active state:
活動的な州:
In this state MASC is trying to acquire a remote node by listening
for a transport protocol connection initiated by the remote node.
この状態では、MASCは、遠隔ノードを開始された輸送プロトコル接続の聞こうとすることによって、遠隔ノードを帯びようとしています。
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to the remote node, sets its Hold Timer to a large
value, and changes its state to OpenSent. A Hold Timer value of
[HOLDTIME] seconds is suggested.
輸送プロトコル接続が成功するなら、ローカルシステムは、ConnectRetryタイマをきれいにして、初期化を終了して、オープンメッセージを遠隔ノードに送って、大きい値にHold Timerを設定して、状態をOpenSentに変えます。 [HOLDTIME]秒のHold Timer値は示されます。
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to other MASC node, continues to listen for a
connection that may be initiated by the remote MASC node, and
changes its state to Connect.
ConnectRetryタイマ満期のイベントに対応して、ローカルシステムは、ConnectRetryタイマを再開して、他のMASCノードに輸送接続を開始して、リモートMASCノードを開始されるかもしれない接続の聞こうとし続けて、状態をConnectに変えます。
If the local system detects that a remote node is trying to
establish a MASC connection to it, and the IP address of the
remote node is not an expected one, the local system restarts the
ConnectRetry timer, rejects the attempted connection, continues to
listen for a connection that may be initiated by the remote MASC
node, and stays in the Active state.
If the local system detects that a remote node is trying to establish a MASC connection to it, and the IP address of the remote node is not an expected one, the local system restarts the ConnectRetry timer, rejects the attempted connection, continues to listen for a connection that may be initiated by the remote MASC node, and stays in the Active state.
The Start event is ignored in the Active state.
The Start event is ignored in the Active state.
In response to any other event (initiated by either system or
operator), the local system releases all MASC resources associated
with this connection and changes its state to Idle.
In response to any other event (initiated by either system or operator), the local system releases all MASC resources associated with this connection and changes its state to Idle.
OpenSent state:
OpenSent state:
In this state MASC waits for an OPEN message from the remote node.
When an OPEN message is received, all fields are checked for
correctness. If the MASC message header checking or OPEN message
checking detects an error (see Section 8.2), or a connection
In this state MASC waits for an OPEN message from the remote node. When an OPEN message is received, all fields are checked for correctness. If the MASC message header checking or OPEN message checking detects an error (see Section 8.2), or a connection
Radoslavov, et al. Experimental [Page 32] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 32] RFC 2909 The MASC Protocol September 2000
collision (see Section 8.8) the local system sends a NOTIFICATION
message and, if the connection is to be closed, it changes its
state to Idle.
collision (see Section 8.8) the local system sends a NOTIFICATION message and, if the connection is to be closed, it changes its state to Idle.
If the locally configured role is SIBLING and there is no parent
domain with Domain ID equal to the Parent Domain ID in the OPEN
message, the local system sends a NOTIFICATION Open Message Error
with Error Subcode set to No Common Parent, the connection must be
closed, and the state of the local system must be changed to Idle.
If the locally configured role is SIBLING and there is no parent domain with Domain ID equal to the Parent Domain ID in the OPEN message, the local system sends a NOTIFICATION Open Message Error with Error Subcode set to No Common Parent, the connection must be closed, and the state of the local system must be changed to Idle.
If there are no errors in the OPEN message, MASC sends a KEEPALIVE
message and sets a KeepAlive timer. The Hold Timer, which was
originally set to a large value (see above), is replaced with the
negotiated Hold Time value (see Section 7.2). If the negotiated
Hold Time value is zero, then the Hold Time timer and KeepAlive
timers are not started. If the value of the MASC Domain ID field
is the same as the local MASC Domain ID, and if the Role field of
the OPEN message is set to INTERNAL_PEER, then the connection is
an "internal" connection; otherwise, it is "external". Finally,
the state is changed to OpenConfirm.
If there are no errors in the OPEN message, MASC sends a KEEPALIVE message and sets a KeepAlive timer. The Hold Timer, which was originally set to a large value (see above), is replaced with the negotiated Hold Time value (see Section 7.2). If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timers are not started. If the value of the MASC Domain ID field is the same as the local MASC Domain ID, and if the Role field of the OPEN message is set to INTERNAL_PEER, then the connection is an "internal" connection; otherwise, it is "external". Finally, the state is changed to OpenConfirm.
If a disconnect notification is received from the underlying
transport protocol, the local system closes the MASC connection,
restarts the ConnectRetry timer, while continue listening for
connection that may be initiated by the remote MASC node, and goes
into the Active state.
If a disconnect notification is received from the underlying transport protocol, the local system closes the MASC connection, restarts the ConnectRetry timer, while continue listening for connection that may be initiated by the remote MASC node, and goes into the Active state.
If the Hold Timer expires, the local system sends a NOTIFICATION
message with error code Hold Timer Expired and changes its state
to Idle.
If the Hold Timer expires, the local system sends a NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
In response to the Stop event (initiated by either system or
operator) the local system sends a NOTIFICATION message with Error
Code Cease and changes its state to Idle.
In response to the Stop event (initiated by either system or operator) the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle.
The Start event is ignored in the OpenSent state.
The Start event is ignored in the OpenSent state.
In response to any other event the local system sends a
NOTIFICATION message with Error Code Finite State Machine Error
and Error Subcode Open/Close MASC Connection FSM Error, and
changes its state to Idle.
In response to any other event the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and Error Subcode Open/Close MASC Connection FSM Error, and changes its state to Idle.
Whenever MASC changes its state from OpenSent to Idle, it closes
the MASC (and transport-level) connection and releases all
resources associated with that connection.
Whenever MASC changes its state from OpenSent to Idle, it closes the MASC (and transport-level) connection and releases all resources associated with that connection.
Radoslavov, et al. Experimental [Page 33] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 33] RFC 2909 The MASC Protocol September 2000
OpenConfirm state:
OpenConfirm state:
In this state MASC waits for a KEEPALIVE or NOTIFICATION message.
In this state MASC waits for a KEEPALIVE or NOTIFICATION message.
If the local system receives a KEEPALIVE message, it changes its
state to Established.
If the local system receives a KEEPALIVE message, it changes its state to Established.
If the Hold Timer expires before a KEEPALIVE message is received,
the local system sends a NOTIFICATION message with error code Hold
Timer Expired and changes its state to Idle.
If the Hold Timer expires before a KEEPALIVE message is received, the local system sends a NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
If the local system receives a NOTIFICATION message with the O-bit
zeroed, it changes its state to Idle.
If the local system receives a NOTIFICATION message with the O-bit zeroed, it changes its state to Idle.
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
In response to the Stop event (initiated by either system or
operator) the local system sends a NOTIFICATION message with Error
Code Cease and changes its state to Idle.
In response to the Stop event (initiated by either system or operator) the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle.
The Start event is ignored in the OpenConfirm state.
The Start event is ignored in the OpenConfirm state.
In response to any other event the local system sends a
NOTIFICATION message with Error Code Finite State Machine Error
and Error Subcode Unspecific, and changes its state to Idle.
In response to any other event the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and Error Subcode Unspecific, and changes its state to Idle.
Whenever MASC changes its state from OpenConfirm to Idle, it
closes the MASC (and transport-level) connection and releases all
resources associated with that connection.
Whenever MASC changes its state from OpenConfirm to Idle, it closes the MASC (and transport-level) connection and releases all resources associated with that connection.
Established state:
Established state:
In the Established state MASC can exchange UPDATE, NOTIFICATION,
and KEEPALIVE messages with the remote node.
In the Established state MASC can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with the remote node.
If the local system receives an UPDATE, or KEEPALIVE message, or
NOTIFICATION message with O-bit set, it restarts its Hold Timer,
if the negotiated Hold Time value is non-zero.
If the local system receives an UPDATE, or KEEPALIVE message, or NOTIFICATION message with O-bit set, it restarts its Hold Timer, if the negotiated Hold Time value is non-zero.
If the local system receives a NOTIFICATION message, with the O-
bit zeroed, it changes its state to Idle.
If the local system receives a NOTIFICATION message, with the O- bit zeroed, it changes its state to Idle.
Radoslavov, et al. Experimental [Page 34] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 34] RFC 2909 The MASC Protocol September 2000
If the local system receives an UPDATE message and the UPDATE
message error handling procedure (see Section 8.3) detects an
error, the local system sends a NOTIFICATION message and, if the
O-bit was zeroed, changes its state to Idle.
If the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 8.3) detects an error, the local system sends a NOTIFICATION message and, if the O-bit was zeroed, changes its state to Idle.
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
If the Hold Timer expires, the local system sends a NOTIFICATION
message with Error Code Hold Timer Expired and changes its state
to Idle.
If the Hold Timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and changes its state to Idle.
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
Each time the local system sends a KEEPALIVE or UPDATE message, it
restarts its KeepAlive timer, unless the negotiated Hold Time
value is zero.
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero.
In response to the Stop event (initiated by either system or
operator), the local system sends a NOTIFICATION message with
Error Code Cease and changes its state to Idle.
In response to the Stop event (initiated by either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle.
The Start event is ignored in the Established state.
The Start event is ignored in the Established state.
After entering the Established state, if the local system has
UPDATE messages that are to be sent to the remote node, they must
be sent immediately (see Section 11.8).
After entering the Established state, if the local system has UPDATE messages that are to be sent to the remote node, they must be sent immediately (see Section 11.8).
In response to any other event, the local system sends a
NOTIFICATION message with Error Code Finite State Machine Error
with the O-bit zeroed and Error Subcode Unspecific, and changes
its state to Idle.
In response to any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error with the O-bit zeroed and Error Subcode Unspecific, and changes its state to Idle.
Whenever MASC changes its state from Established to Idle, it
closes the MASC (and transport-level) connection, releases all
resources associated with that connection, and deletes all state
derived from that connection.
Whenever MASC changes its state from Established to Idle, it closes the MASC (and transport-level) connection, releases all resources associated with that connection, and deletes all state derived from that connection.
11. UPDATE Message Processing
11. UPDATE Message Processing
The UPDATE message are accepted only when the system is in the Established state.
The UPDATE message are accepted only when the system is in the Established state.
In the text below, a MASC domain is considered a child of itself with regard to the claims that are related to the address space with local usage purpose (i.e. to be used by the MAASs within that domain). For
In the text below, a MASC domain is considered a child of itself with regard to the claims that are related to the address space with local usage purpose (i.e. to be used by the MAASs within that domain). For
Radoslavov, et al. Experimental [Page 35] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 35] RFC 2909 The MASC Protocol September 2000
example, a NEW_CLAIM initiated by a MASC node to obtain more space for local usage from a prefix managed by that domain will have field Role = CHILD.
example, a NEW_CLAIM initiated by a MASC node to obtain more space for local usage from a prefix managed by that domain will have field Role = CHILD.
If an UPDATE is to be propagated further, it should not be sent back to the node that UPDATE was received from, unless there is an indication that the connection to that node was down and then restored.
If an UPDATE is to be propagated further, it should not be sent back to the node that UPDATE was received from, unless there is an indication that the connection to that node was down and then restored.
If the local system receives an UPDATE message, and there is no indication for error, it checks whether to accept or reject the message, and if it is not rejected, the UPDATE is processed based on its type.
If the local system receives an UPDATE message, and there is no indication for error, it checks whether to accept or reject the message, and if it is not rejected, the UPDATE is processed based on its type.
If an UPDATE message must be associated with a parent domain, then there must be a PREFIX_MANAGED by some parent domain for a prefix that covers the prefix of the particular UPDATE.
If an UPDATE message must be associated with a parent domain, then there must be a PREFIX_MANAGED by some parent domain for a prefix that covers the prefix of the particular UPDATE.
11.1. Accept/Reject an UPDATE
11.1. Accept/Reject an UPDATE
The Origin Role field is first compared against the local system's configured Role, according to Table 1, to determine the relationship of the origin to the local system, where Locally-Configured Role is the local configuration with regard to the peer-forwarder of the message. A result of "---" means that receiving such an UPDATE is illegal and should generate a NOTIFICATION. Any other result is the value to use as the "Updated" Origin Role when propagating the UPDATE to others. This is analogous to updating a metric upon receiving a route, based on the metric of the link.
The Origin Role field is first compared against the local system's configured Role, according to Table 1, to determine the relationship of the origin to the local system, where Locally-Configured Role is the local configuration with regard to the peer-forwarder of the message. A result of "---" means that receiving such an UPDATE is illegal and should generate a NOTIFICATION. Any other result is the value to use as the "Updated" Origin Role when propagating the UPDATE to others. This is analogous to updating a metric upon receiving a route, based on the metric of the link.
Locally-Configured Role
Origin
Role || INTERNAL_PEER | CHILD | SIBLING | PARENT
=========++===============+=========+=========+=========
INTERNAL || INTERNAL_PEER | PARENT | SIBLING | CHILD
CHILD || CHILD | SIBLING | --- | ---
SIBLING || SIBLING | --- | SIBLING | CHILD
PARENT || PARENT | --- | PARENT | ---
Locally-Configured Role Origin Role || INTERNAL_PEER | CHILD | SIBLING | PARENT =========++===============+=========+=========+========= INTERNAL || INTERNAL_PEER | PARENT | SIBLING | CHILD CHILD || CHILD | SIBLING | --- | --- SIBLING || SIBLING | --- | SIBLING | CHILD PARENT || PARENT | --- | PARENT | ---
Table 1: Updated Origin Role Computation
Table 1: Updated Origin Role Computation
After the Origin Role is updated, the following additional processing needs to be applied:
After the Origin Role is updated, the following additional processing needs to be applied:
o If the output from the Updated Origin Role Computation is SIBLING,
but the Origin Domain ID is the same as the local MASC domain, the
Updated Origin Role is changed to INTERNAL. This is necessary in
case a MASC node receives from a parent or sibling its own UPDATEs
o If the output from the Updated Origin Role Computation is SIBLING, but the Origin Domain ID is the same as the local MASC domain, the Updated Origin Role is changed to INTERNAL. This is necessary in case a MASC node receives from a parent or sibling its own UPDATEs
Radoslavov, et al. Experimental [Page 36] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 36] RFC 2909 The MASC Protocol September 2000
after reboot, or if because of internal partitioning, the
INTERNAL_PEERs are exchanging UPDATEs via other MASC domains
(either parent or sibling(s)).
after reboot, or if because of internal partitioning, the INTERNAL_PEERs are exchanging UPDATEs via other MASC domains (either parent or sibling(s)).
o If both Locally-Configured Role, and Origin Role are equal to
PARENT, and the Origin Domain ID is the same as the local MASC
domain, the Updated Origin Role is changed to INTERNAL. This is
necessary to allow a parent to receive its own UPDATEs through its
own children, although the parent might drop those UPDATEs if it
has a reason not to believe its children.
o If both Locally-Configured Role, and Origin Role are equal to PARENT, and the Origin Domain ID is the same as the local MASC domain, the Updated Origin Role is changed to INTERNAL. This is necessary to allow a parent to receive its own UPDATEs through its own children, although the parent might drop those UPDATEs if it has a reason not to believe its children.
o If both Locally-Configured Role, and Origin Role are equal to
PARENT, and the Origin Domain ID is the same as the remote MASC
domain, and the UPDATE type is CLAIM_DENIED, the Updated Origin
Role is changed to INTERNAL. This is necessary to allow a parent
to receive the CLAIM_DENIED it has originated through the child
whose claim was denied. If the Origin Domain ID is not same as
the remote MASC domain, but is same as some of the other MASC
children domains, the Updated Origin Role still should be changed
to INTERNAL, although the parent might drop this UPDATE if it has
a reason not to believe a third party child.
o If both Locally-Configured Role, and Origin Role are equal to PARENT, and the Origin Domain ID is the same as the remote MASC domain, and the UPDATE type is CLAIM_DENIED, the Updated Origin Role is changed to INTERNAL. This is necessary to allow a parent to receive the CLAIM_DENIED it has originated through the child whose claim was denied. If the Origin Domain ID is not same as the remote MASC domain, but is same as some of the other MASC children domains, the Updated Origin Role still should be changed to INTERNAL, although the parent might drop this UPDATE if it has a reason not to believe a third party child.
If the Updated Origin Role is INTERNAL, but the Origin Domain ID differs from the local Domain ID, a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> must be sent back, and the claim is rejected.
If the Updated Origin Role is INTERNAL, but the Origin Domain ID differs from the local Domain ID, a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> must be sent back, and the claim is rejected.
If Claim Timestamp and Claim Holdtime indicate that the claim has expired (e.g. Timestamp + Claim Holdtime <= CurrentTime), the UPDATE is silently dropped and no further actions are taken.
If Claim Timestamp and Claim Holdtime indicate that the claim has expired (e.g. Timestamp + Claim Holdtime <= CurrentTime), the UPDATE is silently dropped and no further actions are taken.
Each new arrival UPDATE is compared with all claims in the local cache. The following fields are compared, and if all of them are the same, the message is silently rejected and no further actions are taken:
Each new arrival UPDATE is compared with all claims in the local cache. The following fields are compared, and if all of them are the same, the message is silently rejected and no further actions are taken:
o Role, D-bit, Type
o Role, D-bit, Type
o AddrFam
o AddrFam
o Claim Timestamp
o Claim Timestamp
o Claim Lifetime
o Claim Lifetime
o Claim Holdtime
o Claim Holdtime
o Origin Domain Identifier
o Origin Domain Identifier
Radoslavov, et al. Experimental [Page 37] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 37] RFC 2909 The MASC Protocol September 2000
o Origin Node Identifier
o Origin Node Identifier
o Address
o Address
o Mask
o Mask
Further processing of an UPDATE is based on its type and the Updated Origin Role.
Further processing of an UPDATE is based on its type and the Updated Origin Role.
11.2. PREFIX_IN_USE Message Processing
11.2. PREFIX_IN_USE Message Processing
11.2.1. PREFIX_IN_USE by PARENT
11.2.1. PREFIX_IN_USE by PARENT
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
11.2.2. PREFIX_IN_USE by SIBLING
11.2.2. PREFIX_IN_USE by SIBLING
If the claim cannot be associated with any parent's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If the claim cannot be associated with any parent's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If the claim collides with some of the local domain's pending claims, the local claims must not be considered further, and the Claim-Timer of each of them must be canceled. If the received PREFIX_IN_USE claim clashes with and wins over some of the local domain's allocated prefixes, resolve the clash according to Section 12.4. Finally, the claim must be propagated further to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain and all known siblings with the same parent domain.
If the claim collides with some of the local domain's pending claims, the local claims must not be considered further, and the Claim-Timer of each of them must be canceled. If the received PREFIX_IN_USE claim clashes with and wins over some of the local domain's allocated prefixes, resolve the clash according to Section 12.4. Finally, the claim must be propagated further to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain and all known siblings with the same parent domain.
11.2.3. PREFIX_IN_USE by CHILD
11.2.3. PREFIX_IN_USE by CHILD
If the claim's prefix is not a subrange of any of the local domain's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken. Otherwise, the claim must be propagated further to all INTERNAL_PEERs and all MASC children domains.
If the claim's prefix is not a subrange of any of the local domain's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken. Otherwise, the claim must be propagated further to all INTERNAL_PEERs and all MASC children domains.
11.2.4. PREFIX_IN_USE by INTERNAL_PEER
11.2.4. PREFIX_IN_USE by INTERNAL_PEER
If the MASC node decides that the local domain does not need that prefix any more, it may be withdrawn, otherwise, the claim is processed as PREFIX_MANAGED.
If the MASC node decides that the local domain does not need that prefix any more, it may be withdrawn, otherwise, the claim is processed as PREFIX_MANAGED.
Radoslavov, et al. Experimental [Page 38] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 38] RFC 2909 The MASC Protocol September 2000
11.3. CLAIM_DENIED Message Processing
11.3. CLAIM_DENIED Message Processing
11.3.1. CLAIM_DENIED by CHILD or SIBLING
11.3.1. CLAIM_DENIED by CHILD or SIBLING
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
11.3.2. CLAIM_DENIED by INTERNAL_PEER
11.3.2. CLAIM_DENIED by INTERNAL_PEER
Propagate to all INTERNAL_PEERs and all MASC children nodes.
Propagate to all INTERNAL_PEERs and all MASC children nodes.
11.3.3. CLAIM_DENIED by PARENT
11.3.3. CLAIM_DENIED by PARENT
If the Origin Domain ID is not same as the local domain ID, and the UPDATE cannot be associated with any parent domain, the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If the Origin Domain ID is not same as the local domain ID, and the UPDATE cannot be associated with any parent domain, the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If the Origin Domain ID is not same as the local domain ID, and the UPDATE can be associated with a parent domain, the message is propagated to all nodes from that parent domain, all INTERNAL_PEERs, and all known SIBLINGs with regard to that parent.
If the Origin Domain ID is not same as the local domain ID, and the UPDATE can be associated with a parent domain, the message is propagated to all nodes from that parent domain, all INTERNAL_PEERs, and all known SIBLINGs with regard to that parent.
If the Origin Domain ID is same as the local domain ID, and there is no corresponding pending claim originated by the local MASC domain (i.e. a NEW_CLAIM or CLAIM_TO_EXPAND with same AddrFam, Origin Domain ID, Claim Timestamp, Address and Mask), a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back and no further actions should be taken. Otherwise, the matching NEW_CLAIM or CLAIM_TO_EXPAND's Claim-Timer must be canceled and the claim must not be considered further. Finally, the received CLAIM_DENIED must be propagated to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain, and all known SIBLINGs with regard to that parent.
If the Origin Domain ID is same as the local domain ID, and there is no corresponding pending claim originated by the local MASC domain (i.e. a NEW_CLAIM or CLAIM_TO_EXPAND with same AddrFam, Origin Domain ID, Claim Timestamp, Address and Mask), a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back and no further actions should be taken. Otherwise, the matching NEW_CLAIM or CLAIM_TO_EXPAND's Claim-Timer must be canceled and the claim must not be considered further. Finally, the received CLAIM_DENIED must be propagated to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain, and all known SIBLINGs with regard to that parent.
11.4. CLAIM_TO_EXPAND Message Processing
11.4. CLAIM_TO_EXPAND Message Processing
11.4.1. CLAIM_TO_EXPAND by PARENT
11.4.1. CLAIM_TO_EXPAND by PARENT
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
Radoslavov, et al. Experimental [Page 39] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 39] RFC 2909 The MASC Protocol September 2000
11.4.2. CLAIM_TO_EXPAND by SIBLING
11.4.2. CLAIM_TO_EXPAND by SIBLING
If the claim cannot be associated with any parent's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If the claim cannot be associated with any parent's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If there is no overlapping PREFIX_IN_USE by the same MASC domain, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix> must be sent back and no further actions should be taken.
If there is no overlapping PREFIX_IN_USE by the same MASC domain, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix> must be sent back and no further actions should be taken.
If the claim collides with and wins over some of the local domain's pending claims, the loser claims must not be considered further, and the Claim-Timer of the each of them must be canceled. Also, the received claim must be propagated further to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain and all known siblings with the same parent domain.
If the claim collides with and wins over some of the local domain's pending claims, the loser claims must not be considered further, and the Claim-Timer of the each of them must be canceled. Also, the received claim must be propagated further to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain and all known siblings with the same parent domain.
11.4.3. CLAIM_TO_EXPAND by CHILD
11.4.3. CLAIM_TO_EXPAND by CHILD
If the claim cannot be associated with any of the local domain's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If the claim cannot be associated with any of the local domain's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If there is no overlapping PREFIX_IN_USE by the same MASC domain, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix> must be sent back and no further actions should be taken.
If there is no overlapping PREFIX_IN_USE by the same MASC domain, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix> must be sent back and no further actions should be taken.
Otherwise, the claim has to be propagated to all INTERNAL_PEERs. If the lifetime of the claim is longer than the lifetime of the corresponding prefix managed by the local domain, or if there is an administratively configured reason to prevent the child from succeeding allocating the claimed prefix, a CLAIM_DENIED must be sent to all MASC children nodes that have same Domain ID as Origin Domain ID in the received message. The CLAIM_DENIED must be the same as the received claim, except Rol=INTERNAL, and Claim Lifetime should be set to the maximum allowed lifetime. Otherwise, propagate the claim to all children as well.
Otherwise, the claim has to be propagated to all INTERNAL_PEERs. If the lifetime of the claim is longer than the lifetime of the corresponding prefix managed by the local domain, or if there is an administratively configured reason to prevent the child from succeeding allocating the claimed prefix, a CLAIM_DENIED must be sent to all MASC children nodes that have same Domain ID as Origin Domain ID in the received message. The CLAIM_DENIED must be the same as the received claim, except Rol=INTERNAL, and Claim Lifetime should be set to the maximum allowed lifetime. Otherwise, propagate the claim to all children as well.
11.4.4. CLAIM_TO_EXPAND by INTERNAL_PEER
11.4.4. CLAIM_TO_EXPAND by INTERNAL_PEER
If the claim cannot be associated with any parent's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further action should be taken.
If the claim cannot be associated with any parent's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further action should be taken.
Radoslavov, et al. Experimental [Page 40] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 40] RFC 2909 The MASC Protocol September 2000
If there is no overlapping PREFIX_IN_USE by the local MASC domain, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back and no further actions should be taken.
If there is no overlapping PREFIX_IN_USE by the local MASC domain, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back and no further actions should be taken.
If the MASC node decides that the local domain does not need that pending claim any more, it MAY be withdrawn. Otherwise, the claim must be propagated to all INTERNAL_PEERs and all MASC nodes from the corresponding parent MASC domain.
If the MASC node decides that the local domain does not need that pending claim any more, it MAY be withdrawn. Otherwise, the claim must be propagated to all INTERNAL_PEERs and all MASC nodes from the corresponding parent MASC domain.
11.5. NEW_CLAIM Message Processing
11.5. NEW_CLAIM Message Processing
If the claim's Address field is 0 (i.e. a hint by a child to a parent to obtain more space), the claim should be propagated only among the nodes that belong to the child Origin Domain and the parent domain.
If the claim's Address field is 0 (i.e. a hint by a child to a parent to obtain more space), the claim should be propagated only among the nodes that belong to the child Origin Domain and the parent domain.
Otherwise, process like CLAIM_TO_EXPAND, except that no check for overlapping PREFIX_IN_USE needs to be performed.
Otherwise, process like CLAIM_TO_EXPAND, except that no check for overlapping PREFIX_IN_USE needs to be performed.
11.6. PREFIX_MANAGED Message Processing.
11.6. PREFIX_MANAGED Message Processing.
11.6.1. PREFIX_MANAGED by PARENT
11.6.1. PREFIX_MANAGED by PARENT
If the Origin Domain ID matches one of the parents' domain ID's, the prefix is recorded, and can be used by the address allocation algorithm for allocating subranges. Also, the message is propagated to all MASC nodes of the corresponding parent domain, all INTERNAL_PEERs, and SIBLINGs with same parent.
If the Origin Domain ID matches one of the parents' domain ID's, the prefix is recorded, and can be used by the address allocation algorithm for allocating subranges. Also, the message is propagated to all MASC nodes of the corresponding parent domain, all INTERNAL_PEERs, and SIBLINGs with same parent.
11.6.2. PREFIX_MANAGED by CHILD or SIBLING
11.6.2. PREFIX_MANAGED by CHILD or SIBLING
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
11.6.3. PREFIX_MANAGED by INTERNAL_PEER
11.6.3. PREFIX_MANAGED by INTERNAL_PEER
The prefix is recorded as allocated to the local domain, propagated to all INTERNAL_PEERs, and can be used for (all items apply):
The prefix is recorded as allocated to the local domain, propagated to all INTERNAL_PEERs, and can be used for (all items apply):
a) address ranges/prefixes advertisements to all MASC children and
local domain's MAASs;
a) address ranges/prefixes advertisements to all MASC children and local domain's MAASs;
b) injection into G-RIB;
b) injection into G-RIB;
c) further expansion by the address allocation algorithm (see
Appendix A);
c) further expansion by the address allocation algorithm (see Appendix A);
Radoslavov, et al. Experimental [Page 41] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 41] RFC 2909 The MASC Protocol September 2000
11.7. WITHDRAW Message Processing
11.7. WITHDRAW Message Processing
11.7.1. WITHDRAW by CHILD
11.7.1. WITHDRAW by CHILD
If the WITHDRAW cannot be associated with any of the child domain's PREFIX_IN_USE (i.e. no child's PREFIX_IN_USE covers WITHDRAW's range), or if the WITHDRAW does not match any of the child domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no child's claim with same Address, Mask and Timestamp), the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix> must be sent back and no further actions should be taken. Otherwise, propagate to all INTERNAL_PEERs and children.
If the WITHDRAW cannot be associated with any of the child domain's PREFIX_IN_USE (i.e. no child's PREFIX_IN_USE covers WITHDRAW's range), or if the WITHDRAW does not match any of the child domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no child's claim with same Address, Mask and Timestamp), the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix> must be sent back and no further actions should be taken. Otherwise, propagate to all INTERNAL_PEERs and children.
11.7.2. WITHDRAW by SIBLING
11.7.2. WITHDRAW by SIBLING
If the WITHDRAW cannot be associated with any of the siblings' PREFIX_IN_USE (i.e. no sibling's PREFIX_IN_USE covers WITHDRAW's range), or if the WITHDRAW does not match any of the sibling domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no sibling's claim with same Address, Mask and Timestamp), the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix> must be sent back and no further actions should be taken. Otherwise, propagate to all INTERNAL_PEERs, all MASC nodes from the same parent MASC domain and all known siblings with the same parent domain.
If the WITHDRAW cannot be associated with any of the siblings' PREFIX_IN_USE (i.e. no sibling's PREFIX_IN_USE covers WITHDRAW's range), or if the WITHDRAW does not match any of the sibling domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no sibling's claim with same Address, Mask and Timestamp), the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix> must be sent back and no further actions should be taken. Otherwise, propagate to all INTERNAL_PEERs, all MASC nodes from the same parent MASC domain and all known siblings with the same parent domain.
11.7.3. WITHDRAW by INTERNAL
11.7.3. WITHDRAW by INTERNAL
If the WITHDRAW cannot be associated with any of the local domain's PREFIX_IN_USE or PREFIX_MANAGED (i.e. no local domain's prefix covers WITHDRAW's range), or if the WITHDRAW does not match any of the local domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no local domain's claim with same Address, Mask and Timestamp) the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back and no further actions should be taken.
If the WITHDRAW cannot be associated with any of the local domain's PREFIX_IN_USE or PREFIX_MANAGED (i.e. no local domain's prefix covers WITHDRAW's range), or if the WITHDRAW does not match any of the local domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no local domain's claim with same Address, Mask and Timestamp) the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back and no further actions should be taken.
Otherwise, propagate to all INTERNAL_PEERs, all MASC nodes of the corresponding parent domain of that prefix, all known siblings with that parent domain, and all children. If the WITHDRAW can be associated with some of local domain's PREFIX_IN_USE or PREFIX_MANAGED, stop advertising the WITHDRAW range to the MAASs and withdraw that range from the G-RIB database. In the special case when there is an indication that the WITHDRAW has been originated by the local domain because of a clash, and the range specified in WITHDRAW is a subrange of the local PREFIX_MANAGED, and the Claim Holdtime of WITHDRAW is shorter than the Claim Holdtime of
Otherwise, propagate to all INTERNAL_PEERs, all MASC nodes of the corresponding parent domain of that prefix, all known siblings with that parent domain, and all children. If the WITHDRAW can be associated with some of local domain's PREFIX_IN_USE or PREFIX_MANAGED, stop advertising the WITHDRAW range to the MAASs and withdraw that range from the G-RIB database. In the special case when there is an indication that the WITHDRAW has been originated by the local domain because of a clash, and the range specified in WITHDRAW is a subrange of the local PREFIX_MANAGED, and the Claim Holdtime of WITHDRAW is shorter than the Claim Holdtime of
Radoslavov, et al. Experimental [Page 42] RFC 2909 The MASC Protocol September 2000
Radoslavov, et al. Experimental [Page 42] RFC 2909 The MASC Protocol September 2000
PREFIX_MANAGED, the WITHDRAW's range should not be withdrawn from the G-RIB. If the WITHDRAW matches a local domain's NEW_CLAIM or CLAIM_TO_EXPAND, cancel the matching claim's Claim-Timer.
PREFIX_MANAGED, the WITHDRAW's range should not be withdrawn from the G-RIB. If the WITHDRAW matches a local domain's NEW_CLAIM or CLAIM_TO_EXPAND, cancel the matching claim's Claim-Timer.
11.7.4. WITHDRAW by PARENT
11.7.4. WITHDRAW by PARENT
If the WITHDRAW cannot be associated with any parent domain, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
If the WITHDRAW cannot be associated with any parent domain, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
Otherwise, propagate to all INTERNAL_PEERs and all known siblings with the same parent domain. Also, originate a WITHDRAW message for each intersection of a locally owned PREFIX_MANAGED/PREFIX_IN_USE and the received WITHDRAW. The locally originated WITHDRAW message's Claim Holdtime should be at least equal to the Claim Holdtime in the WITHDRAW message received from the parent; the Origin Node ID should be the same as the particular PREFIX_MANAGED/PREFIX_IN_USE.
Otherwise, propagate to all INTERNAL_PEERs and all known siblings with the same parent domain. Also, originate a WITHDRAW message for each intersection of a locally owned PREFIX_MANAGED/PREFIX_IN_USE and the received WITHDRAW. The locally originated WITHDRAW message's Claim Holdtime should be at least equal to the Claim Holdtime in the WITHDRAW message received from the parent; the Origin Node ID should be the same as the particular PREFIX_MANAGED/PREFIX_IN_USE.
11.8. UPDATE Message Ordering
11.8. UPDATE Message Ordering
To simplify consistency and sanity check implementations, if there is more than one UPDATE message that needs to be send to a peer (for example, after a connection (re)establishment), some of the UPDATEs must be sent before others.
To simplify consistency and sanity check implementations, if there is more than one UPDATE message that needs to be send to a peer (for example, after a connection (re)establishment), some of the UPDATEs must be sent before others.
The rules that always apply are:
The rules that always apply are:
o PREFIX_IN_USE must always be sent BEFORE CLAIM_TO_EXPAND,
NEW_CLAIM, and WITHDRAW by the same MASC domain
o PREFIX_IN_USE must always be sent BEFORE CLAIM_TO_EXPAND, NEW_CLAIM, and WITHDRAW by the same MASC domain
o WITHDRAW must always be sent AFTER PREFIX_IN_USE, CLAIM_TO_EXPAND,
NEW_CLAIM, and PREFIX_MANAGED by the same MASC domain
o _TO_EXPAND、NEW_クレーム、およびPREFIX_MANAGEDは、同じMASCドメインのそばでいつも_AFTER PREFIX_IN USEをWITHDRAWに送らなければならないのを要求します。
Any further ordering is defined below by the roles of the sender and the receiver.
これ以上、注文は以下で送付者と受信機の役割によって定義されます。
11.8.1. Parent to Child
11.8.1. 子供の親
Messages are sent in the following order:
以下のオーダーでメッセージを送ります:
1) Parent's PREFIX_MANAGED and WITHDRAWs.
1) 親の接頭語_は管理して、引き下がります。
2) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
CLAIMs from third party children that are hints for more space
(i.e. address = 0) should not be propagated; if propagated, the
child should drop them.
2) _すべての子供のPREFIX_IN USE、_がTO_EXPANDであることを要求してください。そうすれば、第三者子供からの、より多くのスペース(すなわち、アドレス=0)のためのヒントであるNEW_CLAIMs. CLAIMsを伝播するべきではありません。 伝播されるなら、子供はそれらを落とすべきです。
Radoslavov, et al. Experimental [Page 43] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[43ページ]RFC2909MASCプロトコル2000年9月
3) Parent initiated CLAIM_DENIED and children initiated WITHDRAWs.
CLAIM_DENIED regarding third party children's claims/hints with
address = 0 should not be propagated; if propagated, the child
should drop them.
3) 親の開始しているクレーム_DENIEDと子供はWITHDRAWsを開始しました。 アドレス=0がある第三者子供のクレーム/ヒントに関するクレーム_DENIEDを伝播するべきではありません。 伝播されるなら、子供はそれらを落とすべきです。
11.8.2. Child to Parent
11.8.2. 親への子供
Messages are sent in the following order:
以下のオーダーでメッセージを送ります:
1) Parent's PREFIX_MANAGED and WITHDRAWs.
1) 親の接頭語_は管理して、引き下がります。
2) All PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMSs from that
parent's space, initiated by that child and all its siblings.
2) _PREFIX_IN USE、_TOがEXPAND、およびその親のスペースからのNEW_CLAIMSsがその子供とそのすべての兄弟で開始した_であることを要求してください。
3) Parent's initiated CLAIM_DENIED, and all WITHDRAWSs that can be
associated with that parent's space and are initiated by the local
domain or all known siblings with that parent.
3) 親は、クレーム_DENIED、およびその親のスペースに関連づけることができて、局所領域によって開始されるすべてのWITHDRAWSsを開始するか、またはその親と一緒にいる兄弟を皆、知っていました。
11.8.3. Sibling to Sibling
11.8.3. 兄弟の兄弟
Messages are sent in the following order:
以下のオーダーでメッセージを送ります:
1) All common parent's PREFIX_MANAGED and WITHDRAWs.
1) すべての一般的な親のPREFIX_MANAGEDとWITHDRAWs。
2) PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs, initiated by
siblings.
2) _PREFIX_IN USE、_TOがEXPAND、およびNEW_CLAIMsが兄弟で開始した_であることを要求してください。
3) CLAIM_DENIEDs initiated by common parent, and WITHDRAWs initiated
by local domain and all known siblings with that parent.
3) その親と共に_が一般的な親によって開始されたDENIEDsであり、WITHDRAWsが皆、局所領域によって開始している、知られている兄弟であることを要求してください。
11.8.4. Internal to Internal
11.8.4. 内部に、内部です。
Messages are sent in the following order:
以下のオーダーでメッセージを送ります:
1) All parents' PREFIX_MANAGED and WITHDRAWs.
1) すべての両親のPREFIX_MANAGEDとWITHDRAWs。
2) Local domain's and all siblings' PREFIX_IN_USE, CLAIM_TO_EXPAND,
and NEW_CLAIMs. CLAIMs from siblings that are hints for more
space (i.e. address = 0) should not be propagated; if propagated,
the recipient should drop them.
2) _局所領域とすべての兄弟のPREFIX_IN USE、_がTO_EXPANDであることを要求してください。そうすれば、より多くのスペース(すなわち、アドレス=0)のためのヒントである兄弟からのNEW_CLAIMs. CLAIMsを伝播するべきではありません。 伝播されるなら、受取人はそれらを落とすべきです。
3) CLAIM_DENIEDs initiated by all parents, and WITHDRAWs initiated by
local domain and all known siblings.
3) _がすべての両親によって開始されたDENIEDsであり、WITHDRAWsが皆、局所領域によって開始している、知られている兄弟であることを要求してください。
4) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
4) _すべての子供のPREFIX_IN USE、_がTO_EXPANDと、NEW_CLAIMsであることを要求してください。
5) All local domain initiated CLAIM_DENIED regarding children claims
and all children initiated WITHDRAWs.
5) すべての局所領域が子供クレームに関してクレーム_DENIEDを開始しました、そして、すべての子供がWITHDRAWsを開始しました。
Radoslavov, et al. Experimental [Page 44] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[44ページ]RFC2909MASCプロトコル2000年9月
12. Operational Considerations
12. 操作上の問題
12.1. Bootup Operations
12.1. Bootup操作
To learn about its parent domains' IDs and prefixes, a MASC node SHOULD try to establish connections to its PARENT nodes before initiating a connection to a SIBLING node. To avoid learning about its own PREFIX_MANAGED from its children or siblings, a MASC node SHOULD try to establish connections to its PARENT nodes and INTERNAL_PEER nodes before initiating a connection to a CHILD or SIBLING node.
親ドメインのIDと接頭語、MASCノードに関して学ぶために、SIBLINGノードに接続を開始する前に、SHOULDはPARENTノードに関係を樹立しようとします。 それ自身のPREFIX_MANAGEDに関して子供か兄弟、MASCノードから学ぶのを避けるために、CHILDかSIBLINGノードに接続を開始する前に、SHOULDはPARENTノードとINTERNAL_PEERノードに関係を樹立しようとします。
12.2. Leaf and Non-leaf MASC Domain Operation
12.2. 葉と非葉のMASCドメイン手術
A non-leaf MASC domain (i.e. a domain that has children domains) should advertise its PREFIX_MANAGED addresses to its children, and should claim from that space the sub-ranges that would be advertised to the internal MAASs (the claim wait time SHOULD be equal to [WAITING_PERIOD]). A MASC node that belongs to a non-leaf MASC domain should perform dual functions by being a child of itself with regard to the claiming and management of the sub-ranges for local usage. A leaf MASC domain should advertise all PREFIX_MANAGED addresses to its MAASs without explicitly claiming them for internal usage. A MASC node can assume that it belongs to a leaf domain if it simply does not have any UPDATEs by children domains. If an UPDATE by a child is received, the domain MUST switch from "leaf" to "non- leaf" mode, and if it needs more addresses for internal usage, it MUST claim them from that domain's PREFIX_MANAGED. After the last UPDATE originated by a child expires, the domain can switch back to "leaf" mode.
クレームは時間SHOULDを待っています。非葉のMASCドメイン(すなわち、子供ドメインを持っているドメイン)がPREFIX_MANAGEDアドレスの子供に広告を出すべきであり、そのスペースから内部のMAASsに広告に掲載されているサブ範囲を要求するべきである、([WAITING_PERIOD)と等しくいてください。 非葉のMASCドメインに属すMASCノードは、ローカルの用法のためにサブ範囲の要求と管理に関してそれ自体の子供であることで二元的な機能を実行するはずです。 明らかに内部の用法に彼らの代金を請求しないで、葉のMASCドメインはすべてのPREFIX_MANAGEDアドレスのMAASsに広告を出すべきです。 MASCノードは、子供ドメインのそばに少しのUPDATEsも絶対に持っていないなら葉のドメインに属すと仮定できます。 子供によるUPDATEが受け取られているなら、ドメインは「葉」から「非葉」モードに切り替わらなければなりません、そして、内部の用法のための、より多くのアドレスを必要とするなら、それはそのドメインのPREFIX_MANAGEDからそれらを要求しなければなりません。 子供によって溯源された最後のUPDATEが期限が切れた後に、ドメインは「葉」モードに元に戻ることができます。
12.3. Clock Skew Workaround
12.3. 時計斜行次善策
Each UPDATE has "Claim Timestamp" field that is set to the absolute time of the MASC node that originated that UPDATE. The timestamp is used for two purposes: to resolve collisions, and to define how long an UPDATE should be kept in the local cache of other MASC nodes. A skew in the clock could result in unfair collision decision such that the claims originated by nodes that have their clock behind the real time will always win; however, because collisions are presumably rare, this will not be an issue. Skew in the clock however might result in expiring an UPDATE earlier than it really should be expired, and a node might assume too early that the expired UPDATE/prefix is free for allocation. To compensate for the clock skew, an UPDATE message should be kept longer than the amount of time specified in the Claim Holdtime. For example, keeping UPDATEs for an additional 24 hours will compensate for clock skew for up to 24 hours.
各UPDATEには、そのUPDATEを溯源したMASCノードの絶対時間に設定される「クレームタイムスタンプ」分野があります。 タイムスタンプは2つの目的に使用されます: 衝突を決議して、UPDATEが他のMASCノードでどれくらい長い状態でローカルなキャッシュで保たれるべきであるかを定義するために。 時計の斜行はリアルタイムの後ろにそれらの時計を持っているノードによって溯源されたクレームがいつも得られるように、不公平な衝突決定をもたらすかもしれません。 しかしながら、衝突がおそらくまれであるので、これは問題にならないでしょう。 しかしながら、時計の斜行はそれが本当に吐き出されるべきであるより早くUPDATEを吐き出すのに結果として生じるかもしれません、そして、ノードはあまりに早く配分において、満期のUPDATE/接頭語が無料であると仮定するかもしれません。 時計斜行を補うために、UPDATEメッセージは時間がクレームHoldtimeで指定したより長い間、保たれるべきです。 例えば、追加24時間UPDATEsを保つと、時計斜行は24時間まで補われるでしょう。
Radoslavov, et al. Experimental [Page 45] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[45ページ]RFC2909MASCプロトコル2000年9月
12.4. Clash Resolving Mechanism
12.4. メカニズムを決議して、衝突してください。
If a MASC node receives a PREFIX_IN_USE claim originated by a sibling and the claim overlaps with some of the local prefixes, the clash must be resolved. Two MASC domains should not manage overlapping address ranges, unless the domains have an ancestor-descendant (e.g. parent-child) relationship in the MASC hierarchy. Also, two MASC domains should not have locally-allocated overlapping address ranges. The clashed address ranges should not be advertised to the MAASs and allocated to multicast applications/sessions. If a clashed address has being allocated to an application, the application should be informed to stop using that address and switch to a new one.
MASCノードが兄弟によって溯源されたPREFIX_IN_USEクレームを受け取って、クレームがローカルの接頭語のいくつかに重なるなら、衝突を決議しなければなりません。 2つのMASCドメインはアドレスの範囲を重ね合わせながら、管理されるべきではありません、ドメインがMASC階層構造で先祖子孫(例えば、親子)関係を持っていないなら。 また、2つのMASCドメインは局所的にアドレスの範囲を重なるのに割り当てるべきではありませんでした。 衝突したアドレスの範囲はMAASsに広告を出して、マルチキャストアプリケーション/セッションまで割り当てるべきではありません。 衝突したアドレスをアプリケーションに割り当てたなら、アプリケーションは、そのアドレスとスイッチを新しいものまで使用するのを止めるために知識があるべきです。
The G-RIB database must be consistent, such that it does not have ambiguous entries. "Ambiguous G-RIB entries" are those entries that might cause the multicast routing protocol to loop or lose connectivity. In MASC the WITHDRAW message is used to solve this problem. When a clashing PREFIX_IN_USE is received, it is compared (using the function describe in Section 5.1.1) against all prefixes allocated to the local domain. If the local PREFIX_IN_USE is the winner, no further actions are taken. If the local PREFIX_IN_USE is the loser, the clashing address range must be withdrawn by initiating a WITHDRAW message. The message must have Role = INTERNAL, Origin Node ID and Origin Domain ID must be the same as the corresponding local PREFIX_IN_USE message, while Claim Timestamp, Claim Lifetime, Claim Holdtime, Address and Mask must be the same as the received winning PREFIX_IN_USE. The initiated WITHDRAW message must be processed as described in Section 11.7.
G-RIBデータベースが一貫しているに違いないので、それには、あいまいなエントリーがありません。 「あいまいなG-RIBエントリー」はマルチキャストルーティング・プロトコルが接続性を輪にするか、または失うことを引き起こすかもしれないそれらのエントリーです。 MASCでは、WITHDRAWメッセージは、この問題を解決するのに使用されます。 衝突している_PREFIX_IN USEが受け取られているとき、それは局所領域に割り当てられたすべての接頭語に対して比較されます(機能がセクション5.1.1で説明する使用)。 地方の_PREFIX_IN USEが勝者であるなら、さらなる行動を全く取りません。 地方の_PREFIX_IN USEがひどいしろものであるなら、衝突しているアドレスの範囲は、WITHDRAWメッセージを開始することによって、引き下がらなければなりません。 RoleはメッセージでINTERNAL、Origin Node IDと等しくなければなりません、そして、Origin Domain IDは対応するローカルのPREFIX_IN_USEメッセージと同じであるに違いありません、クレームTimestamp、クレームLifetime、クレームHoldtime、Address、およびMaskは_容認された勝利PREFIX_IN USEと同じであるに違いありませんが。 セクション11.7で説明されるように開始しているWITHDRAWメッセージを処理しなければなりません。
If a cached WITHDRAW times out and the local MASC domain owns an overlapping PREFIX_MANAGED or PREFIX_IN_USE, the overlapping prefix ranges can be injected back into the G-RIB database. Similarly, the address ranges that were not advertised to the local domain's MAASs due to the WITHDRAW, can now be advertised again.
aが外でWITHDRAW回をキャッシュして、地方のMASCドメインが重なっている_PREFIX MANAGEDかPREFIX_IN_USEを所有しているなら、重なっている接頭語範囲をG-RIBデータベースに注ぎ返すことができます。 同様に、それがアドレスの範囲であったのはWITHDRAWのため局所領域のMAASsに広告を出さないで、現在、再び広告を出すことができます。
In addition to the automatic resolving of clashes, a MASC implementation should support manual resolving of clashes. For example, after a clash is detected, the network administrator should be informed that a clash has occurred. The specific manual mechanisms are outside the scope of this protocol.
衝突の自動決議に加えて、MASC実現は衝突の手動の決議を支持するべきです。 例えば、衝突が検出された後にネットワーク管理者に衝突が起こったと知らされるべきです。 このプロトコルの範囲の外に特定の手動のメカニズムがあります。
A MASC node must be configured to operate using either manual or automatic clash resolution mechanisms.
手動の、または、自動である衝突解決メカニズムを使用することで作動するためにMASCノードを構成しなければなりません。
Radoslavov, et al. Experimental [Page 46] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[46ページ]RFC2909MASCプロトコル2000年9月
12.5. Changing Network Providers
12.5. ネットワーク内の提供者を変えます。
If a MASC domain changes a network provider, such that the old provider cannot be used to provide connectivity, any traffic for sessions that are in progress and use that MASC domain as the root of multicast distribution trees will not be able to reach that domain.
MASCドメインが接続性を提供するのに古いプロバイダーを使用できないようにネットワーク内の提供者を変えると、進行中であり、マルチキャスト分配木の根としてそのMASCドメインを使用するセッションのためのどんな交通もそのドメインに達することができないでしょう。
If the new network provider is willing to carry the traffic for the old sessions rooted at the customer domain, then it must propagate the customer's old prefixes through the G-RIB. However, at least one MASC node in the customer domain must maintain a TCP connection to one of the old network provider's MASC nodes. Thus, it can continue to "defend" the customer's prefixes, and should continue until the old prefixes' lifetimes expire.
新しいネットワーク内の提供者が、顧客ドメインに根づいている古いセッションのための交通を運んでも構わないと思っているなら、それはG-RIBを通して顧客の古い接頭語を伝播しなければなりません。 しかしながら、顧客ドメインの少なくとも1つのMASCノードが古いネットワーク内の提供者のMASCノードの1つにTCP接続を維持しなければなりません。 したがって、それは、顧客の接頭語を「防御し」続けることができて、古い接頭語の寿命が期限が切れるまで、続くべきです。
If the new network provider is not willing to propagate the old prefixes, then the customer should remove its prefixes from the G- RIB. If BGMP is in use, the old network provider's domain will automatically become the Root Domain for the customer's old groups due to the lack of a more specific group route. MASC nodes in the customer domain MAY still connect with the old provider's MASC nodes to defend their allocation.
新しいネットワーク内の提供者が古い接頭語を伝播することを望んでいないなら、顧客はG RIBから接頭語を取り除くべきです。 BGMPが使用中であるなら、古いネットワーク内の提供者のドメインは、より特定のグループルートの不足のため自動的に顧客の古いグループのためのRoot Domainになるでしょう。 顧客ドメインのMASCノードは、彼らの配分を防御するためにまだ古いプロバイダーのMASCノードに接続しているかもしれません。
12.6. Debugging
12.6. デバッグ
12.6.1. Prefix-to-Domain Lookup
12.6.1. 接頭語からドメインへのルックアップ
Use mtrace [MTRACE] to find the BGMP/MASC root domain for a group address chosen from that prefix.
mtrace[MTRACE]を使用して、その接頭語から選ばれたグループアドレスに関してBGMP/MASC根のドメインを見つけてください。
12.6.2. Domain-to-Prefix Lookup
12.6.2. ドメインから接頭語へのルックアップ
We can find the address space allocated to a particular MASC domain by directly querying one of the MASC servers within that domain, by observing the state in parents, siblings, or children MASC domains, or by observing the G-RIB information originated by that domain. From those three methods, the first method can provide the most detailed information. Finding the address of one of the MASC nodes within a particular domain is outside the scope of MASC.
私たちは、そのドメインの中で直接MASCサーバの1つについて質問するか、両親、兄弟、または子供MASCドメインの状態を観測するか、またはそのドメインによって溯源されたG-RIB情報を観測することによって、特定のMASCドメインに割り当てられたアドレス空間を見つけることができます。 それらの3つの方法から、最初の方法は最も詳細な情報を提供できます。 MASCの範囲の外に特定のドメインの中でMASCノードの1つのアドレスを見つけるのがあります。
13. MASC Storage
13. MASC格納
In general, MASC will be run by a border routers, which, in general do not have stable storage. In this case, MASC must use the Layer 2 protocol/mechanism (e.g., ([AAP]) as described in [MALLOC] to store the important information (the prefixes allocated by the local domain) in the domain's MAASs who should have stable storage. If the
一般に、MASCは境界ルータによって走らされる、どれ、一般に、安定貯蔵を持たないでくださいか。 この場合、MASCは安定貯蔵を持っているはずであるドメインのMAASsの重要情報(局所領域によって割り当てられた接頭語)を格納するために[MALLOC]で説明されるようにLayer2プロトコル/メカニズム(例えば、[AAP])を使用しなければなりません。
Radoslavov, et al. Experimental [Page 47] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[47ページ]RFC2909MASCプロトコル2000年9月
MASC speaker has local storage, it should use it instead of the Layer 2 protocol/mechanism. Claims that are in progress do not have to be saved by using the Layer 2 protocol/mechanism.
MASCスピーカーには、地方の格納があって、それはLayer2プロトコル/メカニズムの代わりにそれを使用するべきです。 進行しているクレームは、Layer2プロトコル/メカニズムを使用することによって、保存される必要はありません。
14. Security Considerations
14. セキュリティ問題
IPsec [IPSEC] can be used to address security concerns between two MASC peering nodes. However, because of the store-and-forward nature of the UPDATE messages, it is possible that if a non-trustworthy MASC node can connect to some point of the MASC topology, then this node can undetectably inject malicious UPDATEs that may disturb the normal operation of other MASC nodes. To address this problem, each MASC node should allow peering only with trustworthy nodes.
2つのMASCじっと見るノードの間の安全上の配慮を記述するのに、IPsec[IPSEC]を使用できます。 しかしながら、UPDATEメッセージの店とフォワード本質のために、非信頼できるMASCノードがMASCトポロジーの何らかのポイントに接続できるならこのノードがundetectablyに他のMASCノードの通常操作を擾乱するかもしれない悪意があるUPDATEsを注入できるのは、可能です。 このその問題を訴えるために、それぞれのMASCノードは、単に信頼できるノードでじっと見るのを許容するはずです。
After a reboot, a MASC node/domain can restore its state from its neighbors (internal peers, parents, siblings, children). Typically, the state received from a parent or internal peer will be trustworthy, but a node may choose to drop its own UPDATEs that were received through a sibling or a child.
リブートの後に、MASCノード/ドメインは隣人(内部の同輩、両親、兄弟、子供)から状態を回復できます。 親か内部の同輩から受け取られた状態は通常、信頼できるようになるでしょうが、ノードは、兄弟か子供を通して受け取られたそれ自身のUPDATEsを落とすのを選ぶかもしれません。
A misbehaving node may attempt a Denial of Service attack by sending a large number of colliding messages that would prevent any of its siblings from allocating more addresses. A single mis-behaving node can easily be identified by all of its siblings, and all of its UPDATEs can be ignored. A Denial of Service attack that uses multiple origin addresses can be prevented if a third-party UPDATE (e.g. by a non-directly connected sibling) is accepted only if it is sent via the common parent domain, and the MASC nodes in the parent domain accept children UPDATEs only if they come via an internal peer, or come directly from a child node that is same as the Origin Node ID.
ふらちな事するノードは、兄弟のどれかが、より多くのアドレスを割り当てるのを防ぐメッセージを多くの衝突に送ることによって、サービス妨害攻撃を試みるかもしれません。 兄弟のすべてで容易にただ一つの誤の振る舞いノードを特定できます、そして、UPDATEsのすべてを無視できます。 一般的な親ドメインを通してそれを送る場合にだけ第三者UPDATE(例えば、非直接接続された兄弟による)を受け入れるなら、複数の起源アドレスを使用するサービス妨害攻撃は防ぐことができて、彼らが内部の同輩を通して来るか、または直接Origin Node IDと同じ子供ノードから来る場合にだけ、親ドメインのMASCノードは子供UPDATEsを受け入れます。
15. IANA Considerations
15. IANA問題
This document defines several number spaces (MASC message types, MASC OPEN message optional parameters types, MASC UPDATE message attribute types, MASC UPDATE message optional parameters types, and MASC NOTIFICATION message error codes and subcodes). For all of these number spaces, certain values are defined in this specification. New values may only be defined by IETF Consensus, as described in [IANA- CONSIDERATIONS]. Basically, this means that they are defined by RFCs approved by the IESG.
このドキュメントはいくつかの数の空間(MASCメッセージタイプ、MASC OPENのメッセージの任意のパラメタタイプ、MASC UPDATEメッセージ属性タイプ、MASC UPDATEのメッセージの任意のパラメタタイプ、MASC NOTIFICATIONメッセージエラーコード、および部分符号)を定義します。 これらの数の空間のすべてに関しては、ある値はこの仕様に基づき定義されます。 新しい値は[IANA- CONSIDERATIONS]で説明されるようにIETF Consensusによって定義されるだけであるかもしれません。 基本的に、これは、それらがIESGによって承認されたRFCsによって定義されることを意味します。
16. Acknowledgments
16. 承認
The authors would like to thank the participants of the IETF for their assistance with this protocol.
作者はこのプロトコルによる彼らの支援についてIETFの関係者に感謝したがっています。
Radoslavov, et al. Experimental [Page 48] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[48ページ]RFC2909MASCプロトコル2000年9月
17. APPENDIX A: Sample Algorithms
17. 付録A: サンプルアルゴリズム
DISCLAIMER: This section describes some preliminary suggestions by various people for algorithms which could be used with MASC.
注意書き: このセクションはMASCと共に使用できたアルゴリズムのために様々な人々によるいくつかの予備の勧めについて説明します。
17.1. Claim Size and Prefix Selection Algorithm
17.1. クレームサイズと接頭語選択アルゴリズム
This section covers the algorithms used by a MASC node (on behalf of a MASC domain) to satisfy the demand for multicast addresses. The allocated addresses should be aggregatable, the address utilization should be reasonably high, and the allocation latency to the MAASs should be shorter than [WAITING_PERIOD] whenever possible.
このセクションはMASCノード(MASCドメインを代表した)によって使用される、マルチキャストアドレスの需要を満たすアルゴリズムをカバーします。 割り当てられたアドレスが「集合-可能」であるはずであり、アドレス利用がかなり高いはずであり、可能であるときはいつも、MAASsへの配分潜在は[WAITING_PERIOD]より短いはずです。
17.1.1. Prefix Expansion
17.1.1. 接頭語拡大
For ease of implementation and troubleshooting, MASC should use contiguous masks to specify the address ranges, i.e. prefixes. (Research indicates that sufficiently good results can be achieved using contiguous masks only.) The chosen prefixes should be as expandable as possible. The method used to choose the children sub- prefixes from the parent's prefix is the so called Reverse Bit Ordering (idea by Dave Thaler; inspired by Kampai [KAMPAI]). For example, if the parent's prefix width is four bits, the addresses of the sub-prefixes are chosen in the following order:
実現とトラブルシューティングの容易さのために、MASCはアドレスの範囲を指定する隣接のマスク、すなわち、接頭語を使用するはずです。 (研究は、隣接のマスクだけを使用することで十分良い結果を獲得できるのを示します。) 選ばれた接頭語はできるだけ拡張可能であるべきです。 親の接頭語からのサブ接頭語の子供を選ぶのに使用される方法はいわゆるReverse Bit Ordering(デーヴThaler; Kampai[KAMPAI]によって奮い立たせられるのによる考え)です。 例えば、親の接頭語幅が4ビットであるなら、サブ接頭語のアドレスは以下のオーダーで選ばれています:
Parent: xxxx
親: xxxx
Child A: 0000 Child B: 1000 Child C: 0100 Child D: 1100
子供A: 0000年の子供B: 1000年の子供C: 0100年の子供D: 1100
If some of the children need to expand their sub-prefix, they try to double the corresponding sub-prefix starting from the right:
何人かの子供が、彼らのサブ接頭語を広げる必要があるなら、右から始めて、彼らは対応するサブ接頭語を倍にしようとします:
Child A: 000x Child A: 00xx Child D: 110x Child D: 11xx
子供A: 000x子供A: 00xx子供D: 110x子供D: 11xx
and so on.
など。
However, because the address ordering is very strict, to reduce the probability for collision, when a new sub-prefix has to be chosen, the choice should be random among all candidates with the same potential for expandability. For example, if the free sub-prefixes are 01xx, 10xx, 110x, then the new prefix to claim should be chosen with probability of 50% for 01xx and 50% for 10xx for example.
しかしながら、新しいサブ接頭語が選ばれなければならないとき、アドレス注文が衝突のために確率を減少させるために非常に厳しいので、選択はすべての候補の中で拡張可能性の同じ可能性で無作為であるべきです。 例えば、10xx無料のサブ接頭語が01xxであるなら、110x、そして、要求する新しい接頭語は01xxのための50%と例えば、10xxのための50%の確率で選ばれるべきです。
Radoslavov, et al. Experimental [Page 49] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[49ページ]RFC2909MASCプロトコル2000年9月
17.1.2. Reducing Allocation Latency
17.1.2. 配分レイテンシを減少させます。
To reduce the allocation latency, a MASC node uses pre-allocation. It constantly monitors the demand for addresses from its children (or MAASs), and predicts what would be the address usage after [WAITING_PERIOD]. Only if the available addresses will be used up within [WAITING_PERIOD], a MASC node claims more addresses in advance.
配分レイテンシを減少させるために、MASCノードはプレ配分を使用します。 それは、子供(または、MAASs)からアドレスの要求を絶えずモニターして、[WAITING_PERIOD]の後にアドレス用法であることを予測します。 利用可能なアドレスが[WAITING_PERIOD]の中で使いきられる場合にだけ、MASCノードはあらかじめ、より多くのアドレスを要求します。
17.1.3. Address Space Utilization
17.1.3. アドレス空間利用
Because every prefix size is a power of two, if a node tries to allocate just a single prefix, the utilization at that node (i.e. at that node's domain) can be as low as 50%. To improve the utilization, a MASC node can have more than one prefix allocated at a time (typically, each of them with different size). By using a pre- allocation and allocating several prefixes of different size (see below), a MASC node should try to keep its address utilization in the range 70-90%.
ノードがまさしくただ一つの接頭語を割り当てようとするならあらゆる接頭語サイズが2のパワーであるので、そのノード(すなわち、そのノードのドメインの)での利用は50%と同じくらい低いことができます。 利用を改良するために、MASCノードで、一度に(通常それらのそれぞれが異なったサイズである)、1つ以上の接頭語を割り当てることができます。 プレ配分を使用して、異なったサイズ(以下を見る)のいくつかの接頭語を割り当てることによって、MASCノードは範囲にアドレス利用を70-90%保とうとするはずです。
17.1.4. Prefix Selection After Increase of Demand
17.1.4. 需要増加の後の接頭語選択
To additionally reduce the allocation latency by reducing the probability for collision, and to improve the aggregability of the allocated addresses, a MASC node carefully chooses the prefixes to claim. The first prefix is chosen at random among all reasonably expandable candidates. If a node chooses to allocate another, smaller prefix, then, instead of doubling the size of the first one which might reduce significantly the address utilization, a second "neighbor" prefix is chosen. For example, if prefix 224.0/16 was already allocated, and the MASC domain needs 256 more addresses, the second prefix to claim will be 224.1.0/24. If the domain needs more addresses, the second prefix will eventually grow to 224.1/16, and then both prefixes can be automatically aggregated into 224.0/15. Only if 224.0.1/24 could not be allocated, a MASC node will choose another prefix (eventually random among the unused prefixes).
衝突のために確率を減少させることによって配分レイテンシをさらに、減少させて、割り当てられたアドレスのaggregabilityを改良するために、MASCノードは慎重に要求する接頭語を選びます。 最初の接頭語はすべての合理的に拡張可能な候補の中で無作為に選ばれています。 ノードが、別のものを割り当てるのを選ぶなら、2番目の「隣人」接頭語が選ばれているより小さいアドレス利用をかなり抑えるかもしれない最初のもののサイズを倍にすることの代わりに当時の接頭語です。 例えば既に接頭語224.0/16を割り当てて、MASCドメインがもう256のアドレスを必要として、要求する2番目の接頭語が224.1が.0/24であったなら割り当てたつもりであったなら。 ドメインが、より多くのアドレスを必要とすると、2番目の接頭語は結局224.1/16まで成長するでしょう、そして、次に、自動的に両方の接頭語は224.0/15に集めることができます。 224.0に.1/24を割り当てることができない場合にだけ、MASCノードは(結局、未使用の接頭語の中で無作為)で別の接頭語を選ぶでしょう。
If the number of allocated prefixes increases above some threshold, and none of them can be extended when more addresses are needed, then, to reduce the amount of state, a MASC node should claim a new larger prefix and should stop re-claiming the older non-expandable prefixes. Research results show that up to three prefixes per MASC domain is a reasonable threshold, such that the address utilization can be in the range 70-90%, and at the same time the prefix flux will be reasonably low.
割り当てられた接頭語の数が何らかの敷居より上まで増加して、次に、より多くのアドレスが状態の量を減少させるのに必要であるときにそれらのどれかを広げることができないなら、MASCノードは、新しいより大きい接頭語を主張するべきであり、より古い非拡張可能な接頭語を開墾するのを止めるはずです。 結果が示しているMASCドメインあたり3つの接頭語まで範囲70-90%にはアドレス利用があることができるための妥当な敷居である研究と同時に接頭語フラックスはかなり低くなるでしょう。
Radoslavov, et al. Experimental [Page 50] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[50ページ]RFC2909MASCプロトコル2000年9月
17.1.5. Prefix Selection After Decrease of Demand
17.1.5. 要求の減少の後の接頭語選択
If the demand for addresses decreases, such that its address space is under-utilized, a MASC node implicitly returns the unused prefixes after their lifetimes expire, or re-claims some smaller sub-prefixes. For example, if prefix 224.0/15 is 50% used by the MAASs and/or children MASC domains, and the overall utilization is such that approximately 2^16 (64K) addresses should be returned, a MASC node should stop reclaiming 224.0/15 and should start reclaiming either 224.0/16 or 224.1/16 (whichever sub-prefix utilization is higher).
アドレスの需要がアドレス空間が下の利用されているように減少するなら、MASCノードは、彼らの寿命が期限が切れた後にそれとなく未使用の接頭語を返すか、またはいくつかの、より小さいサブ接頭語を開墾します。 例えば、MASCノードは、接頭語224.0/15がMAASsによって使用された50%、そして/または、子供MASCドメインであり、総合的な利用がそのようなものであるのでおよそ2^16(64K)のアドレスを返すなら224.0/15を取り戻すのを止めるべきであり、224.0/16か224.1/16(どのより高いサブ接頭語利用)を取り戻すか始めるはずです。
17.1.6. Lifetime Extension Algorithm
17.1.6. 生涯拡大アルゴリズム
If the demand for addresses did not decrease, then a MASC node re- claims the prefixes it has allocated before their lifetime expires. Each prefix (or sub-prefix if the demand has decreased) should be re-claimed every 48 hours.
アドレスの需要が減少しなかったなら、彼らの寿命が期限が切れる前にMASCノードはそれが割り当てた接頭語を再要求します。 各接頭語、(サブ接頭語、需要が減少した、)、48時間毎に開墾されるべきです。
18. APPENDIX B: Strawman Deployment
18. 付録B: わら人形展開
At the moment of writing, 225.0.0.0-225.255.255.255 is temporarily allocated to MALLOC. Presumably this block of addresses will be used for experimental deployment and testing.
この文を書いているときに、MALLOCに割り当てて、225.0.0.0-225.255.255.255は一時そうです。 おそらくアドレスのこのブロックは実験的な展開とテストに使用されるでしょう。
If MASC were widely deployed on the Internet, we might expect numbers similar to the following:
MASCがインターネットで広く配備されるなら、私たちは以下と同様の数を予想するでしょうに:
o Initially will have approximately 128 Top-Level Domains
o 初めは、およそ128Top-レベルDomainsを持つでしょう。
o Assume initially approximately 8192 level-2 MASC domains; on
average, a TLD will have approximately 64 children domains.
o 初めは、8192年頃のレベル-2MASCドメインを仮定してください。 TLDには、平均的に、およそ64の子供ドメインがあるでしょう。
o MASC managed global addresses:
o MASCはグローバルなアドレスを管理しました:
The following (large) ranges are not allocated yet (2^N represents
the size of the contiguous mask prefixes):
以下の(大きい)の範囲はまだ割り当てられていません(2^Nは隣接のマスク接頭語のサイズを表します):
225.0.0.0 - 231.255.255.255 = 2^26 + 2^25 + 2^24
234.0.0.0 - 238.255.255.255 = 2^25 + 2^25 + 2^24
---------------------------
Total: 12*2^24 addresses
225.0.0.0 - 231.255.255.255 = 2^26 + 2^25 + 2^24 234.0.0.0 - 238.255.255.255 = 2^25 + 2^25 + 2^24 --------------------------- 以下を合計してください。 12 *2^24アドレス
Initially, the range 228.0.0.0 - 231.255.255.255 (4*2^24 = 2^26 =
64M) could be used by MASC as the global addresses pool. The rest
(8*2^24) should be reserved. Part of it could be added later to
MASC, or can be used to enlarge the pool of administratively
scoped addresses (currently 239.X.X.X), or the pool for static
allocation (233.X.X.X).
初めは、範囲、228.0、.0、.0、--231.255 .255 .255 グローバルなアドレスが水たまりになって、MASCは(4*2^24 = 2^26 = 64M)を使用できました。 残り(8*2^24)は予約されるべきです。 それの一部を後でMASCに加えることができたか、または行政上見られたアドレスのプール(現在の239.X.X.X)、または静的割り付けのためのプール(233.X.X.X)を拡大するのに使用できます。
Radoslavov, et al. Experimental [Page 51] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[51ページ]RFC2909MASCプロトコル2000年9月
o If the multicast addresses are evenly distributed, each TLD would
have a maximum of 2^19 (512K) addresses, while each level-2 MASC
domain would have 8192 addresses.
o マルチキャストアドレスが均等に配布されるなら、各TLDには、最大2^19(512K)のアドレスがあるでしょう、それぞれのレベル-2MASCドメインでは、8192のアドレスがあるでしょうが。
o Initial claim size: 256 addresses/MASC domain
o クレームサイズに頭文字をつけてください: 256アドレス/MASCドメイン
o Could use soft and hard thresholds to specify the maximum amount
of claimed+allocated addresses per domain. For example, trigger a
warning message if claimed+allocated addresses by a domain is >=
1.0*average_assumed_per_domain (a strawman default soft
threshold):
o 最大の量の1ドメインあたりの要求されたか割り当てられたアドレスを指定するのに柔らかくて困難な敷居を使用できました。 例えば、__ドメイン(わら人形のデフォルトの柔らかい敷居)あたりの_であると思われて、ドメインのそばの要求されたか割り当てられたアドレスが>=1.0*平均であるなら警告メッセージの引き金となってください:
* if a TLD claim+allocation >= 512K
* if a second level MASC domain claim+allocation >= 8K
* *2番目の平らなMASCドメインクレーム+配分>が8Kと等しいならTLDクレーム+配分>が512Kと等しいなら
The hard threshold (for example, 2.0*average_assumed_per_domain)
can be enforced by sending an explicit DENIED message.
明白なDENIEDメッセージを送ることによって、困難な敷居(例えば、2.0*平均_は_ドメインあたりの_を仮定した)を励行されることができます。
The TLDs thresholds (with regard to the claims by the second level
MASC domains) is a private matter and is a part of the particular
TLD policy: the thresholds could be per customer, and the warnings
to the administrators could be a signal that it is time to change
the policy.
TLDs敷居(2番目の平らなMASCドメインのそばでのクレームに関する)は、個人的な問題であり、特定のTLD方針の一部です: 敷居が顧客単位であるかもしれません、そして、管理者への警告はもう方針を変えるべき時間であるという信号であるかもしれません。
o Initial claim lifetime is of the order of 30 days. Prefix
lifetime is periodically (every 48 hours) reclaimed/extended,
unless the prefix is under-utilized (see APPENDIX A). Because the
allocation is demand-driven, the allocated prefix lifetime will be
automatically extended if the MAASs need longer prefix lifetime
(e.g. 3-6 months).
o 寿命が30日間の注文のものであるというクレームに頭文字をつけてください。 生涯を前に置いてください。接頭語が下の利用されていない場合(APPENDIX Aを見てください)、定期的に開墾されるか、または広げられます(48時間毎)。 配分が需要主導であるので、MAASsが、より長い間(例えば、3-6カ月)生涯を前に置かなければならないなら広げられて、割り当てられた接頭語生涯意志は自動的に需要主導です。
o A level-2 MASC domain could have children (i.e. level-3) MASC
domains.
o レベル-2MASCドメインには、子供(すなわち、レベル-3)MASCドメインがあるかもしれません。
o If a level-2 or level-3 MASC domain uses less than 128 addresses,
a Layer 2 protocol/mechanism (e.g. AAP) should be run among that
domain and its parent MASC domain.
o レベル-2かレベル-3MASCドメインが128未満のアドレスを使用するなら、Layer2プロトコル/メカニズム(例えば、AAP)はそのドメインとその親MASCドメインの中で動かされるべきです。
19. Authors' Addresses
19. 作者のアドレス
Pavlin Radoslavov Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
ロサンゼルス、パブリンラドスラーボフコンピュータサイエンス部の南カリフォルニア大学/ISIカリフォルニア90089米国
EMail: pavlin@catarina.usc.edu
メール: pavlin@catarina.usc.edu
Radoslavov, et al. Experimental [Page 52] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[52ページ]RFC2909MASCプロトコル2000年9月
Deborah Estrin Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
ロサンゼルス、デボラEstrinコンピュータサイエンス部の南カリフォルニア大学/ISIカリフォルニア90089米国
EMail: estrin@isi.edu
メール: estrin@isi.edu
Ramesh Govindan University of Southern California/ISI 4676 Admiralty Way Marina Del Rey, CA 90292 USA
Ramesh Govindan南カリフォルニア大学/ISI4676海軍省Wayマリナデル・レイ(カリフォルニア)90292米国
EMail: govindan@isi.edu
メール: govindan@isi.edu
Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) 1947 Center St., Suite 600 Berkeley, CA 94704 USA
ISCI(ACIRI)1947センター通り、600バークレー、スイートカリフォルニア94704米国でのインターネット調査のためのマークハンドレーAT&Tセンター
EMail: mjh@aciri.org
メール: mjh@aciri.org
Satish Kumar Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
ロサンゼルス、サティシュクマーコンピュータサイエンス部の南カリフォルニア大学/ISIカリフォルニア90089米国
EMail: kkumar@usc.edu
メール: kkumar@usc.edu
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
デヴィッドターレルマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: dthaler@microsoft.com
メール: dthaler@microsoft.com
Radoslavov, et al. Experimental [Page 53] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[53ページ]RFC2909MASCプロトコル2000年9月
20. References
20. 参照
[AAP] Handley, M. and S. Hanna, "Multicast Address
Allocation Protocol (AAP)", Work in Progress.
[AAP] 「マルチキャストアドレス配分プロトコル(AAP)」というハンドレー、M.、およびS.ハンナは進行中で働いています。
[API] Finlayson, R., "An Abstract API for Multicast
Address Allocation", RFC 2771, February 2000.
[API] フィンリースン、R.、「マルチキャストアドレス配分のための抽象的なAPI」、RFC2771、2000年2月。
[BGMP] Thaler, D., Estrin, D. and D. Meyer, "Border
Gateway Multicast Protocol (BGMP): Protocol
Specification", Work in Progress.
[BGMP] ターレル、D.、Estrin、D.、およびD.マイヤー、「ゲートウェイマルチキャストプロトコル(BGMP)に接してください」 「プロトコル仕様」、処理中の作業。
[BGP] Rekhter, Y. and T. Li, "A Border Gateway
Protocol 4 (BGP-4)", RFC 1771, March 1995.
1995年の[BGP]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[CIDR] Rekhter, Y. and C. Topolcic, "Exchanging
Routing Information Across Provider Boundaries
in the CIDR Environment", RFC 1520, September
1993.
[CIDR] RekhterとY.とC.Topolcic、「CIDR環境におけるプロバイダー限界の向こう側に経路情報を交換する」RFC1520、1993年9月。
[IANA] Reynolds, J. and J. Postel, "Assigned Numbers",
STD 2, RFC 1700, October 1994.
[IANA] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
[IANA-問題]Alvestrand、H.、およびT.Narten、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。
[IPSEC] Kent, S. and R. Atkinson, "Security
Architecture for the Internet Protocol", RFC
2401, November 1998.
[IPSEC] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[KAMPAI] Tsuchiya, P., "Efficient and Flexible
Hierarchical Address Assignment", INET92, June
1992, pp. 441--450.
[KAMPAI] Tsuchiya、P.、「効率的でフレキシブルな階層的なアドレス課題」、INET92、1992年6月、ページ 441--450.
[MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast
Address Dynamic Client Allocation Protocol
(MADCAP)", RFC 2730, December 1999.
[向こう見ずな] ハンナとS.とパテルとB.とM.シャー、「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、RFC2730、1999年12月。
[MALLOC] Thaler, D., Handley, M. and D. Estrin, "The
Internet Multicast Address Allocation
Architecture", RFC 2908, September 2000.
[MALLOC] ターレルとD.とハンドレーとM.とD.Estrin、「インターネットマルチキャストアドレス配分構造」、RFC2908、2000年9月。
[MBGP] Bates, T., Chandra, R., Katz, D. and Y.
Rekhter, "Multiprotocol Extensions for BGP-4",
RFC 2283, September 1997.
[MBGP] ベイツとT.とチャンドラとR.とキャッツとD.とY.Rekhter、「BGP-4インチのためのMultiprotocol拡張子、RFC2283、1997年9月。」
Radoslavov, et al. Experimental [Page 54] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[54ページ]RFC2909MASCプロトコル2000年9月
[MTRACE] Fenner, W., and S. Casner, "A `traceroute'
facility for IP Multicast", Work in Progress.
Progressの[MTRACE]フェナー、W.、およびS.Casner、「IP Multicastのための'トレースルート'施設」、Work。
[MZAP] Handley, M, Thaler, D. and R. Kermode
"Multicast-Scope Zone Announcement Protocol
(MZAP)", RFC 2776, February 2000.
[MZAP] ハンドレーとMとターレルとD.とR.カーモード「マルチキャスト範囲ゾーン発表プロトコル(MZAP)」、RFC2776、2000年2月。
[RFC1112] Deering, S., "Host Extensions for IP
Multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[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月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6
Addressing Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[SCOPE] Meyer, D., "Administratively Scoped IP
Multicast", RFC 2365, July 1998.
[範囲] マイヤー、D.、「行政上見られたIPマルチキャスト」、RFC2365、1998年7月。
Radoslavov, et al. Experimental [Page 55] RFC 2909 The MASC Protocol September 2000
ラドスラーボフ、他 実験的な[55ページ]RFC2909MASCプロトコル2000年9月
21. Full Copyright Statement
21. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Radoslavov, et al. Experimental [Page 56]
ラドスラーボフ、他 実験的[56ページ]
一覧
スポンサーリンク
