[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[16NG] Re: stepped multicast operation and two questions to David Johnston
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
16NG at ietf.org
https://www1.ietf.org/mailman/listinfo/16ng