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
>