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

AW: [802.21] An issue regarding primitives!



Hi Vivek,

>The link events originate from the link layer and are 
>intended for MIH and do not have a destination identifier 
>associated with them. 

That means for me, there are no "Remote" Link events. Did
I understood it correctly?

>The local MIH Function can determine 
>if these events need to be sent to remote/peer MIH entities 
>or not depending on remote/peer MIH registration for these 
>events etc.

Here is the place where I am not understanding, how can
an MIHF dertermine this? on what basis?

In draft 3, section 6.1.5, it is mentioned:

"EventSource: is used to identify the event source entity where 
 the event originated"

 I understand with this, that if a registration has to be made
 by MIHF, then the destination to which the registration req. has
 to be sent by MIHF is "EventSource".

 Now let us assume that MIHF-A and MIHF-B sends a remote registraion
 to MIHF-C. In both cases MIHF-A and MIHF-B uses the same EventSource.
 
 If the event occures at MIHF-C, it has to send an indication
 to MIHF-A and MIHF-B. Where does MIHF-C gets the ID of A and B?

In the above example, I can replace MIHF-A with USER-A and MIHF-B
with USER-B. MIHF-C is the MIHF in a peer.

Sorry for bothering you, but I feel I miss somthing here
in understanding.

> But all MIH_SAP primitives (commands) have a Destination 
> Identifier associated with them. Please refer to section 
> 7 for details on different MIH command related primitives.

Yes, I agree with this and that is what I was pointing out
with "discrepancy with the general primitive syntax for command".
In this case we may have to extend the general syntax
in section 6.2, draft 3 with CommandDestination parameter.


regards,
Kalyan

-----Ursprüngliche Nachricht-----
Von: Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM] 
Gesendet: Mittwoch, 14. Dezember 2005 11:55
An: STDS-802-21@listserv.ieee.org
Betreff: Re: [802.21] An issue regarding primitives!


> -----Original Message-----
> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of 
> Kalyan Koora
> Sent: Wednesday, December 14, 2005 2:15 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: An issue regarding primitives!
> 
> Hello All,
> 
> while going through the draft, couple of questions raised
> in my mind which I would like to discuss with you all.
> 
> General Primitive Syntax
> ------------------------
>  The general syntax of the primitives described in draft for ES and CS  
> contain a source ID and an Information/Result set.
> 
>  => What I miss here is destination ID (there are couple of advantages
>     with this, will explain in next point).
[Vivek G Gupta] 
The current draft already seems to account for this.
The link events originate from the link layer and are intended for MIH and do not have a destination identifier associated with them. The local MIH Function can determine if these events need to be sent to remote/peer MIH entities or not depending on remote/peer MIH registration for these events etc. But all MIH_SAP primitives (commands) have a Destination Identifier associated with them. Please refer to section 7 for details on different MIH command related primitives.

> 
>  If you check the MIH-Poll, which is listed as MIH Command, then the  
> primitive described for it is having a source and destination ID.  
> This is in discrepancy with the general primitive syntax for command  
> service.
> 
[Vivek G Gupta] 
Which MIH commands do not have Destination Identifier listed in section 7?

> Couple of advantages in having both the IDs
> -------------------------------------------
>  * Having both the IDs (source & destination) in a primitive will
reduce
>    the overhead of defining a same event/command once as local and
>    once as remote. I think, this is also pointed by couple of us.
> 
>  * That is, all the events going from L2 to MIH and from MIH to HL are
>    treated as local events. And at the same time, all the commands
going
>    from HL to MIH and MIH to L2 are treated as local commands.
> 
>  * MIHF decides on receiving the events/commands from other layers,
>    depending on the destination ID, to treat them either as local
>    or remote events/commands. It then forwards them to local receiver
>    or to remote MIHF with the help of external transport protocol.
> 
>    NOTE: The remote events/commands are exchanged ONLY between the
>          MIHF peers and not between the other layers.
> 
> I would like to know your opinions.
> 
> with best regards,
> Kalyan
>