Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: RPR multicast issue



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
 
----- Original Message -----
Sent: Friday, October 13, 2000 10:36 AM
Subject: RE: RPR multicast issue

Please eloberate why RPR as a chain of ethernet switches is a not good flow control for RPR. Why would congestion on RPR would be any worse than in a chain of ethernet switches.
 
-Sanjay K. Agrawal
-----Original Message-----
From: Harry Peng [mailto:hpeng@xxxxxxxxxxxxxxxxxx]
Sent: Friday, October 13, 2000 7:44 AM
To: William Dai
Cc: stds-802-rprsg
Subject: Re: RPR multicast issue

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
----- Original Message -----
Sent: Thursday, September 28, 2000 5:26 PM
Subject: RE: RPR multicast issue
 Ensuirng that every node sees a multicast packet
is certainly beyond the scope of RPR.

Just like in switched ethernet, there are  no garauntees
made for delivering a multicast packet to EVERY node.
Due to congestion, it could be dropped at some intermediate
switch.

raj

-----Original Message-----
From: William Dai [mailto:wdai@xxxxxxxxxxx]
Sent: Thursday, September 28, 2000 3:11 PM
To: stds-802-rprsg@xxxxxxxx
Subject: RPR multicast issue
 

Hi All,

I have a question regarding multicast packet transfer over RPR.

How to make sure that all the related node on a RPR receive
the multicast packet without dropping it due to lack of space
in its receiving buffer ? Or it it beyond the scope of the RPR
MAC definition ?

Actually this question applies to the unicast case too.

Thanks.

William Dai
Allayer Communications

-- 
Harry Peng               
------------------------------------------------------------------
Dept: 1E11              
Email: hpeng@xxxxxxxxxxxxxxxxxx
ESN:   39-52277           
Phone  613-765-2277
Fax:   613-768-4904 
Web:   http://skywww/~hpeng/
-------------------------------------------------------------------