Network Working Group Javier Pastor
INTERNET-DRAFT Ericsson
Expires: November 2002
HannsJuergen Schwarzbauer
Siemens
May, 2002
IPSP Commmunication Description for M3UA
<draft-pastor-sigtran-m3ua-ipspcomm-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document is a compilation of all the IPSP literature presented
in the M3UA (MTP-3 User Adaptation Layer) RFC. It contains a
description of IPSP commmunication showing the main concepts and
procedures.
Pastor, Schwarzbauer [Page 1]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
TABLE OF CONTENTS
1. Introduction.......................................................3
1.1 IPSP Definition....................................................3
1.2 Protocol Architecture..............................................3
1.3 Services Provided by the M3UA Layer................................4
1.4 Functional Areas...................................................5
1.5 Sample Configuration: SCCP Transport between IPSPs.................9
1.6 Definition of M3UA Boundaries......................................9
2. Conventions.......................................................10
3. M3UA Protocol Elements............................................10
4. Procedures.........................................................10
4.1 Procedures to Support the M3UA-User...............................10
4.2 Procedures to Support the Management of SCTP Associations.........12
4.3 AS and IPSP State Maintenance.....................................13
4.4 Routing Key Management Procedures [Optional]......................26
5. Examples of M3UA Procedures for IPSP...............................28
5.1 Establishment of Association and Traffic between IPSPs............29
5.2 IPSP Traffic Failover Examples....................................34
5.3 Normal Withdrawal of an IPSP from an Application Server and
Teardown of an Association........................................35
5.4 M3UA/MTP3-User Boundary Examples for an IPSP.....................36
5.5 Complete examples for IPSP communication..........................37
6. Acknowledgements..................................................38
7. Authors' Addresses................................................38
8. References........................................................39
9. Open Issues........................................................39
Annex A: Example or RK use within IPSP communication..................39
Pastor, Schwarzbauer [Page 2]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
1. Introduction
This draft is a compilation of all the IPSP literature presented in
the M3UA RFC. Due to time shortages there were some cases where this
specifications were mixed up with the SGP and ASP explanations and
were hard to be extracted.
No new features have been added, but just a copy/paste of the
messages, procedures and examples texts extracted from the original
document in order to assist in the IPSP concept understanding.
The text is therefore almost the same as the one included in [M3UA-
RFC]. Only light modifications have been done only when the
understanding was difficult when including the "IPSP" word.
Some general sections have also been included to make the document
more consistent.
This draft also intends to assist in finding the holes that this
approach may include. This should help to complete the M3UAÆs
implementorÆs guide and IPSP communication.
The structure of this document is as follows:
@ Extract of IPSP concepts from the Introduction section in [M3UA-
RFC].
@ Extract of Procedures from [M3UA-RFC].
@ Examples from [M3UA-RFC] addapted to the IPSP communication.
@ Open Issues to solve.
@ An Annex with an example of RK management.
1.1 IPSP Definition
IP Server Process (IPSP) - A process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except that
it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does
not use the services of a Signalling Gateway node.
A key point to understand the IPSP concept is said in [M3UA-RFC]
section 4.3, when describing the procedures and is the following:
"[...] only the SGP/ASP case is described but the SGP side of the
procedures also apply to an IPSP sending traffic to an AS consisting
of a set of remote IPSPs."
1.2 Protocol Architecture.
The framework architecture that has been defined for SCN signalling
transport over IP uses multiple components, including a common
Pastor, Schwarzbauer [Page 3]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
signalling transport protocol and an adaptation module to support the
services expected by a particular SCN signalling protocol from its
underlying protocol layer.
Within the framework architecture, this document defines an MTP3-User
adaptation module suitable for supporting the transfer of messages of
any protocol layer that is identified to the MTP Level 3 as an MTP
User. The list of these protocol layers includes, but is not limited
to, ISDN User Part (ISUP), Signalling Connection Control Part
(SCCP), and Telephone User Part (TUP). TCAP or RANAP messages are
transferred transparently by the M3UA protocol as SCCP payload, as
they are SCCP-User protocols.
It is recommended that M3UA use the services of the Stream Control
Transmission Protocol (SCTP) as the underlying reliable common
signalling transport protocol. This is to take advantage of various
SCTP features such as:
- Explicit packet-oriented delivery (not stream-oriented),
- Sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual
user messages,
- Optional multiplexing of user messages into SCTP datagrams,
- Network-level fault tolerance through support of multi-homing
at either or both ends of an association,
- Resistance to flooding and masquerade attacks, and
- Data segmentation to conform to discovered path MTU size.
Under certain scenarios, such as back-to-back connections without
redundancy requirements, the SCTP functions above might not be a
requirement and TCP MAY be used as the underlying common transport
protocol.
1.3 Services Provided by the M3UA Layer
The M3UA Layer at an IPSP provides the equivalent set of primitives
at its upper layer to the MTP3-Users as provided by the MTP Level 3
to its local MTP3-Users at an SS7 SEP.
In IPSP communication the M3UA layer is used for point-to-point
signalling between two IP Server Processes (IPSPs). In this case,the
M3UA layer provides the same set of primitives and services at its
Upper layer as the MTP3.
The expected MTP3 services are not offered remotely from an SGP. The
MTP3 services are provided but the procedures to support these
services are a subset of the MTP3 procedures due to the simplified
point-to-point nature of the IPSP to IPSP relationship.
1.3.1 Support for the Transport of MTP3-User Messages
Pastor, Schwarzbauer [Page 4]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
The M3UA layer provides the transport of MTP-TRANSFER primitives
across an established SCTP association between IPSPs.
The M3UA layer does not impose a 272-octet signalling information
field (SIF) length limit as specified by the SS7 MTP Level 2 protocol
[7,8,9]. Larger information blocks can be accommodated directly by
M3UA/SCTP, without the need for an upper layer segmentation /
reassembly procedure as specified in recent SCCP or ISUP versions.
1.3.2 Native Management Functions
The M3UA layer provides the capability to indicate errors associated
with received M3UA messages and to notify, as appropriate, local
management and/or the peer M3UA.
1.3.3 Support for the Management of SCTP Associations between IPSPs.
The M3UA layer at the IPSP maintains the availability state of all
configured remote IPSPs, to manage the SCTP Associations and the
traffic between the M3UA peers. As well, the active/inactive and
congestion state of remote IPSPs is maintained.
The M3UA layer MAY be instructed by local management to establish an
SCTP association to a peer M3UA node. This can be achieved using the
M-SCTP_ESTABLISH primitives (See Section 1.6.3 in [M3UA-RFC] for a
description of management primitives) to request, indicate and
confirm the establishment of an SCTP association with a peer M3UA
node. In order to avoid redundant SCTP associations between two M3UA
peers, one side (client) SHOULD be designated to establish the SCTP
association, or
M3UA configuration information maintained to detect redundant
associations (e.g., via knowledge of the expected local and remote
SCTP endpoint addresses).
Local management MAY request from the M3UA layer the status of the
underlying SCTP associations using the M-SCTP_STATUS request and
confirm primitives. Also, the M3UA MAY autonomously inform local
management of the reason for the release of an SCTP association,
determined either locally within the M3UA layer or by a primitive
from the SCTP.
Also the M3UA layer MAY inform the local management of the change in
status of an IPSP or AS. This MAY be achieved using the M-ASP_STATUS
request or M-AS_STATUS request primitives.
1.4 Functional Areas
1.4.1 Routing Contexts and Routing Keys
1.4.1.1 Overview
Pastor, Schwarzbauer [Page 5]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
The distribution of SS7 messages between an IPSP within an
Application Server and another IPSP within a remote Application
Server is determined by the Routing Keys and their associated Routing
Contexts. A Routing Key is essentially a set of SS7 parameters used
to filter SS7 messages, whereas the Routing Context parameter is a 4-
byte value (integer) that is associated to that Routing Key in a 1:1
relationship. The Routing Context therefore can be viewed as an index
into a sending node's Message Distribution Table containing the
Routing Key entries.
Possible SS7 address/routing information that comprise a Routing Key
entry includes, for example, the OPC, DPC, SIO found in the MTP3
routing label, or MTP3-User specific fields (such as the ISUP CIC,
SCCP subsystem number). Some example Routing Keys are: the DPC
alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
DPC/SSN combination. The particular information used to define an
M3UA Routing Key is application and network dependent, and none of
the above examples are mandated.
An IPSP may be configured to process signalling traffic related to
more than one Application Server, over a single SCTP Association. In
ASP Active and ASP Inactive management messages, the signalling
traffic to be started or stopped is discriminated by the Routing
Context parameter. At an IPSP, the received Routing Context
parameter uniquely identifies the range of signalling traffic
associated with each Application Server that the IPSP is configured
to receive.
1.4.1.2 Routing Key Limitations
Routing Keys SHOULD be unique in the sense that each received SS7
signalling message SHOULD have a full or partial match to a single
routing result. It is not necessary for the parameter range values
within a particular Routing Key to be contiguous. For example, an AS
could be configured to support call processing for multiple ranges of
PSTN trunks that are not represented by contiguous CIC values.
1.4.1.3 Managing Routing Contexts and Routing Keys
There are two ways to provision a Routing Key at an IPSP. A Routing
Key may be configured statically using an implementation dependent
management interface, or dynamically using the M3UA Routing Key
registration procedure.
When using a management interface to configure Routing Keys, the
message distribution function within an IPSP is not limited to the
set of parameters defined in this document. Other implementation
dependent distribution algorithms may be used.
Pastor, Schwarzbauer [Page 6]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
1.4.1.4 Message Distribution at the IPSP
To direct messages received from the MTP3-User to the appropriate IP
destination, an IPSP must perform a message distribution function
using information from the received MTP3-User message.
To support this message distribution, the IPSP might, for example,
maintain the equivalent of a network address translation table,
mapping incoming SS7 message information to an Application Server for
a particular application and range of traffic. This could be
accomplished by comparing elements of the incoming SS7 message to
currently defined Routing Keys in the IPSP.
These Routing Keys could in turn map directly to an Application
Server that is enabled by one or more remote IPSPs. These remote
IPSPs provide dynamic status information regarding their
availability, traffic handling capability and congestion to the IPSP
using various management messages defined in the M3UA protocol.
The list of IPSPs in an AS is assumed to be dynamic, taking into
account the availability, traffic handling capability and congestion
status of the individual IPSPs in the list, as well as configuration
changes and possible failover mechanisms.
Normally, one or more IPSPs are active (i.e., currently processing
traffic) in the AS but in certain failure and transition cases it is
possible that there may be no active IPSP available. Broadcast,
loadsharing and backup scenarios are supported.
When there is no matching Routing Key entry for an incoming SS7
message from the local MTP3-User to M3UA, a default treatment MAY be
specified. Possible solutions are to provide a default Application
Server at the IPSP that directs all unallocated traffic to a (set of)
default remote IPSP(s), or to drop the message and provide a
notification to layer management. The treatment of unallocated
traffic is implementation dependent.
1.4.2 SS7 and M3UA Interworking
Since IPSPs use M3UA in a point-to-point fashion, there is no concept
of routing of messages beyond the remote end. Therefore, SS7 and
M3UA interworking is not necessary for this model.
1.4.3 Redundancy Models
1.4.3.1 Application Server Redundancy
All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned
Routing Key at an IPSP are mapped to an Application Server.
Pastor, Schwarzbauer [Page 7]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
The Application Server is the set of all IPSPs associated with a
specific Routing Key. Each IPSP in this set may be active, inactive
or unavailable. Active IPSPs handle traffic; inactive IPSPs might be
used when active IPSPs become unavailable.
The failover model supports an "n+k" redundancy model, where "n"
IPSPs is the minimum number of redundant IPSPs required to handle
traffic and "k" IPSPs are available to take over for a failed or
unavailable IPSP.
A "1+1" active/backup redundancy is a subset of this model. A simplex
"1+0" model is also supported as a subset, with no IPSP redundancy.
1.4.4 Flow Control
Local Management at an IPSP may wish to stop traffic across an SCTP
association to temporarily remove the association from service or to
perform testing and maintenance activity. The function could
optionally be used to control the start of traffic on to a newly
available SCTP association.
1.4.5 Congestion Management
The M3UA layer is informed of local and IP network congestion by
means of an implementation-dependent function (e.g., an
implementation-dependent indication from the SCTP of IP network
congestion).
At an IPSP, the M3UA layer indicates congestion to local MTP3-Users
by means of an MTP-STATUS primitive, as per current MTP3 procedures,
to invoke appropriate upper layer responses.
The M3UA layer at an IPSP MAY indicate local congestion to an
M3UA peer with an SCON message.
1.4.6 SCTP Stream Mapping.
The M3UA layer at IPSPs also supports the assignment of signalling
traffic into streams within an SCTP association. Traffic that
requires sequencing SHOULD be assigned to the same stream. To
accomplish this, MTP3-User traffic may be assigned to individual
streams based on, for example, the SLS value in the MTP3 Routing
Label or the ISUP CIC assignment, subject of course to the maximum
number of streams supported by the underlying SCTP association.
1.4.7 Client/Server Model
In the case of IPSP to IPSP communication, the peer endpoints using
Pastor, Schwarzbauer [Page 8]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
M3UA SHOULD be configured so that one always takes on the role of
client and the other the role of server for initiating SCTP
associations.
The SCTP and TCP Registered User Port Number Assignment for M3UA is
2905.
1.5 Sample Configuration: SCCP Transport between IPSPs
Figure 1
******** IP ********
* IPSP *----------* IPSP *
******** ********
+------+ +------+
|SCCP- | |SCCP- |
| User | | User |
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| M3UA | | M3UA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
|________________|
----------------
This example shows an architecture where no Signalling Gateway is
used.
In this example, SCCP messages are exchanged directly between two IP-
resident IPSPs with resident SCCP-User protocol instances, such as
RANAP or TCAP. SS7 network interworking is not required, therefore
there is no MTP3 network management status information for the SCCP
and SCCP-User protocols to consider. Any MTP-PAUSE, MTP-RESUME or
MTP-STATUS indications from the M3UA layer to the SCCP layer should
consider the status of the SCTP Association and underlying IP network
and any congestion information received from the remote site.
1.6 Definition of M3UA Boundaries
As defined in [RFC-M3UA].
Pastor, Schwarzbauer [Page 9]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
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
[RFC2119].
3. M3UA Protocol Elements
All the messages from [RFC-M3UA] MAY/SHOULD/MUST? be used with IPSP
communication except DUNA, DAVA, DAUD and DRST.
The description of the M3UA messages and parameters can be found on
[RFC-M3UA].
4. Procedures
The M3UA layer needs to respond to various local primitives it
receives from other layers as well as the messages that it receives
from the peer M3UA layer. This section describes the M3UA procedures
in response to these events.
4.1 Procedures to Support the M3UA-User
4.1.1 Receipt of Primitives from the M3UA-User
On receiving an MTP-TRANSFER request primitive from an upper layer at
an IPSP, the M3UA layer sends a corresponding DATA message (see
Section 3 of [M3UA-RFC]) to its M3UA peer. The M3UA peer receiving
the DATA message sends an MTP-TRANSFER indication primitive to the
upper layer.
The M3UA message distribution function (see Section 1.4.2.1 in [M3UA-
RFC]) determines the Application Server (AS) based on comparing the
information in the MTP-TRANSFER request primitive with a provisioned
Routing Key.
From the list of IPSPs within the AS table, a remote IPSP in the ASP-
ACTIVE state is selected and a DATA message is constructed and issued
on the corresponding SCTP association. If more than one IPSP is in
the ASP-ACTIVE state (i.e., traffic is to be loadshared across more
than one IPSP), one of the IPSP in the ASP_ACTIVE state is selected
from the list. If the IPSPs are in Broadcast Mode, all active IPSPs
will be selected and the message sent to each of the active IPSPs.
The selection algorithm is implementation dependent but could, for
example, be round robin or based on the SLS or ISUP CIC. The
appropriate selection algorithm must be chosen carefully as it is
Pastor, Schwarzbauer [Page 10]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
dependent on application assumptions and understanding of the degree
of state coordination between the ASP_ACTIVE IPSPs in the AS.
In addition, the message needs to be sent on the appropriate SCTP
stream, again taking care to meet the message sequencing needs of the
signalling application. DATA messages MUST be sent on an SCTP stream
other than stream '0'.
4.1.2 Receipt of Primitives from the Layer Management
On receiving primitives from the local Layer Management, the M3UA
layer will take the requested action and provide an appropriate
response primitive to Layer Management.
An M-SCTP_ESTABLISH request primitive from Layer Management at an
IPSP will initiate the establishment of an SCTP association. The
M3UA layer will attempt to establish an SCTP association with the
remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local
SCTP layer.
When an SCTP association has been successfully established, the SCTP
will send an SCTP-COMMUNICATION_UP notification primitive to the
local M3UA layer. At the IPSP that initiated the request, the M3UA
layer will send an M-SCTP_ESTABLISH confirm primitive to Layer
Management when the association setup is complete. At the peer M3UA
layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer
Management upon successful completion of an incoming SCTP association
setup.
An M-SCTP_RELEASE request primitive from Layer Management initiates
the teardown of an SCTP association. The M3UA layer accomplishes a
graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN
primitive to the SCTP layer.
When the graceful shutdown of the SCTP association has been
accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE
notification primitive to the local M3UA layer. At the M3UA Layer
that initiated the request, the M3UA layer will send an M-
SCTP_RELEASE confirm primitive to Layer Management when the
association shutdown is complete. At the peer M3UA Layer, an M-
SCTP_RELEASE indication primitive is sent to Layer Management upon
abort or successful shutdown of an SCTP association.
An M-SCTP_STATUS request primitive supports a Layer Management query
of the local status of a particular SCTP association. The M3UA layer
simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS
primitive to the SCTP layer. When the SCTP responds, the M3UA layer
maps the association status information to an M-SCTP_STATUS confirm
primitive. No peer protocol is invoked.
Pastor, Schwarzbauer [Page 11]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive
mappings can be described for the various other SCTP Upper Layer
primitives in RFC2960 [17] such as INITIALIZE, SET PRIMARY, CHANGE
HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD,
SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND
NETWORK STATUS CHANGE. Alternatively, these SCTP Upper Layer
primitives (and Status as well) can be considered for modelling
purposes as a Layer Management interaction directly with the SCTP
Layer.
M-NOTIFY indication and M-ERROR indication primitives indicate to
Layer Management the notification or error information contained in a
received M3UA Notify or Error message respectively. These
indications can also be generated based on local M3UA events.
An M-ASP_STATUS request primitive supports a Layer Management query
of the status of a particular local or remote IPSP. The M3UA layer
responds with the status in an M-ASP_STATUS confirm primitive. No
M3UA peer protocol is invoked.
An M-AS_STATUS request supports a Layer Management query of the
status of a particular AS. The M3UA responds with an M-AS_STATUS
confirm primitive. No M3UA peer protocol is invoked.
M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-
ASP_INACTIVE request primitives allow Layer Management at an IPSP to
initiate state changes. Upon successful completion, a corresponding
confirm primitive is provided by the M3UA layer to Layer Management.
If an invocation is unsuccessful, an Error indication primitive is
provided in the primitive. These requests result in outgoing ASP Up,
ASP Down, ASP Active and ASP Inactive messages to the remote IPSP
M3UA peer.
4.2 Procedures to Support the Management of SCTP Associations
4.2.1 Receipt of M3UA Peer Management Messages
Upon successful state changes resulting from reception of ASP Up, ASP
Down, ASP Active and ASP Inactive messages from a peer M3UA, the M3UA
layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE and
M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication
primitives to the local Layer Management.
M-NOTIFY indication and M-ERROR indication primitives indicate to
Layer Management the notification or error information contained in a
received M3UA Notify or Error message. These indications can also be
generated based on local M3UA events.
All non-Transfer and non-SSNM messages, except BEAT and BEAT Ack,
SHOULD be sent with sequenced delivery to ensure ordering. ASPTM
Pastor, Schwarzbauer [Page 12]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
messages MAY be sent on one of the streams used to carry the data
traffic related to the Routing Context(s), to minimize possible
message loss. BEAT and BEAT Ack messages MAY be sent using out-of-
order delivery, and MAY be sent on any stream.
4.3 AS and IPSP State Maintenance
The M3UA layer on the IPSP maintains the state of each remote IPSP,
in each Application Server that the IPSP is configured to receive
traffic, as input to the M3UA message distribution function.
4.3.1 IPSP States
The state of each remote IPSP, in each AS that it is configured to
operate, is maintained in the M3UA layer in the peer IPSP. The state
of a particular IPSP in a particular AS changes due to events. The
events include:
* Reception of messages from the peer M3UA layer at the IPSP;
* Reception of some messages from the peer M3UA layer at other
IPSPs in the AS (e.g., ASP Active message indicating
"Override");
* Reception of indications from the SCTP layer; or
* Local Management intervention.
The IPSP state transition diagram is shown in Figure 2. The possible
states of an IPSP are:
ASP-DOWN: The remote M3UA peer at the IPSP is unavailable and/or the
related SCTP association is down. Initially all IPSPs will be in
this state. An IPSP in this state SHOULD NOT be sent any M3UA
messages, with the exception of Heartbeat, ASP Down Ack and Error
messages.
ASP-INACTIVE: The remote M3UA peer at the IPSP is available (and the
related SCTP association is up) but application traffic is stopped.
In this state the IPSP SHOULD NOT be sent any DATA or SSNM messages
for the AS for which the ASP is inactive.
ASP-ACTIVE: The remote M3UA peer at the IPSP is available and
application traffic is active (for a particular Routing Context or
set of Routing Contexts).
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
Down Indication to the Upper Layer Protocol (M3UA) on an IPSP. The
local SCTP layer will send this indication when it detects the loss
of connectivity to the IPSPÆs peer SCTP layer. SCTP CDI is
understood as either a SHUTDOWN_COMPLETE notification or
COMMUNICATION_LOST notification from the SCTP layer.
Pastor, Schwarzbauer [Page 13]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
SCTP RI: The local SCTP layer's Restart indication to the upper layer
protocol (M3UA) on an IPSP. The local SCTP will send this indication
when it detects a restart from the IPSP's peer SCTP layer.
Figure 2: IPSP State Transition Diagram, per AS
+--------------+
| |
+----------------------| ASP-ACTIVE |
| Other +-------| |
| IPSP in AS | +--------------+
| Overrides | ^ |
| | ASP | | ASP
| | Active | | Inactive
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI/
SCTP RI | | v SCTP RI
| +--------------+
| | |
+--------------------->| ASP-DOWN |
| |
+--------------+
4.3.2 AS States
The state of the AS is maintained in the M3UA layer on the remote
ASs. The state of an AS changes due to events. These events include:
* IPSP state transitions
* Recovery timer triggers
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies
that all related IPSPs are in the ASP-DOWN state for this AS.
Initially the AS will be in this state. An Application Server is in
the AS-DOWN state when it is removed from a configuration.
AS-INACTIVE: The Application Server is available but no application
traffic is active (i.e., one or more related IPSPs are in the ASP-
INACTIVE state, but none in the ASP-ACTIVE state). The recovery
timer T(r) is not running or has expired.
Pastor, Schwarzbauer [Page 14]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
AS-ACTIVE: The Application Server is available and application
traffic is active. This state implies that at least one IPSP is in
the ASP-ACTIVE state.
AS-PENDING: An active IPSP has transitioned to ASP-INACTIVE or ASP-
DOWN and it was the last remaining active IPSP in the AS. A recovery
timer T(r) SHOULD be started and all incoming signalling messages
SHOULD be queued by the peer IPSP. If an IPSP becomes ASP-ACTIVE
before T(r) expires, the AS is moved to the AS-ACTIVE state and all
the queued messages will be sent to the IPSP.
If T(r) expires before an IPSP becomes ASP-ACTIVE, and the peer IPSP
has no alternative, the peerm IPSP may stops queuing messages and
discards all previously queued messages. The AS will move to the AS-
INACTIVE state if at least one IPSP is in ASP-INACTIVE state,
otherwise it will move to AS-DOWN state.
Figure 3 shows an example AS state machine for the case where the
AS/IPSP data is preconfigured. For other cases where the AS/IPSP
configuration data is created dynamically, there would be differences
in the state machine, especially at creation of the AS.
Figure 3: AS State Transition Diagram
+----------+ one IPSP trans to ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ IPSP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one IPSP| | all IPSP \ one IPSP | | Last ACTIVE
trans | | trans to \ trans to | | IPSP trans
to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<----------------------------| |
+----------+ Tr Expiry and no IPSP +-------------+
in ASP-INACTIVE state)
Pastor, Schwarzbauer [Page 15]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
Tr = Recovery Timer
For example, where the AS/IPSP configuration data is not created
until Registration of the first IPSP, the AS-INACTIVE state is
entered directly upon the first successful REG REQ from an IPSP.
Another example is where the AS/IPSP configuration data is not
created until the first IPSP successfully enters the ASP-ACTIVE
state. In this case the AS-ACTIVE state is entered directly.
4.3.3 M3UA Management Procedures for Primitives
Before the establishment of an SCTP association the IPSP state at
both IPSPs is assumed to be in the state ASP-DOWN.
Once the SCTP association is established (see Section 4.2.1) and
assuming that the local M3UA-User is ready, the local M3UA IPSP
Maintenance (IPSPM) function will initiate the relevant procedures,
using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey
the IPSP state to the peer IPSP (see Section 4.3.4).
If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or
SCTP-RESTART indication primitive from the underlying SCTP layer, it
will inform the Layer Management by invoking the M-SCTP_STATUS
indication primitive. The state of the IPSP will be moved to ASP-
DOWN.
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to
re-establish the SCTP Association. This MAY be done by the M3UA
layer automatically, or Layer Management MAY reestablish using the M-
SCTP_ESTABLISH request primitive.
In the case of an SCTP-RESTART indication at an IPSP, the IPSP is now
considered by its M3UA peer to be in the ASP-DOWN state. The IPSP,
if it is to recover, must begin any recovery with the ASP-Up
procedure.
4.3.4 ASPM Procedures for Peer-to-Peer Messages
4.3.4.1 ASP Up Procedures
After an IPSP has successfully established an SCTP association to a
peer IPSP, the peer IPSP waits for the IPSP to send an ASP Up
message, indicating that the IPSP M3UA peer is available. One IPSP
is always the initiator of the ASP Up message. This action MAY be
initiated at the IPSP by an M-ASP_UP request primitive from Layer
Management or MAY be initiated automatically by an M3UA management
function.
Pastor, Schwarzbauer [Page 16]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
When an ASP Up message is received at a peer IPSP and internally the
remote IPSP is in the ASP-DOWN state and not considered locked out
for local management reasons, the peer IPSP marks the remote IPSP in
the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up
indication primitive. If the peer IPSP is aware, via current
configuration data, which Application Servers the IPSP is configured
to operate in, the peer IPSP updates the IPSP state to ASP-INACTIVE
in each AS that it is a member.
Alternatively, the peer IPSP may move the IPSP into a pool of
Inactive IPSPs available for future configuration within Application
Server(s), determined in a subsequent Registration Request or ASP
Active procedure. If the ASP Up message contains an ASP Identifier,
the peer IPSP should save the ASP Identifier for that IPSP. The peer
IPSP MUST send an ASP Up Ack message in response to a received ASP Up
message even if the IPSP is already marked as ASP-INACTIVE at the
peer IPSP.
If for any local reason (e.g., management lockout) the peer IPSP
cannot respond with an ASP Up Ack message, the peer IPSP responds to
an ASP Up message with an Error message with reason "Refused -
Management Blocking".
At one IPSP, the ASP Up Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_UP confirm primitive.
When one IPSP sends an ASP Up message it starts timer T(ack). If the
IPSP does not receive a response to an ASP Up message within T(ack),
the IPSP MAY restart T(ack) and resend ASP Up messages until it
receives an ASP Up Ack message. T(ack) is provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Up
messages MAY be put under control of Layer Management. In this
method, expiry of T(ack) results in an M-ASP_UP confirm primitive
carrying a negative indication.
The IPSP must wait for the ASP Up Ack message before sending any
other M3UA messages (e.g., ASP Active or REG REQ). If the peer IPSP
receives any other M3UA messages before an ASP Up message is received
(other than ASP Down - see Section 4.3.4.2), the peer IPSP MAY
discard them.
If an ASP Up message is received and internally the remote IPSP is in
the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as
an Error message ("Unexpected Message), and the remote IPSP state is
changed to ASP-INACTIVE in all relevant Application Servers.
If an ASP Up message is received and internally the remote IPSP is
already in the ASP-INACTIVE state, an ASP Up Ack message is returned
and no further action is taken.
Pastor, Schwarzbauer [Page 17]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
4.3.4.1.1 M3UA Version Control
If an ASP Up message with an unsupported version is received, the
receiving end responds with an Error message, indicating the version
the receiving node supports and notifies Layer Management.
This is useful when protocol version upgrades are being performed in
a network. A node upgraded to a newer version should support the
older versions used on other nodes it is communicating with.
4.3.4.1.2 Practical Considerations (ASP Up)
To follow this process means an interchange of ASP Up messages from
each end. Therefore four messages would be needed for completion.
Another option is to consider a simple exchange. This is a
simplification for the processed explained above. An IPSP may be
considered in the ASP-INACTIVE state after an ASP Up or ASP Up Ack
has been received from it. This option does not follow the ASP state
transition diagram.
The IPSP may inform Layer Management of the change in state of the
remote IPSP using M-ASP_UP indication or confirmation primitives.
If for any local reason (e.g., management lockout) an IPSP cannot
respond to an ASP Up message with an ASP Up Ack message, it responds
to an ASP Up message with an Error message with reason "Refused -
Management Blocking" and leaves the remote IPSP in the ASP-DOWN
state.
4.3.4.2 ASP-Down Procedures
The IPSP will send an ASP Down message to a peer IPSP when the IPSP
wishes to be removed from service in all Application Servers that it
is a member and no longer receive any DATA, SSNM or ASPTM messages.
This action MAY be initiated at the IPSP by an M-ASP_DOWN request
primitive from Layer Management or MAY be initiated automatically
by an M3UA management function.
Whether the IPSP is permanently removed from any AS is a function of
configuration management. In the case where the IPSP previously used
the Registration procedures (see Section 4.4.1) to register within
Application Servers but has not deregistered from all of them prior
to sending the ASP Down message, the peer IPSP MUST consider the ASP
as Deregistered in all Application Servers that it is still a member.
Upon the reception of ASP Down message by an IPSP from a peer IPSP,
the IPSP marks the IPSP as ASP-DOWN, informs Layer Management with an
M-ASP_Down indication primitive, and returns an ASP Down Ack message
to the peer IPSP.
Pastor, Schwarzbauer [Page 18]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
An IPSP MUST send an ASP Down Ack message in response to a received
ASP Down message from the a peer IPSP even if the peer IPSP is
already marked as ASP-DOWN at the IPSP.
At an IPSP, the ASP Down Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_DOWN confirm primitive.
If an IPSP receives an ASP Down Ack without having sent an ASP Down
message, the IPSP should now consider itself as in the ASP-DOWN
state. If the IPSP was previously in the ASP-ACTIVE or ASP-INACTIVE
state, the IPSP should then initiate procedures to return itself to
its previous state.
When an IPSP sends an ASP Down message it starts timer T(ack). If the
IPSP does not receive a response to an ASP Down message within
T(ack), the IPSP MAY restart T(ack) and resend ASP Down messages
until it receives an ASP Down Ack message. T(ack) is provisionable,
with a default of 2 seconds. Alternatively, retransmission of ASP
Down messages MAY be put under control of Layer Management. In this
method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive
carrying a negative indication.
4.3.4.2.1 Practical Considerations (ASP Down)
To follow this process means an interchange of ASP Down messages from
each end. Therefore four messages would be needed for completion.
Another option is to consider a simple exchange. This is a
simplification for the processed explained above An IPSP can be
considered in the ASP-DOWN state after an ASP Down or ASP Down Ack
has been received from it. This option does not follow the ASP state
transition diagram.
The IPSP may inform Layer Management of the change in state of the
remote IPSP using M-ASP_DN indication or confirmation primitives.
If for any local reason (e.g., management lockout) an IPSP cannot
respond to an ASP Down message with an ASP Down Ack message, it
responds to an ASP Down message with an Error message with reason
"Refused - Management Blocking" and leaves the remote IPSP in the
ASP-INACTIVE state.
Pastor, Schwarzbauer [Page 19]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
4.3.4.3 ASP Active Procedures
Anytime after the IPSP has received an ASP Up Ack message from the a
peer IPSP, the IPSP MAY send an ASP Active message to the peer IPSP
indicating that the IPSP is ready to start processing traffic. This
action MAY be initiated at the IPSP by an M-ASP_ACTIVE request
primitive from Layer Management or MAY be initiated automatically by
an M3UA management function. In the case where an IPSP wishes to
process the traffic for more than one Application Server across a
common SCTP association, the ASP Active message(s) SHOULD contain a
list of one or more Routing Contexts to indicate for which
Application Servers the ASP Active message applies. It is not
necessary for the IPSP to include all Routing Contexts of interest in
a single ASP Active message, thus requesting to become active in all
Routing Contexts at the same time. Multiple ASP Active messages MAY
be used to activate within the Application Servers independently, or
in sets. In the case where an ASP Active message does not contain a
Routing Context parameter, the receiver must know, via configuration
data, which Application Server(s) the IPSP is a member.
For the Application Servers that the IPSP can be successfully
activated, the peer IPSP responds with one or more ASP Active Ack
messages, including the associated Routing Context(s) and reflecting
any Traffic Mode Type value present in the related ASP Active
message. The Routing Context parameter MUST be included in the ASP
Active Ack message(s) if the received ASP Active message contained
any Routing Contexts. Depending on any Traffic Mode Type request in
the ASP Active message, or local configuration data if there is no
request, the peer IPSP moves the IPSP to the correct ASP traffic
state within the associated Application Server(s). Layer Management
is informed with an M-ASP_Active indication. If the peer IPSP
receives any Data messages before an ASP Active message is received,
the peer IPSP MAY discard them. By sending an ASP Active Ack
message, the peer IPSP is now ready to receive and send traffic for
the related Routing Context(s). The IPSP SHOULD NOT send Data or
SSNM messages for the related Routing Context(s) before receiving an
ASP Active Ack message from the peer IPSP, or it will risk message
loss.
Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing an IPSP
to independently acknowledge the ASP Active message for different
(sets of) Routing Contexts. An IPSP MUST send an Error message
("Invalid Routing Context") for each Routing Context value that the
IPSP cannot be successfully activated.
In the case where an "out-of-the-blue" ASP Active message is received
(i.e., a peer IPSP has not registered with the IPSP or the IPSP has
no static configuration data for the peer IPSP), the message MAY be
silently discarded.
Pastor, Schwarzbauer [Page 20]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
An IPSP MUST send an ASP Active Ack message in response to a received
ASP Active message from a remote IPSP, if the remote IPSP is already
marked in the ASP-ACTIVE state at the IPSP.
At an IPSP, the ASP Active Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_ACTIVE confirm primitive.
It is possible for the IPSP to receive Data message(s) before the ASP
Active Ack message as the ASP Active Ack and Data messages from a
remote IPSP may be sent on different SCTP streams. Message loss is
possible as the IPSP does not consider itself in the ASP-ACTIVE state
until reception of the ASP Active Ack message.
When an IPSP sends an ASP Active message it starts timer T(ack). If
the IPSP does not receive a response to an ASP Active message within
T(ack), the IPSP MAY restart T(ack) and resend ASP Active messages
until it receives an ASP Active Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Active messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in an M-
ASP_ACTIVE confirm primitive carrying a negative indication.
There are three modes of Application Server traffic handling in the
IPSP M3UA layer: Override, Loadshare and Broadcast. When included,
the Traffic Mode Type parameter in the ASP Active message indicates
the traffic handling mode to be used in a particular Application
Server. If an IPSP determines that the mode indicated in an ASP
Active message is unsupported or incompatible with the mode currently
configured for a peer IPSP, the IPSP responds with an Error message
("Unsupported / Invalid Traffic Handling Mode"). If the traffic
handling mode of the Application Server is not already known via
configuration data, then the traffic handling mode indicated in the
first ASP Active message causing the transition of the Application
Server state to AS-ACTIVE MAY be used to set the mode.
In the case of an Override mode AS, reception of an ASP Active
message at an IPSP causes the (re)direction of all traffic for the AS
to the remote IPSP that sent the ASP Active message. Any previously
active remote IPSP in the AS is now considered to be in state ASP-
INACTIVE and SHOULD no longer receive traffic from the IPSP within
the AS. The IPSP then MUST send a Notify message ("Alternate
ASP_Active") to the previously active remote IPSP in the AS, and
SHOULD stop traffic to/from that remote IPSP. The remote IPSP
receiving this Notify MUST consider itself now in the ASP-INACTIVE
state, if it is not already aware of this via inter-IPSP
communication with the Overriding remote IPSP.
In the case of a Loadshare mode AS, reception of an ASP Active
message at an IPSP causes the direction of traffic to the remote IPSP
sending the ASP Active message, in addition to all the other remote
IPSPs that are currently active in the AS. The algorithm at the IPSP
for loadsharing traffic within an AS to all the active remote IPSPs
Pastor, Schwarzbauer [Page 21]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
is implementation dependent. The algorithm could, for example, be
round-robin or based on information in the Data message (e.g., the
SLS, SCCP SSN, ISUP CIC value).
An IPSP, upon reception of an ASP Active message for the first remote
IPSP in a Loadshare AS, MAY choose not to direct traffic to a newly
active remote IPSP until it determines that there are sufficient
resources to handle the expected load (e.g., until there are "n"
remote IPSPs in state ASP-ACTIVE in the AS). In this case, the IPSP
SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient
resources.
For the n+k redundancy case, IPSPs which are in that AS should
coordinate among themselves the number of active IPSPs in the AS, and
should start sending traffic only after n IPSPs are active.
All IPSPs within a loadsharing mode AS must be able to process any
Data message received for the AS, to accommodate any potential
failover or rebalancing of the offered load.
In the case of a Broadcast mode AS, reception of an ASP Active
message at an IPSP causes the direction of traffic to the remote IPSP
sending the ASP Active message, in addition to all the other remote
IPSPs that are currently active in the AS. The algorithm at the IPSP
for broadcasting traffic within an AS to all the active remote IPSPs
is a simple broadcast algorithm, where every message is sent to each
of the active remote IPSPs.
An IPSP, upon reception of an ASP Active message for the first remote
IPSP in a Broadcast AS, MAY choose not to direct traffic to a newly
active remote IPSP until it determines that there are sufficient
resources to handle the expected load (e.g., until there are "n"
IPSPs in state ASP-ACTIVE in the AS). In this case, the IPSP SHOULD
withhold the Notify (AS-ACTIVE) until there are sufficient resources.
For the n+k redundancy case, IPSPs which are in that AS should
coordinate among themselves the number of active IPSPs in the AS, and
should start sending traffic only after n IPSPs are active.
Whenever an IPSP in a Broadcast mode AS becomes ASP-ACTIVE, the peer
IPSP MUST tag the first DATA message broadcast in each traffic flow
with a unique Correlation Id parameter. The purpose of this Id is to
permit the newly active IPSP to synchronize its processing of traffic
in each traffic flow with the other IPSPs in the broadcast group.
4.3.4.3.1 Practical Considerations (ASP Active)
Either of the IPSPs can initiate communication.
An interchange of ASP Active messages from each end is performed.
This behavior gives the additional advantage of allowing the
Pastor, Schwarzbauer [Page 22]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
selection of a particular AS to be activated from each end. It is
especially useful when an IPSP is serving more than one AS. It will
need four messages for completion.
Alternatively a simplification of this process can also be
implemented. When an IPSP receives an ASP Active, it should mark the
peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP
receiving an ASP Active Ack message may mark the peer as ASP-Active,
if it is not already in the ASP-ACTIVE state. This option does not
follow the IPSP state transition diagram. Only two messages will be
needed for completion.
4.3.4.4 ASP Inactive Procedures
When an IPSP wishes to withdraw from receiving traffic within an AS,
the IPSP sends an ASP Inactive message to the peer IPSP. This action
MAY be initiated at the IPSP by an M-ASP_INACTIVE request primitive
from Layer Management or MAY be initiated automatically by an M3UA
management function. In the case where an IPSP is processing the
traffic for more than one Application Server across a common SCTP
association, the ASP Inactive message contains one or more Routing
Contexts to indicate for which Application Servers the ASP Inactive
message applies. In the case where an ASP Inactive message does not
contain a Routing Context parameter, the receiver must know, via
configuration data, which Application Servers the IPSP is a member
and move the IPSP to the ASP-INACTIVE state in all Application
Servers. In the case of an Override mode AS, where another IPSP has
already taken over the traffic within the AS with an ASP Active
("Override") message, the IPSP that sends the ASP Inactive message is
already considered by the peer IPSP to be in state ASP-INACTIVE. An
ASP Inactive Ack message is sent to the IPSP, after ensuring that all
traffic is stopped to the IPSP.
In the case of a Loadshare mode AS, the IPSP moves the peer IPSP to
the ASP-INACTIVE state and the AS traffic is reallocated across the
remaining peer IPSPs in the state ASP-ACTIVE, as per the loadsharing
algorithm currently used within the AS. A Notify message
"Insufficient ASP resources active in AS") MAY be sent to all
inactive remote IPSPs, if required. An ASP Inactive Ack message is
sent to the remote IPSP after all traffic is halted and Layer
Management is informed with an M-ASP_INACTIVE indication primitive.
In the case of a Broadcast mode AS, the IPSP moves the remote IPSP to
the ASP-INACTIVE state and the AS traffic is broadcast only to the
remaining remote ASPs in the state ASP-ACTIVE within that AS. A
Notify message ("Insufficient ASP resources active in AS") MAY be
sent to all remote inactive IPSPs within the AS, if required. An ASP
Inactive Ack message is sent to the remote IPSP after all traffic is
halted and Layer Management is informed with an M-ASP_INACTIVE
indication primitive.
Pastor, Schwarzbauer [Page 23]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
Multiple ASP Inactive Ack messages MAY be used in response to an ASP
Inactive message containing multiple Routing Contexts, allowing an
IPSP to independently acknowledge for different (sets of) Routing
Contexts upon the reception of ASP Inactive message with several RCs.
The IPSP sends an Error message ("Invalid Routing Context") message
for each invalid or unconfigured Routing Context value in a received
ASP Inactive message.
An IPSP MUST send an ASP Inactive Ack message in response to a
received ASP Inactive message from a peer IPSP and the peer IPSP is
already marked as ASP-INACTIVE at the IPSP.
At an IPSP, the ASP Inactive Ack message received is not
acknowledged. Layer Management is informed with an M-ASP_INACTIVE
confirm primitive.
If an IPSP receives an ASP Inactive Ack without having sent an ASP
Inactive message, the IPSP should now consider itself as in the ASP-
INACTIVE state. If the IPSP was previously in the ASP-ACTIVE state,
the ASP should then initiate procedures to return itself to its
previous state.
When an IPSP sends an ASP Inactive message it starts timer T(ack).
If the IPSP does not receive a response to an ASP Inactive message
within T(ack), the IPSP MAY restart T(ack) and resend ASP Inactive
messages until it receives an ASP Inactive Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Inactive messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in a M-
ASP_Inactive confirm primitive carrying a negative indication.
If when an IPSP sending an ASP Inactive message to a remote IPSP, no
other remote IPSPs in the Application Server are in the state ASP-
ACTIVE, the IPSP sending the ASP Inactive message MUST send a Notify
message ("AS-Pending") to all of the remote IPSPs in the AS which are
in the state ASP-INACTIVE. The IPSP SHOULD also start buffering the
messages directed to that AS for T(r) seconds, after which messages
MAY be discarded. T(r) is configurable by the network operator. If
the IPSP receives an ASP Active message from a remote IPSP in the AS
before expiry of T(r), the buffered traffic is directed to that
remote IPSP and the timer is cancelled. If T(r) expires, the AS is
moved to the AS-INACTIVE state.
4.3.4.4.1 Practical Considerations (ASP Inactive)
An interchange of ASP Inactive messages from each end is performed.
This option gives the additional advantage of allowing the selection
of a particular AS to be deactivated from each end. It is especially
useful when an IPSP is serving more than one AS. It would need four
messages for completion.
Pastor, Schwarzbauer [Page 24]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
A simplification can apply for some cases. An IPSP may be considered
in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive or
ASP Inactive Ack message has been received from it. This option does
not follow the IPSP state transition diagram. Only two messages will
be needed for completion.
4.3.4.5 Notify Procedures
A Notify message reflecting a change in the AS state MUST be sent to
all peer IPSPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed
IPSP. At the peer IPSP, Layer Management is informed with an M-
NOTIFY indication primitive. The Notify message must be sent whether
the AS state change was a result of an IPSP failure or reception of
an ASP State management (ASPSM) / ASP Traffic Management (ASPTM)
message. In the second case, the Notify message MUST be sent after
any related acknowledgement messages (e.g., ASP Up Ack, ASP Down
Ack, ASP Active Ack, or ASP Inactive Ack).
In the case where a Notify message("AS-PENDING") message is sent by a
IPSP that now has no peer IPSPs active to service the traffic, or
where a Notify ("Insufficient ASP/IPSP resources active in AS")
message is sent in the Loadshare or Broadcast mode, the Notify
message does not explicitly compel the peer IPSP(s) receiving the
message to become active. The IPSPs remain in control of what (and
when) traffic action is taken.
In the case where a Notify message does not contain a Routing Context
parameter, the receiver must know, via configuration data, of which
Application Servers the IPSP is a member and take the appropriate
action in each AS.
4.3.4.6 Heartbeat Procedures
The optional Heartbeat procedures MAY be used when operating over
transport layers that do not have their own heartbeat mechanism for
detecting loss of the transport association (i.e., other than SCTP).
Either M3UA peer may optionally send Heartbeat messages periodically,
subject to a provisionable timer T(beat). Upon receiving a Heartbeat
message, the M3UA peer MUST respond with a Heartbeat Ack message.
If no Heartbeat Ack message (or any other M3UA message) is received
from the M3UA peer within 2*T(beat), the remote M3UA peer is
considered unavailable. Transmission of Heartbeat messages is
stopped and the signalling process SHOULD attempt to reestablish
communication if it is configured as the client for the disconnected
M3UA peer.
Pastor, Schwarzbauer [Page 25]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
The Heartbeat message may optionally contain an opaque Heartbeat Data
parameter that MUST be echoed back unchanged in the related Heartbeat
Ack message. The sender, upon examining the contents of the returned
Heartbeat Ack message, MAY choose to consider the remote M3UA peer as
unavailable. The contents/format of the Heartbeat Data parameter is
implementation-dependent and only of local interest to the original
sender. The contents may be used, for example, to support a
Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a
timestamp mechanism (to evaluate delays).
Note: Heartbeat related events are not shown in Figure 4 "IPSP state
transition diagram".
4.4 Routing Key Management Procedures [Optional]
4.4.1 Registration
An IPSP MAY dynamically register with a peer IPSP as an IPSP within
an Application Server using the REG REQ message. A Routing Key
parameter in the REG REQ message specifies the parameters associated
with the Routing Key.
The peer IPSP examines the contents of the received Routing Key
parameter and compares it with the currently provisioned Routing
Keys. If the received Routing Key matches an existing IPSP Routing
Key entry at the peer IPSP, and the IPSP is not currently included in
the list of IPSPs for the related Application Server, the peer IPSP
MAY authorize the IPSP to be added to the AS. Or, if the Routing Key
does not currently exist and the received Routing Key data is valid
and unique, a peer IPSP supporting dynamic configuration MAY
authorize the creation of a new Routing Key and related Application
Server and add the IPSP to the new AS. In either case, the peer IPSP
returns a Registration Response message to the IPSP, containing the
same Local-RK-Identifier as provided in the initial request, and a
Registration Result "Successfully Registered". A unique Routing
Context value assigned to the peer IPSP Routing Key is included. The
method of Routing Context value assignment at the peer IPSP is
implementation dependent but must be guaranteed to be unique for each
Application Server or Routing Key supported by the peer IPSP.
If an IPSP does not support the registration procedure, upon a REG
REQ message from a peer IPSP, the IPSP returns an Error message to
the peer IPSP, with an error code of "Unsupported Message Type".
If an IPSP determines that the received Routing Key data included in
a REG REQ is invalid, or contains invalid parameter values, the peer
IPSP returns a Registration Response message to the peer IPSP,
containing a Registration Result "Error - Invalid Routing Key",
"Error - Invalid DPC", "Error - Invalid Network Appearance" as
appropriate.
Pastor, Schwarzbauer [Page 26]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
If an IPSP determines that a unique Routing Key cannot be created
upon the reception of a REG REQ message, the IPSP returns a
Registration Response message to the peer IPSP, with a Registration
Status of "Error - "Cannot Support Unique Routing". An outcoming
signalling message sent by the local application to a peer IPSP
should not match against more than one Routing Key.
If an IPSP does not authorize an otherwise valid registration request
from a peer IPSP, the IPSP returns a REG RSP message to the peer IPSP
containing the Registration Result "Error - Permission Denied".
If an IPSP determines that a received Routing Key does not currently
exist and the IPSP does not support dynamic configuration, the IPSP
returns a Registration Response message to the peer IPSP, containing
a Registration Result "Error - Routing Key not Currently
Provisioned".
If an IPSP determines that a received Routing Key does not currently
exist and the IPSP supports dynamic configuration but does not have
the capacity to add new Routing Key and Application Server entries,
the IPSP returns a Registration Response message to the peer IPSP,
containing a Registration Result "Error - Insufficient Resources".
If an IPSP determines that one or more of the Routing Key parameters
are not supported for the purpose of creating new Routing Key
entries, the IPSP returns a Registration Response message to the
remote IPSP, containing a Registration Result "Error - Unsupported RK
parameter field". This result MAY be used if, for example, the IPSP
does not support RK Circuit Range Lists in a Routing Key because the
IPSP does not support ISUP traffic, or does not provide CIC range
granularity.
A Registration Response "Error - Unsupported Traffic Handling Mode"
is returned if the Routing Key in the REG REQ contains an Traffic
Handling Mode that is inconsistent with the presently configured mode
for the matching Application Server.
An IPSP MAY register multiple Routing Keys at once by including a
number of Routing Key parameters in a single REG REQ message. The
peer IPSP MAY respond to each registration request in a single REG
RSP message, indicating the success or failure result for each
Routing Key in a separate Registration Result parameter.
Alternatively the peer IPSP MAY respond with multiple REG RSP
messages, each with one or more Registration Result parameters. The
IPSP uses the Local-RK-Identifier parameter to correlate the requests
with the responses.
Pastor, Schwarzbauer [Page 27]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
4.4.2 Deregistration
An IPSP MAY dynamically deregister with a peer IPSP as an IPSP within
an Application Server using the DEREG REQ message. A Routing Context
parameter in the DEREG REQ message specifies which Routing Keys to
deregister. An IPSP SHOULD move to the ASP-INACTIVE state for an
Application Server before attempting to deregister the Routing Key
(i.e., deregister after receiving an ASP Inactive Ack). Also, an
IPSP SHOULD deregister from all Application Servers that it is a
member before attempting to move to the ASP-Down state.
The IPSP receiving the DEREG REQ message examines the contents of the
received Routing Context parameter and validates that the peer IPSP
is currently registered in the Application Server(s) related to the
included Routing Context(s). If validated, the peer IPSP is
deregistered as an IPSP in the related Application Server.
The deregistration procedure does not necessarily imply the deletion
of Routing Key and Application Server configuration data at the IPSP.
Other IPSPs may continue to be associated with that Application
Server, in which case the Routing Key data SHOULD NOT be deleted. If
a Deregistration results in no more remote IPSPs registered in an
Application Server, an IPSP MAY delete the Routing Key data.
An IPSP acknowledges the deregistration request by returning a DEREG
RSP message to the requesting IPSP. The result of the deregistration
is found in the Deregistration Result parameter, indicating success
or failure with cause.
An IPSP MAY deregister multiple Routing Contexts at once by including
a number of Routing Contexts in a single DEREG REQ message. The peer
IPSP MAY respond to each deregistration request in a single DEREG RSP
message, indicating the success or failure result for each Routing
Context in a separate Deregistration Result parameter.
5. Examples of M3UA Procedures for IPSP
The IPSPs are named as IPSP-X[Z][n] where:
- X: the AS name, in this section it is represented by a capital
letter.
- Z: other optional AS names whenever the IPSP serve to more than
one AS.
- n: an optional number used when it is necessary to differenciate
amongst several IPSPs that serve the same AS.
The first section deals with the establishment of connections between
IPSPs. It starts with the simple case of one IPSP per AS and with no
registration. The optional registration procedure is added in the
next example. In the third example the IPSP serves to more than one
Pastor, Schwarzbauer [Page 28]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
AS. Next examples show the extension to configurations with two IPSPs
per AS, using loadsharing and override traffic mode types. The last
example extends the explanation to three IPSPs serving one AS with
the loadsharing traffic mode type to complete the whole picture.
In this example section only the messages regarding to one side are
shown. Where the double exchange method is used to establish/withdraw
the connection, the same messages and rules will apply to the other
end.
The second section shows failover examples for override and
loadsharing traffic mode types.
The third section explains the withdrawing of the communication for
the simplest case shown in the first section. The extension to more
complicated scenarios is easily inferred.
As in section one, only the messages from one end are shown; to
complete the double exchange method the same messages need to be
exchanged from the other end.
Finally, a complete example includig all the amin messages is shown
for double and simple exchange methods using a very simple scenario.
5.1 Establishment of Association and Traffic between IPSPs
These scenarios show the example M3UA message flows for the
establishment of traffic between two IPSPs. In all cases it is
assumed that the SCTP association is already set up.
5.1.1 Single IPSP in a remote Application Server ("1+0" sparing)
These scenarios show the example M3UA message flows for the
establishment of traffic between two IPSPs, where only one ASP/IPSP
is configured within an AS/IPS (no backup).
Pastor, Schwarzbauer [Page 29]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
5.1.1.1 Single IPSP in an Application Server ("1+0" sparing), No
Registration
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|<------- ASP Active(RCn)--------| RC: Routing Context
|-----ASP Active Ack (RCn)------>| (optional)
| |
Note: If the ASP Active message contains an optional Routing Context
parameter, The ASP Active message only applies for the specified RC
value(s). For an unknown RC value, the IPSP-A responds with an Error
message.
5.1.1.2 Single IPSP in remote Application Server ("1+0" sparing),
Dynamic Registration
This scenario is the same as for 5.1.1.1 but with the optional
exchange of registration information. In this case the Registration
is accepted by the IPSP.
IPSP-A IPSP-B
| |
|<------------ASP Up-------------|
|----------ASP Up Ack----------->|
| |
|<----REGISTER REQ(LRC-B,RK-B)---| LRC: Local Routing
| | Context
|----REGISTER RESP(LRC-B,RC-B)-->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RC-B)-------|
|-----ASP Active Ack (RC-B)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RK-B), the Register Response message will contain an
unsuccessful indication and the IPSP will not subsequently send an
ASP Active message.
Pastor, Schwarzbauer [Page 30]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
5.1.1.3 Single remote IPSP in Multiple Application Servers (each with
"1+0" sparing), Dynamic Registration (Case 1 - Multiple Registration
Requests)
IPSP-A IPSP-BC
| |
|<------------ASP Up-------------|
|----------ASP Up Ack----------->|
| |
|<----REGISTER REQ(LRC-B,RK-B)---| LRC: Local Routing
| | Context
|----REGISTER RESP(LRC-B,RC-B)-->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RC-B)-------|
|-----ASP Active Ack (RC-B)----->|
| |
| |
|<----REGISTER REQ(LRC-C,RK-C)---|
| |
|----REGISTER RESP(LRC-C,RC-C)-->|
| |
| |
|<------- ASP Active(RC-C)-------|
|-----ASP Active Ack (RC-C)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RK-C), the Register Response message will contain an
unsuccessful indication and the IPSP will not subsequently send an
ASP Active message. Each LRC/RK pair registration is considered
independently.
It is not necessary to follow a Registration Request/Response message
pair with an ASP Active message before sending the next Registration
Request. The ASP Active message can be sent at any time after the
related successful registration.
Pastor, Schwarzbauer [Page 31]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
5.1.1.4 Single IPSP in Multiple Application Servers (each with "1+0"
sparing), Dynamic Registration (Case 2 - Single Registration Request)
IPSP-A IPSP-BC
| |
|<------------ASP Up-------------|
|----------ASP Up Ack----------->|
| |
|<---REGISTER REQ({LRC-B,RK-B},--|
| {LRC-C,RK-C}) |
| |
|---REGISTER RESP({LRC-B,RC-B},->|
| (LRC-C,RC-C}) |
| |
|<------- ASP Active(RC-B)-------|
|-----ASP Active Ack (RC-B)----->|
| |
| |
|<------- ASP Active(RC-C)-------|
|-----ASP Active Ack (RC-C)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
Invalid RK-C), the Register Response message will contain an
unsuccessful indication and the IPSP will not subsequently send an
ASP Active message. Each LRC/RK pair registration is considered
independently.
The ASP Active message can be sent at any time after the related
successful registration, and may have more than one RC.
5.1.2 Two IPSPs in Application Server ("1+1" sparing)
This scenario shows the example M3UA message flows for the
establishment of traffic between an IPSP and two IPSPs in the same
AS, where IPSP-B1 is configured to be in the ASP-ACTIVE state and
IPSP-B2 is to be a "backup" in the event of communication failure or
the withdrawal from service of IPSP1. IPSP2 may act as a hot, warm,
or cold backup depending on the extent to which IPSP1 and IPSP2 share
call/transaction state or can communicate call state under
failure/withdrawal events. The example message flow is the same
whether the ASP Active messages indicate "Override", "Loadshare" or
"Broadcast" mode, although typically this example would use an
Override mode.
Pastor, Schwarzbauer [Page 32]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
IPSP-A IPSP-B1 IPSP-B2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|<-----------------------------ASP Up----------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<-------ASP Active-------| |
|------ASP Active Ack---->| |
| | |
5.1.3 Two IPSPs in an Application Server ("1+1" sparing, loadsharing
case)
This scenario shows a similar case to Section 5.1.2 but where the two
IPSPs are brought to the state ASP-ACTIVE and subsequently loadshare
the traffic. In this case, one IPSP is sufficient to handle the total
traffic load.
IPSP-A IPSP-B1 IPSP-B2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|-----ASP-Active Ack----->| |
| | |
|----------------------------NOTIFY (AS-ACTIVE------>|
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-------------------------------ASP Active Ack------>|
| | |
5.1.4 Three IPSPs in an Application Server ("n+k" sparing, loadsharing
case)
This scenario shows the example M3UA message flows for the
establishment of traffic between an IPSP and three IPSPs in the same
AS, where two of the IPSPs are brought to the state ASP-ACTIVE and
subsequently share the load. In this case, a minimum of two IPSPs are
required to handle the total traffic load (2+1 sparing).
Pastor, Schwarzbauer [Page 33]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
IPSP-A IPSP-B1 IPSP-B2 IPSP-B3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|<--------------------------ASP Up-------| |
|-------------------------ASP Up Ack---->| |
| | | |
|<---------------------------------------------ASP Up--------|
|---------------------------------------------ASP Up Ack---->|
| | | |
| | | |
|<--ASP Act (Ldshr)--| | |
|----ASP Act Ack---->| | |
| | | |
|----------Notify (AS-ACTIVE)----------->| |
|-----------------------Notify (AS-ACTIVE)------------------>|
| | | |
|<--------------------ASP Act. (Ldshr)---| |
|-----------------------ASP Act Ack----->| |
| | | |
5.2 IPSP Traffic Failover Examples
5.2.1 (1+1 Sparing, Withdrawal of IPSP, Backup Override)
Following on from the example in Section 5.1.2, and IPSP-B1 withdraws
from service:
IPSP-A IPSP-B1 IPSP-B2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
|------------------------NTFY(AS-Pending)----------->|
| | |
|<------------------------------ ASP Active----------|
|------------------------------ASP Active Ack------->|
| |
Note: If the IPSP-A M3UA layer detects the loss of the M3UA peer
(e.g., M3UA heartbeat loss or detection of SCTP failure), the initial
ASP Inactive message exchange (i.e., between IPSP-A and IPSP-B1)
would not occur.
5.2.2 (1+1 Sparing, Backup Override)
Following on from the example in Section 5.1.2, IPSP-B2 wishes to
Override IPSP-B1 and take over the traffic:
Pastor, Schwarzbauer [Page 34]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
IPSP-A IPSP-B1 IPSP-B2
| | |
|<------------------------------ ASP Active----------|
|-------------------------------ASP Active Ack------>|
|----NTFY(Alt ASP-Act)--->|
| | |
5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of IPSP)
Following on from the example in Section 5.1.4, and IPSP-B1
withdraws from service:
IPSP-A IPSP-B1 IPSP-B2 IPSP-B3
| | | |
|<----ASP Inact.-----| | |
|---ASP Inact Ack--->| | |
| | | |
|--------------------------------NTFY(Ins. IPSPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |
For the Notify message to be sent, IPSP-A maintains knowledge of the
minimum IPSP-A resources required (e.g., if the IPSP-A knows that
"n+k" = "2+1" for a Loadshare AS and "n" currently equals "1").
Note: If IPSP-A detects loss of the IPSP-B1 M3UA peer (e.g., M3UA
heartbeat loss or detection of SCTP failure), the initial ASP
Inactive message exchange (i.e., IPSP-A <û> IPSP-B1) would not occur.
5.3 Normal Withdrawal of an IPSP from an Application Server and Teardown
of an Association
An IPSP which is now confirmed in the state ASP-INACTIVE (i.e., the
IPSP has received an ASP Inactive Ack message) may now proceed to the
ASP-DOWN state, if it is to be removed from service. Following on
from Section 5.2.1 or 5.2.3, where IPSP-B has moved to the "Inactive"
state:
IPSP-A IPSP-B
| |
|<-----ASP Inactive (RC-B)------| RC: Routing Context
|----ASP Inactive Ack (RC-B)--->|
| |
|<-----DEREGISTER REQ(RC-B)-----| See Notes
| |
|--DEREGISTER RESP(LRC-B,RC-B)->|
Pastor, Schwarzbauer [Page 35]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
| |
| |
| |
|<-----------ASP Down-----------|
|---------ASP Down Ack--------->|
| |
Note: The Deregistration procedure MUST be used if the IPSP-B
previously used the Registration procedures for configuration within
the Application Server. ASP Inactive and Deregister messages
exchanges may contain multiple Routing Contexts.
IPSP-B SHOULD be in the ASP-INACTIVE state and SHOULD have
deregistered in all its Routing Contexts before attempting to move to
the ASP-DOWN state.
5.4 M3UA/MTP3-User Boundary Examples for an IPSP
This section describes the primitive mapping between the MTP3 User
and the M3UA layer at an IPSP.
5.4.1 Support for MTP-TRANSFER Primitives at the IPSP
When the MTP3-User on the IPSP has data to send to a remote MTP3-
User, it uses the MTP-TRANSFER request primitive. The M3UA layer at
the IPSP will do the following when it receives an MTP-TRANSFER
request primitive from the M3UA user:
- Determine the correct IPSP;
- Determine the correct association to the chosen IPSP;
- Determine the correct stream in the association (e.g., based on
SLS);
- Determine whether to complete the optional fields of the DATA
message;
- Map the MTP-TRANSFER request primitive into the Protocol Data
field of a DATA message;
- Send the DATA message to the remote M3UA peer at the remote IPSP,
over the SCTP association.
IPSP-A IPSP-B
| |
|<-----DATA Message-------|<--MTP-TRANSFER req.
| |
When the M3UA layer on the IPSP receives a DATA message from the M3UA
peer at the remote IPSP, it will do the following:
Pastor, Schwarzbauer [Page 36]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
- Evaluate the optional fields of the DATA message, if present;
- Map the Protocol Data field of a DATA message into the MTP-
TRANSFER indication primitive;
- Pass the MTP-TRANSFER indication primitive to the user part. In
case of multiple user parts, the optional fields of the Data
message are used to determine the concerned user part.
IPSP-A IPSP-B
| |
|------Data Message------>|-->MTP-Transfer ind.
| |
5.5 Complete examples for IPSP communication.
These scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection) using the simplest scenario.
It is assumed that the SCTP association is already set up. Both
single exchange and double exchange behavior are included for
illustrative purposes.
5.5.1 Single exchange
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RC-B)-------| RC: Routing Context
|-----ASP Active Ack (RC-B)----->| (optional)
| |
| |
|<========= DATA (RC-B) =======>|
| |
|<-----ASP Inactive (RC-B)-------| RC: Routing Context
|----ASP Inactive Ack (RC-B)---->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context are previously agreed to be the same in both
directions.
5.5.2 Double exchange
Pastor, Schwarzbauer [Page 37]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RC-B)-------| RC: Routing Context
|-----ASP Active Ack (RC-B)----->| (optional)
| |
|------- ASP Active(RC-A)------->| RC: Routing Context
|<-----ASP Active Ack (RC-A)-----| (optional)
| |
|<========= DATA (RC-A) ========|
|========== DATA (RC-B) =======>|
| |
|<-----ASP Inactive (RC-B)-------| RC: Routing Context
|----ASP Inactive Ack (RC-B)---->|
| |
|------ASP Inactive (RC-A)------>| RC: Routing Context
|<----ASP Inactive Ack (RC-A)----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
6. Acknowledgements
The authors would like to thank Ken Morneault, Lyndon Ong and Greg
Sidebottom for their valuable comments.
7. Authors' Addresses
Javier Pastor-Balbas
Ericsson Espana S.A.
Ombu 3
28045 Madrid
Spain
Phone: +34-91-339-3819
Email: j.javier.pastor@ericsson.com
HannsJuergen Schwarzbauer
SIEMENS AG
Pastor, Schwarzbauer [Page 38]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
Hofmannstr. 51
81359 Munich
Germany
Phone: +49-89-722-24236
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
8. References
[RFC-M3UA] "MTP3 User Adaptation Layer"
9. Open Issues
This are the open issues that have been detected for the moment:
@ Concept of "connection state" for double exchange. When the
connection is ready to exchange DATA messages. Unidirectional
connections allowed? Personal opinion: no.
@ Compatibility of single exchange with double exchange
Annex A: Example or RK use within IPSP communication
AS3 wants to send traffic to AS1 and AS2. So, it needs two Routing
Keys. AS1/AS2 needs to be able to send traffic back to AS3 so they
need one Routing Key.
AS1 AS2 AS3
+--------------+ +---------------+ +--------------+
| IPSP1 IPSP2 | | IPSP1 IPSP2 | | IPSP1 IPSP2 |
+--------------+ +---------------+ +--------------+
| | | |
| -------------------- |
| |
----------------------------------------------
AS1: Routing Key 1 = AS3
AS2: Routing Key 1 = AS3
AS3: Routing Key 1 = AS1
Routing Key 2 = AS2
Note: lines show logical connections between ASes.
Pastor, Schwarzbauer [Page 39]
INTERNET-DRAFT M3UA IPSP Communication May 20, 2002
Full 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 procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions 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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pastor, Schwarzbauer [Page 40]