rfc2907.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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