[要約] RFC 2909は、マルチキャストアドレスセットクレーム（MASC）プロトコルに関するものであり、マルチキャストアドレスの所有権を主張するためのプロトコルです。その目的は、マルチキャストアドレスの競合を解決し、アドレスの使用を効果的に管理することです。
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
マルチキャストアドレスセットクレーム（MASC）プロトコル
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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.
ドメインに関連付けられたプレフィックスのセット（「アドレスセット」）は、ドメイン間ルーティングプロトコル（BGP4 [MBGP]など）に注入され、ドメイン間マルチキャストツリー構造プロトコル（例：BGMP）で使用できます。[BGMP]）ドメイン間グループ共有ツリーを構築する。
Note that a domain does not need to allocate an address set for the hosts in that domain to be able to allocate group addresses, nor does allocating necessarily guarantee that hosts in other domains will not use an address in the set (since, for example, hosts are not forced to contact a MAAS before using a group address). Allocating an address set to a domain does, however, ensure that inter-domain group-specific multicast distribution trees for any group in the address set will be locally-rooted, and that traffic will be sent outside the given domain only when and where external receivers exist.
ドメインは、グループアドレスを割り当てることができるようにそのドメインのホストにアドレスセットを割り当てる必要がないことに注意してください。また、他のドメインのホストがセット内のアドレスを使用しないことを必ずしも保証しないことに注意してください（たとえば、たとえば、ホストは、グループアドレスを使用する前に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サーバーAノード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].
[RFC1112]のIPv4および[RFC2460]のIPv6で定義されているマルチキャスト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）プロトコルは、MASCドメインによって使用され、各ドメイン内のマルチキャストアドレス割り当てサーバー（MAASS）によって使用されるアドレスセットを請求および割り当てます。通常、独自のマルチキャストアドレススペースを必要とする各ドメインの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ノードによって選択されたアドレスセットは、そのノードのドメインに割り当てられていると見なされます。その後、3つのことが起こる可能性があります。
a) The allocated prefix can then be injected as a "multicast route" into the inter-domain routing protocol (e.g., BGP4+ [MBGP]) as "G-RIB" Network Layer Reachability Information (NLRI), where it may be used by an inter-domain multicast routing protocol (e.g., BGMP [BGMP]) to construct group-shared trees. To reduce the size and slow the growth of the G-RIB, MASC nodes may perform CIDR-like aggregation [CIDR] of the multicast NLRI information. This motivates the need for an algorithm to select prefixes for domains in such a way as to ensure good aggregation in addition to achieving good address space utilization.
a) 割り当てられたプレフィックスは、「マルチキャストルート」としてドメイン間ルーティングプロトコル（例：BGP4 [MBGP]）に「G-rib」ネットワークレイヤーリーチビリティ情報（NLRI）として注入できます。-Domainマルチキャストルーティングプロトコル（例：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が使用するドメイン階層は、ドメイン間トポロジーのやや階層構造、たとえば地域に接続されたバックボーン、メトロポリタンプロバイダーに接続された地域などと一致しています。他のMASCドメインの顧客であるMASCドメインには、親としてこれらのプロバイダードメインの1つ以上があります。たとえば、地域のプロバイダーであるMASCドメインは、バックボーンプロバイダードメインの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には、単一の顧客（または「子」）、C5、（C5A、C5B、C5C）が含まれています。P4には、それぞれ（C5A、C5B、C5C）、（C6A、C6B）、および（C7a）を含む3人の子供、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の内部_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.
子の顧客関係が存在するため、ローカルノードはリモートノードからアドレススペースを取得できます。たとえば、C6AはP4Aとのセッションの子供です。
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.
親Aプロバイダー関係が存在するため、リモートノードがローカルノードからアドレススペースを取得できます。たとえば、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（トップレベルのドメイン兄弟ピアリング）とのセッションの兄弟です。また、C6Bは、共通の親P4に関してC7Aとのセッションで兄弟です。
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.
プレフィックスの寿命が切れた後、そのプレフィックスを所有するドメイン内のマスコンノードは、そのプレフィックスの使用を停止する必要があります。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.
複数の共通の親を持つ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は、管理スコープゾーン[スコープ]内のアドレスのサブアロークのプレフィックスにも使用できますが、スコープが「分裂可能」（[malloc]および[mzap]で説明されているように）の場合にのみ。MASCノードは、MZAP [MZAP]メッセージを聞くことで、内部に存在するスコープを学習できます。
A "Zone TLD" is a domain which has no parent domain within the scope zone. Zone TLDs act as TLDs for the prefix associated with the scope. Figure 2 gives an example, where a scope boundary around domains P3 and C5 has been added to Figure 1. Domain P3 is a Zone TLD, since its only parent (T1) is outside the boundary. Hence, P3 can claim space directly out of the prefix associated with the scope itself. Domain C5, on the other hand, has a parent within the scope (namely, P3), and hence is not a Zone TLD.
「ゾーンTLD」は、スコープゾーン内に親ドメインがないドメインです。ゾーンTLDSは、スコープに関連付けられたプレフィックスのTLDSとして機能します。図2に、ドメインP3とC5の周りのスコープ境界が図1に追加されている例を示します。ドメインP3はゾーンTLDです。したがって、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ドメインに代わってより多くのアドレススペースを必要とする場合、アドレスプレフィックスのサイズと値をローカルで決定します。たとえば、このノードが親のアドレスセット、その兄弟の主張と割り当て、独自のアドレスセット、兄弟からの主張メッセージ、および/またはその子供と需要パターンに関する知識に基づいて、決定は基に基づいている可能性があります。ローカルドメイン。サンプルアルゴリズムは付録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) クレームは、両親の1人（ドメインがトップレベルのドメインではない場合）、同じ親と同じ親のすべての兄弟、およびすべての内部ピアに送信されます。その後、クレームタイマーが[waite_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 すべての子供と内部ピアにプレフィックス_管理メッセージを送信し、管理されたスペース内でクレームを発行する可能性があることを通知します。その後、局所的な使用についてサブプレフィックスを請求できます（セクション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)
o freix_in_use、rack_denied、rack_to_expand、またはnew_claim（prefix_manage、撤回は、比較する必要があるクレームとは見なされない）の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
o クレームを発信したノードのMASC識別子
When two claims are compared, first the type is compared based on the following precedence:
2つのクレームを比較すると、最初に次の優先順位に基づいてタイプが比較されます。
PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_CLAIM
If the type is the same, then the timestamps are used to compare the claims. In practice, two claims will have the same type if the type is either NEW_CLAIM (ordinary collision) or PREFIX_IN_USE (signal for a clash). When the timestamps are compared, the claim with the smallest, i.e. earliest timestamp wins. If the timestamps are the same, then the claim with the smallest Origin Node Identifier wins.
タイプが同じ場合、タイムスタンプはクレームを比較するために使用されます。実際には、タイプがnew_claim（通常の衝突）またはprefix_in_use（衝突の信号）のいずれかである場合、2つのクレームは同じタイプになります。タイムスタンプを比較すると、最小の、つまり初期のタイムスタンプでの主張が勝ちます。タイムスタンプが同じ場合、最小のオリジンノード識別子のクレームが勝ちます。
The procedure for extending the lifetime of prefixes already in use is the same as claiming new space (see Section 5.1), except that the claim type must be CLAIM_TO_EXPAND, while the Address and the Mask of the claim (see Section 7.3) must be the same as the already allocated prefix. If the Claim-Timer expires and there is no collision, the desired lifetime is assumed.
既に使用されているプレフィックスの寿命を延長する手順は、クレームタイプが請求_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.
既に使用されているプレフィックスの寿命を延長する手順は、クレームタイプが請求_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.
[PORT_NUMBER] 2587. IANAによって割り当てられたように、入ってくるMASC接続を聞くために使用されるTCPポート番号。
[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).
[waite_period] new_claim（またはrack_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]）。[initiate_claim_delay]のデフォルト値：600秒（つまり、10分）。
[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-OCTET符号なし整数は、オクテットのヘッダーを含むメッセージの全長を示します。したがって、たとえば、次のメッセージの開始をトランスポートレベルのストリームに配置できます。長さフィールドの値は、常に少なくとも4で4096以下でなければならず、メッセージタイプに応じてさらに制約される場合があります。メッセージが許可された後、追加データの「パディング」はないため、長さのフィールドは、メッセージの残りの部分を考慮して、必要な最小値を持つ必要があります。
Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
タイプ：この1-OCTET Unsigned Integerは、メッセージのタイプコードを示します。次のタイプコードが定義されています。
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
1-オープン2-更新3-通知4-キープライブ
Reserved: This 1-octet field is reserved. MUST be set to zero by the sender, and MUST be ignored by the receiver.
予約済み：この1-OCTETフィールドは予約されています。送信者はゼロに設定する必要があり、受信機は無視する必要があります。
After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
トランスポートプロトコル接続が確立された後、各側から送信された最初のメッセージは開かれたメッセージです。オープンメッセージが許容できる場合、オープンを確認するキープライブメッセージが返送されます。オープンが確認されると、更新、KeepAlive、および通知メッセージが交換される場合があります。
The minimum length of the OPEN message is 20 octets (including message header). In addition to the fixed-size MASC header, the OPEN message contains the following fields:
開いたメッセージの最小長は20オクテット（メッセージヘッダーを含む）です。固定サイズのMASCヘッダーに加えて、開くメッセージには次のフィールドが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |R| AddrFam |Rol| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MASC Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent's Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: This 1-octet unsigned integer indicates the protocol version number of the message. The current MASC version number is 1.
バージョン：この1-OCTET Unsigned Integerは、メッセージのプロトコルバージョン番号を示します。現在の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)
私の役割（ROL）：この2ビットフィールドは、送信システムと受信システムとの関係を示しています：00 = internal_peer（ある内部ピアから別のピアに送信）兄弟（ある兄弟から別の兄弟に送られた）11 =親（親から子供に送られた）
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-OCTETの署名されていない整数は、送信者がホールドタイマーの値を提案する秒数を示します。開いたメッセージを受信すると、MASCスピーカーは、そのピアの構成された保留時間の小さいと、開いたメッセージで受け取った保留時間を使用して、ホールドタイマーの値を計算する必要があります。保留時間はゼロまたは少なくとも3秒でなければなりません。実装は、保留時間に基づいて接続を拒否する場合があります。計算された値は、送信者による連続したキープライブおよび/または更新メッセージの受領の間に経過する可能性のある最大秒数を示します。推奨値は[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-OCTET整数、または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ノード識別子の値を、そのMASCスピーカーに割り当てられたグローバルな不一致の値に設定します（例：IPv4またはIPv6アドレス）。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の場合。ROLがinternal_peerまたは兄弟である場合にのみ使用されますが、それ以外の場合は無視されます。この分野は、兄弟間の一般的な親を決定し、兄弟と兄弟と兄弟のそれぞれと姉妹のつながりを特定の親と関連付け、内部のピア間のTLD関連の構成問題を発見するために使用されます。非TLDノードが両親のいずれかのドメインIDをまだ知らない場合、内部ピアへの開いたメッセージで独自のドメイン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).
更新メッセージは、MASCスピーカー間で請求/衝突/プレフィックス管理された情報を転送するために使用されます。更新メッセージには、常に固定サイズのMASCヘッダーと、以下に説明する1つ以上の属性が含まれます。更新メッセージの最小長は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-OCTET Unsigned Integerは、属性のタイプコードを示します。次のタイプコードが定義されています。
0 = PREFIX_IN_USE (prefix is being used by the origin) 1 = CLAIM_DENIED (the claim is refused (probably by the origin's parent domain)) 2 = CLAIM_TO_EXPAND (origin is trying to expand the size of an existing prefix) 3 = NEW_CLAIM (origin is trying to claim a new prefix) 4 = PREFIX_MANAGED (parent is informing child of space available) 5 = WITHDRAW (origin is withdrawing a previous claim)
0 = prefix_in_use（プレフィックスは原点によって使用されています）新しいプレフィックスを請求しようとしている）
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は、「オプションの」属性用に予約されています。必要な属性が認識されていない場合、更新エラーコードと認識されていない必要な属性サブコードを使用した通知が送信されます。認識されていないオプションの属性は、単に無視されます。
Reserved: This 1-octet field is reserved. MUST be set to zero by the sender, and MUST be ignored by the receiver.
予約済み：この1-OCTETフィールドは予約されています。送信者はゼロに設定する必要があり、受信機は無視する必要があります。
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、および撤回のエンコードについて説明します。
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.
予約1：この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-bit：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 =内部（送信者のドメインによって発信された）01 =子（送信者のドメインの子から発信される）10 =兄弟（送信者のドメインの兄弟によって生まれた）11 =親（送信者のドメインの親によって生まれた）
Reserved2: This 2-octet field is reserved. MUST be set to zero by the sender, and MUST be ignored by the receiver.
予約2：この2-OCTETフィールドは予約されています。送信者はゼロに設定する必要があり、受信機は無視する必要があります。
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.
クレームタイムスタンプ：クレームが発信されたときのタイムスタンプ。タイムスタンプは、1970年1月1日、グリニッジの真夜中（0時間）から秒数で表されます。
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の主張の場合、それはlifetimeを請求することと等しくなければなりません。rable_to_expand、new_claim、およびrack_deniedの場合、[waite_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).
Origin Domain Identifier：クレームオリジネーターのドメイン識別子。その長さと形式の定義は、送信者ドメイン識別子と同じです（セクション7.2を参照）。
Origin Node Identifier: The MASC Node ID of the claim originator. Its length and format definition are same as the Sender MASC Node Identifier (see Section 7.2).
Originノード識別子：クレームオリジネーターのMASCノードID。その長さと形式の定義は、送信者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)
アドレス：エンコードする指定されたプレフィックスに関連付けられたアドレス。長さはアドレスファミリに基づいて決定されます（例：IPv4の4オクテット、IPv6の場合は16）
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メッセージはピア間で十分なほど十分に交換されます。送信された最後のKeepAliveまたは更新メッセージの間の合理的な最大時間、およびKeepaliveメッセージが送信される時間は、保留時間間隔の3分の1になります。KeepAliveメッセージは、1秒あたり1秒よりも頻繁に送信してはなりません。実装は、保留時間間隔の関数としてKeepAliveメッセージを送信するレートを調整する場合があります。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
ネゴシエートされた保持時間間隔がゼロの場合、定期的なkeepAliveメッセージを送信する必要はありません。
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オープンメッセージエラーセクション8.2
3 UPDATE Message Error Section 8.3
3更新メッセージエラーセクション8.3
4 Hold Timer Expired Section 8.4
4ホールドタイマーの有効期限が切れたセクション8.4
5 Finite State Machine Error Section 8.5
5有限状態マシンエラーセクション8.5
6 NOTIFICATION Message Error Section 8.6
6通知メッセージエラーセクション8.6
7 Cease Section 8.7
7セクション8.7を停止します
Error subcode: This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field, and the O-bit must be zero (i.e. the connection will be closed). The notation used in the error description below is: MC = Must Close connection = O-bit is zero; CC = Can Close connection = O-bit might be zero.
エラーサブコード：この1-OCTET Unsigned Integerは、報告されたエラーの性質に関するより具体的な情報を提供します。各エラーコードには、1つ以上のエラーサブコードが関連付けられている場合があります。適切なエラーサブコードが定義されていない場合、エラーサブコードフィールドにゼロ（非特異的）値が使用され、Oビットはゼロでなければなりません（つまり、接続は閉じます）。以下のエラー説明で使用される表記法は次のとおりです。MC=接続を閉じる必要があります= O-Bitはゼロです。CC =接続を閉じることができます= o-bitはゼロかもしれません。
Message Header Error subcodes: 0 - Unspecific (MC) 1 - Bad Message Length (MC) 2 - Bad Message Type (CC)
メッセージヘッダーエラーサブコード：0-非特異的（MC）1-悪いメッセージ長（MC）2-悪いメッセージタイプ（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)
0-非特異的（MC）1-サポートされていないバージョン番号（MC）2-悪いピアドメインID（MC）3-悪いピアマスドノードID（MC）6-許容できない保留時間（MC）7-無効な親構成（MC）8 - 一貫性のない役割（MC）9-悪い親ドメインID（MC）10-一般的な親（MC）13-認識されていないアドレスファミリー（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)
更新メッセージエラーサブコード：0-非特異的（MC）1-不正な属性リスト（MC）2-認識されていない必要な属性（CC）5-属性長エラー（MC）10-無効なアドレスフィールド（CC）11-無効なマスクフィールド（CC（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-クレームホールドタイムもShort（CC）29 -Holdtimeが長すぎる（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)
0 -Unspecific（MC）1 -Open/Close MASC接続FSMエラー（MC）2-予期しないメッセージタイプFSMエラー（MC）
Cease subcodes (the O-bit is always zero):
サブコードを停止します（Oビットは常にゼロです）：
0 - Unspecific (MC)
0-非特異的（MC）
NOTIFICATION subcodes (the O-bit is always zero):
通知サブコード（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).
メッセージヘッダーの処理中に検出されたすべてのエラーは、エラーコードメッセージヘッダーエラーを使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。データフィールドには、誤ったメッセージ（メッセージヘッダーを含む）が含まれています。
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未満または4096を超えている場合、または開いたメッセージの長さが開いているメッセージの最小長い場合、または更新メッセージの長さが最小長い場合の場合更新メッセージの場合、またはKeepAliveメッセージの長さが4に等しくない場合、エラーサブコードはメッセージの長さが悪いに設定されます。
If the Type field of the message header is not recognized, then the Error Subcode is set to Bad Message 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.
オープンメッセージの処理中に検出されたすべてのエラーは、エラーコードを開くメッセージエラーを使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。データフィールドには、特に明記しない限り、誤った開くメッセージ（メッセージヘッダーを除く）が含まれます。
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).
受信したオープンメッセージのバージョンフィールドに含まれるバージョン番号がサポートされていない場合、エラーサブコードはサポートされていないバージョン番号に設定されます。データフィールドは、1オクテストの署名されていない整数であり、リモートMASCノード入札のバージョンよりもローカルでサポートされている最大のバージョン数が少ないことを示しています（受信したオープンメッセージに示されています）。
If the Sender Domain Identifier field of the OPEN message is unacceptable, then the Error Subcode is set to Bad Peer Domain ID. The determination of acceptable Domain IDs is outside the scope of this protocol.
開いたメッセージの送信者ドメイン識別子フィールドが許容できない場合、エラーサブコードは悪いピアドメイン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.
開いているメッセージの送信者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.
開いたメッセージの保持時間フィールドが受け入れられない場合、エラーサブコードは許容できない保留時間に設定する必要があります。実装は、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-OCTETで、ローカルシステムの構成された役割が含まれています。
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.
リモートシステムが兄弟であると想定されているが、ローカルシステム（開いているメッセージの親ドメイン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.
更新メッセージの処理中に検出されたすべてのエラーは、エラーコード更新メッセージエラーを使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。データフィールドには、特に明記しない限り、誤った更新メッセージ（属性ヘッダーを含むが、メッセージヘッダーを除く）が含まれます。
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.
マスクフィールドには、非連続ビットマスクが含まれており、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の役割/クレームタイプの組み合わせが次のいずれかではない場合、エラーサブコードはタイプエラーをクレームするように設定されます。
Origin Claim Role Type
Originクレームロールタイプ
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 chail_denied（1）iCs rack_to_expand（2）iCs new_claim（3）i p prefix_manage（4）ICSP撤回（5）
If there is a reason to believe that the Origin Domain ID is invalid, then the Error Subcode is set to Origin Domain ID Error. The same applies for Origin Node ID (the corresponding error is Origin Node ID Error).
Origin Domain IDが無効であると信じる理由がある場合、エラーサブコードはOriginドメインIDエラーに設定されます。同じことがOrigin Node IDにも当てはまります（対応するエラーはOriginノード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時間）であると判断した場合、サブコードのクレームのライフタイムが短すぎるという更新メッセージエラーが送信される場合があります。
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.
ノード（通常、子供からクレームを受け取る親）が、請求の寿命が長すぎること（たとえば、15,768,000以上、つまり半年）であると判断した場合、サブコードクレームのライフタイムで更新メッセージエラーを送信する場合があります。通常、親MASCノードは、最も長い許容寿命で満たされたクレームライフタイムフィールドを使用して、最初のクレーム_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.
ノード（通常、子供からクレームを受け取る親）がクレームタイムスタンプが小さすぎる、つまり古すぎると判断した場合（たとえば、ノードが時計が非常に正確であることを自信がある場合）、それは送信する必要があります。サブコードの請求タイムスタンプが古くなりすぎるメッセージエラーを更新します。請求タイムスタンプが多すぎると同様に定義されています。
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.
ノード（通常、子供からクレームを受け取る親）がマスクフィールドで暗示されるプレフィックスサイズが小さすぎること（たとえば、16のアドレスより小さい）であると判断した場合、サブコード請求プレフィックスサイズの更新メッセージエラーを送信する場合があります小さすぎる。
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.
ノード（通常、子供からクレームを受け取る親）がマスクフィールドで暗示されているプレフィックスサイズが大きすぎると判断した場合、サブコードクレームのプレフィックスサイズが大きすぎて更新メッセージエラーを送信する場合があります。通常、親MASCノードは、子供の大規模な主張された住所範囲の一部のサブレンジに対して、最初の請求_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.
受信した更新メッセージの計算された更新された元の役割が違法である場合（セクション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.
受信した更新メッセージを親のプレフィックスに関連付ける必要があるが、関連性が成功していない場合、エラーサブコードは適切な親プレフィックスに設定されます。適切な子プレフィックスなし、適切な内部プレフィックス、および適切な兄弟プレフィックスエラーサブコードも同様に定義されていません。
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.
ノードがクレームホールドタイムが短すぎると判断した場合（たとえば、ほんの数秒）、サブコードの請求保留タイムが短すぎて更新メッセージエラーを送信する場合があります。
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.
ノードがクレームホールドタイムが長すぎると判断した場合（たとえば、15,768,000を超える、つまり半年）、サブコードの請求保留タイムを使用して更新メッセージエラーを送信する必要があります。
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.
システムが、開いたメッセージの保留時間フィールドで指定された期間内に継続的なKeepaliveおよび/または更新および/または通知メッセージを受信しない場合、Hold Timerの有効期限が切れたエラーコードを持つ通知メッセージを送信し、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有限状態マシンによって検出されたエラー（予期しないイベントの受領など）は、エラーコード有限状態マシンエラーを使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。
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ビットゼロ付きの通知、通知エラーのエラーコード、およびサブコード非特異的なサブコードを送信する必要があります。さらに、データフィールドには、不規則な通知メッセージを含める必要があります。ただし、不規則な通知メッセージの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つの並列接続が形成される可能性があります。この状況を接続衝突と呼びます。明らかに、これらの接続の1つを閉じる必要があります。ノードが兄弟であり、それらのそれぞれの接続が異なる親に関連付けられていた場合、この状況は衝突とは見なさないことに注意してください（セクション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スピーカーによって開始された接続のみを保持することです。
Upon receipt of an OPEN message, the local system must examine all of its connections that are in the OpenConfirm state. A MASC speaker may also examine connections in an OpenSent state if it knows the MASC Node Identifier of the remote node by means outside of the protocol. If among these connections there is a connection to a remote MASC speaker whose MASC Node Identifier equals the one in the OPEN message, and, in case of a sibling-to-sibling connection, the Parent Domain ID of that connection equals the one in the OPEN message, then the local system performs the following connection collision resolution procedure:
オープンメッセージを受信すると、ローカルシステムは、OpenConfirm状態にあるすべての接続を調べなければなりません。MASCスピーカーは、プロトコルの外側の外側にあるリモートノードのMASCノード識別子を知っている場合、オープンな状態での接続を調べることもできます。これらの接続の中に、MASCノード識別子が開かれたメッセージのものに等しいリモートMASCスピーカーへの接続があり、兄弟から姉妹への接続の場合、その接続の親ドメインIDはメッセージを開くと、ローカルシステムが次の接続衝突解決手順を実行します。
1. The MASC Node Identifier of the local system is compared to the MASC Node Identifier of the remote system (as specified in the OPEN message). Comparing MASC Node Identifiers is done by treating them as unsigned integers (e.g. 4-octets long for IPv4 and 16-octets long for IPv6).
1. ローカルシステムのMASCノード識別子は、リモートシステムのMASCノード識別子と比較されます（開くメッセージで指定されています）。MASCノード識別子の比較は、それらを符号なしの整数として扱うことによって行われます（例：IPv4の場合は4オクテット、IPv6の場合は16オクテットが長い）。
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ノード識別子の値がリモートの値よりも小さい場合、ローカルシステムは既に存在する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を参照）。
Closing the MASC connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
MASC接続の閉鎖（衝突解像度の手順から生じる）は、エラーコードが停止して通知メッセージを送信することで達成されます。
MASC speakers may negotiate the version of the protocol by making multiple attempts to open a MASC connection, starting with the highest version number each supports. If an open attempt fails with an Error Code OPEN Message Error, and an Error Subcode Unsupported Version Number, then the MASC speaker has available the version number it tried, the version number the remote node tried, the version number passed by the remote node in the NOTIFICATION message, and the version numbers that it supports. If the two MASC speakers do support one or more common versions, then this will allow them to rapidly determine the highest common version. In order to support MASC version negotiation, future versions of MASC must retain the format of the OPEN and NOTIFICATION messages.
MASCスピーカーは、MASC接続を開くために複数の試行を行うことにより、各サポートを開始することにより、プロトコルのバージョンをネゴシエートする場合があります。オープン試行がエラーコードを開くメッセージエラーとエラーサブコードのサポートバージョン番号で失敗した場合、MASCスピーカーは試したバージョン番号、リモートノードが試したバージョン番号、リモートノードで渡されたバージョン番号を使用できます。通知メッセージ、およびサポートするバージョン番号。2つのMASCスピーカーが1つ以上の一般的なバージョンをサポートしている場合、これにより、最高の一般的なバージョンを迅速に決定できます。MASCバージョンのネゴシエーションをサポートするために、MASCの将来のバージョンは、オープンおよび通知メッセージの形式を保持する必要があります。
This section specifies MASC operation in terms of a Finite State Machine (FSM). The FSM and the operations are peer peering session. Following is a brief summary and overview of MASC operations by state as determined by this FSM.
このセクションでは、有限状態マシン（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リソースを初期化し、ConnectRetryタイマーを開始し、リモートノードへのトランスポート接続を開始し、リモートマスコノードによって開始される可能性のある接続をリッスンします。、およびその状態を変更して接続します。ConnectRetryタイマーの正確な値はローカルな問題ですが、TCPの初期化を可能にするには十分に大きくなければなりません。
If a MASC speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent MASC errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a node that was previously transitioned to Idle due to an error. For a node that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry, but shall not be longer than 24 hours.
MASCスピーカーがエラーを検出した場合、接続をシャットダウンし、状態をアイドル状態に変更します。アイドル状態から抜け出すには、スタートイベントの生成が必要です。このようなイベントが自動的に生成された場合、永続的なMASCエラーにより、スピーカーの永続的な羽ばたきが発生する可能性があります。このような状態を避けるために、エラーのために以前にアイドル状態に移行していたノードについて、開始イベントをすぐに生成しないことをお勧めします。エラーのために以前にアイドルに移行したノードの場合、そのようなイベントが自動的に生成された場合、開始イベントの連続した生成の間の時間は指数関数的に増加するものとします。初期タイマーの値は60秒でなければなりません。連続した各再試行の時間は2倍になりますが、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.
トランスポートプロトコル接続が成功した場合、ローカルシステムはConnectRetryタイマーをクリアし、初期化を完了し、オープンメッセージをリモートノードに送信し、その状態をオープンに変更します。Transport Protocol Connectが失敗した場合（たとえば、再送信タイムアウトなど）、ローカルシステムがConnectRetryタイマーを再起動し、リモート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.
ConnectRetryタイマーの期限切れイベントに応じて、ローカルシステムはConnectRetryタイマーを再起動し、他の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.
トランスポートプロトコル接続が成功した場合、ローカルシステムはConnectRetryタイマーをクリアし、初期化を完了し、オープンメッセージをリモートノードに送信し、ホールドタイマーを大きな値に設定し、状態をオープンに変更します。[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.
ConnectRetryタイマーの期限切れイベントに応じて、ローカルシステムはConnectRetryタイマーを再起動し、他の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アドレスが予想されるものではない場合、ローカルシステムはConnectRetryタイマーを再起動し、試行された接続を拒否し、聞き続けますリモート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:
オープンな状態：
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 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.
この状態では、MASCはリモートノードから開いたメッセージを待っています。開いたメッセージが受信されると、すべてのフィールドに正確さが確認されます。MASCメッセージヘッダーチェックまたは開きメッセージチェックがエラー（セクション8.2を参照）、または接続衝突（セクション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.
ローカルに構成された役割が兄弟であり、開いたメッセージの親ドメインIDに等しいドメインIDを持つ親ドメインがない場合、ローカルシステムはエラーサブコード設定で通知を送信します共通の親にセットするには、接続を閉じる必要があります、そしてローカルシステムの状態をアイドル状態に変更する必要があります。
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.
オープンメッセージにエラーがない場合、MASCはKeepAliveメッセージを送信し、KeepAliveタイマーを設定します。もともと大きな値（上記参照）に設定されていたホールドタイマーは、交渉された保留時間値に置き換えられます（セクション7.2を参照）。ネゴシエートされた保持時間値がゼロの場合、ホールドタイムタイマーとキープライブタイマーは開始されません。MASCドメインIDフィールドの値がローカルMASCドメインIDと同じであり、開くメッセージのロールフィールドが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接続を閉じ、ConnectRetryタイマーを再起動し、リモート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.
ホールドタイマーの有効期限が切れた場合、ローカルシステムはエラーコードの有効期限が切れ、その状態をアイドル状態に変更して通知メッセージを送信します。
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.
STOPイベント（システムまたはオペレーターのいずれかによって開始された）に応じて、ローカルシステムはエラーコードの停止を伴う通知メッセージを送信し、状態をアイドル状態に変更します。
The Start event is ignored in the OpenSent state.
開始イベントは、オープンな状態で無視されます。
In response to any other event the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and Error Subcode Open/Close MASC Connection FSM Error, and changes its state to Idle.
他のイベントに応じて、ローカルシステムはエラーコードの有限状態マシンエラーとエラーサブコードを使用して通知メッセージを送信します。
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が状態をオープンでアイドル状態からアイドル状態に変更すると、MASC（および輸送レベル）接続を閉じ、その接続に関連するすべてのリソースをリリースします。
OpenConfirm state:
OpenConfirm州：
In this state MASC waits for a KEEPALIVE or NOTIFICATION message.
この状態では、MASCはキープライブまたは通知メッセージを待ちます。
If the local system receives a KEEPALIVE message, it changes its state to Established.
ローカルシステムがキープライブメッセージを受信した場合、状態を確立するまで変更します。
If the Hold Timer expires before a KEEPALIVE message is received, the local system sends a NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
KeepAliveメッセージが受信される前にHoldタイマーが期限切れになった場合、ローカルシステムはエラーコードの有効期限が切れ、その状態をアイドル状態に変更する通知メッセージを送信します。
If the local system receives a NOTIFICATION message with the O-bit zeroed, it changes its state to Idle.
ローカルシステムがOビットがゼロになって通知メッセージを受信した場合、状態をアイドル状態に変更します。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
Keepalive Timerが期限切れになった場合、ローカルシステムはKeepAliveメッセージを送信し、KeepAliveタイマーを再起動します。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
基礎となる輸送プロトコルから切断通知が受信された場合、ローカルシステムは状態をアイドル状態に変更します。
In response to the Stop event (initiated by either system or operator) the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle.
STOPイベント（システムまたはオペレーターのいずれかによって開始された）に応じて、ローカルシステムはエラーコードの停止を伴う通知メッセージを送信し、状態をアイドル状態に変更します。
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.
他のイベントに応じて、ローカルシステムはエラーコードの有限状態マシンエラーとエラーサブコードを使用して通知メッセージを送信し、その状態をアイドル状態に変更します。
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がOpenConfirmからアイドルに状態を変更すると、MASC（および輸送レベル）接続を閉じ、その接続に関連するすべてのリソースをリリースします。
Established state:
確立された州：
In the Established state MASC can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with the remote node.
確立された状態では、MASCはリモートノードで更新、通知、およびキープライブメッセージを交換できます。
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.
ローカルシステムが更新、またはKeepAliveメッセージ、またはOBITセットを使用した通知メッセージを受信した場合、ネゴシエートされた保持時間値がゼロでない場合、ホールドタイマーを再起動します。
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を参照）がエラーを検出した場合、ローカルシステムは通知メッセージを送信し、Oビットがゼロになった場合、状態をアイドル状態に変更します。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
基礎となる輸送プロトコルから切断通知が受信された場合、ローカルシステムは状態をアイドル状態に変更します。
If the Hold Timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and changes its state to Idle.
ホールドタイマーの有効期限が切れた場合、ローカルシステムはエラーコードの有効期限が切れ、その状態をアイドル状態に変更して通知メッセージを送信します。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
Keepalive Timerが期限切れになった場合、ローカルシステムはKeepAliveメッセージを送信し、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または更新メッセージを送信するたびに、交渉された保持時間値がゼロでない限り、KeepAliveタイマーを再起動します。
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.
STOPイベント（システムまたはオペレーターのいずれかによって開始される）に応じて、ローカルシステムはエラーコードの停止を伴う通知メッセージを送信し、状態をアイドル状態に変更します。
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).
確立された状態に入った後、ローカルシステムにリモートノードに送信される更新メッセージがある場合、すぐに送信する必要があります（セクション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ビットゼロとエラーサブコードが非特異的で、その状態をアイドル状態に変更します。
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が確立された状態からアイドル状態まで状態を変更するたびに、MASC（および輸送レベル）接続を閉じ、その接続に関連するすべてのリソースを解放し、その接続から派生したすべての状態を削除します。
The UPDATE message are accepted only when the system is in the Established state.
更新メッセージは、システムが確立された状態にある場合にのみ受け入れられます。
In the text below, a MASC domain is considered a child of itself with regard to the claims that are related to the address space with local usage purpose (i.e. to be used by the MAASs within that domain). For 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.
更新をさらに伝播する場合、そのノードへの接続がダウンしてから復元されたことを示さない限り、更新が受信されたノードに送信されないでください。
If the local system receives an UPDATE message, and there is no indication for error, it checks whether to accept or reject the message, and if it is not rejected, the UPDATE is processed based on its type.
ローカルシステムが更新メッセージを受信し、エラーの兆候がない場合、メッセージを受け入れるか拒否するかをチェックし、拒否されていない場合、更新はそのタイプに基づいて処理されます。
If an UPDATE message must be associated with a parent domain, then there must be a PREFIX_MANAGED by some parent domain for a prefix that covers the prefix of the particular UPDATE.
更新メッセージが親ドメインに関連付けられている必要がある場合、特定のアップデートのプレフィックスをカバーするプレフィックスについては、親ドメインによって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.
Originの役割フィールドは、表1によると、ローカルシステムの構成された役割と最初に比較され、原点とローカル構成の関係を決定します。ローカルに構成された役割は、メッセージのピアフォーカーに関するローカル構成です。。「---」の結果は、そのような更新を受信することは違法であり、通知を生成する必要があることを意味します。他の結果は、他の更新を伝播する際に「更新された」起源の役割として使用する価値です。これは、リンクのメトリックに基づいて、ルートを受信するとメトリックを更新することに類似しています。
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)).
o 更新されたOriginの役割計算からの出力が兄弟であるが、Origin Domain IDがローカルMASCドメインと同じである場合、更新されたOriginの役割は内部に変更されます。これは、MASCノードが再起動後に親または兄弟から独自の更新を受信した場合、または内部パーティション化のために、内部_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.
o 局所的に構成された役割と起源の役割の両方が親に等しく、OriginドメインIDがローカルMASCドメインと同じである場合、更新されたオリジンの役割は内部に変更されます。これは、親が自分の子供を通して自分の更新を受け取ることができるために必要ですが、親は子供を信じない理由がある場合にそれらの更新をドロップする可能性があります。
o If both Locally-Configured Role, and Origin Role are equal to PARENT, and the Origin Domain ID is the same as the remote MASC domain, and the UPDATE type is CLAIM_DENIED, the Updated Origin Role is changed to INTERNAL. This is necessary to allow a parent to receive the CLAIM_DENIED it has originated through the child whose claim was denied. If the Origin Domain ID is not same as the remote MASC domain, but is same as some of the other MASC children domains, the Updated Origin Role still should be changed to INTERNAL, although the parent might drop this UPDATE if it has a reason not to believe a third party child.
o 局所的に構成された役割とOriginの両方の役割が親に等しい場合、Origin Domain IDがリモートMASCドメインと同じであり、更新タイプは請求_deniedである場合、更新されたオリジンの役割は内部に変更されます。これは、親が主張が拒否された子供から生まれた請求_deniedを受け取ることができるようにするために必要です。OriginドメインIDがリモートMASCドメインと同じではなく、他のMASC子供ドメインの一部と同じである場合、更新されたオリジンの役割は内部に変更する必要がありますが、親は理由がない場合はこの更新をドロップする可能性があります。サードパーティの子供を信じる。
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.
更新されたOriginの役割が内部であるが、Origin Domain IDがローカルドメインIDとは異なる場合、<更新メッセージエラーの通知、違法オリジンの役割>を返送する必要があり、クレームは拒否されます。
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.
クレームタイムスタンプとクレームホールドタイムがクレームの有効期限が切れていることを示している場合（たとえば、タイムスタンプの請求holdtime <= CurrentTime）、アップデートは静かに削除され、それ以上のアクションは実行されません。
Each new arrival UPDATE is compared with all claims in the local cache. The following fields are compared, and if all of them are the same, the message is silently rejected and no further actions are taken:
各新しい到着アップデートは、ローカルキャッシュのすべてのクレームと比較されます。次のフィールドが比較され、それらのすべてが同じ場合、メッセージは静かに拒否され、それ以上のアクションは行われません。
o Role, D-bit, Type
o 役割、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 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.
更新のさらなる処理は、そのタイプと更新されたオリジンの役割に基づいています。
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
クレームは拒否され、<更新メッセージエラー、違法出身の役割>の通知を返送する必要があります。
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に関連付けることができない場合、クレームは削除され、<更新メッセージエラーの通知、適切な親のプレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。
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ノード、すべての内部_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.
クレームのプレフィックスがローカルドメインのプレフィックス_Managedのいずれかのサブランジではない場合、クレームは削除され、<更新メッセージエラーの通知、適切な親プレフィックス>は送信する必要はなく、さらなるアクションを実行する必要はありません。それ以外の場合、クレームは、すべての内部_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_manageとして処理されます。
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
メッセージは拒否され、<更新メッセージエラー、違法出身の役割>の通知を返送する必要があります。
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.
Origin Domain IDがローカルドメインIDと同じで、更新が親ドメインに関連付けられない場合、メッセージが削除され、<更新メッセージエラーの通知、適切な親プレフィックス>は返送されない必要があります。行動をとる必要があります。
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.
Origin Domain IDがローカルドメインIDと同じであり、更新が親ドメインに関連付けられる可能性がある場合、メッセージはその親ドメイン、すべての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.
Origin Domain IDがローカルドメインIDと同じであり、ローカルMASCドメイン（つまり、同じaddrfam、Origin Domain ID、請求タイムスタンプ、アドレス、マスクを持つnew_claimまたはrack_to_expand）によって発信される対応する保留中のクレームがない場合、通知<更新メッセージエラーの場合、適切な内部プレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。それ以外の場合、一致するnew_claimまたはrack_to_expandのクレームタイマーをキャンセルする必要があり、請求をさらに考慮してはなりません。最後に、受信した請求_deniedは、すべての内部_peers、対応する親MASCドメインからのすべてのMASCノード、およびその親に関するすべての既知の兄弟に伝播する必要があります。
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
クレームは拒否され、<更新メッセージエラー、違法出身の役割>の通知を返送する必要があります。
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に関連付けることができない場合、クレームは削除され、<更新メッセージエラーの通知、適切な親のプレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。
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ドメインに重複するプレフィックス_in_useがない場合、クレームが削除され、<更新メッセージエラーの通知があり、適切な兄弟プレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。
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.
請求が衝突し、ローカルドメインの保留中の請求の一部に勝った場合、敗者の主張をさらに考慮してはならず、それぞれの請求ティマーをキャンセルする必要があります。また、受信したクレームは、対応する親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.
クレームをローカルドメインのプレフィックス_Managedのいずれかに関連付けることができない場合、クレームは削除され、<更新メッセージエラーの通知、適切な親プレフィックス>は送信する必要はなく、それ以上のアクションを実行する必要はありません。
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ドメインによってfix_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に伝播する必要があります。クレームの寿命が、ローカルドメインによって管理されている対応するプレフィックスの寿命よりも長い場合、または子供が請求されたプレフィックスを割り当てることを成功させるのを防ぐための管理上構成された理由がある場合、請求_deniedはすべてのMASCの子供ノードに送信する必要があります受信したメッセージにOrigin Domain IDと同じドメインIDがあります。rol = internalを除き、請求_deniedは受け取った請求と同じでなければなりません。それ以外の場合は、すべての子供にも主張を広めます。
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ドメインによるfreix_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ノードが、ローカルドメインがその保留中の請求をこれ以上請求する必要がないと判断した場合、それは撤回される可能性があります。それ以外の場合、クレームは、対応する親MASCドメインからのすべての内部_Peersおよびすべての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.
それ以外の場合は、請求_to_expandのように処理します。ただし、fix_in_useのオーバーラップのチェックを実行する必要がないことを除きます。
11.6. PREFIX_MANAGED Message Processing.
11.6. prefix_managedメッセージ処理。
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.
Origin Domain IDが親のドメインIDの1つと一致する場合、プレフィックスが記録され、サブレンジを割り当てるためにアドレス割り当てアルゴリズムで使用できます。また、メッセージは、対応する親ドメイン、すべての内部_peers、および同じ親の兄弟のすべてのMASCノードに伝播されます。
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
メッセージは拒否され、<更新メッセージエラー、違法出身の役割>の通知を返送する必要があります。
The prefix is recorded as allocated to the local domain, propagated to all INTERNAL_PEERs, and can be used for (all items apply):
プレフィックスは、ローカルドメインに割り当てられたものとして記録され、すべての内部_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.
撤回を子ドメインのプレフィックス_in_useのいずれかに関連付けることができない場合（つまり、子のプレフィックス_in_useが撤回の範囲をカバーすることはありません）、または撤回が子ドメインのnew_claimまたはrack_to_expandのいずれかと一致しない場合およびタイムスタンプ）、メッセージが削除され、<更新メッセージエラーの通知があり、適切な子プレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。それ以外の場合は、すべての内部_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.
撤退が兄弟のプレフィックス_in_useのいずれかに関連付けられない場合（つまり、兄弟のプレフィックスのプレフィックス_in_useが撤回の範囲をカバーすることはありません）、または撤退が兄弟ドメインのnew_claimまたはrack_to_expandのいずれかと一致しない場合（つまり、兄弟の主張は同じ住所、マスカスマスの主張はありません。およびタイムスタンプ）、メッセージが削除され、<更新メッセージエラーの通知があり、適切な兄弟プレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。それ以外の場合は、すべての内部_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.
撤回をローカルドメインのプレフィックス_in_useまたはprefix_managedのいずれかに関連付けることができない場合（つまり、ローカルドメインのプレフィックスが撤回の範囲をカバーしていない場合）、または撤回がローカルドメインのnew_claimまたはrack_to_expandのいずれかと一致しない場合（つまり、ローカルドメインの主張はありません。同じアドレス、マスク、タイムスタンプ）メッセージが削除され、<更新メッセージエラーの通知があり、適切な内部プレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。
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 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.
それ以外の場合は、すべての内部_peersに伝播します。すべての内部_peersは、そのプレフィックスの対応する親ドメインのすべてのmascノード、その親ドメインを持つすべての兄弟、およびすべての子供に伝播します。撤回がローカルドメインのprefix_in_useまたはprefix_manageの一部に関連付けられる場合は、撤退範囲をmaassに宣伝し、G-ribデータベースからその範囲を引き出すことを停止します。衝突のために撤退がローカルドメインによって発信され、撤退で指定された範囲がローカルプレフィックス_Manageのサブレンジであり、撤回の請求保留タイムがクレームホールドタイムよりも短いことを示す特別なケースでは、特別なケースではprefix_Managedの撤退範囲をG-ribから撤回しないでください。撤回がローカルドメインのnew_claimまたはrack_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.
撤回を親ドメインに関連付けることができない場合、<更新メッセージエラーの通知、適切な親のプレフィックス>を送信する必要はなく、それ以上のアクションを実行する必要はありません。
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.
それ以外の場合は、すべての内部_peersおよび同じ親ドメインを持つすべての既知の兄弟に伝播します。また、ローカル所有のprefix_managed/prefix_in_useと受信した撤回の各交差点の撤回メッセージが発生します。局所開始された撤回メッセージのクレーム保留タイムは、親から受け取った撤回メッセージのクレーム保留タイムと少なくとも等しくなければなりません。Origin Node IDは、特定のPrefix_manage/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.
一貫性と正気の実装を簡素化するために、ピアに送信する必要がある複数の更新メッセージがある場合（たとえば、接続（再）確立の後）、更新の一部を他のものより前に送信する必要があります。
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は、rack_to_expand、new_claimの前に常に送信する必要があります。
o WITHDRAW must always be sent AFTER PREFIX_IN_USE, CLAIM_TO_EXPAND, NEW_CLAIM, and PREFIX_MANAGED by the same MASC domain
o プレフィックス_in_use、rack_to_expand、new_claim、およびprefix_managed後に常に送信する必要があります。
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) 親のfix_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) すべての子供のプレフィックス_in_use、rack_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) 親は請求_deniedを開始し、子供は撤退しました。サードパーティの子供の主張/アドレス= 0のヒントに関して請求_deniedは伝播しないでください。伝播した場合、子供はそれらを落とす必要があります。
Messages are sent in the following order:
メッセージは次の順序で送信されます。
1) Parent's PREFIX_MANAGED and WITHDRAWs.
1) 親のfix_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、rack_to_expand、およびnew_claimssは、その子供とそのすべての兄弟によって開始された親のスペースからのnew_claimsです。
3) Parent's initiated CLAIM_DENIED, and all WITHDRAWSs that can be associated with that parent's space and are initiated by the local domain or all known siblings with that parent.
3) 親が開始した請求_denied、およびその親のスペースに関連付けられ、その親とのローカルドメインまたは既知のすべての兄弟によって開始されるすべての撤回。
Messages are sent in the following order:
メッセージは次の順序で送信されます。
1) All common parent's PREFIX_MANAGED and WITHDRAWs.
1) すべての一般的な親のプレフィックス_Managedと撤回。
2) PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs, initiated by siblings.
2) prefix_in_use、rack_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) common_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、rack_to_expand、およびnew_claims。より多くのスペースのヒントである兄弟からの主張（つまり、アドレス= 0）を伝播すべきではありません。伝播した場合、受信者はそれらをドロップする必要があります。
3) CLAIM_DENIEDs initiated by all parents, and WITHDRAWs initiated by local domain and all known siblings.
3) すべての親によって開始され、地元のドメインおよびすべての既知の兄弟によって開始された撤回を撤回します。
4) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
4) すべての子供のプレフィックス_in_use、rack_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ノードは、兄弟ノードへの接続を開始する前に、親ノードへの接続を確立しようとする必要があります。子供や兄弟からの独自のプレフィックス_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ドメイン（つまり、子供のドメインを持つドメイン）は、そのプレフィックス_管理アドレスを子供に宣伝し、その空間から内部MAASSに宣伝されるサブレンジを主張する必要があります（主張の待機時間は等しいはずです[waite_period]に）。非葉のMASCドメインに属するMASCノードは、ローカル使用のためのサブレンジの主張と管理に関してそれ自体の子供であることにより、二重関数を実行する必要があります。Leaf MASCドメインは、内部使用について明示的に主張することなく、すべてのPrefix_ManagedアドレスをMAASSに宣伝する必要があります。MASCノードは、子供のドメインによる更新がない場合、葉のドメインに属していると想定できます。子供による更新が受信された場合、ドメインは「リーフ」から「非葉」モードから「非葉」モードに切り替える必要があり、内部使用のためにさらにアドレスが必要な場合は、そのドメインのPrefix_Manageから請求する必要があります。子どもが有効期限を切る最後の更新の後、ドメインは「リーフ」モードに戻ることができます。
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.
各アップデートには、その更新から発信されたMASCノードの絶対時間に設定された「クレームタイムスタンプ」フィールドがあります。タイムスタンプは、衝突を解決するために、他のMASCノードのローカルキャッシュに更新を保持する時間を定義するために、2つの目的に使用されます。時計のゆがんでいると、リアルタイムの後ろに時計があるノードが生み出す請求が常に勝つように、不当な衝突決定につながる可能性があります。ただし、衝突はおそらくまれであるため、これは問題ではありません。ただし、クロックでゆがんでいる可能性があり、実際に有効期限が切れるよりも早く更新が期限切れになる可能性があり、ノードは、期限切れのアップデート/プレフィックスが割り当てのために無料であることを早すぎると仮定する可能性があります。クロックスキューを補うには、請求保留タイムで指定された時間よりも更新メッセージを長く保つ必要があります。たとえば、追加の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ノードが兄弟によって発信されたプレフィックス_in_useクレームを受信し、クレームがローカルプレフィックスの一部と重複する場合、衝突を解決する必要があります。ドメインに祖先の子孫（親子など）の関係がMASC階層に関係していない限り、2つの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では、この問題を解決するために撤退メッセージが使用されます。衝突fix_in_useが受信されると、ローカルドメインに割り当てられたすべてのプレフィックスと比較されます（セクション5.1.1で説明されています）。ローカルプレフィックス_in_useが勝者である場合、それ以上のアクションは実行されません。Local Prefix_In_useが敗者である場合、引き出しメッセージを開始することにより、衝突アドレス範囲を取り下げる必要があります。メッセージには役割=内部、Origin Node ID、およびOrigin Domain IDが対応するローカルPrefix_in_useメッセージと同じでなければなりませんが、クレームタイムスタンプ、クレームライフタイム、クレームホールドタイム、アドレス、およびマスクは、受信したwining refix_in_useと同じでなければなりません。開始された撤回メッセージは、セクション11.7で説明されているように処理する必要があります。
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ドメインが重複するプレフィックスまたはプレフィックス_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ノードの1つへのTCP接続を維持する必要があります。したがって、顧客の接頭辞を「防御」し続けることができ、古いプレフィックスの寿命が切れるまで続行する必要があります。
If the new network provider is not willing to propagate the old prefixes, then the customer should remove its prefixes from the G-RIB. If BGMP is in use, the old network provider's domain will automatically become the Root Domain for the customer's old groups due to the lack of a more specific group route. MASC nodes in the customer domain MAY still connect with the old provider's MASC nodes to defend their allocation.
新しいネットワークプロバイダーが古いプレフィックスを伝播する意思がない場合、顧客はG-RIBからプレフィックスを削除する必要があります。BGMPが使用されている場合、古いネットワークプロバイダーのドメインは、より具体的なグループルートがないため、顧客の古いグループのルートドメインに自動的になります。顧客ドメインのMASCノードは、古いプロバイダーのMASCノードと接続して、割り当てを守ることができます。
Use mtrace [MTRACE] to find the BGMP/MASC root domain for a group address chosen from that prefix.
mtrace [mtrace]を使用して、そのプレフィックスから選択したグループアドレスのBGMP/MASCルートドメインを見つけます。
We can find the address space allocated to a particular MASC domain by directly querying one of the MASC servers within that domain, by observing the state in parents, siblings, or children MASC domains, or by observing the G-RIB information originated by that domain. From those three methods, the first method can provide the most detailed information. Finding the address of one of the MASC nodes within a particular domain is outside the scope of MASC.
そのドメイン内のMASCサーバーの1つを直接照会すること、親、兄弟、または子供のMASCドメインの状態を観察すること、またはそのドメインによって発生するG-RIB情報を観察することにより、特定のMASCドメインに割り当てられたアドレス空間を見つけることができます。。これらの3つの方法から、最初の方法は最も詳細な情報を提供できます。特定のドメイン内のMASCノードの1つのアドレスを見つけることは、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 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はボーダールーターによって実行されますが、一般に安定したストレージはありません。この場合、MASCは[MALLOC]で説明されているように、レイヤー2プロトコル/メカニズム（例：（[AAP]））を使用して、安定したストレージが必要なドメインのMAASSに重要な情報（ローカルドメインによって割り当てられた接頭辞）を保存する必要があります。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ピアリングノード間のセキュリティ上の懸念に対処できます。ただし、更新メッセージのストアアンドフォワードな性質のため、信頼できない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.
誤っているノードは、兄弟のいずれかがより多くの住所を割り当てることを妨げる多数の衝突メッセージを送信することにより、サービスの拒否攻撃を試みる場合があります。すべての兄弟によって単一の誤行動をとるノードは簡単に識別でき、そのすべての更新は無視できます。複数のオリジンアドレスを使用するサービス拒否攻撃は、サードパーティの更新（例：非方向に接続された兄弟による）が一般的な親ドメインを介して送信され、親ドメインのMASCノードが送信された場合にのみ受け入れられた場合に防止できます。子どもが内部ピアを介して来る場合にのみ子供の更新を受け入れるか、Origin Node 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更新メッセージ属性タイプ、MASC更新メッセージオプションパラメータータイプ、およびMASC通知メッセージエラーコードとサブコード）を定義します。これらのすべての数値スペースについて、この仕様では特定の値が定義されています。新しい値は、[IANA-Considerations]で説明されているように、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への割り当て待ち時間は、可能な限り[waite_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は隣接するマスクを使用してアドレス範囲、つまりプレフィックスを指定する必要があります。（調査によると、隣接するマスクのみを使用して、十分に良好な結果を達成できることが示されています。）選択されたプレフィックスは、可能な限り拡張可能である必要があります。親の接頭辞から子供のサブプレフィックスを選択するために使用される方法は、いわゆるリバースビット順序です（Dave Thalerによるアイデア、Kampai [Kampai]に触発された）。たとえば、親のプレフィックス幅が4ビットの場合、サブプレフィックスのアドレスが次の順序で選択されます。
Parent: xxxx
親：xxxx
Child A: 0000 Child B: 1000 Child C: 0100 Child D: 1100
子供A：0000チャイルドB：1000チャイルドC：0100チャイルドD：1100
If some of the children need to expand their sub-prefix, they try to double the corresponding sub-prefix starting from the right:
一部の子どもたちがサブプレフィックスを拡張する必要がある場合、彼らは右から始まる対応するサブプレフィックスを2倍にしようとします。
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）からの住所の需要を常に監視し、[waite_period]後のアドレスの使用法とはどうなるかを予測します。利用可能なアドレスが[waite_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の電力であるため、ノードが単一のプレフィックスのみを割り当てようとする場合、そのノードでの使用率（つまり、そのノードのドメインで）は50％という低くなります。使用率を改善するために、MASCノードは、一度に1つ以上の接頭辞を割り当てることができます（通常、それぞれが異なるサイズの）。事前配分を使用して、異なるサイズのいくつかのプレフィックスを割り当てることにより（以下を参照）、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倍にする代わりに、2番目の「隣接」プレフィックスが選択されます。たとえば、プレフィックス224.0/16がすでに割り当てられており、MASCドメインにさらに256個のアドレスが必要な場合、請求する2番目のプレフィックスは224.1.0/24になります。ドメインがより多くのアドレスを必要とする場合、2番目のプレフィックスは最終的に224.1/16に成長し、両方のプレフィックスを224.0/15に自動的に集約できます。224.0.1/24を割り当てることができなかった場合にのみ、MASCノードは別のプレフィックスを選択します（最終的には未使用のプレフィックスの間でランダム）。
If the number of allocated prefixes increases above some threshold, and none of them can be extended when more addresses are needed, then, to reduce the amount of state, a MASC node should claim a new larger prefix and should stop re-claiming the older non-expandable prefixes. Research results show that up to three prefixes per MASC domain is a reasonable threshold, such that the address utilization can be in the range 70-90%, and at the same time the prefix flux will be reasonably low.
割り当てられた接頭辞の数がいくらかのしきい値を超えて増加し、より多くのアドレスが必要な場合に拡張できない場合、状態の量を減らすために、MASCノードは新しい大きなプレフィックスを請求し、古いものを再クレームするのを停止する必要があります非拡張性プレフィックス。研究結果は、MASCドメインごとに最大3つの接頭辞が合理的なしきい値であるため、アドレスの使用率は70〜90％の範囲になり、同時にプレフィックスフラックスがかなり低くなることが示されています。
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.0.0-255.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.0-231.255.255.255（4*2^24 = 2^26 = 64M）は、MASCによってグローバルアドレスプールとして使用できます。残り（8*2^24）は予約する必要があります。その一部は後で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.
o マルチキャストアドレスが均等に分布している場合、各TLDには最大2^19（512K）アドレスがあり、各レベル2 MASCドメインには8192アドレスがあります。
o Initial claim size: 256 addresses/MASC domain
o 初期クレームサイズ：256アドレス/MASCドメイン
o Could use soft and hard thresholds to specify the maximum amount of claimed+allocated addresses per domain. For example, trigger a warning message if claimed+allocated addresses by a domain is >= 1.0*average_assumed_per_domain (a strawman default soft threshold):
o ソフトとハードのしきい値を使用して、ドメインごとに請求された割り当てられたアドレスの最大量を指定できます。たとえば、ドメインによって割り当てられたアドレスが請求された場合、警告メッセージをトリガーします> = 1.0*verag。assumed_per_domain（ストローマンのデフォルトソフトしきい値）：
* if a TLD claim+allocation >= 512K * if a second level MASC domain claim+allocation >= 8K
* TLDが割り当てを請求する場合> = 512K *
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）は、明示的な拒否メッセージを送信することで実施できます。
The TLDs thresholds (with regard to the claims by the second level MASC domains) is a private matter and is a part of the particular TLD policy: the thresholds could be per customer, and the warnings to the administrators could be a signal that it is time to change the policy.
TLDSのしきい値（第2レベルのMASCドメインによるクレームに関して）は私的な問題であり、特定のTLDポリシーの一部です。しきい値は顧客ごとであり、管理者への警告は、ポリシーを変更する時間。
o Initial claim lifetime is of the order of 30 days. Prefix lifetime is periodically (every 48 hours) reclaimed/extended, unless the prefix is under-utilized (see APPENDIX A). Because the allocation is demand-driven, the allocated prefix lifetime will be automatically extended if the MAASs need longer prefix lifetime (e.g. 3-6 months).
o 初期クレームの寿命は30日間です。プレフィックスが十分に活用されていない限り、プレフィックスの寿命は定期的に（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.
o レベル2またはレベル3のMASCドメインが128未満のアドレスを使用する場合、レイヤー2プロトコル/メカニズム（AAPなど）をそのドメインとその親MASCドメイン間で実行する必要があります。
Pavlin Radoslavov Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
パブリンラドスラボフコンピューターサイエンス学部南カリフォルニア大学/ISIロサンゼルス、カリフォルニア州90089 USA
EMail: pavlin@catarina.usc.edu
Deborah Estrin
Computer Science Department
University of Southern California/ISI
Los Angeles, CA 90089
USA
EMail: estrin@isi.edu
Ramesh Govindan University of Southern California/ISI 4676 Admiralty Way Marina Del Rey, CA 90292 USA
南カリフォルニア大学ラメシュゴビンダン大学/ISI 4676アドミラルティウェイマリーナデルレイ、カリフォルニア90292 USA
EMail: govindan@isi.edu
Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) 1947 Center St., Suite 600 Berkeley, CA 94704 USA
ISCI（ACIRI）1947 Center St.、Suite 600 Berkeley、CA 94704 USAのMark Handley AT＆Tセンターのインターネット研究センター
EMail: mjh@aciri.org
Satish Kumar Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
サティシュクマールコンピューターサイエンス学部南カリフォルニア大学/ISIロサンゼルス、カリフォルニア州90089 USA
EMail: kkumar@usc.edu
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
David Thaler Microsoft One Microsoft Way Redmond、WA 98052 USA
EMail: dthaler@microsoft.com
[AAP] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress.
[AAP] Handley、M。およびS. Hanna、「マルチキャストアドレス割り当てプロトコル（AAP）」、作業進行中。
[API] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[API] Finlayson、R。、「マルチキャストアドレス割り当ての抽象API」、RFC 2771、2000年2月。
[BGMP] Thaler, D., Estrin, D. and D. Meyer, "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Work in Progress.
[BGMP] Thaler、D.、Estrin、D。およびD. Meyer、「Border Gateway Multicast Protocol（BGMP）：プロトコル仕様」、進行中の作業。
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP] Rekhter、Y。およびT. Li、「Border Gateway Protocol 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] Reynolds、J。およびJ. Postel、「割り当てられた番号」、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-Considerations] 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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[KAMPAI] Tsuchiya, P., "Efficient and Flexible Hierarchical Address Assignment", INET92, June 1992, pp. 441--450.
[Kampai] Tsuchiya、P。、「効率的かつ柔軟な階層的アドレスの割り当て」、INET92、1992年6月、pp。441--450。
[MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[Madcap] Hanna、S.、Patel、B。、およびM. Shah、「マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）」、RFC 2730、1999年12月。
[MALLOC] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[Malloc] Thaler、D.、Handley、M。and D. Estrin、「The Internet Multicast Address Arlocation Architecture」、RFC 2908、2000年9月。
[MBGP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, September 1997.
[MBGP] Bates、T.、Chandra、R.、Katz、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] Fenner、W。、およびS. Casner、「IPマルチキャスト用の「Traceroute」施設」が進行中です。
[MZAP] Handley, M, Thaler, D. and R. Kermode "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[MZAP] Handley、M、Thaler、D。およびR. Kermode「マルチキャストスコープゾーンアナウンスアナウンスプロトコル（MZAP）」、RFC 2776、2000年2月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[SCOPE] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[スコープ] Meyer、D。、「管理上スコープIPマルチキャスト」、RFC 2365、1998年7月。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。