Subject: [Sigtran] M3UA IG v04

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 3 Jul 2003 10:59:17 +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