

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]