Subject: Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs)

From: gabriel montenegro <[email-masked]>
Date: Wed, 10 Jan 2007 11:40:53 -0800 (PST)

GARP/GMRP is not widely deployed, and seems to be obsoleted at the IEEE already.
RFC 4541 (MLD snooping) is the deployed solution, as Max already discussed 
in the November meeting:

    http://www3.ietf.org/proceedings/06nov/slides/16ng-4/sld7.htm

Notice that the last bullet mentions that no ND changes are required, so 
a future revision of the IP-over-ETH-CS draft will have much simpler ND-related
text.

A good reference in this respect is:
   2.7.2.  Host/Router Flooding Reduction in
   http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.txt
To point out that solutions exist, of which RFC4541 is the most widely deployed.

-gabriel

----- Original Message ----
From: Alexandru Petrescu <[email-masked]>
To: "Premec, Domagoj" <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Tuesday, January 9, 2007 2:02:04 PM
Subject: Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs)

Hi Domagoj, thanks for the email, skipping the parts we agree...

Premec, Domagoj wrote:
>>>> - Any reference or description of "Relay DAD"? there are 
>>>> earlier occurrences
>>> Relay DAD is described in 2.2.2.3. Are you just pointing out that
>>>  Relay DAD is mentioned before 2.2.2.3, so the explanation should
>>>  also be moved to the first occurance of Relay DAD? "Relay DAD" 
>>> and "ND Relay" are terms also used in 
>>> draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
>> 
>> I would point out to more than just moving the definition text next
>>  to the first use.
>> 
>> ND is defined in rfc2461 and DAD in rfc2462.  None of these 
>> documents defines what a "Relay ND" or a "Relay DAD" would do.  An
>>  IP machine 'relaying' ND packets from left to right, across links,
>>  instead of forwarding or routing them needs to be specified
>> clearly and separately I believe, provided there's an identified
>> need.
>> 
>> For example, the draft  says:
>>> Relay DAD means that the Neighbor Solicitation message used in 
>>> DAD process will be relayed only to the MS which already has 
>>> configured the solicited address as its own address (if such MS 
>>> exist at all).
>> In one sense, this is what DAD does already (not Relay DAD). 
>> RFC2462:
>>> Before sending a Neighbor Solicitation, an interface MUST join 
>>> the all-nodes multicast address and the solicited-node multicast 
>>> address of the tentative address.  The former insures that the 
>>> node receives Neighbor Advertisements from other nodes already 
>>> using the address; the latter insures that two nodes attempting 
>>> to use the same address simultaneously detect each other's 
>>> presence.
>> So I could suggest removing the word 'Relay' from the draft text, 
>> just leave "DAD", and all would be fine.
> 
> No, relay DAD is no ordinary DAD. The standard DAD procedure assumes
>  that the DAD solicitation is delivered to all the nodes using the 
> same prefix. Relay DAD delivers the DAD solicitation only to the node
>  that already owns the address being verified.

Not very sure about that.  The DADing NS is sent to an IP solicited-node
multicast address.  Not all nodes in the subnet join that address, only
the ones whose last 24bits of MAC address match the Tentative Address.

The DAD procedure doesn't assume the DADing NS is sent to all nodes
multicast address (with link-scope). rfc2462 5.4.2: "IP destination is
set to the solicited-node multicast address of the target address."  The
IP dst address would be FF02:0:0:0:0:1:FFXX:XXXX (X: last 24bits of MAC
address).  The link-layer dst multicast address would be
33-33-FF-XX-XX-XX I believe (X: last 24bits of MAC address, for IPv4
it's different: 23bits).

If one desires to deliver the DADing NS only to one particular node (and
not to a group) then one would put the full IP address in the dst, and
the full MAC address in the link-layer dst.  And this behaviour is not
specified by DAD (not sure whether it's forbidden, but it's not spec'ed
in rfc2462).

>> In another sense, reading the draft text suggesting to send the NS 
>> to only some MSs (maybe another criteria than joining an address) 
>> makes think that it may defeat the DAD's main goal.  What happens 
>> if some MS autoconfigures an address that conflicts with the one in
>> NS and that MS doesn't see that NS.
> 
> This must not happen. It is the responsibility of the bridge (the 
> authorative address cache) to deliver the DAD solicitation to the 
> right MS (the one that already owns the address being verified).

Ok, I think we have identified a good responsability for the bridge, and
this is inline with my understanding of bridge making link-layer
multicast work ok.

This bridge could also implement 802.1D and 802.1Q.  More precisely
maybe the GARP Multicast Registration Protocol (GMRP).  With this
link-layer LLC protocol, a GARP participant declares to another about
the group it wants to receive.  This happens with LLC PDUs (not IP
packets).  I think, no?

In this case the BS would not forward the DADing NS to the nodes that
haven't joined the link-layer solicited node multicast address.

So if the BS does that then bandwidth wouldn't be wasted and waking up
idle modes wouldn't be, no?

>> Related to 'Relay' in this context is the concept of 'proxy ND' 
>> whereby a node would do ND  on behalf on another node. This is 
>> partly defined in ND rfc2461 and largely used by a Mobile IPv6 HA 
>> rfc3775.  Just wanted to mention them.
> 
> The intention of the relay DAD is to save the radio resources. When a
>  host sends a DAD solicitation, 802.16 MAC will deliver it to the BS.
> 
> 
> 
Ok.

> Normal behavior as per RFC 2461 would be that the DAD message is 
> delivered to all MSs sharing the same prefix.

Not to all, just those that joined the group (small, maybe 1-sized) of
solicited node mc address.  No?

> But many of the MSs may be in the idle mode, meaning that the 
> delivery of the DAD message would incur paging and wake up from idle
>  mode, in addition to radio bandwidth necessary to transfer the DAD 
> solicitation itself.

Yes, two things: avoid waking up and avoid unnecessary bw consumption.

To avoid consuming bandwidth the BS shouldn't send the DADing NS to all
nodes under it.  This can be achieved with a link-layer multicast
protocol (not IP) and normal DAD.

To avoid waking up the idle node, the SS Eth drivers (under a BS not
doing that multicast link-layer stuff) can avoid putting the received
packet to the kernel stack, based on the local driver table it maintains
about the link-layer multicast groups it listens too.  Most Eth drivers
on a SS are able to filter what they receive (not deliver to IP stack).
 Some drivers are sensitive to packets received on Eth and will wake up
the node for any packet, some are more picky.

I agree though that _if_ DADing NS were sent to all-nodes multicast
address then it would potentially involve waking up all those who joined
that group, thus all nodes in a subnet.

> In relay DAD approach, the bridge (from figure 5) is aware of all 
> attached MSs and their IP addresses (authorative address cache). 
> Using this knowledge, the bridge can deliver the DAD solicitation 
> only to the MS that has already configured the address being verified
>  as its own address. And this MS will then defend its address.

Yes, this is what normal DAD would do too (not Relay), provided the node
joined that solicited-node address.  No?

The bridge should be able to do Ethernet multicast and I believe many
are, no?  Otherwise in a hierarchy of bridges all broadcasted packets
would be seen by everyone, and this doesn't happen in the wired world.

> Yes, this is similar to HA performing proxy ND on behalf of the 
> mobile node. And the bridge may indeed defend the verified address on
>  behalf of another node (which owns the address being verified). But 
> it is my understanding that such (proxy ND) approach would't work 
> with secure ND, that's why the bridge, in case of address conflict, 
> will relay the DAD solicitation to the MS so that the MS itslef can 
> defend the address.

Ah I see!  But Relay ND would have its own issues with SeND - right?

I think one can build attacks on both proxy ND and on 'Relay' ND.

> I-D draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt also 
> mentiones relay DAD. It does provide some additional details. We 
> should probaby define relay DAD just in one document and then refer 
> to it form other documents.

Yes, Relay ND looks as a new functionality that deserves separate
documentation.  For one it's obviously different IPv4 (Relay ARP?)
than IPv6 at least because (1) IPv4 doesn't require the use of
link-local multicast addresses and (2) address duplication detection for
IPv4 link-local addresses is different than DAD.  So I would suggest
separation that the IPv6-over-ETH draft in two: IPv6 and IPv4.  And the
Relay DAD draft too in two: Relay DAD and Relay ARP.

For Relay DAD, if there's enough energy and need to document as a
specific functionality (like proxy ND) then I think it needs
requirements and goals too.  Otherwise it could be documented as an
informational feature that has probably been implemented(?) or needed by
an SDO(?).

Thanks,

Alex

_______________________________________________
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, 10 Jan 2007 21:38:47 +0100

> GARP/GMRP is not widely deployed, and seems to be obsoleted at the 

Thanks for clarification.  Maybe IEEE proposes something else instead,
in order to have link-layer multicast?

> RFC 4541 (MLD snooping) is the deployed solution, as Max already 
> discussed in the November meeting:
> 

Yes, remark though that the MLD snooping doc rfc4541 is informational,
will that alter the status of IPv6-over-ETHCS.

I am not sure the IPv6-over-ETHCS could make a recommendation to use
rfc4541, because of its informational status.

IPv6-over-ETHCS could simply assume that ETHCS offers link-layer
multicast service to the IPv6 stack.  This could be a goal for ETHCS.
Whether ETHCS fullfills that by using MLD snooping or another IEEE
link-layer protocol, that should be irrelevant to the IPv6 stack.  But I
don't think the IPv6-over-ETHCS should recommend use of MLD snooping.

> Notice that the last bullet mentions that no ND changes are required,
>  so a future revision of the IP-over-ETH-CS draft will have much 
> simpler ND-related text.

Yes, I agree.

> To point out that solutions exist, of which RFC4541 is the most 

I can not comment on the deployed widely comment, but the fact that it's
informational it may mean it's not interoperable although widely
deployed?  I don't know, just asking.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jan 2007 18:23:31 +0100

Hi, sorry for following-up on my own email...

Alexandru Petrescu wrote:
> Thanks for clarification.  Maybe IEEE proposes something else 
> instead, in order to have link-layer multicast?
> 

Absent GARP/GMRP I think a thing to write in the future version of
IPv6-over-ETHCS draft with respect to multicast is about the multicast
features of the 802.16 MAC and ETHCS?  More than the current section 4.3
saying just that 802.16 MAC dl is mc while ul is not mc
(download/upload/multicast).

It's clear that IPv6 ND needs a link-layer that is multicast capable,
and in both directions.  802.16 MAC seems to be mc-capable (CID for
multiple links, MCA-REQ/RSP, etc).  However, it's not clear to me from
IEEE spec whether (1) both directions are mc capable and (2) the ETHCS
(_over_ 802.16MAC) offers a multicast capable link interface to IP.

Ie the questions are: (1) will a multicasted NS sent by SS get delivered
to that mc group?  or just the RA sent by BS? (is 802.16 MAC mc-capable
in both directions)? and (2) will an IPv6 RA sent to all-nodes IP and
all-nodes MAC address get delivered as such, when it's put on ETHCS (not
on 802.16MAC SAP)?  (will the ETHCS classifiers understand MAC multicast
dst addresses.)

