Subject: RE: [Sigtran] M3UA IG v04

From: "J.Javier Pastor (EE/EEM)" <[email-masked]>
Date: Tue, 8 Jul 2003 10:49:53 +0200

It seems that finally it went through.... (Better late than never) :-D

http://www.ietf.org/internet-drafts/draft-ietf-sigtran-m3ua-implementors-guide-04.txt

Cheers // Javier.

> -----Original Message-----
> From: J.Javier Pastor (EE/EEM) 
> Sent: jueves, 03 de julio de 2003 10:59
> To: [email-masked]
> Cc: [email-masked]'; Samuel Dur D. Jeyaseelan
> Subject: [Sigtran] M3UA IG v04
> 
> 
> 
> 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-i
> mplementors-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
> 

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