Subject: RE: [Sigtran] Re: M3UA Notify message

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 26 Jun 2003 10:10:30 +0200

Brian, 

More comments on yours....

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: jueves, 26 de junio de 2003 9:44
> To: Javier Pastor-Balbas (ECE)
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] Re: M3UA Notify message
> 
> 
> Javier,
> 
> Your proposal for 3.15 is still unacceptable.
> 
> Please see comments below...
> 
> Javier Pastor-Balbas (ECE) wrote:                             
>                       (Thu, 26 Jun 2003 09:12:20)
> > Brian, 
> > 
> > See my comments inline...
> > 
> > Cheers // Javier.
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: martes, 24 de junio de 2003 23:25
> > > To: Tolga Asveren
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] Re: M3UA Notify message
> > > 
> > > 
> > > Tolga,
> > > 
> > > Tolga Asveren wrote:                                          
> > >                        (Tue, 24 Jun 2003 13:54:50)
> > > > Brian,
> > > > (some more repeating of my ideas about this topic ;-)
> > > > )
> > > > --- "Brian F. G. Bidulock" <[email-masked]>
> > > > wrote:
> > > > > Tolga,
> > > > > 
> > > > > The RFC permits an SG to wait until sufficient
> > > > > resources are active before directing traffic to
> > > > > the ASP as you describe.
> > > > > 
> > > > > There is no reason, however, to require the SG
> > > > > to wait.
> > > > [TOLGA]Basically, what you are describing is "Let SG
> > > > decide by itself, when to activate AS". In such a
> > > > case, there should be a mechanism for SG to tell about
> > > > this state change, which will make the ASPs to change
> > > > their AS state accordingly -IMO, NTFY, as decribed in
> > > > RFC can't be seen as serving this purpose, as it is
> > > > not mandatory that ASPs update AS state based on
> > > > that-. I also doubt, whether SG can dynamically decide
> > > > when to activate AS, while it does not receive traffic
> > > > for AS.
> > > 
> > > NTFY serves this purpose.  Whether your ASP
> > > relies on it or not is up to the ASP designer.
> > > You say your ASPs can coordinate 'n' without
> > > relying on NTFY, so there is obviously no need
> > > for any extra protocol to signal this.
> > > 
> > 
> > It can not be up to the ASP designer !! Upon the activation 
> of the first ASP the following scenario will happen:
> > - SG thinks that AS is in AS-ACTIVE when the first ASP gets 
> the ASP-ACTIVE state
> > - ASP in ASP-ACTIVE state remains itself in an AS with 
> AS-INACTIVE (less than n ASPs are ASP-ACTIVE and there is 
> ASP-coordination)
> > 
> > There is not a common network view !! This MUST be fixed.
> 
> The RFC does not say that the ASP considers itself in the
> AS-INACTIVE state until n ASPs are active.  Read again:
> 
>    For the n+k redundancy case, ASPs which are in that AS should
>    coordinate among themselves the number of active ASPs in 
> the AS, and
>    should start sending traffic only after n ASPs are active.
> 
> The ASP considers itself in the ASP-ACTIVE state for the AS
> (and may consider the AS active) as soon as it receives the
> ASP Active Ack.
> 
> The ASP may consider the AS active as soon as it receives an
> NTFY(AS-Active) regardless of whether it is ASP-INACTIVE for
> the AS.
> 
> What the ASPs do is not start sending traffic until 'n' are
> active.
> 
> > 
> > 
> > 
> > > > > 
> > > > > It appears to me that the RFC accomodates your
> > > > > view, but also accomodates other views (AS
> > > > > active on first ASP).  If your ASPs can indeed
> > > > > coordinate 'n' amoung themselves, then it is
> > > > > moot what the SG does.
> > > > [TOLGA] IMO it is not irrelevant what SG does, if ASPs
> > > > coordinate 'n' among themselves -not based on NTFY-.
> > > > In such a case, it might happen that SG switches AS
> > > > state to ACTIVE with less than n ACTIVE ASPs but ASPs
> > > > will still wait for n ASPs to become ACTIVE and will
> > > > have AS state INACTIVE. The result will be SG exposing
> > > > AS as available to SS7 network, while in fact it was
> > > > not ready on ASP side, this IMO shouldn't happen. 
> > > 
> > > Here's where your wrong.  Activating an AS and
> > > traffic from the SS7 network are not correlated.
> > > There is no requirement to direct traffic after
> > > AS-ACTIVE.  When the SG indicates SS7 network
> > > availability is a function of the NIF and there
> > > are no requirements in the RFC in this regard.
> > 
> > Read the description of the AS-INACTIVE state. No traffic 
> processing for the
> > ASPs belonging to that AS.
> 
> Read the AS-ACTIVE state description.  It does not
> say that the SG must direct any traffic.
> 
It says "no application traffic is active". So there must not be any application traffic with the AS, which correponds with AS-INACTIVE.

