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 Peter,
I agree with you that there should be a generic mechanism to carry L2
frames, that was the original idea of the LL_Transfer. The reason for
adding the extra parameters was to help with the authentication. Do
you think the use of this primitives, defining as optional the
security parameters will be enough?

I have no answer yet to the response primitives, I am not sure if they
are needed or not in current spec.

BR
Antonio

On Tue, Jul 3, 2012 at 8:13 PM, Peter McCann <Peter.McCann@xxxxxxxxxx> 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
>>
>>



-- 
Antonio de la Oliva
Visiting Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax:   +34 91 624 8749