Re: [RPRWG] control TTL (the 255-station and 2000-km issue)
David,
David James wrote:
>
> Mike,
>
> Comments solely on the control TTL subject:
>
> > I do not believe that one does TTL decrememnt on the
> > opposite ring. Therefore 255 nodes is still possible.
>
> I do not believe that no-TTL-decrement on the opposite
> ring works, and therefore cannot be assumed.
> 1) Its not clear this would work for discovery and
> fairness (actually, its also not clear they have
> fully considered wrap).
I believe it will work, but I also agree that the work
should be done to prove it one way or another.
> 2) The original no-TTL-decrement proposal has been
> shown to fail, as it cannot scrub a corrupte frame
> that circulated on the wrong ringlet.
Which I showed a fix for and you discuss in 3).
> 3) In response to (2), some folks believe that the
> fix would be to do one of two things on the return
> run, depending on the topology discovery state:
> a) Don't decrement, if the topology appears wrapped.
> b) Do decrement, if the topology appears unwrapped.
> The problem with (3), which you seem to advocate,
> is the time gap between the wrap action and the
> the distribution/settling of the wrap state information
> in other stations. During this time difference, any
> and all TTL-strip based frames will be discarded.
A good point david, in response please consider the following
Never decrement when on the wrong ring. Once the wrap
state is left, kill the packet if the ring id
is wrong. THus going into wrap does not cause the
packets to be prematurely lost. When leaving wrap
the packets will be killed once everyone knows
the wrap is over.
Please note this was hinted at in the pseudo code I put in
but not explicitly enough.
>
> Since the no-TTL-decrement protocol (which is not well
> documented, I think, in D0.3) doesn't work, I assume
> the fix will be to decrement always when passing through
> stations. Thus, 127 is the maximum number of supportable
> stations if the TTL is 256. With that working assumption,
> which is _far_ greater than any conceivable configuration,
> we are not explicitly prohibited for doing more robust
> TTL update protocols, but could use a variant of (3) if
> one could actually be documented in detail and its dependency
> on the discovery protocol were well documented as well.
> (Hmm, are the topology discovery messages subject to the
> no-decrement-on-return as well? Could become a catch-22).
>
> > 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.
>
> This situation of source disappearance is easily avoided
> by flooding frames from one station with a destination
> address of that station's upstream station.
> This is more efficient anyway. Then, the destination
> strips the frame: no problem.
>
> The "slick trick" mentioned below is only necessary when
> the DSID and SSID both disappear, in which case that trick
> works unless more-than-1/2 of the stations disappear.
>
> > 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.
>
> I believe the slick trick works, but always welcome comments pointing
> out flaws in that belief. I believe it would be more
> productive to illustrate the particular scenerio that you
> believe to be a concern, rather than make otherwise
> unverifiable comments such as "does not work".
>
David, I gave an example, but I was clearly overly terse in
describing it. Let me try it again.
here is the terse example
> > 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.
>
In SIMPLE bridging a packet comes onto a ring whose DA and
SA do not appear on the ring. Even assuming a ring local
DSID and SSID being layered, the DSID does not exist on
the ring, so it must be flooded everywhere. Therefore,
the only way the packet can be stripped is by source
stripping or TTL decrement. If the source bridge then
goes bye-bye only TTL decrement will remove the packet.
Therefore, the TTL mechanism must be robust.
> The way for evaluating concerns such as "does not work" is
> to field the question to the flooding task group of BAH, so
> a better reviewed and documented conclusion can be provided to
> the working group.
I did not notice which of the many "lists" this came in on and
just hit reply. I will be happy to forward it to the BAH list.
cheers,
mike
>
> 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 Mike Takefman
> > Sent: Friday, June 21, 2002 7: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
> >
--
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