Advanced Message Queuing Protocol (AMQP) Binding to the Stream Control Transmission Protocol

Advanced Message Queuing Protocol (AMQP) Binding to the Stream Control Transmission Protocol (SCTP) Version 1.0

Working Draft 01

26 August 2013

Technical Committee:

OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC

Chair:

Steve Huston (), Individual

Editors:

Steve Huston (), Individual

Paul Knight (), Individual

Matthew Arrott (), Individual

other – Rob Godfrey?

Additional artifacts:

This prose specification is one component of a Work Product that also includes:

• XML schemas:(list file names or directory name)
• Other parts (list titles and/or file names)

Related work:

This specification is related to:

• OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0. 29 October 2012. OASIS Standard.
• Stream Control Transmission Protocol. September 2007. IETF RFC4960.

Abstract:

This specification describes an approach to transporting AMQP messages over the SCTP transport layer protocol, RFC 4960. The binding interface maps the AMQP connection to the SCTP Association and maps the AMQP Channel to the SCTP Stream.

Status:

This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

Initial URI pattern:

(Managed by OASIS TC Administration; please don’t modify.)

Copyright © OASIS Open 2013. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Table of Contents

1Introduction

1.1 Terminology

1.2 Normative References

1.3 Non-Normative References

2AMQP and SCTP discussion

2.1 AMQP

2.2 SCTP

2.2.1 SCTP description

2.2.1.1 Basic SCTP Features

2.2.1.2 SCTP DATA Exchange Features

2.2.2 SCTP comparison to TCP and UDP

2.3 Use cases for AMQP over SCTP

2.3.1 Buyer negotiating price/quantity with multiple sellers

2.3.1.1 Level 4 section title is usually deepest for Table of Contents

3AMQP binding to SCTP

3.1 Mapping/binding mechanism

3.2 Security

4# Conformance

Appendix A.Acknowledgments

Appendix B.Revision History

amqp-sctp-v1.0-wd01Working Draft 0126 August2013

Standards Track DraftCopyright © OASIS Open 2013. All Rights Reserved.Page 1 of 14

1Introduction

This document specifies a method of binding or mapping the Advanced Message Queuing Protocol [AMQP] to the Stream Control Transmission Protocol [SCTP], an Internet Protocol (IP) transport protocol which provides capabilities not supported by the more commonly used alternatives, the Transmission Control Protocol [TCP] or the User Datagram Protocol [UDP].

This document is organized as follows:

Section 2 provides a non-normative discussion of AMQP and SCTP, including their attributes relevant to the specified bindings or mappings, and also provides descriptive use cases.

Section 3 provides a normative description and details of the mappings or bindings.The current Section 3 may be expanded to multiple sections as needed, covering items like:

• Security
• Reliability
• Performance
• (please suggest others)

1.1Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

References to the citations in the Normative References or Non-Normative References sections appear within brackets. References to other Internet-based resources are identified with complete visible hyperlinks enclosed in parentheses.

Text in red indicates commentary on areas in this document which require additional work, and should all be removed before publication at the OASIS Committee Specification level.

1.2Normative References

[RFC2119]Bradner, S.,“Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[AMQP]OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0. 29 October 2012. OASIS Standard.

[amqp-pt1-types]OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0 Part 1: Types. 29 October 2012. OASIS Standard.

[amqp-pt2-transport]OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0 Part 2: Transport. 29 October 2012. OASIS Standard.

[amqp-pt3-messaging]OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0 Part 3: Messaging. 29 October 2012. OASIS Standard.

[amqp-pt4-transactions]OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0 Part 4: Transactions. 29 October 2012. OASIS Standard.

[amqp-pt5-security]OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0 Part 5: Security. 29 October 2012. OASIS Standard.

[RFC4960]R. Stewart, ed., “Stream Control Transmission Protocol”, RFC 4960, September 2007.

[RFC6096]M. Tuexen, R. Stewart, “Stream Control Transmission Protocol (SCTP) Chunk Flags Registration”, RFC6096, January 2011.

[TCP]Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[UDP]Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.

[Reference] [Full reference citation]

1.3Non-Normative References

[RFC3286]L. Ong, J. Yoakum, “An Introduction to the Stream Control Transmission Protocol (SCTP)”, RFC 3286, May 2002.

[SCTP-Ref]Stream Control Transmission Protocol (SCTP): A Reference Guide. Randall R. Stewart, Qiaobing Xie. Addison-Wesley, 2002. ISBN 0-201-72186-4.

[Reference] [Full reference citation]

2AMQP and SCTP discussion

All text in this section, including subsections, is non-normative.

2.1AMQP

