Subject: RE: [MIPSHOP-MIH-DT] Discovery thread

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 5 Jul 2007 15:38:05 -0400

Hi Sam,

Sorry for taking so long. Please see some answers below.

Jc

-----Original Message-----
From: sam xia [mailto:[email-masked]] 
Sent: June 28, 2007 1:55 PM
To: Zuniga, Juan Carlos; 'Telemaco Melia'; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Discovery thread

HI, Carlos,
I have some questions about your explaination. Could you give me more
clarifications?
please see my question inline. 

BestRegards;
Sam(Zhongqi)Xia;
-----Original Message-----
From: Zuniga, Juan Carlos [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 12:45 AM
To: Telemaco Melia; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Discovery thread

Hello all,

Subir and I are in the 3GPP in Orlando, and Subir's PC (finally) gave up
on
him :) Hence, we are sending a common response to the last issues.
Please see our comments below.

Cheers,

Jc (&S)

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]]
Sent: June 28, 2007 4:28 AM
To: sam xia; Subir Das
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Discovery thread

Subir, Sam,

I guess that we are now facing the following problems: 

- where the mapping MoSID (MIHFID) <==> MoS IP address is stored I would
see
this happening in the MSTP layer. Could you state what .21 thinks about
it?

[JC&S] This mapping should be done in the MIHF, and in general the MSTP
should receive a unicast IP address from the MIHF. However, during
discovery, this address could be a b'cast/m'cast address (see next
point).

Sam> 
I am not sure what the "address" in your comments stands for? It's an IP
address for MIHF entity, or just an IP address for an uncertain/specific
other service entity used to help discovery MIHF entity?

[JCZ] Yes, it is an IP address for an MIHF entity.

Do you mean that while discovering, MIHF MUST input a parameter
"address" to
MSTP?

[JCZ] I would assume so.

Do you mean that MSTP knows the IP address for MIHF entity and does not
know
the MIHF ID for MIHF entity?

[JCZ] I think so.

Do you mean that MSTP never cares MIHF ID for MIHF entity?

[JCZ] Not sure if by "never cares" you mean that it does not require it,
or it does not carry it.

Do you mean that the input parameter from MoS to MSTP is always IP
address,
impossible for MIHF ID?

[JCZ] If the mapping happens in the MIHF, the MIHF ID is hidden in the
payload.

- broadcast vs request/reply discovery mechanism This should help in
covering all the possible scenarios

[JC&S] Both can be supported. Assuming that the transport provides a
b'cast
mechanism (e.g. IP b'cast/m'cast), the MIHF can request the MSTP to send
either a b'cast or a unicast discovery request message.

- capability discovery associated or not to MoS discovery I would say it
is
optional

[JC&S] Indeed, this is currently an option in 802.21. The discovery
response
could include some capability information (e.g. which services are
supported) to allow the source taking a better decision. However, this
would
be transparent to the MSTP.

We all agree that MoS can be located either in the home or the visited.

[JC&S] Yes we do. However, we have some views regarding this topic (and
what
was written in the draft doc).
In our view, IS could be either be provided by the home, visited, or
both.
This, more than a recommendation will be a deployment specific issue,
which
will be related to the policies dictated by the home operator, (e.g. get
this services "only" from me, but those you "could"
get from visited).
Regarding the ES/CS, these should be close to where the HO decision is
being
taken, which again could be in the home or visited network.
Therefore, since all these scenarios must be supported by the MSTP, we
DO
NOT believe that we should favour one scenario vs another. The solution
that
we provide should work well in all scenarios. Thus, all services could
be in
home or visited and we should remove the direct statement from the text
doc.
We can keep the table with the mapping showing all, but not showing
preferred.

SAM> How do people in .21 WG think about the situation wherein MoS is
deployed in the third party, neither in home network nor in visited
network?
Is it possible?

[JCZ] I don't know where that could be.

Views?

Tele

-----Original Message-----
From: sam xia [mailto:[email-masked]]
Sent: Tuesday, June 26, 2007 5:55 PM
To: 'Subir Das'
Cc: Telemaco Melia; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Discovery thread

HI Subir,
please see my comments inline.

