Subject: RE: [Sigtran] RE: M3UA IG: section 3.15 reworked

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 18 Jun 2003 11:47:02 +0200

Samuel and Brian, 

As the archives say, the agreements were:
- Move from AS-INACTIVE to AS-ACTIVE after n ASPs get the ASP-ACTIVE state.
- Stay in AS-ACTIVE even though the number of ASPs that are in ASP-ACTIVE state is below n.

Apart from that I've not seen any consensus on removing it. Although I can find several mails from Brian saying "strike section 3.15"... But I may be wrong. In that case I would appreciate you point me to the exact item where this consensus were made.

Inside the current RFC there are clear divergences: While section 1.4.4.1 says that "n" is the minimum number of redundant ASPs to handle traffic, section 4.3.2 says that an AS can handle traffic with only one ASP in ASP-ACTIVE. These two views MUST be aligned...

Since the relation between n+k and the AS states is not included in the RFC, I would recommend to maintain this text (with the final agreement). 

Cheers // Javier.

> -----Original Message-----
> From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]]
> Sent: miércoles, 18 de junio de 2003 6:44
> To: Brian F. G. Bidulock
> Cc: Javier Pastor-Balbas (ECE); [email-masked]'; Ken Morneault
> (E-mail); Antonio Cañete (ECE)
> Subject: Re: [Sigtran] RE: M3UA IG: section 3.15 reworked
> 
> 
> 
> Pastor,
> 
>  I too believe that concensus was made to delete section 3.15 from IG 
>  as RFC is sufficient to explain n+k case.
> 
> --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. *******
> 
> On Tue, 17 Jun 2003, Brian F. G. Bidulock wrote:
> 
> > Javier,
> > 
> > I believe the concensus from the last long discussions was to
> > remove section 3.15.
> > 
> > --brian
> > 
> > Javier Pastor-Balbas (ECE) wrote:                           
>                         (Tue, 17 Jun 2003 16:51:16)
> > > This is the last version. There were still some 
> unfinished sentences and inconsistences in the first text I 
> sent. Now, they are fixed.
> > > 
> > > Cheers // Javier.
> > > 
> > > 
> > > --------- 
> > > Old text: (Section 4.3.2) 
> > > ---------
> > > 
> > > AS-DOWN: The Application Server is unavailable.  This 
> state implies 
> > > that all related ASPs are in the ASP-DOWN state for this 
> AS. Initially the AS will be in this state. An Application 
> Server is in the AS-DOWN state when it is removed from a 
> configuration.
> > > 
> > > AS-INACTIVE: The Application Server is available but no 
> application 
> > > traffic is active (i.e., one or more related ASPs are in the ASP-
> > > INACTIVE state, but none in the ASP-ACTIVE state).  The recovery 
> > > timer T(r) is not running or has expired. 
> > > 
> > > AS-ACTIVE: The Application Server is available and 
> application traffic is active.  This state implies that at 
> least one ASP is in the ASP-ACTIVE state.
> > > 
> > > AS-PENDING: An active ASP has transitioned to 
> ASP-INACTIVE or ASP-DOWN  and it was the last remaining 
> active ASP in the AS.  A recovery timer T(r) SHOULD be 
> started and all incoming signalling messages SHOULD be queued 
> by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, 
> the AS is moved to the AS-ACTIVE state and all the queued 
> messages will be sent to the ASP. 
> > > 
> > > If T(r) expires before an ASP becomes ASP-ACTIVE, and the 
> SGP has no 
> > > alternative, the SGP may stops queuing messages and discards all 
> > > previously queued messages. The AS will move to the 
> AS-INACTIVE state 
> > > if at least one ASP is in ASP-INACTIVE state, otherwise 
> it will move 
> > > to AS-DOWN state. 
> > > 
> > > Figure 5 shows an example AS state machine for the case where the 
> > > AS/ASP data is preconfigured.  For other cases where the AS/ASP 
> > > configuration data is created dynamically, there would be 
> differences 
> > > in the state machine, especially at creation of the AS.  
> > > 
> > >                  Figure 5: AS State Transition Diagram
> > > 
> > >      +----------+   one ASP trans to ACTIVE   +-------------+
> > >      |    AS-   |---------------------------->|     AS-   
>   |      
> > >      | INACTIVE |                             |   ACTIVE    |
> > >      |          |<---                         |             |
> > >      +----------+    \                        +-------------+
> > >         ^   |         \ Tr Expiry,                ^    |
> > >         |   |          \ at least one             |    |
> > >         |   |           \ ASP in ASP-INACTIVE     |    |
> > >         |   |            \                        |    |
> > >         |   |             \                       |    |
> > >         |   |              \                      |    |
> > > one ASP |   | all ASP       \            one ASP  |    | 
> Last ACTIVE
> > > trans   |   | trans to       \           trans to |    | 
> ASP trans to
> > > to      |   | ASP-DOWN        -------\   ASP-     |    | 
> ASP-INACTIVE
> > > ASP-    |   |                         \  ACTIVE   |    | 
> or ASP-DOWN
> > > INACTIVE|   |                          \          |    |  
> (start Tr)
> > >         |   |                           \         |    |
> > >         |   |                            \        |    |
> > >         |   v                             \       |    v         
> > >      +----------+                          \  +-------------+
> > >      |          |                           --|           
>   |      
> > >      | AS-DOWN  |                             | AS-PENDING  |
> > >      |          |                             |  (queueing) |
> > >      |          |<----------------------------|             |
> > >      +----------+    Tr Expiry and no ASP     +-------------+
> > >                      in ASP-INACTIVE state)   
> > > 
> > >  Tr = Recovery Timer
> > > 
> > > 
> > > 
> > > For example, where the AS/ASP configuration data is not 
> created until 
> > > Registration of the first ASP, the AS-INACTIVE state is entered 
> > > directly upon the first successful REG REQ from an ASP.  Another 
> > > example is where the AS/ASP configuration data is not 
> created until the first ASP successfully enters the 
> ASP-ACTIVE state.  In this case the AS-ACTIVE state is 
> entered directly.
> > > 
> > > 
> > > --------- 
> > > New text: (Section 4.3.2) 
> > > ---------
> > > 
> > > AS-DOWN: The Application Server is unavailable.  This 
> state implies that the number of ASPs being in ASP-INACTIVE 
> or ASP-ACTIVE is less than "n". Initially the AS will be in 
> this state. An Application Server is in the AS-DOWN state 
> when it is removed from a configuration.
> > > 
> > > AS-INACTIVE: The Application Server is available but no 
> application traffic is active. This implies that there are at 
> least n ASPs in either ASP-INACTIVE or ASP-ACTIVE but the 
> total number of ASPs in ASP-ACTIVE state has not reach n.  
> The recovery timer T(r) is not running or has expired. 
> > > 
> > > AS-ACTIVE: The Application Server is available and 
> application traffic is active. The AS moves to this state 
> after being in AS-INACTIVE and getting n ASPs in ASP-ACTIVE 
> state or, after reaching AS-ACTIVE and keeping one or more 
> ASPs in ASP-ACTIVE state. 
> > > 
> > > AS-PENDING: The last active ASP has transitioned from 
> ASP-ACTIVE to ASP-INACTIVE or ASP-DOWN.  A recovery timer 
> T(r) SHOULD be started and all incoming signalling messages 
> SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE 
> before T(r) expires, the AS is moved to the AS-ACTIVE state 
> and all the queued messages will be sent to the ASP. 
> > > 
> > > If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP 
> MAY stops queuing messages and discards all 
> > > previously queued messages. The AS will move to the 
> AS-INACTIVE state 
> > > if at least the number of ASPs in ASP-INACTIVE sum n, 
> otherwise it will move to AS-DOWN state. 
> > > 
> > > Figure 5 shows an example AS state machine for the case where the 
> > > AS/ASP data is preconfigured and an n+k redundancy model. 
> > > 
> > > 
> > >              Figure 5: AS State Transition Diagram
> > > 
> > >                    
> > >      +----------+          IA2AC              +-------------+
> > >      |    AS-   |---------------------------->|     AS-     |
> > >      | INACTIVE |                             |   ACTIVE    |
> > >      |          |<-----------                 |             |
> > >      +----------+            \                +-------------+
> > >         ^   |                 \                    ^   |
> > >         |   | IA2DN            \ PN2IA             |   | AC2PN
> > >         |   |                   \                  |   | 
> > >   DN2IA |   |                    \          PN2AC  |   | 
> > >         |   v                     \                |   v
> > >      +----------+                  \          +-------------+
> > >      |          |                   ----------|             |
> > >      | AS-DOWN  |                             | AS-PENDING  |
> > >      |          |                  PN2DN      |  (queueing) |
> > >      |          |<----------------------------|             |
> > >      +----------+                             +-------------+
> > > 
> > > 
> > > 
> > > DN2IA: One ASP moves to ASP-INACTIVE causing that n ASPs 
> are in either ASP-ACTIVE or ASP-INACTIVE states.
> > > 
> > > IA2DN: One ASP moves to ASP-DOWN causing that the number 
> of ASPs in either ASP-ACTIVE or ASP-INACTIVE drops below n.
> > > 
> > > IA2AC: one ASP moves to ASP-ACTIVE, causing number of 
> ASPs in the ASP-ACTIVE state to be n.
> > > 
> > > AC2PN: the last ASP in ASP-ACTIVE state moves to 
> ASP-INACTIVE or ASP-DOWN states, causing the number of ASPs 
> in ASP-ACTIVE drop below 1.
> > > 
> > > PN2AC: One ASP moves to ASP-ACTIVE.
> > > 
> > > PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE.
> > > 
> > > PN2DN: T(r) Expiry, the number of ASPs in ASP-INACTIVE 
> state is less than n.
> > > 
> > > As "n" ASPs are needed to handle the maximum engineered 
> load of the AS, an AS becomes AS-ACTIVE right after n ASPs 
> reach the ASP-ACTIVE state during the start-up phase. Once 
> the traffic is flowing, an AS keeps the AS-ACTIVE state till 
> the last ASP turns to another state different to ASP-ACTIVE, 
> avoiding unnecessary traffic disturbances as long as there 
> are ASPs available, in the assumption that the AS will not 
> always be exposed to the maximum load. 
> > > 
> > > There are other cases where the AS/ASP configuration data 
> is created dynamically. In those cases there would be 
> differences in the state machine, especially at creation of 
> the AS. For example, where the AS/ASP configuration data is 
> not created until Registration of the first ASP, the 
> AS-INACTIVE state is entered directly upon the nth successful 
> REG REQ from an ASP belonging to that AS.  Another example is 
> where the AS/ASP configuration data is not created until the 
> nth ASP successfully enters the ASP-ACTIVE state.  In this 
> latter case the AS-ACTIVE state is entered directly.
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > -- 
> > 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: Wed, 18 Jun 2003 04:26:39 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                                                   (Wed, 18 Jun 2003 11:47:02)
> Apart from that I've not seen any consensus on removing it. Although I can
> find several mails from Brian saying "strike section 3.15"... But I may be
> wrong. In that case I would appreciate you point me to the exact item where
> this consensus were made.

