Hi Sri, > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Wednesday, September 17, 2014 5:47 PM > To: Templin, Fred L > Cc: [email protected] > Subject: Re: [DMM] DMM Interim call #2 - agenda forming > > 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 AERO NBMA virtual link mode applies to any tunnel type (UDP, GRE, IP-in-IP, GTP (I guess), etc.). > 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 ? Right, there is no difference in the way the tunneled packets appear as bits-over-the-wire. The difference is that the AERO NBMA virtual link model allows for L2 address resolution via IPv6 ND messaging the same as on any IP interface. > > 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. Let me think about this. > Again, I've my views against using any client-based solutions for RO > solutions. AERO RO is initiated by the source Client and directed toward the target Client. When the source Client sends packets destined for a target Client, the source also sends a RO message. Both the data packets and the RO message are sent via a routing chain. In the PMIPv6 deployment model, it would go as: MAG1 -> LMA1 -> (some forwarding agent) -> LMA2 -> MAG2 After the RO, subsequent communications would go directly as: MAG1 -> MAG2 But, it is important to note that AERO generalizes to any mobility scenario, and not just the PMIP deployment model. For AERO RO, mobile Clients may have no way of trusting each other without involving some chain of trust as provided by the AERO Servers and Relays. Thanks - Fred [email protected] > Regards > Sri > > > > > On 9/15/14 4:02 PM, "Templin, Fred L" <[email protected]> wrote: > > >Hi Sri, > > > >> -----Original Message----- > >> From: Sri Gundavelli (sgundave) [mailto:[email protected]] > >> Sent: Monday, September 15, 2014 3:32 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, > >> > >> 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 [email protected] https://www.ietf.org/mailman/listinfo/dmm
