Subject: [Sigtran] RFC 4666 on Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)

From: [email-masked]
Date: Wed, 20 Sep 2006 16:43:04 -0700

A new Request for Comments is now available in online RFC libraries.

        RFC 4666

        Title:      Signaling System 7 (SS7) Message 
                    Transfer Part 3 (MTP3) - User 
                    Adaptation Layer (M3UA) 
        Author:     K. Morneault, Ed.,
                    J. Pastor-Balbas, Ed.
        Status:     Standards Track
        Date:       September 2006
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      124
        Characters: 292991
        Obsoletes:  RFC3332
        See-Also:   

        I-D Tag:    draft-ietf-sigtran-rfc3332bis-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4666.txt

This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol.  Also,
provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains.  This
protocol would be used between a Signalling Gateway (SG) and a Media
Gateway Controller (MGC) or IP-resident Database, or between two
IP-based applications.  It is assumed that the SG receives SS7
signalling over a standard SS7 interface using the SS7 Message
Transfer Part (MTP) to provide transport.  This document obsoletes
RFC 3332.  [STANDARDS TRACK]

This document is a product of the Signaling Transport
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Sedlak Michael" <[email-masked]>
Date: Thu, 21 Sep 2006 10:33:42 +0200

Hi,

Is there a delta-list between RFC3332 and RFC4666 ?

Best regards,
Michael 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 

        RFC 4666

The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents thereof.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 02:59:11 -0600

Sedlak,

Sedlak Michael wrote:               (Thu, 21 Sep 2006 10:33:42)
> Is there a delta-list between RFC3332 and RFC4666 ?

;) Yes, its:

    draft-ietf-sigtran-m3ua-implementors-guide-07.txt

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Satya Prasad Nemana <[email-masked]>
Date: Thu, 21 Sep 2006 14:34:39 +0530

A general comment on ASP failover cases,
M3UA does not have any method of doing retrieval /retranamission
Although SCTP does have the capability through multi homing,
the ULP should have the request in place to do the retrieval/retransmission
In the case of a single AS having only a single ASP configured, there is 
no chance of retrieval (but this is the most rare configuration as networks
are configured  not to go down with a single point of failure)
In case the AS is configured with two ASPs and each having a different 
SCTP assoc with a single path in  each of the assoc..
there is no chance of message retrieval... as per the current rfc.

No idea if this was not felt important in a telecom network!!

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 03:11:53 -0600

Satya,

Satya Prasad Nemana wrote:                      (Thu, 21 Sep 2006 14:34:39)
> No idea if this was not felt important in a telecom network!!

If you feel its important you might consider supporting, or at
least commenting on:

 http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-corid-04.txt

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 08:31:44 -0400

Satya,

In M3UA network redundancy is provided by SCTP multihoming and host
redundancy by using multiple ASPs for an AS.

For the configuration you are mentioning, if the ASP host is down, there is
no message retrieval possible in SS7 as well for the similar case. If the
SCTP association is lost to an ASP, this shouldn't happen due to network
problems (this property be guaranteed with SCTP multihoming and proper IP
network configuration) and should indicate a host failure.

     Thanks,
     Tolga

> -----Original Message-----
> From: Satya Prasad Nemana
> [mailto:[email-masked]]
> Sent: Thursday, September 21, 2006 5:05 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sigtran] RFC 4666 on Signaling System 7 (SS7) Message
> TransferPart 3 (MTP3) - User Adaptation Layer (M3UA)
>
>
>

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 08:58:22 -0400

Brian,

There is no such mechanism defined in SS7 specifications.

  Thanks,
  Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 21, 2006 8:55 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Tolga,
> Tolga Asveren wrote:                                              
>    (Thu, 21 Sep 2006 08:31:44)
> > 
> > no message retrieval possible in SS7 as well for the similar case.
> 
> When a host (SP) fails in SS7, other SPs are still able to 
> retrieve messages
> from their buffers and send them via alternate SPs.
> 
> M3UA could too, particularly in the case where an SG fails and there
> are multiple SG as STP.
> 
> Again, see:
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 07:19:34 -0600

Tolga,

Tolga Asveren wrote:                        (Thu, 21 Sep 2006 08:58:22)
> There is no such mechanism defined in SS7 specifications.

Oh really?  See in particular Figure A.11/Q.705 (single STP failure)
and Figure A.13/Q.705 (dual STP failure).

And, of course, the mechanism is Clause 5/Q.704.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 09:23:15 -0400

Brian,

Changeover mechanism is not to address host failures because when a host is
down, it can't tell anything about the last received message etc...

    Thanks,
    Tolga

> Sent: Thursday, September 21, 2006 9:20 AM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: Satya Prasad Nemana <[email-masked]>
Date: Thu, 21 Sep 2006 18:57:21 +0530

Tolga,

Consider the situation

SP1 is routing  ISUP messages to  AS1 (which has ASP11, ASP12) via SG- 
SG1 in loadshared...
SG1 has sent 1000 msgs to AS1 via SCTP assoc of ASP11..
When SCTP assoc of ASP11 fails and AS1 has acked via SACK 940 msgs..
The current implementations do not have the capacity to retransmit the 
remaining 60 msgs...
They are lost although we have ASP12 for redundancy purposes.

Considering the case of Multi Homing also...
even if ASP11 is multi homed and loses one path with a similar 
situation, there is still no chance of
retransmitting the msgs as M3UA does not define any such method for 
retrieval ....

Regards,
Satya Prasad

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 07:29:38 -0600

Tolga,

Tolga Asveren wrote:                             (Thu, 21 Sep 2006 09:23:15)
> down, it can't tell anything about the last received message etc...

Changeover addresses link failure, where link failure is defined as
any time at which MTP Level 3 receives link failure indication from
a signalling links, which includes adjacent signalling point failure.
Look at the diagrams.

Besides, the introduction to:

illustrates this well, I think.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 09:33:16 -0400

Satya,

If SCTP association to ASP11 is lost, this implies that ASP11 host is down,
because network redundancy is provided with SCTP multihoming and proper IP
network engineering. When ASP11 is down, there is no way to retrieve
anyhting. The possibility of loosing SCTP association without a host failure
should be guranateed to be below some acceptable threshold value, i.e.
really really low.

BTW, your assumption of SCTP not being able to failover between paths with
no message loss is not correct. SCTP does this without message loss and
missequencing.

     Thanks,
     Tolga
-----Original Message-----
From: Satya Prasad Nemana [mailto:[email-masked]]
Sent: Thursday, September 21, 2006 9:27 AM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 on Signaling System 7 (SS7)Message

Tolga,

Consider the situation

SP1 is routing  ISUP messages to  AS1 (which has ASP11, ASP12) via SG- SG1
in loadshared...

Considering the case of Multi Homing also...
even if ASP11 is multi homed and loses one path with a similar situation,
there is still no chance of
retransmitting the msgs as M3UA does not define any such method for
retrieval ....

Regards,
Satya Prasad

Tolga Asveren wrote:

Satya,

     Thanks,
     Tolga

-----Original Message-----

the ULP should have the request in place to do the
retrieval/retransmission
no chance of retrieval (but this is the most rare configuration
as networks

       RFC 4666

       help: ways_to_get_rfcs

...

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 09:34:13 -0400

Brian,

Addressing link failure does not correspond to host redundancy but to
network interface/network redundancy, which is addressed by SCTP
multihoming.

     Thanks,
     Tolga

> Sent: Thursday, September 21, 2006 9:30 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] RFC 4666 on Signaling System 7 (SS7)
> MessageTransferPart 3 (MTP3) - User Adaptation Layer (M3UA)
>
>
> Tolga,
>

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 21 Sep 2006 09:39:31 -0400

Personally, I would back some type of mechanism for retrieval.
 
Tolga,
 
I agree that in an ideal world, we should never loose associations
except for the case of host failure.  In reality, we are seeing all
sorts of scenarios:
 
1. Some switches/networks require us to run multiple associations to the
same host to improve performance.
 
2. Multihomed associations can fail (daul port NIC failure with SCTP
running on the NIC) while the host remains running.
 
I would back Brian's CORID draft.
 
Regards,
Lincoln

________________________________

Tolga,

Consider the situation

Regards,
Satya Prasad

Tolga Asveren wrote:

	Satya,
	
	In M3UA network redundancy is provided by SCTP multihoming and
host
	redundancy by using multiple ASPs for an AS.
	
	For the configuration you are mentioning, if the ASP host is
down, there is
	no message retrieval possible in SS7 as well for the similar
case. If the
	SCTP association is lost to an ASP, this shouldn't happen due to
network
	problems (this property be guaranteed with SCTP multihoming and
proper IP
	network configuration) and should indicate a host failure.
	
	     Thanks,
	     Tolga

		-----Original Message-----
		From: Satya Prasad Nemana
		[mailto:[email-masked]]
		Sent: Thursday, September 21, 2006 5:05 AM
		To: [email-masked]
		Cc: [email-masked]; [email-masked];
[email-masked]
		Subject: Re: [Sigtran] RFC 4666 on Signaling System 7
(SS7) Message
		TransferPart 3 (MTP3) - User Adaptation Layer (M3UA)

		A general comment on ASP failover cases,
		M3UA does not have any method of doing retrieval
/retranamission
		Although SCTP does have the capability through multi
homing,
		the ULP should have the request in place to do the
		retrieval/retransmission
		In the case of a single AS having only a single ASP
configured, there is
		no chance of retrieval (but this is the most rare
configuration
		as networks
		are configured  not to go down with a single point of
failure)
		In case the AS is configured with two ASPs and each
having a different
		SCTP assoc with a single path in  each of the assoc..
		there is no chance of message retrieval... as per the
