CITADEL configuration and reconfiguration synthesis

CITADEL configuration and
reconfiguration synthesis
Univ. Grenoble Alpes Configuration Plane Training 1

 Source: Université grenoble-Alpes (UGA)
 Abstract: This material provides a thorough presentation of the
CITADEL Reconfiguration Plane, hereafter denoted XP, from high-level
design to low-level implementation and deployment on the CITADEL
platform.
 Learning outcome: Learn about the design, implementation and capabilities of
the CITADEL Configuration plane.
 Intended audience: System integrators
 Pre-requisites:
 MILS and Adaptive MILS
 CITADEL Modeling Language (SLIM)
 CITADEL platform (PikeOS, TSN)
 Python and C languages
 Language: English
 Format: PDF slides
 Expected workload: 2h
Introduction

 Overall organization
 Role in the CITADEL framework
 Interaction with other planes
 Reconfig. Planner, Controller, Agent
 Interactions and operation
 Implementation and deployment
 Usage and examples
Outline
3Configuration Plane TrainingUniv. Grenoble Alpes

Overall Organization

Reconfiguration Plane Position (I)
Configuration Plane Training 5Univ. Grenoble Alpes

 In the CITADEL framework, the configuration plane (XP),
plays an executive role which is to reconfigure the
Adaptive MILS system.
 Reconfiguration performed by XP covers mainly:
 The MILS policy architecture:
● subjects,
● communication between subjects, and
● subjects deployment.
 The MILS monitoring systems
● Monitors.
 To achieve reconfiguration, XP interacts with other
planes of the CITADEL framework, namely the
Adaptation Plane (AP), the Monitoring Plane (MP), the
Operational Plane (OP) and the Foundational Plane (FP)
as shown in the next slide.
Reconfiguration Plane Position (II)

Interactions with other planes (I)
7Univ. Grenoble Alpes Configuration Plane Training

Interactions with other planes (II)
8
Adaptation Plane
(AP)
1- target
configurationnotification
2- reconfiguration
step
notification
2- reconfiguration
step
notification
Foundational (FP)/Operational Planes (OP)
…
Reconfiguration Plane
(XP)
Monitoring Plane (MP)
Node 1
S1 Si
…
TSN
Net.
PikeOS
Node M
Si+1 SN
…
PikeOS
1. XP receives a target configuration
from AP, i.e. the new system
configuration to reach.
2. Based on that, XP issues
reconfiguration commands to
reconfigure MP and OP.
3. XP always expect a
notification back from
the reconfigured
planes.
Configuration Plane Training
4. It also notifies back AP.
Univ. Grenoble Alpes

Reconfiguration operation: overview
9
Configuration
Plane
Operational/Foundational Planes
Curent intermediate
Configuration
Target intermediate
Configuration
…
Intermediate Abstract Configurations
Current Concrete
Configuration
…
Small Step
Small Steps
Primitive Primitives
Target Concrete
Configuration
…Primitives
Current Architecture
(SLIM Model + Parameter Vector1)
Adaptation
Plane
Target Architecture
(SLIM Model + Parameter Vector2)
Big Step
XP proceeds by refining a high-level reconfiguration objective (big step) into
an intermediate plan (small steps) then into low-level primitives.
Configuration Plane TrainingUniv. Grenoble Alpes

Reconfiguration
Planner, Controller, Agent
10
Interaction and operation

Reconfiguration Plane Components
Reconfiguration plan
Constraints
Target configuration
Current
Configuration
Reconfiguration
commands
AdaptionPlane
MonitorPlane
Reconfiguration Planner
Reconfiguration
State Controller
Notification
Operational Plane
Notification
Low-level
Reconfiguration
PrimitivesNotification
Configuration
Change Agents
Foundational Plane
The figure shows the different
components of XP, namely
• The Planner,
• The Controller, and
• The Config. Change Agent,
in addition to the interactions
with the other planes.
Notification
Notification
deployment

 The Planner
Is responsible for computing a reconfiguration plan
given the target configuration sent by AP.
 The Controller
Is responsible to refine the high-level
reconfiguration plan computed by the planner and
to execute it by sending reconfiguration commands
to the Configuration Change Agent and to MP.
 The Configuration Change Agent
