home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-semeria-00.txt < prev    next >
Text File  |  1996-06-04  |  124KB  |  3,083 lines
  1.  
  2. INTERNET-DRAFT                                     Expires September 1996
  3.  
  4.  
  5.  
  6. INTERNET-DRAFT                                               C. Semeria
  7.                                                               T. Maufer
  8. Category: Informational                               3Comy Corporation
  9.                                                              March 1996
  10.  
  11.  
  12.  
  13.                Introduction to IP Multicast Routing
  14.  
  15.                  <draft-rfced-info-semeria-00.txt>
  16.  
  17.  
  18. 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
  26.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  27.    other documents at any time.  It is not appropriate to use Internet
  28.    Drafts as reference material or to cite them other than as a
  29.    "working draft" or "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:
  34.  
  35.          ftp.is.co.za (Africa)
  36.          nic.nordu.net (Europe)
  37.          ds.internic.net (US East Coast)
  38.          ftp.isi.edu (US West Coast)
  39.          munnari.oz.au (Pacific Rim)
  40.  
  41.  
  42. Semeria & Maufer                                               [Page 1]
  43.  
  44. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  45.  
  46.  
  47. ABSTRACT
  48.      The first part of this paper describes the benefits of 
  49.      multicasting, the MBONE, Class D addressing, and the operation of 
  50.      the Internet Group Management Protocol (IGMP).  The second 
  51.      section explores a number of different algorithms that may 
  52.      potentially be employed by multicast routing protocols:
  53.  
  54.      - Flooding
  55.      - Spanning Trees
  56.      - Reverse Path Broadcasting (RPB)
  57.      - Truncated Reverse Path Broadcasting (TRPB)
  58.      - Reverse Path Multicasting (RPM)
  59.      - Core Based Trees
  60.  
  61.      The third part contains the main body of the paper.  It 
  62.      describes how the previous algorithms are implemented in 
  63.      multicast routing protocols available today. 
  64.  
  65.      - Distance Vector Multicast Routing Protocol (DVMRP)
  66.      - Multicast OSPF (MOSPF)
  67.      - Protocol-Independent Multicast (PIM)
  68.  
  69. Table of Contents
  70.      1. INTRODUCTION
  71.      1.1 Multicast Groups
  72.      1.2 Group Membership Protocol
  73.      1.3 Multicast Routing Protocol
  74.      2. MULTICAST SUPPORT FOR EMERGING INTERNET APPLICATIONS
  75.      2.1 Reducing Network Load
  76.      2.2 Resource Discovery
  77.      2.3 Support for Datacasting Applications
  78.      3. THE INTERNET'S MULTICAST BACKBONE (MBONE)
  79.      4. MULTICAST ADDRESSING
  80.      4.1 Class D Addresses
  81.      4.2 Mapping a Class D Address to an Ethernet Address
  82.      4.3 Transimission and Delivery of Multicast Datagrams
  83.      5.0 INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
  84.      5.1 IGMP Version 1
  85.      5.2 IGMP Version 2
  86.      5.3 IGMP Version 3
  87.      6. MULTICAST FORWARDING ALGORITHMS
  88.      6.1 Flooding
  89.      6.2 Spanning Tree
  90.      6.3 Reverse Path Broadcasting (RPB)
  91.      6.3.1 Operation
  92.      6.3.2 Benefits and Limitations
  93.      6.4 Truncated Reverse Path Broadcasting (TRPB)
  94.      6.5 Reverse Path Multicasting (RPM)
  95.      6.5.1 Operation
  96.      6.5.2 Limitations
  97.      6.6 Core Based Trees
  98.  
  99.  
  100. Semeria & Maufer                                               [Page 2]
  101.  
  102. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  103.  
  104.      6.6.1 Operation
  105.      6.6.2 Benefits
  106.      6.6.3 Limitations
  107.      7. DISTANCE VECTOR MULTICAST ROUTING PROTOCOL (DVMRP)
  108.      7.1 Physical and Tunnel Interfaces
  109.      7.2 Basic Operation
  110.      7.3 DVMRP Router Functions
  111.      7.4 DVMRP Routing Table
  112.      7.5 DVMRP Forwarding Table
  113.      7.6 HIERARCHICAL DVMRP (DVMRP v4.0)
  114.      7.6.1 Benefits of Hierarchical Multicast Routing
  115.      7.6.2 Hierarchical Architecture
  116.      8. MULTICAST EXTENSIONS TO OSPF (MOSPF)
  117.      8.1 Intra-Area Routing with MOSPF
  118.      8.1.1 Local Group Database
  119.      8.1.2 Datagram's Shortest Path Tree
  120.      8.1.3 Forwarding Cache
  121.      8.2 Mixing MOSPF and OSPF Routers
  122.      8.3 Inter-Area Routing with MOSPF
  123.      8.3.1 Inter-Area Multicast Forwarders
  124.      8.3.2 Inter-Area Datagram's Shortest Path Tree
  125.      8.4 Inter-Autonomous System Multicasting with MOSPF
  126.      9. PROTOCOL-INDEPENDENT MULTICAST (PIM)
  127.      9.1 PIM-Dense Mode (PIM-DM)
  128.      9.2 PIM-Sparse Mode (PIM-SM)
  129.      9.2.1 Directly Attached Host Joins a Group
  130.      9.2.2 Directly Attached Source Sends to a Group
  131.      9.2.3 RP-Shared Tree or Shortest Path Tree (SPT)
  132.      9.3 Unresolved Issues
  133.      10. References
  134.      10.1 Request for Comments (RFCs)
  135.      10.2 Internet Drafts
  136.      10.3 Textbooks
  137.      10.4 Other
  138.      11. SECURITY CONSIDERATIONS
  139.      12. AUTHORS' ADDRESSES 
  140.  
  141.  
  142. 1. Introduction
  143.      There are three fundamental types of IPv4 addresses - unicast,
  144.      broadcast, and multicast.  A unicast address is designed to
  145.      transmit a packet to a single destination.  A broadcast address is
  146.      used to send a datagram to an entire subnetwork.  A
  147.      multicast address is designed to enable the delivery of datagrams
  148.      to a set of hosts that have been configured as members of a 
  149.      multicast group in various scattered subnetworks.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157. Semeria & Maufer                                               [Page3] 
  158.  
  159. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  160.  
  161.      Multicasting is not connection oriented.  A multicast datagram is
  162.      delivered to destination group members with the same "best-
  163.      effort" reliability as a standard unicast IP datagram.  This
  164.      means that a multicast datagram is not guaranteed to reach all
  165.      members of the group, or arrive in the same order relative to the
  166.      transmission of other packets.  
  167.  
  168.      The only difference between a multicast IP packet and a unicast
  169.      IP packet is the presence of a cgroup address` in the Destination
  170.      Address field of the IP header.  Instead of a Class A, B, or C IP
  171.      address, multicasting employs a Class D address format (224.0.0.0
  172.      - 239.255.255.255).  
  173.  
  174.  
  175. 1.1 Multicast Groups
  176.  
  177.      Individual hosts are free to join or leave a multicast group 
  178.      at any time.  There are no restrictions on the physical location 
  179.      or the number of members in a multicast group.  A host may be a 
  180.      member of more than one multicast group at any given time and 
  181.      does not have to belong to a group to send messages to members of 
  182.      a group.  
  183.  
  184. 1.2 Group Membership Protocol
  185.      A group membership protocol is employed by routers to learn about 
  186.      the presence of group members on their directly attached 
  187.      subnetworks.  When a host joins a multicast group, it 
  188.      transmits a group membership protocol message for the group(s) 
  189.      that it wishes to receive, and sets its IP process and network 
  190.      interface card to receive frames addressed to the multicast 
  191.      group.  This receiver-initiated join process has excellent
  192.      scaling properties since, as the multicast group increases in
  193.      size, it becomes ever more likely that a new group member will be 
  194.      able to locate a nearby branch of the multicast distribution tree.
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214. Semeria & Maufer                                               [Page4]
  215.  
  216. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  217.  
  218. ======================================================================
  219.                     _    _    _    _ 
  220.                    |_|  |_|  |_|  |_|
  221.                    '-'  '-'  '-'  '-'
  222.                     |    |    |    | 
  223.                   <- - - - - - - - - ->
  224.                            |
  225.                            |
  226.                            v
  227.                         Router 
  228.                            ^  
  229.                         /     \
  230.  _  ^                 +         +              ^  _ 
  231. |_|-|               /            \             |-|_|
  232. '_' |             +                +           | '_'
  233.  _  |          v                     v         |  _ 
  234. |_|-|- - >|Router| <- + - + - + -> |Router|<- -|-|_|
  235. '_' |                                          | '_'
  236.  _  |                                          |  _ 
  237. |_|-|                                          |-|_|
  238. '_' |                                          | '_'
  239.     v                                          v
  240.  
  241.  
  242. LEGEND
  243.  
  244. <- - - -> Group Membership Protocol
  245. <-+-+-+-> Multicast Routing Protocol
  246.  
  247. Figure 1: Multicast IP Delivery Service
  248. =====================================================================
  249.  
  250. 1.3 Multicast Routing Protocol
  251.  
  252.      Multicast routers execute a multicast routing protocol to define 
  253.      delivery paths that enable the forwarding of multicast datagrams 
  254.      across an internetwork.  The Distance Vector Multicast Routing
  255.      Protocol (DVMRP) is a distance-vector 
  256.      routing protocol and Multicast OSPF (MOSPF) is an 
  257.      extension to the OSPF link-state unicast routing protocol.  
  258.  
  259. 2. MULTICAST SUPPORT FOR EMERGING INTERNET APPLICATIONS
  260.  
  261.      Today, the majority of Internet applications rely on point-to-
  262.      point transmission.  The utilization of point-to-multipoint 
  263.      transmission has traditionally been limited to local area network
  264.      applications.  Over the past few years the Internet has seen a 
  265.      rise in the number of new applications that rely on multicast 
  266.      transmission.  Multicast IP conserves bandwidth by forcing the
  267.      network to do packet replication only when necessary, and offers 
  268.      an attractive alternative to unicast transmission for the delivery 
  269.  
  270.  
  271. Semeria & Maufer                                               [Page5]
  272.  
  273. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  274.  
  275.      of network ticker tapes, live stock quotes, multiparty video ,
  276.      conferencing and shared whiteboard applications, among others. 
  277.      It is important to note that the applications for IP Multicast 
  278.      are not solely limited to the Internet.  Multicast IP can also 
  279.      play an important role in large distributed commercial networks.
  280.  
  281. 2.1 Reducing Network Load
  282.  
  283.      Assume that a stock ticker application is required to
  284.      transmit packets to 100 stations within an organizationes 
  285.      network.  Unicast transmission to the group of stations will 
  286.      require the periodic transmission of 100 packets where many 
  287.      packets may be required to traverse the same link(s).  Multicast 
  288.      transmission is the ideal solution for this type of application 
  289.      since it requires only a single packet transmission by the source
  290.      which is replicated at forks in the multicast delivery tree.  
  291.  
  292.      Broadcast transmission is not an effective solution for this type
  293.      of application since it affects the CPU performance of each and 
  294.      every end station that sees the packet and it wastes bandwidth.
  295.  
  296. 2.2 Resource Discovery
  297.  
  298.      Some applications implement multicast group addresses instead of
  299.      broadcasts to transmit packets to group members residing on the 
  300.      same network.  However, there is no reason to limit the extent of
  301.      a multicast transmission to a single LAN.  The time-to-live (TTL)
  302.      field in the IP header can be used to limit the range (or "scope") 
  303.      of a multicast transmission.
  304.  
  305. 2.3 Support for Datacasting Applications
  306.  
  307.      Since 1992 the IETF has conducted a series of "audiocast" 
  308.      experiments in which live audio and video were multicast from the 
  309.      IETF meeting site to destinations around the world.  Datacasting 
  310.      takes compressed audio and video signals from the source station 
  311.      and transmits them as a sequence of UDP packets to a group 
  312.      address.  Multicasting might eliminate an organization's need to 
  313.      maintain parallel networks for voice, video, and data.  
  314.  
  315. 3. THE INTERNET'S MULTICAST BACKBONE (MBONE)
  316.  
  317.      The Internet Multicast Backbone (MBONE) is an interconnected set 
  318.      of subnetworks and routers that support the delivery of IP 
  319.      multicast traffic.  The goal of the MBONE is to construct a semi-
  320.      permanent IP multicast testbed to enable the deployment of 
  321.      multicast applications without waiting for the standardization 
  322.      process to deliver a complete set of Internet multicasting 
  323.      standards.  The MBONE has grown from 40 subnets in four different 
  324.      countries in 1992, to more than 2800 subnets in over 25 countries 
  325.      by March 1996.  With new multicast applications and multicast-
  326.  
  327.  
  328. Semeria & Maufer                                               [Page6] 
  329.  
  330. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  331.  
  332.      based services appearing, it appears likely that the MBONE 
  333.      will continue to grow at an ever-increasing rate.  
  334.  
  335.      The MBONE is a virtual network that is layered on top of sections
  336.      of the physical Internet.  It is composed of islands of multicast
  337.      routing capability connected to other islands by virtual point-
  338.      to-point links called "tunnels."  The tunnels allow multicast 
  339.      traffic to pass through the non-multicast-capable parts of the 
  340.      Internet.  IP multicast packets are encapsulated as IP-over-IP 
  341.      (i.e., the protocol number is set to 4) so they look like normal
  342.      unicast packets to intervening routers.  The encapsulation is 
  343.      added on entry to a tunnel and stripped off on exit from a 
  344.      tunnel.  This set of multicast routers, their directly connected
  345.      subnetworks, and the interconnecting tunnels define the MBONE.
  346.  
  347. ======================================================================
  348.  
  349.  
  350.                       +++++++ 
  351.                    / |Island | \
  352.                  /T/ |   A   | \T\
  353.                 /U/  +++++++++   \U\
  354.               /N/        |         \N\
  355.             /N/          |           \N\
  356.           /E/            |             \E\
  357.         /L/              |               \L\
  358.  ++++++++            +++++++++           ++++++++ 
  359. | Island |           | Island| ---------| Island |
  360. |    B   |           |   C   |   Tunnel |   D    |
  361. ++++++++++           +++++++++ --------- ++++++++ 
  362.        \ \               |
  363.          \T\             |
  364.            \U\           |
  365.             \N\          |
  366.               \N\    +++++++++ 
  367.                 \E\  |Island | 
  368.                   \L\|   E   | 
  369.                     \+++++++++ 
  370. .           
  371.  
  372. Figure 2: Internet Multicast Backbone (MBONE)
  373. ======================================================================
  374.  
  375.      Since the MBONE and the Internet have different topologies, 
  376.      multicast routers execute a separate routing protocol to 
  377.      decide how to forward multicast packets.  The majority of the 
  378.      MBONE routers currently use the Distance Vector Multicast 
  379.      Routing Protocol (DVMRP), although some portions of the MBONE 
  380.      execute either Multicast OSPF (MOSPF) or the Protocol-Independent
  381.      Multicast (PIM) routing protocols.  The operation of each of 
  382.      these protocols is discussed later in this paper.
  383.  
  384.  
  385. Semeria & Maufer                                               [Page7] 
  386.  
  387. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  388.  
  389.      The MBONE carries audio and video multicasts of Internet 
  390.      Engineering Task Force (IETF) meetings, NASA Space Shuttle 
  391.      Missions, U.S. House and Senate sessions, and live satellite 
  392.      weather photos.  The Session Directory (SD) tool provides users 
  393.      with a listing of the active multicast sessions on the MBONE and 
  394.      allows them to define or join a conference.  
  395.  
  396. 3. MULTICAST ADDRESSING
  397.      A multicast address is assigned to a set of receivers defining a
  398.      multicast group.  Senders use the multicast address as the      
  399.      destination IP address of a packet that is to be transmitted to 
  400.      all group members.  
  401.  
  402. Class D Addresses
  403.  
  404.      An IP multicast group is identified by a Class D address.  Class 
  405.      D addresses have their high-order four bits set to "1110" 
  406.      followed by a 28-bit multicast group ID.  Expressed in standard 
  407.      "dotted-decimal" notation, multicast group addresses range from 
  408.      224.0.0.0 to 239.255.255.255.  Figure 3 shows the format of a 32-
  409.      bit Class D address.  
  410.  
  411. ======================================================================
  412.  
  413.  
  414.       0 1 2 3                                                      31
  415.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  416.      |1|1|1|0|                   Multicast Group ID                  |
  417.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  418.              |------------------28 bits------------------------------|
  419.  
  420.  
  421. Figure 3: Class D Multicast Address Format
  422. ======================================================================
  423.  
  424.      The Internet Assigned Numbers Authority (IANA) maintains a list 
  425.      of registered IP multicast groups.  The base address 224.0.0.0 is
  426.      reserved and cannot be assigned to any group.  The block of 
  427.      multicast addresses ranging from 224.0.0.1 to 224.0.0.255 is 
  428.      reserved for the use of routing protocols and other low-level 
  429.      topology discovery or maintenance protocols.  Multicast routers 
  430.      will not forward a multicast datagram with a destination address 
  431.      in this range, regardless of its TTL.  
  432.  
  433.      The remaining groups ranging from 224.0.1.0 to 239.255.255.255 
  434.      are assigned to various multicast applications or remain 
  435.      unassigned.  From this range, 239.0.0.0 to 239.255.255.255 are to 
  436.      be reserved for site-local "administratively scoped" applications, 
  437.      not Internet-wide applications. Some of the well-known groups 
  438.      include: "all systems on this subnet" (224.0.0.1), "all routers on  
  439.      this subnet"(224.0.0.2), "all DVMRP routers" (224.0.0.4), "all 
  440.  
  441.  
  442. Semeria & Maufer                                               [Page8]
  443.  
  444. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  445.  
  446.      OSPF routers" (224.0.0.5), "IETF-1-Audio" (224.0.1.11), 
  447.      "IETF-1-Video" (224.0.1.12), "AUDIONEWS" (224.0.1.7), and "MUSIC-
  448.      SERVICE" (224.0.1.16) .  
  449.  
  450. 4.2 Mapping a Class D Address to an Ethernet Address
  451.  
  452.      The IANA has been allocated a reserved portion of the IEEE-802 
  453.      MAC-layer multicast address space.  All of the addresses in IANA's 
  454.      reserved block begin with 01-00-5E (hex).  A simple procedure was 
  455.      developed to map Class D addresses to this reserved address block.  
  456.      This allows IP multicasting to take advantage of the hardware-
  457.      level multicasting supported by network interface cards.  
  458.  
  459.      For example, the mapping between a Class D IP address and an
  460.      Ethernet multicast address is obtained by placing the low-order 23
  461.      bits of the Class D address into the low-order 23 bits of IANA's
  462.      reserved address block.  
  463.  
  464.      Figure 4 illustrates how the multicast group address 
  465.      224.10.8.5 (E0-0A-08-05) is mapped into an Ethernet (IEEE-802)
  466.      multicast address.  
  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.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499. Semeria & Maufer                                               [Page9]
  500.  
  501. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  502.  
  503. ======================================================================
  504.    Class D Address: 224.10.8.5                             
  505.                                      E       0   -    0    
  506.                                  _________ _______ _______ 
  507.                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+
  508.                                 |1 1 1 0 0 0 0 0|0 0 0 0 1
  509.                                 +-+-+-+-+-.-+-+-+-+.+-+-+-+
  510.                                         |          |       
  511.                                         |    not   |       
  512. Ethernet                                |          |       
  513. Multicast                               |   used   |       
  514. Address                                 |          |       
  515. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  516. |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|0 1 0 1 1 1 1 0|0 0 0 0 1
  517. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  518. ________ _______ _______ _______ ________ _______ ________ 
  519.     0       1   -   0       0   -    5       E   -    0    
  520.  
  521.  
  522.     [Address mapping below continued from half above]
  523.  
  524.  
  525.    A   -   0       8  -     0      5
  526.   _______ _______ _______ _______ _______
  527.   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  528.   0 1 0|0 0 0 0 1 0 0 0|0 0 0 0 0 1 0 1|
  529.   -+.+-+-+-+-+.+-+-+-+-+.+-+-+-+-+.+-+-+
  530.                ^
  531.                |
  532.     low-order 23-bits mapped 
  533.                |
  534.                v
  535.   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  536.   0 1 0|0 0 0 0 1 0 0 0|0 0 0 0 0 1 0 1|
  537.   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.   _______ _______ _______ ________ _____ 
  539.    A   -   0       8   -    0      5     
  540.  
  541.  
  542. Figure 4: Mapping between Class D and IEEE-802 Multicast Addresses
  543. ======================================================================
  544.  
  545.      The mapping in Figure 4 places the low-order 23 bits of the IP 
  546.      multicast group ID into the low order 23 bits of the Ethernet 
  547.      address.  You should note that the mapping may place up to 32 
  548.      different IP groups into the same Ethernet address because the 
  549.      upper 5 bits of the IP multicast group ID are ignored.  For 
  550.      example, the multicast addresses 224.138.8.5 (E0-8A-08-05) and 
  551.      225.10.8.5 (E1-0A-08-05) would also be mapped to the same 
  552.      Ethernet address (01-00-5E-0A-08-05) used in this example.
  553.  
  554.  
  555.  
  556.  
  557. Semeria & Maufer                                              [Page 10] 
  558.  
  559. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  560.  
  561. 4.3 Transmission and Delivery of Multicast Datagrams
  562.  
  563.      When the sender and receivers are members of the same (LAN)
  564.      subnetwork, the transmission and reception of multicast frames is  
  565.      a relatively simple process.  The source station simply addresses 
  566.      the IP packet to the multicast group, the network interface card 
  567.      maps the Class D address to the corresponding IEEE-802 multicast
  568.      address, and the frame is sent.  Receivers that wish to capture 
  569.      the frame notify their IP layer that they want to receive 
  570.      datagrams addressed to the group.  
  571.  
  572.      Things become much more complicated when the sender is attached 
  573.      to one subnetwork and receivers reside on different subnetworks.
  574.      In this case, the routers are required to implement a multicast 
  575.      routing protocol that permits the construction of multicast 
  576.      delivery trees and supports multicast data packet forwarding.  In
  577.      addition, each router needs to implement a group membership 
  578.      protocol that allows it to learn about the existence of group 
  579.      members on its directly attached subnetworks.  
  580.  
  581. 5. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
  582.  
  583.      The Internet Group Management Protocol (IGMP) runs between hosts 
  584.      and their immediately-neighboring multicast routers.  The 
  585.      mechanisms of the protocol allow a host to inform its local 
  586.      router that it wishes to receive transmissions addressed to a 
  587.      specific multicast group.  Also, routers periodically query the 
  588.      LAN to determine if known group members are still active.  If 
  589.      there is more than one router on the LAN performing IP 
  590.      multicasting, one of the routers is elected "querier" and
  591.      assumes the responsibility of querying the LAN for group members.
  592.  
  593.      Based on the group membership information learned from the IGMP,
  594.      a router is able to determine which (if any) multicast traffic 
  595.      needs to beforwarded to each of its "leaf" subnetworks.  Multicast
  596.      routers use this information, in conjunction with a multicast
  597.      routing protocol, to support IP multicasting across the Internet.  
  598.  
  599. 5.1 IGMP Version 1
  600.  
  601.      IGMP Version 1 was specified in RFC-1112.  According to the 
  602.      specification, multicast routers periodically transmit Host 
  603.      Membership Query messages to determine which host groups have 
  604.      members on their directly attached networks.  Query messages are
  605.      addressed to the all-hosts group (224.0.0.1) and have an IP TTL =
  606.      1.  This means that Query messages sourced by a router are      
  607.      transmitted across the directly attached subnetwork but are not 
  608.      forwarded by another multicast router.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614. Semeria & Maufer                                              [Page 11]
  615.  
  616. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  617.  
  618. ======================================================================
  619.  
  620.  
  621.      Group 1                                         
  622.       ____            ____                    _____________________
  623.      |    |          |    |                  |  multicast rounter  |
  624.      |_H2_|          |_H4_|                  |_____________________|
  625.       ----            ----                       _____   |
  626.         |               |                    <--|Query|  |
  627.         |               |                       |-----|  |
  628.         |               |                                |
  629. ---|----|-------|-------|--------|-----------------------|
  630.    |            |                |
  631.    |            |                |
  632.  ____         ____              ____
  633. |    |       |    |            |    |
  634. |_H1_|       |_H3_|            |_H5_|
  635.  ----         ----              ---- 
  636. Group 2      Group 1           Group 1
  637.              Group 2
  638.  
  639.  
  640.  
  641. Figure 5: Internet Group Management Protocol-Query Message
  642. ======================================================================
  643.  
  644.      When a host receives a Query message, it responds with a Host 
  645.      Membership Report for each host group to which it belongs.  In 
  646.      order to avoid a flurry of Reports, each host starts a randomly-
  647.      chosen Report delay timer for each of its group memberships.  If, 
  648.      during the delay period, another Report is heard for the same 
  649.      group, the local host cancels its Report for the group.  
  650.      Otherwise, the host transmits a Report to the reported group 
  651.      address causing all other members of the group to cancel their 
  652.      Report messages.  This procedure guarantees that Reports are 
  653.      spread out over a period of time and that only one Report is 
  654.      generated for each group with at least one member on the 
  655.      subnetwork.
  656.  
  657.      It should be noted that multicast routers do not need to be 
  658.      directly addressed since their interfaces are configured to 
  659.      receive all multicast IP traffic.  Also, a router does not need 
  660.      to maintain a detailed list of which hosts belong to each 
  661.      multicast group, the router only needs to know that at least one 
  662.      group member is present on a network interface.  
  663.  
  664.      Multicast routers periodically transmit Queries to update their 
  665.      knowledge of the group members present on each network interface.
  666.  
  667.  
  668.  
  669.  
  670.  
  671. Semeria & Maufer                                              [Page 12]
  672.  
  673. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  674.  
  675.      If the router does not receive a Report for a particular group 
  676.      after a number of Queries, the router assumes that group members 
  677.      are no longer present on the interface and the group is removed 
  678.      from the list of group memberships for the directly attached 
  679.      subnetwork.
  680.  
  681.      When a host first joins a group, it immediately transmits a 
  682.      Report for the group rather than waiting for a router Query.  
  683.      This guarantees that the host will receive traffic addressed to 
  684.      the group if it is the first member of that group on the 
  685.      subnetwork.  
  686.  
  687. 5.2 IGMP Version 2
  688.  
  689.      IGMP Version 2 was distributed as part of the IP Multicasting 
  690.      (Version 3.3 through Version 3.6) code package.  Initially, there
  691.      was no detailed specification for IGMP Version 2 other than the 
  692.      source code.  However, the complete specification 
  693.      has recently been published in <draft-ietf-idmr-igmp-v2-01.txt> 
  694.      which replaces the informal specification contained in Appendix I
  695.      of RFC-1112.  IGMP Version 2 enhances and extends IGMP Version 1
  696.      while also providing backwards compatibility with Version 1 
  697.      hosts.  
  698.  
  699.      IGMP Version 2 defines a procedure for the election of the 
  700.      multicast querier for each LAN.  In IGMP Version 2, the router 
  701.      with the lowest IP address on the LAN is elected the multicast 
  702.      querier.  In IGMP Version 1, the querier election was determined
  703.      by the multicast routing protocol.  This could lead to potential
  704.      problems because each multicast routing protocol used different 
  705.      methods for determining the multicast querier.   
  706.  
  707.      IGMP Version 2 defines a new type of Query message - the Group-
  708.      Specific Query message.  Group-Specific Query messages allow a 
  709.      router to transmit a Query to a specific multicast group rather 
  710.      than all groups residing on a directly attached subnetwork.
  711.  
  712.      Finally, IGMP Version 2 defines a Leave Group message to add low-
  713.      leave latency to IGMP.  When the last host to respond to a Query 
  714.      with a Report wishes to leave that specific group, the host 
  715.      transmits a Leave Group message to the all-routers group 
  716.      (224.0.0.2) with the group field set to the group to be left.  In
  717.      response to a Leave Group message, the router begins the 
  718.      transmission of Group-Specific Query messages on the interface 
  719.      that received the Leave Group message.  If there are no Reports 
  720.      in response to the Group-Specific Query messages, the group is 
  721.      removed from the list of group memberships for the directly 
  722.      attached subnetwork.
  723.  
  724.  
  725.  
  726.  
  727.  
  728. Semeria & Maufer                                              [Page 13] 
  729.  
  730. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  731.  
  732. 5.3 IGMP Version 3
  733.      IGMP Version 3 is a preliminary draft specification published in 
  734.      <draft-cain-igmp-00.txt>.  IGMP Version 3 introduces support for 
  735.      Group-Source Report messages so that a host can elect to receive 
  736.      traffic from specific sources of a multicast group.  An Inclusion
  737.      Group-Source Report message allows a host to specify the IP 
  738.      addresses of the specific sources it wants to receive.  An 
  739.      Exclusion Group-Source Report message allows a host to explicitly
  740.      identify the sources that it does not want to receive.  With IGMP
  741.      Version 1 and Version 2, if a host wants to receive any sources 
  742.      from a group, the traffic from all sources for the group has to 
  743.      be forwarded onto the subnetwork.  
  744.  
  745.      IGMP Version 3 will help conserve bandwidth by allowing a 
  746.      host to select the specific sources from which it wants to receive
  747.      traffic.Also, multicast routing protocols will be able to make use
  748.      this information to conserve bandwidth when constructing the 
  749.      branches of their multicast delivery trees.  
  750.  
  751.      Finally, support for Leave Group messages first introduced in 
  752.      IGMP Version 2 has been enhanced to support Group-Source Leave 
  753.      messages.  This feature allows a host to leave an entire group or
  754.      to specify the specific IP address of the group-source(s) that it
  755.      wishes to leave.  
  756.  
  757. MULTICAST FORWARDING ALGORITHMS
  758.  
  759.      IGMP provides the final step in a multicast packet delivery 
  760.      service since it is only concerned with the forwarding of 
  761.      multicast traffic from the local router to group members on 
  762.      directly-attached subnetworks.  IGMP is not concerned with the
  763.      delivery of multicast packets between neighboring routers or 
  764.      across an internetwork.
  765.  
  766.      To provide an Internet-wide delivery service, it is necessary to
  767.      define multicast routing protocols.  A multicast routing 
  768.      protocol is responsible for the construction of multicast packet
  769.      delivery trees and performing multicast packet forwarding.  This 
  770.      section explores a number of different algorithms that may 
  771.      potentially be employed by multicast routing protocols:
  772.  
  773.      - Flooding
  774.      - Spanning Trees
  775.      - Reverse Path Broadcasting (RPB)
  776.      - Truncated Reverse Path Broadcasting (TRPB)
  777.      - Reverse Path Multicasting (RPM)
  778.      - Core Based Trees
  779.  
  780.      Later sections will describe how these algorithms are implemented
  781.      in the most prevalent multicast routing protocols in the Internet
  782.      today. 
  783.  
  784.  
  785. Semeria & Maufer                                              [Page 14]
  786.  
  787. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  788.  
  789.      - Distance Vector Multicast Routing Protocol (DVMRP)
  790.      - Multicast OSPF (MOSPF)
  791.      - Protocol-Independent Multicast (PIM)
  792.  
  793. 6.1 Flooding
  794.  
  795.      The simplest technique for delivering multicast datagrams to all 
  796.      routers in an internetwork is to implement a flooding algorithm.
  797.      The flooding procedure begins when a router receives a packet 
  798.      that is addressed to a multicast group.  The router employs a 
  799.      protocol mechanism to determine whether this is the first time 
  800.      that it has seen this particular packet or whether it has seen 
  801.      the packet before.  If it is the first reception of the packet, 
  802.      the packet is forwarded on all interfaces, except the one on 
  803.      which it arrived, guaranteeing that the multicast packet reaches 
  804.      all routers in the internetwork.  If the router has seen the 
  805.      packet before, it is simply discarded.  
  806.  
  807.      A flooding algorithm is very simple to implement since a router 
  808.      does not have to maintain a routing table and only needs to keep 
  809.      track of the most recently seen packets.  However, flooding does 
  810.      not scale for Internet-wide applications since it generates a 
  811.      large number of duplicate packets and uses all available paths 
  812.      across the internetwork instead of just a limited number.  Also, 
  813.      the flooding algorithm makes inefficient use of router memory 
  814.      resources since each router is required to maintain a distinct 
  815.      table entry for each recently seen packet.
  816.  
  817. 6.2 Spanning Tree
  818.  
  819.      A more effective solution than flooding would be to select a 
  820.      subset of the Internet topology that forms a spanning tree.  The 
  821.      spanning tree defines a tree structure where only one active path 
  822.      connects any two routers on the Internet.  Figure 6 shows an 
  823.      internetwork and a spanning tree rooted at router RR.
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Semeria & Maufer                                              [Page 15] 
  843.  
  844. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  845.  
  846. ======================================================================
  847. Internetwork
  848.  
  849.      #----------------#
  850.    / |\              / \
  851.   |  | \           /    \
  852.   |  |   \       /       \
  853.   |  |    \    /          \
  854.   |  |      \ /            \
  855.   |  |       #------#       \
  856.   |  |      /       | \      \
  857.   |  |     /        |  \      \
  858.   |   \   /         |   \-------#
  859.   |    \ /          |     -----/|
  860.   |     #-----------#----/      | 
  861.   |    /|\---    --/|    \      |
  862.   |   / |    \  /    \    \     |
  863.   |  /   \    /\     |     \   /
  864.   | /      \ /   \   |      \ /
  865.   #---------#--   \  |   ----#
  866.                \   \ |  /     
  867.                 \--- #-/      
  868.  
  869. Spanning Tree
  870.  
  871.      #                #
  872.       \              /  
  873.        \           /     
  874.          \       /        
  875.           \    /           
  876.             \ /             
  877.              #------RR        
  878.                     | \       
  879.                     |  \       
  880.                     |   \-------#
  881.                     |            
  882.         #-----------#----        
  883.        /|           |    \       
  884.       / |            \    \      
  885.      /   \           |     \     
  886.     /      \         |      \    
  887.   #         #-       |       #   
  888.                      |
  889.                      #
  890.  
  891.  
  892. LEGEND
  893.  
  894. #   Router
  895. RR  Root Router
  896. Figure 6: Spanning Tree
  897. ======================================================================
  898.  
  899. Semeria & Maufer                                              [Page 16] 
  900.  
  901. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  902.  
  903.      Once the spanning tree has been built, a multicast router simply 
  904.      forwards each multicast packet to all interfaces that are part of 
  905.      the spanning tree except the one on which the packet originally 
  906.      arrived.  Forwarding along the branches of a spanning tree 
  907.      guarantees that the multicast packet will not loop and that it 
  908.      will eventually reach all routers in the internetwork.  
  909.  
  910.      A spanning tree solution is powerful and would be relatively easy 
  911.      to implement since there is a great deal of experience with 
  912.      spanning tree protocols in the Internet community.  However,
  913.      a spanning tree solution can centralize traffic on a small number
  914.      of links, and may not provide the most efficient path between the 
  915.      source subnetwork and group members
  916.  
  917. 6.3 Reverse Path Broadcasting (RPB)
  918.  
  919.      An even more efficient solution than building a single spanning 
  920.      tree for the entire Internet would be to build a group-specific 
  921.      spanning tree for each potential source subnetwork.  These 
  922.      spanning trees would result in source-rooted delivery trees 
  923.      emanating from the subnetwork directly connected to the source 
  924.      station.  Since there are many potential sources for a group, a 
  925.      different spanning tree is constructed for each active (source, 
  926.      group) pair.
  927.  
  928. 6.3.1 Operation
  929.  
  930.      The fundamental algorithm to construct these source-rooted trees 
  931.      is referred to as Reverse Path Broadcasting (RPB).  The RPB 
  932.      algorithm is actually quite simple.  For each (source, group) 
  933.      pair, if a packet arrives on a link that the local router 
  934.      considers to be the shortest path back to the source of the 
  935.      packet, then the router forwards the packet on all interfaces 
  936.      except the incoming interface.  Otherwise, the packet is 
  937.      discarded.  The interface over which the router expects to 
  938.      receive multicast packets from a particular source is referred to 
  939.      as the "parent" link.  The outbound links over which the router 
  940.      forwards the multicast packet are called the "child" links.   
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956. Semeria & Maufer                                              [Page 17] 
  957.  
  958. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  959.  
  960. ======================================================================
  961.  
  962.  
  963.                  Source
  964.                     .   ^
  965.                     .   |    shortest path back to the
  966.                     .   |     source for THIS router
  967.                     .   |
  968.                "parent link"
  969.                     _
  970.             ______|!2|_____
  971.            |               |
  972. --"child -|!1|           |!3| - "child --
  973.     link"  |    ROUTER     |      link" 
  974.            |_______________|
  975.  
  976.  
  977. Figure 6: Reverse Path Broadcasting - Forwarding Algorithm
  978. ======================================================================
  979.  
  980.      This basic algorithm can be enhanced to reduce unnecessary packet 
  981.      duplication if the router making the forwarding decision can 
  982.      determine whether a neighboring router on a potential child link 
  983.      considers the local router to be on its shortest path back to the 
  984.      source (i.e., on the remote router's parent link for the (source, 
  985.      group) pair).  If this is the case, the packet is forwarded to 
  986.      the neighbor.  Otherwise, the datagram is not forwarded on the 
  987.      potential child link because the neighboring router will be 
  988.      required to discard the packet since it arrives on a non-parent 
  989.      link for the (source, group) pair.  
  990.  
  991.      The information to make this "downstream" decision is relatively 
  992.      easy to derive from a link-state routing protocol since each 
  993.      router maintains a topological database for the entire routing 
  994.      domain.  If a distance-vector routing protocol is employed, a 
  995.      neighbor can either advertise its previous hop for the (source, 
  996.      group) pair as part of its routing update messages or "poison 
  997.      reverse" the route.  Either of these techniques allows an 
  998.      upstream router to determine if a downstream neighboring router 
  999.      considers it to be on the downstream router's shortest path back
  1000.      to the source.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013. Semeria & Maufer                                              [Page 18] 
  1014.  
  1015. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1016.  
  1017. ======================================================================
  1018.  Source Station------>O
  1019.                     A #
  1020.                      +|+
  1021.                     + | +
  1022.                    +  O  +
  1023.                   +       +
  1024.                  1         2
  1025.                 +           +
  1026.                +             +
  1027.               +               +
  1028.           B  +                 +  C
  1029.           O-#- - - - -3- - - - -#-O
  1030.            +|+                 +|+
  1031.           + | +               + | +
  1032.          +  O  +             +  O  +
  1033.         +       +           +       +
  1034.        +         +         +         +
  1035.       4           5       6           7
  1036.      +             +     +             +
  1037.     +               + E +               +
  1038.    +                 + +                 +
  1039. D #- - - - -8- - - - -#- - - - -9- - - - -# F
  1040.   |                   |                   |
  1041.   O                   O                   O
  1042.  
  1043.  
  1044. LEGEND
  1045.  
  1046. O   Leaf
  1047. + + Shortest-path
  1048. - - Branch
  1049. #   Router
  1050.  
  1051.  
  1052. Figure 8: Reverse Path Broadcasting - Example
  1053. =======================================================================
  1054.  
  1055.      Please refer to Figure 8 for a discussion describing the basic 
  1056.      operation of the enhanced RPB algorithm.  Note that the source 
  1057.      station (S) is attached to a leaf subnetwork directly connected 
  1058.      to Router A.  For this example, we will look at the RPB algorithm 
  1059.      from Router B's perspective.  Router B receives the multicast 
  1060.      packet from Router A on link 1.  Since Router B considers link 1 
  1061.      to be the parent link for the (source, group) pair, it 
  1062.      forwards the packet on link 4, link 5, and the local leaf 
  1063.      subnetworks if they have group members.  Router B does not 
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070. Semeria & Maufer                                              [Page 19] 
  1071.  
  1072. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1073.  
  1074.      forward the packet on link 3 because it knows from routing 
  1075.      protocol exchanges that Router C considers link 2 as its parent 
  1076.      link for the (source, group) pair.  If Router B were to forward 
  1077.      the packet on link 3 it would be discarded by Router C since it 
  1078.      would arrive on a non-parent link for the (source, group) pair.  
  1079.  
  1080. 6.3.2 Benefits and Limitations
  1081.  
  1082.      The key benefit to reverse path broadcasting is that it is 
  1083.      reasonably efficient and easy to implement.  It does not require 
  1084.      that the router know about the entire spanning tree nor does it 
  1085.      require a special mechanism to stop the forwarding process, as 
  1086.      flooding does.  In addition, it guarantees the fastest delivery 
  1087.      possible since multicast packets always follow the shortest path 
  1088.      from the source station to the destination group.  Finally, the 
  1089.      packets are distributed over multiple links resulting in better 
  1090.      network utilization since a different tree is computed for each 
  1091.      (source, group) pair.  
  1092.  
  1093.      One of the major limitations of the RPB algorithm is that it does 
  1094.      not take into account multicast group membership when building 
  1095.      the distribution tree for a (source, group) pair.  As a result, 
  1096.      datagrams may be unnecessarily forwarded to subnetworks that have 
  1097.      no members in the destination group.  
  1098.  
  1099. 6.4 Truncated Reverse Path Broadcasting (TRPB)
  1100.  
  1101.      Truncated Reverse Path Broadcasting (TRPB) was developed to 
  1102.      overcome the limitations of Reverse Path Broadcasting.  With the 
  1103.      help of IGMP, multicast routers determine the group memberships 
  1104.      on each leaf subnetwork and avoid forwarding datagrams onto a 
  1105.      leaf subnetwork if it does not have a member of the destination 
  1106.      group present.  The spanning delivery tree is "truncated" by the 
  1107.      router if a leaf subnetwork does not have group members.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127. Semeria & Maufer                                              [Page 20] 
  1128.  
  1129. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1130.  
  1131. ======================================================================
  1132.                       Source
  1133.                           .   |
  1134.                           .   |
  1135.                           .   |     (Source, G1)
  1136.                           .   v
  1137.                           |
  1138.                      "parent link"
  1139.                           |
  1140.         "child link"     __
  1141.     G1            ______|!2|_____
  1142.      \           |               |
  1143.    G3\\ _____   --     ROUTER   --       ______ / G2
  1144.       \| hub |--|!1|           |!3|-----|switch|/
  1145.       /|_____|  ^--      --     -- ^    |______|\
  1146.       /        ^ |______|!4|_____|   ^          \ 
  1147.     G1       ^         ^ --            ^         G3
  1148.             ^        ^   |              ^ 
  1149.         Forward->->-^ "child link"  Truncate
  1150.                          |
  1151.  
  1152. Figure 9: Truncated Reverse Path Broadcasting - (TRPB)
  1153. ======================================================================
  1154.  
  1155.      Figure 9 illustrates the operation of TRPB algorithm.  In this 
  1156.      example the router receives a multicast packet on its parent link 
  1157.      for the (Source, G1) pair.  The router forwards the datagram on 
  1158.      !1 since the interface has at least one member of G1.  The router 
  1159.      does not forward the datagram to !3 since this interface has no 
  1160.      members in the destination group.  The datagram is forwarded on 
  1161.      !4 if and only if a downstream router considers the interface as 
  1162.      part of its "parent link" for the (Source, G1) pair.  
  1163.  
  1164.      TRPB removes some limitations of RPB but it solves only part of 
  1165.      the problem.  It eliminates unnecessary traffic on leaf           
  1166.      subnetworks but it does not consider group memberships when      
  1167.      building the branches of the distribution tree.
  1168.  
  1169. 6.5 Reverse Path Multicasting (RPM)
  1170.  
  1171.      Reverse Path Multicasting (RPM) is an enhancement to Reverse Path 
  1172.      Broadcasting and Truncated Reverse Path Broadcasting.  RPM 
  1173.      creates a delivery tree that spans only: 
  1174.  
  1175.      -Subnetworks with group members, and
  1176.      -Routers and subnetworks along the shortest path to subnetworks 
  1177.      with group members
  1178.  
  1179.      RPM allows the source-rooted spanning tree to be pruned so that 
  1180.      datagrams are only forwarded along branches that lead to members
  1181.      of the destination group.  
  1182.  
  1183.  
  1184. Semeria & Maufer                                              [Page 21] 
  1185.  
  1186. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1187.  
  1188. 6.5.1 Operation
  1189.  
  1190.      When a multicast router receives a packet for a (source, group) 
  1191.      pair, the first packet is forwarded following the TRPB algorithm 
  1192.      to all routers in the internetwork.  Routers that are at the edge 
  1193.      of the network and have no further down-stream routers in the TRPB 
  1194.      tree are called leaf routers.  The TRPB algorithm guarantees that 
  1195.      each leaf router receives the first multicast packet.  If there is 
  1196.      a group member on one of its leaf subnetworks, a leaf router 
  1197.      forwards the packet based on its IGMP information.  If none of 
  1198.      the subnetworks connected to the leaf router have group members, 
  1199.      the leaf router may transmit a "prune" message on its parent link 
  1200.      informing the upstream router that it should not forward packets 
  1201.      for the particular (source, group) pair on the child interface 
  1202.      receiving the prune message.  Prune messages are only sent one   
  1203.      hop back towards the source.
  1204.  
  1205.  
  1206. ======================================================================
  1207.                    Source
  1208.                       . |
  1209.                       . | (Source, G)
  1210.                       . |
  1211.                       | v
  1212.                       | 
  1213.                     O-#-G
  1214.                       |**********
  1215.                     ^ |         *
  1216.                     , |         *
  1217.                     ^ |         *  O
  1218.                     , |         * /
  1219.                     O-#-O       #***********
  1220.                     ^ |\      ^ |\         *
  1221.                     ^ | O     ^ | G        *
  1222.                     , |       , |          *
  1223.                     ^ |       ^ |          *
  1224.                     , |       , |          *
  1225.                       #         #          # 
  1226.                      /|\       /|\        /|\ 
  1227.                     O O O     O O O      G O G
  1228. LEGEND
  1229.  
  1230. #   Router
  1231. O   Leaf without group member
  1232. G   Leaf with group member
  1233. *** Active Branch
  1234. --- Pruned Branch
  1235. ,>, Prune Message (direction of flow -->
  1236.  
  1237. Figure 10: Reverse Path Multicasting  (RPM)
  1238. ======================================================================
  1239.  
  1240.  
  1241. Semeria & Maufer                                              [Page 22] 
  1242.  
  1243. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1244.  
  1245.      An upstream router receiving a prune message is required to 
  1246.      record the prune information in memory.  If the upstream router 
  1247.      has no local recipient and receives prune messages on each of the 
  1248.      child interfaces that it used to forward the first packet, the 
  1249.      upstream router does not need to receive additional packets for 
  1250.      the (source, group) pair.  This means that the upstream router 
  1251.      can generate a prune message of its own, one hop back towards the 
  1252.      source.  The cascade of prune messages creates a multicast 
  1253.      forwarding tree that only contains branches that lead to active 
  1254.      group members.  
  1255.  
  1256.      Since both the group membership and network topology are
  1257.      dynamically changing, the pruned state of the multicast 
  1258.      forwarding tree must be refreshed at regular intervals.  
  1259.      Periodically, the prune information is removed from the memory of 
  1260.      all routers and the next packet for the (source, group) pair is 
  1261.      forwarded to all leaf routers.  This results in a new burst of 
  1262.      prune messages allowing the multicast forwarding tree to adapt to 
  1263.      the ever changing multicast delivery requirements of the 
  1264.      internetwork.  
  1265.  
  1266. 6.5.2 Limitations
  1267.  
  1268.      Despite the improvements offered by the RPM algorithm, there are 
  1269.      still several scaling issues that need to be addressed when 
  1270.      attempting to develop an Internet-wide delivery service.  The 
  1271.      first limitation is that multicast packets must be periodically 
  1272.      forwarded to every router in the internetwork.  The second 
  1273.      drawback is that each router is required to maintain state 
  1274.      information for all groups and each source.  The significance of 
  1275.      these shortcomings is amplified as the number of sources and 
  1276.      groups in the multicast internetwork expands.  
  1277.  
  1278. 6.6 Core Based Trees (CBT)
  1279.  
  1280.      The latest addition to the existing set of multicast forwarding 
  1281.      algorithms is the Core Based Trees (CBT).  Unlike existing 
  1282.      algorithms which build a source-rooted, shortest-path tree for 
  1283.      each (source, group) pair, CBT constructs a single delivery tree 
  1284.      that is shared by all members of a group.  The CBT algorithm is 
  1285.      quite similar to the spanning tree algorithm except it constructs 
  1286.      a different core-based tree for each group.  Multicast traffic 
  1287.      for each group is sent and received over the same delivery tree, 
  1288.      regardless of the source.  
  1289.  
  1290. 6.6.1 Operation
  1291.  
  1292.      A core-based tree may involve a single router, or set of routers,
  1293.      which act as the core of a multicast delivery tree.  Figure 11 
  1294.      illustrates how multicast traffic is forwarded across a CBT 
  1295.  
  1296.  
  1297.  
  1298. Semeria & Maufer                                              [Page 23] 
  1299.  
  1300. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1301.  
  1302.      "backbone" to all members of the group.  Note that the CBT 
  1303.      backbone may contain both core and non-core routers.
  1304.  
  1305.  
  1306. ======================================================================
  1307.  
  1308.  
  1309.                Incoming multicast packet
  1310.                      for the group 
  1311.                     [Source Station]
  1312.                            N
  1313.                           v|
  1314.              N            v|
  1315.             ^|            v|       N
  1316.             ^|            v|      ^|
  1317.          < <^| < < < < <  v| > > >^| > >
  1318.        N- - -# * * * * * * N * * * # * * N
  1319.             v|                   v/ \v
  1320.             v|                  v/   \v
  1321.             v|                  N     \v
  1322.              N                         N
  1323.  
  1324.  
  1325. LEGEND
  1326.  
  1327. #   Core Router
  1328. N   Non Core Router
  1329. * * CBT Backbone   (> arrows indicate path direction of flow)
  1330. > > Multicast Packet Path (> arrows indicate path direction of flow)
  1331.  
  1332.  
  1333. Figure 11: Multi-core CBT Multicast Delivery Tree
  1334. ======================================================================
  1335.  
  1336.  
  1337.      Each station that wishes to receive traffic that has been 
  1338.      addressed to a multicast group is required to send a "join" 
  1339.      message towards the core tree of the particular multicast group.
  1340.      A potential group member only needs to know the address of one of
  1341.      the group's core routers in order to transmit a unicast join 
  1342.      request.  The join request is processed by all intermediate 
  1343.      routers which identify the interface on which the join was 
  1344.      received as belonging to the group's delivery tree.  The 
  1345.      intermediate routers continue to forward the join message towards 
  1346.      the core and marking local interfaces until the request reaches a 
  1347.      core router.  
  1348.  
  1349.      Similar to other multicast forwarding algorithms, CBT does not 
  1350.      require that the source of a multicast packet be a member of the 
  1351.      destination group.  Packets sourced by a non-group member are 
  1352.      simply unicast towards the core until they reach the first router 
  1353.  
  1354.  
  1355. Semeria & Maufer                                              [Page 24] 
  1356.  
  1357. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1358.  
  1359.      that is a member of the group's delivery tree.  When the unicast 
  1360.      packet reaches a member of the delivery tree, the packet is 
  1361.      multicast to all outgoing interfaces that are part of the tree 
  1362.      except the incoming link.  This guarantees that the multicast 
  1363.      packet is forwarded to all routers on the delivery tree.
  1364.  
  1365. 6.6.2 Benefits
  1366.  
  1367.      In terms of scalability, CBT has several advantages over the 
  1368.      Reverse Path Multicasting (RPM) algorithm.  CBT makes efficient 
  1369.      use of router resources since it only requires a router to 
  1370.      maintain state information for each group, not for each (source, 
  1371.      group) pair.  Also, CBT conserves network bandwidth since it does 
  1372.      not require that multicast frames be periodically forwarded to 
  1373.      all multicast routers in the internetwork.  
  1374.  
  1375. 6.6.3 Limitations
  1376.  
  1377.      Despite these benefits, there are still several limitations to 
  1378.      the CBT approach.  CBT may result in traffic concentration and 
  1379.      bottlenecks near core routers since traffic from all sources 
  1380.      traverses the same set of links as it approaches the core.  In 
  1381.      addition, a single shared delivery tree may create suboptimal 
  1382.      routes resulting in increased delay which is a critical issue for 
  1383.      some multimedia applications.  Finally, new algorithms still need 
  1384.      to be developed to support core management which encompasses all 
  1385.      aspects of core router selection and (potentially) dynamic 
  1386.      placement strategies.  
  1387.  
  1388. 7. DISTANCE VECTOR MULTICAST ROUTING PROTOCOL (DVMRP)
  1389.  
  1390.      The Distance Vector Multicast Routing Protocol (DVMRP) is a
  1391.      distance-vector routing protocol designed to support the 
  1392.      forwarding of multicast datagrams through an internetwork.  
  1393.      DVMRP constructs source-
  1394.      rooted multicast delivery trees using variants of the Reverse 
  1395.      Path Broadcasting (RPB) algorithm.  DVMRP is currently deployed 
  1396.      in the majority of MBONE routers.  
  1397.  
  1398.      DVMRP was first defined in RFC-1075.  The original specification 
  1399.      was derived from the Routing Information Protocol (RIP) and 
  1400.      employed the Truncated Reverse Path Broadcasting (TRPB) 
  1401.      algorithm.  The major difference between RIP and DVMRP is that 
  1402.      RIP is concerned with calculating the shortest path to a 
  1403.      destination while DVMRP is concerned with computing the shortest 
  1404.      path back to a source.  It is important to note that the latest 
  1405.      mrouted version 3.5 and vendor implementations have extended 
  1406.      DVMRP to employ the Reverse Path Multicasting (RPM) algorithm.  
  1407.      This means that the latest implementations of DVMRP are quite 
  1408.      different from the original RFC specification with respect to 
  1409.      packet format, tunnel format, and packet types.
  1410.  
  1411.  
  1412. Semeria & Maufer                                              [Page 25] 
  1413.  
  1414. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1415.  
  1416. 7.1 Physical and Tunnel Interfaces
  1417.  
  1418.      The ports of a DVMRP router may be either a physical interface to 
  1419.      a directly attached subnetwork or a tunnel interface to another 
  1420.      multicast island.  All interfaces are configured with a metric 
  1421.      that specifies the cost for the given port and a TTL threshold 
  1422.      that limits the scope of a multicast transmission.  In addition, 
  1423.      each tunnel interface must be explicitly configured with two 
  1424.      additional parameters - the IP address of the local router's 
  1425.      interface and the IP address of the remote router's interface.  
  1426.  
  1427.  
  1428. ======================================================================
  1429.  
  1430. Initial TTL                        Scope
  1431. ______________________________________________________________________
  1432. 0                                  Restricted to the same host
  1433. 1                                  Restricted to the same subnetwork 
  1434. 32                                 Restricted to the same site 
  1435. 64                                 Restricted to the same region 
  1436. 128                                Restricted to the same continent 
  1437. 255                                Unrestricted in scope 
  1438.  
  1439.  
  1440. Table 1:   TTL Scope Control Values
  1441. ======================================================================
  1442.  
  1443.      A multicast router will only forwarded a multicast datagram 
  1444.      across an interface if the TTL field in the IP header is greater 
  1445.      than the TTL threshold assigned to the interface.  Table 1 lists 
  1446.      the conventional TTL values that are used to restrict the scope 
  1447.      of an IP multicast.  For example, a multicast datagram with a TTL 
  1448.      of less than 32 is restricted to the same site and should not be 
  1449.      forwarded across an interface to other sites in the same region.  
  1450.  
  1451. 7.2 Basic Operation
  1452.  
  1453.      DVMRP implements the Reverse Path Multicasting (RPM) algorithm. 
  1454.      According to RPM, the first datagram for any (source, group) pair 
  1455.      is forwarded across the entire internetwork providing the 
  1456.      packet's TTL and router interface thresholds permit.  The initial 
  1457.      datagram is delivered to all leaf routers which transmit prune 
  1458.      messages back towards the source if there are no group members on 
  1459.      their directly attached leaf subnetworks.  The prune messages 
  1460.      result in the removal of branches from the tree that do not lead 
  1461.      to group members, thus creating a source-specific shortest path 
  1462.      tree with all leaves having group members.  After a period of 
  1463.      time, the pruned branches grow back and the next datagram for the 
  1464.      (source, group) pair is forwarded across the entire internetwork 
  1465.      resulting in a new set of prune messages.
  1466.  
  1467.  
  1468.  
  1469. Semeria & Maufer                                              [Page 26] 
  1470.  
  1471. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1472.  
  1473.      DVMRP implements a mechanism to quickly "graft" back a previously 
  1474.      pruned branch of a group's delivery tree.  If a router that 
  1475.      previously sent a prune message for a (source, group) pair 
  1476.      discovers new group members on a leaf network, it sends a graft 
  1477.      message to the group's previous-hop router.  When an upstream 
  1478.      router receives a graft message, it cancels out the previously-
  1479.      received prune message.  Graft messages may cascade back towards 
  1480.      the source allowing previously pruned branches to be restored as 
  1481.      part of the multicast delivery tree. 
  1482.  
  1483. 7.3 DVMRP Router Functions
  1484.  
  1485.      When there is more than one DVMRP router on a subnetwork, the 
  1486.      Dominant Router is responsible for the periodic transmission of 
  1487.      IGMP Host Membership Query messages.  Upon initialization, a 
  1488.      DVMRP router considers itself to be the Dominant Router for the 
  1489.      subnetwork until it receives a Host Membership Query message from 
  1490.      a neighbor router with a lower IP address.  Figure 12 illustrates 
  1491.      how the router with the lowest IP address functions as the 
  1492.      Designated Router for the subnetwork .  
  1493.  
  1494.  
  1495. ======================================================================
  1496.  
  1497.  
  1498.         _____________                               _____________
  1499.        | Router A    |                       DR    | Router B    |
  1500.        |             |                             |             |
  1501.         -------------                               -------------
  1502.    128.2.3.4  |                                  <-Query  |  128.2.1.1
  1503.               |                                           |
  1504.  ---------------------------------------------------------------------
  1505.                                        | 
  1506.                           128.2.3.1    | 
  1507.                                  _____________  
  1508.                                 | Router C    |
  1509.                                 |             |
  1510.                                  ------------- 
  1511.  
  1512.  
  1513. Figure 12. DVMRP Dominant Router
  1514. ======================================================================
  1515.  
  1516.      In order to avoid duplicate multicast datagrams when there is 
  1517.      more than one DVMRP router on a subnetwork, one router is elected 
  1518.      the Dominant Router for the particular source subnetwork.  In 
  1519.      Figure 13, Router C is downstream and may potentially receive 
  1520.      datagrams from the source subnetwork from Router A or Router B.  
  1521.      If Router A's metric to the source subnetwork is less than Router 
  1522.      B's metric, Router A is dominant to Router B.  This means that 
  1523.      Router A forwards traffic from the source subnetwork and Router B 
  1524.  
  1525.  
  1526. Semeria & Maufer                                              [Page 27] 
  1527.  
  1528. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1529.  
  1530.      discards traffic from the source subnetwork.  However, if Router 
  1531.      A's metric is equal to Router B's metric, the router with the 
  1532.      lowest IP address on its downstream interface (child link) 
  1533.      becomes the Dominant Router.  
  1534.  
  1535.  
  1536. ======================================================================
  1537.  
  1538.  
  1539.                                    To
  1540.                -<-<-<-<-<-<-Source Subnetwork->->->->->->->->--
  1541.               v                                                v
  1542.               |                                                |
  1543.           parent link                                      parent link
  1544.               |                                                |
  1545.         _____________                                    _____________
  1546.        | Router A    |                                  | Router B    |
  1547.        |             |                                  |             |
  1548.         -------------                                    -------------
  1549.               |                                                |
  1550.          child link                                       child link
  1551.               |                                                |
  1552.  ---------------------------------------------------------------------
  1553.                                        | 
  1554.                                   parent link
  1555.                                        | 
  1556.                                  _____________ 
  1557.                                 | Router C    |
  1558.                                 |             |
  1559.                                  ------------- 
  1560.                                        | 
  1561.                                   child link
  1562.                                        | 
  1563.   
  1564. Figure 13. DVMRP Dominant Router
  1565. ======================================================================
  1566.  
  1567. 7.4 DVMRP Routing Table
  1568.  
  1569.      Since the DVMRP was developed to route multicast and not unicast 
  1570.      traffic, a router may be required to run multiple routing 
  1571.      processes - one for the delivery of unicast traffic and another 
  1572.      for the delivery of multicast traffic.  The DVMRP process 
  1573.      periodically exchanges routing table update messages with 
  1574.      multicast-capable neighbors.  These updates are independent of 
  1575.      those generated by any Interior Gateway Protocol which provides 
  1576.      support for unicast routing.  
  1577.  
  1578.      DVMRP relies on the receipt of "poison reverse" updates for leaf 
  1579.      router detection.  This technique requires that a downstream 
  1580.      neighbor advertise "infinity" for a source subnetwork to the 
  1581.  
  1582.  
  1583. Semeria & Maufer                                              [Page 28] 
  1584.  
  1585. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1586.  
  1587.      previous hop router on its shortest-path back to that source 
  1588.      subnetwork.  If an upstream router does not receive a "poison 
  1589.      reverse" update for the source subnetwork on a downstream 
  1590.      interface, the upstream router assumes that the downstream 
  1591.      subnetwork is a leaf and removes the downstream port from its 
  1592.      list of forwarding ports. 
  1593.  
  1594.      A sample routing table for a DVMRP router is shown in Figure 14.  
  1595.      Unlike the typical table created by a unicast routing protocol 
  1596.      such as RIP, the DVMRP routing table contains Source Subnets and 
  1597.      From-Gateways instead of Destinations and Next-Hop Gateways.  The 
  1598.      routing table represents the shortest path source-rooted spanning 
  1599.      tree to every participating subnetwork in the internetwork - the 
  1600.      Reverse Path Broadcasting (RPB) tree.  The DVMRP routing table 
  1601.      does not consider group membership or received prune messages.  
  1602.  
  1603.  
  1604. ======================================================================
  1605.  
  1606. Source      Subnet     From        Metric Status TTL
  1607.  Subnet      Mask       Gateway
  1608.  
  1609.  
  1610. 128.1.0.0  255.255.0.0  128.7.5.2    3      Up   200
  1611. 128.2.0.0  255.255.0.0  128.7.5.2    5      Up   150
  1612. 128.3.0.0  255.255.0.0  128.6.3.1    2      Up   150
  1613. 128.3.0.0  255.255.0.0  128.6.3.1    4      Up   200
  1614.  
  1615.  
  1616. Figure 14: DVMRP Routing Table
  1617. ======================================================================
  1618.  
  1619. The key elements in DVMRP routing table include the following items:
  1620.  
  1621. Source Subnet          A subnetwork containing a host sourcing 
  1622.                        multicast datagrams
  1623.  
  1624. Subnet Mask            The subnet mask assigned to the Source Subnet.
  1625.                        Note that the DVMRP provides the subnet mask 
  1626.                        for each source subnetwork.
  1627.  
  1628. From-Gateway           The previous hop router leading back to the 
  1629.                        Source Subnet.  
  1630.  
  1631. TTL                    The time-to-live is used for table management 
  1632.                        and indicates the number of seconds before an 
  1633.                        entry is removed from the routing table.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640. Semeria & Maufer                                              [Page 29] 
  1641.  
  1642. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1643.  
  1644. 7.5 DVMRP Forwarding Table
  1645.  
  1646.      Since the DVMRP routing table is not aware of group membership, 
  1647.      the DVMRP process builds a forwarding table based on a 
  1648.      combination of the information contained in the multicast routing 
  1649.      table, known groups, and received prune messages.  The forwarding 
  1650.      table represents the local router's understanding of the shortest 
  1651.      path source-rooted delivery tree for each (source, group) pair - 
  1652.      the Reverse Path Multicasting (RPM) tree.  
  1653.  
  1654.  
  1655. ======================================================================
  1656.  
  1657. Source      Multicast   TTL  InPort  OutPorts
  1658.  Subnet      Group 
  1659.  
  1660.  
  1661.  128.1.0.0  224.1.1.1   200  1 Pr     2p3p
  1662.             224.2.2.2   100  1        2p3
  1663.             224.3.3.3   250  1        2
  1664.  128.2.0.0  224.1.1.1   150  2        2p3
  1665.  
  1666.  
  1667. Figure 15: DVMRP Forwarding Table
  1668. ======================================================================
  1669.  
  1670.      The forwarding table for a typical DVMRP router is shown in 
  1671.      Figure 15. The elements in this display include the following 
  1672.      items:
  1673.  
  1674. Source Subnet           The subnetwork containing a host sourcing 
  1675.                         multicast datagrams addressed to the 
  1676.                         specified groups
  1677.  
  1678. Multicast Group         The Class D IP address to which multicast 
  1679.                         datagrams are addressed. Note that a given Source 
  1680.                         Subnet may contain sources for many different 
  1681.                         Multicast Groups.  
  1682.  
  1683. InPort                  The parent port for the (source, group) pair.  
  1684.                         A 'Pr' in this column indicates that a prune 
  1685.                         message has been sent to the upstream router.
  1686.  
  1687. OutPorts                The child ports over which multicast datagrams 
  1688.                         for the (source, group) pair are forwarded.  
  1689.                         A lower case 'p' in this column indicates 
  1690.                         that the router has received a prune message 
  1691.                         from a downstream router.  
  1692.  
  1693.  
  1694.  
  1695.  
  1696. Semeria & Maufer                                              [Page 30] 
  1697.  
  1698. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1699.  
  1700. 7.6 Hierarchical DVMRP
  1701.  
  1702.      The rapid growth of the MBONE is beginning to place increasing 
  1703.      demands on its routers.  The current version of the DVMRP treats 
  1704.      the MBONE as a single, "flat" routing domain where each router is 
  1705.      required to maintain detailed routing information to every 
  1706.      subnetwork on the MBONE.  As the number of subnetworks continues 
  1707.      to increase, the size of the routing tables and of the periodic 
  1708.      update messages will continue to grow.  If nothing is done about 
  1709.      these issues, the processing and memory capabilities of the MBONE 
  1710.      routers will eventually be depleted and routing on the MBONE will 
  1711.      fail.
  1712.  
  1713. 7.6.1 Benefits of Hierarchical Multicast Routing
  1714.  
  1715.      To overcome these potential threats, a hierarchical version of 
  1716.      the DVMRP is under development.  In hierarchical routing, the 
  1717.      MBONE is divided into a number of individual routing domains.  
  1718.      Each routing domain executes its own instance of a multicast 
  1719.      routing protocol.  Another protocol, or another instance of the 
  1720.      same protocol, is used for routing between the individual 
  1721.      domains.  Hierarchical routing reduces the demand for router 
  1722.      resources because each router only needs to know the explicit
  1723.      details about routing packets to destinations within its own
  1724.      domain, but knows nothing about the detailed topological structure 
  1725.      of any of the other domains.  The protocol running between the 
  1726.      individual domains maintains information about the interconnection 
  1727.      of the domains, but not about the internal topology of each
  1728.      domain.  
  1729.  
  1730. ======================================================================
  1731.                                                       _________
  1732.                       ________       _________       /         \
  1733.                      /        \     /         \     | Region D  |
  1734.      ___________     |Region B|-L2-|           |-L2-\___________/
  1735.     /           \-L2-\________/    |           |      ___________
  1736.    |             |     |    |      |           |     /           \
  1737.    | Region A    |    L2   L2      | Region C  |-L2-| Region E    |
  1738.    |             |     |    |      |           |    |             |
  1739.     \___________/     ________     |           |    \_____________/
  1740.                      /        \-L2-|           |                 
  1741.                      |Region F|    \___________/
  1742.                      \________/
  1743.  
  1744.      In addition to reducing the amount of routing information, there 
  1745.      are several other benefits gained from the development of a 
  1746.      hierarchical version of the DVMRP.
  1747.  
  1748.  
  1749. Figure 16. Hierarchical DVMRP
  1750. ======================================================================
  1751.  
  1752.  
  1753. Semeria & Maufer                                              [Page 31] 
  1754.  
  1755. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1756.  
  1757.      - Different multicast routing protocols may be deployed in each 
  1758.      region of the MBONE.  This permits the testing and deployment of 
  1759.      new protocols on a domain-by-domain basis.  
  1760.  
  1761.      - The effects of an individual link or router failures are 
  1762.      limited to only those routers operating within a single domain.
  1763.      Likewise, the effects of any change to the topological 
  1764.      interconnection of regions is limited to only inter-domain 
  1765.      routers.  These enhancements are especially important when 
  1766.      deploying a distance-vector routing protocol which can result in
  1767.      relatively long convergence times.  
  1768.  
  1769.      - The count-to-infinity problem associated with distance-vector 
  1770.      routing protocols places limitations on the maximum diameter of 
  1771.      the MBONE topology.  Hierarchical routing limits these diameter 
  1772.      constraints to a single domain, not to the MBONE as a whole.
  1773.  
  1774. 7.6.2 Hierarchical Architecture
  1775.  
  1776.      Hierarchical DVMRP proposes the creation of non-intersecting 
  1777.      regions where each region has a unique Region-Id.  The routers 
  1778.      internal to a region execute any multicast 
  1779.      routing protocols such as DVMRP, MOSPF, PIM, or CBT as a "Level 1"
  1780.      (L1) protocol.  Each region is required to have at least one 
  1781.      "boundary router" which is responsible for providing inter-region 
  1782.      connectivity.  The boundary routers execute DVMRP as a "Level 2" 
  1783.      (L2) protocol to forward traffic between regions.  
  1784.  
  1785.      The L2 routers exchange routing information in the form of 
  1786.      Region-Ids instead of the individual subnetwork addresses 
  1787.      contained within each region.  With DVMRP as the L2 protocol, 
  1788.      inter-regional multicast delivery tree is constructed based on 
  1789.      the (region_ID, group) pair rather than the standard (source, 
  1790.      group) pair.  
  1791.  
  1792.      When a multicast packet originates within a region, it is 
  1793.      forwarded according to the L1 protocol to all subnetworks 
  1794.      containing group members.  In addition, the datagram is forwarded 
  1795.      to each of the boundary routers (L2) configured for the source 
  1796.      region.  The L2 routers tag the packet with the Region-Id and 
  1797.      placed it in an encapsulation header for delivery to other 
  1798.      regions.  When the packet arrives at a remote region, the 
  1799.      encapsulation header is removed before delivery to group members 
  1800.      by the L1 routers.  
  1801.  
  1802. 8. MULTICAST EXTENSIONS TO OSPF (MOSPF)
  1803.  
  1804.      Version 2 of the Open Shortest Path First (OSPF) routing protocol 
  1805.      is defined in RFC-1583.  It is an Interior Gateway Protocol (IGP) 
  1806.      specifically designed to distribute unicast topology information 
  1807.      among routers belonging to a single Autonomous System.  OSPF is 
  1808.  
  1809.  
  1810. Semeria & Maufer                                              [Page 32] 
  1811.  
  1812. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1813.  
  1814.      based on link-state algorithms which permit rapid route 
  1815.      calculation with a minimum of routing protocol traffic.  In
  1816.       addition to efficient oute calculation, OSPF is an open standard 
  1817.      that supports hierarchical routing, load balancing, and the import 
  1818.      of external routing information.  
  1819.  
  1820.      The Multicast Extensions to OSPF (MOSPF) are defined in RFC-1584.  
  1821.      MOSPF routers maintain a current image of the network topology 
  1822.      through the unicast OSPF link-state routing protocol.  MOSPF 
  1823.      enhances the OSPF protocol by providing the ability to route 
  1824.      multicast IP traffic.  The multicast extensions to OSPF are built 
  1825.      on top of OSPF Version 2 so that a multicast routing capability 
  1826.      can be easily introduced into an OSPF Version 2 routing domain.  
  1827.      The enhancements that have been added are backwards compatible so 
  1828.      that routers running MOSPF will interoperate with non-multicast 
  1829.      OSPF routers when forwarding unicast IP data traffic.  
  1830.  
  1831.      MOSPF, unlike DVMRP, does not provide support for tunnels.
  1832.  
  1833. 8.1 Intra-Area Routing with MOSPF
  1834.  
  1835.      Intra-Area Routing describes the basic routing algorithm employed 
  1836.      by MOSPF.  This elementary algorithm runs inside a single OSPF 
  1837.      area and supports multicast forwarding when the source and all 
  1838.      destination group members reside in the same OSPF area, or when 
  1839.      the entire Autonomous System is a single OSPF area.  The 
  1840.      following discussion assumes that the reader is familiar with the 
  1841.      basic operation of the OSPF routing protocol.
  1842.  
  1843. 8.1.1 Local Group Database
  1844.  
  1845.      Similar to DVMRP, MOSPF routers use the Internet Group Management 
  1846.      Protocol (IGMP) to monitor multicast group membership on directly 
  1847.      attached subnetworks.  MOSPF routers are required to implement a 
  1848.      "local group database" which maintains a list of directly 
  1849.      attached group members and determines the local router's 
  1850.      responsibility for delivering multicast datagrams to these group 
  1851.      members.  
  1852.  
  1853.      On any given subnetwork, the transmission of IGMP Host Membership 
  1854.      Queries is performed solely by the Designated Router (DR).  Also, 
  1855.      the responsibility of listening to IGMP Host Membership Reports 
  1856.      is performed only by the Designated Router (DR) and the Backup 
  1857.      Designated Router (BDR).  This means that in a mixed environment 
  1858.      containing both MOSPF and OSPF routers, an MOSPF router must be 
  1859.      elected the DR for the subnetwork if IGMP Queries are to be 
  1860.      generated.  This can be achieved by simply assigning all non-MOSPF 
  1861.      routers a RouterPriority of 0 to prevent them from becoming the 
  1862.      DR or BDR, thus allowing an MOSPF router to become the DR for the 
  1863.      subnetwork.  
  1864.  
  1865.  
  1866.  
  1867. Semeria & Maufer                                              [Page 33] 
  1868.  
  1869. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1870.  
  1871.      The DR is responsible for communicating group membership 
  1872.      information to all other routers in the OSPF area by flooding 
  1873.      Group-Membership LSAs.  The DR originates a separate Group-
  1874.      Membership LSA for each multicast group having one or more 
  1875.      entries in the DR's local group database.  Similar to Router-LSAs 
  1876.      and Network-LSAs, Group Membership-LSAs are flooded throughout a 
  1877.      single area only.  This ensures that all remotely-originated 
  1878.      multicast datagrams are forwarded to the specified subnetwork for 
  1879.      distribution to local group members.  
  1880.  
  1881. 8.1.2 Datagram's Shortest Path Tree
  1882.  
  1883.      The datagram's shortest path tree describes the path taken by a 
  1884.      multicast datagram as it travels through the internetwork from the 
  1885.      source subnetwork to each of the individual group members.  The 
  1886.      shortest path tree for each (source, group) pair is built "on 
  1887.      demand" when a router receives the first multicast datagram for a 
  1888.      particular (source, group) pair.  
  1889.  
  1890.      When the initial datagram arrives, the source subnetwork is 
  1891.      located in the MOSPF link state database.  The MOSPF link state 
  1892.      database is simply the standard OSPF link state database with the 
  1893.      addition of Group-Membership LSAs.  Based on the Router-LSAs and 
  1894.      Network-LSAs in the MOSPF link state database, a source-rooted 
  1895.      shortest-path tree is constructed using Dijkstra's algorithm.  
  1896.      After the tree is built, Group-Membership LSAs are used to prune 
  1897.      those branches that do not lead to subnetworks containing 
  1898.      individual group members.  The result of the Dijkstra calculation 
  1899.      is a pruned shortest-path tree rooted at the datagram's source.
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924. Semeria & Maufer                                              [Page 34] 
  1925.  
  1926. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1927.  
  1928. ======================================================================
  1929.  
  1930.  
  1931.                       S
  1932.                       |
  1933.                       |
  1934.                    A  #
  1935.                      / \
  1936.                     /   \
  1937.                    1     2
  1938.                   /       \
  1939.                B #         # C
  1940.                 / \         \
  1941.                /   \         \
  1942.               3     4         5
  1943.              /       \         \  
  1944.           D #         # E       # F
  1945.                      / \         \
  1946.                     /   \         \
  1947.                    6     7         8
  1948.                   /       \         \
  1949.                G #         # H       # I
  1950.  
  1951.  
  1952. LEGEND
  1953.  
  1954.  #   Router           
  1955.  
  1956.  
  1957. Figure 17. Shortest Path Tree for (S, G)
  1958. ======================================================================
  1959.  
  1960.      To forward a multicast datagram to downstream members of the 
  1961.      group, each router must determine its position in the datagram's 
  1962.      shortest path delivery tree.  Assume that Figure 17 illustrates 
  1963.      the shortest path tree for a particular (source, group) pair.  
  1964.      Router E's upstream node is Router B and there are two downstream 
  1965.      interfaces: one connecting to Subnetwork 6 and another connecting 
  1966.      to Subnetwork 7.  
  1967.  
  1968.      Note the following properties of the basic MOSPF routing 
  1969.      algorithm:
  1970.  
  1971.      - For a given multicast datagram, all routers within an OSPF area 
  1972.      calculate the same source-rooted shortest path delivery tree.  
  1973.      Tie-breakers have been defined to guarantee that if several equal- 
  1974.      cost paths exist, all routers agree on a single path through the 
  1975.      area.  Unlike unicast OSPF, MOSPF does not support the concept of 
  1976.      equal-cost multipath routing.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981. Semeria & Maufer                                              [Page 35] 
  1982.  
  1983. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  1984.  
  1985.      - Synchronized link state databases containing Group-Membership 
  1986.      LSAs allow an MOSPF router to perform the Reverse Path 
  1987.      Multicasting (RPM) computation "in memory."   Unlike DVMRP, this
  1988.      means that the first datagram of a group transmission does not 
  1989.      have to be forwarded to all routers in the area.
  1990.  
  1991.      - The "on demand" construction of the shortest-path delivery tree 
  1992.      has the benefit of spreading calculations over time, resulting in 
  1993.      a lesser impact for participating routers.  
  1994.  
  1995. 8.1.3 Forwarding Cache
  1996.  
  1997.      Each MOSPF router makes its forwarding decision based on the 
  1998.      contents of its forwarding cache.  The forwarding cache is built 
  1999.      from the source-rooted shortest-path tree for each (source, 
  2000.      group) pair and the router's local group database.  After the 
  2001.      router discovers its position in the shortest path tree, a 
  2002.      forwarding cache entry is created containing the (source, group) 
  2003.      pair, the upstream node, and the downstream interfaces.  At this 
  2004.      point, the Dijkstra shortest path tree is discarded releasing all 
  2005.      resources associated with the creation of the tree.  From this 
  2006.      point on, the forwarding cache entry is used to forward all 
  2007.      subsequent datagrams for the (source, group) pair.  
  2008.  
  2009. ======================================================================
  2010.  
  2011. Destination   Source     Upstream   Downstream   TTL
  2012.  
  2013.  
  2014.  
  2015. 224.1.1.1     128.1.0.2    11        12   13      5
  2016. 224.1.1.1     128.4.1.2    11        12   13      2
  2017. 224.1.1.1     128.5.2.2    11        12   13      3
  2018. 224.2.2.2     128.2.0.3    12        11           7
  2019.  
  2020.  
  2021. Figure 18: MOSPF Forwarding Cache
  2022. ======================================================================
  2023.  
  2024.      Figure 18 displays the forwarding cache for a typical MOSPF 
  2025.      router.  The elements in the display include the following items:
  2026.  
  2027. Destination            The destination group address to which matching 
  2028.                        datagrams are forwarded.  
  2029.  
  2030. Source                 The datagram's source subnetwork. Each 
  2031.                        Destination/Source pair identifies a separate 
  2032.                        forwarding cache entry.
  2033.  
  2034. Upstream               The interface from which a matching datagram 
  2035.                        must be received
  2036.  
  2037.  
  2038. Semeria & Maufer                                              [Page 36] 
  2039.  
  2040. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2041.  
  2042. Downstream             The interfaces over which a matching datagram 
  2043.                        should be forwarded to reach Destination group
  2044.                        members
  2045.  
  2046. TTL                    The minimum number of hops a datagram will 
  2047.                        travel to reach the multicast group members.
  2048.                        This allows the router to discard datagrams 
  2049.                        that do not have a chance of reaching a 
  2050.                        destination group member.  
  2051.  
  2052.      The information in the forwarding cache is not aged or 
  2053.      periodically refreshed.  It is maintained as long as there are 
  2054.      system resources available (i.e., memory) or until the next 
  2055.      topology change.  In general, the contents of the forwarding 
  2056.      cache will change when: 
  2057.  
  2058.      - The topology of the OSPF internetwork changes forcing all of the 
  2059.      datagram shortest-path trees to be recalculated.
  2060.  
  2061.       - There is a change in the Group-Membership LSAs indicating that 
  2062.      the distribution of individual group members has changed. 
  2063.  
  2064. 8.2 Mixing MOSPF and OSPF Routers
  2065.  
  2066.      MOSPF routers can be combined with non-multicast OSPF routers.  
  2067.      This permits the gradual deployment of MOSPF and allows 
  2068.      experimentation with multicast routing on a limited scale.  When 
  2069.      MOSPF and non-multicast OSPF routers are mixed within an 
  2070.      Autonomous System, all routers will interoperate in the 
  2071.      forwarding of unicast datagrams.  
  2072.  
  2073.      It is important to note that an MOSPF router is required to 
  2074.      eliminate all non-multicast OSPF routers when it builds its 
  2075.      source-rooted shortest-path delivery tree.  An MOSPF router can 
  2076.      easily determine the multicast capability of any other router 
  2077.      based on the setting of the multicast bit (MC-bit) in the Options 
  2078.      field of each router's link state advertisements.  The omission 
  2079.      of non-multicast routers can create a number of potential 
  2080.      problems when forwarding multicast traffic:
  2081.  
  2082.      - Multicast datagrams may be forwarded along suboptimal routes 
  2083.      since the shortest path between two points may require traversal 
  2084.      of a non-multicast OSPF router.
  2085.  
  2086.      - Even though there is unicast connectivity to a destination, 
  2087.      there may not be multicast connectivity.  For example, the 
  2088.      network may partition with respect to multicast connectivity 
  2089.      since the only path between two points requires traversal of a 
  2090.      non-multicast OSPF router.
  2091.  
  2092.      - The forwarding of multicast and unicast datagrams between two 
  2093.  
  2094.  
  2095. Semeria & Maufer                                              [Page 37] 
  2096.  
  2097. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2098.  
  2099.      points may follow entirely different paths through the 
  2100.      internetwork.  This may make routing problems somewhat more
  2101.      difficult to debug.  
  2102.  
  2103.      - The Designated Router for a multi-access network must be an 
  2104.      MOSPF router.  If a non-multicast OSPF router is elected the DR, 
  2105.      the subnetwork will not be selected to forward multicast 
  2106.      datagrams since a non-multicast DR cannot generate Group-
  2107.      Membership LSAs for its subnetwork.
  2108.  
  2109. 8.3 Inter-Area Routing with MOSPF
  2110.  
  2111.      Inter-area routing involves the case where a datagram's source 
  2112.      and some of its destination group members reside in different 
  2113.      OSPF areas.  It should be noted that the forwarding of multicast 
  2114.      datagrams continues to be determined by the contents of the 
  2115.      forwarding cache which is still built from the local group 
  2116.      database and the datagram shortest-path trees.  The major 
  2117.      differences are related to the way that group membership 
  2118.      information is propagated and the way that the inter-area 
  2119.      shortest-path tree is constructed. 
  2120.  
  2121. 8.3.1 Inter-Area Multicast Forwarders
  2122.  
  2123.      In MOSPF, a subset of an area's Area Border Routers (ABRs)
  2124.      function as "inter-area multicast forwarders."  An inter-area 
  2125.      multicast forwarder is responsible for the forwarding of group 
  2126.      membership information and multicast datagrams between areas.  
  2127.      Configuration parameters determine whether or not a particular 
  2128.      ABR also functions as an inter-area multicast forwarder.  
  2129.  
  2130.  
  2131.      Inter-area multicast forwarders summarize their attached areas' 
  2132.      group membership information to the backbone by originating new 
  2133.      Group-Membership LSAs into the backbone area.  It is important to 
  2134.      note that the summarization of group membership in MOSPF is 
  2135.      asymmetric.  This means that group membership information from 
  2136.      non-backbone areas is flooded into the backbone.  However, the 
  2137.      backbone does not readvertise either backbone group membership 
  2138.      information or group membership information learned from other
  2139.      non-backbone areas into any non-backbone areas.  
  2140.  
  2141.  
  2142.  
  2143.  
  2144.  
  2145.  
  2146.  
  2147.  
  2148.  
  2149.  
  2150.  
  2151.  
  2152. Semeria & Maufer                                              [Page 38] 
  2153.  
  2154. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2155.  
  2156. ======================================================================
  2157.  
  2158.  
  2159.  -------------------------
  2160. /      Backbone Area      \
  2161. |                         |
  2162. |      ^           ^      |
  2163. |   ___|___     ___|___   |
  2164. \__|       |___|       |__/
  2165.    |---*---|   |---*---|
  2166.    / Area 1\   / Area 2\
  2167.    |       |   |       |
  2168.    |       |   |       |
  2169.    |-------|   |-------|
  2170.    
  2171.  
  2172.  
  2173. LEGEND
  2174.  
  2175.    ^
  2176.    |    Group Membership LSAs
  2177.  _____
  2178. |_____| Area Border Routher and
  2179.         Inter-Area Multicast Forwarder
  2180.  
  2181. *       Wild-Card Multicast
  2182.         Receiver Interface
  2183.  
  2184.  
  2185. Figure 19. Inter-Area Routing Architecture
  2186. ======================================================================
  2187.  
  2188.      To permit the forwarding of multicast traffic between areas, 
  2189.      MOSPF introduces the concept of a "wild-card multicast receiver."
  2190.      A wild-card multicast receiver is a router that receives all 
  2191.      multicast traffic generated in an area, regardless of the 
  2192.      multicast group membership.  In non-backbone areas, all inter-
  2193.      area multicast forwarders operate as wild-card multicast 
  2194.      receivers.  This guarantees that all multicast traffic 
  2195.      originating in a non-backbone area is delivered to its inter-area 
  2196.      multicast forwarder, and then if necessary into the backbone 
  2197.      area.  Since the backbone has group membership knowledge for all 
  2198.      areas, the datagram can then be forwarded to group members 
  2199.      residing in the backbone and other non-backbone areas.  The      
  2200.      backbone area does not require wild-card multicast receivers 
  2201.      because the routers in the backbone area have complete knowledge 
  2202.      of group membership information for the entire OSPF system.  
  2203.  
  2204. 8.3.2 Inter-Area Datagram Shortest-Path Tree
  2205.  
  2206.      In the case of inter-area multicast routing, it is often 
  2207.  
  2208.  
  2209. Semeria & Maufer                                              [Page 39] 
  2210.  
  2211. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2212.  
  2213.      impossible to build a complete datagram shortest-path delivery 
  2214.      tree.  Incomplete trees are created because detailed topological 
  2215.      and group membership information for each OSPF area is not 
  2216.      distributed to other OSPF areas.  To overcome these limitations, 
  2217.      topological estimates are made through the use of wild-card 
  2218.      receivers and OSPF Summary-Links LSAs.  
  2219.  
  2220.      There are two cases that need to be considered when constructing 
  2221.      an inter-area shortest-path delivery tree.  The first involves 
  2222.      the condition when the source subnetwork is located in the same 
  2223.      area as the router performing the calculation.  The second 
  2224.      situation occurs when the source subnetwork is located in a 
  2225.      different area than the router performing the calculation.
  2226.  
  2227.      If the source of a multicast datagram resides in the same area as 
  2228.      the router performing the calculation, the pruning process must 
  2229.      be careful to ensure that branches leading to other areas are not 
  2230.      removed from the tree.  Only those branches having no group 
  2231.      members nor wild-card multicast receivers are pruned.  Branches 
  2232.      containing wild-card multicast receivers must be retained since 
  2233.      the local routers do not know if there are group members residing 
  2234.      in other areas.
  2235.  
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250.  
  2251.  
  2252.  
  2253.  
  2254.  
  2255.  
  2256.  
  2257.  
  2258.  
  2259.  
  2260.  
  2261.  
  2262.  
  2263.  
  2264.  
  2265.  
  2266. Semeria & Maufer                                              [Page 40] 
  2267.  
  2268. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2269.  
  2270. ======================================================================
  2271.  ----------------------------------
  2272. |              S                   |
  2273. |              |     Area 1        |
  2274. |              |                   |
  2275. |              #                   |
  2276. |             / \                  |
  2277. |            /   \                 |
  2278. |           /     \                |
  2279. |          /       \               |
  2280. |       O-#         #-O            |
  2281. |        / \         \             |
  2282. |       /   \         \            |
  2283. |      /     \         \           |
  2284. |     /       \         \          |
  2285. |  O-#         #         #-O       |
  2286. |             / \         \        |
  2287. |            /   \         \       |
  2288. |           /     \         \      |
  2289. |          /       \         \     |
  2290. |       O-#         #-O       ---  |
  2291.  ----------------------------| ? |- 
  2292.                               ---  
  2293.                                To Backbone
  2294.  
  2295.  
  2296. LEGEND
  2297.  
  2298. S   Source Subnetwork
  2299. O   Subnet Containing Group Members
  2300. #   Intra-Area MOSPF Router
  2301. ?   WildCard Multicast Receiver
  2302.  
  2303. Figure 20. Datagram Shortest Path Tree -Source in Same Area
  2304. ======================================================================
  2305.  
  2306.      If the source of a multicast datagram resides in a different area 
  2307.      than the router performing the calculation, the details 
  2308.      describing the local topology surrounding the source station are 
  2309.      not known.  However, this information can be estimated using 
  2310.      information provided by Summary Links LSAs for the source 
  2311.      subnetwork.  In this case, the base of the tree begins with 
  2312.      branches directly connecting the source subnetwork to each of the 
  2313.      local area's inter-area multicast forwarders.  The inter-area 
  2314.      multicast forwarders must be included in the tree since any 
  2315.      multicast datagrams originating outside the local area will enter 
  2316.      the area via an inter-area multicast forwarder.  
  2317.  
  2318.  
  2319.  
  2320.  
  2321.  
  2322.  
  2323. Semeria & Maufer                                              [Page 41] 
  2324.  
  2325. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2326. ======================================================================
  2327.  
  2328.                S
  2329.                |
  2330.                #
  2331.                |
  2332.        Summary-Links LSA
  2333.                |
  2334.               ---
  2335.  ------------| ? |-----------------
  2336. |             ---    Area 1        |
  2337. |              |                   |
  2338. |              #                   |
  2339. |             / \                  |
  2340. |            /   \                 |
  2341. |           /     \                |
  2342. |          /       \               |
  2343. |       O-#         #-O            |
  2344. |        / \         \             |
  2345. |       /   \         \            |
  2346. |      /     \         \           |
  2347. |     /       \         \          |
  2348. |  O-#         #         #-O       |
  2349. |             / \         \        |
  2350. |            /   \         \       |
  2351. |           /     \         \      |
  2352. |          /       \         \     |
  2353. |       O-#         #-O       #-O  |
  2354.  ---------------------------------- 
  2355.  
  2356.  
  2357. LEGEND
  2358.  
  2359. S   Source Subnetwork
  2360. O   Subnet Containing Group Members
  2361. #   Interarea MOSPF Router
  2362. ?   Intra-Area Multicast Forwarder
  2363.  
  2364. Figure 21. Shortest Path Tree -Source in Different Area
  2365. ======================================================================
  2366.  
  2367.      Since each inter-area multicast forwarder is also an ABR, it must 
  2368.      maintain a separate link state database for each attached area.  
  2369.      This means that each inter-area multicast forwarder is required 
  2370.      to calculate a separate forwarding tree for each of its attached 
  2371.      areas.  After the individual trees are calculated, they are 
  2372.      merged into a single forwarding cache entry for the (source, 
  2373.      group) pair and then the individual trees are discarded.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380. Semeria & Maufer                                              [Page 42] 
  2381.  
  2382. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2383.  
  2384. 8.4 Inter-Autonomous System Multicasting with MOSPF
  2385.  
  2386.      Inter-Autonomous System Multicasting involves the situation where 
  2387.      a datagram's source and at least some of its destination group 
  2388.      members reside in different Autonomous Systems.  It should be 
  2389.      emphasized that in OSPF terminology "inter-AS" communication also 
  2390.      refers to connectivity between an OSPF domain and another routing 
  2391.      domain which could be within the same Autonomous System.
  2392.  
  2393.      To facilitate inter-AS multicast routing, selected Autonomous 
  2394.      System Boundary Routers (ASBRs) are configured as "inter-AS 
  2395.      multicast forwarders."  MOSPF makes the assumption that each 
  2396.      inter-AS multicast forwarder executes an inter-AS multicast 
  2397.      routing protocol (such as DVMRP) which forwards multicast 
  2398.      datagrams in a reverse path forwarding (RPF) manner.  Each inter-
  2399.      AS multicast forwarder functions as a wild-card multicast 
  2400.      receiver in each of its attached areas.  This guarantees that 
  2401.      each inter-AS multicast forwarder remains on all pruned shortest-
  2402.      path trees and receives all multicast datagrams, regardless of 
  2403.      the multicast group membership.  
  2404.  
  2405.      Three cases need to be considered when describing the 
  2406.      construction of an inter-AS shortest-path delivery tree.  The 
  2407.      first occurs when the source subnetwork is located in the same 
  2408.      area as the router performing the calculation.  For the second 
  2409.      case, the source subnetwork resides in a different area than the 
  2410.      router performing the calculation.  The final case occurs when 
  2411.      the source subnetwork is located in a different AS (or in another 
  2412.      routing domain within the same AS) than the router performing the 
  2413.      calculation.
  2414.  
  2415.      The first two cases are similar to the inter-area examples 
  2416.      described in the previous section.  The only enhancement is that 
  2417.      inter-AS multicast forwarders must also be included on the pruned 
  2418.      shortest path delivery tree.  Branches containing inter-AS 
  2419.      multicast forwarders must be retained since the local routers do 
  2420.      not know if there are group members residing in other Autonomous 
  2421.      Systems.  When a multicast datagram arrives at an inter-AS 
  2422.      multicast forwarder, it is the responsibility of the ASBR to 
  2423.      determine whether the datagram should be forwarded outside of the 
  2424.      local Autonomous System.  Figure 22 illustrates a sample inter-AS 
  2425.      shortest path delivery tree when the source subnetwork resides in 
  2426.      the same area as the router performing the calculation.
  2427.  
  2428.  
  2429.  
  2430.  
  2431.  
  2432.  
  2433.  
  2434.  
  2435.  
  2436.  
  2437. Semeria & Maufer                                              [Page 43] 
  2438.  
  2439. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2440.  
  2441. ======================================================================
  2442.                      
  2443.  -----------------------------------
  2444. |              S     Area 1         |
  2445. |              |                    |
  2446. |              #                    |
  2447. |             / \                   |
  2448. |            /   \                  |
  2449. |           /     \                 |
  2450. |          /       \                |
  2451. |       O-#         #-O             |
  2452. |        / \         \              |
  2453. |       /   \         \             |
  2454. |      /     \         \            |
  2455. |     /       \         \           |
  2456. |  O-#         #         #-O        |
  2457. |             / \         \         |
  2458. |            /   \         \        |
  2459. |           /     \         \       |
  2460. |          /       \         \      |
  2461. |         /         #-O       \     |
  2462. |       ---                    ---  |
  2463.  ------| & |------------------| ? |-
  2464.         ---                    ---
  2465.  To other Autonomous      To Backbone
  2466.      Systems
  2467.  
  2468.  
  2469. LEGEND
  2470.  
  2471. S   Source Subnetwork
  2472. O   Subnet Containing Group Members
  2473. #   Intra-Area MOSPF Router
  2474. ?   Inter-Area Multicast Forwarder
  2475. &   Inter-AS Multicast Forwarder
  2476.  
  2477. Figure 22. Inter-AS Datagram Shortest Path Tree -Source in Same Area
  2478. ======================================================================
  2479.  
  2480.      If the source of a multicast datagram resides in a different 
  2481.      Autonomous System than the router performing the calculation, the 
  2482.      details describing the local topology surrounding the source 
  2483.      station are not known.   However, this information can be 
  2484.      estimated using the multicast-capable AS External links 
  2485.      describing the source subnetwork.  In this case, the base of the 
  2486.      tree begins with branches directly connecting the source 
  2487.      subnetwork to each of the local area's inter-AS multicast 
  2488.      forwarders.  
  2489.  
  2490.      Figure 23 shows a sample inter-AS shortest-path delivery tree 
  2491.      when the inter-AS multicast forwarder resides in the same area as 
  2492.  
  2493.  
  2494. Semeria & Maufer                                              [Page 44] 
  2495.  
  2496. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2497.  
  2498.      the router performing the calculation.  If the inter-AS multicast 
  2499.      forwarder is located in a different area than the router 
  2500.      performing the calculation, the topology surrounding the source 
  2501.      is approximated by combining the Summary-ASBR Link with the 
  2502.      multicast capable AS External Link.
  2503.  
  2504.  
  2505. ======================================================================
  2506.                S
  2507.                |
  2508.                :
  2509.                |
  2510.        AS External links
  2511.                |
  2512.                |
  2513.               ---
  2514.  ------------| & |-----------------
  2515. |             ---                  |
  2516. |             / \                  |
  2517. |            /   \     Area 1      |
  2518. |           /     \                |
  2519. |          /       \               |
  2520. |       O-#         #-O            |
  2521. |        / \         \             |
  2522. |       /   \         \            |
  2523. |      /     \         \           |
  2524. |     /       \         \          |
  2525. |  O-#         #         #-O       |
  2526. |             / \         \        |
  2527. |            /   \         \       |
  2528. |           /     \         \      |
  2529. |          /       \         \     |
  2530. |         /         #-O       #-O  |
  2531. |       ---                        |
  2532.  ------| ? |----------------------- 
  2533.         --- 
  2534.  To Backbone
  2535.  
  2536.  
  2537. LEGEND
  2538.  
  2539. S   Source Subnetwork
  2540. O   Subnet Containing Group Members
  2541. #   Intra-Area MOSPF Router
  2542. ?   Inter-Area Multicast Forwarder
  2543. &   Inter-AS Multicast Forwarder
  2544.  
  2545.  
  2546. Figure 23. Inter-AS Datagram Shortest Path Tree -Source in Different AS
  2547. ======================================================================
  2548.  
  2549.  
  2550.  
  2551. Semeria & Maufer                                              [Page 45] 
  2552.  
  2553. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2554.  
  2555.      As a final point, it is important to note that AS External Links 
  2556.      are not imported into Stub areas.  If the source is located 
  2557.      outside of the stub area, the topology surrounding the source is 
  2558.      estimated by the Default Summary Links originated by the stub 
  2559.      area's intra-area multicast forwarder rather than the AS External
  2560.      Links.
  2561.  
  2562. 9. PROTOCOL-INDEPENDENT MULTICAST (PIM)
  2563.  
  2564.      The Protocol Independent Multicast (PIM) routing protocol is 
  2565.      currently under development by the Inter-Domain Multicast Routing 
  2566.      (IDMR) working group of the IETF.  The objective of the IDMR 
  2567.      working group is to develop a standard multicast routing protocol 
  2568.      that can provide scalable inter-domain multicast routing across 
  2569.      the Internet.  
  2570.  
  2571.      PIM receives its name because it is not dependent on the 
  2572.      mechanisms provided by any particular unicast routing protocol. 
  2573.      However, any implementation supporting PIM requires the presence 
  2574.      of a unicast routing protocol to provide routing table 
  2575.      information and to adapt to topology changes.  
  2576.  
  2577.      PIM makes a clear distinction between a multicast routing 
  2578.      protocol that is designed for dense environments and one that is 
  2579.      designed for sparse environments.  Dense-mode refers to a 
  2580.      protocol that is designed to operate in an environment where 
  2581.      group members are relatively densely packed and bandwidth is
  2582.      plentiful.  Sparse-mode refers to a protocol that is optimized 
  2583.      for environments where group members are distributed across many 
  2584.      regions of the Internet and bandwidth is not necessarily widely
  2585.      available.  It is important to note that sparse-mode does not
  2586.      imply that the group has a few members, just that they are widely
  2587.      dispersed across the Internet.  
  2588.  
  2589.      The designers of PIM argue that DVMRP and MOSPF were developed 
  2590.      for environments where group members are densely distributed.  
  2591.      They emphasize that when group members and senders are sparsely 
  2592.      distributed across a wide area, DVMRP and MOSPF do not 
  2593.      provide the most efficient multicast delivery service.  DVMRP 
  2594.      periodically sends multicast packets over many links that do not 
  2595.      lead to group members, while MOSPF sends group membership 
  2596.      information over many links that do not lead to senders or 
  2597.      receivers.  
  2598.  
  2599. 9.1 PIM-Dense Mode (PIM-DM)
  2600.  
  2601.      While the PIM architecture was driven by the need to provide 
  2602.      scalable sparse-mode delivery trees, it also defines a new dense-
  2603.      mode protocol instead of relying on existing dense-mode protocols 
  2604.      such as DVMRP and MOSPF.  It is envisioned that PIM-DM will be 
  2605.      deployed in resource rich environments, such as a campus LAN 
  2606.  
  2607.  
  2608. Semeria & Maufer                                              [Page 46] 
  2609.  
  2610. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2611.  
  2612.      where group membership is relatively dense and bandwidth is likely
  2613.      to be readily available.  
  2614.  
  2615.      PIM-Dense Mode (PIM-DM) is similar to DVMRP in that it employs 
  2616.      the Reverse Path Multicasting (RPM) algorithm.  However, there 
  2617.      are several important differences between PIM-DM and DVMRP:  
  2618.  
  2619.      - PIM-DM relies on the presence of an existing unicast routing 
  2620.      protocol to adapt to topology changes, but it is independent of 
  2621.      the mechanisms of the specific unicast routing protocol.  In 
  2622.      contrast, DVMRP contains an integrated routing protocol that 
  2623.      makes use of its own RIP-like exchanges to compute the required 
  2624.      unicast routing information.  MOSPF uses the information 
  2625.      contained in the OSPF link state database, but MOSPF is specific 
  2626.      to only the OSPF unicast routing protocol.  
  2627.  
  2628.      - Unlike DVMRP which calculates a set of child interfaces for 
  2629.      each (source, group) pair, PIM-DM simply forwards multicast 
  2630.      traffic on all downstream interfaces until explicit prune 
  2631.      messages are received.  PIM-DM is willing to accept packet 
  2632.      duplication to eliminate routing protocol dependencies and to 
  2633.      avoid the overhead involved in building the parent/child 
  2634.      database.  
  2635.  
  2636.      For those cases where group members suddenly appear on a pruned 
  2637.      branch of the distribution tree, PIM-DM, like DVMRP, employs 
  2638.      graft messages to add the previously pruned branch to the 
  2639.      delivery tree.  Finally, PIM-DM control message processing and 
  2640.      data packet forwarding is integrated with PIM-Sparse Mode 
  2641.      operation so that a single router can run different modes for 
  2642.      different groups.  
  2643.  
  2644. 9.2 PIM-Sparse Mode (PIM-SM)
  2645.  
  2646.      PIM-Sparse Mode (PIM-SM) is being developed to provide a 
  2647.      multicast routing protocol that provides efficient communication 
  2648.      between members of sparsely distributed groups - the type of 
  2649.      groups that are most common in wide-area internetworks.  Its 
  2650.      designers believe that several hosts wishing to participate in a 
  2651.      multicast conference do not justify flooding the entire 
  2652.      internetwork with periodic multicast traffic.  They fear that 
  2653.      existing multicast routing protocols will experience scaling 
  2654.      problems if several thousand small conferences are in progress, 
  2655.      creating large amounts of aggregate traffic that would 
  2656.      potentially saturate most wide-area Internet connections.  To 
  2657.      eliminate these potential scaling issues, PIM-SM is designed to 
  2658.      limit multicast traffic so that only those routers interested in 
  2659.      receiving traffic for a particular group "see" it.  
  2660.  
  2661.      PIM-SM differs from existing dense-mode multicast algorithms in 
  2662.      two essential ways:
  2663.  
  2664.  
  2665. Semeria & Maufer                                              [Page 47] 
  2666.  
  2667. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2668.  
  2669.      - Routers with directly attached or downstream members are 
  2670.      required to join a sparse mode distribution tree by transmitting 
  2671.      explicit join messages.  If a router does not become part of the 
  2672.      pre-defined distribution tree, it will not receive multicast 
  2673.      traffic addressed to the group.  In contrast, dense-mode 
  2674.      multicast routing protocols assume downstream group membership 
  2675.      and continue to forward multicast traffic on downstream links 
  2676.      until explicit prune messages are received.  The default 
  2677.      forwarding action of the other dense-mode multicast routing 
  2678.      protocols is to forward traffic, while the default action of a 
  2679.      sparse-mode multicast routing protocol is block traffic unless it 
  2680.      is explicitly requested.  
  2681.  
  2682.  
  2683.  ======================================================================
  2684.      S1                                      S2
  2685.    ___|___                                 ___|___
  2686.         |                                   |
  2687.         |                                   |
  2688.         #                                   #
  2689.          \                                 /
  2690.           \            Primary            /
  2691.            \_____________RP______________/
  2692.                         /|\
  2693.       ________________// | \\_______________
  2694.      /         _______/  |  \______         \
  2695.      #         #         #         #         #
  2696.   ___|___   ___|___   ___|___   ___|___   ___|___
  2697.         |         |         |         |         |
  2698.         R         R         R         R         R
  2699.  
  2700.  
  2701. LEGEND
  2702.  
  2703.    #   PIM Router
  2704.    R   Multicast Receiver 
  2705.  
  2706. Figure 24 Primary Rendezvous Point
  2707. ======================================================================
  2708.  
  2709.      - PIM-SM is similar to the Core Based Tree (CBT) approach in that 
  2710.      it employs the concept of a rendezvous point (RP) where receivers 
  2711.      "meet" new sources.  The initiator of each multicast group 
  2712.      selects a primary RP and a small ordered set of alternative RPs, 
  2713.      known as the RP-list.  For each multicast group, there is only a 
  2714.      single active RP.  Each receiver wishing to join a multicast 
  2715.      group contacts its directly attached router which in turn joins 
  2716.      the multicast distribution tree by sending an explicit join 
  2717.      message to the group's primary RP.  A source uses the RP to 
  2718.      announce its presence and to find a path to members that have 
  2719.      joined the group.  This model requires sparse mode routers to 
  2720.  
  2721.  
  2722. Semeria & Maufer                                              [Page 48] 
  2723.  
  2724. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2725.  
  2726.      maintain some state (i.e., the RP-list) prior to the arrival of 
  2727.      data packets.  In contrast, dense mode multicast routing 
  2728.      protocols are data driven since they do not define state for a 
  2729.      multicast group until the first data packet arrives.  
  2730.  
  2731. 9.2.1 Directly Attached Host Joins a Group
  2732.  
  2733.      When there is more than one PIM router connected to a multi-   
  2734.      access LAN, the router with the highest IP address is selected to
  2735.      function as the Designated Router (DR) for the LAN.  The DR is 
  2736.      responsible for the transmission of IGMP Host Query messages, for 
  2737.      sending Join/Prune messages towards the RP, and for maintaining 
  2738.      the status of the active RP for local senders to multicast groups.
  2739.  
  2740.      To facilitate the differentiation between DM and SM groups, a 
  2741.      part of the Class D multicast address space is being reserved for 
  2742.      use by SM groups.  When the DR receives an IGMP Report message for 
  2743.      a new group, the DR determines if the group is RP-based or not by
  2744.      examining the group address.  If the address indicates a SM group,
  2745.      the DR performs a look up in the associated group's RP-list to
  2746.      determine the primary RP for the group.  The draft specification 
  2747.      describes a procedure for the selection of the primary RP and the
  2748.      use of alternate RPs if the primary RP becomes unreachable.   
  2749.  
  2750.  
  2751. ======================================================================
  2752.  
  2753.                                 Source (S)
  2754.                                 _|____ 
  2755.                                    |
  2756.                                    |
  2757.                                    #
  2758.                                   / \
  2759.                                  /   \
  2760.                                 /     \
  2761.                                #       #
  2762.                               /         \
  2763.              Designated      /           \
  2764.  Host      | Router         /             \  Rendezvous Point
  2765.       -----|- # - - - - - -#- - - - - - - -RP   for group G
  2766. (receiver) |  ----Join-->  ----Join-->      
  2767.            |
  2768.  
  2769.  
  2770. LEGEND
  2771.  
  2772.    #   PIM Router
  2773.    RP  Rendezvous Point 
  2774.  
  2775. Figure 25: Host Joins a Multicast Group
  2776. ======================================================================
  2777.  
  2778.  
  2779. Semeria & Maufer                                              [Page 49] 
  2780.  
  2781. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2782.  
  2783.     After performing the lookup, the DR creates a multicast 
  2784.     forwarding cache for the (*, group) pair and transmits a unicast 
  2785.     PIM-Join message to the primary RP.  The (*, group) notation 
  2786.     indicates an (any source, group) pair.  The intermediate routers 
  2787.     forward the unicast PIM-Join message and create a forwarding cache
  2788.     entry for the (*, group) pair.  Intermediate routers create the
  2789.     forwarding cache entry so that they will know how to forward 
  2790.     traffic addressed to the (*, group) pair downstream to the DR 
  2791.     originating the PIM-Join message.   
  2792.  
  2793. 9.2.2 Directly Attached Source Sends to a Group
  2794.  
  2795.      When a host first transmits a multicast packet to a group, its DR 
  2796.      must forward the datagram to the primary RP for subsequent 
  2797.      distribution across the group's delivery tree.  The DR 
  2798.      encapsulates the multicast packet in a PIM-SM-Register packet and 
  2799.      unicasts it to the primary RP for the group.  The PIM-SM-Register 
  2800.      packet informs the RP of a new source which causes the active RP 
  2801.      to transmit PIM-Join messages back to the source station's DR.  
  2802.      The routers lying between the source's DR and the RP maintain 
  2803.      state from received PIM-Join messages so that they will know how 
  2804.      to forward subsequent unencapsulated multicast packets from the 
  2805.      source subnetwork to the RP.  
  2806.  
  2807.  
  2808.  
  2809.  
  2810.  
  2811.  
  2812.  
  2813.  
  2814.  
  2815.  
  2816.  
  2817.  
  2818.  
  2819.  
  2820.  
  2821.  
  2822.  
  2823.  
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836. Semeria & Maufer                                              [Page 50] 
  2837.  
  2838. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2839.  
  2840. ======================================================================
  2841.  
  2842.                                 Source (S)
  2843.                                 _|____ 
  2844.                                    |
  2845.                                    |
  2846.                                    #
  2847.                                   / \ 
  2848.                                  /  ^\ 
  2849.                                 /    .\ 
  2850.                                #      ^# 
  2851.                               /        .\ 
  2852.              Designated      /          ^\ 
  2853.  Host      | Router         /            .\ v            |  Host
  2854.       -----|-#- - - - - - -#- - - - - - - -RP- - - # - - -|--
  2855. (receiver) |  <~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~>  | (receiver)
  2856.  
  2857.  
  2858. LEGEND
  2859.  
  2860.    #   PIM Router
  2861.    RP  Rendezvous Point 
  2862.     PIM-Register     
  2863. < . <  PIM-Join         
  2864. ~ ~ ~  Resend to         
  2865.       group members     
  2866.  
  2867. Figure 26: Source sends to a Multicast Group 
  2868. ======================================================================
  2869.  
  2870.  
  2871.      The source's DR ceases to encapsulate data packets in PIM-SM-
  2872.      Registers when it receives Join/Prune messages from the RP.  At 
  2873.      this point, data traffic is forwarded by the DR in its native 
  2874.      multicast format to the RP.  When the RP receives multicast 
  2875.      packets from the source station, it resends the datagrams on the 
  2876.      RP-shared tree to all downstream group members.  
  2877.  
  2878. 9.2.3 RP-Shared Tree or Shortest Path Tree (SPT)
  2879.  
  2880.      The RP-shared tree provides connectivity for group members but 
  2881.      does not optimize the delivery path through the internetwork.  
  2882.      PIM-SM allows receivers to either continue to receive multicast 
  2883.      traffic over the RP-shared tree or over a source-rooted shortest-
  2884.      path tree that a receiver subsequently creates.  The shortest-
  2885.      path tree allows a group member to reduce the delay between 
  2886.      itself and a particular source.  
  2887.  
  2888.  
  2889.  
  2890.  
  2891.  
  2892.  
  2893. Semeria & Maufer                                              [Page 51] 
  2894.  
  2895. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2896.  
  2897. ======================================================================
  2898.  
  2899.                                 Source (S)
  2900.                                 _|____ 
  2901.                                    |
  2902.                                   %|
  2903.                                  % #
  2904.                                 % / \*
  2905.                                % /   \*
  2906.                               % /     \*
  2907.           Designated         % #       #*
  2908.            Router           % /         \*
  2909.                            % /           \*
  2910.  Host      |  <-% % % % % % /             \v
  2911.       -----|-#- - - - - - -#- - - - - - - -RP
  2912. (receiver) |  <* * * * * * * * * * * * * * 
  2913.            |
  2914.  
  2915.  
  2916. LEGEND
  2917.  
  2918.   #   PIM Router
  2919.   RP  Rendezvous Point
  2920. * *  RP Tree          
  2921. % %   SPT Tree
  2922.  
  2923. Figure 27: RP-Shared Tree (RP Tree) and Shortest Path Tree (SPT)  
  2924. ======================================================================
  2925.  
  2926.      A PIM router with local receivers has the option of switching to 
  2927.      the source's shortest-path tree as soon as it starts receiving 
  2928.      data packets from the source station.  The change-over may be 
  2929.      triggered if the data rate from the source station exceeds a 
  2930.      predefined threshold.  The local receiver's DR does this by 
  2931.      sending a Join message towards the active source.  At the same 
  2932.      time, protocol mechanisms guarantee that a Prune message for the 
  2933.      same source is transmitted to the active RP.  Alternatively, the 
  2934.      DR may be configured to continue using the RP-based tree and 
  2935.      never switch over to the source's shortest-path tree.  
  2936.  
  2937. 9.3 Unresolved Issues
  2938.  
  2939.      It is important to note that PIM is an Internet draft.  This 
  2940.      means that it is still early in its development cycle and clearly 
  2941.      a "work in progress."  There are several important issues that 
  2942.      require further research, engineering, and/or experimentation:  
  2943.  
  2944.      - PIM-SM still requires routers to maintain a significant amount 
  2945.      of state information to describe sources and groups.  
  2946.  
  2947.      - Some multicast routers will be required to have both PIM 
  2948.  
  2949.  
  2950. Semeria & Maufer                                              [Page 52] 
  2951.  
  2952. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  2953.  
  2954.      interfaces and non-PIM interfaces.  The interaction and sharing 
  2955.      of multicast routing information between PIM and other multicast 
  2956.      routing protocols is still in the early stages of definition.  
  2957.  
  2958.      - The future deployment of PIM-SM will require extremely tight 
  2959.      coordination among the many different Internet service providers 
  2960.      to support an Internet-wide delivery service.
  2961.  
  2962.      - Finally, PIM-SM is considerably more complex than DVMRP or the 
  2963.      MOSPF extensions.
  2964.  
  2965. 10. REFERENCES
  2966.  
  2967. 10.1 Requests for Comments (RFCs)
  2968.  
  2969.      1075       "Distance Vector Multicast Routing Protocol," D. Waitzman, 
  2970.      C. Partridge, and S. Deering, November 1988.
  2971.  
  2972.      1112       "Host Extensions for IP Multicasting," Steve Deering, 
  2973.      August 1989.
  2974.  
  2975.      1583       "OSPF Version 2," John Moy, March 1994.
  2976.  
  2977.      1584       "Multicast Extensions to OSPF," John Moy, March 1994.
  2978.  
  2979.      1585       "MOSPF: Analysis and Experience," John Moy, March 1994.
  2980.  
  2981.      1800       "Internet Official Protocol Standards," Jon Postel, 
  2982.      Editor, July 1995.
  2983.  
  2984.      1812       "Requirements for IP version 4 Routers," Fred Baker,
  2985.      Editor, June 1995
  2986.  
  2987. 10.2 Internet Drafts
  2988.  
  2989.      "Core Based Trees (CBT) Multicast: Architectural Overview," 
  2990.      <draft-ietf-idmr-cbt-arch-02.txt>, A. J. Ballardie, June 20, 
  2991.      1995.
  2992.  
  2993.      "Core Based Trees (CBT) Multicast: Protocol Specification," <draft 
  2994.      -ietf-idmr-cbt-spec-03.txt>, A. J. Ballardie, November 21, 1995. 
  2995.  
  2996.      "Hierarchical Distance Vector Multicast Routing for the MBONE,"  
  2997.      Ajit Thyagarajan, and Steve Deering, July 1995. 
  2998.  
  2999.      "Internet Group Management Protocol, Version 2," <draft-ietf-
  3000.      idmr-igmp-v2-01.txt>, William Fenner, Expires March 1996.
  3001.  
  3002.      "Internet Group Management Protocol, Version 3," <draft-cain-
  3003.      igmp-00.txt>, Brad Cain, Ajit Thyagarajan, and Steve Deering, 
  3004.      Expires March 8, 1996
  3005.  
  3006.  
  3007. Semeria & Maufer                                              [Page 53] 
  3008.  
  3009. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  3010.  
  3011.      "Protocol Independent Multicast (PIM), Dense Mode Protocol 
  3012.      Specification," <draft-ietf-idmr-PIM-DM-spec-01.ps>, D. Estrin, 
  3013.      D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. Sharma, and A. 
  3014.      Helmy, January 17, 1996.
  3015.  
  3016.      "Protocol Independent Multicast (PIM): Motivation and 
  3017.      Architecture," <draft-ietf-idmr-pim-arch-01.ps>, S. Deering, D. 
  3018.      Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei, January 
  3019.      11, 1995.
  3020.  
  3021.      "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 
  3022.      Specification," <draft-ietf-idmr-PIM-SM-spec-02.ps>, S. Deering, 
  3023.      D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. Sharma, 
  3024.      and A Helmy, September 7, 1995.
  3025.  
  3026. 10.3 Textbooks
  3027.  
  3028.      Comer, Douglas E. Internetworking with TCP/IP Volume 1 
  3029.      Principles, Protocols, and Architecture Second Edition, Prentice 
  3030.      Hall, Inc. Englewood Cliffs, New Jersey, 1991
  3031.  
  3032.      Huitema, Christian. Routing in the Internet, Prentice Hall, Inc. 
  3033.      Englewood Cliffs, New Jersey, 1995
  3034.  
  3035.      Stevens, W. Richard. TCP/IP Illustrated: Volume 1 The Protocols, 
  3036.      Addison Wesley Publishing Company, Reading MA, 1994
  3037.  
  3038.      Wright, Gary and W. Richard Stevens. TCP/IP Illustrated: Volume 2 
  3039.      The Implementation, Addison Wesley Publishing Company, Reading MA, 
  3040.      MA, 1995
  3041.  
  3042. 10.4 Other
  3043.  
  3044.      Ballardie, Anthony J. "A New Approach to Multicast Communication 
  3045.      in a Datagram Internetwork," Ph.D. Thesis, University of London, 
  3046.      May 1995.
  3047.  
  3048.      Deering, Steven E. "Multicast Routing in a Datagram
  3049.      Internetwork," Ph.D. Thesis, Stanford University, December 1991.
  3050.  
  3051. 11. SECURITY CONSIDERATIONS
  3052.      Security issues are not discussed in this memo.
  3053.  
  3054. 12. AUTHORS' ADDRESSES
  3055.  
  3056.      Chuck Semeria
  3057.      3Com Corporation
  3058.      5400 Bayfront Plaza
  3059.      P.O. Box 58145
  3060.      Santa Clara, CA 95052-8145
  3061.      Phone: (408) 764-7201
  3062.      Email: Chuck_Semeria@3Mail.3Com.Com
  3063.  
  3064.  
  3065. Semeria & Maufer                                              [Page 54] 
  3066.  
  3067. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  3068.  
  3069.      Tom Maufer
  3070.      3Com Corporation
  3071.      5400 Bayfront Plaza
  3072.      P.O. Box 58145
  3073.      Santa Clara, CA 95052-8145
  3074.      Phone: (408) 764-8814
  3075.      Email: Maufer@3nsd.3Com.Com
  3076.  
  3077.  
  3078. Semeria & Maufer                                              [Page 55] 
  3079.  
  3080. INTERNET-DRAFT   Introduction to IP Multicast Routing        March 1996
  3081.  
  3082. INTERNET-DRAFT                                     Expires September 1996
  3083.