current rfc.
		
		No idea if this was not felt important in a telecom
network!!

			A new Request for Comments is now available in
online RFC libraries.

			       RFC 4666
			
			       Title:      Signaling System 7 (SS7)
Message
			
			       I-D Tag:
draft-ietf-sigtran-rfc3332bis-06.txt
			
			       URL:
http://www.rfc-editor.org/rfc/rfc4666.txt
			
			This memo defines a protocol for supporting the
transport of any SS7
			MTP3-User signalling (e.g., ISUP and SCCP
messages) over IP using the
			services of the Stream Control Transmission
Protocol.  Also,
			provision is made for protocol elements that
enable a seamless
			operation of the MTP3-User peers in the SS7 and
IP domains.  This
			protocol would be used between a Signalling
Gateway (SG) and a Media
			Gateway Controller (MGC) or IP-resident
Database, or between two
			IP-based applications.  It is assumed that the
SG receives SS7
			signalling over a standard SS7 interface using
the SS7 Message
			Transfer Part (MTP) to provide transport.  This
document obsoletes
			RFC 3332.  [STANDARDS TRACK]
			
			This document is a product of the Signaling
Transport
			Working Group of the IETF.

			STANDARDS TRACK: This document specifies an
Internet standards track
			protocol for the Internet community,and requests
discussion and
			suggestions for improvements.Please refer to the
current edition of the
			Internet Official Protocol Standards (STD 1) for
the standardization
			state and status of this protocol.  Distribution
of this memo is
			unlimited.
			
			This announcement is sent to the IETF list and
the RFC-DIST list.
			Requests to be added to or deleted from the IETF
distribution list
			should be sent to [email-masked].
Requests to be
			added to or deleted from the RFC-DIST
distribution list should
			be sent to [email-masked].
			
			Details on obtaining RFCs via FTP or EMAIL may
be obtained by sending
			an EMAIL message to [email-masked] with
the message body

			
			       help: ways_to_get_rfcs
			
			Requests for special distribution should be
addressed to either the
			author of the RFC in question, or to
[email-masked].  Unless
			specifically noted otherwise on the RFC itself,
all RFCs are for
			unlimited distribution.
			
			Submissions for Requests for Comments should be
sent to
			[email-masked].  Please consult RFC
2223, Instructions to RFC
			Authors, for further information.

			...

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 07:40:39 -0600

Tolga,

Tolga Asveren wrote:                                                 (Thu, 21 Sep 2006 09:34:13)
> network interface/network redundancy, which is addressed by SCTP

Well, no.  See Figure A.11/Q.705.

Also, SCTP multihoming does not address changeover of traffic
between SGP belonging to the same SG, between ASP belonging
to the same AS, or between SGs.  All of these cases are changing
traffic between associations.  SCTP multihoming does not even
address the failure of a single SGP.  Nor does it even address
taking an ASP or SGP in and out of service.

addresses all these points.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 21 Sep 2006 09:42:24 -0400

Tolga,

It would be possible to implement SCTP in an embedded on a NIC card with
dual ports for supporting multihoming and the UA layers running on the
host.  If the NIC card failed (OR if a Tier 4 support engineering
accidently unplugged a few power cables disabled a couple routers), we
could loose some associations while still keeping others.

Some type of "OPTIONAL" retrieval mechanism would go towards the 0%
message loss that SS7 is striving towards.  I'm not sure why you would
oppose such a mechanism if it is optional.  

Regards,
Lincoln

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, September 21, 2006 9:33 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] RFC 4666 on Signaling System 7(SS7)Message

Satya,

If SCTP association to ASP11 is lost, this implies that ASP11 host is
down, because network redundancy is provided with SCTP multihoming and
proper IP network engineering. When ASP11 is down, there is no way to
retrieve anyhting. The possibility of loosing SCTP association without a
host failure should be guranateed to be below some acceptable threshold
value, i.e.
really really low.

BTW, your assumption of SCTP not being able to failover between paths
with no message loss is not correct. SCTP does this without message loss
and missequencing.

     Thanks,
     Tolga
-----Original Message-----

Tolga,

Consider the situation

Considering the case of Multi Homing also...
even if ASP11 is multi homed and loses one path with a similar
situation, there is still no chance of retransmitting the msgs as M3UA
does not define any such method for retrieval ....

Regards,
Satya Prasad

Tolga Asveren wrote:

Satya,

For the configuration you are mentioning, if the ASP host is down, there
is no message retrieval possible in SS7 as well for the similar case. If
the SCTP association is lost to an ASP, this shouldn't happen due to
network problems (this property be guaranteed with SCTP multihoming and
proper IP network configuration) and should indicate a host failure.

     Thanks,
     Tolga

-----Original Message-----

