From: Koen Zeilstra (koen@koenzeilstra.com)
Date: Fri Jun 09 2006 - 03:52:36 ART
What about this?
http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_white_paper09186a0080080204.shtml
-----------------------
"Here at the Phone Company, we serve all kinds of people; from
Presidents and Kings to the scum of the earth ..."
On Wed, 10 May 2006, Petr Lapukhov wrote:
| Excellent, topic here!
|
| Now, the only thing i could quickly find on DocCD for RSVP/LLQ is
|
| http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_white_paper09
| 186a0080080204.shtml
|
| It has one excellent picture, that cleared my thoughts a little.
|
| This is how i get it:
|
| First of all, RSVP is not just a signalling mechanism. It also has idead of
| classification, based on concept of flow.
|
| Next, RSVP was originally implemented to work with WFQ (reserved flows) -
| due to it's flow-based nature. RSVP defines a set of reserved queues within
| WFQ, that have lower weights than other flows.Note that this is not
| a strict priority queueing, so RSVP is not always served first.
|
| Then a concept of strict priority was introduced into WFQ - IP RTP priority.
| Now, what should we do, when a voice flow is classified to be under RSVP
| reservation? Cisco introduced a concept of "ip rsvp pq-profile", that could
| direct some of RSVP flows into PQ.**
|
| Finally, PQ+WFQ mutated to LLQ/CBWFQ, as we know it by now.
| But still, this concept is based on original PQ+WFQ idea. So I think
| RSVP would work great with modern LLQ as well.
|
| This is what you can see on a picture - after all classifications been done,
| we have one priority queue per interface (this is where RTP priority and
| class priority are merged). Still RSVP could direct some of it's flows into
| this queue.
|
| But as I get it, this priority queue "reserved bandwidth" is based on
| LLQ/RTP
| Priority configuration. RSVP bandwidth is bandwidth (weigth) defined for
| reserved
| flows within WFQ.
|
| I'll try to verify RSVP with modern LLQ in my lab as soon as possible, since
| i'm interested in results too :)
|
| HTH
| Petr
|
| 2006/5/10, James Ventre <messageboard@ventrefamily.com>:
| >
| > Thought you might find this interesting
| >
| > By: Pete Welcher
| > http://www.netcraftsmen.net/welcher/papers/smorgasbord01.html
| >
| >
| > "I recently did some work that lead to heavily reviewing the (sparse)
| > Cisco RSVP documentation. The documentation really doesn't say much
| > about how RSVP actually works in the Cisco routers. In particular, the
| > documentation does say RSVP works with weights with WFQ. Fine, I believe
| > that, and I know enough about that to believe it probably does what is
| > needed. Does RSVP also do that with CBWFQ/MQC? Not documented, as far as
| > I could see. The RSVP LLQ feature is mis-titled, it is really Priority
| > Queueing with WFQ, a far different thing. Etc. I ended up with the
| > feeling that the only thing Cisco RSVP seemed guaranteed to work with
| > was WFQ. "
| >
| >
| > James
| >
| >
| >
| > Jian Gu wrote:
| > > Hi, could any one please give me a pointer which explains how RSVP is
| > > configured to work with LLQ for voice traffic? my understanding is that
| > RSVP
| > > is just a signalling protocol, it still depends individual router's LLQ
| > > implementation to guarantee bandwidth for voice, but if LLQ is
| > configured
| > > for voice traffic in every router, why do we need RSVP at all for voice?
| > >
| > > Jian
| > >
| > > _______________________________________________________________________
| > > Subscription information may be found at:
| > > http://www.groupstudy.com/list/CCIELab.html
| >
| > _______________________________________________________________________
| > Subscription information may be found at:
| > http://www.groupstudy.com/list/CCIELab.html
|
| _______________________________________________________________________
| Subscription information may be found at:
| http://www.groupstudy.com/list/CCIELab.html
|
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:32 ART