Subject: [Sigtran] M3UA: Synchronizing DPC availability state between ASPs in the same AS

From: Dan Gora <[email-masked]>
Date: Sat, 8 Apr 2017 01:47:46 -0300

Hi All,

We have a distributed M3UA implementation with two ASPs on different
physical hosts servicing a single AS talking to a single SGP in a
single SG:

SG1       AS1
---      -----
SGP1 --- ASP 1
     +-- ASP 2

It's unknown who the SGP/SG vendor is, but our customer is claiming
that when we start ASP 1 and ASP 2 that both will enter the ASP-Active
state with SGP1, then both ASP 1 and ASP 2 will each send a DAUD
message to SGP1.  However the problem is that the SGP will only reply
with a DAVA/DUNA to ASP 1.  Subsequent DAUD messages from ASP2 to
SGP1 are "replied to" by the SGP1 by sending the DAVA/DUNA to ASP
1, not ASP 2.  They also claim that this "should be sufficient".
They also claim that we should not need to send DAUD from ASP 2 at
all, that we should "coordinate" the DAUD sending so that only one
ASP sends a DAUD message.

Now this feels wrong to me.  There is nothing in the spec which
specifically states that the ASPs have to synchronize the destination
states between themselves just because they belong to the same AS.

There is also numerous places (RFC 4666: 3.4.1 (DUNA) and 3.4.2)
where it says that the DUNA/DAVA message is sent to "all concerned
ASPs" and in 4.5.1 where it says:

   The SGP M3UA layer determines the set of concerned ASPs to be
   informed based on the specific SS7 network for which the primitive
   indication is relevant.  In this way, all ASPs configured to
   send/receive traffic within a particular Network Appearance
   are informed.  If the SGP operates within a single SS7 Network
   Appearance, then all ASPs are informed.

Also it seems pretty clear from the specification that an ASP can
send a DAUD pretty much any time it wants and I've never seen anything
where a message can be "responded to" via a different association (ie
a different ASP).  There is certainly no description of any mechanism
by which sending DAUD has to be coordinated among the ASPs in an AS.

On the other hand...

I cannot find anything definitive about this.