A general comment on ASP failover cases, M3UA does not have any method
of doing retrieval /retranamission Although SCTP does have the
capability through multi homing, the ULP should have the request in
place to do the retrieval/retransmission In the case of a single AS
having only a single ASP configured, there is no chance of retrieval
(but this is the most rare configuration as networks are configured  not
to go down with a single point of failure) In case the AS is configured
with two ASPs and each having a different SCTP assoc with a single path
in  each of the assoc..
there is no chance of message retrieval... as per the current rfc.

       RFC 4666

This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol.  Also, provision
is made for protocol elements that enable a seamless operation of the
MTP3-User peers in the SS7 and IP domains.  This protocol would be used
between a Signalling Gateway (SG) and a Media Gateway Controller (MGC)
or IP-resident Database, or between two IP-based applications.  It is
assumed that the SG receives SS7 signalling over a standard SS7
interface using the SS7 Message Transfer Part (MTP) to provide
transport.  This document obsoletes RFC 3332.  [STANDARDS TRACK]

This document is a product of the Signaling Transport Working Group of
the IETF.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be added to or
deleted from the RFC-DIST distribution list should be sent to
[email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an
EMAIL message to [email-masked] with the message body

       help: ways_to_get_rfcs

...

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 09:51:56 -0400

Lincoln,

Please see for comments below.

   Thanks,
   Tolga
-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Thursday, September 21, 2006 9:40 AM
To: [email-masked]; Tolga Asveren
Cc: [email-masked]
Subject: RE: [Sigtran] RFC 4666 on Signaling System 7 (SS7)Message

Tolga,

I agree that in an ideal world, we should never loose associations except
for the case of host failure.  In reality, we are seeing all sorts of
scenarios:

1. Some switches/networks require us to run multiple associations to the
same host to improve performance.
[TOLGA]What is the reason for that? If there is not enough bandwidth on the
LAN/IP network, how does it help to have multiple SCTP associations (or are
you referring to a different scenario)?

2. Multihomed associations can fail (daul port NIC failure with SCTP running
on the NIC) while the host remains running.
[TOLGA]Yes, of course they can. My point is, the possibility of this
happening should be guaranteed to be lower than an acceptable value. SIGTRAN
protocols run over IP, which implies that IP network design has something to
do with their performance and reliability (Isn't the same true for SS7
links, that underlying topology must be engineered?).

I would back Brian's CORID draft.
[TOLGA]I won't, unless I see something which is necessary and not addressed
by the current mechanism (or can't be addressed by some extension, which is
following the same philosophy witht he existing mechanism).

Regards,
Lincoln

Tolga,

Consider the situation

Regards,
Satya Prasad

Tolga Asveren wrote:

Satya,

     Thanks,
     Tolga

-----Original Message-----

       RFC 4666

       help: ways_to_get_rfcs

...

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 07:55:10 -0600

Lincoln,

My ISP powers their DSLAMs off of commercial power.  (And they
are also the incumbent phone company.)

There are in fact many maintenance reasons for withdrawing traffic
from a node (e.g. SGP).  Maintenance.  Software upgrade.  Network
reconfiguration.  SS7 handles these through the management and
inhibition of signalling links using the same set of procedures 
that are used for failure.  The management reasons do not include
failure.

In the draft, I highlight the race condition between two SGP when
traffic is switched between them.  Without these procedures it is
unlikely that one could switch traffic on, say, an high capacity
HLR, without risking either message missequencing from prematurely
divering traffic to the alternate SGP, or risking widespread
transaction failure by delaying the traffic too long.  A protocol
approach can switch traffic almost instantaneously, and with little
risk.

Just taking one ASP in the pool down for software upgraed on a big
HLR could cause havoc in the network.  As things stand, you better
do it at 3:00 am.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 07:57:01 -0600

Tolga,

Tolga Asveren wrote:                                                 (Thu, 21 Sep 2006 09:51:56)
> following the same philosophy witht he existing mechanism).

There is no existing mechanism in M3UA.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 21 Sep 2006 09:58:38 -0400

Tolga,

We have run in to some switches where the SCTP is located on NIC cards.
The NIC cards bottleneck.  So they use multiple NICs to get improved
performance.  It has nothing to do with the LAN/WAN itself.

Are you denying below that SS7 links failed?  In a properly engineered
network, and SS7 link should never fail.  But they do.

In a properly engineered IP network, associations should never fail.
But they do.

Lincoln

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, September 21, 2006 9:52 AM
To: Haresign Lincoln
Cc: [email-masked]
Subject: RE: [Sigtran] RFC 4666 on Signaling System 7 (SS7)Message

Lincoln,

   Thanks,
   Tolga
-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Thursday, September 21, 2006 9:40 AM
To: [email-masked]; Tolga Asveren
Cc: [email-masked]
Subject: RE: [Sigtran] RFC 4666 on Signaling System 7 (SS7)Message

Tolga,

sorts of
scenarios:

