|
Necdet, your response to Raj provides an
opportunity to remind everyone that although pseudo-code may be an excellent way
to get some idea of how standards compliant hardware could work, it is an
exemplary implementation only, and is in an informative, not normative standard,
which is where it belongs. Necdet, I don't find any fault in your
pointing to the pseudo-code to show how things might work. However, it
is vital that the IEEE 802.17 standard has a normative portion that
precisely and comprehensively defines standard based behavior for all
compliant hardware. I expect we will need the equivalent of state
machine diagrams and tables to accomplish this vital function.
Best regards,
Robert D. Love Chair, Resilient Packet Ring Alliance President, LAN
Connect Consultants 7105 Leveret Circle Raleigh, NC
27615 Phone: 919 848-6773 Mobile: 919
810-7816 email: rdlove@xxxxxxxx
Fax: 208 978-1187
----- Original Message -----
Sent: Wednesday, March 06, 2002 2:39
PM
Subject: Re: [RPRWG] Single and dual
transit buffer MACs
Raj,
If you look at the psuedo code at Annex H
page 247 line 3:
UpdatedEveryClockCycle(Station * sPtr)
{
// tokenOctets is
decremented by 1 for every LP/eMP octet that is transmitted by the client.
// A packet is sent to completion, why is the below check here?
if
((sPtr->addRateCongestion < sPtr->allowRateCongestion) &&
(sPtr->fwdRate + sPtr->addRate + sPtr->rate_iMP < MAX_LRATE -
sPtr->reservedRate) &&
... )
sPtr->addRateOk =
TRUE; // true means OK to send client packets
This check ensures that there is enough BW at the outgoing link for the
reserved traffic, otherwise client will not be able to add eMP or LP packets
to the ring (this will reduce the advertised fair rate as well). This will
ensure that there is enough BW reserved on the link.
Please let me know if you have any questions or comments.
Thanks.
Necdet
Raj Sharma wrote:
I have some concern with the
way in which co-existence of Single Transit Buffer (STB) MAC and Dual
Transit Buffer (DTB) MACs on the same ring has been approached in draft 0. I
thought I voice my concerns to the working group on the reflector to enable
some dialog in resolving this concern while I also file my
comments.
I think the best place to start would be
at Clause 9.3, page 70, lines 3 and 4 which is: "If a ring consists of mixed RPR MACs
(single and dual transit buffer nodes), the fairness scheme will needto interact without disadvantaging any other
node on the ring."
First
disadvantage stems from the special accommodations to be made in the DTB
MACs to support performance requirements while using STB MAC at other nodes.
This requirement is stipulated further down in the same Clause 9.3, page 70,
lines 11 through 13. This stipulates that DTB MAC requires a rate shaper to throttle ring
outgoing rate to no more than 95% of the link rate. The only way a loss-less
MAC (as stipulated in 5.3.2, page 33, line 41) can do this is to buffer
frames when instantaneous rates exceed 95%. Further, if such traffic shaper
is classless than HP priority traffic could be subjected to further
buffering in this traffic shaper leading to contradiction of clause 3.1,
which requires HP traffic to have no more transit delay than one frame-time
through transit nodes.In other words
defining a RPR standard to accommodate STB MAC is not free of cost in terms of implementation and complexity in the
standard.
Raj
Colleagues,Draft 0.1 has been up on the
RPR web for a week now, and I have yet to see any
significantdialog on the issues that have been outlined in the draft by the
editors. (I also have notreceived any formal comments from RPR WG members.) Please note
that there is onlyabout a week left to go in the comment period, and about ten days
to the meeting, so Istrongly urge all concerned parties to start their comments about
these issues now.Best
regards,- Tom
AlexanderChief Editor, RPR
WG
|