RE: ASPSM and ASPTM example for SG having multiple SGPs
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Sandeep,
I completely agree that examples are necessary. OTOH, I think first we need
to decide what is the "best" semantics.
I really think we should discuss with an open-mind what the NTFY/traffic
distribution semantics should be for multiple SGP cases. I am in favor of
having all ASPSM/ASPTM per SGP. For NTFY, I think we may have a bit more
flexibility, considering its advisory nature. BTW, are ASPs relying on
NTFY("AS State Change") notifications for any decision, it seems to me they
shouldn't but there may be some which do in practice. It could be also good
to get some feedback from more people about that.
Thanks,
Tolga
> -----Original Message-----
> From: Sandeep Kumar [mailto:[email protected]]
> Sent: Wednesday, March 01, 2006 3:15 AM
> To: [email protected]
> Subject: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs
>
>
> 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
>