Subject: [Sigtran] SUA IP+SSN based routing and load sharing.

From: "Sulakshan Vajipayajula" <[email-masked]>
Date: Wed, 23 Jan 2008 12:37:11 -0500

Hello All,

I need some clarifications from the experts on understanding the IP+SSN
based RKEYS operating in LOADSHARE mode.

How should a (IP+SSN based) RKEY be defined if it is shared among
multiple ASPs (multiple SCTP associations) with in an Application
server. Each ASP (SCTP association) has different IP address than the
one defined in the RKEY.  Can we even define an IP+SSN based RKEY in
LOADSHARE mode?

For SUA CORE (connection_request) message containing a destination
address (IP+SSN), is it ok if the destination address differs from the
IP address in the SCTP association.

Thanks in advance.

Sulakshan

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 23 Jan 2008 13:35:29 -0700

Sulakshan,

IP+SSN never made any sense to me, but there is no
requirement for the IP to be the same as any IP
belonging to any SCTP association: the IP address
simply identifies an SCCP endpoint in the same manner
as an point code.  So IP+SSN is the same as PC+SSN
except the IP represents the end point instead of the
PC.  Or, for IPv4, consider an IP address as effectively
a 32-bit point code.

--brian

Sulakshan Vajipayajula wrote:                 (Wed, 23 Jan 2008 12:37:11)
> 
>    Hello All,
> 
> 
>    I  need  some  clarifications  from  the  experts on understanding the
>    IP+SSN based RKEYS operating in LOADSHARE mode.
> 
> 

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 23 Jan 2008 15:44:10 -0500

Brian,

I agree.  Perhaps the AS represents a "virtual IP" that is being used by
all the ASPs in the AS if loadshare is the routing mode in an SG/AS
relationship.  

It is my understanding that 3GPP is pushing SUA with SSN & IP as the
Routing Keys as the preferred method so as that a packet can clearly be
traced from source to destination.  However, if loadshare and Virtual IP
were being used, this would tend to defeat at least one leg of the path
(perhaps there is only one leg if there are no SCCP relay points).

Perhaps the intention is to use SSN/IP in an ALL IP network (no SG,
therefore no loadshare mode).  In this case, perhaps it makes sense.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2008 3:35 PM
To: Sulakshan Vajipayajula
Cc: [email-masked]
Subject: Re: [Sigtran] SUA IP+SSN based routing and load sharing.

Sulakshan,

IP+SSN never made any sense to me, but there is no
requirement for the IP to be the same as any IP belonging to any SCTP
association: the IP address simply identifies an SCCP endpoint in the
same manner as an point code.  So IP+SSN is the same as PC+SSN except
the IP represents the end point instead of the PC.  Or, for IPv4,
consider an IP address as effectively a 32-bit point code.

--brian

Sulakshan Vajipayajula wrote:                 (Wed, 23 Jan 2008
12:37:11)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 23 Jan 2008 14:07:31 -0700

Haresign,

Haresign Lincoln wrote:                   (Wed, 23 Jan 2008 15:44:10)
> therefore no loadshare mode).  In this case, perhaps it makes sense.

Yes, the purpose for IP+SSN was in an all-IP network (SUA nodes
operating as relay nodes or IPSP nodes) and what it avoids would
be arbitrarily assigning an SS7 point code to a node that never
sees an SS7 network (what numbering authority would you get that
from)?  Perhaps hostname+SSN would have made more sense in an
all-IP network, but there is no hostname+SSN, just hostname.

Where it never made sense to me was using SUA at all in an
all-IP network.  Something more like ITU-T's TI-SCCP (Q.2220)
using the Generic Signalling Transport Service (see Q.2150.0,
Q.2150.1, Q.2150.2 and, for SCTP, Q.2150.3) makes more sense to
me.

--brian

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