Re: [RPRWG] What rcvdFairRate should be used if SC-FCM are not being received?
I had submitted a comment on the same issue (TTL decrement in table 9.5)
for the last meeting.
Draft2.1 could be updated as a response to that comment and Table 9.2
could reflect the change.
Prasenjit Biswas
Necdet Uzun wrote:
>
> 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