rfc2907.txt

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

         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.




Kermode                     Standards Track                     [Page 7]

RFC 2907      MADCAP Multicast Scope Nesting State Option September 2000


   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.



Kermode                     Standards Track                     [Page 8]

RFC 2907      MADCAP Multicast Scope Nesting State Option September 2000


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  |
      +-----+-----+-----+-----+-----+-----+-...-+-----+




Kermode                     Standards Track                     [Page 9]

RFC 2907      MADCAP Multicast Scope Nesting State Option September 2000


   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).











Kermode                     Standards Track                    [Page 10]

RFC 2907      MADCAP Multicast Scope Nesting State Option September 2000


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.








Kermode                     Standards Track                    [Page 11]

RFC 2907      MADCAP Multicast Scope Nesting State Option September 2000


   [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: [e-mail]






























Kermode                     Standards Track                    [Page 12]

RFC 2907      MADCAP Multicast Scope Nesting State Option September 2000


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.



















Kermode                     Standards Track                    [Page 13]