doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7496.txt b/doc/rfc/rfc7496.txt
new file mode 100644
index 0000000..e301c68
--- /dev/null
+++ b/doc/rfc/rfc7496.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         M. Tuexen
+Request for Comments: 7496              Muenster Univ. of Appl. Sciences
+Category: Standards Track                                  R. Seggelmann
+ISSN: 2070-1721                      Metafinanz Informationssysteme GmbH
+                                                              R. Stewart
+                                                           Netflix, Inc.
+                                                               S. Loreto
+                                                                Ericsson
+                                                              April 2015
+
+
+             Additional Policies for the Partially Reliable
+             Stream Control Transmission Protocol Extension
+
+Abstract
+
+   This document defines two additional policies for the Partially
+   Reliable Stream Control Transmission Protocol (PR-SCTP) extension.
+   These policies allow limitation of the number of retransmissions and
+   prioritization of user messages for more efficient usage of the send
+   buffer.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7496.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 1]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Additional PR-SCTP Policies . . . . . . . . . . . . . . . . .   3
+     3.1.  Limited Retransmissions Policy  . . . . . . . . . . . . .   3
+     3.2.  Priority Policy . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Socket API Considerations . . . . . . . . . . . . . . . . . .   4
+     4.1.  Data Types  . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.2.  Support for Added PR-SCTP Policies  . . . . . . . . . . .   5
+     4.3.  Socket Option for Getting the Stream-Specific PR-SCTP
+           Status (SCTP_PR_STREAM_STATUS)  . . . . . . . . . . . . .   6
+     4.4.  Socket Option for Getting the Association-Specific
+           PR-SCTP Status (SCTP_PR_ASSOC_STATUS) . . . . . . . . . .   7
+     4.5.  Socket Option for Getting and Setting the PR-SCTP Support
+           (SCTP_PR_SUPPORTED) . . . . . . . . . . . . . . . . . . .   8
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 2]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+1.  Introduction
+
+   The Partially Reliable SCTP (PR-SCTP) extension defined in [RFC3758]
+   provides a generic method for senders to abandon user messages.  The
+   decision to abandon a user message is sender side only, and the exact
+   condition is called a "PR-SCTP policy" ([RFC3758] refers to them as
+   "PR-SCTP Services").  [RFC3758] also defines one particular PR-SCTP
+   policy, called "Timed Reliability".  This allows the sender to
+   specify a timeout for a user message after which the SCTP stack
+   abandons the user message.
+
+   This document specifies the following two additional PR-SCTP
+   policies:
+
+   Limited Retransmission Policy:  Allows limitation of the number of
+      retransmissions.
+
+   Priority Policy:  Allows removal of lower-priority messages if space
+      for higher-priority messages is needed in the send buffer.
+
+2.  Conventions
+
+   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].
+
+3.  Additional PR-SCTP Policies
+
+   This section defines two new PR-SCTP policies, one in each
+   subsection.
+
+   Please note that it is REQUIRED to implement [RFC3758], if you want
+   to implement these additional policies.  However, these additional
+   policies are OPTIONAL when implementing [RFC3758].
+
+3.1.  Limited Retransmissions Policy
+
+   Using the Limited Retransmission Policy allows the sender of a user
+   message to specify an upper limit for the number of retransmissions
+   for each DATA chunk of the given user messages.  The sender MUST
+   abandon a user message if the number of retransmissions of any of the
+   DATA chunks of the user message would exceed the provided limit.  The
+   sender MUST perform all other actions required for processing the
+   retransmission event, such as adapting the congestion window and the
+   retransmission timeout.  Please note that the number of
+   retransmissions includes both fast and timer-based retransmissions.
+
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 3]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+   The sender MAY limit the number of retransmissions to 0.  This will
+   result in abandoning the message when it would get retransmitted for
+   the first time.  The use of this setting provides a service similar
+   to UDP, which also does not perform any retransmissions.
+
+   Please note that using this policy does not affect the handling of
+   the thresholds 'Association.Max.Retrans' and 'Path.Max.Retrans' as
+   specified in Section 8 of [RFC4960].
+
+   The WebRTC protocol stack (see [DATA-CHAN]) is an example of where
+   the Limited Retransmissions Policy is used.
+
+3.2.  Priority Policy
+
+   Using the Priority Policy allows the sender of a user message to
+   specify a priority.  When storing a user message in the send buffer
+   while there is not enough available space, the SCTP stack at the
+   sender side MAY abandon other user message(s) of the same SCTP
+   association (with the same or a different stream) with a priority
+   lower than the provided one.  User messages sent reliably are
+   considered to have a priority higher than all messages sent with the
+   Priority Policy.  The algorithm for selecting the message(s) being
+   abandoned is implementation specific.
+
+   After lower-priority messages have been abandoned, high-priority
+   messages can be transferred without the send call blocking (if used
+   in blocking mode) or the send call failing (if used in non-blocking
+   mode).
+
+   The IP Flow Information Export (IPFIX) protocol stack (see [RFC7011])
+   is an example of where the Priority Policy can be used.  Template
+   records would be sent with full reliability, while flow records
+   related to billing, security, and other monitoring would be sent
+   using the Priority Policy with varying priority.  The priority of
+   security-related flow records would be set higher than the priority
+   of monitoring-related flow records.
+
+4.  Socket API Considerations
+
+   This section describes how the socket API defined in [RFC6458] is
+   extended to support the newly defined PR-SCTP policies, to provide
+   some statistical information, and to control the negotiation of the
+   PR-SCTP extension during the SCTP association setup.
+
+   Please note that this section is informational only.
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 4]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+4.1.  Data Types
+
+   This section uses data types from [IEEE.1003-1G.1997]: uintN_t means
+   an unsigned integer of exactly N bits (e.g., uint16_t).  This is the
+   same as in [RFC6458].
+
+4.2.  Support for Added PR-SCTP Policies
+
+   As defined in [RFC6458], the PR-SCTP policy is specified and
+   configured by using the following sctp_prinfo structure:
+
+   struct sctp_prinfo {
+     uint16_t pr_policy;
+     uint32_t pr_value;
+   };
+
+   When the Limited Retransmission Policy described in Section 3.1 is
+   used, pr_policy has the value SCTP_PR_SCTP_RTX and the number of
+   retransmissions is given in pr_value.
+
+   When using the Priority Policy described in Section 3.2, pr_policy
+   has the value SCTP_PR_SCTP_PRIO.  The priority is given in pr_value.
+   The value of zero is the highest priority, and larger numbers in
+   pr_value denote lower priorities.
+
+   The following table summarizes the possible parameter settings
+   defined in [RFC6458] and this document:
+
+     +-------------------+---------------------------+---------------+
+     | pr_policy         | pr_value                  | Specification |
+     +-------------------+---------------------------+---------------+
+     | SCTP_PR_SCTP_NONE | Ignored                   | [RFC6458]     |
+     | SCTP_PR_SCTP_TTL  | Lifetime in ms            | [RFC6458]     |
+     | SCTP_PR_SCTP_RTX  | Number of retransmissions | Section 3.1   |
+     | SCTP_PR_SCTP_PRIO | Priority                  | Section 3.2   |
+     +-------------------+---------------------------+---------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 5]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+4.3.  Socket Option for Getting the Stream-Specific PR-SCTP Status
+      (SCTP_PR_STREAM_STATUS)
+
+   This socket option uses IPPROTO_SCTP as its level and
+   SCTP_PR_STREAM_STATUS as its name.  It can only be used with
+   getsockopt() but not with setsockopt().  The socket option value uses
+   the following structure:
+
+   struct sctp_prstatus {
+     sctp_assoc_t sprstat_assoc_id;
+     uint16_t sprstat_sid;
+     uint16_t sprstat_policy;
+     uint64_t sprstat_abandoned_unsent;
+     uint64_t sprstat_abandoned_sent;
+   };
+
+   sprstat_assoc_id:  This parameter is ignored for one-to-one style
+      sockets.  For one-to-many style sockets, this parameter indicates
+      for which association the user wants the information.  It is an
+      error to use SCTP_{CURRENT|ALL|FUTURE}_ASSOC in sprstat_assoc_id.
+
+   sprstat_sid:  This parameter indicates for which outgoing SCTP stream
+      the user wants the information.
+
+   sprstat_policy:  This parameter indicates for which PR-SCTP policy
+      the user wants the information.  It is an error to use
+      SCTP_PR_SCTP_NONE in sprstat_policy.  If SCTP_PR_SCTP_ALL is used,
+      the counters provided are aggregated over all supported policies.
+
+   sprstat_abandoned_unsent:  The number of user messages that have been
+      abandoned using the policy specified in sprstat_policy on the
+      stream specified in sprstat_sid for the association specified by
+      sprstat_assoc_id, before any part of the user message could be
+      sent.
+
+   sprstat_abandoned_sent:  The number of user messages that have been
+      abandoned using the policy specified in sprstat_policy on the
+      stream specified in sprstat_sid for the association specified by
+      sprstat_assoc_id, after a part of the user message has been sent.
+
+   There are separate counters for unsent and sent user messages because
+   the SCTP_SEND_FAILED_EVENT supports a similar differentiation.
+   Please note that an abandoned large user message requiring SCTP-level
+   fragmentation is reported in the sprstat_abandoned_sent counter as
+   soon as at least one fragment of it has been sent.  Therefore, each
+   abandoned user message is counted in either sprstat_abandoned_unsent
+   or sprstat_abandoned_sent.
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 6]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+   If more detailed information about abandoned user messages is
+   required, the subscription to the SCTP_SEND_FAILED_EVENT is
+   recommended.  Please note that some implementations might choose not
+   to support this option, since it increases the resources needed for
+   an outgoing SCTP stream.  For the same reasons, some implementations
+   might only support using SCTP_PR_SCTP_ALL in sprstat_policy.
+
+   sctp_opt_info() needs to be extended to support
+   SCTP_PR_STREAM_STATUS.
+
+4.4.  Socket Option for Getting the Association-Specific PR-SCTP Status
+      (SCTP_PR_ASSOC_STATUS)
+
+   This socket option uses IPPROTO_SCTP as its level and
+   SCTP_PR_ASSOC_STATUS as its name.  It can only be used with
+   getsockopt(), but not with setsockopt().  The socket option value
+   uses the same structure as described in Section 4.3:
+
+   struct sctp_prstatus {
+     sctp_assoc_t sprstat_assoc_id;
+     uint16_t sprstat_sid;
+     uint16_t sprstat_policy;
+     uint64_t sprstat_abandoned_unsent;
+     uint64_t sprstat_abandoned_sent;
+   };
+
+   sprstat_assoc_id:  This parameter is ignored for one-to-one style
+      sockets.  For one-to-many style sockets, this parameter indicates
+      for which association the user wants the information.  It is an
+      error to use SCTP_{CURRENT|ALL|FUTURE}_ASSOC in sprstat_assoc_id.
+
+   sprstat_sid:  This parameter is ignored.
+
+   sprstat_policy:  This parameter indicates for which PR-SCTP policy
+      the user wants the information.  It is an error to use
+      SCTP_PR_SCTP_NONE in sprstat_policy.  If SCTP_PR_SCTP_ALL is used,
+      the counters provided are aggregated over all supported policies.
+
+   sprstat_abandoned_unsent:  The number of user messages that have been
+      abandoned using the policy specified in sprstat_policy for the
+      association specified by sprstat_assoc_id, before any part of the
+      user message could be sent.
+
+   sprstat_abandoned_sent:  The number of user messages that have been
+      abandoned using the policy specified in sprstat_policy for the
+      association specified by sprstat_assoc_id, after a part of the
+      user message has been sent.
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 7]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+   There are separate counters for unsent and sent user messages because
+   the SCTP_SEND_FAILED_EVENT supports a similar differentiation.
+   Please note that an abandoned large user message requiring SCTP-level
+   fragmentation is reported in the sprstat_abandoned_sent counter as
+   soon as at least one fragment of it has been sent.  Therefore, each
+   abandoned user message is counted in either sprstat_abandoned_unsent
+   or sprstat_abandoned_sent.
+
+   If more detailed information about abandoned user messages is
+   required, the usage of the option described in Section 4.3 or the
+   subscription to the SCTP_SEND_FAILED_EVENT is recommended.
+
+   sctp_opt_info() needs to be extended to support SCTP_PR_ASSOC_STATUS.
+
+4.5.  Socket Option for Getting and Setting the PR-SCTP Support
+      (SCTP_PR_SUPPORTED)
+
+   This socket option allows the enabling or disabling of the
+   negotiation of PR-SCTP support for future associations.  For existing
+   associations, it allows one to query whether or not PR-SCTP support
+   was negotiated on a particular association.
+
+   Whether or not PR-SCTP is enabled by default is implementation
+   specific.
+
+   This socket option uses IPPROTO_SCTP as its level and
+   SCTP_PR_SUPPORTED as its name.  It can be used with getsockopt() and
+   setsockopt().  The socket option value uses the following structure
+   defined in [RFC6458]:
+
+   struct sctp_assoc_value {
+     sctp_assoc_t assoc_id;
+     uint32_t assoc_value;
+   };
+
+   assoc_id:  This parameter is ignored for one-to-one style sockets.
+      For one-to-many style sockets, this parameter indicates upon which
+      association the user is performing an action.  The special
+      sctp_assoc_t SCTP_FUTURE_ASSOC can also be used; it is an error to
+      use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
+
+   assoc_value:  A non-zero value encodes the enabling of PR-SCTP,
+      whereas a value of 0 encodes the disabling of PR-SCTP.
+
+   sctp_opt_info() needs to be extended to support SCTP_PR_SUPPORTED.
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 8]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+5.  Security Considerations
+
+   This document does not add any security considerations to those given
+   in [RFC4960], [RFC3758], and [RFC6458].  As indicated in the Security
+   Considerations of [RFC3758], transport-layer security in the form of
+   TLS over SCTP (see [RFC3436]) can't be used for PR-SCTP.  However,
+   DTLS over SCTP (see [RFC6083]) could be used instead.  If DTLS over
+   SCTP as specified in [RFC6083] is used, the Security Considerations
+   of [RFC6083] do apply.  It should also be noted that using PR-SCTP
+   for an SCTP association doesn't allow that association to behave more
+   aggressively than an SCTP association not using PR-SCTP.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+              Conrad, "Stream Control Transmission Protocol (SCTP)
+              Partial Reliability Extension", RFC 3758, May 2004,
+              <http://www.rfc-editor.org/info/rfc3758>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, September 2007,
+              <http://www.rfc-editor.org/info/rfc4960>.
+
+6.2.  Informative References
+
+   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
+              Layer Security over Stream Control Transmission Protocol",
+              RFC 3436, December 2002,
+              <http://www.rfc-editor.org/info/rfc3436>.
+
+   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
+              Transport Layer Security (DTLS) for Stream Control
+              Transmission Protocol (SCTP)", RFC 6083, January 2011,
+              <http://www.rfc-editor.org/info/rfc6083>.
+
+   [RFC6458]  Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
+              Yasevich, "Sockets API Extensions for the Stream Control
+              Transmission Protocol (SCTP)", RFC 6458, December 2011,
+              <http://www.rfc-editor.org/info/rfc6458>.
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                    [Page 9]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
+              "Specification of the IP Flow Information Export (IPFIX)
+              Protocol for the Exchange of Flow Information", STD 77,
+              RFC 7011, September 2013,
+              <http://www.rfc-editor.org/info/rfc7011>.
+
+   [DATA-CHAN]
+              Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
+              Channels", Work in Progress, draft-ietf-rtcweb-data-
+              channel-13, January 2015.
+
+   [IEEE.1003-1G.1997]
+              IEEE, "Protocol Independent Interfaces", IEEE Standard
+              1003.1G, March 1997.
+
+Acknowledgments
+
+   The authors wish to thank Benoit Claise, Spencer Dawkins, Gorry
+   Fairhurst, Stephen Farrell, Barry Leiba, Karen Egede Nielsen,
+   Ka-Cheong Poon, Dan Romascanu, Irene Ruengeler, Jamal Hadi Salim,
+   Joseph Salowey, Brian Trammell, and Vlad Yasevich for their
+   invaluable comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                   [Page 10]
+
+RFC 7496               Additional PR-SCTP Policies            April 2015
+
+
+Authors' Addresses
+
+   Michael Tuexen
+   Muenster University of Applied Sciences
+   Stegerwaldstrasse 39
+   48565 Steinfurt
+   Germany
+
+   EMail: tuexen@fh-muenster.de
+
+
+   Robin Seggelmann
+   Metafinanz Informationssysteme GmbH
+   Leopoldstrasse 146
+   80804 Muenchen
+   Germany
+
+   EMail: rfc@robin-seggelmann.com
+
+
+   Randall R. Stewart
+   Netflix, Inc.
+   Chapin, SC  29036
+   United States
+
+   EMail: randall@lakerest.net
+
+
+   Salvatore Loreto
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Salvatore.Loreto@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuexen, et al.               Standards Track                   [Page 11]
+