Join Pilot

Limited slots available for early access

Guide

ALPINEDMX over IPLighting Protocol With IdentitySecure Lighting Protocol

ALPINE: Identity-First Transport for Lighting Control

ALPINE is a modern lighting control transport that replaces Art-Net and sACN while preserving DMX. It adds identity, capability negotiation, session ownership, and deterministic streaming.

ALPINEALPINEDecember 31, 2025

ALPINE: Identity-First Transport for Lighting Control


What ALPINE Is (and What It Replaces)

ALPINE is a transport protocol for controller-to-device lighting control. It is designed to replace legacy DMX-over-IP transports such as Art-Net and sACN, while leaving fixture-level DMX fully intact.

In the Y-Link ecosystem:

  • Fixtures connect over DMX to Y-Link devices

  • Those devices expose fixtures upstream via ALPINE

  • Controllers (for example, Y-Link Studio) communicate with devices using ALPINE

ALPINE defines a complete control lifecycle:

  • discovery

  • handshake

  • control-plane operations

  • real-time streaming

It is a wire protocol based on CBOR, with a deterministic session model and explicit cryptographic identity.


Why Legacy DMX-over-IP Transports Fall Short

Art-Net and sACN solved distribution of 512-slot DMX universes over IP, but their model reflects the constraints of DMX rather than the needs of modern control networks.

They do not provide:

  • a native identity system

  • capability negotiation

  • deterministic session ownership

They also conflate discovery and control with limited trust semantics. These protocols can be made to work at scale, but only by building out-of-band conventions around them.

ALPINE exists to formalize what those conventions attempt to provide:

  • authenticated identity

  • deterministic session ownership

  • a streaming model not bound to the DMX universe abstraction


Identity-First Design

Every ALPINE device has:

  • a stable device identifier

  • manufacturer and model identifiers

  • a long-term Ed25519 public key

Identity is not implied by IP address or hostname.
It is explicit and cryptographically verifiable.

This identity baseline is the foundation for trust and downstream control decisions. It also enables auditable provisioning workflows, because identity is part of the protocol itself — not an external assumption.


Discovery and Trust

Discovery is a UDP broadcast-based exchange.

  • A controller sends an alpine_discover message containing:

    • a nonce

    • requested information categories

  • The device replies unicast with:

    • identity information

    • network information

    • declared capabilities

    • an Ed25519 signature covering the response and nonce

The controller is required to:

  • verify the signature

  • verify the nonce

  • bind the device identity to the network interface that received the reply

This makes discovery explicit, observable, and resistant to spoofing, while avoiding reliance on mDNS or multicast availability.


Capability Negotiation

Devices declare capabilities during:

  • discovery

  • handshake

  • control-plane queries

Capabilities include:

  • supported channel formats (u8, u16)

  • maximum channel counts

  • grouping support

  • streaming support

  • encryption support

Controllers adapt explicitly, rather than guessing device behavior.

This is especially important for mixed fleets, where deterministic decisions must be based on declared capability contracts instead of heuristics or vendor-specific assumptions.


Session-Based Control and Ownership

ALPINE establishes control via a mutual-authentication handshake:

  • X25519 for key exchange

  • Ed25519 for signature verification

  • HKDF-SHA256 for session key derivation

Once a session is active:

  • control-plane messages are authenticated

  • messages are sequenced

  • ownership is explicit

Control-plane envelopes are reliable by design:

  • monotonically increasing sequence numbers

  • retransmission support

  • exponential backoff

  • acknowledgements with optional structured payloads

This produces a deterministic ownership model:

  • the controller knows which session it owns

  • the device knows which session is authoritative


Streaming Model and Determinism

Streaming is distinct from the control plane.

Frames are sent as alpine_frame envelopes containing:

  • session ID

  • timestamp

  • priority

  • channel format (u8 or u16)

  • channel data

  • optional groups and metadata

Streaming properties:

  • frames are not retransmitted

  • frames are ordered per session

  • devices apply explicit jitter strategies:

    • hold-last

    • drop

    • interpolation

This model removes the fixed universe constraints of DMX-derived transports. Instead of packing 512-slot universes into packets, ALPINE streams structured control frames that reflect the actual payload.

ALPINE also defines stream profiles (Auto, Realtime, Install) that bind latency and resilience behavior to a session. Profiles are validated and immutable once streaming starts, preventing runtime drift.

Design commitment:

Under loss or jitter, ALPINE degrades visual quality, not temporal correctness.


Performance Benchmarks

ALPINE includes transport-level benchmarks comparing frame encode → send → receive → decode cost against sACN and Art-Net, using real UDP loopback and identical payloads.

Observed Results (Median / p95)

Protocol

Channels

Median (µs)

p95 (µs)

ALPINE

128

~9.5

~12

ALPINE

512

~22

~27

sACN

128

~7.8

~10

sACN

512

~17

~21

Art-Net

128

~6.3

~9

Art-Net

512

~14.5

~18

Interpretation

  • Where ALPINE is slower:
    ALPINE performs additional work per frame — CBOR encoding, structured envelopes, and optional authentication — resulting in ~1.2× overhead vs sACN and ~1.5× vs Art-Net in this environment.

  • Where ALPINE is more predictable:
    Latency variance is tighter. Deterministic layout and parsing reduce tail jitter compared to legacy packets with looser structure.

  • Why this trade-off exists:
    Art-Net and sACN optimize for minimal packet cost. ALPINE optimizes for identity, ownership, capability awareness, and deterministic control semantics. The observed ~10–15 µs delta (~0.01 ms) is typically negligible compared to scheduling, rendering, or fixture response times.

These benchmarks are intended for comparison and regression detection, not absolute performance claims.


How Y-Link Uses ALPINE in Practice

Within Y-Link, ALPINE’s role is narrow and explicit:

  • Fixtures connect to Y-Link devices via DMX cables

  • Y-Link devices expose those fixtures upstream as ALPINE endpoints

  • Controllers communicate using ALPINE discovery, handshake, control, and streaming

This preserves the existing DMX fixture ecosystem while modernizing the controller-to-device transport.

A Y-Link device can represent a collection of DMX fixtures while still exposing:

  • a stable cryptographic identity

  • declared capabilities

  • deterministic session ownership


Why This Architecture Scales Better Than Art-Net and sACN

ALPINE scales because it makes identity and ownership explicit, and cleanly separates concerns:

  • Identity & discovery are cryptographically verifiable

  • Capabilities are declared and negotiated

  • Control-plane operations are reliable, authenticated, and ordered

  • Streaming is session-bound, timestamped, and not universe-constrained

For complex systems, the limiting factor is not bandwidth — it is determinism and observability.


Summary

ALPINE is a controller-to-device transport protocol that replaces Art-Net and sACN without replacing fixture-level DMX.

It provides:

  • identity-first discovery

  • capability negotiation

  • session-based control

  • structured, deterministic streaming

The result is a deterministic, auditable control network that integrates cleanly with existing DMX fixtures while enabling modern lighting control workflows.

ALPINE Lighting Protocol: Identity-First Art-Net & sACN Replacement | Y-Link