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

["Jihoon Lee" <[e-mail]>]

Hi Max,
Yes, you're right. I'm not gonna use that word.

Thanks,
Jihoon


2007/1/19, Riegel, Maximilian <[e-mail]>om>:
>
> 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