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