If ETHCS is link-layer multicast capable then it is enough to say in the
document that ETHCS is link-layer multicast capable, with an example.
If ETHCS is not link-layer multicast capable, bidirectionally, I think
the draft should say that ETHCS should be link-layer multicast capable,
bidirectionally, otherwise IPv6 doesn't work on it.  I don't think the
draft should develop a technique to make ETHCS link-layer multicast
capable, bidirectionally.

If there is agreement or incentive I can provide text as I suggested above.

Alex

---

From: "Jihoon Lee" <[email-masked]>
Date: Fri, 12 Jan 2007 10:03:02 +0900

Hi Alex,

Let me jump into discussion.
1) 802.16/16e MAC has no capability to do uplink multicast. In DL,
802.16provides multicast CIDs which is initiated by DSA messages. In
UL, however,
there is no way for an MS to access others' UL data fundamentally, in
802.16PHY/MAC. In case of ETH over
802.16, the ETH(bridge) may cover this (an MS sends multicast data in UL,
and then a bridge forwards it back). But, there is still a difficulty in
multicasting data back except for the source MS.

Best regards,
Jihoon Lee

==============================================================

Jihoon(Brandon) Lee ([email-masked], [email-masked])
Multimedia  and Mobile Communication Laboratory, Seoul National University.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jan 2007 12:19:32 +0100

Hi Jihoon, thanks for reply,

Jihoon Lee wrote:
> Hi Alex,
> 
> Let me jump into discussion. 1) 802.16/16e MAC has no capability to 
> do uplink multicast. In DL, 802.16 provides multicast CIDs which is 
> initiated by DSA messages. In UL, however, there is no way for an MS 
> to access others' UL data fundamentally, in 802.16 PHY/MAC.

Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and
surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to
mention the word 'multicast'.)

The issue is that a SS running IPv6 needs to multicast a NA, from time
to time.  For DAD it needs to send a NS to a multicast address too.

> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS 
> sends multicast data in UL, and then a bridge forwards it back). But,
>  there is still a difficulty in multicasting data back except for the
>  source MS.

You mean the bridge in BS?  I was thinking ETHCS in SS may offer a
multicast interface to the IP stack.

In both cases (bridge in BS or bridge in SS), I think it is not up to
this document to specify how the ETHCS transforms a asymmetric ul/dl
multicast feature into a symmetric one.  But it should be a goal for
ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6
stack won't work.  What do you think?

Alex

---

From: Pars Mutaf <[email-masked]>
Date: Fri, 12 Jan 2007 15:25:00 +0100

Hi, sorry for popping up,

> > to access others' UL data fundamentally, in 802.16 PHY/MAC.

Do you think this is an accidental design choice (i.e. no uplink
multicast)? Or 802.16/16e MAC designers had very good fundamental
reasons? 

(I'm sorry. This question looks out-of IETF scope. But I think we may 
learn something more general i.e. useful to IP perhaps?)

Thank you.
pars

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jan 2007 17:43:59 +0100

Hi Pars, I would like so see others' oppinions on this too.

Pars Mutaf wrote:
>>> Let me jump into discussion. 1) 802.16/16e MAC has no capability 
>>> to do uplink multicast. In DL, 802.16 provides multicast CIDs 
>>> which is initiated by DSA messages. In UL, however, there is no 
>>> way for an MS to access others' UL data fundamentally, in 802.16 
>>> PHY/MAC.
> 

I'm not a link-layer designer.  I think the choice for 802.16MAC to
design multicast only downlink (not ul) is inline with the widespread
usage of mobile terminals: clients download stuff, rarely upload.

Multi-party video calls (not even IP) need however multicast to run
bothways ok to gain in efficiency.

And there are link-layers (802.11) that offer a multicast appearence to
the IP stack, bothways, despite the lower layer packet being sent
through the AP always.  This should happen over 802.16MAC ETHCS too,
otherwise ND won't work.

Alex

---

From: "Ray Bell" <[email-masked]>
Date: Fri, 12 Jan 2007 09:04:40 -0800

Alex,

I agree with your comments, and believe it is important to point out that
while 802.16e will be used by moble terminals, it will also be used by fixed
terminals (e.g., LAN WiMAX modem) -- by both retail & enterprise customers.
I believe that this reinforces the requirements which you have noted...

Ray

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, January 12, 2007 8:44 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS

Alex

---

From: "Steve Jackowski" <[email-masked]>
Date: Fri, 12 Jan 2007 09:14:49 -0800

All,

My 2 cents:

We work with WiMax and Satellite providers (who have the same basic 
topology).  The issue we've seen is the contention for the RF channels. 
This can be avoided on the downlinks, but is critical on the uplinks.  The 
asymmetry between up and downlinks combined with the point-multipoint 
topology exacerbates the problem.  At this time, most WiMax vendors are 
trying to block uplink broadcast/multicast to maximize uplink bandwidth 
available to subscribers (and to maximize the number of subscribers).  While 
historically networks had more download traffic than upload, the trend 
towards more peer-oriented networking creates a challenge that will 
ultmately be addressed, but is currently one of the biggest problems in 
WiMax.

Steve
----------------------------------------------------------------
Steve Jackowski
President/CEO
Deterministic Networks, Inc.
1200 Pacific Avenue, Ste 280
Santa Cruz, Ca 95060

Office: (831) 421-0388 x18
Mobile: (408) 813-6294
Fax: (831) 421-0394
www.DeterministicNetworks.com
"Secure Network Acceleration"

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, January 12, 2007 8:43 AM
Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS

>>>> Let me jump into discussion. 1) 802.16/16e MAC has no capability to do 
>>>> uplink multicast. In DL, 802.16 provides multicast CIDs which is 
>>>> initiated by DSA messages. In UL, however, there is no way for an MS to 
>>>> access others' UL data fundamentally, in 802.16 PHY/MAC.
>>

---

From: "Jihoon Lee" <[email-masked]>
Date: Sun, 14 Jan 2007 00:44:48 +0900

Hi Alex,

Sorry for my late response. Basically I agree with your opinion.
An IPv6 node requires a link local multicast address in order to perform
DAD, ND, and RA.

Contrary to our expectations, 802.16/16e don't support UL multicast
(which means an MS forwards data directly to other MSs in the same cell).

(BTW, I think I need to clarify the UL multicast I mentioned. I believe you
already know this: the multicast/broadcast which is sent by an MS  to other
MSs in the same cell (BS) cannot be supported in 802.16. However, other MSs
in another cell (BS) may receive this since the 802.16 backhaul (WiMAX
ASN) may multicast/broadcast at ETH or IP layer.)

I agree that the document needs to specify how to deal with this problem.

Best regards,
Jihoon

---

From: "Qiang Zhang" <[email-masked]>
Date: Sat, 13 Jan 2007 23:56:53 -0500

Hi All,

