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

From: gabriel montenegro <[email-masked]>
Date: Wed, 17 Jan 2007 08:03:47 -0800 (PST)

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" <[email-masked]>
To: Alexandru Petrescu <[email-masked]>
Cc: [email-masked]
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:[email-masked]] 
Sent: Wednesday, January 17, 2007 10:54 AM
To: Riegel, Maximilian
Cc: [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jan 2007 17:50:45 +0100

gabriel montenegro wrote:
> 
> I'd suggest less rather than more text.

I agree with the intent.

> If it's standard behavior (as suggested by Max), rather than 
> describing it again and risking getting it wrong (even 
> sources (and sections within them if need be).

Yes, but currently it is not the case - it doesn't refer to at least
MLDv2 RFC (but prefers to refer to an INFORMATIONAL 4541 optimization of
its usage).  For example MLDv2 says all MLDv2-capable nodes should join
FF02::16.  Will an 802.16 ETHCS node join that address or not?  MUST it?
  RFC2460-2464 don't require that.

For multicast it reads as if authors concentrated in making link-layer
do multicast.  For example, the IPv6 section doesn't contain the word
'multicast' - or the fundamental need for it is IPv6 running over
Ethernet _only_ if that Ethernet is multicast capable.  This is
completely absent from the IPv6 text.

But, the document contains 7 occurences of 'bridge SHALL' statements.

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

I agree and share the intent.

> The problem of limiting potential flooding at the link-layer is not 
> new and we can just point at section 2.7 of 

I agree, I think we can refer to that (although it looks as a
infrastructure multicast problem, non link-local).  But I'm not sure
what is the potential flooding problem in this 802.16 context?  Anyone
noticed such problem?

The only problem I'm aware of is that IPv6 prefers the link-layer to be
multicast capable.

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

You mean link-layer normative?

Or you mean IPv6 normative?  Sorry, I'm trying to figure out.

For example rfc2461 says the node MUST join a group before receiving
some messages.  The IP-over-ETHCS document doesn't say neither it joins
neither it doesn't.  If the SS MUST join, then how would it do it?  2461
is silent about how to do it and MLDv2 has certain conditions under
which the join should happen.  IP-over-ETHCS document is silent about
all this.

There are also unspecified rules for joining a link-local group, running
over Ethernet, and that don't involve message exchange, and deployed
today.  Which of those should SS do?

RFC2464 says what are the mapping rules for IPv6 multicast addresses to
EThernet link-layer multicast addresses.  In that document there are no
'mapping rules' for IPv6 unicast addresses, nor for IPv4uni/multicast
addresses.

IP-over-ETHCS document says 'mapping' only for IPv4 (referring to
rfc894) and says nothing about IPv6 mapping rules, it's silent about that.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 17 Jan 2007 11:08:27 -0600

Alex, 

Let me pick on just one comment that you made on this thread:

> The only problem I'm aware of is that IPv6 prefers the link-layer to be

IPv6 is designed to work on many different types of links. It was not
designed to work just on mutlicast capable links as your sentence implies.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jan 2007 18:23:42 +0100

Basavaraj Patil wrote:
>> The only problem I'm aware of is that IPv6 prefers the link-layer
>> to be multicast capable.
>> 
> 

I meant links with link-layer headers.

Reading ND it says "node MUST join" before receiving an RA.  'Join' can
happen only if that link is multicast-capable.

In practice IPv6 runs even over RS-232,  I've tried, but no conformant
ND runs on that.

Alex