Subject: RE: [Sigtran] M3UA notify message

From: <[email-masked]>
Date: Thu, 23 Feb 2006 09:03:03 +0530

Tolga,
	Well, I might have put it wrong but actually what I wanted to
say was that if a particular AS can be reached thorough more than one
SGPs then, routing keys and AS states are shared across SGPs in
accordance with section 1.4.1.

Regards,
 
Prabind

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2006 8:10 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA notify message

Prabind,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2006 9:49 AM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA notify message
>
>
> Tolga,
> Right, but the question nitin asked is per AS! So suppose one AS would
> provide one user part functionality and taking services from multiple
> SGPs, then should't all SGPs share the information about remote
AS/ASPs?
> I suppose that's the situation depicted.
[TOLGA]Sharing information about them does not mean running a single ASP
state machine in the SG. Each SGP runs its own ASP state machine and
follows
procedures described in the specification according to that. Otherwise
interoperability would be broken. How to create a unique SPMC view is an
implementation dependent issue.

Nitin's question is about whether NTFY needs to be sent to ASP2 from
SGP1.
If one follows the procedures defined in the RFC, it shouldn't be. NTFY
for
this case is sent to all ASPs which are not in DOWN state, when the
state
for an AS in a SGP changes.
>
> Please let me know which sections deals with: "State machines are kept
> per SGP".
[TOLGA]Have a look to 4.3 AS and ASP/IPSP State Maintainenece. All
procedures are defined between ASP/SGP, not between ASP/SG.
>
>
> Regards,
>
> Prabind
>
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2006 7:41 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA notify message
>
> Prabind,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, February 22, 2006 9:19 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] M3UA notify message
> >
> >
> > Nitin,
> > Refer to section "1.4.1 Signalling Point Code Representation". It
> > clearly says:
> > "Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
> >    remote AS/ASP states of each SGP SHOULD be coordinated across all
> the
> >    SGPs.  Rerouting of traffic between the SGPs MAY also be
> supported.:
> > "
> [TOLGA]This section refers to aggragating the unique SPMC view and
> supporting the implementation dependent internal routing
functionality.
> State machines are kept per SGP.
>
> 4.3 AS and ASP/IPSP State Maintenance
>
>    The M3UA layer on the SGP maintains the state of each remote ASP,
in
>    each Application Server that the ASP is configured to receive
>    traffic, as input to the M3UA message distribution function.
>    Similarly, where IPSPs use M3UA in a point-to-point fashion, the
M3UA
>    layer in an IPSP maintains the state of remote IPSPs.
> > Since SGP2 will know what SGP1 has, it will send notifications to
ASP.
> >
> > Regards,
> >
> > Prabind
> >
> >
> > -----Original Message-----
> > From: nitin [mailto:[email-masked]]
> > Sent: Wednesday, February 22, 2006 7:55 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] M3UA notify message
> >
> > hi ,
> > I think i had not explained my questions clearly . I am trying to
> > explain
> > them again .
> >
> > Please have a look at the diagram :-
> >
> > -----------                 -----------
> > SGP1                         SGP2
> > ---|--------                ----|--------
> >     |                                  |
> >     |                                  |
> >     |                                  |
> >     |                                  |
> >     |                                  |
> > ------------               ----------
> > ASP1                        ASP2
> > ------------               -----------
> >
> > In this diagram, SGP1 and SGP2 are both part of SG1. ASP1 and ASP2
are
> > part
> > of AS1.
> >
> > ASP1 has made sctp associatiion with SGP1 only .
> > ASP2 has made sctp association with  SGP2 only.
> > AS is in override mode.
> >
> > ASP1 is INACTIVE at SGP1 and ASP2 is INACTIVE at SGP2.
> >
> > 1. Now, if ASP1 sends ASP ACTIVE message to SGP1 . will SGP2 be
> sending
> > notify for AS ACTIVE to ASP2.
> >
> > 2. If yes, now suppose ASP2 sends ACTIVE to SGP2 .
> >     Should Alternate ASP active notify be given to ASP1.
> >     If yes , in earlier discussions we have observed that Notify
> should
> > be
> > done per SGP and not SG.
> >
> > 3. To add further ,   ASPSM, ASPTM, SSNM/SPMC ,notify messages be
> > considered
> > per SG  or per SGP.
> >
> > 4. The question 4 that i had written in previous mail , i am
> explaining
> > again.
> > In that question I was not very clear in saying that n+k was for SGP
> or
> > SG.
> >
> > Actually what i want to ask is that ..............n+k is per SG or
per
> > SGP.
> >
> > For example :- suppose 2+1 architecture is there . Now SG has two
> SGP's
> > and
> > AS has two ASP's.
> > ASP1 is active on SGP1 and ASP2 is active on SGP2.
> > Since in this case total number of active ASP's is two , we should
> > consider
> > AS to be active at SG.
> >
> >                 OR
> > suppose ASP1 and ASP2 are both active on SGP1 but none of them is on
> > SGP2.
> > So in that case also
> > the number of ASP's active is two. Should we consider AS active at
SG
> in
> > this case .
> >
> > Which of the above two cases is valid or both.
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "nitin" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Wednesday, February 22, 2006 5:19 PM
> > Subject: Re: [Sigtran] M3UA notify message
> >
> >
> > > nitin,
> > >
> > > nitin wrote:                                   (Wed, 22 Feb 2006
> > 17:28:49)
> > > > Hi,
> > > > if this is the case, then what will happen when(4 cases given
> below
> > are
> > > > different from each other) :-
> > > > 1. AS(consisting of ASP1 and ASP2) is active at SG (consisting
of
> > SGP1
> > and
> > > > SGP2) since ASP1 has done ASP active at SGP1. AS is in override
> mode
> > and
> > now
> > > > ASP2 sends ASP active message to SGP2 , now what will happen.
> Should
> > SGP1
> > > > send alternate ASP active notify to ASP1 and mark ASP2 as
active.
> > But if
> > > > such is the case , ASP2 has not yet formed the association with
> > SGP1.
> > >
> > > SGP2 sends it.
> > >
> > > > 2. should the SS7 traffic of SGP2 be routed through SGP1 since
> > AS(load
> > share
> > > > mode) is active(ASP1 has done active at SGP1) and SGP2 has
already
> > sent
> > the
> > > > notify for AS active to ASP2.
> > >
> > > Yes.
> > >
> > > > 3. If  AS is in loadshare mode (rest of the configuration same
as
> in
> > 1)
> > .
> > > > Now when ASP2 sends active to SGP2 , should notify be sent again
> to
> > the
> > > > ASP2.
> > >
> > > What Notify?
> > >
> > > > 4. In n+k architecture should this n be taken for SG or this is
> for
> > SGP.
> > I
> > > > mean to say AS should become active at SG (when it is active at
n
> > SGP's
> > ,
> > > > supposing single ASP of AS is active at each of n SGP)or (should
n
> > ASP's
> > be
> > > > active at any SGP) or (n ASP's should be active only no matter
> where
> > and
> > how
> > > > they are).
> > >
> > > n+k refers to ASPs (and possibly IPSPs), not SGPs.
> > >
> > > >
> > > > There was an earlier mail (copied below) , in which SGP2 sends
> > notify
> > again
> > > > to ASP which should not happen if we are going according to the
> > current
> > > > scenario.
> > >
> > > The extra Notify is redundant (but not forbidden).
> > >
> > > --brian
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > >
> > >
> > >
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.1.375 / Virus Database: 268.0.0/266 - Release Date:
> > 2/21/2006
> > >
> > >
> >
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 23 Feb 2006 10:16:34 -0500

