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.
2. 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
Univ. Grenoble Alpes Configuration Plane Training 2
3. 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
6. 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)
Univ. Grenoble Alpes Configuration Plane Training 6
8. 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
9. 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
11. 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
11Configuration Plane TrainingUniv. Grenoble Alpes
12. 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
Univ. Grenoble Alpes Configuration Plane Training 12
13. 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.
Reconfiguration Planner
Univ. Grenoble Alpes Configuration Plane Training 13
Reconfiguration plan
Constraints
Target configuration
Reconfiguration Planner
Notification
AdaptionPlane
Notification
14. 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
Univ. Grenoble Alpes Configuration Plane Training 14
Reconfiguration
commands
MonitorPlane
Reconfiguration
State Controller
Notification
Notification
deployment
Reconfiguration plan
Notification
15. 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
Univ. Grenoble Alpes Configuration Plane Training 15
Low-level
Reconfiguration
PrimitivesNotification
Configuration
Change Agents
Reconfiguration
commandsNotification
17. 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
Univ. Grenoble Alpes Configuration Plane Training 17
18. Deployment
Univ. Grenoble Alpes Configuration Plane Training 18
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).
19. 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
Univ. Grenoble Alpes Configuration Plane Training 19
Core
Agent
- PikeOS -
XP back-end
- ElinOS -
Comm.
Agent
- ElinOS - out_ex
in_ex Reconfiguration commands
Notifications
Qports
XP
Front-end
22. 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
Univ. Grenoble Alpes Configuration Plane Training 22
23. Example: Sender/Receiver
Univ. Grenoble Alpes Configuration Plane Training 23
Current configuration
Sender
{nodes_1}
Receiver
{nodes_2}
Target configuration
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 …
24. 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)
Univ. Grenoble Alpes Configuration Plane Training 24
25. 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)
Univ. Grenoble Alpes Configuration Plane Training 25
26. Running XP components
Univ. Grenoble Alpes Configuration Plane Training 26
Configuration Change Agent on nodes_1
Configuration Change Agent on nodes_2
XP back-end Initialization
27. Example: Sender/Receiver (Cont.)
Univ. Grenoble Alpes Configuration Plane Training 27
Current configuration
Sender
{nodes_1}
Receiver
{nodes_2}
Target configuration
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.