RE: [RPRWG] Destination Address of RPR control messages
Mike,
Comments interleaved.
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: Thursday, May 30, 2002 1:01 PM
> To: stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] Destination Address of RPR control messages
>
>
>
> David,
>
> restricting this to .17 for the moment. This is an
> interesting tidbit.
>
> My first response is lets get the RAC to sign up to
> this, it has an architectural cleaness that might as
> well be codified. As you are a member of the RAC is
> this reasonable to expect acceptance of/on?
I believe this is the right approach, since its being
done as a defacto standard on other standards anyway.
Also, there are alot of 802-aware folks on the RAC.
> My second question is do we have to go to the RAC
> anyway to reserve a broadcast address as suggested
> by Anoop? If so, we can kill two birds with one
> stone in terms of a RAC liason.
I'm not aware of the IEEE/RAC assigning broadcast addresses,
but maybe that's because I haven't been 802-centric until
recently.
> Another third choice is
> 1) make control messages with all ones broadcast
> 2) control messages that have the multicast bit set
> but are not all ones are hop by hop
> (avoiding the issue of going to the RAC by leaving
> the exact value unspecified)
> 3) unicast addresses go to the station addressed if
> the station is on the ring and are killed by source strip
> or TTL if they are not on the ring
>
> Note: If the no-one feels the need for unicast delivery of
> control messages 2) could be modified to hop by hop
> if not all ones.
Seems like the first solution was sufficient and viable,
and the other alternatives are a bit dirty.
> cheers,
>
> mike
>
>
> David James wrote:
> >
> > Mike,
> >
> > While I like to use a zero-valued MAC address as a NULL value,
> > with the assumption that NULL MAC addresses are stripped
> > by the first downstream station, there is a small point
> > of concern: this is (in theory) a valid MAC address usable by
> > Xerox.
> >
> > Of course, other standards have asked for Xerox to be contacted
> > and agree that zero is a null (rather than potentially valid)
> > MAC address. And, it reality, this address has been used and
> > retired years ago.
> >
> > Its probably safe to use the zero value, although (in theory)
> > safeness has not yet been validated by the IEEE/RAC.
> >
> > 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: Thursday, May 30, 2002 11:58 AM
> > > To: Anoop Ghanwani
> > > Cc: 'stds-802-17@xxxxxxxx'
> > > Subject: Re: [RPRWG] Destination Address of RPR control messages
> > >
> > >
> > >
> > > Anoop,
> > >
> > > The original reason for differentiating them (as I recall
> > > and I could be wrong). Was to provide different addresses
> > > so that the type of control message (broadcast or hop by hop)
> > > could be easily determined in terms of receiption rules.
> > > Checking for all ones or all zeros is very easy and from
> > > a debugging perspective, makes it very easy to identify
> > > packets.
> > >
> > > Using a single "reserved" multicast for both hop by hop
> > > and control defeats the purpose of making the reception
> > > rules easy.
> > >
> > > Using two has the ugly semantics of a multicast address
> > > used to mark a unicast packet.
> > >
> > > mike
> > >
> > > Anoop Ghanwani wrote:
> > > >
> > > > According to Clause 8 in D0.2, the destination address
> > > > is set to "all zeros" for hop-by-hop control packets,
> > > > and "all ones" for broadcast control packets.
> > > >
> > > > Other IEEE 802 MACs use reserved multicast addresses to
> > > > identify MAC control frames. For example, IEEE 802.3
> > > > flow control frames are sent with a destination address
> > > > of 01-80-C2-00-00-01. These frames are only sent on
> > > > full-duplex Ethernet links and must not be forwarded
> > > > by the MAC.
> > > >
> > > > Is there any reason for deviating from the standard
> > > > practice?
> > > >
> > > > -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
>