RE: [RPRWG] A problem with fairness messages
Hi,
I am just catching up on this thread.
Is the TTL being set to 255 just for congestion control
messages or also data frames in general. We still need
to be able to set the TTL to something less than 255 to
allow for bidirectional flooding of user data frames.
thanks,
robert
-----Original Message-----
From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
Sent: Saturday, June 15, 2002 2:13 AM
To: 'Necdet Uzun '; Anoop Ghanwani
Cc: ''John Lemon' '; ''stds-802-17@xxxxxxxx' '; Komal Rathi
Subject: RE: [RPRWG] A problem with fairness messages
Necdet,
Maybe that needs to change too! :-)
With the topology database and the source MAC address,
we have enough information to get the TTL_to_congestion
without having to bother with the TTL of the packet.
However, the problem there is how to handle cases
when topology hasn't yet converged.
In any case, the TTL is part of the MAC function,
but digging deep into a control packet is not. In
fact, as I've pointed out many times before, 802 uses
special multicast addresses to identify control packets.
AFAIK, (and I could be wrong but I need an example here)
802 MACs don't have to dig even beyond the destination
address to identify a control packet.
Finally, Komal actually pointed out to me that fairness
messages are always sent with a TTL of 255 in order to
get the TTL_to_congestion, so John's analysis was actually
incorrect. TTL stripping cannot really be used.
-Anoop
-----Original Message-----
From: Necdet Uzun
To: Anoop Ghanwani
Cc: 'John Lemon'; 'stds-802-17@xxxxxxxx'
Sent: 6/14/02 3:10 PM
Subject: 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
> > > >
> >