Re: [RPRWG] P802.17b D1_2 Multicast Conference Call Reminder

["Mike Takefman (tak)" <tak@xxxxxxxxx>]

Robert, 

I wouldn't quite say we had exactly the concensus that
you highlight, but you aren't far off. I am sure it will
be an interesting call.

mike

-------------------------------------------

Michael Takefman              tak@cisco.com
Distinguished Engineer,       Cisco Systems
Chair IEEE 802.17 Stds WG
3000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399       cell:613-220-6991 

> -----Original Message-----
> From: Castellano Robert [mailto:rcast3@yahoo.com] 
> Sent: Thursday, February 23, 2006 6:54 PM
> To: STDS-802-17@listserv.ieee.org
> Subject: Re: [RPRWG] P802.17b D1_2 Multicast Conference Call Reminder
> 
> Mike,
> 
> 1.  We previously had consensus of there being a client 
> option enabling the client to bypass SAS.  My understanding 
> of this option is that it would bypass any SAS table lookups. 
>  As a client option this would enable frames to be bypassed 
> on a frame by frame basis.
> 
> Either the 2 or 4 address format was acceptable, provided the 
> frame did not contain the SAS learn signature.  
> 
> We also discussed an enhancement to the request_sas option to 
> handle multicast frames.  In this case, multicast frames can 
> take a form where they do not have the SAS learn signature, 
> but are still processed by the group address table to allow 
> scoping.  I believe you proposed a couple different values 
> for the request_sas parameter to distinguish between when 
> multicast frames are learned/not-learned.
> 
> Multicast frames should follow from these same kind of rules. 
>  Hence, if the source of a multicast frame is intended to be 
> learned, the frame should have the SASgroupAddress signature. 
>  If the multicast frame is not intended to be learned it 
> should be flooded using some other group address.  It would 
> also be helpful to understand the criteria in a. vs. b. on 
> when the frame is extended vs. not extended.  If the frame is 
> extended based on whether the SA equals the station SA, then 
> both a and b should follow from normal frame transmission rules.
> 
> In question #3
> a. Should be supported for frames which bypass the "unicast" 
> SAS machine.
> 
> b. Unclear on what triggers the extend for a non-learned 
> frame.  Is it that the SA does not equal the station SA?  If 
> so, then a and b should simply follow from a frame that 
> bypasses SAS and the extension is based on normal 802.17 
> frame processing rules. 
> 
> c. Supported for frames having the SAS signature. 
> This should be for frames which do not bypass SAS.
> 
> d. Should be supported for frames which do not have the SAS 
> group address signature.
> 
> Question #6 needs to distinguish between when there is a hit 
> in the multicast table vs. no-hit.
> 
> If there is a hit in the group address table, then the table 
> should take precedence.  If there is no hit in the group 
> address table then the client parameter should take precedence.
> 
> The proposed table that I had sent out earlier reflects the 
> precedence relationship between the client parameters, hit in 
> either the unicast or group address table, Std.cleave, and 
> setting of frame.fi.
> 
> I think we should also discuss this table the relationship of 
> frame.fi.
> 
>      Thanks,
> 
>      Robert
> 
> 
> 
> --- "Mike Takefman (tak)" <tak@CISCO.COM> wrote:
> 
> > RPRWGers,
> > 
> > A reminder that this Friday is a conference call to discuss 
> multicast 
> > scoping in 802.17b.
> > 
> > Call starts at 9am (dial in 866-902-7862 ID 8021700).
> > 
> > During the past few weeks a few people have changed their votes and 
> > the new results are shown below.
> > 
> > We are still slightly short of a decision on both question. 
> Thus, if 
> > people wish to change their votes based on reviewing the current 
> > results, they should contact me immediately.
> > 
> > As previously reported, there were 2 questions that did not 
> achieve a 
> > concensus view
> > 
> >
> ----------------------------------------------------------
> > 
> > Question 3:
> > 3)	Multicast scoping should have the following 
> > features. [Note: a, b, and c get a 2-address frame from the 
> client (as 
> > compared to d).]
> > 
> > a.	Scope basic frames without SAS learning
> > b.	Scope extended frames without SAS learning
> > c.	Scope extended frames with SAS learning
> > d.	Scope client frames with 4 addresses without SAS
> > learning
> > 
> > The set of {a,b,c,d} has decreased to acceptable to 50% of voters
> > (6 of 12) but had 5 negative votes for that option.
> > 
> > The set of {a,b,c} has increased to be acceptable to 66% of voters
> > (8 of 12) but has 2 negative votes for that option.
> > 
> > Note that option {a,b,c} is now 1 vote away from being 
> acceptable to a 
> > 75% majority.
> > 
> >
> -----------------------------------------------------------
> > 
> > Question 6:
> > 
> > 6)	Assuming it is done frame by frame, control over
> > how a
> > frame is processed is via:
> > 
> > a.	Client supplied request parameter(s)
> > b.	Configuration of the Multicast Table
> > c.	Both, client request takes priority
> > d.	Both, table takes priority
> > 
> > Option C has 8 votes or 72% support but 2 negative votes 
> Option B has 
> > 7 votes or 63% support but 3 negative votes
> > 
> > Either of these options could go over the top, but clearly 
> C requires 
> > just 1 versus 2 more voter(s).
> > 
> > Because of the near loss on C the editor was instructed to prepare 
> > text (in editor's notes) assuming C was selected. The text 
> will not be 
> > an official part of the draft until it is approved.
> > 
> > 
> > cheers,
> > 
> > mike
> > 
> > -------------------------------------------
> > 
> > Michael Takefman              tak@cisco.com
> > Distinguished Engineer,       Cisco Systems
> > Chair IEEE 802.17 Stds WG
> > 3000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > voice: 613-254-3399       cell:613-220-6991
> > 
>