|
With "L2 protocol enhancement", "a chain of Ethernet switch"
will work in ring topolgy,
and it is a natural solution to allow different speed at
different ring segement (hop) as
some people promoted in the other
thread of email. The "L2 protocol enhancement"
in this case would most likely be the task of 802.1d, and
if the ring is not required to be
a homogeneous one in each direction, the
existing RPR protocols will break, and we're
going back to ground zero.
If the above are true, what is left for RPR to
standardize ?
One the flow control issue, let me clarify myself further.
I'm using the interface BW as the example
to illustrate the neccesity of flow control.
I'm against hop-by-hop pause type of flow control, but
I'm for the end-to-end rate
control type of flow control. It should be classified as part
of the RPR QoS mechnism.
What I'm saying is that we should standardize some sort of
signalling message between
destination RPR node and source RPR node. Flow control is not
special property of L4
protocols, I do feel it should exist in RPR L2
protcols.
William
----- Original Message -----
Sent: Tuesday, October 17, 2000 9:11
PM
Subject: RE: RPR multicast issue
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
----- 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
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/
-------------------------------------------------------------------
|