Re: [DMM] Coordination of mobility solutions

["Templin, Fred L" <[e-mail]>]

Hi Alper,

> -----Original Message-----
> From: Alper Yegin [mailto:[e-mail]]
> Sent: Saturday, September 27, 2014 5:26 AM
> To: Templin, Fred L
> Cc: [e-mail]
> Subject: Re: [DMM] Coordination of mobility solutions
> 
> Hi Fred,
> 
> >> 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.
> >
> > Another approach is DNS. For example, nodes can discover whether the
> > network supports AERO by resolving the FQDN "linkupnetworks.domainname".
> >
> 
> Yes, that's possible too.

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

> >> - Discovering corresponding node's mobility capabilities:
> >>
> >> Whether it supports MPTCP, MIP route optimization, etc.
> >> 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.
> >
> 
> Trial-and-error, when fails, would create additional latency getting in the way of starting the e2e
> communications.

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

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

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

Thanks - Fred
[e-mail]

> Alper
> 
> 
> 
> 
> > Thanks - Fred
> > [e-mail]
> >
> >> Alper
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dmm