RE: [RPRWG] A problem with fairness messages
Necdet,
That is true. However, from an architectural standpoint
the function of parsing that field belongs in the FCU
and not in the MAC receive logic.
-Anoop
> -----Original Message-----
> From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
> Sent: Friday, June 14, 2002 10:46 AM
> To: Anoop Ghanwani
> Cc: 'John Lemon'; 'stds-802-17@xxxxxxxx'
> Subject: Re: [RPRWG] A problem with fairness messages
>
>
> Anoop,
>
> Byte 9 of fairness message contains a "fairness message type"
> if it is 0 it
> is type-A , if it is 1 it is type B. (version field: clause 9.6.4.1 of
> D0.2) (fairness message type: clause 9.4.10.1 of D.3).
>
> So they are distinct. You do not need a DA or TTL value to
> determine the
> type.
>
> Thanks.
>
> Necdet
>
> Anoop Ghanwani wrote:
>
> > John,
> >
> > Thanks for pointing that out. When I thought of
> > the issue, I missed the part that TTL stripping
> > would take care of it.
> >
> > -Anoop
> >
> > > -----Original Message-----
> > > From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> > > Sent: Thursday, June 13, 2002 5:15 PM
> > > To: 'Anoop Ghanwani'; 'stds-802-17@xxxxxxxx'
> > > Subject: RE: [RPRWG] A problem with fairness messages
> > >
> > >
> > > Anoop,
> > >
> > > The other key difference is that Type A messages have a TTL
> > > of 1, whereas
> > > Type B messages have a TTL of 255. Therefore, Type A
> messages will be
> > > stripped based on TTL value, whereas Type B messages will
> be source
> > > stripped.
> > >
> > > jl
> > >
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> > > Sent: Thursday, June 13, 2002 4:49 PM
> > > To: 'stds-802-17@xxxxxxxx'
> > > Subject: [RPRWG] A problem with fairness messages
> > >
> > >
> > >
> > >
> > > In the current version of the draft, we have:
> > > - Type A fairness messages that are propagated
> > > hop-by-hop; and
> > > - Type B fairness messages that are broadcast.
> > >
> > > However, fairness messages do not contain
> > > a destination address, and the only thing that
> > > identifies them as fairness messages is the
> > > 2-bit "Packet Type" value in the ring control
> > > field. This doesn't tell us whether the message
> > > is Type A or Type B; that is done by the fairness
> > > control header which is interpreted in the FCU.
> > >
> > > This means that both Type A and Type B messages
> > > must essentially be "dropped" (i.e. stripped)
> > > from the ring and passed to the fairness control
> > > unit (FCU). The FCU then discovers that the frame
> > > is a Type B message and "adds" it back to the ring.
> > > This is not broadcast behavior from the standpoint
> > > of the RPR MAC.
> > >
> > > There are two possible solutions for this problem:
> > > 1 - Introduce a destination MAC address in fairness
> > > messages; or
> > > 2 - Use two separate "Packet Type" values --
> > > one to indicate a Type A fairness message and
> > > one to indicate Type B fairness message.
> > >
> > > I personally prefer #1 and was going to put in
> > > a comment with respect to that, but I thought I'd
> > > share this with the list to see what others feel.
> > >
> > > -Anoop
> > > --
> > > Anoop Ghanwani - Lantern Communications - 408-521-6707
> > >
>