Subject: [MIPSHOP-MIH-DT] Discovery thread

From: Telemaco Melia <[email-masked]>
Date: Fri, 08 Jun 2007 12:41:04 +0200

Hi all,

I just start a new tread to allow easier reading.

First of all a general comment.
I think we need to design a recommended discovery solution while not 
preventing other specific mechanisms to be used.
I guess Stefano's suggestion is the right compromise to ensure enough 
flexibility to the solution.

As for the candidate analysis, in this case DHCP, I think nobody did 
consider the different types of MoS we need to discover, and what model 
we would like to use.
I can see two different ways of working: PULL model and PUSH model.

PULL model: this is probably what the terminal applies when requesting 
for an IS
We were discussing this internally and the feeling is that for roaming 
scenarios DHCP cannot help much in discovering IS of roaming partners.
Additionally we should take into account that also network nodes might 
use the IS. Not sure about the use of DHCP in this case.

PUSH model: this is probably what the network does by subscribing for 
events of mobiles nodes (and use CS to mandate handovers) upon 
authentication.

For the PULL model we also take into account the proxy model. In Prague 
we did agree that multi hop discovery in out of scope.
However, I would like to discuss the possibility to apply the same model 
.21 applies (session ID and transaction ID) for the proxy model.

Views?

telemaco

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

---

From: "Stefano Faccin" <[email-masked]>
Date: Fri, 8 Jun 2007 07:17:24 -0700

Tele,
I was thinking of use cases and I have a question. I may agree that DHCP
would not help in discovering information for a roaming partner (in most
cases). What about the use cases where the same operator (home or
visited) support both air interface 1 and air interface 2? 

One aspect to consider is the architecture. For the mobile node to be
able to use a mechanism based on IP transport to access a given server
(DHCP, etc.), the mobile node must have IP connectivity with such
entity. Depending on the specific architecture, the mobile node may gain
connectivity directly to the visited network, i.e. close to the access,
or remotely (e.g. in the home network). To make a parallel, in
traditional GPRS the connectivity is with the home network because the
GGSN is located there, whereas some of the information servers having
knowledge of the information local to the access are typically in the
visited network. I would consider this type of aspects carefully.

A question for clarification: are you talking about MIHS discovery, or
network discovery?

Stefano

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 3:41 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] Discovery thread

Hi all,

Views?

telemaco

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 13:44:04 -0500

Hi all,

First off, I would recommend we have a mandatory to implement discovery
mechanism, while
supporting other mechanisms.  This is manditory to implement, so that it
could always be
used as a fallback when a specific mechanism is not available.

For discovery, I guess we have a couple of architectures we could
support:

1) Home network (everything goes back to the 'home')
2) Visited network (discovery on the local network you are attached to).
 2a) visited network provides the service
 2b) visited network supports a roaming infrastructure back to the home
network
3) No discovery, preprovision the solution.

Implicit in this is who is providing the service.  

I'm leaning to something 2b above, as I think that is the only scalable
solution,
however if 2B is not supported, I guess we could always fall back to the
other 
solutions.

thoughts?
John