Reading through the mailing list archives
there are notions where "SSNM messages are "per-AS""
(https://www.ietf.org/mail-archive/web/sigtran/current/msg00725.html)
and there is also the "philosophical" notion that an AS is the SAP
though which an MTP3 User accesses the MTP3 network and in this case
the AS is serviced via two (distributed) ASPs, which seems to imply
that the ASPs should have a synchronized view of the DPC status.

So, what should I think about this?  Are we required to synchronize
the destination state for an AS across all the ASPs automatically
(ie by sending a DAUD or receiving a DAVA/DUNA on only one ASP in
the group of ASPs serving this AS)?  If so, where does this appear
(or is even implied) in the spec?

Can I definitely tell the customer that either the SG is totally
broken or else something is misconfigured?

What might possibly be misconfigured to cause the SG to behave this
way? (I realize that this is totally a shot in the dark, we are
supposedly getting more information from the customer...)

Any tips would be most welcome.

thanks,
dan

---

From: David Laight <[email-masked]>
Date: Mon, 10 Apr 2017 08:38:36 +0000

From: Dan Gora
> Sent: 08 April 2017 05:48
 
> ASPs" and in 4.5.1 where it says:
...

This is a difference between rfc 4666 and the older 3332.

AFAICT one major network equipment manufacturer has not updated their
protocol stack to conform to rfc4666.

We've a horrid bodge that detects the missing indications.

	David

---

From: Dan Gora <[email-masked]>
Date: Mon, 10 Apr 2017 15:55:55 -0300

Hi David,

Thanks for your response...

> This is a difference between rfc 4666 and the older 3332.

Is it?  The only difference I can see in rfc 4666 in section 4.5.1 is
the addition of this paragraph:

   For the particular case that an ASP becomes active for an AS and
   destinations normally accessible to the AS are inaccessible,
   restricted, or congested, the SG MAY send DUNA, DRST, or SCON
   messages for the inaccessible, restricted, or congested destinations
   to the ASP newly active for the AS to prevent the ASP from sending
   traffic for destinations that it might not otherwise know that are
   inaccessible, restricted, or congested.  For the newly activating ASP
   from which the SGP has received an ASP Active message, these DUNA,
   DRST, and SCON messages MAY be sent before sending the ASP Active Ack
   that completes the activation procedure.

But RFC 3332 still doesn't really clearly state that the ASPs have to
synchronize their destination state within an AS.  On the contrary,
from 4.5.1 it still seems to imply that the SGP has to send DAVA/DUNA,
etc to _all_ "concerned" ASPs, not just one in an AS.

> We've a horrid bodge that detects the missing indications.

What missing indications are you referring to?  The missing NTFY
messages for the AS (section 5.1.1.1, etc..)?

thanks,
dan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Apr 2017 13:41:19 -0600

Dan,

When an SG sends DUNA, DAVA, DRST, SCON for an AS, we had
long discussions and agreed that it was sufficient that the
SG sends the indication to at least one ASP active for the
AS with the SG.  Even so, many SG vendors send the indication
to _every_ ASP active for the AS.  Multiple M3UA associations
between SG and AS can be viewed as links in a linkset, and,
following the analogy, an STP will only send TFP, TFA, etc.
on one link in the linkset.

However, this was never really the case for DAUD.  DAUD is
sent from ASP to SGP not from AS to SG.  For periodic DAUD,
the recommendation is that the DAUD be sent from an ASP to
the SGP that send the corresponding DUNA, DAVA, DRST, SCON.

For MTP Restart procedure, the recommendation was that the
SGP send DUNA, DAVA, DRST, SCON after receiving the ASP
Active and before sending the ASP Active Ack, so that the
ASP will not send traffic to unavailable destinations when
it becomes active.

So, yes and no, you may have to correlate the receipt of
DUNA, DAVA, DRST, SCON at any ASP across all ASPs active
for the AS (if the SG does not broadcast); however, you
should never have to do so in response to DAUD.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Apr 2017 13:51:04 -0600

Dan,

Brian F. G. Bidulock wrote:       (Mon, 10 Apr 2017 13:41:19)
> should never have to do so in response to DAUD.

See, for example, RFC 4666/5.4 Auditing Examples.  You
will see that all transactions are between ASP and SGP,
not between AS and SG.

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

---

From: Dan Gora <[email-masked]>
Date: Mon, 10 Apr 2017 17:00:12 -0300

> will see that all transactions are between ASP and SGP,

Right... This is what led me to believe that we didn't have to
synchronize the DPC states (and various conversions on the mailing
list), but then again your description of considering ASPs in the same
AS connected to the same SG as links in a linkset is what made be
think that yes, we do need to synchronize the DPC states.

However, this customer's SG seems to be even worse in that it's
replying to a DAUD from ASP2 with a DAVA/DUNA to ASP1, _not_ ASP2 (or
so they say, we still haven't been provided with traces or debug logs
yet..).  That just seems broken to me..

If we have to "fix" this, it seems like it should be safe to
synchronize the states across all the active ASPs.  I cannot think of
a scenario where a DPC would be available in ASP 1 via SG1, but not
via ASP2 as long as both are connected and ASP-Active with the SG1
since the SG1 has to synchronize it's state among all the SGPs in the
SG.  Right?

thanks
dan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Apr 2017 14:09:32 -0600

Dan,

Please see comments below...

Dan Gora wrote:                    (Mon, 10 Apr 2017 17:00:12)
> since the SG1 has to synchronize it's state among all the SGPs in the

Well, no.  We considered that an SG with multiple SGP might get
one or more SGPs partitioned from the others, and potentially
isolated from the network.  Although they are isolated, their
M3UA connections to the ASPs in the AS are still viable and
the unsolicited ASP Inactive Ack procedure might not be
necessary.  In that case, some SGP might send DUNA(*) while the
others still have available routes.  This was a major reason
for sending periodic DAUD to the SGP that sent the corresponding
DUNA, DRST, SCON.

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