Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal



Hi, Charles,

What do you think about eliminating the .response and .confirm primitives
from the link layer transfer?

I read 802.21a which contains Auth Request/Response messages and I guess
Yoshi is saying that was the inspiration for making separate link layer
frame request/responses.  However, I don't see why we have to do this.

There may be reasons other than authentication to send a link-layer frame
to a remote PoA.  The setup of the link may involve several messages
prior to or after authentication.  It would seem appropriate to have a
generic way to carry these messages.

-Pete

Charles E. Perkins wrote:
> 
> Hello Pete,
> 
> I am in agreement with Yoshi on all of these points.  They should be
> reflected in the next revision of the proposal.
> 
> Would you be willing to review the diagrams and make suggestions about
> how they might be clearer?  It seems to me that the differences
> between the various scenarios could be highlighted somehow, or
> irrelevant detail omitted, so that the main points are easier to grasp.
> 
> Regards,
> Charlie P.
> 
> 
> On 7/2/2012 4:39 PM, Yoshihiro Ohba wrote:
> 
> 
> 	Hi Pete,
> 
> 	Thank you very much for reviewing the document.
> 
> 	Please see my comments below.
> 
> 	(2012/07/03 4:55), Peter McCann wrote:
> 
> 		Hi,
> 
> 		I had promised to send some review comments on this document.
> 
> 
> 		In Section 3, the acronym "MN" is expanded to mean "Mobile Network."
> I think
> 		you meant, "Mobile Node?"
> 
> 	I think it should be "Mobile Node".
> 
> 
> 		After reviewing the base 802.21 specification, I think the use of
> the primitives
> 		is mostly correct; however, some of the description in the text is a
> bit wrong.
> 
> 		For example, you say in Section 7.4.29.1.1 that the function of the
> 		MIH_LL_Transfer.request primitive is to carry link-layer frames
> between the 		MN and the serving PoS.  This is incorrect.  It only
> carries the link-layer 		frames between the MIH user and the MIHF.  It
> is the corresponding message 		in Section 8.6.3.24 that actually carries
> the frames to the new PoS via the 		existing network.  This message is
> generated by the MIHF after receiving 		an invocation of the
> MIH_LL_Transfer.request primitive from the MIH user.
> 
> 
> 	You are right.  I think Section 7.4.29.1.1 has to be revised as you
> 	pointed out.
> 
> 
> 		In Section 7.4.29.1.3: you say that the primitive is generated by an
> MIH user
> 		to start an authentication and association process based on
> link-layer frames.
> 		Do you really need to be so specific?  This is a general- purpose
> primitive for
> 		sending link-layer frames for any purpose whatsoever, isn't it?
> 
> 	AFAIK, the discussed use of the primitive is pre-registration, and
> 	sending link-layer frames for any purpose using this primitive has not
> 	been discussed.  If we expand the usage to allow sending any LL frame
> 	then the text should be revised.  But we need to agree on expanding
> 	the usage first.
> 
> 
> 		Section 7.4.29.1.4: you say the MIH_LL_Transfer.indication is used
> by a remote
> 		MIHF.  I don't think you need to specify that it is a "remote" MIHF.
> You just
> 		need to say that it is used by an MIHF to notify the local MIH user
> about the
> 		receipt of an MIH_LL_Transfer request message.
> 
> 	I agree.  The text needs to be revised as you suggested.
> 
> 
> 		I do not think you need to specify the corresponding .response and
> .confirm 		messages.  The transfer of a link-layer frame is a one-way,
> unreliable operation 		that does not always generate a response. 
> Specifying a .response just seems 		redundant; the MIH user that
> receives an .indication can always generate a 		brand new .request
> primitive to transfer a link layer frame in the other 		direction.
> 
> 	The reason for having .response and .confirm primitives in
> 	MIH_LL_Transfer is basically inherited from 802.21a MIH_LL_Auth.
> 
> 	I would say the design depends on whether the use of MIH_LL_Transfer
> 	is for pre-registration only or for carrying any link-layer frame.
> 
> 
> 		Similarly, I think you can do away with the
> MIH_N2N_LL_Transfer.response and
> 		.confirm primitives.
> 
> 	Again the design depends on whether the use of MIH_LL_Transfer
> 	is for pre-registration only or for carrying any link-layer frame.
> 
> 	Best Regards,
> 	Yoshihiro Ohba
> 
>