blob: 6585b62cd33e9340a1af9745b0e62df32025c265 [file] [log] [blame]
Internet Engineering Task Force M. Sustrik, Ed.
Intended status: Informational May 4, 2014
Expires: November 5, 2014
Publish/Subscribe Scalability Protocol
This document defines a scalability protocol used for distributing
data to arbitrary number of subscriber nodes.
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 November 5, 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
( 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 November 5, 2014 [Page 1]
Internet-Draft Publish/Subscribe SP May 2014
1. Introduction
2. Underlying protocol
The publish/subscribe protocol can be run on top of any SP mapping,
such as, for example, SP TCPmapping [SPoverTCP].
Also, given that SP protocols describe the behaviour of entire
arbitrarily complex topology rather than of a single node-to-node
communication, several underlying protocols can be used in parallel.
For example, publisher can send a message to intermediary node via
TCP. The intermediate node can then forward the message via PGM etc.
+---+ TCP +---+ PGM +---+
| |----------->| |---------->| |
+---+ +---+ +---+
| PGM +---+
+------------>| |
3. Overview of the algorithm
4. Hop-by-hop vs. End-to-end
5. Hop-by-hop functionality
5.1. PUB endpoint
5.2. SUB endpoint
6. End-to-end functionality
End-to-end functionality is built on top of hop-to-hop functionality.
Thus, an endpoint on the edge of a topology contains all the hop-by-
hop functionality, but also implements additional functionality of
Sustrik Expires November 5, 2014 [Page 2]
Internet-Draft Publish/Subscribe SP May 2014
its own. This end-to-end functionality acts basically as a user of
the underlying hop-by-hop functionality.
6.1. PUB endpoint
6.2. SUB endpoint
7. Loop avoidance
TODO: Do we want any loop avoidance in PUB/SUB?
8. IANA Considerations
New SP endpoint types PUB and SUB should be registered by IANA. For
now, value of 32 should be used for PUB endpoints and value of 33 for
SUB endpoints.
IANA should eventually also register and issue numbers for different
message matching algorithms.
9. Security Considerations
The mapping is not intended to provide any additional security to the
underlying protocol. DoS concerns are addressed within the
10. References
Sustrik, M., "TCP mapping for SPs", August 2013.
Author's Address
Martin Sustrik (editor)
Sustrik Expires November 5, 2014 [Page 3]