>From: ext Stefano Faccin [mailto:[email-masked]] 
>Sent: 08 June, 2007 07:17
>To: Telemaco Melia; [email-masked]
>Subject: RE: [MIPSHOP-MIH-DT] Discovery thread
>
>Tele,
>I was thinking of use cases and I have a question. I may agree 
>that DHCP would not help in discovering information for a 
>roaming partner (in most cases). What about the use cases 
>where the same operator (home or
>One aspect to consider is the architecture. For the mobile 
>node to be able to use a mechanism based on IP transport to 
>access a given server (DHCP, etc.), the mobile node must have 
>IP connectivity with such entity. Depending on the specific 
>architecture, the mobile node may gain connectivity directly 
>to the visited network, i.e. close to the access, or remotely 
>(e.g. in the home network). To make a parallel, in traditional 
>GPRS the connectivity is with the home network because the 
>GGSN is located there, whereas some of the information servers 
>having knowledge of the information local to the access are 
>typically in the visited network. I would consider this type 
>of aspects carefully.
>
>A question for clarification: are you talking about MIHS 
>discovery, or network discovery?
>
>Stefano
>
>I think we need to design a recommended discovery solution 
>while not preventing other specific mechanisms to be used.
>I guess Stefano's suggestion is the right compromise to ensure 
>enough flexibility to the solution.
>
>As for the candidate analysis, in this case DHCP, I think 
>nobody did consider the different types of MoS we need to 
>discover, and what model we would like to use.
>PULL model: this is probably what the terminal applies when 
>requesting for an IS We were discussing this internally and 
>the feeling is that for roaming scenarios DHCP cannot help 
>much in discovering IS of roaming partners.
>Additionally we should take into account that also network 
>nodes might use the IS. Not sure about the use of DHCP in this case.
>
>PUSH model: this is probably what the network does by 
>subscribing for events of mobiles nodes (and use CS to mandate 
>handovers) upon authentication.
>
>For the PULL model we also take into account the proxy model. 
>In Prague we did agree that multi hop discovery in out of scope.

---

From: "Stefano Faccin" <[email-masked]>
Date: Fri, 8 Jun 2007 12:37:55 -0700

John, well put. However, I don't think we can live with 2b in all cases.
E.g., in certain cases the UE has only connectivity with the home
network, and no ability to connect with any server at IP level locally.
Therefore, it must use (1). An example is 3GPP with home routed traffic:
all IP traffic goes directly to the home network. 
Stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 11:44 AM
To: Stefano Faccin; [email-masked];
[email-masked]

Hi all,

thoughts?
John

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 14:44:18 -0500

well, I guess we could qualify my points.  In the 3GPP case,
the local connection is the home network, as you are getting
your IP address & first hop router from your home network - 
so you are never really in a visited network, as far as IP 
connectivity is concerned.

John

>Sent: 08 June, 2007 12:38
>To: Loughney John (Nokia-NRC/PaloAlto); 
>[email-masked]; [email-masked]
>E.g., in certain cases the UE has only connectivity with the 
>home network, and no ability to connect with any server at IP 
>level locally.
>First off, I would recommend we have a mandatory to implement 
>discovery mechanism, while supporting other mechanisms.  This 
>is manditory to implement, so that it could always be used as 
>a fallback when a specific mechanism is not available.
>
> 2b) visited network supports a roaming infrastructure back to 
>the home network
>I'm leaning to something 2b above, as I think that is the only 
>scalable solution, however if 2B is not supported, I guess we 
>could always fall back to the other solutions.
>
>thoughts?
>John
> 
>
>>I was thinking of use cases and I have a question. I may agree that 
>>DHCP would not help in discovering information for a roaming partner 
>>(in most cases). What about the use cases where the same 
>operator (home 
>>or
>>entity. Depending on the specific architecture, the mobile node may 
>>gain connectivity directly to the visited network, i.e. close to the 
>>access, or remotely (e.g. in the home network). To make a 
>parallel, in 
>requesting 
>>for an IS We were discussing this internally and the feeling is that 
>>for roaming scenarios DHCP cannot help much in discovering IS of 
>>roaming partners.
>nodes might 
>>events of mobiles nodes (and use CS to mandate

---

From: "Stefano Faccin" <[email-masked]>
Date: Fri, 8 Jun 2007 12:55:24 -0700

Ok, I see your point. However, we need to consider the lower layers when
we define the terminology. There are scenarios where the visited network
(i.e. the network where the terminal gains connectivity at L2) is
different from the network where the terminal gains IP connectivity (in
the example below for me that's the home network). In such scenarios,
one may think of using MIH ES/CS for traffic steering in terms of
controlling the access the terminal connects to in the visited network.
To describe such scenario, I need to keep using the term visited network
for the network where the terminal gains link layer and possibly IP
connectivity, and home network for the network the terminal has a
subscription with (and where in certain scenarios the MIH service must
be provided).

Stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 12:44 PM
To: Stefano Faccin; [email-masked];
[email-masked]

John

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 15:11:05 -0500

Then, I guess we need to be clear at which layer we are talking about,
otherwise we will really get people confused.  

>Sent: 08 June, 2007 12:55
>Ok, I see your point. However, we need to consider the lower 
>layers when we define the terminology. There are scenarios 
>where the visited network (i.e. the network where the terminal 
>gains connectivity at L2) is different from the network where 
>the terminal gains IP connectivity (in the example below for 
>me that's the home network). In such scenarios, one may think 
>of using MIH ES/CS for traffic steering in terms of 
>To describe such scenario, I need to keep using the term 
>visited network for the network where the terminal gains link 
>layer and possibly IP connectivity, and home network for the 
>network the terminal has a subscription with (and where in 
>certain scenarios the MIH service must be provided).
>
>Stefano
>
>your IP address & first hop router from your home network - so 
>you are never really in a visited network, as far as IP 
>>To: Loughney John (Nokia-NRC/PaloAlto); [email-masked]; 
>>[email-masked]
>discovery 
>>mechanism, while supporting other mechanisms.  This is manditory to 
>>implement, so that it could always be used as a fallback when a 
>>specific mechanism is not available.
>>
>>solution, however if 2B is not supported, I guess we could 
>always fall 
>>back to the other solutions.
>>
>>thoughts?
>>John
>> 
>>
>node to be 
>subscribing for

---

From: Sam Xia <[email-masked]>
Date: Mon, 11 Jun 2007 11:12:33 +0800

hi all,
 see the inline.

> 
> Then, I guess we need to be clear at which layer we are 
> talking about, otherwise we will really get people confused.  
> 

I think that Stefano identifies a particular use case which has been
deployed in GPRS networks.  Even US is attached to the visited foreign
network, its IP connectivity is bound to the SGSN in home network.  This
situation adds the complexity to the MIHF discovering procedure. I consider
that a new architecture should be supplementd as follows:
1) Home network (everything goes back to the 'home')
   1a) home network provides the service;
   1b) home network supports a roaming infrastucture destined to the MIHF
service in the visited network; or provides proxy in home network, sering as
MIHF services in visited network.

The 1b) model considers the special use cases, such as GPRS/UMTS.

