Subject: [Sigtran] Conceptual doubt between an ASP and SGP

From: Ajay Garg <[email-masked]>
Date: Thu, 13 Mar 2014 11:48:19 +0530

Hi all.

I am an absolute newbie in telecom domain, so kindly forgive me if I sound
incredibly stupid.

>From what I understand, an ASP is a process running on an AS, and a SGP is
a process running on a SG.
Each ASP <-> SGP link is a SCTP connection.

Also, I understand that SGP is responsible for message-routing, while an
ASP is merely an end-point for a SCTP connection.

Given that, are there any extra differences between a ASP and SGP (in
addition to the routing-capabilities of a SGP)?

I will be grateful for any pointers/clarifications.

Thanks and Regards,
Ajay

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Mar 2014 01:17:29 -0600

Ajay,

Please see comments below...

Ajay Garg wrote:                              (Thu, 13 Mar 2014 11:48:19)
>    Hi all.
>    I am an absolute newbie in telecom domain, so kindly forgive me if I
>    sound incredibly stupid.
>    From what I understand, an ASP is a process running on an AS, and a SGP
>    is a process running on a SG.

Not quite.  See RFC 4666 "1.2 Terminology" for a definition of ASP,
AS, SGP and SG.

>    Also, I understand that SGP is responsible for message-routing, while
>    an ASP is merely an end-point for a SCTP connection.

RFC 4666 describes for 124 pages the differences between ASP and SGP.

BTW, it is not an SGP per se that has routing capabilities, but an
SG, where the SG is made up of some SGP, an SS7 stack and a
interworking function.

See also RFC 2719 "Framework Architecture for Signaling Transport"
for a better overview of what's going on.

--brian

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

---

From: Ajay Garg <[email-masked]>
Date: Thu, 13 Mar 2014 15:34:38 +0530

Brian,

RFC-2719 seems to be too technical for the use-case we are trying to
understand :)
I would rather present (a simplified version of) our use-case.

*
We have 3 nodes - N1, N2, N3.

*
We need to transfer messages in-between N1 and N3.

*
There is an IPSP-IPSP association each between between N1 <-> N2, and N2
<-> N3 (but no IPSP-IPSP association between N1 <-> N3).

*
Also, provisions for GTT are available at each of N1, N2 and N3.

Theoritically/Practically, would the above configuration work? Or is it
necessary to have a SGP configured at N2?

Looking forward to clarifications.

Thanks and Regards,
Ajay

On Thu, Mar 13, 2014 at 12:47 PM, Brian F. G. Bidulock <[email-masked]
> wrote:

-- 
Regards,
Ajay

---

From: David Laight <[email-masked]>
Date: Thu, 13 Mar 2014 10:53:03 +0000

M3UA can’t itself transfer your messages directly from N1 to N3.
It is worth remembering that M3UA carries the interface between MTP3 and its user parts
(typically ISUP and SCCP) over IP.
IPSP seems a ‘bodge’ that more or less works and allows the userparts (at different pointcodes)
to send message to each other.

In your case the SCCP code at node N2 could forward messages that arrive from N1 onwards
to N3. Whether the SCCP you have can be configured to do that is another matter.

                David

From: Sigtran [mailto:[email-masked]] On Behalf Of Ajay Garg
Sent: 13 March 2014 10:05
To: [email-masked]; [email-masked]
Subject: Re: [Sigtran] Conceptual doubt between an ASP and SGP

Brian,
RFC-2719 seems to be too technical for the use-case we are trying to understand :)
I would rather present (a simplified version of) our use-case.
*
We have 3 nodes - N1, N2, N3.
*
We need to transfer messages in-between N1 and N3.
*
There is an IPSP-IPSP association each between between N1 <-> N2, and N2 <-> N3 (but no IPSP-IPSP association between N1 <-> N3).
*
Also, provisions for GTT are available at each of N1, N2 and N3.

Theoritically/Practically, would the above configuration work? Or is it necessary to have a SGP configured at N2?

Thanks and Regards,
Ajay

On Thu, Mar 13, 2014 at 12:47 PM, Brian F. G. Bidulock <[email-masked]<mailto:[email-masked]>> wrote:
Ajay,

--brian

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

--
Regards,
Ajay

---

From: Ajay Garg <[email-masked]>
Date: Thu, 13 Mar 2014 17:04:37 +0530

