blob: b878e083993428aa02c25cd201c952c288f0e8b7 [file] [log] [blame]
Internet Engineering Task Force G. D'Amore, Ed.
Intended status: Informational M. Sustrik
Expires: April 29, 2017
October 26, 2016
UDP Mapping for Scalability Protocols
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
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 April 29, 2017.
Copyright Notice
Copyright (c) 2016 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
( 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.
D'Amore & Sustrik Expires April 29, 2017 [Page 1]
Internet-Draft UDP mapping for SPs October 2016
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
There is also no way to pack multiple SP messages into a single UDP
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 | opcode |
| type | reserved |
| payload ...
The first three 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
The first three bytes of the protocol header MUST be set to 0x00,
0x53 and 0x50. If the protocol header received from the peer
differs, the UDP packet 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
D'Amore & Sustrik Expires April 29, 2017 [Page 2]
Internet-Draft UDP mapping for SPs October 2016
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.
3.1. Opcode
The fourth byte is an operation code (opcode), which is used to
indicate a transport-specific type of operation. The following
operations are defined:
0x00 -- DATA: The packet carries SP payload data.
0x01 -- CREQ: The packet requests (initiates) a logical
0x02 -- CACK: The packet confirms creation of a logical
0x03 -- DISC: The packet terminates a logical connection.
It is intended that if the protocol must be revised, that additional
op codes can be assigned, obviating the need for an explicit version
These operation codes are used in the mangement of logical
connections, and are described in more detail in the Logical
Connections section below.
3.2. SP Type
The 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.
3.3. Reserved Field
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.
D'Amore & Sustrik Expires April 29, 2017 [Page 3]
Internet-Draft UDP mapping for SPs October 2016
3.4. Payload
The packet header is followed by the opaque message payload which
spans all the way to the end of the packet. The payload contents are
the SP message content itself, except in the case of DISC messages.
4. Unicast Only
This mapping operates only over Unicast UDP. Messages with source or
destination addresses that are not unicast MUST be discarded.
Furthermore, there is an assumption that bidirectional communication
is possible. Various SP protocols have this requirement anyway.
5. Logical Connections
This mapping of the SP protocols is layered on top of a
connectionless transport layer. However the SP protocols require use
of logical connections in order to pass "connection IDs" in some of
the fields (such as the backtrace information used for the Request/
Reply Scalability Protocol.
Hence it is desirable to create logical connections, and to be able
to ensure that the connections are kept active either by monitoring
activity passively, or by active probing. It is also desirable for a
peer to be able to indicate that it's partner may release resources
used for tracking the connection.
The logical connection itself is still best-effort only, and packets
may be corrupted, lost, or reordered. The packets are also subject
to inspecion, modification, and replay, if the underlying IP
transport is not secured.
5.1. Connection roles
As with other transports like TCP, we intentionally create the notion
of a connection initiator, and a connection accepter. The initator
is always the party who initiates the connection, and is the party
responsible for sending CREQ messages. The accepter is the party
that receives the CREQ messages, and replies with CACK (or possibly
The role of initiator and accepter do not change during the course of
a single logical connection.
D'Amore & Sustrik Expires April 29, 2017 [Page 4]
Internet-Draft UDP mapping for SPs October 2016
5.2. Keeping the Connection Alive
In order to keep session state, implementations will generally store
data for each session. In order to prevent a stale session from
consuming these resources forever, and in order to keep any
intervening state active (e.g. NAT rules), a CACK message may be sent
at any time by the initator.
In the event of an error, the accepter MAY reply with an DISC
message. Otherwise it MUST reply with a CREQ message.
An accepter MUST NOT send a CACK message.
The initiator MUST send CREQ messages every T1 seconds.
An accepter that has not received a CREQ message for at least T2
seconds, or an initiator that has not received a CACK message for at
least T2 seconds, SHOULD assume the connection has failed, and and
may discard any state associated with the logical connection.
It is recommended that T1 and T2 be configurable, with recommended
default values of 30 and 300. This means that sessions that go
inexplicably silent for 5 minutes will be closed, and their resources
Note that values for T1 and T2 must match on both initiator and
accepter for correct operation. Failure to do so will likely result
in permature connection termination.
6. Message Types
6.1. DATA messages
DATA messages (opcode 0x00) are used on an established logical,
connection and, and carry SP messages. The payload part of the
message is the SP payload. Data messages are unacknowledged.
A DATA message that is received by a party which does not have a
corresponding logical connection set up SHOULD be replied to with a
DISC message, using error code 0x04 (not connected).
DATA messages may only be sent on an active connection, and may be
sent at any time by either party.
D'Amore & Sustrik Expires April 29, 2017 [Page 5]
Internet-Draft UDP mapping for SPs October 2016
6.2. CREQ messages
CREQ messages are used to establish a logical connection. The
initiator sends a CREQ message to the listener. On success, the
accepter will record the full UDP source and destination addresses
(including IP addresses and port numbers), creating a local entry in
a list of logical connections.
If this is successful, the accepter MUST respond with an CACK
message. Otherwise it SHOULD respond with an appropriately formed
DISC message. CREQ messages have no payload. A CREQ message may be
sent at any time, and is idempotent. (If the receiver of a CREQ
already has the logical connection established, it need simply reply
with the CACK.
6.3. CACK messages
CACK messages are sent in response to a CREQ, when the connection is
either already established, or after a new connection is established.
As noted above, CREQ is meant to be idempotent, and indeed may be
sent periodically to keep a connection from idling out, and so a CACK
message is also expected to be sent over the network periodically.
6.4. DISC messages
DISC messages are sent by one side of a logical connection to
terminate the logical connection. This notification allows the
remote partner to either terminate an existing connection, such as
when it is shutting down, or to reject a connection attempt made with
DISC messages carry in their payload, a single byte indicating a
reason for the disconnect, along with a human readable reason as an
ASCII byte array. (This MAY not be present, and SHOULD NOT be zero
The following reasons for DISC are defined:
0x00 - normal close of a socket or endpoint
0x01 - connection rejected
0x02 - SP protocol invalid
0x03 - invalid address (such as multicast)
0x04 - not connected
D'Amore & Sustrik Expires April 29, 2017 [Page 6]
Internet-Draft UDP mapping for SPs October 2016
0xff - Other error
7. Latency Considerations
A full round trip is required to establish a logical connection.
However, a particularly optimistic initiator could send a CREQ and a
DATA message in rapid succession, and hope that the DATA was
received. Since these protocols are best effort only, this might not
be a terrible thing to do.
A future extension might be to offer a new opcode, allowing DATA to
be combined with a CREQ or CACK. However, given that typical uses of
these protocols are for long-lived use cases, there does not seem to
be any particular urgency in doing this.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
The mapping isn't intended to provide any additional security in
addition to UDP. If this is a concern, it is recommended that IPsec
or similar approaches be used to secure the underlying transport.
Authors' Addresses
Garrett D'Amore (editor)
Martin Sustrik
D'Amore & Sustrik Expires April 29, 2017 [Page 7]