Subject: RE: [Sigtran] M3UA - AUTHORS-FINAL-ASP database equalization

From: "Richard Adams" <[email-masked]>
Date: Mon, 10 Feb 2003 16:44:59 +0100

Ken,
Brian suggested a modification to his own text, and I agree with that : 
the second SHOULD should become a MAY.
So the proposed text reads:
"When an ASP becomes active for an AS and the SG is experiencing
SS7 network isolation or is performing the MTP Restart procedure
for the AS, the SG SHOULD send a DUNA(*) to the newly active ASP
to prevent the ASP from sending traffic.
 
When an ASP becomes active for an AS and destinations normally
acessible to the ASP are inaccessible, restricted or congested
for the AS, the SG MAY send DUNA, DRST or SCON AS for the
inacessible, restricted or congested destinations to the ASP
newly active for the AS to prevent the ASP from sending traffic
for destinations that it might otherwise not know are
inaccessible, restricted or congested."

What would concern me is that any other changes are starting to 
re-open AS/ASP management (and therefore any changes should
be consistent across M3UA, SUA, M2UA at least).
 Plugtests have shown the current procedures to work and
interwork between implementations. I fear we are opening 
a can of worms, which could ultimately lead to re-design to
build the ASP active/inactive procedures so that they integrated
into MTP restart. While this could be a laudable aim, I think
it might take a long time. MTP restart took ~5 to 7 years before
it was tightly-enough specified (and would work for a network
where a number of signalling points were re-starting at the same time).

Samuel's text did not appear to me to differentiate sufficiently
between actions when the SG allowed dynamic registration, and those when
it
didn't. And I would want to see the consequences, preferably
shown in a state transition diagram for the interaction between 
the SG and several ASPs. This would need to cover the sub-state changes
between INACTIVE_but_ready_to_become_active, INACTIVE_and_remaining_so,
and how the SG differentiated. And why would this be different
for static configurations? And in the transition from INACTIVE
to ACTIVE, does an ASP need to pass through the _ready_to_become_active
substate. Is it this transition that causes the SG to send out
SSNMs? If so, how does it know without signalling between the ASP and
SG ?  Or is this information pre-configured ?

Kind regards,
Dick Adams,
[email-masked]

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 10 Feb 2003 11:18:27 -0800 (PST)

I also think the proposed text might be usefull in IG
and I have some commnets/questions below.

  Tolga
> inaccessible, restricted or congested."
[TOLGA]Because Q.704 does not specify actions when a
local user part becomes available, I think there is no
danger of divergence from Q.704. But how can ASP know,
when the last DUNA, DRST, SCON is received before
starting to send traffic? I would think, there is no
need that it waits for a specific message, i.e. it can
send DATA to any destination as soon as it becomes
ACTIVE and SSNM from SG is used just as additional
information. So, I would think, if an ASP really wants
to play safe, it should send DAUDs to SG for the
destinations it is interested in and wait replies from
them before sending DATA (or better synchronizes
destination table with its peer ASP)
And regarding sending SSNM while ASP inactive I  still
have the same idea, my personal opinion is to keep RFC
as it is. 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Feb 2003 14:25:42 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 10 Feb 2003 11:18:27)
> have the same idea, my personal opinion is to keep RFC

It could be possible for the SG to send the SSNM after
receiving ASPAC, but before sending ASPAC Ack.  That way
the ASPAC Ack acts like a TRA.

For example, an ASP inactive for the AS sends ASPAC Ack
and the SG has the ASP marked inactive at the SG for the
AS.  The SG sends DAVA(*) followed by any necessary
DUNA, SCON and DRST (which should be a short list), or,
if the SG is in MTP Restart, it sends DUNA(*).  The SG
could send these SSNM ordered in the AS stream.  Then
it could follow with the ASPAC Ack ordered in the same
stream.  The ASP should not start traffic until it
receives the ASPAC Ack, anyway.  Note that this would
only need to be performed for the first SGP that the ASP
becomes active for.  So it would look something like this:

   SGP                                 ASP
    |                                   |
    |                              /----|<-- (start)
    |                             /     |
    |      /-------ASPAC---------/      | MTP-User assumes
    |     /                             | all destinations
    |<---/                              | available but
    |----\                              | suppresses traffic.
    |----\\                             |
    |----\\\-------DAVA(*)-------\      |
    |     \\-------DUNA(1)-------\\     |
    |----\ \-------SCON(2)-------\\\--->| (reasserts above)
    |     \                       \\--->|--> MTP-PAUSE
    |      \------ASPAC Ack------\ \--->|--> MTP-STATUS
    |----\                        \     |
    |----\\                        \--->|--> MTP-RESTART-ENDS
    |     \\--------DATA---------\ /----|<-- MTP-TRANSFER
    |      \--------DATA---------\X/----|<-- MTP-TRANSFER
    |      /--------DATA---------/X\--->|--> MTP-TRANSFER
    |     //--------DATA---------/ \--->|--> MTP-TRANSFER
    |<---//                             |
    |<---/                              |
    |                                   |
    |                                   |

Now, that could be quite useful where the ASP Point Code
is different from the SG Point Code and the ASP Point Code
has routes to the entire SS7 network.  It also mimics the
SS7 MTP Restart procedure for this "detached" point code.

For the SG MTP Restart case, the SHOULD was intended for
something like this for the case where the ASP Point Code
is different from the SG point code:

   SGP                                 ASP
    |                                   |
    |                              /----|<-- (start)
    |                             /     |
    |      /-------ASPAC---------/      | MTP-User assumes
    |     /                             | all destinations
    |<---/                              | available but
    |----\                              | suppresses traffic.
    |----\\                             |
    |----\\\-------DUNA(*)-------\      |
    |     \\------DAVA(SG)-------\\     |
    |      \------ASPAC Ack------\\\--->|  (isolation)
    |                             \\--->|--> MTP-RESUME
    |----\                         \--->|--> MTP-RESTART-ENDS
    |----\\                             |
    |     \\--------DATA---------\ /----|<-- MTP-TRANSFER
    |      \--------DATA---------\X/----|<-- MTP-TRANSFER
    |      /--------DATA---------/X\--->|--> MTP-TRANSFER
    |     //--------DATA---------/ \--->|--> MTP-TRANSFER
    |<---//    (to and from SG only)    |
    |<---/                              |
    |                                   |
    |                                   |

If the ASP sends DAUD just before ASPAC, a similar scenario
can be acheived:

   SGP                                 ASP
    |                                   |
    |                              /----|<-- (start)
    |                             //----|
    |      /-------DAUD(*)-------//     |
    |     //-------ASPAC---------/      | MTP-User assumes
    |<---//                             | all destinations
    |<---/                              | available but
    |----\                              | suppresses traffic.
    |----\\                             |
    |----\\\-------DAVA(*)-------\      |
    |     \\-------DUNA(1)-------\\     |
    |----\ \-------SCON(2)-------\\\--->| (reasserts above)
    |     \                       \\--->|--> MTP-PAUSE
    |      \------ASPAC Ack------\ \--->|--> MTP-STATUS
    |----\                        \     |
    |----\\                        \--->|--> MTP-RESTART-ENDS
    |     \\--------DATA---------\ /----|<-- MTP-TRANSFER
    |      \--------DATA---------\X/----|<-- MTP-TRANSFER
    |      /--------DATA---------/X\--->|--> MTP-TRANSFER
    |     //--------DATA---------/ \--->|--> MTP-TRANSFER
    |<---//                             |
    |<---/                              |
    |                                   |
    |                                   |

And as long as the SG completes responding to the DAUD(*)
before responding to the ASPAC with ASPAC Ack, the same
scenario results.

I don't see a problem with sending the DAUD(*) before the
ASPAC.  DAUD is permitted to be sent unordered (and on
stream 0) and could be expedited ahead of the ASPAC
(which is sent ordered and normally on the same stream
as the AS DATA) by SCTP anyway.

I think that by saying that the inactive ASP MAY audit, and
the SG MAY respond to audits from inactive ASPs, this type
of smooth restart can be acheived.

Note that this would work equally well for the first active
ASP as it would for the subsequent active or overriding ASP.

So I think the following would suffice:

  If an SG is in MTP restart, the first SGP SHOULD send
  DUNA(*) before ASPAC Ack to the ASP newly activating for
  the AS.

  An SGP MAY send DAVA(*) followed by DUNA, DRST and SCON
  for affected destinations before sending ASPAC Ack to a
  newly activating AS.

  An SGP MAY respond to DAUD from an inactive ASP.

  An SGP SHOULD complete responding to a previous DAUD
  before responding to ASPAC with ASPAC Ack for an ASP newly
  activating for an AS.

  If an ASP wishes to update destination status when going
  active, it SHOULD send DAUD before sending ASPAC.

It would be nice to say somehow that in these scenarios the
SG can perform "abbreviations" such as above (DUNA(*) followed
by a couple of DAVAs, or DAVA(*) followed by a couple of
DUNAs).

Comments?

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 11 Feb 2003 01:53:59 -0800 (PST)

Brian,

Some more questions/comments.

  Tolga

[..snip...]

  If an SG is in MTP restart, the first SGP SHOULD
send
  DUNA(*) before ASPAC Ack to the ASP newly activating
for
  the AS.

  An SGP MAY send DAVA(*) followed by DUNA, DRST and
SCON
  for affected destinations before sending ASPAC Ack
to a
  newly activating AS.

  An SGP SHOULD complete responding to a previous DAUD
  before responding to ASPAC with ASPAC Ack for an ASP
newly
  activating for an AS.

  If an ASP wishes to update destination status when
going
  active, it SHOULD send DAUD before sending ASPAC.

[TOLGA] That SSNM and ASPAC/ASPAC-ACK should be sent
on the same stream is a key point in the proposed
procedure. So, I would think, this somehow should be
mentioned. 
In fact I would think, stream related issues deserve
to be explained in IG as a separate topic (like "AS
stream concept", synchronizing with HBEAT/HBEAT-ACK on
each stream to be used for the AS etc... IMO, still
some further discussions might be usefull about those
topics)

And I also would like to add -although not practically
important- even with the proposed procedures, I
wouldn't see ASPAC-ACK as corresponding to TRA but to
MTP-RestartEnd indication in case of MTP-Restart and
to the in Q.704 unspecified indication for other
cases(considering that this corresponds to becoming of
local user part available. In fact even when SG is in
MTP-Restart isn't ASPAC indicating that local user
part is available now?)

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Feb 2003 03:33:37 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 11 Feb 2003 01:53:59)
> MTP-Restart isn't ASPAC indicating that local user

Not when the ASP point code is separate from the SG
point code.  In that case, the ASP MTP is really restarting
and ASPAC is equivalent to TRA.  The ASP is not an MTP
user which has become available, but an entire point code
that has just appeared on the SS7 network.  But for the
pure backhaul cases, I agree, ASPAC corresponds to the
underspecified MTP-RESTART-ENDS (primitive?).

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 11 Feb 2003 05:22:19 -0800 (PST)

Brian,
> underspecified MTP-RESTART-ENDS (primitive?).
[TOLGA]Even for STP SG case, it is quite discussible,
where MTP3 of PC for AS sits , or how much of it sits
where(for single SG case, for multiple SG case)(but no
need to discuss further in this thread IMO)