Thanks a ton David for the clarifications !!

On Thu, Mar 13, 2014 at 4:23 PM, David Laight <[email-masked]>wrote:

>  M3UA can't itself transfer your messages directly from N1 to N3.
>
> IPSP seems a 'bodge' that more or less works and allows the userparts (at
> different pointcodes)
>

Yep, we are in a position to configure Global-Title-Translation (GTT) rules
on N2, which will enable us to "route" messages from N1 -> N3, and N3 -> N1.

However, the above makes us wonder on the following question ::

Assuming all nodes (N1, N2, N3) are pure SIGTRAN-nodes (no SS7 nodes), is
it ever required at all to make N2 a SGP ?
(Of course, that would also mean changing the links between N1 <-> N2, and
N2 <-> N3 to ASP <-> SGP types)

Looking forward to more clarifications !!

Thanks and Regards,
Ajay

>
>
>                 David
>
>
>
>
>
> *From:* Sigtran [mailto:[email-masked]] *On Behalf Of *Ajay Garg
> *Sent:* 13 March 2014 10:05
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [Sigtran] Conceptual doubt between an ASP and SGP
>
>
>
> Brian,
>
> On Thu, Mar 13, 2014 at 12:47 PM, Brian F. G. Bidulock <
> [email-masked]> wrote:
>
> Ajay,
>
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
> P *Please consider the environment and don't print this e-mail unless you
> really need to*
>
>

-- 
Regards,
Ajay

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Mar 2014 07:39:02 -0600

Ajay,

Ajay Garg wrote:                               (Thu, 13 Mar 2014 15:34:38)
>    There is an IPSP-IPSP association each between between N1 <-> N2, and
>    N2 <-> N3 (but no IPSP-IPSP association between N1 <-> N3).
>    *

M3UA IPSP only supports point to point and does not support a transfer
function in the middle.

SUA supports what you are attempting.

--brian

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

---

From: Ajay Garg <[email-masked]>
Date: Fri, 14 Mar 2014 11:45:20 +0530

Brian,

I meant that in the scenario all of N1, N2, N3 are pure sigtran-nodes (i.e.
no SS7 nodes in the network), is there any usecase when transferring
messages from N1->N3 in the configuration ::

              * IPSP-IPSP association between N1 <-> N2
              * IPSP-IPSP association between N2 <-> N3
              * GTT at N2

will have ANY different behaviour (from pure end-user point of view)
against the configuration ::

              * ASP-SGP association between N1 <-> N2
              * SGP-ASP association between N2 <-> N3
              * GTT at N2

?

-- 
Regards,
Ajay

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Mar 2014 02:37:14 -0600

Ajay,

Ajay Garg wrote:                             (Fri, 14 Mar 2014 11:45:20)
>    I meant that in the scenario all of N1, N2, N3 are pure sigtran-nodes
>    (i.e. no SS7 nodes in the network), is there any usecase when
>    transferring messages from N1->N3 in the configuration ::

Yes, I understand, however, the former scenario is explicitly not
supported by the M3UA standard (see some clips below).  We explicitly
only supported IPSP in an end-point to end-point connection with no
intermediate transfer function due to the lack of a satisfactory
interworking of SS7 network management functions.

So, for example, in the AS <-> SG <-> AS configuration, the SG
provides management messages to the one AS on the availability,
restriction and congestion state of the routeset toward the other
AS (not to mention the entire gamut of any necessary rerouting
and MTP restart procedures).

IPSP <-> IPSP does not provide any SS7 network management messages
other than perhaps nodal SCON.

In SS7 terminology, consider the IPSP <-> IPSP connection as an
F-link only.  That is, there cannot be an intermediate transfer
function.  IPSP <-> IPSP is really no more than hardwiring a
restricted subset of two MTP-User interfaces together.

It was not necessary for us to reinvent the entire SS7 network
for IPSP mode, as the AS <-> SG <-> AS configuration was
sufficient.

OTOH, SUA does support GTT and transfer at an intermediate IPSP
node, because SCCP defines its own management and can be (and is)
run over other generic network layers (such as SSCOP).  SCCP
also does not restrict the network location of routing functions.

--brian

RFC 4666

