Subject: RE: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 11 Oct 2005 08:51:51 -0400

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

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, October 10, 2005 5:19 PM
To: Haresign Lincoln
Cc: Tolga Asveren; [email-masked]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

Haresign,

Haresign Lincoln wrote:
(Mon, 10 Oct 2005 14:43:29)
> Brian,
> 
> Perhaps you were not aware, but additional GTT can also take place at 
> an endpoint.

Yes, and the result of GTT is a point code.

> Many STPs will do GTT and they can allow further GTT to take place at 
> the final destination (the signalling end point).

And to send the message to that end point requires a point code.

> In this
> case, it will arrive at an SG with a GTT in the called and calling 
> address.

If there is no point code in the called address, it is taken from the
DPC of the MTP label.  SUA does not have an MTP label so this
information is included in the Called Address for SUA.

> The SG is not required to (and probably shouldn't) convert the called 
> address to a PC/SSN.

For ASP operation it does.  SUA SG-ASP transport the SCCP-SCCP User
interface (see the RFC).  See Q.711.  CL and CREF are always delivered
to the SCCP User with a MTP-SAP (point code and SI value).

> So a CLDT may arrive at the ASP with JUST a GT in the called address.

No.  There are some cases in Q.711 CO where the Responding Address can
differ from the Called Address during connection set up, but both still
contain an MTP-SAP.

> 
> And you may have designed your architecture so the ASPs have no need 
> to know their point code (a much simpler configuration).  This is 
> nothing NEW or outside the spec.

You can do that, however, to signal SCCP congestion requires
identification of the SCCP that is suffering congestion, and the SCCP is
identified by its MTP-SAP (point code and SI value), not by a Global
Title.  Therefore, the Affected Point Code is mandatory in the SCON,
just as it is mandatory in the N-PCSTATE Indication.

--brian

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Oct 2005 10:58:47 -0600

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 F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Oct 2005 11:18:09 -0600

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)

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