Re: 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 protected] 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 protected]
http://www.openss7.org/