Re: [RPRWG] Destination Address of RPR control messages
MAC addresses for control protocols such as STP come from IEEE OUI that is
assigned to IEEE, and the value is 0x00-80-C2 (multicasted to 01-80-C2). The
same value is used for all bridged PDUs for similar purposes (802.1D related).
Since RPR is another 802.x standard, we should be able to reserve another lower
set of numbers for RPR purposes, using the same OUI.
As an aside, it's probably because Xerox owns 00-00-00, this value is used for
Ethertype assignments for IEEE802.3 frame formats, such as ones used for rfc1483
and rfc1490 for multiprotocol over ATM and frame relay. So an IP packet would
have 00-00-00-08-00 as its OUI+PID.
As far as bridging is concerned, I am not in favor of all 00 MAC addresses.
While it is relatively harmless to use it in our case, it's prone to confusion.
If someone were taking network traces on traffic and logs packets with all 00
MAC address among other packets, it would be confusing to determine right off
what the packet is supposed to mean. In past, I've (mistakenly, now that David
pointed out) written transparent bridging software where I specifically
discarded packets addressed to all 00 MAC address (thinking these got to be bad
packets), or sourced by a multicast address, etc.
Pankaj.
"Castellano, Robert" wrote:
> All,
>
> Does it really matter whether we pick 0 to represent the null MAC address
> or some other globally unique value that has been assigned by the RAC?
> Who assigned the MAC addresses for control protocols for well known L2
> protocols such as STP, etc.?
>
> Also, if there is a control bit in the RPR frame distinguishing between
> a specific RPR specific control packet vs. data packet are we free to choose
> any MAC addresses
> for RPR control purposes.
>
> thanks,
>
> robert
>
> -----Original Message-----
> From: David James [mailto:djz@xxxxxxxxxxx]
> Sent: Thursday, May 30, 2002 3:23 PM
> To: Mike Takefman; Anoop Ghanwani
> Cc: IEEE RAC; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] Destination Address of RPR control messages
>
> 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
> >