HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:19:03 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 04 Jun 1996 16:45:39 GMT ETag: "2e6d27-63e4-31b46833" Accept-Ranges: bytes Content-Length: 25572 Connection: close Content-Type: text/plain Network Working Group Yakov Rekhter Internet Draft Cisco Systems Dino Farinacci Cisco Systems Expiration Date: October 1996 April 1996 Support for Sparse Mode PIM over ATM draft-ietf-rolc-pim-atm-00.txt 1. Status of this Memo This document is an Internet-Draft. 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.'' 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). 2. Abstract In this document we describe how a combination of NHRP and the sparse mode PIM could be used to establish shortcuts (single IP hop) for the multicast traffic traversing an ATM network. Yakov Rekhter, Dino Farinacci [Page 1] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 3. Motivations Support of IP multicast over ATM in the current MPOA architecture is based on the concept of Multicast Address Resolution Servers (MARS) [MARS]. With MARS the set of hosts and routers on a common ATM network is partitioned into clusters. The current MARS document requires one- to-one mapping between clusters and Logical IP Subnets (LISs). Multicast traffic between hosts and/or routers in different clusters passes through routers. Just like for the unicast traffic it could be desirable to eliminate IP hops through routers when traversing an ATM network, quite similar arguments could be applied to the multicast traffic - it could be desirable to eliminate IP hops through routers when carrying multicast traffic across an ATM network. Just like for the unicast traffic it could be desirable to establish a direct (short-cut) VC that could cross LISs' boundaries, one could argue that for the multicast traffic it could be desirable to be able to establish a direct (short-cut) point-to-multipoint (p2mpt) VC that could cross clusters' (LISs') boundaries. MARS is insufficient to accomplish this goal - as we mentioned above, MARS assumes that the multicast traffic between hosts and/or routes in different clusters (or LISs) has to flow through routers. In this document we describe a mechanism that allows to establish shortcuts (single IP hop) for the multicast traffic traversing an ATM network. The shortcuts could cross clusters' boundaries. The shortcuts utilize p2mpt VC ATM capabilities. 4. Scope of applicability The current work in the IETF on supporting IP multicast routing is focuses primarily on two proposals - Protocol Independent Multicast (PIM), and Core Based Tree (CBT). This document is focused on PIM. PIM distinguishes between two types of IP multicast groups - sparse mode and dense mode. Since a single p2mpt VC is unlikely to scale to a fairly large number of leaf nodes, and since a p2mpt VC is the only presently available ATM mechanism to support multicast, we would assume that the primary target for the shortcuts would be the multicast traffic that could be supported via the sparse mode. Therefore we focus mostly on the mechanisms that provide shortcuts for the sparse mode PIM [PIM-SM]. It is not expected that the mechanism described in this document Yakov Rekhter, Dino Farinacci [Page 2] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 would be used to handle IP multicast over ATM by every possible application that uses Sparse Mode PIM. To the contrary, only the applications that have sufficiently high volume of traffic, and/or specific QoS requirements are expected to use the mechanism. Handling of IP multicast traffic over ATM for other applications is expected to be supported via MARS and routers (and thus could incur multiple IP hops across an ATM network). One could observe similarities between this strategy and the approach for handling unicast traffic over ATM suggested in [Rekhter:95], which suggests that the decision to establish shortcuts for the unicast traffic should be controlled by the QoS and/or traffic characteristics. 5. Constructing shortcuts for sparse mode PIM In this section we describe the mechanisms that could be used by hosts and routers attached to an ATM network to construct p2mpt VCs, thus providing shortcuts across an ATM network for the IP multicast traffic that could be supported via the sparse mode PIM. 5.1. Egress router at the border of an ATM network When a router with an ATM interface receives a PIM Join message on a non-ATM interface, and the next hop towards the RP or the source (whatever is carried in the message) is reachable via the ATM interface, the router checks if it has a shortcut information for the RP or the source (whatever is carried in the message). If no shortcut information is available, the router may try to acquire this information by issuing an NHRP Request with the destination address in the Request set to either the address of the RP or the source (as carried in the Join message). When a router with an ATM interface has Sparse Mode receivers on a non-ATM interface(s), the router uses shared (RP-based) tree, and the next hop towards the RP is reachable via the ATM interface, the router checks if it has a shortcut information for the RP. If no shortcut information is available, the router may try to acquire this information by issuing an NHRP Request with the destination address in the Request set to the address of the RP. When a router with an ATM interface has Sparse Mode receivers on a non-ATM interface(s), the router uses source-based tree, and the next hop towards the source is reachable via the ATM interface, the router checks if it has a shortcut information for the source. If no shortcut information is available, the router may try to acquire this Yakov Rekhter, Dino Farinacci [Page 3] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 information by issuing an NHRP Request with the destination address in the Request set to the address of the source. 5.1.1. p2mpt VC rooted at a router This section describes the behavior of the egress router when either (a) the egress router uses the RP-based (shared) tree, or (b) the egress router uses the source-based tree, but the source is not directly connected to the ATM network. The egress router could determine whether the source is directly connected to the ATM network by using the information provided by NHRP. Once the router receives an NHRP Reply, the router uses the Next Hop information from the Reply to update its Reverse Path Forwarding (RPF) information. After the RPF information is updated, all the subsequent PIM Join messages would be addresses to the entity identified by the Next Hop IP address carried in the Reply (the Unicast-Upstream Neighbor Address in the Join messages would be set to the Next Hop IP address carried in the Reply). 5.1.2. p2mpt VC rooted at the source This section describes the behavior of the egress router when the egress router uses the source-based tree, and the source is directly connected to the ATM network. The egress router could determine whether the source is directly connected to the ATM network by using the information provider by NHRP. We consider three different cases based on whether the source supports PIM, IGMPv2, or IGMPv3. [Discussion: at the present moment there is no way for the egress router to determine whether the source supports PIM, IGMPv2, or IGMPv3. However, this information could be obtained by fairly simple extensions to NHRP.] 5.1.2.1. Source supports PIM This section describes the behavior of the egress router when the egress router uses the source-based tree, the source is directly connected to the ATM network, and the source implements PIM Join and Prune messages. Once the router receives an NHRP Reply, the router uses the Next Hop information from the Reply to update its Reverse Path Forwarding Yakov Rekhter, Dino Farinacci [Page 4] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 (RPF) information. After the RPF information is updated, all the subsequent PIM Join messages originated by the router would be addresses to the unicast address of the source. 5.1.2.2. Source supports IGMPv2 This section describes the behavior of the egress router when the egress router uses the source-based tree, the source is directly connected to the ATM network, and the source implements IGMPv2. Once the router receives an NHRP Reply, the router uses the Next Hop information from the Reply to update its Reverse Path Forwarding (RPF) information. After the RPF information is updated, all the subsequent IGMP Report messages originated by the router would be addressed to the unicast address of the source. 5.1.2.3. Source supports IGMPv3 This section describes the behavior of the egress router when the egress router uses the source-based tree, the source is directly connected to the ATM network, and the source implements IGMPv3. Once the router receives an NHRP Reply, the router uses the Next Hop information from the Reply to update its Reverse Path Forwarding (RPF) information. After the RPF information is updated, all the subsequent IGMP Report messages originated by the router would be addressed to the unicast address of the source. The Type of the message should be set to Group-Source Report. The Report Type in the messages should be set to Inclusion Report. The messages should carry the address of the source in the Source Address field. 5.1.3. Pruning off the old upstream neighbor Since the use of the information carried in the NHRP Reply would cause the RPF neighbor to the RP (or the source) to change, the router will also send a PIM Prune message to the old RPF neighbor. This is done so that ATM resources can be freed up, and to stop data arriving on the now duplicate path. The router could defer sending the Prune message until it gets added to the p2mpt VC. The router could delay it even further until it gets the first multicast packet from that VC. Delaying the Prune until the router gets added to the p2mpt VC is necessary, as it would guarantee that at any given moment the router would always be on the multicast distribution tree. Observe that deferring the Prune message Yakov Rekhter, Dino Farinacci [Page 5] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 represents a tradeoff between the possibility of receiving duplicate packets and receiving no packets at all. 5.2. ATM attached receiver (host) This section describes the behavior of a host that is a member of a given multicast group, and is directly connected to an ATM network. The following assumes that a receiver within a group doesn't have the information about the IP address of the RP for that group. Therefore, the following doesn't describe how the receiver would establish a shortcut towards the RP. We consider three different alternatives based on whether the host supports a subset of PIM, IGMPv2, or IGMPv3. 5.2.1. Receiver supports PIM The following assumes that the host implements PIM Join and Prune messages. When a host (receiver) with an ATM interface wants to establish a shortcut towards a particular sender (source), the host sends an NHRP Request towards the source. Once the host receives an NHRP Reply, the host uses the Next Hop information carried in the Reply to update its RPF for the source. Once the RPF information is updated, all the subsequent PIM Join messages for that source originated by the host would be addresses to the entity identified by the Next Hop information. A host, just like an egress router, could defer the Prune message to its non-shortcut upstream neighbor until the host gets added to the p2mpt VC (see Section 5.1.3 above). 5.2.2. Receiver supports IGMPv2 The following assumes that the host supports IGMPv2. When a host (receiver) with an ATM interface wants to establish a shortcut towards a particular sender (source), the host sends an NHRP Request towards the source. Once the host receives an NHRP Reply, the host uses the Next Hop information carried in the Reply to update its RPF for the source. After the RPF information is updated, all Yakov Rekhter, Dino Farinacci [Page 6] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 the subsequent IGMP Report messages originated by the host for the group would be addressed to the unicast address of the entity identified by the Next Hop IP address carried in the Reply. 5.2.3. Receiver supports IGMPv3 The following assumes that the host supports IGMPv3. When a host with an ATM interface wants to establish a shortcut a shortcut towards a particular sender (source), the host sends an NHRP Request towards the source. Once the host receives an NHRP Reply, the host uses the Next Hop information carried in the Reply to update its RPF for the source. After the RPF information is updated, the host would start sending IGMP Report messages for the group addressed to the unicast address of the entity identified by the Next Hop IP address carried in the Reply. The Type in the message should be set to Group-Source Report. The Report Type in the messages should be set to Inclusion Report. The messages should carry the address of the source in the Source Address field. The host should also send an IGMP Report message to its default router. The Type in the message should be set to Group-Source Leave. The Report Type in the message should be set to Exclusion Report. The message should carry the address of the source in the Source Address field. 5.3. Ingress router at the border of an ATM network When a router with an ATM interface receives a PIM Join message or an IGMPv[2,3] Report message on the ATM interface, the router checks whether it has an ATM address of the originator of the message. If yes, then the router may add the entity identified by that address to its p2mpt VC associated with the multicast address carried in the Join message. If the router doesn't have the ATM address of the originator, the router may use NHRP to resolve IP to ATM address mapping for the originator, and then add the originator to its p2mpt VC. The decision to establish a p2mpt VC is a local to the router matter. If the router doesn't have an already established p2mpt VC for a given group address, then the router may defer establishing such a VC until arbitrary point in the future. The receivers (for that group) on the ATM network would prune its non-shortcut upstream neighbor only after they would be added to the p2mpt VC. Yakov Rekhter, Dino Farinacci [Page 7] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 5.4. ATM attached sender (host) This section describes the behavior of a host that is a sender for a given multicast group, and is directly connected to an ATM network. We consider two different cases based on whether the host supports PIM or IGMPv[2,3]. 5.4.1. Sender supports PIM When the host receives a PIM Join message, the host checks whether it has an ATM address of the originator of the message. If yes, then the host may add the entity identified by that address to its p2mpt VC associated with the multicast address carried in the Join message. If the host doesn't have the ATM address of the originator, the router may use NHRP to resolve IP to ATM address mapping for the originator, and then add the originator to its p2mpt VC. The decision to establish a p2mpt VC is a local to the host matter. 5.4.2. Sender supports IGMPv[2,3] When a source with an ATM interface receives an IGMP Report message on the ATM interface, the source checks whether it has the ATM address of the originator of the message. If yes, then the source may add the entity identified by that address to its p2mpt VC associated with the multicast address carried in the Report message. If not, then the source may originate its own NHRP Request to find the ATM address of the originator of the IGMP Report message. 5.5. ATM attached Rendezvous Point (RP) Observe that an RP is nothing, but a PIM-capable router. When an RP receives a PIM Register message, the RP would send an NHRP Request towards the sender of the message. Once the RP receives an NHRP Reply, the RP behavior is determined by whether the originator of the Register message is on the ATM network or not. In the former case the RP follows the rules specified in Section 5.1.2. In the latter case the RP follows the rules specified in Section 5.1.1. Yakov Rekhter, Dino Farinacci [Page 8] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 6. Using shared and source-based trees When an egress router (or a receiver) on an ATM network that uses shortcut on a shared (RP-based) tree also wants to use source-based tree, if the upstream neighbor for the shared tree is on the same ATM network as the egress router (or the receiver), then after joining both trees (shared and source-based) the egress router (or the receiver) may end up receiving packets from the source both via the source-based and via the shared tree, even if the egress router (or the receiver) sends PIM Prune (or IGMP Leave) for the source along the shared tree. A way to deal with the duplicates is to make it responsibility of the router (or the receiver) to filter out duplicate packets received over the shared (RP-based) tree. 7. Using "hard" state (ATM) to refresh "soft" state (PIM) One thing we need to consider is the overhead due to PIM Join messages. Once a p2mpt VC is established, every leaf of that VC is going to send PIM Join messages to the root of that VC. Since PIM Join messages are sent periodically (to refresh the state), the number of these messages that the root would receive may not be insignificant. One could observe however, that the fact that a leaf (of the VC) is willing to be a part of that VC could be used as an implicit indication to refresh the PIM state. So, perhaps for the case where we use p2mpt VC, the frequency of PIM Join (to refresh the state) could be significantly reduced. 8. Applications to the Dense Mode PIM When an IP multicast group is densely distributed across a large region of a network, the group operates in dense mode PIM. That is to say, that some portions of the region can be densely populated with members and other parts may be sparsely populated. If the sparsely populated region encompasses an ATM network, then the scheme described in this document (based on using sparse mode PIM) could be used over such a region. Yakov Rekhter, Dino Farinacci [Page 9] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 9. Interaction with RSVP When RSVP is used in conjunction with multicast, one important issue is the issue of reserving appropriate resources by the originator of a p2mpt VC. If at the time of initiating the p2mpt VC the root of the VC did not receive Flowspec information, then the VC is originated with UBR or ABR ATM service class. Once the root receives the Flowspec information, the root would originate another p2mpt VC that that provides QoS consistent with the Flowspec information. After the new VC is established, the initial p2mpt VC could be torn down. 10. Comparison with other approaches It was suggested to use RSVP to establish shortcuts for the multicast traffic [RC20250, Milliken:95]. One could observe however, that establishing shortcuts effectively changes multicast packet forwarding. Doing this has certain implications. First of all, establishing shortcuts via RSVP, and using these shortcuts for sending multicast traffic may result in a situation where a receiver (which is a leaf node of a p2mpt VC) would effectively have not one, but two upstream neighbors. The first one would be determined by PIM, and the second would be the root of the p2mpt VC. This could lead to a situation where the receiver would get duplicate packets, which is clearly undesirable. Also observe that doing shortcuts with RSVP requires changes to RSVP. Finally, note that doing shortcuts with RSVP turns RSVP into a protocol that controls the next hop selection, and effectively makes it a routing protocol. This, of course, contradicts one of the fundamental design principles of RSVP that states quite clearly that "RSVP is not itself a routing protocol". RSVP is designed to operate over an underlying unicast or multicast routing. Therefore, in order to change the entities on which RSVP reserves resources, one need to change the underlying unicast or multicast routing. Since PIM is the protocol that controls multicast routing, one could argue that affecting PIM for constructing shortcuts is more appropriate that doing this with RSVP. Since handling of PIM messages is controlled by the unicast forwarding, and specifically by the RPF information, one could further argue that the most appropriate way to affect PIM is by manipulating the RPF information that PIM uses. It is precisely this approach that is described in this document. Specifically, NHRP is used to manipulate the RPF information. This, in turn, affects the PIM and thus the multicast forwarding. Once multicast forwarding provides the shortcuts, RSVP flows along these shortcuts, and reserve resources along the shortcuts. One could also observe that coupling the mechanism to establish Yakov Rekhter, Dino Farinacci [Page 10] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 shortcuts with RSVP assumes that the only case where shortcuts would need to be established is when RSVP is used. We think that this assumption may be too restrictive. With the approach proposed in this document this assumption is unnecessary as well. 11. Security Considerations Security issues are not discussed in this document. 12. References [CBT] Ballardie, A. J., "Core Based Trees (CBT) Multicast Protocol Specification", Internet Draft, November 21, 1995 [MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", draft-ietf-ipatm-ipmc-10.txt, December 1995 [Milliken:95], Milliken, W., "Integrated Servces IP Multicasting over ATM", Internet Draft, July 1995 [NHRP] Katz, D., Piscitello, D., Cole, B., Luciani, J., "NBMA Next Hop Resolution Protocol (NHRP)", Internet Draft, December 1995 [PIM-SM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., Helmy, A., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", Internet Draft, September 1995 [RC20250] Birman, A., Firoiu, V., Guerin, R., Kandlur, D., "Provisioning of RSVP-based Services over a Large ATM Network", IBM Research Report, RC20250, October 1995 [Rekhter:95] Rekhter, Y., Kandlur, D., ""Local/Remote" Forwarding Decision in Switched Data Link Subnetworks", Internet Draft, December 1995 Yakov Rekhter, Dino Farinacci [Page 11] Internet Draft draft-ietf-rolc-pim-atm-00.txt April 1996 13. Acknowledgements To be supplied. 14. Author Information Yakov Rekhter cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134 Phone: (914) 528-0090 email: yakov@cisco.com Dino Farinacci Cisco Systems 170 Tasman Dr. San Jose, CA 95134 Phone: (408) 526-4696 e-mail: dino@cisco.com Yakov Rekhter, Dino Farinacci [Page 12]