rfc2102.txt

RFC 的详细文档！

   particular source-group pair.  The performance of this scheme is
   expected to be relatively poor for large networks with sparsely
   distributed group membership.  Furthermore, no support for policies
   or QOS is provided.

2. Core Based Trees (CBT)[BFC93].  This scheme uses a single tree shared
   by all sources per group.  This tree has a single router as the core
   (with additional routers for robustness) from which branches emanate.
   The chief distinguishing characteristic of CBT is that it is receiver
   initiated, i.e., receivers wishing to join a multicast group find the
   tree (or its core) and attach themselves to it, without any



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


   participation from the sources.

   The chief motivation behind this scheme is the reduction of the state
   overhead, to O(G), in comparison to DVMRP and PIM(described below).
   Also, only routers in the path between the core and the potential
   members are involved in the process.  Core-based tree formation and
   packet flow are decoupled from underlying unicast routing.

   The main disadvantage is that packets no longer traverse the shortest
   path from the source to their destinations.  The performance in
   general depends on judicious placement of cores and coordination
   between them.  Traffic concentration on links incident to the core is
   another problem.  There is also a dependence on network entities (in
   other administrative domains, for instance) for resource reservation
   and policy routing.

3. Protocol Independent Multicasting (PIM)[DEFJ93].  Yet another approach
   based on the receiver initiated philosophy, this is designed to reap
   the advantages of DVMRP and CBT. Using a "rendezvous point", a
   concept similar to the core discussed above, it allows for the
   simultaneous existence of shared and source-specific multicast trees.
   In the steady state, data can be delivered over the reverse shortest
   path from the sender to the receiver (for better end-to-end delay) or
   over the shared tree.

   Using two modes of operation, sparse and dense, this provides
   improved performance, both when the group membership in an
   internetwork is sparse and when it is dense.  It is however, a
   complex protocol.  A limitation of PIM is that the shortest paths are
   based on the reverse metrics and therefore truly "shortest" only when
   the links are symmetric.

4. Multicast Open Shortest Path First (MOSPF)[Moy92].  Unlike the
   abovementioned approaches, this is based on link-state routing
   information distribution.  The packet forwarding mechanism is
   hop-by-hop.  Since every router has complete topology information,
   every router computes the shortest path multicast tree from any
   source to any group using Dijkstra's algorithm.  If the router
   doing the computation falls within the tree computed, it can
   determine which links it must forward copies onto.











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


   MOSPF inherits advantages of OSPF and link-state distribution, namely
   localized route computation (and easy verification of loop-freedom),
   fast convergence to link-state changes etc. However, group membership
   information is sent throughout the network, including links that are
   not in the direct path to the multicast destinations.  Thus, like
   DVMRP, this is most suitable for small internetworks, that is, as an
   intra-domain routing mechanism.

