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

["Riegel, Maximilian" <[e-mail]>]

Usage of GRE is a WiMAX specific implementation choice of connecting BSs
with the bridge and this GRE tunnels should not appear anymore in future
revisions of the IPoETH draft. The specification can well be written
without mentioning 'GRE'.

There are many other solutions possible for connecting BSs with a bridge
and the draft should be not specific to one particular implementation.

Bye
Max

-----Original Message-----
From: Alexandru Petrescu [mailto:[e-mail]] 
Sent: Thursday, January 18, 2007 9:54 PM
To: Jihoon Lee
Cc: [e-mail]
Subject: [16NG] Re: stepped multicast operation (was: and IPv6 over
ETHCS)

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.

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?

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?

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

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.

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

Alex


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng