Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RPRWG] Single and dual transit buffer MACs



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

-----Original Message-----
From: Tom Alexander [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
Sent: Friday, March 01, 2002 3:00 PM
To: stds-802-17@xxxxxxxx
Subject: [RPRWG] Dialog on issues, comments, etc.
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
begin:vcard 
n:Uzun;Necdet
tel;work:408 853 0461
x-mozilla-html:TRUE
url:www.cisco.com
version:2.1
email;internet:nuzun@xxxxxxxxx
adr;quoted-printable:;;Cisco Systems, Inc.=0D=0A170 W. Tasman Drive SJ-16-3=0D=0A;San Jose;CA;95134;
fn:Necdet Uzun
end:vcard