Hi Fred,
>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. There is no explicit tunnel configuration in any of the mobility architectures. The tunnel state creation is dynamic and is created based on the events from the signaling functions. The tunnel is a standard L3 tunnel with standard encapsulation methods such as GRE, IP-in-IP and UDP. I'm trying to understand the advantages of this NBMA virtual link. I assumed the encapsulation is a standard encapsulation such as with UDP. The specific rules for selection of the IP traffic for tunneling, or tunnel header selection is a more implementation specific aspect. One can create a tunnel between two points A and B and apply a policy route, which state all traffic from MAc-1/IP-1 needs to be encapsulated with tunnel header A-B. If I'm monitoring the link of a tunneled traffic, I would not know the difference between traffic tunneled from a NBMA virtual link and a tunneled traffic with dynamically created tunnels. How we realize tunneling is internal to the operating system and has no bearing on the interoperability ?. Do you agree with this ? > 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. Ok. In MIPv6 RO scheme the MN's trusted entity is the home agent and it provides the frame work for a CN to trust the MN's relation/association with its home address (anchored on HA) and its care-of address (direct route). The approach does not require both the peers to have a mobility anchor, but the Return Routability test procedure assures any correspondent node to trust the HoA to CoA relation and use direct routing paths. I'm not sure how one approach is better over the other. Again, I've my views against using any client-based solutions for RO solutions. Regards Sri On 9/15/14 4:02 PM, "Templin, Fred L" <fred.l.temp...@boeing.com> wrote: >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. > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
