RE: [RPRWG] control TTL
Anoop,
Your reading is consistent with my memory,
as per the actual motion as well as the
motivation.
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 Anoop Ghanwani
>>Sent: Wednesday, June 19, 2002 7:13 AM
>>To: 'Harry Peng '; 'Tom Alexander '; 'stds-802-17@xxxxxxxx '
>>Cc: ''djz@xxxxxxxxxxx' '; 'John Lemon '; Anoop Ghanwani
>>Subject: RE: [RPRWG] control TTL
>>
>>
>>
>>
>>Harry,
>>
>>Per my reading, the objective says that we will support
>>at least 64 nodes "with an objective to go up to 255 nodes".
>>I assume that we have 2 separate numbers in the objective
>>because it was thought that that might be issues going
>>up to 255 nodes. I wasn't active in this group back then,
>>so I'm not sure why it was worded in this way.
>>
>>-Anoop
>>
>>-----Original Message-----
>>From: Harry Peng
>>To: Tom Alexander; stds-802-17@xxxxxxxx
>>Cc: 'djz@xxxxxxxxxxx'; John Lemon; 'Anoop Ghanwani'
>>Sent: 6/19/02 6:54 AM
>>Subject: RE: [RPRWG] control TTL
>>
>>
>>Point of order
>>
>>One of our objective voted in is to support 255 stations on a ring.
>>The motion was passed July 2001.
>>
>>Regards,
>>
>>Harry
>>
>>
>>-----Original Message-----
>>From: Tom Alexander [ mailto:Tom_Alexander@xxxxxxxxxxxxxx
>><mailto:Tom_Alexander@xxxxxxxxxxxxxx> ]
>>Sent: Tuesday, June 18, 2002 10:35 PM
>>To: stds-802-17@xxxxxxxx
>>Cc: 'djz@xxxxxxxxxxx'; John Lemon; 'Anoop Ghanwani'
>>Subject: RE: [RPRWG] control TTL
>>
>>
>>
>>John, David,
>>
>>Both of these numbers arose out of the resolution to
>>comment #155 on D0.2. Specifically, the comment wanted
>>distance, speed and number of stations on the ring to
>>be part of the statement of RPR performance objectives.
>>The group resolution was as follows:
>>
>> "Contributions are requested on the following topics:
>> what performance objectives (distance, speed, MAC
>> end-to-end delay, delay jitter, etc. for specific
>> configurations) should be specified? What should these
>> objectives be for the RPR MAC?
>>
>> Recommendations: The maximum number of stations should
>> be defined compatible with an 8-bit TTL field, as
>> determined by Clauses 6 and 11. The maximum ring size
>> should be set to 2000 km. As for the remainder,
>> contributions are requested."
>>
>>With regard to the distance, there is unfortunately no
>>clause in D0.2 where a distance is specified at all, let
>>alone in a normative manner. Therefore, the CRG followed
>>what it believed to be the stated intent of the WG, and
>>set the distance placeholder in D0.2 to 2000 km. There
>>was no intent that this should be normative; in fact, an
>>editor's note at the very beginning of Clause 1 explicitly
>>states that none of the material in the clause is
>>normative.
>>
>>With regard to the number of stations on the ring, the
>>resolution simply requests that the number of stations
>>should be defined 'consistent with an 8-bit TTL'. It was
>>stated at the time that an 8-bit TTL limits one to 127
>>stations (< 255 nodes, each station counting as two nodes)
>>to cover the case of a wrapped ring. Therefore, the only
>>means available to the editor of satisfying that resolution
>>was to put down "127" as the number of stations in the
>>objectives.
>>
>>It is entirely possible that one or both of the above
>>numbers is incorrect or unsatisfactory; this is why the
>>comment resolution group started off by requesting
>>contributions on the objectives. Clearly, the conversion
>>of the placeholders to actual numbers has had the beneficial
>>effect of sparking the discussions necessary to produce
>>such contributions!
>>
>>Best regards,
>>
>>- Tom A.
>>Chief Editor, P802.17
>>
>>
>>-----Original Message-----
>>From: David James [ mailto:djz@xxxxxxxxxxx <mailto:djz@xxxxxxxxxxx> ]
>>Sent: Tuesday, June 18, 2002 6:43 PM
>>To: John Lemon; 'Anoop Ghanwani'; stds-802-17@xxxxxxxx
>>Cc: Tom Alexander
>>Subject: RE: [RPRWG] control TTL
>>
>>
>>John,
>>
>>From my recollection, there were items that affected the whole
>>draft, rather than specific clauses, and this was one of them.
>>That ad-hoc resolution group addressed this and other issues,
>>or so I thought. Have to ask Tom Alexander on the details.
>>
>>Regardless of recollection, this number is consistent with
>>a past working group decision. There are painful repercussions
>>in having numbers set at 255, since the number of attachment
>>points (that can all be legally visited once) is twice the
>>number of stations and should be counted in the TTL field.
>>
>>And, I'm most interest in what possible technical reason
>>could be used to justify such a large number of devices?
>>Particulary when each chip may be required to support
>>things like discovery tables. No point is having all
>>chips support a large theoretical maximum, when it
>>rarely (if ever) will be utilized.
>>
>>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
>><mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx> ]On Behalf Of John Lemon
>>> Sent: Tuesday, June 18, 2002 5:44 PM
>>> To: 'Anoop Ghanwani'; 'stds-802-17@xxxxxxxx'
>>> Cc: Tom Alexander (E-mail)
>>> Subject: RE: [RPRWG] control TTL
>>>
>>>
>>>
>>> The maximum number of stations on a ring is 255, not 127. I have no
>>idea why
>>> someone changed clause 1; but clauses 8, 9, 10, 11, and E all use a
>>value of
>>> 255. And the resolution of comments 155 and 431 support this. The
>>Overview
>>> is informative, and is supposed to reflect a simple summary of what
>>has been
>>> decided in the normative clauses.
>>>
>>> (As an aside, while I have no problem with 2000 km as a recommended
>>limit,
>>> I'm also troubled that such technical changes are being made in the
>>Overview
>>> instead of one of the normative clauses. The Overview should be
>>reflecting
>>> what has been decided in the other clauses, not making its own
>>decisions.)
>>>
>>> jl
>>>
>>> -----Original Message-----
>>> From: Anoop Ghanwani [ mailto:anoop@xxxxxxxxxxxxxx
>><mailto:anoop@xxxxxxxxxxxxxx> ]
>>> Sent: Tuesday, June 18, 2002 3:47 PM
>>> To: 'stds-802-17@xxxxxxxx'
>>> Subject: [RPRWG] control TTL
>>>
>>>
>>>
>>>
>>> At the last meeting I had a comment requesting more
>>> information on why the control TTL is 2 bytes. The
>>> explanation provided was that 1 byte is not sufficient
>>> if we have 255 stations and are wrapping. With D0.3,
>>> the maximum number of stations is 127. So now I
>>> don't see a reason for a 2-byte control TTL. I'm
>>> about to submit another comment for this, unless I
>>> can be convinced of a technical reason for a 2-byte
>>> control TTL.
>>>
>>> -Anoop
>>> --
>>> Anoop Ghanwani - Lantern Communications - 408-521-6707
>>>
>>