关于ODL-SDNiApp是否仍受支持及SDN控制器间通信工具的问询

First off, let's address your question about ODL-SDNiApp: this component is no longer supported by the OpenDaylight project. The last update to its user guide was for the Helium release (circa 2015), and looking at the project's code repositories, community discussions, and release notes from subsequent versions (Lithium, Neon, etc.), there's no active development, bug fixes, or maintenance happening for SDNiApp anymore. It's effectively a deprecated component, so I'd strongly advise against using it in any new testing or production environments—you'll run into unpatched bugs, compatibility issues with newer ODL versions, and zero community support if you hit problems.

Now, for practical tools and methods to enable communication between SDN controllers, here are my top recommendations based on real-world use cases:

• ODL Native Clustering & RESTCONF/NETCONF
  If you're sticking with OpenDaylight, the official way to handle multi-controller communication is using its built-in clustering (powered by Akka). This lets multiple ODL instances form a cluster, automatically syncing topology data, flow rules, and state. For cross-cluster or direct controller-to-controller interactions, you can leverage ODL's standard RESTCONF or NETCONF APIs—each controller can send requests to another's API endpoints to fetch or modify network state.

• ONOS Inter-Controller Communication & Federation
  If you're open to switching or combining controllers, ONOS has robust native support for inter-controller communication. Its Inter-Controller module handles state sharing and coordination between ONOS instances, and its Federation framework allows seamless collaboration across different ONOS clusters. It's actively maintained and aligns with modern SDN standards.

• Message Queue Middleware (Kafka/RabbitMQ)
  For heterogeneous environments (e.g., mixing ODL, ONOS, or custom controllers), using a message broker like Kafka or RabbitMQ is a flexible approach. Controllers can publish events (like topology changes, flow updates, or fault alerts) to a shared queue, and other controllers can subscribe to these events. This decouples the controllers and works well for asynchronous communication needs.

• Custom gRPC/REST Services
  If you need a tailored communication layer for specific business logic, building lightweight gRPC or REST services is a great option. gRPC offers high performance for low-latency interactions, while REST is easier to prototype. You can deploy these services on each controller to exchange custom data (like traffic engineering policies, resource allocation commands) between instances.

• SDNI-Compliant Frameworks
  The Open Networking Foundation (ONF) defines the SDN Interconnection (SDNI) standard for multi-controller environments. Look for open-source implementations that align with this standard—many modern SDN projects (like ONOS and newer ODL modules) include components that support SDNI principles for secure, standardized inter-controller communication.

内容的提问来源于stack exchange，提问作者Aymen