Re: [rprsg] (Terms & Defn) topology terms
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
> > >