comments?

> >Ok, I see your point. However, we need to consider the lower layers 
> >when we define the terminology. There are scenarios where 
> the visited 
> >network (i.e. the network where the terminal gains 
> connectivity at L2) 
> >is different from the network where the terminal gains IP 
> connectivity 
> >(in the example below for me that's the home network). In such 
> >scenarios, one may think of using MIH ES/CS for traffic steering in 
> >terms of controlling the access the terminal connects to in 
> the visited 
> >network.
> >To describe such scenario, I need to keep using the term visited 
> >network for the network where the terminal gains link layer and 
> >possibly IP connectivity, and home network for the network 
> the terminal 
> >has a subscription with (and where in certain scenarios the 
> MIH service 
> >must be provided).
> >
> >Stefano
> >
> the local 
> >connection is the home network, as you are getting your IP address & 
> >first hop router from your home network - so you are never 
> really in a 
> >visited network, as far as IP connectivity is concerned.
> >
> >John
> >
> while not 
> nobody did

---

From: "Stefano Faccin" <[email-masked]>
Date: Sun, 10 Jun 2007 20:14:11 -0700

Sam, 
yes, that is one possibility. However, in case the connectivity as in GPRS is through a GGSN in the home network, I'm not sure I see the case where the service would be provided by the visited network. It seems there would be a lot of info going back and forth, not sure if it is worthwhile when considering the roaming scenarios wrt the subscription cases that are possible.
Stefano

________________________________

From: Sam Xia [mailto:[email-masked]]
Sent: Sun 6/10/2007 8:12 PM
To: [email-masked]; Stefano Faccin; [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Discovery thread

hi all,
 see the inline.

comments?

---

From: Sam Xia <[email-masked]>
Date: Mon, 11 Jun 2007 11:27:09 +0800

Hi, all,
 please see the inline.

> Sent: Friday, June 08, 2007 6:41 PM
> I guess Stefano's suggestion is the right compromise to 
> ensure enough flexibility to the solution.
> 

Maybe. But I am not sure.  Because in most cases the MIHF services will be
deployed in the access network/visited network, instead of in the
homenetwork, i don't know why DHCP can not hlep much in discovering IS. 

> subscribing for events of mobiles nodes (and use CS to 
> mandate handovers) upon authentication.

Yes, for the push model, we don't need to think more about this. DHCP is
only useful for pull model.

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 11 Jun 2007 16:12:13 +0200

Hi all,

Would something similar to this start to capture the discussions?

                                X
      +--------------+  +====+  X   +====+   +--------------+
      | HOME NETWORK |  |MoSh|  X   |MoSh|   | HOME NETWORK |
      +--------------+  +====+  X   +====+   +--------------+
            /\                  X                  /\
            ||                  X                  ||
            \/                  X                  \/
        +--------+              X   +====+ +-----------------+
        |   MN   |              X   |MoSv| | VISITED NETWORK |
        +--------+              X   +====+ +-----------------+
                                X                  /\
                                X                  ||
                                X                  \/
                                X              +--------+
                                X              |   MN   |
                                X              +--------+
                                X

tele

---

From: <[email-masked]>
Date: Mon, 11 Jun 2007 13:00:56 -0500

Do we also need to consider L2?  I think the plausable scenarios we have
are:

1) L2 connected to home network, L3 connected to home network 
2) L2 connected to visited network, L3 connected to home network (3GPP
roaming case)
3) L2 connected to visited network, L3 connected to visited network 

John

>From: ext Telemaco Melia [mailto:[email-masked]] 
>Sent: 11 June, 2007 07:12
>To: Loughney John (Nokia-NRC/PaloAlto)
>Cc: [email-masked]; [email-masked]
>Subject: Re: [MIPSHOP-MIH-DT] Discovery thread
>
>Hi all,
>
>> discovery mechanism, while supporting other mechanisms.  This is 
>> manditory to implement, so that it could always be used as a 
>fallback 
>> when a specific mechanism is not available.
>>
>>  2b) visited network supports a roaming infrastructure back to the 
>> home network
>> scalable solution, however if 2B is not supported, I guess we could 
>> always fall back to the other solutions.
>>
>> thoughts?
>> John
>>  
>>
>>   
>>> (in most cases). What about the use cases where the same operator 
>>> (home or
>>> able to use a mechanism based on IP transport to access a given 
>>> server (DHCP, etc.), the mobile node must have IP connectivity with 
>>> such entity. Depending on the specific architecture, the 
>mobile node 
>>> may gain connectivity directly to the visited network, i.e. 
>close to 
>>> the access, or remotely (e.g. in the home network). To make a 
>>> parallel, in traditional GPRS the connectivity is with the home 
>>> network because the GGSN is located there, whereas some of the 
>>> information servers having knowledge of the information 
>local to the 
>>> access are typically in the visited network. I would consider this 
>>> type of aspects carefully.
>>>
>>> A question for clarification: are you talking about MIHS discovery, 
>>> or network discovery?
>>>
>>> Stefano
>>>
>>> consider the different types of MoS we need to discover, and what 
>>> model we would like to use.
>>> requesting for an IS We were discussing this internally and the 
>>> feeling is that for roaming scenarios DHCP cannot help much in 
>>> discovering IS of roaming partners.
>>> Additionally we should take into account that also network nodes 
>>> might use the IS. Not sure about the use of DHCP in this case.
>>>

---

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 12 Jun 2007 03:04:08 -0700

Sam,

> home network, i don't know why DHCP can not hlep much in discovering
IS. 

[[Stefano] ] I do not agree that most services will be provided in the
visited network. I would agree about IS, but many deployment scenarios
the ES/CS services will be in the home network (i.e. home operator wants
control of inter-technology handoff and related traffic steering).
Therefore, we cannot conclude that in general the services are provided
by the visited network, and therefore DHCP only cannot be the solution.

Stefano

---

From: <[email-masked]>
Date: Tue, 12 Jun 2007 08:38:02 -0500

I agree with Stefano, we need to look at getting ES/CS services 
working from the home network in a roaming scenario. 

>Sent: 12 June, 2007 03:04
>To: Sam Xia; Telemaco Melia; [email-masked]
>> deployed in the access network/visited network, instead of 
>in the home 
>> network, i don't know why DHCP can not hlep much in discovering
>IS. 
>
>[[Stefano] ] I do not agree that most services will be 
>provided in the visited network. I would agree about IS, but 
>many deployment scenarios the ES/CS services will be in the 
>home network (i.e. home operator wants control of 
>inter-technology handoff and related traffic steering).
>Therefore, we cannot conclude that in general the services are 
>provided by the visited network, and therefore DHCP only 
>cannot be the solution.
>
>Stefano
>

---

From: Sam Xia <[email-masked]>
Date: Wed, 13 Jun 2007 10:48:57 +0800

yes, it is possible.  I just can not envision it.

 Best Regards, Sam Xia 

> Sent: Tuesday, June 12, 2007 9:38 PM
> To: [email-masked]; [email-masked]; 
> I agree with Stefano, we need to look at getting ES/CS 
> services working from the home network in a roaming scenario. 
> 
> provided in the 
> >the ES/CS services will be in the home network (i.e. home operator 
> >wants control of inter-technology handoff and related traffic 
> >steering).

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 13 Jun 2007 17:30:38 +0200

John,

I am not sure why we would need to consider L2. Would not this confuse 
people since we are designing a L3 solution?
If you believe it is important could you please elaborate the scenarios 
you had in mind?

tele

[email-masked] wrote:
>>> 2) Visited network (discovery on the local network you are 
>>>       
>> attached to).
>>     
>>>> DHCP would not help in discovering information for a 
>>>>         
>> roaming partner 
>>     
>> ensure enough

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 13 Jun 2007 17:35:14 +0200

Yep I agree too.

[email-masked] wrote:
>>> Maybe. But I am not sure.  Because in most cases the MIHF services
>>>       
>> will be
>>     

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.				Fax: +49 (0) 6221 4342- 155
Network Laboratories			Web: http://www.netlab.nec.de
Kurfuersten-Anlage 36			       
69115 Heidelberg
GERMANY   

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: <[email-masked]>
Date: Wed, 13 Jun 2007 11:32:41 -0500

