UC-21: L2VPN Request with QoS Requirements (max_delay + strict=True)

[lmarinve]

Use Case 21: User Submits a Request with QoS Requirements for max_delay and strict=True

Domain: QoS & VLAN Management / User Requests & Scheduling
Component(s): SDX Controller, Meican

---

Trigger

A user submits an L2VPN provisioning request specifying a max_delay QoS constraint (e.g., ≤ 10ms) and sets strict=True, indicating that delay limits must be fully respected end-to-end.

---

Expected Behavior

SDX Controller:

• Interpret the QoS constraint: max_delay must not be exceeded across the entire path
• Use the Path Computation Element (PCE) to search for a path within the delay threshold
• If no such path is found:
  • Reject the request with a clear message: "Unable to satisfy maximum delay requirement under current network conditions."
  • Do not provision a degraded path
• If a valid path is found:
  • Proceed with provisioning
  • Optionally: update internal delay usage tracking to avoid overcommitting low-delay resources in future requests (TODO: track per-link/path delay allocations)
• Notify the user of the result

Meican:

• Provide UI fields for max_delay and strict in the request form
• Show validation results and QoS status in service view
• Allow feedback or retries with relaxed QoS parameters if needed

---

Discussion

• Enforcement of max_delay depends on telemetry (e.g., BAPM) and link delay metadata.
• Strict delay adherence may be impossible in certain inter-domain topologies—SDX should provide actionable user messages.
• Usage tracking for delay constraints is an open design question—may require coordination with PCE and telemetry systems.

---

Test Coverage

Planned test: test_21_qos_maxdelay_strict_provisioning.py
This test validates:

• Rejection of L2VPN provisioning when max_delay is not achievable
• Acceptance and provisioning when path meets the QoS constraint
• Accurate reflection of provisioning result in Meican

---

Project Reference

• Project 16 – AtlanticWave-SDX E2E Use Cases

---