Brian,

State sharing/State coordination etc.. are all not well defined terms. What
I mean is that each SGP needs to execute ASPTM/ASPSM state machine
procedures independently and use their independent states for that
purpose -but based on what I read in this thread it seems that there is no
common interpretation about this-.

Please see below for more comments.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, February 23, 2006 1:04 AM
> To: [email-masked]
> Cc: [email-masked]
> You are correct, there is a case where the ASP state is shared across
> the SGPs making up an SG: in the Override traffic mode AS it is
> necessary to share which ASP is "Active" and which is "Standby" as only
> one ASP can be Active for the AS.
[TOLGA]I am not sure about this. All section 4.3 talks about SGPs and ASPs
as peers of the procedures to be followed. For example, if one looks to
4.3.4.3 ASP Active Procedures , one can see that all traffic mode procedures
are described from SGP point of view, not from SG point of view. We can talk
about benefits of different approaches but my understanding according to the
current text is that traffic mode decisions are done in each SGP
independently, but please note that a well-defined and explained behavior is
necessary to prevent interoperability issues.

Please also keep in mind the first item in Greg's e-mail you quoted before:
    1) Each ASP-SGP association uses the M3UA protocol independently

This, IMHO is an important principle and we shouldn't give it up.
>
> This is also a case where state transitions directly associated with
> ASPTM/ASPSM message procedures must be considered on an SG-wide basis,
> contrary to Tolga's previous statements on this thread.
[TOLGA]Before I reply, I need to know which procedures you specifically have
in mind.
>
> It is possible, but perhaps less important to interoperability, that an
> SG could coordinate the ASP state for ASPs in a Loadshare or Broadcast
> AS.  That is, when loadsharing, the selection algorithm at an SGP could
> consider the availability of ASPs to other SGPs to more equally
> distribute traffic.  For Broadcast mode AS, consideration of ASP state
> across the SGP could provide a more optimal broadcast of traffic (i.e.
> without sending multiple messages to or missing completely an ASP).
[TOLGA]Yes, this won't effect interoperability at all.
>
> For the case of SSNM, it is possible (but not required) for the SG to
> avoid sending duplicate SSNM messagese to any given ASP.  By considering
> the ASP state on an SG-wide basis, it is possible to ensure that only
> one SSNM message is sent to an ASP (via only one SGP).
[TOLGA]Yes not required with a "MUST", but it is common sense and is
mentioned in the RFC as well, because status of SS7 destinations is kept
gloabl in the SG, afterall it is a MTP3 entity.
>
> The override and SSNM cases were given consideration in the original
> thread that led to the wording 1.4.1.  The others were not so much.
>
> Therefore, I agree that the statement in 1.4.1 should not be ammended.
[TOLGA]I humbly disagree. That NTFY is to be sent based on changes for a
global-AS state is not clear at all, especially if one considers 4.3.2 and
4.3.4.5 -please do not expect us to refer to some e-mail sent 5 years ago
each time ;-)- BTW, I really think we first need to decide what is the exact
semantics we want to have for this.
>
> --brian
>
>
> [email-masked] wrote:                (Thu, 23 Feb 2006
> 09:50:04)
> >
> > I am still concerned about this statement from Tolga:
> >
> > " In any case, it is good that there is finally consensus regarding that
> > ASPSM/ASPTM procedures and associated state machines being independent
> > on
> > each SGP."
> >
> > If multiple SGPs are serving a single AS, then shouldn't the ASP states
> > also be shared across the related SGPs?
> > Else if I am wrong then the following statement in section 1.4.1 should
> > be amended to share the AS states only.
> > " Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
> >    remote AS/ASP states of each SGP SHOULD be coordinated across all the
> >    SGPs."
> >
> > Tolga, further considering the sahring of ASP states then, in the case
> > of the interoperability issue (as you depicted), the rfc says that if an
> > ASP is already inactive the ASP-UP message would still be respnded by an
> > ack.
> >
> > I think the things become simpler if we consider sharing of ASP states
> > of a particular AS across all SGPs serving that AS.
> >
> >
> > Regards,
> >
> > Prabind
> >
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

