Re: ASPSM and ASPTM example for SG having multiple SGPs
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Sandeep,
I think duplicate notifications are a really bad idea: it introduces
all manner of races. Consider several NTFY(Alternate ASP Active)'s
on different paths.
Also, I think any new examples should include multiple ASPs as well
as multiple SGPs. (Let's not make the same mistake again.)
--brian
Sandeep Kumar wrote: (Wed, 01 Mar 2006 13:45:16)
> Hi,
>
> As everyone agrees there is a requirement for a document having test
> cases or examples addressing how AS is handled by an SG (multiple
> SGPs) .
>
> Here is a proposal for such kind of example, if it is acceptable, then
> we can prepare similar examples for more scenarios
>
>
> 5.1.5 Single ASP in an Application Server ("1+0" sparing), Two SGPs in an SG
>
> This scenario shows the example M3UA message flows for the
> establishment of traffic between SGPs and an ASP where only one ASP
> is configured within an AS (no backup). Both SGPs are part of an SG and
> they co-ordinate AS state between them.
>
> SGP2 SGP1 ASP1
> | | |
> | |<--------ASP Up---------|
> | |-------ASP Up Ack------>|
> | | |
> | |--NOTIFY(AS-INACTIVE)-->|
> | | |
> |<--------------------------ASP Up----------------|
> |--------------------------ASP Up Ack------------>|
> | | |
> |------------------------NOTIFY(AS-INACTIVE)----->| 1*
> | | |
> | | |
> | |<-------ASP Active------|
> | |------ASP Active Ack--->|
> | | |
> | |---NOTIFY(AS-ACTIVE)--->|
> |------------------------NOTIFY(AS-ACTIVE)------->| 2*
> | | |
> | | |
> |<--------------------------ASP Active------------|
> |--------------------------ASP Active Ack-------->|
> | | |
> | | | 3*
>
> 1* - Duplicate Notify, may not be issued by SGP
> 2* - Duplicate Notify, may not be issued by SGP
> 3* - Here Notify may be issued by SGP
>
>
> 5.3.2 Withdrawal of ASP, Two SGPs in an SG
>
> Following on from the example in Section 5.1.5, and ASP1 withdraws
> from service:
>
> SGP2 SGP1 ASP1
> | | |
> | |<-----ASP Inactive------|
> | |----ASP Inactive Ack--->|
> | | |
> | | | 1*
> | | |
> |<--------------------------ASP Inactive----------|
> |--------------------------ASP Inactive Ack------>|
> | | |
> | |--NOTIFY(AS-PENDING)--->|
> | | |
> |------------------------NOTIFY(AS-PENDING)------>| 2*
> | | |
> | |--NOTIFY(AS-INACTIVE)-->|
> | | |
> |------------------------NOTIFY(AS-INACTIVE)----->| 3*
> | | |
> | | |
> | |<-------ASP Down--------|
> | |------ASP Down Ack----->|
> | | |
> | | |
> |<--------------------------ASP Down--------------|
> |--------------------------ASP Down Ack---------->|
> | | |
> | | |
>
> 1* - AS state will not change, as it is still ACTIVE with another SGP
> 2* - Duplicate Notify, may not be issued by SGP
> 3* - Duplicate Notify, may not be issued by SGP
>
> Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g.,
> M3UA heartbeat loss or detection of SCTP failure), the initial ASP
> Inactive message exchange (i.e., SGP to ASP1) would not occur.
>
> It is very important from interoperability point of view, ASP
> behaviour will also change with decision of doing ASPSM and NOTIFY
> procedures per SG or per SGP.
>
> Thanks,
> Sandeep
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/