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

Lincoln,

Please see for comments below.

   Thanks,
   Tolga
-----Original Message-----
From: Haresign Lincoln [mailto:[email protected]]
Sent: Thursday, September 21, 2006 9:40 AM
To: [email protected]; Tolga Asveren
Cc: [email protected]
Subject: RE: [Sigtran] 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.
[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




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