---

From: <[email-masked]>
Date: Fri, 24 Feb 2006 12:09:48 +0530

Nitin,
If n=2, then AS is not active as the overall view of AS at SG requires
two distinct ASPs to be active!! And SGPs can easily distinguish the
ASPs in an AS with the ASP-IDs.

Regards,
 
Prabind

-----Original Message-----
From: nitin [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 12:25 PM
To: Haresign Lincoln; [email-masked]; PRABIND CHAUBEY (WT01 -
Voice & Next Generation Networks)
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA notify message

hi ,
For the 3rd case , i had not mentioned n , it is 2.
So if it is 2, then what will be the case.
----- Original Message ----- 
From: "Haresign Lincoln" <[email-masked]>
To: "nitin" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 23, 2006 8:49 PM
Subject: RE: [Sigtran] M3UA notify message

Nitin,

For the first scenario, I would think that the ASP is either:

1) Configured at the SG (perhaps with IP addresses)
2) Is sending an ASPID to the SG.

In this way, the SG can see that the ASUP/ACPAC are coming from the same
ASP as the ASPID MUST be unique within the AS.  Therefore, the SG
properly manages the state of the AS and ASP.

For the second scenario, I would say the data message should be dropped
and an error return since the ASP/SGP2 state machine has not been
properly completed.