BestRegards;
Sam(Zhongqi)Xia;
-----Original Message-----
From: Subir Das [mailto:[email-masked]]
Sent: Saturday, June 23, 2007 1:31 AM
To: sam xia
Cc: 'Telemaco Melia'; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Discovery thread

sam xia wrote:
>  Hi, all
>  Before we discuss the mapping relation, I think we have some issues 
> to clarify and unite firstly:
>
> 1: What is the policy to direct discovering procedure?
> If there are a lot of MoSes deployed, which one/some MoS server is 
> required for requestion MIHF node?  For example,  IS/CS/ES are 
> deployed at homenetwork, visited homenetwork as well as the third 
> network,  which ones are required for requesting nodes?
>   
  Subir> I don't think we need to depend too much on policy on
discovering
procedure. May be I am missing something.
IMO,  the important thing will be deployment models/scenrios and we
should
allow all of them.

SAM> For example, if there exists a lot of MoS providers, which one/ones
should be discoverd by MIHF in the mobile node?  In particular, for a
mobile
node, there maybe exist MoS providers in the home network and visited
network. Which one should we discover?  What is the policy?

> 2:  What information is stored where (Tele mentioned) This point is 
> very important and has critical impacts on our discovering
> procedure.    Home network/ Visisted Network /or Centralized database?
> And the discovering model John described is useful for us to discuss.
>   
    Subir> Which information are we referring here? If we support all
possible scenarios how does it
   matter where the information is stored?
SAM> I don't think that it is possible that one solution is suitable for
all
scenarios. I just think that it is good enough that one solution is
suitable
for all scenarios existing in the real world and some possible future
scenarios.  BTW,  if we don't discuss the how and where to store MIHF
ID,
the corresponding IP address as well as the MIHF capabilities, what's
the
base for us to discuss the solution?

>
>
>
> BestRegards;
> Sam(Zhongqi)Xia;
> -----Original Message-----
> From: Telemaco Melia [mailto:[email-masked]]
> Sent: Friday, June 22, 2007 11:32 PM
> To: [email-masked]
> Subject: [MIPSHOP-MIH-DT] Discovery thread
>
> HI all,
>
> I just start a new thread to have a clear starting point.
>
> First of all let me state that I agree with the picture Subir
proposed.
> In fact it is explaining more in details what we already stated in the

> PS document (figure 5) and I guess this is well accepted from all of
us.
> Now before considering the 3 scenarios Subir proposed I guess we 
> should pay attention to what information is stored where.
>
> Info@MIHFID: how the MIHF can configure its own MIHFID? I remember we 
> had many discussions in Prague and the consensus was that whatever is 
> the mechanism (.21 specific) the MSTP has nothing to do with it.
> The MSTP is just informed about the MIHFID. Is the assumption still
valid?
>
> Info@MSTP: could we agree that the MSTP performs reverse address 
> translation between MIHFID and IP address of that MIHFID?
> And that this is the only information that the MSTP retains of the
Mos?
>
> Considering the above, depending on when the information is available,

> we end up in the cases Subir described.
>
> CaseI:  MIHFID@destination is known but NOT IPaddress@destination
>  
> CaseII: IPaddress@destination is known but NOT the MIHFID@destination 
> Is this possible at all if the MSTP performs the mapping?
>
> CaseIII: Neither MIHFID@destination nor IPaddress@destination are 
> known
>
> Beside caseII where I have doubts, we probably need a request reply 
> mechanism for caseI and caseIII.
> Would a solution similar to the request reply model of the IS match 
> our requirements? Multihop operation? Centralized vs. decentralized?
> Additionally, considering caseIII capability discovery might help in 
> MIHF node discovery when no info on the MIHF peer is available.
>
>
>
> Views?
>
> tele
>
>
>
>
>
>
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
>
>
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
>   

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Sam Xia <[email-masked]>
Date: Mon, 09 Jul 2007 15:31:57 +0800

Hi Carlos,

Thank you for your answer. And I still have some doubts inline.

 Best Regards, Sam Xia 

