RE: Recommendation for SUA modifications
"Haresign Lincoln" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <849535E338E99741B7F7413F73253EDB02544A56@us-nj-mail1.comverse.com> |
Brian, Personally, I am not tied to SCON. Initially I asked if SCON can by used for ASP congestion and you seemed to imply that it could in our first exchange. I then tried to resolve the problems with the RFC. If you want to use the ASP Status message, I have absolutely no problem with this solution and would back it 100%. We should indicate in the SUA IG that SCON can not be used for ASP->SG congestion as is currently stated in the RFC. WG, Moving forwards, there are now two proposals on the table: 1) Add a new message (as outlined below) 2) Modify the SCON (as I have outlined in previous emails) I'm willing to support either solution 100%. In either case, we may want to discuss the actual wording. But in principle, I'm happy with both solutions. Regards, Lincoln -----Original Message----- From: Brian F. G. Bidulock [mailto:[email protected]] Sent: Friday, October 14, 2005 9:46 AM To: Haresign Lincoln Cc: Valerie Gastaud; [email protected]; [email protected]; [email protected] Subject: Re: [Sigtran] Recommendation for SUA modifications Haresign, Signalling ASP congestion with SCON is a misuse of SCON. Define some ASPTM messages to do the job. ASPTM messages are only indexed off of Routing Context, do not contain any addresses, and can use their own congestion level definition. Leave SCON alone. Here you go: ASP Traffic Maintenance (ASPTM) Messages 0 Reserved 1 ASP Active (ACTIVE) 2 ASP Inactive (INACTIVE) 3 ASP Active Ack (ACTIVE ACK) 4 ASP Inactive Ack (INACTIVE ACK) > 5 ASP Status (STATUS) > 6 ASP Status Qry (STATUS QRY) 7 - 127 Reserved by the IETF 128 - 255 Reserved for IETF-Defined Message Class Extensions >3.6.5. ASP Status (STATUS) > > The ASPST message is sent by an ASP to indicate to a remote SUA peer > that it is experiencing congestion in processing signalling traffic > for a particular Application Server. > > The format for the STATUS message is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tag = 0x0006 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / Routing Context / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tag = 0x0019 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / ASP Congestion / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tag = 0x0110 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / Info String / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Parameters > Routing Context Optional > ASP Congestion Mandatory > Info String Optional > >3.6.4. ASP Status Qry (STATUS QRY) > > The STATUS QRY message is used to request an ASP-Status message from > a remote SUA peer indicating the current congestion of the remote > ASP. > > The format for the STATUS Qry message is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tag = 0x0006 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / Routing Context / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tag = 0x0004 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / INFO String / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Parameters > Routing Context Optional > INFO String Optional 3.9. Common Parameters These TLV parameters are common across the different adaptation layers. Parameter Name Parameter ID ============== ============ Reserved 0x0000 Not used in SUA 0x0001 Not used in SUA 0x0002 Not used in SUA 0x0003 Info String 0x0004 Not used in SUA 0x0005 Routing Context 0x0006 Diagnostic Info 0x0007 Not used in SUA 0x0008 Heartbeat Data 0x0009 Not Used in SUA 0x000A Traffic Mode Type 0x000B Error Code 0x000C Status 0x000D Not used in SUA 0x000E Not used in SUA 0x000F Not used in SUA 0x0010 ASP Identifier 0x0011 Affected Point Code 0x0012 Correlation ID 0x0013 Registration Result 0x0014 Deregistration Result 0x0015 Registration Status 0x0016 Deregistration Status 0x0017 Local Routing Key Identifier 0x0018 > ASP Congestion 0x0019 The ASP/IPSP state transition diagram is shown in Figure 1. The possible states of an ASP/IPSP are: ASP-DOWN: The remote SUA peer at the ASP/IPSP is unavailable and/or the related SCTP association is down. Initially all ASPs/IPSPs will be in this state. An ASP/IPSP in this state SHOULD NOT be sent any SUA messages, with the exception of Heartbeat, ASP Down Ack and Error messages. ASP-INACTIVE: The remote SUA peer at the ASP/IPSP is available (and the related SCTP association is up) but application traffic is stopped. In this state the ASP/IPSP SHOULD NOT be sent any DATA or SSNM messages for the AS for which the ASP/IPSP is inactive. ASP-ACTIVE: The remote SUA peer at the ASP/IPSP is available and application traffic is active (for a particular Routing Context or set of Routing Contexts). > ASP-CONGESTED: The remote SUA peer at the ASP/IPSP is available and > application traffic is active (for a particular Routing Context or > set of Routing Contexts), however, the ASP is experiencing congestion > related to one or more Routing Contexts. Figure 1: ASP/IPSP State Transition Diagram, per AS | +--------------+ +---------------+ | | | ASPST | | | +----------------------| ASP-ACTIVE |<------->| ASP-CONGESTED | | | Other ASP/ +-------| | | | | | IPSP in AS | +--------------+ +---------------+ | | Overrides | ^ | | | | | | |<---------------------+ | | ASPAC/ | | ASPIA/ | |[ASPAC-Ack]| | [ASPIA-Ack] | | | v | | +--------------+ | | | | | +------>| ASP-INACTIVE | | | | | +--------------+ | ^ | ASPDN/ | | | ASPDN / [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /] SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/ SCTP RI | | | SCTP RI | | v | +--------------+ | | | +--------------------->| ASP-DOWN | | | +--------------+ The possible states of an AS are: AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state. An Application Server is in the AS-DOWN state before it can be removed from a configuration. AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP-INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired. AS-ACTIVE : The Application Server is available and application traffic is active. This state implies that at least one ASP is in the ASP-ACTIVE state. > AS-CONGESTED: The Application Server is available and application > traffic is active, however at least one ASP is in the > ASP-CONGESTED state for the AS. AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP- DOWN and it was the last remaining active ASP in the AS. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages will be sent to the ASP. 4.3.4.7 ASP Status Procedures At any time that an ASP/IPSP is in the ASP-ACTIVE or ASP-CONGESTED states for an AS, it can send an ASP Status message updating then congestion level, or abatement of congestion, using the ASP Congestion parameter contained in the message and pertaining to the included Routing Context(s). Upon receipt of an ASP Status message, an SG/IPSP MAY take actions with regard to ASP congestion giving consideration for the congestion and active statuses of the other ASPs/IPSPs in the AS. Actions could, for example, include the redirection or redistribution of traffic within a Load-Sharing AS. 4.3.4.8 ASP Status Qry Procedures At any time that an ASP/IPSP is in the ASP-ACTIVE or ASP-CONGESTED states for an AS, the peer SG/IPSP can send an ASP Status Qry message querying the congestion state of the remote ASP/IPSP for the Application Servers indicated by the Routing Context(s) contained in the query. Upon receipt of an ASP Status Query message, if the ASP/IPSP is in the ASP-ACTIVE or ASP-CONGESTED states for the indicated AS, the ASP/IPSP MUST respond with an ASP Status message indicating the current congestion status for the AS. Note that because only one ASP Congestion parameter is contained in the ASP Status message, that multiple ASP Status messages might be required in response to a single ASP Status Qry message. Fill in your own proprietary SG practices here. --brian Haresign Lincoln wrote: (Fri, 14 Oct 2005 09:18:59) > Brian, > > You still have not addressed how to handle _ASP congestion_ in the two > scenarios below. I have. > > At this point, I seem to have the agreement of several other members > of the WG. You seem to be the only person opposed to making affected > point code optional. I think Valerie's suggestion was a good one. > > I'm not sure this exchange is practical anymore since you and I have a > basic disagreement over how to solve a problem. I've presented a > solution. If you have another one, I'd be welcome to listen to it. > But in lieu of another solution to the two problems outlined below, it > is my opinion that this exchange is no longer serving a practical > purpose. I look forward to feedback from other members of the WG and > the SUA IG editors. > > Thanks for all your feedback. > -- 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.