| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
"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." According to the accathed contribution (which will be broken into pieces per Kona for approval next March) MIH will attempt to always transport over R1 when R1 is available. So NET-SAP will always be used by MIH. In case R1 is not avaiable, NET_SAP will use common L3 approach mechansim as indicated. Also regarding your SAP question, please reveiw the attached. Peretz Feder
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.
21-06-0492-03-0000-GenRefModel.doc