Deployment of Control-/Data-Plane separation in DMM

The Distributed Mobility Management (DMM) working group is currently investigating solutions, which are based on the separation of mobility management functions' Control- and Data-Plane. The network functions in charge of the mobility control are separated from the data plane nodes, responsible mainly for, but not limited to, data packet forwarding. In this scenario, it is possible to design different mechanisms for the interaction between the mobility control function and the data plane nodes. One of these mechanisms devises a Software Defined Networking (SDN) abstraction layer between control and data planes, embodied by an SDN Network Controller (NC). The NC enforces instructions from different mobility control functions, which operate on top of a Network Controller and hold the mobility states, to Data-Plane nodes (DPNs), such as switches or routers, within a defined network scope. DPNs in different networks may be controlled by physically separated NCs. The NC configures Data-Plane nodes with forwarding and policy enforcement related rules, either with the accuracy of a single data flow or as aggregated rule, such as for an IP address prefix. An example of a Control-Plane function is the Control-Plane of a Local Mobility Anchor (LMA-C) as per the Proxy Mobile IPv6 (PMIPv6) architecture or a Packet Data Network (PDN) Gateway's Control-Plane functions as per the 3rd Generation Partnership Project's architecture for cellular mobile communications. These functions perform protocol operation with remote Control-Plane functions for mobility management, e.g. the Control-Plane of a Mobile Access Gateway (MAG) as per the PMIPv6 protocol. Control-Plane functions associated with mobility management need to interact with the NC to enforce forwarding and policy rules in the Data-Plane. By taking again the PMIPv6 architecture as an example, the Data-Plane nodes have the role of the Data-Plane functions within an LMA or MAG. This document discusses various deployment options for mobility management in a Control-/Data-Plane separated setup utilizing SDN and how results of the chartered work about Forwarding Policy Control (FPC) can be used in such setup. The diagrams and descriptions as per this document are meant for discussion and consideration in the DMM working group's chartered item about DMM deployment options. The WG document specifies an abstraction and information model for DMM control and data plane separation. The specified functional architecture comprises a Client function, which is associated with the mobility management Control-Plane, and an Agent function, which is associated with Data-Plane configuration. Client and Agent interact with each other as per the specification in to enforce forwarding and policy rules from the mobility management Control-Plane in the Data-Plane. Such rules comprise, for example, forwarding of defined traffic through a GRE tunnel to a remote Data-Plane node while the traffic should experience prioritization as per a defined Quality-of-Service class. Such interaction is illustrated in

In the present document we describe a base reference model from , to then propose some sub-scenarios of interest for practical deployment. In the base reference model, as depicted in , the Control-/Data-Plane interaction is performed through an NC that exhibits a southbound interface (SBI), e.g. the OpenFlow protocol, to configure DPNs, and exposes a northbound interface (NBI) towards mobility management Control-Plane functions utilizing the Client and Agent functions as well as the abstraction and configuration model as per . This enables the mobility management Control-Plane using the NC's NBI to enforce rules and policies in the Data-Plane, which are relevant for the Control-Plane's operation, without the need to be aware of a Data-Plane node's configuration details and whether the Data-Plane node is a switch or a router. An SDN-based Control- and Data-plane separation for DMM has been proposed also in . In such draft the mobility function is co-located with the SDN Network Controller. By doing so, the mobility protocol is highly coupled with the NC and the SBI interface. The present draft extends by introducing the use of an NBI as an additional abstraction layer. In this way the architecture gains in flexibility as the mobility function is independent from the specific SBI and NC used. The NBI hides Data-Plane configuration details from Control-Plane functions and is represented by a protocol implementation as per .

The flexibility introduced by splitting the Control-/Data-Plane reference point into two different interfaces, namely the NBI and the SBI, may lead to practical limitations for a single network controller to handle the whole set of data plane nodes. As a consequence, when multiple NCs are to be deployed, different scenarios arise with different characteristics. This documents explores three possible deployment scenarios.

A single network controller may lead to practical limitations when it comes to handle the operations in large network, like scalability issues and protocol promptness. The mobility management protocol should execute quickly in order to guarantee optimal service to users. For this reason the network controller should not be too distant from the DPNs. Therefore, a network administrator might deploy multiple NCs, each responsible for a network sub-domain or site. By deploying multiple NCs, the Control-/Data-Plane reference model as depicted in suffers some variations as described in the following subsections.

In this scenario the NCs from different sites are directly interacting with the mobility control function by means of the NBI interface. The mobility control function possesses a holistic view of the network domain and propagates the instruction to the NCs accordingly. The mobility control function, which is associated with the Client function as per , connects to two Agent functions, each associated with one NC. This scenario is illustrated in .

In this scenario, the mobility control Client function interacts with a single Agent co-located with one NC, which in turns propagates the configuration through an east-west interface (EWI) to other NCs. This scenario is illustrated in .

In this scenario, each NC interacts through an Agent with a dedicated instance of the mobility function Client. It is then up to the different mobility control entities to coordinate the operations among different sites. This scenario is illustrated in .