| <?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> |
| |