rfc2102.txt

RFC 的详细文档！

Network Working Group                                     R. Ramanathan
Request for Comments: 2102                 BBN Systems and Technologies
Category: Informational                                   February 1997


  Multicast Support for Nimrod :  Requirements and Solution Approaches


Status of this Memo

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

Abstract

   Nimrod does not specify a particular solution for multicasting.
   Rather, Nimrod may use any of a number of emerging multicast
   techniques.  We identify the requirements that Nimrod has of a
   solution for multicast support.  We compare existing approaches for
   multicasting within an internetwork and discuss their advantages and
   disadvantages.  Finally, as an example, we outline the mechanisms to
   support multicast in Nimrod using the scheme currently being
   developed within the IETF - namely, the Protocol Indpendent Multicast
   (PIM) protocol.

Table of Contents

   1  Introduction.................................................  2
   2  Multicast vs Unicast.........................................  3
   3  Goals and Requirements.......................................  4
   4  Approaches...................................................  6
   5  A Multicasting Scheme based on PIM........................... 10
      5.1 Overview ................................................ 10
      5.2 Joining and Leaving a Tree .............................. 12
          5.2.1 An Example ........................................ 15
      5.3 Establishing a Shared Tree .............................. 16
      5.4 Switching to a Source-Rooted Shortest Path Tree.......... 18
      5.5 Miscellaneous Issues..................................... 20
   6  Security Considerations...................................... 21
   7  Summary...................................................... 21
   8  References................................................... 22
   9  Acknowledgements............................................. 23
   10 Author's Address............................................. 23







Ramanathan                   Informational                      [Page 1]

RFC 2102                Nimrod Multicast Support           February 1997


1  Introduction

   The nature of emerging applications such as videoconferencing, remote
   classroom, etc.  makes the support for multicasting essential for any
   future routing architecture.  Multicasting is performed by using a
   multicast delivery tree whose leaves are the multicast destinations.

   Nimrod does not propose a solution for the multicasting problem.
   There are two chief reasons for this.  First, multicasting is a non-
   trivial problem whose requirements are still not well understood.
   Second, a number of groups (for instance the IDMR working group of
   the IETF) are studying the problem by itself and it is not our
   intention to duplicate those efforts.

   This attitude towards multicasting is consistent with Nimrod's
   general philosophy of flexibility, adaptability and incremental
   change.

   While a multicasting solution per se is not part of the "core" Nimrod
   architecture, Nimrod does require that the solution have certain
   characteristics.  It is the purpose of this document to discuss some
   of these requirements and evaluate approaches towards meeting them.

   This document is organized as follows.  In section 2 we discuss why
   multicasting is treated a little differently than unicast despite the
   fact that the former is essentially a generalization of the latter.
   Following that, in section 4 we discuss current approaches toward
   multicasting .  In section 5, we give an example of how Nimrod
   multicasting may be done using PIM [DEF+94a].  For readers who do not
   have the time to go through the entire document, a summary is given
   at the end.

   This document uses many terms and concepts from the Nimrod
   Architecture document [CCS96] and some terms and concepts (in section
   5) from the Nimrod Functionality document [RS96].  Much of the
   discussion assumes that you have read at least the Nimrod
   Architecture document [CCS96].














Ramanathan                   Informational                      [Page 2]

RFC 2102                Nimrod Multicast Support           February 1997


2  Multicast vs Unicast

   We begin by looking at the similarities and differences between
   unicast routing and multicast routing.  Both unicast and multicast
   routing require two phases - route generation and packet forwarding.
   In the case of unicast routing, Nimrod specifies modes of packet
   forwarding; route generation itself is not specified but left to the
   particular routing agent.  For multicasting, Nimrod leaves both route
   generation and packet forwarding mechanisms unspecified.  To explain
   why, we first point out three aspects that make multicasting quite
   different from unicasting :

o Groups and group dynamism.  In multicasting, the destinations are part
  of a group, whose membership is dynamic.  This brings up the following
  issues :

  -  An association between the multicast group and the EIDs and
     locators of the members comprising that group.  This is especially
     relevant in the case of sender initiated multicasting and policy
     support.

  -  A mechanism to accommodate new group members in the delivery in
     response to addition of members, and a mechanism to "prune" the
     delivery in response to departures.

o State creation.  Most solutions to multicasting can essentially be
  viewed as creating state in routers for multicast packet forwarding.
  Based on who creates the state, multicasting solutions differ.  In
  multicasting, we have several options for this - e.g., the sender, the
  receivers or the intermediate routers.

o Route generation.  Even more so than in unicast routing, one can choose
  from a rich spectrum of heuristics with different tradeoffs between a
  number of parameters (such as cost and delay, algorithmic time
  complexity and optimality etc.).  For instance, some heuristics produce
  a low-cost tree with high end-to-end delay and some produce trees that
  give the shortest path to each destination but with a higher cost.
  Heuristics for multicasting are a significant research area today, and
  we expect advances to result in sophisticated heuristics in the near
  future.

   Noting that there are various possible combinations of route
   generation, group dynamism handling and state creation for a solution
   and that each solution conceivably has applications for which it is
   the most suitable, we do not specify one particular approach to
   multicasting in Nimrod.  Every implementation of Nimrod is free to
   use its own multicasting technique, as long as it meets the goals and
   requirements of Nimrod.  However, for interoperability, it is



Ramanathan                   Informational                      [Page 3]

