|
Yes. In my term, it is from destination RPR node to source RPR
node on a single ring,
and it should be class dependent.
Scalability is a problem, but RPR do have a upper limit
(128/256 ?) node per ring, I think
that will help.
William Dai
Williams...... On your comments, I think the question is
related to the Fairness definition. Is your end-to-end
definition: from egress to ingress ports on
a single ring?
William Dai wrote:
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) assome
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 bea homogeneous one in each direction, the existing
RPR protocols will break, and we'regoing 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 ratecontrol 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
betweendestination RPR node and source RPR node. Flow control is not special
property of L4protocols, 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 fairnessof ring resource access, but there is
nothing to prevent traffic flow into the same destination nodefrom both
East and West direstions at the same time, i.e., input rate = 2x output
rate. That iswhy I'm saying that congestion could be worse on the RPR
acccess module than on the Ethernetaccess 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 trafficmanagment (along with buffering scheme) as
the higher layer task of switch/router, then theabove 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 Ethernetswitches is that RPR provide the
pass-through buffers, and RPR protocol is tightly coupled withit. Pause
type of flow control will break all the proposed schemes, and there is
potential ring lockupproblem 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/
------------------------------------------------------------------- --
Harry Peng
------------------------------------------------------------------
Dept: 1E11
Email: hpeng@xxxxxxxxxxxxxxxxxx
ESN: 39-52277
Phone 613-765-2277
Fax: 613-768-4904
Web: http://skywww/~hpeng/
-------------------------------------------------------------------
|