rfc2189.txt

RFC 的详细文档！

Network Working Group                                       A. Ballardie
Request for Comments: 2189                                    Consultant
Category: Experimental                                    September 1997



           Core Based Trees (CBT version 2) Multicast Routing

                      -- Protocol Specification --


Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This document describes the Core Based Tree (CBT version 2) network
   layer multicast routing protocol. CBT builds a shared multicast
   distribution tree per group, and is suited to inter- and intra-domain
   multicast routing.

   CBT may use a separate multicast routing table, or it may use that of
   underlying unicast routing, to establish paths between senders and
   receivers. The CBT architecture is described in [1].

   This document is progressing through the IDMR working group of the
   IETF.  CBT related documents include [1, 5, 6]. For all IDMR-related
   documents, see http://www.cs.ucl.ac.uk/ietf/idmr.

TABLE OF CONTENTS

  1. Changes Since Previous version............................. 2
  2. Introduction & Terminology................................. 3
  3. CBT Functional Overview.................................... 3
  4. CBT Protocol Specificiation Details........................ 6
     4.1 CBT HELLO Protocol..................................... 6
         4.1.1 Sending HELLOs................................... 7
         4.1.2 Receiving HELLOs................................. 7
     4.2 JOIN_REQUEST Processing................................ 8
         4.2.1 Sending JOIN_REQUESTs............................ 8
         4.2.2 Receiving JOIN_REQUESTs.......................... 8
     4.3 JOIN_ACK Processing.................................... 9
         4.3.1 Sending JOIN_ACKs................................ 9
         4.3.2 Receiving JOIN_ACKs.............................. 9



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


     4.4 QUIT_NOTIFICATION Processing........................... 10
         4.4.1 Sending QUIT_NOTIFICATIONs....................... 10
         4.4.2 Receiving QUIT_NOTIFICATIONs..................... 10
     4.5 CBT ECHO_REQUEST Processing............................ 11
         4.5.1 Sending ECHO_REQUESTs............................ 11
         4.5.2 Receiving ECHO_REQUESTs.......................... 12
     4.6 ECHO_REPLY Processing.................................. 12
         4.6.1 Sending ECHO_REPLYs.............................. 12
         4.6.2 Receiving ECHO_REPLYs............................ 12
     4.7 FLUSH_TREE Processing.................................. 13
         4.7.1 Sending FLUSH_TREE Messages...................... 13
         4.7.2 Receiving FLUSH_TREE Messages.................... 13
  5. Non-Member Sending......................................... 13
  6. Timers and Default Values.................................. 13
  7. CBT Packet Formats and Message Types....................... 14
     7.1 CBT Common Control Packet Header....................... 14
     7.2 HELLO Packet Format.................................... 15
     7.3 JOIN_REQUEST Packet Format............................. 16
     7.4 JOIN_ACK Packet Format................................. 16
     7.5 QUIT_NOTIFICATION Packet Format........................ 17
     7.6 ECHO_REQUEST Packet Format............................. 18
     7.7 ECHO_REPLY Packet Format............................... 18
     7.8 FLUSH_TREE Packet Format............................... 19
  8. Core Router Discovery...................................... 19
     8.1  "Bootstrap" Mechanism Overview........................ 20
     8.2  Bootstrap Message Format.............................. 21
     8.3  Candidate Core Advertisement Message Format........... 21
  9. Interoperability Issues.................................... 21
  10.  Security Considerations.................................. 21
  Acknowledgements.............................................. 22
  References.................................................... 22
  Author Information............................................ 23

