Subject: PIM-SM Register packets + RSVP

From: Nair Venugopal <[email-masked]>
Date: Tue, 30 Nov 1999 23:22:33 -0800 (PST)

When using RSVP with PIM-SM, the initial RSVP-PATH message for a multicast
destination would get PIM-Register-Encapsulated by the source's DR and
get unicasted to the RP. 

This suggests that none of the intermediate routers between the
source's DR and the RP would be able to process the RSVP message since the
protocol field in the outermost header of such an IP packet would be PIM
(103) instead of RSVP(46).  If so, no RSVP state can be created between
the source's DR and the RP until a native multicast path gets established
between them. 

Once a native multicast path gets established between the source's DR and
the RP, then everything would be fine. The next RSVP-PATH message sent
would get processed by all intermediate routers between the source and the
RP. However, for shortlived sessions (eg. a "voice" call), one would only
get Best Effort forwarding between the source's DR and the RP. 

1) Are there documented mechanisms by which one could ensure that the
   initial RSVP-PATH message gets honored by intermediate routers
   between the source and the RP if it is encapsulated inside PIM-Register
   packets?

2) Does this fall under the charter of the PIM WG?

thanks.
--Venu

--------------------------------------------------------------------
Nair Venugopal  --- [email-masked] --- 3Com WAP Engineering

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 1 Dec 1999 01:15:33 -0800 (PST)

>>    between the source and the RP if it is encapsulated inside PIM-Register

    One could do this if the Router Alert Option accompanied the Register
    message. Then intermediate nodes could install Path state. However, the
    path from the DR to the RP could not be the same as the multicast
    path from the DR to the RP (because the joins from the RP to the source
    go on the shortest path from RP to source). Therefore, this solution
    really isn't viable.

>> 2) Does this fall under the charter of the PIM WG?

    I believe it falls under the RSVP WG. That is, how does one prime a
    multicast path so PATH messages can flow on the correct (read: ultimate)
    multicast tree.

Dino

---

From: Dave Thaler <[email-masked]>
Date: Wed, 1 Dec 1999 12:31:43 -0800 (PST)

> 2) Does this fall under the charter of the PIM WG?

This problem is really no different than when a PATH message goes
across any type of tunnel, so it's not PIM-specific.  As such, I agree 
with Dino that it is under the RSVP WG to specify how reservations over 
tunnels work.

-Dave