rfc2201.txt

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

   retransmits those control messages for which it expects a response,
   if that response is not forthcoming within the retransmission-
   interval, which varies depending on the type of message involved.
   There is an upper bound (typically 3) on the number of
   retransmissions of the original message before an exception condition
   is raised.

   For example, the exception procedure for lack of response to an
   ECHO_REQUEST is to send a QUIT_NOTIFICATION upstream and a FLUSH_TREE
   message downstream for the group. If this is router has group members
   attached, it restarts the joining process to the group's core.

4.2.2.  Non-Member Sending

   If a non-member sender's local router is already on-tree for the
   group being sent to, the subnet's upstream router simply forwards the
   data packet over all outgoing interfaces corresponding to that
   group's forwarding cache entry. This is in contrast to PIM-SM [18]
   which must encapsulate data from a non-member sender, irrespective of
   whether the local router has joined the tree. This is due to PIM's
   uni-directional state.

   If the sender's subnet is not attached to the group tree, the local
   DR must encapsulate the data packet and unicast it to the group's
   core router, where it is decapsulated and disseminated over all tree
   interfaces, as specified by the core's forwarding cache entry for the
   group. The data packet encapsulation method is IP-in-IP [14].

   Routers in between a non-member sender and the group's core need not
   know anything about the multicast group, and indeed may even be
   multicast-unaware. This makes CBT particulary attractive for
   applications with non-member senders.

5.  Interoperability with Other Multicast Routing Protocols

   See "interoperability" in section 4.1.

   The interoperability mechanisms for interfacing CBT with DVMRP are
   defined in [15].

6.  Core Router Discovery

   Core router discovery is by far the most controversial and difficult
   aspect of shared tree multicast architectures, particularly in the
   context of inter-domain multicast routing (IDMR).  There have been
   many proposals over the past three years or so, including advertising
   core addresses in a multicast session directory like "sdr" [11],
   manual placement, and the HPIM [12] approach of strictly dividing up



Ballardie                     Experimental                     [Page 11]

RFC 2201           CBT Multicast Routing Architecture     September 1997


   the multicast address space into many "hierarchical scopes" and using
   explicit advertising of core routers between scope levels.

   There are currently two options for CBTv2 [1] core discovery; the
   "bootstrap" mechamism, and manual placement. The bootstrap mechanisms
   (as currently specified with the PIM sparse mode protocol [18]) is
   applicable only to intra-domain core discovery, and allows for a
   "plug & play" type operation with minimal configuration. The
   disadvantage of the bootstrap mechanism is that it is much more
   difficult to affect the shape, and thus optimality, of the resulting
   distribution tree. Also, it must be implemented by all CBT routers
   within a domain.

   Manual configuration of leaf routers with <core, group> mappings is
   the other option (note: leaf routers only); this imposes a degree of
   administrative burden - the mapping for a particular group must be
   coordinated across all leaf routers to ensure consistency. Hence,
   this method does not scale particularly well. However, it is likely
   that "better" trees will result from this method, and it is also the
   only available option for inter-domain core discovery currently
   available.


6.1.  Bootstrap Mechanism Overview

   It is unlikely at this stage that the bootstrap mechanism will be
   appended to a well-known network layer protocol, such as IGMP [5] or
   ICMP [13], though this would facilitate its ubiquitous (intra-domain)
   deployment.  Therefore, each multicast routing protocol requiring the
   bootstrap mechanism must implement it as part of the multicast
   routing protocol itself.

   A summary of the operation of the bootstrap mechanism follows. It is
   assumed that all routers within the domain implement the "bootstrap"
   protocol, or at least forward bootstrap protocol messages.

   A subset of the domain's routers are configured to be CBT candidate
   core routers. Each candidate core router periodically (default every
   60 secs) advertises itself to the domain's Bootstrap Router (BSR),
   using  "Core Advertisement" messages.  The BSR is itself elected
   dynamically from all (or participating) routers in the domain.  The
   domain's elected BSR collects "Core Advertisement" messages from
   candidate core routers and periodically advertises a candidate core
   set (CC-set) to each other router in the domain, using traditional
   hopby-hop unicast forwarding. The BSR uses "Bootstrap Messages" to
   advertise the CC-set. Together, "Core Advertisements" and "Bootstrap
   Messages" comprise the "bootstrap" protocol.




Ballardie                     Experimental                     [Page 12]

RFC 2201           CBT Multicast Routing Architecture     September 1997


   When a router receives an IGMP host membership report from one of its
   directly attached hosts, the local router uses a hash function on the
   reported group address, the result of which is used as an index into
   the CC-set. This is how local routers discover which core to use for
   a particular group.

   Note the hash function is specifically tailored such that a small
   number of consecutive groups always hash to the same core.
   Furthermore, bootstrap messages can carry a "group mask", potentially
   limiting a CC-set to a particular range of groups. This can help
   reduce traffic concentration at the core.

   If a BSR detects a particular core as being unreachable (it has not
   announced its availability within some period), it deletes the
   relevant core from the CC-set sent in its next bootstrap message.
   This is how a local router discovers a group's core is unreachable;
   the router must re-hash for each affected group and join the new core
   after removing the old state. The removal of the "old" state follows
   the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message
   downstream.

