[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                      Keyur Patel
Internet Draft                                             Cisco Systems
Expiration Date: December 2003                             Radia Perlman
                                                           Sun Microsystems
                                                           Dino Farinacci
                                                           Greg Shepherd
                                                           Procket Networks
                   Multicast Signaling Conduit Protocol

                          draft-keyur-mscp-00.txt


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


2. Abstract

   This document describes an approach for solving the "last-mile" problem
   for multicast, especially SSM-style multicast, called Multicast Signaling
   Conduit Protocol (MSCP). It is intended to facilitate an endnode whose
   OS does not support IGMPv3, or who resides in a portion of the Internet
   infrastructure without multicast, to join multicast groups. It is
   especially intended for SSM-style groups, although it could be adapted
   for use for other multicast groups.

Patel, Perlman, Farinacci, Shepherd                             [Page 1]


Internet Draft      draft-keyur-mscp-00.txt                     December 2003


3. Introduction

   An impediment to getting SSM Multicast deployed is that, as currently
   specified, it depends on IGMPv3. Since IGMPv3 is in the IP stack, it
   requires endnodes to upgrade to an OS that supports IGMPv3 and it
   requires IGMPv3 support on the first hop multicast capable routers as
   well. This document proposes a new IP protocol known as Multicast
   Signaling Conduit Protocol (MSCP) which eliminates the requirement of
   running IGMPv3 both on endnodes as well as first hop multicast capable
   routers. This draft is solely for the purpose of joining SSM-style
   groups, i.e., groups in which the IP address of the root is explicitly
   known by the joining host. This draft allows hosts to join SSM-style
   groups even if

     * the host's OS stack does not support IGMPv3
     * the local routers do not support IGMPv3, or even multicast, and/or
     * some routers along the path to the root do not support multicast.


   This is achieved by defining a new user level process that runs MSCP.
   All that is really required to join an SSM-style group with this
   mechanism is for the joining host and the root (the "Source") to
   support this. As more routers are upgraded to supporting this,
   bandwidth use is minimized by utilizing multicast rather than tunnels.

   Although in theory this style of host join could be used instead of
   IGMP to join a non-SSM group, for non-SSM groups this design offers
   no advantage over IGMP, since only IGMPv2, which is already widely
   deployed, is required for joining non-SSM groups.

   However, if an endnode does reside in a portion of the Internet
   without any support for multicast, this mechanism could be used
   for non-SSM groups by using an anycast address in place of an
   explicit root address.

   A router that does not support the messages in this draft
   will simply forward such messages towards the destination specified
   in the messages. The first multicast capable router that supports
   MSCP will notice these messages and will form a tunnel with the end
   node that generated the message.


Patel, Perlman, Farinacci, Shepherd                             [Page 2]


Internet Draft      draft-keyur-mscp-00.txt                     December 2003


4  Multicast Signaling Conduit Protocol

   We propose a new IP multicast signaling protocol known as Multicast
   Signaling Conduit protocol (MSCP). This protocol has an ability to
   form multicast tunnels with specified destination address in the IP
   header. It runs directly over IP protocol.

   We also propose new MSCP messages with destination address in the
   IP header as either "Source" (root of the tree) address or anycast
   address to direct all the MSCP packets to a specific place within an
   AS. A wellknown anycast address defined by IANA will be used
   to transmit MSCP packets to a specified destination within an AS.

   Multicast routers implementing MSCP should treat the receipt of MSCP
   messages as intended for them, even though the destination address in
   the IP header is a unicast of the tree root. To allow a router to
   recognize a MSCP messages addressed to the unicast root address, and
   place it on the slow path, rather than simply forwarding it towards
   the specified destination, the packet will have the router alert option,
   and the IP protocol type="MSCP" with version 1.

   Usually a multicast router implementing MSCP that notices an MSCP message
   would trap the message and create a tunnel to the node that sent the
   MSCP Host-Join. However, in the case where the IP destination address is
   "MSCP Anycast", the router should forward the packet towards a router that
   advertises reachability to that address.

   Multicast routers with MSCP support receiving MSCP Join/Prune [5]
   messages will process them in similar way as PIM Join/Prune messages.
   However, MSCP routers receiving MSCP Join/Prune will send
   MSCP (Join/Prune)-Ack message back to the sender of MSCP Join/Prune
   messages  with a 4 byte cookie value. Receivers upon receipt of MSCP
   (Join/Prune)-Ack message will respond back with MSCP Auth-Ack message
   in which it will re-send the cookie value sent by the router. MSCP
   routers receiving Auth-Ack for Join/Prune will then create/delete
   interface state accordingly.

   MSCP routers will create tunnel interfaces (refer section 6) in
   their (S, G) oif lists when receiving MSCP Join [5] messages from
   receivers that are not directly connected. For all the directly
   connected receivers, MSCP routers will create interfaces in their
   (S, G) oif lists in the same way as if an IGMP (S,G) join or a PIM
   Join/Prune message were received. An implementation must have a
   configured upper bound on number of tunnel interfaces that it can put
   in oif lists of any multicast route. Multicast routers receiving such
   MSCP Host-Join/Prune messages will process them and create state in
   similar way as if a PIM Join/Prune (S, G) message was received.

   All the non-multicast capable routers will simply forward such packets
   towards the unicast source address/anycast address. Current routers
   which receive an IP unicast packet with IP options process these packets
   and forward them towards the unicast destination address specified in the
   ip packet if the destination is not one of the ip addresses of the
   routers. Otherwise, these routers forward these packets up the local
   stack for local delivery. Therefore, current routers will forward the
   packets destined for the unicast address of the root, to the root,
   which is the desired behavior.

   MSCP Routers maintaining tunnel state for (S, G) will periodically
   query all its interested receivers by sending MSCP Query [5] messages.
   All end-hosts willing to subscribe to a particular (S, G) group
   will be periodically sending MSCP Host-Join [5] messages. All the MSCP
   Host-Join/Prune [5] messages will be sent with unicast source address
   as the destination address. All the MSCP Host-Join/Prune messages
   will be sent with IP Router Alert option.

Patel, Perlman, Farinacci, Shepherd                             [Page 3]


Internet Draft      draft-keyur-mscp-00.txt                     December 2003

5  MSCP Messages
   This section defines different message formats for MSCP. MSCP messages
   are sent either unicast to a particular source or towards anycast address.
   Each MSCP message has a fixed size header. The layout of this header is
   shown below:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver   | Type  |   Reserved    |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   MSCP Ver
     MSCP Version number is 1.

   Type
     Types for specific MSCP messages.  MSCP Types are:


     Message Type                          Destination
     -------------------------------------------------------------------------
     0 = Query Message                     Unicast to Source/Anycast
     1 = Join Message                      Unicast to Source/Anycast
     2 = Join-Ack Message                  Unicast to Source/Anycast
     3 = Auth Ack                          Unicast to Source/Anycast
     4 = Prune Message                     Unicast to Source/Anycast
     5 = Prune-Ack Message                 Unicast to Source/Anycast
     6 = Data Message                      Unicast to Source/Anycast

   Reserved
     Set to zero on transmission.  Ignored upon receipt.

   Checksum
     The checksum is a standard IP checksum, i.e.  the 16-bit one's
     complement of the one's complement sum of the entire MSCP message.
     For computing the checksum, the checksum field is zeroed.

     For IPv6, the checksum also includes the IPv6 "pseudo-header", as
     specified in RFC 2460, section 8.1 [5]. This "pseudo-header" is
     prepended to the MSCP header for the purposes of calculating the
     checksum.  The "Upper-Layer Packet Length" in the pseudo-header is
     set to the length of the MSCP message.  The Next Header value used
     in the pseudo-header is 103.  If the packet's length is not an
     integral number of 16-bit words, the packet is padded with a byte
     of zero before performing the checksum.

   Encoded format for Unicast Source and Group address is shown below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Addr Family  | Encoding Type |     Unicast Address
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Addr Family
     The MSCP address family of the 'Unicast Address' field of this
     address.

     Values of 0-127 are as assigned by the IANA for Internet Address
     Families in [8]. Values 128-250 are reserved to be assigned by the
     IANA for PIM-specific Address Families.  Values 251 though 255 are
     designated for private use.  As there is no assignment authority
     for this space, collisions should be expected.

   Encoding Type
     The type of encoding used within a specific Address Family.  The
     value `0' is reserved for this field, and represents the native
     encoding of the Address Family.



Patel, Perlman, Farinacci, Shepherd                             [Page 4]


Internet Draft      draft-keyur-mscp-00.txt                     December 2003


   Unicast Address
     The unicast address as represented by the given Address Family and
     Encoding Type.



5.1  MSCP Host Query message format

   MSCP Prune-Ack messages are sent in reply to Prune message by routers
   forming tunnels.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Unicast Router address  (Encoded-Source format)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Unicast Router Address
     For format description refer to Encoded-Unicast address.


5.2  MSCP Host-Join message format

   MSCP Host-Joins are sent to assist building source/core trees (SPT/CBT).


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Num Jn groups |          Holdtime             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tn Format    | Multicast Source Address  (Encoded format)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address 1 (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             .                                 |
     |                             .                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address n (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Reserved
     Transmitted as zero, ignored on receipt.

   Number of Join Groups
     The number of multicast group sets contained in the message.

   Holdtime
     The amount of time a receiver must keep the Join state alive,
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     appropriate canceling Join message, or timed out according to
     local policy.  This may be used with dial-on-demand links, to avoid
     keeping the link up with periodic Join/Prune messages.

     Note that the Holdtime must be larger than the
     J/P_Override_Interval(I) (refer to [PIM-SM]).

   Tunnel Type
     Specific type of Tunnel that receiver wants Router to create
     0 (IP-in-IP), 1 (GRE).

   Multicast Source address
     For format description refer to Encoded-Unicast address.

   Join Group Address 1 .. n
     This list contains the Groups that the sending router will forward
     multicast datagrams for if received on the interface this message
     is sent on.

     See Encoded-Source-Address format.



Patel, Perlman, Farinacci, Shepherd                             [Page 5]


Internet Draft      draft-keyur-mscp-00.txt                     December 2003


5.3  MSCP Host Join-Ack message format

   MSCP Join-Ack messages are sent in reply to Join message by routers
   forming tunnels.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Num Pr groups |          Holdtime             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tn Format    | Multicast Source Address  (Encoded format)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address 1 (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             .                                 |
     |                             .                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address n (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Cookie Value                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Reserved
     Transmitted as zero, ignored on receipt.

   Number of Prune Groups
     The number of multicast group sets contained in the message.

   Holdtime
     The amount of time a receiver must keep the Join state alive,
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     appropriate canceling Join message, or timed out according to
     local policy.  This may be used with dial-on-demand links, to avoid
     keeping the link up with periodic Join/Prune messages.

     Note that the Holdtime must be larger than the
     J/P_Override_Interval(I) (refer to [PIM-SM]).

   Tunnel Type
     Specific type of Tunnel that receiver wants Router to create
     0 (IP-in-IP), 1 (GRE).

   Multicast Source address
     For format description refer to Encoded-Unicast address.

   Join Group Address 1 .. n
     This list contains the Groups that the sending router will forward
     multicast datagrams for if received on the interface this message
     is sent on.

     See Encoded-Source-Address format.

   Fixed four byte Key
     Cookie value that is reflected back in Auth-Ack message.


5.4  MSCP Host-Prune message format

   MSCP Host-Prunes are sent to prune source trees when members leave groups.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Num Pr groups |          Holdtime             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tn Format    | Multicast Source Address  (Encoded format)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address 1 (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             .                                 |
     |                             .                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address n (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Patel, Perlman, Farinacci, Shepherd                             [Page 6]


Internet Draft      draft-keyur-mscp-00.txt                     December 2003


   Reserved
     Transmitted as zero, ignored on receipt.

   Number of Prune Groups
     The number of multicast group sets contained in the message.

   Holdtime
     The amount of time a receiver must keep the Join state alive,
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     appropriate canceling Join message, or timed out according to
     local policy.  This may be used with dial-on-demand links, to avoid
     keeping the link up with periodic Join/Prune messages.

     Note that the Holdtime must be larger than the
     J/P_Override_Interval(I) (refer to [PIM-SM]).

   Tunnel Type
     Specific type of Tunnel that receiver is using with the Router
     0 (IP-in-IP), 1 (GRE).

   Multicast Source address
     For format description refer to Encoded-Unicast address.

   Join Group Address 1 .. n
     This list contains the Groups that the sending router will forward
     multicast datagrams for if received on the interface this message
     is sent on.

     See Encoded-Source-Address format.


5.5  MSCP Host Prune-Ack message format

   MSCP Host-Prunes are sent to prune source trees when members leave groups.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Num Pr groups |          Holdtime             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tn Format    | Multicast Source Address  (Encoded format)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address 1 (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             .                                 |
     |                             .                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address n (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Cookie Value                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved
     Transmitted as zero, ignored on receipt.

   Number of Prune Groups
     The number of multicast group sets contained in the message.

   Holdtime
     The amount of time a receiver must keep the Join state alive,
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     appropriate canceling Join message, or timed out according to
     local policy.  This may be used with dial-on-demand links, to avoid
     keeping the link up with periodic Join/Prune messages.

     Note that the Holdtime must be larger than the
     J/P_Override_Interval(I) (refer to [PIM-SM]).

   Tunnel Type
     Specific type of Tunnel that receiver is using with the Router
     0 (IP-in-IP), 1 (GRE).

   Multicast Source address
     For format description refer to Encoded-Unicast address.

   Join Group Address 1 .. n
     This list contains the Groups that the sending router will forward
     multicast datagrams for if received on the interface this message
     is sent on.

     See Encoded-Source-Address format.

   Fixed four byte Key
     Cookie value that is reflected back in Auth-Ack message.


5.6  MSCP Host Auth-Ack message format

   MSCP Prune-Ack messages are sent in reply to Prune message by routers
   forming tunnels.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Prune/Joine   |          Cookie Value         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Cookie Value                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved
     Transmitted as zero, ignored on receipt.

   Prune/Join
     Auth message sent in respone to 0 (Join-Ack) 1 (Prune-Ack).

   Fixed four byte Key
     Cookie value that is reflected back in Auth-Ack message.



Patel, Perlman, Farinacci, Shepherd                             [Page 7]

Internet Draft      draft-keyur-mscp-00.txt                     December 2003


6. Tunnel Interfaces
   Because not all intermediate routers support native ip multicast,
   MSCP requires all the oifs on which it receives MSCP Host-Join/Prunes
   messages from receivers which are not directly connected to be created
   as tunnel interfaces. In practice, tunnels typically use either IP-IP
   [Perk96] or Generic Routing Encapsulation (GRE) [Han94a,Han94b],
   although, other encapsulation methods are acceptable.



7. Security Considerations

   MSCP does not change any multicast security issues. PIM is open to many
   types of resource overload. For instance, a node which transmits from
   many bogus source addresses will cause PIM routers to join to many (S,G)
   pairs, eventually exhausting state. PIM routers must protect themselves
   by limiting the amount of state for multicast, so that a denial of
   service attack on multicast will not destroy unicast.

   With LAN-based IGMP joins, only nodes on the LAN can initiate a join,
   so if the LAN is physically protected, and all routers along the
   path to the RP (or S in an (S,G) join) are trusted, it might be
   somewhat harder for a node to create join state untraceably than
   it would with this tunnel proposal. With this tunnel proposal,
   the join message is sent over a multi-hop path.

   As stated in the document, a router is configured with a maximum
   number of tunnels it is willing to accept, so an attack to deplete
   its tunnel resources will only affect attempts to create tunnels,
   and not cause any other denial of service.

   Additionally, the router to whom tunnels will be created is likely
   to be the entry router at an ISP, and it can consider an entire customer
   network to be a LAN. If suspiciously many tunnels are being created
   from that customer network, the router can start discriminating against
   joins from that customer network, when resources are being depleted.

   Eventually, cryptographic authentication can be added between the
   joiner and the router, by having potential joiners obtain a key (or
   certificate) from the router before they are allowed to join, and
   having join messages cryptographically authenticated.

8. Acknowledgements

   We express our thanks to Alex Zinin, Dino Farinacci, Lorenzo Vicisano,
   liming Wei, Tom Pusateri, and Nidhi Bhaskar for their review and comments.

9. References

   [PIM-SM]  Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas,
             "Protocol Independent Multicast - Sparse Mode (PIM-SM):
             Protocol Specification (Revised)".

   [Han94a]  Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
             Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and
             cisco Systems, October 1994.

   [Han94b]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
             Routing Encapsulation over IPv4 networks", RFC 1702,
             NetSmiths, Ltd., cisco Systems, October 1994.

   [Perk96]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
             October 1996.


10. Author Information

   Keyur Patel
   Cisco Systems. Inc.
   email: keyur@ayrnetworks.com

   Radia Perlman
   Sun Microsystems. Inc.
   email: Radia.Perlman@sun.com

   Dino Farinacci
   Procket Networks Inc.
   email: dino@procket.com

   Greg Shepherd
   Procket Networks Inc.
   email: shep@procket.com