RE: RFC 4666 on Signaling System 7 (SS7)Message TransferPart 3 (MTP3) - User Adaptation Layer (M3UA)
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
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
> -----Original Message-----
> From: Haresign Lincoln [mailto:[email protected]]
> Sent: Thursday, September 21, 2006 9:59 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,
>
> 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 protected]]
> Sent: Thursday, September 21, 2006 9:52 AM
> To: Haresign Lincoln
> Cc: [email protected]
> Subject: RE: [Sigtran] 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
>
>
>