Subject: [Sigtran] M3UA IG v04

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 3 Jul 2003 11:45:57 +0200

Hi guys,

We tried to submit the next IG version before the deadline, but I got confused since I thought it ended at 12:00 instead of 9:00. So the server bounced it. I'll submit the doc again after the IETF meeting. In the meantime you can find it at:

http://standards.ericsson.net/javier/draft-ietf-sigtran-m3ua-implementors-guide-04.txt

We've tried to include all the different opinions in here. Although it seems that the case of waiting till n ASPs is the preferred one, we have included the new possibility of a smooth start for those of you who want to activate the AS when the first ASP gets to ACTIVE. At the end it will be the operator's decission how to proceed during the activation phase. Hopefully everyone agrees on this wording...

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: martes, 01 de julio de 2003 20:18
> To: Samuel Dur D. Jeyaseelan
> Cc: [email-masked]
> Subject: Re: [Sigtran] Re:n+k issue
> 
> 
> Samuel,
> 
> Perhaps you could answer my questions below first.  Please be
> specific.
> 
> --brian
> 
> Samuel Dur D. Jeyaseelan wrote:                               
>                       (Tue, 01 Jul 2003 06:09:34)
> > 
> > Brian,
> > 
> >   Can you bit elaborate your n=256 example (ANSI-SLS) with 
> real-time 
> >   scenario?(please write to the point)
> > 
> > --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, 1 Jul 2003, Brian F. G. Bidulock wrote:
> > 
> > > Samuel,
> > > 
> > > Samuel Dur D. Jeyaseelan wrote:                      
> (Mon, 30 Jun 2003 09:44:01)
> > > > 
> > > > Brian,
> > > > 
> > > > On Sat, 28 Jun 2003, Brian F. G. Bidulock wrote:
> > > > 
> > > > > Samuel,
> > > > > 
> > > > > I should point out that the proposal to require that 
> the SG wait for 'n' to
> > > > > start traffic does not have much merit.
> > > > > 
> > > > > Example: n=256, k=1
> > > > > 
> > > > > 2 ASPs fail, permanently and need to be manually replaced.
> > > > > 
> > > > > A temporary network failure causes SCTP associations 
> to be lost to the
> > > > > remaining 255 ASPs.  They move to the ASP down state 
> and immediately
> > > > > re-establish SCTP associations and move to the 
> ASP-Active state.  Because the
> > > > > number of ASPs is < n, the SG will not restart 
> traffic for some time.
> > > > 
> > > > Your example leads to the following figure.
> > > > 
> > > >          SG1                            AS1
> > > >      
> > > >  SS7 MSG +------+----------------------- ASP (1)
> > > > ---------| SGP1 |----------------------- ASP (2)
> > > >          |      |----------------------- ....
> > > >          +------+----------------------- ASP (256)
> > > >             |
> > > >             | 
> > > >             +---------------------------ASP(k)
> > > > 
> > > > 1. First of all craft will not configure 1 ASP as 
> backup for 256 Active
> > > >    ASPs, if he does, it means to be a poor network 
> configuration.
> > > 
> > > Well, first of all, craft does not normally choose the 
> number of ASPs used for
> > > backup, engineering does.  Second, k=1 is more than 
> adequate for n=256 where
> > > the ASPs are reasonably reliable and have a short 
> replacement time.
> > > 
> > > Regardless, I followed with the same example with n=2 and k=1.
> > > 
> > > > 
> > > > 2. Consider ASP as an MGC, your example leads to 256 
> MGCs and they are 
> > > >    controlled by a single SGP.A good network will have 
> multiple SGPs to
> > > >    share the POTENTIAL traffic across ASPs.
> > > 
> > > You seem to misunderstand the concept of redundancy in 
> M3UA: there are not
> > > multiple SGPs or ASPs because of traffic load.  It is 
> easy enough to handle
> > > the traffic of a small to medium sized country through a 
> single processor.
> > > 
> > > Also, you seem to misunderstand that an SGP and an ASP 
> are not processors.
> > > They are processes.  One host processor could have many 
> (even 256) ASPs or
> > > SGPs (or both for that matter).
> > > 
> > > > 
> > > > 3. BASIC INTENTION OF 'n+k' is,just to make sure that 
> incoming messages
> > > >    ARE EFFICIENTLY TRANSMITTED TO DESTINATION ASPs WITH 
> THE HELP OF
> > > >    MINIMUM NUMBER OF ASSOCIATIONS.
> > > 
> > > No.  The intention of 'n+k' is to provide one of the more 
> recently accepted
> > > models for reliability using redundancy (n = m+1, k=0 
> being the typical system
> > > deployed in the field today, m usually being greater than 
> 2).  Up until
> > > recently, only 2m (or m+m) systems were considered 
> carrier class.  Some
> > > systems were 4m (with 3 out of 4 vote).
> > > 
> > > You should take some time to look at redundancy and 
> reliability requirements
> > > for carrier grade systems for an understanding of how to 
> calculate and provide
> > > the reliability requirements expected by carriers.  There 
> are good standards
> > > written on the topic.  See the Telcordia NEBS and 
> reliability specs, for
> > > example.  If you have an RBOC RFP handy, take a look at 
> the hardware and
> > > software reliability requirements sections or talk to the 
> engineer in your
> > > company responsible for answering those sections.
> > > 
> > > > 
> > > >    Say for example
> > > > 
> > > >    Inefficient configuration -just an example
> > > >    ------------------------------------------
> > > >   
> > > >             SLS         DEST
> > > >             =================
> > > >              0           ASP1
> > > >              1           ASP1
> > > >              2           ASP1
> > > >              3           ASP1
> > > >              4           ASP1
> > > >              5           ASP1
> > > >              6           ASP1
> > > >              .            .
> > > >              .            .
> > > >              15          ASP1
> > > >              
> > > >              
> > > >                SG                            AS1
> > > > sls(0,1..15 )+----+  sls(0,1..15)         +------+
> > > > -------------|SGP1|-----------------------| ASP1 |
> > > >              |    |              ASSOC-1  +------+
> > > >              +----+                     
> > > > 
> > > >                       Fig - 1
> > > > 
> > > > In this figure, all incoming messages are transmitted 
> over ASSOC-1 towards
> > > > ASP1.Here there are two potential problems 
> > > > 
> > > >        1. Total incoming traffic is dependent on a single ASP
> > > >        2. ASP1 is always overloaded, messages are 
> processed one by one
> > > >           from the transmission buffer which ultimately 
> introduces time
> > > >           delay(example last arrived msg will be 
> processed at the end).
> > > 
> > > The above was not in my examples.  My examples had n > 1.
> > > 
> > > > 
> > > > 
> > > > Efficient configuration
> > > > -----------------------  
> > > > 
> > > >              SLS         DEST
> > > >             =================
> > > >              0           ASP1
> > > >              1           ASP1
> > > >              2           ASP1
> > > >              3           ASP1
> > > >              4           ASP1
> > > >              5           ASP1
> > > >              6           ASP1
> > > >              7           ASP1
> > > >              8           ASP2
> > > >              9           ASP2
> > > >              .            .
> > > >              .            .
> > > >              15          ASP2
> > > > 
> > > >                
> > > >                        
> > > >                        
> > > >               SG                             AS1
> > > > sls(0,1..15 )+----+   sls(0,1,..7)ASSOC-1 +------+
> > > > -------------|SGP1|-----------------------| ASP1 |
> > > >              |    |--------+              +------+
> > > >              +----+        | sls(8,9..15) +------+
> > > >                            +--------------| ASP2 |
> > > >                                  ASSOC-2  +------+
> > > >                         
> > > >                    fig - 2
> > > > 
> > > > In this example incoming traffic is distributed between 
> ASP1 and ASP2.
> > > > 
> > > > IN ORDER TO HANDLE THE HEAVY INCOMING TRAFFIC, SGP1 
> NEEDS MINIMUM OF
> > > > 2 ACTIVE ASPs BY SETTING n=2.
> > > 
> > > Do they not comply to SS7 ISUP/SCCP flow and congestion 
> controls?  Are they
> > > running at full capacity in this arrangement?  Are these 
> your ASPs?  Do you
> > > design your systems this way?
> > > 
> > > Take a look at the reliability engineering.  If either of 
> these ASPs is
> > > handling its maximum rated capacity, it will have to be 
> reliable to .99999
> > > This is because, if one ASP fails, 50% of the system has 
> failed.  A 50% system
> > > failure is deemed a "system" failure rather than a 
> "component" failure in
> > > reliability engineering for carrier grade systems.  
> Considering proscribed
> > > replacement times on the ASP, this would be difficult to 
> achieve unless both
> > > ASPs were hardware fault tolerant platforms.
> > > 
> > > Nevertheless, the RFC defines ASPs as a process, not a 
> processor.  There is
> > > nothing restricting the two ASPs in your diagram from 
> being processes on the
> > > same processor.  In that case, when ASP2 is down, ASP1 
> has double the
> > > processing capacity as it had before.
> > > 
> > > You certainly cannot make statements as you have made here without
> > > presupposing an implementation architecture outside the 
> scope of the standard.
> > > 
> > > Besides, the RFC permits you to configure your SGP (and 
> why do you only have
> > > one of them?) so that it waits for 'n' ASPs to become 
> active.  You MAY do
> > > this.  Just don't require everybody else to follow your 
> approach.  (Actually,
> > > if the above is your approach, don't require anyone else 
> to follow it.)
> > > 
> > > Several other points: ANSI T1.111.4/2000 SLS values are 
> 8-bits.  That means
> > > there are 256 SLS values (gee, I had 256 ASPs in my example).
> > > 
> > > For another thing, sequenced traffic flows are not only 
> based on SLS.  In an
> > > ITU-T network, each remote signalling point has 16 
> independent traffic flows
> > > for each AS.  The traffic flows from each remote 
> signalling point is
> > > independent from the traffic flows of other remote 
> signalling points.
> > > Therefore, if there are 400 remote signalling points, 
> there will be 6400
> > > independent traffic flows that the SG can use for 
> distribution of AS traffic
> > > for one AS over as many as 6400 ASPs without risking 
> mis-sequencing of
> > > messages.  For an ANSI T1.111.4/2000 network using 8-bit 
> SLS values with 400
> > > remote signalling points, there would be 102400 
> independent traffic flows to
> > > the AS that the SG can use to distribute traffic to one 
> AS over as many as
> > > 102400 ASPs without risking message mis-sequencing.
> > > 
> > > > 
> > > > 
> > > > Your example with n=256 is completely a wrong 
> interpretaion of 'n+k'
> > > > redundancy case.
> > > 
> > > Quite the opposite, you clearly misunderstand redundancy 
> and reliability in
> > > carrier grade systems and obviously have little 
> experience with them.
> > > 
> > > Here's a little primer for you:
> > > 
> > > Carrier grade systems were originally designed as 
> hot-standby, fully redundant
> > > systems.  For every processor actively handling traffic, 
> there was a hot
> > > standby processor also actively handling the same 
> traffic.  This typically
> > > required special bus arrangements whereby the I/O bus of 
> one processor was
> > > actively controlling peripheral devices, while the hot 
> standby processor was
> > > issuing I/O bus output that was not terminated to the I/O 
> bus.  The bus also
> > > normally performed a comparison of the outputs from the 
> active side and the
> > > outputs from the inactive side.  Peripheral components, 
> such as switch fabric
> > > were also fully redundant (duplicated).  Switching 
> fabrics are separated into
> > > an A-plane and a B-plane in much the same fashion as the 
> SPCS front-end I/O
> > > bus.
> > > 
> > > Note that active/standby in M3UA does not address the 
> above model.  2+0
> > > broadcast does.
> > > 
> > > The problem with such a systems was what we used to call 
> the "kill your
> > > sister" syndrome.  A failure on the inactive side only 
> detectable to the I/O
> > > bus could cause a switch from the active to inactive 
> side, resulting in the
> > > switch running on the erroneous inactive side.  We called 
> it the "kill your
> > > sister" syndrome because it is not so surprising that the 
> psychotic sister
> > > (erred inactive side) kills the sane sister (correct active side).
> > > 
> > > Primarily to avoid the "kill your sister" syndrome, some 
> switches were
> > > designed with 3 or 4 processors on an cross-checking I/O 
> bus pair.  In that
> > > case, it would take a 2 out of 3 or 3 out of 4 vote to 
> shift from the active
> > > processor.  These systems were far less susceptible to 
> inactive plane errors
> > > that were only detected at the I/O bus.
> > > 
> > > Note that the only M3UA model that address the above is 
> the 3+0 or 4+0
> > > broadcast model.
> > > 
> > > When the use of general purpose computing platforms for 
> telecommunications
> > > systems started to become popular, there were several 
> models that emerged.
> > > 
> > > First was taking two big iron UNIX hosts and running them 
> in active/standby.
> > > In this scenario, one UNIX host would be actively 
> handling traffic and the
> > > other would be warm standby.  By "warm" standby, it means 
> that the device was
> > > powered and was synchronizing state on a checkpoint 
> interval or monitoring the
> > > health of the active hosts with heartbeats.  Shared 
> memory, shared DASD or
> > > message passing are the most common mechanisms of 
> redundancy.  These systems
> > > are considered "highly available" systems rather than the 
> "fault tolerant"
> > > systems used in telecommunications above.  An increased 
> level of reliability
> > > is often achieved by using hardware fault tolerant 
> multiple processor hosts.
> > > 
> > > In M3UA, the active/standby model addresses these 
> systems.  Although M3UA
> > > provides for a '1+k' model, k is invariably 1.
> > > 
> > > The major difficulties with these systems are: a) 
> switchover latency between
> > > systems; b) loss of state during switchover; and c) 
> scalability.  Switchover
> > > latency is normally improved by decreasing heartbeat 
> intervals.  State
> > > synchronization is normally improved by decreasing the 
> process checkpoint
> > > interval.  These reductions typically increase cost and 
> they are normally
> > > chosen to minimize a cost/performance/reliability metric. 
>  Scalability was
> > > typically performed by installing larger more powerful 
> hosts with increased
> > > demand.  This was not good, because larger processors 
> tended to have poorer
> > > cost/performance ratios that smaller processors.
> > > 
> > > Later it was determined that the cost of a complete 
> redundant host that was
> > > wasting CPU cycles while inactive could be avoided while 
> addressing the
> > > deficiencies of the paired host approach above.  To increase state
> > > synchronization, state could be spread over a number of 
> hosts.  If there were
> > > 'm' hosts, the failure of one host could at worst affect 
> a proportion, 1/m, of
> > > the state.  Therefore state synchronization would improve 
> as m increased.  To
> > > distribute the state, traffic load would be shared over 
> the m hosts according
> > > to state.  This also served the needs of scalability and 
> provided for closer
> > > to linear cost scalability, because the number of hosts, 
> m, could be increased
> > > while holding the cost/performance ratio of the hosts 
> constant.  The costs of
> > > redundancy could also be reduced over the fully redundant 
> systems described
> > > above, because redundancy could be achieved using 'm+1' 
> processors, where 'm'
> > > processors were required to handle the maximum engineered 
> load.  For systems
> > > as small as 'm=2' hosts with equivalent reliability to 
> that normally
> > > experienced in the '1+1' active/standby scenario above, 
> system reliability
> > > figures could be maintained with less redundancy cost.  
> It is important to
> > > note, that in these systems, all 'm+1' hosts are active 
> and handling only a
> > > proportion m/(m+1) of their rated capacity.  It is very 
> seldom that the rated
> > > capacity was more that 2/3 of the maximum short-term capacity.
> > > 
> > > These systems do not solve the heartbeat interval problem of the
> > > active/standby paired hosts system above.  Typically what 
> these systems use is
> > > more sophisticated watchdog approaches rather than 
> passing heartbeat messages
> > > between processes on the active and standby hosts.  
> Memory sharing, DASD
> > > sharing, message passing, reliable broadcast, voting, and 
> a plethora of
> > > reliable distributed systems techniques have been 
> developed that are useful in
> > > these systems.
> > > 
> > > Adoption of these latter systems changed the requirement 
> from "duplicated"
> > > systems to systems with no "single point of failure".
> > > 
> > > Now, the 'n+k' load-sharing and broadcast model was 
> intended to address these
> > > systems.  Where 'n == m' in the description above.  That 
> is why we agreed that
> > > n is the maximum engineered load.  Because that is what 
> 'm' is.  The k is the
> > > 1 in the description above, generalized.
> > > 
> > > First off, you must understand that it is not the 
> intention of the model to
> > > have 'n' ASPs active and 'k' inactive unless 'n=1, k=1'.  
> This is described in
> > > section 1.4.4.1:
> > > 
> > >   A "1+1" active/standby redundancy is a subset of this model.
> > > 
> > > Also no redundancy is possible:
> > > 
> > >   A simplex "1+0" model is also supported as a subset, 
> with no ASP redundancy.
> > > 
> > > (The term "simplex" come from the telephone switches 
> described above where the
> > > inactive side is taken off-line.  Such a situation is 
> described as running the
> > > switch "simplex".)
> > > 
> > > The 'n+k' model is to address the 'm+1' distributed 
> systems described last.
> > > Rereading section 1.4.4.1:
> > > 
> > >   The failover model supports an "n+k" redundancy model, 
> where "n" APSs is the
> > >   minimum number of redundant [sic] ASPs required to 
> handle traffic and "k"
> > >   ASPs are available to take over for a failed or unavailable ASP.
> > > 
> > > Note that the state of the "k" ASPs with respect to an AS 
> is not stated.  In
> > > the 'm+1' redundant system described above, the "k" ASPs 
> are active for the
> > > AS.  "k" ASPs active in load sharing mode are "available 
> to take over for a
> > > failed or unavailable ASP".
> > > 
> > > It is typical to run the "k" ASPs active (and I know you 
> had some questions
> > > about activating the "k" ASPs, but the point is that they 
> are normally already
> > > active), and handling their own share of traffic.  In 
> this case, each ASPs
> > > handles n/(n+k) of their engineered capacity.  Were you 
> actually considering
> > > deploying such a atypical model where the 'k' ASPs are inactive?
> > > 
> > > "k" ASPs can be taken out of service, upgraded, and 
> brought back into service
> > > without affecting the maximum engineering traffic 
> handling capacity of the
> > > system (in absence of failures during the upgrade).  This 
> assists in graceful
> > > software/hardware upgrades on live systems.  (Keeping 
> them inactive would
> > > serve no purpose and would, decrease maximum traffic 
> handling capability,
> > > increase loss of state on fail-over, and increase 
> fail-over latency: all good 
> > > reasons for not deactivating the 'k' ASPs).
> > > 
> > > Now, reliability engineering for carrier class systems 
> takes the view that if
> > > 50% of the load bearing components in a system fail (stop 
> operating in any
> > > way), then the entire system has failed.  If traffic is 
> stopped above n/2
> > > processes, the system will have failed prematurely.
> > > 
> > > A requirement to withhold traffic < n will always suffer 
> a prolonged system
> > > failure, because only n/2 are required to make the system 
> available.
> > > Therefore, on startup the reliability of the system is 
> degraded by the
> > > negative exponent n/2, regardless of whether n=256 or 
> n=2; however, increasing
> > > 'n' increases the damage done to reliability by waiting for 'n'.
> > > 
> > > A requirement for the SG to wait for 'n' is unacceptable 
> from the standpoint
> > > of the redundancy model that 'n+k' was meant to address, 
> as well as other
> > > possible models that it can accommodate.
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > Consider the same example with: n=2, k=1, two ASPs failed.
> > > > > 
> > > > > Any system that introduces hysteresis to aggravate 
> and perpetuate an outage in
> > > > > this fashion is not very useful.
> > > > > 
> > > > > In the examples, what would have been a brief 
> AS-PENDING situation has been
> > > > > turned into a prolonged and complete system failure.  
> It is certainly not good
> > > > > practice to design redundant systems in that fashion 
> and recommending or
> > > > > requiring such a design would be a bad thing.
> > > > > 
> > > > > To further the example, consider the multiple SG as 
> STP situation.  One SG
> > > > > cannot know the state of ASPs for the its mated SG 
> and therefore cannot
> > > > > distinguish between the restart scenario and the 
> start scenario as far as the
> > > > > AS state is concerned because the SG does not know 
> the state of the AS itself:
> > > > > the AS could be active with other SGs.
> > > > > 
> > > > > This is the same case for SGP.  Unless AS state is 
> synchronized across SGPs,
> > > > > one SGP cannot know the total state of the AS (only 
> its partition).  There is
> > > > > no requirement to synchronize AS state across SGP (on 
> the SGP side, AS-state
> > > > > is per-SGP), and there is certainly no requirement to 
> synchronize AS-state
> > > > > across SGs.
> > > > > 
> > > > > So, take the (n=2, k=0) example where there are two 
> SGs.  Due to a network
> > > > > partitioning at startup, one ASP can communicate only 
> with one SG, and the
> > > > > other ASP can communicate only with the other SG.  
> Because n=2, neither SG
> > > > > will start traffic and the system suffers 100% 
> failure until the network
> > > > > partitioning ceases.
> > > > > 
> > > > > Consider the same example where there are two SGPs 
> (instead of SGs) and the
> > > > > two ASPs normally only form one association (e.g., 
> ASP1-SGP1, ASP2-SGP2).
> > > > > Note that there is no requirement in the RFC to form 
> full-mesh associations.
> > > > > Because the number of active ASPs with each SGP is < 
> 2, the system will never
> > > > > start.
> > > > > 
> > > > > These are not strange scenarios.  These situations 
> are all permitted by the
> > > > > RFC.  Yet, in each situation it is clear that one 
> cannot recommend that the SG
> > > > > wait.  The result would be a non-functional system.  
> There are many more
> > > > > examples.
> > > > > 
> > > > > n+k is a model for redundancy (not for congestion and 
> flow control).  A system
> > > > > with an SG that waits for n is, in general, not a 
> fully redundant system at
> > > > > all, but is, rather, prone to these failure syndromes.
> > > > > 
> > > > > When you look at the situation and apply the 
> experience of reliability
> > > > > engineering, the recommendation is that the SG SHOULD 
> start traffic when the
> > > > > first ASP goes active.
> > > > > 
> > > > > Why wait for 'n' anyway?  Because the ASP cannot 
> handle some level of traffic?
> > > > > Any ASP that conforms to MTP-User standards, must 
> have the standardized
> > > > > MTP-User (ISUP/SCCP) congestion and flow controls and 
> must have the SCTP
> > > > > congestion controls and is therefore able to accept 
> any amount of traffic
> > > > > overload.
> > > > > 
> > > > > So there is no real reason for the SG to wait for 
> 'n'.  Nevertheless, the RFC
> > > > > allows this as an OPTION.  Requiring (MUST) or 
> recommending it (SHOULD)
> > > > > regardless of whether the number of active processors 
> is rising or falling,
> > > > > whether start, restart or failure, is unacceptable.
> > > > > 
> > > > > On the other side, at the ASPs, the ASPs have a 
> requirement to share state
> > > > > between them.  They must share circuit state and 
> transaction state in all
> > > > > configurations to meet carrier grade.  This is stated 
> in the RFC.  It is
> > > > > implicit that the ASPs are capable of knowing with 
> which SGs, and which SGPs
> > > > > for which they are active.  They have access to the 
> total state of the AS that
> > > > > they collectively represent, that the SG/SGP does 
> not.  Therefore is it
> > > > > reasonable for the ASPs to coordinate among 
> themselves the number of active
> > > > > ASPs and to ensure that there are sufficient ASPs 
> active to handle the
> > > > > expected load before starting traffic.  Because the 
> ASPs need not respond to
> > > > > user test traffic (UPT/SST), the ASPs are also in 
> control of when remote SS7
> > > > > MTP-User restart traffic toward them.
> > > > > 
> > > > > Therefore, the recommendation that the ASPs SHOULD 
> coordinate among
> > > > > themselves the number of active ASPs and not start 
> traffic until a sufficient
> > > > > number of them are active is sound.  This is not a 
> MUST, permitting ASPs
> > > > > that know that they are capable of handling any 
> overload, to start traffic
> > > > > immediately, or at some earlier point.
> > > > > 
> > > > > Back to the RFC, the RFC sets the normal case where 
> the SG starts traffic on
> > > > > the first active ASP but explicitly permits as an 
> OPTION to wait until it
> > > > > considers that there are sufficient ASPs active to 
> handle the offered load.
> > > > > The RFC also RECOMMENDS that the ASPs coordinate 
> among themselves the number
> > > > > of active ASPs so that there are sufficient ASPs to 
> handle the expected load.
> > > > > 
> > > > > The provisions in the RFC are both sound, where the 
> proposal and section 3.15
> > > > > is clearly not.
> > > > > 
> > > > > Remember when looking at the AS state diagram in the 
> RFC that this is the
> > > > > SGP's view of the AS state and not the total state of 
> the AS, that can only
> > > > > known to the ASPs for all configurations.  'n' as 
> defined has no meaning to
> > > > > the state machine at the SGP because is not required 
> to know, and often cannot
> > > > > know, how many ASPs are active for the AS via other 
> SGPs and SGs, or even via
> > > > > direct connection to the SS7 network.
> > > > > 
> > > > > Some SGs might have special knowledge, or 
> sophisticated algorithms that allow
> > > > > it to determine whether a congestive failure will be 
> the immediate result of
> >  > > > starting or restarting traffic.  These SGs are 
> permitted as an
> > OPTION to wait.
> > > > > 
> > > > > The ASPs SHOULD have the knowledge of how many are 
> required to handle the
> > > > > expected load, because they must share 
> circuit/transaction state and they must
> > > > > have congestion and flow controls as required by the 
> standards.
> > > > > 
> > > > > So again, the RFC is adequate in this regard.  The 
> current proposal and
> > > > > section 3.15 are not.
> > > > RFC is inadequate so we need section 3.15 to explain 'n+k' case.
> > > 
> > > Teaching reliability engineering and the design of 
> redundant systems is
> > > outside the scope of the RFC and the IG.  People, such as 
> yourself, are better
> > > advised to learn the subject matter before attempting to 
> implement or claim a
> > > complete understanding of the protocol.
> > > 
> > > The current RFC provides the protocol mechanisms and basis for
> > > interoperability for all of the common approaches to 
> redundancy in carrier
> > > class systems, and even provides a general model that can 
> accommodate
> > > non-traditional redundancy architectures.
> > > 
> > > When confused about how a redundancy architecture works, 
> don't blame the M3UA
> > > RFC, blame those responsible for describing redundant 
> architectures to you.
> > > 
> > > In the appendix we stated:
> > > 
> > >    M3UA imposes no restrictions as to the exact layout of 
> the network
> > >    elements, the message distribution algorithms and the 
> distribution of
> > >    signalling processes.  Instead, it provides a 
> framework and a set of
> > >    messages that allow for a flexible and scalable 
> signalling network
> > >    architecture, aiming to provide reliability and performance.
> > > 
> > > Forcing SGs to wait for 'n' ASPs active before activating 
> is contrary to this.
> > > The existing "MAY" achieves this flexibility.
> > > 
> > > When reading 1.4.4.1, also remember this statement in the 
> appendix, that used
> > > to be beside 1.4.4.1.  The description of 'n+k' does not 
> dictate the state of
> > > the 'k' or the state of the AS with respect to 'n' to 
> leave the redundancy
> > > model flexible, and accommodate '1+1' and '1+0' in the same model.
> > > 
> > > Also, please don't presume to tell me to set 'n' to 1, as 
> it is not a
> > > arbitrary value, but the number 'm' in the 'm+1' 
> distributed system in common
> > > use today.  This number is determined as the minimum 
> number of ASPs required
> > > to handle the maximum engineered load, and not, as Tolga 
> would have, the
> > > minimum number of ASPs required to handle ANY load.  If 
> you want your system
> > > to behave as Tolga proposes, just have your SG exercise 
> the "MAY choose not to
> > > direct traffic" option of section 4.3.4.3 of the RFC.
> > > 
> > > Section 3.15 and Tolga's proposal should be struck 
> because they attempt to
> > > impose a 'n' active 'k' inactive and system cannot 
> restart (3.15) or start
> > > (Tolga) without 'n' view on the redundancy model, where 
> it is clearly the
> > > intent of the RFC to place no such restrictions on the 
> model, but to
> > > accommodate a range of models, that is already achieved 
> by the RFC text.
> > > 
> > > --brian
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> 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, 10 Jul 2003 05:36:33 -0600

