| |
| |
| |
| |
| Internet Engineering Task Force M. Sustrik, Ed. |
| Internet-Draft |
| Intended status: Informational March 2014 |
| Expires: September 2, 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 2, 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 2, 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 exactly one SP message. |
| |
| 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. |
| |
| 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: |
| |
| 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 ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+- |
| |
| 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 sending to |
| the endpoint. Subsequent two bytes make the check even more |
| |
| |
| |
| Sustrik Expires September 2, 2014 [Page 2] |
| |
| Internet-Draft UDP mapping for SPs March 2014 |
| |
| |
| 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. |
| |
| 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. |
| |
| 4. IANA Considerations |
| |
| This memo includes no request to IANA. |
| |
| 5. Security Considerations |
| |
| The mapping isn't intended to provide any additional security in |
| addition to what UDP does. |
| |
| Author's Address |
| |
| Martin Sustrik (editor) |
| |
| Email: sustrik@250bpm.com |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Sustrik Expires September 2, 2014 [Page 3] |
| |