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

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



Folks:

Maybe I am jumping in the middle here, but are we discussing link layer changes?

I hope not since Link layer (which one actually? - as we are LL agnostic) is not in our control.

Peretz Feder 

-----Original Message-----
From: Peter McCann [mailto:Peter.McCann@xxxxxxxxxx] 
Sent: Tuesday, July 03, 2012 4:09 PM
To: STDS-802-21@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal

Hi, Juan Carlos,

These retransmission mechanisms, if used, would operate underneath
the MIHF layer to improve the reliability of the MIH messages.  I
don't think their presence or absence implies anything about the
need for a separate "link layer transfer response" message.  If 
anything, their operation seems to remove the need for an
acknowledgement at the MIH layer.

The request/response model seems to be very specific to a particular
authentication framework.  If we make the link layer transfer generic
I think we only need one-way "send" and "receive" primitives.  You can
always implement request/response on top of those primitives if the
upper layer semantics require it.

-Pete

Zuniga, Juan Carlos wrote:
> Hi Pete, Charlie,
> 
> Regarding retransmission and reliability of MIH messages, I remember
> we had lengthy discussions when we were working on the baseline 802.21
> spec. The conclusions were captured in what finally became the
> guidelines to transport MIH messages over IP (RFC 5677). Maybe this
> would be useful for your conversation:
> 
> http://tools.ietf.org/html/rfc5677
> 
> Regards,
> 
> Juan Carlos
> 
>> -----Original Message----- From: Peter McCann
>> [mailto:Peter.McCann@xxxxxxxxxx] Sent: Tuesday, July 03, 2012 2:54 PM
>> To: STDS-802-21@xxxxxxxxxxxxxxxxx Subject: 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
>>>>> 
>>>>> 
>>> 
>>>