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-cbt-dvmrp-00.txt < prev    next >
Text File  |  1997-09-04  |  17KB  |  495 lines
  1.  
  2.  
  3.  
  4. Inter-Domain Multicast Routing (IDMR)                       A. Ballardie
  5. INTERNET-DRAFT                                              Consultant
  6.  
  7.                                                             March 1997.
  8.  
  9.  
  10.              Core Based Tree (CBT) Multicast Border Router
  11.              Specification for Connecting a CBT Stub Region
  12.                           to a DVMRP Backbone
  13.  
  14.                  <draft-ietf-idmr-cbt-dvmrp-00.txt>
  15.  
  16. Status of this Memo
  17.  
  18.    This document is an Internet Draft.  Internet Drafts are working doc-
  19.    uments of the Internet Engineering Task Force (IETF), its Areas, and
  20.    its Working Groups. Note that other groups may also distribute work-
  21.    ing documents as Internet Drafts).
  22.  
  23.    Internet Drafts are draft documents valid for a maximum of six
  24.    months. Internet Drafts may be updated, replaced, or obsoleted by
  25.    other documents at any time.  It is not appropriate to use Internet
  26.    Drafts as reference material or to cite them other than as a "working
  27.    draft" or "work in progress."
  28.  
  29.    Please check the I-D abstract listing contained in each Internet
  30.    Draft directory to learn the current status of this or any other In-
  31.    ternet Draft.
  32.  
  33.  
  34. Abstract
  35.  
  36.    This document specifies the behaviour of CBT multicast border router
  37.    interconnecting a CBT multicast stub domain (region) to a DVMRP [1]
  38.    multicast backbone.
  39.  
  40.    The document provides guidelines that are intended to be generally
  41.    aligned with the mechanisms described in the "Interoperability Rules
  42.    for Multicast Routing Protocols" [2]. Certain aspects of those rules
  43.    may be interpreted and implemented differently, and therefore some
  44.    discretion is left to the implementor.
  45.  
  46.    This document assumes the reader is familiar with  the CBT protocol
  47.    [3].
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Expires September 1997                                          [Page 1]
  54.  
  55.  
  56.  
  57. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  58.  
  59.  
  60. 1.  Interoperability Model & Assumptions
  61.  
  62.    The interoperability model and mechanisms we present assume:
  63.  
  64.    +o    a CBT border router (BR) interconnects a multicast stub region
  65.         (collection of networks defined by one or more CBT-capable bor-
  66.         der routers) to a dense mode multicast region, such as a DVMRP
  67.         backbone.  The CBT stub region may or may not be multi-homed.
  68.  
  69.    +o    logically, a BR has at least two "components", each component
  70.         being associated with a particular multicast routing protocol.
  71.         Each component may have more than one associated interface which
  72.         is running the particular multicast protocol associated with the
  73.         component. One of these components is a CBT component.
  74.  
  75.    +o    all components share a common multicast forwarding cache of
  76.         (S,G) entries for the purpose of inter-domain multicast routing.
  77.         To ensure that all components have a consistent view of the
  78.         shared cache a BR's components must be able to communicate with
  79.         each other; how is implementation dependent.  Additionally, each
  80.         component may have a separate multicast forwarding cache spe-
  81.         cific to that component's multicast routing protocol.
  82.  
  83.    +o    the presence of a domain-wide reporting (DWR) mechanism [4],
  84.         enabling the dynamic and timely reporting of group joining and
  85.         leaving inside a CBT domain to the domain's border routers. DWRs
  86.         are only necessary for inter-domain scoped groups; they may not
  87.         be sent for intra-domain scoped (administratively scoped [5])
  88.         groups.  DWRs are not assumed present in DVMRP domains.
  89.  
  90.    +o    a <core, group> mapping table per CBT component exists which
  91.         maintains mappings between core routers and active groups pre-
  92.         sent inside a CBT domain.
  93.  
  94.    +o    mixed multicast protocol LANs are not permitted.
  95.  
  96.    +o    The term "region" and "domain" are used interchangeably through-
  97.         out.
  98.  
  99.  
  100.  
  101. 2.  Overview
  102.  
  103.    There are essentially two aspects to this specification: the election
  104.    of a "designated border router", and the intrinsics of a border
  105.  
  106.  
  107.  
  108. Expires September 1997                                          [Page 2]
  109.  
  110.  
  111.  
  112. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  113.  
  114.  
  115.    router's shared multicast forwarding cache.
  116.  
  117.    Like other routers in a CBT domain, a border router (BR) listens to
  118.    bootstrap messages [8].  A BR joins each core advertised in a valid
  119.    bootstrap message by sending a JOIN_REQUEST, with the BR_JOIN option
  120.    set [3], towards each core; in doing so the BR joins all groups that
  121.    map to this core router. The state created by this join represents
  122.    (*, core) state, unlike the typical (G) state maintained by other on-
  123.    tree routers.  This state exists between the sending BR router and
  124.    the core router; it transends any distribution trees that are
  125.    "attached" to this core router. Hence, some (probably small number
  126.    of) routers within a CBT domain - those on the path between a BR and
  127.    a core router - may have to store both (G) state and (*, core) state.
  128.  
  129.    Only the domain's elected designated border router may forward data
  130.    packets across the CBT domain boundary. Similarly with routing traf-
  131.    fic. Any other border routers may participate in the interactions
  132.    necessary to maintain the BR shared forwarding cache, but they may
  133.    not forward data packets or routing traffic across boundary.
  134.  
  135.  
  136.  
  137. 3.  Designated Border Router Election
  138.  
  139.    One of a CBT stub region's border routers (BRs) is elected, dynami-
  140.    cally, as the region's designated BR.
  141.  
  142.    The designated BR is elected using CBT's HELLO protocol [3], which
  143.    operates over a tree spanning all the region's BRs. The core router
  144.    for this tree is elected using the intra-domain core router discovery
  145.    ("bootstrap") mechanism described in [3, 6]. The multicast address
  146.    for this administratively scoped group - the "all-border-routers"
  147.    (ABR) group - is 239.0.0.15 (IANA assignment pending).  The desig-
  148.    nated BR election criteria are the same as those for LAN DR election
  149.    [3].
  150.  
  151.    When a BR starts up, like other routers in the domain, it awaits
  152.    bootstrap messages from the domain's elected bootstrap router. Once a
  153.    BR receives a valid candidate core set (CC-set) advertisement, it
  154.    performs a hash function on the ABR group address yielding a core
  155.    from the CC-set. The BR then sends a JOIN_REQUEST towards the core so
  156.    as to join the ABR group tree.
  157.  
  158.    On receipt of the JOIN_ACK, the BR begins engaging in the HELLO pro-
  159.    tocol for border routers.
  160.  
  161.  
  162.  
  163. Expires September 1997                                          [Page 3]
  164.  
  165.  
  166.  
  167. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  168.  
  169.  
  170.    The HELLO protocol for designated BR election is virtually identical
  171.    to the LAN DR election, except for the following:
  172.  
  173.    +o    HELLO messages sent by a BR are sent with HELLO option type 0
  174.         (zero); this is the BR_HELLO option type. Its option length is 0
  175.         (zero), and its option value is 0 (zero).
  176.  
  177.    +o    HELLO messages sent by a BR are addressed to the ABR group, and
  178.         sent with IP TTL MAX_TTL.
  179.  
  180.    +o    a "designated BR flag" is kept per BR (not per interface as with
  181.         the DR flag). By default, this flag is set (in steady state,
  182.         only one of a domain's BRs will have its "designated BR flag"
  183.         set).
  184.  
  185.    Consequently, a BR participating in LAN DR election as well as desig-
  186.    nated BR election, must maintain LAN DR and designated BR HELLO
  187.    information separately, i.e. random response, HELLO preference, and
  188.    HELLO convergence time (for definitions, see [3]).  Hence, different
  189.    random response intervals, and different HELLO preferences, can be
  190.    configured for LAN DR election and designated BR election on border
  191.    routers.
  192.  
  193.    Besides these differences, HELLO protocol operation is identical to
  194.    that specified for LAN DR election in [3].
  195.  
  196.  
  197.              ------------X----------------------X--X--------
  198.              |     |           |             |         |   |    X = component
  199.              |     | comp A    |             | comp B  |   |         interface
  200.              |     -------------             -----------   |
  201.              |                                             |    comp = component
  202.              |         -----------------------------       |
  203.              |         |     Shared Multicast      |       |
  204.              |         |   Forwarding Cache (S,G)  |       |
  205.              |         -----------------------------       |
  206.              |                                             |
  207.              |     ------------              ----------    |
  208.              |     |  comp C   |             | comp D  |   |
  209.              |     |           |             |         |   |
  210.              ----------X----X----------------------X--------
  211.  
  212.  
  213.             Figure 1: Example Representation of a Border Router
  214.  
  215.  
  216.  
  217.  
  218. Expires September 1997                                          [Page 4]
  219.  
  220.  
  221.  
  222. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  223.  
  224.  
  225. 4.  Multicast Forwarding Cache Manipulation
  226.  
  227.  
  228.    Note that this section describes some, but not necessarily all, of a
  229.    DVMRP component's interactions with regards to manipulating the
  230.    shared forwarding cache. These are covered elsewhere [2].
  231.  
  232.    A border router's shared multicast forwarding cache consists of a set
  233.    of (S, G) entries, where S represents an address if the entry is cre-
  234.    ated by the BR's DVMRP component, or the wildcard address (*) if the
  235.    entry is created by the BR's CBT component. The creating component of
  236.    an entry is the entry's "owner".  Only the owner of an entry can
  237.    remove it from the shared forwarding cache.  Each entry consists of
  238.    an incoming interface, and an outgoing interface list.
  239.  
  240.    If multicast data arrives over one of a border router's DVMRP compo-
  241.    nent interfaces, the BR first attempts to match the packet's source
  242.    and group addresses (S, G). If no match is found and the data arrives
  243.    over the correct interface for source S, an (S, G) forwarding cache
  244.    entry is created. The incoming interface is copied to the entry's
  245.    incoming interface, and any interfaces listed in any other (S, G) or
  246.    (*, G) entries, and not yet listed under this (S, G), are placed in
  247.    this (S, G) entry's outgoing interface list.
  248.  
  249.    Whenever the outgoing interface list of an (S, G) entry becomes NULL,
  250.    the creator of the (S, G) entry sends a DVMRP prune message upstream.
  251.    However, if the outgoing interface list of a (*, G) entry becomes
  252.    NULL, the CBT component deletes the (*, G) forwarding cache entry.
  253.    However, the CBT component must not send a QUIT_NOTIFICATION upstream
  254.    (internally) towards to core for the group until all group associa-
  255.    tions are removed from that core in the <core, group> mapping table.
  256.    When a QUIT_NOTIFICATION is sent, the interface over which the
  257.    QUIT_NOTIFICATION is sent is removed from the outgoing interface list
  258.    of any (*, G) and (S, G) entries.
  259.  
  260.    If the outgoing interface list of an (S, G) entry goes from NULL to
  261.    non-NULL, the owning DVMRP component must send a DVMRP graft message
  262.    upstream for source S.
  263.  
  264.    If a domain-wide report (DWR) is received by one of a BR's CBT compo-
  265.    nent interfaces, the group is added to the component group table
  266.    under the corresponding core entry.  The CBT component searches for
  267.    any (*, G) and (S, G) entries, and adds the interface to the outgoing
  268.    interface list of each such entry. If no entry is found, the CBT com-
  269.    ponent creates a (*, G) entry, adds the corresponding interface as
  270.  
  271.  
  272.  
  273. Expires September 1997                                          [Page 5]
  274.  
  275.  
  276.  
  277. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  278.  
  279.  
  280.    the entry's incoming interface, and also copies any interfaces listed
  281.    under any (*, G) and (S, G) entries not yet listed in this entry to
  282.    this entry's outgoing interface list.
  283.  
  284.    Once a CBT component establishes a particular group is no longer pre-
  285.    sent inside its domain, the group is removed from the corresponding
  286.    <core, group> table entry.  If the component owns a (*, G) entry
  287.    which has a non-NULL outgoing interface list, no further action is
  288.    taken. If however, the entry's outgoing interface list is NULL, or
  289.    becomes NULL, the CBT component deletes the (*, G) entry from the
  290.    forwarding cache.  The CBT component can only send a CBT
  291.    QUIT_NOTIFICATION when all groups have been removed from a <core,
  292.    group> table entry.
  293.  
  294.    If an IGMP [7] host membership report/leave is received by one of a
  295.    BR's CBT component interfaces, it is processed according to normal
  296.    IGMP behaviour. Additionally, this event causes the CBT component to
  297.    generate a DWR for itself.
  298.  
  299.  
  300.  
  301.  
  302. 5.  Data Flow
  303.  
  304.    When data arrives at a BR, a longest match, i.e. (S, G) is first
  305.    attempted.  For any (S, G) match, the data must arrive over the
  306.    entry's incoming interface, else it is discarded. If the data arrives
  307.    over the correct interface for S, a copy of the data packet is for-
  308.    warded over each interface listed in the entry's outgoing interface
  309.    list.
  310.  
  311.     If only (*, G) can be matched, a copy of the data pkt is forwarded
  312.    over each interface listed in the entry except the incoming inter-
  313.    face.
  314.  
  315.    If no entry is found in the multicast forwarding cache, the data is
  316.    discarded.
  317.  
  318.  
  319.  
  320. 6.  Routing Information Flow
  321.  
  322.    A CBT stub region need never import routes from a dense mode region
  323.    since the nature of CBT forwarding does not require this information.
  324.    The reverse is not true; the dense mode region requires routes from
  325.  
  326.  
  327.  
  328. Expires September 1997                                          [Page 6]
  329.  
  330.  
  331.  
  332. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  333.  
  334.  
  335.    the CBT region, so that, for traffic sourced inside the CBT region,
  336.    DVMRP routers outside the CBT stub region can correctly perform their
  337.    RPF check, upon which their data forwarding decision is based.
  338.  
  339.    The designated BR is responsible for injecting internal routing
  340.    information into the DVMRP region.
  341.  
  342.    The designated BR can either inject only "active" routes (those net-
  343.    work prefixes for active sources inside the CBT region), or a CIDR
  344.    aggregate, into the DVMRP region.
  345.  
  346.  
  347.  
  348.  
  349.  
  350. 7.  Summary
  351.  
  352.    This memo describes the rules and mechanisms of operation of a CBT
  353.    component of a Border Router attaching a stub CBT region to a DVMRP
  354.    backbone. The mechanisms described are generally aligned with the
  355.    rules and procedures given in "Interoperability Rules for Multicast
  356.    Protocols" [2].
  357.  
  358.  
  359.  
  360.    Acknowledgements
  361.  
  362.    Special thanks goes to Paul Francis, NTT Japan, for the original
  363.    brainstorming sessions that led to the development of CBT.
  364.  
  365.    Dave Thaler provided many comments with regards to aligning this
  366.    specification with [2].
  367.  
  368.  
  369.  
  370. References
  371.  
  372.   [1] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri;
  373.   ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-dvmrp-v3-**.txt.
  374.   Working draft, 1997.
  375.  
  376.   [2] Interoperability Rules for Multicast Routing Protocols; D. Thaler;
  377.   ftp://ds.internic.net/internet-drafts/draft-thaler-interop-00.txt;
  378.   November 1996.
  379.  
  380.  
  381.  
  382.  
  383. Expires September 1997                                          [Page 7]
  384.  
  385.  
  386.  
  387. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  388.  
  389.  
  390.   [3] Core Based Trees (CBT) Multicast Routing: Protocol Specification;
  391.   A.  Ballardie; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-
  392.   cbt-spec-**.txt.  Working draft, March 1997.
  393.  
  394.   [4]  IETF IDMR Working Group minutes, July 1995.
  395.   (ftp://cs.ucl.ac.uk/darpa/IDMR/IETF-JUL95/idmr-minutes-july95.txt).
  396.  
  397.   [5] Administrative Scoping...
  398.  
  399.   [6] Protocol Independent Multicast (PIM) Sparse Mode Specification; D.
  400.   Estrin et al; ftp://netweb.usc.edu/pim   Working drafts, 1996.
  401.  
  402.   [7] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner;
  403.   ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-v2-**.txt.
  404.   Working draft, 1996.
  405.  
  406.   [8] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Rout-
  407.   ing; D. Estrin et al.; Technical Report, available from:
  408.   ftp//catarina.usc.edu/pim
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438. Expires September 1997                                          [Page 8]
  439.  
  440.  
  441.  
  442. INTERNET-DRAFT        CBT - DVMRP Interoperability            March 1997
  443.  
  444.  
  445. Author Information:
  446.  
  447.    Tony Ballardie,
  448.    Research Consultant.
  449.    e-mail: ABallardie@acm.org
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493. Expires September 1997                                          [Page 9]
  494.  
  495.