MADCAP scope nesting: MADCAP Multicast Scope Nesting State Option
A MADCAP option that tells clients which multicast scopes sit inside which, so they can widen a search one scope at a time.
Kermode, R., "MADCAP Multicast Scope Nesting State Option", RFC 2907, DOI 10.17487/RFC2907, September 2000, <https://www.rfc-editor.org/info/rfc2907>.
@misc{rfc2907,
series = {Request for Comments},
number = 2907,
howpublished = {RFC 2907},
publisher = {RFC Editor},
doi = {10.17487/RFC2907},
url = {https://www.rfc-editor.org/info/rfc2907},
author = {R. Kermode},
title = {{MADCAP Multicast Scope Nesting State Option}},
pagetotal = 13,
year = 2000,
month = sep,
} RFC text
Contents
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
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.
....... *******
... *** *** 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.
. . . . . . . . . . . . . . . . . .
. 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].
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.
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.
________________________________
/............ \ \ \
/.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
3.3 Multicast Scope Nesting State Option Usage
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".
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)
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.
4. Managing Dynamically Nested Scopes
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:
a) whether the nesting decision is still under consideration or
can be considered definitive, and therefore be announced to
MADCAP clients.
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.
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.
To realize a) and b) MADCAP servers MUST implement the following two
timers; NEST_NO_DECISION_TIMER, ZONES_EXIST_TIMER.
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.
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.
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.
4.1 MADCAP Server processing of MZAP messages
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.
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.
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.
4.2 Updating State for Dynamic Scopes due to timer expiration.
MADCAP servers will update X/Y nesting state upon the expiration of
timers in the following manner.
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".
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.
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.
5. Multicast Scope Nesting State Option Format
Code Len Count Nest State Matrix
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 17 | p | m | N1 | | Nm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
Code: 16 bits
Option identifier 17.
Len: 16 bits
The length of the option in bytes.
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.
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.
6. Constants
[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).
[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).
7. Security Considerations
Since this document proposes an extension to the MADCAP protocol via
the addition of a new option, the same set of security concerns
apply.
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.
8. IANA Considerations
The Multicast Nesting State Option has been assigned MADCAP option
code 17 by the IANA [RFC2730].
9. Acknowledgments
The Author would like to acknowledge Mark Handley and Dave Thaler for
the helpful discussions and feedback which helped shape and refine
this document.
10. References
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[RFC2730] Patel, B.V., Shah, M. and S.R. Hanna, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999.
[RFC2776] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", RFC 2776, February
2000.
[RFC2908] Handley, M., Thaler, D. and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908,
September 2000.
11. Author's Address
Roger Kermode
Motorola Australian Research Centre
Locked Bag 5028
Botany, NSW 1455
Australia
EMail: Roger.Kermode@motorola.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
AI ELI5
On this page
§1What the Option Adds to MADCAP
The Multicast Address Dynamic Client Allocation Protocol (MADCAP, RFC 2730) lets clients ask multicast address allocation servers to reserve, request and extend leases on multicast addresses. It is part of the Multicast Address Allocation Architecture (RFC 2908).
MADCAP's existing Multicast Scope List option tells a client which scopes exist. RFC 2907 proposes a Multicast Scope Nesting State option that also says how those scopes nest. Clients can then choose scopes better for a session and build hierarchies of administratively scoped zones.
A list of groups is useful. A list that also says which group is inside which is more useful, because you can start small and grow.
§2The Split Horizon Problem and Expanding Scope Searches
Searching and localized recovery that rely on TTL scoping suffer when deployed widely. A requestor and a responder must each use a TTL large enough to reach the other. When they are many hops apart the TTL becomes large, and many receivers hear only the request or only the response. This is the split horizon effect.
Administrative scoping (RFC 2365) avoids this: routers stop packets in a range of multicast addresses at a configured perimeter, forming an administratively scoped zone. Routers can build and manage such zones with MZAP (RFC 2776), which can also tell whether zones nest.
With a hierarchy of zones, a requestor can run an expanding scope search. It starts at the smallest known scope and retransmits a small number of additional times at the same scope. If nothing answers, it moves to the next largest scope, and continues until it gets a response or reaches the largest legal scope for the session. Nodes that hear a response while waiting to send their own suppress it.
Shouting louder and louder reaches lots of people who did not need to hear. It is better to ask in your own classroom first, then the whole school, then the town.
§3Nesting State and the Scope List
Two scopes X and Y can be related in one of four ways: X nests inside Y, Y nests inside X, they do not nest (the overlap case), or they nest inside each other. The last case SHOULD be read as X and Y having exactly the same border, which does not make them the same scope because they may cover different multicast address ranges.
MADCAP servers MUST store this state and MUST allow it to be updated as the network changes. Each server SHOULD keep two pieces of state per pair, written X/Y for "X nests inside Y", each either true or false. Indeterminate state counts as false.
The Multicast Scope List option lists each visible scope as a tuple of Scope ID (the smallest address in its range), Last Address (the largest), TTL, and one or more language-specific names. The new option is OPTIONAL: servers MAY implement it. They learn nesting by static configuration or from a protocol such as MZAP.
Two circles can be one inside the other, either way round, side by side overlapping, or exactly on top of each other. The server keeps a yes or no for each pair.
§4The Bit-Packed Nesting Matrix
For n scopes there are n(n-1)/2 pairings, and the RFC counts n(n-1) pieces of nesting information. For efficiency and flexibility the option uses a bit-packed matrix. Row X and column Y hold the state X/Y: a 1 means the row scope nests inside the column scope, and a 0 means false or indeterminate. The diagonal is removed, since a scope compared with itself carries no information, and each row is zero-padded to the next byte boundary.
The RFC's example has seven scopes with nestings S1/S2, S2/S3, S2/S4, S3/S5, S4/S5, S5/S6 and S6/S7. Note that many more nesting relationships are implied by that set. The final representation is seven bytes, one per row.
The option depends on the Multicast Scope List option, because scope descriptions can change and the two must travel atomically. It MUST only be used in messages that carry the scope list option, specifically an ACK in response to GETINFO, and MUST NOT be included without it. A client wanting nesting lists both option codes in an Option Request option in a GETINFO message.
Picture a grid of yes and no boxes, one row per group. Each row is squashed into a tiny number written in ones and zeros, so the whole grid takes very little space.
Row Bits Byte
1 1111 1100 0xfc
2 0111 1100 0x7c
3 0001 1100 0x1c
4 0001 1100 0x1c
5 0000 1100 0x0c
6 0000 0100 0x04
7 0000 0000 0x00
Final: 0xfc 0x7c 0x1c 0x1c 0x0c 0x04 0x00§5The Option Format
The option has four parts. Code is 16 bits and holds the option identifier 17. Len is 16 bits and gives the length of the option in bytes. Count is 8 bits and gives the number of zones in the matrix.
Count MUST be identical to the Count field in the preceding Multicast Scope List option. If it is not, the scope nesting information MUST be ignored. The Nest State Matrix is the compressed matrix derived as in the example, and for N scopes it is N times ceil((N-1)/8) bytes long. Its rows and columns follow the same order as the scopes in the Multicast Scope List option.
The message starts with a label saying what it is, then how long it is, then how many groups there are, and then the grid. If the group count does not match the list, the grid is thrown away.
- Code16 bits — Option identifier 17.
- Len16 bits — Length of the option in bytes.
- Count8 bits — Number of zones; must match the Multicast Scope List option.
- MatrixN x ceil((N-1)/8) bytes — Bit-packed nesting matrix, in scope list order.
§6Keeping Nesting State Current with Timers
Scope boundaries change when a network partitions or heals, is brought up, or a router is reconfigured. Servers MUST therefore track whether a nesting decision is still pending or definitive, whether a scope has been destroyed, and whether a boundary change has flipped a relationship. Two timers cover the first two: NEST_NO_DECISION_TIMER and ZONES_EXIST_TIMER.
When MZAP is used, servers eavesdrop on messages sent by Zone Border Routers. Zone Announcement Messages (ZAMs) show which scopes exist, and Not Inside Messages (NIMs) show which do not nest. When a NIM says X does not nest in Y, the server MUST set X/Y to false and restart NEST_NO_DECISION_TIMER for it. Until that timer expires, a server MUST NOT conclude that a scope nests within another.
If NEST_NO_DECISION_TIMER expires and no message has said X does not nest in Y, the server MUST conclude that X nests in Y and change X/Y from false to true. It then starts ZONES_EXIST_TIMER, which resets only when a ZAM has been received for both zones since the last restart. If that timer expires, the server SHOULD conclude one of the zones no longer exists and destroy both X/Y and Y/X state.
The server assumes a group is inside another only after it has waited long enough without hearing "no". It keeps checking that both groups still exist, and forgets the pair if they go quiet.
| Timer | Purpose | Value with MZAP |
|---|---|---|
| NEST_NO_DECISION_TIMER | Wait before concluding X nests in Y | More than 2340 seconds (39 minutes) |
| ZONES_EXIST_TIMER | Detect that a zone has been destroyed | At least 5460 seconds (91 minutes) |
§7Security and Timer Constants
The option inherits the security concerns of MADCAP. If its contents were falsified, clients would be misinformed about nesting and would pick scopes in the wrong order. They would use larger scopes than necessary, flattening the hierarchy and cancelling its advantage. Protocols relying on the hierarchy would scale less well, but would not be prevented from working.
For the timers, the RFC says that with MZAP, NEST_NO_DECISION_TIMER should be greater than the MZAP NIM-INTERVAL plus 30%, which is 1800 + 30% = 2340 seconds (39 minutes). ZONES_EXIST_TIMER should be no less than the MZAP NIM-HOLDTIME, which has a default of 5460 seconds (91 minutes). IANA has assigned the option MADCAP option code 17.
If someone lies about which group is inside which, computers shout to bigger crowds than needed. That is wasteful but not fatal.