1.  Changes from CBT version 1

   This version of the CBT protocol specification differs significantly
   from the previous version. Consequently, this version represents
   version 2 of the CBT protocol.  CBT version 2 is not, and was not,
   intended to be backwards compatible with version 1; we do not expect
   this to cause extensive compatibility problems because we do not
   believe CBT is at all widely deployed at this stage. However, any
   future versions of CBT can be expected to be backwards compatible
   with this version.








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


   The most significant changes to version 2 compared to version 1
   include:

   o new LAN mechanisms, including the incorporation of an HELLO
     protocol.

   o new simplified packet formats, with the definition of a common CBT
     control packet header.

   o each group shared tree has only one active core router.

     This specification revision is a complete re-write of the previous
     revision.

2.  Introduction & Terminology

   In CBT, a "core router" (or just "core") is a router which acts as a
   "meeting point" between a sender and group receivers. The term
   "rendezvous point (RP)" is used equivalently in some contexts [2]. A
   core router need not be configured to know it is a core router.

   A router that is part of a CBT distribution tree is known as an "on-
   tree" router. An on-tree router maintains active state for the group.

   We refer to a broadcast interface as any interface that supports
   multicast transmission.

   An "upstream" interface (or router) is one which is on the path
   towards the group's core router with respect to this interface (or
   router). A "downstream" interface (or router) is one which is on the
   path away from the group's core router with respect to this interface
   (or router).

   Other terminology is introduced in its context throughout the text.

