| draft-bidulock-sigtran-aspcong-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-bidulock-sigtran-aspcong-00.txt.
Network Working Group Brian Bidulock
INTERNET-DRAFT OpenSS7 Corporation
October 16, 2005
Expires in April 2006
ASP Congestion (ASPCONG)
for
Signalling User Adaptation Layers
<draft-bidulock-sigtran-aspcong-00.txt>
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 a "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 April 2006.
Copyright
Copyright (C) The Internet Society (2005).
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..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.0 Page 1
Internet Draft UA ASPCONG October 16, 2005
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
[RFC 2960] associations for SS7 [Q.700] Signalling User Adaptation
Protocols [M2UA..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..SUA, ISUA, TUA] by adding the following terms:
B. Bidulock Version 0.0 Page 2
Internet Draft UA ASPCONG October 16, 2005
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) [RFC 2960] SS7 Signalling
User Adaptation Layers [M2UA..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
that is directed from a given SGP toward a specific Application
Server, via a specific ASP. As such, ASP Congestion can be identified
B. Bidulock Version 0.0 Page 3
Internet Draft UA ASPCONG October 16, 2005
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
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
B. Bidulock Version 0.0 Page 4
Internet Draft UA ASPCONG October 16, 2005
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.0 Page 5
Internet Draft UA ASPCONG October 16, 2005
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.0 Page 6
Internet Draft UA ASPCONG October 16, 2005
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.
The ASPSTAT message would require both a description of the NIF
B. Bidulock Version 0.0 Page 7
Internet Draft UA ASPCONG October 16, 2005
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-BIS, 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.
1.8. Conclusions
The following conclusions have been reached regarding the mechanisms
described in this document.
B. Bidulock Version 0.0 Page 8
Internet Draft UA ASPCONG October 16, 2005
(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.0 Page 9
Internet Draft UA ASPCONG October 16, 2005
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 keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when they appear in this document, are to be interpreted
as described in [RFC 2119].
3. Protocol Elements
The following protocol element definitions are provided by ASPCONG
in extension to the existing protocol element definitions for the UAs
[M2UA..SUA, ISUA, TUA].
B. Bidulock Version 0.0 Page 10
Internet Draft UA ASPCONG October 16, 2005
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.0 Page 11
Internet Draft UA ASPCONG October 16, 2005
0 no congestion
1 congestion-accept
2 congestion-discard
3-7 reserved
For [M3UA-BIS], 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.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:
1 reserved
2 Application Server Inactive (AS-Inactive)
B. Bidulock Version 0.0 Page 12
Internet Draft UA ASPCONG October 16, 2005
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.0 Page 13
Internet Draft UA ASPCONG October 16, 2005
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
TID Label Optional
B. Bidulock Version 0.0 Page 14
Internet Draft UA ASPCONG October 16, 2005
DRN Label Optional
Info String Optional
Note 1: The Routing Context parameter is only optionally included in
UA protocols that support it [M3UA-BIS, 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.0 Page 15
Internet Draft UA ASPCONG October 16, 2005
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.0 Page 16
Internet Draft UA ASPCONG October 16, 2005
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-BIS, 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.0 Page 17
Internet Draft UA ASPCONG October 16, 2005
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-BIS, 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
Application Server (AS) indicated by the Routing Context (or
B. Bidulock Version 0.0 Page 18
Internet Draft UA ASPCONG October 16, 2005
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
requested.
B. Bidulock Version 0.0 Page 19
Internet Draft UA ASPCONG October 16, 2005
Note 2: The Routing Context parameter is only optionally included in
UA protocols that support it [M3UA-BIS, 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..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,
where "n" is the congestion level associated with
the AS.
B. Bidulock Version 0.0 Page 20
Internet Draft UA ASPCONG October 16, 2005
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.
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.
B. Bidulock Version 0.0 Page 21
Internet Draft UA ASPCONG October 16, 2005
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
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).
B. Bidulock Version 0.0 Page 22
Internet Draft UA ASPCONG October 16, 2005
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.)
6. Security
ASPCONG does not introduce any new security risks or considerations
that are not already inherent in the UAs [M2UA..SUA, ISUA, TUA].
Please see the SIGTRAN Security document [SIGSEC] for security
consideration and recommendations that are applicable to each of the
UAs.
B. Bidulock Version 0.0 Page 23
Internet Draft UA ASPCONG October 16, 2005
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.
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
B. Bidulock Version 0.0 Page 24
Internet Draft UA ASPCONG October 16, 2005
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.0. Version 0.0
The initial version of this document.
0.0.0. Change Log
$Log: draft-bidulock-sigtran-aspcong-00.me,v $
Revision 0.9.2.1 2005/10/17 11:53:45 brian
- updated drafts for republication
B. Bidulock Version 0.0 Page 25
Internet Draft UA ASPCONG October 16, 2005
R. References
[ASPEXT] Bidulock, B., "Application Server Process (ASP) Extension
Framework," <draft-bidulock-sigtran-aspext-04.txt>, Internet
Engineering Task Force - Signalling Transport Working Group
(October 16, 2005). Work In Progress.
R.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119 - BCP 14, 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, Internet Engineering
Task Force - Signalling Transport Working Group (September,
2002).
[M3UA-BIS] Pastor, J., Morneault, K., "Signaling System 7 (SS7)
Message Transfer Part 3 (MTP3)-User Adaptation Layer (M3UA),"
<draft-ietf-sigtran-rfc3332bis-05.txt>, Internet Engineering Task
Force - Signalling Transport Working Group (October 2005). Work
In Progress
[SUA] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller,
J. and Bidulock, B., "Signalling Connection Control Part User
Adaptation Layer (SUA)," RFC 3868, Internet Engineering Task
Force - Signalling Transport Working Group (October, 2004).
[RFC 2960] Stewart, 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 (February 2000).
[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")
[CORID] Bidulock, B., "Correlation Id and Heartbeat Procedures
Supporting Lossless Fail-Over," <draft-bidulock-sigtran-
corid-04.txt>, Internet Engineering Task Force - Signalling
Transport Working Group (October 16, 2005). Work In Progress.
[LOADSEL] Bidulock, B., "Load Selection Extension for Signalling User
Adaptation Layers (LOADSEL)," <draft-bidulock-sigtran-
loadsel-04.txt>, Internet Engineering Task Force - Signalling
Transport Working Group (October 16, 2005). Work In Progress.
[LOADGRP] Bidulock, B., "Load Grouping Extension for Signalling User
Adaptation Layers (LOADGRP)," <draft-bidulock-sigtran-
loadgrp-04.txt>, Internet Engineering Task Force - Signalling
B. Bidulock Version 0.0 Page 26
Internet Draft UA ASPCONG October 16, 2005
Transport Working Group (October 16, 2005). Work In Progress.
[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 Institue (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
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 Institue
(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
Institue (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 Institue (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).
[M3UA] Sidebottom, G., Morneault, K. and Pastor-Balbas, J., (eds),
"Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User
Adaptation Layer (M3UA)," RFC 3332, Internet Engineering Task
Force - Signalling Transport Working Group (September, 2002).
R.2. Informative References
[ISUA] Bidulock, B., "SS7 ISUP-User Adaptation Layer (ISUA)," <draft-
B. Bidulock Version 0.0 Page 27
Internet Draft UA ASPCONG October 16, 2005
bidulock-sigtran-isua-03.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (October 16, 2005). Work In
Progress.
[TUA] Bidulock, B., "SS7 TCAP-User Adaptation Layer (TUA)," <draft-
bidulock-sigtran-tua-04.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (October 16, 2005). 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: [email protected]
URL: http//www.openss7.org/
This draft expires April 2006.
B. Bidulock Version 0.0 Page 28
Internet Draft UA ASPCONG October 16, 2005
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 ................................................. 8
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 ................................... 21
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 ...................................................... 23
6.1 Interworking Procedures ..................................... 24
7 IANA Considerations ........................................... 24
0 Change History ................................................ 25
0.0 Version 0.0 ................................................. 25
0.0.0 Change Log ................................................ 25
R References .................................................... 26
R.1 Normative References ........................................ 26
R.2 Informative References ...................................... 27
Acknowledgements ................................................ 28
Author's Addresses .............................................. 28
Table of Contents ............................................... 29
B. Bidulock Version 0.0 Page 29
Internet Draft UA ASPCONG October 16, 2005
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 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 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 to the IETF at [email protected].
Disclaimer of Validity
This document and the information contained herein is provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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 Internet Society (2005). 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.0 Page 30
| ||||||||||||||||||
| Last modified: Wed, 27 Nov 2024 04:35:30 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||||