Subject: [Sigtran] FW: RFC 4666 M3UA

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 12 Sep 2007 15:15:00 -0400

Forwarding question to the main list for comments.

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 1:50 PM
To: [email-masked]; [email-masked]; 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-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 12 Sep 2007 15:17:59 -0400

FYI, "ITP" referred to in the email is a type of SG.

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

Ken,Javier,Lyndon,

Kevin P. Spence
Verizon Communications
Network Specialist

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 12 Sep 2007 15:52:12 -0400

Even for the case, where SG has its own PC, it needs to execute MTP3
procedures for the PC of AS.  

In this example, generating proper RCT is responsibility of SG and it
needs to do this autonomously.

   Thanks,
   Tolga

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

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 1:50 PM
To: [email-masked]; [email-masked]; Ong, Lyndon
Subject: RFC 4666 M3UA
Ken,Javier,Lyndon,

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 12 Sep 2007 15:53:45 -0400

Kevin,

1. Regarding how the SGP should respond to the SS7 TFC msg - This question relates only to the behavior of the MTP3
layer within the SGP, and is thus beyond the scope of RFC4666.

2. Regarding the lack of a provision within M3UA to facilitate IP endpoints to send a message to the ITP that would
generate a proper RCT - I agree with you that this is missing from RFC4666. Is this a "must have" issue for you?

Barry Nagelberg

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, September 12, 2007 3:18 PM
To: Ong, Lyndon; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] FW: 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.

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?
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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Sep 2007 10:48:56 -0600

Kevin,

I believe that you are talking about the multiple SG as STP scenario.
For this scenario to work correctly, from the SS7 perspective, each STP
must view the ASP Point Code to be an alias point code that is local to
the STP in the same sense as an ANSI T1.111.4/2000 SCCP "Alias" point
code described in ANSI T1.111.4/2000 3.9 and 3.A.  That is, the remote
ASP is connecting via M3UA to a local MTP-SAP on the STP which is shared
between STP pairs in the ANSI T1.111.4 "Alias" sense.

When set up in this manner, each STP must respond to TFC in the
appropriate manner as dictated by, for example, ANSI T1.111.4 Section
13.7, and in your case:

 13.7.5 If T15 expires after the last updated of the congestion
 status of the signalilng route set towards destination X by a
 transfer-controlled message relating to the same destination, the
 signalling-route-set-congestion-rest procedure is invoked (see
 13.9).

and

 13.9 The signalling-route-set-congestion-test procedure is used at
 an originating signalling point to update the congestion status
 associated with a route set towards a certain destination.  The
 purpose is to test whether or not signalling messages destined
 towards that destination with a given message priority or higher
 may be sent.

 ...

Because the "Alias" point code is considered local to the STP, the STP
must respond in the same manner as a signalling end point under sections
13.7 and 13.9.

The DAUD procedure is not intended to trigger SS7 procedures at the SG,
but is intended as an optional procedure invoked by the ASP to permit
the ASP to syncrhonize its state with regard to availability and
congestion of remote signalling points to support restart.

The SCON is the equivalent of the MTP-STATUS.

So, sending RCT is the obligation of the STP which "owns" the ASP's
signalling point code in the SS7 sense.  Route set status changes
resulting from the procedure are indicated to the ASP using SCON.

Because your implementation appears to be sending RCT under the correct
circumstances, but is mere placing the wrong point code in the test
message, it is likely just a bug.

--brian

Lyndon Ong wrote:                                (Wed, 12 Sep 2007 15:15:00)
>    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.
>        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?
>        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?
> 

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

---

From: "Tuel, Josh" <[email-masked]>
Date: Wed, 19 Sep 2007 21:48:17 -0500

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-masked]] 
Sent: Wednesday, September 12, 2007 2:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Sigtran] FW: RFC 4666 M3UA

Ken,Javier,Lyndon,

Kevin P. Spence
Verizon Communications
Network Specialist

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2007 01:04:28 -0600

Josh,

The situation is no different for SUA.  Just how did you think that there was
a difference?  Under M3UA or SUA (or TUA for that matter), in the "multiple SG
as STP" configuration, where there are AS that can originate messages with the
point code for which a TFC arrives with that point code in the DPC, the SG
needs to perform the procedures of Q.704/13.6, Q.704/13.7 or Q.704/13.8 as
appropriate, which may include running timer T15 for the OPC/DPC (of the TFC)
and generating RCT messages to the OPC (of the TFC) as required as required.

But this is SS7 and outside the scope of the RFCs.

--brian

Tuel, Josh wrote:                               (Wed, 19 Sep 2007 21:48:17)
> 
>    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).
> 

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