# Advanced Network Configuration Tips ## RAVENNA & PTPv2 Overview **RAVENNA** is a professional audio networking technology designed for flexibility and scalability over standard IP networks. Operating on protocol layers at or above Layer 3 of the OSI model, it enables true routability, making it ideal for complex network topologies. At its core, RAVENNA uses the **Real-time Transport Protocol (RTP)** for low-latency, reliable audio delivery. Each stream includes well-defined parameters such as stream name, payload format, channel count, access information, and sample rate, giving users comprehensive control over audio routing. **Precision Time Protocol version 2 (PTPv2)** is fundamental to RAVENNA, enabling multiple PTP clock domains within the same network. Unlike PTPv1, PTPv2 supports several independent timing domains without interference, offering enhanced flexibility. RAVENNA streams are typically multicast, which optimizes bandwidth by sending data only to subscribed devices. Device and stream discovery can be performed using DHCP, DNS, or Zeroconf protocols. For example, in HOLOPLOT setups, a **DHCP server is required**. RAVENNA also allows for fine-tuning of stream, sender, and receiver parameters. *** ## Payload Management in High-Traffic Networks Below is a list of possible system sizes and their categorization. It is important to understand the scale of a system and, with it, the connected requirements due to increased traffic. #### **Categorization of system sizes**
SizeNetwork descriptionNetwork requirements
Small
  • 1-15 Audio Modules, 1 Controller
  • 1-2 Switch hops between PTP master and receiver
  • Mixed AoIP (Dante & RAVENNA) standards, HOLOPLOT control, and other traffic
  • QoS configuration on the Switches
  • IGMPv2 snooping
  • IGMP querier
  • Separation of PTPv2 clock domains or usage of a boundary clock device if same domain required (E.g. Q-SYS)
Medium
  • 15-50 audio modules, 1-3 Controller
  • 1-2 Switch hops between PTP master and receiver
  • Mixed AoIP (Dante & RAVENNA) standards, HOLOPLOT control, and other traffic

  • An NTP clock and steady internet connection are recommended
  • QoS configuration on the Switches
  • IGMPv2 snooping
  • IGMP querier
  • Separation of PTPv2 clock domains or usage of a boundary clock device if same domain required (E.g. Q-SYS)
  • PTP aware switches
  • Regular CPU monitoring of PTP leader device strongly recommended
Large

  • 50-150 audio modules, 1-3 Controller
  • 3 and more switch hops between PTP Clock Leader and Followers
  • Mixed AoIP (Dante & RAVENNA) standards, HOLOPLOT control, and other traffic

  • An NTP clock and steady internet connection are recommended
  • QoS configuration on the Switches
  • IGMPv2 & v3 snooping
  • IGMP querier
  • Separation of PTPv2 clock domains or usage of a boundary clock device if same domain required (E.g.: Q-SYS)
  • PTP-aware boundary clock switches
  • Regular CPU monitoring of PTP leader device strongly recommended
  • Usage of VLANs strongly recommended
Very Large

  • More than 150 audio modules and more than 3 Controllers
  • 3 and more switch hops between PTP Clock Leader and Followers
  • Mixed AoIP (Dante & RAVENNA) standards, HOLOPLOT control, and other traffic
  • Same as for Large
  • Consultancy by an external network specialist strongly advised if no resources in-house
  • Fiber connections to be considered where applicable
### Key parameters for Configuration The following are critical for a well-performing RAVENNA/AES67 network: * **Quality of Service (QoS):** Network devices must support **DiffServ QoS** and be configured for AES67/RAVENNA. Use the following **DSCP values**: * PTPv2 Clock traffic: `EF (46)` — Expedited forwarding / Highest queue * RTP and RTCP stream data: `AF41 (34)` — Assured forwarding * Discovery and management traffic: `DF (0)` — Best effort * **IGMP Snooping:** Ensure **IGMPv2 and IGMPv3** are supported to manage multicast traffic effectively. * **Latency & Bandwidth Trade-off:** Lower latency increases bandwidth use due to higher packet rates. Make sure your network infrastructure can handle this. * **Jitter:** Devices must accommodate jitter within acceptable limits. For HOLOPLOT Modules, jitter tolerances are to be kept within **±0.8 µs** at 48 kHz. ## Recommended settings for cascaded network topologies For large deployments using **spine-leaf** or similar cascaded network structures: #### End-to-End (E2E) Latency Optimization * HOLOPLOT Control allows **global latency adjustments** across all audio modules. * Take hop counts into account when configuring stream latency. #### Clock Strategies * **Transparent Clocks (TC):** * PTP-aware switches measure internal packet delay and add it to the correction field. * Offers high accuracy but **less scalable** in very large networks. * **Boundary Clocks (BC):** * Intermediate PTP sources reduce master-follower packet traffic. * Preferred for **large systems** due to better scalability and network load distribution. {% hint style="info" %} **TIP**: Use transparent clocks in smaller systems for precision; switch to boundary clocks as your deployment grows. For additional AES67 tips, refer to [aes67-quick-start-guide](https://docs.holoplot.com/user-guides/holoplot-system-deployment/aes67-quick-start-guide "mention"). {% endhint %} ### Overall aspects on the performance of RAVENNA/AES67 networks ## RAVENNA/AES67 Network Performance Factors The performance of a RAVENNA/AES67 audio network, crucial for professional audio applications, is influenced by a multitude of factors spanning the leader device, follower devices, and the network infrastructure itself. #### Leader (Grandmaster) Device * **Clock Accuracy**: The internal oscillator or reference input must be stable. * **Redundancy**: Always deploy a **backup GM** to avoid clock loss. * **Sync Interval**: A shorter interval increases precision but adds load to the network and master. #### Follower Device Configuration * **PTP Delay Request Interval**:\ Affects how fast and precisely followers can synchronize. Shorter values result in better sync, but increases multicast control traffic #### Network Infrastructure * **Topology**: Redundant paths increase fault tolerance and clock accuracy. * **Link Speed**: Higher speeds reduce congestion and support more streams. * **Traffic Monitoring**: Continuously monitor bandwidth utilization to avoid overload. * **QoS Enforcement**:\ Prioritize: * PTP sync messages * Media traffic (RTP) * Management/control packets #### Redundancy * **Redundant Paths**: Ensure failover capability in case of link or switch failure. * **Dual Networks** (Primary & Secondary): Crucial for **mission-critical audio systems** where downtime is unacceptable.