| draft-bidulock-sigtran-loadgrp-00 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-bidulock-sigtran-loadgrp-00.txt.
Network Working Group Brian Bidulock
INTERNET-DRAFT OpenSS7 Corporation
Expires in six months January 10, 2002
Load Grouping Extension
for
Signalling User Adaptation Layers
<draft-bidulock-sigtran-loadgrp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 or RFC 2026. Internet-Drafts are
working documents of the Inetnet 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
To learn the current status of any Internet-Draft, please check the
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This Internet-Draft describes an extension parameter and procedure to
the Signalling User Adaptation Protocols [IUA...TUA], based on the
Stream Transmission Control Protocol (SCTP) [RFC 2960] which permits
an Application Server Processes (ASP) to indicate its placement
within a Load Group and permits an Signalling Gateway (SG) to
distribute traffic over Load Groups under Application Server Process
(ASP) control.
The described procedure provides for Override, Loadshare and
Broadcast traffic mode operation within a Load Group consisting of
one or more Application Server Processes (ASPs) resulting a mixture
B. Bidulock Version 0.0 Page 1
Internet Draft UA Load Grouping January 10, 2002
of traffic modes within an Application Server (AS). The parameters
and procedures described here supplement the UA Load Selection
[LOADSEL] extension parameters and procedures for improvide
distribution of traffic over ASPs and Signalling Gateway Processes
(SGPs).
1. Introduction
1.1. Scope
This Internet-Draft provides the Load Distribution parameter and
associated procedures in extension to the parmeters and procedures of
the Signalling User Adaptation Layers (UAs) [IUA...TUA], and the Load
Selection [LOADSEL] extension, for the purpose of permitting
Application Server Process control over grouping of ASPs into
Application Servers as part of the procedures of these UA protocols.
This Load Grouping extension is intended to be compatible with UA
implementations not supporting this extension.
1.2. Terminology
This extension supplements the terminology used in the UA documents
[IUA...TUA] and the Load Selection extension by adding the following
terms:
Load Distribution (LD) - a Traffic Mode Type which is applicable
within a Load Group.
Load Group (LG) - a group of ASPs that share the same traffic
distribution within an Application Server. An ASP is permitted
to belong to more than one Load Group for a given AS.
Load Selection (LS) - an identifier that uniquely identifies a Load
Group within an Application Server. This identifier is only
guaranteed unique within the scope of an Application Server and
must be combined with a Routing Context or (set of) Interface
Identifier(s) to uniquely define a Load Group at a Signalling
Gateway.
Signalling User Adaptation Layer (UA) - one or more of the Stream
Control Transmission Protocol (SCTP) [RFC 2960] Signalling User
Adatapation Layers [IUA...TUA].
1.3. Overview
Existing UA procedures with regard to traffic distribution and ASP
traffic management provide a mechanism to select the algorithm for
coordinating state and distributing traffic over a number of
Application Server Processes (ASPs) serving an Application Server.
These existing procedures provide only simplified distribution
approaches which are not ammeniable to large scale systems that need
to adapt to dynamic traffic loading or need live reconfiguration for
maintenance purposes.
B. Bidulock Version 0.0 Page 2
Internet Draft UA Load Grouping January 10, 2002
This extension to the Signalling User Adaptation Layers [IUA...TUA]
permits close control over the grouping of Application Server
Processes serving an Application Server that provides the following
capability not existing in the current scheme:
Grouping of ASPs into Load Groups
Under the existing approach, each Application Server Process
acts independently with respect to an Application Server. This
approach does not provide for the grouping of ASPs into
workgroups, not does it provide coordintaed control of the role
of groups of ASPs serving an ASP. As a result, the existing
scheme does not scale well in this regard.
This extension draft provides for the grouping of ASPs into
load groups with a traffic distribution mode (Load
Distribution) within the load group that is independent of the
Application Sever traffic mode.
1.3.1. Existing Traffic Distribution
Figure 1 illustrates the existing traffic distribution algorithm that
is used across the Signalling User Adaptation Layers.
____
Traffic /....\
Mode Type ____|__....|
_______ | |...|
| |------------------->| ASP |...|
| SGP |-----\ |_______|...|
|_______|----\ \ ____|__....|
\--\ \ \ | |...|
\ \ \---------->| ASP |...|
_______ \ \ |_______|...|
| | \ \ |......| Application
| SGP | \ \ |......| Server
|_______| \ \ |......|
\ \ |......|
\ \ ____|__....|
\ \ | |...|
\ \---->| ASP |...|
\ |_______|...|
\ ____|__....|
\ | |...|
\-->| ASP |...|
|_______|...|
|......|
\____/
Figure 1. Existing Traffic Distribution
B. Bidulock Version 0.0 Page 3
Internet Draft UA Load Grouping January 10, 2002
When an SGP distributes a Signalling User Adaptation Layer message
towards the Application Server based on the Routing (Link) Key, it
selects an ASP that is active for the AS according to a Traffic Mode
Type that is associated with the AS. The Traffic Mode Type describes
three general distribution algorithms: Override, Loadshare and
Broadcast.
The detailed actions taken for these distribution algorithms are
described in Section 4 of the Signalling User Adaptation Layer
specifications [IUA...TUA]; however, they can be summarized as
follows:
Traffic Mode Type Override:- When distributing messages to an
Override Application Server, the SGP selects the ASP which is
active for the Application Server. In an Override Application
Server, at most one ASP can be active for the AS at any given
point in time. The active ASP for the AS is selected.
Traffic Mode Type Loadshare:- When distributing messages to a
Loadshare Application Server, the SGP selects one of the ASPs
that are active for the Application Server using an
implementation dependent loadsharing algorithm based on some
unspecified aspect of the traffic or static configuration data.
Traffic Mode Type Broadcast:- When distributing messages to a
Broadcast Application Server, the SGP sends a copy of the
message to each of the ASPs that are active for the Application
Server. (The ASPs themselves decide which, if any, of the ASPs
will process the message.)
In general, for the Signalling User Adapatation Layers, the Traffic
Mode Type is a characteristic of the Application Server, and an
Application Server can only have associated with it only one Traffic
Mode Type, and thus, only one traffic distribution algorithm can be
used across the ASPs that are serving a given Application Server.
This extension document enhances the traffic distribution algorithms
of the existing Signalling User Adaptation Layers by introducing an
additional level of distribution.
1.3.2. Extended Traffic Distribution
Figure 2 illustrates the extended traffic distribution algorithms
that are used across the Signalling User Adaptation Layers as a
result of the messages and procedures in this extension.
This extension introduces the concept of a Load Group. A Load Group
is a logical grouping of Application Server Processes (ASPs) into
traffic groups serving an Application Server. Signalling Gateway
Processes (SGPs) distribute traffic first over Load Groups and then
distribute traffic within the Load Group. Each Load Group describes
and is identified by a Load Selection [LOADSEL] within the
Application Server. The Load Selection identifies the traffic flows
that will be distributed to an associated Load Group within an
B. Bidulock Version 0.0 Page 4
Internet Draft UA Load Grouping January 10, 2002
____ ____
Traffic Load /....\ /....\
Mode Type Group|...___||__....|
_______ |..| |...|
| |---+---------------->| ASP |...|
| SGP | \ |..|_______|...|
|_______|-\ \ |...___||__....|
\ \ |..| |...|
\ \------------>| ASP |...|
_______ | |..|_______|...|
| | | |......||......| Application
| SGP | | \____/ |......| Server
|_______| | ____ |......|
| Load /....\ |......|
| Group|...___||__....|
| |..| |...|
+---------------->| ASP |...|
\ |..|_______|...|
\ |...___||__....|
\ |..| |...|
\------------>| ASP |...|
|..|_______|...|
|......||......|
\____/ \____/
Figure 2. Load Group Traffic Distribution
Application Server.
When an SGP distributes a Signalling User Adaptation Layer message
towards an Application Server based on the Routing (Link) Key, it
first selects an Load Group that is active for the Application Server
according a traffic distribtuion algorithm determined by the Load
Distribution that is associated with the Application Server and the
Load Selection position of the Load Group within the AS.
The Traffic Mode Type continues to describe three general
distribution algorithms: Override, Loadshare and Broadcast. The
change in the behavior of the SGP when selecting an ASP for traffic
distribution introduced by this extension is that the SGP also takes
into account the concept of a Load Group as identified within an AS
by its Load Selection.
The extended procedures can be summarized as follows:
Traffic Mode Type Override:- When distributing messages to an
Override Application Server, the SGP first selects the Load
Group that is active for the Application Server. In an
Override Application Server, at most one Load Group can be
active for the AS at any given point in time. The active Load
Group for the AS is selected.
B. Bidulock Version 0.0 Page 5
Internet Draft UA Load Grouping January 10, 2002
Traffic Mode Type Loadshare:- When distributing messages to a
Loadshare Application Server, the SGP selects one of the Load
Groups that are active for the Application Server using an
implementation dependent loadsharing algorithm based on the
Load Selection [LOADSEL] associated with the Load Group.
Traffic Mode Type Broadcast:- When distrbuting messages to a
Broadcast Application Server, the SGP sends a copy of the
message to each of the Load Groups that are active for the
Application Server. (The Load Groups themselves decide which,
if any, of the Load Groups will process the message.)
After selecting an Load Group according to the Traffic Mode Type for
the Application Server, the SGP then selects an ASP within the Load
Group based on the Load Distribution that is associated with the Load
Group. The Load Distribution describes the same three general
distribution algorithms that are provided in the Traffic Mode Type:
Override, Loadshare and Broadcast. When selecting an active ASP
within a Load Group, the procedures that the SGP will follow can be
summarized as follows:
Load Distribution Override:- When distributing messages within an
Override Load Group, the SGP selects the ASP which is active
for the Load Group. In an Override Load Group, at most one ASP
can be active for the Load Group at any given point in time.
The active ASP for the Load Group is selected.
Load Distribution Loadshare:- When distributing messages within a
Loadshare Load Group, the SGP selects one of the ASPs that are
active for the Load Group using an implementation dependent
loadsharing algorithm based on some unspecified aspect of the
traffic or static configuration data.
Load Distribution Broadcast:- When distributing messages within a
Broadcast Load Group, the SGP sends a copy of the message to
each of the ASPs that are active for the Load Group. (The ASPs
themselves decide which, if any, of the APSs will process the
message.)
The result of this extension is that two levels of traffic
distribution are provided for, permitting more flexible membership of
ASPs serving Application Servers, and provides the Application Server
Process with more control over the traffic patterns for which it is
active.
1.4. Sample Configurations
Although this extension does not restrict either Traffic Mode Type or
Load Distribution to a static assignment, there are, for example, six
(6) combinations of static Traffic Mode Type and Load Distribution
assignment under this scheme. Not all of these combinations provide
for interesting or useful configurations as follows:
Internet Draft UA Load Grouping January 10, 2002
Table 1. Sample Configurations
+----+---------+---------+---------------------------------------+
| | Traffic | Load | |
|Mode| Mode | Distri- |Description |
| | Type | bution | |
+----+---------+---------+---------------------------------------+
| 1 |Override |Loadshare|This mode permits a loadshare group of |
| | | |ASPs to override another loadshare |
| | | |group of ASPs. |
+----+ +---------+---------------------------------------+
| 2 | |Broadcast|This mode allows "mirrored" ASPs to |
| | | |override each other. |
+----+---------+---------+---------------------------------------+
| 3 |Loadshare|Override |This mode allows ASPs to override each |
| | | |other within a traffic slot of a |
| | | |loadshare group. |
+----+ +---------+---------------------------------------+
| 4 | |Broadcast|This mode permits "striping" and |
| | | |"mirroring" with loadsharing under ASP |
| | | |control. |
+----+---------+---------+---------------------------------------+
| 5 |Broadcast|Override |This mode permits a joining ASP to |
| | | |knock another ASP out of a Broadcast |
| | | |slot for an Application Server. |
+----+ +---------+---------------------------------------+
| 6 | |Loadshare|This mode permits "mirroring" and |
| | | |"striping" including automatic |
| | | |loadsharing within a mirror image. |
+----+---------+---------+---------------------------------------+
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 subsections describe the parameters which are added by
this extension, their format and the message in which they are used.
3.1. Parameters
This extension adds one new parameter: the Load Distribution
parameter.
3.1.1. Load Distribution
The Load Distribution parameter is used in the REQ REQ, REQ RSP,
ASPAC and ASPAC ACK messages. It is used in conjunction with the
Traffic Mode Type parameter [M3UA...TUA] and Load Selection parameter
B. Bidulock Version 0.0 Page 7
Internet Draft UA Load Grouping January 10, 2002
[LOADSEL] to further refine the traffic distribution algorithm for an
ASP in a Load Group serving an Application Server. The Load
Selection parameter identifies the Load Group for which the ASP is
registering, activating or deactivating and the Load Distribution
parameter identifies the traffic distribution that is to be used
within the Load Group.
The Load Distribution 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 = 8 |
+---------------------------------+-----------------------------+
| Load Distribution |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EDITOR'S NOTE:- The parameter tag values shown as 0xXXXX
above will be assigned by IANA within the common parameter
range of the SIGTRAN UAs and may change its value in further
versions of this document.
The Load Distribution parameter contains the following fields:
Load Distribution field: n x 32-bits (unsigned integer)
THe Load Distribution has the same purpose for the Load Group that
the Traffic Mode Type has for the Application Server: it identifies
the traffic distribution algorithm to be used within the Load
Group. Valid values for Load Distribution are as follows:
1 Override
2 Loadshare
3 Broadcast
3.2. Messages
This extension adds the Load Distribtution parameter as an OPTIONAL
parameter to be used in conjunction with the common Traffic Mode Type
in the following messages: [1]
REG REQ Registration Request message
ASPAC ASP Active message
ASPAC Ack ASP Active Ack message
3.2.1. Registration Request (REG REQ)
This extension supplements the Registration Request (REG REQ) message
by permitting the following optional parameters to be included in the
B. Bidulock Version 0.0 Page 8
Internet Draft UA Load Grouping January 10, 2002
Routing Key [M3UA...TUA] parameter or Link Key [IUA...M2UA] parameter
within the message:
Extension Subparameters
-----------------------------------------
Load Distribution Optional
The Load Distribution parameter is used in the Routing (Link) Key to
further refine the traffic distribution to be received by the
registering ASP.
The format of the resulting Routing Key or Link Key parameter 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK(LK)-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Selection (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Distribution (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ or \
/ Interface Identifier(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No other changes to the REG REQ message, Routing Key or Link Key
parameters format are provided by this extension[1].
When an ASP wishes to register within a Load Group associated with an
Application Server, it includes the Load Selection parameter and Load
Distribution in the Routing (Link) Key for that Application Server in
the REG REQ message.
The Load Distribtuion parameter indicates the traffic distribution
method to be used within the Load Group as identified by the Load
Selection.
3.2.2. Registration Response (REG RSP)
This extension adds the following Registration Status values to the
)Registration Status field in the REG RSP message:
B. Bidulock Version 0.0 Page 9
Internet Draft UA Load Grouping January 10, 2002
0xZZ Error - Unsupported/Invalid Load Distribution
EDITOR'S NOTE:- The Registration Status value shown as 0xZZ)
above will be assigned by IANA as a value of the UA-specific
Registration Status parameter for each SIGTRAN UA and may
change its value in further versions of this document.
3.2.3. ASP Active (ASPAC)
This extension supplements the ASPAC message by permitting the
following optional parameters to be included in the message:
Extension Parameters
-----------------------------------------
Load Distribution Optional
The format of the resulting ASPAC 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 = 0x000b | Length = 8 |
+---------------------------------+-----------------------------+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x001d | Length = 8 |
+---------------------------------+-----------------------------+
\ \
/ Load Selection(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0xXXXX | Length = 8 |
+---------------------------------+-----------------------------+
| Load Distribution |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ or \
/ Interface Identifier(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+---------------------------------+-----------------------------+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EDITOR'S NOTE:- The parameter tag values shown as 0xXXXX
B. Bidulock Version 0.0 Page 10
Internet Draft UA Load Grouping January 10, 2002
above will be assigned by IANA within the common parameter
range of the SIGTRAN UAs and may change its value in further
versions of this document.
No other changes to the ASPAC message format are provided by this
extension[1].
When an ASP wishes to activate only within a Load Group associated
with an Application Server, it includes the Load Selection and Load
Distribtuion parameters in the ASPAC message.
The Load Distribtuion parameter indicates the traffic distribution
method to be used within the Load Group as identified by the Load
Selection.
3.2.4. ASP Active Ack (ASPAC ACK)
This extension supplements the ASPAC ACK message by permitting the
following optional parameters to be included in the message:
Extension Parameters
-----------------------------------------
Load Distribution Optional
The format of the resulting ASPAC ACK message is as follows:
B. Bidulock Version 0.0 Page 11
Internet Draft UA Load Grouping January 10, 2002
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 = 0x001d | Length = 8 |
+---------------------------------+-----------------------------+
\ \
/ Load Selection(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0xXXXX | Length = 8 |
+---------------------------------+-----------------------------+
| Load Distribtuion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ or \
/ Interface Identifier(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+---------------------------------+-----------------------------+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EDITOR'S NOTE:- The parameter tag values shown as 0xXXXX
above will be assigned by IANA within the common parameter
range of the SIGTRAN UAs and may change its value in further
versions of this document.
No other changes to the ASPAC ACK message format are provided by this
extension[1].
When an ASP has requested activation within a Load Group or the SG
otherwise activates the ASP within a Load Group the SG responds with
an ASPAC ACK message including the Load Selection that identifies the
Load Group and optionally includes the Load Distribution for the Load
Group in which the ASP has been activated. If the ASP included the
Load Distribution parameter in the ASPAC message, the SG MUST include
the Load Distribution parameter in the response ASPAC ACK message.
The Load Distribtuion parameter indicates the traffic distribution
method to be used within the Load Group as identified by the Load
Selection.
B. Bidulock Version 0.0 Page 12
Internet Draft UA Load Grouping January 10, 2002
3.2.5. Error (ERR)
This extension supplements the Error (ERR) message by adding the
following values to the common mandatory Error Code parameter in the
ERR message:
0xYY Invalid/Unsupported Load Distribution
EDITOR'S NOTE:- The Error Code value shown throughout this
document as 0xYY) will be assigned by IANA as a value of the
common Error Code parameter for SIGTRAN UAs and may change
its value in further versions of this document.
This new error code is interpreted as follows:
The "Invalid/Unsupported Load Distribution" error would be sent by an
SGP if an ASP sends an ASP Active with an invalid or unsupported
Load Distribution. An example would be a case in which the SGP
did not support override within a Load Group.
No other changes to the ERR message or Error Code parameter values
are provided by this extension. See Section 4 for extension
procedures associated with the ERR message.
4. Procedures
This Load Grouping extension provides for an additional level of
control over the traffic distribution patterns within an Application
Server. This extension provides the Load Distribution parameter
which may be optionally included in the REG REQ, ASPAC and ASPAC ACK
messages. In addition, it supplements the ASP State Maintenance and
ASP Traffic Maintenance procedures.
4.1. ASP State Maintenance
In addition to the SGP mainting the state of each remote ASP in each
Application Server that the ASP is configured to receive traffic,
under this extension, the SGP MAY also maintain the state of each
remote ASP in each Load Group within an Application server that the
ASP is configured to receive traffic. The Load Group state is
maintained separate from the ASP and AS states.
4.1.1. Load Group State
The state of the Load Group is maintained in the Signalling User
Adaptation Layer on the SGPs. The state of the Load Group changes
due ASP state transitions. The possible states of a Load Group are:
LG-DOWN: The Load Group is unavaialble. This state implies
that all related ASPs are in the ASP-DOWN state for
this Load Group. Initially, the Load Group will be
B. Bidulock Version 0.0 Page 13
Internet Draft UA Load Grouping January 10, 2002
in this state.
LG-INACTIVE: The Load Group is available but no application
traffic is active (i.e, one or more related ASPs are
in the ASP-INACTIVE state, but none are in the ASP-
ACTIVE state within the Load Group).
LG-ACTIVE: The Load Group is available and application traffic
is active. This state implies that at least one ASP
is in the ASP-ACTIVE state within the Load Group.
4.1.2. Application Server State
Where ASPs are configured to operation within Load Groups under this
extension, the Application Server state is interpreted as provided in
the Signalling User Adaptation Layer specifications [M3UA...TUA].
4.2. ASP Traffic Maintenance
4.2.1. ASP Active Procedures
This Load Grouping extension supplements the ASP Active Procedures as
follows:
When an ASP sends an ASPAC message to activate the ASP within an
Application Server, the ASP MAY choose to activate within a Load
Group for the specified AS by including the Load Selection parameter
in the )ASPAC message.
When an SGP receives an ASPAC message with a Load Selection parameter
in the message, or where the SGP is otherwise configured to activate
the ASP in a configured Load Group, when the SGP moves the ASP to the
ASP-ACTIVE state for the AS, it also moves the ASP to the ASP-ACTIVE
state for the Load Group identified by the Load Selector field in the
Load Selection parameter. In either case, if the activation is
successful, the SGP includes the Load Selection parameter in the
ASPAC ACK message.
If the Load Selector in the ASPAC message is invalid, the SGP
responds with ERR("Error - Invalid Load Selector"). If the Load
Selection parameter is not present in the ASPAC message and the SGP
is configured to require one, or the Load Selector field is not valid
or unconfigured for the Application Server, the SGP responsds with
ERR("Error - Unsupported/Unconfigured/Missing Load Selector"). If
the Load Selection parameter contains an invalid or unsupported Load
Distribution value, or the Load Selection parameter is missing but
the SGP cannot determine the distribution applicable to the Load
Group without one, the SGP response with ERR("Error -
Invalid/Unsupported/Missing Load Distribution").
There are three modes of Application Server traffic handling in the
SGP at the Application Server level and three modes of AS traffic
handling at the Load Group level: Override, Loadshare and Broadcast.
When included, the Traffic Mode Type parameter in the ASPAC message
B. Bidulock Version 0.0 Page 14
Internet Draft UA Load Grouping January 10, 2002
indicates the traffic handling mode to be used in a particular
Application Server between Load Groups. When included, the Load
Distribution field in the Load Selection parameter indicates the
traffic handling mode to be used between ASPs within a Load Group.
In the case of an Override mode AS, reception of an ASP Active
message at an SGP may move a Load Group to the LG-ACTIVE state. When
an LG moves to the LG-ACTIVE state in an Override mode AS, this
causes the (re)direction of all traffic for the AS to the active Load
Group. Distribution of traffic within the Load Group is determine on
the basis of the Load Distribution mode of the Load Group. Any
previously active Load Group is now considered to be in state LG-
INACTIVE and SHOULD no longer receive traffic from the SGP within the
AS. The SGP then MUST send a Notify message ("Alternate ASP Active")
and include the Load Selection parameter in the Notify message
indicating the Load Group that has become active.
In the case of a Loadshare mode AS, the reception of an ASP Active
message at an SGP that moves a Load Group to the LG-ACTIVE state
causes the direction of specific traffic flows associated with the
Load Selector to the Load Group. The assignment of traffic flows to
Load Selector values is implementation depenedent, but could be based
on specific information in the protocol data message.
In the case of a Broadcast mode AS, reception of an ASP Active
message at an SGP that results in moving a Load Group to the LG-
ACTIVE state within the AS causes the direction of traffic to the
newly active Load Group in addition to all the other LGs that are
currently active for the AS. The algorithm at the SGP for
broadcasting traffic within an AS to all the active ASPs is a simple
broadcast algorithm, where every message is sent to each of the
active Load Groups.
4.2.2. ASP Inactive Procedures
This Load Grouping extension supplements the ASP Active procedures of
the UAs as follows:
When an ASP wishes to withdraw from a specific Load Group within an
Application Server, the ASP sends an ASP Inactive message to the SGP
with a Load Selection parameter included in the message. In the case
where the ASP does not include the Load Selection parameter in the
ASP Inactive message, the SGP must know via configuration data which
Load Groups the ASP is a member. Upon receiving an ASP Inactive
message with included or implied Load Selection(s), the SGP moves the
ASP to the ASP-INACTIVE state in each of the Load Groups indicated.
4.3. Registration
UAs permit Application Server Processes to register for the Routing
Context (Interface Identifier) associated with a Routing Key (Link
Key). This draft extends the registration procedure to also permit
the Application Server Process to register for a Load Group
identifier in addition to the Routing Contex/Interface Id. This is
B. Bidulock Version 0.0 Page 15
Internet Draft UA Load Grouping January 10, 2002
performed using a Load Group which has the same form as the Routing
Key, but has some additional fields which are only applicable to
Loadsharing.
In addition to the normal registration procedures of the UAs, the
following additional error conditions can occur:
"Error - Invalid Load Group"
This error MUST be sent in an Error (ERR) message if the SG
determines that the Load Group is invalid.
"Error - Unsupported/Unconfigured Load Group"
This error MUST be sent in an Error (ERR) message whenever the
SG determines that the Load Group provided in a REG REQ message
has not be configured and the SG does not support dynamic
allocation of Load Selectors for the specified Key, and MUST be
sent in an Error (ERR) message whenever the SG determines that
the Load Group provided in a REG REQ message is not supported
by the SG.
"Error - Invalid/Unsupported/Missing Load Distribution"
This error MUST be sent in an Error (ERR) message whenever the
SG determines that the Load Distribution associated wtih a Load
Group is invalid, is not supported by the SG, or is required to
determine the Load Distribution algorithm of the Load Group but
is missing from the Load Group in the REG REQ message.
4.4. ASP Activation
When activating, this draft extends the UA activation procedures by
permitting an optional Load Selection parameter to be included in the
ASP Active (ASPAC) and ASP Active Ack (ASPAC Ack) messages. The Load
Selection parameter is used to indicate for which Load Group the
concerned Application Server is becoming active.
Whenever the SG is unable to activate the ASP within the selected
Application Server Load Group, the SG MUST reply with an Error (ERR)
message containing one of the errors defined in the UA documents[1],
or one of the following additional errors:
"Error - Invalid Load Group Identifier"
4.5. ASP Deactivation
When deactivating, this draft extends the UA activation procedures by
permitting an optional Load Selection parameter to be included in the
ASP Inactive (ASPIA) and ASP Inactive Ack (ASPIA Ack) message. The
Load Selection parameter is used to indicate for which traffic in the
Load Group the concerned Application Server is becoming inactive.
4.6. ASP Failure
When an ASP fails that was supporting load-sharing application
servers, the NTFY("ASP Failure")
B. Bidulock Version 0.0 Page 16
Internet Draft UA Load Grouping January 10, 2002
4.7. ASP Override
4.8. Notification
When the SGP or IPSP notifies its UA peer with a NTFY messages which
concerns an ASP, it MUST include the Load Group (if available) along
with the ASP Identifier in the message. The NTFY messages to which
this applies are:
NTFY("ASP Failure") -
When the SGP or IPSP notifies the active and inactive ASPs in
an AS that it has detected the failure of an ASP or the failure
of an association to an ASP (i.e. SCTP Communication Lost
Indication), it MUST include the Load Group (if available) with
the ASP Identifier in the message. When the Routing
Context(s)/Interface Identifier(s) associated with the
Application Servers cannot be implied at the ASP from static
configuration data, the Routing Context/Interface Identifier(s)
MUST also be placed in the NTFY("ASP Failure") message. The
notifying SGP or IPSP MAY also place the Load Selection
parameter into the NTFY("ASP Failure") message to indicate the
traffic which was applicable to the load selection at the time
of the failure.
The purpose of this procedure is to inform the active and
inactive ASPs, not only of the ASP failure, but of the identity
of the ASP and the load selection for which the failed ASP was
responsible.
NTFY("Alternate ASP Active in AS") -
When the SGP or IPSP notifies the previously active ASP in a
override AS that an alternate ASP has become active using the
NTFY("Alternate ASP Active in AS") message, it MUST include the
Load Group (if available) with the ASP Identifier in the
message.
The purpose of this procedure is to inform the previously active ASP,
not only of the that another ASP has taken over the traffic for which
the notified ASP was previously responsible, but to also indicate the
identify of the overriding ASP and the load selection that was
overridden.
5. Security
6. IANA Considerations
This extension adds the following parameter tag value (described in
Section 3) to the Common Parameter numbering space for the UAs
[M3UA...TUA].
0xXXXX Load Distribution
B. Bidulock Version 0.0 Page 17
Internet Draft UA Load Grouping January 10, 2002
EDITOR'S NOTE:- The Load Distribution parameter tag value
shown throughout this document as 0xXXXX will be assigned by
IANA within the common parameter range of the SIGTRAN UAs and
may change its value in further versions of this document.
This extension adds the following value to the Error Code parameter
of the UAs.
0xYY Invalid/Unsupported Load Distribution
EDITOR'S NOTE:- The Error Code value shown as 0xYY) above
will be assigned by IANA as a value of the common Error Code
parameter for SIGTRAN UAs and may change its value in further
versions of this document.
This extension adds the following value to the Registration Status
field of the Registration Result parameter for the UAs [M3UA...TUA].
0xZZ Error - Invalid/Unsupported Load Distribution
EDITOR'S NOTE:- The Registration Status value shown as 0xZZ)
above will be assigned by IANA as a value of each UA-specific
Registration Status parameter for each SIGTRAN UA and may
change its value in further versions of this document.
7. Acknowledgements
The authors would like to thank Ken Morneault, Barry Nagelberg,
Benjamin J. Wilson, Jacques Rajchgod, Greg Sidebottom and Gery
Verwimp for their valuable comments and suggestions.
8. Author's Addresses
Brian Bidulock Phone: +1-972-839-4489
OpenSS7 Corporation Email: bidulock@openss7.org
4701 Preston Park Boulevard
Suite 424
Plano, TX 75093
USA
This draft expires July, 2002.
B. Bidulock Version 0.0 Page 18
Internet Draft UA Load Grouping January 10, 2002
Endnotes
[1] For a detailed description of these messages, see Section 3 of
M3UA, SUA and TUA [M3UA...TUA].
References
IUA.
K. Morneault, S. Rengasami, M. Kalla and G. Sidebottom, "ISDN
Q.921-User Adaptation Layer," RFC 3057, The Internet Society
(November, 2000).
DUA.
A. Vydyam, R. Mukundan, N. Mangalpally and K. Morneault,
"DPNSS/DASS 2 Extensions to the IUA Protocol," <draft-ietf-
sigtran-dua-00.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (July 2001). Work In
Progress. [Expired]
V5UA.
E. Weilandt, N. Khanchandani and F. Ergincan, "V5.2-User
Adaption Layer (V5UA)," <draft-ietf-sigtran-v5ua-01.txt>,
Internet Engineering Task Force - Signalling Transport Working
Group (July 2001). Work In Progress. [Expired]
M2UA.
K. Morneault, R. Dantu, G. Sidebottom, T. George, B. Bidulock
and J. Heitz, "SS7 MTP2-User Adaptation Layer (M2UA)," <draft-
ietf-sigtran-m2ua-11.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (November, 2001). Work In
Progress.
M3UA.
G. Sidebottom, J. Pastor-Balbes, I. Rytina, G. Mousseau, L. Ong,
H. J. Schwarzbauer, K. Gradischnig, K. Morneault, M. Kalla, N.
Glaude, B. Bidulock and N. Glaude, "SS7 MTP3-User Adaptation
Layer (M3UA)," <draft-ietf-sigtran-m3ua-10.txt>, Internet
Engineering Task Force - Signalling Transport Working Group
(November, 2001). Work In Progress.
SUA.
J. Loughney, G. Sidebottom, G. Mousseau, S. Lorusso, L. Coene,
G. Verwimp, J. Keller, F. E. Gonzalez, W. Sully, S. Furniss and
B. Bidulock, "SS7 SCCP-User Adaptation Layer (SUA)," <draft-
ietf-sigtran-sua-09.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (June 15, 2001). Work In
Progress.
TUA.
B. Bidulock, "SS7 TCAP-User Adaptation Layer (TUA)," <draft-
bidulock-sigtran-tua-00.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (January 2002). Work In
Progress.
B. Bidulock Version 0.0 Page 19
Internet Draft UA Load Grouping January 10, 2002
RFC 2960.
R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer,
T. Taylor, I. Rytina, H. Kalla, L. Zhang and V. Paxson, "Stream
Control Transmission Protocol (SCTP)," RFC 2960, The Internet
Society (February 2000).
LOADSEL.
B. Bidulock, "Load Selection Extension for Signalling User
Adaptation Layers (LOADSEL)," <draft-bidulock-sigtran-
loadsel-00.txt>, Internet Engineering Task Force - Signalling
Transport Working Group (January 2002). Work In Progress.
RFC 2119.
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119 - BCP 14, Internet Engineering Task Force
(March 1997).
B. Bidulock Version 0.0 Page 20
Internet Draft UA Load Grouping January 10, 2002
List of Tables
Table 1 Sample Configurations ................................. 7
List of Illustrations
Figure 1 Existing Traffic Distribution ........................ 3
Figure 2 Load Group Traffic Distribution ...................... 5
Table of Contents
1 Introduction ................................................ 2
1.1 Scope ..................................................... 2
1.2 Terminology ............................................... 2
1.3 Overview .................................................. 2
1.3.1 Existing Traffic Distribution ........................... 3
1.3.2 Extended Traffic Distribution ........................... 4
1.4 Sample Configurations ..................................... 6
2 Conventions ................................................. 7
3 Protocol Elements ........................................... 7
3.1 Parameters ................................................ 7
3.1.1 Load Distribution ....................................... 7
3.2 Messages .................................................. 8
3.2.1 Registration Request (REG REQ) .......................... 8
3.2.2 Registration Response (REG RSP) ......................... 9
3.2.3 ASP Active (ASPAC) ...................................... 10
3.2.4 ASP Active Ack (ASPAC ACK) .............................. 11
3.2.5 Error (ERR) ............................................. 13
4 Procedures .................................................. 13
4.1 ASP State Maintenance ..................................... 13
4.1.1 Load Group State ........................................ 13
4.1.2 Application Server State ................................ 14
4.2 ASP Traffic Maintenance ................................... 14
4.2.1 ASP Active Procedures ................................... 14
4.2.2 ASP Inactive Procedures ................................. 15
4.3 Registration .............................................. 15
4.4 ASP Activation ............................................ 16
4.5 ASP Deactivation .......................................... 16
4.6 ASP Failure ............................................... 16
4.7 ASP Override .............................................. 17
4.8 Notification .............................................. 17
5 Security .................................................... 17
6 IANA Considerations ......................................... 17
7 Acknowledgements ............................................ 18
8 Author's Addresses .......................................... 18
B. Bidulock Version 0.0 Page 21
Internet Draft UA Load Grouping January 10, 2002
Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedure for
copyrights defined in the Internet Standards process must be
followed, or as required to translate into languages other than
English.
The limited permission granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and 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
MECHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
B. Bidulock Version 0.0 Page 22
|
Documentation