Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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