Subject: [MIPSHOP-MIH-DT] Discovery thread

From: Telemaco Melia <[email-masked]>
Date: Fri, 22 Jun 2007 17:32:10 +0200

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

---

From: "sam xia" <[email-masked]>
Date: Sat, 23 Jun 2007 00:22:40 +0800

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?

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.

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,

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.

CaseII: IPaddress@destination is known but NOT the MIHFID@destination Is
this possible at all if the MSTP performs the mapping?

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

---

From: Subir Das <[email-masked]>
Date: Fri, 22 Jun 2007 13:20:09 -0400

Tele,
Thanks for summarizing it. Pl. see my views inline.

-Subir

Telemaco Melia wrote:
> 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.
>
Subir>    As far as .21 model goes, some users informs the MIHF ID to 
the MIHF. If not, MIHF needs to discover it. I agree
    with you that transport protocol has nothing to do with it. It is 
the role of MOS protocol  to do the mapping between MIHF ID
    and transport address.
>
> Info@MSTP: could we agree that the MSTP performs reverse address 
> translation between MIHFID and IP address of that MIHFID?
Subir>    We have to remember that FQDN or NAI is example of MIHF ID. It 
is not mandatory that it has to be always that.
     For example, in a closed network, one can use something else as 
long as it is unique in tat operating domain. But of course, for 
interworking with others or to support roaming cases, it has to be 
globally unique. Of course one can argue that NAI  alone may not be 
globally unique.

 Now if MIHF ID is FQDN, yes a reverse lookup will help to discover the 
IP address and it is perfectly a valid solution. And that means an out 
of band discovery mechanism will be used. But I would suggest not to 
jump to a specific solution yet.

> Is this possible at all if the MSTP performs the mapping?
  Subir>  I would say, MSTP does not need to do the mapping, it is the 
MIHF who keeps the mapping at least for .21.
> 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.
   Subir> That's  the reason I wanted to clarify our assumptions here 
and also wanted to give .21 perspective. Is it always necessary to have 
a request/reply mechanism for discovery?

---

From: Subir Das <[email-masked]>
Date: Fri, 22 Jun 2007 13:30:37 -0400

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

---

From: "sam xia" <[email-masked]>
Date: Tue, 26 Jun 2007 23:40:43 +0800

hi Subir,
See my comments inline. 

-----Original Message-----
From: Subir Das [mailto:[email-masked]] 
Sent: Saturday, June 23, 2007 1:20 AM
To: Telemaco Melia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Discovery thread

Tele,

-Subir

Telemaco Melia wrote:
> 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.
Subir>    As far as .21 model goes, some users informs the MIHF ID to
the MIHF. If not, MIHF needs to discover it. I agree
    with you that transport protocol has nothing to do with it. It is the
role of MOS protocol  to do the mapping between MIHF ID
    and transport address.

SAM>  If MoS do the mapping, the input from MoS to transport SAP exposed to
the tansport user is transport address, instead of MIHF ID. Am I right?  But
from the .21, i learn that the parameter of SAP from MoS to MSTP is MIHF ID.
Is it a collision?

Subir>    We have to remember that FQDN or NAI is example of MIHF ID. It
is not mandatory that it has to be always that.
     For example, in a closed network, one can use something else as long as
it is unique in tat operating domain. But of course, for interworking with
others or to support roaming cases, it has to be globally unique. Of course
one can argue that NAI  alone may not be globally unique.

 Now if MIHF ID is FQDN, yes a reverse lookup will help to discover the IP
address and it is perfectly a valid solution. And that means an out of band
discovery mechanism will be used. But I would suggest not to jump to a
specific solution yet.

SAM >  There are too many uncertainities in .21.  without specific scenarios
and assumptions, it is hard to come up with a solution.  And i think that it
is just the cause that we can not come up a possible solution. Even the
deadline is coming, We are arguing the requirements now!  And i think that
time is very urgent and that it is the moment to discuss some specific
details.

> Is this possible at all if the MSTP performs the mapping?
  Subir>  I would say, MSTP does not need to do the mapping, it is the MIHF
who keeps the mapping at least for .21.
> MIHF node discovery when no info on the MIHF peer is available.
   Subir> That's  the reason I wanted to clarify our assumptions here and
also wanted to give .21 perspective. Is it always necessary to have a
request/reply mechanism for discovery?

---

From: "sam xia" <[email-masked]>
Date: Tue, 26 Jun 2007 23:54:46 +0800

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

---

From: "Telemaco Melia" <[email-masked]>
Date: Thu, 28 Jun 2007 10:27:43 +0200

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?

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

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

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

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,

BestRegards;
Sam(Zhongqi)Xia;

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 28 Jun 2007 12:44:37 -0400

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,

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

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

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

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,

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

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

    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?

> Considering the above, depending on when the information is available,

> we end up in the cases Subir described.
>

---

From: "sam xia" <[email-masked]>
Date: Fri, 29 Jun 2007 01:54:51 +0800

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,

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

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

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

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

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

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?

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,

BestRegards;
Sam(Zhongqi)Xia;