Subject: [Actn] ACTN architecture/framework

From: Leeyoung <[email-masked]>
Date: Wed, 13 Aug 2014 16:57:03 +0000

Hi,

One of the action items from the BoF was to define an architecture framework for ACTN. I think we can start based on the current framework document. http://tools.ietf.org/html/draft-ceccarelli-actn-framework-02

>From the framework, the term VNC (Virtual Network Controller) was defined to denote a control function for multi-domain virtual network coordination and operation to give a global view and control of operator's multi-domain transport networks.  PNC (Physical Network Controller) was defined to denote a domain control of different kinds (e.g., EMS/NMS, Control Plane like GMPLS/ASON, or PCE based, etc.). Each PNC is responsible for its domain's control and operation such as provisioning, path computation, etc.

Here's how the VNC and PNC functionality is captured from the framework draft.

The virtual network controller is composed by the following functional components:

+------------------------------------------------------------------+

|                                                                  |

| Virtual     +-------------+        +------------------------+    |

| Network     | VNS Proxy   |        | Abstract Topology DB   |    |

| Controller  +-------------+        +------------------------+    |

|                                                                  |

| +-------------------+  +-------------------+   +---------------+ |

| | Resource Manager  |  | vConnection Agent |   |VNC OAM handler| |

| +-------------------+  +-------------------+   +---------------+ |
          +------------------------------------------------------------------+

*         VNS proxy: The VNS proxy is the functional module in charge of performing policy management and AAA (Authentication, authorization, and accounting) functions. It is the one that receives that VN instantiation and resource allocation requests from the Customer controllers.

*         Abstract Topology DB: This is the database where the abstract topology, generated by the VNC or received from the PNC, is stored. A different VN instance is kept for every different customer.

*         Resource Manager: The resource manager is in charge of receiving VNS instantiation requests from the customer controller and, as a consequence, triggering a concurrent path computation request to the PCE in the PNC based on the traffic matrix. The Resource manager is also in charge of generating the abstract topology for the customer.

*         vConnection Agent: This module is in charge of mapping VN setup commands into network provisioning requests to the PNC.

*         VNC OAM handler: The VNC OAM handler is the module that is in charge of understanding how the network is operating, detecting faults and reacting to problems related to the abstract topology.

The physical network controller is the one in charge of configuring the network elements, monitoring the physical topology of the network and passing it, either raw or abstracted, to the VNC.
It is composed by the following functional components:

+------------------------------------------------------------------+

|                                                                  |

| Physical    +-----------+ +-----+   +------------------------+   |

| Network     | VNC Proxy | | PCE |   | Abstract Topology Gen. |   |

| Controller  +-----------+ +-----+   +------------------------+   |

|                                                                  |

| +---------------+ +--------------------+ +--------------------+  |

| |PNC OAM Handler| |Provisioning Manager| |Physical Topology DB|  |

| +---------------+ +--------------------+ +--------------------+  |
   +------------------------------------------------------------------+

*         VNC proxy: The VNC proxy is the functional module in charge of performing policy management and AAA (Authentication, authorization, and accounting) functions on requests coming from the VNC.

*         PCE: This is the stateful PCE performing the path computation over the physical topology and that provides the vConnection agent with the network topology.

*         Abstract topology generator: the network topology can be passed to the VNC as raw or abstract. In case the topology is passed as abstract topology, this module is in charge of generating it from the physical topology DB. The module is optional.

*         ONC OAM handler: it verifies that connections exists, implements monitoring functions to see if failures occurs. It is the proxy to an OSS/NMS system but does not duplicate any of OSS/NMS functionalities.

*         Physical topology database: The physical topology database is mainly composed by two databases: the Traffic Engineering Database (TED) and the LSP Database (LSP-DB).

*         Provisioning manager: The Provisioning Manager is responsible for making or channeling requests for the establishment of LSPs.  This may be instructions to the control plane running in the networks, or may involve the programming of individual network devices.  In the latter case, the Provisioning Manager may act as an OpenFlow Controller [ONF].
>From this context, we can begin to discuss architectural discussion such as interfaces functionality and work flows and information models between the VNC and PNCs.
Thanks,
Young