Is responsible for reconfiguring FP/OP. It executes
the appropriate low-level reconfiguration primitives
(PikeOS and TSN network) upon receiving
reconfiguration commands from the Controller.
Components roles

 Applies high-level reasoning to compute a reconfiguration plan that
leads the system from its current configuration to the target
configuration.
 The current and target configurations received from AP are SLIM
models. They are transformed into a graph representation.
 The reconfiguration plan is a sequence of actions over graphs e.g.,
add/remove nodes and edges.
 The constraints represents requirements such as
• « always remove the node’s edges before removing the node ».
• « always remove before add ».
 A notification is sent back to AP to notify success or failure.
Constraints
Notification
AdaptionPlane
Notification

 Refines the reconfiguration plan generated by the planner and
drives the reconfiguration execution.
 It includes appropriate reconfiguration commands into the
reconfiguration plan for monitors reconfiguration.
 deployment information concern the subjects of the
application and the configuration change agents.
 Reconfiguration commands are sent accordingly to the
monitoring plane and the config. change agents in each node.
 A notification is sent back to the planner to notify
success/failure.
Reconfiguration Controller
Reconfiguration
commands
MonitorPlane
Reconfiguration
State Controller
Notification
Notification
deployment
Notification

 Maps high-level reconfiguration commands
received from the controller to concrete
reconfiguration primitives and executes them.
 A Configuration Change Agent is deployed in each
node of the distributed MILS platform.
 Based on the primitive execution result, it notifies
back the controller.
Configuration Change Agent
Low-level
Reconfiguration
PrimitivesNotification
Configuration
Change Agents
Reconfiguration
commandsNotification

Reconfiguration
Planner, Controller, Agent
16
Implementation and deployment

 The Configuration plane is designed as a
back-end and a front-end
 The back-end
● encompasses the Planner and the Controller,
● is fully implemented in Python.
https://redmine.citadel-
project.org/projects/citadel-
framework/repository/show/Configuration-
Plane/controller/trunk
 The front-end
● contains different instances of config. change
agents,
● is fully implemented in C,
● Relies on PikeOS and ElinOS libraries.
Overall design

Deployment
reconfiguration
commands
Foundational (FP)/Operational Planes (OP)
…
XP back-end
Node 1
S1 Si
…
TSN
Net.
PikeOS
Node M
Si+1 SN
…
PikeOS
Planner
Controller
Reconfig.
planNotification
XP
front
-end
XP
front
-end
Notification
Notification
 The XP back-end is to be deployed on the same node as
the remaining CITADEL framework components. It is
deployed as an ElinOS partition.
 The front-end is deployed on the different nodes of
MILS Platform. Each node of the system hosts a
Configuration Change Agent (CCA).

 The Configuration Change Agent (CCA) is further decomposed into two modules:
 A communication agent
● Is responsible for interacting with the controller (front-end) and other components
inside/outside the node, e.g. TSN partition,
● Is deployed as an ElinOS partition.
https://redmine.citadel-project.org/projects/citadel-framework/repository/show/Configuration-
Plane/agent/trunk/CommHandlerApp.eapp
 A core agent
● Is responsible for executing PikeOS primitives,
● Is deployed as a native PikeOS partition,
● Requires abilities: read/write file system (eth0:dyn_reconf.conf), VM_AB_PART_SET_MOD
https://redmine.citadel-project.org/projects/citadel-framework/repository/show/Configuration-
Plane/agent/trunk/ReconfCoreAgent.p4app
 Communication between the two agents is performed using PikeOS Queue ports.
CCA implementation
Core
Agent
- PikeOS -
XP back-end
- ElinOS -
Comm.
Agent
- ElinOS - out_ex
in_ex Reconfiguration commands
Notifications
Qports
XP
Front-end

Usage & examples

 Back-end usage
./xp.py --ccas_deployment <CCAS deployment file>
--subjects_deployment <subjects deployment file>
 Requirements
● Python 2.7
● NetworkX Python library
● CITADEL Framework
● Compass tool
 Front-end usage
 Communication agent
Commagent [--master-port=PORT] [--interceptor-
port=PORT]
 Core agent
● Automatically started (PikeOS process)
Usage

 Subjects deployment file
 provides information about all application’s subjects (running/parked).
 Each line contains sid,pid,vca,vcb,ip,status,node
 sid = application subject identifier (id)
 pid = running partition identifier (number)
 vca = virtual channel identifier (id) - connecting subject partition to virtual eth service
 vcb = virtual channel identifier (id) - connectint virtual eth service to tsn partition
 ip = ip address of the application subject (xxx.yyy.zzz.www)
 status = initial subject status (UP | DOWN)
 node = node identifier (id)
 Information about the "tsn" partition are to be included in the same way.
 Example of a valid description
