doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc7829.txt b/doc/rfc/rfc7829.txt
new file mode 100644
index 0000000..5d8bd50
--- /dev/null
+++ b/doc/rfc/rfc7829.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        Y. Nishida
+Request for Comments: 7829                            GE Global Research
+Category: Standards Track                                   P. Natarajan
+ISSN: 2070-1721                                            Cisco Systems
+                                                                 A. Caro
+                                                        BBN Technologies
+                                                                 P. Amer
+                                                  University of Delaware
+                                                              K. Nielsen
+                                                                Ericsson
+                                                              April 2016
+
+
+              SCTP-PF: A Quick Failover Algorithm for the
+                  Stream Control Transmission Protocol
+
+Abstract
+
+   The Stream Control Transmission Protocol (SCTP) supports multihoming.
+   However, when the failover operation specified in RFC 4960 is
+   followed, there can be significant delay and performance degradation
+   in the data transfer path failover.  This document specifies a quick
+   failover algorithm and introduces the SCTP Potentially Failed
+   (SCTP-PF) destination state in SCTP Path Management.
+
+   This document also specifies a dormant state operation of SCTP that
+   is required to be followed by an SCTP-PF implementation, but it may
+   equally well be applied by a standard SCTP implementation, as
+   described in RFC 4960.
+
+   Additionally, this document introduces an alternative switchback
+   operation mode called "Primary Path Switchover" that will be
+   beneficial in certain situations.  This mode of operation applies to
+   both a standard SCTP implementation and an SCTP-PF implementation.
+
+   The procedures defined in the document require only minimal
+   modifications to the specification in RFC 4960.  The procedures are
+   sender-side only and do not impact the SCTP receiver.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                    [Page 1]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+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/rfc7829.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                    [Page 2]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
+   3.  SCTP with Potentially Failed (SCTP-PF) Destination State  . .   5
+     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.2.  Specification of the SCTP-PF Procedures . . . . . . . . .   6
+   4.  Dormant State Operation . . . . . . . . . . . . . . . . . . .  10
+     4.1.  SCTP Dormant State Procedure  . . . . . . . . . . . . . .  11
+   5.  Primary Path Switchover . . . . . . . . . . . . . . . . . . .  11
+   6.  Suggested SCTP Protocol Parameter Values  . . . . . . . . . .  13
+   7.  Socket API Considerations . . . . . . . . . . . . . . . . . .  13
+     7.1.  Support for the Potentially Failed Path State . . . . . .  14
+     7.2.  Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket
+           Option  . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     7.3.  Exposing the Potentially Failed Path State
+           (SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option  . .  16
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
+   9.  MIB Considerations  . . . . . . . . . . . . . . . . . . . . .  17
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  17
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  18
+   Appendix A.  Discussion of Alternative Approaches . . . . . . . .  20
+     A.1.  Reduce PMR  . . . . . . . . . . . . . . . . . . . . . . .  20
+     A.2.  Adjust RTO-Related Parameters . . . . . . . . . . . . . .  21
+   Appendix B.  Discussion of the Path-Bouncing Effect . . . . . . .  21
+   Appendix C.  SCTP-PF for SCTP Single-Homed Operation  . . . . . .  22
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23
+
+1.  Introduction
+
+   The Stream Control Transmission Protocol (SCTP) specified in
+   [RFC4960] supports multihoming at the transport layer.  SCTP's
+   multihoming features include failure detection and failover
+   procedures to provide network interface redundancy and improved end-
+   to-end fault tolerance.  In SCTP's current failure detection
+   procedure, the sender must experience Path.Max.Retrans (PMR) number
+   of consecutive failed timer-based retransmissions on a destination
+   address before detecting a path failure.  Until detecting the path
+   failure, the sender continues to transmit data on the failed path.
+   The prolonged time in which SCTP as described in [RFC4960] continues
+   to use a failed path severely degrades the performance of the
+   protocol.  To address this problem, this document specifies a quick
+   failover algorithm called "SCTP-PF" based on the introduction of a
+   new Potentially Failed (PF) path state in SCTP path management.  The
+
+
+
+
+
+Nishida, et al.              Standards Track                    [Page 3]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+   performance deficiencies of the failover operation described in RFC
+   4960, and the improvements obtainable from the introduction of a PF
+   state in SCTP, were proposed and documented in [NATARAJAN09] for
+   Concurrent Multipath Transfer SCTP [IYENGAR06].
+
+   While SCTP-PF can accelerate the failover process and improve
+   performance, the risk that an SCTP endpoint might enter the dormant
+   state where all destination addresses are inactive can be increased.
+   [RFC4960] leaves the protocol operation during dormant state to
+   implementations and encourages avoiding entering the state as much as
+   possible by careful tuning of the PMR and Association.Max.Retrans
+   (AMR) parameters.  We specify a dormant state operation for SCTP-PF,
+   which makes SCTP-PF provide the same disruption tolerance as
+   [RFC4960] despite the fact that the dormant state may be entered more
+   quickly.  The dormant state operation may equally well be applied by
+   an implementation of [RFC4960] and will serve here to provide added
+   fault tolerance for situations where the tuning of the PMR and AMR
+   parameters fail to provide adequate prevention of the entering of the
+   dormant state.
+
+   The operation after the recovery of a failed path also impacts the
+   performance of the protocol.  With the procedures specified in
+   [RFC4960], SCTP will (after a failover from the primary path) switch
+   back to use the primary path for data transfer as soon as this path
+   becomes available again.  From a performance perspective, such a
+   forced switchback of the data transmission path can be suboptimal as
+   the Congestion Window (CWND) towards the original primary destination
+   address has to be rebuilt once data transfer resumes, [CARO02].  As
+   an optional alternative to the switchback operation of [RFC4960],
+   this document specifies an alternative Primary Path Switchover
+   procedure that avoids such forced switchbacks of the data transfer
+   path.  The Primary Path Switchover operation was originally proposed
+   in [CARO02].
+
+   While SCTP-PF is primarily motivated by a desire to improve the
+   multihomed operation, the feature also applies to SCTP single-homed
+   operation.  Here the algorithm serves to provide increased failure
+   detection on idle associations, whereas the failover or switchback
+   aspects of the algorithm will not be activated.  This is discussed in
+   more detail in Appendix C.
+
+   A brief description of the motivation for the introduction of the PF
+   state, including a discussion of alternative approaches to mitigate
+   the deficiencies of the failover operation in [RFC4960], are given in
+   the appendices.  Discussion of path-bouncing effects that might be
+   caused by frequent switchovers are also provided there.
+
+
+
+
+
+Nishida, et al.              Standards Track                    [Page 4]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+2.  Conventions and Terminology
+
+   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.  SCTP with Potentially Failed (SCTP-PF) Destination State
+
+3.1.  Overview
+
+   To minimize the performance impact during failover, the sender should
+   avoid transmitting data to a failed destination address as early as
+   possible.  In the SCTP path management scheme described in [RFC4960],
+   the sender stops transmitting data to a destination address only
+   after the destination address is marked inactive.  This process takes
+   a significant amount of time as it requires the error counter of the
+   destination address to exceed the PMR threshold.  The issue cannot
+   simply be mitigated by lowering the PMR threshold because this may
+   result in spurious failure detection and unnecessary prevention of
+   the usage of a preferred primary path.  Also, due to the coupled
+   tuning of the PMR and the AMR parameter values in [RFC4960], lowering
+   the PMR threshold may result in lowering the AMR threshold, which
+   would result in a decrease of the fault tolerance of SCTP.
+
+   The solution provided in this document is to extend the SCTP path
+   management scheme of [RFC4960] by the addition of the PF state as an
+   intermediate state in between the active and inactive state of a
+   destination address in the path management scheme of [RFC4960], and
+   let the failover of data transfer away from a destination address be
+   driven by the entering of the PF state instead of by the entering of
+   the inactive state.  Thereby, SCTP may perform quick failover without
+   negatively impacting the overall fault tolerance of SCTP as described
+   in [RFC4960].  At the same time, HEARTBEAT probing based on
+   Retransmission Timeout (RTO) is initiated towards a destination
+   address once it enters PF state.  Thereby, SCTP may quickly ascertain
+   whether network connectivity towards the destination address is
+   broken or whether the failover was spurious.  In the case where the
+   failover was spurious, data transfer may quickly resume towards the
+   original destination address.
+
+   The new failure detection algorithm assumes that loss detected by a
+   timeout implies either severe congestion or network connectivity
+   failure.  It recommends that, by default, a destination address be
+   classified as PF at the occurrence of the first timeout.
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                    [Page 5]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+3.2.  Specification of the SCTP-PF Procedures
+
+   The SCTP-PF operation is specified as follows:
+
+   1.   The sender maintains a new tunable SCTP Protocol Parameter
+        called PotentiallyFailed.Max.Retrans (PFMR).  The PFMR defines
+        the new intermediate PF threshold on the destination address
+        error counter.  When this threshold is exceeded, the destination
+        address is classified as PF.  The RECOMMENDED value of PFMR is
+        0.  If PFMR is set to be greater than or equal to PMR, the
+        resulting PF threshold will be so high that the destination
+        address will reach the inactive state before it can be
+        classified as PF.
+
+   2.   The error counter of an active destination address is
+        incremented or cleared as specified in [RFC4960].  This means
+        that the error counter of the destination address in active
+        state will be incremented each time the Timer T3 retransmission
+        (T3-rtx) timer expires, or each time a HEARTBEAT chunk is sent
+        when idle and not acknowledged within an RTO.  When the value in
+        the destination address error counter exceeds PFMR, the endpoint
+        MUST mark the destination address as in the PF state.
+
+   3.   An SCTP-PF sender SHOULD NOT send data to destination addresses
+        in PF state when alternative destination addresses in active
+        state are available.  Specifically, this means that:
+
+        i.     When there is outbound data to send and the destination
+               address presently used for data transmission is in PF
+               state, the sender SHOULD choose a destination address in
+               active state, if one exists, and use this destination
+               address for data transmission.
+
+        ii.    As specified in Section 6.4.1 of [RFC4960], when the
+               sender retransmits data that has timed out, they should
+               attempt to pick a new destination address for data
+               retransmission.  In this case, the sender SHOULD choose
+               an alternate destination transport address in active
+               state, if one exists.
+
+        iii.   When there is outbound data to send and the SCTP user
+               explicitly requests to send data to a destination address
+               in PF state, the sender SHOULD send the data to an
+               alternate destination address in active state if one
+               exists.
+
+
+
+
+
+
+Nishida, et al.              Standards Track                    [Page 6]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+        When choosing among multiple destination addresses in active
+        state, an SCTP sender will follow the guiding principles of
+        Section 6.4.1 of [RFC4960] by choosing the most divergent
+        source-destination pairs compared with, for (the aforementioned
+        points i and ii):
+
+        i.    the destination address in PF state that it performs a
+              failover from, and
+
+        ii.   the destination address towards which the data timed out.
+
+        Rules for picking the most divergent source-destination pair are
+        an implementation decision and are not specified within this
+        document.
+
+        In all cases, the sender MUST NOT change the state of the chosen
+        destination address, whether this state be active or PF, and it
+        MUST NOT clear the error counter of the destination address as a
+        result of choosing the destination address for data
+        transmission.
+
+   4.   When the destination addresses are all in PF state, or some are
+        in PF state and some in inactive state, the sender MUST choose
+        one destination address in PF state and SHOULD transmit or
+        retransmit data to this destination address using the following
+        rules:
+
+        i.    The sender SHOULD choose the destination in PF state with
+              the lowest error count (fewest consecutive timeouts) for
+              data transmission and transmit or retransmit data to this
+              destination.
+
+        ii.   When there are multiple destination addresses in PF state
+              with same error count, the sender should let the choice
+              among the multiple destination addresses in PF state with
+              equal error count be based on the principles of choosing
+              the most divergent source-destination pairs when executing
+              (potentially consecutive) retransmission outlined in
+              Section 6.4.1 of [RFC4960].  Rules for picking the most
+              divergent source-destination pairs are an implementation
+              decision and are not specified within this document.
+
+        The sender MUST NOT change the state and the error counter of
+        any destination addresses as the result of the selection.
+
+   5.   The HB.Interval of the Path Heartbeat function of [RFC4960] MUST
+        be ignored for destination addresses in PF state.  Instead,
+        HEARTBEAT chunks are sent to destination addresses in PF state
+
+
+
+Nishida, et al.              Standards Track                    [Page 7]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+        once per RTO.  HEARTBEAT chunks SHOULD be sent to destination
+        addresses in PF state, but the sending of HEARTBEATs MUST honor
+        whether or not the Path Heartbeat function (Section 8.3 of
+        [RFC4960]) is enabled for the destination address.  That is, if
+        the Path Heartbeat function is disabled for the destination
+        address in question, HEARTBEATs MUST NOT be sent.  Note that
+        when the Path Heartbeat function is disabled, it may take longer
+        to transition a destination address in PF state back to active
+        state.
+
+   6.   HEARTBEATs are sent when a destination address reaches the PF
+        state.  When a HEARTBEAT chunk is not acknowledged within the
+        RTO, the sender increments the error counter and exponentially
+        backs off the RTO value.  If the error counter is less than PMR,
+        the sender transmits another packet containing the HEARTBEAT
+        chunk immediately after timeout expiration on the previous
+        HEARTBEAT.  When data is being transmitted to a destination
+        address in the PF state, the transmission of a HEARTBEAT chunk
+        MAY be omitted in the case where the receipt of a Selective
+        Acknowledgment (SACK) of the data or a T3-rtx timer expiration
+        on the data can provide equivalent information, such as the case
+        where the data chunk has been transmitted to a single
+        destination address only.  Likewise, the timeout of a HEARTBEAT
+        chunk MAY be ignored if data is outstanding towards the
+        destination address.
+
+   7.   When the sender receives a HEARTBEAT ACK from a HEARTBEAT sent
+        to a destination address in PF state, the sender SHOULD clear
+        the error counter of the destination address and transition the
+        destination address back to active state.  However, there may be
+        a situation where HEARTBEAT chunks can go through while DATA
+        chunks cannot.  Hence, in a situation where a HEARTBEAT ACK
+        arrives while there is data outstanding towards the destination
+        address to which the HEARTBEAT was sent, then an implementation
+        MAY choose to not have the HEARTBEAT ACK reset the error
+        counter, but have the error counter reset await the fate of the
+        outstanding data transmission.  This situation can happen when
+        data is sent to a destination address in PF state.  When the
+        sender resumes data transmission on a destination address after
+        a transition of the destination address from PF to active state,
+        it MUST do this following the prescriptions of Section 7.2 of
+        [RFC4960].
+
+   8.   Additional PMR - PFMR consecutive timeouts on a destination
+        address in PF state confirm the path failure, upon which the
+        destination address transitions to the inactive state.  As
+        described in [RFC4960], the sender SHOULD (i) notify the Upper
+        Layer Protocol (ULP) about this state transition, and (ii)
+
+
+
+Nishida, et al.              Standards Track                    [Page 8]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+        transmit HEARTBEAT chunks to the inactive destination address at
+        a lower HB.Interval frequency as described in Section 8.3 of
+        [RFC4960] (when the Path Heartbeat function is enabled for the
+        destination address).
+
+   9.   Acknowledgments for chunks that have been transmitted to
+        multiple destinations (i.e., a chunk that has been retransmitted
+        to a different destination address than the destination address
+        to which the chunk was first transmitted) SHOULD NOT clear the
+        error count for an inactive destination address and SHOULD NOT
+        move a destination address in PF state back to active state,
+        since a sender cannot disambiguate whether the ACK was for the
+        original transmission or the retransmission(s).  An SCTP sender
+        MAY clear the error counter and move a destination address back
+        to active state by information other than acknowledgments, when
+        it can uniquely determine which destination, among multiple
+        destination addresses, the chunk reached.  This document makes
+        no reference to what such information could consist of, nor how
+        such information could be obtained.
+
+   10.  Acknowledgments for data chunks that have been transmitted to
+        one destination address only MUST clear the error counter for
+        the destination address and MUST transition a destination
+        address in PF state back to active state.  This situation can
+        happen when new data is sent to a destination address in the PF
+        state.  It can also happen in situations where the destination
+        address is in the PF state due to the occurrence of a spurious
+        T3-rtx timer and acknowledgments start to arrive for data sent
+        prior to occurrence of the spurious T3-rtx and data has not yet
+        been retransmitted towards other destinations.  This document
+        does not specify special handling for detection of, or reaction
+        to, spurious T3-rtx timeouts, e.g., for special operation vis-
+        a-vis the congestion control handling or data retransmission
+        operation towards a destination address that undergoes a
+        transition from active to PF to active state due to a spurious
+        T3-rtx timeout.  But it is noted that this is an area that would
+        benefit from additional attention, experimentation, and
+        specification for single-homed SCTP as well as for multihomed
+        SCTP protocol operation.
+
+   11.  When all destination addresses are in inactive state, and SCTP
+        protocol operation thus is said to be in dormant state, the
+        prescriptions given in Section 4 shall be followed.
+
+   12.  The SCTP stack SHOULD expose the PF state of its destination
+        addresses to the ULP as well as provide the means to notify the
+        ULP of state transitions of its destination addresses from
+        active to PF, and vice versa.  However, it is recommended that
+
+
+
+Nishida, et al.              Standards Track                    [Page 9]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+        an SCTP stack implementing SCTP-PF also allows for the ULP to be
+        kept ignorant of the PF state of its destinations and the
+        associated state transitions, thus allowing for retention of the
+        simpler state transition model of [RFC4960] in the ULP.  For
+        this reason, it is recommended that an SCTP stack implementing
+        SCTP-PF also provide the ULP with the means to suppress exposure
+        of the PF state and the associated state transitions.
+
+4.  Dormant State Operation
+
+   In a situation with complete disruption of the communication in
+   between the SCTP endpoints, the aggressive HEARTBEAT transmissions of
+   SCTP-PF on destination addresses in PF state may make the association
+   enter dormant state faster than a standard SCTP implementation of
+   [RFC4960] given the same setting of PMR and AMR.  For example, an
+   SCTP association with two destination addresses would typically reach
+   dormant state in half the time of an SCTP implementation of [RFC4960]
+   in such situations.  This is because an SCTP PF sender will send
+   HEARTBEATs and data retransmissions in parallel with RTO intervals
+   when there are multiple destinations addresses in PF state.  This
+   argument presumes that RTO << HB.Interval of [RFC4960].  With the
+   design goal that SCTP-PF shall provide the same level of disruption
+   tolerance as a standard SCTP implementation with the same PMR and AMR
+   setting, we prescribe that an SCTP-PF implementation SHOULD operate
+   as described in Section 4.1 during dormant state.
+
+   An SCTP-PF implementation MAY choose a different dormant state
+   operation than the one described in Section 4.1 provided that the
+   solution chosen does not decrease the fault tolerance of the SCTP-PF
+   operation.
+
+   The prescription below for SCTP-PF dormant state handling MUST NOT be
+   coupled to the value of the PFMR, but solely to the activation of
+   SCTP-PF logic in an SCTP implementation.
+
+   It is noted that the below dormant state operation can also provide
+   enhanced disruption tolerance to a standard SCTP implementation that
+   doesn't support SCTP-PF.  Thus, it can be sensible for a standard
+   SCTP implementation to follow this mode of operation.  For a standard
+   SCTP implementation, the continuation of data transmission during
+   dormant state makes the fault tolerance of SCTP be more robust
+   towards situations where some, or all, alternative paths of an SCTP
+   association approach, or reach, inactive state before the primary
+   path used for data transmission observes trouble.
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 10]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+4.1.  SCTP Dormant State Procedure
+
+   1.  When the destination addresses are all in inactive state and data
+       is available for transfer, the sender MUST choose one destination
+       and transmit data to this destination address.
+
+   2.  The sender MUST NOT change the state of the chosen destination
+       address (it remains in inactive state) and MUST NOT clear the
+       error counter of the destination address as a result of choosing
+       the destination address for data transmission.
+
+   3.  The sender SHOULD choose the destination in inactive state with
+       the lowest error count (fewest consecutive timeouts) for data
+       transmission.  When there are multiple destinations with the same
+       error count in inactive state, the sender SHOULD attempt to pick
+       the most divergent source -- destination pair from the last
+       source -- destination pair where failure was observed.  Rules for
+       picking the most divergent source-destination pair are an
+       implementation decision and are not specified within this
+       document.  To support differentiation of inactive destination
+       addresses based on their error count, SCTP will need to allow for
+       incrementing of the destination address error counters up to some
+       reasonable limit above PMR+1, thus changing the prescriptions of
+       Section 8.3 of [RFC4960] in this respect.  The exact limit to
+       apply is not specified in this document, but it is considered
+       reasonable enough to require that the limit be an order of
+       magnitude higher than the PMR value.  A sender MAY choose to
+       deploy other strategies than the strategy defined here.  The
+       strategy to prioritize the last active destination address, i.e.,
+       the destination address with the fewest error counts is optimal
+       when some paths are permanently inactive, but suboptimal when
+       path instability is transient.
+
+5.  Primary Path Switchover
+
+   The objective of the Primary Path Switchover operation is to allow
+   the SCTP sender to continue data transmission on a new working path
+   even when the old primary destination address becomes active again.
+   This is achieved by having SCTP perform a switchover of the primary
+   path to the new working path if the error counter of the primary path
+   exceeds a certain threshold.  This mode of operation can be applied
+   not only to SCTP-PF implementations, but also to implementations of
+   [RFC4960].
+
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 11]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+   The Primary Path Switchover operation requires only sender-side
+   changes.  The details are:
+
+   1.  The sender maintains a new tunable parameter, called
+       Primary.Switchover.Max.Retrans (PSMR).  For SCTP-PF
+       implementations, the PSMR MUST be set greater than or equal to
+       the PFMR value.  For implementations of [RFC4960], the PSMR MUST
+       be set greater than or equal to the PMR value.  Implementations
+       MUST reject any other values of PSMR.
+
+   2.  When the path error counter on a set primary path exceeds PSMR,
+       the SCTP implementation MUST autonomously select and set a new
+       primary path.
+
+   3.  The primary path selected by the SCTP implementation MUST be the
+       path that, at the given time, would be chosen for data transfer.
+       A previously failed primary path can be used as a data transfer
+       path as per normal path selection when the present data transfer
+       path fails.
+
+   4.  For SCTP-PF, the recommended value of PSMR is PFMR when Primary
+       Path Switchover operation mode is used.  This means that no
+       forced switchback to a previously failed primary path is
+       performed.  An SCTP-PF implementation of Primary Path Switchover
+       MUST support the setting of PSMR = PFMR.  An SCTP-PF
+       implementation of Primary Path Switchover MAY support setting of
+       PSMR > PFMR.
+
+   5.  For standard SCTP, the recommended value of PSMR is PMR when
+       Primary Path Switchover is used.  This means that no forced
+       switchback to a previously failed primary path is performed.  A
+       standard SCTP implementation of Primary Path Switchover MUST
+       support the setting of PSMR = PMR.  A standard SCTP
+       implementation of Primary Path Switchover MAY support larger
+       settings of PSMR > PMR.
+
+   6.  It MUST be possible to disable the Primary Path Switchover
+       operation and obtain the standard switchback operation of
+       [RFC4960].
+
+   The manner of switchover operation that is most optimal in a given
+   scenario depends on the relative quality of a set primary path versus
+   the quality of alternative paths available as well as on the extent
+   to which it is desired for the mode of operation to enforce traffic
+   distribution over a number of network paths.  That is, load
+   distribution of traffic from multiple SCTP associations may be
+   enforced by distribution of the set primary paths with the switchback
+   operation of [RFC4960].  However, as switchback behavior of [RFC4960]
+
+
+
+Nishida, et al.              Standards Track                   [Page 12]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+   is suboptimal in certain situations, especially in scenarios where a
+   number of equally good paths are available, an SCTP implementation
+   MAY support also, as alternative behavior, the Primary Path
+   Switchover mode of operation and MAY enable it based on applications'
+   requests.
+
+   For an SCTP implementation that implements the Primary Path
+   Switchover operation, this specification RECOMMENDS that the standard
+   switchback operation of [RFC4960] be retained as the default
+   operation.
+
+6.  Suggested SCTP Protocol Parameter Values
+
+   This document does not alter the value recommendation for the SCTP
+   Protocol Parameters defined in [RFC4960].
+
+   The following protocol parameter is RECOMMENDED:
+
+      PotentiallyFailed.Max.Retrans (PFMR) - 0
+
+7.  Socket API Considerations
+
+   This section describes how the socket API defined in [RFC6458] is
+   extended to provide a way for the application to control and observe
+   the SCTP-PF behavior as well as the Primary Path Switchover function.
+
+   Please note that this section is informational only.
+
+   A socket API implementation based on [RFC6458] is, by means of the
+   existing SCTP_PEER_ADDR_CHANGE event, extended to provide the event
+   notification when a peer address enters or leaves the PF state as
+   well as the socket API implementation is extended to expose the PF
+   state of a peer address in the existing SCTP_GET_PEER_ADDR_INFO
+   structure.
+
+   Furthermore, two new read/write socket options for the level
+   IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS and
+   SCTP_EXPOSE_POTENTIALLY_FAILED_STATE are defined as described below.
+   The first socket option is used to control the values of the PFMR and
+   PSMR parameters described in Sections 3 and 5.  The second one
+   controls the exposition of the PF path state.
+
+   Support for the SCTP_PEER_ADDR_THLDS and
+   SCTP_EXPOSE_POTENTIALLY_FAILED_STATE socket options also needs to be
+   added to the function sctp_opt_info().
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 13]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+7.1.  Support for the Potentially Failed Path State
+
+   As defined in [RFC6458], the SCTP_PEER_ADDR_CHANGE event is provided
+   if the status of a peer address changes.  In addition to the state
+   changes described in [RFC6458], this event is also provided if a peer
+   address enters or leaves the PF state.  The notification as defined
+   in [RFC6458] uses the following structure:
+
+   struct sctp_paddr_change {
+     uint16_t spc_type;
+     uint16_t spc_flags;
+     uint32_t spc_length;
+     struct sockaddr_storage spc_aaddr;
+     uint32_t spc_state;
+     uint32_t spc_error;
+     sctp_assoc_t spc_assoc_id;
+   }
+
+   [RFC6458] defines the constants SCTP_ADDR_AVAILABLE,
+   SCTP_ADDR_UNREACHABLE, SCTP_ADDR_REMOVED, SCTP_ADDR_ADDED, and
+   SCTP_ADDR_MADE_PRIM to be provided in the spc_state field.  This
+   document defines the new additional constant
+   SCTP_ADDR_POTENTIALLY_FAILED, which is reported if the affected
+   address becomes PF.
+
+   The SCTP_GET_PEER_ADDR_INFO socket option defined in [RFC6458] can be
+   used to query the state of a peer address.  It uses the following
+   structure:
+
+   struct sctp_paddrinfo {
+     sctp_assoc_t spinfo_assoc_id;
+     struct sockaddr_storage spinfo_address;
+     int32_t spinfo_state;
+     uint32_t spinfo_cwnd;
+     uint32_t spinfo_srtt;
+     uint32_t spinfo_rto;
+     uint32_t spinfo_mtu;
+   };
+
+   [RFC6458] defines the constants SCTP_UNCONFIRMED, SCTP_ACTIVE, and
+   SCTP_INACTIVE to be provided in the spinfo_state field.  This
+   document defines the new additional constant SCTP_POTENTIALLY_FAILED,
+   which is reported if the peer address is PF.
+
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 14]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+7.2.  Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket Option
+
+   Applications can control the SCTP-PF behavior by getting or setting
+   the number of consecutive timeouts before a peer address is
+   considered PF or unreachable.  The same socket option is used by
+   applications to set and get the number of timeouts before the primary
+   path is changed automatically by the Primary Path Switchover
+   function.  This socket option uses the level IPPROTO_SCTP and the
+   name SCTP_PEER_ADDR_THLDS.
+
+   The following structure is used to access and modify the thresholds:
+
+   struct sctp_paddrthlds {
+     sctp_assoc_t spt_assoc_id;
+     struct sockaddr_storage spt_address;
+     uint16_t spt_pathmaxrxt;
+     uint16_t spt_pathpfthld;
+     uint16_t spt_pathcpthld;
+   };
+
+   spt_assoc_id:  This parameter is ignored for one-to-one style
+      sockets.  For one-to-many style sockets, the application may fill
+      in an association identifier or SCTP_FUTURE_ASSOC.  It is an error
+      to use SCTP_{CURRENT|ALL}_ASSOC in spt_assoc_id.
+
+   spt_address:  This specifies which peer address is of interest.  If a
+      wildcard address is provided, this socket option applies to all
+      current and future peer addresses.
+
+   spt_pathmaxrxt:  Each peer address of interest is considered
+      unreachable, if its path error counter exceeds spt_pathmaxrxt.
+
+   spt_pathpfthld:  Each peer address of interest is considered PF, if
+      its path error counter exceeds spt_pathpfthld.
+
+   spt_pathcpthld:  Each peer address of interest is not considered the
+      primary remote address anymore, if its path error counter exceeds
+      spt_pathcpthld.  Using a value of 0xffff disables the selection of
+      a new primary peer address.  If an implementation does not support
+      the automatic selection of a new primary address, it should
+      indicate an error with errno set to EINVAL if a value different
+      from 0xffff is used in spt_pathcpthld.  For SCTP-PF, the setting
+      of spt_pathcpthld < spt_pathpfthld should be rejected with errno
+      set to EINVAL.  For standard SCTP, the setting of spt_pathcpthld <
+      spt_pathmaxrxt should be rejected with errno set to EINVAL.  An
+      SCTP-PF implementation may support only setting of spt_pathcpthld
+      = spt_pathpfthld and spt_pathcpthld = 0xffff and a standard SCTP
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 15]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+      implementation may support only setting of spt_pathcpthld =
+      spt_pathmaxrxt and spt_pathcpthld = 0xffff.  In these cases, SCTP
+      shall reject setting of other values with errno set to EINVAL.
+
+7.3.  Exposing the Potentially Failed Path State
+      (SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option
+
+   Applications can control the exposure of the PF path state in the
+   SCTP_PEER_ADDR_CHANGE event and the SCTP_GET_PEER_ADDR_INFO as
+   described in Section 7.1.  The default value is implementation
+   specific.
+
+   This socket option uses the level IPPROTO_SCTP and the name
+   SCTP_EXPOSE_POTENTIALLY_FAILED_STATE.
+
+   The following structure is used to control the exposition of the PF
+   path state:
+
+   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, the application may fill in an
+      association identifier or SCTP_FUTURE_ASSOC.  It is an error to
+      use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
+
+   assoc_value:  The PF path state is exposed if, and only if, this
+      parameter is non-zero.
+
+8.  Security Considerations
+
+   Security considerations for the use of SCTP and its APIs are
+   discussed in [RFC4960] and [RFC6458].
+
+   The logic introduced by this document does not impact existing SCTP
+   messages on the wire.  Also, this document does not introduce any new
+   SCTP messages on the wire that require new security considerations.
+
+   SCTP-PF makes SCTP not only more robust during primary path failure/
+   congestion, but also more vulnerable to network connectivity/
+   congestion attacks on the primary path.  SCTP-PF makes it easier for
+   an attacker to trick SCTP into changing the data transfer path, since
+   the duration of time that an attacker needs to negatively influence
+   the network connectivity is much shorter than used in [RFC4960].
+   However, SCTP-PF does not constitute a significant change in the
+   duration of time and effort an attacker needs to keep SCTP away from
+
+
+
+Nishida, et al.              Standards Track                   [Page 16]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+   the primary path.  With the standard switchback operation in
+   [RFC4960], SCTP resumes data transfer on its primary path as soon as
+   the next HEARTBEAT succeeds.
+
+   On the other hand, usage of the Primary Path Switchover mechanism,
+   does change the threat analysis.  This is because on-path attackers
+   can force a permanent change of the data transfer path by blocking
+   the primary path until the switchover of the primary path is
+   triggered by the Primary Path Switchover algorithm.  This will
+   especially be the case when the Primary Path Switchover is used
+   together with SCTP-PF with the particular setting of PSMR = PFMR = 0,
+   as Primary Path Switchover here happens already at the first RTO
+   timeout experienced.  Users of the Primary Path Switchover mechanism
+   should be aware of this fact.
+
+   The event notification of path state transfer from active to PF state
+   and vice versa gives attackers an increased possibility to generate
+   more local events.  However, it is assumed that event notifications
+   are rate-limited in the implementation to address this threat.
+
+9.  MIB Considerations
+
+   SCTP-PF introduces new SCTP algorithms for failover and switchback
+   with associated new state parameters.  It is recommended that the
+   SCTP-MIB defined in [RFC3873] is updated to support the management of
+   the SCTP-PF implementation.  This can be done by extending the
+   sctpAssocRemAddrActive field of the SCTPAssocRemAddrTable to include
+   information of the PF state of the destination address and by adding
+   new fields to the SCTPAssocRemAddrTable supporting
+   PotentiallyFailed.Max.Retrans (PFMR) and
+   Primary.Switchover.Max.Retrans (PSMR) parameters.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <http://www.rfc-editor.org/info/rfc4960>.
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 17]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+10.2.  Informative References
+
+   [CARO02]   Caro, A., Iyengar, J., Amer, P., Heinz, G., and R.
+              Stewart, "A Two-level Threshold Recovery Mechanism for
+              SCTP", Tech report, CIS Dept., University of Delaware,
+              July 2002.
+
+   [CARO04]   Caro, A., Amer, P., and R. Stewart, "End-to-End Failover
+              Thresholds for Transport Layer Multihoming", MILCOM 2004,
+              DOI 10.1109/MILCOM.2004.1493253, November 2004.
+
+   [CARO05]   Caro, A., "End-to-End Fault Tolerance using Transport
+              Layer Multihoming", Ph.D. Thesis, University of Delaware,
+              DOI 10.1007/BF03219970, January 2005.
+
+   [FALLON08]
+              Fallon, S., Jacob, P., Qiao, Y., Murphy, L., Fallon, E.,
+              and A. Hanley, "SCTP Switchover Performance Issues in WLAN
+              Environments", IEEE CCNC, DOI 10.1109/ccnc08.2007.131,
+              January 2008.
+
+   [GRINNEMO04]
+              Grinnemo, K-J. and A. Brunstrom, "Performance of SCTP-
+              controlled failovers in M3UA-based SIGTRAN networks",
+              Advanced Simulation Technologies Conference, April 2004.
+
+   [IYENGAR06]
+              Iyengar, J., Amer, P., and R. Stewart, "Concurrent
+              Multipath Transfer using SCTP Multihoming over Independent
+              End-to-end Paths", IEEE/ACM Transactions on Networking,
+              DOI 10.1109/TNET.2006.882843, October 2006.
+
+   [JUNGMAIER02]
+              Jungmaier, A., Rathgeb, E., and M. Tuexen, "On the use of
+              SCTP in failover scenarios", World Multiconference on
+              Systemics, Cybernetics and Informatics, July 2002.
+
+   [NATARAJAN09]
+              Natarajan, P., Ekiz, N., Amer, P., and R. Stewart,
+              "Concurrent Multipath Transfer during Path Failure",
+              Computer Communications, DOI 10.1016/j.comcom.2009.05.001,
+              May 2009.
+
+   [RFC3873]  Pastor, J. and M. Belinchon, "Stream Control Transmission
+              Protocol (SCTP) Management Information Base (MIB)",
+              RFC 3873, DOI 10.17487/RFC3873, September 2004,
+              <http://www.rfc-editor.org/info/rfc3873>.
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 18]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+   [RFC6458]  Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
+              Yasevich, "Sockets API Extensions for the Stream Control
+              Transmission Protocol (SCTP)", RFC 6458,
+              DOI 10.17487/RFC6458, December 2011,
+              <http://www.rfc-editor.org/info/rfc6458>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 19]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+Appendix A.  Discussion of Alternative Approaches
+
+   This section lists alternative approaches for the issues described in
+   this document.  Although these approaches do not require updating RFC
+   4960, we do not recommend them for the reasons described below.
+
+A.1.  Reduce PMR
+
+   Smaller values for Path.Max.Retrans shorten the failover duration and
+   in fact, this is recommended in some research results [JUNGMAIER02],
+   [GRINNEMO04], and [FALLON08].  However, to significantly reduce the
+   failover time, it is required to go down (as with PFMR) to
+   Path.Max.Retrans=0 and, with this setting, SCTP switches to another
+   destination address already on a single timeout that may result in
+   spurious failover.  Spurious failover is a problem in standard SCTP
+   as the transmission of HEARTBEATs on the left primary path, unlike in
+   SCTP-PF, is governed by HB.Interval also during the failover process.
+   HB.Interval is usually set in the order of seconds (recommended value
+   is 30 seconds) and when the primary path becomes inactive, the next
+   HEARTBEAT may be transmitted only many seconds later: as recommended,
+   only 30 seconds later.  Meanwhile, the primary path may have long
+   since recovered, if it needed recovery at all (indeed the failover
+   could be truly spurious).  In such situations, post failover, an
+   endpoint is forced to wait in the order of many seconds before the
+   endpoint can resume transmission on the primary path and furthermore,
+   once it returns on the primary path, the CWND needs to be rebuilt
+   anew -- a process that the throughput already had to suffer from on
+   the alternate path.  Using a smaller value for HB.Interval might help
+   this situation, but it would result in a general waste of bandwidth
+   as such more frequent HEARTBEATING would take place also when there
+   are no observed troubles.  The bandwidth overhead may be diminished
+   by having the ULP use a smaller HB.Interval only on the path that, at
+   any given time, is set to be the primary path; however, this adds
+   complication in the ULP.
+
+   In addition, smaller Path.Max.Retrans values also affect the
+   Association.Max.Retrans value.  When the SCTP association's error
+   count exceeds Association.Max.Retrans threshold, the SCTP sender
+   considers the peer endpoint unreachable and terminates the
+   association.  Section 8.2 in [RFC4960] recommends that the
+   Association.Max.Retrans value should not be larger than the summation
+   of the Path.Max.Retrans of each of the destination addresses.
+
+
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 20]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+   Otherwise, the SCTP sender considers its peer reachable even when all
+   destinations are INACTIVE.  To avoid this dormant state operation,
+   standard SCTP implementation SHOULD reduce Association.Max.Retrans
+   accordingly whenever it reduces Path.Max.Retrans.  However, smaller
+   Association.Max.Retrans value decreases the fault tolerance of SCTP
+   as it increases the chances of association termination during minor
+   congestion events.
+
+A.2.  Adjust RTO-Related Parameters
+
+   As several research results indicate, we can also shorten the
+   duration of the failover process by adjusting the RTO-related
+   parameters [JUNGMAIER02] and [FALLON08].  During the failover
+   process, RTO keeps being doubled.  However, if we can choose a
+   smaller value for RTO.max, we can stop the exponential growth of RTO
+   at some point.  Also, choosing smaller values for RTO.initial or
+   RTO.min can contribute to keeping the RTO value small.
+
+   Similar to reducing Path.Max.Retrans, the advantage of this approach
+   is that it requires no modification to the current specification,
+   although it needs to ignore several recommendations described in
+   Section 15 of [RFC4960].  However, this approach requires having
+   enough knowledge about the network characteristics between endpoints.
+   Otherwise, it can introduce adverse side effects such as spurious
+   timeouts.
+
+   The significant issue with this approach, however, is that even if
+   the RTO.max is lowered to an optimal low value, as long as the
+   Path.Max.Retrans is kept at the recommended value from [RFC4960], the
+   reduction of the RTO.max doesn't reduce the failover time
+   sufficiently enough to prevent severe performance degradation during
+   failover.
+
+Appendix B.  Discussion of the Path-Bouncing Effect
+
+   The methods described in the document can accelerate the failover
+   process.  Hence, they might introduce a path-bouncing effect in which
+   the sender keeps changing the data transmission path frequently.
+   This sounds harmful to the data transfer; however, several research
+   results indicate that there is no serious problem with SCTP in terms
+   of the path-bouncing effect (see [CARO04] and [CARO05]).
+
+   There are two main reasons for this.  First, SCTP is basically
+   designed for multipath communication, which means SCTP maintains all
+   path-related parameters (CWND, ssthresh, RTT, error count, etc.) per
+   each destination address.  These parameters cannot be affected by
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 21]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+   path bouncing.  In addition, when SCTP migrates the data transfer to
+   another path, it starts with the minimal or the initial CWND.  Hence,
+   there is little chance for packet reordering or duplicating.
+
+   Second, even if all communication paths between the end nodes share
+   the same bottleneck, the SCTP-PF results in a behavior already
+   allowed by [RFC4960].
+
+Appendix C.  SCTP-PF for SCTP Single-Homed Operation
+
+   For a single-homed SCTP association, the only tangible effect of the
+   activation of SCTP-PF operation is enhanced failure detection in
+   terms of potential notification of the PF state of the sole
+   destination address as well as, for idle associations, more rapid
+   entering, and notification, of inactive state of the destination
+   address and more rapid endpoint failure detection.  It is believed
+   that neither of these effects are harmful, provided adequate dormant
+   state operation is implemented.  Furthermore, it is believed that
+   they may be particularly useful for applications that deploy multiple
+   SCTP associations for load-balancing purposes.  The early
+   notification of the PF state may be used for preventive measures as
+   the entering of the PF state can be used as a warning of potential
+   congestion.  Depending on the PMR value, the aggressive HEARTBEAT
+   transmission in PF state may speed up the endpoint failure detection
+   (exceed of AMR threshold on the sole path error counter) on idle
+   associations in the case with a relatively large HB.Interval value
+   compared to RTO (e.g., 30 seconds) is used.
+
+Acknowledgments
+
+   The authors would like to acknowledge members of the IETF Transport
+   Area Working Group (tsvwg) for continuing discussions on this
+   document and insightful feedback, and we appreciate continuous
+   encouragement and suggestions from the Chairs of the tsvwg.  We
+   especially wish to thank Michael Tuexen for his many invaluable
+   comments and for his substantial supports with the making of the
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 22]
+
+RFC 7829                         SCTP-PF                      April 2016
+
+
+Authors' Addresses
+
+   Yoshifumi Nishida
+   GE Global Research
+   2623 Camino Ramon
+   San Ramon, CA  94583
+   United States
+
+   Email: nishida@wide.ad.jp
+
+
+   Preethi Natarajan
+   Cisco Systems
+   510 McCarthy Blvd.
+   Milpitas, CA  95035
+   United States
+
+   Email: prenatar@cisco.com
+
+
+   Armando Caro
+   BBN Technologies
+   10 Moulton St.
+   Cambridge, MA  02138
+   United States
+
+   Email: acaro@bbn.com
+
+
+   Paul D. Amer
+   University of Delaware
+   Computer Science Department - 434 Smith Hall
+   Newark, DE  19716-2586
+   United States
+
+   Email: amer@udel.edu
+
+
+   Karen E. E. Nielsen
+   Ericsson
+   Kistavaegen 25
+   Stockholm  164 80
+   Sweden
+
+   Email: karen.nielsen@tieto.com
+
+
+
+
+
+
+Nishida, et al.              Standards Track                   [Page 23]
+