Subject: WG: WG: m3ua 10, sua 9: SSNM to inactive ASPs

From: Angermayr Manfred <[email-masked]>
Date: Thu, 13 Dec 2001 13:00:46 +0100

Resending ...

Hello Brian,
you said that an SG can not know, wheter the sent SSNM are received by an inactive ASP/AS or not. As SSNM messages are not acknowledged, even if the ASP active, there is no guarantee for the SG, that its SSNM messages are actually processed (they could be lost due to internal processing failures...).
For the SG however this no problem, the response DUNA methode will clear the situation.
Normally however the M3UA layer at an inactive ASP should be able to process incomming SSNM messages - the M3UA layer has indicated its availability with the ASP UP message. Maybe the user parts are not ready, but the M3UA layer can keep the status (in case of multiple SGs it has to keep the status anyway).
If an ASP implementation is not able or does not want to process SSNM messages in the inactive state, it is free for the ASP to discard them and request the status later on with the audit procedure.
For other architectures however it could be usefull to give the SSNM messages to the ASP in the inactive state. So why should we not allow the SG to offer these messages? 
As Andrew said, by saying that 'the SG MAY send SSNM messages to INACTIVE ASPs' we could gain more flexibility. There is no need for the ASP to take them, but if the SSNM messages are usefull for the ASP, we should allow the SG to send them!

Regards,
Manfred

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 12. Dezember 2001 21:10
An: sigtran
Cc: [email-masked]
Betreff: Re: WG: m3ua 10, sua 9: SSNM to inactive ASPs

Andrew,

Andrew Booth wrote:                                          (Wed, 12 Dec 2001 13:54:26)
> Hi Tolga,
> 
> I agree with your point that the arguments in the MTP Restart thread
> assume that the user is only present if the ASP is ACTIVE.  It seems
> to me that this interpretation is overly restrictive.  The description
> in the M3UA draft 10 is
> 
>    ASP-INACTIVE:  The remote M3UA peer at the ASP is available (and
>    the related SCTP association is up) but application traffic is
>    stopped.  [snip the comments about what should and should not be
>    sent, that differs between M3UA and SUA]

The concensus was that and ASP is inactive on a per-AS basis.
Indeed, an ASP can be ACTIVE for one AS/RC and INACTIVE for
another at the same time.  When an ASP goes UP, it is ASP-INACTIVE
for all the AS configured.  Things change from there on out.

> 
> The description does not say that the user is "not present", just that
> the user isn't ready to process "application traffic".  If we
> interpret "application traffic" as meaning DATA messages, then it can
> be appropriate to send SSNM messages to INACTIVE ASPs.  I can think of
> many examples where this interpretation is useful.

I think you would agree that the SG needs to know whether a user
is available or not.  How else is the SG to send UPU on behalf of
a user or decide to route traffic to the "default" AS.  The SG
needs to have a means to determine the availability of a user.
The only mechanism in M3UA and SUA for the SG to know user-part
availability is whether an ASP is ACTIVE or INACTIVE for an AS.
There is no other way to make things work at the SG.

> If we don't seem to break anything by saying that the SG MAY send SSNM
> messages to INACTIVE ASPs, and we get extra flexibility.  With MAY,
> either option is open to an implementation, depending on the setup and
> application requirements.  My vote is still for the current SUA
> approach, if the two drafts merge their procedures in this area.

Placing a MAY here accomplishes nothing, as the SG has only one
indication of user availability (the AS is ACTIVE).  If an SG sends
SNMM to an INACTIVE AS, how does it know that the AS ever receives
them?  It seems rather pointless to send them in the first place.

This is the very same for SUA.  Why did anyone think that SUA needs
SNMM to be sent to INACTIVE AS?

--brian

