Re: Recommendation for SUA modifications
"Samuel Dur D. Jeyaseelan" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <Pine.SOL.4.10.10510140941540.28448-100000@ssdtcom01.ssd.usa.alcatel.com> |
Sigtran, M3UA rfc also has the same 'congestion' problem, will it be modified as per this thread ? --Samuel Alcatel USA, Inc. Internet: <userid>@ssd.usa.alcatel.com 1000 Coit Road, Plano, Texas 75075 ******* The opinions expressed are not those of Alcatel USA, Inc. ******* On Fri, 14 Oct 2005, Brian F. G. Bidulock wrote: > 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. > > > ...etc. > > > 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/ > > _______________________________________________ > Sigtran mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/sigtran >