Javier,

Your "new possibility" is the norm in the RFC.  You seem to want reverse
the sense of the RFC.  The RFC says that we activate on the 1st ASP and
MAY withhold until the 'n'th ASP.  3.14 says that we SHOULD withhold to
the 'n'th ASP and MAY activate on the first.

The reason for this change escapes me.  There is no justification to
reverse the option.

Please, answer me this:

  Who has an ASP that is so broken that it needs the SGP to wait
  for 'n' of them to become active?

  Please identify yourselves!

There are several other places in the RFC that assume activation on the
first ASP.  It is sewn through and through the RFC that loadsharing and
broadcast is performed across the active APSs (regardless of n).

Section 3.7.1:
                                                  ...  In Loadshare
      mode, the ASP will share in the traffic distribution with any
      other currently active ASPs.  In Broadcast mode, the ASP will
      receive the same messages as any other currently active ASP.

(Notice the word "any", twice, above.)

Section 4.1.1

   From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE
   state is selected and a DATA message is constructed and issued on the
   corresponding SCTP association.  If more than one ASP is in the ASP-
   ACTIVE state (i.e., traffic is to be loadshared across more than one
   ASP), one of the ASPs in the ASP-ACTIVE state is selected from the
   list.  If the ASPs are in Broadcast Mode, all active ASPs will be
   selected and the message sent to each of the active ASPs.

