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