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,

Yes, I think we only need a single message type and two primitives,
one for sending and one for receiving.  Link-layer frames are one-way
unreliable datagrams.

-Pete

Charles E. Perkins wrote:
> 
> Hello Pete,
> 
> In general, I am O.K. with removing .confirm, but I reckon the
> .response message would often be useful.
> 
> Your point about generalizing the link-layer frame message to enable
> signaling unrelated to authentication is also valid I think.  However,
> unless there is a particular case within the jurisdiction of 802.21
> for doing so, I'm not sure if there is any process that we could
> charter for that purpose.
> 
> If you mean to say that we only need a single message for any generic
> cross-domain link-layer communication, I'm intrigued but haven't spent
> enough time thinking about it to decide.  Do you think we should have
> a discussion about it?
> 
> Regards,
> Charlie P.
> 
> On 7/3/2012 11:13 AM, Peter McCann wrote:
>> 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
>>> 
>>> 
> 
>