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, Peretz,

Yes, part of the MIH messaging layer which is defined in 802.21 to run
over Ethernet and in IETF to run over IP.  This is already defined.

-Pete

Feder, Peretz (Peretz) wrote:
> Pete:
> 
> This line confused me:
> 
> "would operate underneath the MIHF layer to improve the reliability of
> the MIH messages"
> 
> Did you mean "underneath the MIHF layer" to actually be part of the
> MIH protocol itself?
> 
> Peretz Feder
> 
> -----Original Message-----
> From: Peter McCann [mailto:Peter.McCann@xxxxxxxxxx]
> Sent: Thursday, July 05, 2012 10:27 AM
> To: STDS-802-21@xxxxxxxxxxxxxxxxx
> Subject: 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
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>>