Component Discovery Protocol¶

In a local area network, we may have one or more input/output devices. We will introduce how to plug/remove devices here.

state:	Draft

Preamble¶

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.

Component Identity¶

We use Universally Unique Identifier (UUID) to identify a component.

Transportation Layer¶

The IoTtalk Data Gateway MUST broadcast its identity on IPv4 UDP 1900. We consider it act as a beacon. A beacon SHALL keep broadcasting in an constant interval. Taking one to five seconds as broadcasting interval is RECOMMENDED.

Protocol Grammar¶

The following ABNF grammar defines Component Discovery Protocol:

cd-protocol      = header body CRLF

header           = "IT" SP src-UUID SP

body             = 1*verb

verb             = hello
                 / ping
                 / pong

hello            = "HELO"
ping             = "PING" 0*1dest-UUID
pong             = "PONG" dest-UUID

src-UUID         = UUID
dest-UUID        = UUID
UUID             = 16OCTET

The sender MUST reveal its UUID in header.

The Protocol Commands¶

The verb described in section Protocol Grammar are considered as commands here.

`hello` Command¶

This command SHALL be used by a beacon to reveal its UUID at the local area network. It MUST carry a UUID refered to sender itself.

`ping` Command¶

This command is invoked when a component need to check the other known components still alive or not.

The following message format are valid:

PING UUID
PING

The former format carry a UUID refered to a destination component. If the UUID of the receiver do not match with message UUID, we MAY drop this message without response. Otherwise, the receiver SHOULD invoke a pong Command.

The later format do not make anything follow it. Any receiver SHOULD invoke a pong Command to original sender. In order to make components be discovered actively, this format is RECOMMENDED to send via broadcasting. Or in case of discovering all component on same endpoint, same ip, for example, this format is also RECOMMENDED.

`pong` Command¶

This command is invoked in order to reponse the ping Command.

The following message format is valid:

PONG UUID

This message MUST carry a UUID referd to the source of ping Command. The receiver MAY drop this message if the carried UUID do not match with receiver itself.

Security Aspects¶

UDP Flood Attack¶

Due to this protocol use UDP as transportation layer. This Attack is a common issue. Attacker can send huge amount of udp packages with ping command to make every devices in the LAN busy.

We RECOMMENDED each device maintain a rate limitation for the ping command. Note again that the receiver of ping command SHOULD invoke response, but not MUST. Devices can drop udp packages if necessary.