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