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



No, I don't think we are discussing link layer changes.  The existing
draft text is about conveying link layer frames of another technology
via the MIH interface.  I am just trying to simplify that interface.

-Pete

Feder, Peretz (Peretz) wrote:
> 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
>>>>>> 
>>>>>> 
>>>> 
>>>>