Physical layer UL/DL multicast or multiPackets should not be confused with
the access network multicast which can go across multiple cells managed by
one ASN, I think there should be no restriction for the design to
incorporate the IP or Eth level multicast initiated from  the ASN after
receiving a IP multicast packet from the MS, am confused why can't the ASN
also broadcast/multicast back to the same cell the MS is residing if you can
clarify

Qiang

On 1/13/07, Jihoon Lee <[email-masked]> wrote:
> (BTW, I think I need to clarify the UL multicast I mentioned. I believe
> you already know this: the multicast/broadcast which is sent by an MS  to
> other MSs in the same cell (BS) cannot be supported in 802.16. However,
> other MSs in another cell (BS) may receive this since the 802.16 backhaul
> (WiMAX ASN) may multicast/broadcast at ETH or IP layer.)
>

---

From: "Jihoon Lee" <[email-masked]>
Date: Mon, 15 Jan 2007 09:31:59 +0900

Hi Qiang,

Let me add on a few more words. As you know, normally ETH switches and IP
routers don't forward multicast/broadcast packets back to their source port.
It's based on assumption that local multicast has already done locally in
the network which is connected to the source port.

Let's say an multicast packet sent by an 802.16 MS is delivered to an ETH
bridge or IP access router. It will be forwarded to other ETH/IP interfaces
(ports), but may not be forwarded to its source interface. However, there
may be other MSs which have never receive the packets, since the source
interface is actually connected to an 802.16 link layer. As I understood,
the question starts from here; why doesn't 802.16 link layer support uplink
multicast/broadcast? Then, which entity could handle this?. Anyway it has to
be specified.

There must be various feasible solutions. Regarding per-MS(service flow) IP
tunnel, the tunnel end point may differentiate the source MS. I'm not sure
that there has ever been a firm resolution made. Whatever the
solution made, it should be transparent to IP/ETH layer. Moreover, the
link-layer performance in terms of air bandwith efficiency is also
important.

Best regards,
Jihoon

2007/1/14, Qiang Zhang <[email-masked]>:
> > other MSs in another cell (BS) may receive this since the 802.16backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.)
> >
> > 2007/1/12, Alexandru Petrescu <[email-masked] >:
> > >

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Jan 2007 13:24:08 +0100

Hi Jihoon,

Jihoon Lee wrote:
> Hi Alex,
> 
> Sorry for my late response. Basically I agree with your opinion. An 
> IPv6 node requires a link local multicast address in order to perform
>  DAD, ND, and RA.
> 
> (BTW, I think I need to clarify the UL multicast I mentioned. I 
> believe you already know this: the multicast/broadcast which is sent 
> by an MS  to other MSs in the same cell (BS) cannot be supported in 
> 802.16. However, other MSs in another cell (BS) may receive this 
> since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH 
> or IP layer.)
> 

Yes, I think the IPv6-over-ETHCS document should make clear the
assumption of IPv6 using link-layer multicast for IPv6.  I don't think
the IPv6-over-ETHCS document should solve the problem you mention above
between parenthesis (uplink mc, or mc between BSs) at link layer.

The IPv6-over-ETHCS document could list the behaviour of ETHCS it
expects.  Ie:

-when MS sends NS to a IP solicited-node multicast address the node who
  has joined group must receive it.
-when BS or AR advertises an RA to all-nodes multicast address then all
  SSs who have joined that group must receive it.
-mapping an IPv6 link-local multicast address should happen (eg sending
  a packet to IP dst ff02::1 should have the link-layer dst
  33:33:33:0:0:0:1).

The document IPv6-over-ETHCS should list what are the means for SS to
_join_ a link-layer multicast group.  There are few of them (send a
link-layer message, send a MLD message, establish a local filtering
rule, always receiving all packets, etc).

But I don't think the IPv6-over-ETHCS document should specify the
link-layer behaviour for an implementation of ETHCS link-layer
multicast.  Do you agree with this latter item?

Alex

> 
> Best regards, Jihoon
> 
> 
> 2007/1/12, Alexandru Petrescu <[email-masked] 
> <mailto:[email-masked]>>:
> 
>>  do uplink multicast. In DL, 802.16 provides multicast CIDs which 
>> is initiated by DSA messages. In UL, however, there is no way for 
>> an MS to access others' UL data fundamentally, in 802.16 PHY/MAC.
> 
>  normal) multicast then that is a big issue for IPv6-over-IPv6CS. 
> (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't 
> seem to mention the word 'multicast'.)
> 
> The issue is that a SS running IPv6 needs to multicast a NA, from 
> time to time.  For DAD it needs to send a NS to a multicast address 
> too.
> 
>> sends multicast data in UL, and then a bridge forwards it back). 
>> But, there is still a difficulty in multicasting data back except 
>> for the source MS.
> 
>  ETHCS to offer such an interface to the IPv6 stack, otherwise the 
> IPv6 stack won't work.  What do you think?
> 
> Alex
> 
>

---

From: "Jihoon Lee" <[email-masked]>
Date: Tue, 16 Jan 2007 09:11:42 +0900

Hi Alex,
I agree with that.

Thanks,
Jihoon

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Jan 2007 14:25:57 +0100

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

---

From: "Daniel Park" <[email-masked]>
Date: Tue, 16 Jan 2007 22:57:30 +0900

Folks,

> the IPv6-over-ETHCS document.

[chair hat-on]

The thread is digressing from the point at issue. Following the 16ng
charter, we will definitely work on a single EthernetCS document to be
ready for publication. While chartering, we (chairs, IAB, IESG and
several experts on this field) had many discussion and ended up to
this conclusion. Thus, please focus on the technical aspect itself not
inputing to separate it.

[chair hat-off]

Alex, your contribution on the current EthernetCS document would be
valuable and acceptable to me. So, please do this...:-)

Thanks,

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Jan 2007 16:24:56 +0100

Daniel Park wrote:
> Folks,
> 
>> 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.
> 
> [chair hat-on]
> 
> charter, we will definitely work on a single EthernetCS document to
> be ready for publication. While chartering, we (chairs, IAB, IESG and
> this conclusion. Thus, please focus on the technical aspect itself
> not inputing to separate it.

Dear Chair, I was not aware of the decision.

> valuable and acceptable to me. So, please do this...:-)

Thanks, I can only submit contribution about IPv6-over-ETHCS (maybe 
section in the full IPv6-IPv4 document).  I can not write text about
IPv4-over-ETHCS for several reasons.  I have implemented IPv6 not IPv4.
  IPv4 does not have stringent requirements with respect to the
link-layer supporting multicast.  IPv4 requires link-layer to be
broadcast capable, not multicast.

I will agree with the group's decisions.

Alex

---

From: "Daniel Park" <[email-masked]>
Date: Wed, 17 Jan 2007 00:34:58 +0900

Thanks much Alex for your prompt and kind understanding.

I'd recommend authors of EthernetCS document to devide technical
sections into IPv4 and IPv6. Then, you who are willing to contribution
IPv6 only will be able to do your work more efficient than now. Also,
who are interesting in IPv4 only will be able to contribute their
efforts to IPv4 section as well...

Author of EthernetCS document, please take care of Alex' concern...:-)

Thanks in advance,

Daniel

--

---

From: "David Johnston" <[email-masked]>
Date: Tue, 16 Jan 2007 08:42:43 -0800

I don't agree with that.

An UL Ethernet MSDU with a multicast or broadcast DA should get sent to
members of the multicast group/everyone in the bridged LAN. Since 802.16
implements a point to point Ethernet similarly to modern cat 5 ethernet,
then either everyone=the Ethernet termination in the BS, or it hits an
802.1D bridge in the BS and so the bridge deals with sending it to the
other 802 
LANs to which is it has bridge ports, including other SSs.

As I mentioned before, an 802.16 BS does not implement one network, it
implements a bunch of point to point networks that may be joined by a
bridge or IP routing or any other scheme that is implemented in the BS.

DJ

________________________________

