RE: [RPRWG] What rcvdFairRate should be used if SC-FCM are not being received?
Necdet:
Looks like I have a couple of comments to submit when the comment period for
D2.1 opens up. I will ensure these are added at that time.
1) Initial value for rcvdFairRate.
I do wonder about the use of unreservedRate, since this implies the
downstream node is congested. If this is the case, rcvdTTL, rcvdRI, recdSA
and downstreamCongested also need initial values in case the math allows
Table 9.5, Row 2 Line 24-27 to be executed. Using FULL_RATE will avoid this.
2) The TTL decrement for SC-FCM packets regenerated from received
rcvdFairRate.
Regards,
Michael Allen
-----Original Message-----
From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
Sent: Monday, January 20, 2003 3:50 PM
To: Michael Allen
Cc: John Lemon; stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] What rcvdFairRate should be used if SC-FCM are not
being received?
Michael,
Thanks for catching the TTL decrement issue for fairness frames. We need to
modify either Table 9.x or Table 6.17 to decrement TTL of fairness frame as
you
proposed. If we do it in clause 9, I prefer it to be done in Table 9.2 as
soon
as frame is received. Would you be submitting a comment for it?
Thanks.
Necdet
Michael Allen wrote:
> Necdet:
>
> I am not sure I agree with your answer for 3). My response is marked
[MDA]:
>
> Regards,
>
> Michael
>
> -----Original Message-----
> From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
> Sent: Monday, January 20, 2003 2:32 PM
> To: Michael Allen
> Cc: John Lemon; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] What rcvdFairRate should be used if SC-FCM are not
> being received?
>
> Michael,
>
> Please see my comments.
>
> Thanks.
>
> Necdet
>
> Michael Allen wrote:
>
> > John:
> >
> > Thanks for your answers. I must admit, I missed the Clause 11 statement
> > about missing SC-FCM messages. Shouldn't the Fairness state machines
have
> > some states that reflect the missing messages and generate a failure
> > indication to the protection state machine?
> >
> > It looks like the initial value of rcvdFairRate has proponents for two
> > values:
> > FULL_RATE
> > unreservedRate
>
> I would say unreservedRate.
>
> >
> >
> > Also, some extra questions...
> >
> > 1) In Table 9.2, "wrappedRing" is not defined. Is this meant to mean "I
am
> > wrapped", or "the ring is wrapped somewhere"?
>
> A wrapping protection somewhere on the ring.
>
> >
> >
> > 2) In Table 9.2, for the wrapped congested case, shouldn't the formula
be:
> > hopsToCongestion = hopsToWrappedDownstreamStation + (256 - rcvdTTL);
> > Assuming hops are not decremented on the "wrong" ring ID.
>
> Any packet going beyond WrappedDownstreamStation would go through the
> congestion
> point if the congested station is on opposite ringlet. Hence, the table is
> right.
>
> >
> >
> > 3) In Table 9.5, Row 2, Line 26 (msg.TTL = rcvdTTL), shouldn't this be
> > replaced with:
> > if (rcvdRI == ringId)
> > {
> > msg.TTL = rcvdTTL - 1;
> > }
> > else
> > {
> > msg.TTL = rcvdTTL;
> > }
> >
>
> Table 9.5 assumes that data path already decremented TTL based on the
rules
> described in clause 6. So TTL is not decremented in FCU. Hence, the table
> 9.5
> row 2 is right.
>
> [MDA]: An SC-FCM would enter Table 6.17, and pass Row 9 moving to state
> TEST.
> [MDA]: Next, Row 13 would match moving to state COPY
> [MDA]: Next, Row 21 which performs copyToControl(). This function does not
> decrement
> any TTL field.
> [MDA]: If the packet is an SC-FCM, it is discaarded in Row 27 (after
having
> the TTL
> decremented), but the packet has already been delivered to the
> control processor.
>
> [MDA]: As such, I still believe the code I propose above is needed in the
> fairness
> message processor.
>
> >
> > Regards,
> >
> > Michael Allen
> >
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of John Lemon
> > Sent: Monday, January 20, 2003 11:21 AM
> > To: Michael Allen; stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] What rcvdFairRate should be used if SC-FCM are not
> > being received?
> >
> > Michael,
> >
> > My answers:
> >
> > 1) Good catch. It is not stated, and therefore needs to be. (I'll expect
a
> > comment from you against D2.1 to address this issue.) My recommendation
> > would be to initialize the last rcvdFairRate with the same value the
> > localFairRate is initialized with.
> >
> > 2) From a fairness control unit point of view, it does not time out.
(See
> > (3) for why it doesn't need to.) Whatever the last one was, is the one
> used.
> >
> > 3) Yes. Note that this is already specified in Clause 11.
> >
> > John Lemon
> >
> > -----Original Message-----
> > From: Michael Allen [mailto:michael_allen@xxxxxxxxxxxxxxx]
> > Sent: Sunday, January 19, 2003 2:05 PM
> > To: stds-802-17@xxxxxxxx
> > Subject: [RPRWG] What rcvdFairRate should be used if SC-FCM are not
> > being received?
> >
> > In section 9.3.1 of D2.0, it indicates that the most recently received
> > rcvdFairRate value should be used in the aging interval calculations.
> >
> > My questions relate to this.
> >
> > 1) What rcvdFairRate should be assumed if a rcvdFairRate has *never*
been
> > received. Should a rcvdFairRate of FFFFh be assumed initially?
> >
> > 2) What rcvdFairRate should be assumed if a rcvdFairRate has not been
> > received for "a while" (like 10 or N intervals), but has been received
at
> > least once. Should a rcvdFairRate of FFFFh be assumed after this period?
> >
> > 3) Should a Signal Fail indication be sent to the Protection Machine if
2)
> > occurs?
> >
> > Regards,
> >
> > Michael Allen
> > Chip Engines, Inc