----- Original Message -----
Sent: Friday, June 21, 2002 2:19 PM
Subject: RE: [RPRWG] control TTL (the
255-station and 2000-km issue)
I may want to tell the packet to travel on the opposite ring
due to traffic considerations, or other considerations, instead of shortest
hop.
There is a potential that the ttl will not be decremented. And
travel the ring continuously.
Possible rule could be if the ring is in wrap mode, instead of
steering, and the packet is in the wrong ring direction then don't decrement
the ttl.
Alternate option is for the "edge" nodes to decrement. I
define the edge node to be the node where the wrapping occurs. This will also
allow for packets to discarded for unreachable destinations.
Joe
-----Original Message-----
From: Mike
Takefman [mailto:tak@xxxxxxxxx]
Sent: Friday, June 21, 2002 10:56 AM
To: Nader Vijeh
Cc: stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] control TTL (the 255-station and 2000-km
issue)
Nader,
solely with regard to the question of TTL decrement on
wrap.
I do not believe that one does TTL decrememnt on the
opposite ring. Therefore 255 nodes is still possible.
To avoid packet duplication in a simple bridged
enviroment
when the bridge which injects the packet
then disappears
requires TTL to be set to the number
of nodes in the ring
and not 2N. Note: the slick
mechanism that DVJ suggested
to look at the DA and
attempt to kill the packet once it
leaves its scope
does not work in this case either.
IMO (and I've been known to be wrong :) )
If (packet_ring_id == ring_id )\
{
decrememnt TTL
/*
this is the normal case
*/
}
Else
{
if
( ring is not in a protection state )
{
decrememnt TTL (or kill packet)
/*
packet has been locked onto the
wrong ring
and should be
destroyed
*/
}
/*
the missing else clause is the case where the packet
is on the opposite ring due to a wrap and is
travelling to the desination and will be
grabbed
once it wraps back onto the other
ring
*/
}
mike
Nader Vijeh wrote:
>
> 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
> >
--
Michael
Takefman
tak@xxxxxxxxx
Manager of
Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000
Innovation Dr, Ottawa, Canada, K2K 3E8
voice:
613-254-3399 fax: 613-254-4867
- - - - - - - Appended by Scientific-Atlanta,
Inc. - - - - - - -
This e-mail and any attachments may contain information
which is confidential, proprietary, privileged or otherwise protected by law.
The information is solely intended for the named addressee (or a person
responsible for delivering it to the addressee). If you are not the intended
recipient of this message, you are not authorized to read, print, retain, copy
or disseminate this message or any part of it. If you have received this
e-mail in error, please notify the sender immediately by return e-mail and
delete it from your computer.