draft-ietf-tsvwg-sctp-failover-12.txt   draft-ietf-tsvwg-sctp-failover-13.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 3, 2016 Cisco Systems Expires: March 4, 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
August 31, 2015 September 1, 2015
SCTP-PF: Quick Failover Algorithm in SCTP SCTP-PF: Quick Failover Algorithm in SCTP
draft-ietf-tsvwg-sctp-failover-12.txt draft-ietf-tsvwg-sctp-failover-13.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 3, 2016. This Internet-Draft will expire on March 4, 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 9, line 18 skipping to change at page 9, line 18
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
retransmitted towards other destinations. This document does retransmitted towards other destinations. This document does
not specify special handling for detection of or reaction to not specify special handling for detection of or reaction to
spurious T3-rtx timeouts, e.g., for special operation Vis-avis spurious T3-rtx timeouts, e.g., for special operation vis-a-vis
the congestion control handling or data retransmission operation the congestion control handling or data retransmission operation
towards a destination address which undergoes a transition from towards a destination address which undergoes a transition from
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
skipping to change at page 11, line 32 skipping to change at page 11, line 32
This is achieved by having SCTP perform a switch over of the primary This is achieved by having SCTP perform a switch over 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 (PMR). For SCTP-PF Primary.Switchover.Max.Retrans (PSMR). For SCTP-PF
implementations, the PMR MUST be set greater or equal to the PFMR implementations, the PSMR MUST be set greater or equal to the
value. For [RFC4960] implementations the PMR MUST be set greater PFMR value. For [RFC4960] implementations the PSMR MUST be set
or equal to the PMR value. Implementations MUST reject any other greater or equal to the PMR value. Implementations MUST reject
values of PMR. any other values of PSMR.
2. When the path error counter on a set primary path exceeds PMR, 2. When the path error counter on a set primary path exceeds PSMR,
the SCTP implementation MUST autonomously select and set a new the SCTP implementation MUST autonomously select and set a new
primary path. primary path.
3. The primary path selected by the SCTP implementation MUST be the 3. The primary path selected by the SCTP implementation MUST be the
path which at the given time would be chosen for data transfer. path which at the given time would be chosen for data transfer.
A previously failed primary path can be used as data transfer A previously failed primary path can be used as data transfer
path as per normal path selection when the present data transfer path as per normal path selection when the present data transfer
path fails. path fails.
4. For SCTP-PF, the recommended value of PMR is PFMR when Primary 4. For SCTP-PF, the recommended value of PSMR is PFMR when Primary
Path Switchover operation mode is used. This means that no Path Switchover operation mode is used. This means that no
forced switchback to a previously failed primary path is forced switchback to a previously failed primary path is
performed. An SCTP-PF implementation of Primary Path Switchover performed. An SCTP-PF implementation of Primary Path Switchover
MUST support the setting of PMR = PFMR. A SCTP-PF implementation MUST support the setting of PSMR = PFMR. A SCTP-PF
of Primary Path Switchover MAY support setting of PMR > PFMR. implementation of Primary Path Switchover MAY support setting of
PSMR > PFMR.
5. For [RFC4960] SCTP, the recommended value of PMR is PMR when 5. For [RFC4960] SCTP, the recommended value of PSMR is PMR when
Primary Path Switchover is used. This means that no forced Primary Path Switchover is used. This means that no forced
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 PMR = 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 PMR > 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 switch over 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 it depends on
the extent to which it is desired for the mode of operation to the extent to which it is desired for the mode of operation to
enforce traffic distribution over a number of network paths. I.e., enforce traffic distribution over a number of network paths. I.e.,
skipping to change at page 13, line 18 skipping to change at page 13, line 18
existing SCTP_PEER_ADDR_CHANGE event, extended to provide the event existing SCTP_PEER_ADDR_CHANGE event, extended to provide the event
notification when a peer address enters or leaves the potentially notification when a peer address enters or leaves the potentially
failed state as well as the socket API implementation is extended to failed state as well as the socket API implementation is extended to
expose the potentially failed state of a peer address in the existing expose the potentially failed state of a peer address in the existing
SCTP_GET_PEER_ADDR_INFO structure. SCTP_GET_PEER_ADDR_INFO structure.
Furthermore, two new read/write socket options for the level Furthermore, two new read/write socket options for the level
IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS and IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS and
SCTP_EXPOSE_POTENTIALLY_FAILED_STATE are defined as described below. SCTP_EXPOSE_POTENTIALLY_FAILED_STATE are defined as described below.
The first socket option is used to control the values of the PFMR and The first socket option is used to control the values of the PFMR and
PMR parameters described in Section 3 and in Section 5. The second PSMR parameters described in Section 3 and in Section 5. The second
one controls the exposition of the potentially failed path state. one controls the exposition of the potentially failed path state.
Support for the SCTP_PEER_ADDR_THLDS and Support for the SCTP_PEER_ADDR_THLDS and
SCTP_EXPOSE_POTENTIALLY_FAILED_STATE socket options need also to be SCTP_EXPOSE_POTENTIALLY_FAILED_STATE socket options need also to be
added to the function sctp_opt_info(). added to the function sctp_opt_info().
7.1. Support for the Potentially Failed Path State 7.1. Support for the Potentially Failed Path State
As defined in [RFC6458], the SCTP_PEER_ADDR_CHANGE event is provided 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 if the status of a peer address changes. In addition to the state
changes described in [RFC6458], this event is also provided, if a changes described in [RFC6458], this event is also provided, if a
peer address enters or leaves the potentially failed state. The peer address enters or leaves the potentially failed state. The
notification as defined in [RFC6458] uses the following structure: notification as defined in [RFC6458] uses the following structure:
strict sctp_paddr_change { struct sctp_paddr_change {
uint16_t spc_type; uint16_t spc_type;
uint16_t spc_flags; uint16_t spc_flags;
uint32_t spc_length; uint32_t spc_length;
strict sockaddr_storage spc_aaddr; struct sockaddr_storage spc_aaddr;
uint32_t spc_state; uint32_t spc_state;
uint32_t spc_error; uint32_t spc_error;
sctp_assoc_t spc_assoc_id; sctp_assoc_t spc_assoc_id;
} }
[RFC6458] defines the constants SCTP_ADDR_AVAILABLE, [RFC6458] defines the constants SCTP_ADDR_AVAILABLE,
SCTP_ADDR_UNREACHABLE, SCTP_ADDR_REMOVED, SCTP_ADDR_ADDED, and SCTP_ADDR_UNREACHABLE, SCTP_ADDR_REMOVED, SCTP_ADDR_ADDED, and
SCTP_ADDR_MADE_PRIM to be provided in the spc_state field. This SCTP_ADDR_MADE_PRIM to be provided in the spc_state field. This
document defines in addition to that the new constant document defines in addition to that the new constant
SCTP_ADDR_POTENTIALLY_FAILED, which is reported if the affected SCTP_ADDR_POTENTIALLY_FAILED, which is reported if the affected
address becomes potentially failed. address becomes potentially failed.
The SCTP_GET_PEER_ADDR_INFO socket option defined in [RFC6458] can be 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 used to query the state of a peer address. It uses the following
structure: structure:
strict sctp_paddrinfo { struct sctp_paddrinfo {
sctp_assoc_t spinfo_assoc_id; sctp_assoc_t spinfo_assoc_id;
strict sockaddr_storage spinfo_address; struct sockaddr_storage spinfo_address;
int32_t spinfo_state; int32_t spinfo_state;
uint32_t spinfo_cwnd; uint32_t spinfo_cwnd;
uint32_t spinfo_srtt; uint32_t spinfo_srtt;
uint32_t spinfo_rto; uint32_t spinfo_rto;
uint32_t spinfo_mtu; uint32_t spinfo_mtu;
}; };
[RFC6458] defines the constants SCTP_UNCONFIRMED, SCTP_ACTIVE, and [RFC6458] defines the constants SCTP_UNCONFIRMED, SCTP_ACTIVE, and
SCTP_INACTIVE to be provided in the spinfo_state field. This SCTP_INACTIVE to be provided in the spinfo_state field. This
document defines in addition to that the new constant document defines in addition to that the new constant
skipping to change at page 14, line 33 skipping to change at page 14, line 33
Applications can control the SCTP-PF behavior by getting or setting Applications can control the SCTP-PF behavior by getting or setting
the number of consecutive timeouts before a peer address is the number of consecutive timeouts before a peer address is
considered potentially failed or unreachable. The same socket option considered potentially failed or unreachable. The same socket option
is used by applications to set and get the number of timeouts before is used by applications to set and get the number of timeouts before
the primary path is changed automatically by the Primary Path the primary path is changed automatically by the Primary Path
Switchover function. This socket option uses the level IPPROTO_SCTP Switchover function. This socket option uses the level IPPROTO_SCTP
and the name SCTP_PEER_ADDR_THLDS. and the name SCTP_PEER_ADDR_THLDS.
The following structure is used to access and modify the thresholds: The following structure is used to access and modify the thresholds:
strict sctp_paddrthlds { struct sctp_paddrthlds {
sctp_assoc_t spt_assoc_id; sctp_assoc_t spt_assoc_id;
strict sockaddr_storage spt_address; struct sockaddr_storage spt_address;
uint16_t spt_pathmaxrxt; uint16_t spt_pathmaxrxt;
uint16_t spt_pathpfthld; uint16_t spt_pathpfthld;
uint16_t spt_pathcpthld; uint16_t spt_pathcpthld;
}; };
spt_assoc_id: This parameter is ignored for one-to-one style spt_assoc_id: This parameter is ignored for one-to-one style
sockets. For One-romany style sockets the application may fill in sockets. For one-to-many style sockets the application may fill
an association identifier or SCTP_FUTURE_ASSOC. It is an error to in an association identifier or SCTP_FUTURE_ASSOC. It is an error
use SCTP_{CURRENT|ALL}_ASSOC in spt_assoc_id. to use SCTP_{CURRENT|ALL}_ASSOC in spt_assoc_id.
spt_address: This specifies which peer address is of interest. If a spt_address: This specifies which peer address is of interest. If a
wild card address is provided, this socket option applies to all wild card address is provided, this socket option applies to all
current and future peer addresses. current and future peer addresses.
spt_pathmaxrxt: Each peer address of interest is considered spt_pathmaxrxt: Each peer address of interest is considered
unreachable, if its path error counter exceeds spt_pathmaxrxt. unreachable, if its path error counter exceeds spt_pathmaxrxt.
spt_pathpfthld: Each peer address of interest is considered spt_pathpfthld: Each peer address of interest is considered
Potentially Failed, if its path error counter exceeds Potentially Failed, if its path error counter exceeds
spt_pathpfthld. spt_pathpfthld.
spt_pathcpthld: Each peer address of interest is not considered the spt_pathcpthld: Each peer address of interest is not considered the
primary remote address anymore, if its path error counter exceeds primary remote address anymore, if its path error counter exceeds
spt_pathcpthld. Using a value of 0off disables the selection of a spt_pathcpthld. Using a value of 0xffff disables the selection of
new primary peer address. If an implementation does not support a new primary peer address. If an implementation does not support
the automatically selection of a new primary address, it should the automatically selection of a new primary address, it should
indicate an error with Erna set to RIVAL if a value different from indicate an error with errno set to EINVAL if a value different
0off is used in spt_pathcpthld. For SCTP-PF, the setting of from 0xffff is used in spt_pathcpthld. For SCTP-PF, the setting
spt_pathcpthld < spt_pathpfthld should be rejected with Erna set of spt_pathcpthld < spt_pathpfthld should be rejected with errno
to RIVAL. For [RFC4960] SCTP, the setting of spt_pathcpthld < set to EINVAL. For [RFC4960] SCTP, the setting of spt_pathcpthld
spt_pathmaxrxt should be rejected with Erna set to RIVAL. A SCTP- < spt_pathmaxrxt should be rejected with errno set to EINVAL. A
PF implementation MAY support only setting of spt_pathcpthld = SCTP-PF implementation MAY support only setting of spt_pathcpthld
spt_pathpfthld and spt_pathcpthld = 0off and a [RFC4960] SCTP = spt_pathpfthld and spt_pathcpthld = 0xffff and a [RFC4960] SCTP
implementation MAY support only setting of spt_pathcpthld = implementation MAY support only setting of spt_pathcpthld =
spt_pathmaxrxt and spt_pathcpthld = 0off. In these cases SCTP spt_pathmaxrxt and spt_pathcpthld = 0xffff. In these cases SCTP
shall reject setting of other values with Erna set to RIVAL. shall reject setting of other values with errno set to EINVAL.
7.3. Exposing the Potentially Failed Path State 7.3. Exposing the Potentially Failed Path State
(SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option (SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option
Applications can control the exposure of the potentially failed path Applications can control the exposure of the potentially failed path
state in the SCTP_PEER_ADDR_CHANGE event and the state in the SCTP_PEER_ADDR_CHANGE event and the
SCTP_GET_PEER_ADDR_INFO as described in Section 7.1. The default SCTP_GET_PEER_ADDR_INFO as described in Section 7.1. The default
value is implementation specific. value is implementation specific.
This socket option uses the level IPPROTO_SCTP and the name This socket option uses the level IPPROTO_SCTP and the name
SCTP_EXPOSE_POTENTIALLY_FAILED_STATE. SCTP_EXPOSE_POTENTIALLY_FAILED_STATE.
The following structure is used to control the exposition of the The following structure is used to control the exposition of the
potentially failed path state: potentially failed path state:
strict sctp_assoc_value { struct sctp_assoc_value {
sctp_assoc_t assoc_id; sctp_assoc_t assoc_id;
uint32_t assoc_value; uint32_t assoc_value;
}; };
assoc_id: This parameter is ignored for one-to-one style sockets. assoc_id: This parameter is ignored for one-to-one style sockets.
For One-romany style sockets the application may fill in an For one-to-many style sockets the application may fill in an
association identifier or SCTP_FUTURE_ASSOC. It is an error to association identifier or SCTP_FUTURE_ASSOC. It is an error to
use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_value: The potentially failed path state is exposed if and assoc_value: The potentially failed path state is exposed if and
only if this parameter is non-zero. only if this parameter is non-zero.
8. Security Considerations 8. Security Considerations
Security considerations for the use of SCTP and its APIs are Security considerations for the use of SCTP and its APIs are
discussed in [RFC4960] and [RFC6458]. discussed in [RFC4960] and [RFC6458].
The logic introduced by this document does not impact existing On- The logic introduced by this document does not impact existing SCTP
anthe-wire SCTP messages. Also, this document does not introduce any messages on the wire. Also, this document does not introduce any new
new On-anthe-wire SCTP messages that require new security SCTP messages on the wire that require new security considerations.
considerations.
SCTP-PF makes SCTP not only more robust during primary path failure/ SCTP-PF makes SCTP not only more robust during primary path failure/
congestion but also more vulnerable to network connectivity/ congestion but also more vulnerable to network connectivity/
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 treat analysis. This is because attackers can force
a permanent change of the data transfer path by blocking the primary a permanent change of the data transfer path by blocking the primary
path until the switchover of the primary path is triggered by the path until the switchover of the primary path is triggered by the
Primary Path Switchover algorithm. This especially will be the case Primary Path Switchover algorithm. This especially will be the case
when the Primary Path Switchover is used together with SCTP-PF with when the Primary Path Switchover is used together with SCTP-PF with
the particular setting of PMR = PFMR = 0, as Primary Path Switchover the particular setting of PSMR = PFMR = 0, as Primary Path Switchover
here happens already at the first RTO timeout experienced. Users of here happens already at the first RTO timeout experienced. Users of
the Primary Path Switchover mechanism should be aware of this fact. 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
for any existing registries managed by IONA. for any existing registries managed by IANA.
10. Acknowledgements 10. Acknowledgements
The authors wish to thank Michael Tuexen for his many invaluable The authors wish to thank Michael Tuexen for his many invaluable
comments and for his very substantial support with the making of this comments and for his very substantial support with the making of this
document. document.
11. Proposed Change of Status (to be Deleted before Publication) 11. Proposed Change of Status (to be Deleted before Publication)
Initially this work looked to entail some changes of the Congestion Initially this work looked to entail some changes of the Congestion
Control (CC) operation of SCTP and for this reason the work was Control (CC) operation of SCTP and for this reason the work was
proposed as Experimental. These intended changes of the CC operation proposed as Experimental. These intended changes of the CC operation
have since been judged to be irrelevant and are no longer part of the have since been judged to be irrelevant and are no longer part of the
specification. As the specification entails no other potential specification. As the specification entails no other potential
harmful features, consensus exists in the G to bring the work forward harmful features, consensus exists in the WG to bring the work
as PS. forward as PS.
Initially concerns have been expressed about the possibility for the Initially concerns have been expressed about the possibility for the
mechanism to introduce path bouncing with potential harmful network mechanism to introduce path bouncing with potential harmful network
impacts. These concerns are believed to be unfounded. This issue is impacts. These concerns are believed to be unfounded. This issue is
addressed in Appendix B. addressed in Appendix B.
It is noted that the feature specified by this document is It is noted that the feature specified by this document is
implemented by multiple SCTP SW implementations and furthermore that implemented by multiple SCTP SW implementations and furthermore that
various variants of the solution have been deployed in Tel co various variants of the solution have been deployed in Tel co
signaling environments for several years with good results. signaling environments for several years with good results.
skipping to change at page 18, line 7 skipping to change at page 18, line 7
[CARO04] Caro Jr., A., Amer, P., and R. Stewart, "End-to-End [CARO04] Caro Jr., A., Amer, P., and R. Stewart, "End-to-End
Failover Thresholds for Transport Layer Multi homing", Failover Thresholds for Transport Layer Multi homing",
MILCOM 2004 , 11 2004. MILCOM 2004 , 11 2004.
[CARO05] Caro Jr., A., "End-to-End Fault Tolerance using Transport [CARO05] Caro Jr., A., "End-to-End Fault Tolerance using Transport
Layer Multi homing", Ph.D Thesis, University of Delaware , Layer Multi homing", Ph.D Thesis, University of Delaware ,
1 2005. 1 2005.
[FALLON08] [FALLON08]
Fallon, S., Jacob, P., Qiao, Y., Murphy, L., Fallon, E., Fallon, S., Jacob, P., Qiao, Y., Murphy, L., Fallon, E.,
and A. Hanley, "SCTP Switchover Performance Issues in ALAN and A. Hanley, "SCTP Switchover Performance Issues in WLAN
Environments", IEEE CCNC 2008, 1 2008. Environments", IEEE CCNC 2008, 1 2008.
[GRINNEMO04] [GRINNEMO04]
Grinnemo, K-J. and A. Brunstrom, "Performance of SCTP- Grinnemo, K-J. and A. Brunstrom, "Performance of SCTP-
controlled failover in M3UA-based SIGHT RAN networks", controlled failovers in M3UA-based SIGTRAN networks",
Advanced Simulation Technologies Conference , 4 2004. Advanced Simulation Technologies Conference , 4 2004.
[IYENGAR06] [IYENGAR06]
Iyengar, J., Amer, P., and R. Stewart, "Concurrent Iyengar, J., Amer, P., and R. Stewart, "Concurrent
Multipath Transfer using SCTP Multi homing over Multipath Transfer using SCTP Multihoming over Independent
Independent End-to-end Paths.", IEEE/ACM Trans on End-to-end Paths.", IEEE/ACM Trans on Networking 14(5), 10
Networking 14(5), 10 2006. 2006.
[JUNGMAIER02] [JUNGMAIER02]
Jungmaier, A., Rathgeb, E., and M. Tuexen, "On the use of Jungmaier, A., Rathgeb, E., and M. Tuexen, "On the use of
SCTP in failover scenarios", World Multiconference on SCTP in failover scenarios", World Multiconference on
Systemics, Cybernetics and Informatics , 7 2002. Systemics, Cybernetics and Informatics , 7 2002.
[NATARAJAN09] [NATARAJAN09]
Natarajan, P., Ekiz, N., Amer, P., and R. Stewart, Natarajan, P., Ekiz, N., Amer, P., and R. Stewart,
"Concurrent Multipath Transfer during Path Failure", "Concurrent Multipath Transfer during Path Failure",
Computer Communications , 5 2009. Computer Communications , 5 2009.
 End of changes. 32 change blocks. 
53 lines changed or deleted 53 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/