MADCAP Multicast Scope Nesting State Option
RFC 2907

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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