Technology: MUP1

MUP1 or Microchip UART Protocol #1, is a simple frame-based protocol designed to run over UART (serial) interface.

The purpose of MUP1 is to offer a point-to-point interface which can work without any configuration, and which cannot be "broken" by applying configuration.

It does have some similarities with SLIP (RFC1055), but as SLIP is IP based, it typically needs IP configuration on both server and client, which contradicts the purpose.

In VelocityDRIVE-SP, MUP1 replaces the typical serial human-friendly console interface seen on many switches. MUP1 is a machine interface that, among other things, can carry CoAP frames, which then gives access to the entire management interface.

To use the MUP1 interface, it is therefore required to have a client with MUP1 support.

The purpose of this document is to specify the MUP1 protocol such that customers and/or third parties can implement MUP1 support in their client products.

1. High-Level Design Requirements

The MUP1 protocol is designed to meet the following goals:

  • Low overhead, frame-based protocol.

  • Integrity checking by using checksum.

  • Access to CoAP stack, with security mechanisms offered by CoAP (DTLS).

    • CoAP access will give access to all CoAP resources including the entire CORECONF interface.

  • Point-to-point communication without any initial configuration.

  • Not limited to CoAP, but shall also support other protocols.

  • Both client and server can initiate messages.

MUP1 is considered a layer-1 / transport-layer protocol, and is therefore not involved in stuff like security, reliability, and re-transmission. All of this is left for the higher layers.

2. Protocol Specification

MUP1 is a frame-based protocol that defines the following symbols:

Symbol Value Description

SOF

> (0x3e)

Start of frame

EOF

< (0x3c)

End of frame

ESC

\ (0x5c)

Escape

The protocol frame format for frames with an odd number of data bytes looks like this:

+-----+------+----+---+----------+
|SOF:1|TYPE:1|DATA|EOF|CHECKSUM:4|
+-----+------+----+---+----------+

The protocol frame format for frames with a even number of data bytes looks like this:

+-----+------+----+---+---+----------+
|SOF:1|TYPE:1|DATA|EOF|EOF|CHECKSUM:4|
+-----+------+----+---+---+----------+

Where:

  • SOF is a symbol to indicate start-of-frame.

  • TYPE is a 1-byte field specifying the message type. Each message type shall be defined in other requirements. Type shall avoid using values which require escaping.

  • DATA is a variable length binary data field. The maximum data size is implementation dependent, but typically advertised in the announce message.
    Default max data size is 300 bytes (actual data - not considering escaping).
    Be aware of escaping rules listed below.

  • EOF: is a symbol to indicate end-of-frame.

    • If the size of DATA is an even number of bytes, then one additional EOF is added. This assures that when calculating CHECKSUM the number of bytes is always even.

  • CHECKSUM is a 4-byte field carrying a checksum of SOF+TYPE+DATA+EOF(s) in the frame. The checksum algorithm is the 16-bit one’s complement (same as used in UDP).

    • The checksum is calculated on the non-escaped DATA.

    • The 16-bit checksum shall be encoded as a hex string using the ASCII characters 0 (0x30) - 9 (0x39) and a (0x61) - f (0x66). The value shall be encoded as big-endian.

    • The checksum value of 0000 (four bytes with the value of 0x30) is special and means that the checksum is ignored.

    • Messages with invalid checksums shall be dropped.

Encoding and Escaping:

The SOF, EOF, and ESC values are special in the MUP1 protocol as they are used to signal the start and end of a frame.
The values 0x00 and 0xFF are special in the Telnet protocol and must not appear on the wire.

