Subject: M3UA v9: ASPStates

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Oct 2001 17:55:56 -0500

Section 4.3.1 says:

  ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the 
  related SCTP association is up) but application traffic is stopped.  In 
  this state the ASP MAY be sent any non-DATA M3UA messages.

Because an ASP is active on a per-AS basis, it is unclear which
messages are permitted here.  Sending of SNMM messages to an ASP
which is inactive for an AS might interfere with the MTP restart
procedures and should not be allowed.  To be consistent with other
passages, the draft should say:

  "In this state the ASP SHOULD NOT be sent any DATA or SNMM messages
   for the AS for which the ASP is inactive."

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

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

---

From: Jacques Rajchgod <[email-masked]>
Date: Fri, 12 Oct 2001 10:24:39 -0500

Inside the text...

Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 5:56 PM
> To: sigtran
> Subject: M3UA v9: ASPStates
>
>
> Section 4.3.1 says:
>

From Jacques
-------------------------------------------------------------------------
I think that the def is inaccurate. I suggest that we reword the def as
follows:
"ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the
related SCTP association is up) but no application traffic exists.
			           ***********************************
----------------------------------------------------------------------------
------------
When I go up first time from "DOWN" to "INACT" , I am ASP-INACT first time.
There is no case here of traffic having stopped. There has never been any
traffic
(I was down until now). Using my suggested words, the def would become
applicable to all situations. Tks.
----------------------------------------------------------------------------
------------

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

---

---

From: Angermayr Manfred <[email-masked]>
Date: Tue, 16 Oct 2001 09:55:41 +0200

Hello Brian,
why should SSNM messages not be sent to an inactive ASP? If you wait for the ASP to become active, the ASP will begin to send DATA messages to destinations that are not available. This would cause an unnecessary loss of messages.
This message loss can be easily avoided by sending DUNA messages already to an inactive ASPs. This has the advantage, that when the ASP becomes active, it has already a correct database! 
I would even say, that in the inactive state the ASP SHOULD be sent SSNM messages. In order to be consistent with the restart procedure, the text in chapter 4.6 also must be changed to: 'the M3UA layers at the SGPs inform all concerned APSs in the ASP-ACTIVE and ASP-INACTIVE state.'

Regards,
Manfred

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Freitag, 12. Oktober 2001 00:56
An: sigtran
Betreff: M3UA v9: ASPStates

Section 4.3.1 says:

--brian

---
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, 16 Oct 2001 03:40:23 -0500

Manfred,

This was resolved Sep 6 on the thread MTP Restart.

The ASP cannot audit outside of a Routing Context (routing is AS dependent).
A Routing Context (AS) is not valid until active.  ASPs are only inactive
for an AS.  If the SGP sends SNMM for all inactive AS, messages are being
sent which have no purpose.

When an AS goes active, it has the option of sending DAUD and waiting for
responses before sending any messages.  Or it could blindly send messages
and receive responsive DUNAs and such.  If the AS (via another ASP) 
already has routing information, in need not send DAUD, but may still if
it so desires.  This ensures that SNMM messages in response to audit are
only performed in response to an AS performing a DAUD and that the responses
are within the context of the AS performing the audit.

Angermayr Manfred wrote:                                (Tue, 16 Oct 2001 09:55:41)
>
> Hello Brian,
>
> why should SSNM messages not be sent to an inactive ASP? If you wait for the
> ASP to become active, the ASP will begin to send DATA messages to
> destinations that are not available. This would cause an unnecessary loss of
> messages.  This message loss can be easily avoided by sending DUNA messages
> already to an inactive ASPs. This has the advantage, that when the ASP
> becomes active, it has already a correct database!  I would even say, that
> in the inactive state the ASP SHOULD be sent SSNM messages. In order to be
> consistent with the restart procedure, the text in chapter 4.6 also must be
> changed to: 'the M3UA layers at the SGPs inform all concerned APSs in the
> ASP-ACTIVE and ASP-INACTIVE state.'

Wrong.  It was resolved that ASPs in the ASP INACTIVE state SHOULD NOT be sent
SNMM messages.  The OLD MTP Restart procedure did this: the new one does not.
The change cited below was agreed to Sep 6 on the M3UA: MTP Restart thread.
The old procedure had too many problems to mention here.

--brian

> 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: Angermayr Manfred <[email-masked]>
Date: Tue, 16 Oct 2001 12:56:41 +0200

Hello Brian,
I'm sorry, that I'm joining the M3UA discussions so late. But maybe you can help me to understand the protocol, because your answer confuses me.

Why is the Routing Context (AS) not valid until active? 
The information about the AS respectively RC is exchanged by using the registration procedure. This is done while the ASP is inactive. I assume the registration procedure does not use invalid data. If the optional registration procedure is not used, the AS information is known anyway. I don't understand what you want to tell me with this statement.

The SG also for an inactive AS / ASP (at least after the registration procedure) can select the SSNM messages to send that are relevant for the AS.

I also do not understand your next statement 'If the SGP sends SSNM for all inactive AS, messages are being
sent which have no purpose.'
I think the purpose of these messages is, that the concerned ASPs already have a correct database when they become active. Maybe the messages are unnecessary if the AS would stay inactive for ever (or at least for a long time), but I think this is not intended.

