rfc2908.txt

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

Network Working Group                                         D. Thaler
Request for Comments: 2908                                    Microsoft
Category: Informational                                      M. Handley
                                                                  ACIRI
                                                              D. Estrin
                                                                    ISI
                                                         September 2000


         The Internet Multicast Address Allocation Architecture

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document proposes a multicast address allocation architecture
   (MALLOC) for the Internet.  The architecture is modular with three
   layers, comprising a host-server mechanism, an intra-domain server-
   server coordination mechanism, and an inter-domain mechanism.

Table of Contents

   1: Introduction ................................................  2
   2: Requirements ................................................  2
   3.1: Address Dynamics ..........................................  4
   3: Overview of the Architecture ................................  5
   4: Scoping .....................................................  7
   4.1: Allocation Scope ..........................................  8
   4.1.1: The IPv4 Allocation Scope -- 239.251.0.0/16 .............  9
   4.1.2: The IPv6 Allocation Scope -- SCOP 6 .....................  9
   5: Overview of the Allocation Process ..........................  9
   6: Security Considerations ..................................... 10
   7: Acknowledgments ............................................. 11
   8: References .................................................. 11
   9: Authors' Addresses .......................................... 12
   10: Full Copyright Statement ................................... 13







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


1.  Introduction

   This document proposes a multicast address allocation architecture
   (MALLOC) for the Internet, and is intended to be generic enough to
   apply to both IPv4 and IPv6 environments.

   As with unicast addresses, the usage of any given multicast address
   is limited in two dimensions:

   Lifetime:
      An address has a start time and a (possibly infinite) end time,
      between which it is valid.

   Scope:
      An address is valid over a specific area of the network.  For
      example, it may be globally valid and unique, or it may be a
      private address which is valid only within a local area.

   This architecture assumes that the primary scoping mechanism in use
   is administrative scoping, as described in RFC 2365 [1].  While
   solutions that work for TTL scoping are possible, they introduce
   significant additional complication for address allocation [2].
   Moreover, TTL scoping is a poor solution for multicast scope control,
   and our assumption is that usage of TTL scoping will decline before
   this architecture is widely used.

2.  Requirements

   From a design point of view, the important properties of multicast
   allocation mechanisms are robustness, timeliness, low probability of
   clashing allocations, and good address space utilization in
   situations where space is scare.  Where this interacts with multicast
   routing, it is desirable for multicast addresses to be allocated in a
   manner that aids aggregation of routing state.

   o  Robustness/Availability

      The robustness requirement is that an application requiring the
      allocation of an address should always be able to obtain one, even
      in the presence of other network failures.

   o  Timeliness

      From a timeliness point of view, a short delay of up to a few
      seconds is probably acceptable before the client is given an
      address with reasonable confidence in its uniqueness.  If the
      session is defined in advance, the address should be allocated as
      soon as possible, and should not wait until just before the



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


      session starts.  It is in some cases acceptable to change the
      multicast addresses used by the session up until the time when the
      session actually starts, but this should only be done when it
      averts a significant problem such as an address clash that was
      discovered after initial session definition.

   o  Low Probability of Clashes

      A multicast address allocation scheme should always be able to
      allocate an address that can be guaranteed not to clash with that
      of another session.  A top-down partitioning of the address space
      would be required to completely guarantee that no clashes would
      occur.

   o  Address Space Packing in Scarcity Situations

      In situations where address space is scarce, simply partitioning
      the address space would result in significant fragmentation of the
      address space.    This is because one would need enough spare
      space in each address space partition to give a reasonable degree
      of assurance that addresses could still be allocated for a
      significant time in the event of a network partition.  In
      addition, providing backup allocation servers in such a hierarchy,
      so that fail-over (including partitioning of a server and its
      backup from each other) does not cause collisions would add
      further to the address space fragmentation.

      Since guaranteeing no clashes in a robust manner requires
      partitioning the address space, providing a hard guarantee leads
      to inefficient address space usage.  Hence, when address space is
      scarce, it is difficult to achieve constant availability and
      timeliness, guarantee no clashes, and achieve good address space
      usage.  As a result, we must prioritize these properties.  We
      believe that, when address space is scarce, achieving good address
      space packing and constant availability are more important than
      guaranteeing that address clashes never occur.  What we aim for in
      these situations is a very high probability that an address clash
      does not occur, but we accept that there is a finite probability
      of this happening.  Should a clash occur (or should an application
      start using an address it did not allocate, which may also lead to
      a clash), either the clash can be detected and addresses changed,
      or hosts receiving additional traffic can prune that traffic using
      source-specific prunes available in IGMP version 3, and so we do
      not believe that this is a disastrous situation.

      In summary, tolerating the possibility of clashes is likely to
      allow allocation of a very high proportion of the address space in
      the presence of network conditions such as those observed in [3].



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


      We believe that we can get good packing and good availability with
      good collision avoidance, while we would have to compromise
      packing and availability significantly to avoid all collisions.

      Finally, in situations where address space is not scarce, such as
      with IPv6, achieving good address space usage is less important,
      and hence partitioning may potentially be used to guarantee no
      collisions among hosts that use this architecture.

2.1.  Address Dynamics

   Multicast addresses may be allocated in any of three ways:

   Static:
      Statically allocated addresses are allocated by IANA for specific
      protocols that require well-known addresses to work.  Examples of
      static addresses are 224.0.1.1 which is used for the Network Time
      Protocol [13] and 224.2.127.255 which is used for global scope
      multicast session announcements.  Applications that use multicast
      for bootstrap purposes should not normally be given their own
      static multicast address, but should bootstrap themselves using a
      well-known service location address which can be used to announce
      the binding between local services and multicast addresses.

      Static addresses typically have a permanent lifetime, and a scope
      defined by the scope range in which they reside.  As such, a
      static address is valid everywhere (although the set of receivers
      may be different depending on location), and may be hard-coded
      into applications, devices, embedded systems, etc.  Static
      addresses are also useful for devices which support sending but
      not receiving multicast IP datagrams (Level 1 conformance as
      specified in RFC 1112 [7]), or even are incapable of receiving any
      data at all, such as a wireless broadcasting device.

   Scope-relative:
      RFC 2365 [1] reserves the highest 256 addresses in every
      administrative scope range for relative assignments.  Relative
      assignments are made by IANA and consist of an offset which is
      valid in every scope.  Relative addresses are reserved for
      infrastructure protocols which require an address in every scope,
      and this offset may be hard-coded into applications, devices,
      embedded systems, etc.  Such devices must have a way (e.g. via
      MZAP [9] or via MADCAP [4]) to obtain the list of scopes in which
      they reside.







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


      The offsets assigned typically have a permanent lifetime, and are
      valid in every scope and location.  Hence, the scope-relative
      address in a given scope range has a lifetime equal to that of the
      scope range in which it falls.

   Dynamic:
      For most purposes, the correct way to use multicast is to obtain a
      dynamic multicast address.  These addresses are provided on demand
      and have a specific lifetime.  An application should request an
      address only for as long as it expects to need the address.  Under
      some circumstances, an address will be granted for a period of
      time that is less than the time that was requested.  This will
      occur rarely if the request is for a reasonable amount of time.
      Applications should be prepared to cope with this when it occurs.

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