RE: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal
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
>>>>>>
>>>>>>
>>>>
>>>>