|
Well RPR defines things like protection
switching as well which is not there elsewhere. When we define mac level
flow control we should make sure that it is not detrimental to upper layers
(L3, L4) in performance.
-Sanjay K. Agrawal
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/
-------------------------------------------------------------------
|