(Note above that there is no 'n' restriction on selecting ASPs to receive
traffic.)

Section 4.3.4.3:

   In the case of a Loadshare mode AS, reception of an ASP Active
   message at an SGP or IPSP causes the direction of traffic to the ASP
   sending the ASP Active message, in addition to all the other ASPs
   that are currently active in the AS.

Section 4.3.4.4:

   In the case of a Loadshare mode AS, the SGP moves the ASP to the
   ASP-INACTIVE state and the AS traffic is reallocated across the
   remaining ASPs in the state ASP-ACTIVE, as per the loadsharing

Also, note that there is no limit to T(r).  So, if it was set infinite,
or just rather large, the start case is transformed to the restart case.

Changing the trantion from the AS-DOWN to AS-INACTIVE state at the SGP
to wait for 'n' ASP-INACTIVE ASPs is even more pointless than waiting
for 'n' ASP-ACTIVE ASPs.  No traffic is flowing.  The RFC always has us
move to the AS-INACTIVE state on the first ASP-INACTIVE ASP.

What in the world did you think would necessitate changing this?

--brian

Javier Pastor-Balbas (ECE) wrote:                                                   (Thu, 03 Jul 2003 11:45:57)
> 
> Hi guys,
> 
> We tried to submit the next IG version before the deadline, but I got
> confused since I thought it ended at 12:00 instead of 9:00. So the server
> bounced it. I'll submit the doc again after the IETF meeting. In the
> meantime you can find it at:
> 
> We've tried to include all the different opinions in here. Although it seems
> that the case of waiting till n ASPs is the preferred one, we have included
> the new possibility of a smooth start for those of you who want to activate
> the AS when the first ASP gets to ACTIVE. At the end it will be the
> operator's decission how to proceed during the activation phase. Hopefully
> everyone agrees on this wording...
> 
> Cheers // Javier.
> 
> 
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 06:36:10 -0600

