home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-idmr-gum-01.txt < prev    next >
Text File  |  1997-11-01  |  53KB  |  1,391 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. IDMR Working Group                                          D. Thaler
  7. Internet Engineering Task Force                           U. Michigan
  8. INTERNET-DRAFT                                              D. Estrin
  9. October 30, 1997                                              USC/ISI
  10. Expires April 1998                                           D. Meyer
  11.                                                             U. Oregon
  12.                                                               Editors
  13.  
  14.  
  15.  
  16.                Border Gateway Multicast Protocol (BGMP):
  17.                          Protocol Specification
  18.                       <draft-ietf-idmr-gum-01.txt>
  19.  
  20.  
  21.  
  22.  
  23.  
  24. Status of this Memo
  25.  
  26. This document is an Internet Draft.  Internet Drafts are working
  27. documents of the Internet Engineering Task Force (IETF), its Areas, and
  28. its Working Groups.  Note that other groups may also distribute working
  29. documents as Internet Drafts.
  30.  
  31. Internet Drafts are valid for a maximum of six months and may be
  32. updated, replaced, or obsoleted by other documents at any time.  It is
  33. inappropriate to use Internet Drafts as reference material or to cite
  34. them other than as a "work in progress".
  35.  
  36.  
  37. Abstract
  38.  
  39. This document describes BGMP, a protocol for inter-domain multicast
  40. routing. BGMP builds shared trees for active multicast groups, and
  41. allows receiver domains to build source-specific, inter-domain,
  42. distribution branches where needed. Building upon concepts from CBT and
  43. PIM-SM, BGMP requires that each multicast group be associated with a
  44. single root (in BGMP it is referred to as the root domain).  BGMP
  45. assumes that at any point in time, different ranges of the class D space
  46. are associated (e.g., with MASC [MASC]) with different domains.  Each of
  47. these domains then becomes the root of the shared domain-trees for all
  48. groups in its range.  Multicast participants will generally receive
  49. better multicast service if the session initiator's address allocator
  50. selects addresses from its own domain's part of the space, thereby
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61. Draft                             BGMP                      October 1997
  62.  
  63.  
  64. causing the root domain to be local to at least one of the session
  65. participants.
  66.  
  67.  
  68. 1.  Acknowledgements
  69.  
  70.    In addition to the authors, the following individuals have
  71.    contributed to the design of BGMP: Cengiz Alaettinoglu, Tony
  72.    Ballardie, Steve Casner, Steve Deering, Dino Farinacci, Bill Fenner,
  73.    Mark Handley, Ahmed Helmy, Van Jacobson, and Satish Kumar.
  74.  
  75.    This document is the product of the IETF IDMR Working Group with Dave
  76.    Thaler, Deborah Estrin, and David Meyer as editors.
  77.  
  78.  
  79. 2.  Purpose
  80.  
  81.    It has been suggested that inter-domain multicast is better supported
  82.    with a rendezvous mechanism whereby members receive source's data
  83.    packets without any sort of global broadcast (e.g., DVMRP and PIM-DM
  84.    broadcast initial data packets and MOSPF broadcasts membership
  85.    information). CBT [CBT] and PIM-SM [PIMSM] use a shared group-tree,
  86.    to which all members join and thereby hear from all sources (and to
  87.    which non-members do not join and thereby hear from no sources).
  88.  
  89.    This document describes BGMP, a protocol for inter-domain multicast
  90.    routing.  BGMP builds shared trees for active multicast groups, and
  91.    allows domains to build source-specific, inter-domain, distribution
  92.    branches where needed. Building upon concepts from CBT and PIM-SM,
  93.    BGMP requires that each global multicast group be associated with a
  94.    single root.  However, in BGMP, the root is an entire exchange or
  95.    domain, rather than a single router.
  96.  
  97.    BGMP assumes that ranges of the class D space have been associated
  98.    (e.g., with MASC [MASC]) with selected domains. Each such domain then
  99.    becomes the root of the shared domain-trees for all groups in its
  100.    range.  An address allocator will generally achieve better
  101.    distribution trees if it takes its multicast addresses from its own
  102.    domain's part of the space, thereby causing the root domain to be
  103.    local.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Expires April 1998                                              [Page 2]
  115.  
  116.  
  117.  
  118.  
  119. Draft                             BGMP                      October 1997
  120.  
  121.  
  122. 3.  Terminology
  123.  
  124. This document uses the following technical terms:
  125.  
  126. Domain:
  127.      A set of one or more contiguous links and zero or more routers
  128.      surrounded by one or more multicast border routers. Note that this
  129.      loose definition of domain also applies to an external link between
  130.      two domains, as well as an exchange.
  131.  
  132. Root Domain:
  133.      When constructing a shared tree of domains for some group, one
  134.      domain will be the "root" of the tree.  The root domain receives
  135.      data from each sender to the group, and functions as a rendezvous
  136.      domain toward which member domains can send inter-domain joins, and
  137.      to which sender domains can send data.
  138.  
  139. Multicast RIB:
  140.      The Routing Information Base, or routing table, used to calculate
  141.      the "next-hop" towards a particular address for multicast traffic.
  142.  
  143. Multicast IGP (M-IGP):
  144.      A generic term for any multicast routing protocol used for tree
  145.      construction within a domain.  Typical examples of M-IGPs are:
  146.      DVMRP, PIM-DM, PIM-SM, CBT, and MOSPF.
  147.  
  148. EGP: A generic term for the interdomain unicast routing protocol in use.
  149.      Typically, this will be some version of BGP which can support a
  150.      Multicast RIB, such as BGP4+ [MBGP], containing both unicast and
  151.      multicast address prefixes.
  152.  
  153. Component:
  154.      The portion of a border router associated with (and logically
  155.      inside) a particular domain that runs the multicast IGP (M-IGP) for
  156.      that domain, if any.  Each border router thus has zero or more
  157.      components inside routing domains. In addition, each border router
  158.      with external links that do not fall inside any routing domain will
  159.      have an inter-domain component that runs BGMP.
  160.  
  161. External peer:
  162.      A border router in another multicast AS (autonomous system, as used
  163.      in BGP), to which an eBGP session is open.
  164.  
  165. Internal peer:
  166.      Another border router of the same multicast AS.  A border router
  167.  
  168.  
  169.  
  170.  
  171.  
  172. Expires April 1998                                              [Page 3]
  173.  
  174.  
  175.  
  176.  
  177. Draft                             BGMP                      October 1997
  178.  
  179.  
  180.      either speaks iBGP ("internal" BGP) directly to internal peers in a
  181.      full mesh, or indirectly through an route reflector [REFLECT].
  182.  
  183. Next-hop peer:
  184.      The next-hop peer towards a given IP address is the next EGP router
  185.      on the path to the given address, according to multicast RIB routes
  186.      in the EGP's routing table (e.g., in BGP4+, routes whose Subsequent
  187.      Address Family Identifier field indicates that the route is valid
  188.      for multicast traffic).
  189.  
  190. target:
  191.      Either an EGP peer, or an M-IGP component on the same router.
  192.  
  193. Tree State Table:
  194.      This is a table of (S-prefix,G-prefix) entries (including (*,G-
  195.      prefix) entries) that have been explicitly joined by a set of
  196.      targets.  Each entry has, in addition to the source and group
  197.      addresses and masks, a list of targets that have explicitly
  198.      requested data (on behalf of directly connected hosts or on behalf
  199.      of downstream routers).  (S,G) entries also have an "SPT" bit.
  200.  
  201.  
  202. 4.  Protocol Overview
  203.  
  204.    BGMP maintains group-prefix state in response to messages from BGMP
  205.    peers and notifications from M-IGP components. Group-shared trees are
  206.    rooted at the domain advertising the group prefix covering those
  207.    groups.  When a receiver joins a specific group address, the border
  208.    router towards the root domain generates a group-specific Join
  209.    message, which is then forwarded Border-Router-by-Border-Router
  210.    towards the root domain (see Figure 1).  Note that BGMP Join and
  211.    Prune messages are sent over TCP connections between BGMP peers, and
  212.    hence BGMP protocol state is refreshed by the TCP keep-alives.
  213.  
  214.    BGMP routers build group-specific bidirectional forwarding state as
  215.    they process the BGMP Join messages. Bidirectional forwarding state
  216.    means that packets received from any target are forwarded to all
  217.    other targets in the target list without any RPF checks.  No group-
  218.    specific state or traffic exists in parts of the network where there
  219.    are no members of that group.
  220.  
  221.    BGMP routers build source-specific unidirectional forwarding state
  222.    only where it is needed to be compatible with source-specific M-IGP
  223.    distribution trees.  For example, a transit domain that uses DVMRP,
  224.    PIM-DM, or PIM-SM as its M-IGP, may need to inject multicast packets
  225.  
  226.  
  227.  
  228.  
  229.  
  230. Expires April 1998                                              [Page 4]
  231.  
  232.  
  233.  
  234.  
  235. Draft                             BGMP                      October 1997
  236.  
  237.  
  238.    from different sources via different border routers (to be compatible
  239.    with the M-IGP RPF checks).  Therefore, the BGMP router that is
  240.    responsible for injecting a particular source's packets may build a
  241.    source-specific BGMP branch if it is not already receiving that
  242.    source's packets via the shared tree (see Transit_1 in Figure 1, for
  243.    Src_A).  Note however, that a stub domain that has only a single ISP
  244.    connection will receive all multicast data packets through the single
  245.    BGMP router to which all RPF checks point; and therefore that BGMP
  246.    router need never build external source-specific distribution paths
  247.    (see Rcvr_Stub_7 in Figure 1).
  248.  
  249.                     Root_Domain
  250.                      [BR61]--------------------------\
  251.                         |                            |
  252.                      [BR32]                         [BR41]
  253.                     Transit_3                     Transit_4
  254.                      [BR31]                      [BR42] [BR43]
  255.                         |                          |      |
  256.                      [BR22]                      [BR52] [BR53]
  257.                     Transit_2                     Transit_5
  258.                      [BR21]                         [BR51]
  259.                         |                            |
  260.                      [BR12]                         [BR61]
  261.                     Transit_1[BR11]----------[BR62]Stub_6
  262.                      [BR13]                        (Src_A)
  263.                         |                          (Rcvr_D)
  264.               -------------------
  265.               |                 |
  266.            [BR71]              [BR81]
  267.           Rcvr_Stub_7       Src_only_Stub_8
  268.           (Rcvr_C)             (Src_B)
  269.  
  270.    Figure 1: Example inter-domain topology. [BRXY] represents a BGMP border
  271.    router.  Transit_X is a transit domain network.  *_Stub_X is a stub
  272.    domain network.
  273.  
  274.  
  275.    Data packets are forwarded based on a combination of BGMP and M-IGP
  276.    rules. The router forwards to a set of targets according to a
  277.    matching (S,G) BGMP tree state entry if it exists. If not found, the
  278.    router checks for a matching (*,G) BGMP tree state entry. If neither
  279.    is found, then the packet is sent natively to the next-hop EGP peer
  280.    for G, according to the Multicast RIB (for example, in the case of a
  281.    non-member sender such as Src_B in Figure 1). If a matching entry was
  282.    found, the packet is forwarded to all other targets in the target
  283.  
  284.  
  285.  
  286.  
  287.  
  288. Expires April 1998                                              [Page 5]
  289.  
  290.  
  291.  
  292.  
  293. Draft                             BGMP                      October 1997
  294.  
  295.  
  296.    list. In this way BGMP trees forward data in a bidirectional manner.
  297.    If a target is an M-IGP component then forwarding is subject to the
  298.    rules of that M-IGP protocol.
  299.  
  300.  
  301. 4.1.  Design Rationale
  302.  
  303.    Several other protocols, or protocol proposals, build shared trees
  304.    within domains [CBT, HPIM, PIM-SM].  The design choices made for BGMP
  305.    result from our focus on Inter-Domain multicast in particular. The
  306.    design choices made by CBT and PIM-SM are better suited to the wide-
  307.    area intra-domain case.  There are three major differences between
  308.    BGMP and other shared-tree protocols:
  309.  
  310.    (1) Unidirectional vs. Bidirectional trees
  311.  
  312.    Bidirectional trees (using bidirectional forwarding state as
  313.    described above) minimize third party dependence which is essential
  314.    in the inter-domain context. For example, in Figure 1, stub domains 7
  315.    and 8 would like to exchange multicast packets without being
  316.    dependent on the quality of connectivity of the root domain.
  317.    However, unidirectional shared trees (i.e., those using RPF checks)
  318.    have more aggressive loop prevention and share the same processing
  319.    rules as source-specific entries which are inherently unidirectional.
  320.  
  321.    The lack of third party dependence concerns in the INTRA domain case
  322.    reduces the incentive to employ bidirectional trees.  BGMP supports
  323.    bidirectional trees because it has to, and because it can without
  324.    excessive cost.
  325.  
  326.    (2) Source-specific distribution trees/branches
  327.  
  328.    In a departure from other shared tree protocols, source-specific BGMP
  329.    state is built ONLY where (a) it IS needed to pull the multicast
  330.    traffic down to a BGMP router that has source-specific (S,G) state,
  331.    and (b) that router is NOT already on the shared tree (i.e., has no
  332.    (*,G) state). We build these source specific branches because most
  333.    M-IGP protocols in use today build source-specific distribution trees
  334.    and would suffer unnecessary overhead if they were not able to import
  335.    packets from high datarate sources via the border router that matches
  336.    the domain's source-specific RPF checks (e.g., BR11 in Figure 1, for
  337.    data from Src_A).  Moreover, some cases in which bidirectional-shared
  338.    tree distribution paths are significantly longer than source-specific
  339.    tree distribution paths, will benefit from these source-specific
  340.    short cuts.
  341.  
  342.  
  343.  
  344.  
  345.  
  346. Expires April 1998                                              [Page 6]
  347.  
  348.  
  349.  
  350.  
  351. Draft                             BGMP                      October 1997
  352.  
  353.  
  354.    However, we do not build source-specific inter-domain trees because
  355.    (a) inter-domain connectivity is generally less rich than intra-
  356.    domain connectivity, so shared distribution trees should have more
  357.    acceptible path length and traffic concentration properties in the
  358.    inter-domain context, than in the intra-domain case, and (b) by
  359.    having the shared tree state always take precedence over source-
  360.    specific tree state, we avoid ambiguities that can otherwise arise.
  361.  
  362.    In summary, BGMP trees are, in a sense, a hybrid between CBT and
  363.    PIM-SM trees.
  364.  
  365.    (3) Method of choosing root of group shared tree
  366.  
  367.    The choice of a group's shared-tree-root has implications for
  368.    performance and policy.  In the intra-domain case it can be assumed
  369.    that all potential shared-tree roots (RPs/Cores) within the domain
  370.    are equally suited to be the root for a group that is initiated
  371.    within that domain. In the INTER-domain case, there is far more
  372.    opportunity for unacceptably poor locality and administrative
  373.    ownership of a group's shared-tree root. Therefore in the intra-
  374.    domain case, other protocols treat all candidate roots (RPs or Cores)
  375.    as equivalent and emphasize load sharing and stability to maximize
  376.    performance.  In the Inter-Domain case, all roots are not equivalent,
  377.    and we adopt an approach whereby a group's root domain is not random
  378.    and is subject to administrative and performance input.
  379.  
  380.  
  381. 5.  Protocol Details
  382.  
  383.    In this section, we describe the detailed protocol that border
  384.    routers perform.  We assume that each border router conforms to the
  385.    component-based model described in [INTEROP].
  386.  
  387.  
  388. 5.1.  Interaction with the EGP
  389.  
  390.    A fundamental requirement imposed by BGMP on the design of an EGP is
  391.    that it be able to carry multicast prefixes.  For example, a multi-
  392.    protocol BGP (MBGP) must be able to carry a multicast prefix in the
  393.    Unicast Network Layer Reachability Information (NLRI) field of the
  394.    UPDATE message (i.e., either a IPv4 class D prefix or a IPv6 prefix
  395.    with high-order octet equal to FF [IPv6MAA]). This capability is
  396.    required by BGMP in the implementation of bi-directional trees; BGMP
  397.    must be able to forward data and control packets to the next hop
  398.    towards either a unicast source S or a multicast group G (see section
  399.  
  400.  
  401.  
  402.  
  403.  
  404. Expires April 1998                                              [Page 7]
  405.  
  406.  
  407.  
  408.  
  409. Draft                             BGMP                      October 1997
  410.  
  411.  
  412.    5.2). It is also required that the path attributes defined in
  413.    [RFC1771] have the same semantics whether they are accompany unicast
  414.    or multicast NLRI.
  415.  
  416.    Note that BGP4+ [MBGP] can be easily extended to satisfy the
  417.    requirement described above. [MBGP] defines the optional transitive
  418.    attributes Multiprotocol Reachable NLRI (MP_REACH_NLRI) and
  419.    Multiprotocol Unreachable (MP_UNREACH_NRLI) to carry sets of
  420.    reachable or unreachable destinations, and the appropriate next hop
  421.    in the case of MP_REACH_NLRI. These attributes contain an Address
  422.    Family Information field [RFC1700] which indicates the type of NLRI
  423.    carried in the attribute. In addition, the attribute carries another
  424.    field, the Subsequent Address Family Identifier, or SAFI, which can
  425.    be used to provide additional information about the type of NLRI. For
  426.    example, SAFI value two indicates that the NLRI is valid for
  427.    multicast forwarding.  BGMP's requirement can be satisfied by
  428.    allowing the NLRI field of the MP_REACH_NLRI (or MP_UNREACH_NLRI) to
  429.    carry a multicast prefix in the Prefix field of the NLRI encoding.
  430.  
  431.    Finally, while not required for correct BGMP operation, the design of
  432.    an EGP should also provide a mechanism that allows discrimination
  433.    between NLRI that is to be used for unicast forwarding and NLRI to be
  434.    used for multicast forwarding. This property is required to support
  435.    multicast specific policy. As mentioned above, BGP4+ specified in
  436.    [MBGP] has this capability.
  437.  
  438.  
  439. 5.2.  Multicast Data Packet Processing
  440.  
  441.    For BGMP rules to be applied, an incoming packet must first be
  442.    "accepted":
  443.  
  444.    o  If the packet was received from an external peer, the packet is
  445.       accepted.
  446.  
  447.    o  If the packet arrived on an interface owned by an M-IGP, the M-IGP
  448.       component determines whether the packet should be accepted or
  449.       dropped according to its rules.  If the packet is accepted, the
  450.       packet is forwarded (or not forwarded) out any other interfaces
  451.       owned by the same component, as specified by the M-IGP.
  452.  
  453.    If the packet is accepted, then the router checks the tree state
  454.    table for a matching (S,G) entry.  If one is found, but the packet
  455.    was not received from the next hop target towards S (if the entry's
  456.    SPT bit is True), or was not received from the next hop target
  457.  
  458.  
  459.  
  460.  
  461.  
  462. Expires April 1998                                              [Page 8]
  463.  
  464.  
  465.  
  466.  
  467. Draft                             BGMP                      October 1997
  468.  
  469.  
  470.    towards G (if the entry's SPT bit is False) then the packet is
  471.    dropped and no further actions are taken.  If no (S,G) entry was
  472.    found, the router then checks for a matching (*,G) entry.
  473.  
  474.    If neither is found, then the packet is forwarded towards the next-
  475.    hop peer for G, according to the Multicast RIB.  If a matching entry
  476.    was found, the packet is forwarded to all other targets in the target
  477.    list.
  478.  
  479.    Forwarding to a target which is an M-IGP component means that the
  480.    packet is forwarded out any interfaces owned by that component
  481.    according to that component's multicast forwarding rules.
  482.  
  483.  
  484. 5.3.  BGMP processing of Join and Prune messages and notifications
  485.  
  486. 5.3.1.  Receiving Joins
  487.  
  488.    When the BGMP component receives a (*,G) or (S,G) Join alert from
  489.    another component, or a BGMP (S,G) or (*,G) Join message from a peer
  490.    (either internal or external), it searches the tree state table for a
  491.    matching entry.  If an entry is found, and that peer is already
  492.    listed in the target list, then the entry's timer is restarted and no
  493.    further actions are taken.
  494.  
  495.    Otherwise, if no (*,G) or (S,G) entry was found, one is created.  In
  496.    the case of a (*,G), the target list is initialized to contain the
  497.    next-hop peer towards G, if it is an external peer. If the peer is
  498.    internal, the target list is initialized to contain the M-IGP
  499.    component owning the next-hop interface.  If there is no next-hop
  500.    peer (because G is inside the domain), then the target list is
  501.    initialized to contain the next-hop component. If a (S,G) entry
  502.    exists for the same G for which the (*,G) Join is being processed,
  503.    and the next-hop peers toward S and G are different, the BGMP router
  504.    must first send a (S,G) Prune message toward the source and clear the
  505.    SPT bit on the (S,G) entry, before activating the (*,G) entry.
  506.  
  507.    The component or peer from which the Join was received is then added
  508.    to the target list.  The router then looks up S or G in the Multicast
  509.    RIB to find the next-hop EGP peer.  If the target list, not including
  510.    the next-hop target towards G for a (*,G) entry, becomes non-null as
  511.    a result, the next-hop EGP peer must be notified as follows:
  512.  
  513.    a) If the next-hop peer towards G (for a (*,G) entry) is an external
  514.       peer, a BGMP (*,G) Join message is unicast to the external peer.
  515.  
  516.  
  517.  
  518.  
  519.  
  520. Expires April 1998                                              [Page 9]
  521.  
  522.  
  523.  
  524.  
  525. Draft                             BGMP                      October 1997
  526.  
  527.  
  528.       If the next-hop peer towards S (for an (S,G) entry) is an external
  529.       peer, and the router does NOT have any active (*,G) state for that
  530.       group address G, a BGMP (S,G) Join message is unicast to the
  531.       external peer.  A BGMP (S,G) Join message is never sent to an
  532.       external peer by a router that also contains active (*,G) state
  533.       for the same group.  If the next-hop peer towards S (for an (S,G
  534.       entry) is an external peer and the router DOES have active (*,G)
  535.       state for that group G, the SPT bit is always set to False.
  536.  
  537.    b) If the next-hop peer is an internal peer, a BGMP (*,G) Join
  538.       message (for a (*,G) entry) or (S,G) Join message (for an (S,G)
  539.       entry) is unicast to the internal peer, In addition, a (*,G) or
  540.       (S,G) Join alert is sent to the M-IGP component owning the next-
  541.       hop interface.
  542.  
  543.    c) If there is no next-hop peer, a (*,G) or (S,G) Join alert is sent
  544.       to the M-IGP component owning the next-hop interface.
  545.  
  546.  
  547. 5.3.2.  Receiving Prune Notifications
  548.  
  549.    When the BGMP component receives a (*,G) or (S,G) Prune alert from
  550.    another component, or a BGMP (*,G) or (S,G) Prune message from a peer
  551.    (either internal or external), it searches the tree state table for a
  552.    matching entry.  If no (S,G) entry was found for an (S,G) Prune, but
  553.    (*,G) state exists, an (S,G) entry is created, with the target list
  554.    copied from the (*,G) entry.  If no matching entry exists, or if the
  555.    component or peer is not listed in the target list, no further
  556.    actions are taken.
  557.  
  558.    Otherwise, the component or peer is removed from the target list. If
  559.    the target list becomes null as a result, the next-hop peer towards G
  560.    (for a (*,G) entry), or towards S (for an (S,G) entry if and only if
  561.    the BGMP router does NOT have any corresponding (*,G) entry), must be
  562.    notified as follows.
  563.  
  564.    a) If the peer is an external peer, a BGMP (*,G) or (S,G) Prune
  565.       message is unicast to it.
  566.  
  567.    b) If the next-hop peer is an internal peer, a BGMP (*,G) or (S,G)
  568.       Prune message is unicast to the internal peer.  In addition, a
  569.       (*,G) or (S,G) Prune alert is sent to the M-IGP component owning
  570.       the next-hop interface.
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578. Expires April 1998                                             [Page 10]
  579.  
  580.  
  581.  
  582.  
  583. Draft                             BGMP                      October 1997
  584.  
  585.  
  586.    c) If there is no next-hop peer, a (*,G) or (S,G) Prune alert is sent
  587.       to the M-IGP component owning the next-hop interface.
  588.  
  589.  
  590.  
  591. 5.3.3.  Receiving Route Change Notifications
  592.  
  593.    When a border router receives a route for a new prefix in the
  594.    multicast RIB, or a existing route for a prefix is withdrawn, a route
  595.    change notification for that prefix must be sent to the BGMP
  596.    component.  In addition, when the next hop peer (according to the
  597.    multicast RIB) changes, a route change notification for that prefix
  598.    must be sent to the BGMP component.
  599.  
  600.    In addition, an internal route for each class-D prefix associated
  601.    with the domain (if any) MUST be injected into the multicast RIB in
  602.    the EGP by the domain's border routers.
  603.  
  604.  
  605.    When a route for a new group prefix is learned, or an existing route
  606.    for a group prefix is withdrawn, or the next-hop peer for a group
  607.    prefix changes, a BGMP router updates all affected (*,G) target
  608.    lists.
  609.  
  610.    When an existing route for a source prefix is withdrawn, or the
  611.    next-hop peer for a source prefix changes, a BGMP router updates all
  612.    affected (S,G) target lists.
  613.  
  614.  
  615. 5.4.  Interaction with M-IGP components
  616.  
  617.    When an M-IGP component on a border router first learns that there
  618.    are internally-reached members for a group G (whose scope is larger
  619.    than a single domain), a (*,G) Join alert is sent to the BGMP
  620.    component. Similarly, when an M-IGP component on a border router
  621.    learns that there are no longer internally-reached members for a
  622.    group G (whose scope is larger than a single domain), a (*,G) Prune
  623.    alert is sent to the BGMP component.
  624.  
  625.    At any time, any M-IGP domain MAY decide to join a source-specific
  626.    branch for some external source S and group G.  When the M-IGP
  627.    component in the border router that is the next-hop router for a
  628.    particular source S learns that a receiver wishes to receive data
  629.    from S on a source-specific path, an (S,G) Join alert is sent to the
  630.    BGMP component.  When it is learned that such receivers no longer
  631.  
  632.  
  633.  
  634.  
  635.  
  636. Expires April 1998                                             [Page 11]
  637.  
  638.  
  639.  
  640.  
  641. Draft                             BGMP                      October 1997
  642.  
  643.  
  644.    exist, an (S,G) Prune alert is sent to the BGMP component.  Recall
  645.    that the BGMP component will generate external source-specific Joins
  646.    only where the source-specific branch does not coincide with the
  647.    shared tree distribution tree for that group.
  648.  
  649.    Finally, we will require that the border router that is the next-hop
  650.    internal peer for a particular address S or G be able to forward data
  651.    for a matching tree state table entry to all members within the
  652.    domain. This requirement has implications on specific M-IGPs as
  653.    follows.
  654.  
  655.  
  656. 5.4.1.  Interaction with DVMRP and PIM-DM
  657.  
  658.    DVMRP and PIM-DM are both "flood and prune" protocols in which every
  659.    data packet must pass an RPF check against the packet's source
  660.    address, or be dropped. If the border router receiving packets from
  661.    an external source is the only BR to inject the route for the source
  662.    into the domain, then there are no problems.  For example, this will
  663.    always be true for stub domains with a single border router (see
  664.    Figure 1). Otherwise, the border router receiving packets externally
  665.    is responsible for encapsulating the data to any other border routers
  666.    that must inject the data into the domain for RPF checks to succeed.
  667.  
  668.    When an intended border router injector for a source receives
  669.    encapsulated packets from another border router in its domain, it
  670.    should create source-specific (S,G) BGMP state.  Note that the border
  671.    router may be configured to do this on a data-rate triggered bases so
  672.    that the state is not created for very low data rate/intermittent
  673.    sources. If source-specific state is created then its incoming
  674.    interface points to the virtual encapsulation interface from the
  675.    border router that forwarded the packet, and it has an SPT flag that
  676.    is initialized to be False.
  677.  
  678.    When the (S,G) BGMP state is created, the BGMP component will in turn
  679.    send a BGMP (S,G) Join message to the next-hop external peer towards
  680.    S if there is no (*,G) state for that same group, G. The (S,G) BGMP
  681.    state will have the SPT bit set to False if (*,G) BGMP state is
  682.    present.
  683.  
  684.    When the first data packet from S arrives from the external peer and
  685.    matches on the BGMP (S,G) state, and IF there is no (*,G) state, the
  686.    router sets the SPT flag to True, resets the incoming interface to
  687.    point to the external peer, and sends a BGMP (S,G) Prune message to
  688.    the border router that was encapsulating the packets (e.g., in Figure
  689.  
  690.  
  691.  
  692.  
  693.  
  694. Expires April 1998                                             [Page 12]
  695.  
  696.  
  697.  
  698.  
  699. Draft                             BGMP                      October 1997
  700.  
  701.  
  702.    1, BR11 sends the (Src_A,G) Prune to BR12). When the border router
  703.    with (*,G) state receives the prune for (S,G), it should delete that
  704.    border router from its list of targets or outgoing interfaces.
  705.  
  706.    PIM-DM and DVMRP present an additional problem, i.e., no protocol
  707.    mechanism exists for joining and pruning entire groups; only joins
  708.    and prunes for individual sources are available. We therefore require
  709.    that some form of Domain-Wide Reports (DWRs) [DWR] are available
  710.    within such domains.  Such messages provide the ability to join and
  711.    prune an entire group across the domain. One simple heuristic to
  712.    approximate DWRs is to assume that if there are any internally-
  713.    reached members, then at least one of them is a sender. With this
  714.    heuristic, the presense of any M-IGP (S,G) state for internally-
  715.    reached sources can be used instead.  Sending a data packet to a
  716.    group is then equivalent to sending a DWR for the group.
  717.  
  718.  
  719. 5.4.2.  Interaction with CBT
  720.  
  721.    CBT builds bidirectional shared trees but must address two points of
  722.    compatibility with BGMP.  First, CBT is currently not specified to
  723.    accommodate more than one border router injecting a packet.
  724.    Therefore, if a CBT domain does have multiple external connections,
  725.    the M-IGP components of the border routers are responsible for
  726.    insuring that only one of them will inject data from any given
  727.    source.  This mechanism is provided in [CBTDM].
  728.  
  729.    Second, CBT cannot process source-specific Joins or Prunes.  Two
  730.    options thus exist for each CBT domain:
  731.  
  732.    Option A:
  733.      The CBT component interprets a (S,G) Join alert as if it were an
  734.      (*,G) Join alert, as described in [INTEROP].  That is, if it is not
  735.      already on the core-tree for G, then it sends a CBT (*,G) JOIN-
  736.      REQUEST message towards the core for G.  Similarly, when the CBT
  737.      component receives an (S,G) Prune alert, and the child interface
  738.      list for a group is NULL, then it sends a (*,G) QUIT_NOTIFICATION
  739.      towards the core for G.  This option has the disadvantage of
  740.      pulling all data for the group G down to the CBT domain when no
  741.      members exist.
  742.  
  743.    Option B:
  744.      The CBT domain does not propagate any source routes (i.e., non-
  745.      class D routes) to their external peers for the Multicast RIB
  746.      unless it is known that no other path exists to that prefix (e.g.,
  747.  
  748.  
  749.  
  750.  
  751.  
  752. Expires April 1998                                             [Page 13]
  753.  
  754.  
  755.  
  756.  
  757. Draft                             BGMP                      October 1997
  758.  
  759.  
  760.      routes for prefixes internal to the domain or in a singly-homed
  761.      customer's domain may be propagated).  This insures that source-
  762.      specific joins are never received unless the source's data already
  763.      passes through the domain on the shared tree, in which case the
  764.      (S,G) Join need not be propagated anyway.  BGMP border routers will
  765.      only send source-specific Joins or Prunes to an external peer if
  766.      that external peer advertises source-prefixes in the EGP.  If a
  767.      BGMP-CBT border router does receive an (S,G) Join or Prune, that
  768.      border router should ignore the message.
  769.  
  770.  
  771. 5.4.3.  Interaction with MOSPF
  772.  
  773.    As with CBT, MOSPF cannot process source-specific Joins or Prunes,
  774.    and the same two options are available.  Therefore, an MOSPF domain
  775.    may either:
  776.  
  777.    Option A:
  778.      send a Group-Membership-LSA for all of G in response to a (S,G)
  779.      Join alert, and "prematurely age" it out (when no other downstream
  780.      members exist) in response to an (S,G) Prune alert, OR
  781.  
  782.    Option B:
  783.      not propagate any source routes (i.e., non-class D routes) to their
  784.      external peers for the Multicast RIB unless it is known that no
  785.      other path exists to that prefix (e.g., routes for prefixes
  786.      internal to the domain or in a singly-homed customer's domain may
  787.      be propagated)
  788.  
  789.  
  790. 5.4.4.  Interaction with PIM-SM
  791.  
  792.    Protocols such as PIM-SM build unidirectional shared and source-
  793.    specific trees.  As with DVMRP and PIM-DM, every data packet must
  794.    pass an RPF check against some group-specific or source-specific
  795.    address.
  796.  
  797.  
  798.    The fewest encapsulations/decapsulations will be done when the
  799.    intra-domain tree is rooted at the next-hop internal peer towards G
  800.    (which becomes the RP), since in general that router will receive the
  801.    most packets from external sources.  To achieve this, each BGMP
  802.    border router to a PIM-SM domain should send Candidate-RP-
  803.    Advertisements within the domain for those groups for which it is the
  804.    shared-domain tree ingress router. When the border router that is the
  805.  
  806.  
  807.  
  808.  
  809.  
  810. Expires April 1998                                             [Page 14]
  811.  
  812.  
  813.  
  814.  
  815. Draft                             BGMP                      October 1997
  816.  
  817.  
  818.    RP for a group G receives an external data packet, it forwards the
  819.    packet according to the M-IGP (i.e., PIM-SM) shared-tree outgoing
  820.    interface list.
  821.  
  822.    Other border routers will receive data packets from external sources
  823.    that are farther down the bidirectional tree of domains. When a
  824.    border router that is not the RP receives an external packet for
  825.    which it does not have a source-specific entry, the border router
  826.    treats it like a local source by creating (S,G) state with a Register
  827.    flag set, based on normal PIM-SM rules; the Border router then
  828.    encapsulates the data packets in PIM-SM Registers and unicasts them
  829.    to the RP for the group.  As explained above, the RP for the inter-
  830.    domain group will be one of the other border routers of the domain.
  831.  
  832.    If a source's data rate is high enough, DRs within the PIM-SM domain
  833.    may switch to the shortest path tree.  If the shortest path to an
  834.    external source is via the group's ingress router for the shared
  835.    tree, the new (S,G) state in the BGMP border router will not cause
  836.    BGMP (S,G) Joins because that border router will already have (*,G)
  837.    state. If however, the shortest path to an external source is via
  838.    some other border router, that border router will create (S,G) BGMP
  839.    state in response to the M-IGP (S,G) Join alert. In this case,
  840.    because there is no local (*,G) state to supress it, the border
  841.    router will send a BGMP (S,G) Join to the next-hop external peer
  842.    towards S, in order to pull the data down directly.  (See BR11 in
  843.    Figure 1.) As in normal PIM-SM operation, those PIM-SM routers that
  844.    have (*,G) and (S,G) state pointing to different incoming interfaces
  845.    will prune that source off the shared tree.  Therefore, all internal
  846.    interfaces may be eventually pruned off the internal shared tree.
  847.  
  848.  
  849. 6.  Interaction with address allocation
  850.  
  851. 6.1.  Requirements for BGMP components
  852.  
  853.    Each border router must be able to determine (e.g., from MASC [MASC])
  854.    which class-D prefixes (if any) belong to each domain in which a
  855.    component resides.
  856.  
  857.    Periodically, the router then multicasts to the domain-scoped ALL-
  858.    PA-RECEIVERS group within each domain that has one or more class-D
  859.    prefixes, a Prefix-Announcement message containing those prefixes.
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868. Expires April 1998                                             [Page 15]
  869.  
  870.  
  871.  
  872.  
  873. Draft                             BGMP                      October 1997
  874.  
  875.  
  876. 6.2.  Interaction with Address Allocators
  877.  
  878.    Each address allocator SHOULD join the domain-scoped ALL-PA-RECEIVERS
  879.    group, and SHOULD allocate addresses from the prefix(es) announced to
  880.    this group.
  881.  
  882.  
  883. 7.  Transition Strategy
  884.  
  885.    There have been significant barriers to multicast deployment in
  886.    Internet backbones.  While many of the problems with the current
  887.    DVMRP backbone (MBONE) have been documented in [ISSUES], most of
  888.    these problems require longer term engineering solutions. However,
  889.    there is much that can be done with existing technologies to enable
  890.    deployment and put in place an architecture that will enable a smooth
  891.    transition to the next generation of inter-domain multicast routing
  892.    protocols (i.e., BGMP).  This section proposes a near-term transition
  893.    strategy and architecture that is designed to be simple, risk-
  894.    neutral, and provide a smooth, incremental transition path to BGMP.
  895.    In addition, the transition architecture provides for improved
  896.    convergence properties, some initial policy control, and the
  897.    opportunity for providers to run either native or tunneled multicast
  898.    backbones and exchanges.
  899.  
  900.    The transition strategy proposed here is to initially use BGP4+
  901.    [MBGP] to provide the desired convergence and policy control
  902.    properties, and PIM-DM for multicast data forwarding.  Once this
  903.    architecture is in place, backbones and exchanges can incrementally
  904.    transition to BGMP and domains running other M-IGPs may be
  905.    incorporated more fully.
  906.  
  907.    Since the current MBone uses a broadcast-and-prune backbone running
  908.    DVMRP, BGMP may view the entire MBone as a single multi-homed stub
  909.    domain (with a new AS number).  The members-are-senders heuristic can
  910.    then be used initially to provide membership notifications within
  911.    this stub domain.
  912.  
  913.    A BGMP backbone can then be formed by designating a neutral PIM-DM
  914.    domain (say, a particular exchange) as the initial BGMP backbone.
  915.    This domain is then associated with the group prefix 224/4 which is
  916.    injected into the Multicast RIB by all BGP4+/BGMP border routers on
  917.    that exchange.
  918.  
  919.    Any domain which meets the following constraints may then transition
  920.    from a normal MBone-connected domain to one running BGMP:
  921.  
  922.  
  923.  
  924.  
  925.  
  926. Expires April 1998                                             [Page 16]
  927.  
  928.  
  929.  
  930.  
  931. Draft                             BGMP                      October 1997
  932.  
  933.  
  934. (1)  Must peer with another BGMP domain and participate in M-BGP to
  935.      propagate routes in the Multicast RIB.
  936.  
  937. (2)  Must establish an internal (to the MBone AS) EGP (e.g., iBGP) peer
  938.      relationship with other border routers of the MBone "stub" domain,
  939.      as is done with unicast routing.  We expect this to eventually
  940.      involve the use of one or more route reflectors [REFLECT] inside
  941.      the MBone domain.
  942.  
  943. (3)  If the transition will partition the MBone "stub" domain, then it
  944.      must be insured that the MBone domain will be administratively
  945.      split into multiple domains, each with a different multicast AS
  946.      number.
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984. Expires April 1998                                             [Page 17]
  985.  
  986.  
  987.  
  988.  
  989. Draft                             BGMP                      October 1997
  990.  
  991.  
  992. 7.1.  Preventing transit through the MBone stub
  993.  
  994.    We desire that two AS's which are mutually reachable through BGMP use
  995.    paths which do not pass through the MBone stub domain.  This is
  996.    illustrated in Figure 2, where the MBone stub is AS 5, which is
  997.    multi-homed to both AS 3 and AS 4.  Paths between sources and
  998.    destinations which have already transitioned to BGP4+/BGMP should not
  999.    use AS 5 as transit unless no other path exists.
  1000.  
  1001.            ----------------------\   /----------------------------
  1002.                                  |   |
  1003.            DVMRP         /----\  |   |  /----\  IGP/iBGP
  1004.            ..............| BR |+++++++++| BR |-----------
  1005.                          \----/  | E |  \----/
  1006.                             +    | B |     +          AS 3
  1007.            MBone            +    | G |     +
  1008.                             +    | P \-----+----------------------
  1009.            AS 5        iBGP +    |         + eBGP
  1010.                             +    |   /-----+----------------------
  1011.                             +    |   |     +
  1012.                             +    |   |     +
  1013.            DVMRP         /----\  |   |  /----\  IGP/iBGP
  1014.            ..............| BR |+++++++++| BR |-----------
  1015.                          \----/  |   |  \----/
  1016.                                  |   |                AS 4
  1017.                                  |   |
  1018.            ----------------------/   \----------------------------
  1019.  
  1020.               Figure 2: Preventing Transit through MBone Stub
  1021.  
  1022.  
  1023.    This requirement is easily solved using standard BGP policy
  1024.    mechanisms. The MBone border routers should prefer EGP routes to
  1025.    DVMRP routes, since DVMRP cannot tag routes as being external.  Thus,
  1026.    external routes may appear in the DVMRP routing table, but will not
  1027.    be imported into the EGP since they will be overridden by iBGP
  1028.    routes.
  1029.  
  1030.    Other EGP routers should prefer routes whose ASpath does not contain
  1031.    the well-known MBone AS number.  This will insure that the route
  1032.    through the MBone stub is not used unless no other path exists.  For
  1033.    safety, routes whose ASpath begins with the MBone AS should receive
  1034.    the worst preference.
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042. Expires April 1998                                             [Page 18]
  1043.  
  1044.  
  1045.  
  1046.  
  1047. Draft                             BGMP                      October 1997
  1048.  
  1049.  
  1050. 8.  Packet Formats
  1051.  
  1052.    WARNING: These formats are preliminary and may change as a result of
  1053.    adding features such as capability negotiation.
  1054.  
  1055.    BGMP only uses one type of message, in which join and prune
  1056.    information is sent.  Since BGMP messages are sent over TCP, only
  1057.    state changes are included.  The TCP keep-alive mechanism thus serves
  1058.    as an explicit state refresh mechanism; when the TCP connection goes
  1059.    down, all related state should be flushed.
  1060.  
  1061.    The message format below allows compact encoding of (*,G-prefix)
  1062.    Joins and Prunes (12 bytes per group, for IPv4), while allowing the
  1063.    flexibility needed to do (S,G) Joins and Prunes towards soures as
  1064.    well as on the shared tree.
  1065.  
  1066.      0                   1                   2                   3
  1067.      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
  1068.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1069.     |   Reserved    |X|R|M| AddrLen | Addr Family   | Encoding Type |
  1070.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1071.     |                        Group-Address                          |
  1072.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1073.     |                          Group-Mask                           |
  1074.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1075.     |                        Source-Entry-1                       ...
  1076.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
  1077.     |                        Source-Entry-2                       ...
  1078.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
  1079.     |                              ...                              |
  1080.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
  1081.     |                        Source-Entry-n                       ...
  1082.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
  1083.  
  1084.    Reserved       Transmitted as 0, ignored upon receipt.  This field
  1085.                   is reserved for future additions, such as version
  1086.                   and message type fields, should they become
  1087.                   necessary.
  1088.    X              Reserved bit.  Transmitted as 0, ignored upon
  1089.                   receipt.
  1090.    R              Root-Domain-tree bit.  If set, the sender desires to
  1091.                   be (or continue to be) part of the shared tree
  1092.                   through the peer, and any source entries are (S,G)
  1093.                   joins and prunes on the shared tree.  If clear, the
  1094.                   sender does not desire to be part of the shared tree
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100. Expires April 1998                                             [Page 19]
  1101.  
  1102.  
  1103.  
  1104.  
  1105. Draft                             BGMP                      October 1997
  1106.  
  1107.  
  1108.                   through the peer, and any source entries are (S,G)
  1109.                   joins and prunes towards soures.
  1110.    M              More-sources bit.  If set, then source entries exist
  1111.                   for this group.
  1112.    AddrLen        Length, in bytes, of the Group-Address field.
  1113.    AddrFamily     Address family (see below) of the group address.
  1114.    Encoding Type  The type of encoding used within a specific Address
  1115.                   Family. The value `0' is reserved for this field,
  1116.                   and represents the native encoding of the Address
  1117.                   Family.
  1118.    Group-Address  The multicast group address to be joined or pruned.
  1119.    Group-Mask     The mask associated with the group address.  The
  1120.                   length of this field should be identical to the
  1121.                   length of the address field.
  1122.  
  1123.    Each Source-Entry has the following format:
  1124.  
  1125.      0                   1                   2                   3
  1126.      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
  1127.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1128.     |   MaskLen     |X|I|M| AddrLen | Addr Family   | Encoding Type |
  1129.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1130.     |                        Source-Address                         |
  1131.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1132.  
  1133.    Masklen         Length, in bits, of the mask to apply to the
  1134.                    address.
  1135.    X               Reserved bit.  Transmitted as 0, ignored upon
  1136.                    receipt.
  1137.    I               Inclusion bit.  When set, the source entry
  1138.                    indicates an addition, or join.  When clean, the
  1139.                    source entry indicates a removal, or prune.
  1140.    M               More-sources bit.  If set, then more source entries
  1141.                    follow for the same group.
  1142.    AddrLen         Length, in bytes, of the Source-Address field.
  1143.    AddrFamily      Address family (see below) of the source address.
  1144.    Encoding Type   The type of encoding used within a specific Address
  1145.                    Family.  The value `0' is reserved for this field,
  1146.                    and represents the native encoding of the Address
  1147.                    Family.
  1148.    Source-Address  Unicast source address to be joined or pruned.
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158. Expires April 1998                                             [Page 20]
  1159.  
  1160.  
  1161.  
  1162.  
  1163. Draft                             BGMP                      October 1997
  1164.  
  1165.  
  1166. 8.1.  Encoding examples
  1167.  
  1168.    R Group     : I Source | Description
  1169.    -----------------------+---------------------------------------------
  1170.    1 G/mask               | (*,G-prefix) join
  1171.    0 G/mask               | (*,G-prefix) prune
  1172.    0 G/ffffffff: 1 S/32   | (S,G) Join towards S.  This is also used to
  1173.                           | switch from a (*,G) Join to an (S,G) Join,
  1174.                           | such as when the next hop peer towards G
  1175.                           | changes, but it is advantagous to continue
  1176.                           | receiving S's data from the peer.
  1177.    0 G/ffffffff: 0 S/32   | (S,G) Prune towards S
  1178.    1 G/ffffffff: 0 S/32   | (S,G) Prune towards root-domain.  This is
  1179.                           | also used to send an initial (*,G) join with
  1180.                           | S pruned, at the same time (such as when the
  1181.                           | next hop peer towards G changes after S has
  1182.                           | already been pruned off).
  1183.    1 G/ffffffff: 1 S/32   | (S,G) Join cancelling prune towards root-
  1184.                           | domain.
  1185.  
  1186. 9.  References
  1187.  
  1188. [MBGP]
  1189.      Bates, T., Chandra, R., Katz, D., and Y. Rekhter., "Multiprotocol
  1190.      Extensions for BGP-4", draft-ietf-idr-bgp4-multiprotocol-01.txt,
  1191.      September 1997.
  1192.  
  1193. [CBT]
  1194.      Ballardie, A. J., "Core Based Trees (CBT) Multicast: Architectural
  1195.      Overview and Specification", University College London, November
  1196.      1994.
  1197.  
  1198. [CBTDM]
  1199.      Ballardie, A., "Core Based Tree (CBT) Multicast Border Router
  1200.      Specification" draft-ietf-idmr-cbt-br-spec-00.txt, October 1997.
  1201.  
  1202. [DVMRP]
  1203.      Pusateri, T., "Distance Vector Multicast Routing Protocol", draft-
  1204.      ietf-idmr-dvmrp-v3-05.txt, October 1997.
  1205.  
  1206. [DWR]
  1207.      Fenner, W., "Domain-Wide Reports", Work in progress.
  1208.  
  1209. [INTEROP]
  1210.      Thaler, D., "Interoperability Rules for Multicast Routing
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216. Expires April 1998                                             [Page 21]
  1217.  
  1218.  
  1219.  
  1220.  
  1221. Draft                             BGMP                      October 1997
  1222.  
  1223.  
  1224.      Protocols", draft-thaler-multicast-interop-01.txt, March 1997.
  1225.  
  1226. [IPv6MAA]
  1227.      R. Hinden, S. Deering, "IPv6 Multicast Address Assignments",
  1228.      draft-ietf-ipngwg-multicast-assgn-04.txt, July 1997.
  1229.  
  1230. [ISSUES]
  1231.      Meyer, D., "Some Issues for an Inter-domain Multicast Routing
  1232.      Protocol", draft-ietf-mboned-imrp-some-issues-02.txt, June 1997.
  1233.  
  1234. [MASC]
  1235.      Estrin, D., Handley, M, and D. Thaler, "Multicast-Address-Set
  1236.      advertisement and Claim mechanism", Work in Progress, June 1997.
  1237.  
  1238. [MOSPF]
  1239.      Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, March
  1240.      1994.
  1241.  
  1242. [PIMDM]
  1243.      Estrin, et al., "Protocol Independent Multicast-Dense Mode (PIM-
  1244.      DM): Protocol Specification", draft-ietf-idmr-pim-dm-spec-05.txt,
  1245.      May 1997.
  1246.  
  1247. [PIMSM]
  1248.      Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM-
  1249.      SM): Protocol Specification", RFC 2117, June 1997.
  1250.  
  1251. [REFLECT]
  1252.      Bates, T., and R. Chandra, "BGP Route Reflection: An alternative to
  1253.      full mesh IBGP", RFC 1966, June 1996.
  1254.  
  1255. [RFC1700]
  1256.      S. J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, October
  1257.      1994.
  1258.  
  1259. [RFC1771]
  1260.      Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771,
  1261.      March 1995.
  1262.  
  1263.  
  1264. 10.  Security Considerations
  1265.  
  1266. Security issues are not discussed in this memo.
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274. Expires April 1998                                             [Page 22]
  1275.  
  1276.  
  1277.  
  1278.  
  1279. Draft                             BGMP                      October 1997
  1280.  
  1281.  
  1282. 11.  Authors' Addresses
  1283.  
  1284.      Dave Thaler
  1285.      Department of Electrical Engineering and Computer Science
  1286.      University of Michigan
  1287.      1301 Beal Ave.
  1288.      Ann Arbor, MI 48109-2122
  1289.      Phone: +1 313 763 5243
  1290.      EMail: thalerd@eecs.umich.edu
  1291.  
  1292.      Deborah Estrin
  1293.      Computer Science Dept./ISI
  1294.      University of Southern California
  1295.      Los Angeles, CA 90089
  1296.      Email: estrin@usc.edu
  1297.  
  1298.      David Meyer
  1299.      University of Oregon
  1300.      1225 Kincaid St.
  1301.      Eugene, OR 97403
  1302.      Phone: (541) 346-1747
  1303.      EMail: meyer@antc.uoregon.edu
  1304.  
  1305.  
  1306.  
  1307. Table of Contents
  1308.  
  1309.  
  1310. 1 Acknowledgements ................................................    2
  1311. 2 Purpose .........................................................    2
  1312. 3 Terminology .....................................................    3
  1313. 4 Protocol Overview ...............................................    4
  1314. 4.1 Design Rationale ..............................................    6
  1315. 5 Protocol Details ................................................    7
  1316. 5.1 Interaction with the EGP ......................................    7
  1317. 5.2 Multicast Data Packet Processing ..............................    8
  1318. 5.3 BGMP processing of Join and Prune messages and notifications
  1319.      ..............................................................    9
  1320. 5.3.1 Receiving Joins .............................................    9
  1321. 5.3.2 Receiving Prune Notifications ...............................   10
  1322. 5.3.3 Receiving Route Change Notifications ........................   11
  1323. 5.4 Interaction with M-IGP components .............................   11
  1324. 5.4.1 Interaction with DVMRP and PIM-DM ...........................   12
  1325. 5.4.2 Interaction with CBT ........................................   13
  1326. 5.4.3 Interaction with MOSPF ......................................   14
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332. Expires April 1998                                             [Page 23]
  1333.  
  1334.  
  1335.  
  1336.  
  1337. Draft                             BGMP                      October 1997
  1338.  
  1339.  
  1340. 5.4.4 Interaction with PIM-SM .....................................   14
  1341. 6 Interaction with address allocation .............................   15
  1342. 6.1 Requirements for BGMP components ..............................   15
  1343. 6.2 Interaction with Address Allocators ...........................   16
  1344. 7 Transition Strategy .............................................   16
  1345. 7.1 Preventing transit through the MBone stub .....................   18
  1346. 8 Packet Formats ..................................................   19
  1347. 8.1 Encoding examples .............................................   21
  1348. 9 References ......................................................   21
  1349. 10 Security Considerations ........................................   22
  1350. 11 Authors' Addresses .............................................   23
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390. Expires April 1998                                             [Page 24]
  1391.