> DUNA(*) is a particular case in point.  Because an
> AS is AS-ACTIVE does not mean that traffic is
> directed at the ASPs.  So, I stand by my statement:
> "Activating an AS and traffic from the SS7 network
> are not correlated."
> 
> Also, the AS state at ASP and SG is not synchronized.  See
> the warnings regarding message loss in Section 4.3.4.3.

These are regarding the delay on reception of the ASPAC-ACK, that will be added to the total traffic loss in there exists a different perception of the AS state in the network. 
> 
> > 
> > > Also, even after the NIF decides to place the PC
> > > or UP as available, there will be some
> > > considerable time before traffic will start.
> > > Distant signalling points and user parts will
> > > have to time out on procedures before they will
> > > restart traffic.  If an SG chooses to do this on
> > > the first active ASP (getting a jump on restart
> > > and knowing that it will take some time for
> > > traffic to resume, and knowing that the APSs
> > > will coordinate 'n' amoungst themselves anyway)
> > > the is is allowed to do so by the RFC, but not
> > > by the IG 3.15 proposal.
> > > 
> > So you'll be happy if we include a SHOULD instead of MUST 
> for n ASPs in the
> > transition form AS-INACTIVE to AS-ACTIVE...
> 
> It has to stay as MAY, as indicated in the current RFC.
> SHOULD is unacceptable.
> 
There is no explicit "MAY" in the current RFC...

> > 
> > 
> > > > > 
> > > > > IG 3.15 attempts to force the optional procedure
> > > > > in the SG, of waiting until sufficient resources
> > > > > are active, to be a mandatory procedure.  (The
> > > > > changing of MAY to MUST that I have always
> > > > > disagreed with.)
> > > > > 
> > > > > What need is there to force your view on others
> > > > > when, as you say, your ASPs can coordinate that
> > > > > 'n' of them are active, anyway?
> > > > [TOLGA]IMO, it is important that AS states are
> > > > consistent on both sides(so the goal is not to put
> > > > restrictions).
> > > 
> > > It is not so important.  Procedures are in place
> > > to resynchronize state.  One of the most
> > > important ones is the Notify procedure.  The SG
> > > MUST notify ASPs of its perceived state for the
> > > AS.  It is not an option.  The ASP can rely on
> > > this because it is an absolute requirement.  (MUST)
> > > 
> > 
> > But also the ASP will syncronize with the rest and wait for 
> n ASPs in ASP-ACTIVE...
> > The ASP can and cannot rely on it. This is only advisory. 
> It is NOT either a MUST or a SHOULD to rely on NTFY.
> 
> It is a MUST that the SG sends Notify.  Therefore the ASP
> can rely on it.  If the ASP cannot rely on it, why else
> would it be a MUST to send it?

I meant "may or may not". There is nothing in the RFC saying that the ASP MUST take into account the NTFY or trigger any action from its reception. Although it is a good test that both network nodes have the same state understanding.
> 
> The MUST keyword is used where an action is required for
> interoperability.  The SG MUST send Notify, so the ASP
> can rely on it.  It is that simple.
> 
As I said it can rely, but it may not...

