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

Hi Alex,

Comments inline.

Best regards,
Brandon

2007/1/20, Alexandru Petrescu <alexandru.petrescu@motorola.com>om>:
>
> 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?]

Here I assumed the former, converting IPv6 link-local multicast addresses to
multicast CIDs.

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.

Yes, it works. But, BS-trigger is still possible.
(1) IPv6 stack generates a MLD REPORT and puts it to ETHCS Driver. ETHCS
Driver pass  it to 802.16 MAC, and it can be transmitted using uplink
transport connection (unicast to BS).
(2) MLD REPORT will be delivered from BS's 802.16 MAC to ETHCS. ETHCS can
trigger BS-initiated DSA if the snooping has equipped.

I cannot say which one is better. In the 802.16 point of view, BS-initiated
DSA procedure is desirable, because we can assume that it has been
authorized. In addition, naturally it protect from any malicious request.
On the other hand, I agree that MS-initiated DSA is natural since MS
initiates MLD-REPORT.

Let me think.

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

just standard 802.16 without any snooping.

> 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.

MBS is multicast and broadcast service, which defined in 802.16. However,
it's described so general in 802.16. The word, "refer", which I used,
is inappropriate. The point was there'll be similar discussion to what we're
doing.

>> 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.

I meant ETHCS. BTW, the bridging function also exists in SS ?

> 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