PIM Working Group Hal Sandick Internet Draft Brad Cain Draft-sandick-pimsm-ssmrules-00.txt Nortel Networks March 2000 Expires September 2000 PIM-SM Rules for Support of Single-Source Multicast 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. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the minor changes in protocol processing rules for the PIM-SM [PIMSM] protocol to support source specific multicast (SSM) routing semantics over the SSM address range [EXPRESS][SSM]. Used in combination with IGMPv3 [IGMPV3], the SSM delivery model can be supported with current protocol implementations. IGMPv3 can be used for communicating source specific (S,G) channel memberships to local routers; PIM-SM can be used for construction of SSM forwarding trees. This document describes the processing rules for PIM-SM in the SSM address range to support construction of SSM delivery trees. 1 Introduction Currently, all multicast routing protocols support Internet Standard Multicast (ISM) supporting any number of senders and receivers (many-to- many) [CBT, DVMRP, MOSPF, PIMDM, PIMSM]. Although the increased complexity of supporting multiple senders is needed by some Sandick, Cain 1 PIM-SM Rules for Single-Source Multicast March 7, 2000 applications, many of the near-term applications making use of multicast use only a single sender (1-to-many). It is believed by some that the complexity of multicast routing and the lack of policy control are reasons for the limited deployment of multicast service. Providers of multicast content, such as financial data, news, video, etc., need only a 1-to-many multicast service from the network. Internet service providers who provide multicast service find shortest path trees better for control and policy. Several proposals have suggested new service models because of these concerns [SIMPLE, EXPRESS]. The Source-Specific Multicast model [SSM] proposes a single-source address range with single source delivery semantics within SSM address range. SSM support does not require a new routing protocol, eliminates the need for bootstrap and RP configuration, and can easily be transited across other multicast routing protocol domains. An advantage of SSM is that it can be implemented with IGMPv3 and PIM-SM with very minor protocol processing rule changes. [SSM] also describes rules for the IGMPv3 protocol for processing host to router joins and leaves within the SSM address range. This document is a companion document to [SSM] and describes the PIM-SM protocol rules for support of SSM multicast. PIM-SM in conjunction with IGMPv3, allow the setup of 1-to-many multicast channels in an extremely efficient fashion. 2 PIM-SM Overview Like other multicast routing protocols, PIM-SM is designed to handle multicast sessions with multiple senders. PIM-SM uses both shared trees and shortest path trees (SPT). Initially, leaf routers join the shared tree until a source's data rate is high enough to cause a shortest path join (i.e. a join towards the source). The shared tree is rooted at a "rendezvous point" router to which all senders forward their data. The rendezvous point then forwards the data onto the shared tree. This kind of shared tree is sometimes described as an (*,G) tree where "*" means all senders and G refers to a particular group address. In order to build a SPT tree a PIM-SM leaf router has to first join the shared tree. When the first data packet for a multicast flow arrives on the shared tree the leaf router can then initiate joining the SPT. After the first packet arrives on the SPT, the leaf routers then must prune back the particular source from the shared tree. It is not uncommon for deployed PIM-SM networks to set the data threshold for joining a SPT to zero, i.e., the SPT join is triggered by the arrival of the first packet. Configuring PIM-SM in this way causes the shared tree to be used for "source discovery" and not for data forwarding. As stated earlier, there are many applications that do not require multiple senders and would benefit from the simplification of direct Sandick, Cain 2 PIM-SM Rules for Single-Source Multicast March 7, 2000 source specific joins (e.g. SPT). IGMPv3 allows receivers to join particular source groups obviating the need for the leaf router to discover the sources through the shared tree. Being able to join the SPT directly with out first joining the shared tree reduces the state in the network, simplifies the routing environment (i.e. no RP placement, etc.), and makes management easier. Therefore, to meet the needs of the 1-to-many case we propose a simplification of PIM-SM that builds SPT trees immediately. 3 Router Support for Single-Source Multicast Single-Source Multicast (SSM) [SSM] defines a SSM multicast address (SSM) range, 232/8, to be used for single source multicast routing. SSM addressing is with per source, per group, where a given (S,G) address describes a single-source _channel_. SSM group addresses are not unique within any scope and can be used by many hosts at the same time. They are only unique when qualified by the unique source address of the transmitting host. For routing purposes, therefore, a SSM channel is a combination of a source and a SSM group address (S,G). Multicast routers which support routing of SSM MUST route datagrams addressed to groups in the SSM range according to SSM forwarding semantics [SSM]. In the following sections, we describe the PIM-SM protocol processing rules for the construction of single-source multicast forwarding trees. 3.1 Single-Source Forwarding SSM forwarding entries are per source, per group forwarding entries (S,G). They consist of a single incoming interface (iif) and a set of outgoing interfaces (oif-list). The rules for the forwarding of IP datagrams in the SSM range are now described. When a packet is received with destination address within the SSM range: If (a matching (S,G) entry is found), then If (iif is equal to the iif of the (S,G) entry) then Forward a copy packet of the packet to all entries in the oif-list Else Drop the packet Else Drop the packet SSM packets MUST only be forwarded to interfaces from which a SSM join (see section 3.2.4) has been received. Sandick, Cain 3 PIM-SM Rules for Single-Source Multicast March 7, 2000 3.2 PIM-SM Rules PIM-SM may be used to implement the SSM join and prune signaling. SSM uses an explicit receiver driven membership which can easily be mapped into the PIM-SM protocol. This section describes the rules for an implementation of SSM using the PIM-SM multicast routing protocol. As described earlier, SSM channels are identified by a (S,G) address pair combination. A SSM "route entry" (from PIM-SM) means a (S,G) address pair, with "G" in the SSM address range, and its associated protocol state. SSM route entries may be built using the PIM-SM protocol (for signaling). The SSM address range currently only defines two operations: 1.) join a channel and 2.) leave a channel. These two operations can be implemented by specifying SSM (S,G) pairs in PIM-SM (S,G) Join and Prune messages and propagating them towards the source address "S". 3.2.1 PIM-SM Message Types SSM makes use of two PIM-SM message types: 1. Hello 2. Join/Prune PIM-SM Hello messages are used to establish neighbor relationships; these messages are standard PIM-SM messages following the PIM-SM format, timer, and processing rules. PIM-SM Join/Prune messages are used to propagate SSM join and prune signaling. These messages follow PIM-SM format, timer, and processing rules. However, only certain Join/Prune message types, Source Address Encodings, and Group Address Encodings are valid within the SSM address range. 3.2.2 Hello Messages PIM-SM Hello messages should be sent between routers supporting SSM. These messages may use the Holdtime option (type = 1). Hello messages are processed and sent according to the PIM-SM protocol specification. 3.2.3 Address Family SSM channels use the IPv4 address family encoding. SSM channels are identified by (S,G) pairs where "G" is within the SSM group address range. Sandick, Cain 4 PIM-SM Rules for Single-Source Multicast March 7, 2000 3.2.3.1 Group Address Encoding PIM-SM defines a group address encoding for address family independence. For a group address within the SSM range, the following applies: 1. Address Family = IPv4 2. Encoding Type = 0 3. Mask Length = 32 3.2.3.2 Source Address Encoding PIM-SM defines a source address encoding for address family independence. For a source address which is part of a SSM (S,G) channel, the following applies for all source addresses. 1. Address Family = IPv4 2. Encoding Type = 0 3. Sparse Bit = 1 4. WC bit = 0 5. R bit = 0 6. Mask Length = 32 3.2.4 Join/Prune PIM-SM Join/Prune messages are used to build SSM trees within routing domains. PIM-SM source-specific join and prune messages are used to signal SSM join/prune operations. A SSM (S,G) join is sent when either a host expresses interest in a single source channel, when the periodic refresh timer expires, or when a join is received which causes creation of a new (S,G) route entry. The following actions cause a triggered (S,G) Join messages to be originated from a router: 1. Creation of a new (S,G) route entry as a result of an IGMPv3 ALLOW_NEW_SOURCES record. 2. Creation of a new (S,G) route entry as a result of reception of a (S,G) Join from a downstream neighbor. 3. Update of a incoming interface for a route entry as a result of a routing change; the new join should be sent to the upstream interface of the new incoming interface entry. 4. Periodic expiration of the refresh timer. The following actions cause a triggered (S,G) Prune message to be originated from a router: 1. Delete of a (S,G) route entry after the IGMPv3 Last Member Query Interval (as a result of an IGMPv3 BLOCK_NEW_SOURCES record). 2. Deletion of a new (S,G) route entry as a result of Sandick, Cain 5 PIM-SM Rules for Single-Source Multicast March 7, 2000 reception of a (S,G) Prune from a downstream neighbor. 3. Update of a incoming interface for a route entry as a result of a routing change; the new prune should be sent to the previous upstream incoming interface. 4. Periodic expiration of the refresh timer. 5. If the last oif for an entry is removed. 3.2.4.1 Refresh Routers MUST periodically refresh their (S,G) fowarding state within the SSM group address range according to the PIM-SM protocol specification. 3.2.4.2 PIM-SM DR PIM-SM elects a designated router per subnet; this router is responsible for originating Joins/Prunes for the subnet. Routers must support PIM- SM DR election within the SSM address range. 3.2.4.3 Assert Due to policy it is possible for two down stream routers to have differences in their respective multicast RIBs. It is therefore possible for these routers to send their (S,G) Joins to different upstream routers. This can result in multiple routers forwarding the same data stream onto a subnet. In these cases the Assert process may be invoked. Assert MUST be supported within the SSM address range. 3.2.4.4 Routing Changes When routing changes occur, the correct incoming interfaces must be updated to reflect the new shortest path routes. Routers supporting SSM MUST update their incoming interfaces according the PIM-SM specification when routing change occur which could affect the correct incoming interface. 3.2.5 Other PIM-SM Messages Within the SSM group address range, only PIM-SM Join/Prune messages are valid. In addition, routers which support SSM MUST send PIM-SM Hello messages according to [PIMSM]. Routers should silently discard any other message types, encodings, or invalid options within in the SSM address range. The following are examples of invalid messages within the SSM address range: - A (*,G) join where "G" is within the SSM address range. - A Register message where the group encoded is within the SSM address range Sandick, Cain 6 PIM-SM Rules for Single-Source Multicast March 7, 2000 3.2.5.1 Register SSM forwarding semantics are such that packets are only forwarded to interfaces from which downstream neighbors have sent a SSM join or interfaces with locally attached SSM group members. In summary, SSM is receiver driven explicit join; data packets MUST not trigger control actions. PIM-SM supports ISM by "rendezvousing" sources and receiver trees at a rendezvous point router (RP). PIM-SM encapsulates sources to register with rendezvous points. Routers supporting SSM MUST not register sources which transmit to group addresses within the SSM address range. Datagrams with destination address within the SSM range should be treated strictly as in section X.1. In 3.2.5.2 Bootstrap PIM-SM uses the bootstrap protocol to propagate RP to group mappings. The single-source model does not require such a protocol as a given (S,G) defines a single channel and therefore a source-rooted tree. It follows that the bootstrap protocol is not relevant for SSM. Routers receiving bootstrap messages for group addresses in the SSM range should forward them according to standard PIM-SM forwarding rules. However, all entries with group addresses in the SSM range should be silently ignored. 3.2.6 Other Tree Entries PIM-SM uses (*,G) entries for building shared trees rooted at a rendezvous point. These entry types MUST not be used for groups in the SSM range. Routers supporting SSM should ignore (*,G) join messages; it follows that datagrams addressed to groups in the SSM range should never be forwarded on RP trees. Therefore, (*,G) oif-lists MUST not be copied into SSM (S,G) oif-lists. PIM-SM uses (*,*,RP) entries for building branches from border routers to RPs for compatibility with other routing protocols. When a datagram addressed to the SSM range is received by a router, it MUST not be forwarded down (*,*,RP) branches. Therefore, (*,*,RP) oif-lists MUST not be copied into SSM (S,G) oif-lists. PIM-SM has the ability to build two types of trees: RP centered and source centered. Furthermore, it includes the ability to switch between these tree types. SSM by definition supports only source centered unidirectional trees. Therefore all PIM-SM support for switching trees is not requiredfor SSM. Sandick, Cain 7 PIM-SM Rules for Single-Source Multicast March 7, 2000 3.3 PIM<->IGMPv3 Interaction for SSM An implementation of SSM may use the IGMPv3 protocol for communicatinghost SSM joins and leaves [holbrook]. IGMPv3 Record types of ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES are used to communicate (S,G) membership information. When a router receives a (S,G) join for a SSM channel, it: 1. Processes the join according to IGMPv3 rules [cain] 2. Performs a lookup on the (S,G) pair to find a matching forwarding entry 3. If a matching entry is found, the router adds the appropriate interface to the oif-list of the matching forwarding entry 4. If a matching entry is not found, a new one is created and a PIM-SM Join is sent (with semantics of section 2) to the interface which is considered closest to the IP source address When a router receives a (S,G) leave for a SSM channel, it: 1. Processes the leave according to IGMPv3 rules 2. If IGMPv3 has determined there are no other members present on the locally attached interface, and a matching entry exists for the (S,G) pair, then: 3. A PIM-SM Prune is sent (with semantics of section 2) to the interface which is considered closest to the IP source address 3.4 Interoperability SSM is a completely separate and distinct model from ISM. Interoperability between these two models is unnecessary and in fact may cause confusion to applications. 4 Packet Formats PIM-SM supports SSM directly using a subset of the PIM-SM protocol. The following is a summary of the message subset used, taken from the PIM-SM specification [PIMSM]: 4.1 Join/Prune Message A Join/Prune message is sent by routers towards upstream sources and RPs. In the SSM address range, PIM-SM Join/Prune messages are used for building single-source trees as described in section 3. Sandick, Cain 8 PIM-SM Rules for Single-Source Multicast March 7, 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Upstream Neighbor Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Multicast Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Joined Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Joined Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Multicast Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Joined Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Joined Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sandick, Cain 9 PIM-SM Rules for Single-Source Multicast March 7, 2000 PIM Ver: PIM Version number is 2. Type: 3 = Join/Prune Reserved Set to zero. Ignored upon receipt. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message, (excluding the data portion in the Register message). For computing the checksum, the checksum field is zeroed. Encoded-Unicast Upstream Neighbor Address The address of the RPF or upstream neighbor. The form for this address is given in the Encoded-Unicast-Address in 4.4. .IP "Reserved" Transmitted as zero, ignored on receipt. Holdtime The amount of time a receiver must keep the Join/Prune state alive, in seconds. If the Holdtime is set to `0xffff', the receiver of this message never times out the oif. This may be used with ISDN lines, to avoid keeping the link up with periodical Join/Prune messages. Furthermore, if the Holdtime is set to `0', the information is timed out immediately. Number of Groups The number of multicast group sets contained in the message. Encoded-Multicast group address For format description see Section 4.3 Number of Joined Sources Number of join source addresses listed for a given group. Join Source Address-1 This list contains the sources that the sending router will forward multicast datagrams for if received on the interface this message is sent on. Number of Pruned Sources Number of prune source addresses listed for a group. Sandick, Cain 10 PIM-SM Rules for Single-Source Multicast March 7, 2000 Prune Source Address-1 .. n This list contains the sources that the sending router does not want to forward multicast datagrams for when received on the interface this message is sent on. If the Join/Prune message boundary exceeds the maximum packet size, then the join and prune lists for the same group must be included in the same packet. 4.2 Addresses Encoding 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 Groups within the SSM range are encoded with Addr Family = IP (1). 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. Unicast Address The unicast address as represented by the given Address Family and Encoding Type. 4.3 Encoded-Group-Address 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 | Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr Family Section 3.2.3. Encoding Type Section 3.2.3. Reserved Transmitted as zero. Ignored upon receipt. Sandick, Cain 11 PIM-SM Rules for Single-Source Multicast March 7, 2000 Mask Len Mask Length MUST be 32. Group multicast Address Section 3.2.3.1. 4.4 Encoded-Source-Address Takes the following format: 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 | Rsrvd |S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr Family Section 3.2.3. Encoding Type Section3.2.3. Reserved Transmitted as zero. Ignored upon receipt. S,W,R See Section 3.2.3for details. Mask Length Mask Length MUST be 32. Source Address The source address. 5 Conclusions This document is a companion document to [SSM] and describes minor changes to PIM-SM protocol processing rules for support of single-source delivery semantics within the SSM group address range. Acknowledgements We wish to acknowledge Hugh Holbrook, Tom Pusateri and Billy Ng for their comments and observations. Sandick, Cain 12 PIM-SM Rules for Single-Source Multicast March 7, 2000 REFERENCES [CBT] Ballardie, Cain, Zhang, Core Based Tree Multicast Routing, Internet-Draft, March 1998 [DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol," draft-ietf-idmr-dvmrp-v3-07.txt, .ps, July 1998. [EXPRESS] Holbrook, H., Cheriton, D, "EXPRESS Multicast", SIGCOMM 99, September 1999. [SSM] Holbook, H., Cain, B., _Source-Specific Multicast for IP,_ draft- hobrook-ssm-00.txt, March 2000. [IGMPV2] ] Fenner, B., "Internet Group Management Protocol, Version 2", RFC2236, November 1997. [IGMPV3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group Management Protocol, Version 3," draft-ietf-idmr-igmpv3-00.txt, November 1997. [MOSPF] Moy, J., "Multicast Extensions to OSPF," RFC1584, March 1994. [PIMDM] Wei, L. et al., "Protocol Independent Multicast Version 2, Dense Mode Specification," internet-draft- idmr-pim-dm-05.txt, November 1997. [PIMSM] Estrin et al., "Protocol Independent Multicast Sparse-Mode: Protocol Specification", draft- - ietf idmr-pim-sm-specv2-00.txt .ps, September 1997. [SIMPLE] Perlman, R. et al "A Design for Simple, Low-Overhead Multicast", draft-perlman-simple-multicast-00.txt, August 1998. AUTHORS' ADDRESSES Brad Cain Nortel Networks, Inc. 600 Tech Park Billerica, MA 01821 phone: +1-978-916-1316 email: bcain@nortelnetworks.com Sandick, Cain 13 PIM-SM Rules for Single-Source Multicast March 7, 2000 Hal Sandick Nortel Networks, Inc. 4309 Emperor Blvd., Suite 200 Durham, NC 27705 Phone: +1=919-992-9046 Email: hsandick@nortelnetworks.com Sandick, Cain 14