home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2189 < prev    next >
Text File  |  1997-09-25  |  52KB  |  1,292 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       A. Ballardie
  8. Request for Comments: 2189                                    Consultant
  9. Category: Experimental                                    September 1997
  10.  
  11.  
  12.  
  13.            Core Based Trees (CBT version 2) Multicast Routing
  14.  
  15.                       -- Protocol Specification --
  16.  
  17.  
  18. Status of this Memo
  19.  
  20.    This memo defines an Experimental Protocol for the Internet
  21.    community.  It does not specify an Internet standard of any kind.
  22.    Discussion and suggestions for improvement are requested.
  23.    Distribution of this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    This document describes the Core Based Tree (CBT version 2) network
  28.    layer multicast routing protocol. CBT builds a shared multicast
  29.    distribution tree per group, and is suited to inter- and intra-domain
  30.    multicast routing.
  31.  
  32.    CBT may use a separate multicast routing table, or it may use that of
  33.    underlying unicast routing, to establish paths between senders and
  34.    receivers. The CBT architecture is described in [1].
  35.  
  36.    This document is progressing through the IDMR working group of the
  37.    IETF.  CBT related documents include [1, 5, 6]. For all IDMR-related
  38.    documents, see http://www.cs.ucl.ac.uk/ietf/idmr.
  39.  
  40. TABLE OF CONTENTS
  41.  
  42.   1. Changes Since Previous version............................. 2
  43.   2. Introduction & Terminology................................. 3
  44.   3. CBT Functional Overview.................................... 3
  45.   4. CBT Protocol Specificiation Details........................ 6
  46.      4.1 CBT HELLO Protocol..................................... 6
  47.          4.1.1 Sending HELLOs................................... 7
  48.          4.1.2 Receiving HELLOs................................. 7
  49.      4.2 JOIN_REQUEST Processing................................ 8
  50.          4.2.1 Sending JOIN_REQUESTs............................ 8
  51.          4.2.2 Receiving JOIN_REQUESTs.......................... 8
  52.      4.3 JOIN_ACK Processing.................................... 9
  53.          4.3.1 Sending JOIN_ACKs................................ 9
  54.          4.3.2 Receiving JOIN_ACKs.............................. 9
  55.  
  56.  
  57.  
  58. Ballardie                     Experimental                      [Page 1]
  59.  
  60. RFC 2189              CBTv2 Protocl Specification         September 1997
  61.  
  62.  
  63.      4.4 QUIT_NOTIFICATION Processing........................... 10
  64.          4.4.1 Sending QUIT_NOTIFICATIONs....................... 10
  65.          4.4.2 Receiving QUIT_NOTIFICATIONs..................... 10
  66.      4.5 CBT ECHO_REQUEST Processing............................ 11
  67.          4.5.1 Sending ECHO_REQUESTs............................ 11
  68.          4.5.2 Receiving ECHO_REQUESTs.......................... 12
  69.      4.6 ECHO_REPLY Processing.................................. 12
  70.          4.6.1 Sending ECHO_REPLYs.............................. 12
  71.          4.6.2 Receiving ECHO_REPLYs............................ 12
  72.      4.7 FLUSH_TREE Processing.................................. 13
  73.          4.7.1 Sending FLUSH_TREE Messages...................... 13
  74.          4.7.2 Receiving FLUSH_TREE Messages.................... 13
  75.   5. Non-Member Sending......................................... 13
  76.   6. Timers and Default Values.................................. 13
  77.   7. CBT Packet Formats and Message Types....................... 14
  78.      7.1 CBT Common Control Packet Header....................... 14
  79.      7.2 HELLO Packet Format.................................... 15
  80.      7.3 JOIN_REQUEST Packet Format............................. 16
  81.      7.4 JOIN_ACK Packet Format................................. 16
  82.      7.5 QUIT_NOTIFICATION Packet Format........................ 17
  83.      7.6 ECHO_REQUEST Packet Format............................. 18
  84.      7.7 ECHO_REPLY Packet Format............................... 18
  85.      7.8 FLUSH_TREE Packet Format............................... 19
  86.   8. Core Router Discovery...................................... 19
  87.      8.1  "Bootstrap" Mechanism Overview........................ 20
  88.      8.2  Bootstrap Message Format.............................. 21
  89.      8.3  Candidate Core Advertisement Message Format........... 21
  90.   9. Interoperability Issues.................................... 21
  91.   10.  Security Considerations.................................. 21
  92.   Acknowledgements.............................................. 22
  93.   References.................................................... 22
  94.   Author Information............................................ 23
  95.  
  96. 1.  Changes from CBT version 1
  97.  
  98.    This version of the CBT protocol specification differs significantly
  99.    from the previous version. Consequently, this version represents
  100.    version 2 of the CBT protocol.  CBT version 2 is not, and was not,
  101.    intended to be backwards compatible with version 1; we do not expect
  102.    this to cause extensive compatibility problems because we do not
  103.    believe CBT is at all widely deployed at this stage. However, any
  104.    future versions of CBT can be expected to be backwards compatible
  105.    with this version.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Ballardie                     Experimental                      [Page 2]
  115.  
  116. RFC 2189              CBTv2 Protocl Specification         September 1997
  117.  
  118.  
  119.    The most significant changes to version 2 compared to version 1
  120.    include:
  121.  
  122.    o new LAN mechanisms, including the incorporation of an HELLO
  123.      protocol.
  124.  
  125.    o new simplified packet formats, with the definition of a common CBT
  126.      control packet header.
  127.  
  128.    o each group shared tree has only one active core router.
  129.  
  130.      This specification revision is a complete re-write of the previous
  131.      revision.
  132.  
  133. 2.  Introduction & Terminology
  134.  
  135.    In CBT, a "core router" (or just "core") is a router which acts as a
  136.    "meeting point" between a sender and group receivers. The term
  137.    "rendezvous point (RP)" is used equivalently in some contexts [2]. A
  138.    core router need not be configured to know it is a core router.
  139.  
  140.    A router that is part of a CBT distribution tree is known as an "on-
  141.    tree" router. An on-tree router maintains active state for the group.
  142.  
  143.    We refer to a broadcast interface as any interface that supports
  144.    multicast transmission.
  145.  
  146.    An "upstream" interface (or router) is one which is on the path
  147.    towards the group's core router with respect to this interface (or
  148.    router). A "downstream" interface (or router) is one which is on the
  149.    path away from the group's core router with respect to this interface
  150.    (or router).
  151.  
  152.    Other terminology is introduced in its context throughout the text.
  153.  
  154. 3.  CBT Functional Overview
  155.  
  156.    The CBT protocol is designed to build and maintain a shared multicast
  157.    distribution tree that spans only those networks and links leading to
  158.    interested receivers.
  159.  
  160.    To achieve this, a host first expresses its interest in joining a
  161.    group by multicasting an IGMP host membership report [3] across its
  162.    attached link. On receiving this report, a local CBT aware router
  163.    invokes the tree joining process (unless it has already) by
  164.    generating a JOIN_REQUEST message, which is sent to the next hop on
  165.    the path towards the group's core router (how the local router
  166.    discovers which core to join is discussed in section 8). This join
  167.  
  168.  
  169.  
  170. Ballardie                     Experimental                      [Page 3]
  171.  
  172. RFC 2189              CBTv2 Protocl Specification         September 1997
  173.  
  174.  
  175.    message must be explicitly acknowledged (JOIN_ACK) either by the core
  176.    router itself, or by another router that is on the path between the
  177.    sending router and the core, which itself has already successfully
  178.    joined the tree.
  179.  
  180.    The join message sets up transient join state in the routers it
  181.    traverses, and this state consists of <group, incoming interface,
  182.    outgoing interface>. "Incoming interface" and "outgoing interface"
  183.    may be "previous hop" and "next hop", respectively, if the
  184.    corresponding links do not support multicast transmission. "Previous
  185.    hop" is taken from the incoming control packet's IP source address,
  186.    and "next hop" is gleaned from the routing table - the next hop to
  187.    the specified core address. This transient state eventually times out
  188.    unless it is "confirmed" with a join acknowledgement (JOIN_ACK) from
  189.    upstream. The JOIN_ACK traverses the reverse path of the
  190.    corresponding join message, which is possible due to the presence of
  191.    the transient join state. Once the acknowledgement reaches the router
  192.    that originated the join message, the new receiver can receive
  193.    traffic sent to the group.
  194.  
  195.    Loops cannot be created in a CBT tree because a) there is only one
  196.    active core per group, and b) tree building/maintenance scenarios
  197.    which may lead to the creation of tree loops are avoided.  For
  198.    example, if a router's upstream neighbour becomes unreachable, the
  199.    router immediately "flushes" all of its downstream branches, allowing
  200.    them to individually rejoin if necessary.  Transient unicast loops do
  201.    not pose a threat because a new join message that loops back on
  202.    itself will never get acknowledged, and thus eventually times out.
  203.  
  204.    The state created in routers by the sending or receiving of a
  205.    JOIN_ACK is bi-directional - data can flow either way along a tree
  206.    "branch", and the state is group specific - it consists of the group
  207.    address and a list of local interfaces over which join messages for
  208.    the group have previously been acknowledged. There is no concept of
  209.    "incoming" or "outgoing" interfaces, though it is necessary to be
  210.    able to distinguish the upstream interface from any downstream
  211.    interfaces. In CBT, these interfaces are known as the "parent" and
  212.    "child" interfaces, respectively. A router is not considered "on-
  213.    tree" until it has received a JOIN_ACK for a previously sent
  214.    JOIN_REQUEST.
  215.  
  216.    With regards to the information contained in the multicast forwarding
  217.    cache, on link types not supporting native multicast transmission an
  218.    on-tree router must store the address of a parent and any children.
  219.    On links supporting multicast however, parent and any child
  220.    information is represented with local interface addresses (or similar
  221.    identifying information, such as an interface "index") over which the
  222.    parent or child is reachable.
  223.  
  224.  
  225.  
  226. Ballardie                     Experimental                      [Page 4]
  227.  
  228. RFC 2189              CBTv2 Protocl Specification         September 1997
  229.  
  230.  
  231.    Data from non-member senders must be encapsulated (IP-in-IP) by the
  232.    first-hop router, and is unicast to the group's core router.
  233.    Consequently, no group state is required in the network between the
  234.    first hop router and the group's core. On arriving at the core
  235.    router, the data packet's outer encapsulating header is removed and
  236.    the packet is disemminated over the group shared tree as described
  237.    below.
  238.  
  239.    When a multicast data packet arrives at a router, the router uses the
  240.    group address as an index into the multicast forwarding cache. A copy
  241.    of the incoming multicast data packet is forwarded over each
  242.    interface (or to each address) listed in the entry except the
  243.    incoming interface.
  244.  
  245.    Each router that comprises a CBT multicast tree, except the core
  246.    router, is responsible for maintaining its upstream link, provided it
  247.    has interested downstream receivers, i.e. the child interface list is
  248.    not NULL. A child interface is one over which a member host is
  249.    directly attached, or one over which a downstream on-tree router is
  250.    attached.  This "tree maintenance" is achieved by each downstream
  251.    router periodically sending a CBT "keepalive" message (ECHO_REQUEST)
  252.    to its upstream neighbour, i.e. its parent router on the tree. One
  253.    keepalive message is sent to represent entries with the same parent,
  254.    thereby improving scalability on links which are shared by many
  255.    groups.  On multicast capable links, a keepalive is multicast to the
  256.    "all-cbt-routers" group (IANA assigned as 224.0.0.15); this has a
  257.    suppressing effect on any other router for which the link is its
  258.    parent link.  If a parent link does not support multicast
  259.    transmission, keepalives are unicast.
  260.  
  261.    The receipt of a keepalive message over a valid child interface
  262.    prompts a response (ECHO_REPLY), which is either unicast or
  263.    multicast, as appropriate.  The ECHO_REPLY message carries a list of
  264.    groups for which the corresponding interface is a child interface.
  265.  
  266.    It cannot be assumed all of the routers on a multi-access link have a
  267.    uniform view of unicast routing; this is particularly the case when a
  268.    multi-access link spans two or more unicast routing domains. This
  269.    could lead to multiple upstream tree branches being formed (an error
  270.    condition) unless steps are taken to ensure all routers on the link
  271.    agree which is the upstream router for a particular group. CBT
  272.    routers attached to a multi-access link participate in an explicit
  273.    election mechanism that elects a single router, the designated router
  274.    (DR), as the link's upstream router for all groups. Since the DR
  275.    might not be the link's best next-hop for a particular core router,
  276.    this may result in join messages being re-directed back across a
  277.    multi-access link. If this happens, the re-directed join message is
  278.    unicast across the link by the DR to the best next-hop, thereby
  279.  
  280.  
  281.  
  282. Ballardie                     Experimental                      [Page 5]
  283.  
  284. RFC 2189              CBTv2 Protocl Specification         September 1997
  285.  
  286.  
  287.    preventing a looping scenario. This re-direction only ever applies to
  288.    join messages.  Whilst this is suboptimal for join messages, which
  289.    are generated infrequently, multicast data never traverses a link
  290.    more than once (either natively, or encapsulated).
  291.  
  292.    In all but the exception case described above, all CBT control
  293.    messages are multicast over multicast supporting links to the "all-
  294.    cbt- routers" group, with IP TTL 1. The IP source address of CBT
  295.    control messages is the outgoing interface of the sending router. The
  296.    IP destination address of CBT control messages is either the "all-
  297.    cbt- routers" group address, or a unicast address, as appropriate.
  298.    All the necessary addressing information is obtained by on-tree
  299.    routers as part of tree set up.
  300.  
  301.    If CBT is implemented over a tunnelled topology, when sending a CBT
  302.    control packet over a tunnel interface, the sending router uses as
  303.    the packet's IP source address the local tunnel end point address,
  304.    and the remote tunnel end point address as the packet's IP
  305.    destination address.
  306.  
  307. 4.  Protocol Specification Details
  308.  
  309.    Details of the CBT protocol are presented in the context of a single
  310.    router implementation.
  311.  
  312. 4.1.  CBT HELLO Protocol
  313.  
  314.    The HELLO protocol is used to elect a designated router (DR) on
  315.    broadcast-type links. It is also used to elect a designated border
  316.    router (BR) when interconnecting a CBT domain with other domains (see
  317.    [5]). Alternatively, the designated BR may be elected as a matter of
  318.    local policy.
  319.  
  320.    A router represents its status as a link's DR by setting the DR-flag
  321.    on that interface; a DR flag is associated with each of a router's
  322.    broadcast interfaces. This flag can only assume one of two values:
  323.    TRUE or FALSE. By default, this flag is FALSE.
  324.  
  325.    A network manager can preference a router's DR eligibility by
  326.    optionally configuring an HELLO preference, which is included in the
  327.    router's HELLO messages.  Valid configuration values range from 1 to
  328.    254 (decimal), 1 representing the "most eligible" value. In the
  329.    absence of explicit configuration, a router assumes the default HELLO
  330.    preference value of 255. The elected DR uses HELLO preference zero
  331.    (0) in HELLO advertisements, irrespective of any configured
  332.    preference.  The DR continues to use preference zero for as long as
  333.    it is running.
  334.  
  335.  
  336.  
  337.  
  338. Ballardie                     Experimental                      [Page 6]
  339.  
  340. RFC 2189              CBTv2 Protocl Specification         September 1997
  341.  
  342.  
  343.    HELLO messages are multicast periodically to the all-cbt-routers
  344.    group, 224.0.0.15, using IP TTL 1. The advertisement period is
  345.    [HELLO_INTERVAL] seconds.
  346.  
  347.    HELLO messages have a suppressing effect on those routers which would
  348.    advertise a "lesser preference" in their HELLO messages; a router
  349.    resets its [HELLO_INTERVAL] if the received HELLO is "better" than
  350.    its own. Thus, in steady state, the HELLO protocol incurs very little
  351.    traffic overhead.
  352.  
  353.    The DR election winner is that which advertises the lowest HELLO
  354.    preference, or the lowest-addressed in the event of a tie.
  355.  
  356.    The situation where two or more routers attached to the same
  357.    broadcast link areadvertising HELLO preference 0 should never arise.
  358.    However, should this situation arise, all but the lowest addressed
  359.    zero advertising router relinquishes its claim as DR immediately by
  360.    unsetting the DR flag on the corresponding interface. The
  361.    relinquishing router(s) subsequently advertise their previously used
  362.    preference value in HELLO advertisements.
  363.  
  364. 4.1.1.  Sending HELLOs
  365.  
  366.    When a router starts up, it multicasts two HELLO messages over each
  367.    of its broadcast interfaces in successsion. The DR flag is initially
  368.    unset (FALSE) on each broadcast interface.  This avoids the situation
  369.    in which each router on a multi-access subnet believes it is the DR,
  370.    thus preventing the multiple forwarding of join-requests should they
  371.    arrive during this start up period.  If no "better" HELLO message is
  372.    received after HOLDTIME seconds, the router assumes the role of DR on
  373.    the corresponding interface.
  374.  
  375.    A router sends an HELLO message whenever its [HELLO_INTERVAL]
  376.    expires.  Whenever a router sends an HELLO message, it resets its
  377.    hello timer.
  378.  
  379. 4.1.2.  Receiving HELLOs
  380.  
  381.    A router does not respond to an HELLO message if the received HELLO
  382.    is "better" than its own, or equally preferenced but lower addressed.
  383.  
  384.    A router must respond to an HELLO message if that received is lesser
  385.    preferenced (or equally preferenced but higher addressed) than would
  386.    be sent by this router over the same interface. This response is sent
  387.    on expiry of an interval timer which is set between zero (0) and
  388.    [HOLDTIME] seconds when the lesser preferenced HELLO message is
  389.    received.
  390.  
  391.  
  392.  
  393.  
  394. Ballardie                     Experimental                      [Page 7]
  395.  
  396. RFC 2189              CBTv2 Protocl Specification         September 1997
  397.  
  398.  
  399. 4.2.  JOIN_REQUEST Processing
  400.  
  401.    A JOIN_REQUEST is the CBT control message used to register a member
  402.    host's interest in joining the distribution tree for the group.
  403.  
  404. 4.2.1.  Sending JOIN_REQUESTs
  405.  
  406.    A JOIN_REQUEST can only ever be originated by a leaf router, i.e. a
  407.    router with directly attached member hosts. This join message is sent
  408.    hop-by-hop towards the core router for the group (see section 8).
  409.    The originating router caches <group, NULL, upstream interface> state
  410.    for each join it originates. This state is known as "transient join
  411.    state".  The absence of a "downstream interface" (NULL) indicates
  412.    that this router is the join message originator, and is therefore
  413.    responsible for any retransmissions of this message if a response is
  414.    not received within [RTX_INTERVAL].  It is an error if no response is
  415.    received after [JOIN_TIMEOUT] seconds.  If this error condition
  416.    occurs, the joining process may be re-invoked by the receipt of the
  417.    next IGMP host membership report from a locally attached member host.
  418.  
  419.    Note that if the interface over which a JOIN_REQUEST is to be sent
  420.    supports multicast, the JOIN_REQUEST is multicast to the all-cbt-
  421.    routers group, using IP TTL 1.  If the link does not support
  422.    multicast, the JOIN_REQUEST is unicast to the next hop on the unicast
  423.    path to the group's core.
  424.  
  425. 4.2.2.  Receiving JOIN_REQUESTs
  426.  
  427.    On broadcast links, JOIN_REQUESTs which are multicast may only be
  428.    forwarded by the link's DR. Other routers attached to the link may
  429.    process the join (see below). JOIN_REQUESTs which are multicast over
  430.    a point-to-point link are only processed by the router on the link
  431.    which does not have a local interface corresponding to the join's
  432.    network layer (IP) source address. Unicast JOIN_REQUESTs may only be
  433.    processed by the router which has a local interface corresponding to
  434.    the join's network layer (IP) destination address.
  435.  
  436.    With regard to forwarding a received JOIN_REQUEST, if the receiving
  437.    router is not on-tree for the group, and is not the group's core
  438.    router, and has not already forwarded a join for the same group, the
  439.    join is forwarded to the next hop on the path towards the core. The
  440.    join is multicast, or unicast, according to whether the outgoing
  441.    interface supports multicast.  The router caches the following
  442.    information with respect to the forwarded join: <group, downstream
  443.    interface, upstream interface>. Subsequent JOIN_REQUESTs received for
  444.    the same group are cached until this router has received a JOIN_ACK
  445.    for the previously sent join, at which time any cached joins can also
  446.    be acknowledged.
  447.  
  448.  
  449.  
  450. Ballardie                     Experimental                      [Page 8]
  451.  
  452. RFC 2189              CBTv2 Protocl Specification         September 1997
  453.  
  454.  
  455.    If this transient join state is not "confirmed" with a join
  456.    acknowledgement (JOIN_ACK) message from upstream, the state is timed
  457.    out after [TRANSIENT_TIMEOUT] seconds.
  458.  
  459.    If the receiving router is the group's core router, the join is
  460.    "terminated" and acknowledged by means of a JOIN_ACK. Similarly, if
  461.    the router is on-tree and the JOIN_REQUEST arrives over an interface
  462.    that is not the upstream interface for the group, the join is
  463.    acknowledged.
  464.  
  465.    If a JOIN_REQUEST for the same group is scheduled to be sent over the
  466.    corresponding interface (i.e. awaiting a timer expiry), the
  467.    JOIN_REQUEST is unscheduled.
  468.  
  469.    If this router has a cache-deletion-timer [CACHE_DEL_TIMER] running
  470.    on the arrival interface for the group specified in a multicast join,
  471.    the timer is cancelled.
  472.  
  473. 4.3.  JOIN_ACK Processing
  474.  
  475.    A JOIN_ACK is the mechanism by which an interface is added to a
  476.    router's multicast forwarding cache; thus, the interface becomes part
  477.    of the group distribution tree.
  478.  
  479. 4.3.1.  Sending JOIN_ACKs
  480.  
  481.    The JOIN_ACK is sent over the same interface as the corresponding
  482.    JOIN_REQUEST was received. The sending of the acknowledgement causes
  483.    the router to add the interface to its child interface list in its
  484.    forwarding cache for the group, if it is not already.
  485.  
  486.    A JOIN_ACK is multicast or unicast, according to whether the outgoing
  487.    interface supports multicast transmission or not.
  488.  
  489. 4.3.2.  Receiving JOIN_ACKs
  490.  
  491.    The group and arrival interface must be matched to a <group, ....,
  492.    upstream interface> from the router's cached transient state. If no
  493.    match is found, the JOIN_ACK is discarded.  If a match is found, a
  494.    CBT forwarding cache entry for the group is created, with "upstream
  495.    interface" marked as the group's parent interface.
  496.  
  497.    If "downstream interface" in the cached transient state is NULL, the
  498.    JOIN_ACK has reached the originator of the corresponding
  499.    JOIN_REQUEST; the JOIN_ACK is not forwarded downstream.  If
  500.    "downstream interface" is non-NULL, a JOIN_ACK for the group is sent
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Ballardie                     Experimental                      [Page 9]
  507.  
  508. RFC 2189              CBTv2 Protocl Specification         September 1997
  509.  
  510.  
  511.    over the "downstream interface" (multicast or unicast, accordingly).
  512.    This interface is installed in the child interface list of the
  513.    group's forwarding cache entry.
  514.  
  515.    Once transient state has been confirmed by transferring it to the
  516.    forwarding cache, the transient state is deleted.
  517.  
  518. 4.4.  QUIT_NOTIFICATION Processing
  519.  
  520.    A CBT tree is "pruned" in the direction downstream-to-upstream
  521.    whenever a CBT router's child interface list for a group becomes
  522.    NULL.
  523.  
  524. 4.4.1.  Sending QUIT_NOTIFICATIONs
  525.  
  526.    A QUIT_NOTIFICATION is sent to a router's parent router on the tree
  527.    whenever the router's child interface list becomes NULL. If the link
  528.    over which the quit is to be sent supports multicast transmission, if
  529.    the sending router is the link's DR the quit is unicast, otherwise it
  530.    is multicast.
  531.  
  532.    A QUIT_NOTIFICATION is not acknowledged; once sent, all information
  533.    pertaining to the group it represents is deleted from the forwarding
  534.    cache immediately.
  535.  
  536.    To help ensure consistency between a child and parent router given
  537.    the potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX]
  538.    QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous
  539.    one.
  540.  
  541.    The sending of a quit (the first) also invokes the sending of a
  542.    FLUSH_TREE message over each downstream interface for the
  543.    corresponding group.
  544.  
  545. 4.4.2.  Receiving QUIT_NOTIFICATIONs
  546.  
  547.    The group reported in the QUIT_NOTIFICATION must be matched with a
  548.    forwarding cache entry. If no match is found, the QUIT_NOTIFICATION
  549.    is ignored and discarded.  If a match is found, if the arrival
  550.    interface is a valid child interface in the group entry, how the
  551.    router proceeds depends on whether the QUIT_NOTIFICATION was
  552.    multicast or unicast.
  553.  
  554.    If the QUIT_NOTIFICATION was unicast, the corresponding child
  555.    interface is deleted from the group's forwarding cache entry, and no
  556.    further processing is required.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Ballardie                     Experimental                     [Page 10]
  563.  
  564. RFC 2189              CBTv2 Protocl Specification         September 1997
  565.  
  566.  
  567.    If the QUIT_NOTIFICATION was multicast, and the arrival interface is
  568.    a valid child interface for the specified group, the router sets a
  569.    cache-deletion-timer [CACHE_DEL_TIMER].
  570.  
  571.    Because this router might be acting as a parent router for multiple
  572.    downstream routers attached to the arrival link, [CACHE_DEL_TIMER]
  573.    interval gives those routers that did not send the  QUIT_NOTIFICA-
  574.    TION, but received it over their parent interface, the opportunity to
  575.    ensure that the parent router does not remove the link from its child
  576.    interface list.  Therefore, on receipt of a multicast
  577.    QUIT_NOTIFICATION over a parent interface, a receiving router
  578.    schedules a JOIN_REQUEST for the group for sending at a random
  579.    interval between 0 (zero) and HOLDTIME seconds.  If a multicast
  580.    JOIN_REQUEST is received over the corresponding interface (parent)
  581.    for the same group before this router sends its own scheduled
  582.    JOIN_REQUEST, it unschedules the multicasting of its own
  583.    JOIN_REQUEST.
  584.  
  585. 4.5.  ECHO_REQUEST Processing
  586.  
  587.    The ECHO_REQUEST message allows a child to monitor reachability to
  588.    its parent router for a group (or range of groups if the parent
  589.    router is the parent for multiple groups). Group information is not
  590.    carried in ECHO_REQUEST messages.
  591.  
  592. 4.5.1.  Sending ECHO_REQUESTs
  593.  
  594.    Whenever a router creates a forwarding cache entry due to the receipt
  595.    of a JOIN_ACK, the router begins the periodic sending of ECHO_REQUEST
  596.    messages over its parent interface. The ECHO_REQUEST is multicast to
  597.    the "all-cbt-routers" group over multicast-capable interfaces, unless
  598.    the sending router is the DR on the interface over which the
  599.    ECHO_REQUEST is being sent, in which case it is unicast (as is the
  600.    corresponding ECHO_REPLY).
  601.  
  602.    ECHO_REQUEST messages are sent at [ECHO_INTERVAL] second intervals.
  603.  
  604.    Whenever an ECHO_REQUEST is sent, [ECHO_INTERVAL] is reset.
  605.  
  606.    If no response is forthcoming, any groups present on the parent
  607.    interface will eventually expire [GROUP_EXPIRE_TIME]. This results in
  608.    the sending of a QUIT_NOTIFICATION upstream, and sends a FLUSH_TREE
  609.    message downstream for each group for which the upstream interface
  610.    was the parent interface.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Ballardie                     Experimental                     [Page 11]
  619.  
  620. RFC 2189              CBTv2 Protocl Specification         September 1997
  621.  
  622.  
  623. 4.5.2.  Receiving ECHO_REQUESTs
  624.  
  625.    If an ECHO_REQUEST is received over any valid child interface, the
  626.    receiving router schedules an ECHO_REPLY message for sending over the
  627.    same interface; the scheduled interval is between 0 (zero) and
  628.    HOLDTIME seconds. This message is multicast to the "all-cbt-routers"
  629.    group over multicast-capable interfaces, and unicast otherwise.
  630.  
  631.    If a multicast ECHO_REQUEST message arrives via any valid parent
  632.    interface, the router resets its [ECHO_INTERVAL] timer for that
  633.    upstream interface, thereby suppressing the sending of its own
  634.    ECHO_REQUEST over that upstream interface.
  635.  
  636. 4.6.  ECHO_REPLY Processing
  637.  
  638.    ECHO_REPLY messages allow a child to monitor the reachability of its
  639.    parent, and help ensure the group state information is consistent
  640.    between them.
  641.  
  642. 4.6.1.  Sending ECHO_REPLY messages
  643.  
  644.    An ECHO_REPLY message is sent in response to receiving an
  645.    ECHO_REQUEST message, provided the ECHO_REQUEST is received over any
  646.    one of this router's valid child interfaces. An ECHO_REPLY reports
  647.    all groups for which the link is its child.
  648.  
  649.    ECHO_REPLY messages are unicast or multicast, as appropriate.
  650.  
  651. 4.6.2.  Receiving ECHO_REPLY messages
  652.  
  653.    An ECHO_REPLY message must be received via a valid parent interface.
  654.  
  655.    For each group reported in an ECHO_REPLY, the downstream router
  656.    attempts to match the group with one in its forwarding cache for
  657.    which the arrival interface is the group's parent interface. For each
  658.    successful match, the entry is "refreshed". If however, after
  659.    [GROUP_EXPIRE_TIME] seconds a group has not been "refreshed", a
  660.    QUIT_NOTIFICATION is sent upstream, and a FLUSH_TREE message is sent
  661.    downstream, for the group.
  662.  
  663.    If this router has directly attached members for any of the flushed
  664.    groups, the receipt of an IGMP host membership report for any of
  665.    those groups will prompt this router to rejoin the corresponding
  666.    tree(s).
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Ballardie                     Experimental                     [Page 12]
  675.  
  676. RFC 2189              CBTv2 Protocl Specification         September 1997
  677.  
  678.  
  679. 4.7.  FLUSH_TREE Processing
  680.  
  681.    The FLUSH_TREE (flush) message is the mechanism by which a router
  682.    invokes the tearing down of all its downstream branches for a
  683.    particular group. The flush message is multicast to the "all-cbt-
  684.    routers" group when sent over multicast-capable interfaces, and
  685.    unicast otherwise.
  686.  
  687. 4.7.1.  Sending FLUSH_TREE messages
  688.  
  689.    A FLUSH_TREE message is sent over each downstream (child) interface
  690.    when a router has lost reachability with its parent router for the
  691.    group (detected via ECHO_REQUEST and ECHO_REPLY messages). All group
  692.    state is removed from an interface over which a flush message is
  693.    sent.  A flush can specify a single group, or all groups
  694.    (INADDR_ANY).
  695.  
  696. 4.7.2.  Receiving FLUSH_TREE messages
  697.  
  698.    A FLUSH_TREE message must be received over the parent interface for
  699.    the specified group, otherwise the message is discarded.
  700.  
  701.    The flush message must be forwarded over each child interface for the
  702.    specified group.
  703.  
  704.    Once the flush message has been forwarded, all state for the group is
  705.    removed from the router's forwarding cache.
  706.  
  707. 5.  Non-Member Sending
  708.  
  709.    Data can be sent to a CBT tree by a sender not attached to the group
  710.    tree.  The sending host originates native multicast data, which is
  711.    promiscuously received by a local router, which must be CBT capable.
  712.    It is assumed the local CBT router knows about the relevant <core,
  713.    group> mapping, and thus can encapsulate (IP-in-IP) the data packet
  714.    and unicast it to the corresponding core router. On arriving at the
  715.    core router, the data packet is decapsulated and disemminated over
  716.    the group tree in the manner already described.
  717.  
  718. 6.  Timers and Default Values
  719.  
  720.    This section provides a summary of the timers described above,
  721.    together with their recommended default values. Other values may be
  722.    configured; if so, the values used should be consistent across all
  723.    CBT routers attached to the same network.
  724.  
  725.    o    [HELLO_INTERVAL]: the interval between sending an HELLO message.
  726.         Default: 60 seconds.
  727.  
  728.  
  729.  
  730. Ballardie                     Experimental                     [Page 13]
  731.  
  732. RFC 2189              CBTv2 Protocl Specification         September 1997
  733.  
  734.  
  735.    o    [HELLO_PREFERENCE]: Default: 255.
  736.  
  737.    o    [HOLDTIME]: generic response interval. Default: 3 seconds.
  738.  
  739.    o    [MAX_RTX]: default maximum number of retransmissions. Default 3.
  740.  
  741.    o    [RTX_INTERVAL]: message retransmission time. Default: 5 seconds.
  742.  
  743.    o    [JOIN_TIMEOUT]: raise exception due to tree join failure.
  744.         Default: 3.5 times [RTX_INTERVAL].
  745.  
  746.    o    [TRANSIENT_TIMEOUT]: delete (unconfirmed) transient state.
  747.         Default: (1.5*RTX_INTERVAL) seconds.
  748.  
  749.    o    [CACHE_DEL_TIMER]: remove child interface from forwarding cache.
  750.         Default: (1.5*HOLDTIME) seconds.
  751.  
  752.    o    [GROUP_EXPIRE_TIME]: time to send a QUIT_NOTIFICATION to our
  753.         non-responding parent.  Default: (1.5*ECHO_INTERVAL).
  754.  
  755.    o    [ECHO_INTERVAL]: interval between sending ECHO_REQUEST to parent
  756.         routers.  Default: 60 seconds.
  757.  
  758.    o    [EXPECTED_REPLY_TIME]: consider parent unreachable. Default: 70
  759.         seconds.
  760.  
  761. 7. CBT Packet Formats and Message Types
  762.  
  763.    CBT control packets are encapsulated in IP. CBT has been assigned IP
  764.    protocol number 7 by IANA [4].
  765.  
  766. 7.1.  CBT Common Control Packet Header
  767.  
  768.    All CBT control messages have a common fixed length header.
  769.  
  770.        0               1               2               3
  771.        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
  772.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  773.       |  vers | type  |  addr len     |         checksum              |
  774.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  775.  
  776.  
  777.                   Figure 1. CBT Common Control Packet Header
  778.  
  779.  
  780.    This CBT specification is version 2.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Ballardie                     Experimental                     [Page 14]
  787.  
  788. RFC 2189              CBTv2 Protocl Specification         September 1997
  789.  
  790.  
  791.    CBT packet types are:
  792.  
  793.    o    type 0: HELLO
  794.  
  795.    o    type 1: JOIN_REQUEST
  796.  
  797.    o    type 2: JOIN_ACK
  798.  
  799.    o    type 3: QUIT_NOTIFICATION
  800.  
  801.    o    type 4: ECHO_REQUEST
  802.  
  803.    o    type 5: ECHO_REPLY
  804.  
  805.    o    type 6: FLUSH_TREE
  806.  
  807.    o    type 7: Bootstrap Message (optional)
  808.  
  809.    o    type 8: Candidate Core Advertisement (optional)
  810.  
  811.  
  812.    o    Addr Length: address length in bytes of unicast or multicast
  813.         addresses carried in the control packet.
  814.  
  815.    o    Checksum: the 16-bit one's complement of the one's complement
  816.         sum of the entire CBT control packet.
  817.  
  818. 7.2.  HELLO Packet Format
  819.  
  820.     0               1               2               3
  821.     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
  822.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  823.    |                    CBT Control Packet Header                  |
  824.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  825.    |  Preference   |  option type  |  option len   |  option value |
  826.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  827.  
  828.                      Figure 2. HELLO Packet Format
  829.  
  830.  
  831.    HELLO Packet Field Definitions:
  832.  
  833.    o    preference: sender's HELLO preference.
  834.  
  835.    o    option type: the type of option present in the "option value"
  836.         field.  One option type is currently defined: option type 0
  837.         (zero) = BR_HELLO; option value 0 (zero); option length 0
  838.         (zero). This option type is used with HELLO messages sent by a
  839.  
  840.  
  841.  
  842. Ballardie                     Experimental                     [Page 15]
  843.  
  844. RFC 2189              CBTv2 Protocl Specification         September 1997
  845.  
  846.  
  847.         border router (BR) as part of designated BR election (see [5]).
  848.  
  849.    o    option len: length of the "option value" field in bytes.
  850.  
  851.    o    option value: variable length field carrying the option value.
  852.  
  853. 7.3.  JOIN_REQUEST Packet Format
  854.  
  855.  
  856.        0               1               2               3
  857.        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
  858.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  859.       |                    CBT Control Packet Header                  |
  860.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  861.       |                          group address                        |
  862.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  863.       |                          target router                        |
  864.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  865.       |                        originating router                     |
  866.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  867.       |  option type  |  option len   |        option value           |
  868.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  869.  
  870.                      Figure 3. JOIN_REQUEST Packet Format
  871.  
  872.  
  873.       JOIN_REQUEST Field Definitions
  874.  
  875.    o    group address: multicast group address of the group being joined.
  876.         For a "wildcard" join (see [5]), this field contains the value of
  877.         INADDR_ANY.
  878.  
  879.    o    target router: target (core) router for the group.
  880.  
  881.    o    originating router: router that originated this JOIN_REQUEST.
  882.  
  883.    o    option type, option len, option value: see HELLO packet format,
  884.         section 7.2.
  885.  
  886. 7.4.  JOIN_ACK Packet Format
  887.  
  888.       JOIN_ACK Field Definitions
  889.  
  890.    o    group address: multicast group address of the group being joined.
  891.  
  892.    o    target router: router (DR) that originated the corresponding
  893.         JOIN_REQUEST.
  894.  
  895.  
  896.  
  897.  
  898. Ballardie                     Experimental                     [Page 16]
  899.  
  900. RFC 2189              CBTv2 Protocl Specification         September 1997
  901.  
  902.  
  903.        0               1               2               3
  904.        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
  905.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  906.       |                    CBT Control Packet Header                  |
  907.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  908.       |                          group address                        |
  909.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  910.       |                           target router                       |
  911.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  912.       |  option type  |  option len   |         option value          |
  913.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  914.  
  915.                        Figure 4. JOIN_ACK Packet Format
  916.    o    option type, option len, option value: see HELLO packet format,
  917.         section 7.2.
  918.  
  919. 7.5.  QUIT_NOTIFICATION Packet Format
  920.  
  921.  
  922.        0               1               2               3
  923.        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
  924.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  925.       |                    CBT Control Packet Header                  |
  926.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  927.       |                          group address                        |
  928.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  929.       |                    originating child router                   |
  930.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  931.  
  932.                   Figure 5. QUIT_NOTIFICATION Packet Format
  933.  
  934.  
  935.       QUIT_NOTIFICATION Field Definitions
  936.  
  937.    o    group address: multicast group address of the group being joined.
  938.  
  939.    o    originating child router: address of the router that
  940.         originates the QUIT_NOTIFICATION.
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Ballardie                     Experimental                     [Page 17]
  955.  
  956. RFC 2189              CBTv2 Protocl Specification         September 1997
  957.  
  958.  
  959. 7.6.  ECHO_REQUEST Packet Format
  960.  
  961.  
  962.        0               1               2               3
  963.        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
  964.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  965.       |                    CBT Control Packet Header                  |
  966.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  967.       |                    originating child router                   |
  968.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  969.  
  970.                      Figure 6. ECHO_REQUEST Packet Format
  971.  
  972.  
  973.       ECHO_REQUEST Field Definitions
  974.  
  975.    o    originating child router: address of the router that
  976.         originates the ECHO_REQUEST.
  977.  
  978.  
  979. 7.7.  ECHO_REPLY Packet Format
  980.  
  981.  
  982.        0               1               2               3
  983.        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
  984.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  985.       |                    CBT Control Packet Header                  |
  986.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  987.       |                    originating parent router                  |
  988.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  989.       |                       group address #1                        |
  990.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  991.       |                       group address #2                        |
  992.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  993.       |                           ......                              |
  994.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  995.       |                       group address #n                        |
  996.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  997.  
  998.                       Figure 7. ECHO_REPLY Packet Format
  999.  
  1000.  
  1001.       ECHO_REPLY Field Definitions
  1002.  
  1003.    o    oringinating parent router: address of the router originating
  1004.         this ECHO_REPLY.
  1005.  
  1006.    o    group address: a list of multicast group addresses for which
  1007.  
  1008.  
  1009.  
  1010. Ballardie                     Experimental                     [Page 18]
  1011.  
  1012. RFC 2189              CBTv2 Protocl Specification         September 1997
  1013.  
  1014.  
  1015.         this router considers itself a parent router w.r.t. the link
  1016.         over which this message is sent.
  1017.  
  1018. 7.8.  FLUSH_TREE Packet Format
  1019.  
  1020.  
  1021.        0               1               2               3
  1022.        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
  1023.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1024.       |                    CBT Control Packet Header                  |
  1025.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1026.       |                         group address                         |
  1027.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1028.       |                           ......                              |
  1029.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1030.       |                       group address #n                        |
  1031.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1032.  
  1033.                       Figure 8. FLUSH_TREE Packet Format
  1034.  
  1035.  
  1036.       FLUSH_TREE Field Definitions
  1037.  
  1038.    o    group address(es): multicast group address(es) of the group(s)
  1039.         being "flushed".
  1040.  
  1041. 8.  Core Router Discovery
  1042.  
  1043.    There are two available options for CBTv2 core discovery; the
  1044.    "bootstrap" mechanism (as currently specified with the PIM sparse
  1045.    mode protocol [2]) is applicable only to intra-domain core discovery,
  1046.    and allows for a "plug & play" type operation with minimal
  1047.    configuration.  The disadvantage of the bootstrap mechanism is that
  1048.    it is much more difficult to affect the shape, and thus optimality,
  1049.    of the resulting distribution tree.  Also, to be applicable, all CBT
  1050.    routers within a domain must implement the bootstrap mechanism.
  1051.  
  1052.    The other option is to manually configure leaf routers with <core,
  1053.    group> mappings (note: leaf routers only); this imposes a degree of
  1054.    administrative burden - the mapping for a particular group must be
  1055.    coordinated across all leaf routers to ensure consistency. Hence,
  1056.    this method does not scale particularly well. However, it is likely
  1057.    that "better" trees will result from this method, and it is also the
  1058.    only available option for inter-domain core discovery currently
  1059.    available.
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Ballardie                     Experimental                     [Page 19]
  1067.  
  1068. RFC 2189              CBTv2 Protocl Specification         September 1997
  1069.  
  1070.  
  1071. 8.1.  "Bootstrap" Mechanism Overview
  1072.  
  1073.    It is unlikely that the bootstrap mechanism will be appended to a
  1074.    well-known network layer protocol, such as IGMP [3], though this
  1075.    would facilitate its ubiquitous (intra-domain) deployment. Therefore,
  1076.    each multicast routing protocol requiring the bootstrap mechanism
  1077.    must implement it as part of the multicast routing protocol itself.
  1078.  
  1079.    A summary of the operation of the bootstrap mechanism follows
  1080.    (details are provided in [7]). It is assumed that all routers within
  1081.    the domain implement the "bootstrap" protocol, or at least forward
  1082.    bootstrap protocol messages.
  1083.  
  1084.    A subset of the domain's routers are configured to be CBT candidate
  1085.    core routers. Each candidate core router periodically (default every
  1086.    60 secs) advertises itself to the domain's Bootstrap Router (BSR),
  1087.    using  "Core Advertisement" messages.  The BSR is itself elected
  1088.    dynamically from all (or participating) routers in the domain.  The
  1089.    domain's elected BSR collects "Core Advertisement" messages from
  1090.    candidate core routers and periodically advertises a candidate core
  1091.    set (CC-set) to each other router in the domain, using traditional
  1092.    hop- by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to
  1093.    advertise the CC-set. Together, "Core Advertisements" and "Bootstrap
  1094.    Messages" comprise the "bootstrap" protocol.
  1095.  
  1096.    When a router receives an IGMP host membership report from one of its
  1097.    directly attached hosts, the local router uses a hash function on the
  1098.    reported group address, the result of which is used as an index into
  1099.    the CC-set. This is how local routers discover which core to use for
  1100.    a particular group.
  1101.  
  1102.    Note the hash function is specifically tailored such that a small
  1103.    number of consecutive groups always hash to the same core.
  1104.    Furthermore, bootstrap messages can carry a "group mask", potentially
  1105.    limiting a CC-set to a particular range of groups. This can help
  1106.    reduce traffic concentration at the core.
  1107.  
  1108.    If a BSR detects a particular core as being unreachable (it has not
  1109.    announced its availability within some period), it deletes the
  1110.    relevant core from the CC-set sent in its next bootstrap message.
  1111.    This is how a local router discovers a group's core is unreachable;
  1112.    the router must re-hash for each affected group and join the new core
  1113.    after removing the old state. The removal of the "old" state follows
  1114.    the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message
  1115.    downstream.
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Ballardie                     Experimental                     [Page 20]
  1123.  
  1124. RFC 2189              CBTv2 Protocl Specification         September 1997
  1125.  
  1126.  
  1127. 8.2.  Bootstrap Message Format
  1128.  
  1129.      0               1               2               3
  1130.      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
  1131.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1132.     |             CBT common control packet header                  |
  1133.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1134.     |      For full Bootstrap Message specification, see [7]        |
  1135.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1136.  
  1137.                    Figure 9. Bootstrap Message Format
  1138.  
  1139.  
  1140. 8.3.  Candidate Core Advertisement Message Format
  1141.  
  1142.  
  1143.      0               1               2               3
  1144.      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
  1145.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1146.     |              CBT common control packet header                 |
  1147.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1148.     |   For full Candidate Core Adv. Message specification, see [7] |
  1149.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1150.  
  1151.          Figure 10. Candidate Core Advertisement Message Format
  1152.  
  1153. 9.  Interoperability Issues
  1154.  
  1155.    Interoperability between CBT and DVMRP is specified in [5].
  1156.  
  1157.    Interoperability with other multicast protocols will be fully
  1158.    specified as the need arises.
  1159.  
  1160. 10.  Security Considerations
  1161.  
  1162.    Security considerations are not addressed in this memo.
  1163.  
  1164.    Whilst multicast security is a topic of ongoing research, multicast
  1165.    applications (users) nevertheless have the ability to take advantage
  1166.    of security services such as encryption or/and authentication
  1167.    provided such services are supported by the applications.
  1168.  
  1169.    RFCs 1949 and 2093/2094 discuss different ways of distributing
  1170.    multicast key material, which can result in the provision of network
  1171.    layer access control to a multicast distribution tree.
  1172.  
  1173.    [9] offers a synopsis of multicast security threats and proposes some
  1174.    possible counter measures.
  1175.  
  1176.  
  1177.  
  1178. Ballardie                     Experimental                     [Page 21]
  1179.  
  1180. RFC 2189              CBTv2 Protocl Specification         September 1997
  1181.  
  1182.  
  1183.    Beyond these, little published work exists on the topic of multicast
  1184.    security.
  1185.  
  1186. Acknowledgements
  1187.  
  1188.    Special thanks goes to Paul Francis, NTT Japan, for the original
  1189.    brainstorming sessions that brought about this work.
  1190.  
  1191.    The emergence of CBTv2 owes much to Clay Shields and his work on
  1192.    Ordered CBT (OCBT) [8]. Clay identified and proved several failure
  1193.    modes of CBT as it was specified with multiple cores, and also
  1194.    suggested using an unreliable quit mechanism, which appears in this
  1195.    specification as the QUIT_NOTIFICATION. Clay has also provided more
  1196.    general constructive comments on the CBT architecture and
  1197.    specification.
  1198.  
  1199.    Others that have contributed to the progress of CBT include Ken
  1200.    Carlberg, Eric Crawley, Jon Crowcroft, Mark Handley, Ahmed Helmy,
  1201.    Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, Scott
  1202.    Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, Paul
  1203.    White, and other participants of the IETF IDMR working group.
  1204.  
  1205.    Thanks also to 3Com Corporation and British Telecom Plc for funding
  1206.    this work.
  1207.  
  1208. References
  1209.  
  1210.    [1] Core Based Trees (CBT) Multicast Routing Architecture; A.
  1211.    Ballardie; RFC 2201, September 1997.
  1212.  
  1213.    [2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D.
  1214.    Estrin et al; ftp://netweb.usc.edu/pim   Working drafts, 1996.
  1215.  
  1216.    [3] Internet Group Management Protocol, version 2 (IGMPv2); W.
  1217.    Fenner; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-
  1218.    v2-**.txt.  Working draft, 1996.
  1219.  
  1220.    [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  1221.    October 1994.
  1222.  
  1223.    [5] CBT Border Router Specification for Interconnecting a CBT Stub
  1224.    Region to a DVMRP Backbone; A. Ballardie;
  1225.    ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-dm-
  1226.    interop-**.txt.  Working draft,  March 1997.
  1227.  
  1228.    [6] Ballardie, A., "Scalable Multicast Key Distribution", RFC 1949,
  1229.    July 1996.
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Ballardie                     Experimental                     [Page 22]
  1235.  
  1236. RFC 2189              CBTv2 Protocl Specification         September 1997
  1237.  
  1238.  
  1239.    [7] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast
  1240.    Routing; D. Estrin et al.; Technical Report;
  1241.    ftp://catarina.usc.edu/pim
  1242.  
  1243.    [8] The Ordered Core Based Tree Protocol; C. Shields and J.J. Garcia-
  1244.    Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan, April
  1245.    1997;
  1246.    http://www.cse.ucsc.edu/research/ccrg/publications/infocomm97ocbt.ps.gz
  1247.  
  1248.    [9]  Multicast-Specific Security Threats and Counter-Measures; A.
  1249.    Ballardie and J. Crowcroft; In Proceedings "Symposium on Network and
  1250.    Distributed System Security", February 1995, pp.2-16.
  1251.  
  1252.  
  1253.  
  1254. Author Information:
  1255.  
  1256.    Tony Ballardie,
  1257.    Research Consultant
  1258.  
  1259.    EMail: ABallardie@acm.org
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Ballardie                     Experimental                     [Page 23]
  1291.  
  1292.