RE: [RPRWG] Destination Address of RPR control messages
Bob,
Interesting point.
Of course, if we end up with DSID and SSID addresses,
one could also pick the largest DSID for downstream
stripping.
Come to think of it, that's actually my favorite.
Because it also works for compact control and/or
data frames that don't include the MAC addresses.
And, there is no need for special MAC assignments!
I'll include that in my next-week BAH presentation.
Hope I'm not perceived as the the black sheep,
or (if so) black wool is in fashion(:>).
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 Castellano,
>>Robert
>>Sent: Thursday, May 30, 2002 2:48 PM
>>To: 'djz@xxxxxxxxxxx'; Mike Takefman; Anoop Ghanwani
>>Cc: IEEE RAC; stds-802-17@xxxxxxxx
>>Subject: RE: [RPRWG] Destination Address of RPR control messages
>>
>>
>>
>>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
>>>