[16NG] Re: stepped multicast operation and two questions to David Johnston

[Alexandru Petrescu <[e-mail]>]

Jihoon Lee wrote:
>> Ok, thanks, I understand MCA-RSP is not specified to be sent 
>> unsolicited but as a response. In this case, we can specify that BS
>>  before sending a RA it sends a MCA-REQ to poll who are the SS's 
>> interested in receiving that RA, and thus SS can send the MCA-RSP 
>> as it is designed. Remark that the router (entity who sends the RA 
>> - BS or AR) MUST join the all-routers address (rfc2461), with a MLD
>>  or with a local filter (popular interpretation).  So subsequent to
>>  sending that MLD REPORT, or setting up filtering rule, it can send
>>  the MCA-REQ.  So we can trigger the sending of MCA-REQ either by 
>> sending the RA, or by MLD JOIN for all-routers, etc. What do you 
>> think about this?  Is this violating anything in 802.16. What 
>> method would you prefer?
> 
> Right now, I'm not sure about the usage of 802.16 MCA messages. 
> Actually I thought the MCA differently. You may need to ask an 16 
> expert the usage of MCA.

David, do you think an IPv6 stack on the BS can ask the 802.16MAC to
send a MCA-REQ to SS to ask it whether it's interested in receiving
packets addressed to 33:33:0:0:0:1?

>> As I understand it DSA-REQ/RSP/ACK are for allocating service flows
>>  with a certain QoS, bandwidth request, (table 113 ieee-2004).
>> This DSA-REQ is for a multicast CID, ok.  I understand
>> DSA-REQ/RSP/ACK are not specifically designed to indicate intention
>> of belonging to a mc group - which is what I'm looking for, the
>> equivalent of MLD REPORT. What do you think?  Should I look
>> elsewhere in the spec?
> 
> Here is another feasible way. I believe this is similar to what 
> you're trying to do:
> 
> DSA performs 802.16 connection setup as well as the service flow 
> creation. If there is no connection (actually CID) on SS, the SS 
> cannot receive it at 802.16 link layer. When BS creates multicast 
> connection between itself and MSs, DSA transaction is required for 
> each MS. Therefore, BS can manage its multicast group which is 
> associated with 802.16 multicast CID. In other words, MS may join by 
> initiating DSA with appropriate multicast CID. Because, in theory, 
> DSA can be initiated by either BS or MS. Consequently, the multicast 
> can be delivered to intended users only in 802.16 link-layer.

[At which point there  would be a need to be able to convert IPv6
  link-local multicast addresses to multicast CIDs, right?  Like ff02::1
  to 16bit.  Or do you think 802.16MAC converts the 33:33::1 to a
  multicast CID?]

I understand.  So the SS uses DSA messages to indicate interest in a
multicast-CID reception, and the BS keeps track of interests.  It makes
sense to me.  The packets addressed to a multicast group will arrive to
SS on that multicast CID.

But I think we still need to say that it is the SS who triggers that DSA
exchange, ie SS's IPv6 stack.  Do you agree?

It can happen in of the following alternative 2 ways: (1) IPv6 stack
generates a MLD REPORT and puts it to ETHCS Driver.  ETHCS Driver
interprets it, drops it, and sends the corresponding DSA-REQ; (2) IPv6
stack calls a function in ETHCS Driver giving it parameter 33:33::1 and
ETHCS Driver generates the DSA-REQ.

I think this should work.

> BTW, basically 802.16 doesn't know any upper layer messages such as 
> IGMP/MLD-REPORT.

Unless it 'snoops' them?

> So, there may be some issues, i.e., who will trigger a multicast 
> connection setup, and which is better, BS-initiated or MS-initiated.

Most IPv6 stacks currently call some function to join a certain group.
Some generate MLD REPORTS, some others just call a driver's function.
This can be matched into DSA-REQ/RSP.

All IPv6 router stacks must join all-routers group, so the BS (_if_ it
sends RAs) should join.  This matches the model of BS sending MCA-REQ
and SS sending MCA-RSP.

> The MBS will be discussed in WiMAX Forum at the end of this month. 
> Then, we may refer to details in DL multicast.

Sorry, I don't know what's MBS.

I think we have freedom to propose something that makes sense for
multicast IPv6 over ETHCS, here.  If there's agreement in the group and
gets drafted then maybe MBS and WiMax will be interested to know what
the draft says.

>> If it does not then one really has to prevent unwanted 
>> 33:33-addressed messages to reach the SS.  Apparently the only way 
>> left is to do it at BS, send the 33:33-addressed packets only to 
>> those SS's that are interested.  What do you think?
> 
> I think you cannot define any classification rule in 'reconstitution'
>  part of SS, since the 'reconstitution' part is defined in 802.16.

David, is it possible for IPv6 stack to add classification rule to the
'reconstitution' part of a SS, ie classifiers in SS that apply to
packets SS receives from BS, not 'uplink' classifiers that apply to
packets SS sends to BS.

> Why don't you do that on top of 802.16?

I was thinking we may save code.

But then _where_ exactly on top of 802.16?  Can I say add 'filtering
rule' in the ETHCS layer of SS?  Or can I say add 'filtering rule' in
the Bridging function of the ETHCS layer of SS?  But please, no
link-local multicast filtering rule in the IPv6 stack.

> BTW, how about the scenario I mentioned above?  I think it could also
>  prevent unwanted/not-joined 33:33-addressed messages to reach the 
> SS.

I think it makes sense.  I think DSA-REQ/RSP can be used by SS to set up
a multicast CID, based on my rough reading of the IEEE-2004 document.  I
think it will open a connection on which the RA will be sent, for example.

I think we need to identify what triggers the sending of the DSA-REQ.
I've suggested above.

I think if we have agreement on that maybe we can write 4 short
paragraphs and then re-ask in the Working Group and the IEEE experts.

Alex


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng