draft-ietf-tsvwg-sctp-failover-01.txt   draft-ietf-tsvwg-sctp-failover-02.txt 
Network Working Group Y. Nishida Network Working Group Y. Nishida
Internet-Draft GE Global Research Internet-Draft GE Global Research
Intended status: Experimental P. Natarajan Intended status: Experimental P. Natarajan
Expires: December 20, 2013 Cisco Systems Expires: April 24, 2014 Cisco Systems
A. Caro A. Caro
BBN Technologies BBN Technologies
P. Amer P. Amer
University of Delaware University of Delaware
June 18, 2013 October 21, 2013
Quick Failover Algorithm in SCTP Quick Failover Algorithm in SCTP
draft-ietf-tsvwg-sctp-failover-01 draft-ietf-tsvwg-sctp-failover-02
Abstract Abstract
One of the major advantages in SCTP is supporting multi-homing One of the major advantages in SCTP is supporting multi-homing
communication. If a multi-homed end-point has redundant network communication. If a multi-homed end-point has redundant network
connections, SCTP sessions can have a good chance to survive from connections, SCTP sessions can have a good chance to survive from
network failures by migrating inactive network to active one. network failures by migrating inactive network to active one.
However, if we follow the SCTP standard, there can be significant However, if we follow the SCTP standard, there can be significant
delay for the network migration. During this migration period, SCTP delay for the network migration. During this migration period, SCTP
cannot transmit much data to the destination. This issue drastically cannot transmit much data to the destination. This issue drastically
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2013. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Issue in SCTP Path Management Process . . . . . . . . . . . . 5 3. Issue in SCTP Path Management Process . . . . . . . . . . . . 5
4. Existing Solutions for Smooth Failover . . . . . . . . . . . . 6 4. Existing Solutions for Smooth Failover . . . . . . . . . . . . 6
4.1. Reduce Path.Max.Retrans . . . . . . . . . . . . . . . . . 6 4.1. Reduce Path.Max.Retrans . . . . . . . . . . . . . . . . . 6
4.2. Adjust RTO related parameters . . . . . . . . . . . . . . 7 4.2. Adjust RTO related parameters . . . . . . . . . . . . . . 7
5. Proposed Solution: SCTP with Potentially-Failed 5. Proposed Solution: SCTP with Potentially-Failed
Destination State (SCTP-PF) . . . . . . . . . . . . . . . . . 8 Destination State (SCTP-PF) . . . . . . . . . . . . . . . . . 8
5.1. SCTP-PF Description . . . . . . . . . . . . . . . . . . . 8 5.1. SCTP-PF Description . . . . . . . . . . . . . . . . . . . 8
5.2. Effect of Path Bouncing . . . . . . . . . . . . . . . . . 10 5.2. Effect of Path Bouncing . . . . . . . . . . . . . . . . . 10
5.3. Permanent Failover . . . . . . . . . . . . . . . . . . . . 10 5.3. Permanent Failover . . . . . . . . . . . . . . . . . . . . 10
5.4. Handling Error Counter . . . . . . . . . . . . . . . . . . 11 5.4. Handling of Association Error Counter . . . . . . . . . . 11
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 12 6. Socket API Considerations . . . . . . . . . . . . . . . . . . 12
6.1. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) socket 6.1. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) socket
option . . . . . . . . . . . . . . . . . . . . . . . . . . 12 option . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 11, line 6 skipping to change at page 11, line 6
path, especially in scenarios where this path's characteristics are path, especially in scenarios where this path's characteristics are
better. In order to mitigate this performance degradation, permanent better. In order to mitigate this performance degradation, permanent
failover was proposed in [CARO02]. Permanent failover allows SCTP to failover was proposed in [CARO02]. Permanent failover allows SCTP to
remain the alternative path even if the primary path becomes active remain the alternative path even if the primary path becomes active
again. We recommend that SCTP-PF should stick to the standard again. We recommend that SCTP-PF should stick to the standard
RFC4960 behavior, i.e., switch back to the original primary once this RFC4960 behavior, i.e., switch back to the original primary once this
destination becomes active again. Permanent failover may be destination becomes active again. Permanent failover may be
considered in the future based on discussions and consensus within considered in the future based on discussions and consensus within
the community. the community.
5.4. Handling Error Counter 5.4. Handling of Association Error Counter
When multiple destinations are in the PF state, the sender may When multiple destinations are in the PF state, the sender may
transmit heartbeats to multiple destinations at the same time. This transmit heartbeats to multiple destinations at the same time. This
allows SCTP-PF sender to quickly track and respond to network status allows SCTP-PF sender to quickly track and respond to network status
change compared to an SCTP sender. However, when all PF destinations change compared to an SCTP sender. However, when all PF destinations
become unavailable, an SCTP-PF sender has outstanding HBs on all become unavailable, an SCTP-PF sender has outstanding HBs on all
destinations compared to an SCTP sender and increases the count for destinations compared to an SCTP sender and increases the count for
the total number of consecutive retransmissions faster than the SCTP the total number of consecutive retransmissions faster than the SCTP
sender. SCTP-PF's faster increase in the error count will result in sender. SCTP-PF's faster increase in the error count will result in
association termination sooner than SCTP. association termination sooner than SCTP. The key difference between
SCTP and SCTP-PF with regard to this feature is whether checking path
status sequentially or concurrently as the number of packets sent for
probing is the same.
For deployments where aggressive failure detection and association For deployments where aggressive failure detection and association
termination is not desired, we recommend that AMR be set to the termination is not desired, we suggest that AMR be set to the
maximum allowed value (sum of PMRs of all paths), to delay assoc recommended maximum value (sum of PMRs of all paths), to delay assoc
termination during SCTP-PF. Another option is to send retransmitted termination during SCTP-PF. Another option is to send retransmitted
data or HB to only one PF destination at a time, but this approach data or HB to only one PF destination at a time, but this approach
may delay path status tracking. To exclude HB timeouts from may delay path status tracking. To exclude HB timeouts from
incrementing the error count can also be a solution, however, this incrementing the error count can also be a solution, however, this
requires an update to Section 8.3 of [RFC4960]. requires an update to Section 8.1 and Section 8.3 of [RFC4960],
otherwise special logics for error counter need to be implemented for
SCTP-PF.
6. Socket API Considerations 6. Socket API Considerations
This section describes how the socket API defined in [RFC6458] is This section describes how the socket API defined in [RFC6458] is
extended to provide a way for the application to control the quick extended to provide a way for the application to control the quick
failover behavior. failover behavior.
Please note that this section is informational only. Please note that this section is informational only.
A socket API implementation based on [RFC6458] is extended by adding A socket API implementation based on [RFC6458] is extended by adding
 End of changes. 9 change blocks. 
10 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/