Javier,

'n' is defined as the number of ASPs that are needed to handle
the maximum engineered load of the AS.

This is the total load from the network correct?  As in the
traffic delivered to the AS, from all SGP, all SG.  Correct?

What has that to do with the number of ASPs active for particular
SGP?

There can be more than on SGP.  Correct?

There can be more than one SG.  Correct?

An ASP can be active for any number of SGPs in any number of SGs.  Correct?

SGPs in an SG should be able to transfer traffic between them.  Correct?

In general, what has the number of ASPs active for one SGP have
to do with the traffic handling capacity of an AS?

Consider the following (n+k == 2+0): (Figure 5).
Consider first that SGP1 and SGP2 are in the same SG.

     ________                  ________   
____|        |________________|        |
    |  SGP1  |        ________|  ASP1  |
    |________|       /        |________|
     ________       /          ________
    |        |_____/          |        |
____|  SGP2  |________________|  ASP2  |
    |________|                |________|

3.14 tells me that I SHOULD NOT direct traffic from the
newtork from SGP1 to ASP1 on startup of ASP1 with SGP1.

Does that include passing traffic from SGP1 via SGP2?

Is this because ASP1 cannot handle the load?

What should SGP1 do?

Now, consider that SGP1 and SGP2 are in different SGs.

Should SGP1 tell the network that the AS is inaccessible?