1. Some switches/networks require us to run multiple associations to the
same host to improve performance.
[TOLGA]What is the reason for that? If there is not enough bandwidth on
the LAN/IP network, how does it help to have multiple SCTP associations
(or are you referring to a different scenario)?

2. Multihomed associations can fail (daul port NIC failure with SCTP
running on the NIC) while the host remains running.
[TOLGA]Yes, of course they can. My point is, the possibility of this
happening should be guaranteed to be lower than an acceptable value.
SIGTRAN protocols run over IP, which implies that IP network design has
something to do with their performance and reliability (Isn't the same
true for SS7 links, that underlying topology must be engineered?).

I would back Brian's CORID draft.
[TOLGA]I won't, unless I see something which is necessary and not
addressed by the current mechanism (or can't be addressed by some
extension, which is following the same philosophy witht he existing
mechanism).

Regards,
Lincoln

Tolga,

Consider the situation

Regards,
Satya Prasad

Tolga Asveren wrote:

Satya,

     Thanks,
     Tolga

-----Original Message-----

       RFC 4666

       help: ways_to_get_rfcs

...

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 09:57:44 -0400

Lincoln,

The SCTP implementation you mentioned is of course possible, but considering
the role of SCTP and its multihoming capability in SIGTRAN, I wouldn't use
such a SCTP card for my deployment, because the rationale behind using SCTP
for SIGTRAN is to provide network interface/network reliability.

BTW, for the equivalent of this in SS7, what would happen if I use a single
card with 16 links? Isn't it the same problem, if the card dies, I loose
everything.

The reason I am against the mechanism is because it is againt the main
principles of SIGTRAN protocols and I don't think there is a real problem
(but this of course is just my personal opinion). To me, the correct aproach
is to make people aware how M3UA addresses network interface/network/host
redundancy and let them engineer their IP networks properly.

    Thanks,
    Tolga

> Sent: Thursday, September 21, 2006 9:42 AM
> To: Tolga Asveren; [email-masked]
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 08:05:33 -0600

Lincoln,

A properly engineered network takes failure into account, rather
than denying its existence.

Nevertheless, the CORID procedures also address divering traffic
for maintenance reasons, not just failure.

--brian

Haresign Lincoln wrote:                     (Thu, 21 Sep 2006 09:58:38)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 10:06:23 -0400

Lincoln,

What corresponds to a SS7 link(s) is (from redundancy point of view), a path
in SCTP, not the SCTP association. One can have (in fact should have for NIC
redundancy) a SCTP associtation spanning multiple NICs.

In SS7, the goal is that some links are alive, not that all links are always
up. Similarly with SCTP, you may loose a path but with proper enginnering
loosing SCTP assocation with no host failure should be a very very samll
probability (like loosing all links in SS7 with no host failure is very very
small probability)

For the switchs you are mentioning, they delibaretly (or just because of
oversight) made a decision, which makes their SCTP not to address NIC
failures. This is rally their problem. The same for the performance.

    Thanks,
    Tolga

> Sent: Thursday, September 21, 2006 9:59 AM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 08:20:47 -0600

Tolga,

So you don't ever want to withdraw traffic for maintenance
reasons?

I remember Summa (now defunct) built a switch like that once:
you had to turn it off to add a T1.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 21 Sep 2006 10:40:25 -0400

Tolga -

1) We have no control over what a customer or other vendor decides to
do.

2) I'm not sure how you define the "main principles of SIGTRAN
protocols".

3) I don't believe that this is equivalent to putting an entire linkset
on one line card.  I'm just talking about putting one multihomed
association on one NIC card with SCTP running on that NIC.  I still have
multiple NICs.

4) This is happening in the real world and message loss is occurring.  I
would be great if the SIGTRAN community worked together to find a real
solution rather than hoping that people will always implement the
perfect solution in the perfect network.

Regards,
Lincoln 

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, September 21, 2006 9:58 AM
To: Haresign Lincoln
Cc: [email-masked]
Subject: RE: [Sigtran] RFC 4666 on Signaling System 7(SS7)Message

Lincoln,

The SCTP implementation you mentioned is of course possible, but
considering the role of SCTP and its multihoming capability in SIGTRAN,
I wouldn't use such a SCTP card for my deployment, because the rationale
behind using SCTP for SIGTRAN is to provide network interface/network
reliability.

BTW, for the equivalent of this in SS7, what would happen if I use a
single card with 16 links? Isn't it the same problem, if the card dies,
I loose everything.

The reason I am against the mechanism is because it is againt the main
principles of SIGTRAN protocols and I don't think there is a real
problem (but this of course is just my personal opinion). To me, the
correct aproach is to make people aware how M3UA addresses network
interface/network/host redundancy and let them engineer their IP
networks properly.

    Thanks,
    Tolga

> It would be possible to implement SCTP in an embedded on a NIC card 
> with dual ports for supporting multihoming and the UA layers running 
> on the host.  If the NIC card failed (OR if a Tier 4 support 
> engineering accidently unplugged a few power cables disabled a couple 
> routers), we could loose some associations while still keeping others.
>

