Subject: RE: [Sigtran] recommendations for M3UA/SUA BEATs when running overSCTP

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 4 Oct 2005 08:51:25 -0400

Thanks Brian.  I couldn't find these later drafts through searching.
I'll take a look at them.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2005 4:11 AM
To: Haresign Lincoln
Cc: Jeff Morriss; [email-masked]
Subject: Re: [Sigtran] recommendations for M3UA/SUA BEATs when running
overSCTP

Lincoln,

By the way, a more current version of the corid draft is here:

  http://www.openss7.org/docs/draft-bidulock-sigtran-corid-02.txt
  http://www.openss7.org/docs/draft-bidulock-sigtran-corid-02.ps
  http://www.openss7.org/docs/draft-bidulock-sigtran-corid-02.pdf

The document did not receive any support as a WG item and expired almost
2 years ago.  You will find backwards compatible procedures in that
draft that can be used by M3UA, even if the other side does not support
the draft.
I would recommend that you use at least that subset when you ABORT
associations in the manner you describe.

--brian

Haresign Lincoln wrote:
(Mon, 03 Oct 2005 14:41:26)
> Brian,
> 
> That's really a separate issue.  Whenever we loose an association for 
> whatever reason, there exists the possibility of message loss.  I 
> consider this one of the major shortcomings of the current 
> specification.  I have reviewed an early draft (Version 0) of your 
> recommendation for using the COORID to prevent message loss and I 
> think it's a good idea.  I haven't seen any other switches that we 
> have interfaced to using this nor have any customers mentioned this.  
> I believe that, as the customers become more educated, they will begin

> to look for solutions to this problem and I think your recommendation 
> is a good place to start.
> 
> Regards,
> Lincoln

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 4 Oct 2005 09:11:06 -0400

Brian,

I don't disagree with anything you've stated below.  We are deploying
M3UA in both ASP and IPSP mode in networks.  And whether the networks
are crappy, or actually quite good, occasionally associations fail.
This can be due to switches at the remote end don't behave properly,
cables fail or are disconnected, IP networks temporarily have problems
or exceed capacity, etc.....  Hey, even the SS7 networks occasionally
fail (and sometimes catastrophically).

My conclusion from this long email chain is:

1) It's probably not a bad idea to send heartbeats if you or your
customer are concerned about end-to-end user part connectivity.

2) It's probably not a bad idea to look at additional (optional)
algorithms for retrieval after an association has failed.  I would
personally help back such a recommendation if it was proposed.

3) Whether it was the original intent of not for the SIGTRAN working
group, M3UA is now being deployed widely in non-VoIP solutions as
replacements to the lower layers of MTP.  And several large switch
vendors are actively pushing this.  I don't believe we should allow the
RFCs and/or the IETF to remain stuck if the networks are evolving.  

4) Of course nobody has bad networks or bad implementations in mind when
they develop standards.  But on the other hand, we see that very good
protocols are designed to handle failures.  That is why we have all the
timers in L3 MTP, TCAP, etc...  These timers were specified in the
ITU/ANSI recommendations to handle bad networks and faulty
implementations.  And if you haven't implemented the timers (the fail
safes), the operators won't let you in the networks.

5) We are implementing local congestion control.  If the remote end
stops responding (except with heartbeats) for too long, we will tear
down the connection.

I'm not sure I have anything else to add that already hasn't been stated
a few times already.  And I think many of us are not necessarily in
disagreement.

Regard,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2005 4:04 AM
To: Haresign Lincoln
Cc: Michael Tuexen; [email-masked]; Jeff Morriss
Subject: Re: [Sigtran] recommendations for M3UA/SUA BEATs when running
overSCTP

Lincoln,

Haresign Lincoln wrote:                             (Mon, 03 Oct 2005
14:48:57)
> Brian,
> 
> "It is not the intention of SIGTRAN to replace SS7.  See the Framework

