RE: Recommendation for SUA modifications

Brian,

See below.

Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, October 12, 2005 7:25 PM
To: Haresign Lincoln
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Haresign,

Haresign Lincoln wrote:
(Wed, 12 Oct 2005 14:55:35)
> Brian,
> 
> When an ASP registers with an SG (either via static configuration or 
> dynamic configuration), one of the optional parameters is destination 
> address.
> 
> IF the ASP has a routing key of destination address and IF the 
> destination address contains a point code, then the point can be 
> derived from the set of routing keys that define that RC.  (In the 
> case of dynamic registration, if the ASP is sending a point code in 
> the destination address, the this whole issue is moot since the ASP 
> knows the PC).

You told me that your ASPs do not provide a point code on registration.
I suggested making the point code in the address used for registration
mandatory and you objected.

[lincoln]: You asked me to give you the algorithm, so I gave you the
complete algorithm for all cases.  The case I'm trying to solve is the
ELSE case.

> 
> Else the point code of the ASP is the same as the point code of the
SG.

And if the SG has multiple point codes?

So, if there is no point code in the registration and the SG supports
multiple point codes, what is the SG to do?

[lincoln]: Can you explain what you mean by multiple point codes.  Are
you in multiple networks, or are you a primary point code with alias
point codes?  If you are multiple point codes, I'm assuming that the NA
will handle that scenario.

Does the SG:

a) Reject your registration, knowing that, following your proposal, it
   could receive messages from the ASP with underspecified addresses (in
   SCON or CLDT, CORE, etc.).

b) Accept your registration and send ERROR messages when it receives
   such underspecified addresses?  (Messages which of course the ASP
   is fully justified in ignoring.)  Is there an error for that?  Would
   we now need one?

c) Just pick a point code and send an SS7 network congestion message
into
   the PSTN/PLMTN.  (Probably a bad idea.)

The trivial case where the SG has only one point code is not very
interesting, because it is not a provisioning difficulty to provising
this one trivial point code at the ASP.

[lincoln]: You may consider it trivial.  I disagree.  If I'm deploying
100 ASPs behind my SG, I need to provision each one of these
unnecessarily.  And additional provisioning sometimes results in
operator error.
   
IMO to support interoperability between SG an ASP implementations, it
would be better to make the presence of a point code mandatory in both
registration (enforceable by the SG), and in SNMM, CO and CL messages
containing addresses.

This is what was done for M3UA.  M3UA DATA messages contain (mandatory)
both point codes in both directions, even in the trivial case where the
SG only has one point code, and even in the case where RC can be
construed to imply point code.  For M3UA, the affected point code it is
also present (and mandatory) in the SCON message sent from ASP to SG.

I don't see why SUA should be any different.  I can't speak for the
other authors, but when we wrote the SUA RFC, I never considered that an
ASP or SG would ever not include a point code in an address.

[lincoln]: Certainly an ASP doesn't have to include a point code in the
address.  In the case when the SG is a single point code, having the AS
behind the SG have to specify the point code is redundant and
unnecessary.  Especially if the AS are using GTT when addressing
messages.

Making the point codes mandatory in address fields for all SUA messages
better promotes interoperability in all configurations, and the
miniscule expense of causing an ASP to provision a single point code for
an SG with only a single point code.

[lincoln]: Again, you call it miniscule, I see it differently.  These
adjectives have no meaning.  Either it is required, or it is not.  In
SOME network architectures, it is redundant and therefore unnecessary.

--brian

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

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