> retrieve anyhting. The possibility of loosing SCTP association without

> a host failure should be guranateed to be below some acceptable 
> threshold value, i.e.
> really really low.
>
> with no message loss is not correct. SCTP does this without message 
> loss and missequencing.
>
>      Thanks,
>      Tolga

> For the configuration you are mentioning, if the ASP host is down, 
> there is no message retrieval possible in SS7 as well for the similar 
> case. If the SCTP association is lost to an ASP, this shouldn't happen

> due to network problems (this property be guaranteed with SCTP 
> multihoming and proper IP network configuration) and should indicate a
host failure.

> (but this is the most rare configuration as networks are configured  
> not to go down with a single point of failure) In case the AS is 
> configured with two ASPs and each having a different SCTP assoc with a

> single path in  each of the assoc..

> MTP3-User peers in the SS7 and IP domains.  This protocol would be 
> used between a Signalling Gateway (SG) and a Media Gateway Controller 
> (MGC) or IP-resident Database, or between two IP-based applications.  
> It is assumed that the SG receives SS7 signalling over a standard SS7 

> suggestions for improvements.Please refer to the current edition of 
> the Internet Official Protocol Standards (STD 1) for the 
> standardization state and status of this protocol.  Distribution of 
> this memo is unlimited.
>
> author of the RFC in question, or to [email-masked].  
> Unless specifically noted otherwise on the RFC itself, all RFCs are 
> for unlimited distribution.
>
> [email-masked].  Please consult RFC 2223, Instructions to 
> RFC Authors, for further information.
>
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 06:55:22 -0600

Tolga,

Tolga Asveren wrote:                                                 (Thu, 21 Sep 2006 08:31:44)
> no message retrieval possible in SS7 as well for the similar case.

When a host (SP) fails in SS7, other SPs are still able to retrieve messages
from their buffers and send them via alternate SPs.

Again, see:

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 11:05:34 -0400

Lincoln,

> Sent: Thursday, September 21, 2006 10:40 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Then why do we have protocols? If a node decides to follow some
protocol, and if it deliberatly does not make use of some redundancy
features provided in the protocol, I think this is really their problem.
> 2) I'm not sure how you define the "main principles of SIGTRAN
[TOLGA]Based on the mechanisms already defined in the protocol and the
rationale behind them.
I really don't like much to use the argument "Because the RFC says so"
(because at so many places the language used is open to interpretation), but
here it goes, from RFC3332 1.3.1
It is recommended that M3UA use the services of the Stream Control
   Transmission Protocol (SCTP) [17] as the underlying reliable common
   signalling transport protocol. This is to take advantage of various
   SCTP features such as:

      - Explicit packet-oriented delivery (not stream-oriented),
      - Sequenced delivery of user messages within multiple streams,
        with an option for order-of-arrival delivery of individual
        user messages,
      - Optional multiplexing of user messages into SCTP datagrams,
      - Network-level fault tolerance through support of multi-homing
        at either or both ends of an association,
      - Resistance to flooding and masquerade attacks, and
      - Data segmentation to conform to discovered path MTU size.

Basically the tool for network redundancy is identified as SCTP multihoming.
> association on one NIC card with SCTP running on that NIC.  I still have
[TOLGA]But those NICs are not used by your M3UA node. If we want to use
them, the SCTP endpoint should span them as well.
> perfect solution in the perfect network.
[TOLGA]We need to think, why this is happening in real world. Is it because
the protocol misses something or is it because people do not
implement/deploy the protocol properly?
I think the real solution is that people make use of SCTP multihoming and
engineer their IP networks properly (like they engineer the physical
topology in SS7 as well).

Let's assume for a while we define a new mechanism, would this help it
people don't impelement it right (or don't implement it at all)?

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 11:11:40 -0400

Brian,

For unsent messages I agree with you, but I think this doesn't require a
change on M3UA itself  from on-the wire protocol point of view. I didn't
check the SCTP socket API document for long time, hopefully they have a
mechanism for that (not that otherwise would prevent some implementor to
provide that type of functionality in their implementation, but considering
that popular OS implementations follow it).

BTW, I also agree that time controlled switchover between associations is a
good idea to decrease probability if missequencing, but again I think it is
a local procedure AFAICS.

    Thanks,
    Tolga

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 21 Sep 2006 11:21:20 -0400

Tolga,

1. Because somebody decide to implement a switch in a certain way does
not mean they violate protocols.  You might say that putting SCTP on a
NIC is not a good idea.  I say that we have no control over how people
implement things. 

2. Nowhere does SCTP guarantee 0% message loss.  SS7 states the same
general principles (e.g., no missequencing, close to no message loss).
And they way they do this is through redundancy on top of redundancy.  A
retrieval mechanism on top of the capabilities that SCTP offers would
get us closer to 0% message loss.  Why are you opposed to an optional
mechanism that improves redundancy?  If you don't want to implement
it....don't.

