Subject: RE: [Sigtran] SUA relay function

From: "Richard Adams" <[email-masked]>
Date: Fri, 6 Dec 2002 13:35:31 +0100

Sorry Brian,
I omitted the essential extra part to the first question, which was "and
can this message be routed to the DPC in the CdPA ?"
But your answer is valuable, pls see below!
Kind regards,
Dick.  

Brian wrote:

Richard Adams wrote:                               (Thu, 05 Dec 2002
16:16:41)
> Hello all,
> could anyone tell me of any SS7 network containing nodes that can
receive an
> SCCP message, routed on SSN, at an MTP signalling end point
(containing
> SCCP), where there is a DPC in the message's called party address that
is
> different from the DPC in the MTP label.
{RAA} Should have had "and is this CdPA DPC route-able to for this
message?" {RAA}
All SCCP nodes following Q.714 should be capable of receiving such a
message
and will deliver it to the local DPC (MTP label) + SSN subsystem.
{RAA} OOPs, yes {RAA}
>
> If so, is this message a (X)(L)UDT, and how did it get out from  SCCP
> routing control (SCRC) at the origin into the MTP-TRANSFER request ?

PC1: GT + PC2 + SSN, Route on GT, MTP DPC = PC2

PC2: after GTT
     GT + PC2 + SSN, Route on SSN, MTP DPC = PC3

PC3: GT + PC2 + SSN, Route on SSN, MTP DPC = PC3
	MTP DPC == PC3, deliver to SSN

{RAA} Here, PC2 denotes a node earlier in the message's path, it might
even be in a different PC domain than PC3's. So, if the _SUA_ gets this
message to push it towards the SSN, it must not  attempt to route to PC2
(so the _relay_ function in SUA must not use the PC to route to)
{RAA}
> 
> The SUA draft 14 allows the addressing possibility in section 1.5.3 at
a
> relay node, and it possibly gives me problems with SCCP management
there.

That's an SUA relay node's equivalent of an MTP transfer but using SUA.
In SUA's case, the DPC in the Destination Address in such a message is
the MTP DPC instead of the Called Party Address DPC.  The SUA node knows
that with route on PC + SSN that this DPC != local DPC and the relay
node transfers the message.

How else did you expect it to route normal TCAP response messages?
Or, to route forward to a SUA node to do GTT for that matter?
{RAA} It's fine for messages in the direction SCTP to SUA, but not in
the direction SCCP to SUA. SUA 14 doesn't distinguish this in section
1.5.3. Also, once the RI = "SSN" in SCCP, there is no chance of using GT
routing further along the path. Does the translation/resolution of the
address information of 1.5.3 (sometimes) yield a new RI 
(= "GT") when routing is on SSN[+PC] ?  

Kind regards,
Dick.

--brian

> 
> Q.714 section 2.3.2.3 applies for the originating node. 
> 
> Kind regards,
> Dick Adams.
> 
> _______________________________________________
> 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: "Richard Adams" <[email-masked]>
Date: Fri, 6 Dec 2002 16:24:11 +0100

Philippe,
If PC2 is derived as Brian showed, I think it MUST NOT be used for routing from the SG to an AS. 
However, if PC2 is a genuine PC unrelated to any PC in the earlier part of the path of the message, you seem to me to have a combination of roles at the SG. AS1 is using the SG as a relay point, AS2 is "local" to the SG. If you want to load share (or use primary/backup)between AS1 and AS2, in the SCCP sense, you could define your "entity set" as AS1 + AS2, with a GT(a) for the entity set. Then, if the message is routed on GT(a) to the SG, the GTT done there could derive AS1 as one entity (with DPC 2, SSN 6), and AS2 the other (with DPC 3, SSN 6). Then, for loadsharing, load share to one or the other (using just SLS value as per ITU, or a function of SLS which gives a more even load share). For messages in response, you need to define a GT(b) for AS1, and another GT(c) for AS2, which should be unique. This is just standard SCCP stuff. If you don't want to load share between them you could route on SSN [+PC], with DPC = 3, SSN = 6 for AS2, DPC = 2, SSN = 6 for AS1 (with the SG!
 having multiple point codes, 3 and 2). Or you could route on GT(c) for AS2, GT(b) for AS1.

My earlier qn. to all should have been "how do you manage to get the DPC in the called party address different from that in the MTP label if you start out with routing indicator = "SSN", in the SS7 network. I don't think you can, so you must (I think!) in your case route on GT up to and including the SG, if you want to load share or use primary/backup working. 