Should SGP1 direct traffic over C-links to SGP2 that will
ultimately be the same a passing traffic to ASP1?

Why should not SGP1 direct traffic to ASP1?

I don't think that 3.14 is very clear.  'n' has nothing to do
with the handling capacity from a given SGP to an AS.  It has
to do with the overall engineered maximum traffic that 'n' ASPs
can handle for the AS.  In even the more trivial cases the SGP
cannot follow the recommendation.

Please explain.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 07:16:03 -0600

Javier,

The AS State Machine illustrated in 3.14 is per-SGP.  Correct?

SGP can communicate with each other in an SG.  Correct?

Why should an SGP pend when the last ASP goes ASP-INACTIVE for
an AS with a given SGP?

Cannot the SGP redirect traffic via another SGP that has ASPs
active for the AS?

Example:

        _______                    _______
       |       |______x    x______|       |
       | SGP1  |         _________| ASP1  |
       |_______|        /         |_______|
        _______        /           _______
       |       |______/           |       |
       | SGP2  |__________________| ASP2  |
       |_______|                  |_______|

When ASP1 goes inactive (or down) w.r.t SGP1, cannot
SGP1 direct traffic via SGP2?

What is the state of the AS at SGP1?

In section 3.14 AC2PN says that:

  AC2PN: the last ASP in the ASP-ACTIVE state moves to
  ASP-INACTIVE or ASP-DOWN states, causing the number of ASPs
  in the ASP-ACTIVE [sic] drop below 1.