For scenario three, once one ASP is active to one SGP, the AS is active.

Regards,
Lincoln

________________________________

From: nitin [mailto:[email-masked]]
Sent: Thursday, February 23, 2006 9:40 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA notify message

I am explaining some scenarios :-

1. Consider SG consisting of SGP1 and SGP2.
     Suppose an AS contain one ASP and the traffic mode of AS is
override.
     If we look in terms of SGP then this override mode
     is of no use, but if we look in terms of SG  and this ASP is making
associations with
     two SGP then this is of much significance. Actually for SGP , ASP
is identified by
     the sctp association . For even if there is only one ASP in AS but
for SGP's they
     don't know this ASP as single ASP.

        Please take AS as inactive initially on both SGP's.

     ASP               SGP1              SGP2       SG
      |     aspAc       |                 |          |
      |---------------->|                 |          | ( please note
here that i have drawn  notify from SG,
      |<----------------|                 |          |   just to
highlight that state of AS is maintained at SG,
      |  asp ac ack     |                 |          |             so
logically this notify is sent with respect to SG)
      |<---------------------------------------------|
      |       notify AS active            |          |
      |                 |                 |          |
      |---aspAc-------------------------->|          |
      |       aspac ack |                 |          |
      |<----------------------------------|          |
      |         notify Alt. Asp Ac.       |          |
      |<---------------------------------------------|
      |                 |                 |          |
      |                 |                 |          |

 Now sicne  when we have configured AS at the SG, we have configured
that AS has only one SGP
 in override mode. However this override mode doesn't makes sense with
one ASP in AS.

 But here what is happening that SGP's doesnot know , that it is the
same ASP which is doing
 active with both SGP's. So when ASP  does active with SGP1 then AS
becomes active. Now when
 ASP does active with SGP2 this is new ASP for SGP2. So what should be
done in this case.Should
 Alternate ASP active notify be sent in this case to same ASP .

2. Now consider another case.

   In this scenario , ASP1 and ASP2 are both part of AS and SGP1 and
SGP2 are both part of SG1.
   In this case assume that ASP1 and ASP2 are both inactive at their
respective SGP's.
   Now my question is little bit different in this case as explained
below:-

     ASP1                 ASP2                SGP1           SGP2
      |     aspAc           |                   |              |
      |---------------------------------------->|              |

      |<----------------------------------------|              |
      |  asp ac ack         |                   |              |

      |<--------------------------------|                        |
      |       notify AS active                   |
|
      |                          |                        |
|
      |                                    data        |
|
                                |---------------------------------->
      |                         |                        |
