[16NG] Re: stepped multicast operation and two questions to David Johnston

[Alexandru Petrescu <[e-mail]>]

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

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

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.

> If the IP Packet CS thinks it can use a multicast group to better 
> 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
>  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.

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

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


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