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
>
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
> Behalf Of
> > Kalyan Koora
> > Sent: Wednesday, December 21, 2005 11:52 PM
> > To: Gupta, Vivek G; STDS-802-21@listserv.ieee.org
> > Subject: AW: [802.21] Ad hoc telecon for Dec 13th
> >
> > Hello All,
> >
> > after seeing this discussion, I feel that the concept which I
> > discussed with couple of you seem to be applicable to solve the
> > present discused problem. So, I just put into the group for
> discussion
> > and see what you all feel about it.
> >
> > 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) from which we can derive MIH
> > function ID (a unique ID of the MIH function layer at a peer),
> > transport protocol ID and the user?
> > This enables a received MIHF peer to know from which MIHF
> the message
> > is received and over which protocol or interface technology.
> > This will allow us in transproting 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.
> > Further, in case of sensible messages, even if same message is sent
> > over different ways it can be still understood by Rx peer.
> >
> > Regards,
> > Kalyan
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM]
> > Gesendet: Mittwoch, 21. Dezember 2005 16:11
> > An: STDS-802-21@LISTSERV.IEEE.ORG
> > Betreff: Re: [802.21] Ad hoc telecon for Dec 13th
> >
> >
> > Srini,
> >
> > [1] Why don't we need registration for IS? Should the MIH enabled
> > Information Service server start providing service to any
> UE without
> > registration?
> >
> > [2] As for tying transport and MIH registration, in my view it does
> > lead to less complex implementations. Mixing and matching transport
> > and different services may lead to additional complexity
> without any
> > undue benefits.
> > For example if communication and registration has been established
> > using
> > L2 and if you are accessing a set of services using L2, and if
> > suddenly/in between the MIH PoS starts sending some of the messages
> > over L3, the client may have difficulty in dealing with it.
> > Why would one want to do MIH registration using one
> transport and then
> > use MIH services over another transport?
> >
> > Best Regards
> > -Vivek
> >
> > > -----Original Message-----
> > > From: Srinivas.Sreemanthula@nokia.com
> > > [mailto:Srinivas.Sreemanthula@nokia.com]
> > > Sent: Monday, December 19, 2005 2:09 PM
> > > To: Gupta, Vivek G; reijo.salminen@seesta.com;
> > > benjamin.kohtm@SG.PANASONIC.COM; STDS-802-21@listserv.ieee.org
> > > Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> > >
> > > Vivek and Reijo,
> > > There is a common understanding that the registration for
> IS may not
> > be
> > > feasible. So far the focus has been only on ES/CS. Do you see the
> > > benefit of tying the transport to the MIH registration?
> > >
> > > My understanding was to have a transport independent framework for
> > this
> > > concept. One could use any transport as long as the
> credentials/ids
> > are
> > > same. Then the question is could one have multiple sets of
> > credentials
> > > that can be used to do multiple registrations between two peers?
> > > Possible, but what is the benefit? Another question to
> ask - Are we
> > > talking about multiple registration between two MIH peers?
> > Or multiple
> > > registrations to the network involving MIH in STA to multiple MIH
> > > entities in the network? If latter, we need some
> coordination among
> > the
> > > involved MIH network entities or else it may be conflicting.
> > >
> > > In the end, it is possible to do it if we have some concrete use
> > cases.
> > >
> > > Regards,
> > > Srini
> > >
> > > >-----Original Message-----
> > > >From: ext Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> > > >Sent: Saturday, December 17, 2005 6:04 AM
> > > >To: Reijo Salminen; Sreemanthula Srinivas (Nokia-NRC/Dallas);
> > > >benjamin.kohtm@SG.PANASONIC.COM; STDS-802-21@listserv.ieee.org
> > > >Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> > > >
> > > >
> > > >One reason I can think of for multiple registrations between two
> > > >MIH peers is if they end up using multiple (different)
> transports.
> > > >For example if two MIH peers were using say L3 for IS and say L2
> > > >for ES/CS, quite likely you may need multiple registrations.
> > > >
> > > >BR,
> > > >-Vivek
> > > >
> > > >> -----Original Message-----
> > > >> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
> > > >Behalf Of
> > > >> Reijo Salminen
> > > >> Sent: Saturday, December 17, 2005 12:06 AM
> > > >> To: Srinivas.Sreemanthula@NOKIA.COM;
> > > >benjamin.kohtm@SG.PANASONIC.COM;
> > > >> STDS-802-21@listserv.ieee.org
> > > >> Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> > > >>
> > > >> Hello,
> > > >>
> > > >> Comment on the multiple registrations, I think it
> would be useful
> > for
> > > >eg.
> > > >> due to the mentioned bandwidth reasons. For example if for a
> > roaming
> > > >> subscriber there is frequent
> registrations/deregistrations due to
> > > >changes
> > > >> in
> > > >> the access network (or if the operator of the access
> network has
> > > >different
> > > >> policies for MIH support at different parts of the access
> > > >network). It
> > > >> could ease the registration process if there could be several
> > > >> registrations,
> > > >and
> > > >> they could be in different states.
> > > >>
> > > >> Comments?
> > > >>
> > > >> BR, Reijo
> > > >>
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
> > > >Behalf Of
> > > >> Srinivas.Sreemanthula@nokia.com
> > > >> Sent: Saturday, December 17, 2005 12:33 AM
> > > >> To: benjamin.kohtm@SG.PANASONIC.COM;
> > STDS-802-21@listserv.ieee.org
> > > >> Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> > > >>
> > > >> Hi Benjamin,
> > > >> I agree with you discovery will happen before as shown
> > in the flow
> > > >> diagram. That statement was specifically referring to ES/CS
> > messages
> > > >> after the discovery procedure. I will change the text to
> > > >reflect this
> > > >> comment.
> > > >>
> > > >> On the second issue, can you elaborate why one would
> > need more than
> > > >one
> > > >> registration between two MIH peers? We discussed the
> > need for only
> > > >one.
> > > >>
> > > >> Regards,
> > > >> Srini
> > > >>
> > > >> >-----Original Message-----
> > > >> >From: ext Benjamin Koh
> [mailto:benjamin.kohtm@SG.PANASONIC.COM]
> > > >> >Sent: Monday, December 12, 2005 11:29 PM
> > > >> >To: STDS-802-21@listserv.ieee.org
> > > >> >Subject: Re: [802.21] Ad hoc telecon for Dec 13th
> > > >> >
> > > >> >Hi!
> > > >> >
> > > >> >Unfortunately I'll not be able to attend this teleconf,
> > however I
> > > >> >have some comments regarding the ES/CS registration.
> > > >> >
> > > >> >"MIH peers may not provide or accept MIH messages without an
> > active
> > > >> >registration session"
> > > >> >While I'm not against having such a requirement, we should
> > consider
> > > >> >allowing some form of (limited?) query or discovery before
> > > >> >registration.
> > > >> > A scenario may be for the initiating node to first
> > query and find
> > > >> >out what are the available Event/Command Services
> > before deciding
> > > >> >whether or not to initiate the registration process
> > (which may be
> > > >> >expensive in terms of time, bandwidth and/or processing).
> > > >This may be
> > > >> >related to some aspects of ES/CS discovery.
> > > >> >
> > > >> >"Establishes a session setup and assigns an id"
> > > >> >Does this imply that that multiple simultaneous sessions
> > > >between the
> > > >> >same two nodes may require multiple registrations?
> > > >> >What is the scenario you have in mind for that?
> > > >> >
> > > >> >Regards,
> > > >> >Ben
> > > >> >
> > > >> >
> > > >> >Srinivas Sreemanthula wrote:
> > > >> >> Hello all,
> > > >> >> Here is the slideset that is built on top of last meeting
> > > >and some
> > > >> >> email discussions. We can use these topics for open
> > > >discussions and
> > > >> >> draw some conclusions.
> > > >> >>
> > > >> >> Regards,
> > > >> >> Srini
> > > >> >>
> >
>