The ASP is not forced to process SSNM messages in the inactive state. If the ASP really wants to wait for becoming active and to get the information only via the slow audit procedure or via the ineffective response method, the ASP can do this anyway.

Brian, can you do me a favor? The problems you mentioned with the ASP getting SSNM messages in the inactive state are not obvious to me. Perhaps you can tell me at least the most crucial disadvantages, because up to now I see only the advantages.

Thanks a lot,
Manfred

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Dienstag, 16. Oktober 2001 10:40
An: sigtran
Betreff: Re: M3UA v9: ASPStates

Manfred,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 06:51:47 -0500

Manfred,

Please see comments below...

Angermayr Manfred wrote:                                (Tue, 16 Oct 2001 12:56:41)
>
> Hello Brian,
>
> I'm sorry, that I'm joining the M3UA discussions so late. But maybe you can
> help me to understand the protocol, because your answer confuses me.
> 
> The information about the AS respectively RC is exchanged by using the
> registration procedure.  This is done while the ASP is inactive.I assume the
> registration procedure does not use invalid data.

The registration procedure is optional.  At the time than an ASP goes
ASPUP the SGP may have no knowledge about which RCs (AS) the ASP is
configured for until the ASP goes ASPAC for a given RC.  Therefore an
SGP cannot necessarily tell which RCs an ASP is INACTIVE for if it has
never gone active for those RCs.

> If the optional registration procedure is not used, the AS information is
> known anyway.

The above statement is not true.  There is no requirement for the SGP to
know all the AS for which the ASP is configured at ASPUP.

> I don't understand what you want to tell me with this statement.

Just that.  At ASPUP, an SGP does not necessarily know for which AS the
ASP is in the ASP-INACTIVE state.  It does not necessarily know the state
of the AS at all (other SGPs may be have the AS in the ACTIVE state, this
SGP may know nothing about the state of the AS an assume that it is in
the AS-INACTIVE state because it has no ASP which is ASP-ACTIVE for that
AS).

> The SG also for an inactive AS / ASP (at least after the registration
> procedure) can select the SSNM messages to send that are relevant for the
> AS.

Because the AS is AS-INACTIVE, there is no MTP-User to receive the SNMM
messages, so there is no need to send them.

> I also do not understand your next statement 'If the SGP sends SSNM for all
> inactive AS, messages are being sent which have no purpose.'

As above, there is no MTP-User to receive them, so they are sent without
purpose.  The ASP can do little but discard them.

> I think the purpose of these messages is, that the concerned ASPs already
> have a correct database when they become active.

The data is AS specific and is delivered to the MTP-User as MTP primitives.
The ASP does not need to keep any database.  It merely delivers them to the
MTP-User as they arrive.  An AS in the INACTIVE state has no MTP-User and
the ASP does not need them because there is no MTP-User to deliver them to.

> Maybe the messages are unnecessary if the AS would stay inactive for ever
> (or at least for a long time), but I think this is not intended.

Again, the SGP cannot always tell for which AS an ASP is inactive after ASP UP.
Even if it can tell, there is no need to send them.

> The ASP is not forced to process SSNM messages in the inactive state. If the
> ASP really wants to wait for becoming active and to get the information only
> via the slow audit procedure or via the ineffective response method, the ASP
> can do this anyway.

The response method is not ineffective: it is part of the MTP specification
and is an essential part of the MTP to MTP-User interface which must be
transparently supported by M3UA.

The Audit procedure is not slow.  DAUD(*).

> Brian, can you do me a favor? The problems you mentioned with the ASP
> getting SSNM messages in the inactive state are not obvious to me. Perhaps
> you can tell me at least the most crucial disadvantages, because up to now I
> see only the advantages.

You have not listed any advantages.  Please list some.

--brian

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

---

---

From: Kurt Kite <[email-masked]>
Date: Tue, 16 Oct 2001 12:20:47 -0500

Some comments and questions below.

Regards,
Kurt

> never gone active for those RCs.

The SGP can tell which RCs an ASP is INACTIVE for if it uses static configuration.

> know all the AS for which the ASP is configured at ASPUP.

There is no requirement but it is allowed.

> the ASP does not need them because there is no MTP-User to deliver them to.

There are still several sections in the draft indicating that the ASP maintains route
status, e.g., section 4.5.2.2. Is is really true that the ASP no longer needs to
maintain
route state or is just for the SEP case?

> 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, 16 Oct 2001 12:48:08 -0500

Kurt,

Kurt Kite wrote:                                             (Tue, 16 Oct 2001 12:20:47)
> The SGP can tell which RCs an ASP is INACTIVE for if it uses static configuration.

It is clear that this is not necessarily the case.  It is only the case
for both static and fixed configurations where the SG has been provisioned
to know what AS and ASP will go active for and can successfully fortell
the future.

> There is no requirement but it is allowed.

The opposite is also not a requirement but is allowed.

> maintain route state or is just for the SEP case?

The only case that the ASP needs to maintain route status is the multiple
SG case where it must maintain the status of routes via each SG.  This is
also possible using DAUD when required rather than "accumulating" routing
information.  If the ASP has no AS active there is no need for it to maintain
any routing information.  It must be able to acquire routing information when
an AS goes active, but this is what the DAUD procedure is for.  (Periodic DAUD
is useless.)