> document. "
> 
> I'm not sure why you say this.  SIGTRAN is replacing the lower layers 
> of SS7.  If you are operating a switch that is talking M3UA IPSP to 
> another switch.  You have replaced the lower layers of SS7 with 
> SIGTRAN.  This is exactly what our customers are doing today for a
variety of reasons:
> 
> - bandwidth problems with SS7
> - Offloading SMS traffic from voice networks to avoid congestion in 
> voice call setup
> 
> Our customers are replacing SS7 with SIGTRAN.  We have SMSCs talking 
> directly to a HLRs and MSCs via SIGTRAN.  I didn't see anything in the

> framework that indicated that this was not the intended use.  Perhaps 
> I'm missing something.  But in any case, this is how SIGTRAN is being 
> deployed in some cases.
> 

As can be seen from RFC 2719 (the Framework document), it was never our
intentions to replace the SS7 network with SIGTRAN when this work was
started.  It was originally intended for backhauling SS7 signalling from
an MG (at a SCN POP) to a MGC (probably centrally located).  Or for an
SG (kind of a MG without media) to a MGC.  Backhaul by definition does
not embrace replacement of the SS7 network, because it cannot exist
without one.  Of course it also relieves the transport of performance
and conformance issues because it becomes the responsibility of the
MG/SG/MGC operator.

IPSP arrangements do not occur in the framework document.  Optional
support for them was an afterthought for everthing but M2PA (which is
only IPSP, but some would say that M2PA was an afterhought itself) and
SUA (IP relay).  (Yes that leaves just M3UA.)  When RFC3332 was going
through last call the WG was blocked on may IPSP issues and we pretty
much agreed that because IPSP operation was completely optional that we
would let it go with defects.  The more glaring of those might be fixed
in the rfc3332bis draft, but IMO IPSP behavior is still to loose to be
of any use in M3UA.

One of the reasons for IPSP as an afterthought was because the
"pre-standard" (TALI) supported it.

What you will see in the Framework document is the concept of the SG-SG
transport (Figure 10/RFC 2719), but again only in the backhaul sense.

IMO the only SS7 UA suitable for consideration for SS7 replacement would
be M2PA, and then over a graded private network with full network
redundancy (probably still cheaper than SS7 links in some places).  M2PA
is the only UA that replaces a layer of the SS7 stack, and then only MTP
Level 2, which was done before with ATM, so it was not a stretch for
carefully controlled IP networks.

M3UA is intended for backhaul.  It does not replace any layers of the
SS7 stack.  (Look at Figure 7 in RFC 2719).  It transports the
"interface" between two SS7 layers.  In M3UA's case, it is the
MTP/MTP-User interface that is transported.  A fully functioning MTP
stack is required on the SG side and a fully functioning MTP-User (e.g.
ISUP) is required at the MGC.

M3UA was crafted carefully to place no new (not already existing in SS7
specifications) requirements of the MTP or of the MTP-User.  Its purpose
(from the introduction of the document) is to transport this interface
in such a was at to keep transparency between the MTP and MTP-User.  We
stuck to the IUT primitive interface as closely as possible to
accomplish that.  A traditionally frictionless function call or message
passing interface inside of an SS7 stack implementation, becomes
extended over an IP network.  I don't think we had a crappy IP network
or broken SCTP stacks in mind.

If your customers are replacing 3GPP SS7 networks with M3UA, then they
are probably following 3GPP TS 29.202, in which case I suggest you take
the matter up with ETSI instead of the IETF, but there are a number of
points to make about TS 29.202:

It says that "[t]he transport of an MTP3-user signalling messages [sic]
shall be accomplished in accordance with the architecture defined by the
"Framework Architecture for Signalling Transport" [16], by "Stream
Control Transmission Protocol"[8] and by the IETF document available in
Annex A."

Now it is interesting that RFC 2719 does not include IPSP in the
architecture.  Yet TS 29.202 describes "Interface C" in Annex A and
places requirements on it.