1.2 Terminology

   ...

   IP Server Process (IPSP) - A process instance of an IP-based
   application.  An IPSP is essentially the same as an ASP, except that
   it uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does
   not use the services of a Signalling Gateway node.

   ...

1.3.2.  Services Provided by the M3UA Layer

   ...

   The M3UA layer may also be used for point-to-point signalling between
   two IP Server Processes (IPSPs).  In this case, the M3UA layer
   provides the same set of primitives and services at its upper layer
   as the MTP3.  However, in this case the expected MTP3 services are
   not offered remotely from an SGP.  The MTP3 services are provided,
   but the procedures to support these services are a subset of the MTP3
   procedures, due to the simplified point-to-point nature of the IPSP-
   to-IPSP relationship.

   ...

1.4.3.4.  IPSP Considerations

   Since IPSPs use M3UA in a point-to-point fashion, there is no concept
   of routing of messages beyond the remote end.  Therefore, SS7 and
   M3UA interworking is not necessary for this model.

   ...

4.3.  AS and ASP/IPSP State Maintenance

   The M3UA layer on the SGP maintains the state of each remote ASP, in
   each Application Server that the ASP is configured to receive
   traffic, as input to the M3UA message distribution function.
   Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA
   layer in an IPSP maintains the state of remote IPSPs.

   ...

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

---

From: David Laight <[email-masked]>
Date: Fri, 14 Mar 2014 09:19:31 +0000

From: Brian F. G. Bidulock
> and MTP restart procedures).

But once the message arrives at SCCP in N2, the global title translation
tables can indicate that the message needs to be forwarded to N3
(possibly with a re-written GT).

So although the SS7 message doesn't get transferred from N1 to N3
a TCAP request can be forwarded.

	David

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Mar 2014 03:27:31 -0600

David,

David Laight wrote:                                                                                                            (Fri, 14 Mar 2014 09:19:31)
> a TCAP request can be forwarded.

The response (from N3 to N1) relies on an MTP transfer function at N2,
making it an SG by definition.

--brian

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

---

From: David Laight <[email-masked]>
Date: Fri, 14 Mar 2014 09:46:14 +0000

From: Brian F. G. Bidulock [mailto:[email-masked]]
> David Laight wrote:
...
> making it an SG by definition.

The return message can also be routed on GT.
So can be returned via the SCCP code on N2 (or via some other
entirely different route).

Remember there is no need for the sender and receiver of TCAP
messages to be on the same ss7 network.

	David

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Mar 2014 03:51:07 -0600

David,

David Laight wrote:                    (Fri, 14 Mar 2014 09:46:14)
> The return message can also be routed on GT.

Theoretically, but not in practice.

--brian

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

---

From: David Laight <[email-masked]>
Date: Fri, 14 Mar 2014 10:02:43 +0000

> Theoretically, but not in practice.

I'll find some customer traces out...
I really don't remember seeing one where the source address
had 'route on pointcode and ssn' set.

I'm pretty sure that most of the TCAP messages we see are
routed by GT in both directions.
It might be useful to send the response back to system the
request came from (ie assuming symmetric routing), but that
uses the pointcode from the routing label - N2 in this case.

	David

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Mar 2014 04:15:29 -0600

David,

David Laight wrote:                            (Fri, 14 Mar 2014 10:02:43)
> uses the pointcode from the routing label - N2 in this case.

GTT does not alter the OPC of the original message.

Calling Party Address is only used to identify the caller for
transaction processing and is not used for reverse routing.

GTT can only exist at an intermediate node in the SS7 network
that has the transfer function.  That is the definition of
intermediate node in SS7.

And regardless, IPSP is defined in M3UA as point to point.
Labelling N2 an IPSP is incorrect.  Why do you wish to label
it an IPSP?

It needs follow the protocol behaviour specified for an SG and
anything connecting to it needs follow the protocol behaviour
of an ASP.  Are you trying to side-step those requirements by
mislabelling it?

--brian

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

---

From: David Laight <[email-masked]>
Date: Fri, 14 Mar 2014 11:02:08 +0000

From: Brian F. G. 
> intermediate node in SS7.

