1) RPR does not have to be homogeneous; however it
does make the system and network design easier.
Day one, the forwarding decision as to which
direction to forward a packet can be determined by hop count.
How to divided the BW in a ring in the
protected case is also easier.
2) For a chain of nodes, RPR provides better BW utilization
and fairer access to all access ports on the ring than
a chain of switches.
Sanjay.... answer to your question :
The ring ingress port is an aggregate
port from many upstream ports. RPR should be distinct in
its approach to provide BW fairness.
We have looked at queuing schemes that tries to
give the same performance. However,
the problem is scalability. The RPR protocol can be build
to 10G and even to 40G today.
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?
Regards,
Harry
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/
-------------------------------------------------------------------
|