# A Comprehensive Survey on Knowledge-Defined Networking
## 7 Application Plane
### Architecture of the Application Plane  
The architecture of the application plane and its interface with other planes [438] are given in Figure 11.  
As evident from Figure 11, there are basically two sub-planes--the intent/policy definition sub-plane and the intent/policy update sub-plane--in the application plane. Note that the policy/intent definition sub-plane is enclosed within the policy/intent update sub-plane. The purpose of the intent/policy definition sub-plane is to define policies and intents using network administrators. Once intents and policies are defined, they can be dynamically updated using the intent/policy update sub-plane using the rules/knowledge received from the knowledge plane, the configurations received from the management plane, and the network topology and statistics received from the control plane. Thus, application policies and intents can be dynamically updated when the network state changes. Note that, in the intent/policy update plane, there is a rule engine to infer from knowledge/rules and other data received from other planes to produce decisions or instructions to update the policies. As evident from Figure 11, both of these sub-planes  
Figure 11: Architecture of the application plane, with different flows exchanged with other planes.  
enclose a set of applications. Note that some applications can be abstracted into a generic application category. Thus, policies can be specified such that the base policies of the base application are inherited by the derived (specific) applications. For instance, routing, load balancing, and QoS provisioning can be abstracted into one traffic engineering base class application. Therefore, an application policy defined for the traffic engineering base application such as \"The normalized network congestion must be maintained below 50%\" is inherited by all the specific traffic engineering applications such as routing, load balancing, and QoS provisioning, and it is not required to redefine the same policy in those applications. However, each specific application inherited by a base application class may have its own unique policies. For instance, the QoS provisioning application may have a policy to \"Give priority to video data\", which is not applicable to routing or load balancing applications.  
Note that the application plane communicates with the knowledge, control, and management planes with the help of a northbound API and a network service abstraction layer. As reviewed in Section 5, the northbound API can be an interface from a network operating system, a RESTful-API, an intent-based API, or a high-level programming language. This northbound interface directly interfaces with the network service abstraction layer, which abstracts all network services and acts as the interface to communicate application requirements to other planes and convey data, knowledge/rules from management, control, and knowledge planes to the application plane. As shown in Figure 11, descriptive knowledge/rules, network topology and network statistics, and configurations flow from the knowledge, control, and management planes, respectively. In the other direction, from the application plane, intents flow to the knowledge plane, and policies flow to the management and control planes.