rfc2776.txt

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

Network Working Group                                         M. Handley
Request for Comments: 2776                                         ACIRI
Category: Standards Track                                      D. Thaler
                                                               Microsoft
                                                              R. Kermode
                                                                Motorola
                                                           February 2000


           Multicast-Scope Zone Announcement Protocol (MZAP)

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 protocol, the Multicast-Scope Zone
   Announcement Protocol (MZAP), for discovering the multicast
   administrative scope zones that are relevant at a particular
   location.  MZAP also provides mechanisms whereby common
   misconfigurations of administrative scope zones can be discovered.

Table of Contents

   1 Introduction ................................................  2
   2 Terminology .................................................  4
   3 Overview ....................................................  5
   3.1 Scope Nesting .............................................  6
   3.2 Other Messages ............................................  7
   3.3 Zone IDs ..................................................  7
   4 Detecting Router Misconfigurations ..........................  8
   4.1 Detecting non-convex scope zones ..........................  8
   4.2 Detecting leaky boundaries for non-local scopes ...........  9
   4.3 Detecting a leaky Local Scope zone ........................ 10
   4.4 Detecting conflicting scope zones ......................... 10
   5 Packet Formats .............................................. 11
   5.1 Zone Announcement Message ................................. 14
   5.2 Zone Limit Exceeded (ZLE) ................................. 15
   5.3 Zone Convexity Message .................................... 15



Handley, et al.             Standards Track                     [Page 1]

RFC 2776                          MZAP                     February 2000


   5.4 Not-Inside Message ........................................ 16
   6 Message Processing Rules .................................... 17
   6.1 Internal entities listening to MZAP messages .............. 17
   6.2 Sending ZAMs .............................................. 18
   6.3 Receiving ZAMs ............................................ 18
   6.4 Sending ZLEs .............................................. 20
   6.5 Receiving ZLEs ............................................ 20
   6.6 Sending ZCMs .............................................. 21
   6.7 Receiving ZCMs ............................................ 21
   6.8 Sending NIMs .............................................. 21
   6.9 Receiving NIMs ............................................ 22
   7 Constants ................................................... 22
   8 Security Considerations ..................................... 23
   9 Acknowledgements ............................................ 24
   10 References ................................................. 25
   11 Authors' Addresses ......................................... 26
   12 Full Copyright Statement ................................... 27

1.  Introduction

   The use of administratively-scoped IP multicast, as defined in RFC
   2365 [1], allows packets to be addressed to a specific range of
   multicast addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4)
   such that the packets will not cross configured administrative
   boundaries, and also allows such addresses to be locally assigned and
   hence are not required to be unique across administrative boundaries.
   This property of logical naming both allows for address reuse, as
   well as provides the capability for infrastructure services such as
   address allocation, session advertisement, and service location to
   use well-known addresses which are guaranteed to have local
   significance within every organization.

   The range of administratively-scoped addresses can be subdivided by
   administrators so that multiple levels of administrative boundaries
   can be simultaneously supported.  As a result, a "multicast scope" is
   defined as a particular range of addresses which has been given some
   topological meaning.

   To support such usage, a router at an administrative boundary is
   configured with one or more per-interface filters, or "multicast
   scope boundaries".  Having such a boundary on an interface means that
   it will not forward packets matching a configured range of multicast
   addresses in either direction on the interface.

   A specific area of the network topology which is within a boundary
   for a given scope is known as a "multicast scope zone".  Since the
   same ranges can be reused within disjoint areas of the network, there
   may be many "multicast scope zones" for any given multicast scope.  A



Handley, et al.             Standards Track                     [Page 2]

RFC 2776                          MZAP                     February 2000


   scope zone may have zero or more textual names (in different
   languages) for the scope, for human convenience.  For example, if the
   range 239.192/14 were assigned to span an entire corporate network,
   it might be given (internally) the name "BigCo Private Scope".

   Administrative scope zones may be of any size, and a particular host
   may be within many administrative scope zones (for different scopes,
   i.e., for non-overlapping ranges of addresses) of various sizes, as
   long as scope zones that intersect topologically do not intersect in
   address range.

   Applications and services are interested in various aspects of the
   scopes within which they reside:

   o  Applications which present users with a choice of which scope in
      which to operate (e.g., when creating a new session, whether it is
      to be confined to a corporate intranet, or whether it should go
      out over the public Internet) are interested in the textual names
      which have significance to users.

   o  Services which use "relative" multicast addresses (as defined in
      [1]) in every scope are interested in the range of addresses used
      by each scope, so that they can apply a constant offset and
      compute which address to use in each scope.

   o  Address allocators are interested in the address range, and
      whether they are allowed to allocate addresses within the entire
      range or not.

   o  Some applications and services may also be interested in the
      nesting relationships among scopes.  For example, knowledge of the
      nesting relationships can be used to perform "expanding-scope"
      searches in a similar, but better behaved, manner to the well-
      known expanding ring search where the TTL of a query is steadily
      increased until a replier can be found.  Studies have also shown
      that nested scopes can be useful in localizing multicast repair
      traffic [8].

   Two barriers currently make administrative scoping difficult to
   deploy and use:

   o  Applications have no way to dynamically discover information on
      scopes that are relevant to them.  This makes it difficult to use
      administrative scope zones, and hence reduces the incentive to
      deploy them.






