draft-ietf-tsvwg-sctp-failover-13.txt   draft-ietf-tsvwg-sctp-failover-14.txt 
Network Working Group Y. Nishida Network Working Group Y. Nishida
Internet-Draft GE Global Research Internet-Draft GE Global Research
Intended status: Standards Track P. Natarajan Intended status: Standards Track P. Natarajan
Expires: March 4, 2016 Cisco Systems Expires: June 11, 2016 Cisco Systems
A. Caro A. Caro
BBN Technologies BBN Technologies
P. Amer P. Amer
University of Delaware University of Delaware
K. Nielsen K. Nielsen
Ericsson Ericsson
September 1, 2015 December 9, 2015
SCTP-PF: Quick Failover Algorithm in SCTP SCTP-PF: Quick Failover Algorithm in SCTP
draft-ietf-tsvwg-sctp-failover-13.txt draft-ietf-tsvwg-sctp-failover-14.txt
Abstract Abstract
SCTP supports multi-homing. However, when the failover operation SCTP supports multi-homing. However, when the failover operation
specified in RFC4960 is followed, there can be significant delay and specified in RFC4960 is followed, there can be significant delay and
performance degradation in the data transfer path failover. To performance degradation in the data transfer path failover. To
overcome this problem this document specifies a quick failover overcome this problem this document specifies a quick failover
algorithm (SCTP-PF) based on the introduction of a Potentially Failed algorithm (SCTP-PF) based on the introduction of a Potentially Failed
(PF) state in SCTP Path Management. (PF) state in SCTP Path Management.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 March 4, 2016. This Internet-Draft will expire on June 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 3, line 34 skipping to change at page 3, line 34
path severely degrades the performance of the protocol. To address path severely degrades the performance of the protocol. To address
this problem, this document specifies a quick failover algorithm this problem, this document specifies a quick failover algorithm
(SCTP-PF) based on the introduction of a new Potentially Failed (PF) (SCTP-PF) based on the introduction of a new Potentially Failed (PF)
path state in SCTP path management. The performance deficiencies of path state in SCTP path management. The performance deficiencies of
the [RFC4960] failover operation, and the improvements obtainable the [RFC4960] failover operation, and the improvements obtainable
from the introduction of a Potentially Failed state in SCTP, were from the introduction of a Potentially Failed state in SCTP, were
proposed and documented in [NATARAJAN09] for Concurrent Multipath proposed and documented in [NATARAJAN09] for Concurrent Multipath
Transfer SCTP [IYENGAR06]. Transfer SCTP [IYENGAR06].
While SCTP-PF can accelerate failover process and improve While SCTP-PF can accelerate failover process and improve
performance, the risks that an SCTP endpoint enters in dormant state performance, the risks that an SCTP endpoint enters the dormant state
where all destination addresses are inactive can be increased. where all destination addresses are inactive can be increased.
[RFC4960] leaves the protocol operation during dormant state to [RFC4960] leaves the protocol operation during dormant state to
implementations and encourages to avoid entering the state as much as implementations and encourages to avoid entering the state as much as
possible by careful tuning of the Path.Max.Retrans (PMR) and possible by careful tuning of the Path.Max.Retrans (PMR) and
Association.Max.Retrans (AMR) parameters. We specify a dormant state Association.Max.Retrans (AMR) parameters. We specify a dormant state
operation for SCTP-PF which makes SCTP-PF provide the same disruption operation for SCTP-PF which makes SCTP-PF provide the same disruption
tolerance as [RFC4960] despite that the dormant state may be entered tolerance as [RFC4960] despite that the dormant state may be entered
more quickly. The dormant state operation may equally well be more quickly. The dormant state operation may equally well be
applied by an [RFC4960] implementation and will here serve to provide applied by an [RFC4960] implementation and will here serve to provide
added fault tolerance for situations where the tuning of the added fault tolerance for situations where the tuning of the
Path.Max.Retrans (PMR) and Association.Max.Retrans (AMR) parameters Path.Max.Retrans (PMR) and Association.Max.Retrans (AMR) parameters
fail to provide adequate prevention of the entering of the dormant fail to provide adequate prevention of the entering of the dormant
state. state.
The operation after the recovery of a failed path equally well The operation after the recovery of a failed path also impacts the
impacts the performance of the protocol. With the procedures performance of the protocol. With the procedures specified in
specified in [RFC4960] SCTP will, after a failover from the primary [RFC4960] SCTP will, after a failover from the primary path, switch
path, switch back to use the primary path for data transfer as soon back to use the primary path for data transfer as soon as this path
as this path becomes available again. From a performance perspective becomes available again. From a performance perspective such a
such a forced switchback of the data transmission path can be forced switchback of the data transmission path can be suboptimal as
suboptimal as the CWND towards the original primary destination the CWND towards the original primary destination address has to be
address has to be rebuilt once data transfer resumes, [CARO02]. As rebuilt once data transfer resumes, [CARO02]. As an optional
an optional alternative to the switchback operation of [RFC4960], alternative to the switchback operation of [RFC4960], this document
this document specifies an alternative Primary Path Switchover specifies an alternative Primary Path Switchover procedure which
procedure which avoid such forced switchbacks of the data transfer avoid such forced switchbacks of the data transfer path. The Primary
path. The Primary Path Switchover operation was originally proposed Path Switchover operation was originally proposed in [CARO02].
in [CARO02].
While SCTP-PF primarily is motivated by a desire to improve the While SCTP-PF primarily is motivated by a desire to improve the
multi-homed operation, the feature applies also to SCTP single-homed multi-homed operation, the feature applies also to SCTP single-homed
operation. Here the algorithm serves to provide increased failure operation. Here the algorithm serves to provide increased failure
detection on idle associations, whereas the failover or switchback detection on idle associations, whereas the failover or switchback
aspects of the algorithm will not be activated. This is discussed in aspects of the algorithm will not be activated. This is discussed in
more detail in Appendix C. more detail in Appendix C.
A brief description of the motivation for the introduction of the A brief description of the motivation for the introduction of the
Potentially Failed state including a discussion of alternative Potentially Failed state including a discussion of alternative
approaches to mitigate the deficiencies of the [RFC4960] failover approaches to mitigate the deficiencies of the [RFC4960] failover
operation are given in the Appendices. Discussion of path bouncing operation are given in the Appendices. Discussion of path bouncing
effects that might be caused by frequent switchover, are also effects that might be caused by frequent switchovers, are also
provided there. provided there.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. SCTP with Potentially Failed Destination State (SCTP-PF) 3. SCTP with Potentially Failed Destination State (SCTP-PF)
skipping to change at page 4, line 48 skipping to change at page 4, line 47
To minimize the performance impact during failover, the sender should To minimize the performance impact during failover, the sender should
avoid transmitting data to a failed destination address as early as avoid transmitting data to a failed destination address as early as
possible. In the [RFC4960] SCTP path management scheme, the sender possible. In the [RFC4960] SCTP path management scheme, the sender
stops transmitting data to a destination address only after the stops transmitting data to a destination address only after the
destination address is marked inactive. This process takes a destination address is marked inactive. This process takes a
significant amount of time as it requires the error counter of the significant amount of time as it requires the error counter of the
destination address to exceed the Path.Max.Retrans (PMR) threshold. destination address to exceed the Path.Max.Retrans (PMR) threshold.
The issue cannot simply be mitigated by lowering of the PMR threshold The issue cannot simply be mitigated by lowering of the PMR threshold
because this may result in spurious failure detection and unnecessary because this may result in spurious failure detection and unnecessary
prevention of the usage of a preferred primary path as well as it, prevention of the usage of a preferred primary path. Also due to the
due to the coupled tuning of the Path.Max.Retrans (PMR) and the coupled tuning of the Path.Max.Retrans (PMR) and the
Association.Max.Retrans (AMR) parameter values in [RFC4960], may Association.Max.Retrans (AMR) parameter values in [RFC4960], lowering
result in compromisation of the fault tolerance of SCTP. of the PMR threshold may result in lowering of the AMR threshold,
which may result in compromisation of the fault tolerance of SCTP.
The solution provided in this document is to extend the SCTP path The solution provided in this document is to extend the SCTP path
management scheme of [RFC4960] by the addition of the Potentially management scheme of [RFC4960] by the addition of the Potentially
Failed (PF) state as an intermediate state in between the active and Failed (PF) state as an intermediate state in between the active and
inactive state of a destination address in the [RFC4960] path inactive state of a destination address in the [RFC4960] path
management scheme, and let the failover of data transfer away from a management scheme, and let the failover of data transfer away from a
destination address be driven by the entering of the PF state instead destination address be driven by the entering of the PF state instead
of by the entering of the inactive state. Thereby SCTP may perform of by the entering of the inactive state. Thereby SCTP may perform
quick failover without compromising the overall fault tolerance of quick failover without compromising the overall fault tolerance of
[RFC4960] SCTP. At the same time, RTO-based HEARTBEAT probing is [RFC4960] SCTP. At the same time, RTO-based HEARTBEAT probing is
initiated towards a destination address once it enters PF state. initiated towards a destination address once it enters PF state.
Thereby SCTP may quickly ascertain whether network connectivity Thereby SCTP may quickly ascertain whether network connectivity
towards the destination address is broken or whether the failover was towards the destination address is broken or whether the failover was
spurious. In the case where the failover was spurious data transfer spurious. In the case where the failover was spurious data transfer
may quickly resume towards the original destination address. may quickly resume towards the original destination address.
The new failure detection algorithm assumes that loss detected by a The new failure detection algorithm assumes that loss detected by a
timeout implies either severe congestion or network connectivity timeout implies either severe congestion or network connectivity
failure and it assumes that by default a destination address is failure. It recommends that by default a destination address is
classified as PF already at the occurrence of one first timeout. classified as PF at the occurrence of the first timeout.
3.2. Specification of the SCTP-PF Procedures 3.2. Specification of the SCTP-PF Procedures
The SCTP-PF operation is specified as follows: The SCTP-PF operation is specified as follows:
1. The sender maintains a new tunable SCTP Protocol Parameter 1. The sender maintains a new tunable SCTP Protocol Parameter
called PotentiallyFailed.Max.Retrans (PFMR). The PFMR defines called PotentiallyFailed.Max.Retrans (PFMR). The PFMR defines
the new intermediate PF threshold on the destination address the new intermediate PF threshold on the destination address
error counter at exceed of which the destination address is error counter at exceed of which the destination address is
classified as PF. The RECOMMENDED value of PFMR is 0, but other classified as PF. The RECOMMENDED value of PFMR is 0, but other
values MAY be used. Setting PFMR larger to or equal to values MAY be used. If PFMR is set to be greater than or equal
Path.Max.Retrans (PMR) does not result in definition of a PF to Path.Max.Retrans (PMR), the resulting PF threshold will be so
threshold for the destination address. I.e., the destination high that the destination address will reach the inactive state
address will not be classified as PF prior to reaching inactive before it can be classified as PF.
state.
2. The error counter of an active destination address is 2. The error counter of an active destination address is
incremented as specified in [RFC4960]. This means that the incremented as specified in [RFC4960]. This means that the
error counter of the destination address will be incremented error counter of the destination address will be incremented
each time the T3-rtx timer expires, or each time a HEARTBEAT each time the T3-rtx timer expires, or each time a HEARTBEAT
chunk is sent when idle and not acknowledged within an RTO. chunk is sent when idle and not acknowledged within an RTO.
When the value in the destination address error counter exceeds When the value in the destination address error counter exceeds
PFMR, the endpoint MUST mark the destination address as in the PFMR, the endpoint MUST mark the destination address as in the
PF state. PF state.
3. The PFMR threshold defines the point the destination address no 3. A SCTP-PF sender SHOULD NOT send data to destination addresses
longer is considered a good candidate for data transmission and
a SCTP-PF sender SHOULD NOT send data to destination addresses
in PF state when alternative destination addresses in active in PF state when alternative destination addresses in active
state are available. Specifically this means that: state are available. Specifically this means that:
i When there is outbound data to send and the destination i When there is outbound data to send and the destination
address presently used for data transmission is in PF state, address presently used for data transmission is in PF state,
the sender SHOULD choose a destination address in active the sender SHOULD choose a destination address in active
state, if one exists, and failover to deploy this destination state, if one exists, and failover to deploy this destination
address for data transmission. address for data transmission.
ii When retransmitting data that has timed out and the sender ii When retransmitting data that has timed out and the sender
skipping to change at page 8, line 7 skipping to change at page 8, line 4
a destination address in PF state back to active state. a destination address in PF state back to active state.
6. HEARTBEATs are sent when a destination address reaches the PF 6. HEARTBEATs are sent when a destination address reaches the PF
state. When a HEARTBEAT chunk is not acknowledged within the state. When a HEARTBEAT chunk is not acknowledged within the
RTO, the sender increments the error counter and exponentially RTO, the sender increments the error counter and exponentially
backs off the RTO value. If the error counter is less than PMR, backs off the RTO value. If the error counter is less than PMR,
the sender transmits another packet containing the HEARTBEAT the sender transmits another packet containing the HEARTBEAT
chunk immediately after timeout expiration on the previous chunk immediately after timeout expiration on the previous
HEARTBEAT. When data is being transmitted to a destination HEARTBEAT. When data is being transmitted to a destination
address in the PF state, the transmission of a HEARTBEAT chunk address in the PF state, the transmission of a HEARTBEAT chunk
MAY be omitted in case receipt of a SACK of or a T3-rtx timer MAY be omitted in case where the receipt of a SACK of the data
expiration on the outstanding data can provide equivalent or a T3-rtx timer expiration on the data can provide equivalent
information, such as a case where the data chunk has transmitted information, such as the case where the data chunk has been
to a single destination. Likewise, the timeout of a HEARTBEAT transmitted to a single destination address only. Likewise, the
chunk MAY be ignored if data is outstanding towards the timeout of a HEARTBEAT chunk MAY be ignored if data is
destination address. outstanding towards the destination address.
7. When the sender receives a HEARTBEAT ACK from a HEARTBEAT sent 7. When the sender receives a HEARTBEAT ACK from a HEARTBEAT sent
to a destination address in PF state, the sender SHOULD clear to a destination address in PF state, the sender SHOULD clear
the error counter of the destination address and transition the the error counter of the destination address and transition the
destination address back to active state. When the sender destination address back to active state. When the sender
resumes data transmission on a destination address after a resumes data transmission on a destination address after a
transition of the destination address from PF to active state, transition of the destination address from PF to active state,
it MUST do this following the prescriptions of Section 7.2 of it MUST do this following the prescriptions of Section 7.2 of
[RFC4960]. In a situation where a HEARTBEAT ACK arrives while [RFC4960]. In a situation where a HEARTBEAT ACK arrives while
there is data outstanding towards the destination address to there is data outstanding towards the destination address to
skipping to change at page 8, line 50 skipping to change at page 8, line 47
retransmitted to a different destination address than the retransmitted to a different destination address than the
destination address to which the chunk was first transmitted) destination address to which the chunk was first transmitted)
SHOULD NOT clear the error count for an inactive destination SHOULD NOT clear the error count for an inactive destination
address and SHOULD NOT transition a destination address in PF address and SHOULD NOT transition a destination address in PF
state back to active state, since a sender cannot disambiguate state back to active state, since a sender cannot disambiguate
whether the ACK was for the original transmission or the whether the ACK was for the original transmission or the
retransmission(s). A SCTP sender MAY apply a different approach retransmission(s). A SCTP sender MAY apply a different approach
for the error count handling based on unequivocally information for the error count handling based on unequivocally information
on which destination (including multiple destination addresses) on which destination (including multiple destination addresses)
the chunk reached. This document makes no reference to what the chunk reached. This document makes no reference to what
such unequivocally information could consist of, neither how such unequivocally information could consist of, nor how such
such unequivocally information could be obtained. The design of unequivocally information could be obtained. The design of such
such an alternative approach is left to implementations. an alternative approach is left to implementations.
10. Acknowledgments for data chunks that has been transmitted to one 10. Acknowledgments for data chunks that has been transmitted to one
destination address only MUST clear the error counter for the destination address only MUST clear the error counter for the
destination address and MUST transition a destination address in destination address and MUST transition a destination address in
PF state back to active state. This situation can happen when PF state back to active state. This situation can happen when
new data is sent to a destination address in the PF state. It new data is sent to a destination address in the PF state. It
can also happen in situations where the destination address is can also happen in situations where the destination address is
in the PF state due to the occurrence of a spurious T3-rtx timer in the PF state due to the occurrence of a spurious T3-rtx timer
and acknowledgments start to arrive for data sent prior to and acknowledgments start to arrive for data sent prior to
occurrence of the spurious T3-rtx and data has not yet been occurrence of the spurious T3-rtx and data has not yet been
skipping to change at page 9, line 31 skipping to change at page 9, line 29
active to PF to active state due to a spurious T3-rtx timeout. active to PF to active state due to a spurious T3-rtx timeout.
But it is noted that this is an area which would benefit from But it is noted that this is an area which would benefit from
additional attention, experimentation and specification for additional attention, experimentation and specification for
single-homed SCTP as well as for multi-homed SCTP protocol single-homed SCTP as well as for multi-homed SCTP protocol
operation. operation.
11. When all destination addresses are in inactive state, and SCTP 11. When all destination addresses are in inactive state, and SCTP
protocol operation thus is said to be in dormant state, the protocol operation thus is said to be in dormant state, the
prescriptions given in Section 4 shall be followed. prescriptions given in Section 4 shall be followed.
12. The SCTP stack SHOULD provide the ULP with the means to expose 12. The SCTP stack SHOULD expose the PF state of its destination
the PF state of its destinations as well as the means to notify addresses to the ULP as well as provide the means to notify the
of state transitions from active to PF, and vice-versa. However ULP of state transitions of its destination addresses from
it is recommended that an SCTP stack implementing SCTP-PF also active to PF, and vice-versa. However it is recommended that an
allows for that the ULP is kept ignorant of the PF state of its SCTP stack implementing SCTP-PF also allows for that the ULP is
destinations and the associated state transition. For this kept ignorant of the PF state of its destinations and the
associated state transitions, thus allowing for retain of the
simpler state transition model of RFC4960 in the ULP. For this
reason it is recommended that an SCTP stack implementing SCTP-PF reason it is recommended that an SCTP stack implementing SCTP-PF
also should provide the ULP with the means to suppress exposure also provides the ULP with the means to suppress exposure of the
of PF state and the associated state transitions. PF state and the associated state transitions.
4. Dormant State Operation 4. Dormant State Operation
In a situation with complete disruption of the communication in In a situation with complete disruption of the communication in
between the SCTP Endpoints, the aggressive HEARTBEAT transmissions of between the SCTP Endpoints, the aggressive HEARTBEAT transmissions of
SCTP-PF on destination addresses in PF state may make the association SCTP-PF on destination addresses in PF state may make the association
enter dormant state faster than a standard [RFC4960] SCTP enter dormant state faster than a standard [RFC4960] SCTP
implementation given the same setting of Path.Max.Retrans (PMR) and implementation given the same setting of Path.Max.Retrans (PMR) and
Association.Max.Retrans (AMR). For example, an SCTP association with Association.Max.Retrans (AMR). For example, an SCTP association with
two destination addresses typically would reach dormant state in half two destination addresses typically would reach dormant state in half
skipping to change at page 10, line 29 skipping to change at page 10, line 28
be coupled to the value of the PFMR, but solely to the activation of be coupled to the value of the PFMR, but solely to the activation of
SCTP-PF logic in an SCTP implementation. SCTP-PF logic in an SCTP implementation.
It is noted that the below dormant state operation is considered to It is noted that the below dormant state operation is considered to
provide added disruption tolerance also for an [RFC4960] SCTP provide added disruption tolerance also for an [RFC4960] SCTP
implementation, and that it can be sensible for an [RFC4960] SCTP implementation, and that it can be sensible for an [RFC4960] SCTP
implementation to follow this mode of operation. For an [RFC4960] implementation to follow this mode of operation. For an [RFC4960]
SCTP implementation the continuation of data transmission during SCTP implementation the continuation of data transmission during
dormant state makes the fault tolerance of SCTP be more robust dormant state makes the fault tolerance of SCTP be more robust
towards situations where some, or all, alternative paths of an SCTP towards situations where some, or all, alternative paths of an SCTP
association approach, or reach, inactive state prior to that the association approach, or reach, inactive state before the primary
primary path used for data transmission observes trouble. path used for data transmission observes trouble.
4.1. SCTP Dormant State Procedure 4.1. SCTP Dormant State Procedure
a. When the destination addresses are all in inactive state and data a. When the destination addresses are all in inactive state and data
is available for transfer, the sender MUST choose one destination is available for transfer, the sender MUST choose one destination
and transmit data to this destination address. and transmit data to this destination address.
b. The sender MUST NOT change the state of the chosen destination b. The sender MUST NOT change the state of the chosen destination
address (it remains in inactive state) and it MUST NOT clear the address (it remains in inactive state) and it MUST NOT clear the
error counter of the destination address as a result of choosing error counter of the destination address as a result of choosing
skipping to change at page 11, line 9 skipping to change at page 11, line 8
the most divergent source - destination pair from the last source the most divergent source - destination pair from the last source
- destination pair where failure was observed. Rules for picking - destination pair where failure was observed. Rules for picking
the most divergent source-destination pair are an implementation the most divergent source-destination pair are an implementation
decision and are not specified within this document. To support decision and are not specified within this document. To support
differentiation of inactive destination addresses based on their differentiation of inactive destination addresses based on their
error count SCTP will need to allow for increment of the error count SCTP will need to allow for increment of the
destination address error counters up to some reasonable limit destination address error counters up to some reasonable limit
above PMR+1, thus changing the prescriptions of [RFC4960], above PMR+1, thus changing the prescriptions of [RFC4960],
section 8.3, in this respect. The exact limit to apply is not section 8.3, in this respect. The exact limit to apply is not
specified in this document but it is considered reasonable to specified in this document but it is considered reasonable to
require for such to be an order of magnitude higher than the PMR require for the limit to be an order of magnitude higher than the
value. A sender MAY choose to deploy other strategies that the PMR value. A sender MAY choose to deploy other strategies that
strategy defined by here. The strategy to prioritize the last the strategy defined here. The strategy to prioritize the last
active destination address, i.e., the destination address with active destination address, i.e., the destination address with
the fewest error counts is optimal when some paths are the fewest error counts is optimal when some paths are
permanently inactive, but suboptimal when a path instability is permanently inactive, but suboptimal when a path instability is
transient. transient.
5. Primary Path Switchover 5. Primary Path Switchover
The objective of the Primary Path Switchover operation is to allow The objective of the Primary Path Switchover operation is to allow
the SCTP sender to continue data transmission on a new working path the SCTP sender to continue data transmission on a new working path
even when the old primary destination address becomes active again. even when the old primary destination address becomes active again.
This is achieved by having SCTP perform a switch over of the primary 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 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 exceeds a certain threshold. This mode of operation can be applied
not only to SCTP-PF implementations, but also to [RFC4960] not only to SCTP-PF implementations, but also to [RFC4960]
implementations. implementations.
The Primary Path Switchover operation requires only sender side The Primary Path Switchover operation requires only sender side
changes. The details are: changes. The details are:
1. The sender maintains a new tunable parameter, called 1. The sender maintains a new tunable parameter, called
Primary.Switchover.Max.Retrans (PSMR). For SCTP-PF Primary.Switchover.Max.Retrans (PSMR). For SCTP-PF
skipping to change at page 12, line 20 skipping to change at page 12, line 19
switchback to a previously failed primary path is performed. A switchback to a previously failed primary path is performed. A
[RFC4960] SCTP implementation of Primary Path Switchover MUST [RFC4960] SCTP implementation of Primary Path Switchover MUST
support the setting of PSMR = PMR. An [RFC4960] SCTP support the setting of PSMR = PMR. An [RFC4960] SCTP
implementation of Primary Path Switchover MAY support larger implementation of Primary Path Switchover MAY support larger
settings of PSMR > PMR. settings of PSMR > PMR.
6. It MUST be possible to disable the Primary Path Switchover 6. It MUST be possible to disable the Primary Path Switchover
operation and obtain the standard switchback operation of operation and obtain the standard switchback operation of
[RFC4960]. [RFC4960].
The manner of switch over operation that is most optimal in a given The manner of switchover operation that is most optimal in a given
scenario depends on the relative quality of a set primary path versus scenario depends on the relative quality of a set primary path versus
the quality of alternative paths available as well as it depends on the quality of alternative paths available as well as on the extent
the extent to which it is desired for the mode of operation to to which it is desired for the mode of operation to enforce traffic
enforce traffic distribution over a number of network paths. I.e., distribution over a number of network paths. I.e., load distribution
load distribution of traffic from multiple SCTP associations may be of traffic from multiple SCTP associations may be sought to be
sought to be enforced by distribution of the set primary paths with enforced by distribution of the set primary paths with [RFC4960]
[RFC4960] switchback operation. However as [RFC4960] switchback switchback operation. However as [RFC4960] switchback behavior is
behavior is suboptimal in certain situations, especially in scenarios suboptimal in certain situations, especially in scenarios where a
where a number of equally good paths are available, an SCTP number of equally good paths are available, an SCTP implementation
implementation MAY support also, as alternative behavior, the Primary MAY support also, as alternative behavior, the Primary Path
Path Switchover mode of operation and MAY enable it based on users' Switchover mode of operation and MAY enable it based on users'
requests. requests.
For an SCTP implementation that implements the Primary Path For an SCTP implementation that implements the Primary Path
Switchover operation, this specification RECOMMENDS that the standard Switchover operation, this specification RECOMMENDS that the standard
RFC4960 switchback operation is retained as the default operation. RFC4960 switchback operation is retained as the default operation.
6. Suggested SCTP Protocol Parameter Values 6. Suggested SCTP Protocol Parameter Values
This document does not alter the [RFC4960] value RECOMMENDATIONS for This document does not alter the [RFC4960] value RECOMMENDATIONS for
the SCTP Protocol Parameters defined in [RFC4960]. the SCTP Protocol Parameters defined in [RFC4960].
skipping to change at page 16, line 26 skipping to change at page 16, line 26
congestion attacks on the primary path. SCTP-PF makes it easier for congestion attacks on the primary path. SCTP-PF makes it easier for
an attacker to trick SCTP to change data transfer path, since the an attacker to trick SCTP to change data transfer path, since the
duration of time that an attacker needs to compromise the network duration of time that an attacker needs to compromise the network
connectivity is much shorter than [RFC4960]. However, SCTP-PF does connectivity is much shorter than [RFC4960]. However, SCTP-PF does
not constitute a significant change in the duration of time and not constitute a significant change in the duration of time and
effort an attacker needs to keep SCTP away from the primary path. effort an attacker needs to keep SCTP away from the primary path.
With the standard switchback operation [RFC4960] SCTP resumes data With the standard switchback operation [RFC4960] SCTP resumes data
transfer on its primary path as soon as the next HEARTBEAT succeeds. transfer on its primary path as soon as the next HEARTBEAT succeeds.
On the other hand, usage of the Primary Path Switchover mechanism, On the other hand, usage of the Primary Path Switchover mechanism,
does change the treat analysis. This is because attackers can force does change the threat analysis. This is because on-path attackers
a permanent change of the data transfer path by blocking the primary can force a permanent change of the data transfer path by blocking
path until the switchover of the primary path is triggered by the the primary path until the switchover of the primary path is
Primary Path Switchover algorithm. This especially will be the case triggered by the Primary Path Switchover algorithm. This especially
when the Primary Path Switchover is used together with SCTP-PF with will be the case when the Primary Path Switchover is used together
the particular setting of PSMR = PFMR = 0, as Primary Path Switchover with SCTP-PF with the particular setting of PSMR = PFMR = 0, as
here happens already at the first RTO timeout experienced. Users of Primary Path Switchover here happens already at the first RTO timeout
the Primary Path Switchover mechanism should be aware of this fact. experienced. Users of the Primary Path Switchover mechanism should
be aware of this fact.
The event notification of path state transfer from active to The event notification of path state transfer from active to
potentially failed state and vice versa gives attackers an increased potentially failed state and vice versa gives attackers an increased
possibility to generate more local events. However, it is assumed possibility to generate more local events. However, it is assumed
that event notifications are rate-limited in the implementation to that event notifications are rate-limited in the implementation to
address this threat. address this threat.
9. IANA Considerations 9. IANA Considerations
This document does not create any new registries or modify the rules This document does not create any new registries or modify the rules
 End of changes. 21 change blocks. 
75 lines changed or deleted 75 lines changed or added

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