Re: [802.21] Ad hoc telecon for Dec 13th
On Fri, Dec 23, 2005 at 02:00:49AM -0800, Gupta, Vivek G wrote:
> 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?
If the MIHF Identifier is L2/L3 address it should be part of transport
specific header not in the MIHF header. I see no reason for the MIHF
Identifier to be something other than L2/L3 address while I think some
additional identifier may be needed in the MIH header if there are
multiple simultaneous MIH sessions between a pair of communicating
MIHFs.
Yoshihiro Ohba
>
> 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
> > >
>