Subject: [Sigtran] Status if M3UA after DUNA from SG

From: "Ambika Tripathy" <[email-masked]>
Date: Fri, 6 Apr 2007 10:06:37 +0530

Hi Folks,

     I have one doubt regarding the DUNA message communication in M3UA.

My Question is if we received DUNA message from the peer SGP, should we
indicate the ULP at ASP to stop traffic, if any alternative SG not
available.

If this is the case then, is there any primitive to do so??

-- 
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "ZHOU Minggang" <[email-masked]>
Date: Fri, 6 Apr 2007 13:26:39 +0800

Hi Ambika, 
RFC 4666 said:
    If there is no alternate route via another SG, the MTP3-User
   at the ASP is expected to stop traffic to the affected destination
   via the SG as per the defined MTP3-User procedures.

So we should indicate the ULP at ASP to stop traffic if any alternative
SG not available.
 
In this case, primitive "MTP-PAUSE" will be used to indicate "Users".
 
Best regards,
Zhou Minggang

  _____  

From: Ambika Tripathy [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 12:37 PM
To: sigtran; bidulock
Subject: [Sigtran] Status if M3UA after DUNA from SG

Hi Folks,

---

From: "Ambika Tripathy" <[email-masked]>
Date: Fri, 6 Apr 2007 11:13:44 +0530

Thanks Zhou,

One more question.

If at the case ASP sends data to SG, then what should the SG will do?
                       ------- Discard the data and generate Error?

On 4/6/07, ZHOU Minggang <[email-masked]> wrote:
> So we should indicate the ULP at ASP to stop traffic if any alternative SG
> not available.
>
>  ------------------------------
> *From:* Ambika Tripathy [mailto:[email-masked]]
> *Sent:* Friday, April 06, 2007 12:37 PM
> *To:* sigtran; bidulock
> *Subject:* [Sigtran] Status if M3UA after DUNA from SG
>
>
>  Hi Folks,
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Apr 2007 00:18:11 -0600

Ambika,

The SG should send DUNA (but not for every data message received from the ASP:
if the SG is in the multiple SG as STP configuration, DUNA should be sent with
the same rules as sending TFP (only one sent to a given PC within a time
interval); if the SG is acting as the SEP, DUNA should be sent with the same
rules as sending MTP-PAUSE (e.g. one every 8 or 10 messages).)

--brian

Ambika Tripathy wrote:                        (Fri, 06 Apr 2007 11:13:44)

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

---

From: "Ambika Tripathy" <[email-masked]>
Date: Fri, 6 Apr 2007 11:48:51 +0530

Hi,

+------+      +-----------+
| STP1 |---X--|   SG1     |
+------+      |           |
 OPC = 1.1.1  |           |
              | +--------+|    +----------+
+------+      | |  SGP 1 ||----|  ASP 1   |
| STP2 |---X--| +--------+|    +----------+
+------+      |           |
OPC = 1.1.2   |OPC = 2.2.2|
              |           |
+------+      |           |
| STP3 |------|           |
+------+      +-----------+
OPC = 1.1.3

In the above diagram, SG1 determines STP1 ans STP2 are not available.

If SG generastes a DUNA message for the above diagram,
which are the APC values in the messages?

-- 
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730

On 4/6/07, Ambika Tripathy <[email-masked]> wrote:
> > *Sent: *Friday, April 06, 2007 12:37 PM
> > *To:* sigtran; bidulock

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Apr 2007 02:03:19 -0600

Ambika,

This is handled by the SS7 specifications.  cf. Q.704.  In this
case, the SG generates a DUNA message for each MTP-PAUSE message
that the MTP at OPC 2.2.2 sends to all local users (i.e. those
for remote signalling points (routesets) inaccessible due to the
network failures indicated, but, of course, not for those that
remain accessible).

It is likely in this case (because of C-links) that no destinations
become inaccessble to 2.2.2 and no DUNA messages are required.

--brian

Ambika Tripathy wrote:                        (Fri, 06 Apr 2007 11:48:51)

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