RE: FW: RFC 4666 M3UA

Kevin, 

 

All good points... points to which I agree... It is definitely not the
best implementation due to the need to open gateway screening for a new
set of point codes that will originate the RCT and new routing for TFCs
(potentially).   

 

Assuming the routing and GWS issues can be overcome, and I agree it's a
pain, the congestion onset and abatement procedure will still work the
same way.    A STP that is congested will send a TFC.   The ITP will
"translate" that TFC into a SCON message.  The IP node will send a DAUD
(Destination Audit) message.  The ITP will "translate" it to a RCT.   If
the ITP does not receive a TFC in response to the RCT, it will send a
Destination Available message to the IP node letting it know the
congestion has abated and traffic will start again.  

 

Now to try to answer your specific questions... I'll do my best...

 

*	If the RCT can't be responded to at all because there is no
routing back to it in all the the STP hops then Both ITP's are out of
sync because neither really knows the true congestion status. 

Correct... traffic would start due to the node not receiving a TFC in
response to the RCT.   If the congestion has not abated, then another
TFC would be sent to the IP node... definitely not the way the TFC/RCT
process was intended to work. 

*	Do both ITP's "Really" handle traffic in a load shared
situation? If not sync is irrelevant. 

It does

*	Is traffic load shared to the ITP/SG or is it costed? If it is
costed on the SS7 side then sync is irrelevant as all SS7 traffic will
point to one ITP/SG thus forcing all TFC's to the same ITP

Load share... Just like a regular B-quad. 

*	Is traffic load shared on the IP side? or Does it switch
ITP/SG's as network management directs? 

Load share... Just like a regular A-link.. 

*	When one ITP/SG sends SCON does the IP endpoint send DAUD to
both ITP/SG's or only to one?

Good question.  If I remember right, it sends to the one it receives the
SCON from.  I don't have my protocol analyzer session data saved (dummy
me) to reference. 

Josh

 

 

 

________________________________

From: [email protected] [mailto:[email protected]] 
Sent: Thursday, September 20, 2007 9:34 AM
To: Tuel, Josh
Cc: [email protected]
Subject: RE: [Sigtran] FW: RFC 4666 M3UA

 

Josh,
This is all new ground. Realistically the SS7 Gateway could be designed
to send a RCT with either the OPC of the Gateway or an OPC of the
relevant point code assigned to the IP endpoint that the SS7 trunks
terminate to.
Each has merit /fault within the IP architectures.

Here's the rub.

Since the beginning of SS7 and TFC implementation the RCT has been
expected to contain the OPC of the End Node that the TFC contained as a
DPC. One very valid reason is that routing already exists across the
entire network for the RCT to traverse back to where it needs to go to
obtain the congestion status, and once there the node receiving it
already has routing to reply as necessary back to the OPC of the RCT.
ANy intermediate node also have the routing. This routing is put in
place when the routing for the trunks or SCCP are ordered.
The SS7 translations people in the present SS7 network know this and
usually allow the RCT, which is Network Management , through the Gateway
Screening. Same for the TFC. 

Now when the SG ( ITP or whatever) sends a RCT back to the originator of
a TFC and the OPC of that RCT is the point code of the SG , few or no
one in the middle or far end is even aware that the SG exists. This
causes the RCT to be not allowed at Gateway Screening or if it makes it
through screening then the STP receiving the RCT does not have a route
back to the SG because no one knows it exists. Hence the SG does not
receive another TFC to update the congestion status, it stops SCON to
the endpoint and trys ISUP again. This is possibly a false relief of
congestion. True the SG point code information could be shared but why
re-invent the SS7 process when the SG could be designed to send the OPC
of the IP endpoint.
I understand that part of the reasonong for sending the ITP/SG point
code was to help prevent the two ITP's from becoming out of sync in
keeping congestion status but lets consider specifics. 

*	If the TFC/RCT exchange is being conducted between only one of
the ITP's then one ITP is already out of sync. 
*	If the RCT can't be responded to at all because there is no
routing back to it in all the the STP hops then Both ITP's are out of
sync because neither really knows the true congestion status. 
*	Do both ITP's "Really" handle traffic in a load shared
situation? If not sync is irrelevant. 
*	Is traffic load shared to the ITP/SG or is it costed? If it is
costed on the SS7 side then sync is irrelevant as all SS7 traffic will
point to one ITP/SG thus forcing all TFC's to the same ITP. 
*	Is traffic load shared on the IP side? or Does it switch
ITP/SG's as network management directs? 
*	When one ITP/SG sends SCON does the IP endpoint send DAUD to
both ITP/SG's or only to one?


There are more questions that impact how this operates. But having
definition to these would help.

Thanks for your input.

Kevin P. Spence
Verizon Communications
Network Specialist 
TSS ENET Essential Network Elements Team
972-615-8199 ext. 4907
 "Tuel, Josh" <[email protected]>



"Tuel, Josh" <[email protected]> 

09/19/2007 10:48 PM

 

To

 
<[email protected]>



cc


Kevin P. Spence/EMPL/VA/Verizon@VZNotes



Subject


RE: [Sigtran] FW: RFC 4666 M3UA

 






The placing of the ITP point code in the OPC of an RCT is the vendor's
implementation. It is not defined in the RFC how this should work. It
was done this way to make M3UA and SUA work the same in this case (SUA
would have to have the RCT OPC=ITP since the AS does not have MTP3
equivalent). 

For M3UA the ITP's job is to front end these management messages and
translate them to the appropriate ASP/AS management message. So when the
240-0-0 is congested, for example, the ITP will terminate the TFC and
send a SCON to 1-1-1. One can argue we should place 1-1-1 in the OPC of
the RCT (since we know the DPC of the TFC) and one can argue it should
be the ITP OPC (since the ITP is supposed to front end SSNM for SS7 for
the ASP). 

Josh 

________________________________

From: Ong, Lyndon [mailto:[email protected]] 
Sent: Wednesday, September 12, 2007 2:15 PM
To: [email protected]
Cc: [email protected]
Subject: [Sigtran] FW: RFC 4666 M3UA

Forwarding question to the main list for comments.

________________________________

From: [email protected] [mailto:[email protected]] 
Sent: Monday, September 10, 2007 1:50 PM
To: [email protected]; [email protected]; Ong, Lyndon
Subject: RFC 4666 M3UA

Ken,Javier,Lyndon,

I got your names from an inquiry to the IETF about the RFC 4666.
Recently I have been involved in some testing of SS7 congestion and it's
reaction from and IP network using M3UA. The SS7 physical connection
utilized two ITP's with BLinks to the SS7 network. It appears the ITP's
tested were not capable of transmitting the RCT ( Route Congestion Test)
message in response to the TFC ( Transfer Congestion) they received with
a proper Originating Point Code. The ITP responded to the TFC with a RCT
that contained it's own originating point code. The RCT should contain
the OPC of the node at the end of the trunks. This would be the IP
endpoint not the ITP. Further it appears there is no provision within
M3UA to facilitate IP endpoints to send a message to the ITP that would
generate a proper RCT.

If possible could you respond to my concerns. 

1. Do I understand the M3UA protocol in the belief there is no workable
RCT provision, or is there a provision that would enable the ITP to
reply to a received TFC with a RCT that has the originating point code
of the IP endpoint? 
2. I notice the DAUD message contains an Information Parameter. Is there
an intent or possibility the DAUD message could trigger a RCT on the SS7
side of the ITP with the correct OPC of the IP endpoint?


Kevin P. Spence
Verizon Communications
Network Specialist 
TSS ENET Essential Network Elements Team
972-615-8199 ext. 4907

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