Re: SUA: Message distribution among Load Shared ASPs (IPSPcase)
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Lincoln, Haresign Lincoln wrote: (Thu, 29 Jun 2006 09:55:47) > > Perhaps I'm missing something. Why would it not work in the multiple SG > scenario? I'm assuming here that the ASP would use the same TID > parameter in the ASPAC message going towards both SGs. TID would require implementnation of both TCAP message decoding and transaction state machines at the STP/SG. This is not appropriate. Nor are STPs normally equipped with general purpose TCAP protocol stacks. TUA provides this capablity at the SG. There is much discussion on this topic on the archives dating all the way back to about 2001. (Also, consider the SUA equivalent problem of your M3UA problem with SI-based routing: one ASP supporting a TID range looses communication with one STP/SG only. Are all of the messages lost? What can the SG do? It cannot send P-Abort because there is no message for a failed TID range. Shoud it send the message to the other STP? What if the ASP for a TID range is isolated from both? With the associated STP send the message back forming a loop? In the M3UA case the STP can track UPU, but there is no equivalent for a TID range.) DRN is very broken for STP/SG. It currently requires the coupling of connection sections at the SG, an unacceptable restriction (SS7 does not require coupling of connection sections at the STP and it is in fact not normally done). The counter-proposal before WGLC on SUA was a registration mechanism whereby connection references could be registered by the ASP on a connection by connection basis with both SG/STP so that coupling of connection sections at the STP would not be the only way to support protocol classes 2 and 3. Without this support, SUA is incapable of providing seamless or transparent interworking for protocol classes 2 and 3. Again, there is also much discussion on this topic dating back to 2001. (Note that coupling is also unnecessarily required at every IPSP relay point.) Both are quite broken. DRN can be fixed. TID cannot. Labels should be done away (or at least made strictly OPTIONAL) for the all scenarios and support for error situations need to be added to make them even workable as an option. See the threads. --brian -- Brian F. G. Bidulock [email protected] http://www.openss7.org/