rfc/sp-udp-mapping-01.xml

<?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 exactly one SP message.</t>

        <t>There is no way to split one SP message into multiple 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>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x00     |      0x53     |      0x50     |    version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             type              |           reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        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 sending
         to the endpoint. 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>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The mapping isn't intended to provide any additional security in
         addition to what UDP does.</t>
    </section>

  </middle>

</rfc>