Subject: RE: [Sigtran] SUA: GTT function placement

From: "Garnero, Pierre" <[email-masked]>
Date: Thu, 2 May 2002 14:56:39 +0200

Brian,

I am not speaking about a SG that cannot service GTT for 
a given Routing Context.
I talk about a GT translation which refer to a point code 
that is no longer accessible on a given SG (and this information
has been, of course, transmitted to the AS thru a DUNA).
In this case, the GT translation (on the SG) works well but the message
cannot be transmitted by the SG, due to the inaccessibility of
the remote point code. As others point codes could be seen 
accessible on this SG, I don't think that this SG must not 
be used (as a whole) by the AS...

Now, as the AS is aware of the pc states, it could be possible 
to perform a GT translation (may be without altering the message
to be send and keeping the called address as is, just to get the 
point code on which the message must be transmitted) and figure out
which SG is able to send this message on the ss7 network.

/Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 2:23 PM
> To: Garnero, Pierre
> Cc: [email-masked]
> Subject: Re: [Sigtran] SUA: GTT function placement
> 
> 
> Pierre,
> 
> Rather than knowing the accessibility of PC1, the ASP selects
> the SG which has an accessible SUA provider layer (as determined
> by the activity of the RC).  If one SG can no longer service
> GTT for a given Routing Context, it should send unsolicited
> ASPIA/Ack for that Routing Context.  In this way, the ASP does
> not need any GTT function whatsoever.  This is no different than
> alias point codes for GTT on STP mates today.  If the SGs have
> independent GTT functions, then they also can have independent
> Routing Contexts.
> 
> --brian
> 
> Garnero, Pierre wrote:                                   
> (Thu, 02 May 2002 13:20:32)
> > Brian,
> > 
> > it seems that you assume in your response that each SG will
> > have exactly the same ss7 network view, that is, they share the
> > same status for each point code in the ss7 network.
> > But, may be, this is too restrictive and I suppose that it is
> > possible to have the following case:
> >   . one SG see a particular PC (say PC1) as accessible
> >   . and the other, see the same PC as inaccessible
> > 
> > In this case, it could be interesting for the AS to select
> > the "right" SG, the one for which PC1 is accessible. And, then, 
> > the AS must rely on a GT translation to find PC1 and
> > figures out that a message for PC1 must be forwarded
> > by a particular SG...
> > 
> > /Pierre
> > 
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Thursday, May 02, 2002 12:06 PM
> > > To: Lamberton, Marc
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] SUA: GTT function placement
> > > 
> > > 
> > > Marc,
> > > 
> > > GTT is not required in the ASP to perform SG selection, just 
> > > as it is not
> > > required in an SEP to perform STP selection.  SCCP does not 
> > > keep track of
> > > the availability of remote subsystems on a per-route 
> > > (per-STP) basis.  It
> > > is both appropriate and adequate for the ASP to loadshare 
> > > outgoing requests
> > > with GT only over the available SGs, just as an SEP does to 
> > > the GTT function
> > > in a mated STP pair.
> > > 
> > > --brian
> > > 
> > > 
> > > Lamberton, Marc wrote:                                 (Thu, 
> > > 02 May 2002 11:00:44)
> > > > Hi all,
> > > > 
> > > > In the SUA draft the GT Translation function is positioned 
> > > in the "SG as
> > > > relay-point". This is clear for inbound messages coming 
> > > from the SS7 network
> > > > with "route on GT" in their called address. 
> > > > 
> > > > For outbound messages (from AS/ASP to SS7) it might be 
> > > possible to perform
> > > > the GTT either in the SG or in the ASP. In a multiple SG's 
> > > configuration, it
> > > > seems that GTT is required in the ASP to perform SG 
> > > selection; if the ASP is
> > > > connected to multiple SG's; the ASP can store the 
> > > availability of remote
> > > > PC/SSN thru each SG, and then use this information to 
> > > perform SG selection.
> > > > For outbound messages with "route on GT" in the called 
> > > address, the ASP must
> > > > perform the GTT to derive a PC, and then select a SG 
> > > capable to reach that
> > > > PC. 
> > > > 
> > > > If the ASP performs a GTT on outbound messages, it would be 
> > > nice to add the
> > > > derived PC into the SUA message called address, and then 
> > > the SGP uses that
> > > > PC for the MTP3 DPC. Can we assume that a SGP receiving a 
> > > message from an
> > > > ASP with a called address containing [RI="route on GT" , a 
> > > GT, and a PC]
> > > > will not perform its own GTT and will use that DPC value 
> > > for the MTP3 header
> > > > ?
> > > > 
> > > > Do you foresee any other issues or advantages to do the GTT 
> > > in the ASP as
> > > > well ?
> > > > 
> > > > Marc Lamberton
> > > > Compaq TPU
> > > > [email-masked]
> > > > Tel. (33)4 9295 5598
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> 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: Thu, 2 May 2002 09:04:23 -0500

Pierre,

Garnero, Pierre wrote:                     (Thu, 02 May 2002 14:56:39)
> which SG is able to send this message on the ss7 network.

There is no need.  The ASP can send the message to the SG and it
will receive CLDR indicating the routing failure if it has return
on error set.  This will result in a N-NOTICE.  This is no different
than if the GTT was local.  If local GTT results in an inaccessible
point code or subsystem, the message will be discarded unless return
on error is set.  The same end occurs:  the AS gets N-NOTICE.  There
is no need to do this on the ASP as the SG is in a better position
to properly return the CLDR.  As this gets translated into the
appropriate TCAP procedure, the TCAP user does not care that the
GTT function is at the SG.  The same is true for CO on CORE.  The
SG would return COREF.

If you place GTT at the ASP, you no longer have ASP behavior, but
IPSP behavior.

--brian

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