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
> >