[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[16NG] Re: stepped multicast operation (was: and IPv6 over ETHCS)
Hi Alex,
Please see inline comments.
Jihoon
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
_______________________________________________
16NG mailing list
16NG at ietf.org
https://www1.ietf.org/mailman/listinfo/16ng