Hi Sri, > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] > Sent: Monday, September 15, 2014 3:32 PM > To: Templin, Fred L; Jouni Korhonen; sarik...@ieee.org > Cc: Dapeng Liu; dmm@ietf.org > Subject: Re: [DMM] DMM Interim call #2 - agenda forming > > Hi Fred, > > Thanks for your response. > > > 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. > > > Lets focus on the Route Optimization. If you can share some views on how > the above model is better compared to the below standardized approaches, > it will really help. > > To your comment on feature gaps, I will try to compile a list and send it > out. I also owe you a response on the thread related to Sataru-san's draft. > > > > In MIP architectures, we have Route optimization support in two modes: > > 1.) Client-based > > - Signaling is based on MIPv6; (http://tools.ietf.org/html/rfc6275#page-25 > ) > - User-plane RO management based on Type-2 Routing > header;(http://tools.ietf.org/html/rfc6275#page-55) > - Scope is global > - Requires Mobile IPv6 software functionality
AERO route optimization is quite different than this. AERO route optimization is based on a chain-of-trust whereby the RO requests and replys always come from the Client's trusted Server instead of an untrusted node. AERO RO is unidirectional - to set up a bidirectional RO requires two unidirectional ROs. These can happen simultaneously or separately, and in some cases it may even be preferable to have only one of the two directions optimized. In the process of setting up the RO, the Clients also come to know the permissible encapsulation IP address or addresses for the encapsulated address. So, the RO also provides a simple data origin authentication capability. > 2.) Network-based > > - Signaling is based on PMIPv6; (http://tools.ietf.org/html/rfc6705#page-8) > - User plane is based on direct tunneling > - Scope is localized PMIP domain > - Works with any mobile node with no additional software capabilities This looks very close to the way AERO handles RO in the network based case. In this case, the AERO Client is analogous to the PMIPv6 MAG, and the RO can go MN1<->Client1<->Client2<->MN2. One of the key differences again is that the AERO NBMA virtual link does not require any explicit tunnel configurations. So, tunneling between Client1<->Client2 is guided by neighbor cache information on the NBMA link. Thanks - Fred fred.l.temp...@boeing.com > Regards > Sri > > > > > > > > > On 9/15/14 8:43 AM, "Templin, Fred L" <fred.l.temp...@boeing.com> wrote: > > >Hi Sri, > > > >> -----Original Message----- > >> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] > >> Sent: Friday, September 12, 2014 7:02 PM > >> To: Templin, Fred L; Jouni Korhonen; sarik...@ieee.org > >> Cc: Dapeng Liu; dmm@ietf.org > >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming > >> > >> Hi Fred, > >> > >> > >> On 9/12/14 8:17 AM, "Templin, Fred L" <fred.l.temp...@boeing.com> 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 > >fred.l.temp...@boeing.com > > > >> Regards > >> Sri > >> > >> > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