The DATA field carries binary data, and must be encoded according to the following rules:

  • The value 0x00 ('0') shall be encoded as [0x5c, 0x30]

  • The value 0xFF ('F') shall be encoded as [0x5c, 0x46]

  • The SOF value 0x3e ('>') shall be encoded as [0x5c, 0x3e]

  • The EOF value 0x3c ('<') shall be encoded as [0x5c, 0x3c]

  • The ESC value 0x5c ('\') shall be encoded as [0x5c, 0x5c]

  • All other values are used as-is.

2.1. Error and Recovery Handling

The error handling in MUP1 is very simple and follows a few simple rules:

  1. Reception of a SOF symbol always resets the MUP1 RX state machine.

    1. Any partially received data shall be dropped.

  2. All data received outside a frame (if no SOF is received) can be ignored, and may be considered as non-reliable trace messages.

  3. Frames with invalid checksums shall be ignored.

  4. Frames with unknown types shall be ignored.

  5. Unexpected characters shall reset the RX state machine, and it shall wait for the next SOF symbol.

3. MUP1 Frame Types

The following message types are defined:

TYPE NAME Reference Direction

A (0x61)

Announce msg

MUP1 TX ANNOUNCE (0x61)

Server-to-Client

c (0x63)

Coap frame

MUP1 RX CoAP (0x63)

Client-to-Server

C (0x43)

Coap frame

MUP1 TX CoAP (0x43)

Server-to-Client

d (0x64)

DTLS frame

MUP1 RX DTLS (0x64)

Client-to-Server

D (0x44)

DTLS frame

MUP1 TX DTLS (0x44)

Server-to-Client

p (0x70)

Ping request

MUP1 RX Ping (0x70)

Client-to-Server

P (0x50)

Ping response

MUP1 TX Pong (0x50)

Server-to-Client

s (0x73)

Sys request

MUP1 Sys Request (0x73)

Client-to-Server

T (0x54)

Trace msg

MUP1 Trace Message (0x54)

Server-to-Client
The switches running VelocityDRIVE-SP implement the Server role.

3.1. MUP1 TX ANNOUNCE (0x61)

This is only allowed in the direction from the server to the client.

This message is sent immediately upon the booting of the VelocityDRIVE-SP system, indicating that it is ready for use.

The message data follows the same format as the PONG message (see MUP1 TX Pong (0x50)).

3.2. MUP1 RX CoAP (0x63)

This is only allowed in the direction from the Client to the Server.

The DATA field carries the raw content of the CoAP request for the server to process.

Any responses triggered by this request shall be received as MUP1 TX CoAP (0x43) message(s). All timers, re-transmissions, security, and other aspects are handled by CoAP.

3.3. MUP1 TX CoAP (0x43)

This is only allowed in the direction from the Server to the Client.

The DATA field carries the raw content of the CoAP message generated by the server for the client to process.

These response messages are only generated when requested by a MUP1 RX CoAP (0x63) message. All timers, re-transmissions, security, and other aspects are handled by CoAP.

3.4. MUP1 RX DTLS (0x64)

This is only allowed in the direction from the Client to the Server.

The DATA field carries the raw content of the DTLS request for the server to process.

After client and server complete a successful handshake, CoAP frames can be sent from client to server using this DTLS connection.

Any responses triggered by this request shall be received as MUP1 TX DTLS (0x44) message(s). All timers, re-transmissions, security, and other aspects are handled by DTLS and COAP.

3.5. MUP1 TX DTLS (0x44)

This is only allowed in the direction from the Server to the Client.

The DATA field carries the raw content of the DTLS message generated by the server for the client to process.

After client and server complete a successful handshake, CoAP frames can be sent from server to client using this DTLS connection.

These response messages are only generated when requested by a MUP1 RX DTLS (0x64) message. All timers, re-transmissions, security, and other aspects are handled by DTLS and CoAP.

3.6. MUP1 RX Ping (0x70)

This is only allowed in the direction from the Client to the Server.

This message is a ping request which can be used to check if the device is connected and alive.

The DATA field shall be empty (0 bytes).

When a ping request is sent, the device shall respond with a MUP1 TX Pong (0x50) message within 1 second, otherwise it shall be assumed that the device is not present.

If the PC sends more than 1 ping message per second, the device may or may not ignore such requests.

3.7. MUP1 TX Pong (0x50)

This is only allowed in the direction from the Server to the Client.

This message is a ping response which shall be generated when a MUP1 RX Ping (0x70) is processed.

The DATA field carries the build version information, the system uptime, and MUP1 information with the following format:

<SW_VERSION><0x20><UP_TIME><0x20><MUP1_SIZE><0x20><MUP1_VERSION>

Where:

  • <SW_VERSION> is a string.

  • <UP_TIME>: Is a string that must contain system uptime in seconds.

  • <MUP1_SIZE>: Is the max size of the non-escaped DATA field that the MUP1 server is able to handle.

  • <MUP1_VERSION>: Is the version number of the MUP1.

3.8. MUP1 Sys Request (0x73)

The sysreq offers a low-level debug interface where various commands can be triggered. This shall only be implemented in the direction from PC to device.

This packet type is obsolete, and the functions implemented here will be moved to a CoAP server instead.

Due to this, the details are not documented here - if needed, then please request the internal specification.

3.9. MUP1 Trace Message (0x54)

This is used by the device to print textual messages on the console.

The data field is used to carry the message to be displayed.