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-ion-intralis-multicast-00.txt < prev    next >
Text File  |  1997-04-25  |  10KB  |  358 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                     Dino Farinacci
  5. Internet Draft                                             Cisco Systems
  6.                                                              David Meyer
  7.                                                     University of Oregon
  8.                                                            Yakov Rekhter
  9.                                                            Cisco Systems
  10.  
  11. Expiration Date: October 1997                                 April 1997
  12.  
  13.   Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
  14.  
  15.  
  16.                <draft-ietf-ion-intralis-multicast-00.txt>
  17.  
  18.  
  19. 1. Status of this Memo
  20.  
  21.    This document is an Internet-Draft.  Internet-Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its areas,
  23.    and its working groups. Note that other groups may also distribute
  24.    working documents as Internet-Drafts.
  25.  
  26.    Internet-Drafts are draft documents valid for a maximum of six months
  27.    and may be updated, replaced, or obsoleted by other documents at any
  28.    time. It is inappropriate to use Internet-Drafts as reference
  29.    material or to cite them other than as ``work in progress.''
  30.  
  31.    To learn the current status of any Internet-Draft, please check the
  32.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  33.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  34.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  35.    ftp.isi.edu (US West Coast).
  36.  
  37.  
  38. 2. Abstract
  39.  
  40.    This document describes how intra-LIS IP multicast can be efficiently
  41.    supported among routers over ATM without using the Multicast Address
  42.    Resolution Server (MARS). The method described here is specific to
  43.    Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism
  44.    inherent in PIM-SM to notify routers when they should create group
  45.    specific point-to-multipoint VCs.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Dino Farinacci, David Meyer, Yakov Rekhter              FORMFEED[Page 1]
  56.  
  57.  
  58.  
  59.  
  60.  
  61. Internet Draft  draft-ietf-ion-intralis-multicast-00.txt      April 1997
  62.  
  63.  
  64. 3. Overall model
  65.  
  66.    This document focuses on forwarding of multicast traffic among PIM-SM
  67.    routers connected to an ATM network. Routers on an ATM network are
  68.    partitioned into Logical IP Subnets, or LISs.  This document deals
  69.    with handling multicast within a single LIS. Handling inter-LIS
  70.    multicast traffic, including handling shortcuts, is outside the scope
  71.    of this document.  In addition, this document does not address
  72.    forwarding of multicast traffic to or from hosts connected to an ATM
  73.    network.
  74.  
  75.  
  76. 4. Router behavior
  77.  
  78.    This document requires that each router within a LIS knows IP and ATM
  79.    addresses of all other routers within the LIS. The mapping between IP
  80.    and ATM addresses may be provided by an ARP server [RFC1577], or by
  81.    any other means (e.g., static configuration).
  82.  
  83.    Each router within a LIS is required to maintain a single (shared)
  84.    router distribution point-to-multipoint VC rooted at the router with
  85.    all other routers in the LIS as the leaf nodes of that VC. The VC is
  86.    expected to be used for forwarding of multicast traffic (both data
  87.    and control) among routers within the LIS.  For example, this VC
  88.    would be used for distributing PIM [PIM-SM] control messages
  89.    (Join/Prune messages).
  90.  
  91.  
  92. 4.1. Establishing Dedicated, Per Group Point-to-Multipoint VCs
  93.  
  94.    Routers may also maintain group specific, dedicated point-to-
  95.    multipoint VCs. In particular, an upstream router for a group may
  96.    choose to become the root of a group specific point-to-multipoint VC
  97.    whose leaves are the downstream routers that have directly connected
  98.    or downstream receivers for the group. While the criteria for
  99.    establishing a group specific point-to-multipoint VC are local to a
  100.    router, issues such as the volume of traffic associated with the
  101.    group and the fanout factor within the LIS should be considered.
  102.    Finally, note that a router must minimally support a single shared
  103.    point-to-multipoint VC for distribution of control messages and data
  104.    (to all group addresses).
  105.  
  106.    A router can choose to establish a dedicated point-to-multipoint VC
  107.    (or add another leaf to an already established dedicated point-to-
  108.    multipoint VC) when it receives a PIM Join messages from another
  109.    router in the same LIS. The router sending the joins uses its shared
  110.    point-to-multipoint VC. Similarly, when a router that is the root of
  111.    a point-to-multipoint VC receives PIM Prune message, it removes the
  112.  
  113.  
  114.  
  115. Dino Farinacci, David Meyer, Yakov Rekhter              FORMFEED[Page 2]
  116.  
  117.  
  118.  
  119.  
  120.  
  121. Internet Draft  draft-ietf-ion-intralis-multicast-00.txt      April 1997
  122.  
  123.  
  124.    originator of the message from its dedicated point-to-multipoint VC.
  125.  
  126.  
  127. 4.2. Switching to a Source-Rooted Tree
  128.  
  129.    If at least one of the routers within a LIS decides to switch to a
  130.    source-rooted tree (by sending (S,G) PIM Joins), then all other
  131.    routers within the LIS that have downstream members for G should
  132.    switch to that source-rooted tree as well. Since a router that
  133.    switches to a source-rooted tree sends PIM Join messages for (S,G)
  134.    over its shared point-to-multipoint VC, the other routers within the
  135.    LIS are able to detect this. Once a router that has downstream
  136.    members for G detects this, the router should send (S,G) PIM Join
  137.    message as well (otherwise the router may receive duplicate traffic
  138.    from S).
  139.  
  140.  
  141. 4.2.1. Adding New Members to a Source-Rooted Tree
  142.  
  143.    As mentioned above, this document requires that once one router in a
  144.    LIS decides to switch to the source tree for some (S,G), all routers
  145.    in the LIS that have downstream members must also switch to the (S,G)
  146.    source tree. Now, when a new router wants to receive traffic from G,
  147.    it starts sending (*,G)-Joins on it's shared point-to-multipoint VC
  148.    toward the RP for G. The root of the (S,G)-source-rooted tree will
  149.    know to add the new router to the point-to-multipoint VC servicing
  150.    the (S,G)-source-rooted tree by observing the (*,G)-joins on it's
  151.    shared point-to-multipoint VC. However, the new router must also
  152.    switch to the (S,G)-source-rooted tree. In order to accomplish this,
  153.    the newly added router must:
  154.  
  155.  
  156.       (i).    Notice that it has been added to a new
  157.               point-to-multipoint VC
  158.  
  159.       (ii).   Notice (S,G) traffic coming down this new
  160.               point-to-multipoint VC
  161.  
  162.       (iii).  Send (S,G) joins toward S, causing it to switch to the
  163.               source-rooted tree. The router learns that the VC is
  164.               used to distribute (S,G) traffic in the previous
  165.               steps.
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175. Dino Farinacci, David Meyer, Yakov Rekhter              FORMFEED[Page 3]
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Internet Draft  draft-ietf-ion-intralis-multicast-00.txt      April 1997
  182.  
  183.  
  184. 4.3. Handing the "Packet Reflection" Problem
  185.  
  186.    When a router receives a multicast packet from another router in its
  187.    own LIS, the router should not send the packet on any of the routers
  188.    distribution point-to-multipoint VCs associate with the LIS. This
  189.    eliminates the problem of "packet reflection". Sending the packet on
  190.    the routers' distribution VCs associated with other LISs is
  191.    controlled by the multicast routing procedures.
  192.  
  193.  
  194.  
  195. 5. Brief Comparison with MARS
  196.  
  197.    The intra-LIS multicast scheme described in this document is intended
  198.    to be a less complex solution to an important subset of the
  199.    functionality provided by the Multicast Address Resolution Server, or
  200.    MARS [MARS]. In particular, it is designed to provide intra-LIS
  201.    multicast between routers using PIM-SM, and does not consider the
  202.    case of host-rooted point-to-multicast multicast distribution VCs.
  203.  
  204.    Although MARS supports both of the current schemes for mapping the IP
  205.    multicast service model to ATM (multicast server and meshes of
  206.    point-to-multipoint VCs), it does so at at cost and complexity higher
  207.    than of the scheme described in this document. In addition, MARS
  208.    requires new encapsulations, whereas this proposal works with either
  209.    LLC/SNAP or with NLPID encapsulation. Another important difference is
  210.    that MARS allows point-to-multipoint VCs rooted either at a source or
  211.    at a multicast server (MCS). The approach taken here is to constrain
  212.    complexity by focusing on PIM-SM (taking advantage of information
  213.    available in explicit joins), and by allowing point-to-multipoint VCs
  214.    to be rooted only at the routers (which is roughly analogous to the
  215.    complexity and functionality of rooting point-to-multipoint VCs at
  216.    the sources).
  217.  
  218.    In summary, the method described in this document is designed for the
  219.    router-to-router case, and takes advantage of the explicit-join
  220.    mechanism inherent in PIM-SM to provide a simple mechanism for
  221.    intra-LIS multicast between routers. MARS, on the other hand, accepts
  222.    different tradeoffs in complexity-functionality design space. In
  223.    particular, while the MARS paradigm provides a general neighbor
  224.    discovery mechanism, allows host to participate, and is protocol
  225.    independent, it does so at considerable cost.
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235. Dino Farinacci, David Meyer, Yakov Rekhter              FORMFEED[Page 4]
  236.  
  237.  
  238.  
  239.  
  240.  
  241. Internet Draft  draft-ietf-ion-intralis-multicast-00.txt      April 1997
  242.  
  243.  
  244. 6. Security Considerations
  245.  
  246.    Security issues are not discussed in this document.
  247.  
  248.  
  249. 7. References
  250.  
  251.    [MARS]    G. Armitage, "Support for Multicast over UNI
  252.              3.0/3.1 based ATM Networks.", RFC2022, November
  253.              1996.
  254.  
  255.    [PIM-SM]  Estrin, D, et. al., "Protocol Independent Multicast
  256.              Sparse Mode (PIM-SM): Protocol Specification",
  257.              draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996.
  258.  
  259.  
  260.  
  261. 8. Acknowledgments
  262.  
  263.    To be supplied.
  264.  
  265.  
  266. 9. Author Information
  267.  
  268.  
  269.    Dino Farinacci
  270.    Cisco Systems
  271.    170 Tasman Dr.
  272.    San Jose, CA 95134
  273.    Phone: (408) 526-4696
  274.    e-mail: dino@cisco.com
  275.  
  276.    David Meyer
  277.    University of Oregon
  278.    1225 Kincaid St.
  279.    Eugene, OR 97403
  280.    Phone: (541) 346-1747
  281.    e-mail: meyer@antc.uoregon.edu
  282.  
  283.    Yakov Rekhter
  284.    cisco Systems, Inc.
  285.    170 Tasman Dr.
  286.    San Jose, CA 95134
  287.    Phone: (914) 528-0090
  288.    email: yakov@cisco.com
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295. Dino Farinacci, David Meyer, Yakov Rekhter              FORMFEED[Page 5]
  296.  
  297.  
  298.  
  299.  
  300.  
  301. Internet Draft  draft-ietf-ion-intralis-multicast-00.txt      April 1997
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355. Dino Farinacci, David Meyer, Yakov Rekhter              FORMFEED[Page 6]
  356.  
  357.  
  358.