Goal: 

To enable standardized NFV benchmark testing, we need to onboard and validate Crucible bench-trafficgen workflows. This story focuses on preparing a dedicated Crucible controller host, validating flexible result archival mechanisms, and defining static RFC-compliant traffic profiles. The objective is to establish a reliable and repeatable benchmark foundation while remaining independent of centralized infrastructure dependencies.

Scope of Work

1. Crucible Controller Host Preparation

• Prepare a dedicated Crucible controller host to execute NFV benchmark tests.

• Enable automation scripts to:

• • Populate the environment profile

• • Trigger and manage benchmark execution via Crucible

• Design the setup in a way that supports future migration to a fully dedicated Crucible controller, without refactoring core logic.

2. Benchmark Result Archival and Indexing Validation

• Evaluate Crucible's flexible run data archival capabilities.

• Validate the ability to:

• • Archive benchmark results locally or to an external server

• • Share run data with a centralized server (if available)

• • Perform indexing and post-processing using the Crucible CLI

• Ensure benchmark execution is not blocked when a centralized OpenSearch database is unavailable.

3. RFC-Compliant Static Traffic Profile Definition

• Define a static traffic profile aligned with RFC benchmark standards.

• Categorize traffic profiles specifically for:

• • 100G throughput

• • Latency measurements

• Ensure profiles are deterministic and suitable for repeatable NFV performance validation.

4. Traffic Generator Backend Categorization

• Organize traffic profiles to support multiple backend implementations:

• • trex-txrx

• • trex-txrx-profile

• Ensure backend selection is configurable without modifying the core benchmark logic.

Acceptance Criteria:

• Crucible controller host is prepared and capable of executing benchmark tests.

• Automation scripts successfully populate environment profiles and trigger Crucible runs.

• Crucible run data can be archived and shared without mandatory reliance on a centralized OpenSearch database.

• Static RFC-compliant traffic profiles are defined for 100G throughput and latency.

• Traffic profiles are categorized and validated for multiple backend support (trex-txrx and trex-txrx-profile).