3. If you implement SCTP on a NIC, you can not have it span multiple
NICs.  This is an implementation choice.  It offloads the host from
running SCTP.  There are arguments for an against it.

4. A retrival type of mechanism would reduce message loss upon failure
of an association when that failure is not related to host failure and
you have other routes to that SGP/ASP.  There is no argument agasint
this basic fact.  

Look, I think you can always say "people should engineer their networks
properly".  And of course I won't argue against that.  But during the 12
months that the customer is tweaking their network and adding load and
adding new switches, etc, etc...should we accept message loss?

Regards,

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, September 21, 2006 11:06 AM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 on Signaling System 7(SS7)Message
TransferPart3 (MTP3) - User Adaptation Layer (M3UA)

Lincoln,

[TOLGA]Based on the mechanisms already defined in the protocol and the
rationale behind them.
I really don't like much to use the argument "Because the RFC says so"
(because at so many places the language used is open to interpretation),
but here it goes, from RFC3332 1.3.1 It is recommended that M3UA use the
services of the Stream Control
   Transmission Protocol (SCTP) [17] as the underlying reliable common
   signalling transport protocol. This is to take advantage of various
   SCTP features such as:

Basically the tool for network redundancy is identified as SCTP
multihoming.
> 3) I don't believe that this is equivalent to putting an entire 
> linkset on one line card.  I'm just talking about putting one 
> multihomed association on one NIC card with SCTP running on that NIC.

> I still have multiple NICs.
>
> 4) This is happening in the real world and message loss is occurring.

> I would be great if the SIGTRAN community worked together to find a 
> real solution rather than hoping that people will always implement the

> perfect solution in the perfect network.
[TOLGA]We need to think, why this is happening in real world. Is it
because the protocol misses something or is it because people do not
implement/deploy the protocol properly?
I think the real solution is that people make use of SCTP multihoming
and engineer their IP networks properly (like they engineer the physical
topology in SS7 as well).

> considering the role of SCTP and its multihoming capability in 
> SIGTRAN, I wouldn't use such a SCTP card for my deployment, because 
> the rationale behind using SCTP for SIGTRAN is to provide network 
> interface/network reliability.
>
> single card with 16 links? Isn't it the same problem, if the card 
> dies, I loose everything.
>

> > engineering accidently unplugged a few power cables disabled a 
> > couple routers), we could loose some associations while still
keeping others.
> > If SCTP association to ASP11 is lost, this implies that ASP11 host 
> > is down, because network redundancy is provided with SCTP 
> > multihoming and
>
> > proper IP network engineering. When ASP11 is down, there is no way 
> > to retrieve anyhting. The possibility of loosing SCTP association 
> > without
>
> > BTW, your assumption of SCTP not being able to failover between 
> > paths with no message loss is not correct. SCTP does this without 
> > message loss and missequencing.
> >
> >      Thanks,
> >      Tolga
> > there is no message retrieval possible in SS7 as well for the 
> > similar case. If the SCTP association is lost to an ASP, this 
> > shouldn't happen
>
> > multihoming and proper IP network configuration) and should indicate

> > a

> > configured with two ASPs and each having a different SCTP assoc with

> > a

> > MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using 
> > the services of the Stream Control Transmission Protocol.  Also, 
> > provision
>
> > is made for protocol elements that enable a seamless operation of 
> > the MTP3-User peers in the SS7 and IP domains.  This protocol would 
> > be used between a Signalling Gateway (SG) and a Media Gateway 
> > Controller
> > It is assumed that the SG receives SS7 signalling over a standard 
> > SS7 interface using the SS7 Message Transfer Part (MTP) to provide 

> > Details on obtaining RFCs via FTP or EMAIL may be obtained by 
> > sending an EMAIL message to [email-masked] with the message

> > body

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 11:35:45 -0600

Tolga,

Tolga Asveren wrote:                              (Thu, 21 Sep 2006 11:11:40)
> For unsent messages I agree with you, but I think this doesn't require a

If the node has another communications path to the node ajacent to the failed
association, buffer updating can be performed just as in SS7, and zero
messages will be lost.  It can be done without waiting and unnecessarily
delaying messages in queue.  Read the draft.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Sep 2006 13:45:34 -0400

Brian,

The method explained in the draft is not something present in SS7
specifications.

We are talking here of two different things:
a)What to do about unsent messages.
b)How to get some information about the last received message by a failed
peer.

a) is a local procedure.

For b), if the host is not down, MTP3 changeover procedure is used for SS7.
For SIGTRAN, SCTP handles failover between the paths.

For b), if the host is down, there is no protocol support(not in SS7 and not
in SIGTRAN). Any mechanism, which can do this (or something similar) locally
is an implementation decision. For example, there is nothing preventing
people to implement a distributed SCTP, which spans multiple hosts. Is this
a good solution IMO not, is it allowed by the protocol I guess so.

     Thanks,
     Tolga
