Subject: Re: [Tsvwg] SCTP applicability statement

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 03:58:20 -0600

Coene,

The applicability statement has the following text:

    3 Multihoming Issues

	...

	It should be noted that SCTP multihoming support only deals with
	communication between two endpoints of which one or both is assigned
	with multiple IP addresses on possibly multiple network interfaces.
	It does NOT deal with communication ends that contain multiple
	endpoints (i.e., clustered endpoints) that can switch over to an
	alternate endpoint in case of failure of the original endpoint.

As it is fundamental to the design of SIGTRAN UAs that such redundancy
between hosts be supported, this statement appears to indicate that
either SCTP is unsuitable for SIGTRAN UAs, or SIGTRAN UAs must include
their own support for handling clustered endpoints (e.g., UA queueing
and acknowledgements).

This is a significant issue with all the SS7 SIGTRAN UAs.  Is the
applicability statement saying that SIGTRAN must layer acknowledgements
over SCTP to accomplish this because no support is provided by SCTP?

--brian

On Wed, 24 Oct 2001, Coene Lode wrote:

> > Folks,
> > 
> > The SCTP applicability statement has been reissued incorporating all the
> > comments coming from the AD's
> > (Thank you Allison and Scott). As you will notice, it looks a lot
> > different from the previous release. 
> > So have a look at:
> > http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-applicability-
> > 07.txt
> > 
> > Both the SIGTRAN and TSV mailing lists are included as both have workitems
> > dealing with SCTP.
> > If you have comments, you can send them to me. 
> > 
> > yours sincerly,
> > Lode Coene
> > 
> > Siemens atea ICN D CS D
> > Software development
> > Atealaan 34
> > B-2200   Herentals    Belgium
> > Tel: +32-14-2-52081   Fax: +32-14-2-53212
> > E-mail: [email-masked]
> > 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 04 Nov 2001 10:21:43 -0500

>over SCTP to accomplish this because no support is provided by SCTP?

        The Internet Architecture does not have a concept of
"clustered endpoints".  So if one is building such a beast, one
ought to include appropriate *internal* mechanisms (i.e. not visible
to the outside, as changes to protocols would be) to make it work 
properly.

        This isn't necessarily rocket science.  However, just as the 
methods for clustering vary widely from one implementation to another, 
the internal methods for ensuring that everything works properly 
in event of failover will need to vary.  Thus, such mechanisms
do not seem ripe for standardisation in IETF.  If one wanted to
standardise clustering methods, IEEE would seem like a more suitable
venue as they have ongoing operating system standards efforts
(and it looks like an OS problem).

        In any event, a properly designed and implemented clustered
system ought to look like a single system to the outside.  That is,
there *ought not* be special protocol changes that would apply only
to clustered systems.

IMHO,

Ran
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 13:31:16 -0600

RJ,

> to the outside, as changes to protocols would be) to make it work 

What do you mean by *internal*?   *Internal* to what?

> (and it looks like an OS problem).

Are you suggesting that the SIGTRAN WG be dechartered and sent to IEEE?

> there *ought not* be special protocol changes that would apply only

They why does SCTP not support this if special protocol changes *ought
not* be required?

--brian

---

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 04 Nov 2001 15:36:56 -0500

>What do you mean by *internal*?   *Internal* to what?

        Internal to the "Cluster Operating System".

>Are you suggesting that the SIGTRAN WG be dechartered and sent to IEEE?

        No.  I gather you either didn't understand or didn't read 
what I wrote.  I'll try again with an effort to use simpler language.

        I'm suggesting that the details of how a cluster operating system 
is built are not IETF work and that those details should be kept hidden 
under the hood of the given cluster (i.e. not be visible on-the-wire).
SIGTRAN isn't chartered to design a cluster operating system, nor
is SIGTRAN chartered to modify transport protocols to solve clustering.
Clustering computer systems is an OS issue not a protocol issue.

>They why does SCTP not support this if special protocol changes *ought

        I did not say that the OS would not need modification.  The
difference between old VMS and clustered VMS was that the OS got
modified to support clustering.  DEC did not change on-the-wire TCP 
when they added cluster support to VMS.  Similarly, on-the-wire SCTP
ought not be changed when adding cluster support to some other OS.

        By definition, if SCTP explicitly supported this, then the 
SCTP protocol would require "special protocol changes that apply only 
to clustered systems".  

        It is up to whichever folks are designing the given clustered
system and its OS to make the cluster look like a single system to
the outside world.  Nothing in the SCTP specs prevents one from doing
that in a myriad of ways (I can think of several approaches that could
work fine).  The SCTP specs simply say that building a cluster is not
within the scope of SCTP -- quite right, building a cluster is an OS
and computer systems problem rather than a protocol problem.

Ran
[email-masked]

---

---

From: Randall Stewart <[email-masked]>
Date: Mon, 05 Nov 2001 06:52:35 -0600

Ran:

I agree 100%.. On top of this the SIGTRAN UA's (as I remember them
at least from a while ago) had a concept of ASP's where one
had multiple of them and they would handle this kind of thing
without necessarily being clusters.

This is also where the RSERPOOL working group got started
and is working towards...

...a very cheap session layer fail-over mechanism...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---