|
      |                          |                        |

      |                      |                       |
      |
|
      |                          |                        |
|
      |                          |                        |
|

Should this data message be dropped at SG or should it be allowed to SS7
side , Since AS is active at SG
 but ASP2 is not active on SGP2.

3. Now here is the 3rd scenario , this is related to n+k AS.

In this case , configuration is AS consisting of ASP1 and ASP2.
SG consisting of SGP1 and SGP2.
Obviously the traffic mode is loadshare.
Now only ASP1 is doing ASP active on SGP1 and SGP2.
ASP2 has not done any m3ua procedures with neither SGP1 , nor SGP2.

ASP1                 ASP2                SGP1           SGP2
      |     aspAc           |                        |
|
      |--------------------------------->|                      |

      |<---------------------------------|                      |

      |  asp ac ack       |                        |
|
      |                          |                        |
      |                          |                        |
      |                          |                        |
|
      |----------asp Ac.---------------------------------------->|

      <-----------ASP act . ack--------------------------------------- |
      |                          |                        |

      |<----------------------------------------------------|
      |
|
      |                          |                        |
|
      |                          |                        |
|

Now since ASP1 has done active on both SGP1 and SGP2 , it is active on
two SGP's.
So with respect to SG two SGP's are active. Should in this case AS be
active or not.

thanks
nitin

----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 23, 2006 11:34 AM
Subject: Re: [Sigtran] M3UA notify message

09:50:04)
the
> Version: 7.1.375 / Virus Database: 268.0.0/267 - Release Date:
2/22/2006

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.0.0/268 - Release Date: 2/23/2006

---

From: <[email-masked]>
Date: Fri, 24 Feb 2006 14:13:57 +0530

Brian,
Thanks for a nice explanation.

Regards,
 
Prabind

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 1:29 PM
To: PRABIND CHAUBEY (WT01 - Voice & Next Generation Networks)
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] M3UA notify message

prabind.chaubey,

I think that you understand the situation well now.

Because AS state depends upon ASP state, it is really not
possible to coordinate AS state across multiple SGP without also
coordinating ASP state.  That is why I feel that Greg stated the
situation well in 1.4.1 when he said:

  "Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
   remote AS/ASP states of each SGP SHOULD be coordinated across all the
   SGPs.  Rerouting of traffic between the SGPs MAY also be supported."

Also note that we never required that a full-mesh of SCTP
associations be formed between ASPs and SGPs.  And, certainly,
as you illustrate below, the failure of an association (or two)
can reduce a full-mesh to a sparse set of SCTP associations
anyway.  A full mesh would likely only be for network
redundancy.  If I have 2 ASPs, 2 SGPs and 2 networks, the most
efficient arrangement from a performance/failure perspective
would be as follows:

  ASP1  -------network A------- SGP1
        \______network B______/
         ______network B_____/\
        /                      \
  ASP2  -------network A------- SGP2

In that way if only network A fails, each ASP is still connected
to a different SGP (for performance), and the same is true if
only network B fails.  If network B fails, the situation
degrades to

  ASP1  -------network A------- SGP1

  ASP2  -------network A------- SGP2

The ability of the system to operate, should not be adversely
affected by the loss off network B.  If the SG does not
coordinate AS/ASP state, in scenarios like the 2+k scenario you
detail, the system will not function to the same degree as that
where AS/ASP state is coordinated.  Good reason for the SHOULD.

Now, we did not go much farther than the statements in section
1.4.1 because there are a number of ways to implement the
necessary functionality without using things like "shared"
state.  These are implementation details.  An example of how to
coordinate state without sharing is to have each SGP proxy its
connected ASPs to other SGPs at a lower priority, so the
full-mesh situation looks like so:

At SGP1:
   SGP1 to ASP1 via netA - priority 1
   SGP1 to ASP2 via netB - priority 1
   SGP1 to ASP1 via SGP2 - priority 2
   SGP1 to ASP2 via SGP2 - priority 2