> Sent: Thursday, September 21, 2006 1:36 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Sep 2006 15:04:59 -0600

Tolga,

It was always the intention of the SIGTRAN protocols that
they support multiple associations between ASP and SGP.
See, for example, Figure 5 in RFC 3332.  That figure shows
a near full mesh of SCTP associations between SGP and ASP.

The purpose of multiple hosts in an SG or MGC is reliability.
If you place one association between them, you have a single
point of failure.  Carrier grade systems are designed for
no single point of failure.  To ensure no SPOF, you need
multiple SGP in an SG, multiple SG, and multiple ASPs in
an MGC.

M3UA cannot handle sequenced changeover or changeback
between associations without message loss (or worse,
duplication) using local procedures.  A protocol mechanism
such as corid is necessary.

SS7 does this (all day long).  CORID is precisely the SS7
procedures applied to SIGTRAN.

If there is some point(s) in the draft that you disagree
with perhaps you could quote them and make some suggestions
for improvement.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Satya Prasad Nemana <[email-masked]>
Date: Fri, 22 Sep 2006 09:15:17 +0530

Tolga,

In my config ASP11 has a single path, so does that ASP12....
Multihoming is not involved in the two ASPs for various reasons...

Regarding
"BTW, your assumption of SCTP not being able to failover between paths with
no message loss is not correct. SCTP does this without message loss and
missequencing."

SCTP does not exist as a single entity and there is always an ULP involved..
If the ULP does not request for retrieval, SCTP will not do the retrieval..
SCTP has the capability not to lose messages on path failures...but all 
depends on the ULP.....
M2PA does that as there is MTP3 involved which does the retrieval/retrans...
M3UA does not do that..

Regards,
Satya Prasad

---

From: "Barry Nagelberg" <[email-masked]>
Date: Fri, 22 Sep 2006 08:38:54 -0400

Satya,

Of course M3UA can retrieve unacked messages from the SCTP transmit queue and send them to the AS over another SCTP
association. Why not? Our implementation does.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: Satya Prasad Nemana [mailto:[email-masked]]
Sent: Thursday, September 21, 2006 11:45 PM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 on Signaling System 7 (SS7)Message TransferPart3 (MTP3) - User Adaptation Layer (M3UA)

Tolga,

Regarding

SCTP does not exist as a single entity and there is always an ULP involved..
If the ULP does not request for retrieval, SCTP will not do the retrieval..
SCTP has the capability not to lose messages on path failures...but all depends on the ULP.....
M2PA does that as there is MTP3 involved which does the retrieval/retrans...
M3UA does not do that..

Regards,
Satya Prasad

Tolga Asveren wrote:

Satya,

     Thanks,
     Tolga
-----Original Message-----
From: Satya Prasad Nemana [mailto:[email-masked]]
Sent: Thursday, September 21, 2006 9:27 AM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 on Signaling System 7 (SS7)Message

Tolga,

Consider the situation

Regards,
Satya Prasad

Tolga Asveren wrote:

Satya,

     Thanks,
     Tolga

-----Original Message-----

       RFC 4666

       help: ways_to_get_rfcs

...

---

From: "Ilie Glib" <[email-masked]>
Date: Fri, 22 Sep 2006 17:41:17 +0200

Hello Brian,

Do you really think that it is normal when there are multiple SCTP
associations between two processes, an SGP and an ASP?
How many signalling processes would see each process in that scenario?

By the way Figure 5 in RFC 3332 does not show that case.

Regards

-Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Fri, 22 Sep 2006 11:47:44 -0400

We support this scenario and have deployed it in some networks for
various reasons. 

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Friday, September 22, 2006 11:41 AM
To: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 on Signaling System 7
(SS7)MessageTransferPart 3 (MTP3) - User Adaptation Layer (M3UA)

Hello Brian,

Regards

-Ilie

On 9/21/06, Brian F. G. Bidulock <[email-masked]> wrote:
> Tolga,
>
> It was always the intention of the SIGTRAN protocols that they support

> multiple associations between ASP and SGP.
> See, for example, Figure 5 in RFC 3332.  That figure shows a near full

> mesh of SCTP associations between SGP and ASP.
>
> If you place one association between them, you have a single point of 
> failure.  Carrier grade systems are designed for no single point of 
> failure.  To ensure no SPOF, you need multiple SGP in an SG, multiple 
> SG, and multiple ASPs in an MGC.
>
> M3UA cannot handle sequenced changeover or changeback between 
> associations without message loss (or worse,
> duplication) using local procedures.  A protocol mechanism such as 
> corid is necessary.
>
> SS7 does this (all day long).  CORID is precisely the SS7 procedures 
> applied to SIGTRAN.
>
> If there is some point(s) in the draft that you disagree with perhaps 
> you could quote them and make some suggestions for improvement.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

--
Ilie