AMQP is defined in a multi-part specification, and the parts of AMQP which are of most interest within the present work are the Transport [amqp-pt2-transport] and Messaging [amqp-pt3-messaging] parts.

Although SCTP is mentioned in passing in the AMQP specification, the use of TCP [TCP]is typically assumed, with detailed specifications for version negotiation ( and connection handling (

SCTP-focused versions of the existing TCP-centric material in the AMQP specification will be developed in the normative sections below.

2.2SCTP

2.2.1SCTP description

Text from RFC3286, to be edited and focused as needed:

2.2.1.1Basic SCTP Features

SCTP is a unicast protocol, and supports data exchange between

exactly 2 endpoints, although these may be represented by multiple IP

addresses.

SCTP provides reliable transmission, detecting when data is

discarded, reordered, duplicated or corrupted, and retransmitting

damaged data as necessary. SCTP transmission is full duplex.

SCTP is message oriented and supports framing of individual message

boundaries. In comparison, TCP is byte oriented and does not

preserve any implicit structure within a transmitted byte stream

without enhancement.

SCTP is rate adaptive similar to TCP, and will scale back data

transfer to the prevailing load conditions in the network. It is

designed to behave cooperatively with TCP sessions attempting to use

the same bandwidth.

The name Stream Control Transmission Protocol is derived from the

multi-streaming function provided by SCTP. This feature allows data

to be partitioned into multiple streams that have the property of

independently sequenced delivery, so that message loss in any one

stream will only initially affect delivery within that stream, and

not delivery in other streams.

In contrast, TCP assumes a single stream of data and ensures that

delivery of that stream takes place with byte sequence preservation.

While this is desirable for delivery of a file or record, it causes

additional delay when message loss or sequence error occurs within

the network. When this happens, TCP must delay delivery of data

until the correct sequencing is restored, either by receipt of an

out-of-sequence message, or by retransmission of a lost message.

[…]

SCTP accomplishes multi-streaming by creating independence between

data transmission and data delivery. In particular, each payload

DATA "chunk" in the protocol uses two sets of sequence numbers, a

Transmission Sequence Number that governs the transmission of

messages and the detection of message loss, and the Stream ID/Stream

Sequence Number pair, which is used to determine the sequence of

delivery of received data.

This independence of mechanisms allows the receiver to determine

immediately when a gap in the transmission sequence occurs (e.g., due

to message loss), and also whether or not messages received following

the gap are within an affected stream. If a message is received

within the affected stream, there will be a corresponding gap in the

Stream Sequence Number, while messages from other streams will not

show a gap. The receiver can therefore continue to deliver messages

to the unaffected streams while buffering messages in the affected

stream until retransmission occurs.

Another core feature of SCTP is multi-homing, or the ability for a

single SCTP endpoint to support multiple IP addresses. The benefit

of multi-homing is potentially greater survivability of the session

in the presence of network failures.

2.2.1.2SCTP DATA Exchange Features

DATA chunk exchange in SCTP follows TCP's Selective ACK procedure.

Receipt of DATA chunks is acknowledged by sending SACK chunks, which

indicate not only the cumulative Transmission Sequence Number (TSN)

range received, but also any non-cumulative TSNs, implying gaps in

the received TSN sequence. Following TCP procedures, SACKs are sent

using the "delayed ack" method, normally one SACK per every other

received packet, but with an upper limit on the delay between SACKs

and an increase to once per received packet when there are gaps

detected.

Flow and Congestion Control follow TCP algorithms. The advertised

receive window indicates buffer occupancy at the receiver, while a

per-path congestion window is maintained to manage the packets in

flight. Slow start, Congestion avoidance, Fast recovery and Fast

retransmit are incorporated into the procedures as described in RFC

2581, with the one change being that the endpoints must manage the

conversion between bytes sent and received and TSNs sent and

received, since TSN is per chunk rather than per byte.

The application can specify a lifetime for data to be transmitted, so

that if the lifetime has expired and the data has not yet been

transmitted, it can be discarded (e.g., time-sensitive signaling

messages). If the data has been transmitted, it must continue to be

delivered to avoid creating a hole in the TSN sequence.

Other topics:

SCTP Shutdown Features

SCTP Message Format

Error handling- retransmission, path failure, endpoint failure

2.2.2SCTP comparison to TCP and UDP

Raw text from RFC3286:

Like TCP, SCTP provides a reliable transport service, ensuring that

data is transported across the network without error and in sequence.

Like TCP, SCTP is a session-oriented mechanism, meaning that a

relationship is created between the endpoints of an SCTP association

prior to data being transmitted, and this relationship is maintained

until all data transmission has been successfully completed.

Unlike TCP, SCTP provides a number of functions that are critical for

telephony signaling transport, and at the same time can potentially

benefit other applications needing transport with additional

performance and reliability.

The name Stream Control Transmission Protocol is derived from the

multi-streaming function provided by SCTP. This feature allows data

to be partitioned into multiple streams that have the property of

independently sequenced delivery, so that message loss in any one

stream will only initially affect delivery within that stream, and

not delivery in other streams.

In contrast, TCP assumes a single stream of data and ensures that

delivery of that stream takes place with byte sequence preservation.

While this is desirable for delivery of a file or record, it causes

additional delay when message loss or sequence error occurs within

the network. When this happens, TCP must delay delivery of data

until the correct sequencing is restored, either by receipt of an

out-of-sequence message, or by retransmission of a lost message.

2.3Use cases for AMQP over SCTP

This section provides a non-normative description of one or more use cases to provide the motivation for this specification.

The use cases identified to date include:

• buyer negotiating price and/or quantity with multiple sellers
• need more use cases

2.3.1Buyer negotiating price/quantity with multiple sellers

text

2.3.1.1Level 4 section title is usually deepest for Table of Contents

text

2.3.1.1.1Level 5 or deeper may be included in TOC with TC approval

text

3AMQP binding to SCTP

This section contains the normative description of binding mechanisms.

(Likely points, from email)

AMQP over SCTP binding specification layers AMQP messages over the SCTP transport layer protocol, RFC 4960 and RFC 3286. The binding interface maps the AMQP connection to the SCTP Association and the AMQP Channel to the SCTP Stream. The SCTP Message contains the content of the AMQP Frame Body. SCTP Stream “0” is designated as a reserved control stream between the AMQP Connection End Points to carry the AMQP Protocol headers, SASL Frames, Connection Open and Close performatives.

3.1Mapping/binding mechanism

straw-man for the SCTP mapping:

An AMQP Connection maps to an SCTP Association, an AMQP Channel maps to an SCTP Stream.

AMQP Framing is not used for the SCTP Mapping. The SCTP Message contains the contents of the AMQP Frame Body.

We register two Payload Protocol Identifiers one for “AMQP 1.0 Frame” and one for “AMQP SASL 1.0 Frame” (identifiers to be provided by IANA).

Protocol Headers will be sent with Payload Protocol Identifier 0.

Protocol Headers, SASL frames and the open and close performatives MUST be sent on stream 0.

AMQP frames received on streams other than stream 0 MUST be buffered until an open performative has been received on stream 0. Implementations SHOULD limit the number of frames that can be buffered and close the connection with an appropriate error code if the buffer is filled and no open has been received.

On receiving a close performative on stream 0, an implementation MAY choose to continue reading messages until no more data is incoming. An implementation SHOULD limit the number of frames that it reads after receiving a close.

In the open performative:

• the max-frame-size MUST be no greater than the negotiated maximum message size of the SCTP association
• channel-max MUST be no greater than the negotiated maximum stream number negotiated for the SCTP association
• idle-time-out MUST NOT be set

We should provide guidance on setting the maximum message size relative to the socket buffer size.

3.2Security

Describe what security protocols are needed and why.

The TLS security layer defined in Section 5.2 is not supported for SCTP

SASL Mechanisms which provide an encryption layer are not supported for SCTP

Q: What about replacing SASL & TLS w/ DTLS under SCTP as their replacement, given SCTP does not support them?

A: So, DTLS would not completely replace SASL - presuming you might still want to use username/password authentication on SCTP.

(text from email, needs cleaning: )

In terms of replacing SSL/TLS, it would certainly replace the case where the entire AMQP protocol is tunneled over TLS... In my comment about section 5.2 I was specifically referring to the mechanism where we do a “TLS upgrade” on an AMQP Connection which initially starts as pure AMQP (i.e. the first bytes on the wire are AMQPx2x1x0x0 rather than the TLS header. As far as I know no-one has actually implemented this layer anyway, and it does not seem it would be appropriate for DTLS.

4Conformance

The last numbered section in the specification must be the Conformance section. Conformance Statements/Clauses go here.

(Conformance must be in place before first OASIS-managed Public Review)

Appendix A.Acknowledgments

The following individuals are members of the OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC as the date of this publication.

Those who have participated in the creation of this specification are gratefully acknowledged.

TC Members:

The TC would also like to gratefully acknowledge the support and advice of Randall Stewart, co-author of the SCTP specification.

Appendix B.Revision History

amqp-sctp-v1.0-wd01Working Draft 0126 August2013

Standards Track DraftCopyright © OASIS Open 2013. All Rights Reserved.Page 1 of 14