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

From: [email-masked]
Date: Mon, 10 Feb 2003 08:55:24 -0500

Hello All,

>Any comment from authors?

I am not an author, but my thinking is that an SG SHOULD NOT send
unsolicited SSNMs to an INACTIVE ASP, and an SG MAY respond to an
audit issued by an INACTIVE ASP (i.e. send solicited SSNMs).

Regards,

Jeff

"Samuel Dur D. Jeyaseelan" <[email-masked]>@ietf.org on
02/10/2003 05:58:43 AM

Sent by:    [email-masked]

To:    Ken Morneault <[email-masked]>
cc:    denim john <[email-masked]>, [email-masked],
       [email-masked], [email-masked],
       [email-masked]
Subject:    Re: [Sigtran] M3UA - AUTHORS-FINAL-ASP database equalization

Any comment from authors?

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Sat, 8 Feb 2003, Samuel Dur D. Jeyaseelan wrote:

>
> Ken,
>
> Find the text changes below.
>
> ======================start===================
>
> 3.17 Disallowing SSNM messages in ASP-INACTIVE state
>
> 3.17.1 Description of the problem
>
>    SSNM messages are received and updated(destination node status) in
>    ASP-ACTIVE state but the backup ASP in inactive state is unaware
>    of SS7 node status changes. So when backup ASP becomes active, it
>    may not take over the traffic as soon as it becomes active.In
>    order to avoid this problem following additional changes are
>    proposed.
>
>        1.SGP can send SSNM messages to ASP-INACTIVE state.
>
>        2.ASP in inactive state can receive SSNM messages.
>
>      Implementing above two points will enhance the efficiency of ASP by
>      taking the traffic as soon as it becomes active.
>
>      Above two points are true only when dynamic registration is allowed
>      between ASP and SGP.
>
> 3.17.2 Text changes to the document
>
>    ---------
>    Old text: (Section 4.6)
>    ---------
>
>    When the SG discovers SS7 network isolation, the SGPs send an
>    indication to all concerned available ASPs (i.e., ASPs in the ASP-
>    ACTIVE state) using DUNA messages for the concerned destinations.
>
>    When the SG has completed the MTP Restart procedure, the M3UA layers
>    at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any
>    available/restricted SS7 destinations using the DAVA/DRST messages.
>    No message is necessary for those destinations still unavailable
>    after the restart procedure.
>
>    ---------
>    New text: (Section 4.6)
>    ---------
>
>    When the SG discovers SS7 network isolation, the SGPs send an
>    indication to all concerned available ASPs (i.e., ASPs in the ASP-
>    ACTIVE state or ASP-INACTIVE state) using DUNA messages for the
>    concerned destinations.
>
>    When the SG has completed the MTP Restart procedure, the M3UA layers
>    at the SGPs inform all concerned ASPs in the ASP-ACTIVE state or ASP-
>    INACTIVE state of any available/restricted SS7 destinations using the
>    DAVA/DRST messages.No message is necessary for those destinations
still
>    unavailable after the restart procedure.
>
>    ---------
>    Old text: (Section 4.5.3)
>    ---------
>
>       - Isolation. The ASP is newly ASP-ACTIVE or has been
>                    isolated from an SGP for an extended period.  The ASP
>                    MAY request the availability/congestion status of one
>                    or more SS7 destinations to which it expects to
>                    communicate.
>
>    ---------
>    New text: (Section 4.5.3)
>    ---------
>
>       - Isolation. The ASP has been isolated from an SGP for an extended
>                    period.  The ASP MAY request the
>                    availability/congestion status of one or more SS7
>                    destinations to which it expects to communicate.
>
> 3.17.3 Solution description
>
>    Wherever "concerned ASP" is referred in the specification, it does
>    mean that ASP in active state or ASP in inactive state.This is true
>    only when dynamic registration is allowed between ASP and SGP.
>
> =================END=========
>
> --Samuel
>
>
>
>   Alcatel USA, Inc.                  Internet: <userid>
@ssd.usa.alcatel.com
>   1000 Coit Road, Plano, Texas 75075
>   ******* The opinions expressed are not those of Alcatel USA, Inc.
*******
>
> On Fri, 7 Feb 2003, Ken Morneault wrote:
>
> >
> >
> > It would be useful if Samuel proposes text changes that could be
> > reviewed and, then, we could see if there was consensus for making
> > this change.
> >
> > Regards,
> >
> > Ken
> >
> > At 03:39 PM 2/7/2003 +0000, denim john wrote:
> >
> > >Brian,
> > >
> > >I would request any one of the authors to conclude this thread.
> > >samuel's idea seems to be good but this will result in changes of m3ua
and sua.
> > >
> > >Regards,
> > >Denim.
> > >
> > >An efficent ASP will take up the load as soon as it comes up.
> > >Inefficient ASP may send DAUD and will receive DRST(...),DUNA(...),
> > >SCON(...).  So from the point of ASP following are the unnecessary
> > >messages.
> > >.SENDING DAUD
> > >.RECEING DRST
> > >.RECEIVING DUNA
> > >.RECEIVING SCON
> > >
> > > From the point of SGP these are the unnecessay messages.
> > >.Receiving DAUD
> > >.SENDING DRST
> > >.SENDING DUNA
> > >.SENDING SCON.
> > >Thats what your argument leads.
> > >
> > >--Samuel
> > >
> > > Alcatel USA, Inc.                  Internet: <userid>
@ssd.usa.alcatel.com
> > > 1000 Coit Road, Plano, Texas 75075
> > > ******* The opinions expressed are not those of Alcatel USA, Inc.
*******
> > >
> > >On Thu, 6 Feb 2003, Brian F. G. Bidulock wrote:
> > >
> > >>Samuel,
> > >>
> > >>That is implementation dependent.  Sending SSNM to inactive ASPs
restricts
> > >>a dimension not restricted by the current and adequate procedure.
The
> > >>SG cannot be required to send SSNM to inactive ASPs.  The RFC should
not
> > >>place a restriction on the number of inactive ASPs, because we cannot
> > >>forsee all future dimensioning.  Procedures should scale as well as
possible.
> > >>The existing procedure scales.  Sending SSNM to inactive ASPs does
not.
> > >
> > >>--brian
> > >>
> > >>Samuel Dur D. Jeyaseelan wrote:
> > >(Thu, 06 Feb 2003 23:13:44)
> > >>> > Brian,
> > >>> > Yes , The RFC does not restrict the number of inactive ASPs.
> > >>> But network configuration will restrict.
> > >>> > --Samuel
> > >>> >   Alcatel USA, Inc.                  Internet: <userid>
@ssd.usa.alcatel.com
> > >>>   1000 Coit Road, Plano, Texas 75075
> > >>>   ******* The opinions expressed are not those of Alcatel USA, Inc.
*******
> > >>> > On Thu, 6 Feb 2003, Brian F. G. Bidulock wrote:
> > >>> > > Samuel,
> > >
> > >>> > > > The RFC does not restrict the number of inactive ASPs.
> > >>> > > > --brian
> > >>> > > > Samuel Dur D. Jeyaseelan wrote:
> > >(Thu, 06 Feb 2003 22:40:48)
> > >>> > > > > > Brian,
> > >>> > > > > > Ok, tell me, where you will configure 1 ASP ACT and
199,000 ASPs INACT?
> > >>> > > I want to know which network does this poor configuration.
> > >>> > > > > > --Samuel
> > >>> > > > > > > > >   Alcatel USA, Inc.                  Internet:
> > ><userid>@ssd.usa.alcatel.com
> > >>> > >   1000 Coit Road, Plano, Texas 75075
> > >>> > >   ******* The opinions expressed are not those of Alcatel USA,
Inc.
> > >*******
> > >>> > > > > > On Thu, 6 Feb 2003, Brian F. G. Bidulock wrote:
> > >>> > > > > > > Samuel,
> > >>> > > > > > > > The RFC does not restrict the number of inactive
ASPs.
> > >>> > > > > > > > --brian
> > >>> > > > > > > > Samuel Dur D. Jeyaseelan wrote:
> > >(Thu, 06 Feb 2003 22:23:12)
> > >>> > > > > > > > > > Richard,
> > >>> > > > > > > > > >   Alcatel USA, Inc.                  Internet:
> > ><userid>@ssd.usa.alcatel.com
> > >>> > > > >   1000 Coit Road, Plano, Texas 75075
> > >>> > > > >   ******* The opinions expressed are not those of Alcatel
USA, Inc.
> > >*******
> > >>> > > > > > > > > > On Thu, 6 Feb 2003, Richard Adams wrote:
> > >>> > > > > > > > > > > Brian,
> > >>> > > > > > I agree with you. I think when the ASP becomes active, it
should
> > >do an
> > >>> > > > > > audit to update its knowledge of the SS7 network. The ASP
needs
> > >to take
> > >>> > > > > > the initiative to find out about the SS7 nodes etc. in
which it
> > >is
> > >>> > > > > > interested. Any other method of working would lead to
impossible
> > >loading
> > >>> > > > > > on the SG.
> > >>> > > > > > > > > > Yes i agree but your suggestion is an indirect
method.
> > >>> > > > > I am proposing a direct method to send SSNM messages from
SGP to
> > >INACTIVE
> > >>> > > > > ASP. When SGP sends DUNA or DRST to ACTVIE ASP, let him
also send a
> > >copy
> > >>> > > > > of the same message to INACTIVE ASP. I dont find any
difficulty
> > >here.
> > >>> > > > > > > > > >  > > > > > > Of course, I hope 199,999 of your
inactive ASPs do not decide to
> > >become
> > >>> > > > > > active at the same time.....! > > > > > > > > > >
Theoritically your example sounds good but practically NOBODY will
> > >>> > > > > configure 1 ASP ACTIVE and 199,999 ASPs INACTIVE.
> > >>> > > > > > > > > > --Samuel
> > >>> > > > > > > > > > > > > > > > > -- > > > > Brian F. G. Bidulock
> > >>> > > > [email-masked]
> > >>> > > > http://www.openss7.org/
> > >>> > > > _______________________________________________
> > >>> > > > Sigtran mailing list
> > >>> > > > [email-masked]
> > >>> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >>> > > > > > > > -- > > Brian F. G. Bidulock
> > >>> > [email-masked]
> > >>> > http://www.openss7.org/
> > >>> > _______________________________________________
> > >>> > Sigtran mailing list
> > >>> > [email-masked]
> > >>> > https://www1.ietf.org/mailman/listinfo/sigtran
> > >>> >
> > >>
> > >>--
> > >>Brian F. G. Bidulock
> > >>[email-masked]
> > >>http://www.openss7.org/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >_________________________________________________________________
> > >Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> > >http://join.msn.com/?page=features/junkmail
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

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

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