--brian

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

---

---

From: Kurt Kite <[email-masked]>
Date: Tue, 16 Oct 2001 14:32:10 -0500

Brian,

Some comments below.

[snip]

> to know what AS and ASP will go active for and can successfully fortell

It is clear that it is absolutely the case for a fixed configuration using static
IP addressing.
No fortune telling is necessary.

> The opposite is also not a requirement but is allowed.

I agree.

[snip]

> an AS goes active, but this is what the DAUD procedure is for.  (Periodic DAUD

Your arguments make sense to me for the SEP use case. Although, I think that a periodic
DAUD is useful in the following situation:
- an SS7 destination becomes unavailable, the SG notifies the ASP via a DUNA, the
ASP notifies the User
- the SS7 destination becomes available, the SG notifies the the ASP, but the User is not
notified, e.g., temporary congestion in the ASP

In the above case, I believe a periodic DAUD is useful.

In the multiple SG case, I agree that it is not necessary to maintain routing information
when an AS is not active. When an AS becomes active the ASP can audit at that point.
However, consider the case where the AS is active and a destination becomes unavailable
from via one SG. At that point how does the ASP determine if the User should be notified?
By sending DAUD to all of the other SGs and "accumulating" the results?

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 17:45:59 -0500

Kurt,

Kurt Kite wrote:                                             (Tue, 16 Oct 2001 14:32:10)
> No fortune telling is necessary.

But it is not a requirement to statically provision to the extent that the SG
knows all the AS for which the ASP might go active.  In these configurations
the SG will need a forture teller.

> In the above case, I believe a periodic DAUD is useful.

I was not asking for the procedure to be removed: I can just see no use for
it, but I'm willing to leave the periodic procedure there.

> By sending DAUD to all of the other SGs and "accumulating" the results?

When the AS is active, it is receiving SNMM.  It is when it is inactive that
the ASP does not need to receive them because the MTP-User is not there to
see them.

--brian

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

---

---

From: Kurt Kite <[email-masked]>
Date: Tue, 16 Oct 2001 18:21:41 -0500

Brian,

See below please.

/Kurt

> the SG will need a forture teller.

Fair enough.

> the ASP does not need to receive them because the MTP-User is not there to

I agree. My point was that, in the multiple SG case, when the AS is active I believe that the
ASP should maintain route state in order to inform the user when a destination becomes
unavailable. Otherwise, the ASP has to send DAUDs to every SG to determine the overall route
state each time it receives an SNMM message.

In the end, how an ASP determines the collective route state toward a destination serviced by
multiple SGs is implementation dependent. The draft only needs to indicate that the ASP should
inform the User when the collective route state of a destination has changed.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 20:00:36 -0500

Kurt,

Kurt Kite wrote:                           (Tue, 16 Oct 2001 18:21:41)
[snip]
> >
> > > In the multiple SG case, I agree that it is not necessary to maintain
> > > routing information when an AS is not active. When an AS becomes active
> > > the ASP can audit at that point.  However, consider the case where the
> > > AS is active and a destination becomes unavailable from via one SG. At
> > > that point how does the ASP determine if the User should be notified?
> I agree. My point was that, in the multiple SG case, when the AS is active I
> believe that the ASP should maintain route state in order to inform the user
> when a destination becomes unavailable. Otherwise, the ASP has to send DAUDs
> to every SG to determine the overall route state each time it receives an
> SNMM message.

In fact, for single SG configurations the ASP need not keep any route
state whatsoever and only needs to perform a DAUD if requested by the
MTP-User (but this is not part of the MTP-User interface: there is nothing
saying that once the MTP/MTP-User interface is instantiated that the
MTP sends any MTP-PAUSE, RESUME or STATUS primitives whatsover, so neither
does the ASP).  When an MTP-User at an AS sends to a destination that is
unavailable, the SG should respond just as it would to a local MTP-User,
with the MTP-PAUSE, RESUME and STATUS primtives as are appropriate for the
variant (ITU-T and ANSI are a little different here...).  The ASP merely
echoes those primitives to the user.

In the IPSP case?  Well the IPSP is still rather vague as to where these
MTP functions reside, however, it appears that a similar function is
peformed at the local IPSP as would be provided by the SG.  Well, SNMM
messages should not even occur in the IPSP scenario.

It is, therefore, not necessary to perform DAUD at all: an MTP-User can
attach itself to an AS at the ASP and interact with it in the same fashion
as it would interact with a local MTP.  It should be unaware of the fact
that the MTP services are being provided by the distant SG.

Many existing MTP-User applications get away without keeping route state
anyways and pretty much ignore MTP-PAUSE and MTP-STATUS indications: they
just periodically attempt to send again.  Auditing serves no purpose for
these applications and maintaining route state should stay with the SG,
where route state is kept.

Both approaches could be taken, so they should both be permitted; however,
there is no need in either approach for the ASP to receive SNMM for inactive
AS, and for proper ASP Traffic Management, an SGP and an ASP should be
permitted to not generate or not accept SNMM messages for inactive AS (those
without MTP-Users).

> In the end, how an ASP determines the collective route state toward a
> destination serviced by multiple SGs is implementation dependent. The draft
> only needs to indicate that the ASP should inform the User when the
> collective route state of a destination has changed.

I don't know what you mean by "collective".

--brian

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

---

---

From: Schmidt Andre <[email-masked]>
Date: Wed, 17 Oct 2001 08:07:52 +0200

Hello Brian, Manfred

[Brian wrote]
At the time than an ASP goes ASPUP the SGP may have no knowledge about which RCs (AS) the ASP is configured for  until the ASP goes ASPAC for a given RC. 

[my comment]
If that would be true, how associate the SGP the received RC to its belonging RK?  
One point in which all systems are similar is, that in every SGP for every RK an RC must be assigned. Otherwise an ASP_ACT would be answered with ERROR Invalid_Routing_Context.
In this point I absolute in agree with Manfred, that already the INA state should be used for SSNM messages. Of course if Dynamic Configuration is used then the RK is not known before REG REQ was received. But after this the SGP is in INA-state maintaining RK respectively RC data. So why should SSNM messages not send to the adjacent AS?

[Brian wrote]

[my comment]
I agree with you that in the normal configuration no database is keep in the ASP.  But if this ASP starts to go in connection to more than one SGP (Multiple SGP Configuration), this database is unavoidable. Therefore it can be considered as sure, that every ASP (produced by different vendors) is able to keep an own database. The question is only on which point this database should be generated. 
Of course the MTP-User is not available in the INA-state, but why not should the ASP process all SSNM messages in the meantime. Not more as a table about the state of the concerning SPC's? 
An MTP-User, which is switching in the available state, could be informed immediately about the actually SPC-states. By exchanging of ASP ACT/ACK the MGC would already be informed about the state of the SS7 network. 
That would means no response method or Audit procedure are necessary.
And of course the response method is part of the MTP specification, but exactly there you will also find a possibility to exchange TFP/TFA before starting traffic. -MTP-restart-

If we consider advantage and disadvantage I can only see that by using Manfred's suggest the activation of an AS would be faster and more reliable as before. 
And an important advantage is, that no user messages must be discarded (response method not necessary)!

With kindest Regards... Andre

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Dienstag, 16. Oktober 2001 13:52
An: sigtran
Betreff: Re: M3UA v9: ASPStates

Manfred,

--brian

-- 
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 01:30:36 -0500

Andre,

Schmidt Andre wrote:                                      (Wed, 17 Oct 2001 08:07:52)
> Hello Brian, Manfred
> 
> [Brian wrote]
> At the time than an ASP goes ASPUP the SGP may have no knowledge about which
> RCs (AS) the ASP is configured for  until the ASP goes ASPAC for a given RC. 
> 
> [my comment]

The SGP has the RC and RK provisioned, it just doesn't know which ASPs
are going to register for or activate which RCs.

> One point in which all systems are similar is, that in every SGP for every
> RK an RC must be assigned. Otherwise an ASP_ACT would be answered with ERROR
> Invalid_Routing_Context.  In this point I absolute in agree with Manfred,
> that already the INA state should be used for SSNM messages.

The SGP does not necessarily know all the AS for which the ASP is
ASP-INACTIVE.

> Of course if Dynamic Configuration is used then the RK is not known before
> REG REQ was received. But after this the SGP is in INA-state maintaining RK
> respectively RC data. So why should SSNM messages not send to the adjacent
> AS?

There is no MTP-User to receive SNMM indications when AS is inactive at the
ASP.  There is no reason to send SNMM in INA.

> I agree with you that in the normal configuration no database is keep in the
> ASP.  But if this ASP starts to go in connection to more than one SGP
> (Multiple SGP Configuration), this database is unavoidable.

Yes it is very avoidable.  The SNMM now reflects the reachability from
the entire SG.  One SNMM from one SGP applies to all.  There is no difference
between multiple SGP or single SGP for SNMM.

> Therefore it can be considered as sure, that every ASP (produced by
> different vendors) is able to keep an own database.

No need in single SG case as described above.

> The question is only on which point this database should be generated.

This route state information already exists at the SG and is unnecessary
at the ASP.

> Of course the MTP-User is not available in the INA-state, but why not should
> the ASP process all SSNM messages in the
> meantime.

Because it is not necessary.

> Not more as a table about the state of the concerning SPC's?  An MTP-User,
> which is switching in the available state, could be informed immediately
> about the actually SPC-states.

Many MTP-Users disregard MTP-PAUSE and MTP-STATUS (increasing congestion)
anyway.  There is no need to keep this information at the ASP when it exists
at the SG.  The semantics are also different on a protocol variant basis--
stuff best left at the SG.

> By exchanging of ASP ACT/ACK the MGC would already be informed about the
> state of the SS7 network. 

> That would means no response method or Audit procedure are necessary.

Response methods are still necessary: they are part of the MTP/MTP-User
semantic.  It is audit procedures which are not necessary.

> And of course the response method is part of the MTP specification, but
> exactly there you will also find a possibility to exchange TFP/TFA before
> starting traffic. -MTP-restart-

You are confusing the SS7 MTP to MTP protocol and the MTP/MTP-User interface
semantic.  MTP-PAUSE/RESUME does not have the same semantic as TFP/TFA.

> If we consider advantage and disadvantage I can only see that by using
> Manfred's suggest the activation of an AS would be faster and more reliable
> as before.

You have not shown that at all.  Quite the reverse is true: the SGP will
send a lot of useless SNMM messages to ASP for AS in the inactive state
which are worthless.  This will degrade performance.  The responsive
methods are there so that only the required updates are provided (destinations
to which the MTP-User is actually and actively sending data).  Updating
the state of a bunch of routesets to which the MTP-User has a route but
to which that MTP-User never sends data is wasteful.

> (response method not necessary)!

Response method is always necessary.  It is part of the MTP/MTP-User
interface which M3UA is attempting to faithfully represent.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 07:39:50 -0500

Hi Brian,

Please see questions/comments below.

  Tolga

> Sent: Wednesday, October 17, 2001 2:31 AM
> To: sigtran
> Subject: Re: M3UA v9: ASPStates
> 
> 
> Andre,
> 
> Schmidt Andre wrote:                                      
[TOLGA] But the scope of RC is between an ASP and SG. So, the same SG can use different RC values for the same RK for different ASPs. I think, the scenario Andre is talking about is, that one uses loose configuration of ASPs (on SG it is not known, which ASP is serving which AS) and also one does not want to use dynamic-registeration of route keys. In such a case, SG can't know, to which RK a RC value sent by this ASP is corresponding.
> > And an important advantage is, that no user messages must 
> be discarded
> > (response method not necessary)!
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 07:56:08 -0500

Tolga,

> [TOLGA] But the scope of RC is between an ASP and SG. So, the same SG can
> use different RC values for the same RK for different ASPs. I think, the
> scenario Andre is talking about is, that one uses loose configuration of
> ASPs (on SG it is not known, which ASP is serving which AS) and also one
> does not want to use dynamic-registeration of route keys. In such a case, SG
> can't know, to which RK a RC value sent by this ASP is corresponding.

Let me spell it out:

I have two ASPs and 200 RK/RCs configured at one SG.

One ASP is active for RC 1.  The other active for RC 2.
Neither ASP has ever gone active for the other 198
statically configured RK/RCs since ASP UP.

Do I send SNMM data for these 198 RC's (ASs for which
both ASPs are ASP-INACTIVE) to both ASPs?

