[16NG] Re: multicast and IPv6 over ETHCS

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

Hi Alex,

My comments are inline.

Best regards,
Jihoon

2007/1/16, Alexandru Petrescu <[e-mail]>om>:
>
> Jihoon Lee wrote:
> > Hi Alex,
> > I agree with that.
>
> I also agree, more specifically for IPv6-over-ETHCS document to not
> specify how to implement link-layer multicast behaviour.
>
> If the draft is separated in two separated documents IPv6-over-ETHCS and
> IPv4-over-ETHCS, then I will suggest the following multicast text, for
> the IPv6-over-ETHCS document.
>
> Do you think this text makes sense in the context of this document?  Do
> you agree with the text or portions of it?  Anything wrong with this text?
>
> Thanks,
>
> Alex
>
> > Running IPv6 over an Ethernet link needs the support of link-layer
> > multicast.  In the 802.16 context, the Ethernet Convergence Sublayer
> > (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE
> > 802.16 Packet Convergence Sublayer) must (1) support multicast
> > link-layer addresses (2) map IPv6 multicast addresses to link-layer
> > addresses and vice-versa, (3) offer the capability of joining and
> > leaving IPv6 link-local multicast groups and (4) send and receive
> > IPv6 link-local multicast packets whose link-layer headers contain
> > link-layer multicast addresses.


I agree with you on the clarification of the requirements/assumptions
related to MS's UL multicasting.

In particular, however,  I think (2) and (3) above are not required in
ETHCS. They should be upper layer or upper management function (that is,
802.3 bridge function) comparing to the ETHCS layer (Here I assume that
ETHCS differs from 802.3 Ethernet bridge). Since ETHCS is a part of IEEE
802.16, it basically supports packet classification (matching 802.16 CID)
and header suppression only, which we should not touch. Therefore, "In the
802.16 context, the Ethernet Convergence Sublayer must..."  may be
inappropriate.

Regarding others' comments, I think you don't have to specify this on
802.16CS layer. There should be multiple choices to implement this.
However, I
think it's worth mentioning what (+ where) should be done. Although, the
draft-ietf-16ng-ip-over-ethernet-over-802.16 says: "Multicast is not enabled
in the uplink but must be realized by an entity on top the IEEE 802.16 MAC
sending packets received on a unicast uplink downstream on a multicast
channel.", it's too simple and general to describe uplink multicast
transmission of IPv6 packets over ETHCS.

For example, you may describe what should be done based on the network
model:
(the followings may depend on the network model which the draft refers.

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

I could not find any flaw in the following text. But, I'm not sure there
is another message in IPv6 which is not mentioned in the last paragraph.


>
> > The following link-layer multicast addresses are recommended by
> > RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill].
> >
> > The rules for mapping IPv6 link-local multicast addresses to
> > link-layer multicast addresses are recommended by RFCxxxx and are the
> > following:
> >
> >     - ff02::1 maps into 33:33:00:00:00:1
> >     - and the others.
> >
>
> > The IPv6 stack must join a certain link-local IPv6 multicast group
> > before receiving packets addressed to that group.  For example,
> > before receiving a Router Advertisement the stack MUST join the IPv6
> > link-local multicast address 'all-nodes'.  When the IPv6 stack on the
> > Subscriber Station joins a certain IPv6 link-local multicast group it
> > MUST receive all packets addressed to that group.  The join operation
> > can happen in several ways: sending a MLD REPORT (RFCxxx), setting a
> > local filtering rule, etc.
> >
> > The IPv6 stack must be able to leave a certain IPv6 link-local
> > multicast group.  When the IPv6 stack leaves a group must no longer
> > receive the IPv6 packets addressed to that group.  Similarly to the
> > joining operation the leaving operation can happen in several ways:
> > sending a MLD REPORT, setting a local filtering rule, etc.
> >
> > The following Neighbour Discovery messages are sent by a Subscriber
> > Station to IPv6 link-local multicast addresses: Neighbour
> > Advertisement, Neighbour Solicitation, Router Solicitation (RFCxxxx).
> > The following Neighbour Discovery messages are received by a
> > Subscriber Station, addressed to IPv6 link-local multicast addresses:
> > Router Advertisement, Neighbour Advertisement, Neighbour
> > Solicitation.
>

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