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, Juan Carlos,

Yes, I agree with your statement below.

-Pete

Zuniga, Juan Carlos wrote:
> Hi Pete,
> 
> I also got confused by the "link-layer" and the "cross-domain"
> terminology. I think the intention is basically to provide some sort
> of transparent container to carry LL information over MIH frames.
> Then, MIH frames can be transported over L2 technologies or over IP as
> per RFC 5677. Do you agree?
> 
> JC
> 
> -----Original Message-----
> From: Peter McCann [mailto:Peter.McCann@xxxxxxxxxx]
> Sent: Thursday, July 05, 2012 10:48 AM
> To: STDS-802-21@xxxxxxxxxxxxxxxxx
> Subject: 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
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>>