rfc2908.txt

RFC 的详细文档！

      At any time during the lifetime of an existing address,
      applications may also request an extension of the lifetime, and
      such extensions will be granted when possible.  When the address
      extension is not granted, the application is expected to request a
      new address to take over from the old address when it expires, and
      to be able to cope with this situation gracefully.  As with
      unicast addresses, no guarantee of reachability of an address is
      provided by the network once the lifetime expires.

      These restrictions on address lifetime are necessary to allow the
      address allocation architecture to be organized around address
      usage patterns in a manner that ensures addresses are aggregatable
      and multicast routing is reasonably close to optimal.  In
      contrast, statically allocated addresses may be given sub-optimal
      routing.

3.  Overview of the Architecture

   The architecture is modular so that each layer may be used, upgraded,
   or replaced independently of the others.  Layering also provides
   isolation, in that different mechanisms at the same layer can be used
   by different organizations without adversely impacting other layers.

   There are three layers in this architecture (Figure 1).  Note that
   these layer numbers are different from the layer numbers in the
   TCP/IP stack, which describe the path of data packets.










Thaler, et al.               Informational                      [Page 5]

RFC 2908                  MALLOC Architecture             September 2000


   +--------------------------+         +------------------------+
   |                          |         |                        |
   |       to other peers     |         |   to other peers       |
   |          ||   //         |         |      ||  //   ||       |
   |          Prefix          |         |    Prefix     Prefix   |
   |       Coordinator        |         |Coordinator  Coordinator|
   +------------||------------+         +-------||----//---------+
                ||Layer 3                       ||   //
   +------------||------------------------------||--//-----------+
   |          Prefix                          Prefix             |
   |       Coordinator=======================Coordinator         |
   |             ^                              ^                |
   |             +----------------+-------------+                |
   |             |       Layer 2  |             |                |
   |     MAAS<---/                |             +---> MAAS       |
   |     ^   ^                    v                    ^         |
   |     .    .                 MAAS                   .         |
   |     .     .Layer 1           ^                    .Layer 1  |
   |     v      v                 .Layer 1             v         |
   | Client   Client              v                 Client       |
   |                           Client                            |
   +-------------------------------------------------------------+

  Figure 1: An Overview of the Multicast Address Allocation Architecture

   Layer 1
      A protocol or mechanism that a multicast client uses to request a
      multicast address from a multicast address allocation server
      (MAAS).  When the server grants an address, it becomes the
      server's responsibility to ensure that this address is not then
      reused elsewhere within the address's scope during the lifetime
      granted.

      Examples of possible protocols or mechanisms at this layer include
      MADCAP [4], HTTP to access a web page for allocation, and IANA
      static address assignments.

      An abstract API for applications to use for dynamic allocation,
      independent of the Layer 1 protocol/mechanism in use, is given in
      [11].

   Layer 2
      An intra-domain protocol or mechanism that MAAS's use to
      coordinate allocations to ensure they do not allocate duplicate
      addresses.  A MAAS must have stable storage, or some equivalent
      robustness mechanism, to ensure that uniqueness is preserved
      across MAAS failures and reboots.




Thaler, et al.               Informational                      [Page 6]

RFC 2908                  MALLOC Architecture             September 2000


      MAASs also use the Layer 2 protocol/mechanism to acquire (from
      "Prefix Coordinators") the ranges of multicast addresses out of
      which they may allocate addresses.

      In this document we use the term "allocation domain" to mean an
      administratively scoped multicast-capable region of the network,
      within which addresses in a specific range may be allocated by a
      Layer 2 protocol/mechanism.

      Examples of protocols or mechanisms at this layer include AAP [5],
      and manual configuration of MAAS's.

   Layer 3
      An inter-domain protocol or mechanism that allocates multicast
      address ranges (with lifetimes) to Prefix Coordinators.
      Individual addresses may then be allocated out of these ranges by
      MAAS's inside allocation domains as described above.

      Examples of protocols or mechanisms at this layer include MASC [6]
      (in which Prefix Coordinators are typically routers without any
      stable storage requirement), and static allocations by AS number
      as described in [10] (in which Prefix Coordinators are typically
      human administrators).

   Each of the three layers serves slightly different purposes and as
   such, protocols or mechanisms at each layer may require different
   design tradeoffs.

