MADCAP Multicast Scope Nesting State Option
Extracted elements (20)
A hierarchical expanding-scope search algorithm exploits nested administratively scoped zones to replace expanding-ring TTL searches. A requestor starts at the smallest known scope and retransmits at progressively larger scopes if no reply is received, avoiding the split-horizon effect entirely while achieving better traffic localization.
The Multicast Scope Nesting State option is made dependent on the Multicast Scope List option because the information describing each scope can change, so both pieces of state must be delivered atomically in the same message to avoid inconsistency between scope identity and nesting relationships.
The Multicast Scope Nesting State option uses a bit-packed matrix representation in the interest of maximal efficiency and flexibility. A 1 in row X, column Y means 'X nests inside Y'; the diagonal is removed and each row is zero-padded to the next byte boundary, yielding N × ceil((N-1)/8) bytes for N scopes.
TTL scoping for multicast searching suffers from the split-horizon effect: when a requestor and responder are separated by many hops, large TTL values cause many nodes to hear only one side of a request/response exchange, creating regions A and C that receive only the request or only the response. Administrative scoping eliminates this by using router-enforced perimeters rather than TTL limits.
When MZAP is used for dynamic scope discovery, MADCAP servers passively eavesdrop on MZAP messages (Zone Announcement Messages and Not Inside Messages) transmitted by Zone Border Routers during normal administrative scope boundary maintenance to learn which scopes exist and which do not nest. This state must be cached within the MADCAP server.
Each MADCAP server SHOULD define two independent pieces of state for each scope pair: whether X nests inside Y, and whether Y nests inside X. The fourth nesting case (mutual nesting) SHOULD be interpreted as the two scopes sharing the same border.
If NEST_NO_DECISION_TIMER expires for state entry X/Y without any NIM received indicating X does not nest in Y, a MADCAP server MUST conclude that X nests inside Y and change X/Y from 'false' to 'true', then start the ZONES_EXIST_TIMER for X/Y. NEST_NO_DECISION_TIMER also resets X/Y='false' state to allow future true transitions if boundaries change.
If the ZONES_EXIST_TIMER expires for state entry X/Y, the server SHOULD conclude that zone X or zone Y no longer exists and SHOULD destroy both X/Y and Y/X state. The timer resets only when Zone Announcement Messages (ZAMs) have been received for both zones since the last restart.
Nesting relationship state MUST be stored in MADCAP servers, and those servers MUST allow the state to be updated as network conditions change.
The Count field in the Multicast Scope Nesting State option MUST be identical to the Count field in the preceding Multicast Scope List option. If they differ, the scope nesting state information MUST BE ignored.
The Multicast Scope Nesting State option is OPTIONAL; MADCAP servers MAY implement it and are not required to do so. Servers learn nesting information via static configuration or a protocol such as MZAP.
The Multicast Scope Nesting State option MUST only appear in ACK messages sent in response to GETINFO, and MUST NOT be included in any message that does not also carry the Multicast Scope List option.
To handle dynamic scope changes, MADCAP servers MUST include mechanisms to determine: (a) whether a nesting decision is still under consideration or is definitive, (b) whether either scope has been destroyed, and (c) whether boundaries have changed so a previous nesting relationship is now reversed. Servers MUST implement two timers: NEST_NO_DECISION_TIMER and ZONES_EXIST_TIMER.
When a MADCAP server receives a Not Inside Message (NIM) from a Zone Border Router indicating scope X does not nest in scope Y, it MUST update its internal X/Y state to 'false' and MUST restart the NEST_NO_DECISION_TIMER for that X/Y state entry.
NEST_NO_DECISION_TIMER: when MZAP is used, this value should be greater than NIM-INTERVAL + 30%, corresponding to 1800 + 30% = 2340 seconds (39 minutes). ZONES_EXIST_TIMER: when MZAP is used, this value should be no less than NIM-HOLDTIME, which defaults to 5460 seconds (91 minutes).
The Multicast Scope List option enumerates visible scopes as successive tuples, each containing: Scope ID (smallest address in the range), Last Address (largest address), TTL (to use when sending to the scope), and one or more language-specific names.
Two scopes X and Y can relate in exactly four ways: X nests inside Y, Y nests inside X, X and Y do not nest (overlap), or X and Y nest inside each other (interpreted as sharing exactly the same border, even if covering different address ranges). Indeterminate nesting state is treated as false.
The Multicast Scope Nesting State option has been assigned MADCAP option code 17 by IANA, as defined in RFC 2730.
Falsified Multicast Scope Nesting State information would cause clients to make incorrect decisions about scope ordering, leading them to use larger scopes than necessary. This effectively flattens the scope hierarchy and nullifies its benefits for scaling, but does not prevent protocols from functioning. The same security concerns applicable to MADCAP generally also apply to this option.
The Multicast Scope Nesting State option encodes: Code (16 bits, value 17), Len (16 bits, total option length in bytes), Count (8 bits, number of zones in the matrix — must match the Count in the preceding Multicast Scope List option), and a Nest State Matrix of N × ceil((N-1)/8) bytes.