Handley, et al.             Standards Track                     [Page 3]

RFC 2776                          MZAP                     February 2000


   o  Misconfiguration is easy.  It is difficult to detect scope zones
      that have been configured so as to not be convex (the shortest
      path between two nodes within the zone passes outside the zone),
      or to leak (one or more boundary routers were not configured
      correctly), or to intersect in both area and address range.

   These two barriers are addressed by this document.  In particular,
   this document defines the Multicast Scope Zone Announcement Protocol
   (MZAP) which allows an entity to learn what scope zones it is within.
   Typically servers will cache the information learned from MZAP and
   can then provide this information to applications in a timely fashion
   upon request using other means, e.g., via MADCAP [9].  MZAP also
   provides diagnostic information to the boundary routers themselves
   that enables misconfigured scope zones to be detected.

2.  Terminology

   The "Local Scope" is defined in RFC 2365 [1] and represents the
   smallest administrative scope larger than link-local, and the
   associated address range is defined as 239.255.0.0 to 239.255.255.255
   inclusive (for IPv4, FF03::/16 for IPv6).  RFC 2365 specifies:

      "239.255.0.0/16 is defined to be the IPv4 Local Scope.  The Local
      Scope is the minimal enclosing scope, and hence is not further
      divisible. Although the exact extent of a Local Scope is site
      dependent, locally scoped regions must obey certain topological
      constraints. In particular, a Local Scope must not span any other
      scope boundary. Further, a Local Scope must be completely
      contained within or equal to any larger scope. In the event that
      scope regions overlap in area, the area of overlap must be in its
      own Local Scope.  This implies that any scope boundary is also a
      boundary for the Local Scope."

   A multicast scope Zone Boundary Router (ZBR) is a router that is
   configured with a boundary for a particular multicast scope on one or
   more of its interfaces.  Any interface that is configured with a
   boundary for any administrative scope zone MUST also have a boundary
   for the Local Scope zone, as described above.

   Such routers SHOULD be configured so that the router itself is within
   the scope zone.  This is shown in Figure 1(a), where router A is
   inside the scope zone and has the boundary configuration.









Handley, et al.             Standards Track                     [Page 4]

RFC 2776                          MZAP                     February 2000


          ............                     ................
         .            .   +B+-->          .                *B+-->
        .              . /               .                / .
       .                *               .                +   .
       .          <---+A*---+C+->       .          <---+A+---*C+->
       .              + .               .              +     .
       .             /  .               .             /      .
        . zone X  <--  .                 . zone X  <--      .
         ..............                   ..................

        A,B,C - routers    * - boundary interface    + - interface

       (a) Correct zone boundary         (b) Incorrect zone boundary

          Figure 1: Administrative scope zone boundary placement

   It is possible for the first router outside the scope zone to be
   configured with the boundary, as illustrated in Figure 1(b) where
   routers B and C are outside the zone and have the boundary
   configuration, whereas A does not, but this is NOT RECOMMENDED.  This
   rule does not apply for Local Scope boundaries, but applies for all
   other boundary routers.

   We next define the term "Zone ID" to mean the lowest IP address used
   by any ZBR for a particular zone for sourcing MZAP messages into that
   scope zone.  The combination of this IP address and the first
   multicast address in the scope range serve to uniquely identify the
   scope zone.  Each ZBR listens for messages from other ZBRs for the
   same boundary, and can determine the Zone ID based on the source
   addresses seen.  The Zone ID may change over time as ZBRs come up and
   down.

   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 [2].

   Constants used by this protocol are shown as [NAME-OF-CONSTANT], and
   summarized in section 7.

3.  Overview

   When a ZBR is configured correctly, it can deduce which side of the
   boundary is inside the scope zone and which side is outside it.

   Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for
   each zone for which it is configured as a boundary into that scope
   zone, containing information on the scope zone's address range, Zone
   ID, and textual names.  These messages are multicast to the well-



Handley, et al.             Standards Track                     [Page 5]

RFC 2776                          MZAP                     February 2000


   known address [MZAP-LOCAL-GROUP] in the Local Scope, and are relayed
   across Local Scope boundaries into all Local Scope zones within the
   scope zone referred to by the ZAM message, as shown in Figure 2.

    ###########################
    # Zone1      =      Zone2 #    ##### = large scope zone boundary
    *E-----+--->A*-----+-x    #
    #      |     =     v      #    ===== = Local Scope boundaries
    #      |     ======*===*==#
    #      |     =     B   F  #    ----> = path of ZAM originated by E
   G*<-----+--->C*->   |   ^  #
    #      v     =   <-+---+  #    ABCDE = ZBRs
    #      D     =      Zone3 #
    #######*###################        * = boundary interface

                   Figure 2: ZAM Flooding Example

   Any entity can thus listen on a single well-known group address and