subject,partition,ch1,ch2,ip_addr,status,node
hello,4,16,17,192.168.0.5,UP,N1
tsn,5,*,*,198.22.14.5,UP,N1
 CCA deployment file
 Provides information about all the deployed configuration change agents
 Each line contains node,ip,port
 node = node identifier (id)
 ip = ip address of the CCA (xxx.yyy.zzz.www)
 Port = port number of which the CCA listen to contorller commands (number)
 Example of a valid description
node;ip_addr;port
N1;192.168.0.6;24000
Input files specification

Example: Sender/Receiver
Current configuration
Sender
{nodes_1}
Receiver
{nodes_2}
Sender
{nodes_2}
Receiver
{nodes_2}
Move Sender
To illustrate the reconfiguration steps, let’s
consider the simple example depicted on the left.
In the latter, the MILS policy architecture
(application) is made of two subjects, namely the
Sender and the Receiver. These are initially
deployed respectively on node N1 and N2 of the
MILS platform.
The considered reconfiguration, is to move the
Sender to N2 (because of a certain event, e.g. N1 is
no more operational). The target configuration is
thus as shown by the graph on the bottom.
The code to run this example is provided under …

 In this example, we have two nodes
 nodes_1 and nodes_2
 We will have tow Configuration Change
Agents, one on each node.
 Run the configuration change agents:
./commagent.exe --master-port 24000
./commagent.exe --master-port 25000
Running XP components (Front-end)

 To run the back-end use the following commands with the mentioned
input files.
./$CITADEL_PATH/Configuration-Plane/controller/trunk/xp.py
--ccas_deployment send-recv-netmon-ccas-deployment.csv
--subjects_deployment send-recv-netmon-subject-deployment.csv
 ccas deployment file
node;ip_addr;port
nodes__1;127.0.0.1;24000
nodes__2;127.0.0.1;25000
 subjects deployment file
subject,partition,ch1,ch2,ip_addr,status,node
sender,4,1,2,192.168.0.5,UP,nodes__1
receiver,5,3,4,192.168.0.6,UP,nodes__2
sender,6,1,2,192.168.0.5,DOWN,nodes__2
receiver,7,3,4,192.168.0.6,DOWN,nodes__1
Running XP components (back-end)

Running XP components
Configuration Change Agent on nodes_1
Configuration Change Agent on nodes_2
XP back-end Initialization

Example: Sender/Receiver (Cont.)
Sender
{nodes_1}
Receiver
{nodes_2}
Sender
{nodes_2}
Receiver
{nodes_2}
Sender
{nodes_1}
Receiver
{nodes_2}
1- Remove Sender->Receiver
Receiver
{nodes_2}
2- Remove Sender on N1
Sender
{nodes_2}
Receiver
{nodes_2}
3- Start Sender on N2
4- Re-establish Sender->Receiver
This reconfiguration plan
is computed by the Planner
component.

Compute reconfiguration plan (abstract)
Receive target configuration
Initialization/receive initial
configuration

Sender
{nodes_1}
Receiver
{nodes_2}
Sender
{nodes_2}
Receiver
{nodes_2}
Sender
{nodes_1}
Receiver
{nodes_2}
1.1- Remove Sender->Receiver
Receiver
{nodes_2}
2.1- Remove Sender on N1
Sender
{nodes_2}
Receiver
{nodes_2}
3.0- Start Sender on N2
4.0- Re-establish Sender->Receiver
1.0- notify monitor (Remove Sender->Receiver)
2.0- notify monitor (Remove Sender on N1)
3.1- notify monitor (start Sender on N2)
4.1- notify monitor (establish Sender->receiver)

Compute reconfiguration plan
(concrete)

Executing the reconfiguration plan

Ayoub Nouri
Ayoub.nouri@univ-grenoble-alpes.fr
Marius Bozga
Marius.bozga@univ-grenoble-alpes.fr
Contact information

CITADEL configuration and reconfiguration synthesis

More Related Content

What's hot

Recently uploaded

CITADEL configuration and reconfiguration synthesis