| |
| |
| |
| |
| Internet Engineering Task Force G. D'Amore, Ed. |
| Internet-Draft |
| Intended status: Informational M. Sustrik |
| Expires: April 29, 2017 |
| October 26, 2016 |
| |
| |
| 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 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 |
| (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. |
| |
| |
| |
| |
| |
| |
| 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 |
| 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 | 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 |
| mechanism. |
| |
| 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 |
| connection. |
| |
| 0x02 -- CACK: The packet confirms creation of a logical |
| connection. |
| |
| 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 |
| field. |
| |
| 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 |
| DISC). |
| |
| 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 |
| reclaimed. |
| |
| 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 |
| CREQ. |
| |
| 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 |
| terminated.) |
| |
| 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) |
| |
| Email: garrett@damore.org |
| |
| |
| Martin Sustrik |
| |
| Email: sustrik@250bpm.com |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| D'Amore & Sustrik Expires April 29, 2017 [Page 7] |