Re: Preparing for DMM future steps and rechartering

Hi, Sri,

I think you will agree that PMIP is a control protocol for setting up
tunnels.  A tunnel implies that we are not using the destination IP
of the inner packet for routing and by definition will lead to a non-optimal
route and a bit of state on some box that can fail and lose that state.

I hope that DMM can consider other approaches such as injecting routes
from the latest L2-attachment point into the access network, which is
a truly Distributed Mobility Management protocol for getting the packets
to the mobile node.  It will lead to more optimal routes and more robust
fault-tolerant operation of the network.

I think we can continue to use the term MAG to apply to that first-hop
router which is hopefully co-located with the L2 termination point (it
may not be so in every technology depending on the extent to which that
technology has evolved to support truly Distributed operation).  Anything
that happens below the MAG (between the MAG and the L2 termination point)
should be out of scope and we should not define any protocol there and we
should discourage any separation between the two.

However, we should not require the MAG to run any form of PMIP because 
tunnels should not be required in the architecture.  We should not require
an LMA, because this would imply a central point of state maintenance and
possibility of failure.

It is fine to consider a split between CP and DP but I thought we had agreed
that any discussion of the protocol to use on such an interface would be
out of scope for this WG.  IMHO we should leave that to the Wireless & Mobile
Working Group of ONF.

Now, the proponents of OpenFlow and other CP/DP splits have argued that it is
better to centralize the algorithms such as routing protocols on a logically
centralized server or servers with a synchronized global view of the network.
I have no problem with that, in which case this centralized controller just 
needs to get notified about the MN's current attachment point, so it can install
the routes (or tunnels, if an operator wishes to use them) into the DP.  But,
the mechanisms for doing so are out of scope for the DMM WG because we are not
working on a CP/DP split.  I think it would be appropriate for the DMM WG (which
exists in the IETF, a standards body that has a long history of developing 
distributed and fault-tolerant routing protocols) to describe a more distributed 
alternative, building on foundational Internet technologies such as I-BGP, in
such a way that will bring down the costs, reduce the latency, and increase the
robustness of wireless access networks.

I actually don't think we need to define any new extensions or IEs for BGP; I
would like to read more about Ryuji's proposed extensions here.  All we need is
for the MAG to learn what IPs have been assigned to the MN, decide which of those
IPs are in the scope of the local AS, and inject routes for those prefixes to
itself.  We could work on alternative mechanisms for discovering this list of
addresses - the fundamental requirement is that we use an authenticated MN ID
(probably an NAI) as an index to lookup the set of IPs in a distributed database.
I've proposed using DNS for this but there are other alternatives.  We also need
a way to make sure the latest UPDATE gets used by all the BGP peers.  I've proposed
putting a timestamp in LOCAL_PREF but there are probably other alternatives.

It would also be nice to have a well-defined fall-back mechanism in case the MN
moves to a different AS or just too far from the original MAG, in which case the
I-BGP approach wouldn't scale.  For these cases, I think a client MIP tunnel to
an HA located in the original AS for each assigned IP address would be ideal.
The HA can behave just like the MAGs in that domain, injecting routes when MNs
establish tunnels to it so as to attract the packets to themselves (this would
be the routing equivalent of the proxy-ARP or proxy-ND mechanism that works on
just a single home link in MIPv4 or MIPv6).  We should work on mechanisms to enable
dynamic assignment of local HAs to MNs and dynamic establishment of security associations
that don't require AAA and associated round-trips to the home network.  Because the HA
is associated with the original MAG that assigned the address, this may involve
some DHCP extensions.  There is already a way to assign the HA IP address but we
will need new extensions to carry the HA credentials to the MN (maybe just an HA DNS
name so the MN can use DANE to retrieve a public key).

I think something like the path I've outlined above would make a good work plan
for the future of DMM.

-Pete




Sri Gundavelli (sgundave) wrote:
> Hi Pete,
> 
> The "D" in DMM to me is "Distributed Data Plane". Your observation on
> my antithetical approach towards "D" is true for control plane. As
> that is not aligned with the current industry direction. When the CP
> is distributed, the cost of the network goes up 10-fold. Running
> policy interfaces to every distributed node is a operational
> nightmare. We bring the CP together for orchestration and enabling
> SDN. We distribute the DP for simplifying the forwarding plane and for
> realizing an optimized routing plane. I assumed you are OK with this.
> 
>> Also, we should not require the MAG to run PMIP.
> 
> 
> I think there is a slight disconnect here. I suspect you want a CP/DP
> based access architecture. But, you want a OpenFlow interface between
> the CP and DP nodes, or may be piggyback the routing protocols along
> the lines of Ryuji's view. My proposal is not about mandating PMIP
> between CP and DP, but rather PMIP stays in the control plane between
> a MAG and LMA, but between MAG-CP and MAG-DP, it can be any interface.
> Between a MAG-CP and a MAG-DP, this could be CAPWAP for WLAN, OpenFlow
> in some other access, some other approach or routing approach. From
> this WG point of view, we can define high-level messaging
> structure/IE's and map them to the respective protocols. This is
> consistent with my approach for CAPWAP Split, or PMIP split approaches.
> Does this work for you ?
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> On 11/10/13 11:27 AM, "Peter McCann" <[email protected]> wrote:
> 
>> Hi, Sri,
>> 
>> I think the chain of gateways you have listed is exactly the source
>> of the problem we are trying to solve, and are antithetical to the D
>> in DMM.
>> 
>> Perhaps we should stick with the term MAG, since that is what we use in
>> the IETF mobility work, and agree not to talk about what happens
>> between the L2-termination point and the MAG.  In my opinion the MAG
>> should be co-located on the L2-termination point and that is the model
>> I am mentally using.
>> 
>> Also, we should not require the MAG to run PMIP.  There have been 2
>> proposals to inject routes from the attachment point instead of
>> initiating tunnels and I think those should be in-scope.
>> 
>> -Pete