Note also that in Annex A/TS 29.202 HEARTBEAT is Mandatory even though
in TS 102 142 says that HEARTBEAT will not be sent.  (I'm sure Jeff will
be glad to hear that.)

Also note that these documents haven't had any real changes made to them
in the last 3 or 4 years (since the telecom bust).

So, if your customers are having problems deploying M3UA in IPSP mode in
their 3GPP networks, particularly to replace SS7 transport, a policy
that 3GPP TS 29.202 clearly endorses, that you or they should take the
matter up with ETSI/3GPP.  Certainly the reliability and performance of
M3UA over ungraded IP networks is nowhere near that of the other two
transports listed (SS7 NB and ATM).  Also, the existence of Annex A
should have twigged somebody to the fact that M3UA is plagued with
interoperability issues, has no real conformance specification nor
validation testing, and is probably inadequate to the task.  If your
customers want to jam it in and save a buck or two on facilities, that's
their business, but when encountering problems in such an arrangement,
please have them complain to those that advocated such an arrangement or
tell them to just push those problems aside and imaging how much money
they are saving on facilities. ;)

As you can clearly see from RFC 2719, we were addressing the ETSI TIPHON
"J" (MGC to SG) interface which is primarily a VoIP interface.

After the release of RFC 3332 we were supposed to do work on an MTP3
SG-SG protocol based on RFC 3332, as an IPSP replacement draft, that
would have been more suitable for the pure SS7 transport envisioned by
TS 29.202, however, work on the pure peer-to-peer SG-SG protocol (call
it M3PA) never got off the ground.  I don't know that there are enough
active contributors left in this WG to complete it anyway.

So, that's why I say that "It is not the intention of SIGTRAN to replace
SS7.  See the Framework document. "

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 4 Oct 2005 09:20:44 -0400

I would agree with your reasoning below. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Monday, October 03, 2005 6:25 PM
To: [email-masked]
Subject: RE: [Sigtran] recommendations for M3UA/SUA BEATs when running
overSCTP

> In our implementation, we are taking down the associations if the 
> other side is misbehaving.  We are operating outside the specification

> in this case.  But I don't think any customers will complain when we 
> explain to them that we are protecting against lost revenue.
[TOLGA]Actually, this can be considered as not really against the
specification(?). Afterall, an association can be brought time any time
for administrative reasons -normally one would first inactivate RKs but
this is besides the point-. OTOH, mentioning about this issue in the
specification could be useful for future implementors. Something like:
"If an anomaly on an SCTP association is detected, association MAY be
torn down. The means of detecting such situations is implementation
dependent and outside of the scope of this recommendation."

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 5 Oct 2005 10:06:50 -0400

Brian,

I agree that this does apply to other UA layers.  And I would certainly
be willing to go through the process/discussions associated with your
draft.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2005 6:23 PM
To: Haresign Lincoln
Cc: Jeff Morriss; [email-masked]
Subject: Re: [Sigtran] recommendations for M3UA/SUA BEATs when running
overSCTP

Haresign,

Haresign Lincoln wrote:
(Tue, 04 Oct 2005 16:11:02)
> Brian,
> 
> My point is that in SS7 networks, links fail.  There is no getting 
> around it.  Our SS7 software is deployed in hundreds of networks 
> throughout the world and on a fairly regular basis, we have had to 
> work with customers to help them resolve why links are failing (I/O 
> cards gone bad, bad use of the Master clock in the network, bad 
> cables, bad connectors, etc...).
> 
> And when they fail, the layer above (MTP Level 3) has a procedure to 
> ensure no data loss when alternate paths exist to route the message. I

> believe a similar mechanism should exist in SIGTRAN to get the same 
> level of fault tolerance in SS7.

Of course I agree.  That is why I wrote draft-bidulock-sigtran-corid.
It provides just such a mechanism using existing protocol elements.
Also it addresses M3UA, SUA and TUA, not just M3UA.

Would you like to see that draft made a WG item?

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/