AW: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives
Hi Srini,
thank you for pointing out your inline comments, I
didn't had a look at it in your previous email :-)
>Yes, I agree to it. But who will initiate this, that is, the
>"decision" to perfrom discovery? MIH itself or MIH user?
>
Srini> minor correction here. We agreed the MIH discovery for L3 is done
Srini> by the xport itself while for L2 it is the MIHF. My contention is
Srini> that it cannot be mIH user since it would be counter-intuitive
Srini> for each MIH user to create their own MIH peers. Both the
Srini> decision and the origination is at MIH.
It seem to me palusible that MIH user will not initiate this.
What is this "xport"? Is it a new entity within a peer?
>Do you mean here the information embedded in remote
>communication between MIHF peers?
Srini> I meant the MIH header information, we provide all the payload
Srini> information that is supported by the primitive.
OK.
>Same as point 1, will upper or lower layer need to know
>whether the info is local or remote? Or the decision will be
>taken place at MIHF?
Srini> this is the tricky part and I have to correct my statement with
Srini> "MAY". Knowing that MIH event registrations terminate at MIH
Srini> layer and there are no remote link events. Clearly when a link
Srini> event is generated you cannot tell that it is remote in scope.
Srini> Only the MIH knows who has registered for it and where the peer
Srini> is. For commands, OTH, there are no registrations so the MIH user
Srini> MAY tell if it is local or remote and the implementation at MIH
Srini> could validate it and act accordingly.
I'll come to this point later after going through the new draft.
I understood, that some changes are made w.r.t. local & remote stuff.
>By the way one IMPORTANT question to be clarified with this
>aspect, who will decide over which interface or using which
>protocol local MIHF has to communicate with peer MIHF? Is it
>the local MIHF or the MIHF user? This point clarifies most of
>the doubts coming up.
Srini> my proposal is keep MIH-users/l2 out of it. MIHF knows all the
Srini> available transports and will choose.
I would further say:
MIHF knows all the available transports and will choose according to user prefs.
Regards,
Kalyan
-----Ursprüngliche Nachricht-----
Von: Srinivas.Sreemanthula@nokia.com [mailto:Srinivas.Sreemanthula@nokia.com]
Gesendet: Dienstag, 24. Januar 2006 22:03
An: Kalyan Koora; STDS-802-21@LISTSERV.IEEE.ORG
Betreff: RE: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives
HI Kalyan,
I completely agree with the inconsistencies in the sections you pointed out. This must be fixed by the end of internal ballot process. The current dialogue to arrive at some common solution.
Regards,
Srini
>-----Original Message-----
>From: ext Kalyan Koora [mailto:kalyan.koora@BENQ.COM]
>Sent: Tuesday, January 24, 2006 2:48 AM
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: [802.21] AW: [802.21] Telecon on source/destination
>Ids within different primitives
>
>Hi Srini,
>
>it is nice to see that we agree on the things quickly. I also
>wanted to raise some questions, which you already put into
>your email :-)
>
>Here my comments:
>
>>The issue must be narrowed down to either i) MIH packet or
>ii) SAP definitions.
>
>I too agree with this and fell that we have already clarified
>src/dst info in MIH variable header part. So the consideration
>is only regarding SAP definition.
>
>Within the present draft 4, in section 6.2.2 we have a command
>primitive definition which has only one ID other than info
>set. In the section 6.2.6.1 we have set of commands defined in
>table 4, eg. MIH Poll. Further, in section 7.4.6.1.2 we have a
>description of the MIH poll request primitive, where we have
>src and dst ID.
>Thus, I am not able to correlate the general primitive with
>the specific primitive description.
>
>>1. MIH discovery mechanisms are performed by the MIH function
>layer and hence
>> part of MIH layer.
>
>Yes, I agree to it. But who will initiate this, that is, the
>"decision" to perfrom discovery? MIH itself or MIH user?
>
Srini> minor correction here. We agreed the MIH discovery for L3 is done
Srini> by the xport itself while for L2 it is the MIHF. My contention is
Srini> that it cannot be mIH user since it would be counter-intuitive
Srini> for each MIH user to create their own MIH peers. Both the
Srini> decision and the origination is at MIH.
>>2. MIH peer information is not made available(as per current
>mechanisms) to the
>> upper or lower layers of MIH.
>
>Do you mean here the information embedded in remote
>communication between MIHF peers?
Srini> I meant the MIH header information, we provide all the payload
Srini> information that is supported by the primitive.
>
>>5. In this regard, the upper and lower layers only need to
>mention local or
>> remote scope in the SAP definition and the MIH will make
>routing decisions
>> about the destination for remote communication.
>
>Same as point 1, will upper or lower layer need to know
>whether the info is local or remote? Or the decision will be
>taken place at MIHF?
Srini> this is the tricky part and I have to correct my statement with
Srini> "MAY". Knowing that MIH event registrations terminate at MIH
Srini> layer and there are no remote link events. Clearly when a link
Srini> event is generated you cannot tell that it is remote in scope.
Srini> Only the MIH knows who has registered for it and where the peer
Srini> is. For commands, OTH, there are no registrations so the MIH user
Srini> MAY tell if it is local or remote and the implementation at MIH
Srini> could validate it and act accordingly.
>>6. I take the same position with regards to the transport
>option (l2 or
>>l3) as well. The decision is upto MIH (this change was
>approved in Kona meeting).
>
>Sorry, I didn't get your point here. Could you please elaborate this?
Srini> In v4 there was a transport parameter in the primitives starting from 7.4.10. I requested to remove it in the F2F meeting.
>
>By the way one IMPORTANT question to be clarified with this
>aspect, who will decide over which interface or using which
>protocol local MIHF has to communicate with peer MIHF? Is it
>the local MIHF or the MIHF user? This point clarifies most of
>the doubts coming up.
Srini> my proposal is keep MIH-users/l2 out of it. MIHF knows all the available transports and will choose.
>
>Regards,
>Kalyan
>
>-----Ursprüngliche Nachricht-----
>Von: Srinivas Sreemanthula [mailto:Srinivas.Sreemanthula@NOKIA.COM]
>Gesendet: Dienstag, 24. Januar 2006 00:18
>An: STDS-802-21@listserv.ieee.org
>Betreff: Re: [802.21] Telecon on source/destination Ids within
>different primitives
>
>
>Hi Wolfgang,
>Sorry I would not be able to make it for the conference next
>week. But, please consider my opinions below as part of your
>discussion. The issue must be narrowed down to either i) MIH
>packet or ii) SAP definitions. My opinions are related to SAP
>defitions, for MIH packet we already have those fields defined.
>
>1. MIH discovery mechanisms are performed by the MIH function
>layer and hence part of MIH layer.
>2. MIH peer information is not made available(as per current
>mechanisms) to the upper or lower layers of MIH.
>3. MIH registration (in the future) will also be part of MIH
>function which provided MIH pairing information (not provided
>to other layers)
>4. The most suitable layer/part of the stack having the
>knowledge of the MIH peer is the MIH layer itself.
>5. In this regard, the upper and lower layers only need to
>mention local or remote scope in the SAP definition and the
>MIH will make routing decisions about the destination for
>remote communication.
>6. I take the same position with regards to the transport
>option (l2 or l3) as well. The decision is upto MIH (this
>change was approved in Kona meeting).
>
>Regards,
>Srini
>
>
>>-----Original Message-----
>>From: ext Wolfgang Gröting [mailto:wolfgang.groeting@BENQ.COM]
>>Sent: Wednesday, January 18, 2006 6:39 PM
>>To: STDS-802-21@listserv.ieee.org
>>Subject: [802.21] Telecon on source/destination Ids within
>>different primitives
>>
>>Dear all,
>>
>> as agreed within the meeting, I suggest to have a telecon on
>>the above mentioned issue next week. I will provide telecon
>>details later on.
>>
>>Aim is to clarify the value of having source / destination Ids
>>within particular commands and events.
>>
>>Cheers,
>>Wolfgang.
>>
>