[16NG] Re: stepped multicast operation (was: and IPv6 over ETHCS)

Hi Alex,

Please see inline comments.

Jihoon

2007/1/19, Alexandru Petrescu <alexandru.petrescu@motorola.com>om>:

> Jihoon Lee wrote:
> > Assumption: IPv6 ND messages cannot be transmitted to other MSs served
> > by the same BS without any additional supporting function.
> >
> > 1) 802.16 BS support a local multicast function. (How? keep this open.
> > Where? Inside BS. maybe a function implemented over ETHCS.) This
> > supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering
> > them to a bridge or an AR.
> > 2) There is a bridge between BSs and ARs. Firstly, the bridge relays
> > (multicasts) IPv6 ND messages except for the source MS.
> > Then, it delivers to AR. (How? keep this open. Where? bridge and AR in
> > case of utilizing VLAN ).
> > 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND
> > messages to other MSs except for the source MS. (How? keep this
> > open. Where? AR).
> > 4) ...
>
> Jihoon, let me try to focus on the above text and motivate why I said it
> would go in an Appendix.
>
> I am against the assumption in step 3 that only GRE tunnel can be used
> for a 802.16 deployment. Other tunnels can do the trick too - L2TPv3
> RFC4719 is designed exactly to transport Ethernet over IP. IEEE802.16
> spec doesn't require GRE (search doesn't hit word 'GRE'). That's
> why I think step 3 should be preceded by a big MAY.

Yes, you're right. In addition, we should not specify it, as Max said.

> The structuring of steps you present above makes sense to me, in that
> functionalities are left open with How - keep open.
>
> From your above text I also understand that only BS and AR behaviours
> are enhanced. I think you don't think SS or MS should do anything
> special to run a special IPv6 over ETHCS. What do you think?

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 am personally interested only on what happens on the SS, I can
> contribute to that.
>
> So I could look for an enhancement for IPv6-over-ETHCS on SS.

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.
(For your information, 802.16 MBS creates 802.16 (DL) multicast connection
using DSA-REQ/RSP/ACK messages)

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)

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

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

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.

What do you think about GRE/L2TP? And about SS IPv6 multicast enhancements?
> Alex
>
>