Certainly not.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 08:10:02 -0500

Hi Brian,

My comment was only related with the sentence "The SGP has the RC and RK provisioned, it just doesn't know which ASPs are going to register for or activate which RCs". It seems, that if one wants to use loose configuration of ASPs, one also needs to go for dynamic registeration.
For not sending unnecessary SSNM messages, I agree with you.

   Tolga

> Sent: Wednesday, October 17, 2001 8:56 AM
> To: sigtran
> Cc: [email-masked]

---

---

From: Angermayr Manfred <[email-masked]>
Date: Wed, 17 Oct 2001 15:53:11 +0200

Brian,
why should 200 RCs be configured at the SG, if no ASP wants to use them? To configure these RKs makes only sense, if the ASPs try to become active for these ASs. 
I agree with you, that it makes no sense to send SSNM messages to an ASP, if you do not know, for which AS the ASP will work. 
But as soon as you know for which AS the ASP will work, you can send your SSNM messages, even if the ASP is still  inactive for this AS (and then it makes sense to do so!). This connection between AS and ASP exists either after the registration procedure or it can be already statically configured. If you do not have this connection between AS and ASP you cannot say anything about the status of this ASP concerning this AS anyway.

Regards,
Manfred

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 17. Oktober 2001 14:56
An: sigtran
Cc: [email-masked]
Betreff: Re: M3UA v9: ASPStates