From: Jihoon Lee [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 4:12 PM
To: Alexandru Petrescu
Cc: [email-masked]; [email-masked]
Subject: [16NG] Re: multicast and IPv6 over ETHCS

Hi Alex,

I agree with that.

Thanks,

Jihoon

2007/1/15, Alexandru Petrescu <[email-masked] >: 

Hi Jihoon,

Alex

>
> Best regards, Jihoon
>
>
> 2007/1/12, Alexandru Petrescu < [email-masked]
<mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Jan 2007 17:51:47 +0100

David Johnston wrote:
> I don’t agree with that.

David, I'm trying to identify whether your disagreement matches my
understanding.

What don't you agree with?  You don't agree that IP-over-ETHCS
document should not specify how the link-layer implements link-layer
multicast?  In other words do you suggest that the document _should_
specify how the link-layer implements link-layer multicast?

> An UL Ethernet MSDU with a multicast or broadcast DA should get sent 
> to members of the multicast group/everyone in the bridged LAN.

Yes.  Is this a problem?

> Since 802.16 implements a point to point Ethernet similarly to modern
>  cat 5 ethernet, then either everyone=the Ethernet termination in the
>  BS, or it hits an 802.1D bridge in the BS and so the bridge deals 
> with sending it to the other 802 LANs to which is it has bridge 
> ports, including other SSs.

I sense this is a way of implementing it.  It is however a link-layer
method.

> As I mentioned before, an 802.16 BS does not implement one network, 
> it implements a bunch of point to point networks that may be joined 
> by a bridge or IP routing or any other scheme that is implemented in 
> the BS.

What is that IP routing scheme that implements a link-layer?  Is it
MPLS?  What other?

Do you suggest that the draft IP-over-ETHCS recommends the 802.16 BS to
implement a bunch of point to point networks joined by an IP router?

I think the draft _could_ list some means by which the link-layer
multicast  _could_ be implemented (major use of word 'MAY') but not to
make any recommendation about that.

Alex

> 
> 
> DJ
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> *From:* Jihoon Lee [mailto:[email-masked]] *Sent:* Monday, 
> January 15, 2007 4:12 PM *To:* Alexandru Petrescu *Cc:* 
> [email-masked]; [email-masked] *Subject:* [16NG] Re: multicast and
>  IPv6 over ETHCS
> 
> 
> 
> Hi Alex,
> 
> I agree with that.
> 
> 
> 
> Thanks,
> 
> Jihoon
> 
> 
> 
> 
> 
> 
> 
> 2007/1/15, Alexandru Petrescu <[email-masked] 
> <mailto:[email-masked]> >:
> 
> Hi Jihoon,
> 
> Jihoon Lee wrote:
>> Hi Alex,
>> 
>>  IPv6 node requires a link local multicast address in order to 
>> perform DAD, ND, and RA.
>> 
>> believe you already know this: the multicast/broadcast which is 
>> sent by an MS  to other MSs in the same cell (BS) cannot be 
>> supported in 802.16. However, other MSs in another cell (BS) may 
>> receive this since the 802.16 backhaul (WiMAX ASN) may 
>> multicast/broadcast at ETH or IP layer.)
>> 
> assumption of IPv6 using link-layer multicast for IPv6.  I don't 
> think the IPv6-over-ETHCS document should solve the problem you 
> mention above between parenthesis (uplink mc, or mc between BSs) at 
> link layer.
> 
> -when MS sends NS to a IP solicited-node multicast address the node 
> who has joined group must receive it. -when BS or AR advertises an RA
>  to all-nodes multicast address then all SSs who have joined that 
> group must receive it. -mapping an IPv6 link-local multicast address 
> should happen (eg sending a packet to IP dst ff02::1 should have the 
> link-layer dst 33:33:33:0:0:0:1).
> 
>> <mailto:[email-masked]
> <mailto:[email-masked]>>>:
>> 
>> Ok.  For one, if the 802.16MAC is not capable to do bidirectional 
>> (or normal) multicast then that is a big issue for 
>> IPv6-over-IPv6CS. (and surprisingly, apparently the document 
>> IPv6-over-IPv6CS doesn't seem to mention the word 'multicast'.)
>> 
>>>  But, there is still a difficulty in multicasting data back 
>>> except for the source MS.
>> 
>> In both cases (bridge in BS or bridge in SS), I think it is not up 
>> to this document to specify how the ETHCS transforms a asymmetric 
>> ul/dl multicast feature into a symmetric one.  But it should be a 
>> goal for ETHCS to offer such an interface to the IPv6 stack, 
>> otherwise the IPv6 stack won't work.  What do you think?
>> 
>> Alex
>> 
>> 
> 
> 
>

---

From: "David Johnston" <[email-masked]>
Date: Tue, 16 Jan 2007 08:58:03 -0800

I was disagreeing with the statement that 802.16e doesn't support UL
multicast. It doesn't down in the depths of the 802.16 MAC, but at the
MAC service it does, using the existing 802 rules of addressing,
bridging and point to point LANs.

I don't think it is necessary for the IETF to specify how link layer
multicast is implemented, since 802 already does.

DJ

> Sent: Tuesday, January 16, 2007 8:52 AM
> To: David Johnston
> Cc: Jihoon Lee; [email-masked]; [email-masked]

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Tue, 16 Jan 2007 18:11:14 +0100

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

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 1:24 PM
To: Jihoon Lee
Cc: [email-masked]; [email-masked]
Subject: [16NG] Re: multicast and IPv6 over ETHCS

Hi Jihoon,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jan 2007 10:54:26 +0100

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]

>  following: - ff02::1 maps into 33:33:00:00:00:1 - and the others.
> 
> 
> before receiving packets addressed to that group. For example, before
>  receiving a Router Advertisement the stack MUST join the IPv6 
>  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.
>

---

From: "Jihoon Lee" <[email-masked]>
Date: Wed, 17 Jan 2007 19:20:19 +0900

Hi Alex,

My comments are inline.

Best regards,
Jihoon

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

---

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

Hi Jihoon, thanks for your comments.

Jihoon Lee wrote:
> 2007/1/16, Alexandru Petrescu <[email-masked] 
> 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.

I think (2) wasn't clear.  I think mapping between link-layer multicast 
addresses and IPv6 link-local addresses is mainly done by the IPv6 
stack, not by the link layer.  That mapping should happen, because it's 
the IPv6 stack building the MAC headers.  I think I can rewrite that to 
say that the IPv6 stack does the mapping, would this be ok?

I agree we should not touch ETHCS packet classiffication.

But I think (3 - offer the capability of joining and leaving IPv6 
link-local multicast addresses) is in the scope below the IPv6 stack.

> 802.16 CS layer. There should be multiple choices to implement this. 
> However, I think it's worth mentioning what (+ where) should be done. 

Maybe.  But if it's done, these methods should be 'MAY' and in Appendix 
I believe.

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

I agree it's too simple, and doesn't cover all that 802.16 MACs can do.

> Assumption: IPv6 ND messages cannot be transmitted to other MSs served 
> by the same BS without any additional supporting function.
>  
> 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.
> (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 ).
> messages to other MSs except for the source MS. (How? keep this 
> open. Where? AR).
> 4) ...

Sounds as a good plan, as an example of implementing link-layer 
multicast.  But I strongly suggest it to contain 'MAY' statements 
everywhere and have it entirely in appendix, as an example of potential 
implementation of link-layer multicast.  This is very good for easing 
readers and understand what the authors tried to say.

> is another message in IPv6 which is not mentioned in the last paragraph.

You're right.  There are at least DHCP Discovers that are sent to 
link-local multicast addresses (and thus link-layer multicast 
addresses).  There may be many others I don't know, or currently under 
development in other WGs.  I could reformulate to be clear that that 
list is not exhaustive.

But I would like to get first clear agreement from draft's authors 
whether it makes sense to include this text, and where in the draft. 
Once I know that I can finely tune it better to WG members' acceptance.

Alex

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Wed, 17 Jan 2007 14:44:24 +0100

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,

Thanks,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jan 2007 16:56:13 +0100

Max, thanks for your comments.  It seems our disagreement is larger than
I thought :-)

In another mail I've tried to suggest that there is value in text that
doesn't specify new behaviour (ie IPv6 runs over ETHCS as usual, no new
behaviour) while you think that a new behaviour should be specified
(albeit link-layer).

I think there are other people on the list who agree that this document
should not specify link-layer behaviour.

Riegel, Maximilian wrote:
> Hi Alex,
> 
> Your text on the behavior of the IPv6 stack on handling multicast 
> looks like standard IPv6 behavior.

Yes, it is standard behaviour of IPv6 stack over a link-layer multicast
capable link, nothing new, that's the intention.

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

Well if it's standard behaviour then it can't be informational, right?

It should be formulated such as to not tresspass the main documents
specifying this (2464, 2461, dhcp, etc) and to _recommend_ them - I agree.

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

I agree if it were so.  But no the text doesn't change standard IPv6
behaviour, far from my intention.  At some point it gets a little more
than standard behaviour: it requires the SS to put link-layer multicast
addresses in the  link-layer header, something that current RFCs don't
require, but implementations do.

If you need, I can change that formulation to not tresspass at all, ie
to say  that implementations MAY use link-layer multicast addresses in
link-layer header fields.  Do you want me to do that?

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

I think this Proposed Standards document is not the place to specify
link-layer behaviour.

> RFC4541 is an example of such an extension to the Ethernet layer.

YEs, and it's INFORMATIONAL at IETF.  Do you think this IPv6-over-ETHCS
document should be INFORMATIONAL?

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

Sounds reasonable to me.  But how that happens shouldn't be specified here.

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

Thanks for this clarification.  So one is tempted to call the document
"IP over bridge device in the system deploying the ETH-CS for
transmitting Ethernet frames over IEEE 802.16".   A terminology issue.

I can re-formulate the multicast phrases in my text to say the the
link-layer multicast goals MAY be implemented by the bridge device in
the system deploying the ETH-CS for transmitting Ethernet frames over
IEEE 802.16.  Do you agree that I re-formulate it that way?