> If the ASP desginer chooses to ignore the Notifications
> that the SG is required to send, she does so at her own
> peril.
> 
> > 
> > > > Secondly, if SG does not see AS as ACTIVE, there
> > > > shouldn't be traffic directed for this AS to this SG.
> > > 
> > > The timing of traffic and AS activity is not
> > > correlated or specified.  This is an NIF
> > > function.  The SG cannot decide WHEN to resume
> > > traffic, it is the remote signalling point that
> > > decides WHEN to resume traffic.
> > > 
> > > By "direct traffic" the RFC means: do that NIF
> > > thing to allow remote signalling points to
> > > resume traffic at some time in the future.
> > > 
> > > > So, which traffic is SG supposed to withhold?
> > > 
> > > The SG does not withhold traffic, it withholds
> > > the NTFY)(AS Active) if it waits to do that NIF
> > > thing until it is confident that there are
> > > sufficient ASP resources active to handle some
> > > future load.  But this must remain optional.
> > > The SG must be permitted to do that NIF thing on
> > > the first active ASP (or 'm'th" or after a timeout) or
> > > whenever it deems necessary after the first
> > > active ASP.  And this cannot be mandated as 'n'.
> > > 
> > > > Initially SG should see AS as ACTIVE -before there was
> > > > any traffic-, and this IMO can be decided only based
> > > > on number of ACTIVE ASPs -where this number can be
> > > > also 1 of course-.
> > > 
> > > No. The SG can do that NIF thing in anticipation
> > > of 'n' ASPs being active because it has the
> > > knowledge that 'n' will become active because
> > > the ASPs SHOULD coordinate that 'n' are active.
> > > 
> > This is not stated in the RFC. 
> 
> That is why the SG is allowed to do so.  Because the
> RFC neither forbids nor recommends against it.
> 
Since the RFC does not state a word about it. It is an implementation choice and not a standard way of working.

> > 
> > > There is no problem with the existing RFC.
> > > 
> > > Mandating 'n' is unacceptable.
> > > 
> > RFC does it as per section 1.4.4.1
> 
> There are no requirements in section 1.4.4.1.
> 
There are not requirements, there are DEFINITIONS: what things are. These are the basis for the protocol explanation.

> > 
> > > I will ask you once more the question that you
> > > have neglected to answer:
> > > 
> > > What bad thing will happen if the SG activates
> > > (does that NIF thing) on the first ASP and the ASPs
> > > wait until 'n'?
> > > 
> > 
> > Answer:
> > - Lack of synchronization among the two parts: ASPs and SGPs
> 
> Lack of synchronization already (intentionally) exists in
> the protocol.  See the comments regarding message loss in
> 4.3.4.3, and particularly:
> 
>    At the ASP, the ASP Active Ack message received is not 
> acknowledged.
>    Layer Management is informed with an M-ASP_ACTIVE confirm 
> primitive.
>    It is possible for the ASP to receive Data message(s) 
> before the ASP
>    Active Ack message as the ASP Active Ack and Data messages 
> from an SG
>    or IPSP may be sent on different SCTP streams.  Message loss is
>    possible as the ASP does not consider itself in the 
> ASP-ACTIVE state
>    until reception of the ASP Active Ack message.
> 

This is due to the network latency, what is unavoidable. But not due to different state view !! The latter should be avoided.
> 
> > - Traffic Loss if the SS7 network start sending traffic 
> before "n" ASPs know the AS is ACTIVE
> 
> What traffic loss?  Give an example.

SS7 nodes start sending traffic to the AS and both the AS has not still "n" ASPs in ASP-ACTIVE and the SG buffer is full.

> 
> > 
> > Which is not tolerable in carrier-grade networks with 
> availability requirements of 99.9999%
> 
> Performance requirements are outside the scope of the RFC.
> 
> (M3UA cannot even meet MTP3 performance requirements with
> IETF recommended SCTP parameters, not M3UA proceedures.)

As you probably know although SCTP was first thought for signaling traffic, in its later steps it was consider to be general purpose. Hope you don't use such parameters for signaling traffic....  

> 
> > 
> > > Quite frankly there is no bad thing that will
> > > happen and therefore all interoperability needs
> > > are met by the existing RFC.
> > 
> > 
> > Your interpretation of the RFC seems to be biased since the RFC also
> > includes statements as 1.4.4.1, the AS-INACTIVE definition 
> or examples for
> > n>1. 
> 
> Section 1.4.4.1, quoted here for others, says:
> 
>    The failover model supports an "n+k" redundancy model, 
> where "n" ASPs
>    is the minimum number of redundant ASPs required to handle traffic
>    and "k" ASPs are available to take over for a failed or unavailable
>    ASP.
> 
> There are no requirements in this section whatsoever.  It is 
> introductory.

As I said before, they are definitions that set up the basis for the protocol.

> Also, we agreed by concensus that the "traffic" referred to here is
> "maximum engineered load".

Maximum engineered load is not peak load, it is the load you are expected to be able to offer 99.9999% of the time... And at least at the beginning you should get it before activate traffic.

Cheers // Javier.

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jun 2003 05:19:02 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                                                   (Thu, 26 Jun 2003 10:10:30)
> It says "no application traffic is active". So there must not be any
> application traffic with the AS, which correponds with AS-INACTIVE.
> 
> These are regarding the delay on reception of the ASPAC-ACK, that will be
> added to the total traffic loss in there exists a different perception of
> the AS state in the network. 

I still stand by my statement.

> There is no explicit "MAY" in the current RFC...

This MAY:

   An SGP or IPSP, upon reception of an ASP Active message for the first
   ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
   active ASP until it determines that there are sufficient resources to
   handle the expected load (e.g., until there are "n" ASPs in state
   ASP-ACTIVE in the AS).  In this case, the SGP or IPSP SHOULD withhold
   the Notify (AS-ACTIVE) until there are sufficient resources.

And this MAY:

   An SGP or IPSP, upon reception of an ASP Active message for the first
   ASP in a Broadcast AS, MAY choose not to direct traffic to a newly
   active ASP until it determines that there are sufficient resources to
   handle the expected load (e.g., until there are "n" ASPs in state
   ASP-ACTIVE in the AS).  In this case, the SGP or IPSP SHOULD withhold
   the Notify (AS-ACTIVE) until there are sufficient resources.

> I meant "may or may not". There is nothing in the RFC saying that the ASP
> MUST take into account the NTFY or trigger any action from its reception.
> Although it is a good test that both network nodes have the same state
> understanding.

So the ASP can rely on it.

> As I said it can rely, but it may not...

And ignore it at its own peril...

> and not a standard way of working.

But currently permitted.  Your proposal would remove this.
It is unacceptable for that and other reasons.

> There are not requirements, there are DEFINITIONS: what things are. These
> are the basis for the protocol explanation.

These are nor definitions.  They are simple statements.
Read 1.4.4.1 again.  Where is there a definition?

> This is due to the network latency, what is unavoidable. But not due to
> different state view !! The latter should be avoided.

It is a difference in state view: the SG views the ASP as
active for the AS because it has send ASP Active Ack, the
ASP does not view itself as active yet because it has not
yet received ASP Active Ack.

I don't see much difference between this and ASPs coordinating
that 'n' of them go active within a short interval.

> SS7 nodes start sending traffic to the AS and both the AS has not still "n"
> ASPs in ASP-ACTIVE and the SG buffer is full.

Where does it say that the ASP does not receive traffic when
it is active for the AS?  It says in the RFC that the ASP
will not send traffic, not that it will not receive it.

> As you probably know although SCTP was first thought for signaling traffic,
> in its later steps it was consider to be general purpose. Hope you don't use
> such parameters for signaling traffic....  

But that is what the SCTP applicability statement says, particularly
with regards to SIGTRAN, that the SCTP [RFC 2960] recommended
parameters are to be followed.  In particular, RTOs max's of 60 seconds
and RTO mins of 1 second.

Are you recommending that the RFC recommendations be violated?

> Maximum engineered load is not peak load, it is the load you are expected to
> be able to offer 99.9999% of the time... And at least at the beginning you
> should get it before activate traffic.

So wrong: we should be glad you have not engineered any networks.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 26 Jun 2003 04:48:59 -0700 (PDT)

Brian,

IMO, one of the key points is that assuming that an
ASP SHOULD rely on NTFY from SGP or not. If there is
such a need, this has to be in RFC/IG with a "SHOULD"
-like everything else necessary is there with a
"SHOULD" or "MUST". Otherwise one can fill the RFC
with "MAY"s and can argue "Well, it is implementors
responsibility to be clever enough to decide which of
those MAY should have been in fact a SHOULD".

I also don't see waiting for n ACTIVE ASPs as a
restriction. It is the same like not putting AS to
ACTIVE without an ACTIVE ASP for n=1 case. In my
opinion based on definition of AS-ACTIVE and
AS-INACTIVE states it is clear that if AS is not
ACTIVE, no application traffic should run to/from it.

IMO, there is also a correlation between AS state and
traffic destined to this AS from SS7 nodes. Without AS
is exposed as available, there won't be traffic for
this AS -or better said should not be-. The view of AS
as seen from SS7 nodes (PC reachability or user part
availability) should reflect the real situation IMO.

If your view is that the first ASPAC is the sign that
ASPs have coordinated n among themselves and in a very
short time, necessary number of ASPs is going to be
ACTIVE, then IMO there is no need to care about n on
SGP side. Just always switch to AS-ACTIVE with the
first ASPAC and leave the coordination totally to
ASPs.
I also don't think it is a good idea to give the
responsibility of a dynamic decision to activate AS to
SG, which is not aware of the load on ASPs and which
even does not receive traffic from SS7 nodes for it.

     Tolga
wrote:
>                                (Thu, 26 Jun 2003
> 10:10:30)

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jun 2003 09:18:45 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 26 Jun 2003 04:48:59)
> those MAY should have been in fact a SHOULD".

