Re: [RPRWG] control TTL (the 255-station and 2000-km issue)
Joe,
if you want the packet to travel on the other ring for traffic purposes,
launch it there.
mike
> "Cordero, Joseph" wrote:
>
> 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