Do you or co-authors accept to introduce my text in the draft?

If yes - where?

I'm not pushing to do it now - please take the time - but if you or
co-authors do, and when you do, please let me know.  Once I know we have
agreement to include the multicast text in the draft I can modify it
according to all suggestions raised on the list.

Alex

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Wed, 17 Jan 2007 17:43:33 +0100

Alex,

I do not know why RFC4541 has become INFORMATIONAL. There may be other
reasons than that it addresses functions below the IP layer. But I still
believe that the IETF is the right place to write specifications on how
IP packets are carried over foo. And in the case of IPoETHo802.16 it is
not a particular framing format but particular functions in the link
layer supporting IP behavior, which we have to specify.
If I am following your statement, PPP would not be in the scope of the
IETF.

>transmitting Ethernet frames over IEEE 802.16".   A terminology issue.

You can just call it 'IP over Ethernet over IEEE802.16'. The bridge
device together with the ETH-CS transport is exactly what is regarded as
'Ethernet'.

Bye
Max

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, January 17, 2007 4:56 PM
To: Riegel, Maximilian
Cc: [email-masked]; Jihoon Lee
Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS

It should be formulated such as to not tresspass the main documents
specifying this (2464, 2461, dhcp, etc) and to _recommend_ them - I
agree.

>  take place in the Ethernet layer over IEEE802.16.

Sounds reasonable to me.  But how that happens shouldn't be specified
here.

If yes - where?

Alex

---

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

Riegel, Maximilian wrote:
> Alex,
> 
> I do not know why RFC4541 has become INFORMATIONAL.

I don't know either, so it is.  Would you like to suggest change its status?

But it looks logical for IP-over-ETHCS to refer first and foremost to
MLDv2 (Proposed Standard) and only after that works refer an
INFORMATIONAL usage of it. No?

> There may be other reasons than that it addresses functions below the
>  IP layer. But I still believe that the IETF is the right place to 
> write specifications on how IP packets are carried over foo.

Yes, IP-over-foo.  I completely agree.

> And in the case of IPoETHo802.16 it is not a particular framing 
> format but particular functions in the link layer supporting IP 
> behavior, which we have to specify.

Excuse me, but 'particular functions in the link layer' are not to be
specified at IETF.

We can try to dissect what 'particular functions in the link layer' is.
  For example, does that function build a link-layer packet?  Does that
function write an IP address in an IP-or-above header?

> If I am following your statement, PPP would not be in the scope of 
> the IETF.

Right, that was solved by saying PPP is not link-layer but layer 2/3.
It doesn't build headers.  More recently one sees PANA (full UDP) and
EAP (independent of link-layer) and ppp doesn't get much upgrade at  IETF.

But, why do you mention ppp here?  Do you see ppp anywhere in the
IP-over-ETHCS context?  I'd be glad to know.  And I'm asking this
because ppp is used everywhere on GPRS/UMTS, and pppoe is used on some
HSDPA.

Using ppp changes the landscape completely and if it's the case it
should be stated.

>>>  Convergence Layer but by a bridge device in the system deploying
>>>  the ETH-CS for transmitting Ethernet frames over IEEE802.16.
>> Thanks for this clarification.  So one is tempted to call the 
>> document "IP over bridge device in the system deploying the ETH-CS
>>  for transmitting Ethernet frames over IEEE 802.16".   A
>> terminology issue.
> 
> device together with the ETH-CS transport is exactly what is regarded
>  as 'Ethernet'.

Do you mean the SS must have this 'bridge device' built-in?

If SS doesn't have the 'bridge device' built-in then maybe there's
nothing to be specified for the SS.

Do you mean brctl? (bridge software on linux).  This is software not
hardware and is present in Bluetooth, but not on the SS, only on the AP.
(Bluetooth had same problem of making ptp links look as
  multicast-capable, see PAN profile).

Alex

---

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

Alex,

Again a comment on just one of your statements:

On 1/17/07 11:04 AM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

> And I'm asking this

PPP or PPPoE is NOT used in GPRS/UMTS or HSDPA.
PDP context != PPP or PPPoE

-Raj

---

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

Alexandru Petrescu wrote:
>  It doesn't build headers.  More recently one sees PANA (full UDP) 
> and EAP (independent of link-layer) and ppp doesn't get much upgrade
>  at  IETF.

Also, ppp-over-ethernet is informational.  But L2TP is what goes on
Standards Track, and L2TP+somePPPoE is informational while LCP+L2TP is
std track.

The second reason for mentioning this is that someone may think
something else than GRE could be used in a 802.16 deployment - it's the
case, so don't make GRE mandatory.

Alex

---

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

Basavaraj Patil wrote:
>> And I'm asking this because ppp is used everywhere on GPRS/UMTS,
>> and pppoe is used on some HSDPA.
> 
> PPP is NOT used in GPRS/UMTS or HSDPA.

How do you know?  I know because I've tried.  It's always the pppd
program and ConfigReq sent/received.

Do you mean a SDO spec says that PDP context is set up?  And that that
SDO document doesn't say 'ppp is used'?  I agree with this part.

> PPPoE is NOT used in GPRS/UMTS or HSDPA.

What do you call a PPP ConfigReq within a MAC header with 48bits
addresses, as displayed by Ethereal?  And with a pcmcia card saying hsdpa.

> PDP context != PPP or PPPoE

I'm sorry.  PDP context is not something defined at IETF, a different
beast, can't compare.

Alex

---

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

Alex,

> program and ConfigReq sent/received.

The PPP that you are talking about is most likely not between your PC card
(that is implementing GPRS/HSDPA) and the GGSN. You could be doing PPP over
a PDP context that is established between the PC card and the GGSN. Question
is, does the PPP terminate at the GGSN? Of course not knowing what kind of
service you are using or details, I can only speculate.

> SDO document doesn't say 'ppp is used'?  I agree with this part.

PPP is an overhead and not required to transport IP packets in GPRS. PDP
contexts are the mechanism used for carrying IP packets.

> addresses, as displayed by Ethereal?  And with a pcmcia card saying hsdpa.

Your Ethereal may not really be have the drivers to read what is being sent
by the HSDPA card... I don't know. As I said above, tell me where is PPP
being terminated in the network, i.e the GPRS core?

> I'm sorry.  PDP context is not something defined at IETF, a different

And I am not asking you to do so. I was just correcting a statement about
PPP usage that you made. And it appeared to be a globally applicable
statement to all GPRS/UMTS/HSDPA deployments.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jan 2007 19:04:58 +0100

Raj, thanks for the email.  I will not post further on this topic, not
because I don't want to reply to you, but because I've already got
private indication (from Chairs and AD) that I should stop ppp
discussion, there's nothing new or relevant to the IP-over-IP/ETHCS.

Alex

Basavaraj Patil wrote:
> The PPP that you are talking about is most likely not between your PC
>  card (that is implementing GPRS/HSDPA) and the GGSN.

I'm sorry but I don't care.  It's about my IP laptop and a certain
network.  IETF doesn't define what's GGSN nor SGSN.  I believe (not
sure) no deployment has strict GGSN/SGSN separation (separation
suggested by SDO and graduate textbooks).

> You could be doing PPP over a PDP context that is established between
>  the PC card and the GGSN. Question is, does the PPP terminate at the
>  GGSN? Of course not knowing what kind of service you are using or 
> details, I can only speculate.

YEs, I agree.  I no longer bother to even speculate, I'm torn down by
these speculations, too many traceroutes, too many pings, on every
operator's different topology.

I prefer to see it as a network into which I can ppp, with a certain
qos.  This is the typical point of view adopted by a end host.

>> Do you mean a SDO spec says that PDP context is set up?  And that 
>> that SDO document doesn't say 'ppp is used'?  I agree with this 
>> part.
> 
> PPP is an overhead and not required to transport IP packets in GPRS.

Well that's what many people do (see 'globally' interpreted at the end
of this message).  Not even Compression modules are used.  It works.

> PDP contexts are the mechanism used for carrying IP packets.

There's no IP-over-PDPcontext StdsTrack RFC, sorry.

I too run IPv6-over-RS232 w/o an RFC telling me how, it works, doesn't
upset anybody, and solves today's context sometimes (think really small
custom stuff).

SDO can do that too with its PDP contexts, unless it upsets somebody.

> Your Ethereal may not really be have the drivers to read what is 
> being sent by the HSDPA card... I don't know.

WEll it does have necessary drivers telling me that.  It's enough for
making run the IPv6 stack, no more needed.

> As I said above, tell me where is PPP being terminated in the 
> network, i.e the GPRS core?

Sorry, I don't know precisely.  It terminates somewhere in the network.
  I could tell you all the experiments I've done to find that precise
question you ask, and how they were voided by simply connecting to
another operator.

