MADCAP Multicast Scope Nesting State Option
RFC 2907
|
Document |
Type |
|
RFC - Proposed Standard
(September 2000; No errata)
|
|
Author |
|
Roger Kermode
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2907 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text