3.  CBT Functional Overview

   The CBT protocol is designed to build and maintain a shared multicast
   distribution tree that spans only those networks and links leading to
   interested receivers.

   To achieve this, a host first expresses its interest in joining a
   group by multicasting an IGMP host membership report [3] across its
   attached link. On receiving this report, a local CBT aware router
   invokes the tree joining process (unless it has already) by
   generating a JOIN_REQUEST message, which is sent to the next hop on
   the path towards the group's core router (how the local router
   discovers which core to join is discussed in section 8). This join



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


   message must be explicitly acknowledged (JOIN_ACK) either by the core
   router itself, or by another router that is on the path between the
   sending router and the core, which itself has already successfully
   joined the tree.

   The join message sets up transient join state in the routers it
   traverses, and this state consists of <group, incoming interface,
   outgoing interface>. "Incoming interface" and "outgoing interface"
   may be "previous hop" and "next hop", respectively, if the
   corresponding links do not support multicast transmission. "Previous
   hop" is taken from the incoming control packet's IP source address,
   and "next hop" is gleaned from the routing table - the next hop to
   the specified core address. This transient state eventually times out
   unless it is "confirmed" with a join acknowledgement (JOIN_ACK) from
   upstream. The JOIN_ACK traverses the reverse path of the
   corresponding join message, which is possible due to the presence of
   the transient join state. Once the acknowledgement reaches the router
   that originated the join message, the new receiver can receive
   traffic sent to the group.

   Loops cannot be created in a CBT tree because a) there is only one
   active core per group, and b) tree building/maintenance scenarios
   which may lead to the creation of tree loops are avoided.  For
   example, if a router's upstream neighbour becomes unreachable, the
   router immediately "flushes" all of its downstream branches, allowing
   them to individually rejoin if necessary.  Transient unicast loops do
   not pose a threat because a new join message that loops back on
   itself will never get acknowledged, and thus eventually times out.

   The state created in routers by the sending or receiving of a
   JOIN_ACK is bi-directional - data can flow either way along a tree
   "branch", and the state is group specific - it consists of the group
   address and a list of local interfaces over which join messages for
   the group have previously been acknowledged. There is no concept of
   "incoming" or "outgoing" interfaces, though it is necessary to be
   able to distinguish the upstream interface from any downstream
   interfaces. In CBT, these interfaces are known as the "parent" and
   "child" interfaces, respectively. A router is not considered "on-
   tree" until it has received a JOIN_ACK for a previously sent
   JOIN_REQUEST.

   With regards to the information contained in the multicast forwarding
   cache, on link types not supporting native multicast transmission an
   on-tree router must store the address of a parent and any children.
   On links supporting multicast however, parent and any child
   information is represented with local interface addresses (or similar
   identifying information, such as an interface "index") over which the
   parent or child is reachable.



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


   Data from non-member senders must be encapsulated (IP-in-IP) by the
   first-hop router, and is unicast to the group's core router.
   Consequently, no group state is required in the network between the
   first hop router and the group's core. On arriving at the core
   router, the data packet's outer encapsulating header is removed and
   the packet is disemminated over the group shared tree as described
   below.

   When a multicast data packet arrives at a router, the router uses the
   group address as an index into the multicast forwarding cache. A copy
   of the incoming multicast data packet is forwarded over each
   interface (or to each address) listed in the entry except the
   incoming interface.

   Each router that comprises a CBT multicast tree, except the core
   router, is responsible for maintaining its upstream link, provided it
   has interested downstream receivers, i.e. the child interface list is
   not NULL. A child interface is one over which a member host is
   directly attached, or one over which a downstream on-tree router is
   attached.  This "tree maintenance" is achieved by each downstream
   router periodically sending a CBT "keepalive" message (ECHO_REQUEST)
   to its upstream neighbour, i.e. its parent router on the tree. One
   keepalive message is sent to represent entries with the same parent,
   thereby improving scalability on links which are shared by many
   groups.  On multicast capable links, a keepalive is multicast to the
   "all-cbt-routers" group (IANA assigned as 224.0.0.15); this has a
   suppressing effect on any other router for which the link is its
   parent link.  If a parent link does not support multicast
   transmission, keepalives are unicast.

   The receipt of a keepalive message over a valid child interface
   prompts a response (ECHO_REPLY), which is either unicast or
   multicast, as appropriate.  The ECHO_REPLY message carries a list of
   groups for which the corresponding interface is a child interface.

   It cannot be assumed all of the routers on a multi-access link have a
   uniform view of unicast routing; this is particularly the case when a
   multi-access link spans two or more unicast routing domains. This
   could lead to multiple upstream tree branches being formed (an error
   condition) unless steps are taken to ensure all routers on the link
   agree which is the upstream router for a particular group. CBT
   routers attached to a multi-access link participate in an explicit
   election mechanism that elects a single router, the designated router
   (DR), as the link's upstream router for all groups. Since the DR
   might not be the link's best next-hop for a particular core router,
   this may result in join messages being re-directed back across a
   multi-access link. If this happens, the re-directed join message is
   unicast across the link by the DR to the best next-hop, thereby



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


   preventing a looping scenario. This re-direction only ever applies to
   join messages.  Whilst this is suboptimal for join messages, which
   are generated infrequently, multicast data never traverses a link
   more than once (either natively, or encapsulated).

   In all but the exception case described above, all CBT control
   messages are multicast over multicast supporting links to the "all-
   cbt- routers" group, with IP TTL 1. The IP source address of CBT
   control messages is the outgoing interface of the sending router. The
   IP destination address of CBT control messages is either the "all-
   cbt- routers" group address, or a unicast address, as appropriate.
   All the necessary addressing information is obtained by on-tree
   routers as part of tree set up.

   If CBT is implemented over a tunnelled topology, when sending a CBT
   control packet over a tunnel interface, the sending router uses as
   the packet's IP source address the local tunnel end point address,
   and the remote tunnel end point address as the packet's IP
   destination address.

4.  Protocol Specification Details

   Details of the CBT protocol are presented in the context of a single
   router implementation.

4.1.  CBT HELLO Protocol

   The HELLO protocol is used to elect a designated router (DR) on
   broadcast-type links. It is also used to elect a designated border
   router (BR) when interconnecting a CBT domain with other domains (see
   [5]). Alternatively, the designated BR may be elected as a matter of
   local policy.

   A router represents its status as a link's DR by setting the DR-flag
   on that interface; a DR flag is associated with each of a router's
   broadcast interfaces. This flag can only assume one of two values:
   TRUE or FALSE. By default, this flag is FALSE.