> 
> Your thoughts?
> Andrew
> 
> Tolga Asveren wrote:
> 
> > Hi,
> >
> > Please see comments below.
> >
> >   Tolga
> >
> > --- "Vats, Umesh" <[email-masked]> wrote:
> > > Hi  All
> > >
> > > I don't see any problem with SGPs sending SSNM
> > > messages to
> > > ASPs in inactive state. For some implementations, it
> > > may not
> > > be useful(I have gone through the old mail archives)
> > > but many implementations may benefit from it. The
> > > one most
> > > obvious benefit is that ASPs won't have to start the
> > > audit
> > > procedure.
> > [TOLGA] It depends on, how one interpretes the meaning
> > of ASPAC message. I think during the "MTP3 Restart"
> > discussions, it was interpreted as declaring
> > availability of the user part. So, before ASPAC, the
> > user part was considered as not existing. In MTP3,
> > after a restart user of MTP3 sees every destination as
> > inaccessible so to mimic that behaviour, it is
> > foreseen that availability information of destination
> > should be updated on ASP, after user part is declared
> > as available, namely after ASPAC. But as I said, all
> > of this starts with the interpretation of the meaning
> > of ASPAC.
> > >
> > > I have another query : "Why do we need RC in the
> > > SSNM messages ?"
> > >
> > > SGP can send SSNM messages to all ASPs in ACTIVE or
> > > INACTIVE
> > > state without caring for the RCs for which those
> > > ASPs have
> > > been registered(or will be later registered). SSNM
> > > messages
> > > need not carry any RC parameter.
> > [TOLGA] They need. For that, you can refer to
> > "M3UA07:Network Appearence" and "M3UA07:RC in DATA and
> > SSNM messages" threads. The problem is that an ASP can
> > serve ASs with different DPCs and for them SS7
> > connectivity of SG can be different. So, a destination
> > can be unreachable for one of them where it is still
> > reachable for the other one.
> > >
> > > Umesh
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock
> > > [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 6:59 AM
> > > To: sigtran
> > > Cc: [email-masked]
> > > Subject: Re: WG: m3ua 10, sua 9: SSNM to inactive
> > > ASPs
> > >
> > >
> > > Angermayr,
> > >
> > > It makes no sense to send SNMM to ASPs that are
> > > INACTIVE.  The
> > > MTP Restart procedure requires that INACTIVE ASPs
> > > not be sent
> > > SNMM.
> > >
> > > --brian
> > >
> > > Angermayr Manfred wrote:
> > > (Tue, 11 Dec 2001 14:58:06)
> > > > Hi,
> > > > I also prefer the current SUA approach, where SSNM
> > > messages MAY be sent to
> > > inactive ASPs.
> > > > If the SG knows for which Aplication Servers the
> > > ASP is configured -
> > > either statically configured or after the dynamic
> > > registration procedure -
> > > the inactive state is in my opinion a good point to
> > > provide information
> > > about the SS7 network. This has the advantage, that
> > > as soon as the ASP
> > > becomes active it has immediately the correct view
> > > of the SS7 network.
> > > >
> > > > Regards,
> > > > Manfred Angermayr
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Andrew Booth [mailto:[email-masked]]
> > > > Gesendet: Freitag, 7. Dezember 2001 19:26
> > > > An: sigtran
> > > > Betreff: m3ua 10, sua 9: SSNM to inactive ASPs
> > > >
> > > >
> > > > Hi All,
> > > >
> > > > This is a resend, sorry if it arrives twice.
> > > >
> > > > I've been concentrating mostly on SUA, but
> > > recently noticed a few
> > > > procedures that are
> > > > different between M3UA draft 10 and SUA draft 9.
> > > In particular:
> > > >
> > > > In M3UA draft 10, SSNM messages SHOULD NOT be sent
> > > to inactive ASPs (
> > > > this was
> > > > changed in version 10 after some debate on the
> > > list ).
> > > > In SUA draft 9, SSNM messages MAY be sent to
> > > inactive ASPs (this was
> > > > changed in
> > > > version 9, as was recommended after the SUA
> > > bakeoff ).
> > > >
> > > > Will these procedures be consolidated at some
> > > point?  If so, I would
> > > > like to put in
> > > > my vote for the current SUA approach.
> > > >
> > > > Andrew
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---
> > > > You are currently subscribed to sigtran as:
> > > [email-masked]
> > > > To unsubscribe send a blank email to
> > > [email-masked]
> > > >
> > > >
> > > > ---
> > > > You are currently subscribed to sigtran as:
> > > [email-masked]
> > > > To unsubscribe send a blank email to
> > > [email-masked]
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as:
> > > [email-masked]
> > > To unsubscribe send a blank email to
> > > [email-masked]
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as:
> > > [email-masked]
> > > To unsubscribe send a blank email to
> > [email-masked]
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Check out Yahoo! Shopping and Yahoo! Auctions for all of
> > your unique holiday gifts! Buy at http://shopping.yahoo.com
> > or bid at http://auctions.yahoo.com
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to [email-masked]
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Andrew Booth <[email-masked]>
Date: Thu, 13 Dec 2001 13:56:35 -0500

Resend (with minor edits):

Hi Brian,

I agree with your comment that the ASP is ACTIVE or INACTIVE only in the context of an AS.

I also agree that the SG needs to know whether an AS is available to receive traffic ( again, I'm interpreting this as DATA traffic ) in order to generate UPU messages or perform the default action, and that AS ACTIVE is the appropriate indicator.  I think the SG has more freedom in deciding what to do with
SSNM messages, since there are no remote SS7 entities expecting a response.

Depending on the specific setup, you may have a good idea that the SSNM messages are arriving to the application, even if the AS is INACTIVE.  Manfred has presented some reasons why the M3UA layer at the ASP might want to receive SSNM messages in the ASP Inactive state even if the user part is unavailable.

Here are some examples of why one might want to send SSNM Messages to an INACTIVE ASP or AS.

Example 1) Suppose you have a SG with an M3UA implementation.  A client wants to build an application that connects to you using M3UA/SCTP, and wants to receive SSNM Messages in the ASP INACTIVE state for some reason internal to their application.  In this case, you would like to send SSNM Messages to the
client's AS or ASPs even if they are in the INACTIVE state.

Example 2) Suppose that an application's ability to process traffic is dependent on the network state.  The application wants to be AS ACTIVE only when the network state permits proper functioning, and AS INACTIVE the rest of the time.  In this case the application would like to receive SSNM messages in the
AS INACTIVE state so it can determine when to become active.

