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

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

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.

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

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

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

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

> There is no problem with the existing RFC.
> 
> Mandating 'n' is unacceptable.
> 
RFC does it as per section 1.4.4.1

> 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
- Traffic Loss if the SS7 network start sending traffic before "n" ASPs know the AS is ACTIVE

Which is not tolerable in carrier-grade networks with availability requirements of 99.9999%

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

> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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

---

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

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

> ASPs belonging to that AS.

Read the AS-ACTIVE state description.  It does not
say that the SG must direct any traffic.

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.

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

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

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.

If the ASP desginer chooses to ignore the Notifications
that the SG is required to send, she does so at her own
peril.

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

> RFC does it as per section 1.4.4.1

There are no requirements in section 1.4.4.1.

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

> - Traffic Loss if the SS7 network start sending traffic before "n" ASPs know the AS is ACTIVE

What traffic loss?  Give an example.

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

> 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.
Also, we agreed by concensus that the "traffic" referred to here is
"maximum engineered load".

--brian

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 26 Jun 2003 04:37:38 -0500 (CDT)

My understanding is, 'n' is just an operator configurable parameter.
When n=1, it sounds to activate an AS as soon as at least one ASP goes
to ACTIVE state, when n=2 , it sounds to activate an AS as soon as 
minimum two ASPs go to ACTIVE state.I think the concept is followed in
the conventional SS7 network, in order to make a particular route as 
unrestricted the operator has an option to describe 'how many links
to be in active state', this is absolutely a configurable parameter,
in order to make a particular route as unrestricted if '# of links
to be in active state' says 3, it is a wise idea to make that route as
unrestricted after 3 links go to active state.  In some very rare 
cases originating node may be sending a warning ss7 message to 
destination node with single active link to make that route as 
unrestricted.

Keeping section 3.15 holds good.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

---

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

Samuel,

The SS7 network does not work the way you describe.  There is no concept
in SS7 of the "minimum number of links" before a route goes active.
A route is active with the first signalling link.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 26 Jun 2003 04:37:38)

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 26 Jun 2003 06:23:40 -0500 (CDT)

Brian,
  Again i am saying it is left to the decision of operator.

  When node A is sending messages to node B, in this case, if operator 
  decides one link is not sufficient to carry messages from node A to
  node B, operator can say 'min 2 links' are required between node
  A and node B.Logically it sounds good also.
 
 --Sam

---

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

Samuel,

What you describe is not provided for in the standards and is
thus, forbidden.

Point to where you believe that this is explicitly permitted
in the MTP standards.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 26 Jun 2003 06:23:40)

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