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
> > >> >>
>