Re: [RPRWG] A problem with fairness messages
Anoop,
I do not understand what the "from an architectural standpoint the function
of parsing that field belongs in the FCU
and not in the MAC receive logic" means. We are letting TTL field (an L2
header field) to be examined by FCU to determine TTL_to_congestion.
Thanks.
Necdet
Anoop Ghanwani wrote:
> 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
> > > >
> >