Subject: M3UA questions

From: "Bouckaert, Philippe" <[email-masked]>
Date: Thu, 11 Oct 2001 10:58:57 +0200

I have some questions/comments on M3UA. The draft I'm looking is the 9:
Sorry 

1.4.4.2. Signaling Gateway Redundancy: 
Why the SGP MUST terminate the SCTP associations when losing all or partial
SS7 connectivity?

4.3.2 AS States
*	Why the AS state is maintained in the SGP? I think it should be
global to the SG. When a SCTP association fails, this ASP (or the AS is
there was the only ASP active)  may be reached by another SGP. This SGP must
be used instead of queuing the messages.
*	Instead of discarding the queued messages, after Tr expiration, why
not specify the default treatment taken for incoming messages without
routing key match, as specified in 4.1.1.  

4.6 MTP3 Restart
It is indicated "When the SG discovers SS7 network isolation, the SGPs
send..". In fact, that should be a SGP instead of SGPs, as DUNA messages
concerns the SG and not the SGP. 

Best regards,
Philippe

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 11 Oct 2001 09:01:50 -0500

Hi,

Please see comments below.

  Tolga

> -----Original Message-----
> From: Bouckaert, Philippe [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 4:59 AM
> To: sigtran
> Subject: M3UA questions
> 
> 
[TOLGA] This depends, what ones interpretation of SGPs id. If you assume
that they form a single MTP3 entity, then when one SGP has lost all or
partial SS7 connectivity, then this would be applicable also to other SGPs
of this SG. In such a case, I would expect the SG to send ASPIA-ACK or
terminating the association, although the first one seems more preferrable.
With draft9, it is stated quite clearly that SGPs should form a single
entity in SS7 and M3UA domain. But if one still wants to think SGPs as
separete MTP3 entities (which is according to me not the correct way) and
only if one of them looses connectivity, then one should take some special
action. Again here, there are two ways to follow, you have internal message
forwarding capability among your SGPs or not. If you have, then it seems
nothing is necessary, because even SS7 connectivity of SGP1 is lost, it will
forward messages it is receiving from ASP to SGP2. But if you don't have
this capability, then you should have a mechanism, which won't let think ASP
that SG is no more handling traffic for that AS (ASP would think like this,
if you send ASPIA-ACK) but also which prevents ASP sending traffic to the
SGP which has lost SS7 connectivity (SGP1 in our example). So, the only way
is to terminate the association.
But as I said, if one thinks SGPs forming a single entity both in M3UA and
SS7 domain, ASPIA-ACK looks elegant and there is no need to terminate the
association.
> be used instead of queuing the messages.
[TOLGA] Probably what meant is , that SGPs keep AS states and share them
among themselves.
> routing key match, as specified in 4.1.1.  
[TOLGA] I think default treatment can have two approaches, whether
discarding the messages or sending them to a predefined ASP. If it is
discarding the messages, that's also done after Tr expiry. In the other
case, if ASP99 is the handling default traffic, then I can configure it also
as standby of an AS, so after timer expiry again all of the traffic is sent
to ASP99. 
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: "Bouckaert, Philippe" <[email-masked]>
Date: Thu, 11 Oct 2001 16:53:05 +0200

Tolga, 

Thans for your comments. 
See my comments below,
Best regards,
Philippe

 -----Original Message-----
From: 	Asveren, Tolga [mailto:[email-masked]] 
Sent:	Thursday, October 11, 2001 4:02 PM
To:	sigtran
Subject:	RE: M3UA questions

Hi,

  Tolga

[TOLGA] This depends, what ones interpretation of SGPs id. If you assume
that they form a single MTP3 entity, then when one SGP has lost all or
partial SS7 connectivity, then this would be applicable also to other SGPs
of this SG. In such a case, I would expect the SG to send ASPIA-ACK or
terminating the association, although the first one seems more preferrable.
With draft9, it is stated quite clearly that SGPs should form a single
entity in SS7 and M3UA domain. But if one still wants to think SGPs as
separete MTP3 entities (which is according to me not the correct way) and
only if one of them looses connectivity, then one should take some special
action. Again here, there are two ways to follow, you have internal message
forwarding capability among your SGPs or not. If you have, then it seems
nothing is necessary, because even SS7 connectivity of SGP1 is lost, it will
forward messages it is receiving from ASP to SGP2. But if you don't have
this capability, then you should have a mechanism, which won't let think ASP
that SG is no more handling traffic for that AS (ASP would think like this,
if you send ASPIA-ACK) but also which prevents ASP sending traffic to the
SGP which has lost SS7 connectivity (SGP1 in our example). So, the only way
is to terminate the association.
But as I said, if one thinks SGPs forming a single entity both in M3UA and
SS7 domain, ASPIA-ACK looks elegant and there is no need to terminate the
association.
[philippe]
I agree that SGPs must form a single MTP3 entity. It seems to me also very
clear in the draft 9. 
Concerning the communications between SGPs, I think it is mandatory.
Imagine 2 linksets, each with 2 links, and each SGP has connected with a
link of each linkset. You lost link 1 on SGP1. You have then 2 solutions:
1. either you let the SCTP connection in live. Then, the SGP1 will have to
forward messages coming from ASP and destined for link 1(failed) to SGP2. to
the link of the same linset as link 1.
2. either you close the connection, and then you will have to forward ss7
messages coming from link 2 /SGP1 to SGP2

In fact, to send ASPIA-ACK is only feasible if you lose all ss7
connectivity. 

[TOLGA] Probably what meant is , that SGPs keep AS states and share them
among themselves.
	[Philippe]
Yes, I think the SGPs must share the AS states. The queuing should be
started when the state AS-PENDING occurs for all SGPs. 

> [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Cheu, Janey M, NNAD" <[email-masked]>
Date: Tue, 16 Oct 2001 14:05:50 -0400

> ----------
> From: 	Bouckaert, Philippe[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	October 11, 2001 10:53 AM
> To: 	sigtran
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 03:15:39 -0500

Philippe,

Please see comments below...

Bouckaert, Philippe wrote:                     (Thu, 11 Oct 2001 16:53:05)
> I agree that SGPs must form a single MTP3 entity. It seems to me also very

Good.  To some it is not so clear.

> Concerning the communications between SGPs, I think it is mandatory.

In broadcast modes, inter-SGP communication is not necessary.

> link of each linkset.
> You lost link 1 on SGP1. You have then 2 solutions:

This was discussed in great detail in the thread from last July:
"M3UAv7: SG redundancy".

> In fact, to send ASPIA-ACK is only feasible if you lose all ss7

Quite the opposite.  the ASPIA Ack procedure is intended to handle
partial failures.  The text you cite should be updated to include
mention of the ASPIA Ack procedure for partial failures.  The procedure
can be applied to a single RC of multiple RCs and permits an SGP
to continue to process traffic for RCs for which it is still able to
while pushing the ASP to the inactive state for RCs which is is no
longer able to handle.  This is a partial failure situation.

In a complete failure situation, ASPIA Ack can be performed for all RCs
without dropping the SCTP association.

The "MUST" of 1.4.4.2 has to go.  There is no reason to drop an
SCTP association with the addition of the ASPIA Ack procedure.
This is an oversight at this sentence was discussed in great
detail and it was agreed that the SCTP assocation need not be
dropped if per-SGP SNMM or SGP mamagement were to be added.

Now it has: the ASPIA Ack procedure allows one to not drop the
association.

Greg?  Javier?

> started when the state AS-PENDING occurs for all SGPs. 

SGPs do not have to share AS state as AS state is defined in the
draft.  If you mean that the SGP might need to know what another
SGP's view of the AS state is, then it is pretty much up to your
implementation whether to do that or not.  AS-PENDING is only
applicable on a per-SGP basis when one SGP is isolated from all
ASPs serving the AS.  Even if you have internal communication between
SGP, the one SGP must withhold traffic for an interval before
handing it off to another SGP to avoid mis-sequencing at the ASP.

> as standby of an AS, so after timer expiry again all of the traffic is sent

There is no requirement to discard.  The text is descriptive and has no
requirement to discard.

> > concerns the SG and not the SGP. 

Any number of SGPs are permitted to send the message.
SGPs (i.e. one or more) is ok.

> You are currently subscribed to sigtran as: [email-masked]

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

---