On Tue, 24 Aug 2004, Bob Braden wrote:
*> - RSVP doesn't have "network indication of support": the nodes keep
*> spewing RSVP messages to the network even if every router is happily
*> ignoring them, and the destination node does not support them.
Well, actually, that's not true. RSVP does have mechanisms to detect
nodes that do not support it, and nodes that do support it but fail
to respond.
Well, that's why I said "correct me if I'm mistaken" ;-).
I noticed that RSVP does have mechanisms to to detect at least some of
these (at least sect 3.8 of RFC2205), but I saw no specification
whether this actually needs to be done, how and when the hosts must
shut up if they don't see any support, etc.
In other words, if the mechanisms are there but the hosts are not
specified or required to use them, or cannot use them for some reason,
they're of arguable usefulness.
*> Possible fix: have the signalling engine contact the local network
*> administrator with a protocol to confirm if it supports the
*> reservations or not.
This is an ideal application of RFC 3751.
The local administrator just needs to be omniscient about the local
domain if the protocol's behaviour is restricted to that, and that's a
considerably easier thing to achieve.
And if you wish to achieve inter-domain reservations.. good luck
trying :) -- the lack of no progress in the last 10 years should
probably discourage most attempts..
*> - path-coupled messages require significant processing at the
*> routers. This probably needs to happen in "slow path", in software.
*> A draft mentioned an implementation being able to support a whopping
*> (NOT!) 7000 sessions. That works for the first hop, and possibly
*> even to a degree inside an enterprise where you can have software
*> based routers and not too many hosts, but it's not a useful model for
*> larger routers, deployed at more central places in the network.
Please see RFC 2998 and RFC 3175.
This is interesting, thanks.
However, if the bottlenecks are at the edge network(s) or the
first/last hop links, I'd say that you may not need to aggregate
within the domain where you want to do reservations, and you (or
rather, the operators) don't want to do any reservations where you
would need to aggregate.
This does not address the concerns of DoS attacks through a high
number of requests or state up to the point of aggregation. Even if
in the edge networks there was no need to aggregate under normal
situations, nodes going crazy could trash the routers with state.
*> Possible fix: instead of on-path processing, contact a node off-path,
*> which performs all the processing, checks the policies, etc., and
*> ensures that appropriate QoS metrics are configured at the appropriate
*> routers (these could be bulk DiffServ guarantees, more specific
*> reservations and whatever).
*>
*> - the policy checks are distributed to all the routers: the real
*> policy, within an administrative domain, is however made in a
*> centralized fashion, so it would be useful not to have to distribute
*> the policy to every router, but rather just process it in one place.
*>
*> Possible fix: BB model provides this capability.
RSVP does not put the policy in every router. Have you ever heard
of COPS?
Yes, as a matter of fact, I have. It's the protocol that there was
some research about roughly 5 years ago, but that has since then died
off and nobody is using it (well, maybe the same set of people who are
using RSVP) :-).
The PIB model was dumped a couple of years ago, and that probably
trashed the dreams of COPS people as well.
The rest of your message seems to move away from tell us what
is wrong with RSVP in particular and path-coupled signaling in
general, to telling us what is wrong with Integrated Service.
Those are old, and endless, arguments, but they don't seem to
have anything to do with the topic you started on.
RSVP builds on the Integrated Service model. Any new protocol w/
path-coupled characteristics and reservations is going to build on the
same model AFAICS. Even though the arguments don't apply to RSVP in
particular (but rather the model it builds upon), they are still valid
concerns -- if the foundation is not solid, there's not much use
building protocols (especially new ones) on top of it.
It may be that the time has solved at least some of these arguments.
If Integrated Service models were really valid, shouldn't we have seen
some of it during the last 10? We haven't -- maybe there is a reason
for it (and the prime reason is IMHO not the protocol used with that
model).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf