AW: [802.21] Ad hoc telecon for Dec 13th
Hello Vivek & Cheng Hong,
at first it is good to see that we all have the
same thing in mind. Even I too say that the peer MIHF
need not to know about the user or what else.
What I say is to use a flexible ID in the MIH-Protocol.
For example, an MIHF is having an oMIHF = 0x12345
as its ID, I agree it is sufficient to use this to
communicate over MIH-Protocol with the peers.
I mean to say it is good to have some flexibility as
1) nMIHF = oMIHF = 0x1234 or
2) nMIHF = oMIHF + UID = 0x1234AB or
3) nMIHF = oMIHF + UID + Protocol = 0x1234AB56
(Don't ask me how I generated them, I have just typed
them in :-)
So, in our present draft we have an MIHF-ID length
field, by making use of this, we can say in 1st case
it is 2 bytes, in 2nd case it is 3 and in 3rd case it
is 4 bytes.
In the below example, the MIHF(b) will send back a response/
trigger/or any message back to MIHF(a), and the MIHF(a) can
dispatch to the correct user back depending on the user
ID, here 0xAB. In this case, MIHF(a) need not use any
mechanism to map the things inside.
>Any thoughts on what the MIHF Identifier should be?
That is what I am trying to point out.
I wish you and your families a happy new year 2006. And
I wish we all bring out a great standard in next year.
Regards,
Kalyan
-----Ursprüngliche Nachricht-----
Von: Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM]
Gesendet: Freitag, 23. Dezember 2005 11:01
An: STDS-802-21@listserv.ieee.org
Betreff: Re: [802.21] Ad hoc telecon for Dec 13th
I agree with Cheng Hong here. The peer MIHF entities only need to know about each other. MIHF within a MN/UE can be made responsible for dispatching MIHF related messages (even those received from remote MIHF entities) to different local MIH Users within a MN/UE.
Any thoughts on what the MIHF Identifier should be? (New unique identifier, L2/L3 address, etc...?) Should this be part of the MIH Function protocol (as shown in current draft) or is this likely to be specified as part of transport specific header as well and so is not required in MIHF header?
Best Regards
-Vivek
> -----Original Message-----
> From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
> Sent: Thursday, December 22, 2005 8:04 PM
> To: Kalyan Koora; Gupta, Vivek G; STDS-802-21@LISTSERV.IEEE.ORG
> Subject: RE: [802.21] Ad hoc telecon for Dec 13th
>
> Hi Kalyan and all,
>
> Merry Christmas, and happy Holidays!
>
> Kalyan, thanks a lot for the explanation. Now I am clear with the
> suggestion.
>
> However, I think we don't really need to have the MIH-User involved in
> the MIH-protocol. In my view the MIH-protocol is always between the
> two MIHF peers, and is not meant for the MIH-User's direct use.
> (MIH-User doesn't talk to a remote entity directly)
>
>
> The MIH-User always talks/(requests) to the local MIHF. Therefore, the
> local MIHF has the information about the MIH-Users and their requests.
> In case a request from a MIH-User requires information from a remote
> MIHF, local MIHF will fetch that information for the MIH-User. This is
> where the MIH-Protocol will be used. The remote MIHF only needs to
> know about the local MIHF, not the MIH-User. Therefore, the current
> MIHF-ID (oMIHF-ID) is sufficient.
>
> It is also possible that multiple MIH-User register/request for the
> same info/event/command. The local MIHF will manage the distribution
> of the info, e.g. when certain event comes from remote MIHF, local
> MIHF will just deliver it to whichever MIH-User registered with itself
> for that particular event.
>
> Getting the MIH-User tightly bound to the MIH-protocol will only limit
> the operation flexibility and increase the overhead for the
> MIH-protocol (over the air).
>
> How do you think about this?
>
> cheers
> Cheng Hong
>
>
> > -----Original Message-----
> > From: stds-802-21@LISTSERV.IEEE.ORG
> > [mailto:stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Kalyan Koora
> > Sent: Thursday, December 22, 2005 10:46 PM
> > To: Cheng Hong; Gupta, Vivek G; STDS-802-21@LISTSERV.IEEE.ORG
> > Subject: AW: [802.21] Ad hoc telecon for Dec 13th
> >
> > Hi Cheng Hong,
> >
> > yes, I know that my explanation was somewhat difficult. I will try
> > with your terms.
> >
> > >So, this is a new ID (different from what we have in the draft)?
> > >Lets call it nMIHF-ID.
> >
> > OK, this is termed here as nMIHF-ID.
> >
> > >A general question: Where exactly would the nMIHF-ID be used?
> >
> > It is used in the MIH protocol, i.e. this is embedded in the MIH
> > packet which is carried between the MIHF peers using transport
> > protocol.
> > Since it is in MIH protocol, I think it is in scope.
> >
> > >And, this is the MIHF-ID we have in the draft? .. so, I will
> > call it oMIHF-ID.
> >
> > OK with this term.
> >
> > >What is the "User"?
> > The user is, MIH user, it can be MIP/SIP/etc. MIH user takes
> > services From MIHF at a peer.
> >
> > >Does this imply that some sort of "user"-level
> > authentication is carried out?
> > No need of this.
> >
> > >Why the User information is required in every message transported
> > >(other than the peer oMIHF-ID)?
> >
> > I'll try to explain. If an MIH-User asks for services from MIHF at
> > peer A,here MIHF(a), then it contacts MIHF at peer B,
> > MIHF(b) using MIH-Protocol. The MIH-Packets are carried in some
> > transport protocol. All the responses from
> > MIHF(b) given back to MIHF(a) are to be sent back to MIH-User. In
> > this case
> > MIHF(a) should keep the tarack of all the requests and responses.
> > This is where I think there should be some sort of registration for
> > even IS too at Local MIHF. But if, for example, nMIHF-ID = oMIHF-ID
> > + MIH-User is used in MIH-Protocol, then as soon as MIHF(a) gets a
> > response, it can easily dispatch the response to the correct
> > MIH-User.
> > If we don't want to added user ID into the nMIHF-ID, then nMIHF-ID =
> > oMIHF-ID.
> > Here it is clear, that we may need couple of bytes more in
> > MIH-Packet, but it leads to less complexity at MIHF and introduces
> > some sort of flexibility.
> >
> > >The oMIHF-ID seems sufficient in providing the MIHF peer identity.
> >
> > Yes, it is sufficient to identity ONLY MIHF peer.
> >
> > >Also, the protocol or interface technology used for the
> > transport would
> > >be known to the receiver MIHF. Why do we need the remote end MIHF
> > >to identify it through the nMIHF-ID? To me, it seems like a
> > internal issue
> > >for the receiving end.
> >
> > In general, as of present, MIHF is not having any information how
> > the MIH packets are received and how packets are to be sent.
> > So far I understood, it can be decide somehow and somewhere.
> > As discussed in previous emails, couple of messages could be bound
> > to couple of transport layers and so on.
> >
> > But let us assume what if an ID is formed using some sort of
> > function like:
> >
> > nMIHF-ID = f(oMIHF-ID, MIH-User ID, protocol/IF ID)
> >
> > >I assume this is about message duplication detection.
> > Similarly, why a
> > >pair of peer oMIHF-IDs (source and dest MIHF-ID), with the
> > Transaction
> > >ID, in current draft cannot achieve the purpose?
> >
> > Message duplication could be advantageous in some cases like some
> > triggers which should be sent soon and with no corruption.
> > The nMIHF-ID will also makes it possible to introduce some sort of
> > intelligence into the MIHF. If a same message with same oMIHF-ID and
> > transaction ID is received more than once, MIHF can analyse over
> > which way and how the quality is.
> > Depending on this MIHF can also decide about the way to give response.
> > I see couple of advantages just by providing this flexible way.
> > In any case, if this sort of intelligence is not required, then we
> > can put all the parameters in the above function to be 0 other than
> > oMIHF-ID.
> >
> > Hope I made it somewhat clear and would like to know about your
> > opinion
> >
> > Regards,
> > Kalyan
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
> > Gesendet: Donnerstag, 22. Dezember 2005 04:17
> > An: Kalyan Koora; Gupta, Vivek G; STDS-802-21@listserv.ieee.org
> > Betreff: RE: [802.21] Ad hoc telecon for Dec 13th
> >
> > Hi Kalyan,
> >
> > Could you please clarify a few points for the proposal? I am trying
> > to understand the proposal, and seems a bit lost (with the different
> > MIHF-IDs :).
> >
> >
> > > In the present draft, it is discussed that the MIHF-ID is
> > generated in
> > > some way or the other. What is, if we have an MIHF-ID (used within
> > > transport to show source/destination)
> >
> > So, this is a new ID (different from what we have in the draft)?
> > Lets call it nMIHF-ID.
> >
> > A general question: Where exactly would the nMIHF-ID be used?
> > In the transport protocol (e.g. L3 or L2 protocol, which is out of
> > .21 scope and should be defined in either, e.g.
> > MIPSHOP or TGu) or the MIH protocol?
> >
> >
> > > from which we can derive MIH function ID (a unique ID of the MIH
> > > function layer at a peer),
> >
> > And, this is the MIHF-ID we have in the draft? .. so, I will call it
> > oMIHF-ID.
> >
> > > transport protocol ID and the user?
> >
> > What is the "User"? Does this imply that some sort of "user"-level
> > authentication is carried out? Why the User information is required
> > in every message transported (other than the peer oMIHF-ID)?
> >
> > And, how would this affect the user (location) privacy?
> >
> >
> > > This enables a received MIHF peer to know from which MIHF
> > the message
> > > is received and over which protocol or interface technology.
> >
> > The oMIHF-ID seems sufficient in providing the MIHF peer identity. I
> > am not sure why the extra information about the protocol and
> > interface in the nMIHF-ID is needed. This seems not a media
> > independent way to go (at least MIHF should not know about it).
> >
> > Also, the protocol or interface technology used for the transport
> > would be known to the receiver MIHF. Why do we need the remote end
> > MIHF to identify it through the nMIHF-ID? To me, it seems like a
> > internal issue for the receiving end.
> >
> >
> > > This will allow us in transporting MIH packets (irrespective of
> > > registration or IS/ES/CS or some other content) over any
> > interface and
> > > using any protocol and at the same time letting the MIH function
> > > at the Rx peer to know from which MIHF Tx the message is received.
> >
> > Same as above, why with the current oMIHF-ID we cannot do that?
> >
> >
> > > Further, in case of sensible
> > > messages, even if same message is sent over different ways
> > it can be
> > > still understood by Rx peer.
> >
> > I assume this is about message duplication detection.
> > Similarly, why a pair of peer oMIHF-IDs (source and dest MIHF-ID),
> > with the Transaction ID, in current draft cannot achieve the
> > purpose?
> >
> > cheers
> >
> > Cheng Hong
> >