Is that the number of ASPs for SGP1?  for SGP2? for the SG?
for all (both) SGs?

In the RFC the AS state machine was per-SGP.  Is the 3.14 state
machine per-SGP?

   IA2AC: one ASP moves to [the] ASP-ACTIVE [state], causing
   [the] number of ASPs in the ASP-ACTIVE state to be n.

When SGP1 receives an ASP Active and sends an ASP Active Ack
to ASP1, how many ASPs are active for the AS?   1?  2?

Please clarify.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 07:21:24 -0600

Javier,

   ---------
   New text: (Section 4.3.4.3, for both loadsharing and broadcast)
   ---------

   At start-up or re-start phases, an SGP or IPSP, upon reception of an
   ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT
   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.

How can the SGP know when there are sufficient resources?

'n'?  How do I count ASPs active for comparison against 'n' at one SGP
in multiple SGs?

Please provide a definition of, and criteria for, sufficient resources to
go with the recommendation.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 07:29:58 -0600

Javier,

Section 3.8 says:

   5.4 Auditing examples

   5.4.1 SG State: Uncongested / Unavailable

          ASP                          SGP
          ---                          ---
           |  -------- DAUD --------->  |
           |  <------ SCON(0) --------  |
           |  <------- DUNA ----------  |

What state of a destination is Uncongested/Unavailable?  There is no
such state in Q.704.  Uncongested routesets are by definition available.
Inaccessible routesets have no congestion state by definition.

