RE: [RPRWG] A problem with fairness messages
John,
For the moment, I would prefer to say that type-A messges
are coded to be stripped by the downstream station.
Some others think that TTL would start at 255 and be decremented,
with other stations (of lower congestion) simply decrementing TTL
and passing the message through. This makes it easy to determine
the source of the message, while enforcing a common convention
(from at least this perspective) of TTL updating.
On the distinctive uses for TTL, only the distance from source
is consistent with the simple start-at-255 methodology, so I
continue to advocate one and only one TTL update protocol.
So, I think this one needs further discussion on encoding.
I would (for the moment) mention downstream addressing as
a need to be addressed by the BAH, which is addressing the
addressing issue currently.
DVJ
David V. James, PhD
Chief Architect
Network Processing Solutions
Data Communications Division
Cypress Semiconductor, Bldg #3
3901 North First Street
San Jose, CA 95134-1599
Work: +1.408.545.7560
Cell: +1.650.954.6906
Fax: +1.408.456.1962
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx
>>-----Original Message-----
>>From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
>>[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of John Lemon
>>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
>>