# Service Discovery protocols
# Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (opens new window).
# Overview
The Service Discovery Protocol is responsible for facilitating Service Discovery in the network. Requests can either be broadcasted or sent to a single device. Responses MUST be sent directly to the requesting device.
Gateway implementations MAY choose to listen to service advertisements and cache the results, in order to act as a service catalog.
# Addressing
Service advertising and discovery MAY be broadcasted or unicasted (directed to a single device). Addressing are as follows:
| Type | Address |
|---|---|
| <broadcast> | 255 (0xFF) |
| <unicast> | Device addr. |
# Service Discovery
Service Discovery can be initiated by any device on the network, however, only listening devices MAY respond. Battery constained- or sleepy devices can advertise their services to a Service Proxy, typically implemented in the Gateway, which can then respond to Service Discovery Requests on it's behalf.
Devices responding to broadcasted Service Discovery requests MUST reply directly to the initiating device. Delays in the reply SHOULD be implemented, in order to avoid collisions.
Service Discovery requests MAY be broadcasted or unicasted. Replies SHOULD be treated the same.
# Service Advertising
Service Advertising is OPTIONAL and MAY be implemented by a device or a gateway.
# Protocol ID numbers
This table lists the Application protocol ID numbers used in the Transport Header (THdr):
| App protocol ID | Description |
|---|---|
| 0 | RFU |
| 1-13 | Reserved |
| 14 | User defined protocol (proprietary) |
| 15 | Reserved |