Hi Sri, > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Friday, September 12, 2014 7:02 PM > To: Templin, Fred L; Jouni Korhonen; [email protected] > Cc: Dapeng Liu; [email protected] > Subject: Re: [DMM] DMM Interim call #2 - agenda forming > > Hi Fred, > > > On 9/12/14 8:17 AM, "Templin, Fred L" <[email protected]> wrote: > > >> > >>Based on these points #3 and #9, can we conclude that we cannot apply > >>AERO > >>for DMM ? If not, how do we apply and deploy Aero for DMM networks ? > > > >I don't think so. Surely we can do proxy AERO, and surely iOS > >phones can do VPN. So, pick one or both of these alternatives > >and I think the concern is addressed? > > > If the latest releases of iOS has support for tunnel interface and route > management, I'll be happy to know the specifics. For a minute, lets go > with that assumption we can realize Aero client on iOS.
iOS supports the TUN half of the TUN/TAP interface. OpenVPN uses the TUN interface, and runs on iOS. AERO assumes OpenVPN as its target integration platform, and requires no kernel changes nor any kernel routing table nor neighbor cache manipulations. AERO can therefore go anywhere OpenVPN can go, including iOS. > That immediately > makes the solution relevant (assuming it supports other basic > capabilities) to a class of solutions that are client-based and not > network-based. My "day in the life" thread shows a use case for a client-based solution. > As I said earlier, the MIP community has failed to realize > client eco-system and any proposals that are client-based have limited > value. Client-based solutions are necessary for the enterprise mobility use case, as expressed in "day in the life" as well as: https://datatracker.ietf.org/doc/draft-templin-aeroent/ > Lets talk about RO for an IP flow between a host and an application > server in some SP's data center. AERO supports RO for two peers that both participate in the same AERO service domain. It is not for peers that participate in different AERO service domains, nor when one peer is AERO and the other is non-AERO. > The probability that the peer supports RO > capabilities defined by a protocol are close to zero. MIPv6 has RO in the > form of IPv6 Type-2 routing header, defined as part of baseline IPv6 AERO requires no kernel changes nor any special IPv6 headers. > specs, but still the MIP community almost gave up on client-based > solutions. This is one data point. AERO route optimization is different. AERO route optimization manipulates the neighbor cache (usually an application-based neighbor cache and not a kernel-resident one) based on IPv6 ND messaging. Client AERO addresses are used to key the neighbor cache entries. > I understand, Aero can be extended to support a Proxy function. But, will > it not look exactly like Proxy Mobile IP ? I'm looking for fundamental > properties which are unique to Aero and that PMIP/MIPv6 lacks ? The AERO proxy messaging would be based on DHCPv6 request/release. I will put this in the next draft version since, as you said, the framework is similar to PMIP. In the AERO model, the AERO Client is analogous to the PMIP MAG and the AERO Server is analogous to the PMIP LMA. However, AERO uses an NBMA tunnel virtual link model that connects all Client and Servers instead of point-to-point tunnels. It also uses neighbor cache entries based on the Client's AERO address(es) instead of explicit tunnel state. Most importantly, it does not matter which Server the Client associates because the mobile node's home network prefixes are not bound to the Server -they are bound to AERO Relays instead. > Instead of the approach, "Aero may be extended to do it", what is that one > capability that Aero offers and that the current mobility protocols lack ? AERO can be applied at multiple levels, both as a network-based proxy system and as a Client-based end system. Consider an AERO Client that is based in a home enterprise network and is currently using its 4G interface. The Client would use one instance of AERO to coordinate with its home network, while the 4G network would use its own instance of AERO to provide the Client with network-based mobility management services within the cellular provider network. AERO can therefore be applied recursively. Consider also a "nested NEMO" situation in which a first mobile router provides an access link to a second mobile router, the second mobile router provides an access link to a third mobile router, the third mobile router ... etc. In such a scenario, a separate AERO instance could be applied at each level. There is still more (including distributed mobility management, route optimization, etc.) that AERO handles easily where the other approaches may not handle so easily. > One line of thinking could be to integrate such unique ideas, if any, to > protocols that are feature rich and were defined before, standardized, > integrated in SDO architectures and has a deployment base. To name one thing, the tunnel virtual link model is a point of departure and I think an area where AERO provides a better model especially for handling route optimization and distributed mobility management. > Aero uses DHCP/ND as a signaling interface, instead of dedicated signaling > interface, and uses tunnels to setup the overlay routing path. For RO, it > uses ICMP, where as MIP uses special messages HoTi/CoTi (please ask > Charlie why they chose those terms :)). OK. > Furthermore, it misses all the > features that the other protocols already can support. You lost me there. What features? And could they not be used on AERO the same as they are used with the other protocols? Thanks - Fred [email protected] > Regards > Sri > > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
