Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 Corporation Intended status:PROPOSED STANDARD February 3, 2007 Expires in August 2007 ASP Congestion (ASPCONG) for Signalling User Adaptation Layers Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in August 2007. Copyright Copyright (C) The IETF Trust (2007). Abstract This memo describes ASP Congestion (ASPCONG) that provides the ability for an Application Server Process (ASP) to indicate congestion to a Signalling Gateway (SG) for the SS7 Signalling User Adaptation Layers [M2UA], [M3UA], [SUA], [ISUA], [TUA]. Extension parameters and procedures are added by this memo in extension to those of the User Adaptation layers to provide for ASP congestion. B. Bidulock Version 0.1 Page 1 Internet Draft UA ASPCONG February 3, 2007 1. Introduction 1.1. Scope This Internet-Draft describes ASP Congestion (ASPCONG) procedures to support the management of congestion and flow control between a Signalling Gateway (SG) and an Application Server (AS) across SCTP [SCTP], [SCTPCRC], [SCTPIG] associations for SS7 [Q.700] Signalling User Adaptation Protocols [M2UA], [M3UA], [SUA], [ISUA], [TUA] supporting the concept of a Routing Context or Interface Identifier. These procedures permit the coordination of ASP Congestion on traffic directed at an Application Server (AS) via an Application Server Process (ASP) from a Signalling Gateway Process (SGP) and supports the coordination of AS Congestion into a coordinated network view at a Signalling Gateway (SG) toward the SS7 network. UA implementations utilizing ASPCONG are intended to be compatible with UA implementations not support the configuration; however, the full benefits achieved by the ASPCONG procedures will not be realized unless implementations at both endpoints implement ASPCONG. 1.2. Abbreviations AS -- Application Server. ASP -- Application Server Process. CORID -- Correlation Id Extension IANA -- Internet Assigned Numbers Authority I-D -- Internet-Draft IETF -- Internet Engineering Task Force IP -- Internet Protocol. IPSP -- IP Signalling Point. LIF -- Local Interworking Function. NIF -- Nodal Interworking Function. SCCP -- Signalling Connection Control Part. SCTP -- Stream Control Transmission Protocol. SG -- Signalling Gateway. SGP -- Signalling Gateway Process. SIGTRAN -- IETF Signalling Transport WG SPP -- Signalling Peer Process. SS7 -- Signalling System No. 7. SUA -- SS7 SCCP-User Adaptation Layer. TCAP -- Transaction Capabilities Application Part. TUA -- SS7 TCAP-User Adaptation Layer. UA -- User Adaptation Layer. WG -- Working Group 1.3. Terminology ASPCONG supplements the terminology used in the UA documents [M2UA], [M3UA], [SUA], [ISUA], [TUA] by adding the following terms: B. Bidulock Version 0.1 Page 2 Internet Draft UA ASPCONG February 3, 2007 Accepted Rate - the rate in number of messages (or message octets) per unit time that are removed from a buffer used to queue messages from one functional unit to another. Offered Rate - the rate in number of messages (or message octets) per unit time that are placed into a buffer used to queue messages from one functional unit to another. Buffer Occupancy - refers to the degree of fill experienced a buffer used to queue messages from one functional unit to another. If the Offered Rate exceeds the Accepted Rate, Buffer Occupancy will, by definition, be increasing; the Offered Rate is less than the Accepted Rate, Buffer Occupancy decreases; when equal, the Buffer Occupancy does not change. Local Interworking Function (LIF) - refers to the function that converts between the lower-layer interface of the UA protocol layer at the ASP and the upper-layer SS7 protocol interface to an Application Server (AS) at served by the ASP. Nodal Interworking Function (NIF) - refers to the function that converts between the upper-layer interface of an SS7 protocol stack at an SGP and the UA protocol layer at the SGP. Signalling Endpoint (SEP) - in this document, a Signalling Endpoint is an SS7 SEP [Q.700] or an Application Server. Signalling Peer Process (SPP) - refers to an ASP, SGP or IPSP. Signalling User Adaptation Layer (UA) - one or more of the Stream Control Transmission Protocol (SCTP) [SCTP], [SCTPCRC], [SCTPIG] SS7 Signalling User Adaptation Layers [M2UA], [M3UA], [SUA], [ISUA], [TUA] supporting the Correlation Id parameter and the BEAT message. 1.4. Overview There are a number of possible mechanisms that can be used to determine congestion toward SS7-Users at an SGP and at an ASP that permit the SG to correlate congestion and present it toward the SS7 network on a basis that followed applicable SS7 standards. This document provides protocol elements within the SS7 User Adaptation Layers (UAs) to assist in the detection of congestion toward SS7 Users at an ASP and that communicate the detection to an SGP for use by the SG in presenting a network view of SS7-User congestion toward the SS7 network. 1.4.1. ASP Congestion ASP Congestion is defined as the situation where an Application Server at an ASP is not accepting signalling messaging traffic at the rate at which it is being offered by an SGP. ASP Congestion only includes the congestion experienced by signalling messaging traffic B. Bidulock Version 0.1 Page 3 Internet Draft UA ASPCONG February 3, 2007 that is directed from a given SGP toward a specific Application Server, via a specific ASP. As such, ASP Congestion can be identified by the 3-tuple of the SGP, AS and ASP. Because there is a 1:1:1 relationship between an RK, and AS, and an RC (or IID), and since there is no more than one SCTP Association for any given SGP-ASP relation, ASP Congestion relates to traffic with a specific RC (or IID) on a given SCTP association. ASP Congestion does not include congestion in signalling messaging traffic flow from the ASP toward the SGP. 1.4.1.1. Points of Detection ASP Congestion can occur at an SGP within the Nodal Interworking Function (NIF), at an SGP within the UA layer at the SGP, within the IP network for a given SCTP association, or at an ASP within the UA layer at the ASP. Congestion or flow control above the UA layer at the ASP, or within an SS7 protocol stack at the SGP are not included under the term ASP Congestion. 1.4.1.2. Models for Detection Methods for detection of ASP Congestion at the various detection points are, of course, implementation specific. That is, the method of detection cannot be specified without knowledge of the actual implementation at the detection point. Nevertheless, models for detection are here presented. 1.4.1.2.1. Detection at the SGP At the SGP, the flow of traffic between the SS7 protocol stack and the UA protocol layer at the SGP can be viewed as traversing a Nodal Interworking Function (NIF) that resides between the SS7 protocol stack and the UA protocol layer. The interface (if one exists) between the NIF and the UA Protocol Layer can be modelled as a set of message queues, one for each SGP-ASP-AS traffic flow. Detection of ASP Congestion at the interface between the NIF and the UA protocol layer at the SGP could then be modelled as detecting the buffer occupancy of a specific message queue (corresponding to a specific SGP-ASP-AS traffic flow) across the interface. Any number of congestion levels could be effected by establishing a set of congestion onset and abatement thresholds. In this document when reference is made to detecting ASP Congestion within the NIF at an SGP, it is this model for detection that is being cited. In a similar way, at the SGP, the flow of traffic between the UA protocol layer and the SCTP association between SGP and ASP, can be viewed as traversing the SCTP transport endpoint functions corresponding to the transmit side of the SCTP association at the SGP. Detection of ASP Congestion at the interface between the UA protocol layer and SCTP at the SGP could then be modelled as detecting buffer B. Bidulock Version 0.1 Page 4 Internet Draft UA ASPCONG February 3, 2007 occupancy of a specific message queue (corresponding to a specific SGP-ASP-AS traffic flow) across the interface. Again, any number of congestion levels could be effected by establishing a set of congestion onset and abatement thresholds. In this document when reference is made to detecting ASP Congestion at the SCTP send buffer, it is this model for detection that is being cited. Congestion below the interface between the SS7 stack and the NIF (e.g. congestion within the SS7 stack proper), is not considered part of ASP Congestion, but is considered as congestion within the SS7 Provider layer for the corresponding UA. 1.4.1.2.2. Detection at the ASP At the ASP, the flow of traffic between the SCTP association from an SGP and the UA protocol layer at the ASP, can be viewed as traversing the SCTP transport endpoint functions corresponding to the receive side of the SCTP association at the ASP. Detection of ASP Congestion at the interface between SCTP and the UA protocol layer at the ASP could then be modelled as detecting buffer occupancy of a specific message queue (corresponding to a specific SGP-ASP-AS traffic flow) across the interface. Any number of congestion levels could be effected by establishing a set of congestion onset and abatement thresholds. In this document when reference is made to detecting ASP Congestion at the SCTP receive buffer, it is this model for detection that is being cited. In yet a similar way, at the ASP, the flow of traffic between the UA protocol layer and the Application Server can be viewed as traversing a Local Interworking Function (LIF) that resides between the UA protocol layer and the upper-layer SS7 protocol stack. The interface (if one exists) between the LIF and the Application Server can be modelled as a set of message queues, one for each SGP-ASP-AS traffic flow. Detection of ASP Congestion at the interface between the LIF and the AS at the ASP could then be modelled as detecting the buffer occupancy of a specific message queue (corresponding to a specific SGP-ASP-AS traffic flow) across the interface. Also, any number of congestion levels could be effected by establishing a set of congestion onset and abatement thresholds. In this document when reference is made to detecting ASP Congestion within the LIF at an ASP, it is this model for detection that is being cited. Congestion beyond the interface between the UA protocol layer and the Application Server (e.g. congestion within the Application Server function itself), is not considered as part of ASP Congestion, but is considered as congestion within the SS7 User layer for the corresponding UA. B. Bidulock Version 0.1 Page 5 Internet Draft UA ASPCONG February 3, 2007 1.5. Sample Configurations (This section will include some diagrams indicating the placement of NIF and LIF functions, the location of SCTP send and receive buffers in relation to the UA protocol layer, the SS7 stack and the Application Server at both the SGP and the ASP.) 1.6. ASP Congestion Management ASP Congestion management is performed at both the SG and the ASP. For proper interworking, protocol elements are used between the ASP and the SGP, and a set of procedures are provided for the management of ASP Congestion. 1.6.1. ASP Congestion Management at an ASP ASP Congestion can be detected at an ASP (as described in section "Detection at the ASP") at the SCTP receive buffer or within the LIF. Whenever an ASP detects a change in congestion toward an AS (ASP Congestion), and the ASP is in the ASP-ACTIVE state with the sending SGP for the corresponding Application Server, it sends an ASP Status message to the sending SGP with the level of congestion indicated in the ASP Congestion parameter contained in the message. While detecting ASP Congestion and sending ASP Status messages indicating congestion to the SGP, the ASP SHOULD NOT discard messages with a priority or importance beneath that of the indicated congestion level. It should be left to the SG to determine which messages should subsequently be discarded as part of whatever procedures are necessary toward the SS7 network. Whenever an ASP receives a NTFY ("AS-CONGESTED") message from an SG indicating that an AS served by the ASP is congested, it is not compelled to take any action. Each ASP that receives the message SHOULD, however, determine whether it can bring additional resources to bear that will relieve the congestion of the Application Server.<1> 1.6.2. ASP Congestion Management at an SGP ASP Congestion can be detected at an SGP (as described in section "Detection at the SGP") within the NIF or at the SCTP send buffer. Also, an SGP can use receipt of an ASPSTAT message as indication of ASP Congestion detected at the ASP. Each SGP maintains an ASP state for each AS at each ASP that the SGP serves. In addition to the activation state of an ASP within an AS, ASPCONG requires that each SGP maintain a congestion level associated with each ASP within each AS. Also, each SG maintains an overall AS state for each AS served by the SG. In addition to the activate state of an AS, ASPCONG requires that each SG maintain a congestion level associated with each AS served by the SG. B. Bidulock Version 0.1 Page 6 Internet Draft UA ASPCONG February 3, 2007 The SG uses the activation state of individual ASPs within AS served by the SG to determine the overall AS state in accordance with the UA state machine (which is similar if not identical for all UAs discussed here). ASPCONG adds the requirement that the SG determine the overall AS congestion status by considering each ASP congestion status within the AS. This is performed in accordance with the state machine procedures of Section 4. The SG uses the activation state of AS server by the SG to present a coordinated network view of the activation served AS toward the SS7 network using standard SS7 procedures. ASPCONG requires that each SG also present a coordinated network view of the congestion status of served AS toward the SS7 network, also using standard SS7 procedures. Whenever an SG determines that the overall congestion status of an Application Server has changed, it notifies all ASPs in the AS-ACTIVE or AS-INACTIVE state for the AS using a NTFY ("AS-CONGESTION") message that contains the ASP Congestion parameter indicating the new congestion Level for the AS. Note that the change in AS congestion status determined by an SG could result either from detection of ASP Congestion local to the SGP, or from receipt of an ASPSTAT message from an ASP indicating ASP Congestion. Once the SG has indicated AS congestion to an AS, it MAY discard messages and provide protocol congestion indications toward the SS7 network in accordance with relevant SS7 standards<2>, but, regardless of the actions taken by the SG toward the SS7 network, the SG SHOULD cease passing traffic toward the congested AS at a priority or importance level lower than the congestion level. 1.7. Issues Although the mechanism presented in this document provides some essential protocol capabilities to the SS7 User Adaptation Layers (UAs) for use in detecting and reporting SS7 User congestion from an ASP to an SGP, a number of issues associated with this approach remain: (1) The UA protocols were designed to permit a Nodal Interworking Function (NIF) to be placed over an existing SS7 protocol layer provider and, using only the primitives and interface to the SS7-Provider that is available to a normal SS7-User as described by the SS7 standards, provide the functions necessary to implement a Signalling Gateway (SG) in the back-haul SG/ASP configuration. The ASPSTAT message would remove this ability. Because the UAs permitted an SG to be implemented over an existing SS7 protocol stack, details of the NIF, and details of the interfaces between the SS7-Provider and the NIF were avoided. B. Bidulock Version 0.1 Page 7 Internet Draft UA ASPCONG February 3, 2007 The ASPSTAT message would require both a description of the NIF as well as details of the additional capabilities required of an SS7 provider a the interface between the NIF and the SS7 provider. (2) Typically, within an SS7 provider implementation, congestion toward an SS7-User is determined within the SS7 provider protocol layer using implementation dependent means. Nevertheless, each SS7 protocol layer provides specific congestion onset and abatement thresholds that are managed within the SS7 protocol layer. Use of the ASPSTAT would require that the management of onset and abatement thresholds span multiple devices, multiple queues and buffers, and also span the SCTP transport carrying traffic. This would make the task of managing onset and abatement thresholds problematic for SS7 network operators. A mechanism where the management of onset and abatement thresholds are contained within the SG if not within the SS7 provider layer is far more preferable than the arrangement required by the ASPSTAT message. (3) The UAs have an existing optional mechanism for communicating SS7 User congestion to the SG. For [M3UA], [SUA], [ISUA], [TUA] that mechanism is the use of the SCON message in the ASP to SG direction. For [M2UA] it is the use of the Status Request message. Adoption of ASPSTAT message would likely require the removal of that mechanism so that it does not conflict with the ASPSTAT mechanism. (4) Use of the ASP Status procedures at the SG for redistribution of traffic within an AS can be dangerous. Without proper knowledge about the load characteristics of the ASPs serving an AS, an SG could provoke rapid oscillations in load distribution across the ASP pool. Although some techniques could be used at the SG to mitigate this (e.g. providing a long duration between switch-overs), all of the UAs follow the principle that traffic decisions are best made by the ASPs rather than at the SG. In fitting with this principle, use of the Notify procedures in conjunction with the [LOADSEL] or [LOADGRP] approach to ASP management of load sharing selection and grouping would allow the ASPs to activate an alternate load selection and grouping in response to congestion that could not be afforded by redistribution at the SG. B. Bidulock Version 0.1 Page 8 Internet Draft UA ASPCONG February 3, 2007 1.8. Conclusions The following conclusions have been reached regarding the mechanisms described in this document. (1) Giving considerations to the issues with the ASPSTAT message described in the previous section, use of the ASPSTAT message at the SGP and SG should be completely OPTIONAL. This permits an implementation that uses an existing SS7 protocol stack implementation to use other mechanisms local to the SG for effecting proper SS7 User congestion controls. (2) Considering that an existing SS7 protocol stack implementation can give indications about SS7 User congestion to SS7 management at the node using a management interface, it is likely possible to implement the NTFY (AS-CONGESTED) procedures at the SG without having to describe the NIF and the NIF/SS7-Provider interface in detail. Therefore, the Notify procedures should be RECOMMENDED. These procedures afford notification of ASPs that in the ASP-INACTIVE state for an AS of the congestion status of the AS a effected by the SG, and permit the ASPs serving the AS to take actions with regard to traffic in the AS (e.g. bringing an ASP from the ASP-INACTIVE state to the ASP-ACTIVE state to relieve the congestion). Note that the Notify procedures do not compel an ASP to take action, but the procedure provides additional information that can enable effective ASP management at the ASP pool. (3) Danger of suboptimal load balancing at the SG resulting from redistribution of traffic from the SG toward an AS and the ensuing message loss and mis-sequencing is justification for making load redistribution in response to AS congestion at the SG NOT RECOMMENDED. If performed at all, load redistribution SHOULD be performed using [LOADSEL] and [LOADGRP] in conjunction with [CORID] (to minimize message loss and mis- sequencing) by the ASPs in response to the Notify procedures outlined in this document, and the SG SHOULD NOT perform load redistribution on its own. (4) provides some adjustments to the HEARTBEAT mechanism that can be used effectively by the SG to determine congestion toward the SS7 User at the ASP, while retaining the management of congestion onset and abatement levels on the SG. In particular, [CORID] provides that a HEARTBEAT sent within an Application Server traffic flow MUST not be responded to by the ASP until the messages in the traffic flow before it have be accepted by the SS7 User (Application Server) at the ASP. This mechanism can be used periodically by the SG to determine the amount of outstanding signalling messages toward the SS7 User and apply SG managed thresholds. The HEARTBEAT mechanism from [CORID] SHOULD be used instead of the ASPSTAT mechanism described here. B. Bidulock Version 0.1 Page 9 Internet Draft UA ASPCONG February 3, 2007 Notes for Section 1 <1> IMPLEMENTATION NOTE:- Actions taken by an ASP in response to a NTFY ("AS-CONGESTED") message might include, for example, an ASP in the ASP-INACTIVE state for a Load Sharing AS moving itself to the ASP-ACTIVE state for the AS using the ASPAC message; or it might include an already active ASP bringing additional redundant AS processors on-line to service the overload. <2> IMPLEMENTATION NOTE:- Note that one way to effect indications of congestion under proper conditions toward the SS7 network using an existing SS7 protocol stack and user interface implementation that does not include a mechanism for requesting congestion downward across the SS7/SS7-User interface, is to cease accepting messages for the affected traffic flow from the SS7/SS7-User interface. This could trigger the SS7-Provider's own congestion procedures in an appropriate manner. <3> IMPLEMENTATION NOTE:- Note that it is NOT RECOMMENDED that an SG redistribute traffic within a Load Share AS. Doing so could cause congestive oscillation between the various ASPs that are active within the Load Share AS. Based on ASP Congestion detected within the SCTP receive buffer or LIF at an ASP, it might be tempting to have an SG decide to redistribute the transmission of traffic over the ASPs in a Load Share AS, however, this is NOT RECOMMENDED: oscillations could occur as a result of this action between the ASPs in a Load Share AS. Based on ASP Congestion detected within the NIF or SCTP send buffer at an SGP, it might also be tempting to have an SG decide to redistribute the transmission of traffic from the SGP that make up the SG, however, this is NOT RECOMMENDED for the same reason (oscillation could occur between the SGP). Any redistribution of traffic with a Load Share AS, or within an Active-Standby AS should result for the activation or deactivate of an ASP within the AS, and then, the procedures of [CORID] SHOULD be followed to avoid message loss, duplication or mis-sequencing. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Protocol Elements The following protocol element definitions are provided by ASPCONG in extension to the existing protocol element definitions for the UAs [M2UA], [M3UA], [SUA], [ISUA], [TUA]. B. Bidulock Version 0.1 Page 10 Internet Draft UA ASPCONG February 3, 2007 3.1. Parameters The following subsections describe the parameters used for APSCONG, their format and the message in which they are used. 3.1.1. ASP Congestion Level The ASP Congestion Level parameter is used in the ASPSTAT message. It is used in the ASPSTAT message to identify the level of congestion currently experienced by the ASP. The ASP Congestion parameter is formatted 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 = 0xXXXX | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | ASP Congestion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ASP Congestion parameter contains the following field: ASP Congestion field: 4 bytes The ASP Congestion field is formatted 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Level| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved field: 29-bits The Reserved field is reserved, MUST be ignored by the receiving SG, and SHOULD be coded zero by the sending ASP. Level field: 3-bits (unsigned integer) The Level field is used by the sending ASP to indicate the current congestion level at the ASP for the indicated AS. This field can take on values from 0 through 7 (inclusive) and is used to indicated the current congestion level of the AS. The value 0 always indicates "no congestion". For [M2UA], the values of the Level field are interpreted in accordance with [Q.703], [T1.111] as follows: B. Bidulock Version 0.1 Page 11 Internet Draft UA ASPCONG February 3, 2007 0 no congestion 1 congestion-accept 2 congestion-discard 3-7 reserved For [M3UA], the values of the Level field are interpreted in accordance with [T1.111], [Q.704] as follows: 0 no congestion 1 congestion level 1 2 congestion level 2 3 congestion level 3 4-7 reserved For [SUA], [TUA], the values of the Level field are interpreted in accordance with [Q.714], [T1.112], [Q.774], [T1.114] as follows: 0 no congestion 1 restricted importance level 1 2 restricted importance level 2 3 restricted importance level 3 4 restricted importance level 4 5 restricted importance level 5 6 restricted importance level 6 7 restricted importance level 7 For [ISUA], the values of the Level field are interpreted in accordance with [Q.764], [T1.113] as follows: 0 no congestion 1 automatic congestion level 1 2 automatic congestion level 2 3 automatic congestion level 3 4-7 reserved Note that some switches use only two levels of ACL, others use three. 3.1.2. Status ASPCONG extends the Status parameter used in the NTFY message as follows: If the Status Type is AS_STATE_CHANGE, then the Status ID (16 bit unsigned integer) values are: B. Bidulock Version 0.1 Page 12 Internet Draft UA ASPCONG February 3, 2007 1 reserved 2 Application Server Inactive (AS-Inactive) 3 Application Server Active (AS-Active) 4 Application Server Pending (AS-Pending) 5 Application Server Congested (AS-Congested) These notifications are sent from an SGP to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the Application Server. 3.2. Messages ASPCONG adds two messages (ASPSTAT and ASPSTAT QRY) to the ASPTM class of messages as follows: Application Server Process Traffic Maintenance (ASPTM) Messages 0 Reserved 1 ASP Active (ASPAC) 2 ASP Inactive (ASPIA) 3 ASP Active Ack (ASPAC ACK) 4 ASP Inactive Ack (ASPIA ACK) 5 ASP Status (ASPSTAT) 6 ASP Status Query (ASPSTST QRY) 7 - 127 Reserved by the IETF 128 - 255 Reserved for IETF-Defined Message Class Extensions ASPCONG also modifies the ACTIVE and NTFY messages as follows: 3.2.1. ASP Active (ACTIVE) The ASPAC message is sent by an ASP to indicate to an SGP that it is Active and ready to process signalling traffic for a particular Application Server. The format of the ACTIVE message is as follows: B. Bidulock Version 0.1 Page 13 Internet Draft UA ASPCONG February 3, 2007 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 = 0x000B | Length = 8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Traffic Mode Type | +-------------------------------+-------------------------------+ | Tag = 0x0006 | Length = 8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Routing Context | +-------------------------------+-------------------------------+ | Tag = 0x0001 | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Interface Identifier (integer) | +-------------------------------+-------------------------------+ | Tag = 0x0003 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Interface Identifier (text) / \ \ +-------------------------------+-------------------------------+ | Tag = 0xXXXX | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | ASP Congestion | +-------------------------------+-------------------------------+ | Tag = 0x0110 | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | TID Label | +-------------------------------+-------------------------------+ | Tag = 0x010F | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | DRN Label | +-------------------------------+-------------------------------+ | Tag = 0x0004 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Info String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ACTIVE message can contain the following parameters: Parameters ------------------------------------------------ Traffic Mode Type Optional Routing Context Optional *1 Interface Identifier (integer) Optional *2 Interface Identifier (text) Optional *2 ASP Congestion Mandatory *3 B. Bidulock Version 0.1 Page 14 Internet Draft UA ASPCONG February 3, 2007 TID Label Optional DRN Label Optional Info String Optional Note 1: The Routing Context parameter is only optionally included in UA protocols that support it [M3UA], [SUA], [ISUA], [TUA], and indicates the Application Server to which the message applies. If there is only one Application Server provisioned for a given SCTP association, then the Routing Context field is optional. Otherwise, the Routing Context field is mandatory. Note 2: The Interface Identifier parameter is only optionally included in UA protocols that support it [M2UA]. Note 3: The ASP Congestion parameter is included in the ASPAC message to indicate to the SGP that the congestion sub-state in which ASP is activating. In this case, the ASP Congestion parameter contains the congestion level currently experienced by the ASP. If the ASP is not activating in a congested state, the Level field of the ASP Congestion parameter MUST contain zero (0), indicating "no congestion". 3.2.2. Notify (NTFY) ASPCONG extends the Notify message as follows: The Notify message is used to provide an autonomous indication of UA events at an SGP/IPSP to an ASP/IPSP. The NTFY message is formatted as follows: B. Bidulock Version 0.1 Page 15 Internet Draft UA ASPCONG February 3, 2007 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 = 0x000D | Length = 8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Status | +-------------------------------+-------------------------------+ | Tag = 0x0011 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | ASP Identifier | +-------------------------------+------------------------------- | Tag = 0x0006 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Routing Context / \ \ +-------------------------------+-------------------------------+ | Tag = 0x0001 | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Interface Identifier (integer) | +-------------------------------+-------------------------------+ | Tag = 0x0003 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Interface Identifier (text) / \ \ +-------------------------------+-------------------------------+ | Tag = 0xXXXX | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | ASP Congestion | +-------------------------------+-------------------------------+ | Tag = 0x0004 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Info String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The NTFY message can contain the following parameters: Parameters ----------------------------------------------------- Status Mandatory ASP Identifier Conditional *1 Routing Context Conditional *2 *3 Interface Identifier (integer) Conditional *4 Interface Identifier (text) Conditional *4 ASP Congestion Conditional *5 Info String Optional B. Bidulock Version 0.1 Page 16 Internet Draft UA ASPCONG February 3, 2007 Note 1: ASP Identifier MUST be used where the IPSP/SGP cannot identify the ASP by pre-configured address/port number information (e.g, where an ASP is resident on a Host using dynamic address/port number assignment) and the Status parameter is set to "Alternate ASP Active" or "ASP Failure". Note 2: When an ASP is registered or configured for multiple AS with an SG, to identify the Application Server, the Routing Context associated with the AS whose state is being notified MUST be placed in the NTFY message when the Status parameter is set to "AS_State_Change". Note 3: The Routing Context parameter is only optionally included in UA protocols that support it [M3UA], [SUA], [ISUA], [TUA], and indicates the Application Server to which the message applies. If there is only one Application Server provisioned for a given SCTP association, then the Routing Context field is optional. Otherwise, the Routing Context field is mandatory. Note 4: The Interface Identifier parameter is only optionally included in UA protocols that support it [M2UA]. Note 5: The ASP Congestion parameter MUST be included in the NTFY message when the Status parameter is set to "AS_State_Change" and the Status ID field is set to "ASP-Congested". The ASP Congestion parameter contains the level of congestion being experienced by the Application Server, as determined by the SGP. 3.2.3. ASP Status (ASPSTAT) The ASP Status message is used by an ASP to report the congestion status toward a local Application Server at the ASP, to an SGP. It may also be used by an IPSP to report the congestion status toward a local Application server at the IPSP to a remote IPSP. The format of the ASPSTAT message is as follows: B. Bidulock Version 0.1 Page 17 Internet Draft UA ASPCONG February 3, 2007 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 = 8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Routing Context | +-------------------------------+-------------------------------+ | Tag = 0x0001 | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Interface Identifier (integer) | +-------------------------------+-------------------------------+ | Tag = 0x0003 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Interface Identifier (text) / \ \ +-------------------------------+-------------------------------+ | Tag = 0xXXXX | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | ASP Congestion | +-------------------------------+-------------------------------+ | Tag = 0x0004 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Info String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ASPSTAT message can contain the following parameters: Parameters -------------------------------------------------- Routing Context Conditional *1 Interface Identifier (integer) Conditional *2 Interface Identifier (text) Conditional *2 ASP Congestion Mandatory *3 Info String Optional Note 1: The Routing Context parameter is only optionally included in UA protocols that support it [M3UA], [SUA], [ISUA], [TUA], and indicates the Application Server to which the message applies. If there is only one Application Server provisioned for a given SCTP association, then the Routing Context field is optional. Otherwise, the Routing Context field is mandatory. Note 2: The Interface Identifier parameter is only optionally included in UA protocols that support it [M2UA]. Note 3: The ASP Congestion parameter is used by the ASP in the ASPSTAT message to indicate the current congestion level of the B. Bidulock Version 0.1 Page 18 Internet Draft UA ASPCONG February 3, 2007 Application Server (AS) indicated by the Routing Context (or Interface Identifier) associated with the AS. The ASPSTAT message MAY contain additional extension parameters provided for by other extensions. 3.2.4. ASP Status Query (ASPSTAT QRY) The ASP Status Query message is used by an SGP to query an ASP concerning the congestion status toward an Application Server at the ASP. It may also be used by an IPSP to query the congestion status toward an Application Server at a remote IPSP. The format of the ASPSTAT 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 = 8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Routing Context | +-------------------------------+-------------------------------+ | Tag = 0x0001 | Length=8 | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Interface Identifier (integer) | +-------------------------------+-------------------------------+ | Tag = 0x0003 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Interface Identifier (text) / \ \ +-------------------------------+-------------------------------+ | Tag = 0x0004 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Info String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ASPSTAT QRY message can contain the following parameters: Parameters ----------------------------------------------------- Routing Context Conditional *1 *2 Interface Identifier (integer) Conditional *3 Interface Identifier (text) Conditional *3 Info String Optional Note 1: The Routing Context (or Interface Identifier) is used by the Signalling Gateway (SG) to indicate to the ASP for which Application Server (AS) the current congestion status is B. Bidulock Version 0.1 Page 19 Internet Draft UA ASPCONG February 3, 2007 requested. Note 2: The Routing Context parameter is only optionally included in UA protocols that support it [M3UA], [SUA], [ISUA], [TUA], and indicates the Application Server to which the message applies. If there is only one Application Server provisioned for a given SCTP association, then the Routing Context field is optional. Otherwise, the Routing Context field is mandatory. Note 3: The Interface Identifier parameter is only optionally included in UA protocols that support it [M2UA]. The ASPSTAT QRY message MAY contain additional extension parameters provided for by other extensions. 4. Procedures ASPCONG provides the following procedures in extension to the procedures of the UAs [M2UA], [M3UA], [SUA], [ISUA], [TUA]. 4.1. AS and ASP State Maintenance ASPCONG introduces the concept of a congested state, both for Application Server Processes (ASPs) and Applications Servers (ASs). These congestion states can be viewed as sub-states of the ASP-ACTIVE and AS-ACTIVE states, respectively. 4.1.1. ASP State ASPCONG adds the following ASP state definition to the state transitions for an Application Server Process: ASP-CONGESTED(n):- This state is a sub-state of the ASP-ACTIVE state. Whenever an ASP is in the ASP-ACTIVE state, it may also be in one of the ASP-CONGESTED(n) sub-states, where "n" is the congestion level associated with the ASP in the AS. Any existing procedure that causes an Application Server Process to leave the ASP-ACTIVE states also applies to any congested ASP- CONGESTED sub-states. Any existing procedure that causes an Application Server Process to enter the ASP-ACTIVE state, enters the state as "uncongested", unless an ASP Congestion parameter is associated with the procedure, in which case the ASP-CONGESTED(n) state is entered, where "n" is the congestion level associated with the ASP Congestion parameter. (Note that the ASP Active message can now contains an ASP Congestion parameter.) 4.1.2. AS State AS-CONGESTED(n):- This state is a sub-state of the AS-ACTIVE state. Whenever an AS is in the AS-ACTIVE state, it may also be in one of the AS-CONGESTED(n) sub-states, B. Bidulock Version 0.1 Page 20 Internet Draft UA ASPCONG February 3, 2007 where "n" is the congestion level associated with the AS. Any existing procedure that causes an Application Server to leave the AS-ACTIVE states also applies to any congested AS-CONGESTED sub- states. Any existing procedure that causes an Application Server to enter the AS-ACTIVE state, enters the state as "uncongested", unless an ASP Congestion parameter is associated with the procedure, in which case the AS-CONGESTED(n) state is entered, where "n" is derived by the SG from the congestion level associated with the ASP Congestion parameter. (Note that the ASP Active message can now contains an ASP Congestion parameter.) 4.1.3. ASP Up Procedures ASP Up procedures are not modified by ASPCONG with the exception that when an ASP moves to the ASP-INACTIVE state for an Application Server from the ASP-DOWN state, the SGP SHOULD send notifications to the newly inactive ASP that it would have otherwise received if it were previously in the ASP-INACTIVE state for the AS. This can now also include the NTFY (AS-CONGESTED) notification. 4.1.4. ASP Down Procedures When an ASP moves to the ASP-DOWN state and is deactivated for all Application Servers served by the ASP at an SGP, the previous congestion status associated with the ASP for the Application Servers will be disregarded and removed from consideration for the calculation of the overall AS congestion status for the corresponding Application Servers. 4.1.5. ASP Active Procedures ASPCONG enhances the ASP Active Procedures of the UAs as follows: When an ASP sends an ASP Active message to an SGP to activate itself for a given Application Server, the ASP includes the ASP Congestion parameter in the message if the ASP is activating for the AS in an already congested state. It is not necessary to include an ASP Congestion parameter if the ASP is not congested at the time of activation. Upon receiving an ASP Active message containing an ASP Congestion parameter, and the SGP is moving the ASP to the ASP-ACTIVE state for the AS, the SGP will also mark the ASP a congested at the congestion Level indicated in the ASP Congestion parameter. The SGP will also take appropriate actions with regard to AS congestion in the same manner as if the SGP had received an ASP Status message for the congestion level immediately following the ASP Active message. B. Bidulock Version 0.1 Page 21 Internet Draft UA ASPCONG February 3, 2007 4.1.6. ASP Inactive Procedures When an ASP is deactivated for an Application Server at an SGP, the previous congestion status associated with the ASP for the Application Server will be disregarded and removed from consideration for the calculation of the overall AS congestion status for the corresponding Application Server. 4.1.7. ASP Status Procedures Whenever an ASP in the ASP-ACTIVE state for an Application Server, determines that it is experiencing congestion toward the Application Server (see "Detection of ASP Congestion at the ASP"), and that the level of congestion toward the Application Server has changed since the last status sent to the SGP, the ASP MAY send the SGP an ASP Status message reporting the change in detected congestion level. The receipt of the ASP Status message is not acknowledged by the SGP. The ASP Status message is sent by the ASP in the same SCTP stream as other ASPTM and signalling messages related to the Application Server (i.e, the same Routing Context (or Interface Identifier) to SCTP stream mapping that is performed for the signalling messages causing the congestion.) ASP Status messages are sent ordered within the SCTP stream. ASP Status messages are not sent on SCTP Stream 0. Whenever an SGP receives an ASP Status message from an ASP in the ASP-ACTIVE state for an Application Server, the SGP MAY consider the congestion level reported in the ASP Congestion parameter contained in the message when determining the congestion level of the ASP within the AS (i.e. ASP-CONGESTED sub-state) as well as when determining the overall AS congestion level (i.e. AS-CONGESTED sub-state) and when considering indication of congestion and invocation of congestion related procedures toward the SS7 network. If an SGP should receive an ASP Status message for an ASP that is not in the ASP-ACTIVE state at an AS, an ERR("Unexpected Message") should be returned and the ASP Status message discarded. 4.1.8. ASP Status Query Procedures At any time that an ASP is in the ASP-ACTIVE state at an SGP for an Application Server, the SGP MAY send an ASP Status Query message to the ASP requesting the current congestion status for the ASP toward the Application Server. ASP Status Query messages can be sent unordered on the SCTP association, and MAY be sent on SCTP Stream 0. Whenever an ASP receives an ASP Status Query message from an SGP for an Application Server, and the ASP is in the ASP-ACTIVE or ASP- INACTIVE state for the Application Server, the ASP MUST respond with B. Bidulock Version 0.1 Page 22 Internet Draft UA ASPCONG February 3, 2007 an ASP Status message indicating the current congestion level toward the Application Server. The Routing Context (or Interface Identifier) contained in the ASP Status message must be the same as appeared in the received ASP Status Query message, and the ASP Congestion parameter contained in the ASP Status message MUST reflect the current congestion level toward the Application Server associated with the Routing Context (or Interface Identifier). If the ASP receives an ASP Status Query message and the ASP is not in the ASP-ACTIVE or ASP-INACTIVE state for Application Server indicated in the Message, it SHOULD return an ERR("Unexpected Message") and take steps to move the SGP state to the current state of the ASP (e.g. by sending, for example, ASP Down). Using this procedure, the SGP can query the ASP Congestion status of an Application Server from an ASP. 4.1.9. Notify Procedures A Notify (NTFY) message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status information, any ASP Identifier of the failed ASP, and the ASP Congestion parameter when ("AS-CONGESTED") is indicated. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify (NTFY) message must be sent whether the AS state change was a result of an ASP failure or reception of an ASP State Management (ASPSM) or ASP Traffic Management (ASPTM) message. In the second case, the Notify (NTFY) message MUST be sent after any ASP State or Traffic Management related acknowledgements messages (e.g, ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). Whenever a Notify (NTFY) ("AS-PENDING") message is sent by an SGP that now has no ASPs active to service the traffic, or where a Notify NTFY ("Insufficient ASP resources active in AS") message MUST be sent in the Load-share or Broadcast mode, the Notify (NTFY) message does not explicitly compel the ASP(s) receiving the message to become active. The ASPs remain in control of what (and when) traffic action is taken. Whenever a Notify (NTFY) ("AS-CONGESTED") message is sent by an SGP that is experiencing AS congestion, the Notify (NTFY) message does not explicitly compel the ASP(s) receiving the message, whether in the ASP-ACTIVE or ASP-INACTIVE state for the Application Server, to take any action: again, the ASPs remain in control of what (and when) traffic action is taken. Whenever a Notify (NTYF) message does not contain a Routing Context (or Interface Identifier) parameter, the receiver must know, via configuration data, of which Application Servers the ASP is a member and take the appropriate action in each AS. 5. Examples (This section will include some examples and message sequence charts indicating the use of each new protocol element and procedure.) B. Bidulock Version 0.1 Page 23 Internet Draft UA ASPCONG February 3, 2007 6. Security ASPCONG does not introduce any new security risks or considerations that are not already inherent in the UAs [M2UA], [M3UA], [SUA], [ISUA], [TUA]. Please see the SIGTRAN Security document [SIGSEC] for security consideration and recommendations that are applicable to each of the UAs. 6.1. Interworking Procedures Because the ASPCONG procedures provided here rely upon cooperation between ASP and SGP, if either the ASP or the SGP does not support these ASPCONG procedures, neither the ASP nor the SGP is able to take advantage of the full benefits of the procedures. The ASP or SGP supporting ASPCONG MAY fall back to the interworking procedures provided in this section, or to procedures based on the original (non- ASPCONG) UA procedures. A peer ASP or SGP that does not support the ASPCONG procedures can either be identified by local configuration information, the ASP Extensions [ASPEXT] procedure, or at ASP Activation time. The lack of support for ASPCONG can be determined at ASP Activation time when the peer ASP or SGP does not place a ASP Congestion parameter (as it MUST if both peers support ASPCONG) in the ASPAC message. When interwokring to an ASP or SGP that does not support ASPCONG, the SGP or ASP supporting ASPCONG SHALL perform all of the local procedures as though the peer SGP or ASP supported ASPCONG with the following exceptions: (1) The ASP MUST NOT send ASP Status messages, either autonomously or in response to a received ASP Status Query message. (2) The SGP MUST NOT send ASP Status Query messages. (3) The ASP MUST NOT send ASP Congestion parameters in ASP Active messages after having received an ERR("Unrecognized Parameter") in response to an initial well-formed ASP Active message containing an ASP Congestion parameter. (4) The SGP MUST NOT send ASP Congestion parameters or NTFY ("AS- CONGESTED") messages after having received an ERR("Invalid Parameter") or ERR("Unrecognized Parameter") in response to an initial well-formed NTFY (AS-CONGESTED) message. The ASP and SGP MAY continue performing local ASP Congestion detection and the SGP MAY continue taking ASP Congestion into consideration when determining actions with regard to congestion toward the SS7 network. B. Bidulock Version 0.1 Page 24 Internet Draft UA ASPCONG February 3, 2007 7. IANA Considerations ASPCONG redefines the format of the Status ID field of the Status parmeter contained in the Notify message in the [M2UA], [M3UA] and [SUA] registries. ASPCONG defines a new ASP Congestion parameter in the [M2UA], [M3UA] and [SUA] registries. ASPCONG redefines the parameters accepted in the ASP Active message to include the new conditional ASP Congestion parameter in the [M2UA], [M3UA] and [SUA] registries. ASPCONG redefines the parameters accepted in the Notify message to include the new conditioanl ASP Congestion parameter in the [M2UA], [M3UA] and [SUA] registries. ASPCONG defines two new messages in the ASP Traffic Management messge class, the ASP Status and ASP Status Query messages, in the [M2UA], [M3UA] and [SUA] registries. 0. Change History This section provides historical information on the changes made to this draft. This section will be removed from the document when the document is finalized. 0.1. Changes from Version 0.0 to Version 0.1 (1) Updated dates and version numbers. (2) Updates for new boilerplate and idnits-2.00.1. 0.0. Version 0.0 The initial version of this document. 0.0.0. Change Log $Log: draft-bidulock-sigtran-aspcong-01.me,v $ Revision 0.9.2.1 2007/02/03 15:47:25 brian - added new drafts Revision-0.9.2.3 2006/07/11 23:03:44 brian - another attempt at submitting version 0 Revision-0.9.2.2 2006/06/27 09:41:15 brian - rereleased drafts Revision-0.9.2.1 2005/10/17 11:53:45 brian - updated drafts for republication B. Bidulock Version 0.1 Page 25 Internet Draft UA ASPCONG February 3, 2007 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14/RFC 2119, The Internet Society (March 1997). [M2UA] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and Heitz, J., "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -- User Adaptation Layer," RFC 3331, The Internet Society (September 2002). [M3UA] Morneault, K., Pastor-Balbas, J., (eds), "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -- User Adaptation Layer (M3UA)," RFC 4666, The Internet Society (September 2006). [SUA] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller, J. and Bidulock, B., "Signalling Connection Control Part User Adaptation Layer (SUA)," RFC 3868, The Internet Society (October 2004). [SCTP] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, H., Zhang, L. and Paxson, V., "Stream Control Transmission Protocol (SCTP)," RFC 2960, The Internet Society (October 2000). (Updated by RFC 3309) (Status: PROPOSED STANDARD) [SCTPCRC] Stone, J., Stewart, R. R. and Otis, D., "Stream Control Transmission Protocol (SCTP) Checksum Change," RFC 3309, The Internet Society (September 2002). (Updates RFC 2960) (Status: PROPOSED STANDARD) [Q.700] ITU, "Introduction to CCITT Signalling System No. 7," ITU-T Recommendation Q.700, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [Q.703] ITU, "Signalling System No. 7 -- Signalling Link," ITU-T Recommendation Q.703, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [T1.111] ANSI, "Signalling System No. 7 -- Message Transfer Part," ANSI T1.111, American National Standards Institute (1992). [Q.704] ITU, "Message Transfer Part -- Signalling Network Functions and Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [Q.714] ITU, "Signalling Connection Control Part Procedures," ITU-T B. Bidulock Version 0.1 Page 26 Internet Draft UA ASPCONG February 3, 2007 Recommendation Q.714, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [T1.112] ANSI, "Signalling System No. 7 -- Signalling Connection Control Part," ANSI T1.112, American National Standards Institute (1992). [Q.774] ITU, "Signalling System No. 7 -- Transaction Capabilities Procedures," ITU-T Recommendation Q.774, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [T1.114] ANSI, "Signalling System No. 7 -- Transaction Capabilities Application Part," ANSI T1.114, American National Standards Institute (1992). [Q.764] ITU, "Signalling System No. 7 -- ISDN User Part Signalling Procedures," ITU-T Recommendation Q.764, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [T1.113] ANSI, "Signalling System No. 7 -- ISDN User Part," ANSI T1.113, American National Standards Institute (1992). [SIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J., "Security Considerations for Signaling Transport (SIGTRAN) Protocols," RFC 3788, Internet Engineering Task Force -- Signalling Transport Working Group (June 2004). Informative References [ISUA] Bidulock, B., "SS7 ISUP-User Adaptation Layer (ISUA)," draft- bidulock-sigtran-isua-04.txt, Internet Engineering Task Force -- Signalling Transport Working Group (February 3, 2007). Work In Progress. [TUA] Bidulock, B., "SS7 TCAP-User Adaptation Layer (TUA)," draft- bidulock-sigtran-tua-05.txt, Internet Engineering Task Force -- Signalling Transport Working Group (February 3, 2007). Work In Progress. [SCTPIG] Stewart, R., Aria-Rodriguez, I., Poon, K., Caro, A. and Tuexen, M., "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues," RFC 4460, The Internet Society (April 2006). (Status: INFORMATIONAL) [CORID] Bidulock, B., "Correlation Id and Heartbeat Procedures Supporting Lossless Fail-Over," draft-bidulock-sigtran- corid-05.txt, Internet Engineering Task Force -- Signalling B. Bidulock Version 0.1 Page 27 Internet Draft UA ASPCONG February 3, 2007 Transport Working Group (February 3, 2007). Work In Progress. [LOADSEL] Bidulock, B., "Load Selection Extension for Signalling User Adaptation Layers (LOADSEL)," draft-bidulock-sigtran- loadsel-05.txt, Internet Engineering Task Force -- Signalling Transport Working Group (February 3, 2007). Work In Progress. [LOADGRP] Bidulock, B., "Load Grouping Extension for Signalling User Adaptation Layers (LOADGRP)," draft-bidulock-sigtran- loadgrp-05.txt, Internet Engineering Task Force -- Signalling Transport Working Group (February 3, 2007). Work In Progress. [ASPEXT] Bidulock, B., "Application Server Process (ASP) Extension Framework," draft-bidulock-sigtran-aspext-05.txt, Internet Engineering Task Force -- Signalling Transport Working Group (February 3, 2007). Work In Progress. Acknowledgements The authors would like to thank Lincoln Haresign, and Tolga Averson for their valuable comments and suggestions. Author's Addresses Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada Phone: +1-780-490-1141 Email: bidulock@openss7.org URL: http//www.openss7.org/ This draft expires August 2007. B. Bidulock Version 0.1 Page 28 Internet Draft UA ASPCONG February 3, 2007 Table of Contents Status of this Memo ............................................. 1 Copyright ....................................................... 1 Abstract ........................................................ 1 1 Introduction .................................................. 2 1.1 Scope ....................................................... 2 1.2 Abbreviations ............................................... 2 1.3 Terminology ................................................. 2 1.4 Overview .................................................... 3 1.4.1 ASP Congestion ............................................ 3 1.5 Sample Configurations ....................................... 6 1.6 ASP Congestion Management ................................... 6 1.6.1 ASP Congestion Management at an ASP ....................... 6 1.6.2 ASP Congestion Management at an SGP ....................... 6 1.7 Issues ...................................................... 7 1.8 Conclusions ................................................. 9 Notes for Section 1 ............................................. 10 2 Conventions ................................................... 10 3 Protocol Elements ............................................. 10 3.1 Parameters .................................................. 11 3.1.1 ASP Congestion Level ...................................... 11 3.1.2 Status .................................................... 12 3.2 Messages .................................................... 13 3.2.1 ASP Active (ACTIVE) ....................................... 13 3.2.2 Notify (NTFY) ............................................. 15 3.2.3 ASP Status (ASPSTAT) ...................................... 17 3.2.4 ASP Status Query (ASPSTAT QRY) ............................ 19 4 Procedures .................................................... 20 4.1 AS and ASP State Maintenance ................................ 20 4.1.1 ASP State ................................................. 20 4.1.2 AS State .................................................. 20 4.1.3 ASP Up Procedures ......................................... 21 4.1.4 ASP Down Procedures ....................................... 21 4.1.5 ASP Active Procedures ..................................... 21 4.1.6 ASP Inactive Procedures ................................... 22 4.1.7 ASP Status Procedures ..................................... 22 4.1.8 ASP Status Query Procedures ............................... 22 4.1.9 Notify Procedures ......................................... 23 5 Examples ...................................................... 23 6 Security ...................................................... 24 6.1 Interworking Procedures ..................................... 24 7 IANA Considerations ........................................... 25 0 Change History ................................................ 25 0.1 Changes from Version 0.0 to Version 0.1 ..................... 25 0.0 Version 0.0 ................................................. 25 0.0.0 Change Log ................................................ 25 Normative References ............................................ 26 Informative References .......................................... 27 Acknowledgements ................................................ 28 Author's Addresses .............................................. 28 Table of Contents ............................................... 29 B. Bidulock Version 0.1 Page 29 Internet Draft UA ASPCONG February 3, 2007 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. B. Bidulock Version 0.1 Page 30