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
>