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

RE: An issue regarding primitives!

> -----Original Message-----
> From: [] On Behalf Of
> Kalyan Koora
> Sent: Wednesday, December 14, 2005 2:15 AM
> To:
> 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

> Couple of advantages in having both the IDs
> -------------------------------------------
>  * Having both the IDs (source & destination) in a primitive will
>    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
>    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