[16NG] Re: stepped multicast operation

Jihoon Lee wrote:
> Yes, I presume that we may not need any special add-on function on SS
>  to address this multicast problem. But, I assume that there may be 
> something in BS or AR or between them. BTW, definately there must be 
> IPv6 stack, ETHCS layer, and 802.16 MAC/PHY on SS, which are 
> supporing RFCs required.
> 
> Firstly, let's consider all possible ways.

I think it is important to identify whether anything special is needed
on SS.  I mean anything other than rfc2461, rfc2464 and MLDv2 and the
other RFCs.

>> For example, we could require IPv6 stack on SS to (1) do MLD REPORT
>>  for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then
>>  (3) transmit an unsolicited 802.16 MCA-RSP message (not MLD
>> REPORT) to BS. The steps 1 and 2 are existing art, rfc2461 and
>> rfc2464. The step 3 is art in 802.16MAC. The sequence of the three
>> steps is novelty for IPv6-over-ETHCS document. What do you think?
>> 
> 
> I think you can mention (1) and (2) for SS. However, (3) is 
> impossible.
> 
> At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is
>  a kind of ack, which has only Transaction Id (which can distinguish 
> each 802.16 MAC message transaction) and Confirmation Code (return 
> code such as success/failure). And MCA-REQ shall be initiated by a 
> BS. Therefore, using MCA-REQ/RSP is not appropriate.

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?

> (For your information, 802.16 MBS creates 802.16 (DL) multicast 
> connection using DSA-REQ/RSP/ACK messages)

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?

> In addition, we'd better not mention any 802.16 message explicitly. 
> (BTW, I think there is no 802.16 message which may do this....hmm)

I think that if we can use the 802.16 message in the way it is intended
to, and if we can get comment from 802.16 expert, then we may be fine.
It may also be that it's not fine at all, by expert oppinion.

>> We could alternatively require the IPv6 stack on SS to (1) do MLD 
>> REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1,
>> and then don't transmit the unsolicited MCA-RSP to BS but set up a
>> uplink classifier rule in ETHCS. Subsequent to that, any PDU
>> received by ETHCS that has dst 33:33::1 goes to the IPv6 stack. We
>> would require the SS's ETHCS to not put to SS's IPv6 stack a PDU
>> that doesn't have such a uplink classifier rule within ETHCS. This
>> should be achieved according to IEEE spec, not enhancement. It
>> could be done by having the output of that uplink classifier rule
>> to go to a CID that is void or nil or non-existent. In this way we
>> could be ok with the IEEESpec (not modify it, not tresspass it).
> 
> 
> As I see, this scenario is more plausible. But I don't fully 
> understand your intention. (1) and (2) are ok.
>> any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 
>> stack.
> 
> This is the BS side, right?

I meant SS.

>> We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU
>>  that doesn't have such a uplink classifier rule within ETHCS.
> 
> I don't understand this sentence. Could you make this clear?

Yes, the goal is for SS.  SS's ETHCS shouldn't deliver ('put') a PDU it
receives from BS's ETHCS, that is addressed to 33:33, to the IPv6 stack,
if SS's doesn't have a 'reconstitution' classifier rule for it.

So one would basically require that only if there is a reconstitution
rule in SS's ETHCS for the 33:33 dst and a normal CID, should the ETHCS
deliver the packet to the IPv6 stack of the SS.

(I should have said maybe 'reconstitution' instead of 'uplink
  classifier'. Figure 7, 8 ieee-2004.  Basically SS has only uplink
  classifiers, BS has only downlink classifiers, when they send packets;
  and they have 'reconstitution' when they receive packets).

> Note that there is no 802.16 classifier in rx side regardless of BS 
> or MS.

I agree, I should have said 'reconstitution' then?  Can the
'reconstitution' part  of SS, the one that undoes PHS, have such a
classifier rule?

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 in all cases we don't want the IPv6 stack on SS to receive 
> multicast packets for which it hasn't joined, because this augments 
> the risk of bad flooding effects.
> 
> 
> Yes. It's desirable.

I agree it is desirable.  To me it is at least desirable, and more, it
is a MUST.  I think we could have been more in agreement if we defined
in detail what the flooding problem is.

Alex

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng