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

Dan Gora <dan.gora@gmail.com> Sat, 08 April 2017 04:48 UTC

Return-Path: <dan.gora@gmail.com>
X-Original-To: sigtran@ietfa.amsl.com
Delivered-To: sigtran@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3DF1270A3 for <sigtran@ietfa.amsl.com>; Fri, 7 Apr 2017 21:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3J9obpokZk4 for <sigtran@ietfa.amsl.com>; Fri, 7 Apr 2017 21:48:29 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BD81293EC for <sigtran@ietf.org>; Fri, 7 Apr 2017 21:48:29 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id u2so4657587wmu.0 for <sigtran@ietf.org>; Fri, 07 Apr 2017 21:48:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Qv7Q2Z020Q65Hxv58QLugTGEuHmOrgGXTI5dHG1pz7s=; b=LmtQMVOvXC8e5zoUeciM2jSrcZTsiDFG8vcApHEt99tPx99YpZN9cJiB8Zpr25Syfx 1D9sjhggRpkRscPPCdO3aUo5NJq5UbboIYyeGJhhdMZ14QGjFSX8Z+7jh8eHfdAdnZQv y+A6lV3SzxquftNpXdXf1qrQ3k6qD57g6+SnwfkQ7DI1ksrX7U+DAte7OAjHw19K8ygJ zQfO99SrYgNq+/4JyPPGwok/oKuPxCUw71I2LdhfoPUB5b/B5FalB0rrcU4KM1axvlTS 7ATLdiedLZGi0yL73Lgnxa1/aypWklJLjUTJhzDMtYtmETgLtXWBp5jHLoYytaJmXe60 bkYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Qv7Q2Z020Q65Hxv58QLugTGEuHmOrgGXTI5dHG1pz7s=; b=EPqqZkVZk+UcfgMpk7SW/+O/3TQtVUBofWFuMN03yKYsjKhgBiMfftedz1OM2YSO/P 2BepS17ehTDzBGXj3axVr+VT47irLtu8GzlK9Na6Ite5uEazWSbyM+e3N77qzMFycjLq UXder0xXliIx6S7s4GMqFeAjN0NsxAi10Ax7HHLC7zphzPC3o3gYhAxk4fHeAHa8H4Fu Ib4ltIBrjuXtyz0OwiiYHNOmN4v7EoEYnZnrQn2jp3evCV4Kft57MhE3eBF7N40n4tj8 /EFI6W7RFyTLOKVurtiotogAI9xtGtdHv3+iqdVtCHhXbvvHXh6q/5FSpMkvoEdTmvw4 bbmQ==
X-Gm-Message-State: AN3rC/6bLt/KUOVl5qDiUeH+lPqwz/BRwIXh5Y6wuWRcukiegWP/izq4 ALkyzj59oLq9jcx858WCYO32wCjHJkQJ
X-Received: by 10.28.66.207 with SMTP id k76mr1953991wmi.121.1491626907328; Fri, 07 Apr 2017 21:48:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.175.212 with HTTP; Fri, 7 Apr 2017 21:47:46 -0700 (PDT)
From: Dan Gora <dan.gora@gmail.com>
Date: Sat, 08 Apr 2017 01:47:46 -0300
Message-ID: <CAGyogRamDgU7fhwfS1rgQC19-vrxsjc-uZvQGwx0wpKB846zKA@mail.gmail.com>
To: sigtran@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sigtran/d46a7P58bvccv0H3XqtSqfXAEGY>
Subject: [Sigtran] M3UA: Synchronizing DPC availability state between ASPs in the same AS
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sigtran/>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Apr 2017 04:48:32 -0000

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