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