I am not saying that an ASP should rely on Notify.
I am saying that it can.  That is, the ASP can meet
the requirement that it SHOULD coordinate that 'n'
ASPs are active regardles of what the SG does, and
that the ASP can know when the SG activates the AS
to synchronize state as much as it cares to.

> restriction.

I do.

> It is the same like not putting AS to

There is no mechanism in SS7 to inform the SS7 network
that an AS (MTP-User) is active.  There is no UPA or UPT
message in MTP, just a UPU.

In the SS7 network every MTP-User can be exposed to
200-300% of its rated load.  The MTP-User is responsible
for user-part congestion avoidance and flow control.

> even does not receive traffic from SS7 nodes for it.

For startup of an MTP-User, the only traffic that can
be received is user part test traffic: e.g. UPT or CVT
for ISUP, or SST for SCCP.  If the ASP does not respond
to these messages, no user-part traffic will flow.

In addition, the MTP-User has congestion avoidance
procedures at its disposal: e.g. ACL in REL for ISUP and
SSC for SCCP.  Because an ASP can always be exposed to
200-300% of its rated load, the ASP had better appropriately
use these procedures.

Therefore, is is the AS that is responsible for starting
traffic flow from the SS7 network to the AS (by responding
to UPT/CVT or SST) and not the responsibility of the SG
at all.  The SG merely starts passing messages to and from
the AS so that the AS can determine respond to these user
part flow control and test messages of its own accord.

