mDNS Handling in Nile's Layer 3 Network
Nile's layer 3 network architecture presents unique challenges for handling multicast traffic, particularly for service discovery protocols like mDNS (Multicast DNS). This document outlines how Nile addresses these challenges to provide seamless service discovery across isolated network segments.
The Nile Service Block (NSB) Gateway serves as a proxy for mDNS and other discovery protocols. This approach allows for:
- Service discovery within and across segments
- Centralized control and management of multicast traffic
- Efficient handling of various discovery protocols
While mDNS is the primary focus, Nile's solution extends to other discovery protocols:
- mDNS (used by AppleTV, Chromecast, Printers, NEAT Bar, and Oculus)
- uPNP/SSDP (used by SONOS)
- SOAP/WS-Discovery
- ONVIF Discovery
- BACnet
- DIAL
- Proprietary protocols (e.g., Polycom X50 and Poly TC8)
- The NSB Gateway learns multicast destinations for discovery packets.
- Administrators can approve or deny services through the Nile Portal, providing granular control over multicast traffic.
To enable service discovery across isolated layer 3 segments, the NSB Gateway:
- Intercepts multicast discovery packets
- Replicates and forwards these packets to relevant segments based on configured policies
- Maintains a database of discovered services and their locations
The NSB implements intelligent discovery based on:
- Proximity (for wireless devices)
- Services are filtered by RF neighborhood
- Casting and streaming services are shown only to nearby devices
- Application type
- Certain services (e.g., printers) are made visible across wider areas
The discovery process involves three main components:
- Service Requestor (client device)
- Service Proxy (NSB Gateway)
- Service Provider (e.g., printer, casting device)
- Nile cloud
The process flow is as follows:
- The client device sends a discovery request and service provider device is advertising various services
- NSB Gateway intercepts the request and the advertised services, sends the meta data to the Nile cloud as metrics. Nile cloud creates a database of end devices advertising the services and their locations
- NSB queries its service database in the cloud, which provides a list of available services and their location information. Additionally Nile cloud has telemetry on Wi-Fi Access Point neighborhood data, building and floor information
- NSB applies filtering based on service type and proximity
- NSB returns a filtered list of services to the client
Network administrators can configure and manage multicast handling through the Nile Portal:
- Approve or deny specific services
- Monitor multicast traffic and service discovery patterns
- The device list page shows all the mDNS based services a device is advertising
- The device details page for a particular end device has a list of all services it should potentially be seeing on the floor and/or building it is in, depending on the type of service
When implementing Nile's mDNS and multicast handling:
- To experience the full benefit of proximity and service type based filtering, Nile recommends having the mDNS and other types of service providing end devices on Wi-Fi. It provides better filtering based on RF Neighborhood data. Wired services are filtered at a coarse level of floor or building
- Consider the impact on network bandwidth, especially in large deployments
- Regularly review and update service discovery policies to maintain security and efficiency, closely tying into the point #2. mDNS and other multicast protocols especially used for service advertisement and discovery are chatty in nature, allowing only the required multicast protocols on the network.
