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
The Multicast Address-Set Claim (MASC) Protocol
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書では、ドメイン間のマルチキャストアドレスのセットの割り当てのために使用することができるマルチキャストアドレス設定項（MASC）プロトコルを記述する。 MASCは、請求項とそのノードのドメインへの1つ以上のアドレスプレフィックスを割り当てるノード（典型的にはルータ）によって使用されます。ドメインは、必ずしもグループアドレスを割り当てることができるように、そのドメイン内のホストに設定されたアドレスを割り当てる必要はありませんが、ドメインに設定されたアドレスを割り当てることは、ドメイン間のグループ固有配信ツリーがローカルに根ざしされることを保証ず、及びそのトラフィックは、外部の受信機が存在する場合にのみ、ドメイン外に送信されます。
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
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
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、ドメイン間のマルチキャストアドレス設定の割り当てのためのプロトコルを記述しています。 MASCプロトコル（マルチキャストアドレス割当アーキテクチャ[MALLOC]におけるレイヤ3プロトコルは）請求項およびそのノードのドメインへの1つ以上のアドレスプレフィックスを割り当てるノード（典型的にはルータ）によって使用されます。各プレフィックスは、プレフィックスが集約されているように、関連した寿命を有し、そして少なくとも同じ長寿命を有するより大きなプレフィックスから選択されます。任意の時点で、各MASCノード（[MALLOC]内のプレフィックスコーディネーター）は、典型的には、それらのクライアントのための適切なアドレスを選択し、そのドメインまたは子MASCドメインに（MAASの）マルチキャストアドレス割り当てサーバを許可する、異なる寿命とスコープを持つ複数のプレフィックスを通知します。
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.
ドメインに関連付けられたプレフィクスのセット（「アドレスセット」）は、それはドメイン間マルチキャストツリー構築プロトコル（例えば、BGMPで使用することができるドメイン間ルーティングプロトコル（例えば、BGP4 + [MBGP]）に注入されます【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.
、ドメイングループアドレスを割り当てることができるように、そのドメイン内のホストのアドレスセットを割り当てる必要はなく、また必ずしも割り当てる他のドメイン内のホストは、例えば、以来（セットのアドレスを使用しないことを保証しないことに注意してくださいホストがグループアドレス）を使用する前に、MAASに連絡することを余儀なくされていません。ドメインに設定されたアドレスを割り当てることは、しかしながら、局所的に根するアドレスセット中の任意のグループに対するそのインタードメイングループ固有のマルチキャスト配信ツリーを確保ず、そのトラフィックは、所与のドメイン外に送信される場合にのみ、どこ外部受信機が存在します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Constants used by this protocol are shown as [NAME_OF_CONSTANT], and summarized in Section 6.
このプロトコルによって使用される定数は、[NAME_OF_CONSTANT]として示され、そして第6節にまとめられています。
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.
本明細書は、読者によく知らないかもしれない多くの用語を使用します。このセクションでは、これらのいくつかを定義し、他の人の定義については、他の文書を参照します。
MAAS (Multicast Address Allocation Server) A host providing multicast address allocation services to end users (e.g. via MADCAP [MADCAP]).
MAAS（マルチキャストアドレス割り当てサーバ）エンドユーザにマルチキャストアドレス割当サービスを提供するホスト（例えば介しMADCAP [MADCAP]）。
MASC server A node running MASC.
MASCサーバノードで実行MASC。
Peer Other MASC speakers a node directly communicates with.
ノードが直接通信を行う他のMASCのスピーカーをピア。
Multicast IP Multicast, as defined for IPv4 in [RFC1112] and for IPv6 in [RFC2460].
[RFC2460]の[RFC1112]およびIPv6用IPv4で定義した通りでマルチキャストIPマルチキャスト。
Multicast Address An IP multicast address or group address, as defined in [RFC1112] and [RFC2373]. An identifier for a group of nodes.
[RFC1112]及び[RFC2373]で定義されるように、IPマルチキャストアドレスやグループアドレスをアドレスマルチキャスト。ノードのグループのための識別子。
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]での世話をされているように、主要な設計制約ではありません。
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, 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）プロトコルは、請求項と各ドメイン内のマルチキャストアドレス割り当てサーバ（Maass第）による使用のためにアドレスセットを割り当てるMASCドメインによって使用されます。一般的に、独自のマルチキャストアドレス空間を必要とする各ドメインの1つのまたは複数の境界ルータは、MASCを実行します。本明細書を通して、用語「MASCドメイン」MASCを実行する少なくとも1つのノードを有するドメインを指します。 （だAS）は、通常、これらのドメインは、自律システムになります。 （そのドメインの代わりに）MASCノードは、任意の衝突の特許請求の範囲のために聴きながら他の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のノードが選択したアドレスセットは、そのノードのドメインに割り当てられていると考えられています。三つのことはその後に起こることがあります。
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-RIB」ネットワークレイヤ到達可能性情報（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）サブプレフィックスは、子ドメインに割り当てることができます。
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ドメインで必要とされるであろう。これは、レプリカの同期の関連する問題およびアドレス空間の多分追加の断片化をもたらします。また、でもこのメカニズムでは、アドレスの衝突は、まだ処理する必要があります。私たちは、提案されている請求-衝突のメカニズムは、クエリ応答メカニズムよりも簡単かつより堅牢であると考えています。
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 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.
MASCによって使用されるドメイン階層は、ドメイン間トポロジーの幾分階層構造と合同であり、例えば、骨格はリージョナルに接続され、BGPのように等大都市プロバイダに接続リージョナル、MASC接続がローカルに設定されています。他のMASCドメインの顧客であるMASCドメインは親として、これらのプロバイダドメインの一つ以上を持つことになります。例えば、地域のプロバイダーですMASCドメインはその親（S）としてその骨格プロバイダドメインの1つ（またはそれ以上）を選択します。子供たちは、親MASCドメインで構成されており、親が子どものドメインで構成されています。上部には、トップレベルドメインの数は、（スパース）メッシュと共有グローバルマルチキャストアドレス空間に接続されています。堅牢性を向上させるために、同じ親ドメインの子のペアは、その親に関しては兄弟として構成されてもよいです。
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とを含む、トップレベルドメイン（例えば、バックボーン・プロバイダー）です。 P3およびP4は、それぞれ（のP3a、P3bの）を含む、地域ドメインであり、（P4aと、P4B）。 P3は（のC5a、C5bと、C5C）を含む単一の顧客（または "子"）、C5を、持っています。 P4は、それぞれ（のC5a、C5bと、C5C）、（C6A、C6B）、及び（C7A）を含む、三人の子供、C5、C6、C7を有します。
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顧客関係が存在します。例えば、C6AはP4aととのセッションでCHILDです。
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プロバイダ関係が存在します。例えば、T2aのはP4aととのセッションで親です。スペースが実際に要求されるかどうかは、実装およびローカルポリシーの設定次第です。
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.
いいえ、顧客プロバイダの関係を兄弟ないことが存在します。例えば、T2aのはT1aの（ピアリングトップレベルドメイン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ドメインは、他の兄弟に親ドメインからのメッセージを伝播し、そして、トップレベルドメインた場合、それがなければならないことができ、他の子供たちに子ドメインからのメッセージを伝達する必要があります親や他の兄弟の兄弟ドメインからのメッセージを伝搬することができるそうでない場合は、他の兄弟の兄弟からのメッセージを伝播します。
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.
各ドメインは、「管理」アドレスセット、および「ローカル割り当て」のアドレスが設定されています。 「管理」のスペースは、ドメインが正常に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を経由して主張しているすべてのアドレス空間。
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.
各プレフィックスは、関連付けられた寿命を持っています。ドメインは、長い寿命よりも接頭辞を使用したい場合は、その寿命が切れる前に、そのドメインは、接頭辞を「更新」しなければならない（5.2節を参照してください）。寿命を延長することができない場合は、ドメインは拡張するために、後で再試行するべきか、別の接頭辞を選択して、主張すべきです。
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のノードのローカルメモリから削除することができます。
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.
その子に親によってアドバタイズ各プレフィックスは、「アクティブ」または「非推奨」のいずれかになります。 「非推奨」プレフィックスは、親がその寿命が満了した後に使用することを中止することを希望する接頭辞です。 「アクティブ」の接頭辞は、サイズのみの展開や寿命延長のための候補です。通常、この情報はその寿命が延長している場合があります親のプレフィックスのかを知るためのヒントとして、子供によって使用されます。
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つの兄弟ノード。親に関連する情報は、同一の親に対応する接続を介して送信されます。内部ピアは、それらの間の複数の接続を開く必要はありません。単一の接続は、全ての情報のために使用されています。
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.
MASCは、管理スコープゾーン[SCOPE]内のアドレスのサブ割り当てプレフィックスのために使用することができるが、（[MZAP] [MALLOC]に記載されたように）範囲は、「分割」である場合にのみ。 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は、」スコープゾーン内には親ドメインを持っていないドメインです。ゾーンのTLDは、スコープに関連付けられている接頭語のためのTLDとしての役割を果たす。図2は、（T1）、その唯一の親が境界の外にあるので、ゾーンTLDはスコープ境界の周りP3をドメインおよびC5 1.ドメインP3を図に追加された例を与えます。したがって、P3は、スコープ自体に関連付けられたプレフィクスから直接空間を請求することができます。ドメインC5は、一方で、範囲（すなわち、P3）内の親を有し、それゆえゾーンTLDありません。
T1a-----------T2a
| |
............|....... |
. | . |
. P3a====P3b . P4a
. | | . /
. | | _______/
. | | / .
. | | / .
. C5a====C5b .
. \\ // .
. \\// .
. C5c .
. .
. Admin Scope Zone .
....................
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との間のセッションのような）スコープ境界を横切るピアリング・セッションは無視されます。つまり、このようなメッセージは、このようなセッションを介して送信されていません。
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）の値を決定します。例えば、決定は、このノードは、その親のアドレスセット、その兄弟の主張と配分、独自のアドレスセット、その兄弟から請求メッセージ、および/またはその子の需要パターンとについて持っている知識に基づいてされる可能性がありますローカルドメイン。サンプルアルゴリズムは、付録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ノードは、それが現在その親ドメイン内の少なくとも1つのノードと確立された接続を有する場合にのみ、親MASCドメインに向けて請求を開始することができます。
After the prefix address and size are decided, the claim proceeds as follows: 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_CLAIM_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を参照します）。
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)
PREFIX_IN_USE、CLAIM_DENIED、CLAIM_TO_EXPAND、またはNEW_CLAIM（PREFIX_MANAGEDと比較する必要が特許請求の範囲とみなされない撤退）：O「型」の1つです
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
クレームを発信したノードのMASC識別子O
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
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.
タイプが同じである場合、タイムスタンプは、特許請求の範囲を比較するために使用されます。タイプのいずれかであるNEW_CLAIM（通常の衝突）またはPREFIX_IN_USE（衝突のための信号）場合、実際には二つの特許請求の範囲は、同じタイプを有することになります。タイムスタンプを比較すると、最小の、すなわち最も早いタイムスタンプ勝利と主張しています。タイムスタンプが同じである場合、最小のオリジンノード識別子を有する請求勝。
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.
住所や請求のマスクは（セクション7.3を参照）しながら、請求タイプは、CLAIM_TO_EXPANDでなければならないことを除いて、既に使用中のプレフィックスの寿命を延長するための手順は、新しいスペースを主張と同じでなければならない、（セクション5.1を参照してください）すでに割り当てられたプレフィックスと同じ。前記タイマーが満了すると衝突がない場合、所望の寿命を想定しています。
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.
住所や請求のマスクは（セクション7.3を参照）を設定する必要がありながら、すでに使用中のプレフィックスの寿命を延長するための手順は、請求タイプはCLAIM_TO_EXPANDでなければならないことを除いて、（セクション5.1を参照）は、新しいスペースを主張すると同じです所望の値に。前記タイマーが満了すると衝突がない場合、所望の大きなプレフィックスがローカル・ドメインに関連付けられています。
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.
ローカルドメインに割り当てられたプレフィックスの有効期間が満了したドメインは、それを再利用する必要がない場合は、この接頭辞に関連付けられているすべてのリソースが削除され、それ以上のアクションは取られません。プレフィックスの有効期間が満了していない場合は、そのプレフィックスのないサブレンジがローカルな利用のためか、子供のドメインの一部で割り当てられていないされている場合、および、スペースは、すべての既知の兄弟と親ドメインに撤退メッセージを送ることによって解放することができます同じ親、およびすべての内部ピア。
MASC uses the following constants:
MASCは、以下の定数を使用しています：
[PORT_NUMBER] 2587. The TCP port number used to listen for incoming MASC connections, as assigned by IANA.
IANAによって割り当てられるようPORT_NUMBER] 2587. 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_CLAIM（又はCLAIM_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_CLAIM_DELAY] MASCノード時間（秒単位）は、新たな請求または空間拡張の請求を開始する前に待機する必要があります。これは間隔（0、[INITIATE_CLAIM_DELAY]）のランダムな値でなければなりません。 600秒（すなわち10分）：[INITIATE_CLAIM_DELAY]のデフォルト値。
[TLD_ID] The Parent Domain Identifier used by a Top-Level Domain (which has no parent). Must be 0.
[TLD_ID]（親を持たない）トップレベルドメインで使用される親ドメイン識別子。 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分）。
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オクテットです。すべての実装は、この最大メッセージサイズをサポートする必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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フィールドの値は常に4096よりも少なくとも4と大きくないなければならず、さらにメッセージの種類に応じて、拘束されてもよいです。余分なデータのない「パディングん」のメッセージが許可された後に、その長さフィールドは、メッセージの残り与えられた必要な最小値を持っている必要があります。
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
Reserved: This 1-octet field is reserved. MUST be set to zero by the sender, and MUST be ignored by the receiver.
予約：この1オクテットのフィールドは予約されています。送信者によってゼロに設定しなければならなく、そして受信機によって無視されなければなりません。
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.
トランスポートプロトコル接続が確立された後、それぞれの側によって送信された最初のメッセージはオープンメッセージです。 OPENメッセージが許容される場合は、OPENを確認するKEEPALIVEメッセージが返送されます。 OPENが確認されると、UPDATE、KEEPALIVE、および通知メッセージを交換することができます。
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:
OPENメッセージの最小の長さは、（メッセージヘッダーを含む）20オクテットです。固定サイズのMASCヘッダに加えて、OPENメッセージは、次のフィールドが含まれています。
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
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)
私の役割（ロル）：この2ビットフィールドは、受信システムへ送信システムの提案された関係を示している：（別の内部ピアから送信された）00 = INTERNAL_PEER（その親に子から送信された）01 = CHILD 10 = （別の兄弟から送られた）SIBLING（その親から子へと送られた）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オクテットの符号なし整数は、送信者がホールドタイマーの値を提案している秒数を示します。 OPENメッセージを受信すると、MASCスピーカーはそのピアとOPENメッセージで受信された保持時間の間、その構成保持時間の小さい方を使用して、ホールドタイマーの値を計算しなければなりません。ホールド時間がゼロまたは少なくとも3秒のいずれかでなければなりません。実装は、ホールド時間に基づいて接続を拒否することができます。算出された値は、送信者によって連続KEEPALIVE及び/又はUPDATEメッセージの受信との間に経過することができる最大秒数を示しています。推奨値は[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.
送信者ドメイン識別子：グローバル一意識別子。その長さは、アドレスファミリに基づいて決定され、符号なし整数（例えばIPv4の4オクテットの整数、またはIPv6の16オクテットの整数）として扱われるべきであるが、少なくとも4つのオクテット長でなければなりません。これは、送信者の自律システム番号に設定する必要がありますが、ネットワークユニキャストプレフィックスアドレスも可能です。
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ノード識別子：このフィールドの長さと形式は、送信者ドメイン識別子フィールドと同じであり、送信者のMASCノード識別子を示します。所与MASCスピーカーは、MASCのスピーカ（例えば、IPv4またはIPv6アドレス）に割り当てられたグローバルに一意の値に、そのMASCノード識別子の値を設定します。 MASCノード識別子の値は、起動時に決定され、セッションが開かれたすべての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 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_ID]に設定されています送信者は、TLDがある場合。ロルがそうでない場合は無視され、INTERNAL_PEERまたはSIBLINGある場合にのみ使用されます。このフィールドは、特定の親を持つ各同胞対の兄弟接続を関連付けるために、内部ピア間TLD関連の構成上の問題を発見するために、兄弟の間に共通の親を決定するために使用されます。非TLDノードがまだその両親のいずれかのドメインIDを知らない場合、それは、その内部ピアにOPENメッセージで、独自のドメイン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.
オプションパラメータ：このフィールドは、各パラメータは、<パラメータ長、パラメータタイプ、パラメータ値>トリプレットとしてエンコードされたオプションのパラメータのリストが含まれていてもよいです。すべてのオプションパラメータの組み合わせた長さは、メッセージヘッダの長さフィールドから導出することができます。
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
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.
パラメータ長は、オクテット単位でパラメータ値フィールドの長さを含む1つのオクテットのフィールドです。パラメータタイプは明確に個々のパラメータを特定する1つのオクテットのフィールドです。パラメータ値は、パラメータタイプフィールドの値に従って解釈される可変長フィールドです。認識できないオプションのパラメータは黙って無視しなければなりません。
This document does not define any optional parameters.
このドキュメントは、オプションのパラメータを定義していません。
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メッセージは、MASCのスピーカー間の請求/衝突/ PrefixManaged情報を転送するために使用されています。 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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All attributes are 4-octets aligned.
すべての属性が揃っ4オクテットです。
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.
長さ：長さは、長さ、タイプ、およびデータ・フィールドを含む、属性全体の長さです。他の属性は、データ・フィールド内にネストされている場合、長さは、すべてのそのようなネストされた属性のサイズを含みます。
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)
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エラーコードと認識されていない必要な属性のサブコードとの通知が送信されます。認識されない任意の属性は、単に無視されます。
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。
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビット。設定した場合、それ以外の接頭辞は（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ビットのフィールドは、そのメッセージを送信するノードへのメッセージの起源の関係/役割を示す：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オクテットのフィールドが予約されています。送信者によってゼロに設定しなければならなく、そして受信機によって無視されなければなりません。
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.
クレーム寿命：クレームのタイムスタンプ間の秒単位の時間、およびプレフィクスが自由になるだろうした時刻。
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].
ホールドタイムを主張する：クレームタイムスタンプ、および請求がローカルキャッシュから削除すべき時刻間の時間を秒単位で。 PREFIX_IN_USEとPREFIX_MANAGEDことが生涯記載に等しくなければならない主張します。 CLAIM_TO_EXPAND、NEW_CLAIM、及びCLAIM_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).
原産地ドメイン識別子：請求発信元のドメイン識別子。その長さおよびフォーマット定義は、送信者ドメイン識別子（セクション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ノードID。その長さおよびフォーマット定義は、Sender MASCノード識別子（セクション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)
住所：指定された接頭辞に関連付けられたアドレスをエンコードします。長さは、アドレスファミリ（IPv6のIPv4の、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.
マスク：指定された接頭辞に関連付けられたマスク。長さは、アドレスフィールドと同じで、アドレスファミリに基づいて決定されます。フィールドには、完全なビットマスクが含まれています。
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を参照）。認識できないオプションのパラメータは黙って無視しなければなりません。このドキュメントは、オプションのパラメータを定義していません。
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は、ピアが到達可能であるかどうかを判断するために、任意のトランスポート・プロトコルベースのキープアライブメカニズムを使用していません。代わりに、キープアライブメッセージは、ホールドタイマーが期限切れに生じないよう十分な頻度でピア間で交換されています。最後KEEPALIVEまたは送信UPDATEメッセージ、およびKEEPALIVEメッセージが送信される時刻との間の合理的な最大時間は、保留時間間隔の三分の一であろう。キープアライブメッセージは、毎秒1よりも頻繁に送ってはいけません。実装は、それが保持時間間隔の関数として、キープアライブメッセージを送信する速度を調整することができます。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
ネゴシエートされた保留時間間隔がゼロであれば、定期的にキープアライブメッセージを送ってはいけません。
A KEEPALIVE message consists of only a message header, and has a length of 4 octets.
KEEPALIVEメッセージは、メッセージヘッダで構成され、4つのオクテットの長さを有しています。
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).
エラー状態が検出されたときに通知メッセージが送信されます。エラー条件によっては、MASCの接続は、またはメッセージを送信した直後に閉じなければならないかもしれません。通知の送信者が接続を閉じることであることを決定した場合、それは（以下を参照）通知メッセージにOビットをゼロにすることによって、これを示すであろう。
In addition to the fixed-size MASC header, the NOTIFICATION message contains the following fields:
固定サイズの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットの符号なし整数は、通知の種類を示します。以下のエラーコードが定義されています。
Error Code Symbolic Name Reference
エラーコードシンボリック名リファレンス
1 Message Header Error Section 8.1
1メッセージヘッダのエラー8.1節
2 OPEN Message Error Section 8.2
2 OPENメッセージエラー8.2節
3 UPDATE Message Error Section 8.3
3 UPDATEメッセージエラー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オクテットの符号なし整数は、報告されたエラーの性質についてのより具体的な情報を提供します。各エラーコードは、それに関連する1つのまたは複数のエラーサブコードを有することができます。いかなる適切なエラーサブコードが定義されていない場合、ゼロ（非特異的）値は、エラーサブコードフィールドに使用され、そしてO-ビットはゼロでなければならない（すなわち、接続が閉じられます）。以下のエラーの説明で使用される表記法は：MC =が接続を閉じる必要があります= Oビットはゼロです。 = OビットがゼロであるかもしれないCCは=接続を閉じることができます。
Message Header Error subcodes:
0 - Unspecific (MC)
1 - Bad Message Length (MC)
2 - Bad Message Type (CC)
OPEN Message Error subcodes:
OPENメッセージエラーサブコード：
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)
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メッセージエラーサブコード：0 - 非特異的（MC）1 - 不正な形式の属性リスト（MC）2 - 認識されていない必須の属性（CC）5 - 属性長エラー（MC）10 - 無効なアドレスフィールド（CC）11 - 無効なマスクフィールド（CC ）12 - 非連続マスク（CC）13 - 認識されないアドレスファミリー（MC）14 - クレームタイプエラー（CC）15 - オリジンドメインIDエラー（CC）16 - オリジンノードIDエラー（CC）17 - 短すぎる請求生涯（CC）18 - クレーム寿命が長すぎる（CC）19 - タイムスタンプ古すぎる（CC）を請求項20 - 請求項タイムスタンプ新しすぎる（CC）21 - クレームプレフィックスサイズが小さすぎる（CC）22 - クレームプレフィックスサイズが大きすぎます（CC） 23 - 不正な起源の役割エラー（CC）24 - いいえ適切な親プレフィックス（CC）25 - いいえ適切な子プレフィックス（CC）26 - いいえ適切な内部プレフィックス（CC）27 - いいえ適切な兄弟プレフィックス（CC）28 - ホールドタイムトゥーを記載ショート（CC）29 - ホールドタイムが長すぎる（CC）を主張
Hold Timer Expired subcodes (the O-bit is always zero):
タイマ（O-ビットは常にゼロである）のサブコードを期限切れホールド：
0 - Unspecific (MC)
0 - 非特異的（MC）
Finite State Machine Error subcodes:
有限ステートマシンのエラーサブコード：
0 - Unspecific (MC)
1 - Open/Close MASC Connection FSM Error (MC)
2 - Unexpected Message Type FSM Error (MC)
Cease subcodes (the O-bit is always zero):
サブコードを（Oビットは常にゼロである）停止。
0 - Unspecific (MC)
0 - 非特異的（MC）
NOTIFICATION subcodes (the O-bit is always zero):
NOTIFICATIONサブコード（Oビットは常にゼロです）。
0 - Unspecific (MC)
0 - 非特異的（MC）
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.
データ：この可変長フィールドは、通知の原因を診断するために使用されます。データフィールドの内容は、エラーコードとエラーサブコードに依存しています。詳細については、セクション8を参照してください。
Note that the length of the Data field can be determined from the message Length field by the formula:
データフィールドの長さが、式によって、メッセージ長フィールドから決定することができることに留意されたいです。
Message Length = 6 + Data Length
メッセージ長= 6 +データ長
The minimum length of the NOTIFICATION message is 6 octets (including message header).
通知メッセージの最小の長さは、（メッセージヘッダーを含む）6つのオクテットです。
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のエラー処理は、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.
ここに記載のいずれかの条件が検出されると、指示されたエラーコード、エラーサブコード、及びデータフィールドを持つ通知メッセージが送信されます。また、MASC接続が閉じられている可能性があります。何のエラーサブコードが指定されていない場合は、ゼロ（非特異的）を使用する必要があります。
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.
明示的に指定しない限り、通知メッセージのデータフィールドは空です。
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).
メッセージヘッダを処理している間に検出されたすべてのエラーは、エラーコードメッセージヘッダエラーでNOTIFICATIONメッセージを送ることによって示されています。エラーサブコードはエラーの特定の性質について詳しく説明します。データフィールドは、（メッセージヘッダーを含む）誤っメッセージを含みます。
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.
メッセージヘッダの長さフィールドには4096より4より小さいか大きい場合、又はOPENメッセージの長さは、オープンメッセージの最小長さより小さい場合、又はUPDATEメッセージの長さが最小長さより小さい場合KEEPALIVEメッセージの長さは4に等しくない場合UPDATEメッセージの、または、エラーサブコードはバートメッセージ長に設定されています。
If the Type field of the message header is not recognized, then the Error Subcode is set to Bad Message Type.
メッセージヘッダのTypeフィールドが認識されない場合は、エラーサブコードはバートメッセージタイプに設定されています。
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.
OPENメッセージの処理中に検出されたすべてのエラーはエラーコードOPENメッセージエラーと通知メッセージを送信することにより示されています。エラーサブコードはエラーの特定の性質について詳しく説明します。特に明記しない限り、データフィールドは、（メッセージヘッダを除く）誤っOPENメッセージが含まれています。
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).
受信OPENメッセージのバージョンフィールドに含まれているバージョン番号がサポートされていない場合は、エラーサブコードはサポートされていないバージョン番号に設定されています。データフィールドは、バージョン遠隔MASCノード入札（受信したオープンメッセージに示されるように）よりも小さい最大ローカルサポートされるバージョン番号を示す1オクテットの符号なし整数です。
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.
OPENメッセージの送信者ドメイン識別子フィールドが受け入れられない場合は、エラーサブコードはバートピアドメインIDに設定されています。許容されるドメイン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.
OPENメッセージの送信者MASCノード識別子フィールドが受け入れられない場合は、エラーサブコードはバートピアMASCノードIDに設定されています。許容されるノード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.
OPENメッセージのホールドタイムフィールドが受け入れられない場合は、エラーサブコードは受け入れられないホールド時間を設定しなければなりません。実装では、1または2秒のホールド時間値を拒絶しなければなりません。実装は、任意の提案ホールド時間を拒否することがあります。ホールド時間を受け入れる実装は、ホールド時間のために交渉した値を使用しなければなりません。
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.
リモート・システムの提案役割はINTERNAL_PEER、およびいずれか（両方ではない）である場合は、ローカル・システムまたはリモート・システムの親ドメインIDは、[TLD_ID]、その後、エラーサブコードは、無効な親構成に設定されています。データフィールドは、すべてのローカルシステムの親ドメインのIDで満たされなければなりません。
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.
（ローカルシステムの構成された役割に基づいて）その期待される役割を持つリモートシステムの提案役割が競合した場合は、エラーサブコードは、一貫性のない役割に設定されています。データフィールドは1オクテットの長さで、ローカルシステムの設定済みの役割が含まれています。
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.
リモートシステムの親ドメインIDが受け入れられない場合は、エラーサブコードはバート親ドメインIDに設定され、データフィールドは誤った親ドメインIDで満たされています。許容される親ドメインIDの決定は、このプロトコルの範囲外です。
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.
リモートシステムが兄弟であることを想定しているが、それは（OPENメッセージで親ドメインのID情報に基づいて）ローカルシステムと共通の親を持っていない場合は、エラーサブコードは、共通の親に設定し、データであり、フィールドは、ローカルMASCドメインのすべての親ドメインのIDで満たされています。
If the Address Family is unrecognized, then the Error Subcode is set to Unrecognized Address Family.
アドレスファミリが認識されない場合は、エラーサブコードは認識されないアドレスファミリに設定されています。
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メッセージ（属性ヘッダを含むが、メッセージヘッダを除く）が含まれています。
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.
任意の認識属性は（属性タイプコードに基づいて）予想される長さと競合する属性の長さを持っている場合は、エラーサブコードは長エラーを属性に設定されています。
If any of the mandatory well-known attributes are not recognized, then the Error Subcode is set to Unrecognized Required Attribute.
必須のよく知られた属性のいずれかが認識されない場合は、エラーサブコードは認識されない必須の属性に設定されています。
If the Address field includes an invalid address (except 0), then the Error Subcode is set to Invalid Address.
アドレスフィールド（0を除く）、無効なアドレスが含まれている場合、エラーサブコードは、無効なアドレスに設定されています。
If the Mask field includes an invalid mask (for example, starting with 0), then the Error Subcode is set to Invalid Mask.
マスクフィールドは、（例えば、0から始まる）、無効なマスクが含まれている場合、エラーサブコードが無効なマスクに設定されています。
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サーバがサポートしていない、または非連続的なマスクを使用するように設定されていない場合、エラーサブコードは、非連続的なマスクに設定されています。
If the Address Family is unrecognized, then the Error Subcode is set to 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 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)
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）
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).
起源のドメインIDが無効であると考えられる理由がある場合は、エラーサブコードは起源のドメインIDエラーに設定されています。同じ起源のノードIDに適用される（対応するエラーが発生ノードIDエラーです）。
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.
ノードが（通常は子供からの請求を受けた親が）クレーム寿命が短すぎる（例えば、未満172800、すなわち48時間）と判断した場合、それはあまりにも短いサブコードクレーム寿命を持つUPDATEメッセージエラーを送信することができます。
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.
ノード（子からの請求を受け、通常は親）が（例えば、以上15768000、すなわち半年）クレームの寿命が長すぎると判断した場合、それは長すぎるサブコードクレーム寿命を持つUPDATEメッセージエラーを送信することができます。通常、親MASCノードが最長許容寿命で満たさクレームLifetimeフィールドで最初のCLAIM_DENIED衝突メッセージを送信する必要があることに注意してください。子供が短い生涯を主張することを拒否した場合、寿命が長い送られるべきであると主張しています。
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.
ノードが（通常は子供からの請求を受けた親が）クレームタイムスタンプ、すなわち古すぎる、小さすぎると判断した場合（ノードは自信そのクロックが非常に正確であるということである場合など）、それは送らなければなりませんサブコードクレームタイムスタンプ古すぎるとUPDATEメッセージエラー。タイムスタンプ新しすぎるが同様に定義されると主張しています。
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のアドレスのために）、それはサブコードクレームプレフィックスサイズでUPDATEメッセージエラーを送信することができ小さすぎる。
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フィールドによって暗示プレフィックスサイズが大きすぎること、それが大きすぎるサブコードクレームプレフィックスサイズでUPDATEメッセージエラーを送信することができます。通常、親MASCノードが子供の大きな主張アドレス範囲のいくつかの部分範囲のための最初のCLAIM_DENIED衝突メッセージを送信する必要があることに注意してください。子供が主張サイズを縮小することを拒否した場合、送信されるべきプレフィックスサイズが大きすぎると主張しています。
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メッセージの計算を更新起源の役割が違法である場合、エラーサブコードが不正な起源の役割エラーに設定されている、（セクション11.1で、表1を参照）。
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メッセージは、親の接頭辞に関連付けする必要がありますが、関連付けが成功しない場合、エラーサブコードはありません適切な親プレフィックスに設定されています。いかなる適切な子プレフィックス、ノー適切な内部プレフィックス、およびノー適切な兄弟プレフィックスエラーサブコードも同様に定義されていません。
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.
ノードは、請求項ホールドタイムが短すぎると判断した場合（たとえば、ほんの数秒のために）、それはあまりにも短いサブコードクレームホールドタイムでUPDATEメッセージエラーを送信することができます。
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.
ノードは、請求項ホールドタイムが長すぎると判断した場合（例えば、以上15768000、すなわち半年）が、それはサブコードクレームホールドタイムが長すぎるとUPDATEメッセージエラーを送るべきです。
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.
属性を処理するときに、他のエラーが発生した場合、エラーサブコードは、不正な形式の属性リストに設定され、かつ不規則な属性は、データ・フィールドに含まれています。
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.
システムがOPENメッセージのホールド時間フィールドで指定された期間内に連続したKEEPALIVEおよび/またはUPDATEおよび/または通知メッセージを受信しない場合には、ホールドタイマー期限切れエラーコードで通知メッセージが送信されなければならないとMASC接続が閉じました。
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有限状態マシンによって検出されたエラー（例えば、予期しないイベントの受信）はエラーコード有限状態機械エラーでNOTIFICATIONメッセージを送ることによって示されています。エラーサブコードはエラーの特定の性質について詳しく説明します。
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 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.
ノードは、通知メッセージを送信し、そこにそのメッセージに誤りがあり、そしてそのメッセージのOビットがゼロで、送信されなければならないO-ビットゼロ、通知エラーのエラーコード、およびサブコード非特異とNOTIFICATIONない場合。また、データフィールドは不安定な通知メッセージを含める必要があります。しかし、不安定な通知メッセージがOビットは、そのような認識されていないエラーコードまたはエラーサブコードなどのエラーが、注目されるべきで、その後、ゼロにした場合、ローカルにログオンし、リモートノードの管理者の注意を喚起する。これを行うための手段が、しかし、この文書の範囲外にあります。
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ノードはエラーコードシーズを有する通知メッセージを送信することによって、そのMASC接続を閉じるために、任意の所与の時点で選択してもよいです。このセクションで示される致命的なエラーが存在しない場合しかし、シーズ通知メッセージを使用してはなりません。
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).
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ノード識別子の値に基づいて、大会は、接続衝突が発生したときにMASCの接続が保持される検出のために確立されています。規則は、衝突に関与するリモートノードのMASCノード識別子を比較し、より高い値のMASCノード識別子と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:
OPENメッセージを受信すると、ローカルシステムはOpenConfirm状態にあるそのすべての接続を調べる必要があります。それはプロトコルの外側によってリモート・ノードのMASCノード識別子を知っている場合MASCスピーカもOpenSent状態の接続を検査することができます。これらの接続のうちMASCノード識別子がOPENメッセージで1に等しく、そして、同胞対の兄弟接続の場合には、その接続の親ドメインIDに1に等しいリモートMASCスピーカへの接続が存在する場合OPENメッセージは、ローカルシステムは、次の接続衝突解決手順を実行します。
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).
（OPENメッセージで指定されるように）1ローカルシステムのMASCノード識別子は、リモートシステムのMASCノード識別子と比較されます。 MASCノード識別子を比較する符号なし整数（IPv4とIPv6の長16オクテットのための長い例えば4オクテット）としてそれらを処理することによって行われます。
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ノード識別子の値は、リモート1未満である場合、ローカル・システムがすでに存在して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).
設立の状態にある既存のMASC接続との接続衝突は、新しく作成された接続の無条件の閉鎖を引き起こします。接続衝突は（セクション10を参照）アイドル、または接続、またはActive状態にある接続を検出できないことに注意してください。
Closing the MASC connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
MASCの接続を閉じる（つまり、衝突解決手順に起因する）エラーコードシーズでNOTIFICATIONメッセージを送ることによって達成されます。
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の接続を開くために複数の試行を行うことで、プロトコルのバージョンを交渉することができます。オープン試みがエラーコードOPENメッセージエラー、およびエラーサブコードサポートされていないバージョン番号で失敗した場合は、MASCのスピーカーは、それが試みたバージョン番号、リモートノードが試さバージョン番号、リモートノード内で渡されたバージョン番号を利用できる持っています通知メッセージ、およびそれがサポートするバージョン番号。 2つのMASCのスピーカーは、1つの以上の共通のバージョンをサポートしている場合、これは彼らが急速に最高の共通のバージョンを確認することができます。 MASCのバージョン交渉をサポートするために、MASCの将来のバージョンでは、OPENおよび通知メッセージの形式を保持しなければなりません。
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.
このセクションでは、有限状態機械（FSM）の観点でMASC操作を指定します。 FSMおよび動作は、セッションをピアリングピアです。このFSMによって決定されるような状態によるMASC操作の簡単な要約と概要は次のとおり。
Initially the peering session is in the Idle state.
当初ピアリングセッションがアイドル状態になっています。
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の接続を拒否します。いかなるリソースは、リモート・ノードに割り当てられていません。遠隔MASCノードによって開始することができる接続のリスニングをしながら（いずれかのシステムまたはオペレータによって開始される）開始イベントに応答して、ローカルシステムは、すべてのMASCのリソースを初期化接続リトライタイマを開始し、リモート・ノードへのトランスポート接続を開始します、およびConnectにその状態を変更します。接続リトライタイマの正確な値は、ローカルの問題であるが、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にその状態を変更します。アイドル状態から抜け出すことは開始イベントの生成を必要とします。そのようなイベントが自動的に生成されている場合は、永続的なMASCエラーがスピーカーの永続的な羽ばたきをもたらすことができます。このような状態を避けるために、スタートイベントが以前のエラーが原因Idleに移行したノードのためにすぐに生成されるべきではないことをお勧めします。以前のエラーに起因Idleに移行したノードのために、開始イベントの連続発生の間の時間は、このようなイベントが自動的に生成された場合に、指数関数的に増加しなければなりません。初期タイマ値は60秒でなければなりません。時間は、連続する各再試行のために倍増されなければならないが、24時間以上であってはなりません。
Any other event received in the Idle state is ignored.
アイドル状態で受信された他のイベントは無視されます。
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.
トランスポートプロトコル接続が成功した場合、ローカルシステムは、接続リトライタイマをクリアして初期化を完了し、遠隔ノードにOPENメッセージを送信し、OpenSentにその状態を変化させます。トランスポート・プロトコル（例えば、再送タイムアウト）失敗、ローカルシステムに接続リトライタイマを再起動接続した場合、リモートMASCノードによって開始され、アクティブな状態にその状態を変化させることができる接続を待機し続けます。
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.
接続リトライタイマ期限切れのイベントに応答して、ローカルシステムは、接続リトライタイマを再起動し、他のMASCのノードへのトランスポート接続を開始し、リモートMASCノードによって開始され、接続状態のままにすることができる接続を待機し続けます。
The Start event is ignored in the Connect 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.
（いずれかのシステムまたはオペレータによって開始される）他のイベントに応答して、ローカルシステムは、この接続に関連付けられたすべてのMASCのリソースを解放し、アイドルために、その状態を変化させます。
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.
トランスポートプロトコル接続が成功した場合、ローカルシステムは接続リトライタイマをクリアし、初期化を完了し、OPENメッセージをリモートノードに送信し、そのホールドタイマが大きな値に設定し、OpenSentにその状態を変化させます。 [HOLDTIME]秒のホールドタイマー値が提案されています。
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.
接続リトライタイマ期限切れのイベントに応答して、ローカルシステムは、接続リトライタイマを再起動し、他のMASCノードへのトランスポート接続を開始し、リモートMASCノードによって開始され、接続するために、その状態を変化させることができる接続を待機し続けます。
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.
ローカルシステムがリモートノードがそれにMASCの接続を確立しようとしていることを検出し、リモートノードのIPアドレスが期待されるものではない、ローカルシステムは接続リトライタイマを再起動し、接続試行を拒否した場合、をリッスンし続けリモートMASCノードによって開始され、アクティブ状態のままにすることができる接続。
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.
（いずれかのシステムまたはオペレータによって開始される）他のイベントに応答して、ローカルシステムは、この接続に関連付けられたすべてのMASCのリソースを解放し、アイドルために、その状態を変化させます。
OpenSent state:
OpenSent状態：
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
この状態で、MASCは、リモート・ノードからのOPENメッセージを待ちます。 OPENメッセージを受信すると、すべてのフィールドが正しいかどうかチェックされます。 MASCメッセージヘッダのチェックまたはOPENメッセージチェックがエラーを検出した場合、または接続（セクション8.2を参照）
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.
衝突（セクション8.8を参照）は、ローカルシステムは、通知メッセージを送信し、接続がクローズされる場合、それはアイドルするために、その状態を変化させます。
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.
ローカルに設定された役割はSIBLINGで、親ドメインIDと同じドメインIDを持つ親ドメインがOPENメッセージ内に存在しない場合は、ローカルシステムが共通の親に設定エラーサブコードと通知のオープンメッセージエラーを送信し、接続が閉じていなければなりません、およびローカルシステムの状態が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.
OPENメッセージでエラーがない場合は、MASCはKEEPALIVEメッセージを送信し、キープアライブタイマーを設定します。元々大きな値に設定されたホールドタイマーは、（上記参照）、（7.2節を参照）ネゴシエートされた保留時間の値に置き換えられます。ネゴシエートされた保留時間値がゼロの場合は、ホールド時間タイマーおよびキープアライブタイマーが開始されていません。 MASCドメインIDフィールドの値は、ローカルMASCドメインIDと同じであり、OPENメッセージの役割フィールドがINTERNAL_PEERに設定されている場合、接続は「内部」接続である場合、それ以外の場合は、「外部」です。最後に、状態が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.
切断通知は、基礎となるトランスポートプロトコルから受信した場合、ローカルシステムは、リモートMASCノードによって開始される接続のリスニングを続行しながら、MASCの接続は、接続リトライタイマを再開閉じ、アクティブ状態になります。
If the Hold Timer expires, the local system sends a NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
ホールドタイマーの期限が切れた場合は、ローカルシステムは、エラーコードで通知メッセージを送信タイマーが満了し、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.
（システムまたはオペレータのいずれかによって開始）ストップイベントに応答して、ローカルシステムは、エラーコードのシーズとの通知メッセージを送信し、Idleにその状態を変更します。
The Start event is ignored in the OpenSent state.
スタートイベントはOpenSent状態では無視されます。
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.
他のイベントに応答して、ローカルシステムは、エラーコード有限ステートマシンのエラーとエラーサブコードのオープン/クローズMASC接続FSMエラーと通知メッセージを送信し、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.
MASCはIdleにOpenSentから、その状態を変更するたびに、それはMASC（およびトランスポート・レベル）接続を解放、その接続に関連付けられているすべてのリソースを閉じます。
OpenConfirm state:
OpenConfirm状態：
In this state MASC waits for a KEEPALIVE or NOTIFICATION message.
この状態で、MASCは、KEEPALIVEまたは通知メッセージを待ちます。
If the local system receives a KEEPALIVE message, it changes its state to Established.
ローカルシステムがKEEPALIVEメッセージを受信した場合、それは設立にその状態を変更します。
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.
KEEPALIVEメッセージが受信される前に、ホールドタイマーの期限が切れた場合は、ローカルシステムは、エラーコードで通知メッセージを送信タイマーが満了し、Idleにその状態を変更するホールド。
If the local system receives a NOTIFICATION message with the O-bit zeroed, it changes its state to Idle.
ローカルシステムがゼロOビットとNOTIFICATIONメッセージを受信した場合、それはアイドルするその状態を変化させます。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
キープアライブタイマーが満了した場合は、ローカルシステムがKEEPALIVEメッセージを送信し、そのキープアライブタイマーを再起動します。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
切断通知が、基礎となるトランスポートプロトコルから受信された場合、ローカルシステムが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.
（システムまたはオペレータのいずれかによって開始）ストップイベントに応答して、ローカルシステムは、エラーコードのシーズとの通知メッセージを送信し、Idleにその状態を変更します。
The Start event is ignored in the OpenConfirm state.
スタートイベントはOpenConfirm状態では無視されます。
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.
他のイベントに応答して、ローカルシステムは、エラーコード有限状態マシンエラーと非特異的エラーサブコードを持つ通知メッセージを送信し、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.
MASCはIdleにOpenConfirmから、その状態を変更するたびに、それはMASC（およびトランスポート・レベル）接続を解放、その接続に関連付けられているすべてのリソースを閉じます。
Established state:
設立の状態：
In the Established state MASC can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with the remote node.
確立された状態のMASCでリモートノードとUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換することができます。
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.
ローカルシステムがOビットがセットされたUPDATE、またはKEEPALIVEメッセージ、または通知メッセージを受信した場合ネゴシエートホールド時間値が非ゼロである場合、それは、そのホールドタイマーを再開する。
If the local system receives a NOTIFICATION message, with the O-bit zeroed, it changes its state to Idle.
ローカルシステムがOビットがゼロで、通知メッセージを受信した場合、それはアイドルするために、その状態を変化させます。
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.
ローカルシステム（セクション8.3を参照）UPDATEメッセージと手続きを処理UPDATEメッセージエラーを受信エラーを検出した場合、ローカルシステムは、通知メッセージを送信し、O-ビットがゼロにされた場合、Idleにその状態を変化させます。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
切断通知が、基礎となるトランスポートプロトコルから受信された場合、ローカルシステムが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.
ホールドタイマーの期限が切れた場合は、ローカルシステムは、エラーコードと通知メッセージはタイマーが満了し、Idleにその状態を変更するホールド送信します。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
キープアライブタイマーが満了した場合は、ローカルシステムがKEEPALIVEメッセージを送信し、そのキープアライブタイマーを再起動します。
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero.
ネゴシエートされた保留時間の値がゼロでない限り、ローカルシステムがKEEPALIVEまたはUPDATEメッセージを送信するたびに、それは、そのキープアライブタイマーを再起動します。
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.
スタートイベントが設立された状態に無視されます。
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).
ローカルシステムが、彼らはすぐに送信されている必要があり、リモート・ノードに送信されるUPDATEメッセージを持っている場合は、ESTABLISHED状態に入った後（項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.
他のイベントに応答して、ローカルシステムはゼロOビットおよび非特異的エラーサブコードとエラーコード有限状態マシンエラーと通知メッセージを送信し、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.
MASCはIdleに設立から、その状態を変更するたびに、それはMASC（および転送レベル）接続は、その接続に関連付けられているすべてのリソースを解放閉じ、その接続に由来するすべての状態を削除します。
The UPDATE message are accepted only when the system is in the Established state.
UPDATEメッセージは、システムが確立された状態にある場合にのみ受け入れられます。
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 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.
以下のテキストでは、MASCドメインは局所使用目的（すなわち、そのドメイン内Maass第によって使用される）とアドレス空間に関連して、特許請求の範囲に関して、自身の子であると考えられます。例えば、そのドメインで管理されるプレフィックスからローカルな利用のためのより多くのスペースを取得するためにMASCノードによって開始さNEW_CLAIMは、フィールドの役割=子供を持つことになります。
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.
UPDATEがさらに伝播する場合、それが戻って、そのノードへの接続がダウンした後、復元されたという指示がない限りUPDATEは、から受信されたノードに送信されるべきではありません。
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.
ローカルシステムが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.
UPDATEメッセージは、親ドメインに関連付ける必要があります場合は、特定のUPDATEのプレフィックスをカバーし、プレフィックスのためのいくつかの親ドメインによるPREFIX_MANAGEDがなければなりません。
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 | ---
Table 1: Updated Origin Role Computation
表1：更新された原点ロール計算
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 after reboot, or if because of internal partitioning, the INTERNAL_PEERs are exchanging UPDATEs via other MASC domains (either parent or sibling(s)).
更新原点ロール計算からの出力はSIBLINGですが、原産地のドメインIDは、ローカルMASCドメインと同じである場合、O、更新起源の役割は、内部に変更されます。これが必要である場合にMASCノードが親から受信するか、またはそれ自身の更新を兄弟再起動後、またはので、内部分割の、INTERNAL_PEERsは他のMASCドメイン（親または兄弟のいずれか（複数可））を介してアップデートを交換する場合。
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.
両方の役割をローカルに構成され、原点の役割が親に等しく、オリジンドメインIDがローカルMASCドメインと同じである場合、O、更新起源の役割は、内部に変更されます。これは、その子を信じていない理由を持っている場合、親はこれらの更新をドロップするかもしれませんが、親が、自身の子供を通じて、自身のアップデートを受信できるようにする必要があります。
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.
両方の役割をローカルに構成され、原点の役割が親に等しく、オリジンドメインIDは、リモートMASCドメインと同じであり、更新種別がCLAIM_DENIEDされている場合、O、更新起源の役割は、内部に変更されます。これは、親が、それはその主張拒否された子を通じて発信していますCLAIM_DENIEDを受信できるようにする必要があります。起源のドメインIDは、リモートMASCのドメインと同じではありませんが、他のMASCの子供のドメインの一部と同じである場合、それはない理由がある場合、親はこのUPDATEをドロップするかもしれませんが、更新起源の役割はまだ、INTERNALに変更する必要がありますサードパーティの子を信じます。
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.
更新起源の役割が内部であるが、起源のドメインIDは、ローカルドメインIDと異なる場合、<UPDATEメッセージエラー、不正な起源の役割>の通知が返送されなければならず、請求が拒否されます。
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.
前記タイムスタンプとホールドタイムクレームがクレーム（例えばタイムスタンプ+請求項ホールドタイム<= CurrentTimeを）有効期限が切れていることを示している場合、UPDATEは静かに滴下され、さらなるアクションはとられません。
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:
それぞれの新しい到着のUPDATEは、ローカルキャッシュ内のすべての請求と比較されます。次のフィールドが比較され、それらのすべてが同じであれば、メッセージは静かに拒否され、それ以上のアクションは取られません。
o Role, D-bit, Type
Oロール、Dビット、タイプ
o AddrFam
O AddrFam
o Claim Timestamp
Oタイムスタンプを主張
o Claim Lifetime
Oクレーム生涯
o Claim Holdtime
Oホールドタイムを主張
o Origin Domain Identifier o Origin Node Identifier
発生ノード識別子〇〇起源ドメイン識別子
o Address
Oアドレス
o Mask
Oマスク
Further processing of an UPDATE is based on its type and the Updated Origin Role.
UPDATEのさらなる処理は、その種類及び更新起源の役割に基づいています。
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
請求は拒否され、<UPDATEメッセージエラー、不正な起源の役割>の通知が返送されるべきです。
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.
請求はいずれの親のPREFIX_MANAGEDに関連付けることができない場合は、請求は<UPDATEメッセージエラー、なし適切な親プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。
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.
請求がローカルドメインの係争中の一部に衝突した場合には、地元の請求項は、考慮されなければならない、とそれらのそれぞれのクレームタイマーは解除されなければなりません。 PREFIX_IN_USE請求の衝突を受け、ローカルドメインに割り当てられたプレフィックスの一部の上に勝てば、12.4項に従って衝突を解決します。最後に、クレームは、すべてのMASCノードは、対応する親MASCドメインと同じ親ドメインとすべての既知の兄弟から、全てINTERNAL_PEERsにさらに伝播されなければなりません。
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.
請求の接頭辞がローカルドメインのPREFIX_MANAGEDのいずれかのサブレンジでない場合は、請求は<UPDATEメッセージエラー、なし適切な親プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。それ以外の場合、請求はすべてINTERNAL_PEERsとすべてのMASCの子ドメインにさらに増殖する必要があります。
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.
MASCノードがローカルドメインがこれ以上その接頭辞を必要としないことを決定した場合、それは撤回することができる、そうでない場合は、請求がPREFIX_MANAGEDとして処理されます。
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
メッセージは拒否され、<UPDATEメッセージエラー、不正な起源の役割>の通知が返送されるべきです。
Propagate to all INTERNAL_PEERs and all MASC children nodes.
すべてINTERNAL_PEERsとすべてのMASCの子ノードに伝播されます。
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.
起源のドメインIDは、ローカルドメインIDと同じではありません、そしてUPDATEは任意の親ドメインに関連付けることができない場合、メッセージは破棄され、<UPDATEメッセージエラー、なし適切な親プレフィックス>の通知は、さらに背中と全く送られてはなりませんアクションが取られるべきです。
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.
オリジンドメインIDがローカルドメインIDと同じではない、とUPDATEが親ドメインに関連付けることができる場合、メッセージはその親ドメインからのすべてのノード、全てINTERNAL_PEERs、その親に関して全ての既知の兄弟に伝播されます。
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.
オリジンドメインIDは、ローカルドメインのIDと同じであり、ローカルMASCドメイン（すなわちNEW_CLAIM又はCLAIM_TO_EXPAND同じAddrFamと、オリジンドメインID、タイムスタンプ、アドレスおよびマスクを記載）によって発信該当する保留中の請求がない、NOTIFICATION場合<UPDATEメッセージエラー、いかなる適切な内部プレフィックス>は返信されませんする必要があり、それ以上のアクションがとられるべきではありません。そうでなければ、マッチングNEW_CLAIM又はCLAIM_TO_EXPANDの主張タイマーはキャンセルされなければならないと主張をさらに考慮されてはなりません。最後に、受信CLAIM_DENIEDは、対応する親MASCドメインからのすべてのINTERNAL_PEERs、すべてのMASCのノードに伝播し、その親に関する既知のすべての兄弟にする必要があります。
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
請求は拒否され、<UPDATEメッセージエラー、不正な起源の役割>の通知が返送されるべきです。
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.
請求はいずれの親のPREFIX_MANAGEDに関連付けることができない場合は、請求は<UPDATEメッセージエラー、なし適切な親プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。
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.
同じMASCのドメインによる重複PREFIX_IN_USEがない場合は、請求は<UPDATEメッセージエラー、なし適切な兄弟姉妹プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。
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.
請求がと衝突し、ローカルドメインの係争中の一部の上に勝てば、敗者の請求項は、考慮されなければならない、とそれらのそれぞれのクレームタイマーをキャンセルしなければなりません。また、受信されたクレームは、すべてINTERNAL_PEERsにさらに伝播する必要があり、対応する親MASCドメインからのすべてのMASCノードと同じ親ドメインとすべての既知の兄弟。
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.
請求がローカルドメインのPREFIX_MANAGEDのいずれかに関連することができない場合は、請求は<UPDATEメッセージエラー、なし適切な親プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。
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.
同じMASCのドメインによる重複PREFIX_IN_USEがない場合は、請求は<UPDATEメッセージエラー、なし適切な子プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。
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.
それ以外の場合、請求はすべてINTERNAL_PEERsに伝播する必要があります。請求の有効期間は、ローカルドメインによって管理され、対応するプレフィックスの寿命より長い場合主張プレフィックスを割り当てる続くから子供を防ぐために、管理上設定理由がある場合、または、CLAIM_DENIEDは、すべてのMASCの子ノードに送信する必要がありますそれは、受信したメッセージの原点ドメインIDと同じドメインIDを持っています。 CLAIM_DENIEDはロル= INTERNALを除いて、受信された請求項と同じで、かつ寿命が最大許容生涯に設定する必要が記載しなければなりません。それ以外の場合は、同様にすべての子供たちへの請求を伝播します。
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.
請求はいずれの親のPREFIX_MANAGEDに関連付けることができない場合は、請求は<UPDATEメッセージエラー、なし適切な親プレフィックス>の通知が返送されなければならず、それ以上のアクションがとられるべきではない、削除されます。
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.
ローカルMASCのドメインによる重複PREFIX_IN_USEがない場合は、請求は<UPDATEメッセージエラー、なし適切な内部プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。
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.
MASCノードがローカルドメインが、それ以上の請求を保留することを必要としないことを決定した場合、それが引き抜かれ得ます。それ以外の場合、請求はすべてINTERNAL_PEERsと、対応する親MASCのドメインからのすべてのMASCのノードに伝播する必要があります。
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.
請求者の住所フィールドが0（より多くのスペースを取得するために、親に子供がつまりヒント）である場合、請求は一人っ子起源ドメインと親ドメインに属するノード間で伝播する必要があります。
Otherwise, process like CLAIM_TO_EXPAND, except that no check for overlapping PREFIX_IN_USE needs to be performed.
それ以外の場合は、CLAIM_TO_EXPANDのようなプロセスは、その以外PREFIX_IN_USEを重ねるためのチェックが実行される必要がありません。
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.
起源のドメインIDは、両親のドメインIDのいずれかと一致する場合は、接頭辞が記録され、部分的な範囲を割り当てるためのアドレス割り当てアルゴリズムによって使用することができます。また、メッセージは、対応する親ドメインの全てMASCノード、すべてINTERNAL_PEERs、同じ親を持つ兄弟に伝播されます。
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
メッセージは拒否され、<UPDATEメッセージエラー、不正な起源の役割>の通知が返送されるべきです。
The prefix is recorded as allocated to the local domain, propagated to all INTERNAL_PEERs, and can be used for (all items apply):
（すべての項目が適用されます）、ローカルドメインに割り当てられたすべてのINTERNAL_PEERsに伝播し、ために使用することができるよう接頭辞が記録されます。
a) address ranges/prefixes advertisements to all MASC children and local domain's MAASs;
a）のアドレス範囲は、/すべてのMASCの子供とローカルドメインのMaass第に広告を接頭辞。
b) injection into G-RIB;
B）G-RIBへの注射;
c) further expansion by the address allocation algorithm (see Appendix A);
アドレス割当てアルゴリズムによってC）さらに膨張（付録A参照）。
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.
子ドメインのPREFIX_IN_USEのいずれかに関連することはできませんWITHDRAW場合（つまりなし子供のPREFIX_IN_USEは、の範囲を撤回カバー）、またはWITHDRAW子ドメインのNEW_CLAIMやCLAIM_TO_EXPAND（のいずれにも一致しない場合、すなわち、同じアドレス、マスク付きノー子供の主張がありますおよびタイムスタンプ）は、メッセージが<UPDATEメッセージエラー、なし適切な子プレフィックス>の通知が送り返されなければならない、それ以上のアクションがとられるべきではない、削除されます。それ以外の場合は、すべてのINTERNAL_PEERsと子供に伝播されます。
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.
兄弟PREFIX_IN_USEのいずれかに関連することはできませんWITHDRAW場合（つまりノー兄弟のPREFIX_IN_USEは、の範囲を撤回カバー）、または同じアドレスを持つノー兄弟の主張があり、すなわち（兄弟ドメインのNEW_CLAIMやCLAIM_TO_EXPANDのいずれにも一致しないWITHDRAW、マスクの場合タイムスタンプ）、メッセージがドロップされると、通知<UPDATEメッセージエラーはありませんが、適切な兄弟プレフィックス>は返信されませんする必要があり、それ以上のアクションがとられるべきではありません。それ以外の場合は、すべてのINTERNAL_PEERsに伝播し、同じ親MASCのドメインからのすべてのMASCのノードと同じ親ドメインを持つすべての既知の兄弟。
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.
WITHDRAWは、ローカルドメインのPREFIX_IN_USEまたはPREFIX_MANAGED（つまりローカルドメインのプレフィックスはの範囲を撤回カバー）のいずれかに関連することができない、またはWITHDRAWは、ローカルドメインのNEW_CLAIMやCLAIM_TO_EXPANDのいずれにも一致しない場合（つまりとローカルドメインの請求があった場合同じアドレス、マスクおよびタイムスタンプ）メッセージがドロップされるが、通知<UPDATEメッセージエラーはありませんが、適切な内部プレフィックス>は返信されませんする必要があり、それ以上のアクションがとられるべきではありません。
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
それ以外の場合は、すべてのINTERNAL_PEERsに伝播し、その接頭辞、その親ドメインを持つすべての既知の兄弟、およびすべての子の対応する親ドメインのすべてのMASCノード。ローカルドメインのPREFIX_IN_USEやPREFIX_MANAGEDの一部に関連付けることができWITHDRAW場合は、Maass第へWITHDRAW範囲のアドバタイズを停止し、G-RIBデータベースからその範囲を撤回。なぜなら衝突のローカルドメインから発信された撤回という指示、及びWITHDRAWで指定された範囲がある特殊な場合にローカルPREFIX_MANAGEDのサブレンジ、及びWITHDRAWの請求項ホールドタイムは、請求項ホールドタイムより短くされの
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は、WITHDRAWの範囲は、G-RIBから撤退すべきではありません。 WITHDRAWは、ローカルドメインのNEW_CLAIMまたはCLAIM_TO_EXPAND一致した場合、マッチングの請求の主張タイマーをキャンセルします。
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.
WITHDRAWは、任意の親ドメインに関連付けることができない場合は、<UPDATEメッセージエラー、なし適切な親プレフィックス>の通知が返送されなければならず、それ以上のアクションがとられるべきではありません。
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.
それ以外の場合は、すべてのINTERNAL_PEERsと同じ親ドメインを持つすべての既知の兄弟に伝播されます。また、局所的に所有PREFIX_MANAGED / PREFIX_IN_USEの各交点ためWITHDRAWメッセージを発信および受信WITHDRAW。局所ホールドタイム撤回メッセージ内のホールドタイムは、親から受信した前記少なくとも等しくなければならないメッセージの主張を撤回発信しました。オリジンノードIDは、特定PREFIX_MANAGED / PREFIX_IN_USEと同じでなければなりません。
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.
（例えば、接続（再）確立した後に）、更新の一部が他の前に送信されなければならないピアに送信される必要がある複数のUPDATEメッセージがある場合、整合性および健全性チェックの実装を簡素化します。
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は常にCLAIM_TO_EXPAND、NEW_CLAIM前に送信され、同じMASCドメインによってWITHDRAWしなければなりません
o WITHDRAW must always be sent AFTER PREFIX_IN_USE, CLAIM_TO_EXPAND, NEW_CLAIM, and PREFIX_MANAGED by the same MASC domain
O常に同じMASCドメインによってPREFIX_IN_USE、CLAIM_TO_EXPAND、NEW_CLAIM後に送信される、とPREFIX_MANAGEDしなければならないWITHDRAW
Any further ordering is defined below by the roles of the sender and the receiver.
任意の更なる順序は、送信者と受信者の役割によって以下に定義されます。
Messages are sent in the following order:
メッセージは次の順序で送信されます。
1) Parent's PREFIX_MANAGED and WITHDRAWs.
1）親のPREFIX_MANAGEDと撤回。
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、CLAIM_TO_EXPAND、およびNEW_CLAIMs。より多くのスペースのためのヒントあるサードパーティ製の子供からのクレーム（すなわち、アドレス= 0）に伝播すべきではありません。伝播した場合、子供がそれらをドロップする必要があります。
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）親がCLAIM_DENIEDを開始し、子どもたちは撤退を開始しました。アドレス= 0が伝播すべきではないとサードパーティの子どもたちの主張/ヒントについてCLAIM_DENIED。伝播した場合、子供がそれらをドロップする必要があります。
Messages are sent in the following order:
メッセージは次の順序で送信されます。
1) Parent's PREFIX_MANAGED and WITHDRAWs.
1）親のPREFIX_MANAGEDと撤回。
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、CLAIM_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）親のはCLAIM_DENIEDを開始し、そしてその親のスペースに関連付けすることができ、ローカルドメインまたはその親を持つすべての既知の兄弟によって開始されているすべてのWITHDRAWSs。
Messages are sent in the following order:
メッセージは次の順序で送信されます。
1) All common parent's PREFIX_MANAGED and WITHDRAWs.
1）すべての共通の親のPREFIX_MANAGEDと撤回。
2) PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs, initiated by siblings.
2）PREFIX_IN_USE、CLAIM_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）CLAIM_DENIEDsは、共通の親によって開始され、ローカルドメインとその親を持つすべての既知の兄弟によって開始撤回します。
Messages are sent in the following order:
メッセージは次の順序で送信されます。
1) All parents' PREFIX_MANAGED and WITHDRAWs.
1）全ての両親PREFIX_MANAGEDと撤回。
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、CLAIM_TO_EXPAND、およびNEW_CLAIMs。より多くのスペースのためのヒントである兄弟から、特許請求の範囲（すなわち、アドレス= 0）に伝播されるべきではありません。伝播した場合、受信者がそれらをドロップする必要があります。
3) CLAIM_DENIEDs initiated by all parents, and WITHDRAWs initiated by local domain and all known siblings.
3）CLAIM_DENIEDsは、すべての親によって開始され、ローカルドメインとすべての既知の兄弟によって開始撤回します。
4) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
4）すべての子どもたちのPREFIX_IN_USE、CLAIM_TO_EXPAND、およびNEW_CLAIMs。
5) All local domain initiated CLAIM_DENIED regarding children claims and all children initiated WITHDRAWs.
5）すべてのローカルドメインを開始請求は、子どもたちの主張については否定し、すべての子どもたちが撤退を開始しました。
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のノードが兄弟ノードへの接続を開始する前に、その親ノードへの接続を確立しようとする必要があります。その子または兄弟から独自のPREFIX_MANAGEDについて学ぶ避けるために、MASCのノードは、子または兄弟ノードへの接続を開始する前に、その親ノードとINTERNAL_PEERノードへの接続を確立しようとする必要があります。
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.
非リーフMASCドメイン（子ドメインを持つすなわちドメイン）がその子にそのPREFIX_MANAGEDアドレスを宣伝する必要があり、その空間から（請求項待ち時間が等しくなるはずである内部Maass第にアドバタイズされるだろうサブ範囲を主張する必要があります）[WAITING_PERIOD]に。非リーフMASCドメインに属しているMASCノードは主張し、ローカルな利用のためのサブ範囲の管理に関して、自身の子であることによって二重の機能を実行する必要があります。葉のMASCドメインは、明示的に内部の使用のためにそれらを主張することなく、そのMaass第に対するすべてのPREFIX_MANAGEDアドレスを宣伝する必要があります。 MASCノードは、それが単に子供ドメインによってすべての更新プログラムを持っていない場合、それは葉のドメインに属していると仮定することができます。子供がUPDATEが受信された場合、ドメインは「非リーフ」モードへの「リーフ」から切り替える必要があり、それは内部使用のための複数のアドレスを必要とする場合、それは、そのドメインのPREFIX_MANAGEDからそれらを主張しなければなりません。子供によって発信最後の更新の有効期限が切れた後、ドメインは「リーフ」モードに切り替えることができます。
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を発信MASCノードの絶対時間に設定されているフィールド「タイムスタンプを主張」を有します。タイムスタンプは2つの目的のために使用されます。衝突を解決するために、およびUPDATEは、他のMASCノードのローカルキャッシュに保持する必要がありますどのくらいの期間を定義します。クロックのスキューは、リアルタイムの後ろに自分の時計を持っているノードによって発信クレームは常に勝つような不当な衝突判定につながる可能性。衝突がおそらく稀であるため、しかし、これは問題になりません。クロックのスキューは、しかし、それは本当に期限切れしなければならない、とノードがあまりにも早く期限切れのUPDATE /プレフィックスが割り当てのために自由であることを前提としているよりも早くUPDATEを期限切れになる可能性があります。クロック・スキューを補償するために、UPDATEメッセージは、より長い、請求項ホールドタイムで指定された時間の量よりも維持されるべきです。例えば、さらに24時間更新を維持することは、最大24時間のクロック・スキューを補償します。
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請求を受信し、前記ローカルプレフィックスの一部と重なる場合は、衝突が解決されなければなりません。二つの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メッセージを開始することによって撤回されなければなりません。メッセージは、ロール項タイムスタンプ、請求寿命は、ホールドタイム、アドレスおよびマスクを主張しながら= INTERNAL、オリジンノードIDとオリジンドメインIDは、対応するローカルPREFIX_IN_USEメッセージと同じでなければなりませんが受信勝利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.
キャッシュさはタイムアウトを撤回し、ローカルMASCドメインが重複PREFIX_MANAGEDまたはPREFIX_IN_USEを所有している場合は、重複プレフィックス範囲がバックG-RIBデータベースに注入することができます。同様に、原因撤回するローカルドメインの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ノードは、手動または自動衝突解決メカニズムのいずれかを使用して動作するように構成されなければなりません。
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ノードの一つへの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が使用されている場合は、古いネットワークプロバイダのドメインは、自動的に複数の特定のグループのルートが不足しているため、顧客の古いグループのためのルートドメインになります。顧客ドメイン内MASCノードは、まだ彼らの割り当てを守るために、古いプロバイダーのMASCのノードに接続することができます。
Use mtrace [MTRACE] to find the BGMP/MASC root domain for a group address chosen from that prefix.
そのプレフィックスから選ばれたグループアドレスのBGMP / MASCのルートドメインを見つけるために[MTRACE] MTRACEを使用してください。
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ドメインの状態を観察することによって、またはそのドメインによって発信G-RIB情報を観察することによってMASCサーバーのいずれかを照会することにより、特定のMASCドメインに割り当てられたアドレス空間を見つけることができます。これらの3つの方法からは、第一の方法は、最も詳細な情報を提供することができます。特定のドメイン内のMASCノードのいずれかのアドレスを見つけることは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は、一般的に安定した記憶装置を持たない、境界ルータによって実行されます。 【MALLOC]に記載されているように、この場合に、MASCは、貯蔵安定性を有するべきであるドメインのMaass第における重要な情報ローカルドメインによって割り当てられた（プレフィックス）を格納するために、レイヤ2プロトコル/機構（例えば、（[AAP]）を使用しなければなりません。もし
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のスピーカーは、ローカルストレージを持って、それは、レイヤ2プロトコル/メカニズムの代わりにそれを使用する必要があります。進行中のクレームは、レイヤ2プロトコル/メカニズムを使用して保存する必要はありません。
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.
IPsecは、[IPSEC 2つのMASCピアリングノード間のセキュリティ問題に対処するために使用することができます。しかし、UPDATEメッセージのストアアンドフォワード性質上、非信頼できるMASCノードはMASCトポロジの一部のポイントに接続できる場合は、このノードが検出できないほど、通常のを妨げることがあり、悪意のある更新を注入することができている可能性があります他のMASCノードの動作を制御します。この問題に対処するために、各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ノード/ドメインは、その隣人（内部ピア、両親、兄弟姉妹、子供）からその状態を復元することができます。典型的には、状態は、親または信頼できるであろう内部ピアから受信するが、ノードは、兄弟又は子供を介して受信された独自の更新をドロップすることを選択することができます。
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.
誤動作ノードは、複数のアドレスを割り当てるから、その兄弟のいずれかを妨げる衝突大量のメッセージを送信することにより、サービス拒否攻撃を試みることができます。単一ミス振る舞うノードは容易にその兄弟の全てによって識別することができ、その更新の全てを無視することができます。 （非直接接続されている兄弟によって）、サードパーティ製のUPDATEは、それが共通の親ドメインを介して送信された場合にのみ受け入れられ、そして親ドメインのMASCノードされている場合、複数の原点のアドレスを使用してサービス拒否攻撃を防止することができます彼らは内部ピアを経由して来た場合にのみ、子供のアップデートを受け入れる、または発生ノードIDと同じである子ノードから直接来ます。
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通知メッセージエラーコードとサブコード）を定義します。これらの番号空間のすべてについて、特定の値は、本明細書で定義されています。 [IANA-考察]に記載されているように新しい値のみ、IETF合意によって定義されてもよいです。基本的に、これは、それらがIESGによって承認されたRFCで定義されていることを意味します。
The authors would like to thank the participants of the IETF for their assistance with this protocol.
著者は、このプロトコルとその支援のためにIETFの参加者に感謝したいと思います。
DISCLAIMER: This section describes some preliminary suggestions by various people for algorithms which could be used with MASC.
免責事項：このセクションでは、MASCで使用することができアルゴリズムのための様々な人々によっていくつかの予備の提案を説明しています。
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]よりも短くなければなりません。
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は、アドレス範囲、すなわち、接頭辞を指定する連続するマスクを使用する必要があります。 （研究は、十分に良好な結果が唯一の連続マスクを用いて達成することができることを示している。）選択されたプレフィックスができるだけ拡張可能であるべきです。親の接頭辞から子どもたちにサブプレフィックスを選択するために使用される方法は、いわゆるリバースビットオーダリングである（デーブターラーによってアイデア; 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.
新しいサブプレフィックスを選択しなければならない時にアドレスの順序が非常に厳格であるため、しかし、衝突の確率を減らすために、選択は、拡張性のために同じ電位を持つすべての候補の中からランダムでなければなりません。フリーサブプレフィックスは01xx、10XX、110Xである場合、例えば、次に記載する新しいプレフィックスは01xx 50％および例えば10XX 50％の確率で選択されるべきです。
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ノードは、事前に複数のアドレスを主張します。
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の累乗であるため、ノードが1つだけのプレフィックスを割り当てるしようとした場合、（すなわち、そのノードのドメインにおける）そのノードにおける利用率が50％と低いことができます。利用率を向上させるために、MASCノードは、時間（異なるサイズを有するそれらの一般的に、それぞれ）に割り当てられた複数のプレフィックスを有することができます。事前割り当てを使用して、異なるサイズ（下記参照）のいくつかのプレフィックスを割り当てることによって、MASCノードは範囲70〜90％で、そのアドレスの利用率を維持しようとすべきです。
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).
さらに、衝突の確率を低減することにより、割り当て待ち時間を低減するために、および割り当てられたアドレスの凝集性を向上させるために、MASCノードが注意深く請求プレフィックスを選択します。最初の接頭辞はすべて合理的に拡張可能な候補の中からランダムに選択されます。ノードは、別の、より小さなプレフィックスを割り当てることを選択した場合、その後、代わりに大幅アドレス利用率を低下させるかもしれない最初のもののサイズを2倍に、第二の「隣接」プレフィックスが選択されます。接頭224.0 / 16が既に割り当てられ、MASCドメインが256個の以上のアドレスを必要とした場合、例えば、請求する第プレフィックスが/ 24 224.1.0します。ドメインが複数のアドレスを必要とする場合は、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パーセントの範囲にあることができるように、合理的な閾値であり、かつ同時にプレフィックスフラックスが適度に低くなることを示しています。
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ノードは暗黙的にその寿命後に未使用のプレフィックスが期限切れに戻り、またはいくつかのより小さなサブプレフィックスを再主張します。接頭224.0 / 15 Maass第及び/又は子供MASCドメインによって使用される50％であり、全体的な使用率は約2 ^ 16（64K）アドレスが返さなければならないようなものである場合、例えば、MASCノードは224.0 / 15の再生を停止しなければなりませんそして、（いずれのサブプレフィックス利用率が高い）224.0 / 16または224.1 / 16のいずれかを再生開始すべきです。
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時間ごとに再主張しなければなりません。
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.
執筆の時、225.0.0.0-225.255.255.255は一時的にMALLOCに割り当てられています。おそらく、このアドレスブロックは、実験的な展開とテストのために使用されます。
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当初は約128トップレベルドメインを持っています
o Assume initially approximately 8192 level-2 MASC domains; on average, a TLD will have approximately 64 children domains.
O最初に約8192レベル2 MASCドメインと仮定する。平均的には、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
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（4 * 2 ^ 24 = 2 ^ 26 = 64M）は、グローバルアドレスプールとしてMASCによって使用することができます。残り（8 ^ 24 * 2）が確保されなければなりません。その一部がMASCに後で追加することができ、または管理スコープアドレスのプール（現在239.X.X.X）、または静的割り当て（233.X.X.X）のためのプールを拡大するために使用することができます。
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.
マルチキャストアドレスが均等に分布している場合、各レベル2 MASCドメインは8192のアドレスを持っているだろうが、O、各TLDは、2 ^ 19（512K）アドレスの最大値を有するであろう。
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.0 * average_assumed_per_domain（strawmanデフォルトソフト閾値）：
* if a TLD claim+allocation >= 512K
* if a second level MASC domain claim+allocation >= 8K
The hard threshold (for example, 2.0*average_assumed_per_domain) can be enforced by sending an explicit DENIED message.
（例えば、2.0 * average_assumed_per_domain）ハードしきい値が明示DENIEDメッセージを送信することによって実施することができます。
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.
（第2のレベルのMASCドメインによるクレームに関して）のTLDしきい値は個人的な問題であり、特定の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日間程度です。プレフィックスが利用不足でない限り、接頭寿命が周期的である（48時間毎）を再生/拡張、（付録A参照します）。割り当ては需要主導型であるため、Maass第長いプレフィックス寿命（例えば、3-6ヶ月）が必要な場合は、割り当てられたプレフィックス寿命が自動的に拡張されます。
o A level-2 MASC domain could have children (i.e. level-3) MASC domains.
Oレベル2 MASCドメインは、子供（即ち、レベル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.
レベル2またはレベル3 MASCドメインが128未満のアドレス、レイヤ2プロトコル/機構（例えばAAP）を使用する場合、Oそのドメインとその親MASCドメイン間で実行されるべきです。
Pavlin Radoslavov Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
南カリフォルニア/ ISIロサンゼルスのPavlin Radoslavovコンピュータサイエンス学部大学、CA 90089 USA
EMail: pavlin@catarina.usc.edu
メールアドレス：pavlin@catarina.usc.edu
Deborah Estrin Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
南カリフォルニア/ ISIロサンゼルスのデボラ・エストリンコンピュータサイエンス学部大学、CA 90089 USA
EMail: estrin@isi.edu
メールアドレス：estrin@isi.edu
Ramesh Govindan University of Southern California/ISI 4676 Admiralty Way Marina Del Rey, CA 90292 USA
南カリフォルニア/ ISIのラメシュ・ガバインダン大学4676アドミラルティWayマリナデルレイ、CA 90292 USA
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
マーク・ハンドリーAT＆T ISCIでインターネット研究センター（ACIRI）1947センターセント、スイート600バークレー、CA 94704 USA
EMail: mjh@aciri.org
メールアドレス：mjh@aciri.org
Satish Kumar Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
南カリフォルニア/ ISIロサンゼルスのサティシュ・クマールコンピュータサイエンス学部大学、CA 90089 USA
EMail: kkumar@usc.edu
メールアドレス：kkumar@usc.edu
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
デビッド・ターラーマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: dthaler@microsoft.com
メールアドレス：dthaler@microsoft.com
[AAP] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress.
【AAP]ハンドレー、M.およびS.ハンナ、 "マルチキャストアドレス割り当てプロトコル（AAP）"、ProgressのWork。
[API] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[API]フィンレイソン、R.、RFC 2771、2000年2月 "マルチキャストアドレスの割り当てのための抽象API"。
[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.
[BGP] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[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環境でのプロバイダの境界を越えてルーティング情報を交換"、RFC 1520、1993年9月。
[IANA] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[IANA]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[KAMPAI] Tsuchiya, P., "Efficient and Flexible Hierarchical Address Assignment", INET92, June 1992, pp. 441--450.
[KAMPAI]土屋、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.
【MADCAP]ハンナ、S.、パテル、B.及びM.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、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、 "インターネットマルチキャストアドレス配分アーキテクチャ"、RFC 2908、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のためのマルチプロトコルの拡張"、RFC 2283、1997年9月。
[MTRACE] Fenner, W., and S. Casner, "A `traceroute' facility for IP Multicast", Work in Progress.
[MTRACE]フェナー、W.、およびS. Casner、 "IPマルチキャストのための`のtraceroute」施設" が進行中で働いています。
[MZAP] Handley, M, Thaler, D. and R. Kermode "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[MZAP]ハンドリー、M、ターラー、D.とR. Kermode "マルチキャストスコープゾーン発表プロトコル（MZAP）"、RFC 2776、2000年2月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[SCOPE] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[SCOPE]マイヤー、D.、 "管理スコープのIPマルチキャスト"、RFC 2365、1998年7月。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。