Tolga,

Let me spell it out:

Certainly not.

--brian

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

---

---

---

From: Kurt Kite <[email-masked]>
Date: Wed, 17 Oct 2001 09:57:02 -0500

One more try.

Assume this configuration:

                                STP
            +---+
        ----| X |-
 EO    /    +---+ \        MGC
+---+ /            \      +---+
| A |-              ------| B |
+---+ \      STP   -------+---+
       \    +---+ /
        ----| Y |-
            +---+

1. All links to A from X and Y are available. AS is active
   at B.
2. Link between A and X becomes unavailable. X sends DUNA
   to B. B MUST not forward DUNA to the User because A is
   still available from Y. The only way that I can see for B
   to know when all routes to A become unavailable is to either
   maintain the routes states per STP or to audit each STP each
   time a DUNA/SCON/DRST is received.

Am I the only one on the mailing list with this view?

/Kurt

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 10:25:44 -0500

Hi Kurt,

I also have the same opinion like you. But like you have said, there are two approaches and it is implementation dependent, although I favor keeping tha states on ASP approach more.
By the way, in that discussion, it also can be interesting to know, what is meant exactly by "user application"? I assume it is used to refer to the SS7 User Part user (e.g. call control application). But the user of MTP3 is SS7 User part (ISUP, SCCP ).
So, even if the user application is not there, MTP3 user will be there, so IMHO it is appropriate to receive and process SSNM messages.

     Tolga

