RE: [RPRWG] Destination Address of RPR control messages
Mike,
OAM control messages may be unicast, so we need 3).
Leon
-----Original Message-----
From: Mike Takefman [mailto:tak@xxxxxxxxx]
Sent: Thursday, May 30, 2002 10: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?
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.
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.
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