RE: Congestion in M3UA/SUA and the use of the SCON
"Haresign Lincoln" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <849535E338E99741B7F7413F73253EDB0249FAC8@us-nj-mail1.comverse.com> |
Brian, I certainly don't expect anyone outside fo Comverse to design our SW. We are extremely successful at that deployed in 100s of networks and thousands of deployments throughtout the world. I'm not sure where you are getting that from or why you would even suggest it. What I do expect is that if a committee is going to come out with a standard, then that committee should be willing to: 1) accept improvements 2) accept compliments 3) accept criticism As I stated, the SIGTRAN RFCs are quite good for their age and my hats off to the contributors. In my humble opinion, I believe we can make improvements in the specifications. At the moment, I'll focus on the SUA specification. This is not related to "nodal TFCs". It is related to subsystem management and how that applies to SCON messages from the ASP. The ability to send an SCON from the ASP exists today in the spec. I've already outlined two problems with this in SUA. I will propose alternate text. Regards, Lincoln -----Original Message----- From: Brian F. G. Bidulock [mailto:[email protected]] Sent: Thursday, October 06, 2005 1:54 PM To: Haresign Lincoln Cc: Tolga Asveren; [email protected] Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON Haresign, Haresign Lincoln wrote: (Thu, 06 Oct 2005 10:21:48) > Tolga, > > [TOLGA]:Does anybody know the rationale behind sending SCON from ASP > to SG when ASP -not the M3UA layer of ASP but something else- is congested? > > The rationale would be that the ASP is congested at the layer above > M3UA and you want to reduce or eliminate new traffic. I can give you > several more concrete examples if you want them. There are many > reasons why an ASP would want to indicate congestion. User part (and subsystem) applications must use their own measures for flow control within the user part (and subsystem). These things are for SS7 network and protocol congestion, not application congestion. > > > [lincoln]: Where is this documented? > [TOLGA]Probably nowhere in official documents, I happen to know about > it just because I could remember -hopefully correctly- the discussions > about whether SCON from ASP to SG should be allowed or not. Could be > an idea to mention about it somewhere. > > And if the specs don't specify something, then it's not in the specs. > Period. I don't think there is any getting around that one. ANSI T1.111.4/2000 specifies the conditions under which an SS7 signalling point can send a "nodal TFC" as a result of the congestion of the Signalling Message Handling function. The SS7 documents are Normative. SCON in the ASP->SG direction was intended to provide a protocol mechanism to allow "nodal TFC", primarily in the multiple SG as STP case (similar to DRST which is also only used in the mutliple SG as STP scenario). It has no other use. As "nodal TFC" itself is optional to send in SS7, SCON ASP->SG must obviously be optional in M3UA/SUA. Also, because the SG is responsible for policy towards the SS7 network (and other MTP- or SCCP-Users), the SG does not need to respond to it or take any action on it whatsoever, unless it wishes to. If you cannnot figure out how to use it don't. Nobody is requiring you to use it. If you would like someone to design your SG for you, do no expect the specification to do so. --brian -- Brian F. G. Bidulock [email protected] http://www.openss7.org/ ______________________________________________________________________ This email message has been scanned by PineApp Mail-Secure and has been found clean.