RE: 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
>