Network Working Group R. Kermode
Request for Comments: 2907 Motorola
Category: Standards Track September 2000
Network Working Group R. Kermode
Request for Comments: 2907 Motorola
Category: Standards Track September 2000
MADCAP Multicast Scope Nesting State Option
MADCAP多播作用域嵌套状态选项
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence it may be used for expanding scope searches or hierarchical multicast transport.
本文档为多播地址动态客户端分配协议（MADCAP）定义了一个新选项，以支持嵌套作用域。新选项的目的是让客户端了解哪些作用域相互嵌套，因此它可以用于扩展作用域搜索或分层多播传输。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . 2
1.1 Time-To-Live (TTL) Scoping Split Horizon Effect. 2
1.2 Eliminating the Split Horizon Effect with
Administrative Scoping . . . . . . . . . . . . . 3
1.3 Terminology. . . . . . . . . . . . . . . . . . . 4
2. Multicast Nested Scoping State. . . . . . . . . . . . 5
3. Multicast Scope Nesting State Option. . . . . . . . . 5
3.1 Multicast Scope List Option . . . . . . . . . . 5
3.2 Representing the Multicast Scope Nesting State . 6
3.3 Multicast Scope Nesting State Option Usage . . . 7
4. Managing Dynamic Nested Scopes. . . . . . . . . . . . 8
4.1 MADCAP Server processing of MZAP messages. . . . 9
4.2 Updating State for Dynamic Nested Scopes due to
Timer Expiration . . . . . . . . . . . . . . 9
5. Multicast Scope Nesting State Option Format . . . . . 9
6. Constants . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . 11
9. Acknowledgements. . . . . . . . . . . . . . . . . . . 11
1. Introduction. . . . . . . . . . . . . . . . . . . . . 2
1.1 Time-To-Live (TTL) Scoping Split Horizon Effect. 2
1.2 Eliminating the Split Horizon Effect with
Administrative Scoping . . . . . . . . . . . . . 3
1.3 Terminology. . . . . . . . . . . . . . . . . . . 4
2. Multicast Nested Scoping State. . . . . . . . . . . . 5
3. Multicast Scope Nesting State Option. . . . . . . . . 5
3.1 Multicast Scope List Option . . . . . . . . . . 5
3.2 Representing the Multicast Scope Nesting State . 6
3.3 Multicast Scope Nesting State Option Usage . . . 7
4. Managing Dynamic Nested Scopes. . . . . . . . . . . . 8
4.1 MADCAP Server processing of MZAP messages. . . . 9
4.2 Updating State for Dynamic Nested Scopes due to
Timer Expiration . . . . . . . . . . . . . . 9
5. Multicast Scope Nesting State Option Format . . . . . 9
6. Constants . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . 11
9. Acknowledgements. . . . . . . . . . . . . . . . . . . 11
10. References. . . . . . . . . . . . . . . . . . . . . . 11
11. Author's Address. . . . . . . . . . . . . . . . . . . 12
12. Full Copyright Statement. . . . . . . . . . . . . . . 13
10. References. . . . . . . . . . . . . . . . . . . . . . 11
11. Author's Address. . . . . . . . . . . . . . . . . . . 12
12. Full Copyright Statement. . . . . . . . . . . . . . . 13
The Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] affords client applications the ability to request multicast address allocation services from multicast address allocation servers. As part of the Multicast Address Allocation Architecture [RFC2908], MADCAP gives clients the ability to reserve, request, and extend leases on multicast addresses.
多播地址动态客户端分配协议（MADCAP）[RFC2730]使客户端应用程序能够从多播地址分配服务器请求多播地址分配服务。作为多播地址分配体系结构[RFC2908]的一部分，MADCAP使客户端能够保留、请求和扩展多播地址的租约。
A new MADCAP option, the "Multicast Scope Nesting State" option is proposed to allow clients to learn not only which scopes exist via the existing "Multicast Scope List" option, but how these scopes nest inside each other. This new option will also afford clients the ability to make better scope selections for a given session and also to construct hierarchies of administratively scoped zones. These hierarchies may then be used to perform expanding scope searches instead of the expanding ring or increasing-TTL searches. Expanding scope searches do not suffer from the Split-Horizon Effect present in expanding ring searches, and therefore both simplify protocol design and provide better localization.
提出了一个新的MADCAP选项“多播作用域嵌套状态”选项，它不仅允许客户端通过现有的“多播作用域列表”选项了解存在哪些作用域，而且允许客户端了解这些作用域如何相互嵌套。此新选项还将使客户端能够为给定会话做出更好的范围选择，并构建管理范围区域的层次结构。然后，可以使用这些层次结构来执行扩展范围搜索，而不是扩展环或增加TTL搜索。扩展范围搜索不会受到扩展环搜索中存在的分割地平线效应的影响，因此，这两种搜索都简化了协议设计并提供了更好的定位。
Multicast searching and localized recovery transport techniques that rely on TTL scoping are known to suffer when deployed in a wide scale manner. The failing lies in the split horizon effect shown below in Figure 1. Here a requestor and responder must each use a TTL that is sufficiently large that they will reach the other. When they are separated by many hops the TTL becomes large and the number of receivers within the multicast tree that only receive either the request or the response can become very large.
众所周知，在大规模部署时，依赖TTL作用域的多播搜索和本地化恢复传输技术会受到影响。失败在于图1所示的分割地平线效应。在这里，请求者和响应者必须各自使用足够大的TTL，以便能够到达对方。当它们被多个跃点隔开时，TTL会变大，并且多播树中只接收请求或响应的接收器数量会变大。
....... *******
... *** *** A Only hears S
.. ** .. ** B hears S and R
. * . * C Only hears R
. * . *
. S<------->R * . TTL Boundary for S
. * . * * TTL Boundary for R
. A * B . C *
.. ** .. **
... *** ***
....... *******
....... *******
... *** *** A Only hears S
.. ** .. ** B hears S and R
. * . * C Only hears R
. * . *
. S<------->R * . TTL Boundary for S
. * . * * TTL Boundary for R
. A * B . C *
.. ** .. **
... *** ***
....... *******
Figure 1 : Split Horizon Problem from TTL scoping
图1:TTL范围划分的分割地平线问题
Ideally, a mechanism that either eliminates or minimizes the size of the A and C regions in Figure 1. as shown in Figure 2. is needed to solve this problem. One mechanism that affords this ability is administrative scoping [RFC2365], in which routers prevent the passing of packets within a certain range of multicast addresses. Routers that have this feature can be configured to provide a perimeter around a region of the network. This perimeter is said to encompass an administratively scoped zone inside of which traffic sent to that particular range of multicast addresses can neither leave nor enter. Routers can construct and manage administratively scoped zones using the MZAP [RFC2776] protocol.
理想情况下，一种消除或最小化图1中a和C区域大小的机制。如图2所示。要解决这一问题，就需要一种新的方法。提供这种能力的一种机制是管理作用域[RFC2365]，在这种机制中，路由器防止在特定的多播地址范围内传递数据包。具有此功能的路由器可以配置为在网络区域周围提供周界。据说该周界包含一个管理范围的区域，在该区域内，发送到该特定范围的多播地址的流量既不能离开也不能进入。路由器可以使用MZAP[RFC2776]协议构造和管理管理范围为管理范围的区域。
........................
. .
. many hops .
.S<------------------------>R.
. .
. .
........................
........................
. .
. many hops .
.S<------------------------>R.
. .
. .
........................
Figure 2 : Eliminating the Split Horizon Effect
图2：消除分割地平线效应
MZAP also includes the ability to determine whether or not administratively scoped regions nest inside one another. This allows hierarchies such as that shown in Figure 1. to be constructed.
MZAP还包括确定管理范围的区域是否相互嵌套的能力。这允许如图1所示的层次结构。待建造。
. . . . . . . . . . . . . . . . . .
. scope a . Scope Boundaries
. . . = scope a
. _______________ ________________ . - = scopes b,c
. / scope b \ / scope c \ . # = scopes d,e,f, & g
.| | | |.
.| ##### ##### | | ##### ##### |.
.| #scope# #scope#| | #scope# #scope# |.
.\ # d # # e #| | # f # # g # /.
.\ #### #####/ \ ##### #### /.
.\____________/ \_____________/.
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. scope a . Scope Boundaries
. . . = scope a
. _______________ ________________ . - = scopes b,c
. / scope b \ / scope c \ . # = scopes d,e,f, & g
.| | | |.
.| ##### ##### | | ##### ##### |.
.| #scope# #scope#| | #scope# #scope# |.
.\ # d # # e #| | # f # # g # /.
.\ #### #####/ \ ##### #### /.
.\____________/ \_____________/.
. . . . . . . . . . . . . . . . .
Figure 3 : Admin Scope Zone Nesting Hierarchy example
图3：管理范围区域嵌套层次结构示例
A generic expanding scope search algorithm [KERM] that exploits the existence of a hierarchy of administratively scoped zones is:
利用管理范围区域层次结构存在性的通用扩展范围搜索算法[KERM]是：
1) Starting with the smallest known scope for the session, a requestor in that session issues a request and waits for a reply.
1) 从会话的最小已知范围开始，该会话中的请求者发出请求并等待答复。
2) If a node within that scope hears a request at a certain scope that it can satisfy it sends a response at that same scope, possibly after some random delay to reduce duplicate responses.
2) 如果该作用域内的节点在某个作用域听到一个请求，并且它可以满足该请求，那么它可能会在某个随机延迟之后在该作用域发送一个响应，以减少重复响应。
3) Nodes that receive a response to a particular request while waiting to send a response to that request, suppress their own response.
3) 在等待发送对特定请求的响应时接收对该请求的响应的节点会抑制自己的响应。
4) If a requestor issues a request to a scope, and does not hear a response after a specified amount of time, it retransmits its request at the same scope a small number of additional times. Should these retries fail to elicit a response, the requestor increases the scope to the next largest scope and tries again.
4) 如果请求者向某个作用域发出请求，并且在指定的时间之后没有听到响应，那么它会在同一作用域上再发送少量的请求。如果这些重试未能引发响应，请求者会将作用域增加到下一个最大的作用域，然后重试。
5) Requestors increase the scope of the request according to step 4 until either a response is received, or the largest legal scope for the session is reached. Should attempts to elicit a response at the largest possible scope for the session fail to yield a response, the requestor may conclude that the request cannot be met.
5) 请求者根据步骤4增加请求的范围，直到收到响应或达到会话的最大合法范围。如果试图在会话的最大可能范围内引发响应的尝试未能产生响应，请求者可能会得出无法满足请求的结论。
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]中所述进行解释。
Throughout the rest of this document, the words "server" or "MADCAP server" refer to a host providing multicast address allocation services via MADCAP. The words "client" or "MADCAP client" refer to a host requesting multicast address allocation services via MADCAP.
在本文档的其余部分中，“服务器”或“MADCAP服务器”指的是通过MADCAP提供多播地址分配服务的主机。词语“客户端”或“MADCAP客户端”指通过MADCAP请求多播地址分配服务的主机。
Two scopes, X and Y, can be related in one of four possible ways.
两个作用域X和Y可以通过四种可能的方式之一进行关联。
1) X nests inside Y, 2) Y nests inside X, 3) X and Y do not nest (the overlap case), and 4) X and Y nest inside each other.
1) X嵌套在Y中，2）Y嵌套在X中，3）X和Y不嵌套（重叠情况），4）X和Y嵌套在彼此内部。
The fourth case SHOULD be interpreted as meaning that X and Y have exactly the same border. This does not mean that X and Y are the same scope since X and Y may correspond to different ranges of the multicast address space.
第四种情况应解释为X和Y具有完全相同的边界。这并不意味着X和Y是相同的范围，因为X和Y可能对应于多播地址空间的不同范围。
This state MUST be stored in the MADCAP servers which MUST allow the state to be updated as network conditions change. Each MADCAP server SHOULD therefore define two pieces of state that describe whether "scope X nests in scope Y" and vice versa. For the remainder of this document the nesting relationship shall be denoted as the "/" where X/Y defines the relation "X nests inside Y". This relation shall be understood to take one of the values "true", or "false". Nesting relationship state that is indeterminate is considered to be "false".
该状态必须存储在MADCAP服务器中，该服务器必须允许该状态随着网络条件的变化而更新。因此，每个MADCAP服务器应该定义两个状态，描述“范围X是否嵌套在范围Y中”，反之亦然。对于本文件的其余部分，嵌套关系应表示为“/”，其中X/Y定义了关系“X嵌套在Y内”。这种关系应理解为取“真”或“假”值之一。不确定的嵌套关系状态被视为“false”。
3 Multicast Scope Nesting State Option
3多播作用域嵌套状态选项
The "Multicast Scope Nesting State" option is proposed to augment the "Multicast Scope List" option within the MADCAP protocol by providing additional information to applications about how scopes nest. The proposed option is OPTIONAL, that is MADCAP servers MAY implement this new option, however they are not required to.
“多播作用域嵌套状态”选项旨在通过向应用程序提供有关作用域如何嵌套的附加信息来扩充MADCAP协议中的“多播作用域列表”选项。建议的选项是可选的，即MADCAP服务器可以实现此新选项，但不需要实现。
MADCAP servers shall learn this additional nesting information by means of static configuration or via some other protocol such as MZAP [RFC2776] that manages administrative scopes in a dynamic fashion.
MADCAP服务器应通过静态配置或通过一些其他协议（如MZAP[RFC2776]）（以动态方式管理管理范围）来了解该附加嵌套信息。
To understand the "Multicast Scope Nesting State" option one must first understand the "Multicast Scope List" option.
要理解“多播作用域嵌套状态”选项，必须首先理解“多播作用域列表”选项。
The Multicast Scope List option in MADCAP is used by MADCAP servers to inform MADCAP clients of which zones are visible. Visible scopes are enumerated inside the option as successive tuples, where each tuple consists of the following information:
MADCAP服务器使用MADCAP中的多播作用域列表选项通知MADCAP客户端哪些区域可见。可见范围在选项中作为连续元组枚举，其中每个元组包含以下信息：
o Scope ID: The smallest address for the range of multicast addresses covered by this scope.
o 作用域ID：此作用域覆盖的多播地址范围的最小地址。
o Last Address: The largest address for the range of multicast addresses covered by this scope.
o Last Address：此作用域所涵盖的多播地址范围的最大地址。
o TTL: The TTL to be used when sending messages to this scope.
o TTL：将消息发送到此作用域时要使用的TTL。
o Name(s): One or more language specific names for the scope.
o 名称：作用域的一个或多个特定于语言的名称。
Given a Multicast Scope List containing descriptions for n scopes one can form n(n-1)/2 pairings. As was shown in section 2 each pairing can take on one of four possible states. Thus, for a list of n scopes there exists 2 pieces of information for each pairing for a total of n(n-1) pieces of information regarding which scopes do and do not nest inside each other.
给定包含n个作用域描述的多播作用域列表，可以形成n（n-1）/2对。如第2节所示，每个配对可以采用四种可能的状态之一。因此，对于n个作用域的列表，每个配对存在2条信息，总共有n（n-1）条关于哪些作用域相互嵌套和不嵌套的信息。
There are several ways to represent this state using full matrices, sparse-matrices, and using lists of variable length lists. In the interests of maximal efficiency and flexibility, the Multicast Nesting State Option uses a bit-packed matrix approach. In this approach a matrix is constructed using pieces of X/Y state where X is the row and Y is the column. A "1" in the matrix means that the relationship "row nests inside column" is true, while a "0" means that this relationship is either false or indeterminate. The diagonal of the matrix is removed, since this is the case where X is the same as Y, and each row is then zero-padded to the next byte boundary to give the final representation.
有几种方法可以使用完整矩阵、稀疏矩阵和可变长度列表来表示这种状态。为了最大限度地提高效率和灵活性，多播嵌套状态选项使用位压缩矩阵方法。在这种方法中，使用X/Y状态的片段构造矩阵，其中X是行，Y是列。矩阵中的“1”表示关系“行嵌套在列中”为真，而“0”表示此关系为假或不确定。矩阵的对角线将被删除，因为在这种情况下，X与Y相同，然后将每行零填充到下一个字节边界，以给出最终表示。
An example of how a matrix would be constructed for the following scope nestings S1/S2, S2/S3, S2/S4, S3/S5, S4/S5, S5/S6, and S6/S7. Note that a number of additional nesting relationships are implied from this set.
关于如何为以下范围嵌套S1/S2、S2/S3、S2/S4、S3/S5、S4/S5、S5/S6和S6/S7构建矩阵的示例。请注意，此集合隐含了许多其他嵌套关系。
________________________________
/............ \ \ \
/.S3 _________._____ \ \ \
|. /+--+ \ . \ | | |
|. | |S1| S2 | . S4 | S5 | S6 | S7 |
|. \+--+ / . | | | |
\. \______/ . | | | |
\....\....... / / / /
\ \___________/ / / /
\___________________/ / /
\ Y \______________________/ /
X \ 1 2 3 4 5 6 7 \_________________________/
+-+-+-+-+-+-+-+
1 |1 1 1 1 1 1 1| *111111 1111 1100 0xfc
2 |0 1 1 1 1 1 1| 0*11111 0111 1100 0x7c
3 |0 0 1 0 1 1 1| 00*0111 0001 1100 0x1c
4 |0 0 0 1 1 1 1| => 000*111 => 0001 1100 => 0x1c
5 |0 0 0 0 1 1 1| 0000*11 0000 1100 0x0c
6 |0 0 0 0 0 1 1| 00000*1 0000 0100 0x04
7 |0 0 0 0 0 0 1| 000000* 0000 0000 0x00
+-+-+-+-+-+-+-+ ^^
* = X/Y where zero padding
X == Y
Final Representation: 0xfc 0x7c 0x1c 0x1c 0x0c 0x04 0x00
________________________________
/............ \ \ \
/.S3 _________._____ \ \ \
|. /+--+ \ . \ | | |
|. | |S1| S2 | . S4 | S5 | S6 | S7 |
|. \+--+ / . | | | |
\. \______/ . | | | |
\....\....... / / / /
\ \___________/ / / /
\___________________/ / /
\ Y \______________________/ /
X \ 1 2 3 4 5 6 7 \_________________________/
+-+-+-+-+-+-+-+
1 |1 1 1 1 1 1 1| *111111 1111 1100 0xfc
2 |0 1 1 1 1 1 1| 0*11111 0111 1100 0x7c
3 |0 0 1 0 1 1 1| 00*0111 0001 1100 0x1c
4 |0 0 0 1 1 1 1| => 000*111 => 0001 1100 => 0x1c
5 |0 0 0 0 1 1 1| 0000*11 0000 1100 0x0c
6 |0 0 0 0 0 1 1| 00000*1 0000 0100 0x04
7 |0 0 0 0 0 0 1| 000000* 0000 0000 0x00
+-+-+-+-+-+-+-+ ^^
* = X/Y where zero padding
X == Y
Final Representation: 0xfc 0x7c 0x1c 0x1c 0x0c 0x04 0x00
Figure 4. Scope Nesting Example
图4。范围嵌套示例
The "Multicast Scope Nesting State" option is dependent upon the "Multicast Scope List" option. This decision was made according to the following reasoning. The Multicast Nest State Option requires that the scopes be identified along with their nesting properties. Since the information needed to describe a scope is contained in the Multicast Scope List option and this information can change, the MADCAP messages that contain the Multicast Scope Nesting State option must be atomic and therefore must include the "Multicast Scope List Option".
“多播作用域嵌套状态”选项取决于“多播作用域列表”选项。这一决定是根据以下理由作出的。多播嵌套状态选项要求标识作用域及其嵌套属性。由于描述作用域所需的信息包含在多播作用域列表选项中，并且该信息可以更改，因此包含多播作用域嵌套状态选项的MADCAP消息必须是原子的，因此必须包含“多播作用域列表选项”。
Thus, the "Multicast Scope Nesting State" option MUST only be used in messages that carry the "Multicast Scope List" option, specifically:
因此，“多播作用域嵌套状态”选项只能在带有“多播作用域列表”选项的消息中使用，具体来说：
ACK (in response to GETINFO)
确认（响应GETINFO）
Since the Multicast Nest State option is dependent upon the Multicast Scope List option, it MUST NOT be included without the Multicast Scope List option.
由于多播嵌套状态选项依赖于多播作用域列表选项，因此在没有多播作用域列表选项的情况下，不能包含该选项。
Clients that need to explicitly learn the nesting relationships between scopes should therefore send a GETINFO message to the server with the "Multicast Scope List" AND "Multicast Scope Nesting State" option codes listed in an Option Request option.
因此，需要显式了解作用域之间嵌套关系的客户端应向服务器发送一条GETINFO消息，并在选项请求选项中列出“多播作用域列表”和“多播作用域嵌套状态”选项代码。
Scopes can either be manually or automatically configured. When scopes are manually configured the relationships between them will also be static, assuming that network does not partition due to router failure. Should the network partition or heal after a partition it is highly likely that the nesting relationships will change. Scope nesting relationships will also change as a network is brought up or when a change is deliberately made to a router either through manual reconfiguration or by some automatic means.
作用域可以手动配置，也可以自动配置。当手动配置作用域时，它们之间的关系也将是静态的，假设网络由于路由器故障而不分区。如果网络分区在分区后恢复或修复，则嵌套关系很可能会改变。范围嵌套关系也将随着网络的建立或通过手动重新配置或某些自动方式对路由器进行有意更改而改变。
To ensure that nesting relationships are correctly determined when scope boundaries undergo change MADCAP servers MUST include a mechanism that allow for:
为确保在范围边界发生更改时正确确定嵌套关系，MADCAP服务器必须包括一种机制，允许：
a) whether the nesting decision is still under consideration or can be considered definitive, and therefore be announced to MADCAP clients.
a) 筑巢决定是否仍在考虑中，或者是否可以被视为最终决定，并因此向MADCAP客户宣布。
b) whether one or both scopes for a particular nesting state entry have been destroyed, and hence whether the nesting state should therefore be discarded.
b) 特定嵌套状态条目的一个或两个作用域是否已销毁，因此是否应丢弃嵌套状态。
c) whether the scope boundaries have changed so that whereas scope X did or did not nest inside scope Y, the opposite is now true.
c) 无论作用域边界是否发生了变化，以致于作用域X是否嵌套在作用域Y内，现在情况正好相反。
To realize a) and b) MADCAP servers MUST implement the following two timers; NEST_NO_DECISION_TIMER, ZONES_EXIST_TIMER.
要实现a）和b）MADCAP服务器必须实现以下两个计时器；嵌套\u无\u决策\u计时器，区域\u存在\u计时器。
The first timer, NEST_NO_DECISION_TIMER, is used to mark time between a MADCAP server's first hearing of a scope and making a decision about its relationship to other zones. Up until the time this timer expires MADCAP servers MUST NOT conclude that the scope nests within another.
第一个计时器NEST_NO_DECISION_timer用于标记MADCAP服务器第一次听到作用域和决定其与其他区域的关系之间的时间。在此计时器过期之前，MADCAP服务器不得断定作用域嵌套在另一个作用域中。
The NEST_NO_DECISION_TIMER timer will also be used to timeout X/Y = "false" state to allow X/Y to be reset to true in the event that the boundaries for zone X and zone Y change so that zone X now nests inside zone Y.
NEST_NO_DECISION_计时器也将用于超时X/Y=“false”状态，以允许在区域X和区域Y的边界发生变化时将X/Y重置为true，从而使区域X现在嵌套在区域Y内。
The second timer ZONES_EXIST_TIMER will be used to timeout the internal state between two scopes in the event that one or both scopes are destroyed.
第二个计时器区域\u EXIST\u计时器将用于在一个或两个作用域被破坏的情况下，使两个作用域之间的内部状态超时。
When MZAP is used to discover the nesting relationship between scopes MADCAP servers will eavesdrop into the MZAP messages that are periodically transmitted by the Zone Border Routers (ZBR) during the normal course of administrative scope boundary maintenance. In this way they will be able to learn which scopes exist (via Zone Announcement Messages, ZAMs) and which of these scopes do not nest (via Not Inside Messages, NIMs). This state must be cached within the MADCAP server.
当使用MZAP发现作用域之间的嵌套关系时，MADCAP服务器将窃听由区域边界路由器（ZBR）在管理作用域边界维护的正常过程中定期传输的MZAP消息。通过这种方式，他们将能够了解哪些作用域存在（通过区域公告消息，ZAM），哪些作用域不嵌套（通过非内部消息，NIM）。此状态必须缓存在MADCAP服务器中。
When a MADCAP server S receives a NIM from a ZBR containing information that scope X does not nest in scope Y, it MUST update its internal state in the following manner.
当MADCAP服务器S从ZBR接收到包含范围X未嵌套在范围Y中的信息的NIM时，它必须以以下方式更新其内部状态。
1) S MUST update its internal X/Y state to "false". 2) S MUST restart NEST_NO_DECISION_TIMER for the newly updated X/Y state.
1) S必须将其内部X/Y状态更新为“false”。2） 必须为新更新的X/Y状态重新启动NEST_NO_DECISION_计时器。
4.2 Updating State for Dynamic Scopes due to timer expiration.
4.2 由于计时器过期，正在更新动态作用域的状态。
MADCAP servers will update X/Y nesting state upon the expiration of timers in the following manner.
MADCAP服务器将在计时器过期时以以下方式更新X/Y嵌套状态。
o If the NEST_NO_DECISION_TIMER expires for a state entry X/Y AND no MADCAP messages have been received that indicate scope X does not nest inside scope Y, a MADCAP Server, S, MUST conclude that scope X nests inside scope Y. As a result S will change X/Y from "false" to "true".
o 如果状态条目X/Y的NEST_NO_DECISION_计时器过期，并且没有收到指示作用域X未嵌套在作用域Y内的MADCAP消息，则MADCAP服务器S必须断定作用域X嵌套在作用域Y内。因此，S将X/Y从“false”更改为“true”。
When a state change from "false" to "true" occurs for X/Y, S must also start the ZONES_EXIST_TIMER timer for X/Y. The ZONES_EXIST_TIMER should only reset when a Zone Announcement Message (ZAM) has been received for both zone X and zone Y since the last time it was restarted. This ensures that both zone X and zone Y are known to still exist.
当X/Y的状态从“false”变为“true”时，S还必须启动X/Y的区域存在计时器。区域存在计时器只有在自上次重新启动后收到区域X和区域Y的区域公告消息（ZAM）时才应重置。这可确保已知X区和Y区仍然存在。
o If the ZONES_EXIST_TIMER expires for a state entry X/Y, S SHOULD conclude that either zone Y or zone X no longer exists and hence that both X/Y and Y/X state should be destroyed.
o 如果某个状态条目X/Y的“区域存在”计时器过期，则S应断定区域Y或区域X不再存在，因此X/Y和Y/X状态都应被销毁。
Code Len Count Nest State Matrix
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 17 | p | m | N1 | | Nm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
Code Len Count Nest State Matrix
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 17 | p | m | N1 | | Nm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
Code: 16 bits Option identifier 17.
代码：16位选项标识符17。
Len: 16 bits The length of the option in bytes.
Len:16位选项的长度，以字节为单位。
Count: 8 bits The number of zones present in the Nest State Matrix. This value MUST be identical to the Count field in the preceding Multicast State List option. If this is not the case the scope nesting state information MUST BE ignored.
计数：8位嵌套状态矩阵中存在的区域数。此值必须与前面的多播状态列表选项中的计数字段相同。如果不是这种情况，则必须忽略作用域嵌套状态信息。
Nest State Matrix: The compressed bit-packed representation of the matrix, derived in the same manner as shown in Figure 4. Note for N scopes the compressed matrix will be N times ceil((N-1)/8) bytes long, where ceil() is the function that rounds up to the nearest integer. The scopes corresponding to the rows and columns of this matrix list in the same order as they appear in the Multicast Scope List Option.
嵌套状态矩阵：矩阵的压缩位压缩表示，其推导方式与图4所示相同。注意：对于N个作用域，压缩矩阵的长度将是ceil（（N-1）/8）字节的N倍，其中ceil（）是向上舍入到最接近整数的函数。与此矩阵列表的行和列对应的作用域的顺序与它们在“多播作用域列表”选项中的显示顺序相同。
[NEST_NO_DECISION_TIMER] The time after which a MADCAP server or client can assume that a message announcing that two zones do not nest should not be received. The length of this timer is dependent upon the zone announcement protocol used to inform the MADCAP router of which zones currently exist. When MZAP [RFC2776] is used this value should be greater than the MZAP timeout value NIM-INTERVAL +30%. This corresponds to a timeout value of 1800 + 30% = 2340 seconds (39 minutes).
[NEST_NO_DECISION_TIMER]MADCAP服务器或客户端可以假定不应收到通知两个区域不嵌套的消息的时间。此计时器的长度取决于用于通知MADCAP路由器当前存在哪些区域的区域公告协议。使用MZAP[RFC2776]时，该值应大于MZAP超时值NIM-INTERVAL+30%。这对应于1800+30%=2340秒（39分钟）的超时值。
[ZONES_EXIST_TIMER] The time after which a MADCAP server or client should assume that the zone in question does not exist when zones are detected dynamically. The length of this timer is dependent upon the zone announcement protocol used to inform the MADCAP router of which zones currently exist. When MZAP [RFC2776] is used this value should be no less than the MZAP timeout value NIM-HOLDTIME, which has a default of 5460 seconds (91 minutes).
[ZONES\u EXIST\u TIMER]动态检测到区域时，MADCAP服务器或客户端应假定该区域不存在的时间。此计时器的长度取决于用于通知MADCAP路由器当前存在哪些区域的区域公告协议。使用MZAP[RFC2776]时，该值应不小于MZAP超时值NIM-HOLDTIME，默认值为5460秒（91分钟）。
Since this document proposes an extension to the MADCAP protocol via the addition of a new option, the same set of security concerns apply.
由于本文件建议通过添加新选项来扩展MADCAP协议，因此同样的安全问题也适用。
In addition to these concerns are those that would arise were the information in the Multicast Scope Nesting State option to be falsified. In this case the clients would be misinformed as to which scopes nest inside one another. In this event, the client would then make incorrect decisions regarding the order in which to use the scopes. The effect of this would be to use larger scopes than necessary, which would effectively flatten any scope hierarchy present and nullify the advantage afforded by the hierarchy's presence.
除了这些问题之外，如果多播作用域嵌套状态选项中的信息被篡改，也会出现这些问题。在这种情况下，客户机将被错误地告知哪些作用域嵌套在另一个作用域中。在这种情况下，客户机将对作用域的使用顺序做出错误的决定。这样做的效果是使用比需要更大的作用域，这将有效地使现有的任何作用域层次结构扁平化，并抵消层次结构的存在所带来的优势。
Thus a malformed or tampered Multicast Scope Nesting option may cause protocols that rely upon the existence of a scoping hierarchy to scale less well, but it would not prevent them from working.
因此，格式错误或篡改的多播作用域嵌套选项可能会导致依赖于作用域层次结构存在的协议伸缩性较差，但这不会阻止它们工作。
The Multicast Nesting State Option has been assigned MADCAP option code 17 by the IANA [RFC2730].
IANA[RFC2730]已为多播嵌套状态选项分配MADCAP选项代码17。
The Author would like to acknowledge Mark Handley and Dave Thaler for the helpful discussions and feedback which helped shape and refine this document.
作者要感谢Mark Handley和Dave Thaler的有益讨论和反馈，这些讨论和反馈有助于形成和完善本文件。
[KERM] Kermode, R., "Smart Network Caches: Localized Content and Application Negotiated Recovery Mechanisms for Multicast Media Distribution", Ph.D. Thesis, MIT Media Laboratory, June 1998.
[KERM]Kermode，R.，“智能网络缓存：多播媒体分发的本地化内容和应用程序协商恢复机制”，博士。麻省理工学院媒体实验室论文，1998年6月。
[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月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[RFC2730] Patel, B.V., Shah, M. and S.R. Hanna, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[RFC2730]Patel，B.V.，Shah，M.和S.R.Hanna，“多播地址动态客户端分配协议（MADCAP）”，RFC2730，1999年12月。
[RFC2776] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[RFC2776]Handley，M.，Thaler，D.和R.Kermode，“多播作用域公告协议（MZAP）”，RFC 27762000年2月。
[RFC2908] Handley, M., Thaler, D. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[RFC2908]Handley，M.，Thaler，D.和D.Estrin，“互联网多播地址分配架构”，RFC 2908，2000年9月。
Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany, NSW 1455 Australia
Roger Kermode摩托罗拉澳大利亚研究中心锁袋5028植物学，新南威尔士州1455澳大利亚
EMail: Roger.Kermode@motorola.com
EMail: Roger.Kermode@motorola.com
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编辑功能的资金目前由互联网协会提供。