RE: [RPRWG] control TTL (the 255-station and 2000-km issue)
All,
I think Tom's point of raising the issue, by having a number, is well taken.
I also agree with Tom that MACs need not have distance requirements and that
distance is phy dependent. However, this MAC, like all other MACs, may have
time domain related limitations that can translate to distances. These
limitations are independent of the phy distance limitations and are an
inherent property of the MAC protocol.
As an example, CSMA/CD has a limitation, based on 'slot time', which was a
function of its collision detection and carrier sense mechanisms. This in
turn sets a maximum for the network diameter (as an inverse function of the
bit rate).
RPR may have such characteristics due to its fairness mechanism. I say 'may'
as it is not possible to discern these limitations from the current contents
of the draft and additional work is needed to quantify any span or diameter
(circumference) limitations . In which case, these need to be specified in
'Bit Times', in order to account for different phy speeds.
As for the number of stations, I agree with Tom that with an 8 bit TTL field
and double decrement on wrap, the absolute maximum will have to be 127 (not
counting 0).
Nader
-----Original Message-----
From: Tom Alexander [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
Sent: Thursday, June 20, 2002 6:50 PM
To: 'John Lemon'; stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] control TTL (the 255-station and 2000-km issue)
John and the P802.17 WG,
I should begin by stating that the editor of Clause 1 had nothing to
do with this. Comment #155 was redirected to Clause 0; I handled it
and implemented the change as a result of the resolution. If there is
any fault here, I take full responsibility.
Two different issues have been raised. The first is that Clause 1
contradicts the rest of the draft, in that the "127 stations" should
have been 255. The second is that Clause 1 introduces new normative
material, in that the 2000 km objective should have been stated elsewhere.
I will treat these separately. Please bear with the lengthy answer.
First, the "127 stations". It is true that the number "255" does indeed
occur in Clause 8 (the only place where it is explicitly related to some
sort of limit) and then in various other clauses where it is used as the
initial value for the TTL field. However, Clause 8 states that the 8-bit
TTL allows for 255 "nodes" on the ring, not "stations". I was originally
under the impression that a "node" was the same as a "station". However,
the CRG appeared to be of the opinion that a "node" was effectively an
attachment point; a station had two attachment points, and decremented
the TTL twice whenever the ring wrapped and a packet passed through it
twice. This appears to be borne out, for example, by Figure 6.12, which
seems to specify TTL behavior that only allows 127 stations on the ring.
As there were no dissenting views in the CRG, and the normative text in
the draft seemed to concur with their view, I assumed that it would be
acceptable for Clause 1 to state that RPR provides for 127 stations
on a ring. There is no reference anywhere in the draft to 255 stations.
(There IS a problem in that the term "node" is used but not defined, but
that's another matter.) I do not see how the defined and normative behavior
could allow for more than 127 stations, and therefore I don't see any
contradictions, but perhaps someone will educate me on this.
In hindsight, though, it would have been better for me to have socialized
this change with the WG as a whole prior to implementing it, regardless of
what the CRG said, as it was a fairly significant issue relating to
previously passed motions and objectives. I apologize to the WG for this
error, and will see that it is not repeated.
The second issue is another matter altogether. The question is whether the
distance should be normatively specified in another clause before the
overview is permitted to provide an actual number.
A "normative" specification is one for which a compliance test can be
devised and applied to a piece of equipment or other artifact. I believe
that the RPR standard CANNOT normatively specify a minimum distance of
2000 km, or any other number for that matter, for the following reasons:
1. The RPR standard defines a MAC, that is, a link layer protocol. Explicit
distance specifications are associated with PHYs, not MACs. It is not
meaningful to specify a distance over which a data-rate-independent and
PHY-independent protocol layer will operate.
2. It will be observed that a compliant RPR interface can use 1 Gigabit
Ethernet PHYs. Further, note that the distance covered by a Gigabit Ethernet
PHY ranges anywhere from 25 meters to 5 km, depending on the PHY type
(giving a maximum ring circumference between only 6 km and 1250 km, even
assuming 255 stations). Clearly, a normative requirement that all RPR
equipment be conformance tested to enable a given (large) ring diameter
to be achieved is hardly desirable, considering that such a wide range
of PHYs can be used; some or all of the PHYs would be non-compliant.
An even bigger issue exists with the SONET PHYs, which do not even
specify a distance limit, but instead a link budget to which a link
should be engineered. Just what do you do in this case? Also, what
happens if the ring for which compliance is being tested has a large
number of regens?
3. In the case of a logical protocol such as RPR, it is much more useful
to specify timers and delays (perhaps even in units of bit times as far
as possible) rather than some sort of distance. An implementation can
be tested against time delays or logical bit periods. Testing a MAC chip
for distance is incomprehensible.
4. Even if the WG arbitrarily decided to provide a normative distance
requirement, there is no single clause to which it belongs. For instance,
it might be put into Clause 10. In this case, Clause 10 would also have
to specify all the test conditions (data rate, PHY type, cable type,
number and type of connectors, etc.) which the implementer should use
as part of the compliance test, as it is impossible to determine whether
an implementation is compliant to a distance requirement without all
of these physical parameters being properly configured. It is hardly
appropriate or useful for Clause 10 to spend a lot of effort specifying
physical parameters for a distance compliance test, and the same goes
for all of the other clauses.
If there cannot be a normative distance specification, should there be
a stated distance objective? Absolutely. The RPR WG has claimed that
it is creating a MAN/RAN standard; it needs to state up front what
it views as a MAN/RAN. In addition, the user needs to know from reading
the standard where he/she can apply this technology, and the implementer
needs background as to where some of the timers and delay requirements
in the protocol clauses came from. The distance objective cannot be
normative - i.e., a requirement placed upon implementers - but is instead
informative - a goal that the standards writers kept in mind when devising
the protocol. As it pertains to the whole of the specification, and not
any single clause, it belongs in the overview.
Therefore, I disagree completely that any new normative material has been
introduced by placing a distance objective (not requirement) in the
introduction clause. I also assert that this is the only place where it
makes logical sense to place such an objective. I think the wording could
be considerably improved, but the number should stay in Clause 1.
Best regards,
- Tom Alexander
Chief Editor, P802.17
-----Original Message-----
From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
Sent: Wednesday, June 19, 2002 10:47 AM
To: Tom Alexander; stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] control TTL
Tom,
My problem is not with the resulting numbers. My problem is with the
process. You state: "the only means available to the editor of satisfying
that resolution was to put down "127" as the number of stations in the
objectives". This is not correct. The editor should have reflected what is
stated throughout the rest of the draft.
In the case of node numbers, the draft clearly lists 255 in clauses 8, 9,
10, 11, and E. If someone wants the number changed, they should address
those sections, not clause 1.
In the case of distance, since the draft says nothing, clause 1 should say
nothing. If people want a maximum distance specified, they should direct the
comment to the appropriate normative clause (10?), not clause 1.
And in all cases, the editor of clause 1, and you as the chief editor,
should ensure that a) contradictions are not introduced, and b) informative
clauses do not introduce new material that is effectively normative in
nature.
jl
-----Original Message-----
From: Tom Alexander [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
Sent: Tuesday, June 18, 2002 7: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]
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]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]
> 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
>