You seem to be confusing the MTP3 STP functionality (which forwards
messages based on the routing label - and doesn't modify the label)
with SCCP forwarding based on GT lookup.
If SCCP forwards a messages (with or without rewriting either GT)
then MTP3 will put the local pointcode in the routing label.

SCCP can forward messages in a node that doesn't have MTP3 STP
functionality. Indeed it can forward the message into an entirely
different SS7 network. It could, for example, forward a message
from an ITU network into an ANSI one (leaving you with ITU TCAP
embedded in ANSI SCCP).

	David

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Mar 2014 05:16:05 -0600

David,

David Laight wrote:                         (Fri, 14 Mar 2014 11:02:08)
> from an ITU network into an ANSI one (leaving you with ITU TCAP

Not confused: read Q.714/2.7.5.

But you didn't answer my question: why would you want to mislabel it?

--brian

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

---

From: Ajay Garg <[email-masked]>
Date: Fri, 14 Mar 2014 16:58:45 +0530

Hi Guys,

I am thankful to all of you for helping us clear our queries.

We were just investigating the different scenarios possible, and my
original motive of starting this thread was to obtain clarifications on
what is theoritically feasible/not-feasible, and practically
feasible/not-feasible (as I said, I am an absolute newbie in telecom
domain).

I understand that ASP <-> SGP <-> ASP  is the general preferred
configuration (unless a mesh-configuration is possible, with an IPSP-IPSP
association between EACH pair of IPSPs).

Thanks again for all the help !!!

-- 
Regards,
Ajay

---

From: David Laight <[email-masked]>
Date: Fri, 14 Mar 2014 11:40:47 +0000

> Not confused: read Q.714/2.7.5.

Yes, but what has that to do with the colour of sliced bread?
Section 2.7.5.1 is all about ensuring that the original opc
is available when the calling party address is 'route on pc+ssn'.

> But you didn't answer my question: why would you want to mislabel it?

It would be mislabelled if the routing label contained anything other than
the pointcode of the last SCCP node that processed the message.

Indeed the MTP3 should ensure that all messages from userparts contain
the local pointcode (or a known alias pointcode) as the originating pointcode
in the routing label. The only messages it should send with any
other originating pointcode are those forwarded by the MTP3 STP code.

SCCP can relay messages in a system that doesn't have MTP3 STP
functionality.

	David

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 15 Mar 2014 00:01:47 -0600

David,

David Laight wrote:                           (Fri, 14 Mar 2014 11:40:47)
> the pointcode of the last SCCP node that processed the message.

Following are two frames from a simple TCAP query/response pair.

In the query, following Q.714/2.7.5, as the sender of the TCAP query
wants a response, it needs to set the routing indicator in the calling
party address to Route on SSN.  In this case, the originating SSP
places its OPC in the calling party address as well.  The message is
sent from the SSP 5-2-181 to the STP GTT alias point code 249-150-253.
This is not the point code of the STP.  It is an alias shared between
STP pairs.  The STP point codes are actually 249-40-0 and 249-41-0.

Frame 651: 91 bytes on wire (728 bits), 91 bytes captured (728 bits)
Message Transfer Part Level 2
Message Transfer Part Level 3
    Service information octet
        10.. .... = Network indicator: National network (0x02)
        ..01 .... = ANSI Priority: 1
        .... 0011 = Service indicator: SCCP (0x03)
    Routing label
        DPC: 249-150-253 (16357117) (0xf996fd)
            1111 1001 .... .... .... .... = DPC Network: 249
            .... .... 1001 0110 .... .... = DPC Cluster: 150
            .... .... .... .... 1111 1101 = DPC Member: 253
        OPC: 5-2-181 (328373) (0x502b5)
            0000 0101 .... .... .... .... = OPC Network: 5
            .... .... 0000 0010 .... .... = OPC Cluster: 2
            .... .... .... .... 1011 0101 = OPC Member: 181
        0000 1011 = Signalling Link Selector: 11
Signalling Connection Control Part
    Message Type: Unitdata (0x09)
    .... 0000 = Class: 0x00
    0000 .... = Message handling: No special options (0x00)
    Pointer to first Mandatory Variable parameter: 3
    Pointer to second Mandatory Variable parameter: 9
    Pointer to third Mandatory Variable parameter: 14
    Called Party address (6 bytes)
        Address Indicator
            1... .... = National Indicator: Address coded to National standard (0x01)
            .0.. .... = Routing Indicator: Route on GT (0x00)
            ..00 10.. = Global Title Indicator: Translation Type only (0x02)
            .... ..0. = Point Code Indicator: Point Code not present (0x00)
            .... ...1 = SubSystem Number Indicator: SSN present (0x01)
        SubSystem Number: SSN not known/not used (0)
        Global Title 0x2 (4 bytes)
            Translation Type: 0xfe
            Called Party Digits: 800572
                Called or Calling GT Digits: 800572
                Number of Called Party Digits: 6
    Calling Party address (5 bytes)
        Address Indicator
            1... .... = National Indicator: Address coded to National standard (0x01)
            .1.. .... = Routing Indicator: Route on SSN (0x01)
            ..00 00.. = Global Title Indicator: No Global Title (0x00)
            .... ..1. = Point Code Indicator: Point Code present (0x01)
            .... ...1 = SubSystem Number Indicator: SSN present (0x01)
        SubSystem Number: BSSAP/BSAP (254)
        PC: 5-2-181 (328373) (0x502b5)
            0000 0101 .... .... .... .... = PC Network: 5
            .... .... 0000 0010 .... .... = PC Cluster: 2
            .... .... .... .... 1011 0101 = PC Member: 181
ANSI Transaction Capabilities Application Part

The STP (and we can only tell which one by looking at the link upon which
the message was sent) performs GTT and sends the message on to SCP without
altering the OPC (in the Calling Party Address).  In this case the query
was forwarded to one of 4 SCPs in a pool: the SCP with point code 249-150-29.

In frame 654, the SSP receives the TCAP response directly from the SCP as
you can see from the OPC and DPC in the MTP label and thus utilizes the
transfer function of some STP in the network (again, only the incoming link
can identify which one).

Frame 654: 71 bytes on wire (568 bits), 71 bytes captured (568 bits)
Message Transfer Part Level 2
Message Transfer Part Level 3
    Service information octet
        10.. .... = Network indicator: National network (0x02)
        ..01 .... = ANSI Priority: 1
        .... 0011 = Service indicator: SCCP (0x03)
    Routing label
        DPC: 5-2-181 (328373) (0x502b5)
            0000 0101 .... .... .... .... = DPC Network: 5
            .... .... 0000 0010 .... .... = DPC Cluster: 2
            .... .... .... .... 1011 0101 = DPC Member: 181
        OPC: 249-150-29 (16356893) (0xf9961d)
            1111 1001 .... .... .... .... = OPC Network: 249
            .... .... 1001 0110 .... .... = OPC Cluster: 150
            .... .... .... .... 0001 1101 = OPC Member: 29
        0100 1000 = Signalling Link Selector: 72
Signalling Connection Control Part
    Message Type: Unitdata (0x09)
    .... 0000 = Class: 0x00
    0000 .... = Message handling: No special options (0x00)
    Pointer to first Mandatory Variable parameter: 3
    Pointer to second Mandatory Variable parameter: 5
    Pointer to third Mandatory Variable parameter: 7
    Called Party address (2 bytes)
        Address Indicator
            1... .... = National Indicator: Address coded to National standard (0x01)
            .1.. .... = Routing Indicator: Route on SSN (0x01)
            ..00 00.. = Global Title Indicator: No Global Title (0x00)
            .... ..0. = Point Code Indicator: Point Code not present (0x00)
            .... ...1 = SubSystem Number Indicator: SSN present (0x01)
        SubSystem Number: BSSAP/BSAP (254)
    Calling Party address (2 bytes)
        Address Indicator
            1... .... = National Indicator: Address coded to National standard (0x01)
            .1.. .... = Routing Indicator: Route on SSN (0x01)
            ..00 00.. = Global Title Indicator: No Global Title (0x00)
            .... ..0. = Point Code Indicator: Point Code not present (0x00)
            .... ...1 = SubSystem Number Indicator: SSN present (0x01)
        SubSystem Number: BSSAP/BSAP (254)
ANSI Transaction Capabilities Application Part

MSC/HLR location query/response pairs function the same.

So, you are incorrect: SCCP cannot function in even the simplest of
query/response pairs without using the transfer function capability
of an intermediate node in the network.

Nevertheless, I and a few others defined the point-to-point IPSP
behaviour for M3UA and it is not the definition you seem to want
to overlay over the standard, which sounds more like hop-to-hop.

--brian

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