>> I'm sorry.  PDP context is not something defined at IETF, a 
>> different beast, can't compare.
> 
> And I am not asking you to do so. I was just correcting a statement 
> about PPP usage that you made. And it appeared to be a globally 
> applicable statement to all GPRS/UMTS/HSDPA deployments.

Ok, what's globally applicable.  To me globally applicable is the
following: google APN name and find the name of operators that will
allow one to ppp into their cell networks.  One will find cell operators
all over the world.  I've personally tried a bunch of them in Europe and
the 2-3 available in US.  GPRS and UMTS and HSDPA.  Is this globally 
applicable to you?

Alex

---

From: "Qiang Zhang" <[email-masked]>
Date: Wed, 17 Jan 2007 16:18:51 -0500

Is there a real case that PPP/PPPoE is overlaid on top PDP or PPP (PDSN
case) or LAP? My guess is that No, i haven't seen a DIALer that does this
and there is no reason to do so. There is case that PC PPP to the AT though
but this terminates at the AT

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 21:54:14 +0100

> messages to other MSs except for the source MS. (How? keep this 

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

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Thu, 18 Jan 2007 22:42:09 +0100

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:[email-masked]] 
Sent: Thursday, January 18, 2007 9:54 PM
To: Jihoon Lee
Cc: [email-masked]
Subject: [16NG] Re: stepped multicast operation (was: and IPv6 over
ETHCS)

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

Alex

---

From: "Jihoon Lee" <[email-masked]>
Date: Fri, 19 Jan 2007 08:28:49 +0900

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

Thanks,
Jihoon

---

From: "Jihoon Lee" <[email-masked]>
Date: Fri, 19 Jan 2007 11:14:09 +0900

Hi Alex,

Please see inline comments.

Jihoon

> why I think step 3 should be preceded by a big MAY.

Yes, you're right. In addition, we should not specify it, as Max said.

> special to run a special IPv6 over ETHCS. What do you think?

Yes, I presume that we may not need any special add-on function on SS
to address this multicast problem. But, I assume that there may be something
in BS or AR or between them. BTW, definately there must be IPv6 stack, ETHCS
layer, and 802.16 MAC/PHY on SS, which are supporing RFCs required.

Firstly, let's consider all possible ways.

> IPv6-over-ETHCS document. What do you think?

I think you can mention (1) and (2) for SS. However, (3) is impossible.

At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is a kind
of ack, which has only Transaction Id (which can distinguish each 802.16 MAC
message transaction) and Confirmation Code (return code such as
success/failure). And MCA-REQ shall be initiated by a BS. Therefore, using
MCA-REQ/RSP is not appropriate.
(For your information, 802.16 MBS creates 802.16 (DL) multicast connection
using DSA-REQ/RSP/ACK messages)

In addition, we'd better not mention any 802.16 message explicitly. (BTW, I
think there is no 802.16 message which may do this....hmm)

> non-existent. In this way we could be ok with the IEEESpec (not modify

As I see, this scenario is more plausible. But I don't fully understand your
intention.
(1) and (2) are ok.
> any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 stack.
This is the BS side, right?
> 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.
I don't understand this sentence. Could you make this clear?

Note that there is no 802.16 classifier in rx side regardless of BS or MS.

> risk of bad flooding effects.

Yes. It's desirable.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jan 2007 12:15:44 +0100

Jihoon Lee wrote:
>  to address this multicast problem. But, I assume that there may be 
> something in BS or AR or between them. BTW, definately there must be 
> IPv6 stack, ETHCS layer, and 802.16 MAC/PHY on SS, which are 
> supporing RFCs required.
> 

I think it is important to identify whether anything special is needed
on SS.  I mean anything other than rfc2461, rfc2464 and MLDv2 and the
other RFCs.

>> 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?
>> 
> 
> At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is
>  a kind of ack, which has only Transaction Id (which can distinguish 
> each 802.16 MAC message transaction) and Confirmation Code (return 
> code such as success/failure). And MCA-REQ shall be initiated by a 
> BS. Therefore, using MCA-REQ/RSP is not appropriate.

Ok, thanks, I understand MCA-RSP is not specified to be sent unsolicited
but as a response.

In this case, we can specify that BS before sending a RA it sends a
MCA-REQ to poll who are the SS's interested in receiving that RA, and
thus SS can send the MCA-RSP as it is designed.

Remark that the router (entity who sends the RA - BS or AR) MUST join
the all-routers address (rfc2461), with a MLD or with a local filter
(popular interpretation).  So subsequent to sending that MLD REPORT, or
setting up filtering rule, it can send the MCA-REQ.  So we can trigger
the sending of MCA-REQ either by sending the RA, or by MLD JOIN for
all-routers, etc.

What do you think about this?  Is this violating anything in 802.16.
What method would you prefer?

> (For your information, 802.16 MBS creates 802.16 (DL) multicast 
> connection using DSA-REQ/RSP/ACK messages)

As I understand it DSA-REQ/RSP/ACK are for allocating service flows with
a certain QoS, bandwidth request, (table 113 ieee-2004).  This DSA-REQ
is for a multicast CID, ok.  I understand DSA-REQ/RSP/ACK are not
specifically designed to indicate intention of belonging to a mc group -
which is what I'm looking for, the equivalent of MLD REPORT.

What do you think?  Should I look elsewhere in the spec?

> In addition, we'd better not mention any 802.16 message explicitly. 
> (BTW, I think there is no 802.16 message which may do this....hmm)

I think that if we can use the 802.16 message in the way it is intended
to, and if we can get comment from 802.16 expert, then we may be fine.
It may also be that it's not fine at all, by expert oppinion.

>> 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).
> 
> 
> As I see, this scenario is more plausible. But I don't fully 
> understand your intention. (1) and (2) are ok.

I meant SS.

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

Yes, the goal is for SS.  SS's ETHCS shouldn't deliver ('put') a PDU it
receives from BS's ETHCS, that is addressed to 33:33, to the IPv6 stack,
if SS's doesn't have a 'reconstitution' classifier rule for it.

So one would basically require that only if there is a reconstitution
rule in SS's ETHCS for the 33:33 dst and a normal CID, should the ETHCS
deliver the packet to the IPv6 stack of the SS.

(I should have said maybe 'reconstitution' instead of 'uplink
  classifier'. Figure 7, 8 ieee-2004.  Basically SS has only uplink
  classifiers, BS has only downlink classifiers, when they send packets;
  and they have 'reconstitution' when they receive packets).

> Note that there is no 802.16 classifier in rx side regardless of BS 

I agree, I should have said 'reconstitution' then?  Can the
'reconstitution' part  of SS, the one that undoes PHS, have such a
classifier rule?

If it does not then one really has to prevent unwanted 33:33-addressed
messages to reach the SS.  Apparently the only way left is to do it at
BS, send the 33:33-addressed packets only to those SS's that are
interested.  What do you think?

> multicast packets for which it hasn't joined, because this augments 
> the risk of bad flooding effects.
> 
> 
> Yes. It's desirable.

I agree it is desirable.  To me it is at least desirable, and more, it
is a MUST.  I think we could have been more in agreement if we defined
in detail what the flooding problem is.

Alex

---

From: "Jihoon Lee" <[email-masked]>
Date: Sat, 20 Jan 2007 01:54:57 +0900

Hi Alex,

>on SS.  I mean anything other than rfc2461, rfc2464 and MLDv2 and the

Ok. I understood your intention.

> What method would you prefer?

 Right now, I'm not sure about the usage of 802.16 MCA messages. Actually I
thought the MCA differently. You may need to ask an 16 expert the usage of
MCA.

> What do you think?  Should I look elsewhere in the spec?

Here is another feasible way. I believe this is similar to what you're
trying to do:

DSA performs 802.16 connection setup as well as the service flow creation.
If there is no connection (actually CID) on SS, the SS cannot receive it at
802.16 link layer. When BS creates multicast connection between itself and
MSs, DSA transaction is required for each MS. Therefore, BS can manage its
multicast group which is associated with 802.16 multicast CID. In other
words, MS may join by initiating DSA with appropriate multicast CID.
Because, in theory, DSA can be initiated by either BS or MS. Consequently,
the multicast can be delivered to intended users only in 802.16 link-layer.

BTW, basically 802.16 doesn't know any upper layer messages such as
IGMP/MLD-REPORT. So, there may be some issues, i.e., who will trigger a
multicast connection setup, and which is better, BS-initiated or
MS-initiated.

The MBS will be discussed in WiMAX Forum at the end of this month. Then, we
may refer to details in DL multicast.

> and they have 'reconstitution' when they receive packets).

 Ok. 'reconstitution' is fine to me.

> Can the 'reconstitution' part  of SS, the one that undoes PHS, have such a
> classifier rule?
>

I think you cannot define any classification rule in 'reconstitution' part
of SS, since the 'reconstitution' part is defined in 802.16. Why don't you
do that on top of 802.16?

BTW, how about the scenario I mentioned above?  I think it could also
prevent unwanted/not-joined 33:33-addressed messages to reach the SS.

