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

["David Johnston" <[e-mail]>]

Replies inline...

 

________________________________

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

 

Hi Alex,

 

Comments inline.

 

Best regards,

Brandon

 

2007/1/20, Alexandru Petrescu <[e-mail]>om>: 

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.

 

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.


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

 

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.
	
	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
	> IGMP/MLD-REPORT.
	
	Unless it 'snoops' them?

just standard 802.16 without any snooping.

	 

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

 

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. 

	 

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

	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.

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

 

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

	 

	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.

	 

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

 

 


 

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