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
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.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain group-specific distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist.
本文档描述了可用于域间多播地址集分配的多播地址集声明（MASC）协议。节点（通常是路由器）使用MASC来声明并向该节点的域分配一个或多个地址前缀。虽然域不一定需要为该域中的主机分配地址集才能分配组地址，但向域分配地址集确实可以确保域间特定于组的分发树在本地生根，只有在存在外部接收器的情况下，流量才会发送到域外。
Table of Contents
目录
1 Introduction .................................................. 4
1.1 Terminology ................................................. 4
1.2 Definitions ................................................. 4
2 Requirements for Inter-Domain Address Allocation .............. 5
3 Overall Architecture .......................................... 5
3.1 Claim-Collide vs. Query-Response Rationale .................. 6
4 MASC Topology ................................................. 6
4.1 Managed vs Locally-Allocated Space .......................... 8
4.2 Prefix Lifetime ............................................. 8
4.3 Active vs. Deprecated Prefixes .............................. 9
4.4 Multi-Parent Sibling-to-Sibling and Internal Peering ........ 9
4.5 Administratively-Scoped Address Allocation .................. 9
5 Protocol Details .............................................. 10
5.1 Claiming Space .............................................. 10
5.1.1 Claim Comparison Function ................................. 12
5.2 Renewing an Existing Claim .................................. 12
5.3 Expanding an Existing Prefix ................................ 12
5.4 Releasing Allocated Space ................................... 13
6 Constants ..................................................... 13
7 Message Formats ............................................... 14
7.1 Message Header Format ....................................... 14
7.2 OPEN Message Format ......................................... 15
7.3 UPDATE Message Format ....................................... 17
7.4 KEEPALIVE Message Format .................................... 21
7.5 NOTIFICATION Message Format ................................. 21
8 MASC Error Handling ........................................... 24
8.1 Message Header Error Handling ............................... 24
8.2 OPEN Message Error Handling ................................. 25
8.3 UPDATE Message Error Handling ............................... 26
8.4 Hold Timer Expired Error Handling ........................... 28
8.5 Finite State Machine Error Handling ......................... 28
8.6 NOTIFICATION Message Error Handling ......................... 28
8.7 Cease ....................................................... 29
8.8 Connection Collision Detection .............................. 29
9 MASC Version Negotiation ...................................... 30
10 MASC Finite State Machine .................................... 30
10.1 Open/Close MASC Connection FSM ............................. 31
11 UPDATE Message Processing .................................... 35
11.1 Accept/Reject an UPDATE .................................... 36
11.2 PREFIX_IN_USE Message Processing ........................... 38
11.2.1 PREFIX_IN_USE by PARENT .................................. 38
11.2.2 PREFIX_IN_USE by SIBLING ................................. 38
11.2.3 PREFIX_IN_USE by CHILD ................................... 38
11.2.4 PREFIX_IN_USE by INTERNAL_PEER ........................... 38
11.3 CLAIM_DENIED Message Processing ............................ 39
11.3.1 CLAIM_DENIED by CHILD or SIBLING ......................... 39
1 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
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层协议）被节点（通常是路由器）用于声明一个或多个地址前缀并将其分配到该节点的域。每个前缀都有一个关联的生存期，并且从一个更大的前缀中选择，该前缀的生存期至少与该前缀的生存期一样长，其方式使得前缀是可聚合的。在任何时候，每个MASC节点（MALLOC中的前缀协调器）通常会公布具有不同生存期和作用域的多个前缀，从而允许该域或子MASC域中的多播地址分配服务器（MAA）为其客户端选择适当的地址。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Constants used by this protocol are shown as [NAME_OF_CONSTANT], and summarized in Section 6.
本协议使用的常数显示为[NAME_OF_CONSTANT]，并在第6节中汇总。
This specification uses a number of terms that may not be familiar to the reader. This section defines some of these and refers to other documents for definitions of others.
本规范使用了一些读者可能不熟悉的术语。本节对其中一些进行了定义，并参考了其他文件对其他文件进行了定义。
MAAS (Multicast Address Allocation Server) A host providing multicast address allocation services to end users (e.g. via MADCAP [MADCAP]).
MAAS（多播地址分配服务器）向最终用户提供多播地址分配服务的主机（例如，通过MADCAP[MADCAP]）。
MASC server A node running MASC.
MASC服务器运行MASC的节点。
Peer Other MASC speakers a node directly communicates with.
对等节点直接与之通信的其他MASC扬声器。
Multicast IP Multicast, as defined for IPv4 in [RFC1112] and for IPv6 in [RFC2460].
多播IP多播，如[RFC1112]中IPv4和[RFC2460]中IPv6的定义。
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,
MASC域使用多播地址集声明（MASC）协议声明和分配地址集，以供每个域内的多播地址分配服务器（MAAS）使用。通常，需要自己的多播地址空间的每个域的一个或多个边界路由器将运行MASC。在本文件中，术语“MASC域”指至少有一个节点运行MASC的域；通常，这些域将是自治系统（AS）。MASC节点（代表其域）选择要声明的地址集，
sends a claim to other MASC domains in the network, and waits while listening for any colliding claims. If there is a collision, the losing claimer gives up the colliding claim and claims a different address set.
向网络中的其他MASC域发送声明，并在侦听任何冲突声明时等待。如果发生冲突，则丢失的索赔人放弃冲突索赔，并索赔不同的地址集。
After a sufficiently long collision-free waiting period, the address set chosen by a MASC node is considered allocated to that node's domain. Three things may then happen:
在足够长的无冲突等待期之后，MASC节点选择的地址集被视为分配给该节点的域。然后可能会发生三件事：
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），其中它可以被域间多播路由协议（例如，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) 节点的域可以为自己分配一个子前缀，该子前缀可由域内的MAAS使用。
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
MASC使用的域层次结构与域间拓扑的层次结构一致，例如，连接到区域的主干网、连接到大都市提供商的区域网等。与BGP一样，MASC连接在本地配置。作为其他MASC域客户的MASC域将有一个或多个提供程序域作为其父域。例如，作为区域提供商的MASC域将选择一个（或多个）主干提供商域作为其父域。子级配置为其父级MASC域，父级配置为其子级MASC域
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.
子域。在顶部，许多顶级域连接在（稀疏）网格中并共享全局多播地址空间。为了提高稳健性，可以将同一父域的一对子域配置为关于该父域的同级。
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有三个子项C5、C6、C7，分别包含（C5a、C5b、C5c）、（C6a、C6b）和（C7a）。
T1a-----------T2a
| |
| |
| |
P3a====P3b P4a====P4b
| | / | / | \
| | _______/ | / | \
| | / | / | \______
| | / | / | \
C5a====C5b C6a====C6b----------C7a
\\ //
\\//
C5c
T1a-----------T2a
| |
| |
| |
P3a====P3b P4a====P4b
| | / | / | \
| | _______/ | / | \
| | / | / | \______
| | / | / | \
C5a====C5b C6a====C6b----------C7a
\\ //
\\//
C5c
Figure 1: Example MASC Topology
图1：MASC拓扑示例
All MASC communications use TCP. Each MASC node is connected to and communicates directly with other MASC nodes. The local node acts in exactly one of the following four roles with respect to each remote note:
所有MASC通信都使用TCP。每个MASC节点都与其他MASC节点连接并直接通信。对于每个远程便笺，本地节点只扮演以下四个角色中的一个：
INTERNAL_PEER The local and remote nodes are both in the same MASC domain. For example, P4b is an INTERNAL_PEER of P4a.
内部对等本地和远程节点都位于同一MASC域中。例如，P4b是P4a的内部_对等点。
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.
父提供者关系存在，远程节点可以通过该关系从本地节点获取地址空间。例如，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是C7a与其共同父P4会话中的兄弟姐妹。
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成功声明的所有地址空间。另一方面，“本地分配”空间包括域内MAAS可能使用的所有地址空间。因此，本地分配的空间是托管空间的子集，并且是指域为其自身使用而分配的部分。
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.
对于叶域（没有子域的域），这两个集合是相同的，因为所有声明的空间都分配给本地使用。另一方面，父域“管理”它通过MASC声明的所有地址空间，而子前缀可以分配给它自己和它的子域。
Each prefix has an associated lifetime. If a domain wants to use a prefix longer than its lifetime, that domain must "renew" the prefix BEFORE its lifetime expires (see Section 5.2). If the lifetime cannot be extended, then the domain should either retry later to extend, or should choose and claim another prefix.
每个前缀都有一个相关的生存期。如果域希望使用比其生存期更长的前缀，则该域必须在其生存期到期之前“续订”前缀（参见第5.2节）。如果无法延长生存期，则域应该稍后重试以延长，或者选择并声明另一个前缀。
After a prefix's lifetime expires, MASC nodes in the domain that own that prefix must stop using that prefix. The corresponding entry from the G-RIB database must be removed, and all information associated with the expired prefix may be deleted from the MASC node's local memory.
前缀的生存期到期后，域中拥有该前缀的MASC节点必须停止使用该前缀。必须删除G-RIB数据库中的相应条目，并且可以从MASC节点的本地内存中删除与过期前缀相关的所有信息。
Each prefix advertised by a parent to its children can be either "active" or "deprecated". A "deprecated" prefix is a prefix that the parent wishes to discontinue to use after its lifetime expires. The "active" prefixes only are candidates for size expansion or lifetime extension. Usually, this information will be used by a child as a hint to know which of the parent's prefixes might have their lifetime extended.
父级向其子级播发的每个前缀可以是“活动”或“不推荐”。“弃用”前缀是父级希望在其生存期到期后停止使用的前缀。“活动”前缀仅适用于扩展大小或延长寿命。通常，该信息将被子级用作提示，以了解哪些父级前缀的生存期可能会延长。
Two sibling nodes that have more than one common parent will create and use between them a number of transport-level connections, one per each common parent. The information associated with a parent will be sent over the connection that corresponds to the same parent. Internal peers do not need to open multiple connections between them; a single connection is used for all information.
具有多个公共父节点的两个同级节点将在它们之间创建并使用多个传输级连接，每个公共父节点一个。与父级关联的信息将通过与同一父级对应的连接发送。内部对等点不需要在它们之间打开多个连接；单个连接用于所有信息。
MASC can also be used for sub-allocating prefixes of addresses within an administrative scope zone [SCOPE], but only if the scope is "divisible" (as described in [MALLOC] and [MZAP]). A MASC node can learn what scopes it resides within by listening to MZAP [MZAP] messages.
MASC还可用于在管理范围区域[scope]内分配地址前缀，但前提是该范围是“可分割的”（如[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”是在范围区域内没有父域的域。区域TLD充当与作用域关联的前缀的TLD。图2给出了一个示例，图1中添加了域P3和C5周围的范围边界。域P3是一个分区TLD，因为它的唯一父级（T1）在边界之外。因此，P3可以直接从与作用域本身相关联的前缀中声明空间。另一方面，域C5在范围内有一个父域（即P3），因此不是区域TLD。
T1a-----------T2a
| |
............|....... |
. | . |
. P3a====P3b . P4a
. | | . /
. | | _______/
. | | / .
. | | / .
. C5a====C5b .
. \\ // .
. \\// .
. C5c .
. .
. Admin Scope Zone .
....................
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节点可以向父MASC域发起声明，当且仅当其当前与该父域中的至少一个节点建立了连接时。
After the prefix address and size are decided, the claim proceeds as follows:
在确定前缀地址和大小后，索赔进行如下：
a) The claim is scheduled to be sent after a random delay in the interval (0, [INITIATE_CLAIM_DELAY]). If a claim originated by a node from the same MASC domain is received, and that claim eliminates the need for the local claim, the local claim is canceled and no further action is taken.
a) 索赔计划在间隔（0，[INITIATE_claim_delay]）的随机延迟后发送。如果接收到来自同一MASC域的节点发起的声明，并且该声明消除了对本地声明的需要，则本地声明将被取消，并且不会采取进一步的操作。
b) The claim is sent to one of the parents (if the domain is not a top-level domain), all known siblings with the same parent, and all internal peers. A Claim-Timer is then started at [WAITING_PERIOD], and the MASC node starts listening for colliding claims.
b) 声明将发送到父级之一（如果域不是顶级域）、具有相同父级的所有已知同级以及所有内部对等方。然后在[WAITING_PERIOD]启动索赔计时器，MASC节点开始侦听冲突索赔。
c) If a colliding claim is received while the Claim-Timer is running, that claim is compared with the locally initiated claim using the function described in Section 5.1.1. If the local claim is the loser, a new prefix must be chosen to claim, and the loser claim's Claim-Timer must be canceled. The loser claim can be either explicitly withdrawn, or can be left to expire without taking further actions. If the winning claim was originated by a node from the same MASC domain, no new claim will be initiated. If the local claim is the winner, no actions need to be taken.
c) 如果在索赔计时器运行时收到碰撞索赔，则使用第5.1.1节中描述的功能将该索赔与本地启动的索赔进行比较。如果本地索赔是失败者，则必须选择新的前缀进行索赔，并且必须取消失败者索赔的索赔计时器。输家索赔可以明确撤回，也可以在不采取进一步行动的情况下到期。如果获胜声明由来自同一MASC域的节点发起，则不会发起新声明。如果本地索赔是赢家，则无需采取任何行动。
d) If the Claim-Timer expires, the claimed prefix becomes associated with the claimer's domain, i.e. it is considered allocated to that domain and the following actions can be performed:
d) 如果索赔计时器过期，则索赔前缀将与索赔人的域相关联，即，它被视为已分配给该域，并且可以执行以下操作：
o Advertise the prefix to its parent, and to all siblings with the same parent, by sending a PREFIX_IN_USE claim to them.
o 通过向其父级和具有相同父级的所有同级发送前缀“IN_IN_USE”声明，将前缀播发给它们。
o Inject the prefix into the G-RIB of the inter-domain routing protocol.
o 将前缀注入域间路由协议的G-RIB。
o Send a PREFIX_MANAGED message to all children and internal peers, informing them that they may issue claims within the managed space. A sub-prefix may then be claimed for local usage (see Section 12.2).
o 向所有子级和内部对等方发送PREFIX_托管消息，通知他们可能在托管空间内发出声明。然后可要求使用子前缀以供本地使用（见第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 “类型”，是以下类型之一：使用中的前缀、拒绝的声明、扩展的声明或新声明（管理的前缀和撤消的声明不被视为必须进行比较的声明）
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:
比较两项权利要求时，首先根据以下优先顺序比较类型：
PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_CLAIM
PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_CLAIM
If the type is the same, then the timestamps are used to compare the claims. In practice, two claims will have the same type if the type is either NEW_CLAIM (ordinary collision) or PREFIX_IN_USE (signal for a clash). When the timestamps are compared, the claim with the smallest, i.e. earliest timestamp wins. If the timestamps are the same, then the claim with the smallest Origin Node Identifier wins.
如果类型相同，则使用时间戳来比较声明。实际上，如果两个声明的类型是NEW_CLAIM（普通碰撞）或PREFIX_In_USE（碰撞信号），则两个声明将具有相同的类型。当比较时间戳时，具有最小时间戳（即最早时间戳）的声明获胜。如果时间戳相同，则具有最小原始节点标识符的声明获胜。
The procedure for extending the lifetime of prefixes already in use is the same as claiming new space (see Section 5.1), except that the claim type must be CLAIM_TO_EXPAND, while the Address and the Mask of the claim (see Section 7.3) must be the same as the already allocated prefix. If the Claim-Timer expires and there is no collision, the desired lifetime is assumed.
延长已使用前缀的生存期的过程与声明新空间的过程相同（参见第5.1节），不同之处在于声明类型必须为claim_TO_EXPAND，而声明的地址和掩码（参见第7.3节）必须与已分配的前缀相同。如果索赔计时器过期且没有冲突，则假定所需的生存期。
The procedure for extending the lifetime of prefixes already in use is the same as claiming new space (see Section 5.1), except that the claim type must be CLAIM_TO_EXPAND, while the Address and the Mask of the claim (see Section 7.3) must be set to the desired values. If the Claim-Timer expires and there is no collision, the desired larger prefix is associated with the local domain.
延长已使用前缀的生存期的过程与声明新空间的过程相同（参见第5.1节），不同之处在于声明类型必须为claim_TO_EXPAND，而声明的地址和掩码（参见第7.3节）必须设置为所需的值。如果声明计时器过期且没有冲突，则所需的较大前缀将与本地域相关联。
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.
[港口编号]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).
[WAITING_PERIOD]在新_声明（或声明_TO_EXPAND）和使用相同前缀的前缀_之间必须经过的时间量（秒）。这必须足够长，以合理跨越任何单个域间网络分区。默认值：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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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无符号整数表示消息的类型代码。定义了以下类型代码：
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标头外，OPEN消息还包含以下字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |R| AddrFam |Rol| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MASC Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent's Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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无符号整数表示消息的协议版本号。当前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)
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=内部对等（从一个内部对等发送到另一个）01=子（从子级发送到其父级）10=同级（从一个同级发送到另一个）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扬声器必须使用其为该对等方配置的保持时间和打开消息中接收到的保持时间中的较小者来计算保持计时器的值。保持时间必须为零或至少三秒。实现可以基于保持时间拒绝连接。计算出的值表示发送方收到连续的KEEPALIVE和/或UPDATE消息之间可能经过的最大秒数。建议值为[HOLDTIME]秒。
Sender Domain Identifier: A globally unique identifier. Its length is determined based on the Address Family, and should be treated as an unsigned integer (e.g. a 4-octet integer for IPv4, or a 16-octet integer for IPv6), but must be at least 4 octets long. It should be set to the Autonomous System number of the sender, but the network unicast prefix address is also acceptable.
发件人域标识符：全局唯一标识符。其长度根据地址族确定，应视为无符号整数（例如，IPv4为4个八位整数，IPv6为16个八位整数），但长度必须至少为4个八位整数。它应该设置为发送方的自治系统号，但也可以接受网络单播前缀地址。
Sender MASC Node Identifier: This field's length and format are same as the Sender Domain Identifier field, and indicates the MASC Node Identifier of the sender. A given MASC speaker sets the value of its MASC Node Identifier to a globally-unique value assigned to that MASC speaker (e.g., an IPv4 or IPv6 address). The value of the MASC Node Identifier is determined on startup and is the same for every MASC session opened.
发送方MASC节点标识符：该字段的长度和格式与发送方域标识符字段相同，表示发送方的MASC节点标识符。给定的MASC扬声器将其MASC节点标识符的值设置为分配给该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
父域标识符：此字段的长度和格式与发送方域标识符字段相同，并设置为发送方父域的域标识符（例如，父域的自治系统号或网络前缀地址），或者如果发送方是TLD，则设置为[TLD_ID]。仅当Rol为内部对等或同级时使用，否则将忽略。此字段用于确定同级之间的公共父级，将每个同级到同级连接与特定父级关联，以及发现与TLD相关的连接
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，则可以在发送给内部对等节点的打开消息中使用自己的域ID。
Optional Parameters: This field may contain a list of optional parameters, where each parameter is encoded as a <Parameter Length, Parameter Type, Parameter Value> triplet. The combined length of all optional parameters can be derived from the Length field in the message header.
可选参数：此字段可能包含可选参数列表，其中每个参数都编码为<parameter Length，parameter Type，parameter Value>三元组。所有可选参数的组合长度可以从消息头中的长度字段中导出。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Length | Parm. Type | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. 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.
参数长度是一个八位字节字段，包含参数值字段的八位字节长度。参数类型是一个八位字节字段，可以明确标识各个参数。参数值是根据参数类型字段的值解释的可变长度字段。无法识别的可选参数必须以静默方式忽略。
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标头和一个或多个属性，如下所述。更新消息的最小长度为40个八位字节（包括消息头）。
Each attribute is of the form:
每个属性的形式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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无符号整数表示属性的类型代码。定义了以下类型代码：
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=前缀使用中的前缀（源站正在使用前缀）1=声明被拒绝（声明被拒绝（可能被源站的父域拒绝））2=声明被扩展（源站正在尝试扩展现有前缀的大小）3=新声明（源站正在尝试声明新前缀）4=前缀被管理（父站正在通知子站可用空间）5=撤回（origin撤回先前的索赔）
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统称为“索赔”。下面的消息格式描述了声明、前缀_MANAGED和draw的编码。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 |D| AddrFam |Rol| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 |D| AddrFam |Rol| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved1: This 1-octet field is reserved. MUST be set to zero by the sender, and MUST be ignored by the receiver.
Reserved1：此1-octet字段为保留字段。发送方必须将其设置为零，接收方必须忽略。
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位：不推荐使用的前缀位。如果已设置，则表示已弃用播发地址前缀，否则该前缀将处于活动状态（请参阅第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.
Reserved2：此2个八位字节字段为保留字段。发送方必须将其设置为零，接收方必须忽略。
Claim Timestamp: The timestamp of the claim when it was originated. The timestamp is expressed in number of seconds since midnight (0 hour), January 1, 1970, Greenwich.
声明时间戳：声明发起时的时间戳。时间戳以自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].
Claim Holdtime：声明时间戳与应从本地缓存中删除声明的时间之间的时间（以秒为单位）。对于正在使用的前缀_和前缀_管理的索赔，其应等于索赔期限；对于索赔_TO _EXPAND、新索赔和索赔_DENIED，其应等于[等待期]。
Origin Domain Identifier: The domain identifier of the claim originator. Its length and format definition are same as the Sender Domain Identifier (see Section 7.2).
来源域标识符：索赔发起人的域标识符。其长度和格式定义与发送方域标识符相同（参见第7.2节）。
Origin Node Identifier: The MASC Node ID of the claim originator. Its length and format definition are same as the Sender MASC Node Identifier (see Section 7.2).
原始节点标识符：索赔发起人的MASC节点ID。其长度和格式定义与发送方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或UPDATE消息到发送KEEPALIVE消息的时间之间合理的最长时间是保持时间间隔的三分之一。KEEPALIVE消息的发送频率不得超过每秒一次。实现可以根据保持时间间隔调整发送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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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无符号整数提供有关报告错误性质的更具体信息。每个错误代码可能有一个或多个与之关联的错误子代码。如果未定义适当的错误子代码，则错误子代码字段使用零（非特定）值，并且O位必须为零（即连接将关闭）。下面错误描述中使用的符号是：MC=必须关闭连接=O位为零；CC=Can关闭连接=O位可能为零。
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:
打开消息错误子代码：
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-错误的对等MASC节点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）12-非连续掩码（CC）13-无法识别的地址族（MC）14-声明类型错误（CC）15-源域ID错误（CC）16-源节点ID错误（CC）17-声明生存期太短（CC）18-声明生存期太长（CC）19-声明时间戳太旧（CC）20-声明时间戳太新（CC）21-声明前缀大小太小（CC）22-声明前缀大小太大（CC）23-非法源角色错误（CC）24-没有适当的父前缀（CC）25-无适当的子前缀（CC）26-无适当的内部前缀（CC）27-无适当的兄弟前缀（CC）28-索赔保留时间太短（CC）29-索赔保留时间太长（CC）
Hold Timer Expired subcodes (the O-bit is always zero):
保持计时器过期的子代码（O位始终为零）：
0 - Unspecific (MC)
0-非特定（MC）
Finite State Machine Error subcodes:
有限状态机错误子代码：
0 - Unspecific (MC) 1 - Open/Close MASC Connection FSM Error (MC) 2 - Unexpected Message Type FSM Error (MC)
0-非特定（MC）1-打开/关闭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.
如果消息头的长度字段小于4或大于4096，或者如果打开消息的长度小于打开消息的最小长度，或者如果更新消息的长度小于更新消息的最小长度，或者如果保留消息的长度不等于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-octet无符号整数，表示本地支持的最大版本号小于远程MASC节点bid的版本号（如收到的OPEN消息中所示）。
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节点标识符字段不可接受，则错误子代码将设置为错误对等方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.
如果打开消息的保持时间字段不可接受，则必须将错误子代码设置为不可接受的保持时间。实现必须拒绝一秒或两秒的保持时间值。实施可以拒绝任何提议的保持时间。接受保留时间的实现必须使用保留时间的协商值。
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.
如果远程系统的建议角色为内部对等，并且本地系统或远程系统的父域ID为[TLD_ID]，则错误子代码设置为无效的父配置。数据字段必须填写本地系统的所有父域ID。
If the remote system's proposed Role conflicts with its expected role (based on the local system's configured Role), then the Error Subcode is set to Inconsistent Role. The Data field is 1-octet long, and contains the local system's configured Role.
如果远程系统的建议角色与其预期角色冲突（基于本地系统配置的角色），则错误子代码将设置为“不一致的角色”。数据字段的长度为1个八位字节，包含本地系统配置的角色。
If the remote system's Parent Domain ID is unacceptable, then the Error Subcode is set to Bad Parent Domain ID, and the Data field is filled with the erroneous Parent Domain ID. The determination of acceptable Parent Domain ID is outside the scope of this protocol.
如果远程系统的父域ID不可接受，则错误子代码将设置为错误的父域ID，数据字段将填充错误的父域ID。确定可接受的父域ID不在本协议的范围内。
If the remote system is supposed to be a sibling, but it does not have a common parent with the local system (based on the Parent Domain ID information in the OPEN message), the Error Subcode is set to No Common Parent, and the Data field is filled with all Parent Domain IDs of the local MASC domain.
如果远程系统应为同级系统，但它与本地系统没有公共父级（基于打开消息中的父域ID信息），则错误子代码将设置为无公共父级，并且数据字段将填充本地MASC域的所有父域ID。
If the Address Family is unrecognized, then the Error Subcode is set to Unrecognized Address Family.
如果地址族无法识别，则错误子代码将设置为无法识别的地址族。
All errors detected while processing the UPDATE message are indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error. The Data field contains the erroneous UPDATE Message (including the attribute header, but excluding the Message Header), unless stated otherwise.
处理更新消息时检测到的所有错误都通过发送带有错误代码的通知消息UPDATE message Error来指示。错误子代码详细说明了错误的具体性质。除非另有说明，否则数据字段包含错误的更新消息（包括属性头，但不包括消息头）。
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 Claim Role Type
来源声明角色类型
ICS PREFIX_IN_USE (0) I P CLAIM_DENIED (1) ICS CLAIM_TO_EXPAND (2) ICS NEW_CLAIM (3) I P PREFIX_MANAGED (4) ICSP WITHDRAW (5)
ICS前缀使用（0）IP声明被拒绝（1）ICS声明要扩展（2）ICS新声明（3）IP前缀管理（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).
如果有理由相信源域ID无效，则错误子代码将设置为源域ID Error。这同样适用于原点节点ID（相应的错误为原点节点ID错误）。
If a node (usually a parent receiving a claim from a child) decides that the Claim Lifetime is too short (for example, less than 172800, i.e. 48 hours), it MAY send an UPDATE Message Error with subcode Claim Lifetime Too Short.
如果节点（通常是从子节点接收声明的父节点）确定声明生存期太短（例如，小于172800，即48小时），则它可能发送子代码声明生存期太短的更新消息错误。
If a node (usually a parent receiving a claim from a child) decides that the Claim Lifetime is too long (for example, more than 15,768,000, i.e. half year), then it MAY send an UPDATE Message Error with subcode Claim Lifetime Too Long. Note that usually a parent MASC node should send first CLAIM_DENIED collision messages with Claim Lifetime field filled with the longest acceptable lifetime. If the child refuses to claim with shorter lifetime, then Claim Lifetime Too Long should be sent.
如果节点（通常是从子节点接收声明的父节点）确定声明生存期过长（例如，超过15768000，即半年），则它可能发送子代码声明生存期过长的更新消息错误。请注意，通常情况下，父MASC节点应发送第一个CLAIM_DENIED冲突消息，CLAIM Lifetime字段中填充了最长的可接受生存期。如果孩子拒绝使用更短的生命周期进行索赔，则应发送生命周期过长的索赔。
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节点应该为子节点的大声明地址范围的某些子范围发送第一个声明\u拒绝冲突消息。如果子级拒绝缩小声明大小，则应发送声明前缀大小过大的声明。
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.
如果节点确定Claim Holdtime太短（例如，仅几秒钟），它可能会发送更新消息错误，子代码Claim Holdtime太短。
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.
如果节点确定Claim Holdtime过长（例如，超过15768000，即半年），则应发送更新消息错误，子代码Claim Holdtime过长。
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和/或UPDATE和/或NOTIFICATION消息，则必须发送带有保持计时器过期错误代码的通知消息，并关闭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
如果节点发送通知消息，且该消息中存在错误，且该消息的O位不为零，则必须发送O位为零、通知错误的错误代码和子代码不特定的通知。此外，数据字段必须包含不稳定通知消息。但是，如果不稳定通知消息的O位为零，则应注意并记录任何错误，例如无法识别的错误代码或错误子代码
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.
本地，并提请远程节点的管理员注意。然而，这样做的方法不在本文件的范围之内。
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节点可以在任何给定时间通过发送带有错误代码STOP的通知消息来选择关闭其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连接，那么这对扬声器之间可能会形成两个并行连接。我们将这种情况称为连接冲突。显然，其中一个连接必须关闭。注意，如果节点是兄弟姐妹，并且这些连接中的每个都与不同的父体相关联，那么我们不认为这种情况是冲突（参见第4.4节）。
Based on the value of the MASC Node Identifier a convention is established for detecting which MASC connection is to be preserved when a connection collision does occur. The convention is to compare the MASC Node Identifiers of the remote nodes involved in the collision and to retain only the connection initiated by the MASC speaker with the higher-valued MASC Node Identifier.
基于MASC节点标识符的值，建立了一种约定，用于在发生连接冲突时检测要保留的MASC连接。约定是比较冲突中涉及的远程节点的MASC节点标识符，并仅保留由MASC说话人启动的连接与较高值的MASC节点标识符。
Upon receipt of an OPEN message, the local system must examine all of its connections that are in the OpenConfirm state. A MASC speaker may also examine connections in an OpenSent state if it knows the MASC Node Identifier of the remote node by means outside of the protocol. If among these connections there is a connection to a remote MASC speaker whose MASC Node Identifier equals the one in the OPEN message, and, in case of a sibling-to-sibling connection, the Parent Domain ID of that connection equals the one in the OPEN message, then the local system performs the following connection collision resolution procedure:
收到打开的消息后，本地系统必须检查所有处于OpenConfirm状态的连接。如果MASC扬声器通过协议之外的方式知道远程节点的MASC节点标识符，则还可以在OpenSent状态下检查连接。如果在这些连接中存在到远程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个八位字节）来比较MASC节点标识符。
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节点标识符的值，则本地系统关闭已存在的MASC连接（已处于OpenConfirm状态的MASC连接），并接受远程系统启动的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连接（由冲突解决过程产生）是通过发送带有错误代码STOP的通知消息来完成的。
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扬声器可以使用它尝试的版本号、远程节点尝试的版本号、通知消息中远程节点传递的版本号以及它支持的版本号。如果两个MASC扬声器确实支持一个或多个通用版本，则这将允许它们快速确定最高通用版本。为了支持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计时器，启动到远程节点的传输连接，同时侦听远程MASC节点可能启动的连接，并将其状态更改为Connect。ConnectRetry计时器的确切值是本地问题，但应该足够大，以允许TCP初始化。
If a MASC speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent MASC errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a node that was previously transitioned to Idle due to an error. For a node that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry, but shall not be longer than 24 hours.
如果MASC扬声器检测到错误，它将关闭连接并将其状态更改为空闲。要摆脱空闲状态，需要生成启动事件。如果这样的事件是自动生成的，那么持续的MASC错误可能会导致说话人的持续拍打。为了避免这种情况，建议不要立即为之前由于错误而转换为空闲的节点生成启动事件。对于之前由于错误而转换为空闲的节点，如果自动生成启动事件，则连续生成启动事件之间的时间应呈指数增长。初始计时器的值应为60秒。每次连续重试的时间应加倍，但不得超过24小时。
Any other event received in the Idle state is ignored.
在空闲状态下接收到的任何其他事件都将被忽略。
Connect state:
连接状态：
In this state MASC is waiting for the transport protocol connection to be completed.
在此状态下，MASC正在等待传输协议连接完成。
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to the remote node, and changes its state to OpenSent. If the transport protocol connect fails (e.g., retransmission timeout), the local system restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote MASC node, and changes its state to Active state.
如果传输协议连接成功，本地系统将清除ConnectRetry计时器，完成初始化，向远程节点发送打开消息，并将其状态更改为OpenSent。如果传输协议连接失败（例如，重传超时），本地系统将重新启动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 timer expired事件，本地系统重新启动ConnectRetry timer，启动到其他MASC节点的传输连接，继续侦听可能由远程MASC节点启动的连接，并保持连接状态。
The Start event is ignored in the Connect state.
在连接状态下忽略启动事件。
In response to any other event (initiated by either system or operator), the local system releases all MASC resources associated with this connection and changes its state to Idle.
为了响应任何其他事件（由系统或操作员启动），本地系统释放与此连接相关的所有MASC资源，并将其状态更改为空闲。
Active state:
活动状态：
In this state MASC is trying to acquire a remote node by listening for a transport protocol connection initiated by the remote node.
在此状态下，MASC试图通过侦听远程节点发起的传输协议连接来获取远程节点。
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to the remote node, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of [HOLDTIME] seconds is suggested.
如果传输协议连接成功，本地系统将清除ConnectRetry计时器，完成初始化，向远程节点发送打开消息，将其保持计时器设置为大值，并将其状态更改为OpenSent。建议保持计时器的值为[HOLDTIME]秒。
In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to other MASC node, continues to listen for a connection that may be initiated by the remote MASC node, and changes its state to Connect.
响应ConnectRetry timer expired事件，本地系统重新启动ConnectRetry timer，启动到其他MASC节点的传输连接，继续侦听可能由远程MASC节点启动的连接，并将其状态更改为Connect。
If the local system detects that a remote node is trying to establish a MASC connection to it, and the IP address of the remote node is not an expected one, the local system restarts the ConnectRetry timer, rejects the attempted connection, continues to listen for a connection that may be initiated by the remote MASC node, and stays in the Active state.
如果本地系统检测到远程节点正试图建立与它的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:
OpenSent状态：
In this state MASC waits for an OPEN message from the remote node. When an OPEN message is received, all fields are checked for correctness. If the MASC message header checking or OPEN message checking detects an error (see Section 8.2), or a connection
在此状态下，MASC等待来自远程节点的打开消息。当收到打开的消息时，将检查所有字段的正确性。如果MASC消息头检查或打开消息检查检测到错误（参见第8.2节）或连接
collision (see Section 8.8) the local system sends a NOTIFICATION message and, if the connection is to be closed, it changes its state to Idle.
冲突（参见第8.8节）本地系统发送一条通知消息，如果要关闭连接，则会将其状态更改为空闲。
If the locally configured role is SIBLING and there is no parent domain with Domain ID equal to the Parent Domain ID in the OPEN message, the local system sends a NOTIFICATION Open Message Error with Error Subcode set to No Common Parent, the connection must be closed, and the state of the local system must be changed to Idle.
如果本地配置的角色是同级角色，并且打开消息中没有域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，则该连接为“INTERNAL”连接；否则，它是“外部的”。最后，状态更改为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的通知消息，并将其状态更改为Idle。
The Start event is ignored in the OpenSent state.
在OpenSent状态下忽略启动事件。
In response to any other event the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and Error Subcode Open/Close MASC Connection FSM Error, and changes its state to Idle.
为了响应任何其他事件，本地系统发送一条带有错误代码“有限状态机错误”和错误子代码“打开/关闭MASC连接FSM错误”的通知消息，并将其状态更改为“空闲”。
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将其状态从OpenSent更改为Idle时，它都会关闭MASC（和传输级别）连接并释放与该连接相关的所有资源。
OpenConfirm state:
OpenConfirm状态：
In this state MASC waits for a KEEPALIVE or NOTIFICATION message.
在此状态下，MASC等待KEEPALIVE或通知消息。
If the local system receives a KEEPALIVE message, it changes its state to Established.
如果本地系统接收到KEEPALIVE消息，它会将其状态更改为“已建立”。
If the Hold Timer expires before a KEEPALIVE message is received, the local system sends a NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
如果在收到KEEPALIVE消息之前保持计时器过期，本地系统将发送一条错误代码为保持计时器过期的通知消息，并将其状态更改为空闲。
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计时器过期，本地系统将发送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的通知消息，并将其状态更改为Idle。
The Start event is ignored in the OpenConfirm state.
在OpenConfirm状态下忽略启动事件。
In response to any other event the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and Error Subcode Unspecific, and changes its state to Idle.
作为对任何其他事件的响应，本地系统发送一条错误代码为有限状态机错误和错误子代码为非特定的通知消息，并将其状态更改为空闲。
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更改为Idle时，它都会关闭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.
如果本地系统接收到设置了O位的更新、KEEPALIVE消息或通知消息，则如果协商的保持时间值为非零，则会重新启动其保持计时器。
If the local system receives a NOTIFICATION message, with the O-bit zeroed, it changes its state to Idle.
如果本地系统接收到通知消息，且O位为零，则会将其状态更改为空闲。
If the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 8.3) detects an error, the local system sends a NOTIFICATION message and, if the O-bit was zeroed, changes its state to Idle.
如果本地系统接收到更新消息，且更新消息错误处理程序（见第8.3节）检测到错误，则本地系统发送通知消息，如果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计时器过期，本地系统将发送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或UPDATE消息时，它都会重新启动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的通知消息，并将其状态更改为Idle。
The Start event is ignored in the Established state.
在已建立状态下忽略启动事件。
After entering the Established state, if the local system has UPDATE messages that are to be sent to the remote node, they must be sent immediately (see Section 11.8).
进入已建立状态后，如果本地系统具有要发送到远程节点的更新消息，则必须立即发送这些消息（参见第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
在下文中，就与具有本地使用目的的地址空间相关的权利要求而言（即，MAAS将在该域内使用），MASC域被视为其自身的子域。对于
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节点发起的新_声明从该域管理的前缀获取更多本地使用空间，其字段Role=CHILD。
If an UPDATE is to be propagated further, it should not be sent back to the node that UPDATE was received from, unless there is an indication that the connection to that node was down and then restored.
如果要进一步传播更新，则不应将其发送回接收更新的节点，除非有迹象表明与该节点的连接已断开，然后已恢复。
If 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.
如果更新消息必须与父域相关联，则必须存在由某个父域管理的前缀_，用于覆盖特定更新前缀的前缀。
The Origin Role field is first compared against the local system's
configured Role, according to Table 1, to determine the relationship
of the origin to the local system, where Locally-Configured Role is
the local configuration with regard to the peer-forwarder of the
message. A result of "---" means that receiving such an UPDATE is
illegal and should generate a NOTIFICATION. Any other result is the
value to use as the "Updated" Origin Role when propagating the UPDATE
to others. This is analogous to updating a metric upon receiving a
route, based on the metric of the link.
The Origin Role field is first compared against the local system's
configured Role, according to Table 1, to determine the relationship
of the origin to the local system, where Locally-Configured Role is
the local configuration with regard to the peer-forwarder of the
message. A result of "---" means that receiving such an UPDATE is
illegal and should generate a NOTIFICATION. Any other result is the
value to use as the "Updated" Origin Role when propagating the UPDATE
to others. This is analogous to updating a metric upon receiving a
route, based on the metric of the link.
Locally-Configured Role
Origin
Role || INTERNAL_PEER | CHILD | SIBLING | PARENT
=========++===============+=========+=========+=========
INTERNAL || INTERNAL_PEER | PARENT | SIBLING | CHILD
CHILD || CHILD | SIBLING | --- | ---
SIBLING || SIBLING | --- | SIBLING | CHILD
PARENT || PARENT | --- | PARENT | ---
Locally-Configured Role
Origin
Role || INTERNAL_PEER | CHILD | SIBLING | PARENT
=========++===============+=========+=========+=========
INTERNAL || INTERNAL_PEER | PARENT | SIBLING | CHILD
CHILD || CHILD | SIBLING | --- | ---
SIBLING || SIBLING | --- | SIBLING | CHILD
PARENT || PARENT | --- | PARENT | ---
Table 1: Updated Origin Role Computation
表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
o 如果更新的源角色计算的输出为同级，但源域ID与本地MASC域相同，则更新的源角色将更改为内部。如果MASC节点从父节点或同级节点接收到自己的更新，这是必要的
after reboot, or if because of internal partitioning, the INTERNAL_PEERs are exchanging UPDATEs via other MASC domains (either parent or sibling(s)).
重新启动后，或者由于内部分区的原因，内部_对等方正在通过其他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 如果本地配置的角色和源角色都等于父角色，并且源域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 如果本地配置的角色和源角色都等于父角色，且源域ID与远程MASC域相同，且更新类型为CLAIM_DENIED，则更新后的源角色将更改为INTERNAL。这是必要的，以允许父母通过其索赔被拒绝的子女接收索赔。如果源域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.
如果更新的源角色是内部的，但源域ID与本地域ID不同，则必须发回<UPDATE Message Error，Invalical Origin Role>的通知，并拒绝索赔。
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.
如果Claim Timestamp和Claim Holdtime指示索赔已过期（例如，Timestamp+Claim 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 阿德法姆
o Claim Timestamp
o 索赔时间戳
o Claim Lifetime
o 索赔期限
o Claim Holdtime
o 索赔保留时间
o Origin Domain Identifier
o 源域标识符
o Origin Node Identifier
o 源节点标识符
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.
声明被拒绝，并应发回<UPDATE Message Error，Invalical Origin Role>的通知。
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.
如果声明无法与任何父级的前缀\u管理关联，则声明将被删除，必须发回<UPDATE Message Error，No property parent PREFIX>的通知，并且不应采取进一步的操作。
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.
如果声明与本地域的某些未决声明冲突，则不能进一步考虑本地声明，并且必须取消每个声明的声明计时器。如果收到的前缀_IN_USE claim与本地域的某些已分配前缀冲突并赢得该前缀，请根据第12.4节解决冲突。最后，该声明必须进一步传播到所有内部_对等方、来自相应父MASC域的所有MASC节点以及具有相同父域的所有已知兄弟节点。
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.
如果声明的前缀不是任何本地域的前缀\u管理的子范围，则声明将被丢弃，必须发回<UPDATE Message Error，No Applied Parent prefix>的通知，并且不应采取进一步的操作。否则，必须将声明进一步传播到所有内部_对等点和所有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节点决定本地域不再需要该前缀，则可以将其撤回，否则，将声明作为前缀处理。
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
该消息被拒绝，并且应发回<UPDATE message Error，Invalical Origin Role>的通知。
Propagate to all INTERNAL_PEERs and all MASC children nodes.
传播到所有内部_对等节点和所有MASC子节点。
If the Origin Domain ID is not same as the local domain ID, and the UPDATE cannot be associated with any parent domain, the message is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further actions should be taken.
如果源域ID与本地域ID不同，并且更新无法与任何父域关联，则会删除消息，必须发回<UPDATE message Error，No property parent Prefix>通知，并且不应采取进一步的操作。
If the Origin Domain ID is not same as the local domain ID, and the UPDATE can be associated with a parent domain, the message is propagated to all nodes from that parent domain, all INTERNAL_PEERs, and all known SIBLINGs with regard to that parent.
如果源域ID与本地域ID不同，并且更新可以与父域关联，则消息将传播到来自该父域的所有节点、所有内部_对等节点以及与该父域相关的所有已知同级节点。
If the Origin Domain ID is same as the local domain ID, and there is no corresponding pending claim originated by the local MASC domain (i.e. a NEW_CLAIM or CLAIM_TO_EXPAND with same AddrFam, Origin Domain ID, Claim Timestamp, Address and Mask), a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back and no further actions should be taken. Otherwise, the matching NEW_CLAIM or CLAIM_TO_EXPAND's Claim-Timer must be canceled and the claim must not be considered further. Finally, the received CLAIM_DENIED must be propagated to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain, and all known SIBLINGs with regard to that parent.
如果源域ID与本地域ID相同，并且本地MASC域没有发起相应的未决声明（即新的\u声明或使用相同的AddrFam、源域ID、声明时间戳、地址和掩码扩展的\u声明），则发出<更新消息错误，不必发回适当的内部前缀>，也不应采取进一步的操作。否则，必须取消匹配的新索赔或索赔到索赔扩展的索赔计时器，并且不得进一步考虑索赔。最后，接收到的CLAIM_DENIED必须传播到所有内部_对等方、来自相应父MASC域的所有MASC节点以及与该父节点相关的所有已知兄弟节点。
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
声明被拒绝，并应发回<UPDATE Message Error，Invalical Origin Role>的通知。
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.
如果声明无法与任何父级的前缀\u管理关联，则声明将被删除，必须发回<UPDATE Message Error，No property parent PREFIX>的通知，并且不应采取进一步的操作。
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域使用的\u中没有重叠的前缀\u，则声明将被放弃，必须发回<UPDATE Message Error，no property Sibling PREFIX>的通知，并且不应采取进一步的操作。
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.
如果声明无法与任何本地域的前缀\u管理相关联，则声明将被删除，必须发回<UPDATE Message Error，No property Parent PREFIX>的通知，并且不应采取进一步的操作。
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域使用的\u中没有重叠的前缀\u，则声明将被放弃，必须发回<UPDATE Message Error，no Adjust Child PREFIX>的通知，并且不应采取进一步的操作。
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.
否则，必须将声明传播到所有内部_对等方。如果声明的生存期长于本地域管理的相应前缀的生存期，或者如果存在管理配置的原因阻止子级成功分配声明的前缀，必须将声明_DENIED发送到所有MASC子节点，这些子节点的域ID与接收到的消息中的源域ID相同。被拒绝的索赔必须与收到的索赔相同，除了Rol=INTERNAL，并且索赔期限应设置为允许的最大期限。否则，也将该声明传播给所有儿童。
If the claim cannot be associated with any parent's PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back and no further action should be taken.
如果声明无法与任何父级的前缀\u管理关联，则声明将被删除，必须发回<更新消息错误，没有适当的父级前缀>的通知，并且不应采取进一步的操作。
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域使用的\u中没有重叠的前缀\u，则声明将被放弃，必须发回<UPDATE Message Error，no Adjust Internal PREFIX>的通知，并且不应采取进一步的操作。
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域传播到所有内部_对等方和所有MASC节点。
If the claim's Address field is 0 (i.e. a hint by a child to a parent to obtain more space), the claim should be propagated only among the nodes that belong to the child Origin Domain and the parent domain.
如果声明的地址字段为0（即子级向父级发出的获取更多空间的提示），则声明应仅在属于子源域和父域的节点之间传播。
Otherwise, process like CLAIM_TO_EXPAND, except that no check for overlapping PREFIX_IN_USE needs to be performed.
否则，像CLAIM_TO_这样的过程将展开，但不需要检查使用中的重叠前缀_。
11.6. PREFIX_MANAGED Message Processing.
11.6. 前缀\u管理的消息处理。
If the Origin Domain ID matches one of the parents' domain ID's, the prefix is recorded, and can be used by the address allocation algorithm for allocating subranges. Also, the message is propagated to all MASC nodes of the corresponding parent domain, all INTERNAL_PEERs, and SIBLINGs with same parent.
如果源域ID与父域ID之一匹配，则会记录前缀，并可由地址分配算法用于分配子范围。此外，消息会传播到相应父域的所有MASC节点、所有内部_对等节点以及具有相同父域的同级节点。
The message is rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back.
该消息被拒绝，并且应发回<UPDATE message Error，Invalical Origin Role>的通知。
The prefix is recorded as allocated to the local domain, propagated to all INTERNAL_PEERs, and can be used for (all items apply):
前缀被记录为分配给本地域，传播到所有内部_对等方，并可用于（所有项目均适用）：
a) address ranges/prefixes advertisements to all MASC children and local domain's MAASs;
a) 所有MASC子级和本地域的MAAS的地址范围/前缀广告；
b) injection into G-RIB;
b) G肋注射；
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.
如果撤回不能与任何子域使用的前缀相关联（即，没有子域使用的前缀涵盖撤回的范围），或者如果撤回与子域的任何新声明或声明不匹配（即没有具有相同地址、掩码和时间戳的子域声明），则丢弃消息，必须发回<更新消息错误，无适当的子前缀>的通知，并且不应采取进一步的操作。否则，传播给所有内部同龄人和儿童。
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.
如果撤回不能与使用中的任何兄弟姐妹前缀相关联（即，使用中的兄弟姐妹前缀不包括撤回的范围），或者撤回不匹配任何兄弟姐妹域的新声明或声明扩展（即没有具有相同地址、掩码和时间戳的兄弟姐妹声明），则消息被丢弃，必须发回<更新消息错误，没有适当的同级前缀>的通知，并且不应采取进一步的操作。否则，将传播到所有内部_对等节点、来自同一父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.
如果撤回不能与任何本地域正在使用的前缀或管理的前缀相关联（即，没有本地域的前缀覆盖撤回的范围），或者如果撤回与任何本地域的新声明或声明不匹配（即没有具有相同地址、掩码和时间戳的本地域声明），消息将被丢弃，必须发回<UPDATE Message Error，无适当的内部前缀>的通知，并且不应采取进一步的操作。
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
否则，传播到所有内部_对等节点、该前缀对应父域的所有MASC节点、该父域的所有已知同级节点以及所有子节点。如果撤销可以与某些本地域正在使用的前缀或管理的前缀相关联，则停止向MAASs公布撤销范围，并从G-RIB数据库中撤销该范围。在特殊情况下，如果有迹象表明撤回是由本地域由于冲突而发起的，并且在撤回中指定的范围是本地前缀_的子范围，并且撤回的索赔保持时间短于
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.
前缀_管理，退出的范围不应从G-RIB中退出。如果撤回与本地域的新\u声明或要扩展的声明\u匹配，请取消匹配声明的声明计时器。
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.
如果撤回不能与任何父域关联，则必须发回<UPDATE Message Error，No property parent Prefix>通知，并且不应采取进一步的操作。
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.
否则，将传播到所有内部_对等点和具有相同父域的所有已知同级。此外，为本地拥有的前缀_MANAGED/PREFIX _IN _USE和接收到的撤销的每个交叉点生成撤销消息。本地生成的撤回消息的索赔保持时间应至少等于从父级接收的撤回消息中的索赔保持时间；源节点ID应与所使用的特定前缀\u管理/前缀\u相同。
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 使用中的前缀\u必须始终在声明\u之前发送给\u扩展、新建\u声明，并由同一MASC域撤回
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、CLAIM_TO_EXPAND、NEW_CLAIM和由同一MASC域管理的前缀_之后发送
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) 父项的前缀_已管理并撤消。
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、CLAIM_TO_EXPAND和NEW_CLAIMs。不应传播来自第三方子级的声明，这些声明暗示需要更多空间（即地址=0）；如果已传播，则子级应删除它们。
3) Parent initiated CLAIM_DENIED and children initiated WITHDRAWs. CLAIM_DENIED regarding third party children's claims/hints with address = 0 should not be propagated; if propagated, the child should drop them.
3) 家长发起的索赔被拒绝，孩子发起的撤回。关于地址为0的第三方子级声明/提示的声明被拒绝，不应传播；如果已传播，则子级应删除它们。
Messages are sent in the following order:
消息按以下顺序发送：
1) Parent's PREFIX_MANAGED and WITHDRAWs.
1) 父项的前缀_已管理并撤消。
2) All PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMSs from that parent's space, initiated by that child and all its siblings.
2) 使用中的所有前缀、扩展的声明以及来自父空间的新声明，均由该子级及其所有兄弟级发起。
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) 父级的已启动声明被拒绝，并且所有可与该父级的空间关联并由本地域或该父级的所有已知同级启动的撤消。
Messages are sent in the following order:
消息按以下顺序发送：
1) All common parent's PREFIX_MANAGED and WITHDRAWs.
1) 所有公共父项的前缀_均已管理和撤消。
2) PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs, initiated by siblings.
2) 前缀_IN_USE，CLAIM_TO_EXPAND，以及新的_CLAIMs，由兄弟姐妹发起。
3) CLAIM_DENIEDs initiated by common parent, and WITHDRAWs initiated by local domain and all known siblings with that parent.
3) CLAIM_拒绝由公共父级发起的请求，并撤回由本地域和该父级的所有已知同级发起的请求。
Messages are sent in the following order:
消息按以下顺序发送：
1) All parents' PREFIX_MANAGED and WITHDRAWs.
1) 所有家长的前缀都已管理并退出。
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) 本地域和所有同级的前缀\u在\u中使用、声明\u到\u扩展以及新声明。不应传播来自兄弟姐妹的关于更多空间（即地址=0）的提示的声明；如果已传播，则收件人应删除它们。
3) CLAIM_DENIEDs initiated by all parents, and WITHDRAWs initiated by local domain and all known siblings.
3) CLAIM_拒绝由所有父项发起，并撤回由本地域和所有已知兄弟项发起。
4) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
4) 所有子项的前缀_IN_USE、CLAIM_TO_EXPAND和NEW_CLAIMs。
5) All local domain initiated CLAIM_DENIED regarding children claims and all children initiated WITHDRAWs.
5) 所有本地域发起的与子项索赔相关的索赔被拒绝，所有子项发起的撤回。
To learn about its parent domains' IDs and prefixes, a MASC node SHOULD try to establish connections to its PARENT nodes before initiating a connection to a SIBLING node. To avoid learning about its own PREFIX_MANAGED from its children or siblings, a MASC node SHOULD try to establish connections to its PARENT nodes and INTERNAL_PEER nodes before initiating a connection to a CHILD or SIBLING node.
要了解其父域的ID和前缀，MASC节点应在启动到同级节点的连接之前尝试建立到其父节点的连接。为了避免从其子节点或同级节点了解其自己管理的前缀_，MASC节点应在启动到子节点或同级节点的连接之前，尝试建立到其父节点和内部_对等节点的连接。
A non-leaf MASC domain (i.e. a domain that has children domains) should advertise its PREFIX_MANAGED addresses to its children, and should claim from that space the sub-ranges that would be advertised to the internal MAASs (the claim wait time SHOULD be equal to [WAITING_PERIOD]). A MASC node that belongs to a non-leaf MASC domain should perform dual functions by being a child of itself with regard to the claiming and management of the sub-ranges for local usage. A leaf MASC domain should advertise all PREFIX_MANAGED addresses to its MAASs without explicitly claiming them for internal usage. A MASC node can assume that it belongs to a leaf domain if it simply does not have any UPDATEs by children domains. If an UPDATE by a child is received, the domain MUST switch from "leaf" to "non-leaf" mode, and if it needs more addresses for internal usage, it MUST claim them from that domain's PREFIX_MANAGED. After the last UPDATE originated by a child expires, the domain can switch back to "leaf" mode.
非叶MASC域（即具有子域的域）应将其前缀_管理的地址通告给其子域，并应从该空间声明将通告给内部MAAS的子范围（声明等待时间应等于[WAITING_PERIOD]）。属于非叶MASC域的MASC节点应通过作为自身的子节点来执行双重功能，以声明和管理本地使用的子范围。叶MASC域应向其MAAS公布所有前缀_管理的地址，而无需明确声明这些地址供内部使用。如果MASC节点没有子域的任何更新，则可以假定它属于叶域。如果接收到子级的更新，域必须从“叶”模式切换到“非叶”模式，如果需要更多地址供内部使用，则必须从该域的前缀_MANAGED中声明这些地址。在子级发起的上次更新过期后，域可以切换回“叶”模式。
Each UPDATE has "Claim Timestamp" field that is set to the absolute time of the MASC node that originated that UPDATE. The timestamp is used for two purposes: to resolve collisions, and to define how long an UPDATE should be kept in the local cache of other MASC nodes. A skew in the clock could result in unfair collision decision such that the claims originated by nodes that have their clock behind the real time will always win; however, because collisions are presumably rare, this will not be an issue. Skew in the clock however might result in expiring an UPDATE earlier than it really should be expired, and a node might assume too early that the expired UPDATE/prefix is free for allocation. To compensate for the clock skew, an UPDATE message should be kept longer than the amount of time specified in the Claim Holdtime. For example, keeping UPDATEs for an additional 24 hours will compensate for clock skew for up to 24 hours.
每个更新都有“Claim Timestamp”字段，该字段设置为发起该更新的MASC节点的绝对时间。时间戳用于两个目的：解决冲突，以及定义更新应在其他MASC节点的本地缓存中保留多长时间。时钟的偏差可能导致不公平的冲突决策，这样，由时钟落后于实时的节点发起的声明将始终获胜；然而，由于碰撞可能很罕见，这将不是一个问题。然而，时钟中的偏差可能导致更新到期时间早于实际到期时间，并且节点可能过早地认为过期的更新/前缀可以自由分配。为了补偿时钟偏移，更新消息的保留时间应长于Claim Holdtime中指定的时间量。例如，将更新保留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节点接收到由同级节点发起的前缀\u IN_USE声明，并且该声明与某些本地前缀重叠，则必须解决冲突。两个MASC域不应管理重叠的地址范围，除非域在MASC层次结构中具有祖先-后代（例如父子）关系。此外，两个MASC域不应具有本地分配的重叠地址范围。冲突的地址范围不应通告给MAAS，并分配给多播应用程序/会话。如果为应用程序分配了冲突的地址，则应通知应用程序停止使用该地址并切换到新地址。
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中，撤销消息用于解决此问题。当接收到冲突前缀_IN_USE时，将其与分配给本地域的所有前缀进行比较（使用第5.1.1节中描述的函数）。如果使用的本地前缀\u是赢家，则不会采取进一步的操作。如果所使用的本地前缀_是失败者，则必须通过启动撤销消息撤销冲突地址范围。消息必须具有Role=INTERNAL，源节点ID和源域ID必须与\u USE消息中相应的本地前缀\u相同，而声明时间戳、声明生存期、声明保持时间、地址和掩码必须与\u USE中接收到的获胜前缀\u相同。必须按照第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域拥有重叠前缀\u MANAGED或PREFIX\u IN\u USE，则重叠前缀范围可以注入回G-RIB数据库。类似地，由于撤销而未向本地域的MAAS播发的地址范围现在可以再次播发。
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传播客户的旧前缀。但是，客户域中至少有一个MASC节点必须与旧网络提供商的一个MASC节点保持TCP连接。因此，它可以继续“保护”客户的前缀，并且应该持续到旧前缀的生存期到期。
If the new network provider is not willing to propagate the old prefixes, then the customer should remove its prefixes from the G-RIB. If BGMP is in use, the old network provider's domain will automatically become the Root Domain for the customer's old groups due to the lack of a more specific group route. MASC nodes in the customer domain MAY still connect with the old provider's MASC nodes to defend their allocation.
如果新的网络供应商不愿意传播旧的前缀，则客户应将其前缀从G-RIB中移除。如果使用BGMP，由于缺少更具体的组路由，旧网络提供商的域将自动成为客户旧组的根域。客户域中的MASC节点仍可与旧提供商的MASC节点连接，以保护其分配。
Use mtrace [MTRACE] to find the BGMP/MASC root domain for a group address chosen from that prefix.
使用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域中的一个MASC服务器，通过观察父级、同级或子级MASC域中的状态，或通过观察该域产生的G-RIB信息，找到分配给该域的地址空间。从这三种方法中，第一种方法可以提供最详细的信息。在特定域中查找一个MASC节点的地址超出了MASC的范围。
In general, MASC will be run by a border routers, which, in general do not have stable storage. In this case, MASC must use the Layer 2 protocol/mechanism (e.g., ([AAP]) as described in [MALLOC] to store the important information (the prefixes allocated by the local domain) in the domain's MAASs who should have stable storage. If the
一般来说，MASC将由边界路由器运行，而边界路由器通常没有稳定的存储。在这种情况下，MASC必须使用第2层协议/机制（例如，（[AAP]），如[MALLOC]中所述，将重要信息（由本地域分配的前缀）存储在域的MAAS中，该MAAS应具有稳定的存储。如果
MASC speaker has local storage, it should use it instead of the Layer 2 protocol/mechanism. Claims that are in progress do not have to be saved by using the Layer 2 protocol/mechanism.
MASC扬声器具有本地存储，应使用本地存储，而不是第2层协议/机制。不必使用第2层协议/机制保存正在进行的声明。
IPsec [IPSEC] can be used to address security concerns between two MASC peering nodes. However, because of the store-and-forward nature of the UPDATE messages, it is possible that if a non-trustworthy MASC node can connect to some point of the MASC topology, then this node can undetectably inject malicious UPDATEs that may disturb the normal operation of other MASC nodes. To address this problem, each MASC node should allow peering only with trustworthy nodes.
IPsec[IPsec]可用于解决两个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节点只有通过内部对等方才接受子更新，则可以防止使用多个源地址的拒绝服务攻击，或者直接来自与源节点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打开消息可选参数类型、MASC更新消息属性类型、MASC更新消息可选参数类型以及MASC通知消息错误代码和子代码）。对于所有这些数字空间，本规范中定义了某些值。新值只能由IETF共识定义，如[IANA-注意事项]所述。基本上，这意味着它们由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域）用于满足多播地址需求的算法。分配的地址应是可聚合的，地址利用率应相当高，MAAS的分配延迟应尽可能短于[WAITING_PERIOD]。
For ease of implementation and troubleshooting, MASC should use contiguous masks to specify the address ranges, i.e. prefixes. (Research indicates that sufficiently good results can be achieved using contiguous masks only.) The chosen prefixes should be as expandable as possible. The method used to choose the children sub-prefixes from the parent's prefix is the so called Reverse Bit Ordering (idea by Dave Thaler; inspired by Kampai [KAMPAI]). For example, if the parent's prefix width is four bits, the addresses of the sub-prefixes are chosen in the following order:
为便于实现和故障排除，MASC应使用连续掩码来指定地址范围，即前缀。（研究表明，仅使用连续掩码可以获得足够好的结果。）所选前缀应尽可能可扩展。用于从父前缀中选择子子前缀的方法是所谓的反向位排序（由Dave Thaler提出，灵感来自Kampai[Kampai]）。例如，如果父前缀宽度为四位，则子前缀的地址按以下顺序选择：
Parent: xxxx
家长：xxxx
Child A: 0000 Child B: 1000 Child C: 0100 Child D: 1100
儿童A:0000儿童B:1000儿童C:0100儿童D:1100
If some of the children need to expand their sub-prefix, they try to double the corresponding sub-prefix starting from the right:
如果某些子级需要扩展其子前缀，则它们会尝试从右侧开始将相应的子前缀加倍：
Child A: 000x Child A: 00xx Child D: 110x Child D: 11xx
子A:000x子A:00xx子D:110x子D:11xx
and so on.
等等
However, because the address ordering is very strict, to reduce the probability for collision, when a new sub-prefix has to be chosen, the choice should be random among all candidates with the same potential for expandability. For example, if the free sub-prefixes are 01xx, 10xx, 110x, then the new prefix to claim should be chosen with probability of 50% for 01xx and 50% for 10xx for example.
然而，由于地址顺序非常严格，为了降低冲突概率，当必须选择新的子前缀时，在具有相同扩展潜力的所有候选中，选择应该是随机的。例如，如果自由子前缀是01xx、10xx、110x，那么选择要声明的新前缀的概率应该是01xx的50%，10xx的50%。
To reduce the allocation latency, a MASC node uses pre-allocation. It constantly monitors the demand for addresses from its children (or MAASs), and predicts what would be the address usage after [WAITING_PERIOD]. Only if the available addresses will be used up within [WAITING_PERIOD], a MASC node claims more addresses in advance.
为了减少分配延迟，MASC节点使用预分配。它不断监控其子代（或MAAS）对地址的需求，并预测[等待期]后的地址使用情况。只有当可用地址在[等待时间]内用完时，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节点一次可以分配多个前缀（通常，每个前缀的大小不同）。通过使用预分配和分配几个不同大小的前缀（见下文），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节点仔细选择要声明的前缀。第一个前缀是在所有可合理扩展的候选中随机选择的。如果一个节点选择分配另一个较小的前缀，那么就选择第二个“邻居”前缀，而不是将可能显著降低地址利用率的第一个前缀的大小增加一倍。例如，如果已经分配了前缀224.0/16，并且MASC域还需要256个地址，那么要声明的第二个前缀将是224.1.0/24。如果域需要更多地址，第二个前缀最终将增长到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域最多有三个前缀是一个合理的阈值，这样地址利用率可以在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节点会在其生存期到期后隐式返回未使用的前缀，或重新声明一些较小的子前缀。例如，如果MAASs和/或子MASC域使用了50%的前缀224.0/15，且总体利用率为大约2^16（64K）个地址，则MASC节点应停止回收224.0/15，并应开始回收224.0/16或224.1/16（以子前缀利用率较高者为准）。
If the demand for addresses did not decrease, then a MASC node re-claims the prefixes it has allocated before their lifetime expires. Each prefix (or sub-prefix if the demand has decreased) should be re-claimed every 48 hours.
如果对地址的需求没有减少，那么MASC节点将重新声明在其生存期到期之前分配的前缀。每个前缀（或子前缀，如果需求减少）应每48小时重新申请一次。
At the moment of writing, 225.0.0.0-225.255.255.255 is temporarily allocated to MALLOC. Presumably this block of addresses will be used for experimental deployment and testing.
在撰写本文时，225.0.0.0-225.255.255.255暂时分配给MALLOC。这个地址块大概将用于实验性部署和测试。
If MASC were widely deployed on the Internet, we might expect numbers similar to the following:
如果MASC广泛部署在互联网上，我们可能会预期类似以下数字：
o Initially will have approximately 128 Top-Level Domains
o 最初将有大约128个顶级域
o Assume initially approximately 8192 level-2 MASC domains; on average, a TLD will have approximately 64 children domains.
o 最初假设约8192个二级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
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).
最初，MASC可以将范围228.0.0.0-231.255.255.255（4*2^24=2^26=64M）用作全局地址池。其余的（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）个地址，而每个二级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*每个域的平均值（strawman默认软阈值），则触发警告消息：
* if a TLD claim+allocation >= 512K * if a second level MASC domain claim+allocation >= 8K
* 如果TLD声明+分配>=512K*如果二级MASC域声明+分配>=8K
The hard threshold (for example, 2.0*average_assumed_per_domain) can be enforced by sending an explicit DENIED message.
硬阈值（例如，每个域2.0*平均值）可以通过发送显式拒绝消息来强制执行。
The TLDs thresholds (with regard to the claims by the second level MASC domains) is a private matter and is a part of the particular TLD policy: the thresholds could be per customer, and the warnings to the administrators could be a signal that it is time to change the policy.
TLD阈值（关于二级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）。由于分配是需求驱动的，如果MAAS需要更长的前缀生存期（例如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个，则应在该域及其父MASC域之间运行第2层协议/机制（例如AAP）。
Pavlin Radoslavov Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
南加州大学计算机科学系帕夫林-拉多斯拉沃夫南加州大学，CA洛杉矶90089
EMail: pavlin@catarina.usc.edu
EMail: pavlin@catarina.usc.edu
Deborah Estrin Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
底波拉埃斯特林计算机科学系南加州大学/ ISI洛杉矶，CA 90089美国
EMail: estrin@isi.edu
EMail: estrin@isi.edu
Ramesh Govindan University of Southern California/ISI 4676 Admiralty Way Marina Del Rey, CA 90292 USA
RAMESH GOVDIN南加州大学/ ISI 4676海军陆路码头Dele雷，CA 90292美国
EMail: govindan@isi.edu
EMail: govindan@isi.edu
Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) 1947 Center St., Suite 600 Berkeley, CA 94704 USA
美国加利福尼亚州伯克利1947年中心街600号套房ISCI（ACIRI）互联网研究马克·汉德利AT&T中心，邮编94704
EMail: mjh@aciri.org
EMail: mjh@aciri.org
Satish Kumar Computer Science Department University of Southern California/ISI Los Angeles, CA 90089 USA
库马尔南加州大学计算机科学系，CA洛杉矶90089美国
EMail: kkumar@usc.edu
EMail: kkumar@usc.edu
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
David Thaler微软一路微软雷德蒙德，华盛顿州98052美国
EMail: dthaler@microsoft.com
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 27712000年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，“边界网关多播协议（BGMP）：协议规范”，正在进行的工作。
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年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.Topolocic，“在CIDR环境中跨提供商边界交换路由信息”，RFC 1520，1993年9月。
[IANA] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[IANA]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA注意事项]Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]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.，“高效灵活的分层地址分配”，INET921992年6月，第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）”，RFC2730，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.和D.Estrin，“互联网多播地址分配架构”，RFC 2908，2000年9月。
[MBGP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, September 1997.
[MBGP]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多播的`追踪路由'设施”，正在进行中。
[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 27762000年2月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年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 23731998年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.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。