1 files changed, 169 insertions, 0 deletions
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]
+