rfc2102.txt

RFC 的详细文档！

   Shared Tree Data Forwarding: Packets sent from the source for group G
   contain the Flow-id used by the sender(s) and receiver(s) for setting
   up the delivery tree.  The packets from the sender are sent to the RP
   where they are multicast, using the state created for the flow, into
   the delivery tree rooted at the RP to all of the receivers that did a
   Tree-Join.

5.4  Switching to a Source-Rooted Shortest Path Tree

   There are two parts involved in switching to a Source-Rooted Shortest
   Path Tree - the receiver-source communications wherein the receiver
   joins a multicast delivery tree rooted at the source and the
   receiver-RP communications wherein the receiver leaves the shared
   tree.

   Receiver-Source Communications:  An endpoint E that is receiving
   packets through the shared tree from source S has the option of
   switching to a delivery tree rooted at the source such that packets
   from S to E traverse the shortest path (using whatever metric).

   The endpoint representative of E obtains the flow-id to be used for
   the flow.  The flow-id is constructed equivalently to the tuple
   (Source-EID, G).  Note that the flow-id must be unique to the
   particular multicast flow.  This is not the only method or perhaps
   even the best method for obtaining a flow id.  Alternate methods for
   obtaining the flow-id are discussed in section 5.5.

   The representative for E initiates a Tree-Join toward S with NMFReq
   fields as follows:

   o S-EID : EID of the Endpoint E.

   o T-EID : EID of the source.

   o Flow-id :  Flow id for the multicast (obtained as mentioned above).

   o Code :  Join.



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


   o Direction :  REVERSE.

   o Source Route : To obtain the route, the route agent is queried for
     a shortest path route (based on the chosen metric, typically, the
     delay) from the source to the endpoint.  We note that the quality
     of the route is constrained by the amount of routing information
     available, directly or indirectly, to the route agent.  The Source
     Route is the reverse of the route thus obtained.

   A comment on the difference between the shortest-path trees obtained
   using the RPF tree as in [DEF+94b, DC90] and the trees that are be
   obtained here.  When using the RPF scheme, the packets from the
   source S to the endpoint E follow a path that is the shortest path
   from E to S. This is the desired path if and only if the path is
   symmetric in either direction.  However, in the mechanism described
   here for Nimrod, the packets do follow the "actual" shortest path
   from S to E whether or not the path is symmetric.

   The NMFRep fields are obvious.

   Receiver-RP Communications: After the receiver has joined the
   source-rooted tree, it can optionally disassociate itself from the
   shared tree.  This is done by initiating a Tree-Leave procedure.

   The representative sends a NMFReq packet toward the RP with the
   fields as follows.

   o S-EID : The EID of the endpoint wishing to leave the shared tree.

   o T-EID : The RP-EID.

   o Flow-id :  The flow-id it used to join the shared tree.

   o Code :  Prune.

   o Direction :  REVERSE.

   o Source Route :  Obtained as for the Tree-Join.

   The prune packet is processed by the intermediate forwarding agents
   as mentioned in section 5.2.  When the receiver gets back the NMFRep
   packet, the receiver has left the shared tree.

   Source Tree Data Forwarding: Packets from the source contain the
   flow-id that was used to join the source tree for a given multicast
   group.  Forwarding agents simply use the state created by the Tree-
   Join procedure in order to duplicate and forward packets toward the
   receivers.



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


5.5  Miscellaneous Issues

   Obtaining the Flow-Id: In the above scheme the flow-id for a
   particular multicast group G was obtained by combining the RP-EID and
   the group set-id (G-SID) (in case of shared tree) or by combining the
   Source-EID and the G-SID (in case of source-based tree).  A
   disadvantage of this approach is that the bit-length of EID/SID is
   potentially high (more than 64 bits) and thus the flow-id could be
   very long.  While there do exist bit-based data structures and search
   algorithms (such as Patricia Trees) that may be used for an efficient
   implementation, it is worth considering some other methods in lieu of
   using the EID/SID combination.  We describe some methods below :

1. For shared trees, the flow-id for a particular group G may be stored
   and updated in the association database.  Since we have to use the
   association database anyway to obtain the RP-EID, these does not cause
   much additional burden.

   However, this cannot be used efficiently for source-based trees because
   we need a flow-id for each combination of Source and Group.

2. The flow-id for shared trees could be done as above.  When the sender
   does an RP-Register, it could send the RP the flow-id that it wishes to
   be used by receivers when they switch to a source-based tree.  This
   could be included in the RP-Register message.  The RP could then
   multicast that flow-id to all receivers in a special packet.  When the
   receivers wish to switch, they use that flow-id.

   This needs the definition of the "special" packet.