Did you think that a routeset could be in an unavailble and congested state?

What is the use of the SCON(0)?  Why is it being sent?

   5.4.4 SG state: Uncongested / Unavailable

          ASP                          SGP
          ---                          ---
           |  -------- DAUD --------->  |
           |  <------- DUNA ----------  |

What is the difference between 5.4.1 and 5.4.4?  They both say
Uncongested/Available.

   [...]. Where the SGP maintains the congestion status of the SS7
   destination, the SGP MUST additionally respond with an SCON message
   before the DAVA or DRST message.  If the SS7 destination is

When is the SGP required to maintain congestion status?  What is the
criteria for an ASP to determine that an SGP should maintain congestion
status and is violating this MUST.  Why must the ASP require the SGP
to send SCON in this circumstance?  What interoperability concern is the
MUST addressing?

Please explain.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 07:33:33 -0600

Javier,

3.18.3 Solution Description

   Clarify that the ASP needs to indicate when the congestion level has
   changed (including abatement).  Further, the ASP peer can maintain
   a timer, if desired, in case the ASP fails to indicate congestion
   abatement.

Where are the procedures for this timer described?  This is the only place
that the timer is mentioned.  Please describe the timer or remove the sentence
saying that it has been described...

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 07:41:35 -0600

Javier,

