Subject: [DMM] Coordination of mobility solutions

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Sep 2014 18:53:08 +0300

As promised, let me enumerate the "protocol" worked involved for solutions aimed at "discovery, selection, and coordinated execution of mobility protocols at multiple layers". 

- Discovering network's mobility capabilities:

Whether it supports PMIP, LISP,  etc.
Possible approach is to define new DHCP options to deliver this "network info" to the terminal.

- Discovering corresponding node's mobility capabilities:

Whether it supports MPTCP, MIP route optimization, etc.
Possible approach is to use DNS-based discovery.

Discovering the MN's own mobility capabilities does not involve any protocol work. It may be based on platform-specific methods, API, application profiling, etc.

How the terminal selects the mobility protocol(s) to apply to a given flow, and how it coordinates execution of them are materials for an "informational" document that'd also refer to the aforementioned discovery elements.

Like Danny was suggesting, we can tackle this in the working team that deals with the source address selection, as there's an interaction  between the two. Whether a flow needs a fixed or sustained or nomadic IP address is influenced by whether the application traffic would need IP-layer mobility or not.

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 19 Sep 2014 19:35:35 +0000

Hi Alper,

Please see inline.

On 9/19/14 8:53 AM, "Alper Yegin" <[email-masked]> wrote:

>As promised, let me enumerate the "protocol" worked involved for
>solutions aimed at "discovery, selection, and coordinated execution of
>mobility protocols at multiple layers".
>

Agree. If you can identify the client behavior and as how this information
is used by the client will really help.

>Possible approach is to use DNS-based discovery.

During SIPTO (RFC6909) standardization, there was a IESG DISCUSS on this.
The concern was that the network is offloading some traffic without the
client being notified. May be this approach of enabling the client with
such details will eliminate that concern. The key point is on the details
on how the client leverages this network information will really help
justify the work.

Regards
Sri

>
>Discovering the MN's own mobility capabilities does not involve any
>protocol work. It may be based on platform-specific methods, API,
>application profiling, etc.
>
>How the terminal selects the mobility protocol(s) to apply to a given
>flow, and how it coordinates execution of them are materials for an
>"informational" document that'd also refer to the aforementioned
>discovery elements.
>
>Like Danny was suggesting, we can tackle this in the working team that
>deals with the source address selection, as there's an interaction
>between the two. Whether a flow needs a fixed or sustained or nomadic IP
>address is influenced by whether the application traffic would need
>IP-layer mobility or not.
>
>Alper
>
>
>
>
>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 Sep 2014 18:53:08 +0000

Hi Alper,

Sorry for the delayed response:

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
> Sent: Friday, September 19, 2014 8:53 AM
> To: [email-masked]
> Subject: [DMM] Coordination of mobility solutions
> 
> As promised, let me enumerate the "protocol" worked involved for solutions aimed at "discovery,
> selection, and coordinated execution of mobility protocols at multiple layers".
> 

Another approach is DNS. For example, nodes can discover whether the
network supports AERO by resolving the FQDN "linkupnetworks.domainname".
 
> Possible approach is to use DNS-based discovery.

With AERO, it might be easier to just test the assumption that
the correspondent participates in the service and then make
other arrangements if it does not.

> Discovering the MN's own mobility capabilities does not involve any protocol work. It may be based on
> platform-specific methods, API, application profiling, etc.

OK.

> How the terminal selects the mobility protocol(s) to apply to a given flow, and how it coordinates
> execution of them are materials for an "informational" document that'd also refer to the
> aforementioned discovery elements.
>
> Like Danny was suggesting, we can tackle this in the working team that deals with the source address
> selection, as there's an interaction  between the two. Whether a flow needs a fixed or sustained or
> nomadic IP address is influenced by whether the application traffic would need IP-layer mobility or
> not.

It seems like some flows would need to go through the home network
using a stable home network address while others should go through
the visited network using an address specific to the access network.
And somehow, the mobile needs to keep the home and visited domains
separate.

Don't some systems already do that? Or, am I missing the point?

Thanks - Fred
[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Sat, 27 Sep 2014 15:26:28 +0300

Hi Fred,

> network supports AERO by resolving the FQDN "linkupnetworks.domainname".

Yes, that's possible too.

> other arrangements if it does not.

Trial-and-error, when fails, would create additional latency getting in the way of starting the e2e communications.

> And somehow, the mobile needs to keep the home and visited domains

Yes.

> Don't some systems already do that? Or, am I missing the point?

The closest I can think of is:  3GPP systems using, say IMS APN and Internet APN, where the Internet APN uses SIPTO at the local network.
Do you have this, or something else in mind?

Alper

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 29 Sep 2014 15:44:09 +0000

Hi Alper,

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Saturday, September 27, 2014 5:26 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [DMM] Coordination of mobility solutions
> 
> Hi Fred,
> 

OK. While not a mobility solution, ISATAP has been doing that for over
a decade now. ISATAP and AERO both use an NBMA tunnel virtual interface
model, and FQDN resolution is the most frequently used means of discovery
supported in both cases. (Other means such as DHCP option are also
possible, but less frequently used.)

> Trial-and-error, when fails, would create additional latency getting in the way of starting the e2e

OK. In terms of discovery of whether a potential correspondent supports
route optimization, DNS resolution is certainly possible by resolving a
FQDN based on the prospective correspondent's IPv6 prefix. For example,
if the IPv6 destination address is 2001:db8:1:2::1 then the source can
resolve the FQDN:

'2.0.0.0.1.0.0.0.8.d.b.0.1.0.0.2.linkupnetworks.com'

If name resolution succeeds, then the source has assurance that the
destination is behind a mobile router that supports route optimization.
This means that the owner of the FQDN "linkupnetworks.com" would need
to add resource records for all AERO Service Prefixes (ASPs) from
which individual AERO Client Prefixes (ACPs) are taken.

I first described this in Section 6.4 of VET:

http://www.ietf.org/archive/id/draft-templin-intarea-vet-40.txt

> Do you have this, or something else in mind?

I don't have much to offer on this subject at the moment, but interested
to learn more.

Thanks - Fred