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]
