Re: [RPRWG] Destination Address of RPR control messages
At 16:00 30/05/2002 -0400, Mike Takefman wrote:
>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?
It is not a reasonable expectation that the RAC will allocate an address
that has already been assigned to another organization (Xerox in this
case), any more than it would be reasonable for the RAC to assign an
address under an OUI that had been assigned to Cisco, for example.
The first step seems to me to be to discuss this with Xerox. If you really
want to go down that route, maybe it would be appropriate for you to ask
the RAC to do this.
>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.
Allocation of multicast addresses for standards use has historically been
done by ISO/IEC SC6 at the request of 802.1; SC6 have asked the RAC to take
responsibility for this activity; however, 802.1 will still be the first
port of call when the transfer has happened.
>Another third choice is
>1) make control messages with all ones broadcast
No doubt a dumb question (I haven't followed this thread too closely), but
how will you distinguish your control messages from other legitimate users
of the all 1's broadcast?
Regards,
Tony
>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.
>
>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
Regards,
Tony