%% You should probably cite rfc7829 instead of this I-D.
@techreport{ietf-tsvwg-sctp-failover-05,
    number =    {draft-ietf-tsvwg-sctp-failover-05},
    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/05/},
    author =    {Yoshifumi Nishida and Preethi Natarajan and Armando L. Caro and Paul D. Amer and karen Nielsen},
    title =     {{Quick Failover Algorithm in SCTP}},
    pagetotal = 17,
    year =      2014,
    month =     jul,
    day =       21,
    abstract =  {One of the major advantages of SCTP is that it supports 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 {[}RFC4960{]} specified failover operation is followed there can be a significant delay in the migration to the active destination addresses, thus severely reducing the effectiveness of SCTP multi-homed operation. The memo complements RFC4960 by the introduction of the Potentially Failed state and associated new Quick Failover operation to apply during network failure and specifies for SCTP senders to support this more performance optimal failover procedure as an add-on to the {[}RFC4960{]} failover operation. The memo in addition complements {[}RFC4960{]} by introduction of alternative switchover operation modes for the data transfer path management after a failover. These operation modes offer for more performance optimal operation in some network environments. From the perspective of this memo the implementation of the additional switchover operation modes is considered optional. The procedures defined require only minimal modifications to the current specification. The procedures are sender-side only and do not impact the SCTP receiver.},
}