[16NG] Re: stepped multicast operation

Hi Alex,

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

Ok. I understood your intention.

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

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

BTW, basically 802.16 doesn't know any upper layer messages such as
IGMP/MLD-REPORT. So, there may be some issues, i.e., who will trigger a
multicast connection setup, and which is better, BS-initiated or
MS-initiated.

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

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

 Ok. 'reconstitution' is fine to me.

> 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 you cannot define any classification rule in 'reconstitution' part
of SS, since the 'reconstitution' part is defined in 802.16. Why don't you
do that on top of 802.16?

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.

Best regards,
Jihoon

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