> From: Kurt Kite [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 10:57 AM
> To: sigtran

---

---

From: "Antonio Roque-Alvarez (ECE)" <[email-masked]>
Date: Wed, 17 Oct 2001 18:03:48 +0200

Hi,

Kurt, your view is completely right.
Route status must be maintained in the AS.

Cheers,
Antonio

> Sent: Wednesday, October 17, 2001 4:57 PM
> To: sigtran
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: Kurt Kite <[email-masked]>
Date: Wed, 17 Oct 2001 11:23:41 -0500

Hi Tolga,

See below please.

/Kurt

> I also have the same opinion like you. But like you have said, there are two approaches and it is implementation dependent, although I favor keeping tha states on ASP approach more.

I also favor this approach.

> So, even if the user application is not there, MTP3 user will be there, so IMHO it is appropriate to receive and process SSNM messages.

I agree with this view as well. I just acknowledge Brian's point that the same result can be achieved by auditing.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 13:53:14 -0500

Angermayr,

Angermayr Manfred wrote:                                (Wed, 17 Oct 2001 15:53:11)
> Brian,
>
> why should 200 RCs be configured at the SG, if no ASP wants to use them?

The ASPs want to use them: just not today--tommorrow.

> To configure these RKs makes only sense, if the ASPs try to become active
> for these ASs.

They are statically configured RK/RC.  They are configured manually
in advance.  It makes perfect sense.

> I agree with you, that it makes no sense to send SSNM messages to an ASP, if
> you do not know, for which AS the ASP will work. 

The SG should never know for sure whether it was provisioned statically
in the fashion described.

> But as soon as you know for which AS the ASP will work, you can send your
> SSNM messages, even if the ASP is still  inactive for this AS (and then it
> makes sense to do so!).

It doesn't make sense to do so.  The SG does not need to be pyshic as
well as a fortune teller.

> This connection between AS and ASP exists either after the registration
> procedure or it can be already statically configured.  If you do not have
> this connection between AS and ASP you cannot say anything about the status
> of this ASP concerning this AS anyway.

There is no need to send SNMM to inactive ASP.  It violates ASPTM
procedures.  End of story.  We agreed to change this Sep 6.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 14:09:17 -0500

Kurt,

Form an association between A and B: you don't need STPs
in the IP domain.  See how much easier that is:

  EO                        MGC
 +---+                     +---+
 | A |---------------------| B |
 +---+                     +---+

--brian

Kurt Kite wrote:                                             (Wed, 17 Oct 2001 09:57:02)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 14:16:34 -0500

Antonio,

Only if one is foolish enough to attempt to recreate the
SS7 network in the IP domain.  The diagram has A and B
acting as full SEP in an SS7 overlay over the IP network.
They will need much more than just route status, they will
need full MTP (for M3UA) and SCCP (for SUA) state machines
and would likely need to pass conformance at Levels 3 and 4.

This is foolish.  We've been here before: if you want to
build a network this way, use M2PA.

--brian

Antonio Roque-Alvarez (ECE) wrote:                        (Wed, 17 Oct 2001 18:03:48)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 17 Oct 2001 12:53:27 -0700

I agree with Kurt and Antonio and the M3UA doc.  Greg & Javier - a note
to you is below also in the {{{}}}.  

When a node (SG or end-node, it doesn't matter) has more than one
path/route to a destination, it MUST maintain route status.  It is
stated in M3UA in several places:

section 1.3.2:  However, in the case where an ASP is connected to more
than one SG, the M3UA layer at an ASP should maintain the status of
configured SS7 destinations and route messages according to the
availability and congestion status of the routes to these destinations
via each SG.

section 1.3.2.3:  The M3UA layer at an ASP keeps the state of the routes
to remote SS7 destinations and may initiate an audit of the
availability, the restricted or the congested state of remote SS7
destinations.  

section 1.3.2.5:  As shown in Figure 1 an ASP may be connected to
multiple SGPs. In such a case a particular SS7 destination may be
reachable via more than one SGP and/or SG, i.e., via more than one
route. As MTP3 users only maintain status on a destination and not on a
route basis, the M3UA layer must maintain the status (availability,
restriction, and/or congestion of route to destination) of the
individual routes, derive the overall availability or congestion status
of the destination from the status of the individual routes, and inform
the MTP3 users of this derived status whenever it changes.

section 1.3.3:  In the example above, each signalling process (SGP, ASP
or IPSP) is the end point to more than one SCTP association, leading to
more than one other signalling processes.  To support this, a signalling
process must be able to support distribution of M3UA messages to many
simultaneous active associations.  This message distribution function is
based on the status of provisioned Routing Keys, the status of the
signalling routes to signalling points in the SS7 network, and the
redundancy model (active-standby, load sharing, broadcast, n+k) of the
remote signalling processes.

section 1.4.2.5:  Implementation Note: Where more than one route (or
SGP) is possible for routing to the SS7 network, the ASP could, for
example, maintain a dynamic table of available SGP routes for the SS7
destinations, taking into account the SS7 destination
availability/restricted/congestion status received from the SGP(s), the
availability status of the individual SGPs and configuration changes and
failover mechanisms. There is, however, no M3UA messaging to manage the
status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
{{{Greg & Javier -- Based on the other sections that I have provided,
the use of "could" in this note is incorrect and needs to be replaced
with SHOULD or MUST.}}}

section 1.4.3.3:  In the case where an ASP is connected to more than one
SGP, the M3UA layer must maintain the status of configured SS7
destinations and route messages according to
availability/congestion/restricted status of the routes to these SS7
destinations.

section 3.4.1:  If there is no alternate route via another SG, the
MTP3-User at the ASP is expected to stop traffic to the affected
destination via the SG as per the defined MTP3-User procedures.

section 4.5.2.1:  Implementation Note: To accomplish this, the M3UA
layer at an ASP maintains the status of routes via the SG(P), much like
an MTP3 layer maintains route-set status.

section 4.5.2.2:  At an ASP, upon receiving a Signalling Network
Management message from the remote M3UA Peer, the M3UA layer updates the
status of the affected route(s) via the originating SG and determines,
whether or not the overall availability or congestion status of the
effected destination(s) has changed. If so, the M3UA layer invokes the
appropriate primitive indications to the resident M3UA-Users.  Local
management is informed.

Therefore the only foolish one is the one that does not do it.

> Sent: Wednesday, October 17, 2001 2:17 PM
> To: sigtran
> [email-masked]
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 18:21:01 -0500

John,

John Schantz wrote:                                          (Wed, 17 Oct 2001 12:53:27)
> availability and congestion status of the routes to these destinations

This was already cited earlier in our discussion.  There is no other
sitation where an ASP needs to maintain routing information.  Although
I first identified this requirement and got it placed in the draft,
there are no RFC keywords in this statement.  Also, it might only be
true for the SG as STP case (not just multiple SGs).

This is because it is possible to have inter-SG communication that
performs this routing function at the SG and does not require the ASP
to reroute between SG on the basis of routeset status via SG/STPs.
The draft cnnnot require how the SG/STPs are configured, it just
needs to support conceivable configurations.  An ASP not needing to
support multiple SGs AS STPs that have no inter-SG communication need
not concern itself about maintaining any routing status.

> availability, the restricted or the congested state of remote SS7

No MUST there.  It is certainly not required for the ASP to keep
route state.

> the MTP3 users of this derived status whenever it changes.

That's just the multiple SG (as STP) case.  Nevertheless, no RFC keywords
here either.  ASPs are not required to support multiple SG (as STP) with
no inter-SG communication: they are permitted to.

> remote signalling processes.

The status of signalling routes and signalling points need only be
taken into consideration for multiple SGs (as STPs with no inter-SG
comm).  The ASP is not required to maintain or use this information:
it is permitted.

> the use of "could" in this note is incorrect and needs to be replaced

Sorry, I got it changed to "could, for example," a few versions back
because there is no need for the ASP to maintain any route status in
other than the multiple SG (as STP no inter-SG comm) case, and then
only reachability (availability, restriction), no need to track
congestion as was already discussed heavily.

Go back in the archives and you will see a lot of notes between Greg
and myself on these multiple SG cases.  It cannot be required to
support multiple SGs as STP with no inter-SG comm, but it is permitted.

> availability/congestion/restricted status of the routes to these SS7

Quirk of the s/SG/SGP/g from v6 to v7.  Still no RFC keywords here.

> destination via the SG as per the defined MTP3-User procedures.

Just the multiple SG case again.

> an MTP3 layer maintains route-set status.

We don't want status of routes on an SGP basis anymore: I thought that
you were the one most vocally objecting to that.  Again, no keywords.

> appropriate primitive indications to the resident M3UA-Users.  Local

Descriptive and and example only.  No keywords.

> Therefore the only foolish one is the one that does not do it.

There is absolutely no requirement (MUST, SHOULD) in the passages cited
to maintain route/destination status at an ASP.  There is no requirement
(MUST, SHOULD) even for the multiple SG case.

Section 1.3.2 says:

  The M3UA Layer at an ASP or IPSP provides the equivalent set of 
  primitives at its upper layer to the MTP3-Users as provided by the MTP 
  Level 3 to its local MTP3-Users at an SS7 SEP.  In this way, the ISUP 
  and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 
  services are offered remotely from an MTP3 Layer at an SGP, and not by 
  a local MTP3 layer.  The MTP3 layer at an SGP may also be unaware that 
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  its local users are actually remote user parts over M3UA.  In effect, 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^
  the M3UA extends access to the MTP3 layer services to a remote IP-based 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  application.  The M3UA layer does not itself provide the MTP3 services.  
  ^^^^^^^^^^^^
  However, in the case where an ASP is connected to more than one SG, 
  the M3UA layer at an ASP should maintain the status of configured SS7 
  destinations and route messages according to the availability and 
  congestion status of the routes to these destinations via each SG.

  The M3UA layer may also be used for point-to-point signalling between 
                                      ^^^^^^^^^^^^^^
  two IP Server Processes (IPSPs).  In this case, the M3UA layer provides 
  the same set of primitives and services at its upper layer as the MTP3. 
  However, in this case the expected MTP3 services are not offered 
  remotely from an SGP.  The MTP3 services are provided but the 
  procedures to support these services are a subset of the MTP3 
  procedures due to the simplified point-to-point nature of the IPSP to 
  IPSP relationship.

There has been no intention to force any MTP state machines or routing
functions at the ASP whatsoever.  The multiple SG case places its
some exceptional demands, but in all cases M3UA exports the MTP-User
interface from the SG to the ASP.  The SG cannot even rely on the fact
that the ASP maintains routing whatsoever and must treat the ASP as
a local user to do so.  The ASP can be a thin-client providing the
MTP/MTP-User interface to the AS and leaving all the MTP implementation
on the SG.  The IPSP case is point-to-point only and there is no need
for DUNA/DAVA/DRST messages at all in the IPSP case (SCON might still
be useful).

If someone wants to place unnecessary routing functions in the ASP,
go ahead.  There is no need to require an implementation to perform
any SS7 routing functions.  If the implementation wishes to adequately
support the multiple SG as STP case (and yes, they have to be STPs,
not just multiple SGs) then they might wish to add some minor routing
functions on a per-SG basis as indicated your earlier quotes.

You weren't around over a year ago, John, when I both proposed and
fought for changes to add DRST to the draft to permit multiple SG as
STP operation and help phrase many of the passages that you now quote.
I dare say that you would not have multiple SG as STP supported by
the draft if it weren't for these efforts.  At the time, it was a clear
concern of supporting the multiple SG as STP case that it would require
some MTP state machine and routing functionality to be introduced into
the ASP, where none is otherwise required.  You see, the passages that
you quote are the multiple SG as STP exceptions to the general rule that
the ASP don't need no MTP state machines or routing functions.

I suggest you look back in the archives.  This was discussed at great
length over M3UA's entire life cycle.  M3UA exports the MTP/MTP-User
interface from SG to ASP.  It provides the MTP/MTP-User interface to
an IPSP.

It concerns me that you, an intelligent person, have taken such a
mis-conception from what is clearly laid out in the architecture, and
had been the intention of the draft all along.  We must have failed
you somewhere to have allowed you to miss the point. ;)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 01:06:40 -0500

Kurt,

Kurt Kite wrote:                      (Wed, 17 Oct 2001 11:23:41)

> same result can be achieved by auditing.

The same result can be acheived without auditing by allowing the
MTP or SCCP on the SG to act responsively as defined in Q.704 and
Q.713.  The ASP need do nothing more than transport the "primitives".

This was the original intention for M3UA.  As little routing function
as possible was added to support mutliple SG as STP operation.  At
the time that we added multiple SG as STP support (DRST and the need
to keep some per-SG routing information at the ASP) the intention
was to completely minimize the routing information maintained at the
ASP.  For non-multipe-SG-as-STP the ASP need not maintain any routing
information whatsoever.  DAUD is never required for non-SG/STP
operation and is even not required in that case.  When the ASP does
not maintain routing information, there is no need to perform a
DAUD unless the implementation might like to get all of its responses
out of the way at the time that an MTP-User (AS) is initialized
amongst the ASPs.

This is not rocket science and has been the intention of the draft
from the start: the ASP is permitted to be as thin as possible and
just transport "primitives" to the user.  If MTP3 routing and state
machines are present at the ASP, who needs M3UA?  Use M2UA.

Greg, help me out here.  We discussed this in October of last year
(funny how these things come around again) and agreed to only
alter the "local view" of the ASP at the SG to accomodate the
multiple-SG-as-STP case only.  Also reference thread from last
January "M3UA-v5: MTP Restart vs Redundancy" where we added the
DRST in the first place to support this feature.

The concensus of the working group was to not generate an M3PA
(I suppose the equivalent of an IPSP with state machines) but to
allow some routing function at the ASP and message support only
for the SG/STP case.

Anything else would represent a significant departure from the last
year or so of work on M3UA.

--brian

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

---

---

From: Kurt Kite <[email-masked]>
Date: Thu, 18 Oct 2001 11:08:03 -0500

Brian,

I should have labeled my diagram clearly. X and Y are actually SG acting as STPs.

/Kurt

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 18 Oct 2001 13:53:13 -0700

I find it very sad that you are basing your whole argument on there
being no ALL CAPS words to make it a requirement.  The text is very
clear that it is a requirement and it would have been assumed to be a
requirement if this had been an ANSI or ITU standards document.

I assumed that the ALL CAPS were there just to get your attention.  I
assume that you would have us delete all the sentences that don't have
an ALL CAPS word since it is not a real sentence and you want us to
ignore these sentences.

> Sent: Wednesday, October 17, 2001 6:21 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 17:25:20 -0500

John,

The working group doesn't seem to have a problem clearly distinguishing
implementation suggestions from RFC keyword requirements in the draft.

It appears you do.

--brian

John Schantz wrote:                                          (Thu, 18 Oct 2001 13:53:13)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 17:37:19 -0500

Kurt,

Well, I see that Javier has suggested that IPSP with transfer function
be deferred to extension draft.  So currently, we have no STPs in the
IP domain.  Would you like to start working on the extension draft?

--brian

Kurt Kite wrote:                                             (Thu, 18 Oct 2001 11:08:03)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 19 Oct 2001 07:43:58 -0700

I don't have any problem now that I know that the working group has a
different set of rules than all the other standards groups do.

> Sent: Thursday, October 18, 2001 5:25 PM
> To: sigtran
> [email-masked]

---