Sean;
| Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English)
| or there is another one??
| I didnt found it in the internet-drafts at the IETF !!!
Good, RSVP for multicast is an insane idea. There is a finite but nearly
zero chance that an ISP will ever squeeze more money out of someone by
promising them via RSVP that their multicast packets will make it through
from source to destination, whether the someone is a source or a listener.
ISPs can squeeze more money with resource reserved unicast.
ISPs can squeeze less money with resource reserved multicast, which
is why, with resource reserved communication, source or listener
are motivated to use multicast.
Then, with free competition between ISPs, some ISP is motivated
to offer multicast.
However, if you demonstrate compliance with an SLA that works like many
unicast ones (x% packet loss, y ms delay, from network edge to network edge),
you may be able to charge more for "best efforts" multicast, and pick
up customers who are frustrated with RSVP stuff.
To make it operationally scale without spending infinite amount of
money on network operators (:-), we need a fully automated
signaling protocol.
"Simple" RSVP: say yes always, or say no always. Choose one.
RSVP is complex partly because of filter spec, which is unnecessary
with shared-tree unidirectional PIM, and half hearted support of
half-reliable link local multicast, which is unnecessary as,
following the CATENET model, internet should not include
large link layer, which ATM network dreamed to be.
Masataka Ohta