> Sent: Friday, July 06, 2007 3:38 AM
> To: sam xia; Telemaco Melia; [email-masked]
> I have some questions about your explaination. Could you give 
> me more clarifications?
> Subir and I are in the 3GPP in Orlando, and Subir's PC 
> (finally) gave up on him :) Hence, we are sending a common 
> response to the last issues.
> - where the mapping MoSID (MIHFID) <==> MoS IP address is 
> stored I would see this happening in the MSTP layer. Could 
> you state what .21 thinks about it?
> 
> [JC&S] This mapping should be done in the MIHF, and in 
> general the MSTP should receive a unicast IP address from the 
> MIHF. However, during discovery, this address could be a 
> b'cast/m'cast address (see next point).
> 
> Sam> 
> I am not sure what the "address" in your comments stands for? 
> It's an IP address for MIHF entity, or just an IP address for 
> an uncertain/specific other service entity used to help 
> discovery MIHF entity?
> 
> Do you mean that while discovering, MIHF MUST input a 
> parameter "address" to MSTP?
> 
> [JCZ] I would assume so.

SAM> Good.From your answers, i can almost draw the discovering procdure for
MIHF entity. MSTP has no idea of MIHF ID. So during discovery, MSTP does
nothing except to send a req and to receive a response. No resolution from
MIHF ID to IP address or vice versa in MSTP. Am I right?

If I am right, MSTP only takes the responsibility for transporting (send and
receive) MIHF entity dicovering packets. It's just a transport function, not
discovery function. Do you think so?

> 
> 
> Do you mean that MSTP knows the IP address for MIHF entity 
> and does not know the MIHF ID for MIHF entity?
> 
> [JCZ] I think so.
> 
> 
> [JCZ] Not sure if by "never cares" you mean that it does not 
> require it, or it does not carry it.
> 
> Do you mean that the input parameter from MoS to MSTP is 
> always IP address, impossible for MIHF ID?
> 
> [JCZ] If the mapping happens in the MIHF, the MIHF ID is 
> hidden in the payload.
> 
> - broadcast vs request/reply discovery mechanism This should 
> help in covering all the possible scenarios
> 
> [JC&S] Both can be supported. Assuming that the transport 
> provides a b'cast mechanism (e.g. IP b'cast/m'cast), the MIHF 
> can request the MSTP to send either a b'cast or a unicast 
> discovery request message.
> 
> 
> 
> - capability discovery associated or not to MoS discovery I 
> would say it is optional
> 
> [JC&S] Indeed, this is currently an option in 802.21. The 
> discovery response could include some capability information 
> (e.g. which services are
> supported) to allow the source taking a better decision. 
> However, this would be transparent to the MSTP.
> 
> 
> [JC&S] Yes we do. However, we have some views regarding this 
> topic (and what was written in the draft doc).
> In our view, IS could be either be provided by the home, 
> visited, or both.
> This, more than a recommendation will be a deployment 
> specific issue, which will be related to the policies 
> dictated by the home operator, (e.g. get this services "only" 
> from me, but those you "could"
> get from visited).
> Regarding the ES/CS, these should be close to where the HO 
> decision is being taken, which again could be in the home or 
> visited network.
> Therefore, since all these scenarios must be supported by the 
> MSTP, we DO NOT believe that we should favour one scenario vs 
> another. The solution that we provide should work well in all 
> scenarios. Thus, all services could be in home or visited and 
> we should remove the direct statement from the text doc.
> We can keep the table with the mapping showing all, but not 
> showing preferred.
> 
> deployed in the third party, neither in home network nor in 
> visited network?
> Is it possible?
> 
>   Subir> I don't think we need to depend too much on policy 
> on discovering procedure. May be I am missing something.
> IMO,  the important thing will be deployment models/scenrios 
> and we should allow all of them.
> 
> should be discoverd by MIHF in the mobile node?  In 
> particular, for a mobile node, there maybe exist MoS 
> providers in the home network and visited network. Which one 
> should we discover?  What is the policy?
> 
>     Subir> Which information are we referring here? If we 
> support all possible scenarios how does it
> scenarios. I just think that it is good enough that one 
> solution is suitable for all scenarios existing in the real 
> world and some possible future scenarios.  BTW,  if we don't 
> discuss the how and where to store MIHF ID, the corresponding 
> IP address as well as the MIHF capabilities, what's the base 
> for us to discuss the solution?
> 
> >
> >
> >
> > BestRegards;
> > Sam(Zhongqi)Xia;