RE: Congestion in M3UA/SUA and the use of the SCON

Brian,

[brian]: I'm sorry but the concept of an SCCP-User that knows the point
code of every node in the SS7 network that it might want to send
messages to, except its own, is not a very useful one.

I'm sorry to say, but you are mistaken.  Requiring an SCCP user to know
the point codes of any node in the network is too much overhead for most
operators for some applications.  For example, a typical SMS application
deals only with global titles (inbound and outbound).  Operators have no
desire to provision all the PCs in their network.  They do this in the
STPs and use GTT all over the place.  This is a basic fact of operation
in most of the large SS7 networks of the world that are running SMS.  If
you are going to be running SMS over an SUA SG, you would provision your
SG with the inbound/outbound GTs.  The outbound GTs would be to an STP
that would do further GTT to get the message to the MSC or HLR.  You
really don't want to do any provisioning on your ASPs if you can avoid
it except for a single GT.  

Knowledge of global titles is all that is required at an endpoint.

I'm not sure what you mean by "MUST be included in the source and
destination addresses of the Registration Request".  Are you referring
to the PC?  Can you please point out where in the SUA RFC it indicates
this?  I couldn't find it.

And no where in the RFC does it indicate that we need to supply the PC
when sending a message from the ASP to the SG.  Nor does it say that
when the SG sends a message to the ASP, it needs to supply a PC in the
destination address.  Certainly you need to supply an Address Indicator
if you are working with GTT, PC, and/or SSN.  But just like an SCCP user
today, it does not need to supply a point code in either the calling or
called address.  If the PC MUST always be present in the
source/destination address, shouldn't we update the RFC to reflect this?
All I see is an example of how to use the PC value if the Address
indicator is set to a certain value.  The AI just provides information
about how to encode/decode based upon what is present.  If you are
saying the PC is a MUST, then the RFC should be updated to indicate that
the source/destination address _MUST_ contain the Point Code parameter.


Today, that is not the case.  And we can build an ASP that complies to
the RFC without any knowledge of the PC.  Knowledge of the PC for some
applications is unnecessary overhead that operators do not want to
configure.


Regards,
Lincoln



-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Tuesday, October 11, 2005 1:18 PM
To: Haresign Lincoln; Tolga Asveren; [email protected]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

Lincoln,

Oh, also MUST be included in the source and destination addresses of the
Registration Request, because you confused that one too.

I'm sorry but the concept of an SCCP-User that knows the point code of
every node in the SS7 network that it might want to send messages to,
except its own, is not a very useful one.

--brian

Brian F. G. Bidulock wrote:                    (Tue, 11 Oct 2005
10:58:47)
> Lincoln,
> 
> Read down just a couple paragraphs: (the section you quote is 
> applicable to SCCP routing, not information delivered to the
SCCP-User).
> 
> 3.10.2.2.  Address Indicator
> 
>    This parameter is needed for interworking with SS7 networks.  The
>    address indicator specifies what address parameters are actually
>    received in the SCCP address from the SS7 network, or are to be
>    populated in the SCCP address when the message is sent into the SS7
>    network.  The value of the routing indicator needs to be taken into
>    account.  It is used in the ASP to SG direction.  For example, the
PC
>    parameter is present in the destination address of the CLDT sent
from
>    ASP->SG, but bit 2 is set to "0" meaning "do not populate this in
the
>    SCCP called party address".  The effect is that the SG only uses
the
>    PC to populate the MTP routing label DPC field, but does not
include
>    it in the SCCP called party address.
> 
>    In the SG->ASP direction, the source address PC parameter is
present
>    (PC of SS7 SEP).  However, this may have been populated from the
OPC
>    in the received MTP routing label, not from the PC field in the
SCCP
>    calling party address.  In this case, bit 2 = "0" denotes that.
The
>    AI gives further instructions to the SG how and when to populate
the
>    SCCP addresses; in the SG->ASP direction, the AI gives information
to
>    the ASP as to what was actually present in the received SCCP
>    addresses.
> 
> If this is so unclear that you do not understand that both the source 
> and destination addresses always have PC populated when interworking 
> with SS7 (just bit 2 of the address indicator set to indicate whether 
> it came from the MTP routing label or the calling or called part 
> addresses), we need to add to the SCCP I-G that when the CLDT, CLDR, 
> CORE, COAK, COREF is sent from an SG to an ASP that one of a PC, 
> Hostname, or IP address MUST be included in both the destination and 
> source addresses.
> 
> --brian
> 
> Haresign Lincoln wrote:                      (Tue, 11 Oct 2005
08:51:51)
> > Brian,
> > 
> > The result of the GTT is a point code/SSN.  However this information

> > does not need to be forwarded to the ASP in the address field.  A
CLDT
> > message can arrive at the ASP with _NO_ DPC in the message anywhere.

> > 
> > Please refer to the defintion for source address in section 3.10.2:
> > 
> >    -  Global Title (e.g., E.164 number) + optional PC and/or SSN,
SSN
> >       may be zero, when routing is done on Global Title
> > 
> >    -  SSN (non-zero) + optional PC and/or Global Title, when routing
is
> >       done on PC + SSN.  The PC is mandatory in the source address
when
> >       sending from SGP to ASP, and in the destination address when
> >       sending from ASP to SGP to reach the SS7 SEP.
> > 
> >    -  Hostname + optional SSN, when routing is done by Hostname
> > 
> >    -  SSN (non-zero) and optional IP address (IPv4 or IPv6) when
routing
> >       is done on IP address + SSN
> > 
> > It is _NOT_ required that the SG provide the PC/SSN in a CLDT
message.
> > Therefore, if the ASP wants to implement the OPTIONAL SCON 
> > procedure, and it is working with global titles, we need to modify 
> > the SCON message requirements.
> > 
> > Regards,
> > Lincoln
> > 
> 
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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