Best regards,
Jihoon

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jan 2007 18:56:01 +0100

Jihoon Lee wrote:
>> Ok, thanks, I understand MCA-RSP is not specified to be sent 
>> unsolicited but as a response. In this case, we can specify that BS
>>  before sending a RA it sends a MCA-REQ to poll who are the SS's 
>> interested in receiving that RA, and thus SS can send the MCA-RSP 
>> as it is designed. Remark that the router (entity who sends the RA 
>> - BS or AR) MUST join the all-routers address (rfc2461), with a MLD
>>  or with a local filter (popular interpretation).  So subsequent to
>>  sending that MLD REPORT, or setting up filtering rule, it can send
>>  the MCA-REQ.  So we can trigger the sending of MCA-REQ either by 
>> sending the RA, or by MLD JOIN for all-routers, etc. What do you 
>> think about this?  Is this violating anything in 802.16. What 
>> method would you prefer?
> 
> Right now, I'm not sure about the usage of 802.16 MCA messages. 
> Actually I thought the MCA differently. You may need to ask an 16 
> expert the usage of MCA.

David, do you think an IPv6 stack on the BS can ask the 802.16MAC to
send a MCA-REQ to SS to ask it whether it's interested in receiving
packets addressed to 33:33:0:0:0:1?

>> As I understand it DSA-REQ/RSP/ACK are for allocating service flows
>>  with a certain QoS, bandwidth request, (table 113 ieee-2004).
>> This DSA-REQ is for a multicast CID, ok.  I understand
>> DSA-REQ/RSP/ACK are not specifically designed to indicate intention
>> of belonging to a mc group - which is what I'm looking for, the
>> equivalent of MLD REPORT. What do you think?  Should I look
>> elsewhere in the spec?
> 
> Here is another feasible way. I believe this is similar to what 
> you're trying to do:
> 
> DSA performs 802.16 connection setup as well as the service flow 
> creation. If there is no connection (actually CID) on SS, the SS 
> cannot receive it at 802.16 link layer. When BS creates multicast 
> connection between itself and MSs, DSA transaction is required for 
> each MS. Therefore, BS can manage its multicast group which is 
> associated with 802.16 multicast CID. In other words, MS may join by 
> initiating DSA with appropriate multicast CID. Because, in theory, 
> DSA can be initiated by either BS or MS. Consequently, the multicast 
> can be delivered to intended users only in 802.16 link-layer.

[At which point there  would be a need to be able to convert IPv6
  link-local multicast addresses to multicast CIDs, right?  Like ff02::1
  to 16bit.  Or do you think 802.16MAC converts the 33:33::1 to a
  multicast CID?]

I understand.  So the SS uses DSA messages to indicate interest in a
multicast-CID reception, and the BS keeps track of interests.  It makes
sense to me.  The packets addressed to a multicast group will arrive to
SS on that multicast CID.

But I think we still need to say that it is the SS who triggers that DSA
exchange, ie SS's IPv6 stack.  Do you agree?

It can happen in of the following alternative 2 ways: (1) IPv6 stack
generates a MLD REPORT and puts it to ETHCS Driver.  ETHCS Driver
interprets it, drops it, and sends the corresponding DSA-REQ; (2) IPv6
stack calls a function in ETHCS Driver giving it parameter 33:33::1 and
ETHCS Driver generates the DSA-REQ.

I think this should work.

> IGMP/MLD-REPORT.

Unless it 'snoops' them?

> So, there may be some issues, i.e., who will trigger a multicast 
> connection setup, and which is better, BS-initiated or MS-initiated.

Most IPv6 stacks currently call some function to join a certain group.
Some generate MLD REPORTS, some others just call a driver's function.
This can be matched into DSA-REQ/RSP.

All IPv6 router stacks must join all-routers group, so the BS (_if_ it
sends RAs) should join.  This matches the model of BS sending MCA-REQ
and SS sending MCA-RSP.

> The MBS will be discussed in WiMAX Forum at the end of this month. 
> Then, we may refer to details in DL multicast.

Sorry, I don't know what's MBS.

I think we have freedom to propose something that makes sense for
multicast IPv6 over ETHCS, here.  If there's agreement in the group and
gets drafted then maybe MBS and WiMax will be interested to know what
the draft says.

>> If it does not then one really has to prevent unwanted 
>> 33:33-addressed messages to reach the SS.  Apparently the only way 
>> left is to do it at BS, send the 33:33-addressed packets only to 
>> those SS's that are interested.  What do you think?
> 
> I think you cannot define any classification rule in 'reconstitution'
>  part of SS, since the 'reconstitution' part is defined in 802.16.

David, is it possible for IPv6 stack to add classification rule to the
'reconstitution' part of a SS, ie classifiers in SS that apply to
packets SS receives from BS, not 'uplink' classifiers that apply to
packets SS sends to BS.

> Why don't you do that on top of 802.16?

I was thinking we may save code.

But then _where_ exactly on top of 802.16?  Can I say add 'filtering
rule' in the ETHCS layer of SS?  Or can I say add 'filtering rule' in
the Bridging function of the ETHCS layer of SS?  But please, no
link-local multicast filtering rule in the IPv6 stack.

>  prevent unwanted/not-joined 33:33-addressed messages to reach the 

I think it makes sense.  I think DSA-REQ/RSP can be used by SS to set up
a multicast CID, based on my rough reading of the IEEE-2004 document.  I
think it will open a connection on which the RA will be sent, for example.

I think we need to identify what triggers the sending of the DSA-REQ.
I've suggested above.

I think if we have agreement on that maybe we can write 4 short
paragraphs and then re-ask in the Working Group and the IEEE experts.

Alex

---

From: "Jihoon Lee" <[email-masked]>
Date: Sat, 20 Jan 2007 04:18:49 +0900

Hi Alex,

Comments inline.

Best regards,
Brandon

> to 16bit.  Or do you think 802.16MAC converts the 33:33::1 to a

Here I assumed the former, converting IPv6 link-local multicast addresses to
multicast CIDs.

> I think this should work.

Yes, it works. But, BS-trigger is still possible.
(1) IPv6 stack generates a MLD REPORT and puts it to ETHCS Driver. ETHCS
Driver pass  it to 802.16 MAC, and it can be transmitted using uplink
transport connection (unicast to BS).
(2) MLD REPORT will be delivered from BS's 802.16 MAC to ETHCS. ETHCS can
trigger BS-initiated DSA if the snooping has equipped.

I cannot say which one is better. In the 802.16 point of view, BS-initiated
DSA procedure is desirable, because we can assume that it has been
authorized. In addition, naturally it protect from any malicious request.
On the other hand, I agree that MS-initiated DSA is natural since MS
initiates MLD-REPORT.

Let me think.

> BTW, basically 802.16 doesn't know any upper layer messages such as

just standard 802.16 without any snooping.

> gets drafted then maybe MBS and WiMax will be interested to know what

MBS is multicast and broadcast service, which defined in 802.16. However,
it's described so general in 802.16. The word, "refer", which I used,
is inappropriate. The point was there'll be similar discussion to what we're
doing.

> link-local multicast filtering rule in the IPv6 stack.

I meant ETHCS. BTW, the bridging function also exists in SS ?

---

From: "David Johnston" <[email-masked]>
Date: Sun, 21 Jan 2007 09:38:21 -0800

Replies inline...

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jihoon Lee
Sent: Friday, January 19, 2007 11:19 AM
To: Alexandru Petrescu
Cc: [email-masked]; David Johnston
Subject: Re: stepped multicast operation and two questions to David
Johnston

Hi Alex,

Comments inline.

Best regards,

Brandon

Jihoon Lee wrote:
>> think about this?  Is this violating anything in 802.16 . What
>> method would you prefer?
>

No. In the case of an IP Packet CS, the IPv6 stack can send a packet to
33:33:0:0:0:1 down into the IP Packet CS of 802.16 and expect the packet
to be correctly dealt with. What happens next is up to the CS. It
*might* cause the CS to perform an MCS-REQ in an implementation, but I
doubt it.

The IP Packet CS has the responsibility to set up connections that it
can use to deal with the packets it needs to send and receive to
correctly provide the CS MAC service. There are no hard and fast rules
about what those connections are. The CS may set up multiple connections
with different QoS parameter and perform classification to assign
packets to connections.

If the IP Packet CS thinks it can use a multicast group to better
implement the MAC service, then it can set one up. However the MAC CPS
multicast service is downlink only, so some thought on the part of the
implementer would be required to know to make this work right. I don't
personally think this has been addressed in any literature I have read
and I don't myself see how it can work well. The correct use of unicast
connections is much more obvious.

In the case of the Ethernet Packet CS, ARP happens as per Ethernet and
the Ethernet Packet CS, similarly to the IP Packet CS, could use
multicast group to implement the correct delivery of 802 addressed
packets (that may be uni, broad or multicast). But again it sounds like
more trouble than it is worth to get right.