Everyone agreed except for Tolga.

> 
> Inside the current RFC there are clear divergences: While section 1.4.4.1
> says that "n" is the minimum number of redundant ASPs to handle traffic,
> section 4.3.2 says that an AS can handle traffic with only one ASP in
> ASP-ACTIVE. These two views MUST be aligned...

This was already described repeatedly in the previous mails and is clear
in the RFC.

Where is the need for text changes?

> 
> Since the relation between n+k and the AS states is not included in the RFC,
> I would recommend to maintain this text (with the final agreement). 

I disagree with alterations to the text in the RFC.  No need has been
demonstrated for any alteration.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 18 Jun 2003 03:58:27 -0700 (PDT)

Please see comments below....
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
>                                (Wed, 18 Jun 2003
> 11:47:02)
[TOLGA]It is clear that an AS, which is not ACTIVE,
SHOULD NOT send/receive application traffic. The only
way to achieve this is to harmonize state change of AS
on ASPs/SGPs. RFC fails to address this for n>1
because it is written always as n=1 in mind. IG
corrects this. 

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 18 Jun 2003 06:10:45 -0500 (CDT)

Pastor,
 
 I could not exactly locate the email referring to remove section
3.15 from IG.But following things i could recollect

1. 'n' is mantatory at start case
2. 'n' is # of ASPs to handle the maximum engineered load
3. When # of ASPs < n (where n > 0),AS state will be still AS-ACTIV
   but SGP will direct all traffic to the ACTIVE ASP(this is not a
   start case).All that SGP needs
   is change in the following internal table

   When Both ASPs-ACTIVE
   ---------------------
   ASP1 -- SLS1
   ASP2 -- SLS2

   When ASP1 goes DOWN
   -------------------
   ASP2 -- SLS1 + SLS2

--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: Wed, 18 Jun 2003 12:09:06 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 18 Jun 2003 03:58:27)
> because it is written always as n=1 in mind. IG

I disagree, the wording "at least one" has 'n' in mind.

It's just not the 'n' you wanted.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Jun 2003 12:12:03 -0600

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Wed, 18 Jun 2003 06:10:45)
> 1. 'n' is mantatory at start case

'n' is not mandatory in the start case.  The ASPs must coordinate 'n'
amoungst themselves.  The SGP can start traffic when the first ASP starts
or wait until 'n', however, it withholds NTFT(AS-ACTIVE) until 'n' in
that case.  This is what the RFC already says.  There is no problem with
it.  Can you see any problem?  (Tolga could not point to one.)

--brian

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