4.  Scoping

   To allocate dynamic addresses within administrative scopes, a MAAS
   must be able to learn which scopes are in effect, what their address
   ranges and names are, and which addresses or subranges within each
   scope are valid for dynamic allocation by the MAAS.

   The first two tasks, learning the scopes in effect and the address
   range and name(s) of each scope, may be provided by static
   configuration or dynamically learned.  For example, a MAAS may simply
   passively listen to MZAP [9] messages to acquire this information.

   To determine the subrange for dynamic allocation, there are two cases
   for each scope, corresponding to small "indivisible" scopes, and big
   "divisible" scopes.  Note that MZAP identifies which scopes are
   divisible and which are not.

   (1) For small scopes, the allocation domain corresponds to the entire
       topology within the administrative scope.  Hence, all MAASs
       inside the scope may use the entire address range (minus the last



Thaler, et al.               Informational                      [Page 7]

RFC 2908                  MALLOC Architecture             September 2000


       256 addresses reserved as scope-relative addresses), and use the
       Layer 2 mechanism/protocol to coordinate allocations.  For small
       scopes, Prefix Coordinators are not involved.

       Hence, for small scopes, the effective "allocation domain" area
       may be different for different scopes.  Note that a small,
       indivisible scope could be larger or smaller than the Allocation
       Scope used for big scopes (see below).

   (2) For big scopes (including the global scope), the area inside the
       scope may be large enough that simply using a Layer 2
       mechanism/protocol may be inefficient or otherwise undesirable.
       In this case, the scope must span multiple allocation domains,
       and the Layer 3 mechanism/protocol must be used to divvy up the
       scoped address space among the allocation domains.  Hence, a MAAS
       may learn of the scope via MZAP, but must acquire a subrange from
       which to allocate from a Prefix Coordinator.

       For simplicity, the effective "allocation domain" area will be
       the same for all big scopes, being the granularity at which all
       big scopes are divided up.  We define the administrative scope at
       this granularity to be the "Allocation Scope".

4.1.  Allocation Scope

   The Allocation Scope is a new administrative scope, defined in this
   document and to be reserved by IANA with values as noted below.  This
   is the scope that is used by a Layer 2 protocol/mechanism to
   coordinate address allocation for addresses in larger, divisible
   scopes.

   We expect that the Allocation Scope will often coincide with a
   unicast Autonomous System (AS) boundary.

   If an AS is too large, or the network administrator wishes to run
   different intra-domain multicast routing in different parts of an AS,
   that AS can be split by manual setup of an allocation scope boundary
   that is not an AS boundary.  This is done by setting up a multicast
   boundary dividing the unicast AS into two or more multicast
   allocation domains.

   If an AS is too small, and address space is scarce, address space
   fragmentation may occur if the AS is its own allocation domain.
   Here, the AS can instead be treated as part of its provider's
   allocation domain, and use a Layer 2 protocol/mechanism to coordinate
   allocation between its MAAS's (if any) and those of its provider.  An
   AS should probably take this course of action if:




Thaler, et al.               Informational                      [Page 8]

RFC 2908                  MALLOC Architecture             September 2000


   o  it is connected to a single provider,

   o  it does not provide transit for another AS, and

   o  it needs fewer than (say) 256 multicast addresses of larger than
      AS scope allocated on average.

4.1.1.  The IPv4 Allocation Scope -- 239.251.0.0/16

   The address space 239.251.0.0/16 is to be reserved for the Allocation
   Scope.  The ranges 239.248.0.0/16, 239.249.0.0/16 and 239.250.0.0/16
   are to be left unassigned and available for expansion of this space.
   These ranges should be left unassigned until the 239.251.0.0/16 space
   is no longer sufficient.

4.1.2.  The IPv6 Allocation Scope -- SCOP 6

   The IPv6 "scop" value 6 is to be used for the Allocation Scope.

5.  Overview of the Allocation Process

   Once Layer 3 allocation has been performed for large, divisible
   scopes, and each Prefix Coordinator has acquired one or more ranges,
   then those ranges are passed to all MAAS's within the Prefix
   Coordinator's domain via a Layer 2 mechanism/protocol.

   MAAS's within the domain receive these ranges and store them as the
   currently allowable addresses for that domain.  Each range is valid
   for a given lifetime (also acquired via the Layer 3
   mechanism/protocol) and is not revoked before the lifetime has
   expired.  MAAS's also learn of small scopes (e.g., via MZAP) and
   store the ranges associated with them.

   Using the Layer 2 mechanism/protocol, each MAAS ensures that it will