No bad thing can happen from the SG starting traffic on
the first active ASP because the only traffic started is
user-part test traffic.  It is the responsibility of the
ASP to respond to test traffic (after 'n' are active) and
restart the user part traffic flow from other users in
the SS7 network.

Therefore, the SG can always start traffic on the first ASP
as provided for in the RFC.

The proposal to require the SG to wait remains unacceptable.

--brian

> > 09:12:20)

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 26 Jun 2003 08:59:13 -0700 (PDT)

Brian,
wrote:
> 04:48:59)
[TOLGA]What is the reason to allow SG to decide
dynamically, when AS should be ACTIVE? And based on
which criteria -apart from number of ACTIVE ASPs-? In
fact, based on your arguments, I would expect that you
propose getting rid of concept of n and just saying
that it is ASPs responsibility when to send ASPAC,
based on current load and expected load and that to
decide for this is outside of the scope of M3UA.

[..snip..]
> message in MTP, just a UPU.
[TOLGA]I think it will be SG, which responds with a
UPU or not for received traffic (including UPT). So,
it might not respond with UPU, if it has AS state
ACTIVE, even if ASP has AS state INACTIVE.
IMO, each layer should do, what it is supposed to do,
without relying to some other mechanisms on upper
layers-for example generating or not generating is
MTP3 responsibility, so SG should do this correctly-.
Personally I prefer to reflect the state of AS
properly to SS7 nodes. For example, with the same
logic, one could argue that UPU is not necessary at
all, because we have SST and CVT. 

[..snip..] 
> as provided for in the RFC.
[TOLGA]What stands in IG does not disallow this, just
using n=1 will achieve this.
> > > > > > > > --- "Brian F. G. Bidulock"
> 
=== message truncated ===

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jun 2003 11:58:53 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 26 Jun 2003 08:59:13)
> ACTIVE, even if ASP has AS state INACTIVE.

