rfc2907.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页
TXT
732 行
Network Working Group R. Kermode
Request for Comments: 2907 Motorola
Category: Standards Track September 2000
MADCAP Multicast Scope Nesting State Option
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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
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
Kermode Standards Track [Page 1]
RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
10. References. . . . . . . . . . . . . . . . . . . . . . 11
11. Author's Address. . . . . . . . . . . . . . . . . . . 12
12. Full Copyright Statement. . . . . . . . . . . . . . . 13
1. Introduction
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.
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.
1.1 Time-To-Live (TTL) Scoping Split Horizon Effect
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.
Kermode Standards Track [Page 2]
RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
....... *******
... *** *** 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.2 Eliminating the Split Horizon Effect with Administrative Scoping
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.
........................
. .
. many hops .
.S<------------------------>R.
. .
. .
........................
Figure 2 : Eliminating the Split Horizon Effect
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.
Kermode Standards Track [Page 3]
RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
. . . . . . . . . . . . . . . . . .
. 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
A generic expanding scope search algorithm [KERM] that exploits the
existence of a hierarchy of administratively scoped zones is:
1) Starting with the smallest known scope for the session, a
requestor in that session issues a request and waits for a reply.
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.
3) Nodes that receive a response to a particular request while
waiting to send a response to that request, suppress their own
response.
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.
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.
1.3. Terminology
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].
Kermode Standards Track [Page 4]
RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
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.
2. Multicast Nested Scoping State
Two scopes, X and Y, can be related in one of four possible ways.
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.
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.
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".
3 Multicast Scope Nesting State Option
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 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.
3.1 Multicast Scope List Option
To understand the "Multicast Scope Nesting State" option one must
first understand the "Multicast Scope List" option.
Kermode Standards Track [Page 5]
RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
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:
o Scope ID:
The smallest address for the range of multicast addresses
covered by this scope.
o Last Address:
The largest address for the range of multicast addresses
covered by this scope.
o TTL:
The TTL to be used when sending messages to this scope.
o Name(s):
One or more language specific names for the scope.
3.2 Representing the Multicast Scope Nesting State
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.
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.
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.
Kermode Standards Track [Page 6]
RFC 2907 MADCAP Multicast Scope Nesting State Option September 2000
________________________________
/............ \ \ \
/.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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?