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

From: Angermayr Manfred <[email-masked]>
Date: Tue, 11 Dec 2001 14:58:06 +0100

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]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Dec 2001 08:59:24 -0600

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)
> 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/

---

---

From: Andrew Booth <[email-masked]>
Date: Tue, 11 Dec 2001 12:10:39 -0500

Hi Brian,

I believe it makes sense to send SSNM messages to INACTIVE ASPs in some cases, such as the case mentioned below by Manfred Angermayr as well as other cases.  May I ask why you find this unreasonable?  I haven't found any convincing reasons in the MTP Restart thread or elsewhere.

Does it break the current M3UA/SUA MTP Restart procedures if we allow the sending of SSNM messages to INACTIVE ASPs?

Andrew

"Brian F. G. Bidulock" wrote:

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

---

---

From: "Vats, Umesh" <[email-masked]>
Date: Tue, 11 Dec 2001 17:59:24 -0800

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.

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.

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,

--brian

> 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. 
> 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/

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Dec 2001 05:39:51 -0800 (PST)

Hi,

Please see comments below.

  Tolga

> obvious benefit is that ASPs won't have to start the
[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.
> 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.
> > I also prefer the current SUA approach, where SSNM
> messages MAY be sent to
> inactive ASPs.
> You are currently subscribed to sigtran as:
> [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

---

---

From: Pathangi N Janardhanan <[email-masked]>
Date: Wed, 12 Dec 2001 20:30:11 +0530

Hi,

> of this starts with the interpretation of the meaning
[jana] I thought that at the start of the restart procudeure, the
MTP3 layer assumed all nodes as accesible, and at the end
of the restart procedure the MTP3 layer can indicate the
restart to the user parts, and as an implementation specific
option indicate the availability or un-availability of destinations.

  If that is the case, then why should we not allow the
SSNM messages in Inactive state. The ASP can build its
reachability rather then doing an audit once it becomes active.
Ofcourse the ASP can choose to ignore the SSNM and
do an audit after it becomes active

> reachable for the other one.

 If the SG is servicing two DPCs, as two differetn ASs. If the
SG determines that it is unable to reach a particual PC x, then this
PC x is unreachable via this SG for all the AS it serves. Could you
explain how the reachability of PC x at the SG depends on if it
is DPC y or DPC z for the ASP?

Thanks
Jana

> > [email-masked]
> > [email-masked]
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Dec 2001 07:27:55 -0800 (PST)

Hi, 
Please see comments below.
  Tolga
--- Pathangi N Janardhanan <[email-masked]>
wrote:
> > > ASPs in inactive state. For some
> implementations, it
> > > may not
> > > but many implementations may benefit from it.
> The
> > > one most
> > > obvious benefit is that ASPs won't have to start
> the
> > > audit
> > > procedure.
[TOLGA]MTP3 assumes all nodes accessible but not MTP3
User(Q.701 8.5) This was discussed in "MTP3 Restart"
thread. Please refer to there.
> > > SGP can send SSNM messages to all ASPs in ACTIVE
> or
> > > INACTIVE
> > > been registered(or will be later registered).
> SSNM
> > > messages
[TOLGA] What you say is not correct. Please refer to
the threads I mentioned in my former message for an
example. (From PC1 of SG there is a F-link to a
destinationA, whereas from the other PC2 there is no
F-link. In some configurations destinationA does not
accept messages from PC1, if they don't arrive from
the F-link. So destinationA is accessible for some AS
and not accessible for other ones.)
> > > Subject: Re: WG: m3ua 10, sua 9: SSNM to
> inactive
> > > ASPs
> > >
> > >
> > > Angermayr,
> > >
> > > MTP Restart procedure requires that INACTIVE
> ASPs
> > > not be sent
> > > SNMM.
> > >
> > > --brian
> > >
> > > Angermayr Manfred wrote:
> > > > 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
> > > >
> > > > 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

---

---

From: Andrew Booth <[email-masked]>
Date: Wed, 12 Dec 2001 13:54:26 -0500

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 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.

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.

Your thoughts?
Andrew

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Dec 2001 14:10:05 -0600

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
> 
>    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

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

---

---

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

Resend ( again ):

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

Angermayr Manfred wrote:

> 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!
> Manfred
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Mittwoch, 12. Dezember 2001 21:10
> An: sigtran
> Betreff: Re: WG: m3ua 10, sua 9: SSNM to inactive ASPs
>
> Andrew,
>

> SNMM to be sent to INACTIVE AS?

[snip]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Dec 2001 14:31:23 -0600

Andrew,

Your examples do not sound realistic.

Besides, an ASP cannot rely upon an SG sending SNMM to INACTIVE AS,
beceause it is not required to do so.  Placing a MAY acheives nothing.

--brian

Andrew Booth wrote:                                          (Thu, 13 Dec 2001 14:41:35)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Dec 2001 14:42:42 -0600

Andrew,

Andrew Booth wrote:                                        (Fri, 14 Dec 2001 15:20:45)
> Hi Brian,
> 
> The second example cited (Example 2) is one way of implementing MTP
> Management for an ISUP protocol converter, with the SG sitting on the
> boundary of ANSI and ITU networks.

There is no need to support such protocol conversion from a MTP-User
perspective using M3UA.  M3UA backhaul exports the MTP-User interface
(it does not export the guts of the SG so that protocol converters can
be built) and M3UA IPSP only supports point-to-point and not the
transfer function.  You are asking M3UA to do more than it was intended
to do.  As such, the example is still unrealistic.

> 
> I agree that you couldn't assume that the SG would send SSNM messages to
> an INACTIVE AS, but the implementer of the SG and the implementer of the
> AS could talk and decide if the behaviour of the SG was appropriate to the
> needs of the AS.  This seems to be an appropriate use of MAY, and an
> appropriate way to use an optional feature.
> 
> May I ask why SHOULD NOT is the appropriate keyword?  From RFC 2119:
> 
> 6. Guidance in the use of these Imperatives
> 
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
> 
> I don't see the "potential for causing harm" in sending SSNM messages to
> INACTIVE ASPs.

Harm would include:

o   putting unnecessary messages on the network endangering legitimate traffic
    during times of congestion;
    
o   causing the ASP to response with ERR("Unexpected Message") to each SNMM
    for an inactive AS, thus doubling unnecessary traffic and increasing the
    harm above.

o   breaking the "export the MTP-User interface" paradigm by exposing
    unnecessary MTP stack internals.

Besides SHOULD NOT and MAY are the same thing.

--brian

> Thanks,

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

---