shortcuts for multicast (not very long)

[Yakov Rekhter <[e-mail]>]

Folks,

Attached is a rough draft of a proposal from Dino and myself on how
to set up NBMA-wide (not limited to a single LIS) point-to-multipoint
VCs for distributing IP multicast traffic.

Comments would be appreciated.

Yakov.
------------------------------cut here---------------------------


		   IP multicast using PIM over ATM
                   -------------------------------

Case 1: 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).

Once the router receives an NHRP Reply, the router uses the Next Hop
information from the Reply to update its RPF, so that 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). 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.

When a router with an ATM interface receives a PIM-Join message on the
ATM interface, and the next hop towards the RP or the source carried in
the message is reachable via a non-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
point-to-multipoint 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
point-to-multipoint VC. The decision to establish a point-to-multipoint
VC is a local to the router matter.

--------------------------------------------------------------------

Case 2: ATM attached host

[The following assumes that hosts can participate in PIM.]

When a host with an ATM interface wants to join a particular multicast
group, host may send an NHRP Request towards the RP for that group. Once the
host receives an NHRP Reply, the host uses the Next Hop information 
carried in the Reply to update its RPF for the RP. This way all the PIM Join
messages for that group originated by the host for the RP
would be addressed to the entity identified by the Next Hop IP address carried 
in the Reply.

When a host with an ATM interface wants to switch from a shared (RP-based)
tree to a source-based tree, the host may send an NHRP Request towards
the source. Once the host receives an NHRP Reply, the host uses the Next
Hop informaiton carried in the Reply to update its RPF for the source.
This way, all the PIM Join messages for that source would be
addresses to the entity identified by the Next Hop information.

[Note: routers that are IP directly connected to the host must propogate the
join message to the source host].

When a host with an ATM interface wants to send packets initially, it will
encapsulate the data in a PIM Register message and unicast it to the RP. The 
host will be able to send packets natively when the Join comes back from the 
RP.


---------------------------------------------------------------------

      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 point-to-multipoint 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 point-to-multipoint VC the frequency of PIM Join (to refresh the
state) could be significantly reduced.