%% You should probably cite rfc7829 instead of this I-D.
@techreport{ietf-tsvwg-sctp-failover-10,
    number =    {draft-ietf-tsvwg-sctp-failover-10},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/10/},
    author =    {Yoshifumi Nishida and Preethi Natarajan and Armando L. Caro and Paul D. Amer and karen Nielsen},
    title =     {{SCTP-PF: Quick Failover Algorithm in SCTP}},
    pagetotal = 21,
    year =      2015,
    month =     mar,
    day =       9,
    abstract =  {One of the major advantages of SCTP is the support of multi-homed communication. A multi-homed SCTP end-point has the ability to withstand network failures by migrating the traffic from an inactive network to an active one. However, if the failover operation as specified in RFC4960 is followed, there can be a significant delay in the migration to the active destination addresses, thus severely reducing the effectiveness of the SCTP failover operation. This document complements RFC4960 by the introduction of a new path state, the Potentially Failed (PF) path state, and an associated new failover operation to apply during a network failure. The algorithm defined is called SCTP Potentially Failed Algorithm, SCTP-PF for short. In addition, the document complements RFC4960 by introducing alternative switchover operation modes for the data transfer path management after the recovery of a failed primary path. These modes can allow improvements in the performance of the operation in some network environments. The implementation of the additional switchover operation modes is an optional part of SCTP-PF. The procedures defined in the document require only minimal modifications to the current specification. The procedures are sender-side only and do not impact the SCTP receiver.},
}