| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I
agree with you that sending pause type of frames in RPR is definitely not the
way to go. That causes problems for TCP/IP traffic even over Ethernet switches
configured point to point. We should make sure that we don't rely on
pause sort of things in RPR, because that would make it much worse for the ring.
Other than pause, Ethernet switches configured in chain would do (besides the L2
protocol issues like spanning tree for rings). As you
described that there are three interfaces: east ring west
ring and local traffic. Thus we have to do switching, switching requires
buffering, traffic prioritization and congestion control. Switching has
been traditionally the function of upper layers, but for RPR we are bringing in
to MAC layer. Why not bring buffering and congestion control as well. Why
not let the QoS be same as the chain of Ethernet switches (minus pause frames)
with L2 protocol enhancements to make ring topology work. How much bandwidth is
provisioned on east vs. west in my opinion is a provisioning and class of
service issue. Some classes are protected like EF and AF1, thus traffic in that
class should be sent only in one direction. Thus, if protection event happens
then other direction can be used to maintain bw gaurantee. Other class
traffic like best effort may not be protected. Thus, available link
capacity should be utilized in both directions.
-Sanjay K. Agrawal
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
|