[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/