rfc2189.txt

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

                     Figure 6. ECHO_REQUEST Packet Format


      ECHO_REQUEST Field Definitions

   o    originating child router: address of the router that
        originates the ECHO_REQUEST.


7.7.  ECHO_REPLY Packet Format


       0               1               2               3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    CBT Control Packet Header                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    originating parent router                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       group address #1                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       group address #2                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ......                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       group address #n                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7. ECHO_REPLY Packet Format


      ECHO_REPLY Field Definitions

   o    oringinating parent router: address of the router originating
        this ECHO_REPLY.

   o    group address: a list of multicast group addresses for which



Ballardie                     Experimental                     [Page 18]

RFC 2189              CBTv2 Protocl Specification         September 1997


        this router considers itself a parent router w.r.t. the link
        over which this message is sent.

7.8.  FLUSH_TREE Packet Format


       0               1               2               3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    CBT Control Packet Header                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         group address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ......                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       group address #n                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 8. FLUSH_TREE Packet Format


      FLUSH_TREE Field Definitions

   o    group address(es): multicast group address(es) of the group(s)
        being "flushed".

8.  Core Router Discovery

   There are two available options for CBTv2 core discovery; the
   "bootstrap" mechanism (as currently specified with the PIM sparse
   mode protocol [2]) 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, to be applicable, all CBT
   routers within a domain must implement the bootstrap mechanism.

   The other option is to manually configure leaf routers with <core,
   group> mappings (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.






Ballardie                     Experimental                     [Page 19]

RFC 2189              CBTv2 Protocl Specification         September 1997


8.1.  "Bootstrap" Mechanism Overview

   It is unlikely that the bootstrap mechanism will be appended to a
   well-known network layer protocol, such as IGMP [3], 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
   (details are provided in [7]). 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
   hop- by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to
   advertise the CC-set. Together, "Core Advertisements" and "Bootstrap
   Messages" comprise the "bootstrap" protocol.

   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.






Ballardie                     Experimental                     [Page 20]

RFC 2189              CBTv2 Protocl Specification         September 1997


8.2.  Bootstrap Message Format

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             CBT common control packet header                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      For full Bootstrap Message specification, see [7]        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9. Bootstrap Message Format


8.3.  Candidate Core Advertisement Message Format


     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              CBT common control packet header                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   For full Candidate Core Adv. Message specification, see [7] |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 10. Candidate Core Advertisement Message Format

9.  Interoperability Issues

   Interoperability between CBT and DVMRP is specified in [5].

   Interoperability with other multicast protocols will be fully
   specified as the need arises.

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

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



Ballardie                     Experimental                     [Page 21]

RFC 2189              CBTv2 Protocl Specification         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.

   The emergence of CBTv2 owes much to Clay Shields and his work on
   Ordered CBT (OCBT) [8]. Clay identified and proved several failure
   modes of CBT as it was specified with multiple cores, and also
   suggested using an unreliable quit mechanism, which appears in this
   specification as the QUIT_NOTIFICATION. Clay has also provided more
   general constructive comments on the CBT architecture and
   specification.

   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] Core Based Trees (CBT) Multicast Routing Architecture; A.
   Ballardie; RFC 2201, September 1997.

   [2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D.
   Estrin et al; ftp://netweb.usc.edu/pim   Working drafts, 1996.

   [3] Internet Group Management Protocol, version 2 (IGMPv2); W.
   Fenner; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-
   v2-**.txt.  Working draft, 1996.

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

   [5] CBT Border Router Specification for Interconnecting a CBT Stub
   Region to a DVMRP Backbone; A. Ballardie;
   ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-dm-
   interop-**.txt.  Working draft,  March 1997.

   [6] Ballardie, A., "Scalable Multicast Key Distribution", RFC 1949,
   July 1996.




Ballardie                     Experimental                     [Page 22]

RFC 2189              CBTv2 Protocl Specification         September 1997


   [7] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast
   Routing; D. Estrin et al.; Technical Report;
   ftp://catarina.usc.edu/pim

   [8] 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/infocomm97ocbt.ps.gz

   [9]  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 23]