At SGP2:
   SGP2 to ASP1 via netB - priority 1
   SGP2 to ASP2 via netA - priority 1
   SGP2 to ASP1 via SGP1 - priority 2
   SGP2 to ASP2 via SGP1 - priority 2

When network B fails, the system would reduce to the following:

At SGP1:
   SGP1 to ASP1 via netA - priority 1
   x x x x x x x x x x x x x x x x x 
   x x x x x x x x x x x x x x x x x 
   SGP1 to ASP2 via SGP2 - priority 2

At SGP2:
   x x x x x x x x x x x x x x x x x 
   SGP2 to ASP2 via netA - priority 1
   SGP2 to ASP1 via SGP1 - priority 2
   x x x x x x x x x x x x x x x x x 

The actions taken to get there are:

   SCTP communication lost from SGP1 to ASP2
   SGP1 marks ASP2 down
   SGP1 signals SGP2 that it can no longer proxy ASP2 (ASPDN equivalent)

   SCTP communication lost from SGP2 to ASP1
   SGP2 marks ASP1 down
   SGP2 signals SGP1 that it can no longer proxy ASP1 (ASPDN equivalent)

This approach also works well if the SG was to get partitioned
due to internal failure, and recovery from the internal
partitioning is smooth.  To a large degree the SGP can run a
local state machine without sharing state (in the "shared
memory" sense) under this arrangement, permitting geographical
distribution of SGP, particularly in administrative domains where
point code exhaustion is an issue.  Also, the M3UA (or SUA)
protocol can largely be reused for communicating between SGP.

But that's design and implementation.  There are, of course,
many other approaches to a solution for coordinating AS/ASP
state.

For the RFC, the word "coordinated" should suffice without going
into implementation details.

--brian

[email-masked] wrote:                           (Fri, 24 Feb
2006 11:17:38)
> Tolga,
> Well let me express in detail:
> "A combined view of the AS is maintained across all SGPs serving that
> AS. This means the state of AS would be maintained at SG. The sate of
> ASPs serving the (above) AS should be coordinated/shared across all
SGPs
> serving the AS. Shared should not be taken as maintained. What I mean
is
> the SGPs are just aware of the state of a particular ASP at a
particular
> SGP in an AS. Only then they can have a combined view of AS"
> 
> Now, if you don't agree with the above, let's consider the redundancy
> model n+k for AS. Here for simplicity I consider the value of n=2 and
> k=0. Guess you would agree that as per this model the AS would be
> considered active only when the number of active ASPs is 2.
> Let's also consider 2 ASPs (ASP1 and ASP2) and two SGPs (SGP1 and
SGP2)
> for the above model. 
> 
> ASP1 ------------- SGP1 (sctp association established and ASP1
inactive)
> 
> 
> ASP2 ------------- SGP2 (sctp association established and ASP2
inactive)
> 
> Now if we take your view into consideration, then even if the ASPs
> become active at there respective SGPs (i.e. ASP1 at SGP1 and ASP2 at
> SGP2), the AS will still not be active. Why? For your view the ASPs
> states would not be shared across SGPs serving a common AS! And the
> minimum required ASPs are 2 for AS to become active!! Do you think,
> that's okay?? Isn't the redundancy model n+k takes the overall view of
> AS at SG to support failover? I guess with your view into
consideration,
> the interoperability would be broken here as the AS would never become
> active.
> 
> Alternatively, let's change the values. N=2 (still!) and K=1 and
> introduce another ASP3 having association with SGP2 but currently
> inactive. Now if SGP1 fails or ASP1 goes down, who do think would
notify
> to ASP3 of insufficient ASPs?(assuming ASPs in AS are not able to
share
> state information). Only SGP2 can do it and without the knowledge of
the
> combined AS view, can it?? And combined AS view at SGP2 can only be
> arrived at with the ASP state sharing!!
> 
> Brian, your views?
> 
> Regards,
>  
> Prabind

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