DJ - This is the normal CS classification scheme. I.E. assigning
outgoing traffic to CID based on packet contents. But can this work
asymmetrically? The uplink has no multicast CIDs because of the
limitations of the laws of physics. Hence my preference for the Ethernet
CS and GPCS(when it comes).

Here I assumed the former, converting IPv6 link-local multicast
addresses to multicast CIDs.

	I understand.  So the SS uses DSA messages to indicate interest
in a
	multicast-CID reception, and the BS keeps track of interests.
It makes 
	sense to me.  The packets addressed to a multicast group will
arrive to
	SS on that multicast CID.
	
	But I think we still need to say that it is the SS who triggers
that DSA
	exchange, ie SS's IPv6 stack.  Do you agree? 

	It can happen in of the following alternative 2 ways: (1) IPv6
stack
	generates a MLD REPORT and puts it to ETHCS Driver.  ETHCS
Driver 
	interprets it, drops it, and sends the corresponding DSA-REQ;
(2) IPv6
	stack calls a function in ETHCS Driver giving it parameter
33:33::1 and
	ETHCS Driver generates the DSA-REQ.

(2) MLD REPORT will be delivered from BS's 802.16 MAC to ETHCS. ETHCS
can trigger BS-initiated DSA if the snooping has equipped. 

I cannot say which one is better. In the 802.16 point of view,
BS-initiated DSA procedure is desirable, because we can assume that it
has been authorized. In addition, naturally it protect from any
malicious request. 

Let me think.

	
	Unless it 'snoops' them?

	> connection setup, and which is better, BS-initiated or
MS-initiated. 
	
	Most IPv6 stacks currently call some function to join a certain
group.
	Some generate MLD REPORTS, some others just call a driver's
function.
	This can be matched into DSA-REQ/RSP.
	
	All IPv6 router stacks must join all-routers group, so the BS
(_if_ it 
	sends RAs) should join.  This matches the model of BS sending
MCA-REQ
	and SS sending MCA-RSP.

	
	I think we have freedom to propose something that makes sense
for
	multicast IPv6 over ETHCS, here.  If there's agreement in the
group and
	gets drafted then maybe MBS and WiMax will be interested to know
what 
	the draft says.

MBS is multicast and broadcast service, which defined in 802.16.
However, it's described so general in 802.16. The word, "refer", which I
used, is inappropriate. The point was there'll be similar discussion to
what we're doing. 

	>  part of SS, since the 'reconstitution' part is defined in
802.16.
	
	David, is it possible for IPv6 stack to add classification rule
to the
	'reconstitution' part of a SS, ie classifiers in SS that apply
to 
	packets SS receives from BS, not 'uplink' classifiers that apply
to
	packets SS sends to BS.

	I assume you mean for PHS? Reconstitution of PHS compressed
packets does not need to refer to the classification rules. It just
needs to uncompress what was compressed and this is a handle-turning
algorithm.

	An SS can know the classification rules applied to a DL
connection by remembering them from the connection setup. But why? What
can it do beyond sending the packets up to the IP stack/bridge? Traffic
filtering can happen but I don't think it is the job of 802.16 to define
that. It's more of an implementation thing.

	
	But then _where_ exactly on top of 802.16?  Can I say add
'filtering
	rule' in the ETHCS layer of SS?  Or can I say add 'filtering
rule' in
	the Bridging function of the ETHCS layer of SS?  But please, no
	link-local multicast filtering rule in the IPv6 stack. 

	Bridging might exist. In the 802 world, you shouldn't need to
know and things will work right. 802.1AB exists if you feel the need to
probe.

	>  prevent unwanted/not-joined 33:33-addressed messages to reach
the 
	> SS.
	
	I think it makes sense.  I think DSA-REQ/RSP can be used by SS
to set up
	a multicast CID, based on my rough reading of the IEEE-2004
document.  I
	think it will open a connection on which the RA will be sent,
for example. 
	
	I think we need to identify what triggers the sending of the
DSA-REQ.
	I've suggested above.

	I think if we have agreement on that maybe we can write 4 short
	paragraphs and then re-ask in the Working Group and the IEEE
experts. 

	Yes. Feel free. I can do my liaisonly duty and pass them on.

	Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jan 2007 20:05:23 +0100

David, thanks the mail.

Let me reply quickly to some of the text.  I've planned more detailed
answer, but I'm figuring to let the first things first and then I'll see.

David Johnston wrote:
>>>> unsolicited but as a response. In this case, we can specify 
>>>> that BS before sending a RA it sends a MCA-REQ to poll who are
>>>>  the SS's interested in receiving that RA, and thus SS can send
>>>>  the MCA-RSP as it is designed. Remark that the router (entity
>>>>  who sends the RA - BS or AR) MUST join the all-routers address
>>>>  (rfc2461), with a MLD or with a local filter (popular 
>>>> interpretation).  So subsequent to sending that MLD REPORT, or
>>>>  setting up filtering rule, it can send the MCA-REQ.  So we can
>>>>  trigger the sending of MCA-REQ either by sending the RA, or by
>>>>  MLD JOIN for all-routers, etc. What do you think about this?
>>>> Is this violating anything in 802.16 . What method would you 
>>>> prefer?
>>> 
>> David, do you think an IPv6 stack on the BS can ask the 802.16MAC 
>> to send a MCA-REQ to SS to ask it whether it's interested in 
>> receiving packets addressed to 33:33:0:0:0:1?
> 
> No. In the case of an IP Packet CS, the IPv6 stack can send a packet
>  to 33:33:0:0:0:1 down into the IP Packet CS of 802.16 and expect the
>  packet to be correctly dealt with. What happens next is up to the
> CS. It **might** cause the CS to perform an MCS-REQ in an
> implementation, but I doubt it.

I think then it would make sense form draft to recommend BS to send that
MCa-REQ before sending the RA.  In this way BS learns who are the SSs
interested to receive the RA.  If it doesn't break anything.  That's
what I'm trying to  figure out, whether use of MCA-REQ at BS prior to
send RA breaks anything.

> correctly provide the CS MAC service. There are no hard and fast 
> rules about what those connections are. The CS may set up multiple 
> connections with different QoS parameter and perform classification 
> to assign packets to connections.

Yes, setting up connections would be done with DSA messages, but I think
MCS-REQ/RSP is only to find out who's listening, polling.

> implement the MAC service, then it can set one up.

This would be great.  If the BS can deliver RAs only to SSs that are
interested in receiving it it would be absolutely great.

> However the MAC CPS multicast service is downlink only, so some 
> thought on the part of the implementer would be required to know to 
> make this work right.

I think that if we can figure out a unitary downlink behaviour then we
can see the uplink behaviour.

You see, I wouldn't care if a IP-multicasted packet from SS1 to SS2
(group made of only IP SS1 and IP SS2) goes through a MAC-layer downlink
multicast group at BS, even if it reaches BS.  The essential is that the
IP-multicasted packet from SS1 to SS2 doesn't go to SSn which hasn't
declared interest in that IP multicast group.

> I don’t personally think this has been addressed in any literature I
>  have read and I don’t myself see how it can work well. The correct 
> use of unicast connections is much more obvious.
> 
> In the case of the Ethernet Packet CS, ARP happens as per Ethernet 
> and the Ethernet Packet CS, similarly to the IP Packet CS, could use
> packets (that may be uni, broad or multicast). But again it sounds 
> like more trouble than it is worth to get right.

There's a difference between ARP and ND in that ND requires the use of
link-layer multicast while ARP less so.

I'm not sure whether some _operation_ should be specified, or only some
_goals_ should be specified and leave much on Ethernet MAC designers.

>>>> As I understand it DSA-REQ/RSP/ACK are for allocating service 
>>>> flows with a certain QoS, bandwidth request, (table 113 
>>>> ieee-2004). This DSA-REQ is for a multicast CID, ok.  I 
>>>> understand DSA-REQ/RSP/ACK are not specifically designed to 
>>>> indicate intention of belonging to a mc group - which is what 
>>>> I'm looking for, the equivalent of MLD REPORT. What do you 
>>>> think? Should I look elsewhere in the spec?
>>> 
>>> connection between itself and MSs, DSA transaction is required
>>> for each MS. Therefore, BS can manage its multicast group which
>>> is associated with 802.16 multicast CID. In other words, MS may
>>> join by initiating DSA with appropriate multicast CID. Because,
>>> in theory, DSA can be initiated by either BS or MS. Consequently,
>> link-local multicast addresses to multicast CIDs, right?  Like 
>> ff02::1 to 16bit.  Or do you think 802.16MAC converts the 33:33::1 
>> to a multicast CID?]
>> 
> 
> DJ – This is the normal CS classification scheme. I.E. assigning 
> limitations of the laws of physics. Hence my preference for the 
> Ethernet CS and GPCS(when it comes).

I like what nature imposes and especially how to design around it.

It may be that a set of uplink unicast connections can be managed as
downlink multicast... and force BS to see all groups packets, and that
would be still fine provided that not all SSs see traffic they're not
interested in.

Alex