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

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 protected]] 
Sent: Thursday, September 21, 2006 11:06 AM
To: [email protected]
Subject: RE: [Sigtran] RFC 4666 on Signaling System 7(SS7)Message
TransferPart3 (MTP3) - User Adaptation Layer (M3UA)

Lincoln,

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email protected]]
> Sent: Thursday, September 21, 2006 10:40 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 -
>
> 1) We have no control over what a customer or other vendor decides to 
> do.
[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 
> protocols".
[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.
> 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.
[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.
>
> 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).

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)?


>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]]
> Sent: Thursday, September 21, 2006 9:58 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,
>
> 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


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