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: as decimal 10 (ASCII new line character), as decimal 92 (ASCII backslash character). In contrast the SLIP protocol defines the two special characters as: is octal 300 (decimal 192) and 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, will indicate the SLOP character and not the ASCII character 27, will indicate the new line character. To send a packet, a SLOP host starts sending the character and then the data in the packet. If a data byte is the same code as character, a two byte sequence of and decimal 110 ("n" character sequence) is sent instead. If it is as an character, a two byte sequence of and decimal 95 ("_" character sequence) is sent instead. When the last byte in the packet has been sent, an 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 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 | HelloWorld Hello\x1b" | Hello \_" Hi,there! | Hi,\nthere! 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 | Hello\[f353 World | World\[28e4 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 | A=1\[5081B=2\[5131C=3\[51a1 2.2. Example source /* 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); } } } 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 . 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 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; } 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 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]