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

[Castellano Robert <rcast3@xxxxxxxxx>]

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
>