JSD-MP solves the joint placement of Virtual Network Functions (VNFs) and the
VNF Managers (VNFMs) that manage them. Most placement work optimizes VNFs first
and places managers afterward; we instead place both together, so VNF placement is
steered toward layouts a manager can actually serve — subject to manager capacity,
a latency radius, and co-location (notManagerNodes) constraints. The problem is
NP-hard, so we provide heuristics and compare them against an exact CPLEX solver.
Central finding. Joint placement is best understood as a feasibility-
preservation mechanism, not a revenue tweak: a management-blind (disjoint)
pipeline frequently strands whole chains because no admissible manager exists for
the layout it chose. Its benefit is therefore conditional — large exactly when
management constraints bind, and negligible (even slightly negative) when they do
not. See Key findings and analysis/FRAMING.md.
Methods implemented here:
bari— the joint VNF+VNFM heuristic (management-aware DP / Viterbi); the core methodrari— MASMAN, a randomized variantabu— Abu-Lebdeh's tabu-search baseline, unmodifiedoabu— Abu-Lebdeh adapted to our constraints for a fair comparison- Optimal with CPLEX, implemented under
simulation/(a Java/Gradle project)
In the jsd-mp problem some functions can be managened and there are the functions that need VNFM, so the following code snippet find these functions in a chain.
itertools.compress(
placement.nodes, chain.manageable_functions
)Also we have the following configuration for our VNFM constraints as default:
ram: 4
cores: 2
capacity: 10
radius: 100
bandwidth: 10
licenseFee: 100Abu-Lebdeh describe a method based on tabu-search to improve VNFM placement on datacenter that already has VNF placement. In our work we are considering the VNF placement jointly with VNFM placement so we are going to change it to consider the placement and after that compare it with our method. In Abu-Lebdeh method there is no way to discard a chain so it can generate infeasible results so we are reserving resources for VNFM to prevent the infeasible situation.
The following variables are available in the src/jsd_mp/abu solution to configure it so you need to change them by hand (with --options) and report them into results.
n_iter
reserve_percentageAbu-Lebdeh uses tabu-search to improve its VNFM placement but at this method it doesn't use consider our problem constraints, so here we are going to optimize it based on our constraints.
From the re-analysis in analysis/, which reports chain
acceptance rate (feasibility) with paired significance tests plus a controlled
sensitivity sweep. Full detail in analysis/SUMMARY.md and
analysis/SWEEP.md.
-
Joint placement preserves feasibility. It accepts ~100% of chains across regimes, whereas disjoint placement is bimodal — a run either nearly succeeds or collapses (often to ~30–50% acceptance) because the post-hoc manager step is infeasible. Mean-revenue plots hide this; acceptance rate exposes it.
-
The advantage is conditional on management binding:
Regime Joint accept Disjoint accept Reading USnet, default (slack) management ~100% ~100% joint adds nothing; revenue −0.2…−0.9% (p<0.01) FatTree, default VNFM ~100% ~20–87% (bimodal) joint preserves feasibility USnet + 4-hop radius ~100% ~35–94% tightening one constraint flips the regime -
The constraint is the cause. Toggling the
notManagerNodesco-location constraint on/off makes the joint advantage appear (+12–19 pp acceptance) and disappear (0 pp), and the gap decays as load saturates raw compute. On the tested topology, manager capacity is not a binding lever.
Running a solver writes a report.csv that the Jupyter notebooks under
results/ load. The corrected, statistically-honest re-analysis and
the sensitivity study live under analysis/ and are regenerable with
uv run --group notebook python analysis/<script>.py.
The manuscript lives under paper/, written in LaTeX using the
MDPI Future Internet class (vendored in paper/Definitions/). Build the
PDF with make -C paper (or latexmk -pdf -bibtex paper/main.tex); CI also
typesets it on every change and uploads the PDF as an artifact. See
paper/README.md for details.
There are two topology that are considering here, fattree and usnet. There is another project that generate networks with these two topology. The generated configuration that must be copied and used with this project as follow:
topology fattree -k 4
cp topology.yaml ../jsd-mp/config/topology.ymlPlease note that you must also consider to store these configuration for future re-runs.
We are going to place SFCs on our network and there is project that generate chains. The generated chains chains can be copied and used with this project as follow:
chainer -n 100
cp chains.yaml ../jsd-mp/config/chains.ymlThis project is managed with uv. Install the
dependencies (and the jsd-mp package itself) with:
uv syncThen run a solver via the jsd-mp console entry point:
uv run jsd-mp -ss rari -c config/ -r 10Run the test suite and type checker with:
uv run pytest
uv run mypyThe Jupyter notebooks and the analysis/ scripts need the extra notebook
dependency group:
uv sync --group notebook
uv run --group notebook python -m ipykernel install --user --name=jsd-mp-krnlIn your notebook, Kernel -> Change Kernel. Your kernel should now be an option.