5. Inter-Domain Policy Routing (IDPR)[Ste].  This approach uses
   link-state routing information distribution like MOSPF, but uses
   source-specified packet forwarding.  Using the link-state
   database, the source generates a policy multicast route to the
   destinations.  Using this, the IDPR path-setup procedure sets up
   state in intermediate entities for packet duplication and
   forwarding. The state contains information about the next-hop
   entities for the multicast flow.  When a data packet arrives,
   it is forwarded to each next hop entity obtained from the state.

   Among the advantages of this approach are its ability to support
   policy based multicast routing with ease and independence
   (flexibility) in the choice of multicasting algorithm used at the
   source.  IDPR also allows resource sharing over multiple multicast
   trees.  The major disadvantage is that it makes it relatively more
   difficult to handle group membership changes (additions and
   deletions) since such changes must be first communicated to the
   source of the tree which will then add branches appropriately.

   We now discuss the applicability of these approaches to Nimrod.
   Common to all of the approaches described is the fact that we need to
   set up state in the intermediate routers for multicast packet
   forwarding.  The approaches differ mainly on who initiates the state
   creation - the sender (e.g., IDPR, PIM), the receiver (e.g., CBT,
   PIM) or the routers themselves create state without intitiation by
   the sender or receivers (e.g., DVMRP, MOSPF).

   Nimrod should be able to accommodate both sender initiated as well as
   receiver initiated state creation for multicasting.  In the remainder
   of this section, we discuss the pros and cons of these approaches for
   Nimrod.

   Nimrod uses link-state routing information distribution (topology
   maps) and has four modes of packet forwarding - flow mode,
   Connectivity Specification Chain (CSC) mode, Connectivity
   Specification Sequence (CSS) mode and datagram mode [CCS96].







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


   An approach similar to that used in IDPR is viable for multicasting
   using the flow mode.  The source can set up state in intermediate
   routers which can then appropriately duplicate packets.  For the CSC,
   BTES and datagram modes, an approach similar to the one used in MOSPF
   is applicable.  In these situations, the advantages and disadvantages
   of these approaches in the context of Nimrod is similar to the
   advantages and disadvantages of IDPR and MOSPF respectively.

   Sender based trees can be set up using an approach similar to IDPR
   and generalizing it to an "n" level hierarchy.  A significant
   advantage of this approach is policy-based routing.  The source knows
   about the policies of nodes that care to advertise them and can
   choose a route the way it wants (i.e., not depend upon other entities
   to choose the route, as in some schemes mentioned above).  Another
   advantage is that each source can use the multicast route generation
   algorithm and packet forwarding scheme that best suits it, instead of
   being forced to use whatever is implemented elsewhere in the network.
   Further, this approach allows for incrementally deploying new
   multicast tree generation algorithms as research in that area
   progresses.

   CBT-like methods may be used to set up receiver initiated trees.
   Nimrod provides link-state maps for generating routes and a CBT-like
   method is compatible with this.  For instance, a receiver wishing to
   join a group may generate a (policy) route to the core for that group
   using its link-state map and attach itself to the tree.

   A disadvantage of sender based methods in general seems to be the
   support of group dynamism.  Specifically, if there is a change in the
   membership of the group, the particular database which contains the
   group-destination mapping must be updated.  In comparison, receiver
   oriented approaches seem to be able to accommodate group dynamism
   more naturally.

   Nimrod does not preclude the simultaneous existence of multiple
   approaches to multicasting and the possibility of switching from one
   to the other depending on the dynamics of group distributions.
   Interoperability is an issue - that is, the question of whether or
   not different implementations of Nimrod can participate in the same
   tree.  However, as long as there is agreement in the structure of the
   state created (i.e., the states can be interpreted uniformly for
   packet forwarding), this should not be a problem.  For instance, a
   receiver wishing to join a sender created tree might set up state on
   a path between itself and a router on the tree with the sender itself
   being unaware of it.  Packets entering the router would now be
   additionally forwarded along this new "branch" to the new receiver.





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


   In conclusion, the architecture of Nimrod can accommodate diverse
   approaches to multicasting.  Each approach has its disadvantages with
   respect to the requirements mentioned in the previous section.  The
   architecture does not demand that one particular solution be used,
   and indeed, we expect that a combination of approaches will be
   employed and engineered in a manner most appropriate to the
   requirements of the particular application or subscriber.

5  A Multicasting Scheme based on PIM

   The Inter-Domain Multicast Routing (IDMR) working group of the IETF
   has developed a specification for a new multicast scheme, namely,
   Protocol Independent Multicasting (PIM) for use in the Internet
   [DEF+94a, DEF+94b].  In this section, we decribe how the schemes
   mentioned therein may be implemented using the facilities provided by
   Nimrod.

   We note that the path setup facility provided in Nimrod makes it very
   conducive to PIM-style multicasting; despite the length of the
   description given here, we assure the reader that it is quite simple
   to implement PIM style multicasting in Nimrod.

   Before reading this section, we recommend that the reader acquire
   some familiarity with PIM (see [DEF+94a, DEF+94b]).

