RE: [RPRWG] a problem about B-CIR
Jiangzhou,
They may or may not physically have buffers in your implementation. This is strictly an implementation decision that is beyond the scope of the standard. Their may not even be any physical correspondence to a stage queue in your implementation. This is there merely to act as a means of describing the behavior of the system.
Think of the stage queue as a pipeline to the transmit. If your implementation can fetch the frames from the client with zero delay, then your stage queue can be zero bytes long. If your implementation takes 250 ns to start getting the first byte of the next frame from the client, then your stage queue needs to hold at least 20 ns of data.
In any case, the stage queue is just used to describe the process of selecting the next frame to send. As soon as it has been selected, it is considered to have been sent into the MAC and is guarantied to be sent at the next opportunity to send a frame from the stage queue, so there is no head of line blocking which might impact the guaranties of other frames behind this one.
jl
-----Original Message-----
From: Jiang zhou [mailto:zjiang@xxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, April 01, 2003 10:28 PM
To: John Lemon; RPRWG (E-mail)
Subject: Re: [RPRWG] a problem about B-CIR
Hi, jl
If the shappers has not buffer and stage queue has not buffer too, when
the stage transmit a 9000 bytes class C frame the client has the class A
frame with length 64bytes to send, how does the stage process this class A
frame? The stage can't disrupt the C frame trasmit. So the A frame can't be
sent before the class C frame is sent out. So this is not guaranteeed the
class A service.
Best Regards
Jiangzhou
----- Original Message -----
From: "John Lemon" <JLemon@xxxxxxxxxxxx>
To: "Jiang zhou" <zjiang@xxxxxxxxxxxxxxxxxxx>; "RPRWG (E-mail)"
<stds-802-17@xxxxxxxx>
Sent: Tuesday, April 01, 2003 8:21 AM
Subject: RE: [RPRWG] a problem about B-CIR
Jiangzhou,
Don't think of the "shapers" in the MAC as maintaining shaping queues. Think
of them as shaping the traffic based on queues maintained in the client.
(Whether the client maintains 1 queue for all B and C, 1 for all B and 1 for
C, or 1 each for B-CIR, C-EIR, and C does not matter to the MAC or to this
discussion.)
The prioritization of B-EIR over C is done by the stage queue state machine
which accepts B-EIR frames in preference to C frames.
There is no advertisement of rateA1 or rateB. The algorithm has been
designed to guarantee that each station gets their allocated rateA1 and
rateB without them being advertised, as long as the sum of all allocated
traffic does not exceed the capacity of the links over which they flow.
jl
-----Original Message-----
From: Jiang zhou [mailto:zjiang@xxxxxxxxxxxxxxxxxxx]
Sent: Saturday, March 29, 2003 12:15 AM
To: RPRWG (E-mail)
Subject: [RPRWG] a problem about B-CIR
Hi,ALL
I have two simple problem on the draft2.1.
If the client's traffic B-CIR enter the shaperB and B-EIR enter the
shperC. How to guarantee the class B traffic in shaperC has high priority
than class C in shapeC?
The classA0 can be informationed to other stations by TLV message on the
ringlet. But how to information the B-CIR rate? If the other station don't
konw the each station B-CIR like the rateA0, how to guarantee the allocated
B-CIR for a station?
Best Regards
Jiangzhou