Section 3.9 says:

          ASP                          SGP
          ---                          ---
           |  ------ ASPIA (RC1)----->  |
           |  <----  ASPIA Ack -------  |
           |  -----DEREG REQ (RC1)--->  |
           |  <----DEREG RSP (RC1)----  |
           |  -------ASPIA (RC1)----->  |

   What should SG do?

The new text does not explicity answer this question.

What does the SGP send in this case?

As RC values are per-SGP, it appears to me that it must be
Error("Invalid Routing Context").

Correct?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 09:15:00 -0600

Javier,

Section 3.14 says:

   IA2DN: One ASP moves to ASP-DOWN causing that the number of ASPs in
   either ASP-ACTIVE or ASP-INACTIVE drops below n.

Am I correct to say that if n=5 and there are 4 ASPs in the ASP-INACTIVE
and 1 ASP in the ASP-ACTIVE state, and then the 1 active ASP moves to
the ASP-DOWN state and T(r) expires that the AS is to move to the AS-DOWN
state?  As follows:

  If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP MAY stop
  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.

Now, that is an AS state change and we must send a NTFY to all the INACTIVE
ASPs (the 4 left inactive) of the state change.  But from Section 3.8.2 of
the RFC, there is no message to notify of an AS-DOWN state:

         1    reserved
         2    Application Server Inactive (AS-INACTIVE)
         3    Application Server Active (AS-ACTIVE)
         4    Application Server Pending (AS-PENDING)

You see, we removed it because there was never an instance in which it
would be sent.  You have inserted an instance again.

Aren't you going to have to define a Notify message (the Reserved value)
for "Application Server Down (AS-DOWN)" so that the INACTIVE ASPs can
be properly notified by the SGP?

Particularly when the RFC says in Section 4.3.4.5: (Notify Procedures)

   A Notify message reflecting a change in the AS state MUST be sent to
   all ASPs in the AS, except those in the ASP-DOWN state, with
   appropriate Status Information and any ASP Identifier of the failed
   ASP.  At the ASP, Layer Management is informed with an M-NOTIFY
   indication primitive.  The Notify message must be sent whether the AS
   state change was a result of an ASP failure or reception of an ASP
   State management (ASPSM) / ASP Traffic Management (ASPTM) message.
   In the second case, the Notify message MUST be sent after any related
   acknowledgement messages  (e.g., ASP Up Ack, ASP Down Ack, ASP Active
   Ack, or ASP Inactive Ack).

The above tells me that I MUST send a Notify message becase of the AS
state change, but there is no message to inform about AS-DOWN state
transition.

What is the purpose of doing this?  What is the protocol difference between
the AS-DOWN state and the AS-INACTIVE state?  What is it that the SGP
does or doesn't do in the one state that it doesn't or does do in the other?

I don't recall this being discussed at all.

Please clarify.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 10:15:47 -0600

Javier,

Section 3.20 has the following new text:

   When an ASP becomes active for an AS and the SG is experiencing SS7
   network isolation or is performing the MTP Restart procedure for the
   AS, the SG SHOULD send a DUNA(*) to the newly active ASP to prevent
   the ASP from sending traffic.

This is provided for by the DAUD procedure in the case of Isolation
in Section 4.5.3 of the RFC.

We discussed this and said that the SGP could send DUNA(*) if it wanted
to try and thwart traffic, but it is not necessary.  The SGP can always
rely on responsive procedures instead (responding to DATA with DUNA for
the inaccessible destination).  Also, the audit procedure allows the
ASP to audit after it becomes newly active whether the MTP is restarting
or not.

Also, there is the situation where the SG serves more than one point code.
In that case, the SG may transfer messages between point codes in the
IP domain while being in MTP Restart w.r.t. the SS7 domain.
That is why 4.6 MTP3 Restart says:

   When the SG discovers SS7 network isolation, the SGPs send an
   indication to all concerned available ASPs (i.e., ASPs in the ASP-
   ACTIVE state) using DUNA messages for the concerned destinations.

Rather than DUNA(*).  MTP Restart does not necessarily affect all SS7
point codes, particularly those in the IP domain.

Change SHOULD to MAY and change DUNA(*) to "DUNA messages for the concerned
destinations".

--brian

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