Re: [Tsvwg] SCTP applicability statement
Allison Mankin <mankin@isi.edu> Mon, 05 November 2001 02:57 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20607 for <tsvwg-archive@odin.ietf.org>; Sun, 4 Nov 2001 21:57:06 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14343 for tsvwg-archive@odin.ietf.org; Sun, 4 Nov 2001 21:57:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14198; Sun, 4 Nov 2001 21:41:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14167 for <tsvwg@optimus.ietf.org>; Sun, 4 Nov 2001 21:41:41 -0500 (EST)
Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20489 for <tsvwg@ietf.org>; Sun, 4 Nov 2001 21:41:38 -0500 (EST)
Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fA52fcf28589; Sun, 4 Nov 2001 21:41:38 -0500
Message-Id: <200111050241.fA52fcf28589@minotaur.nge.isi.edu>
To: bidulock@openss7.org
cc: sigtran <sigtran@lyris.nortelnetworks.com>, "Transport Area wg (E-mail)" <tsvwg@ietf.org>
Reply-To: mankin@isi.edu
Subject: Re: [Tsvwg] SCTP applicability statement
In-reply-to: Your message of Sun, 04 Nov 2001 15:33:57 -0600. <20011104153357.I3223@openss7.org>
Mime-Version: 1.0 (generated by tm-edit 1.7)
Content-Type: text/plain; charset="US-ASCII"
Date: Sun, 04 Nov 2001 21:41:38 -0500
From: Allison Mankin <mankin@isi.edu>
Sender: tsvwg-admin@ietf.org
Errors-To: tsvwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
X-BeenThere: tsvwg@ietf.org
Brian, > So, is your answer no? Yes, my answer is no :) - SCTP is not intended to fail over between different associations - the protocol reliability is within the association. With the endpoints being on different boxes, that is, in arbitrary network locations, it would be a different protocol to do what you request. But multiple SCTP associations can still be used as failovers for each other, through use of an application layer watchdog and a short list of duplicate transactions that might need to be sent. The section on aaa transport that I recommended (3.2 in draft-ietf-aaa-transport-04.txt) is about a robust way to do this. > Is it fair to say that SCTP does not support failover between > multi-homed hosts, between associations, your second case? > Yes, that's fair. But to repeat, those different associations have arbitrary endpoints. How do SIGTRAN applications know what to make of a set of message that start arriving suddenly because failover has occurred - there must be application support of backup server use. > Are you saying that applications such as SIGTRAN, RSERPOOL, AAA, > must implement their own sequence numbers and acknowledgements > and retransmission queues between associations? > No, I think SIGTRAN and RSERPOOL apps (and aaa, by way of the draft I recommended you look at) can use multiple associations with an application layer algorithm that is different (and simpler) than sequence numbers, acks and transport retransmission queues. There needs to be duplicate detection of transactions, but failing over within the SCTP association can result in duplicates too. I think you should look at the algorithm I've recommended and compare it with the specific requirements. Allison > > Allison Mankin wrote: (Sun, 04 Nov 2001 16: > 22:14) > > > > > Does SCTP support failover between multi-homed hosts? > > > > > > > > > Is failover between multi-homed hosts within the scope of SCTP? > > > > Brian, > > > > SCTP's multi-homing has no relation to anything between* > > hosts, only between interfaces of one host. There might be > > some kind of cluster that appears to its SCTP peer be one host > > with multiple interfaces, but it would not be within the scope > > of SCTP to know about the cluster. > > > > In draft-ietf-aaa-transport-04.txt, section 3.2. there's a > > good discussion of failover/failback, which distinguishes > > among: > > > > - what a cluster does in its cluster OS or cluster communication > > system > > - what application-level watchdogs do, where the failover is among > > multiple potential peers (here AAA servers) > > - what SCTP does > > > > If all interfaces of an SCTP host are down, that's the second case. > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg
- [Tsvwg] SCTP applicability statement Coene Lode
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Allison Mankin
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Allison Mankin
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Allison Mankin
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement RJ Atkinson
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Chip Sharp
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- Re: [Tsvwg] SCTP applicability statement Chip Sharp
- Re: [Tsvwg] SCTP applicability statement Phillip Conrad
- Re: [Tsvwg] SCTP applicability statement Randall Stewart
- RE: [Tsvwg] SCTP applicability statement Ong, Lyndon
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Qiaobing Xie
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement Qiaobing Xie
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Kacheong Poon
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Randall Stewart
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP applicability statement David Lehmann
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Jacob Heitz
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Kacheong Poon
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Randall Stewart
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP: Data chunk in flight when a_rwn… Chip Sharp