Re: Recommendation for SUA modifications
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Lincoln, Please see comments inline. Haresign Lincoln wrote: (Wed, 12 Oct 2005 11:02:09) --X-snip-X-- > > Parameters > Routing Context Optional > | Affected Point Code Conditional *1 > SSN Optional *1 > Congestion Level Mandatory > SMI Optional > Info String Optional > > > | Note 1: For an SCON from the SG to an ASP, when the SSN is included, > the SCON message corresponds to the SCCP N-STATE primitive. > When the SSN is not included, the SCON message corresponds > to the SCCP N-PCSTATE primitive reporting signalling point > or network congestion status. > > | When the SCON is from the ASP to the SG, the affected point > | code is an optional parameter. The SG, if necessary, can > | determine the affected PC from the Routing Context. > --X-snip-X-- The SG cannot determine the PC of messages comming from the ASP by Routing Context. If you think that it can, please detail one procedure that the SG can follow to associate a Point Code with this message when it is received from an ASP. Please bear in mind that an ASP is not restricted to sending messages from the source address that it has registered to receive messages. For example, if ASP A registers AS 1 with Routing key PC 111 and SSN 5, obtaining RC 1, it is permitted to send messages with source address PC 333 SSN 7 labelled with RC 1. There is no restriction in the ASP->SG direction for SCON either. So if the SG cannot get the OPC for the outgoing SS7 message from the SCON, where is it going to get it from? --X-snip-X-- > > Parameters > Routing Context Optional > | Source Address Optional *1 > | Affected Point Code Conditional *1 > | SSN Conditional *1 > Congestion Level Mandatory > SMI Optional > Info String Optional > > > | Note 1: For an SCON from the SG to an ASP, when the SSN is included, > the SCON message corresponds to the SCCP N-STATE primitive. > When the SSN is not included, the SCON message corresponds > to the SCCP N-PCSTATE primitive reporting signalling point > or network congestion status. > > | When the SCON is from the ASP to the SG, the ASP can use > | the source address parameter instead of the Affected Point > | Code parameter. This is used mainly in the case when the > | Routing Keys associated with the ASP may not include a point > | code and/or an SSN. The SG should be able to derive the affected > | PC from the registration information and take any actions > | that might be appropriate to for subsystem congestion in > | the network. > | > | If the ASP is sending Source Address, it is not necessary to > | send SSN and/or Affected Point Code as this information is > | either contained in the source address, or can be derived at > | the SG. > When developing the RFC we considered using Source Address in the SCON; however, as neither the N-STATE or N-PCSTATE can contain a Global Title, we rejected using the Source Address. The situation has not changed. I strongly disagree with both proposals. The motiviation behind them is to modify the SCON message to attempt something that it was never intended to do: communicate ASP congestion. SCON is intended for SS7 congestion only. If you want to develop enhancements for ASP congestion control, please write an extension draft detailing the new protocol elements required and their usage. It might be easier to modify or participate in Kamesh's draft. --brian -- Brian F. G. Bidulock [email protected] http://www.openss7.org/