---

From: "Richard Adams" <[email-masked]>
Date: Tue, 11 Feb 2003 08:37:08 +0100

Brian,
what you suggest does seem to work OK. So with your judicious use of
SHOULD and MAY, I like the proposal.
Incidentally, it would be nice to find some place in the documents to
put the sequence diagrams ! 
They are useful in explaining how the RFC is used.
I've additional comments below between [RAA] and {raa}

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 10 February 2003 22:26
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA - AUTHORS-FINAL-ASP database equalization

Tolga,

Tolga Asveren wrote:
(Mon, 10 Feb 2003 11:18:27)
> I also think the proposed text might be usefull in IG
> and I have some commnets/questions below.
> 
>   Tolga
> --- Richard Adams <[email-masked]> wrote:
> > 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."
> [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. 

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(*).
[RAA] Could the restarting SG just ignore the ASPAC Ack for now, then
perhaps send the SSNMs later ? It depends in which part of its
restart it is in  - initially a restarting STP waits to
receive routeing info and constructs its routeings before
sending out any routeing data itself.
{raa}
  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.
[RAA] OK {raa}

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?
[RAA] OK to the above. In the scenarios, perhaps put a note about 
the number of SSNM messages can be kept to a minimum by sending
an SSNM message which gives the status of the majority of the
concerned signalling points, followed by one or more SSNMs 
where necessary giving the status of the minority of SPs ( {raa}

Kind regards,
Dick Adams,
[email-masked]