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