Re: [RPRWG] A problem with fairness messages
Guys,
I don't think its a big issue for the FCU to have a
forward path to the client for type 1.In fact
given the ability to define types 2 ... in the future
people building silicon probably want to make the
"routing" decision flexibly
mike
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
> > > >
> >
--
Michael Takefman tak@xxxxxxxxx
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 fax: 613-254-4867