3. The flow-id is handed out only by the source (for source-based trees)
   or the RP (for shared trees).  The receivers use a "dummy" flow-id in
   the NMFReq when doing a Tree-Join.  The correct flow-id to be used is
   returned in the NMFRep message generated by the forwarding agent where
   the new branch meets the existing tree.  Forwarding agents in the path
   of the NMFRep packet update the state information by rewriting the
   dummy flow-id by the correct flow-id contained in the NMFRep packet.

   This requires the re-definition of the NMFRep packet.  Note that now
   there must be space for two flow-ids in the NMFRep packet - one for the
   "dummy" flow-id and the other for the "correct" flow-id that must
   replace the dummy flow-id.

   We claim that each of the above schemes achieves synchronization in
   the flow-id in various parts of the internetwork and that each flow-
   id is unique to the multicast delivery tree.  A formal proof of these
   claims is beyond the scope of this document.




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


   Dense Mode Multicast:  The PIM architecture [DEF+94a] includes a
   multicast protocol when the group membership is densely distributed
   within the internetwork.  In this mode, no Rendezvous Points are used
   and a source rooted tree is formed based on Reverse Path Forwarding
   in a manner similar to that of DVMRP [DC90].

   We do not give details of how Nimrod can implement Dense Mode
   Multicast here.

   Multiple RPs:  Our discussion above has been based on the assumption
   that there is one RP per group.  PIM allows more than one RP per
   group.  We do not discuss multiple-RP PIM here.

6  Security Considerations

   Security issues are not discussed in this memo.

7  Summary

o Nimrod does not specify a particular multicast route generation
  algorithm or state creation procedure.  Nimrod can accommodate diverse
  multicast techniques and leaves the choice of the technique to the
  particular instantiation of Nimrod.

o A solution for multicasting within Nimrod should be capable of:

  -  Scaling to large networks, large numbers of multicast groups and
     large multicast groups.

  -  Supporting policy, including quality of service and access
     restrictions.

  -  Resource sharing.

  -  Interoperability with other solutions.

o Multicasting typically requires the setting up of state in intermediate
  routers for packet forwarding.  The state setup may be initiated by the
  sender (e.g., IDPR), by the receiver (e.g., CBT), by both (e.g., PIM)
  or by neither.  The architecture of Nimrod provides sufficient
  flexibility to accommodate any of these approaches.

o A receiver-initiated multicast protocol, PIM, is being designed by the
  IDMR working group of the IETF. The facilities provided by Nimrod make
  the use of PIM as a multicast protocol quite straightforward.






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


8  References

[BFC93]   A. J. Ballardie, P. F. Francis, and J. Crowcroft. Core based
          trees. In Proceedings of ACM SIGCOMM, 1993.

[CCS96]   Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod
          Routing Architecture", RFC 1992, August 1996.

[DC90]    S. Deering and D. Cheriton. Multicast routing in datagram
          internetworks and extended lans. ACM Transactions on Computer
          Systems, pages 85--111, May 1990.

[DEF+94a] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu,
          C., and L. Wei, "Protocol Independent Multicast (PIM) :
          Motivation and Architecture, Work in Progress.

[DEF+94b] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu,
          C., and L. Wei, "Protocol Independent Multicast (PIM) :
          Sparse Mode Protocol Specification, Work in Progress.

[DEFJ93]  Deering, S., Estrin, D., Farinacci, D., and V. Jacobson,
          "IGMP router extensions for routing to sparse multicast
          groups, Work in Progress.

[DM78]    Y. K. Dalal and R. M. Metcalfe. Reverse path forwarding of
          broadcast packets. Communications of the ACM, 21(12), pages
          1040--1048, 1978.

[Moy92]   Moy, J., "Multicast Extensions to OSPF, RFC 1584, March 1994.

[RS96]    Ramanathan, S., and M. Steenstrup, "Nimrod functional and
          protocol specifications, Work in Progress.

[Ste]     Steenstrup, M., "Inter-domain policy routing protocol
          specification:  Version 2", Work in Progress.
















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


9  Acknowledgements

   We thank Isidro Castineyra (BBN), Charles Lynn (BBN), Martha
   Steenstrup (BBN) and other members of the Nimrod Working Group for
   their comments and suggestions on this memo.

10  Author's Address

   Ram Ramanathan
   BBN Systems and Technologies
   10 Moulton Street
   Cambridge, MA 02138

   Phone:  [phone]
   EMail:  [e-mail]




































Ramanathan                   Informational                     [Page 23]