-----Original Message-----
From: Bouckaert, Philippe [mailto:[email-masked]]
Sent: 06 December 2002 15:48
To: Richard Adams; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] SUA relay function

Richard, Brian,

the called party address, for a message coming from ss7, should normally not include a PC (Q.714, 2.2.2.1). But if it is present, it must be ignored by SCCP (Q.7142.2.1 "Even if an SPC is present in the "called party address" parameter, it shall not be used by SCRC.").
And ,as Brian mentioned, it should be delivered to the local DPC. 

But if we check the following configuration, there is a problem for message coming from ss7,
	------		 --------------
	| SG 	|---------- | AS 1         |
 	| PC=3|		|  PC=2, SSN=6 |
	------		 --------------
		\            --------
		 \----------|AS 2    |
				|  SSN=6 |
				 --------

message with MTP3 DPC=3, SCCP Cld add=(rtg on SSN, PC=2, SSN=6). 
According SCCP recommendation, this message will be sent to AS 2 (or discarded if AS 2 is not defined). 

Does that mean that, in order to reach AS1, a message must be sent either by using GT, or by using PC =2 as MTP DPC? In this case, the SG should manage several PCs...

What do you think?
Regards,
Philippe

-----Original Message-----
From: Richard Adams [mailto:[email-masked]]
Sent: Friday, December 06, 2002 1:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] SUA relay function

Sorry Brian,

Brian wrote:

> Hello all,
> could anyone tell me of any SS7 network containing nodes that can receive an
> SCCP message, routed on SSN, at an MTP signalling end point(containing
> SCCP), where there is a DPC in the message's called party address that is
{RAA} Should have had "and is this CdPA DPC route-able to for this
message?" 
{RAA}
All SCCP nodes following Q.714 should be capable of receiving such a
message and will deliver it to the local DPC (MTP label) + SSN subsystem.
{RAA} OOPs, yes {RAA}

PC2: after GTT

> 
> The SUA draft 14 allows the addressing possibility in section 1.5.3 at a
> relay node, and it possibly gives me problems with SCCP management there.

Kind regards,
Dick.

--brian

---

From: "Richard Adams" <[email-masked]>
Date: Mon, 9 Dec 2002 14:41:16 +0100

Philippe,
I agree with your reading of Q.714. So, for routing from the origin on "SSN" to PC2, the MTP label DPC has to be DPC2, also the SCCP CdPA DPC has to be DPC 2 (if there is one in there).
And for routing to the SSN6 "at" the SG with DPC 3, the messages routed on SSN have to have MTP label DPC 3. So, these cases imply multiple PC working at the SG. The wording in the SUA relay function description is unclear to me. What is meant by "the address presented is not one of the relay node" ? To me, if the node is doing multiple PC working, all the multiple PCs are of the node!
Perhaps what is meant is that the PC is one for which the SG acts as a pseudo-STP. 
There are a number of different models covered by the SUA draft. I still have to work them all out. But for this sort of "relay node", the SCCP management gets complicated (not least because the SG would have to look inside the "user data" part of all (X)(L)UDT messages to see if they are in fact SCMG messages, and extract the appropriate information, and do the SCCP management (if we assume that SCCP management is not remoted, although the SG is acting as just a relay point - and so it should not have to perform the SCCP management of points it relays to, but it probably does do it!)
 
I think routing on GT is easier from SS7 network to SG.
 
There is another difficulty I can see for messages through the relay point from ASP towards the SS7 network, if the message is to be routed in the IP part of the network on SSN (+DPC), and then routed in the SS7 network on GT. This is because the routing indicator up to the relay point is "SSN". But it needs to be changed to indicate "GT" when the message is onward routed from the relay point by SSN (+DPC in the Destination Address). However, there isn't a way in the Destination Address of saying how this is to be done. The AI states what should be present, but it doesn't at the moment instruct the relay node to change the value of the RI. Perhaps it should!
Kind regards,
Dick.

	-----Original Message----- 
	From: Bouckaert, Philippe [mailto:[email-masked]] 
	Sent: Fri 06/12/2002 15:47 
	To: Richard Adams; [email-masked] 
	Cc: [email-masked] 
	Subject: RE: [Sigtran] SUA relay function

	Richard, Brian,

	

	What do you think?
	Regards,
	Philippe
	
	-----Original Message-----
	From: Richard Adams [mailto:[email-masked]]
	Sent: Friday, December 06, 2002 1:36 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: RE: [Sigtran] SUA relay function

	Sorry Brian,
	
	Brian wrote:

	
	PC2: after GTT

	

	Kind regards,
	Dick.

	--brian