Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:[email protected]] > Sent: Saturday, September 27, 2014 5:26 AM > To: Templin, Fred L > Cc: [email protected] > 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 [email protected] > Alper > > > > > > Thanks - Fred > > [email protected] > > > >> Alper > >> > >> > >> > >> > >> _______________________________________________ > >> dmm mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
