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

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/
-------------------------------------------------------------------