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

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 3 Oct 2005 14:48:57 -0400

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.

Regards,
Lincoln

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

Haresign,

Haresign Lincoln wrote:
(Mon, 03 Oct 2005 14:28:21)
> 
> [lincoln]: OK, so that's my point.  I think Jeff was saying that 
> perhaps the RFC should recommend what to do in the case of a badly 
> behaved network.  The ITU/ANSI specifications are pretty good about 
> recommending what to do.  The SS7 networks have historically been 
> quite robust and I believe this is due to the exacting SS7 
> specification and also years of actual experience.

Also hundreds of millions of dollars of simulation.

> Over the last 25 years (but mostly in the first 15
> years) the SS7 specs were modified a number of times to fix problems 
> and improve reliability.  If SIGTRAN is intended to take the place of 
> the underlying layers in SS7, I think it would benefit the entire 
> community to work together to improve the specifications.

It is not the intention of SIGTRAN to replace SS7.  See the Framework
document.

> Otherwise, customers at
> the highest layers (the non-technical people who hold the money and 
> only see the lost revenues when downtimes occur) won't be interested 
> (or will at least be very hesitant) in deploying SIGTRAN.  And I don't

> think anybody wants that.

Although it might be the place of a BCP to say so, the protocol
specification does not include normative operational considerations.
Neither does SS7 specifications for that matter.

--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.

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Oct 2005 22:35:42 +0200

Lincoln,

SIGTRAN is about interworking of IP based networks and SS7 networks.
This includes (in my view) that you 'replace' the lower layer, but
you are still using SS7 application layers...

So I think both of you are right.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Oct 2005 02:04:26 -0600

Lincoln,

Haresign Lincoln wrote:                             (Mon, 03 Oct 2005 14:48:57)
> I'm missing something.  But in any case, this is how SIGTRAN is being

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/