Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives



Title: Nachricht

“MIH will attempt to always transport over R1 when R1 is available”  instead of over R3:

..which basically means, L2 will always be preferred over L3:

Is this always true?

Do we really need to make such assertions in 802.21 Specification?

I would prefer to keep such statements out of the normative part of the specification.

 

I am also not sure what do we gain by introduction of MIH_NET_SAP.

Apart from that most of what this contribution specifies is already there in the new draft.

 

Best Regards

-Vivek

 

 


From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of Kalyan Koora
Sent: Friday, January 27, 2006 4:30 AM
To: Peretz Feder; STDS-802-21@listserv.ieee.org
Subject: AW: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives

 

Hi Peretz,

 

just one quick comment to your doc. You mention that MIH_SME_SAP is media-independent

and always maintain the same names and primitives. But in the table, why do you put different

names for it? I mean, why can't it be same as MIH_SAP?

 

Regards,

Kalyan

-----Ursprüngliche Nachricht-----
Von: Peretz Feder [mailto:pfeder@LUCENT.COM]
Gesendet: Freitag, 27. Januar 2006 06:18
An: STDS-802-21@listserv.ieee.org
Betreff: Re: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives

Kalyan:


"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



On 1/24/2006 3:48 AM, Kalyan Koora wrote:

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.