Re: Optional ASP-ID in M3UA
"Ambika Tripathy" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Hi Brain,
This if the below statement is true and ASPID is optionally configured
and in the loadshare mode one ASP has failed, how can the SG will notify
which ASP is failed?
*2. Four ASPs serve an AS, e.g. in loadshare mode. The SG reports ASP
failure in the AS. The ASPs cannot know for certain to which ASP
the SG refers unless they provide ASP-ID with ASP-UP. Therefore, when
the ASP provides ASP-ID in ASP-UP, the SG must store the value and use
it when reporting ASP Failure in a NOTIFY message*
**
If in loadshare mode, if we configure ASP ID is optional and Notify
procedure is optional it will be difficult to update the status of AS if I
am not wrong.
Or is there any other procedure problem to resolve it. Please let me know.
--
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730
On 3/12/08, Brian F. G. Bidulock <[email protected]> wrote:
>
> Ambika,
>
> Ambika Tripathy wrote: (Wed, 12 Mar 2008 12:19:33)
> >
> > Why there is ASPID in protocol and what is need then?
>
> 1. Two ASPs are implemetned, each as a separate process on the same host.
> Each connects to the same SGP using dynamic port allocation (e.g. binds
> to port 0). The SGP cannot distinguish between them based on IP
> addresses
> (which are the same) nor port number (of which the SGP has no a priori
> knowledge). In such a case the SGP can require an ASP-ID.
>
> 2. Four ASPs serve an AS, e.g. in loadshare mode. The SG reports ASP
> failure in the AS. The ASPs cannot know for certain to which ASP
> the SG refers unless they provide ASP-ID with ASP-UP. Therefore, when
> the ASP provides ASP-ID in ASP-UP, the SG must store the value and use
> it when reporting ASP Failure in a NOTIFY message.
>
> But both these situations are mentioned in the RFC.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran