Internet DRAFT - draft-jharms-slop
draft-jharms-slop
INTERNET-DRAFT Jens Harms
Intended Status: Experimental (no org)
Expires: August 23, 2018 February 19, 2018
serial line open packet protocol - SLOP
draft-jharms-slop-00
Abstract
This memo describes an experimental application level protocol for
data transmission over tcp/ip or other streaming protocols. It is
also useful for data transmission over serial lines such as rs232.
This is an experimental, not recommended standard. Distribution of
this memo is unlimited.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Jens Harms Expires August 23, 2018 [Page 1]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SLOP PROTOCOL . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Example source . . . . . . . . . . . . . . . . . . . . . . 5
2.3. CRC16 checksum functions . . . . . . . . . . . . . . . . . 8
2.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Normative References . . . . . . . . . . . . . . . . . . . 11
5.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Jens Harms Expires August 23, 2018 [Page 2]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
1 Introduction
This document describes a simple and lightweight protocol based on
[RFC1055] (SLIP) for the transmission of data over a serial line.
TCP and UDP are the most used protocols for internet communication.
Because there is no support for structured data many programmer
choose to invent their own protocol. Sometimes they use SLIP to
separate a stream into packets and sometimes they do very strange
things.
To make things simple again, this proposed protocol can be used as a
foundation for other application specific protocols and help
programmer in designing new protocols.
The SLOP protocol is exceptional helpful if it is necessary to debug
an application. For example, you can connect to TCP/IP SLOP protocol
server with telnet and type slop messages with your keyboard and
display the response on your terminal. No special software is
required.
Protocol features:
* Secure detection of beginning and ending of a data chunk
* Control codes are ASCII terminal compatible
* Optional error checking
* Very lightweight and suited for micro-controller
1.1 Terminology
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 [RFC2119].
2. SLOP PROTOCOL
In real world applications SLIP already has shown is usefulness but
also its limitations. The Protocol described here is an independent
rework. It was originally developed to help with micro-controller
development but has show that it helps with the implementation of
communication in large applications.
The SLOP protocol defines two special characters: <END> as decimal 10
(ASCII new line character), <ESC> as decimal 92 (ASCII backslash
character).
In contrast the SLIP protocol defines the two special characters as:
<END> is octal 300 (decimal 192) and <ESC> is octal 333 (decimal 219)
Jens Harms Expires August 23, 2018 [Page 3]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
not to be confused with the ASCII escape character; (RFC1055)
For the purposes of this discussion, <ESC> will indicate the SLOP
<ESC> character and not the ASCII character 27, <END> will indicate
the new line character.
To send a packet, a SLOP host starts sending the <END> character and
then the data in the packet.
If a data byte is the same code as <END> character, a two byte
sequence of <ESC> and decimal 110 ("n" character sequence) is sent
instead.
If it is as an <ESC> character, a two byte sequence of <ESC> and
decimal 95 ("_" character sequence) is sent instead.
When the last byte in the packet has been sent, an <END> character is
then transmitted.
The size of this data block is therefor defined by the sender.
If the sender wishes error detection it can embed a CRC16 checksum
anywhere in the packet data. A CRC16 Checksum starts with a two byte
sequence of <ESC> and decimal 91 ("[" ASCII left square bracket)
followed by a four character hexadecimal encoded CRC16 checksum in
lowercase letters.
SLOP encoded messages will look like strings in the programming
language "C" (the rule of least surprise). And because the newline is
used to terminate an SLOP message, one can easily dump a SLOP
communication onto a terminal or connect a slop server to a terminal.
2.1. Examples
1. The first line shows a simple text, the second line the encoding
of the escape character and the last line shows encoding of an
embedded new line character.
INPUT | OUTPUT
-----------------+------------------------
HelloWorld | <END>HelloWorld<END>
Hello\x1b" | <END>Hello \_"<END>
Hi,<END>there! | <END>Hi,\nthere!<END>
2. These two lines show encoding with embedded crc-16 checksum.
Jens Harms Expires August 23, 2018 [Page 4]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
INPUT | OUTPUT
-----------------+------------------
Hello | <END>Hello\[f353<END>
World | <END>World\[28e4<END>
3. Here is an example where embedded check sums are used as field
delimiter (replacing the space character in the input stream).
INPUT | OUTPUT
-----------------+------------------_
A=1 B=2 C=3 | <END>A=1\[5081B=2\[5131C=3\[51a1<END>
2.2. Example source
<CODE BEGINS>
/* SLOP special character codes
*/
#define END 10 /* indicates end of packet */
#define ESC 92 /* indicates byte stuffing */
#define ESC_END 110 /* ESC ESC_END means END data byte */
#define ESC_ESC 95 /* ESC ESC_ESC means ESC data byte */
#define ESC_CRC 91 /* END CHUNK with CRC CHECK */
/* calculate value from hex ascii code */
uint16_t asctohex(uint16_t val, uint8_t asc) {
if( asc >= 'a' ) asc -= 'a' - 10; else asc -= '0';
return ((uint16_t)(val << 4)) | asc;
}
/* calculate ascii code from upper 4 bit of value */
uint8_t hextoasc(uint16_t val) {
uint8_t asc = val >> 12;
return ( asc > 9 ) ? asc + 'a' - 10 : asc + '0';
}
/* sends a packet located at (p) with (len) bytes, if (with_crc) does
* not equals zero, a crc checksum will be appended. */
void send_packet( char *p, int len, int with_crc )
{
uint16_t crc = crc_init();
/* send an initial END character to flush out any data that may
* have accumulated in the receiver due to line noise
*/
send_char(END);
Jens Harms Expires August 23, 2018 [Page 5]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
/* for each byte in the packet, send the appropriate character
* sequence
*/
while(len--) {
switch(*p) {
/* if it's the same code as an END character, we send a
* special two character code so as not to make the
* receiver think we sent an END
*/
case END:
send_char(ESC);
send_char(ESC_END);
break;
/* if it's the same code as an ESC character,
* we send a special two character code so as not
* to make the receiver think we sent an ESC
*/
case ESC:
send_char(ESC);
send_char(ESC_ESC);
break;
/* otherwise, we just send the character
*/
default:
send_char(*p);
}
crc = crc_update(crc, p, 1 );
p++;
}
if( with_crc ) {
crc=crc_finalize(crc);
send_char( ESC );
send_char( ESC_CRC );
for(int i=0;i<4;i++, crc <<= 4 )
send_char( hextoasc(crc) );
}
/* tell the receiver that we're done sending the packet
*/
send_char(END);
}
/* receives a packet into the buffer located at (p).
* If more than (len) bytes are received, the packet will
Jens Harms Expires August 23, 2018 [Page 6]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
* be truncated.
* Returns 1 - if a crc checksum error occurs
* 2 - if the packet was truncated
* 0 - data correct received
*
* len_return: the number of bytes stored in the buffer.
*/
int recv_packet(char *p, int len, int *len_return)
{
char c;
int received = 0;
uint16_t crc = crc_init();
int error = 0;
uint16_t cs;
/* sit in a loop reading bytes until we put together
* a whole packet.
* Make sure not to copy them into the packet if we
* run out of room.
*/
while(1) {
/* get a character to process
*/
c = recv_char();
/* handle bytestuffing if necessary
*/
switch(c) {
/* if it's an END character then we're done with
* the packet
*/
case END:
if(received) {
*len_return = received;
if( error ) return 1;
if( received > len ) return 2;
return 0;
}
else
break;
/* if it's the same code as an ESC character, wait
* and get another character and then figure out
* what to store in the packet based on that.
*/
case ESC:
c = recv_char();
Jens Harms Expires August 23, 2018 [Page 7]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
/* if "c" is not one of these two, then we
* have a protocol violation. The best bet
* seems to be to leave the byte alone and
* just stuff it into the packet
*/
switch(c) {
case ESC_END:
c = END;
break;
case ESC_ESC:
c = ESC;
break;
case ESC_CRC:
cs=0;
for(int i=0;i<4;i++) cs=asctohex(cs, recv_char());
if( cs != crc ) error = 1;
crc = crc_init();
continue;
}
/* here we fall into the default handler and let
* it store the character for us
*/
default:
if(received < len)
p[received] = c;
received++;
crc = crc_update(crc,&c,1);
}
}
}
<CODE ENDS>
2.3. CRC16 checksum functions
The CRC16 checksum function uses the configuration: Width=16,
Poly=0x8005, XorIn=0, ReflectIn=True, XorOut=0, ReflectOut=True from
the pycrc project <https://pycrc.org>. The source code was generated
with the command:
pycrc.py --width=16 --poly=0x8005 --reflect-in=1 \
--xor-in=0 --reflect-out=1 --xor-out=1 \
--algorithm=bit-by-bit-fast --generate c
<CODE BEGINS>
typedef uint16_t crc_t;
Jens Harms Expires August 23, 2018 [Page 8]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
crc_t crc_init(void)
{
return 0;
}
crc_t crc_reflect(crc_t data, size_t data_len)
{
unsigned int i;
crc_t ret;
ret = data & 0x01;
for (i = 1; i < data_len; i++) {
data >>= 1;
ret = (ret << 1) | (data & 0x01);
}
return ret;
}
crc_t crc_update(crc_t crc, const void *data, size_t data_len)
{
const unsigned char *d = (const unsigned char *)data;
unsigned int i;
bool bit;
unsigned char c;
while (data_len--) {
c = t1_crc_reflect(*d++, 8);
for (i = 0; i < 8; i++) {
bit = crc & 0x8000;
crc = (crc << 1) | ((c >> (7 - i)) & 0x01);
if (bit) {
crc ^= 0x8005;
}
}
crc &= 0xffff;
}
return crc & 0xffff;
}
crc_t crc_finalize(crc_t crc)
{
unsigned int i;
bool bit;
for (i = 0; i < 16; i++) {
Jens Harms Expires August 23, 2018 [Page 9]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
bit = crc & 0x8000;
crc <<= 1;
if (bit) {
crc ^= 0x8005;
}
}
crc = t1_crc_reflect(crc, 16);
return crc & 0xffff;
}
<CODE ENDS>
2.4. Discussion
The CRC16 checksum can be used to separate the packet into fields.
This is very useful for most real world applications because often
application data is packed as a record of fields. If the client needs
to break the packet into fields a second protocol layer is necessary.
With the slop protocol a host can send a CRC checksum after each
field in a record. The client can determine the CRC checksum when it
is receiving a packet and break the packet into fields. For most
implementations it would be useful to define a maximum for the packet
size, currently SLOP does not define such limits, but it could in the
future if it becomes necessary.
Be aware that this protocol only defines packets to be transmitted.
Reactions e.g. on a broken checksum are beyond the scope of this
document.
Jens Harms Expires August 23, 2018 [Page 10]
INTERNET DRAFT serial line open packet protocol - SLOPFebruary 19, 2018
3 Security Considerations
Currently there are no security considerations
4 IANA Considerations
Currently there are no IANA considerations
5 References
5.1 Normative References
[RFC1055] J. Romkey, "A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS
OVER SERIAL LINES: SLIP", RFC 1055, June 1988,
<http://www.rfc-editor.org/info/rfc1055>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
5.2 Informative References
Authors' Addresses
Jens Harms
Drosselweg 1
26603 Aurich
Germany
EMail: au1064@gmail.com
Jens Harms Expires August 23, 2018 [Page 11]
