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