Test Objectives

Test Goals

The main test objective is to ensure that the advanced CoS features of the ACX7000 series platforms meet the requirements for reliable and high-quality performance in 5G Fronthaul. The secondary test objective is to confirm that the CoS behaviors are consistent throughout the mobile backhaul topology and across different devices.

An intrinsic test goal of JVD is to identify any limitations, anomalies, and problem reports (PRs) that are discovered during the validation stages. These issues are addressed and fixed whenever possible, and any code changes are revalidated as part of the test execution to ensure the solution functions as intended.

The CoS operational goals are summarized by functional category. Additional details of each category are available in the Solution Architecture section.

Classification

• Behavior Aggregate (BA) classification is based on the received or pre-marked 802.1p, DSCP, or EXP packet headers.
• Fixed Classification maps all interface traffic to a specific forwarding class.
• Multifield classifier matches received packet attributes and maps to a forwarding class. A multifield classifier is included to match eCPRI, PTPoE, and OAM traffic or received 802.1p bits and maps to an appropriate forwarding class.
• Host-outbound exception traffic is assigned to a specified forwarding class and queue.

Queuing and Scheduling

• Eight forwarding classes and eight queues are used in the validation.
• (LLQ allows delay-sensitive data to be given preferential treatment over other traffic.
• Multi-level priority queues ensure differentiated services and applications can be appropriately prioritized across the network topology.
• Scheduler percentages are honored based on custom shaping rates (port level).
• Unused bandwidth is made available to other queues as required (up to shaping-rate) and proportional to the configured transmit-rate.
• Queueing and scheduling implementation distinctions for ACX7000 platforms:
  • Six priority levels are supported, with each higher priority pre-empting the lower: low-latency, strict-high, high, medium-high, medium-low, and low.
  • As of Junos OS Evolved Release 24.3R1, ACX supports eight priority levels for port QoS.
  • LLQ priority is serviced ahead of and pre-empts all other queues.
  • All priority queues with equal priority are serviced as round-robin.
  • Transmit-rate is not utilized on priority queues and might be shaped (PIR) to prevent starving lower priority queues.
  • Low-priority queues are serviced as WFQ round-robin in accordance with the transmit rate.
  • Only low-priority queues might use the transmit-rate configuration.
  • LLQ is given a dedicated VOQ to Egress Queue (EGQ) to ensure latency preservation.
  • When shaping rate is used, the amount is deducted from the total port speed. The remainder port speed is used to calculate transmit-rate percentage.
  • Fair Adaptive Dynamic Threshold (FADT) shared buffer allocation is updated on demand.
• Queueing and scheduling implementation distinctions for MX Trio-based platforms:
  • Five traffic priority levels are supported: strict-high, high, medium-high, medium-low, and low.
  • Queues in-profile (operating within the configured bandwidth rate) function within the guaranteed region where only strict-high queues can starve.
  • Guaranteed queues are serviced as priority queue deficit weighted round-robin (PQ-DWRR).
  • Queues out-of-profile (operating over the configured bandwidth rate) function in the excess priority region. Equal priority queues are serviced as WRR, with transmit-rate being the weight. Excess region priority is configurable, including excess transmit rate or weight.
  • An out-of-profile high-priority queue cannot starve an in-profile low-priority queue. Only strict-high operates without any excess region (therefore might be shaped to prevent starving other queues).
  • Buffer can be locked with manual configuration.

Rewrite

• Traffic is mapped to the correct queue(s), and customer or default rewrite rules are honored.
• Ingress traffic is marked as 802.1p or DSCP and rewritten for EXP classification at egress.
• Ingress traffic with EXP marking is rewritten to 802.1p or DSCP at egress.
• The rewrite operation affects the outermost tag for dual-tagged frames, preserving the inner tag.
• Preserve QoS codepoints end to end for inner and outer tags (wherever intended).
• Multiple rewrite types are supported per interface.

Shaping and Rate Limiting

• Port-level shaper honors existing scheduler transmit rates based on the provisioned shaper bandwidth.
• PQs allow rate-limiting to prevent starving low-priority queues.
• The port shaper inherits and appropriately scales the configured scheduling characteristics.
• Shaped queues do not exceed the configured shaping rate.

Latency Budget

• LLQ has the highest priority. In scenarios where the network is not congested and the line rate is below 100%, the LLQ adheres to the following latency budgets:
  • O-RU-to-O-DU latency averages ≤10µ per device.
  • RU-to-SAG latency ≤10ms (expected ≤100µ).
  • eCPRI Type 5 One Way Delay measurement is approximately ≤10µ per device.
• LLQ functionality ensures that the latency budget for delay-sensitive traffic is preserved in congestion and non-congestion conditions.

Key 5G Validation Attributes

• The solution ensures an end-to-end latency and stable jitter for eCPRI packets delivered between RU and DU nodes.
• Prioritize critical eCPRI fronthaul traffic during congestion and non-congestion conditions.
• Preserve latency budget of eCPRI fronthaul traffic during congestion and non-congestion conditions.
• Maintain traffic priorities across shared links.
• Maintain traffic priorities within and between VPN services that share common links.
• Allow transmission of eCPRI Type 7 event indication errors during network congestion.
• Maintain consistent CoS and resiliency across negative stress conditions restart control and data plane daemons, add/delete configurations, and so on.).
• CSR allows all types of UNI interfaces to interconnect with 5G gNB and 4G eNB as described.
• HSR supports the proposed connectivity of O-DU and O-CU, including redundancy options.
• Transport and connectivity services are supported for 4G MBH.

Test Flow Characteristics

The JVD includes the following traffic patterns.

Accepted Frame Types

• Untagged (port-based)
• Tagged (802.1Q)
• Double-tagged (802.1ad)

Accepted Ether Types

• 0x8100 802.1Q (C-TAG or used with Single-Tagged flows)
• 0x88a8 802.1ad (S-TAG on Q-in-Q flows)

Test Non-Goals

Non-goals represent functions outside the scope of this JVD or might be covered previously.

• Custom drop profiles weighted random early detection (WRED)
• Temporal transmit rate or buffer (elastic buffer is used)
• Hierarchical CoS and H-Policing
• 802.1CM TSN Profile B with frame pre-emption (802.1Qbu)
• VLAN manipulation operations (covered in previous CoS JVD)
• Underlay or Overlay validation other than those specified in the solution goals section
• Failover and convergence scenarios (covered in previous 5G JVDs)
• End-to-End timing and synchronization distribution: synchronous Ethernet, IEEE1588v2
• G.8275.1 PTP Aware with per-node boundary clock
• SLA Monitoring: RFC 2544, Y.1564, TWAMP, and active assurance
• Telemetry, management, and automation
• Network or Link Slicing
• Flex-Algo, transport classes, BGP classful transport (covered in previous 5G JVDs)

Failure Scenarios

The validation covers the following failure scenarios:

• Link congestion
• Queue congestion without traffic discarding
• Queue congestion with traffic discarding
• Single and multiple queue congestion conditions
• Injected failure events (including eCPRI type)
• Process restart