It all started as a basic idea of allowing a host with its statically configured IP address to be reachable at the same IP address when moving to a new point of attachment. Thus, there was RFC2002 for IP Mobility. At the time there was no concern of the different applications running on the laptop or the host as there was not many applications anyway or if there were, they all shared similar requirements for quality of services.

With the realization of the very limited number of IPv4 addressing, there was the notion of allowing the host to be reachable at different point of attachment while being dynamically allocated the same IPv4 address. The dice started rolling with many different features for Mobile IPv4 and Mobile IPv6. Despite all the enhancements and changes to allow multiple care-of addresses [RFC-5648], Mobile Router Support [RFC-5177], Hierarchical Mobile IPv6 [RFC-5380], Network-Based Mobility in v6 and v4 flavors [RFC5213, RFC-5563], etc., there always was one fundamental aspect that never changed. The mobility aspect was always controlled via the network layer without interference from the application layer [Remember: All applications were treated as the same from the network layer point of view]. Thus, all applications running on the same host use the same reachability, i.e., the same IP address and consequently the same IP anchor, e.g., home agent.

As everything around us started to move to all-IP based networking including time-sensitive applications, restricting the IP mobility management to the network layer without the knowledge of the specific needs of the different applications which are using the underlined transport pipe becomes problematic.

In other words, if a host or a mobile device has a VoIP application, a Video Conferencing application, an http session, and email running at the same time, then anchoring all of these applications traffics at a single node in the network (e.g., home agent) becomes overkill. It would probably work without noticeable problem with the http and email sessions but may cause some unacceptable delay which may cause a reduced level of Quality of Experience (QoE) by the end user. In addition, the http and email session may not require an IP address that is mobile across different access network points of attachment. In other words, most probably no noticeable degradation in the QoE will occur if such applications traffic is always anchored at the access gateway with the possibility of having a different IP address allocated whenever the point of attachment is changed, for example. That for sure can NOT be afforded for a time-sensitive application like VoIP or Video Conferencing.

This introduced the whole idea of how to provide IP Mobility at the network layer while taking on consideration the type of application that is using this transport pipe. In other words, how to make sure that the transport pipe being established satisfies the mobility requirement of the application that is using it. Thus, the concept of Distributed Mobility Management which more accurately was later defined within IETF as Dynamic Mobility Management or DMM. To be followed.