7.  Summary

   This document presents an architecture for intra- and inter-domain
   multicast routing.  We motivated this architecture by describing how
   an inter-domain multicast routing algorithm must scale to large
   numbers of groups present in the internetwork, and discussed why most
   other existing algorithms are less suited to inter-domain multicast
   routing.  We followed by describing the features and components of
   the architecture, illustrating its simplicity and scalability.

8.  Security Considerations

   Security considerations are not addressed in this memo.

   Whilst multicast security is a topic of ongoing research, multicast
   applications (users) nevertheless have the ability to take advantage
   of security services such as encryption or/and authentication
   provided such services are supported by the applications.

   RFCs 1949 and 2093/2094 discuss different ways of distributing
   multicast key material, which can result in the provision of network
   layer access control to a multicast distribution tree.

   [19] offers a synopsis of multicast security threats and proposes
   some possible counter measures.





Ballardie                     Experimental                     [Page 13]

RFC 2201           CBT Multicast Routing Architecture     September 1997


   Beyond these, little published work exists on the topic of multicast
   security.

Acknowledgements

   Special thanks goes to Paul Francis, NTT Japan, for the original
   brainstorming sessions that brought about this work.

   Clay Shields' work on OCBT [17] identified various failure scenarios
   with a multi-core architecture, resulting in the specification of a
   single core architecture.

   Others that have contributed to the progress of CBT include Ken
   Carlberg, Eric Crawley, Jon Crowcroft, Mark Handley, Ahmed Helmy,
   Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, Scott
   Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, Paul
   White, and other participants of the IETF IDMR working group.

   Thanks also to 3Com Corporation and British Telecom Plc for funding
   this work.

References

   [1] Ballardie, A., "Core Based Trees (CBT version 2) Multicast
   Routing: Protocol Specification", RFC 2189, September 1997.

   [2] Multicast Routing in a Datagram Internetwork; S. Deering, PhD
   Thesis, 1991; ftp://gregorio.stanford.edu/vmtp/sd-thesis.ps.

   [3] Mechanisms for Broadcast and Selective Broadcast; D. Wall; PhD
   thesis, Stanford University, June 1980. Technical Report #90.

   [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
   October 1994.

   [5] Internet Group Management Protocol, version 2 (IGMPv2); W.
   Fenner; Work In Progress.

   [6] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri;
   Work In Progress.

   [7] Protocol Independent Multicast (PIM) Dense Mode Specification; D.
   Estrin et al; ftp://netweb.usc.edu/pim, Work In Progress.

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

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



Ballardie                     Experimental                     [Page 14]

RFC 2201           CBT Multicast Routing Architecture     September 1997


   [10] Some Issues for an Inter-Domain Multicast Routing Protocol; D.
   Meyer;  Work In Progress.

   [11] SDP: Session Description Protocol; M. Handley and V. Jacobson;
   Work In Progress.

   [12] Hierarchical Protocol Independent Multicast; M. Handley, J.
   Crowcroft, I. Wakeman.  Available from:
   http://www.cs.ucl.ac.uk/staff/M.Handley/hpim.ps  and
   ftp://cs.ucl.ac.uk/darpa/IDMR/hpim.ps   Work done 1995.

   [13] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5,
   RFC 792, September 1981.

   [14] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
   1996.

   [15] CBT - Dense Mode Multicast Interoperability; A. Ballardie; Work
   In Progress.

   [16] Performance and Resource Cost Comparisons of Multicast Routing
   Algorithms for Distributed Interactive Simulation Applications; T.
   Billhartz, J. Bibb Cain, E.  Farrey-Goudreau, and D. Feig. Available
   from: http://www.epm.ornl.gov/~sgb/pubs.html; July 1995.

   [17] The Ordered Core Based Tree Protocol; C. Shields and J.J.
   Garcia- Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan,
   April 1997; http://www.cse.ucsc.edu/research/ccrg/publications/info-
   comm97ocbt.ps.gz

   [18] Estrin, D., et. al., "Protocol Independent Multicast-Sparse Mode
   (PIM-SM): Protocol Specification", RFC 2117, June 1997.

   [19] Multicast-Specific Security Threats and Counter-Measures; A.
   Ballardie and J. Crowcroft; In Proceedings "Symposium on Network and
   Distributed System Security", February 1995, pp.2-16.

Author Information

   Tony Ballardie,
   Research Consultant

   EMail: [e-mail]








Ballardie                     Experimental                     [Page 15]