[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
>>>>>
>>>>>
>>>
>>>