Subject: FW: PIM-SM Register packets + RSVP

From: Fred Baker <[email-masked]>
Date: Mon, 10 Jan 2000 08:36:25 -0800

Comments below

>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

This was forwarded to me by Carol Iturralde. Let me make a couple of
observations.

Our implementation, at the moment, solves this in the simplest way
imaginable. If there is no route for a multicast on a PIM-Sparse network,
the initial RSVP PATH message will, as you say, get forwarded to the DR,
which will set up a route. We refresh the PATH message a second later, when
the route should have been set up. This seems to work in the cases our
customers have tested it in.

That said, there is a better approach in
draft-ietf-rsvp-refresh-reduct-01.txt. This targets a number of instances
where messages (new or changed reservations) may be lost in transit and
thereby gum up the works, of which the PIM-SPARSE setup is an example. In
essence, the proposal is to put an identifier on such a message and require
it to be acknowledged. It might be sent fairly frequently, say on
one-second intervals with an exponential back-off, until the Ack comes
back, but once the Ack comes back, the RSVP Time out might be set quite
high, limited to handling refresh and time-out issues.

I would suggest - this is the chair's to decide, but I'll give my two cents
- that starting RSVP Work in yet another working group is probably not the
most efficient approach. Rather, I'd prefer to see work items identified by
other working groups reflected back tot the RSVP folks.

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Jan 2000 12:38:33 -0800

Sending again with the right mailing list for RSVP. Comments below