RFC for UDP transport added

3 files changed, 284 insertions, 2 deletions

diff --git a/rfc/sp-tcp-mapping-01.xml b/rfc/sp-tcp-mapping-01.xml
index d5b81c8..83a0c95 100644
--- a/rfc/sp-tcp-mapping-01.xml
+++ b/rfc/sp-tcp-mapping-01.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="US-ASCII"?>
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
 
-<rfc category="info" docName="sp-tcp-mapping-02">
+<rfc category="info" docName="sp-tcp-mapping-01">
 
   <front>
 
@@ -41,7 +41,7 @@
       <t>This mapping should be layered directly on the top of TCP.</t>
 
       <t>There's no fixed TCP port to use for the communication. Instead, port
-         number are assigned to individual services by the user.</t>
+         numbers are assigned to individual services by the user.</t>
 
     </section>
 
diff --git a/rfc/sp-udp-mapping-01.txt b/rfc/sp-udp-mapping-01.txt
new file mode 100644
index 0000000..7d65b35
--- /dev/null
+++ b/rfc/sp-udp-mapping-01.txt
@@ -0,0 +1,169 @@
+
+
+
+
+Internet Engineering Task Force                          M. Sustrik, Ed.
+Internet-Draft
+Intended status: Informational                            March 24, 2014
+Expires: September 25, 2014
+
+
+                 UDP Mapping for Scalability Protocols
+                           sp-udp-mapping-01
+
+Abstract
+
+   This document defines the UDP mapping for scalability protocols.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on September 25, 2014.
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   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.
+
+
+
+
+
+
+
+Sustrik                Expires September 25, 2014               [Page 1]
+
+Internet-Draft             UDP mapping for SPs                March 2014
+
+
+1.  Underlying protocol
+
+   This mapping should be layered directly on the top of UDP.
+
+   There's no fixed UDP port to use for the communication.  Instead,
+   port numbers are assigned to individual services by the user.
+
+2.  Message delimitation
+
+   Each UDP packet maps to exacrly one SP message.
+
+   There is no way to split one SP message into mutliple UDP packets and
+   therefore SP messages larger than existing path MTU will be dropped
+   silently.
+
+   There is also no way to pack multiple SP messages into a single UDP
+   packet.
+
+3.  Packet layout
+
+   Each packet consists of an 8-byte header followed by the opaque
+   message payload:
+
++------+------+------+--------------+------------+----------------+----------
+| 0x00 | 0x53 | 0x50 | version (8b) | type (16b) | reserved (16b) | payload
++------+------+------+--------------+------------+----------------+----------
+
+   First four bytes of the protocol header are used to make sure that
+   the peer's protocol is compatible with the protocol used by the local
+   endpoint.  Keep in mind that this protocol is designed to run on an
+   arbitrary UDP port, thus the standard compatibility check -- if it
+   runs on port X and protocol Y is assigned to X by IANA, it speaks
+   protocol Y -- does not apply.  We have to use an alternative
+   mechanism.
+
+   First four bytes of the protocol header MUST be set to 0x00, 0x53,
+   0x50 and 0x00 respectively.  If the protocol header received from the
+   peer differs, the UDP packets MUST be ignored.
+
+   The fact that the first byte of the protocol header is binary zero
+   eliminates any text-based protocols that were accidentally connected
+   to the endpiont.  Subsequent two bytes make the check even more
+   rigorous.  At the same time they can be used as a debugging hint to
+   indicate that the connection is supposed to use one of the
+   scalability protocols -- ASCII representation of these bytes is 'SP'
+   that can be easily spotted in when capturing the network traffic.
+   Finally, the fourth byte rules out any incompatible versions of this
+   protocol.
+
+
+
+Sustrik                Expires September 25, 2014               [Page 2]
+
+Internet-Draft             UDP mapping for SPs                March 2014
+
+
+   Fifth and sixth bytes of the header form a 16-bit unsigned integer in
+   network byte order representing the type of SP endpoint on the layer
+   above.  The value SHOULD NOT be interpreted by the mapping, rather
+   the interpretation should be delegated to the scalability protocol
+   above the mapping.  For informational purposes, it should be noted
+   that the field encodes information such as SP protocol ID, protocol
+   version and the role of endpoint within the protocol.  Individual
+   values are assigned by IANA.
+
+   Finally, the last two bytes of the protocol header are reserved for
+   future use and must be set to binary zeroes.  If the protocol header
+   from the peer contains anything else than zeroes in this field, the
+   implementation MUST ignore the UDP packet.
+
+   Packet header is followed by opaque message payload which spans all
+   the way to the end of the packet.
+
+Author's Address
+
+   Martin Sustrik (editor)
+
+   Email: sustrik@250bpm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sustrik                Expires September 25, 2014               [Page 3]
+
diff --git a/rfc/sp-udp-mapping-01.xml b/rfc/sp-udp-mapping-01.xml
new file mode 100644
index 0000000..505461a
--- /dev/null
+++ b/rfc/sp-udp-mapping-01.xml
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="US-ASCII"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+
+<rfc category="info" docName="sp-udp-mapping-01">
+
+  <front>
+
+    <title abbrev="UDP mapping for SPs">
+    UDP Mapping for Scalability Protocols
+    </title>
+
+    <author fullname="Martin Sustrik" initials="M." role="editor"
+            surname="Sustrik">
+      <address>
+        <email>sustrik@250bpm.com</email>
+      </address>
+    </author>
+
+    <date month="March" year="2014" />
+
+    <area>Applications</area>
+    <workgroup>Internet Engineering Task Force</workgroup>
+
+    <keyword>UDP</keyword>
+    <keyword>SP</keyword>
+
+    <abstract>
+      <t>This document defines the UDP mapping for scalability protocols.</t>
+    </abstract>
+
+  </front>
+
+  <middle>
+
+    <section title = "Underlying protocol">
+
+      <t>This mapping should be layered directly on the top of UDP.</t>
+
+      <t>There's no fixed UDP port to use for the communication. Instead, port
+         numbers are assigned to individual services by the user.</t>
+
+    </section>
+
+    <section title = "Message delimitation">
+
+        <t>Each UDP packet maps to exacrly one SP message.</t>
+
+        <t>There is no way to split one SP message into mutliple UDP packets
+           and therefore SP messages larger than existing path MTU will be
+           dropped silently.</t>
+
+        <t>There is also no way to pack multiple SP messages into a single
+           UDP packet.</t>
+
+    </section>
+
+    <section title = "Packet layout">
+
+      <t>Each packet consists of an 8-byte header followed by the opaque
+         message payload:</t>
+
+      <figure>
+        <artwork>
++------+------+------+--------------+------------+----------------+----------
+| 0x00 | 0x53 | 0x50 | version (8b) | type (16b) | reserved (16b) | payload
++------+------+------+--------------+------------+----------------+----------
+        </artwork>
+      </figure>
+
+      <t>First four bytes of the protocol header are used to make sure that
+         the peer's protocol is compatible with the protocol used by the local
+         endpoint. Keep in mind that this protocol is designed to run on an
+         arbitrary UDP port, thus the standard compatibility check -- if it runs
+         on port X and protocol Y is assigned to X by IANA, it speaks protocol Y
+         -- does not apply. We have to use an alternative mechanism.</t>
+
+      <t>First four bytes of the protocol header MUST be set to 0x00, 0x53, 0x50
+         and 0x00 respectively. If the protocol header received from the peer
+         differs, the UDP packets MUST be ignored.</t>
+
+      <t>The fact that the first byte of the protocol header is binary zero
+         eliminates any text-based protocols that were accidentally connected
+         to the endpiont. Subsequent two bytes make the check even more
+         rigorous. At the same time they can be used as a debugging hint to
+         indicate that the connection is supposed to use one of the scalability
+         protocols -- ASCII representation of these bytes is 'SP' that can
+         be easily spotted in when capturing the network traffic. Finally,
+         the fourth byte rules out any incompatible versions of this
+         protocol.</t>
+      
+      <t>Fifth and sixth bytes of the header form a 16-bit unsigned integer in
+         network byte order representing the type of SP endpoint on the layer
+         above. The value SHOULD NOT be interpreted by the mapping, rather
+         the interpretation should be delegated to the scalability protocol
+         above the mapping. For informational purposes, it should be noted that
+         the field encodes information such as SP protocol ID, protocol version
+         and the role of endpoint within the protocol. Individual values are
+         assigned by IANA.</t>
+
+      <t>Finally, the last two bytes of the protocol header are reserved for
+         future use and must be set to binary zeroes. If the protocol header
+         from the peer contains anything else than zeroes in this field, the
+         implementation MUST ignore the UDP packet.</t>
+
+      <t>Packet header is followed by opaque message payload which spans all
+         the way to the end of the packet.</t>
+
+    </section>
+
+  </middle>
+
+</rfc>
+