| draft-bidulock-sigtran-loadgrp-05Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-bidulock-sigtran-loadgrp-05.txt.
Network Working Group Brian Bidulock
INTERNET-DRAFT OpenSS7 Corporation
Intended status: PROPOSED STANDARD February 3, 2007
Expires in August 2007
Load Grouping Extension
for
Signalling User Adaptation Layers
<draft-bidulock-sigtran-loadgrp-05.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 as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire in August 2007.
Copyright
Copyright (C) The IETF Trust (2007).
Abstract
This Internet-Draft describes an extension parameter and procedure
to the Signalling User Adaptation Protocols [IUA], [M2UA], [M3UA],
[SUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA], based on the Stream
Transmission Control Protocol (SCTP) [SCTP] 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)
B. Bidulock Version 0.5 Page 1
Internet Draft UA LOADGRP February 3, 2007
control.
The described procedure provides for Override, Load-share and
Broadcast traffic mode operation within a Load Group consisting of one
or more Application Server Processes (ASPs) resulting in a mixture 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 improved distribution of
traffic over ASPs and Signalling Gateway Processes (SGPs).
Contents
A complete table of contents, list of illustrations and tables, and
a change history, are included at the end of this document.
1. Introduction
1.1. Scope
This Internet-Draft provides the Load Distribution parameter and
associated procedures in extension to the parameters and procedures of
the Signalling User Adaptation Layers (UAs) [IUA], [M2UA], [M3UA],
[SUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA], and the UA 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. Abbreviations
AS --Application Server.
ASP --Application Server Process.
IANA --Internet Assigned Numbers Authority
I-D --Internet-Draft
IETF --Internet Engineering Task Force
IP --Internet Protocol.
IPSP --IP Signalling Point.
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.
B. Bidulock Version 0.5 Page 2
Internet Draft UA LOADGRP February 3, 2007
WG --Working Group
1.3. Terminology
LOADGRP supplements the terminology used in the UA documents [IUA],
[M2UA], [M3UA], [SUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA] and the
UA Load Selection [LOADSEL] 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 Selector (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) [SCTP] Signalling User
Adaptation Layers [IUA], [M2UA], [M3UA], [SUA], [DUA], [V5UA],
[GR303UA], [ISUA], [TUA].
1.4. 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 amenable to large scale systems that need to
adapt to dynamic traffic loading or need live reconfiguration for
maintenance purposes.
LOADGRP extensions to the Signalling User Adaptation Layers [IUA],
[M2UA], [M3UA], [SUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA] permits
close control over the grouping of Application Server Processes
serving an Application Server that provides the capability to group
ASPs into load groups not existing in the current scheme.
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 work groups, not does
it provide coordinated control of the role of groups of ASPs serving
an ASP. As a result, the existing scheme does not scale well in this
regard.
B. Bidulock Version 0.5 Page 3
Internet Draft UA LOADGRP February 3, 2007
LOADGRP 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.4.1. Existing Traffic Distribution
Figure 1 illustrates the existing traffic distribution algorithm
that is used across the Signalling User Adaptation Layers.
When an SGP distributes a Signalling User Adaptation Layer message
toward 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, Load-share and
Broadcast.
The detailed actions taken for these distribution algorithms are
described in Section 4 of the Signalling User Adaptation Layer
specifications [IUA], [M2UA], [M3UA], [SUA], [DUA], [V5UA], [GR303UA],
[ISUA], [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
____
Traffic /....\
Mode Type ____|__....|
_______ | |...|
| |------------------->| ASP |...|
| SGP |-----\ |_______|...|
|_______|----\ \ ____|__....|
\--\ \ \ | |...|
\ \ \---------->| ASP |...|
_______ \ \ |_______|...|
| | \ \ |......| Application
| SGP | \ \ |......| Server
|_______| \ \ |......|
\ \ |......|
\ \ ____|__....|
\ \ | |...|
\ \---->| ASP |...|
\ |_______|...|
\ ____|__....|
\ | |...|
\-->| ASP |...|
|_______|...|
|......|
\____/
Figure 1. Existing Traffic Distribution
B. Bidulock Version 0.5 Page 4
Internet Draft UA LOADGRP February 3, 2007
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 Load-share:- When distributing messages to a Load-
share Application Server, the SGP selects one of the ASPs that are
active for the Application Server using an implementation
dependent load-sharing 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 Adaptation 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.
LOADGRP enhances the traffic distribution algorithms of the existing
Signalling User Adaptation Layers by introducing an additional level
of distribution.
1.4.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 LOADGRP.
LOADGRP 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 Selector [LOADSEL] within the Application Server.
The Load Selector identifies the traffic flows that will be
distributed to an associated Load Group within an Application Server.
When an SGP distributes a Signalling User Adaptation Layer message
toward 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 distribution algorithm determined by the Load
Distribution that is associated with the Application Server and the
Load Selector position of the Load Group within the AS.
The Traffic Mode Type continues to describe three general
distribution algorithms: Override, Load-share and Broadcast. The
change in the behaviour of the SGP when selecting an ASP for traffic
distribution introduced by LOADGRP is that the SGP also takes into
account the concept of a Load Group as identified within an AS by its
Load Selector.
B. Bidulock Version 0.5 Page 5
Internet Draft UA LOADGRP February 3, 2007
____ ____
Traffic Load /....\ /....\
Mode Type Group|...___||__....|
_______ |..| |...|
| |---+---------------->| ASP |...|
| SGP | \ |..|_______|...|
|_______|-\ \ |...___||__....|
\ \ |..| |...|
\ \------------>| ASP |...|
_______ | |..|_______|...|
| | | |......||......| Application
| SGP | | \____/ |......| Server
|_______| | ____ |......|
| Load /....\ |......|
| Group|...___||__....|
| |..| |...|
+---------------->| ASP |...|
\ |..|_______|...|
\ |...___||__....|
\ |..| |...|
\------------>| ASP |...|
|..|_______|...|
|......||......|
\____/ \____/
Figure 2. Load Group Traffic Distribution
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.
Traffic Mode Type Load-share:- When distributing messages to a Load-
share Application Server, the SGP selects one of the Load Groups
that are active for the Application Server using an implementation
dependent load-sharing algorithm based on the Load Selector
[LOADSEL] associated with the Load Group.
Traffic Mode Type Broadcast:- When distributing 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
B. Bidulock Version 0.5 Page 6
Internet Draft UA LOADGRP February 3, 2007
distribution algorithms that are provided in the Traffic Mode Type:
Override, Load-share 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 Load-share:- When distributing messages within a
Load-share Load Group, the SGP selects one of the ASPs that are
active for the Load Group using an implementation dependent load-
sharing 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 ASPs will process the
message.)
The result of LOADGRP 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.5. Sample Configurations
Although LOADGRP 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:
B. Bidulock Version 0.5 Page 7
Internet Draft UA LOADGRP February 3, 2007
Table 1. Sample Configurations
+----+----------+----------+---------------------------------------+
| | Traffic | Load | |
|Mode| Mode | Distri- |Description |
| | Type | bution | |
+----+----------+----------+---------------------------------------+
| 1 |Override |Load-share|This mode permits a load-share group |
| | | |of ASPs to override another load-share |
| | | |group of ASPs. |
+----+ +----------+---------------------------------------+
| 2 | |Broadcast |This mode allows "mirrored" ASPs to |
| | | |override each other. |
+----+----------+----------+---------------------------------------+
| 3 |Load-share|Override |This mode allows ASPs to override each |
| | | |other within a traffic slot of a load- |
| | | |share group. |
+----+ +----------+---------------------------------------+
| 4 | |Broadcast |This mode permits "striping" and |
| | | |"mirroring" with load-sharing 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 | |Load-share|This mode permits "mirroring" and |
| | | |"striping" including automatic load- |
| | | |sharing within a mirror image. |
+----+----------+----------+---------------------------------------+
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Protocol Elements
The following subsections describe the parameters which are added by
LOADGRP, their format and the message in which they are used.
3.1. Parameters
LOADGRP 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 [M2UA], [M3UA], [SUA], [ISUA], [TUA] and
Load Selector parameter [LOADSEL] to further refine the traffic
B. Bidulock Version 0.5 Page 8
Internet Draft UA LOADGRP February 3, 2007
distribution algorithm for an ASP in a Load Group serving an
Application Server. The Load Selector 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: <1>
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 = 0x001a | Length = 8 |
+ - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
| Load Distribution |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Load-share
3 Broadcast
3.2. Messages
LOADGRP adds the Load Distribution parameter as an OPTIONAL
parameter to be used in conjunction with the common Traffic Mode Type
in the following messages: <2>
REG REQ Registration Request message
ASPAC ASP Active message
ASPAC ACK ASP Active Ack message
3.2.1. Registration Request (REG REQ)
LOADGRP supplements the Registration Request (REG REQ) message by
permitting the following optional parameters to be included in the
Routing (Link) Key [M2UA], [M3UA], [SUA], [ISUA], [TUA] parameter or
Link Key [IUA], [M2UA], [DUA], [V5UA], [GR303UA] parameter within the
message:
B. Bidulock Version 0.5 Page 9
Internet Draft UA LOADGRP February 3, 2007
Extension Sub-parameters
-----------------------------------------
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) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Distribution parameter indicates the traffic distribution
method to be used within the Load Group as identified by the Load
Selection.
No other changes to the REG REQ message, Routing Key or Link Key
parameters format are provided by LOADGRP<2>.
3.2.2. Registration Response (REG RSP)
LOADGRP adds the following Registration Status values to the
)Registration Status field in the REG RSP message: <3>
16 Error - Unsupported/Invalid Load Distribution
B. Bidulock Version 0.5 Page 10
Internet Draft UA LOADGRP February 3, 2007
3.2.3. ASP Active (ASPAC)
LOADGRP 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: <4>
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 |
+---------------------------------------------------------------+
\ \
/ Routing Context /
\ or \
/ Interface Identifier(s) /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x001a | Length = 8 |
+ - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
| Load Distribution |
+-------------------------------+-------------------------------+
| Tag = 0x001d | Length = 8 |
+ - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
\ \
/ Load Selector(s) /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+ - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When an ASP wishes to activate only within a Load Group associated
with an Application Server, it includes the Load Selector and Load
Distribution parameters in the ASPAC message.
The Load Distribution parameter indicates the traffic distribution
method to be used within the Load Group as identified by the Load
Selector.
B. Bidulock Version 0.5 Page 11
Internet Draft UA LOADGRP February 3, 2007
No other changes to the ASPAC message format are provided by
LOADGRP<2>.
3.2.4. ASP Active Ack (ASPAC ACK)
LOADGRP 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: <5>
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 |
+---------------------------------------------------------------+
\ \
/ Routing Context /
\ or \
/ Interface Identifier(s) /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x001a | Length = 8 |
+ - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
| Load Distribution |
+-------------------------------+-------------------------------+
| Tag = 0x001d | Length = 8 |
+ - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
\ \
/ Load Selector(s) /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+ - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Selector 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
B. Bidulock Version 0.5 Page 12
Internet Draft UA LOADGRP February 3, 2007
the Load Distribution parameter in the response ASPAC ACK message.
The Load Distribution parameter indicates the traffic distribution
method to be used within the Load Group as identified by the Load
Selector.
No other changes to the ASPAC ACK message format are provided by
LOADGRP<2>.
3.2.5. Error (ERR)
LOADGRP supplements the Error (ERR) message by adding the following
values to the common mandatory Error Code parameter in the ERR
message: <6>
28 Unsupported Load Distribution
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 LOADGRP. See Section 4 for extension procedures
associated with the ERR message.
B. Bidulock Version 0.5 Page 13
Internet Draft UA LOADGRP February 3, 2007
Notes for Section 3
<1> EDITOR'S NOTE:- The parameter tag values shown as 0x001a 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.
<2> For a detailed description of these messages, see Section 3 of
the specific UA document [M2UA], [M3UA], [SUA], [ISUA], [TUA].
<3> EDITOR'S NOTE:- The Registration Status value shown as 16 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.
<4> EDITOR'S NOTE:- The parameter tag values shown as 0x001a 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.
<5> EDITOR'S NOTE:- The parameter tag values shown as 0x001a 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.
<6> EDITOR'S NOTE:- The Error Code value shown throughout this
document as 28 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.
4. Procedures
LOADGRP provides for an additional level of control over the traffic
distribution patterns within an Application Server. LOADGRP 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 maintaining the state of each remote ASP in
each Application Server that the ASP is configured to receive traffic,
under LOADGRP, 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
B. Bidulock Version 0.5 Page 14
Internet Draft UA LOADGRP February 3, 2007
ASP state transitions. The possible states of a Load Group are:
LG-DOWN: The Load Group is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for
this Load Group. Initially, the Load Group will be 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 for operation within Load Groups under
LOADGRP, the Application Server state is interpreted as provided in
the Signalling User Adaptation Layer specifications [M2UA], [M3UA],
[SUA], [ISUA], [TUA].
4.2. ASP Traffic Maintenance
4.2.1. ASP Up Procedures
LOADGRP extends the ASP Up procedures to include the concept of the
Load Group.
Whenever an SGP moves an ASP to the ASP-UP state, it also moves the
ASP to the ASP-INACTIVE state in all Load Groups in all Application
Servers for which the ASP is configured. This may have the effect of
changing the Load Group state, requiring the generation of NTFY
messages as described under ""Notify Procedures"" below.
4.2.2. ASP Down Procedures
LOADGRP extends the ASP Down procedures to include the concept of
the Load Group.
Whenever an SGP moves an ASP to the ASP-DOWN state, it also moves
the ASP to the ASP-DOWN state in all Load Groups in all Application
Servers to which the ASP belongs. This may have the effect of
changing the Load Group state, requiring the generation of NTFY
messages as described under ""Notify Procedures"" below.
4.2.3. ASP Active Procedures
When activating, LOADGRP extends the UA activation procedures by
permitting an optional Load Distribution parameter to be included in
the ASP Active (ASPAC) and ASP Active Ack (ASPAC ACK) messages. The
Load Selector parameter is used to indicate for which Load Group the
B. Bidulock Version 0.5 Page 15
Internet Draft UA LOADGRP February 3, 2007
concerned Application Server is becoming active [LOADSEL] and the Load
Distribution parameter is used to indicate the traffic mode of the
Load Group.
LOADGRP 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 Selector parameter in the
ASPAC message.
When an SGP receives an ASPAC message with a Load Selector 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 parameter.
In either case, if the activation is successful, the SGP includes the
Load Selector parameter in the ASPAC ACK message.
If the Load Selector in the ASPAC message is invalid, the SGP
responds with ERR("Invalid Load Selector"). If the Load Selector
parameter is not present in the ASPAC message and the SGP is
configured to require one, or the Load Selector parameter is not valid
or not configured for the Application Server, the SGP responds with
ERR("Missing Parameter"). If the Load Selector parameter contains an
invalid or unsupported Load Distribution value, or the Load
Distribution parameter is missing but the SGP cannot determine the
distribution applicable to the Load Group without one, the SGP
responds with ERR("Unsupported 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, Load-share and Broadcast.
When included, the Traffic Mode Type parameter in the ASPAC message
indicates the traffic handling mode to be used in a particular
Application Server between Load Groups. When included, the Load
Distribution parameter indicates the traffic handling mode to be used
between ASPs within the Load Group indicated by the Load Selector
parameter.
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 NTFY("Alternate ASP Active") and
include the Load Selector parameter in the Notify message indicating
the Load Group that has become active.
B. Bidulock Version 0.5 Page 16
Internet Draft UA LOADGRP February 3, 2007
In the case of a Load-share 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 dependent, 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.4. ASP Inactive Procedures
When deactivating, LOADGRP extends the UA activation procedures by
permitting an optional Load Selector parameter to be included in the
ASP Inactive (ASPIA) and ASP Inactive Ack (ASPIA ACK) message. The
Load Selector parameter is used to indicate for which Load Group the
concerned Application Server is becoming inactive.
LOADGRP 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 Selector parameter included in the message. In the case
where the ASP does not include the Load Selector 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 Selector, the SGP moves the ASP to the
ASP-INACTIVE state in each of the Load Groups indicated.
4.2.5. Notify Procedures
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("AS-ACTIVE"), NTFY("AS-PENDING"), NTFY("AS-INACTIVE") -
When the SGP or IPSP notifies the active and inactive ASPs in an AS
that it has detected the transition of the Application Server to the
AS-ACTIVE, AS-PENDING or AS-INACTIVE state, or that it has detected
the transition of a Load Group to the LG-ACTIVE state for the AS, it
MUST include the Load Selector, if available, indicating the Load
Group which has changed state along with the ASP Identifier, if any,
in the NTFY message.
When the Routing Context (Interface Identifier) associated with the
Application Server cannot be implied at the ASP from static
B. Bidulock Version 0.5 Page 17
Internet Draft UA LOADGRP February 3, 2007
configuration data, the Routing Context (Interface Identifier) MUST
also be placed in the NTFY message.
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 Selector (if available) with the ASP
Identifier in the message.
When the Routing Context (Interface Identifier) associated with the
Application Servers cannot be implied at the ASP from static
configuration data, the Routing Context (Interface Identifier) MUST
also be placed in the NTFY("ASP Failure") message.
The notifying SGP or IPSP MAY also place the Load Selector 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, it MUST include
the Load Selector indicating the Load Group, if any, with the ASP
Identifier, if available, in the NTFY 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.
When an ASP becomes ASP-INACTIVE for a Load Group or Application
Server for the first time, the SGP MAY send NTFY messages indicating
the state of the Application Server and the Load Groups in the
application server to the newly inactive ASP. Application Server
state is notified by sending the appropriate NTFY message without a
Load Selector parameter present in the message. Load Group state is
notified by sending the appropriate NTFY message with a Load Selector
parameter indicating the Load Group in the message.
4.3. Registration
UAs permit Application Server Processes to register for the Routing
Context (Interface Identifier) associated with a Routing Key (Link
Key). LOADGRP extends the registration procedure to also permit the
Application Server Process to register a )Load Distribution against a
Load Selector identifying a Load Group in addition to the Routing
B. Bidulock Version 0.5 Page 18
Internet Draft UA LOADGRP February 3, 2007
Context (Interface Id).
This is performed by extending the registration procedure of Load
Selection [LOADSEL] by adding the Load Distribution parameter to the
REG REQ message during registration. The Load Distribution parameter
is analogous to the Traffic Mode Type parameter.
In addition to the normal registration procedures of the UAs, the
following additional error conditions can occur:
"Error - Unsupported/Invalid Load Distribution"
This error MUST be sent in an Registration Response (REG RSP)
message whenever the SG determines that the Load Distribution
associated with 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 Selection in the REG
REQ message.
4.4. Interworking Procedures
5. Examples
Figure 3 illustrates the example configuration that is used for all
the examples in this section. The example configuration consist of:
+ Two SGs (SG1 and SG2) acting as STPs in the SS7 network and
consisting (for example) of a single SGP. Each SG is connected to
each of the ASPs in the example configuration.
+ Four ASPs (ASP1, ASP2, ASP3 and ASP4). Each ASP is connected to
both of the SGs in the example configuration.
+ Two Load Selectors (LS1 and LS2) are associated with the
Application Server. The traffic that corresponds to each Load
Selectors and the Load Distribution within each Load Selector is
different in each example.
B. Bidulock Version 0.5 Page 19
Internet Draft UA LOADGRP February 3, 2007
SCTP
Associations ________ _________
_________ ............| | / \
| |..: .......| ASP1 | | AS1 |
| |..... : |________| | |
________| SG1 |....: : | ......... |
/| |...:: : ________ | : : |
\ / |_________| :::..:......| | | : LS1 : |
\ / | :: :......| ASP2 | | :.......: |
\ / | :: :: |________| | |
X | :: :: | |
/ \ | :: :: ________ | |
/ \ ____|____ ::...::.....| | | |
/ \ | |..:....::.....| ASP3 | | ......... |
_______\| |..:.....:: |________| | : : |
| SG2 |..:......: | : LS2 : |
| |..:..... ________ | :.......: |
|_________| :....:......| | | |
:......| ASP4 | | |
|________| \_________/
Figure 3. Example Configuration
5.1.1. Initialization
Figure 4 illustrates the common initialization procedure use for all
of the examples. Each ASP establishes an SCTP Association with SG1
and sends and ASP Up message to which it receives and ASP Up response.
The ASPs are not statically configured to serve specific AS or LS
within the AS, so no Notify messages are received. The same sequence
of messages are also exchanged with SG2.
B. Bidulock Version 0.5 Page 20
Internet Draft UA LOADGRP February 3, 2007
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-Establish Association------>: : : : :
:<----:-ASPUP-----------------------: : : : :
:-----:-ASPUP ACK------------------>: : : : :
: : : : : : :
(2) :<----:-Establish Association-------:--->: : : :
:<----:-ASPUP-----------------------:----: : : :
:-----:-ASPUP ACK-------------------:--->: : : :
: : : : : : :
(3) :<----:-Establish Association-------:----:--->: : :
:<----:-ASPUP-----------------------:----:----: : :
:-----:-ASPUP ACK-------------------:----:--->: : :
: : : : : : :
(4) :<----:-Establish Association-------:----:----:--->: :
:<----:-ASPUP-----------------------:----:----:----: :
:-----:-ASPUP ACK-------------------:----:----:--->: :
: : : : : : :
(5) : : (Same message exchange for SG2) : : : :
: : : : : : :
Figure 4. Example - Initialization
5.2. M3UA with Override LG, Load-share AS, based on CIC
This example is for an M3UA [M3UA] configuration with the
Application Server (AS1) configured with a Traffic Mode Type of Load-
share. The Application Server (AS1) has associated with it a Routing
Key (RK1) that consists of a Destination Point Code that corresponds
to the AS1 (MGC1) point code (PC1), an Originating Point Code that
corresponds to a remote MGC2 point code (PC2), and the SI value for
ISUP (SI=5). The Load Selectors (LS1 and LS2) correspond to two sets
of CIC values which correspond to two different trunk groups between
MGC1 and MGC2 (TG1 and TG2).
B. Bidulock Version 0.5 Page 21
Internet Draft UA LOADGRP February 3, 2007
5.2.1. Activation
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-ASPAC(LS1/RC1)--------------: : : : :
:-----:-ASPAC ACK(LS1/RC1)--------->: : : : :
:-----:-NTFY(AS_Act)(LS1/RC1)------>: : : : :
: : : : : : :
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
: : : : : : :
(2) :<----:-ASPAC(LS2/RC1)--------------:----: : : :
:-----:-ASPAC ACK(LS2/RC1)----------:--->: : : :
:-----:-NTFY(AS_Act)(LS2/RC1)------>: : : : :
:-----:-NTFY(AS_Act)(LS2/RC1)-------:--->: : : :
: : : : : : :
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(3) :<----:-ASPAC(LS2/RC1)--------------:----:----: : :
:-----:-ASPAC ACK(LS2/RC1)----------:----:--->: : :
:-----:-NTFY(Alt ASP)(LS2/RC1/ASP3)-:--->: : : :
: : : : : : :
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS2)-------------------:----:--->:<---:------>:
: : : : : : :
(4) :<----:-ASPIA(LS2/RC1)--------------:----: : : :
:-----:-ASPIA ACK(LS2/RC1)----------:--->: : : :
: : : : : : :
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS2)-------------------:----:--->:<---:------>:
: : : : : : :
Figure 5. M3UA Example - Activation
Figure 5 illustrates activation of the ASPs for Load-share Load
Distribution within the Override Application Server. The sequence of
events is as follows:
(1) ASP1 sends an ASP Active message to SG1 identifying Load
Selector LS1 within Application Server AS1/RC1, optionally
including a Load Distribution indicating ""Load-share,"" and
receives an acknowledgement and a notification. Data is
transferred between the SG and ASP1 for Load Group LS1 within
AS1.
(2) ASP2 sends an ASP Active message to SG1 identifying Load
Selector LS2 within Application Server AS1/RC1 and receives an
acknowledgement and notification. ASP1 also receives
notification that LS2 is active for AS1/RC1. Data is
transferred between the SG and ASP2 for AS1/RC1 load-shared on
B. Bidulock Version 0.5 Page 22
Internet Draft UA LOADGRP February 3, 2007
CIC between LS1/ASP1 and LS2/ASP2.
(3) ASP3 sends an ASP Active message to SG1 identifying Load
Selector LS2 within Application Server AS1/RC1 and receives an
acknowledgement. Because LS2 is an Override Load Group, ASP2
gets a notification that ASP3 is now the active ASP for
LS2/AS1/RC1. Data is transfer to ASP3 for LS2 and remains
transferred to ASP1 for LS1.
(4) ASP2 sends an ASP Inactive message to SG1 identifying Load
Selector LS1 within Application Server AS1/RC1 and receives an
acknowledgement. Because ASP2 is not active in LS2, and LS2 is
an Override Load Group, SG1 continues to load-share between LS1
to ASP1 and LS2 to ASP3.
5.2.2. Failure of ASP1
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(2) :<- - :-COMM LOST - - - - -XXXX- - -: : : : :
:-----:-NTFY(ASP Fail)(ASP1)--------:--->: : : :
:-----:-NTFY(ASP Fail)(ASP1)--------:----:--->: : :
:-----:-NTFY(ASP Fail)(ASP1)--------:----:----:--->: :
:-----:-NTFY(AS_Pending)(LS1/RC1)---:--->: : : :
:-----:-NTFY(AS_Pending)(LS1/RC1)---:----:--->: : :
:-----:-NTFY(AS_Pending)(LS1/RC1)---:----:----:--->: :
: : : : : : :
(3) :<----:-ASPAC(LS1/RC1)--------------:----:----:----: :
:-----:-ASPAC ACK(LS1/RC1)----------:----:----:--->: :
:-----:-NTFY(AS_Active)(LS1/RC1)----:--->: : : :
:-----:-NTFY(AS_Active)(LS1/RC1)----:----:--->: : :
:-----:-NTFY(AS_Active)(LS1/RC1)----:----:----:--->: :
: : : : : : :
(4) :<----:-DATA(LS1)-------------------:----:----:--->:<----->:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
Figure 6. M3UA Example - Failure of ASP1
Figure 6 illustrates the failure of ASP1. The sequence of events is
as follows:
(1) Data for LS1 within AS1 is exchanged between SG1 and ASP1.
Data for LS2 within AS1 is exchanged between SG1 and ASP2.
(2) Communication is lost between SG1 and ASP1. ASP2, ASP3, and
ASP4 are notified of the failure of ASP1 and the change of
B. Bidulock Version 0.5 Page 23
Internet Draft UA LOADGRP February 3, 2007
state of AS1 to AS-PENDING for LS1. Data for LS2 in AS1 is
unaffected.
(3) ASP4 (spare) responds to the AS-PENDING notification and
activates for LS1 in AS1/RC1. ASP2, ASP3 and ASP4 receive an
AS-ACTIVE notification. Data for LS1 in AS1 is now exchanged
with ASP4. Data for LS2 in AS1 continues to be exchanged with
ASP2.
5.2.3. Sparing
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
: : : : : : :
(2) :<----:-ASPAC(LS1/RC1)--------------:----:----:----: :
:-----:-ASPAC ACK(LS1/RC1)----------:----:----:--->: :
:-----:-NTFY(Alt ASP)(ASP4)-------->: : : : :
: : : : : : :
(3) :<----:-DATA(LS1)-------------------:----:----:--->:<----->:
:<----:-DATA(LS1)-------------------:----:----:--->:<----->:
: : : : : : :
(4) :<----:-ASPDN-----------------------: : : : :
:-----:-ASPDN ACK------------------>: : : : :
: : : : : : :
Figure 7. M3UA Example - Sparing
Figure 7 illustrates a sparing situation where one ASP takes over
traffic from another so that the original ASP can be taken out of
service. The sequence of events is as follows:
(1) Data for LS1 in AS1 is exchange between SG1 and ASP1.
(2) ASP4 (spare) activates for LS1 in AS1 and receives an
acknowledgement. ASP4 has overridden ASP1 and a notification
is sent to ASP1 that indicates that ASP4 in now the "Alternate
ASP Active for AS".
(3) Data for LS1 in AS1 is now being exchanged between SG1 and
ASP4.
(4) ASP1 can now be taken down and out of service.
5.3. SUA with Load-share LG, Load-share AS based on GT
This example is for an SUA [SUA] configuration with the Application
Server (AS1) configured with a Traffic Mode Type of Load-share. The
Application Server (AS1) has associated with it (RK1) that consists of
B. Bidulock Version 0.5 Page 24
Internet Draft UA LOADGRP February 3, 2007
Destination Point Code and Subsystem Number that corresponds to the
AS1 (HLR1) point code (PC1). The Load Selectors (LS1 and LS2)
correspond to two sets of Global Titles which correspond to Mobile and
GSTN numbering.
5.3.1. Activation
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-ASPAC(LS1/RC1)--------------: : : : :
:-----:-ASPAC ACK(LS1/RC1)--------->: : : : :
:-----:-NTFY(AS_Act)(LS1/RC1)------>: : : : :
: : : : : : :
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
: : : : : : :
(2) :<----:-ASPAC(LS2/RC1)--------------:----: : : :
:-----:-ASPAC ACK(LS2/RC1)----------:--->: : : :
:-----:-NTFY(AS_Act)(LS2/RC1)------>: : : : :
:-----:-NTFY(AS_Act)(LS2/RC1)-------:--->: : : :
: : : : : : :
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(3) :<----:-ASPAC(LS1/RC1)--------------:----:----: : :
:-----:-ASPAC ACK(LS1/RC1)----------:----:--->: : :
: : : : : : :
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
: : : : : : :
(4) :<----:-ASPIA(LS1,LS2/RC1)----------:----:----:----: :
:-----:-ASPIA ACK(LS1,LS2/RC1)------:----:----:--->: :
: : : : : : :
(5) : : (Same message exchange for SG2) : : : :
: : : : : : :
Figure 8. SUA Example - Activation
Figure 8 illustrates activation of the ASPs for Load Selectors
within the Load-share Application Server. The sequence of events is
as follows:
(1) ASP1 sends an ASP Active message to SG1 identifying Load
Selector LS1 within Application Server AS1/RC1 and receives an
acknowledgement and a notification. Data is transferred
between the SG and ASP1 for Load Selector LS1 within AS1.
(2) ASP2 sends an ASP Active message to SG1 identifying Load
Selector LS2 within Application Server AS1/RC1 and receives an
acknowledgement and a notification. ASP1 also receives
notification that AS1/RC1 is active for LS2. Data is
transferred between the SG and ASP2 for Load Selector LS2
B. Bidulock Version 0.5 Page 25
Internet Draft UA LOADGRP February 3, 2007
within AS1.
(3) ASP3 sends an ASP Active message to SG1 identifying Load
Selector LS1 within Application Server AS1/RC1 and receives an
acknowledgement. Data is load-shared between the SG and ASP1
and ASP3 for Load Selector LS1 within AS1.
(4) ASP4 sends an ASP Inactive message to SG1 identifying Load
Selector LS1 and LS2 within Application Server AS1/RC1 and
receives an acknowledgement.
(5) The same exchange is repeated for SG2.
5.3.2. Failure of ASP1 and ASP2
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(2) :<- - :-COMM LOST - - - - -XXXX- - -: : : : :
:-----:-NTFY(ASP Fail)(ASP1)--------:--->: : : :
:-----:-NTFY(ASP Fail)(ASP1)--------:----:--->: : :
:-----:-NTFY(ASP Fail)(ASP1)--------:----:----:--->: :
: : : : : : :
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(3) :<- - :-COMM LOST - - - - -XXXX- - -: - -: : : :
:-----:-NTFY(ASP Fail)(ASP2)--------:----:--->: : :
:-----:-NTFY(ASP Fail)(ASP2)--------:----:----:--->: :
:-----:-NTFY(AS_Pending)(LS2/RC1)---:----:--->: : :
:-----:-NTFY(AS_Pending)(LS2/RC1)---:----:----:--->: :
: : : : : : :
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
: : : : : : :
(4) :<----:-ASPAC(LS2/RC1)--------------:----:----:----: :
:-----:-ASPAC ACK(LS2/RC1)----------:----:----:--->: :
:-----:-NTFY(AS_Active)(LS2/RC1)----:----:--->: : :
:-----:-NTFY(AS_Active)(LS2/RC1)----:----:----:--->: :
: : : : : : :
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
:<----:-DATA(LS2)-------------------:----:----:--->:<----->:
: : : : : : :
Figure 9. SUA Example - Failure of ASP1 and ASP2
Figure 9 illustrates the failure of ASP1 followed by the failure of
ASP2. The sequence of events is as follows:
B. Bidulock Version 0.5 Page 26
Internet Draft UA LOADGRP February 3, 2007
(1) Data for LS1 within AS1 is load-shared between ASP1 and ASP3.
Data for LS2 within AS1 is transferred to ASP2.
(2) Communication is lost between SG1 and ASP1. ASP2, ASP3, and
ASP4 are notified of the failure of ASP1. Data for LS1 in AS1
is now transferred to ASP3 only. Data for LS2 in AS1 is
unaffected and is still transferred to ASP2.
(3) Communication is lost between SG1 and ASP2. ASP3 and ASP4 are
notified of the failure of ASP2 as well of the AS1 state change
to AS-PENDING for LS2. Data for LS2 is queued at the SG.
(4) ASP4 (spare) responds to the AS-PENDING notification and
activates for LS2 in AS1/RC1. ASP3 and ASP4 receive an AS-
ACTIVE notification for LS2. Data for LS2 in AS1 is now
transferred to ASP4.
5.3.3. Sparing
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
: : : : : : :
(2) :<----:-ASPAC(LS1/RC1)--------------:----:----:----: :
:-----:-ASPAC ACK(LS1/RC1)----------:----:----:--->: :
: : : : : : :
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
:<----:-DATA(LS1)-------------------:----:----:--->:<----->:
: : : : : : :
(3) :<----:-ASPIA(LS1/RC1)--------------: : : : :
:-----:-ASPIA ACK(LS1/RC1)--------->: : : : :
: : : : : : :
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
:<----:-DATA(LS1)-------------------:----:----:--->:<----->:
: : : : : : :
(5) :<----:-ASPDN-----------------------: : : : :
:-----:-ASPDN ACK------------------>: : : : :
: : : : : : :
Figure 10. SUA Example - Sparing
Figure 10 illustrates a sparing situation where one ASP takes over
traffic from another so that the original ASP can be taken out of
service. The sequence of events is as follows:
(1) Data for LS1 in AS1 is load-shared by SG1 between ASP1 and
ASP3.
B. Bidulock Version 0.5 Page 27
Internet Draft UA LOADGRP February 3, 2007
(2) ASP4 (spare) activates for LS1 in AS1 and receives and
acknowledgement. Data for LS1 in AS1 is now load-shared by SG1
between ASP1, ASP3 and ASP4.
(3) ASP1 deactivates for LS1 in AS1 and receives and
acknowledgement.
(4) Data for LS1 in AS1 is now load-shared by SG1 between ASP3 and
ASP4.
(5) ASP1 can now be taken down and out of service.
5.4. TUA with Broadcast LG, Load-share AS based on DID
This example is for an TUA [TUA] configuration with the Application
Server (AS1) configured with a Traffic Mode Type of Broadcast. The
Application Server (AS1) has associated with it (RK1) that consists of
Destination Point Code and Subsystem Number that corresponds to the
AS1 (HLR1) point code (PC1). The Load Selectors (LS1 and LS2)
correspond to two sets of Dialogue Ids which correspond to even and
odd Dialogue Ids.
5.4.1. Activation
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-ASPAC(LS1/RC1)--------------: : : : :
:-----:-ASPAC ACK(LS1/RC1)--------->: : : : :
:-----:-NTFY(AS_Act)(LS1/RC1)------>: : : : :
: : : : : : :
:<----:-DATA(LS1)(CorrId)---------->:<---:----:----:------>:
:<----:-DATA(LS1)------------------>:<---:----:----:------>:
: : : : : : :
(2) :<----:-ASPAC(LS2/RC1)--------------:----: : : :
:-----:-ASPAC ACK(LS2/RC1)----------:--->: : : :
:-----:-NTFY(AS_Act)(LS2/RC1)------>: : : : :
:-----:-NTFY(AS_Act)(LS2/RC1)-------:--->: : : :
: : : : : : :
:<----:-DATA(LS2)(CorrId)-----------:--->:<---:----:------>:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(3) :<----:-ASPAC(LS1/RC1)--------------:----:----: : :
:-----:-ASPAC ACK(LS1/RC1)----------:----:--->: : :
:-----:-NTFY(AS_Act)(LS1,LS2/RC1)---:----:--->: : :
: : : : : : :
:<----:-DATA(LS1)(CorrId)---------->:<---:--->:<---:------>:
:<----:-DATA(LS1)------------------>:<---:--->:<---:------>:
: : : : : : :
(4) :<----:-ASPIA(LS2/RC1)--------------:----:----:----: :
:-----:-ASPIA ACK(LS2/RC1)----------:----:----:--->: :
: : : : : : :
(5) : : (Same message exchange for SG2) : : : :
B. Bidulock Version 0.5 Page 28
Internet Draft UA LOADGRP February 3, 2007
: : : : : : :
Figure 11. TUA Example - Activation
Figure 11 illustrates activation of the ASPs for Load Selectors
within the Broadcast Application Server. The sequence of events is as
follows:
(1) ASP1 sends an ASP Active message to SG1 identifying Load
Selector LS1 within Application Server AS1/RC1 and receives an
acknowledgement and a notification. Data is transferred
between the SG and ASP1 for Load Selector LS1 within AS1. The
initial Data Messages for LS1 within AS1 are tagged with a
Correlation Id.
(2) ASP2 sends an ASP Active message to SG1 identifying Load
Selector LS2 within Application Server AS1/RC1 and receives an
acknowledgement and a notification. ASP1 also receives
notification that AS1/RC1 is active for LS2. Data is
transferred between the SG and ASP2 for Load Selector LS2
within AS1. The initial Data Messages for LS2 within AS1 are
tagged with a Correlation Id.
(3) ASP3 sends an ASP Active message to SG1 identifying Load
Selector LS1 within Application Server AS1/RC1 and receives an
acknowledgement. Data is broadcast the SG and ASP1 and ASP3
for Load Selector LS1 within AS1. The initial Data Messages
for LS2 within AS1 are tagged with a Correlation Id.
(4) ASP4 sends an ASP Inactive message to SG1 identifying Load
Selector LS1 and LS2 within Application Server AS1/RC1 and
receives an acknowledgement.
(5) The same exchange is repeated for SG2.
B. Bidulock Version 0.5 Page 29
Internet Draft UA LOADGRP February 3, 2007
5.4.2. Failure of ASP1 and ASP2
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-DATA(LS1)------------------>:<---:--->:<---:------>:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(2) :<- - :-COMM LOST - - - - -XXXX- - -: : : : :
:-----:-NTFY(ASP Fail)(ASP1)--------:--->: : : :
:-----:-NTFY(ASP Fail)(ASP1)--------:----:--->: : :
:-----:-NTFY(ASP Fail)(ASP1)--------:----:----:--->: :
: : : : : : :
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
:<----:-DATA(LS2)-------------------:--->:<---:----:------>:
: : : : : : :
(3) :<- - :-COMM LOST - - - - -XXXX- - -: - -: : : :
:-----:-NTFY(ASP Fail)(ASP2)--------:----:--->: : :
:-----:-NTFY(ASP Fail)(ASP2)--------:----:----:--->: :
:-----:-NTFY(AS_Pending)(LS2/RC1)---:----:--->: : :
:-----:-NTFY(AS_Pending)(LS2/RC1)---:----:----:--->: :
: : : : : : :
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
: : : : : : :
(4) :<----:-ASPAC(LS2/RC1)--------------:----:----:----: :
:-----:-ASPAC ACK(LS2/RC1)----------:----:----:--->: :
:-----:-NTFY(AS_Active)(LS2/RC1)----:----:--->: : :
:-----:-NTFY(AS_Active)(LS2/RC1)----:----:----:--->: :
: : : : : : :
:<----:-DATA(LS2)(CorrId)-----------:----:----:--->:<----->:
:<----:-DATA(LS2)-------------------:----:----:--->:<----->:
:<----:-DATA(LS1)-------------------:----:--->:<---:------>:
: : : : : : :
(5) :<----:-ASPDN-----------------------: : : : :
:-----:-ASPDN ACK------------------>: : : : :
: : : : : : :
Figure 12. TUA Example - Failure of ASP1
Figure 12 illustrates the failure of ASP1 followed by the failure of
ASP2. The sequence of events is as follows:
(1) Data for LS1 within AS1 is broadcast to ASP1 and ASP3. Data
for LS2 within AS1 is sent to ASP2.
(2) Communication is lost between SG1 and ASP1. ASP2, ASP3, and
ASP4 are notified of the failure of ASP1. Data for LS1 in AS1
is directed toward ASP3 only. Data for LS2 in AS1 is
unaffected.
B. Bidulock Version 0.5 Page 30
Internet Draft UA LOADGRP February 3, 2007
(3) Communication is lost between SG1 and ASP2. ASP3 and ASP4 are
notified of the failure of ASP1 as well of the AS1 state change
to AS-PENDING for LS2. Data for LS2 is queued at the SG.
(4) ASP4 (spare) responds to the AS-PENDING notification and
activates for LS2 in AS1/RC1. ASP3 and ASP4 receive an AS-
ACTIVE notification. Data for LS2 in AS1 is now exchanged with
ASP4. Initial DATA messages for LS2 in AS1 are tagged with a
Correlation Id.
5.4.3. Sparing
SG1 SG2 ASP1 ASP2 ASP3 ASP4 AS1
: : : : : : :
(1) :<----:-DATA(LS1)------------------>:<---:--->:<---:------>:
: : : : : : :
(2) :<----:-ASPAC(LS1/RC1)--------------:----:----:----: :
:-----:-ASPAC ACK(LS1/RC1)----------:----:----:--->: :
: : : : : : :
:<----:-DATA(LS1)(CorrId)-----------:----:----:--->:<----->:
:<----:-DATA(LS1)------------------>:<---:--->:<-->:<----->:
: : : : : : :
(3) :<----:-ASPIA(LS1/RC1)--------------: : : : :
:-----:-ASPIA ACK(LS1/RC1)--------->: : : : :
: : : : : : :
(4) :<----:-DATA(LS1)-------------------:----:--->:<-->:<----->:
: : : : : : :
(5) :<----:-ASPDN-----------------------: : : : :
:-----:-ASPDN ACK------------------>: : : : :
: : : : : : :
Figure 13. TUA Example - Sparing
Figure 13 illustrates a sparing situation where one ASP takes over
traffic from another so that the original ASP can be taken out of
service. The sequence of events is as follows:
(1) Data for LS1 in AS1 is broadcast from SG1 to ASP1 and ASP3.
(2) ASP4 (spare) activates for LS1 in AS1 and receives and
acknowledgement. Data for LS1 in AS1 is now being broadcast
from SG1 to ASP1, ASP3 and ASP4. Initial data for LS1 in AS1
is tagged with a Correlation Id.
(3) ASP1 deactivates for LS1 in AS1 and receives and
acknowledgement.
(4) Data for LS1 in AS1 is now broadcast from SG1 to ASP3 and ASP4.
B. Bidulock Version 0.5 Page 31
Internet Draft UA LOADGRP February 3, 2007
(5) ASP1 can now be taken down and out of service.
6. Security
LOADGRP does not introduce any new security risks or considerations
that are not already inherent in the UA [IUA], [M2UA], [M3UA], [SUA],
[DUA], [V5UA], [GR303UA], [ISUA], [TUA] Please see SIGTRAN Security
document [SIGSEC] for security considerations and recommendations that
are applicable to each UA.
7. IANA Considerations
LOADGRP adds the following parameter tag value (described in Section
3) to the Common Parameter numbering space for the UAs [IUA], [M2UA],
[M3UA], [SUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA].
Tag Value Parameter Name
----------------------------------
0x001a Load Distribution <1>
LOADGRP adds the following value to the Error Code parameter of the
UAs.
28 Unsupported Load Distribution <2>
LOADGRP adds the following value to the Registration Status field of
the Registration Result parameter for the UAs [M2UA], [M3UA], [SUA],
[ISUA], [TUA].
16 Error - Invalid/Unsupported Load Distribution <3>
Notes for Section 7
<1> EDITOR'S NOTE:- The Load Distribution parameter tag value
shown throughout this document as 0x001a 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.
<2> EDITOR'S NOTE:- The Error Code value shown as 28 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.
<3> EDITOR'S NOTE:- The Registration Status value shown as 16
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.
B. Bidulock Version 0.5 Page 32
Internet Draft UA LOADGRP February 3, 2007
0. Revision 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.5. Changes from Version 0.4 to Version 0.5
+ updated to new boilerplate.
+ updated references, version numbers and dates.
0.4. Changes from Version 0.3 to Version 0.4
+ updated to IETF boilerplate for first and last page.
+ updated references, version numbers and dates.
+ resubmitted to sync with IETF numbering
0.3. Changes from Version 0.2 to Version 0.3
+ updated references, version numbers and dates.
0.2. Changes from Version 0.1 to Version 0.2
+ added list of abbreviations.
+ moved history section.
+ updated release version and dates.
+ updated references.
+ split reference section.
+ updated security section.
+ moved notes to end of document.
0.1. Changes from Version 0.0 to Version 0.1
+ added this section,
+ updated release version and dates,
+ updated references,
+ updated postscript diagrams,
+ minor formatting changes,
+ reworked the procedures section,
+ added interworking rules,
+ change Load Selection to Load Selector to match LOADSEL [LOADSEL],
+ added examples,
+ updated author's address.
0.0. Version 0.0
The initial version of this document.
0.0.0. Change Log
$Log: draft-bidulock-sigtran-loadgrp-05.me,v $
Revision 0.9.2.1 2007/02/03 15:47:25 brian
B. Bidulock Version 0.5 Page 33
Internet Draft UA LOADGRP February 3, 2007
- added new drafts
Revision 0.9.2.5 2006/06/27 09:41:15 brian
- rereleased drafts
Revision 0.9.2.4 2006/06/18 20:53:35 brian
- preparing for draft rerelease
Revision 0.9.2.3 2005/10/17 11:53:46 brian
- updated drafts for republication
Revision 0.9.2.2 2005/05/14 08:33:19 brian
- copyright header correction
Revision 0.9.2.1 2004/03/16 05:10:41 brian
- Added drafts and figures.
Revision 0.8.2.2 2003/08/01 12:23:15 brian
Added abbreviations, updated format.
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14/RFC 2119, The Internet Society (March
1997). <http://www.ietf.org/rfc/rfc2119.txt>
[IUA] Morneault, K., Rengasami, S., Kalla, M. and Sidebottom, G.,
"Integrated Services Digital Network (ISDN) Q.921-User Adaptation
Layer," RFC 4233, The Internet Society (January 2006).
(Obsoletes RFC 3057) <http://www.ietf.org/rfc/rfc4233.txt>
[M2UA] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and
Heitz, J., "Signaling System 7 (SS7) Message Transfer Part 2
(MTP2) -- User Adaptation Layer," RFC 3331, The Internet Society
(September 2002). <http://www.ietf.org/rfc/rfc3331.txt>
[M3UA] Morneault, K., Pastor-Balbas, J., (eds), "Signaling System 7
(SS7) Message Transfer Part 3 (MTP3) -- User Adaptation Layer
(M3UA)," RFC 4666, The Internet Society (September 2006).
<http://www.ietf.org/rfc/rfc4666.txt>
[SUA] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller,
J. and Bidulock, B., "Signalling Connection Control Part User
Adaptation Layer (SUA)," RFC 3868, The Internet Society (October
2004). <http://www.ietf.org/rfc/rfc3868.txt>
[SCTP] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, H., Zhang, L.
and Paxson, V., "Stream Control Transmission Protocol (SCTP),"
RFC 2960, The Internet Society (October 2000). (Updated by RFC
B. Bidulock Version 0.5 Page 34
Internet Draft UA LOADGRP February 3, 2007
3309) (Status: PROPOSED STANDARD)
<http://www.ietf.org/rfc/rfc2960.txt>
[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). <http://www.ietf.org/rfc/rfc3788.txt>
Informative References
[DUA] Mukundan, R., Morneault, K., Mangalpally, N. and Vydyam, A.,
"Digital Private Network Signaling System (DPNSS)/Digital Access
Signaling System 2 (DASS 2) Extensions to the IUA Protocol," RFC
4129, The Internet Society (August 2005). (Status: PROPOSED
STANDARD) <http://www.ietf.org/rfc/rfc4129.txt>
[V5UA] Weilandt, E., Khanchandani, N. and Rao, S., "V5.2-User
Adaption Layer (V5UA)," RFC 3807, The Internet Society (June
2004). (Updates RFC 3057) <http://www.ietf.org/rfc/rfc3807.txt>
[GR303UA] Mukundan, R., Morneault, K., "GR-303 extensions to the IUA
Protocol," draft-ietf-sigtran-gr303ua-00.txt, Internet
Engineering Task Force -- Signalling Transport Working Group
(December 2002). Work In Progress. (Expired)
<http://www.ietf.org/internet-drafts/draft-ietf-sigtran-
gr303ua-00.txt>
[ISUA] Bidulock, B., "SS7 ISUP-User Adaptation Layer (ISUA)," draft-
bidulock-sigtran-isua-04.txt, Internet Engineering Task Force --
Signalling Transport Working Group (February 3, 2007). Work In
Progress. <http://www.ietf.org/internet-drafts/draft-bidulock-
sigtran-isua-04.txt>
[TUA] Bidulock, B., "SS7 TCAP-User Adaptation Layer (TUA)," draft-
bidulock-sigtran-tua-05.txt, Internet Engineering Task Force --
Signalling Transport Working Group (February 3, 2007). Work In
Progress. <http://www.ietf.org/internet-drafts/draft-bidulock-
sigtran-tua-05.txt>
[LOADSEL] Bidulock, B., "Load Selection Extension for Signalling User
Adaptation Layers (LOADSEL)," draft-bidulock-sigtran-
loadsel-05.txt, Internet Engineering Task Force -- Signalling
Transport Working Group (February 3, 2007). Work In Progress.
<http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-
loadsel-05.txt>
B. Bidulock Version 0.5 Page 35
Internet Draft UA LOADGRP February 3, 2007
Acknowledgements
The authors would like to thank Tolga Asveren, Ken Morneault, Barry
Nagelberg, Benjamin J. Wilson, Jacques Rajchgod, Greg Sidebottom and
Gery Verwimp 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 August 2007.
B. Bidulock Version 0.5 Page 36
Internet Draft UA LOADGRP February 3, 2007
List of Tables
Table 1. Sample Configurations .................................. 8
List of Illustrations
Figure 1. Existing Traffic Distribution ......................... 4
Figure 2. Load Group Traffic Distribution ....................... 6
Figure 3. Example Configuration ................................. 20
Figure 4. Example - Initialization .............................. 21
Figure 5. M3UA Example - Activation ............................. 22
Figure 6. M3UA Example - Failure of ASP1 ........................ 23
Figure 7. M3UA Example - Sparing ................................ 24
Figure 8. SUA Example - Activation .............................. 25
Figure 9. SUA Example - Failure of ASP1 and ASP2 ................ 26
Figure 10. SUA Example - Sparing ................................ 27
Figure 11. TUA Example - Activation ............................. 29
Figure 12. TUA Example - Failure of ASP1 ........................ 30
Figure 13. TUA Example - Sparing ................................ 31
Table of Contents
Status of this Memo ............................................. 1
Copyright ....................................................... 1
Abstract ........................................................ 1
Contents ........................................................ 2
1 Introduction .................................................. 2
1.1 Scope ....................................................... 2
1.2 Abbreviations ............................................... 2
1.3 Terminology ................................................. 3
1.4 Overview .................................................... 3
1.4.1 Existing Traffic Distribution ............................. 4
1.4.2 Extended Traffic Distribution ............................. 5
1.5 Sample Configurations ....................................... 7
2 Conventions ................................................... 8
3 Protocol Elements ............................................. 8
3.1 Parameters .................................................. 8
3.1.1 Load Distribution ......................................... 8
3.2 Messages .................................................... 9
3.2.1 Registration Request (REG REQ) ............................ 9
3.2.2 Registration Response (REG RSP) ........................... 10
3.2.3 ASP Active (ASPAC) ........................................ 11
3.2.4 ASP Active Ack (ASPAC ACK) ................................ 12
3.2.5 Error (ERR) ............................................... 13
Notes for Section 3 ............................................. 14
4 Procedures .................................................... 14
4.1 ASP State Maintenance ....................................... 14
4.1.1 Load Group State .......................................... 14
4.1.2 Application Server State .................................. 15
4.2 ASP Traffic Maintenance ..................................... 15
4.2.1 ASP Up Procedures ......................................... 15
4.2.2 ASP Down Procedures ....................................... 15
B. Bidulock Version 0.5 Page 37
Internet Draft UA LOADGRP February 3, 2007
4.2.3 ASP Active Procedures ..................................... 15
4.2.4 ASP Inactive Procedures ................................... 17
4.2.5 Notify Procedures ......................................... 17
4.3 Registration ................................................ 18
4.4 Interworking Procedures ..................................... 19
5 Examples ...................................................... 19
5.1.1 Initialization ............................................ 20
5.2 M3UA with Override LG, Load-share AS, based on CIC .......... 21
5.2.1 Activation ................................................ 22
5.2.2 Failure of ASP1 ........................................... 23
5.2.3 Sparing ................................................... 24
5.3 SUA with Load-share LG, Load-share AS based on GT ........... 24
5.3.1 Activation ................................................ 25
5.3.2 Failure of ASP1 and ASP2 .................................. 26
5.3.3 Sparing ................................................... 27
5.4 TUA with Broadcast LG, Load-share AS based on DID ........... 28
5.4.1 Activation ................................................ 28
5.4.2 Failure of ASP1 and ASP2 .................................. 30
5.4.3 Sparing ................................................... 31
6 Security ...................................................... 32
7 IANA Considerations ........................................... 32
Notes for Section 7 ............................................. 32
0 Revision History .............................................. 33
0.5 Changes from Version 0.4 to Version 0.5 ..................... 33
0.4 Changes from Version 0.3 to Version 0.4 ..................... 33
0.3 Changes from Version 0.2 to Version 0.3 ..................... 33
0.2 Changes from Version 0.1 to Version 0.2 ..................... 33
0.1 Changes from Version 0.0 to Version 0.1 ..................... 33
0.0 Version 0.0 ................................................. 33
0.0.0 Change Log ................................................ 33
Normative References ............................................ 34
Informative References .......................................... 35
Acknowledgements ................................................ 36
Author's Addresses .............................................. 36
List of Tables .................................................. 37
List of Illustrations ........................................... 37
Table of Contents ............................................... 37
B. Bidulock Version 0.5 Page 38
Internet Draft UA LOADGRP February 3, 2007
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
[email protected].
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
B. Bidulock Version 0.5 Page 39
| ||||||||||||||||||
| Last modified: Wed, 27 Nov 2024 17:10:20 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||||