Subject: RE: [Sigtran] SUA: stop an ASP for Ongoing traffic

From: "Zannin, Francois" <[email-masked]>
Date: Tue, 30 Apr 2002 09:42:10 +0200

Tolga,

This approach implies a full TCAP database in the SG for all AS. 
First, this can be costly in CPU and memory, second, the SG must 
be aware of all TCAP transaction and there is no way to handle 
the TCAP prearranged END.

Should be the solution to tell the telecom operator that they 
are not able to stop properly the traffic when they need to 
stop an ASP?

The only current possible solution is to ignore that the SSN 
is hosting as TCAP application and that all APS are serving 
ALL the TCAP applications instances (a global message 
distribution between several ASP and AS).

Isn't it possible to add an indication between the ASP and 
the SG(p) that can carry different kind of information like 
this end of TCAP open dialog (something like the NOTIFY). 
This indication can be used in the future for this protocol 
evolution.

	Francois.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 6:58 PM
> To: [email-masked]
> Subject: RE: [Sigtran] SUA: stop an ASP for Ongoing traffic
> 
> 
> Francois,
> 
> Although it wouldn't be very elegant, SGP can also decide, 
> whether there are
> still dialogues alive on ASP (SGP knows for which dialogues a 
> particular ASP
> is responsible for and it can keep a list of open dialogues), 
> and sends
> ASPIAC-ACK only after there are no more open dialogues for 
> this ASP. In my
> view this is doable but I have to admit not very nice.
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Zannin, Francois [mailto:[email-masked]]
> > Sent: Monday, April 29, 2002 12:24 PM
> > To: Tolga Asveren; [email-masked]
> > Subject: RE: [Sigtran] SUA: stop an ASP for Ongoing traffic
> >
> >
> > Tolga,
> >
> > I think that only the AS associated to an ASP knows that it has
> > no more ongoing dialog. Only the AS can decide that the traffic
> > can be stopped. A solution should be to have a message from the
> > ASP for the SGP that indicate that the ASP do not want initiate
> > new dialog but the traffic can continue for the CONTINUE, END and
> > ABORT TCAP messages.
> >
> > Can it be possible to add a "NOTIFY LIKE" message from the 
> ASP to the SGP?
> >
> > 	Francois Z.
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Monday, April 29, 2002 6:10 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] SUA: stop an ASP for Ongoing traffic
> > >
> > >
> > > Francois,
> > >
> > > I believe ASPIA/ASPIA-ACK should be enough for such a case.
> > > ASPIA tells SGP
> > > that ASP wants to withdraw from handling traffic and SGP will send
> > > ASPIA-ACK, after all traffic is stopped.
> > >
> > >    Tolga
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > Zannin, Francois
> > > > Sent: Monday, April 29, 2002 10:54 AM
> > > > To: [email-masked]
> > > > Subject: [Sigtran] SUA: stop an ASP for Ongoing traffic
> > > >
> > > >
> > > > Hi,
> > > >
> > > > In draft SUA 13, 4.7.3.1 about TCAP traffic, it is said that
> > > > ongoing traffic for an AS passing through an inactive ASP is
> > > > returned in #UDTS message (TID for an inactive ASP).
> > > >
> > > > If we need to stop properly an ASP without ongoing transaction
> > > > traffic lost, what is the procedure to stop an ASP.
> > > >
> > > > In that case, we need to stop the distribution of "new" messages
> > > > to the concerned ASP but we still need to send it messages for
> > > > it's TID and to accept messages from this ASP for the ss7 network.
> > > >
> > > > Currently I haven't seen any messages that inform the SG(p) that
> > > > the ASP has to be removed of the distribution of new traffic.
> > > >
> > > > Francois Z.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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: "Tolga Asveren" <[email-masked]>
Date: Tue, 30 Apr 2002 08:19:41 -0400

Francois,

> Sent: Tuesday, April 30, 2002 3:42 AM
[TOLGA] I agree handling all of this stuff on SGP wouldn't be very nice, and
yes there will be a problem with prearranged end, unless one puts also the
necessary logic for it to SGP (which is even more ugly)
> are not able to stop properly the traffic when they need to
[TOLGA] In fact this problem occurs if you have simplex TCAP. If you have
active/standby or active/active TCAP layers, then there won't be a problem.
But still, in my opinion it would be better, if the protocol could handle
this also for simplex case properly.
> This indication can be used in the future for this protocol
[TOLGA] What do other people think?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Apr 2002 17:57:59 -0500

Tolga,

Tolga Asveren wrote:                     (Tue, 30 Apr 2002 08:19:41)
[snip]
> [TOLGA] What do other people think?
[snip]

Use TUA.

SUA attempting to track information a layer above (TCAP
transactions) is a boundary violation and not terribly
advisable.

In TUA, the ASP knows the state each transaction, is aware of
prearranged END, transaction and component timers.  This type of
coordination is possible.

