Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I imagine the likely implementation of RPR aceess module would
require 3 major interfaces,
East Ring I/F, West Ring I/F, and the Access I/F (for
switch/router connection). In my opinion,
the bandwidth of the Access I/F should be at most equal to
that of a ring I/F for practical reasons,
though you may disagree with me. The current RPR protocols are
trying to guarantee the fairness
of ring resource access, but there is nothing to prevent
traffic flow into the same destination node
from both East and West direstions at the same time, i.e.,
input rate = 2x output rate. That is
why I'm saying that congestion could be worse on the RPR
acccess module than on the Ethernet
access module, and that is also why I'm promoting the
importance of flow control integration.
Actually, the foundamental issue here is how we view the
RPR scope. If we treat the traffic
managment (along with buffering scheme) as the higher layer
task of switch/router, then the
above is irrelavent, and argueing QoS issue inside RPR doesn't
make sense either.
On the other question, one of the important differences
between the RPR and a chain of Ethernet
switches is that RPR provide the pass-through buffers, and RPR
protocol is tightly coupled with
it. Pause type of flow control will break all the proposed
schemes, and there is potential ring lockup
problem if we are not careful.
William
Yes William, what you call flow control on the ring is the fairness protocols as there are many proposal for RPR. However, the model for the RPR is not a chain of ethernet switches. As you pointed out flow control mechanism for ethernet is "definitely not a good onefor RPR". Regards, Harry William Dai wrote: Raj, Mike, Thanks for the clarification. Let me elaborate the issue further. RPR is a dual ring topology, short term congestion can easilyoccur, in my opinion, the situation would be much worse thanthat in the switched Ethernet environment. Ethernet has the 802.3x Pause frame defined as a L2 flow controloption, not a perfect one for Ethernet, and definitely not a good onefor RPR. So should we define a L2 flow control mechanism as partof the RPR MAC ? Best regards William DaiAllayer Communications -- Harry Peng ------------------------------------------------------------------ Dept: 1E11 Email: hpeng@xxxxxxxxxxxxxxxxxx ESN: 39-52277 Phone 613-765-2277 Fax: 613-768-4904 Web: http://skywww/~hpeng/ ------------------------------------------------------------------- |