Stefano pointed out that we might need to be concerned about
L2 roaming, but I don't see the impact yet myself, if the solution
we are looking at is purely L3.

However, thinking about a usage scenario, how does this sound:

1) Outside of home network 
2) Device connects to first L2 network it can
3) Device then creates an IP connection to home network 
4) Device reports what L2 network it is on (potentially informing of
other L2 networks it sees)
5) Home network tells device to change it's L2 network to prefered
roaming partner, for example.

John

>Sent: 13 June, 2007 08:31
>I am not sure why we would need to consider L2. Would not this 
>confuse people since we are designing a L3 solution?
>If you believe it is important could you please elaborate the 
>scenarios you had in mind?
>
>tele
>
>>>>> However, I would like to discuss the possibility to apply 
>the same 
>>>>> model
>>>>>

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 13 Jun 2007 19:09:15 +0200

I see.
What we should then support as part of the  network controlled handover 
is steering of roaming.
Inter or intra technology?

tele

[email-masked] wrote:
>>> 2) L2 connected to visited network, L3 connected to home 
>>>       
>> network (3GPP 
>>     
>>> roaming case)
>>>>> scalable solution, however if 2B is not supported, I guess 
>>>>>           
>> we could 
>>     
>>>>>> I was thinking of use cases and I have a question. I may 
>>>>>>             
>> agree that 
>>     
>>>>>> server (DHCP, etc.), the mobile node must have IP 
>>>>>>             
>> connectivity with 
>>     
>>>>>> access are typically in the visited network. I would 
>>>>>>             
>> consider this 
>>     
>> discovery, 
>>>>>> I can see two different ways of working: PULL model and 
>>>>>>             
>> PUSH model.
>>

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 13 Jun 2007 13:02:22 -0700

Steering or roaming is nothing more or less than network selection,
would you agree? So the answer would be yes, this can be one of the use
cases in theory, though I am not so convinced about this use case being
realistic (e.g. it would never fly in fora like 3GPP).
Definitely inter!
Stefano

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 10:09 AM
To: [email-masked]
Cc: Stefano Faccin; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Discovery thread

I see.

tele

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 13 Jun 2007 13:04:38 -0700

That was meant to say "steering of roaming". Sorry, I'm typing on my
not-so friendly "fruit" cell phone keyboard. Waiting to get my iPhone
...
Stefano

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 10:09 AM
To: [email-masked]
Cc: Stefano Faccin; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Discovery thread

I see.

tele

---

From: <[email-masked]>
Date: Wed, 13 Jun 2007 15:27:06 -0500

Stefano,

I agree with the 3GPP case, but I guess it can also be used for WLAN
selection as well.
If you see multiple WLANs, you might get advised which one to select.

Do you see this as in scope for .21?

John 

>Sent: 13 June, 2007 13:05
>To: Stefano Faccin; Telemaco Melia; Loughney John (Nokia-NRC/PaloAlto)
>That was meant to say "steering of roaming". Sorry, I'm typing 
>on my not-so friendly "fruit" cell phone keyboard. Waiting to 
>get my iPhone ...
>Stefano
>
>Steering or roaming is nothing more or less than network 
>selection, would you agree? So the answer would be yes, this 
>can be one of the use cases in theory, though I am not so 
>convinced about this use case being realistic (e.g. it would 
>never fly in fora like 3GPP).
>Definitely inter!
>Stefano
>
>What we should then support as part of the  network controlled 
>handover is steering of roaming.
>> L2 roaming, but I don't see the impact yet myself, if the 
>solution we 
>> are looking at is purely L3.
>>
>>>> Do we also need to consider L2?  I think the plausable 
>scenarios we 
>>>> have
>>>> are:
>>>>
>NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
>Road, London W3 6BL | Registered in England 2832014 
>
>

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 13 Jun 2007 13:51:51 -0700

Yes, I would agree it is.
Stefano

From: [email-masked] [mailto:[email-masked]]
Sent: Wed 6/13/2007 1:27 PM
To: Stefano Faccin; [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Discovery thread

Stefano,

John

>Network Laboratories                   Web: http://www.netlab.nec.de <http://www.netlab.nec.de/> 
>Kurfuersten-Anlage 36                        
>69115 Heidelberg
>GERMANY  
>

---

From: Subir Das <[email-masked]>
Date: Wed, 20 Jun 2007 14:17:00 -0400

John,
This is definitely a valid scenario for handover, definitely not 
desirable at the
initial attachment. However, I do not see any impact on discovery here.

-Subir