RE: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal
Hi, Juan Carlos,
Yes, I agree with your statement below.
-Pete
Zuniga, Juan Carlos wrote:
> Hi Pete,
>
> I also got confused by the "link-layer" and the "cross-domain"
> terminology. I think the intention is basically to provide some sort
> of transparent container to carry LL information over MIH frames.
> Then, MIH frames can be transported over L2 technologies or over IP as
> per RFC 5677. Do you agree?
>
> JC
>
> -----Original Message-----
> From: Peter McCann [mailto:Peter.McCann@xxxxxxxxxx]
> Sent: Thursday, July 05, 2012 10:48 AM
> To: STDS-802-21@xxxxxxxxxxxxxxxxx
> Subject: 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>