Re: [16NG] Re: multicast and IPv6 over ETHCS

[gabriel montenegro <[e-mail]>]

I'd suggest less rather than more text. If it's standard behavior
(as suggested by Max), rather than describing it again and risking getting it wrong (even
informatively), I think it's better to just refer to the proper
sources (and sections within them if need be). The whole point of ETH CS is that
the data path should look very similar to most (switched) ethernet nowadays
("point-to-point LAN" as per section 6.5.1--Support by IEEE Std 802.3--of IEEE 802.1D-2004). 

The problem of limiting potential flooding at the link-layer is not new and
we can just point at section 2.7 of
http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.txt
for existing procedures.

Now, if there's anything normative that needs to change, Alex, please point
that out. 

-gabriel

----- Original Message ----
From: "Riegel, Maximilian" <[e-mail]>
To: Alexandru Petrescu <[e-mail]>
Cc: [e-mail]
Sent: Wednesday, January 17, 2007 5:44:24 AM
Subject: RE: [16NG] Re: multicast and IPv6 over ETHCS

Hi Alex,

Your text on the behavior of the IPv6 stack on handling multicast looks
like standard IPv6 behavior. If this is true, than your text may be
added for informational purposes but do not add anything to the
normative part of the specification.

If your text is defining special IPv6 behavior, i.e. changing standard
IPv6 behavior, then it is not acceptable for the IPoETH-CS solution.

The IPoETH solution does not allow any change to the standard behavior
of the IP stack, when sending IP packets over Ethernet, but implements
IP specific extensions in the Ethernet layer to make the transmission of
IP over Ethernet more 'wireless friendly'. RFC4541 is an example of such
an extension to the Ethernet layer.
There is a real-world reason behind: an IP host may be connected by an
Ethernet cable to an IEEE802.16 bridge device. The host does not have
any awareness that its IP over Ethernet packets are transferred over an
IEEE802.16 radio link. All the IP specific optimization must take place
in the Ethernet layer over IEEE802.16.

Bye
Max
BTW: Link layer multicast is not provided by the Ethernet Convergence
Layer but by a bridge device in the system deploying the ETH-CS for
transmitting Ethernet frames over IEEE802.16.

-----Original Message-----
From: Alexandru Petrescu [mailto:[e-mail]] 
Sent: Wednesday, January 17, 2007 10:54 AM
To: Riegel, Maximilian
Cc: [e-mail]; Jihoon Lee
Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS

Hi Max,

Let me try to understand this.  You suggest that it is the aim of the
draft to specify the link layer behaviour when forwarding IPv6 multicast
messages.  I suggest that no link-layer behaviour should be specified,
but the interface.  (a distinction akin to OO programming, but
may not be that obvious).  I think we  may be saying the same thing but
with different words.

So, in order to clarify whether we agree or not: do you agree with the
multicast text I've sent, see below?   Do you think that text has its
place in the draft?

Thanks,

Alex

Riegel, Maximilian wrote:
> Hi Alex,
> 
> I do not agree with your proposal. It is the aim of the draft to 
> specify the particular behavior of the link layer when forwarding 
> IPv6 multicast messages.
> 
> The IPv6 solution does not relay on the multicast implementation in 
> the ETH link layer, but specifies what should be provided in the ETH 
> link layer to more efficiently handle IPv6 multicast messages over 
> IEEE802.16.
> 
> Bye Max

[snipping the rest of thread and inserting the multicast for IPv6 on
  ETHCS proposal text]

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

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