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