Not responding with UPU does not activate traffic at
the remote peer.  For ISUP, a message must be received
from the ASP (UPA or CNF(97)) before traffic will be
started.  For, SCCP a message must be received from
the ASP (SSA) before traffic will be started.

So, you see, the ASP is responsible for starting
traffic from remote peers, other than UP test messages,
which, if not responded to, will NOT start user traffic.

There is still the concept of 'n', it is just that
the ASP is responsible for it, not the SG, as in the
RFC...

> MTP3 responsibility, so SG should do this correctly-.

User flow control and congestion control is explicitly
a responsibility of the MTP-User in the MTP specifications.
It is MTP that we are transporting with M3UA, and flow
control (starting user traffic) and congestion control
(throttling excess user traffic) is explicitly the
responsibility of the ASP.  As in the RFC...

> all, because we have SST and CVT. 

UPU is necessary for distinguishing between an
unequipped user (for which traffic must cease and
management be notified) and an unavailable user (for
which user test procedures begin).  To distinguish,
this message is issued by MTP.  Aside from that, 
UPT/UPA (and restarting user traffic) is the
responsibility of ISUP and  SST/SSA to SSN 0 (and
restarting subsystem traffic) is the responsibility
of SCCP.  These are the responsibilities of the MTP-User
in the MTP specifications.  They are the responsibility
of the ASP in the M3UA RFC, and a responsibility that
the ASP cannot avoid.  The MTP cannot send UPA/SSA for
the user part, even if it wanted to.

So, at the SG, there is no correlation between AS-ACTIVE
and the restart of the user traffic.  User traffic will
only restart some time after AS-ACTIVE, when the ASPs
decide amoungst themselves (E.G. WHEN 'N' OF THEM ARE
ACTIVE) that they should send UPA/SSA and restart
user traffic.

> using n=1 will achieve this.

The RFC permits it when 'n' is not one.

You can see from the above that AS-ACTIVE and 'n' has
no bearing on when the "traffic" mentioned in 1.4.4.1
is directed to the ASP.  The ASP decides this for itself
when it coordinates that 'n' are active.

No changes are needed to the AS state machin or the
RFC.  Nothing bad will happen.  IG. 3.15 is a waste of
time.  Stike it.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 26 Jun 2003 11:54:54 -0700 (PDT)

Brian,

To me any user part message (including ISUP/SCCP
management messages) is the same. So, that SG causes
SST to be sent by a peer, in fact where AS was not
ACTIVE on ASP side is also bad.

IMO, user part procedures should be irrelevant for
M3UA. We should try to mimic MTP3 as much as possible,
and when a user part is not avialable, MTP3 replies
with UPU for messages received for that user part.
There is a way to achieve consistency of AS states at
ASP and SGP sides and my personal opinion is to move
in that direction. Personally I fail to see a benefit
of not doing so -especially when n=1 is always
possible, for the behaviour you describe below n=1
should work fine as far as I can see (that ASPs reply
with SSA/UPA only after n of them are ACTIVE-).

In fact, as far as I can understand, you are proposing
to get rid of n, althoug you say it is still there but
just for ASP. I think, M3UA document should not speak
about procedures/requirements of user parts on ASP
side but just of M3UA stack on ASP side. In your way
of operation, you shift the concept of n up to the
user parts -so IMO this makes it disappear in the
context of M3UA-.

     Tolga

wrote:
> 08:59:13)
> > >                                 (Thu, 26 Jun
> 2003
> > > > IMO, one of the key points is that assuming
> that
> > > an
> > > > ASP SHOULD rely on NTFY from SGP or not. If
> there
> > > is
> > > > responsibility to be clever enough to decide
> which
> > > of
> > > that an AS (MTP-User) is active.  There is no
> UPA or
> > > UPT
> > > Therefore, the SG can always start traffic on
> the
> > > first ASP
> <[email-masked]>
> > > > >                                (Thu, 26 Jun

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jun 2003 13:01:23 -0600

Tolga,

I am not proposing anything.  I wish to stick with
the RFC as it stands.  You and Javier are prosposing
a change.  One that is unnecessary and one that I
disagree with.

--brian

Tolga Asveren wrote:                                                                 (Thu, 26 Jun 2003 11:54:54)

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