RE: [802.21] An issue regarding primitives!
> -----Original Message-----
> From: Kalyan Koora [mailto:kalyan.koora@benq.com]
> Sent: Wednesday, December 14, 2005 4:07 AM
> To: Gupta, Vivek G; STDS-802-21@listserv.ieee.org
> Subject: 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?
[Vivek G Gupta]
Currently we have defined Remote link events as well in the draft (though it would be better to have all link events as local only and the corresponding MIH events as remote, to avoid having two sets of similar remote events).
MIH entities can register with peer MIH entities to receive remote link/MIH events. The link layer by itself has no knowledge about a link event being remote. From link layer perspective the event destination is always the local MIH Function. The local MIH Function determines whether to consume the event locally or package it and transport it to peer MIH Function entities as well, depending on specific event registration requests received from peer MIH-F entities.
>
> >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?
[Vivek G Gupta]
MIH entities register with their peer MIH counterparts indicating the events they are interested in receiving notifications for. MIH Event Register/ MIH Event Deregister should take care of this. We need to expand on these primitives in current draft (version 4). On receiving this registration request a MIH-F entity may issue local Link Register Event request to receive appropriate link events.
>
> In draft 3, section 6.1.5, it is mentioned:
[Vivek G Gupta]
Please use draft version D00.04.
>
> "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.
[Vivek G Gupta]
As part of this registration MIHF-C should get the ID and any other relevant details of MIHF-A and MIHF-B. We should explain this better in MIH Event Register/Deregister.
>
> 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?
[Vivek G Gupta]
See above.
>
> 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.
[Vivek G Gupta]
If MIHF-A is USER-A, then MIHF-C still sends the indication to peer MIHF entity which then sends an indication up the local stack to USER-A. MIH-F entities send remote messages only to peer MIH-F entities. The local MIH-F entity has to manage dispatching of messages to registered clients locally.
>
> 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.
[Vivek G Gupta]
Yes. That appears correct. We need to update only the general set of primitives. However the discrepancy is only in section 6 and section 7 which has all the primitives seems ok.
>
>
> 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
> >