RE: [RPRWG] A problem with fairness messages
Mike,
Thank you for verifying the need to support duplicate
suppression on RPR, in the context of multicast and
flooded frames when the source station disappears.
From my analysis, the preferred technique is based on
a consistency check between DSID, SSID, and
a standardized decrement-from-255 TTL field.
I would be happy to provide a reference, contained
within previously submitted or to-be-submitted comments.
Using the TTL for this purpose fails when the ring
diameter decreases. The change in ring diameter
is associated with fiber cuts and (from what I here)
a cut cable is a more common occurance than nutz stations.
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: Monday, June 17, 2002 10:59 AM
> To: David V. James
> Cc: Anoop Ghanwani; 'Castellano, Robert'; 'Necdet Uzun '; ''John Lemon'
> '; stds-802-17@xxxxxxxx; Komal Rathi
> Subject: Re: [RPRWG] A problem with fairness messages
>
>
>
> David,
>
> may I beg to differ with your statement? :)
>
> If the station that sources the packet goes
> nutz, TTL is required to strip the packet
> and avoid double delivery. TTL still
> has to scope the packets travel.
>
> mike
>
> "David V. James" wrote:
> >
> > Robert,
> >
> > Hope is all going well.
> > I beg to differ with your statement:
> > >> We still need to be able to set the TTL to something
> > >> less than 255 to allow for bidirectional flooding of
> > >> user data frames.
> >
> > The DSID proposed by the BAH can be used to specify the
> > strip point and a distinct flooding bit can be used to
> > specify the flooding mode. Not only is that possible,
> > its preferred to having the TTL decrement be messy,
> > as in frame-type-dependent and run-side-dependent,
> > as would be the case if used as suggested.
> >
> > 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 Anoop Ghanwani
> > >>Sent: Monday, June 17, 2002 9:46 AM
> > >>To: 'Castellano, Robert'; Anoop Ghanwani; 'Necdet Uzun '
> > >>Cc: ''John Lemon' '; ''stds-802-17@xxxxxxxx' '; Komal Rathi
> > >>Subject: RE: [RPRWG] A problem with fairness messages
> > >>
> > >>
> > >>
> > >>
> > >>Bob,
> > >>
> > >>This discussion only applies to fairness messages.
> > >>
> > >>-Anoop
> > >>
> > >>> -----Original Message-----
> > >>> From: Castellano, Robert [mailto:RCastellano@xxxxxxxxx]
> > >>> Sent: Monday, June 17, 2002 9:46 AM
> > >>> To: 'Anoop Ghanwani'; 'Necdet Uzun '
> > >>> Cc: ''John Lemon' '; ''stds-802-17@xxxxxxxx' '; Komal Rathi
> > >>> Subject: RE: [RPRWG] A problem with fairness messages
> > >>>
> > >>>
> > >>> Hi,
> > >>>
> > >>> I am just catching up on this thread.
> > >>>
> > >>> Is the TTL being set to 255 just for congestion control
> > >>> messages or also data frames in general. We still need
> > >>> to be able to set the TTL to something less than 255 to
> > >>> allow for bidirectional flooding of user data frames.
> > >>>
> > >>> thanks,
> > >>>
> > >>> robert
> > >>
>
> --
> 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
>