RFC 2102                Nimrod Multicast Support           February 1997


   necessary that certain things are agreed upon - for instance, the
   structure of the forwarding information database that they create (we
   discuss this in more detail in section 4).

   Thus, we do not discuss the details of any multicast solution here,
   only its requirements in the context of Nimrod.  Specifically, we
   structure the discussion in the remainder of this document on the
   following two themes :

  o What are the goals that we want to meet in providing multicasting in
    Nimrod, and what specific requirements do these goals imply for the
    multicast solution?

  o What are some of the approaches to multicasting being discussed
    currently, and how relevant are each of these approaches to Nimrod?

3  Goals and Requirements

   The chief goals of Nimrod multicasting and their implications on
   solution requirements are as follows:

1. Scalability.  Nimrod multicasting must scale in terms of the size of
   the internetwork, the number of groups supported and the number of
   members per group.  It must also support group dynamism efficiently.
   This has the following implications for the solution:

   o Routers not on the direct path to the multicast destinations should
     not be involved in state management.  In a network with a large
     number of routers, a solution that does involve such routers is
     unlikely to scale.

   o It is likely that there will be a number of applications that have
     a few members per group (e.g., medical imaging) and a number of
     applications that have a large number of members per group (e.g.,
     news distribution).  Nimrod multicasting should scale for both
     these situations.  If no single mechanism adequately scales for
     both sparse and dense group memberships simultaneously, a
     combination of mechanisms should be considered.

   o In the face of group membership change, there must be a facility
     for incremental addition or deletion of "branches" in the
     multicast tree.  Reconstructing the tree from scratch is not likely
     to scale.








Ramanathan                   Informational                      [Page 4]

RFC 2102                Nimrod Multicast Support           February 1997


   o It is likely that we will have some well-known groups (i.e., groups
     which are more or less permanent in existence) and some ephemeral
     groups.  The dynamics of group membership are likely to be
     different for each class of groups, and the solution should take
     that into account as appropriate.

2. Policy support.  This includes both quality of service (QOS) as
   well as access restrictions, although currently, demand is probably
   higher for QOS. In particular, every path from a source to each
   destination in the multicast group should satisfy the requested
   quality of service and conform to the access restrictions.  The
   implications for the multicasting solution are :

  o It is likely that many multicasting applications will be cost
    conscious in addition to having strict quality of service bounds
    (such as delay and jitter).  Balancing these will necessitate
    dealing with some new parameters - e.g., the tree cost (sum of the
    "cost" of each link), the tree delay (maximum, mean and variance
    in end-to-end delay) etc.

  o In order to support policy-based routing, we need to know where the
    destinations are (so that we can decide what route we can take to
    them).  In such a case, a mechanism that provides an association
    between a group id and a set of destination locators is probably
    required.

  o Some policy constraints are likely to be destination specific.  For
    instance, a domain might refuse transit service to traffic going to
    certain destination domains.  This presents certain unique problems
    - in particular, for a single group, multiple trees may need to be
    built, each tree "servicing" disjoint partitions of the multicast
    destinations.

3. Resource sharing.  Multicasting typically goes hand in hand with large
   traffic volume or applications with a high demand for resources.
   These, in turn, imply efficient resource management and sharing if
   possible.  Therefore, it is important that we place an emphasis on
   interaction with resource reservation.  For instance, Nimrod must be
   able to provide information on which tree resources are shareable and
   which are not so that resource reservation may use it while allocating
   resources to flows.

4. Interoperability.  There are two issues in this context.  First, the
   solution must be independent of mechanisms that provide the solution
   with information it needs.  For instance, many multicast solutions
   (e.g., PIM) make use of information supplied by unicast routing
   protocols.  The multicast solution must not be dependent on which
   unicast protocol is used.



Ramanathan                   Informational                      [Page 5]

RFC 2102                Nimrod Multicast Support           February 1997


   Second, a multicast solution must interoperate with other multicast
   solutions in the construction of a delivery tree.  This implies some
   kind of "agreement" at some "level".  For instance, the agreement
   could be that everybody use the same structure for storing forwarding
   information in the routers.  Since the delivery tree is defined by the
   nature of forwarding information in the routers and not by the
   particular mechanism used to create that information, multiple
   implementations can coexist.

4  Approaches

   The approaches to multicasting currently in operation and those being
   considered by the IETF include the following :

1. Distance vector multicast routing protocol (DVMRP)[DC90].  This
   approach is based upon distance-vector routing information distribution
   and hop-by-hop forwarding.  It uses Reverse Path Forwarding (RPF)[DM78]
   - a distributed algorithm for constructing an internetwork broadcast
   tree.  DVMRP uses a modified RPF algorithm, essentially a truncated
   broadcast tree, to build a reverse shortest path sender-based multicast
   delivery tree.  A reverse shortest path from s to d is a path that uses
   the same intermediate nodes as those in the shortest path from d to
   s (If the paths are symmetric (i.e., cost the same) in either
   direction, the reverse shortest path is same as the shortest path.)
   An implementation of RPF exists in the current Internet in what
   is commonly referred to as the MBONE. An improvement to this is in the
   process of being deployed.  It incorporates "prune" messages to
   truncate further the routers not on the path to the destinations and
   "graft" messages to undo this truncation, if later necessary.

   The main advantage of this scheme is that it is simple.  The major
   handicap is scalability.  Two issues have been raised in this
   context[BFC93].  First, if S is the number of active sources and G
   the number of groups, then the state overhead is O(GS) and might be
   unacceptable when resources are limited.  Second, routers not on a
   multicast tree are involved (in terms of sending/tracking prune and
   graft messages) even though they might not be interested in the