RE: RFC 4666 on Signaling System 7 (SS7)Message TransferPart 3 (MTP3) - User Adaptation Layer (M3UA)

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

________________________________

From: Satya Prasad Nemana
[mailto:[email protected]] 
Sent: Thursday, September 21, 2006 9:27 AM
To: Tolga Asveren
Cc: [email protected]
Subject: Re: [Sigtran] RFC 4666 on Signaling System 7 (SS7)Message
TransferPart 3 (MTP3) - User Adaptation Layer (M3UA)


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



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 protected]]
		Sent: Thursday, September 21, 2006 5:05 AM
		To: [email protected]
		Cc: [email protected]; [email protected];
[email protected]
		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!!
		
		[email protected] wrote:
		
		    

			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 protected],
			                   [email protected]
			       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 protected].
Requests to be
			added to or deleted from the RFC-DIST
distribution list should
			be sent to [email protected].
			
			Details on obtaining RFCs via FTP or EMAIL may
be obtained by sending
			an EMAIL message to [email protected] with
the message body
			
			help: ways_to_get_rfcs. For example:
			
			       To: [email protected]
			       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 protected].  Unless
			specifically noted otherwise on the RFC itself,
all RFCs are for
			unlimited distribution.
			
			Submissions for Requests for Comments should be
sent to
			[email protected].  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 protected]
			https://www1.ietf.org/mailman/listinfo/sigtran
			
			
			
			
			      

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

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

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