Re: [rprsg] (Terms & Defn) topology terms
Bob Love,
Today anyone can buy an bunch of ethernet switches and
hook them up and they work with no configuration. It
may not be optimal, but it will be acceptable.
RPR will be an inferior technology if it is not possible
for *some* implementations to work in a complete plug and
play manner.
For people who really want to do full provisioning, then
the box can clearly not send traffic to the ring until
the provisioning has occured. However, that is just one
application of RPR.
Alot of customers do not want to have to provision the
boxes at all. In this case having the boxes default to
either 1/N of the ring bandwidth, or the lowest
weighted value of ring BW is the "fair" solution.
The reason Cisco agreed to the friendly amendment to make
adding traffic optional, was to insure that those people
who have the provisioned view of the world were not
locked out of RPR implementation.
mike
RDLove wrote:
>
> Bob, I have a concern with your proposed "plug and play" definition.
> Assuming stations are assigned bandwidth and must live with that assignment,
> I see a potential fundamental problem with allowing the station to have
> access to put data on the ring before there has been any provisioning. This
> would be akin to someone buying a cell phone and expecting to be able to
> make calls with it, before a phone number has been assigned to it.
>
> Are there other opinions on this one?
>
> Best regards,
>
> Robert D. Love
> Chair, Resilient Packet Ring Alliance
> President, LAN Connect Consultants
> 7105 Leveret Circle Raleigh, NC 27615
> Phone: 919 848-6773 Mobile: 919 810-7816
> email: rdlove@xxxxxxxx Fax: 208 978-1187
> ----- Original Message -----
> From: "Bob Sultan" <Bob.Sultan@xxxxxxxxxxxxxxx>
> To: <stds-802-rprsg@xxxxxxxx>
> Sent: Thursday, May 24, 2001 4:19 PM
> Subject: Re: [rprsg] (Terms & Defn) topology terms
>
> >
> > Kanaiya,
> >
> > I was concerned that you wouldn't have the 'play' aspect of 'plug and
> play' if
> > you couldn't insert or copy traffic after you 'plug'. After looking at
> the
> > Microsoft 'plug and play' descriptions, I see now that it would be
> reasonable to
> > require that hardware configuration be automatic, but that the card need
> not
> > source or sink data traffic without provisioning. So, that might leave us
> with
> > the definitions:
> >
> > plug-and-play : The property that a station be operational some time
> after
> > physical insertion of the station into the ring and power-on of the
> station,
> > without a requirement for explicit configuration .
> >
> > operational : The state of a station in which it transits traffic and
> performs
> > control activities associated with the steady-state.
> >
> > Bob
> >
> > Kanaiya Vasani wrote:
> >
> > > The first part of Allan's email goes back to the definition of plug and
> > > play. My interpretation of the motion on plug and play is that the newly
> > > inserted node will provide a transit/tandem path for frames on the ring;
> > > supporting insertion of data frames without prior provisioning is
> optional.
> > >
> > > I agree with Allan that the definition of plug and play should capture
> the
> > > intent of the motion.
> > >
> > > - Kanaiya
> > >
> > > -----Original Message-----
> > > From: Allan Pepper [mailto:acpepper@xxxxxxxxxxxxxxxxxx]
> > > Sent: Thursday, May 24, 2001 9:51 AM
> > > To: stds-802-rprsg@xxxxxxxx
> > > Cc: Bob Sultan
> > > Subject: Re: [rprsg] (Terms & Defn) topology terms
> > >
> > > Bob,
> > >
> > > Should it not be possible to preclude the addition of ingress traffic
> until
> > > such
> > > a time as a new station has been provisioned? I believe that some
> companies
> > > wish
> > > to do this.
> > >
> > > Using transit is fine by me, I do think it will lead to confusion with
> > > transmit.
> > > They are both very similar visually and audibly. However, I have no
> problem
> > > changing to use whatever term the group decides is best.
> > >
> > > Thanks,
> > > Allan.
> > >
> > > Bob Sultan wrote:
> > > >
> > > > Brian, Allan,
> > > >
> > > > I agree that the disruption time should not be specified. Using the
> > > definition I suggested as a base,
> > > > this would leave us with:
> > > >
> > > > plug-and-play: The property that a station be operational some time
> after
> > > physical insertion of the
> > > > station into the ring and power-on of the station, without a
> requirement
> > > for explicit station
> > > > provisioning or configuration .
> > > >
> > > > Allan,
> > > >
> > > > I think it simplifies the definition to use the separately defined
> term
> > > 'operational'. I'm not sure why
> > > > the work 'optional' is needed for ingress traffic (although I do
> remember
> > > that this was discussed in the
> > > > meeting). If the station has ingress traffic and there is a default
> > > provisioning and the traffic is
> > > > consistent with that provisioning, then I would assume that an
> operational
> > > station would transmit that
> > > > traffic consistent with the rules for ingress traffic. Also, I
> normally
> > > expect that a plug-and-play
> > > > device would be fully operational with respect to control activities
> (not
> > > just the ability to insert
> > > > control messages).
> > > >
> > > > Your posting raises another terminology issue. You refer to 'tandem'
> > > traffic, rather than 'transit'
> > > > traffic. The term 'tandem' has the advantage that it is less likely
> to be
> > > mistaken for the term
> > > > 'transmit' than is the case with 'transit'. On the other hand,
> 'transit'
> > > seems more descriptive and
> > > > 'tandem' has an association with telephony.. This is clearly a key
> term,
> > > how do others in the group
> > > > feel about this?
> > > >
> > > > Bob
> > > >
> > > > Allan Pepper wrote:
> > > >
> > > > > Brian, Bob,
> > > > >
> > > > > I would prefer a definition for plug and play that avoids mentioning
> > > specific times for protection
> > > > > switching caused by inserting a station into a ring.
> > > > >
> > > > > The original intent of the term plug and play was to indicate that a
> new
> > > station could be inserted
> > > > > and pass tandem frames, insert control frames, and optionally insert
> > > data frames without any
> > > > > operator
> > > > > provisioning.
> > > > >
> > > > > Including Brian's suggestion, this would make the definition for
> > > plug-and-play:
> > > > > The property that a station be able to recieve and transmit tandem
> > > frames (and optionally insert
> > > > > data
> > > > > frames) some time after physical insertion of the station into the
> ring
> > > and power-on of the station,
> > > > > without a requirement for explicit station provisioning or
> > > configuration.
> > > > >
> > > > > Thanks,
> > > > > Allan Pepper
> > > > >
> > > > > Brian Holden wrote:
> > > > > >
> > > > > > Bob,
> > > > > >
> > > > > > Good definitions.
> > > > > >
> > > > > > The phrase "without disruption to transit traffic" in your
> definition
> > > of plug-and-play is TBD in
> > > > > > the standard. Unless we add specific capabilities in the
> standard, it
> > > is likely that there will
> > > > > > be at least 50 ms of disruption when you break the ring to put a
> new
> > > station in, and maybe more
> > > > > > when the ring is restored. Your definition can be changed to
> reflect
> > > the current state of the
> > > > > > motions by just dropping the words "without disruption to transit
> > > traffic and". Another
> > > > > > possibility is to change "without disruption" to "with minimal
> > > disruption" - either works for me.
> > > > > >
> > > > > > Thanks,
> > > > > > Brian H.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Brian Holden PMC-Sierra, Inc.
> > > > > > 3975 Freedom Circle, Santa Clara CA USA
> > > > > > +1.408.239.8123 Fax +1.408.492.9862
> > > > > > brian_holden@xxxxxxxxxxxxxx http://www.pmc-sierra.com
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Bob Sultan [mailto:Bob.Sultan@xxxxxxxxxxxxxxx]
> > > > > > Sent: Wednesday, May 23, 2001 8:30 AM
> > > > > > To: stds-802-rprsg@xxxxxxxx
> > > > > > Subject: Re: [rprsg] (Terms & Defn) topology terms
> > > > > >
> > > > > > Brian,
> > > > > >
> > > > > > I added your definition of plug-and-play to a new category
> called
> > > 'activation'. I also
> > > > > > added my own alternative, and a definition of 'operational'
> used
> > > in that definition.
> > > > > >
> > > > > > activation
> > > > > > plug-and-play : (Alt. 1) The requirement that a station be
> > > capable of Topology
> > > > > > Discovery and optional insertion and drop of user frames
> without
> > > manual intervention
> > > > > > other than the physical connection of the equipment .
> > > > > > (Alt. 2) The property that a station be operational some time
> > > after physical insertion
> > > > > > of the station into the ring and power-on of the station,
> without
> > > disruption to transit
> > > > > > traffic and without a requirement for explicit station
> > > provisioning or configuration .
> > > > > >
> > > > > > operational : The state of a station in which it transits
> traffic,
> > > inserts traffic consistent
> > > > > > with explicit or default provisioning, copies and/or strips
> traffic
> > > destined for the station, and
> > > > > > performs control activities associated with the steady-state.
> > > > > >
> > > > > > I modified 'topology database' and added 'topology discovery':
> > > > > > topology/routing
> > > > > > topology database : A representation of the connectivity and
> > > capabilities of stations and links
> > > > > > on the ring.
> > > > > > topology discovery : The process by which the connectivity and
> > > capabilities of the stations and
> > > > > > links on the ring is discovered by a newly added station.
> > > > > > protection (resilience)
> > > > > > I replaced the definitions of steering and wrapping:
> > > > > >
> > > > > > steering: Placement of a frame on the outer ring or inner ring at
> the
> > > ingress data-station based
> > > > > > on knowledge of the ring topology . Steering provides resiliency
> by
> > > directing frames on a path
> > > > > > that does not transit a failed transmission link or node.
> > > > > >
> > > > > > wrapping: The transit of a frame such that it is received on one
> > > transmission ring and
> > > > > > retransmitted on the opposing ring. Wrapping provides resiliency
> by
> > > allowing traffic to bypass a
> > > > > > failed transmission link or node on the ring.
> > > > > >
> > > > > > steering : The placement of a frame on a specific ringlet at the
> > > ingress station based on
> > > > > > knowledge of the ring topology .
> > > > > >
> > > > > > wrapping: The transit of a frame such that the frame is received
> on
> > > one ringlet and retransmitted
> > > > > > on the opposing ringlet . (footnote: The definition describes
> the
> > > case of a dual-ring as agreed
> > > > > > in the May meeting. In the case of a multi-ring, this might be
> changed
> > > to 'an opposing ringlet' or
> > > > > > 'a different (or alternate) ringlet'. It might also be unchanged,
> > > depending on what is considered
> > > > > > to be a useful definition of wrapping in the multi-ring
> environment.)
> > > > > >
> > > > > > Keep those definitions coming, I will repost the doc after we
> have
> > > some more.
> > > > > > Bob
> > > > > >
> > > > > >
> > > > > > Brian Holden wrote:
> > > > > >
> > > > > > > How about:
> > > > > > >
> > > > > > > Topology Database: A representation of the connectivity and
> > > capabilities of the stations and
> > > > > > > links on the ring.
> > > > > > >
> > > > > > > (Inevitably we will end up with at least one bit of
> standards-based
> > > optional capability which
> > > > > > > will need to be stored in the database.)
> > > > > > >
> > > > > > > Topology Discovery: The process by which the connectivity and
> > > capabilities of the stations and
> > > > > > > links on the ring is discovered by a newly added station.
> > > > > > >
> > > > > > > and a new one from the motions
> > > > > > >
> > > > > > > Plug and Play: The requirement that a station be capable of
> > > Topology Discovery and optional
> > > > > > > insertion and drop of user frames without manual intervention
> other
> > > than the physical connection
> > > > > > > of the equipment.
> > > > > > >
> > > > > > > Brian H.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Brian Holden PMC-Sierra, Inc.
> > > > > > > 3975 Freedom Circle, Santa Clara CA USA
> > > > > > > +1.408.239.8123 Fax +1.408.492.9862
> > > > > > > brian_holden@xxxxxxxxxxxxxx http://www.pmc-sierra.com
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Bob Sultan [mailto:Bob.Sultan@xxxxxxxxxxxxxxx]
> > > > > > > Sent: Tuesday, May 22, 2001 3:17 PM
> > > > > > > To: stds-802-rprsg@xxxxxxxx
> > > > > > > Cc: Allan Pepper; Brian Holden
> > > > > > > Subject: Re: [rprsg] (Terms & Defn) In definitions of steering
> and
> > > > > > > wrapping s/b ringl ets instead of rings
> > > > > > >
> > > > > > > Brian,
> > > > > > > I agree with your corrections, but we probably need to correct
> these
> > > further.
> > > > > > >
> > > > > > > Allan,
> > > > > > > After seeing Brian's email, but before seeing your email, I made
> a
> > > nearly
> > > > > > > identical correction. I omitted the words 'and link failures'
> as I
> > > assumed that
> > > > > > > 'ring topology' means 'current ring topology' and already
> includes
> > > any failed
> > > > > > > links. Let me know if you disagree.
> > > > > > >
> > > > > > > Wrapping is more interesting. In the case of a dual-ring,
> > > 'different ringlet'
> > > > > > > and 'opposing ringlet' would have the same meaning. So, if the
> > > definition is
> > > > > > > specific to a dual-ring, I prefer 'opposing ringlet'. I think
> you
> > > intended your
> > > > > > > definition to be sufficiently general to cover the multi-ring
> case.
> > > The
> > > > > > > definition would allow 'wrapping' by shifting frames from one
> > > clockwise ringlet
> > > > > > > to another clockwise ringlet. This could be exactly what people
> > > have in mind for
> > > > > > > wrapping on a multi-ring, but I'm not sure.
> > > > > > >
> > > > > > > So, should our definitions be specific to the dual-ring case
> (and we
> > > could update
> > > > > > > them if the standard includes multi-rings) or should they all be
> > > sufficiently
> > > > > > > general to include the multi-ring case (and we could update them
> to
> > > make them
> > > > > > > specific to the dual-ring case if multi-rings are not
> supported)?
> > > My bias is
> > > > > > > towards describing the dual-ring case (but it is a bias).
> > > > > > >
> > > > > > > If we define our terms based on a multi-ring, I think I would
> need
> > > some
> > > > > > > understanding of how steering, wrapping, discovery, etc. are
> > > described in the
> > > > > > > multi-ring environment. If someone thinks we should define
> terms
> > > general enough
> > > > > > > for a multi-ring, can that person volunteer a description of how
> > > this works?
> > > > > > >
> > > > > > > Bob
> > > > > > >
> > > > > > > Allan Pepper wrote:
> > > > > > >
> > > > > > > > I belive the term node should also be replced with station.
> > > Additionaly, the
> > > > > > > > definition does not need to explain why the mechanism works.
> These
> > > changes
> > > > > > > > would make the following definitions.
> > > > > > > >
> > > > > > > > steering: placement of a frame on a ringlet by the ingress
> station
> > > based on
> > > > > > > > knowledge of ring topology and link failures.
> > > > > > > >
> > > > > > > > wrapping: the transit of a frame such that is is received by a
> > > station on one
> > > > > > > > ringlet and re-transmitted on a different ringlet.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Allan Pepper
> > > > > > > > Nortel Networks
> > > > > > > >
> > > > > > > > Brian Holden wrote:
> > > > > > > > >
> > > > > > > > > Bob, Group,
> > > > > > > > >
> > > > > > > > > In the definitions of Steering and Wrapping, the
> > > > > > > > > word "ring" should be replaced by "ringlet" except in
> > > > > > > > > the phrases "ring topology" and "node on the ring".
> > > > > > > > > The phrase "node on the ring" could also be replaced
> > > > > > > > > by "node".
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Brian H.
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Brian Holden PMC-Sierra, Inc.
> > > > > > > > > 3975 Freedom Circle, Santa Clara CA USA
> > > > > > > > > +1.408.239.8123 Fax +1.408.492.9862
> > > > > > > > > brian_holden@xxxxxxxxxxxxxx http://www.pmc-sierra.com
> > > > > > >
> >
--
Michael Takefman tak@xxxxxxxxx
Manager HW Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-271-3399 fax: 613-271-4867