Re: RPR multicast issue
My $0.02
>William Dai wrote:
>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.
I don't and I do :). We have implementations of RPR that fit
the following categories:
Head-End:
Can source and sink traffic on both directions
at full line rate - this is the aggregation point
for a metro access ring or a POP access ring.
It could also be a content server (which likely
would source at full rate). It could also be
peering points between ISPs.
Out-station:
Can source and sink traffic on both directions
at less than line rate. This will be an access
box.
>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.
I agree that this can happen and for my boxes this is no
new issue because that is what congestion mechanism's
like RED are for. Flow control mechanisms for a ring
would be very ugly and difficult to be proven correct.
>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.
I agree that the discussion is one of scope. Ethernet
does not provide traffic management in the MAC layer
and support QOS only in that packets are tagged.
I believe that RPR should provide some traffic mgt in
the MAC layer as well as some support for QOS. But I
agree that certain parts of traffic management are
outside of the scope of RPR and an inherent part of
the value add design of the switch/router. This is
true in the ethernet switch world.
>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.
That is why I do not advocate that we have signalling that
would try to flow control nodes.
mike