Another approach that works for SUA is to have an RC(1) which is
based on GT (BEGIN transactions are typically routable on GT)
and an RC(2) which is based on PC/SSN only (no GT) and TID
label.  That way, one can deactivate for new transactions with
ASPIA RC(1) while allowing existing transactions under the TID
label to complete on RC(2).  After some time, the ASP could send
ASPIA RC(2) to complete the coordinated shutdown with that TID
label range either swithing over or loadsharing over the
remaining available ASPs.

If the ASPs are running as replicated susbsystems in SCCP, it is
possible to exchange the special forms of the DRST to request
permission to withdraw from service from the other ASPs serving
the subsystem.

So it looks like this:

                   _______        _______                
                  |       |      |       |               
                  | ASP1  |      |  ASP2 |               
                  |       |      |       |               
                  |_______|      |_______|               
                    | | |          | | |                 
                    | |  \___   __/  | |                 
                     \ \ ____\_/____/  |                 
                      \ X_____|______ /                  
                   ____|______|______|____               
                  |  __|__  __|__  __|__  |              
                  | |     ||     ||     | |              
                  | | RC1 || RC2 || RC3 | |              
                  | |_____||_____||_____| |              
                  |         _____         |              
                  |        /     \        |              
                  |       |  AMF  |  SG   |              
                  |       |       |       |              
                  |        \_____/        |              
                  |_______________________|              

Where the AMF looks like:

  RC         RK             TID Label            TM
 ---- ------------------ --------------- ---------------------
  RC1  DPC-X/SSN-5/GT-Y       none        ASP1/ASP2 Loadshare
  RC2  DPC-X/SSN-5       0 mask 0x8000000 ASP1/ASP2 Active/Standby
  RC3  DPC-X/SSN-5       1 mask 0x8000000 ASP2/ASP1 Active/Standby

To withdraw, ASP1 coordinates with ASP2 and sends ASPIA RC1
and receives no further transaction initiations (BEGIN).  ASP2
in loadshare mode on RC1 accepts all new transactions an assigns
TIDs in the label range for RC3 on all new transactions.

Existing transactions to ASP1 complete on RC2 (because they have
TIDs in the label range on RC2).

Once ASP1 is confident that all existing transactions have
completed (some implementation dependent indication), it can
send ASPIA RC2.  ASP2 detects this and gets an indication from
the SG that it is now the active ASP for RC2 any remaining
mesages received by ASP2 on RC2 can be deal with using TCAP
Abort procedures.

When ASP1 wants to start traffic again, it overrides RC2 with
ASPAC RC2.  It follows this with ASPAC RC1 to start receiving
a load of the initial transactions (BEGIN).

This stragegy can be accomplished by setting RK1 on a range
of Global Titles (regardless of whether final GTT has been done
or not).  This permits an ASP to withdraw and re-enter within
the granularity of a GT range instead of for an entire
subsystem.  The example is for an SSN 5 HLR, where a GT range
migth be, for example, a range of MINs representing a service
provider or service provider area.

This approach also works for multiple SGs.  Identical routing keys
are defined on both SGs and the withdrawing/rejoining ASP sends
ASPIA/ASPAC to both SGs.  It is even possible to withdraw from
only on SG, while continuing to share transaction load on the
other SG.  This might make some maintenance actions with regard
to SGs smoother.

No changes are required to the SUA draft to permit this
operation.  The TID labels are already provided for.

Don't attempt this approach with SUA CO protocol classes on
multiple SGs acting as STPs though.  The DLR label approach is
broken for multiple SGs acting as STPs.  Actually it is somewhat
broken for single SGs as well.  The difference is that using the
TID label approach, there is a full TCAP state machine that is
pepared to handle Aborts for TCAP messages that go astray.  In
the SUA CO case there is no CO-state machine at the ASP to
correctly handle situations in the tables in Q.714 Appendix B.
The proposed registration procedure for DLRs would have
permitted this approach for SUA CO.

The way that registration would look for TID, is that when ASP1
accepts a new transaction on RC1, it would register the assigned
local TID against RC2.  ASP2 accepting new transactions on RC1
would register assigned local TID against RC3.  When
transactions complete, ASP1 would deregister the TID from RC2
and ASP2 would deregister the TID from RC3.  That way, the
SG is aware of what open transactions there are against RC2 and
RC3.

Then things could be controlled from the SG instead of just the
ASP.  The SG could issue unsolicited ASPIA Ack to ASP1 for RC1.
This would stop all new transactions from being routed to ASP1.
Once the last TID was deregistered from RC2, the SG could send
ASPIA Ack to ASP1 on RC2 completing withdrawing ASP1 from
service.  Any further ASPAC attempts from ASP1 for RC1 or RC2
could be met with "Management Blocking" until the SG is ready
to allow ASP1 back into service.

This is one of the many reasons why a (de)registration approach
to TID/DLR is supperior to TID/DLR Labels.

I propose that TID/DLR registeration/deregistration messages be
placed back into SUA.  TUA has TID registration/deregistration
facilities, and that is why I would recommend using TUA in this
scenario rather than the existing SUA.

--brian

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