5.1  Overview

   The PIM architecture maintains the traditional IP multicast service
   model of receiver-initiated membership and is independent of any
   specific unicast routing protocol (hence the name).

   A significant aspect of PIM is that it provides mechanisms for
   establishing two kinds of trees - a shared tree, which is intended
   for low "cost" multicasting and a source-based tree, intended for low
   delay multicasting.

   A shared tree is rooted at a rendezvous point (RP), which is
   typically a prespecified router for the multicast group in question.
   In order to establish a shared tree, a designated router (DR) for a
   host wishing to join a group G initiates a flow setup from the RP for
   G to the DR. A source S wishing to send to a group G initiates a flow
   setup between S and the RP for group G. At the conclusion of these
   flow setups, packets can be forwarded from S to H through the RP. For
   details on the protocol used to implement this flow setup please
   refer to [DEF+94b].






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


   After the shared tree has been setup, a recipient for group G has the
   option of switching to a source-based shortest path tree.  In such a
   tree, packets are delivered from the source to each recipient along
   the shortest path.  To establish a source-based shortest path tree,
   the DR for H looks at the source S of the packets it is receiving via
   the shared tree and establishes a flow between S and the DR. The flow
   is established along the shortest path from the DR to S (Thus,
   strictly speaking, it is the reverse shortest path that is being
   used.) Subsequently, packets can be forwarded from S to H using this
   shortest path and thereby bypassing the RP. For details on the
   protocol used to implement source-based trees in PIM please refer to
   [DEF+94b].

   When a host wishes to leave a multicast group, its designated router
   sends a prune message towards the source (for source-based trees) or
   towards the RP (for shared trees).  For details on this and other
   features of PIM please refer to [DEF+94b].

   In Nimrod, PIM is implemented as follows (we refer to PIM based
   multicast as Nimpim).  In order to join a shared tree, an endpoint
   (or an agent acting on behalf of the endpoint) wishing to join a
   group G queries the association database for the EID and locator of
   the RP for G (for well-known groups the association may be
   configured).  It is required that such an association be maintained
   for every multicast group G. The endpoint gets a route for the RP and
   initiates a multicast flow setup to the RP (a multicast flow setup is
   similar to an unicast flow setup described in [CCS96] except for one
   feature - when a multicast flow setup request reaches a node that
   already has that flow present, the request is not forwarded further.
   The new flow gets "spliced" in as a new branch of the existing
   multicast tree).  Similarly, the source establishes a flow to the RP.
   The RP creates state to associate these two flows and now packets can
   be forwarded to the endpoints from the source.  Note that each flow
   setup may be "hierarchical" and involve many subflows.  All this,
   however, is transparent to Nimpim.  For details on management of
   hierarchical flows please refer to [CCS96].

   To create the source-based tree, the representative for a recipient
   node N obtains the EID or locator of the source from the data packets
   and initiates a multicast flow setup to the source.  The route agent
   for the node N uses its map in order to calculate the shortest path
   from the source to N. The flow request is sent along the reverse of
   this path.  We note that the "shortness" of the path is constrained
   by the amount of routing information available locally.  However,
   since the map is available locally, one can find the actual shortest
   path from the source to N and not use the shortest path from N to S.
   Thus, with Nimrod one can actually surmount a shortcoming of PIM with
   relative ease.



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


   We now discuss some more details of Nimpim.  We start with a
   description of multicast flow setup.  This is the "basic"
   functionality required to implement multicasting.  Having this
   "building-block" spelt out, we use this to specify the establishment
   of the shared tree (in section 5.3) and the establishment of a
   source-based tree (in section 5.4).

   We only discuss sparse-mode multicasting, as described in [DEF+94a]
   here.  Further, to simplify the discussion, we assume a single
   Rendezvous Point per group.  Finally, we "address" all entities in
   terms of their EIDs alone for reasons of conciseness - the locators
   could be used in conjuction to reduce the overhead of database
   lookups.

5.2  Joining and Leaving a Tree

   Nimpim uses two control packets in order to setup a flow - the Nimrod
   Multicast Flow-Request packet (NMFReq) and the Nimrod Multicast
   Flow-Reply packet (NMFRep).

   The NMFReq packet is a control packet identified by a prespecified
   "payload type".  The protocol-specific part of this packet includes
   the following fields (except for the Code field, these fields are
   present in the Unicast Flow-Request packet too) :