|
Bob,
You are right. We need to have more detail on this in the normative
section (9.3) of the standard.
Thanks.
Necdet
RDLove wrote:
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
|