[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Diffserv] RSVP vs DiffServ
at least this is a topic of discussion which I am interested in
> > > My description would be that RSVP is thought by some
> > not to "scale
> > > well" in very large networks,
It would clarify things if you could explain "scalability with respect
> > Let's look at this a little further. What do we mean when
> > we say "RSVP is
> > used at the edges". RSVP is an end-to-end signaling
> > protocol, so - RSVP
> > travels through every device on the end-to-end path
> > through the network.
> Yes, but it doesn't operate to provide QoS knobs within the diffserv
> domain. As was proposed in one of the diffserv drafts at the recent
> IETF meeting, it's possible to use RSVP as an admission control
> protocol at the diffserv edge. Or other means could be used instead.
RSVP can be used to provide end-to-end admission control.
With reference to
Bernet Y., Yavatkar R., Ford P., Baker F., Zhang L., Speer M., Braden
R., Davie B., "Integrated Services Operation Over Diffserv Networks",
Internet Draft, June 1999
Diffserv is being considered as a NETWORK ELEMENT along the end-to-end
path. So at least the ingress/egress points should be RSVP-aware -
> But, to summarize, a diffserv core router does not listen to RSVP.
> Not unless we really change the diffserv charter.
This is interesting but I tend to agree with Yoram on that it depends on
what RSVP signaling does to "network elements" or RSVP-aware devices and
whether Diffserv should be RSVP-aware or not.
Do you have some proposals on how to change it?
Per-Flow set-up of Path/Resv state is one task that can be done using
RSVP. RSVP could be modified in such a way so as NOT to install per-flow
state or to have no state at all in Diffserv
Lecturer, Department of Computer Science,
Faculty of Engineering, University of Mauritius
Tel. 454 1041 Fax. 465 71 44
diffserv mailing list