Your thoughts?
Andrew

> SNMM to be sent to INACTIVE AS?

[snip]

---

---

From: Andrew Booth <[email-masked]>
Date: Thu, 13 Dec 2001 12:37:39 -0500

Hi Brian,

What it means to deliver an SSNM message to an inactive ASP depends on the specific setup.  If the application and the M3UA layer are the same process, then the application is present as soon as the ASP is inactive.

As for why one might want to send SSNM Messages to an inactive ASP, consider the following examples:

1) You have a SG with an M3UA implementation.  A client wants to build an application that connects to you using M3UA/SCTP, and wants to receive SSNM Messages in the ASP Inactive state for some reason internal to their application.  If the M3UA specification says that you MAY send SSNM messages to such an ASP
you can readily agree to their request.  If the M3UA specification ends up saying that you SHOULD NOT send such messages, you have to carefully consider all the possible impacts of the change.  As far as I can see the impact is just extra load, a factor which one is certain to consider anyway when deciding
whether to send messages.  In this case the extra research and energy spent deciding why there is a SHOULD NOT in the specification would amount to completely wasted effort.

2) A SG is connected to two SS7 networks, network 1 and network 2.  An application interacts between PC A in network 1 using Routing Context 1 and PC B in network 2 using Routing Context 2.  Without either of A or B, the application cannot perform its intended function.
To handle network failures/maintenance, the following scheme is proposed:
If PC B becomes unavailable (as indicated by an SSNM message to the application ), the application sends an inactive for Routing Context 1.  When PC B becomes available again (as indicated by an SSNM message), the application send ASP Active for RC 1.  Similarily for PC A and RC 1.
Unfortunately, if PC A and PC B are both unavailable at the same time, the application cannot determine the availability of either since no longer receives SSNM messages.

Angermayr Manfred wrote:

> > > To unsubscribe send a blank email to [email-masked]
> >
> >
> >
> > ---
> > To unsubscribe send a blank email to [email-masked]
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
> ---
> To unsubscribe send a blank email to [email-masked]
>
> ---
> To unsubscribe send a blank email to [email-masked]

---